INSIGHT
AIが「問題なし」と言った。それだけで、確かめたことにするな
AIのレビュー結果が「問題なし」でも、対象や条件が分からなければ検証完了の証拠にはなりません。確認済みと未確認を記録し、検証を見直す条件を示します。
AIで作った申請フォームを、同じAIに点検してもらった。「重大な問題は見つかりませんでした」。気になって別のAIにも聞いたけれど、返事は似ている。自分でも一件登録できたので、同僚へURLを送ろうとしている。
その前に、AIは何を読み、何を実際に試したのでしょうか。コードを読んだだけなのか。試験用の環境で動かしたのか。あなたが使おうとしている権限や接続先まで見たのか。そこが分からなければ、「問題なし」を確認完了へ置き換えることはできません。
「問題なし」という返事だけでは、何を見たか分からない
AIは、コードの誤りを探す、改善案を出す、試験の候補を増やすといった仕事で役立ちます。ただし、見せていない設定や、実行していない試験まで、返答の言葉から確認済みにはできません。
コードだけを渡したなら、実際の利用者の権限や接続先、現場の例外ルールは見えていないかもしれません。「安全か確認して」とだけ聞いたなら、あなたの仕事で許容できない失敗を、そもそも指定していない可能性があります。
検証範囲とは、何を対象に、どの環境で、どの条件を試し、何を合格としたかです。まずAIへ、見た資料、実行した試験、その結果、実行していない確認を分けて示すよう頼みます。ただし、その説明もAIの返答です。実行記録や実際の設定と合うかを確認し、記録がなければ未確認として残します。
「試したとAIが説明したこと」と、「試した記録を確認できたこと」も、分けてください。
読む確認、動かす試験、仕事に合うかの判断を分ける
申請を一件登録できても、別部署の申請を読めないことまで確かめたわけではありません。同じ申請を二度送ったとき、通信が切れたとき、取消が入ったときも、それぞれ別の条件です。
確認を次のように分けると、AIの返答だけでは足りない部分が見えてきます。
| 確認の種類 | 申請フォームでの例 | それだけでは分からないこと |
|---|---|---|
| コードや設定を読む | 権限を判定する処理があるかを見る | 実際の利用者と設定で、その処理が働くか |
| 条件を変えて動かす | 部署の違う試験アカウントで閲覧を試す | その閲覧範囲を業務として認めてよいか |
| 仕事の条件に照らす | 誰の申請を誰が見てよいかを確認する | 実装が、その決定どおりに動くか |
どれか一つを済ませても、残りは自動的には終わりません。逆に、同じ対象を何度も読ませるより、抜けた種類の確認を足すほうが役立つ場合があります。
受け入れ条件は、業務で使ってよいと判断するための具体的な条件です。あなたが業務上の閲覧範囲を決める立場でなければ、AIに補わせず、その情報を管理する人へ聞きます。その答えを、許可を得た試験用アカウントとデータで確かめられる形へ変えます。作成者が一人で業務の決定権まで引き受ける必要はありません。
研究が分けた二つの合格を、混ぜない
SusVibesの研究は、100件のPythonリポジトリで過去に脆弱性が修正された実装を基に186の機能追加課題を構成し、機能上の合格と、安全性を含む合格を分けて評価しました。ここでは2026年8月21日付のarXiv第3版を参照します。研究の対象と方法は本文 で確認できます。
この研究から言えるのは、選ばれた課題に対し、機能の成功と安全性を別の基準で評価したことです。対象はPythonに限定されており、通常の全開発や全AIモデルの事故率を示すものではありません。AI同士のレビューと人のレビューを直接比べた研究でもありません。
したがって、「AIレビューは信用できない」「人が見れば必ず分かる」という結論には使えません。ここで役立つのは、合格という言葉の中身を分ける視点です。
機能テストに通った結果を、権限や安全性、業務継続まで合格した結果へ言い換えてはいけません。
次の人が確かめ直せる記録を、回答画面の代わりに残す
別のAIに同じコードを渡し、回答が一致しても、見せていない設定が確認済みになるわけではありません。人のレビューも、「専門家が見た」という肩書や人数だけでは範囲を説明できません。複数AIの合意そのものは別の記事で扱いますが、ここでは、誰が確認しても次へ渡せる記録に注目します。
- 対象：どの版のコード、設定、権限、接続先を見たか。
- 環境と条件：どこで、どの利用者・入力・操作を試したか。
- 結果：期待した結果と実際の結果、確認できる記録は何か。
- 未確認：まだ試していない条件と、その間は使わない範囲はどこか。
- 次の確認：何を自分で試し、何を誰に判断・支援してもらうか。
NISTのSecure Software Development Framework 1.1 は、安全な開発を、開発工程から公開後の脆弱性対応まで含む仕事として整理しています。AI回答の正しさを保証する資料ではありません。上の記録項目も、本稿で確認の引き継ぎに使うための提案です。
たとえば、「試験環境で登録と一覧表示は成功。別部署からの閲覧は未確認。実データはまだ入れない」と残せば、次に必要なのは安心できる言い回しではなく、閲覧の境界を確かめる試験だと分かります。
AIによって確認の準備や調査が速くなることはあります。その効果を報告するときも、短くできた作業と、まだ試していない作業を分けます。未確認の項目を消してしまえば、時間の節約ではなく、確認の省略になります。
返答を保存する前に、一件の確認結果を残す
AIの「問題なし」は、次に何を確かめるかを考える材料です。返答だけを保存して終えるのではなく、まず一件、対象・条件・期待した結果・実際の結果を記録してください。
確認できない条件は、無理に「問題なし」へ寄せず、未確認として次の試験や担当へ渡します。
試験用データで作り続けることはできても、まだ確かめていない権限で人に使わせたり、本番の送信・更新につないだりはしない。自分が何を確かめたのかを言える状態にしてから、使う範囲を広げてください。