AIコードレビューの確かめ方｜AIが書いたコードとAIのレビューを、技術責任者のいない会社はどう扱うか

要約

• AIのコードレビューは、人のレビューを補うものです。提供元も見落としがあると明記しており、指摘がゼロでも安全とは言えません。
• AIのレビューは、標準では承認をしません。取り込むかどうかを決めるのは人で、本番に近いデータでのテストも、レビューとは別に必要です。
• 経営者はコードを読む必要はありません。「誰が承認したか」「どのデータで試したか」「壊れたら何が起きるか」を、開発会社や社員に聞きましょう。

技術責任者のいない会社では、開発会社や社内のエンジニアが「コードはAIで書き、レビューもAIにさせています」と言ったとき、それでよいのかを判断できません。コードとは、コンピューターへの指示を書いたプログラムの中身のことです。

この記事では、生成AI（文章や画像、プログラムを作り出すAI）が書いたコードと、AIにさせたコードレビューを、経営者がどう確かめればよいかをまとめます。コードレビューとは、書いたコードを別の人が読み、誤りや危ない書き方がないかを確かめる作業です。AIの提供元が公式に説明していることと、私自身が実務で決めている確かめ方をもとにしています。

AIによるコードレビューとは何か

AIによるコードレビューとは、人の代わりにAIがコードを読み、問題のある箇所や直し方を指摘する仕組みです。

代表的なものに、GitHub Copilot code review と、Claude Code の Code Review があります。GitHub は、プログラムを保管し、複数の人で変更を管理するためのサービスです。どちらも、プルリクエストを読んで指摘を書きます。プルリクエストとは、コードの変更を本体に取り込む（マージする）前に、ほかの人に確認を依頼する申請のことです。

• GitHub Copilot code review: プルリクエストを読んで問題を見つけ、数回のクリックで反映できる修正案を出す、としています。
• Claude Code の Code Review: 複数のAIが、変更された部分をまわりのコードと合わせて読み、論理の誤り、脆弱性（悪用されると情報の漏えいや不正な操作につながる、システムの弱点）、例外的なケースの抜けといった問題を探す、としています。例外的なケース（エッジケース）とは、ふだんは起きない、まれな条件のことです。2026年10月時点で、対象は Team と Enterprise のプランです。

経営者が押さえておく点は、AIのレビューは「変更を読んで意見を書く」仕組みだということです。「取り込んでよい」と決める仕組みではありません。

AIのレビューで指摘がなければ、安全と言えるか

言えません。どちらの提供元も、AIのレビューには見落としがあると公式に書いています。

• GitHub: Copilot がプルリクエストのすべての問題を見つける保証はなく、変更が大きく複雑なときはとくに見落としうる、としています。ハルシネーション（AIが、事実と違う内容をもっともらしく出すこと）の危険もあるとし、人のレビューを補うために使い、置き換えないよう求めています。
• Claude Code: バグ（プログラムの誤り）や脆弱性などを見落とすことがあり、指摘がなくても安全とは言えない、としています。

確認する範囲にも限界があります。Copilot は、変更が加わるたびに確認する設定にしない限り、1つのプルリクエストを1回しか見ません。package.json のような、部品を管理するファイルや、ログ、SVG（画像の形式の1つ）のファイルは対象外です。

Claude Code の Code Review は、標準では、本番環境を壊す不具合を見つけることに絞っています。本番環境とは、顧客や社員が実際に使っているシステムのことです。書き方の好みや、テストが十分かどうかは見ません。また、変更とまわりのコードを読むだけで、コードを組み立てたり動かしたりはしません。

提供元の説明と、経営者にとっての意味を並べると、次のとおりです。

私は、「正しく動いているように見える」ことと「本当に正しい」ことを、分けて考えるようにしています。AIのレビューで指摘が出なかったことも、「正しい」ことの証明にはなりません。

AIが書いたコードを確かめる責任は誰にあるか

使う側にあります。AIにコードを書かせるサービスの提供元は、出力されたコードを確かめるのは利用者だと明記しています。

• GitHub Copilot: 提案されたコードを受け入れる前にレビューし、正しいか確かめるのは利用者だ、としています。一見正しくても実際には正しくないコードや、書き方は合っていても安全でないコードが出力されることがあるため、コードは必ず念入りにレビューし、テストするよう求めています。
• Claude Code: 提案されたコードや命令が安全かどうかは、許可する前に利用者が確かめるもの、としています。危険を大きく抑える仕組みはあっても、あらゆる攻撃を防げる仕組みはない、とも書いています。GitHub 上で決まった作業を自動で動かす仕組み（GitHub Actions）で使う場合も、必要な権限だけを与え、取り込む前に変更をレビューするよう勧めています。

つまり、AIが書いたコードをAIにレビューさせても、確かめる責任は会社に残ります。コードを書くAIもレビューするAIも、最後に人が確かめる前提で作られているのです。

