要約： AIが書いたコードのレビューでは、自動チェックやAIレビューが見落としやすい点を、人が確認します。業務ルール、権限、データの扱い、実在しないパッケージやAPI、何も検証していないテストなどです。VAONは自動チェック、AIによる確認、人のレビューを7つの工程に組み込み、レビューとテストの記録をお客様が閲覧できる形で残しています。
目次
- AIが書いたコードに、なぜ人のレビューが必要ですか。
- 人が確認する観点は何ですか。
- 意味のないテストや、実在しないパッケージはどう見抜きますか。
- 自動チェック、AI、人はどう役割を分けますか。
- VAONの7工程では、どんな記録が残りますか。
- この方法だけでは足りないのは、どんな場合ですか。
- よくあるご質問
1. AIが書いたコードに、なぜ人のレビューが必要ですか。
AIが書いたコードに人のレビューが必要なのは、AIが「このコードは動くか」には強くても、「この会社の業務として正しいか」までは判断できないためです。見た目が整っていて、コメントもテストも付いているコードでも、その業務の担当者しか知らないルールに反していることがあります。
VAONでも、お客様から最もよくいただくご質問の一つが「AIが書いたコードは誰が確認するのか」でした。2026年は、この質問が特に多い年です。「AIを信頼しています」も「AIは使っていません」も、お答えとしては十分ではないと考えています。必要なのは、人が何を確認するのかという一覧と、確認したことを示す記録です。
AIが生成するコード全般のリスクは、別の記事「シャドーAIとAI生成コードのリスク」で整理しています。本記事では、レビュー担当者が見る観点と、どんな記録を残すかに絞ってご説明します。
2. 人が確認する観点は何ですか。
AIが書いたコードのレビューで人が確認する観点は、次の8つです。いずれも、検査ツールやAIレビューだけでは文脈が足りず、結論を出しにくい箇所です。
| 観点 | よくある問題 | レビュー担当者の問い |
|---|---|---|
| 業務ルール | 実際の規定ではなく、AIが推測した動きになっている（端数処理、締め日、特定顧客の例外など） | このルールは要件定義書のどの項目に基づくか。誰が確認したか |
| 権限 | 画面ではボタンを隠しているが、APIは権限のない人にもデータを返す | この利用者がAPIを直接呼ぶとどうなるか |
| データの扱い | 個人情報がログに出力される。利用者や拠点での絞り込みが漏れている。不要な項目まで返している | どのデータが外部やログに出ていくか |
| 実在しないパッケージ・API | AIが作り出した、または古い版にしかないパッケージ、関数、引数 | パッケージは公式のレジストリに存在するか。使用中の版にその関数はあるか |
| 意味のないテスト | 検証がない。自明なことだけを検証している。モックが常にテストの期待どおりの値を返す | コードをわざと壊したら、テストは失敗するか |
| エラー処理と境界値 | エラーを握りつぶして黙ってデフォルト値を返す。空、重複、同時アクセスを考慮していない | 入力が空、重複、極端に大きい場合はどうなるか |
| 依頼範囲外の変更 | 無関係なファイルを書き換える。一括で名前を変える。使われているコードを「不要」として削除する | 変更された行はすべて、この変更の目的に含まれるか |
| キーと設定 | 実際のキーや本番環境のアドレスが、サンプルコードやテストに残っている | 特定の人の端末でしか成立しない値はないか |
この中でも、業務ルールと権限は、機械に任せきれない観点です。「一定額を超える注文は管理者の承認が必要」という処理が、お客様の規定なのか、偶然そうなっているだけなのかは、検査ツールには区別できません。要件を読んだ人だけが答えられます。
3. 意味のないテストや、実在しないパッケージはどう見抜きますか。
意味のないテストは、コードをわざと壊して確かめます。実在しないパッケージは、AIの提案を信じず、公式のレジストリで名前を調べて見抜きます。
テストの場合。 AIは、直前に生成したコードに合わせてテストを書きがちです。そのため、コードが誤っていれば、テストも誤った動作を正しいものとして受け入れてしまいます。最も手軽な確認方法は、比較演算子を一つ変える、条件を一つ外すなどしてから、もう一度実行することです。それでもテストが成功するなら、そのテストは何も守っていません。より確実なのは、コードではなく要件から、テストシナリオを先に作ることです。
パッケージとAPIの場合。 プルリクエストでパッケージが追加されたら、レビュー担当者は公式のレジストリを開き、名前が実在するか、誰が保守しているか、最後の更新はいつかを確認します。もっともらしい名前でも、AIが作り出したものである場合があります。その名前を攻撃者が先に登録している可能性もあります。見慣れない関数や引数は、使用中の版のドキュメントで確かめるか、実際に動かします。作り話のコードは自然に見えるため、目で読むだけでは足りません。
4. 自動チェック、AI、人はどう役割を分けますか。
VAONのプロジェクトでは、自動チェックが典型的なパターンの問題を止め、AIが変更箇所をもう一度確認し、文脈が必要な判断は人が行います。各層は互いを補うもので、どれも他を置き換えるものではありません。
| 層 | 行うこと | 限界 |
|---|---|---|
| すべてのプルリクエストで動く自動チェック | シークレットのスキャン、依存パッケージのスキャン、静的解析（SAST）。メインブランチは保護され、レビュー前は統合できない | 既知のパターンしか見つけられず、業務ルールは分からない |
| AIによる変更箇所のセキュリティ確認 | 差分を読み、疑わしい箇所を指摘する | 誤検知があり、見落としもあり得る |
| 人のレビュー | 上の2つの結果を読み、さらに2章の8つの観点を確認する | 読む人の時間と知識に左右される |
補足が2点あります。1点目は、AIによる確認は人の補助であり、人の代わりではないことです。誤検知は日常的に起きるため、必ず人が結果を読んで判断します。2点目は、お客様がソースコードをAIツールに入力することをまだ許可されていない場合、AIによる確認は実行しないことです。その場合は、自動チェックと人のレビューで進めます。なお、VAONのセキュア開発プロセスは、NIST SSDF（SP 800-218）を参考にしています。
5. VAONの7工程では、どんな記録が残りますか。
VAONの7工程では、すべての工程で記録が残ります。すべてのプロジェクトでレビューとテストの記録を保管しており、お客様はそれを閲覧できます。変更ごとに、次の順で進めます。
- 計画。 記録：変更の内容と範囲。
- 別の担当者による指摘。 記録：コードを書く前の、計画への指摘。
- 承認。 記録：進めるか、計画を直すかの判断。
- 構築。 AIが支援し、人が確認します。記録：変更理由を添えたプルリクエスト。
- 相互確認とチーム責任者の承認。 記録：レビューコメント、承認者名、自動チェックの結果。
- 別環境でのテスト。 記録：テストシナリオと実行結果。
- リリース。 記録：リリースノートとタグ。
VAONのエンジニアは、Claude CodeとGitHub Copilotを毎日使っています。AIがコードの読み直し、テストの生成、ドキュメントの同期を担い、リリース前には人が確認します。お客様に驚かれることが多いのは、工程2です。指摘は構築のあとではなく前に入ります。誤った計画を直すほうが、書き終えたプルリクエストを直すより、はるかに小さな手間で済むためです。
お客様にとって、この記録は「AIが書いたコードは誰が確認するのか」への直接の答えになります。誰がどの変更を読んだか、どのテストが実行されたか、どのリリースにどのタグが付いたかを確かめられます。記録の形式はプロジェクトによって異なる場合があります。保管方法に要件がある場合は、キックオフの段階でお知らせください。AIを検証に使うときの確認の流れは「AI時代のQA：4段階の検証ループ」で紹介しています。
6. この方法だけでは足りないのは、どんな場合ですか。
人のレビューは、どれほど丁寧に行っても、すべての欠陥を見つけられるわけではありません。あらかじめ知っておきたい場面が3つあります。
- レビュー担当者に負荷が集中する場合。 AIによってコードの量は増えますが、人が読める時間は増えません。プルリクエストが大きいほど、読む側は流し読みになります。変更を小さく保ち、短い単位で動く状態にして、1回のレビューで読み切れるようにします。
- レビュー担当者が業務を知らない場合。 要件が文書で確定していなければ、照らし合わせる基準がなく、2章の最初の2つの観点が働きません。
- 数日で破棄する試作の場合。 完全なプロセスは重すぎます。試作であることを明示し、本番環境には載せないことを確認すれば十分です。
7. よくあるご質問
AIが書いたコードを、AIでレビューすれば十分ですか。 十分ではありません。AIレビューは疑わしい箇所を挙げるのに役立ちますが、誤検知があり、見落としもあります。特に業務ルールと権限に関わる問題は苦手です。VAONでは、AIを追加の層として使い、結果は人が読んで判断します。
レビューとテストの記録を、お客様は見られますか。 はい。VAONのすべてのプロジェクトでレビューとテストの記録を保管しており、お客様は閲覧できます。必要なときに探し回ることがないよう、保管場所と閲覧方法はキックオフの段階で決めておくことをお勧めします。
ソースコードをAIツールに入力する許可がない場合はどうなりますか。 プロジェクトは進められます。AIによる確認の層だけがなくなります。プルリクエストごとのシークレットスキャン、依存パッケージのスキャン、静的解析、人のレビューは変わりません。
AIが書いた大きなプルリクエストは、どこから読めばよいですか。 変更の説明と関連する要件から読み始め、画面よりも先に、権限とデータに関わる変更を読みます。全体を読み切れない大きさであれば、流し読みで承認せず、分割を依頼してください。
自動テストが充実していれば、人のレビューは省けますか。 省けません。テストが確認するのは、テストを書いた人が思いついた範囲だけです。AIが生成したテストが、誤ったコードに合わせて書かれることもあります。テストとレビューは、別のものを確認しています。
AIを使う開発チームのレビュー体制を、発注の前に確認しておきたいとお考えではありませんか。 VAONの無料相談（60分）では、CEOが同席し、レビューとテストの記録のサンプルをお見せしながらプロセスをご説明します。資料のご準備は不要で、お申し込みによる義務も生じません。無料相談（60分）
あわせてお読みください：AI駆動開発を外注する前に確認する12項目、AIコーディングのセキュリティ対策 国の注意喚起が開発会社に求めていること
参考資料
- NIST「Secure Software Development Framework (SSDF) Version 1.1」SP 800-218（2022年2月）：https://csrc.nist.gov/pubs/sp/800/218/final（2026年10月17日確認）