私自身、AIが書いたコードを本番に反映する直前で止めたことがあります。例外的なケースへの備えが抜けていて、実際のデータで試すと、予想していなかったエラーが出ました。本番に近いデータで必ず試してから反映する、という決まりを守っていたので、本番に出る前に気づけたのです。AIに勧められた Excel の関数で、行をコピーしたとたんに集計がずれたこともあります。範囲の指定が、コピーしてもずれない形（絶対参照）になっていなかったためでした。どちらも、一見しただけでは誤りが分かりませんでした。

AIのレビューのほかに、どんな確かめ方があるか

人の承認と、機械の検査です。どちらも GitHub に仕組みがあります。

人の承認

GitHub のプルリクエストのレビューでは、人が変更にコメントし、改善を提案し、承認するか、直すよう求めるかを示せます。レビューの種類は次の3つです。

Copilot の「コメント」は、プルリクエストに必要な承認の数に入りません。承認を出せる設定もありますが、標準ではオフで、企業・組織・リポジトリ（プログラムとその変更の履歴をまとめて保管する場所）の単位でオンにできます。オンにすると、Copilot が、必要な承認の条件を満たす承認を出せるようになります。しかし、私が確認した時点では、まだ試験提供の段階です。Claude Code の Code Review は、承認も差し止めもせず、取り込むかどうかの判断はチームに残る、としています。

リポジトリの管理者は、承認がないと取り込めないように設定できます。ブランチ保護（本体にあたるコードの置き場所を守り、条件を満たさない変更を取り込めなくする設定）では、次のことを決められます。

• 決まった数の承認を受けないと、取り込めない
• 承認のあとに中身が変わる変更が加わったら、前の承認を取り消す
• そのコードの担当として決めた人（コードオーナー）のレビューを必須にする
• 決められた機械の検査がすべて通らないと、取り込めない

機械の検査

静的解析とは、プログラムを動かさずに誤りを見つけることです。その1つが型チェックで、値の種類（数字か文字か、など）に合わない使い方をしていないかを、動かす前に調べます。TypeScript というプログラムの言語は、自らを、この型チェックを行うツールだと説明しています。

GitHub には、コードスキャン（code scanning）という機能もあります。リポジトリのコードを解析し、セキュリティ（情報やシステムを、漏えいや不正な操作から守ること）の弱点や、コードの誤りを見つけるものです。そのための解析の仕組みとして、GitHub が開発した CodeQL があり、セキュリティの点検を自動で行います。

私は、AIが書いたコードに対して、必ず型チェックと静的解析を通し、そのうえで実際のデータと結果を突き合わせています。機械の検査は、動かす前に分かる誤りを見つけます。動かして初めて出る誤りは、実際のデータで試さないと見つかりません。

確かめ方ごとの分担を並べると、次のとおりです。

経営者は何を確かめればよいか

経営者は、コードを読まなくてかまいません。私は技術に詳しくない経営者に説明するときは、専門用語を避け、「コスト」「リスク」「時間」という3つの言葉で話すようにしています。AIで書いたコードとAIのレビューも、同じように専門用語を使わずに問えば確かめられます。開発会社や社員に、次のことを聞きましょう。

• 壊れたら、何が、誰に、どれだけ起きるか
• AIのレビューのあと、中身を理解して説明できる人が確かめ、承認したか。それは誰か
• 本番に出す前に、本番に近いデータで、誰が試したか。例外的なケースも試したか
• 型チェックや静的解析を通したか
• 画面や帳票に出る数字や名前を、元の資料と突き合わせたか

数字と名前を挙げたのは、私が、AIの出した数値と固有名詞をそのまま信じず、必ず確かめているからです。

私の判断の基準は、壊れたときの被害の大きさと、中身を理解して説明できる人がいるかの2点です。答えが「AIが確認したので大丈夫です」だけで、人の名前と試したデータが出てこないなら、そのコードは本番に出さず、試作までにとどめましょう。

専門家のレビューなしで本番に出さないコードは何か

次のコードは、AIがレビューしたかどうかに関わらず、少なくとも専門家のレビューなしでは本番に出さないようにしましょう。

• ログイン、権限の管理、決済など、安全の土台になる部分（ログインは使う人が本人かを確かめる仕組み、権限の管理は人によって見てよい情報やできる操作を分ける仕組み、決済は代金を受け取る仕組みです）
• 顧客や従業員の個人情報を扱う、本番のシステム（日本の個人情報保護法や、フィリピンで個人情報を守る法律 Data Privacy Act の対象です）
• 会計、給与、税務など、誤りがお金や法律上の責任につながるもの

どれも、壊れたときの被害が大きいものです。オンライン英会話のログイン管理ツールを手がけた案件では、試作こそ早くできたものの、本番に出す前にセキュリティと権限の設計を作り直すことになりました。社員や外注先がAIに任せて作るツールの扱いは、バイブコーディングのリスク｜AIに作らせてよいもの・いけないものと、誰が確かめるかの決め方で説明しています。

開発会社に「AIでレビューまでしているから安い」と言われたらどうするか

提案そのものは否定しなくてかまいません。確かめるのは、安くなった分がどの工程から来ているかです。提供元の説明どおり、AIのレビューは人のレビューを補うもので、コードを動かして試すものでもありません。

私は見積もりを見るとき、設計・実装・テスト・保守の工数（作業にかかる人と時間の量）の割合が妥当かを必ず確かめます。見積もりが極端に安いときは、たいていテストや保守の工数が抜けているからです。見積もりに、誰がどのデータで試すか、誰が承認するかが書かれているかを見ましょう。工数の内訳の見方は、システム開発の見積もりは妥当か、工数の内訳から確かめる方法で説明しています。

20年ほど前、知人の起業家が、安く作れたと喜んでいたビジネスマッチングサイトを確認したことがあります。セキュリティの穴がいくつも見つかり、結局は直す費用がかかって、最初からきちんと作るより高くつきました。

進め方も確かめましょう。日本の開発会社とフィリピンの開発チームに発注してきたなかで、うまくいったのは、週に一度の進捗の共有で、毎回動くものを見せてもらった案件でした。仕様書だけ渡して任せきりにした案件では、納品の間際になって、思っていたものとはまったく違うものが届きました。AIのレビューの結果を報告してもらうだけでなく、実際に動くものを定期的に見せてもらいましょう。

よくある質問

Q: AIのコードレビューを入れれば、人のレビューは要らなくなりますか。

要らなくはなりません。GitHub は、Copilot のレビューは人のレビューを補うもので、置き換えるものではないとしています。Claude Code の Code Review でも、取り込むかどうかの判断はチームに残ります。

Q: AIのレビューで指摘が1つもありませんでした。本番に出してよいですか。

指摘がないだけでは判断できません。Claude Code の説明にも、指摘がないことは、誤りがないことも安全であることも意味しない、とあります。本番に近いデータで誰が試したか、中身を説明できる人が承認したかを確かめてから決めましょう。

Q: AIに承認まで任せる設定はありますか。

GitHub Copilot には、必要な承認の条件を満たす承認を出せる設定があります。標準ではオフで、確認した時点では試験提供の段階です。設定するかどうかに関わらず、壊れたときの被害が大きいコードは、中身を説明できる人が確かめるようにしましょう。

まとめ

• AIのコードレビューは、人のレビューを補うものです。提供元も見落としがあると明記しており、指摘がゼロでも安全の証明にはなりません。
• AIが書いたコードも、AIにさせたレビューも、確かめる責任は使う側の会社にあります。
• AIのレビューはコードを動かさないため、型チェック・静的解析と、本番に近いデータでのテストを、別の条件にします。
• 取り込むかどうかは、中身を理解して説明できる人が承認して決めます。GitHub のブランチ保護で、承認がないと取り込めないようにもできます。
• ログイン・権限の管理・決済、個人情報、会計・給与・税務に関わるコードは、専門家のレビューなしで本番に出さないようにします。

無料相談のご案内

PH Tech AI は、社内に技術責任者がいない中小企業・スタートアップの、技術の判断と開発体制づくりを支援しています。開発会社や社員がAIで書いたコードを、誰がどう確かめ、誰が承認するかという体制を、一緒に考えます。無料でご相談いただけます。まずはお気軽にお問い合わせください。

参考・出典

• GitHub Docs（GitHub Copilot のコード補完の責任ある利用について）: https://docs.github.com/en/copilot/responsible-use/copilot-code-completion
• Claude Code Docs「Security」: https://code.claude.com/docs/en/security
• Claude Code Docs「GitHub Actions」: https://code.claude.com/docs/en/github-actions
• GitHub Docs（GitHub Copilot code review の概要）: https://docs.github.com/en/copilot/concepts/agents/code-review
• GitHub Docs（GitHub Copilot code review の責任ある利用について）: https://docs.github.com/en/copilot/responsible-use/code-review
• GitHub Docs（GitHub Copilot code review の使い方）: https://docs.github.com/en/copilot/how-tos/use-copilot-agents/request-a-code-review/use-code-review
• Claude Code Docs「Code Review」: https://code.claude.com/docs/en/code-review
• GitHub Docs（プルリクエストのレビューについて）: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews
• GitHub Docs（ブランチ保護について）: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
• GitHub Docs（コードスキャンについて）: https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning
• TypeScript 公式ドキュメント（ハンドブック。静的解析と型チェックの説明）: https://www.typescriptlang.org/docs/handbook/typescript-from-scratch.html