AIエージェントにアプリや記事を作ってもらい、「完了しました」と返ってきた。ところがフォルダを開くとファイルがない。ファイルはあってもテストが落ちる。テストは通っても、ブラウザでボタンを押すと動かない。画面は動いても、依頼した条件の一部が抜けている。
この食い違いは、「AIの完了報告が全部でたらめ」という単純な話ではありません。完了という一語の中に、別々に確かめるべき事実が混ざっていることが原因です。
この記事では、次の四つを分離します。
- ファイルを書いた
- テストした
- 画面で動いた
- 要件を満たした
結論から言うと、AIの文章による自己申告は証拠の入口にすぎません。成果物の実在、差分、実行記録、実画面、要件との対応表を順にそろえ、初めて「完了」と判定します。
これは特定のAIサービスの勝敗を決める話ではありません。どのエージェントを使う場合でも、能力の外側に検品の仕組みを置くための方法です。依頼の書き方そのものは、先にAIへの依頼状の書き方を読むと組み合わせやすくなります。記事や文書の品質検査を自動化したい場合は、AIが書く記事に機械の門番を付ける方法も参考になります。
なぜ「完了しました」をそのまま採用できないのか
AIエージェントは、ファイルを読む、書く、コマンドを実行する、外部ツールを呼ぶ、といった複数の段階を経て作業します。OpenAIのEvals APIも、評価を「テスト基準」と「データソース」を持つ構造として扱っています。つまり、回答が生成されたことと、その回答が基準を満たすことは別です。
Anthropicのtool use文書でも、モデルがクライアント側ツールの利用を要求した後、実際のツールを実行し、その結果を対応付けて返すのは利用側の実装です。モデルが「このツールを使うべき」と判断したことは、ツールが正常に実行された証明ではありません。
GitHubのコーディングエージェントも、変更後にレビューを求める流れを前提にしています。また、生成コードに対するセキュリティ検査として、コードスキャン、秘密検査、依存関係の検査を別々に説明しています。エージェントが変更を作ったことと、安全に採用できることを分離しているわけです。
検品で特に問題になりやすい痛みは、次の四つです。
痛み1: 過設計
小さな修正を頼んだのに、新しい設定層や使わない共通部品まで増える状態です。見た目は大作でも、変更範囲が広がるほど既存機能を壊す場所、検品する場所、将来保守する場所が増えます。
過設計は「コード量が多いから不合格」ではありません。依頼した目的に必要か、既存の仕組みで足りなかったか、追加した複雑さをテストできているかで判定します。成果物一覧と差分が必要なのは、この余計な広がりを見つけるためです。
痛み2: 指示無視
「このファイルだけを変更する」「公開しない」「既存の形式に合わせる」と書いたのに、別ファイルを直す、外部へ送る、勝手な機能を足す、といった状態です。
依頼文を守ったかは、テストの成功だけでは分かりません。テスト対象外のファイルを変更していても、テストは通るからです。変更ファイルの一覧と外部副作用の確認票を独立させます。
痛み3: 完了の嘘
ここでいう「嘘」は、必ずしも故意を意味しません。AIが途中経過、予定、推測、ツールの表示を、完了した事実としてまとめてしまう状態です。「書きます」と「書きました」、「テストする必要があります」と「テストしました」が混線することがあります。
対策は人格評価ではなく、事実を機械で読み直すことです。ファイルの実在、更新日時、サイズ、差分、終了コード、標準出力、失敗出力を保存します。
痛み4: 架空API
もっともらしいURL、関数名、引数、戻り値を提示したものの、公式ドキュメントに存在しない状態です。名前が自然だと、人は見落としやすくなります。
見分け方は推測勝負にしません。公式ドキュメントの該当URLと、外部副作用のない最小再現で確かめます。検索結果の要約、個人ブログ、AI自身の説明だけでは採用しません。
「四つの完了」を分ける
同じ作業でも、証明する対象は四層あります。
| 層 | 確かめたい主張 | 主な証拠 | まだ言えないこと |
|---|---|---|---|
| ファイル | 指定場所に成果物が存在する | 絶対パス、ファイル一覧、サイズ、ハッシュ、差分 | 内容が正しい、動く |
| テスト | 指定した検査を実行し、結果が出た | コマンド、開始時刻、終了コード、生出力、失敗ログ | 実画面で使える、全要件を満たす |
| 実画面 | 利用者の操作で期待する反応が出る | 対象URL、環境、操作手順、スクリーンショット、代表ケース | 例外系や全要件が正しい |
| 要件 | 事前に決めた条件を満たす | 要件と証拠の対応表、未確認事項、承認記録 | 将来も壊れない |
「ファイルを書いた」は、ファイルの存在で確かめます。「テストした」は、テストコマンドと終了コードと生出力で確かめます。「画面で動いた」は、実際の表示環境と操作結果で確かめます。「要件を満たした」は、要件一つずつに証拠を結び付けて確かめます。
一段を飛ばして次の段を推測しないことが重要です。たとえば、ビルド成功は実画面の操作成功と同じではありません。トップページが表示されたことは、フォーム送信、エラー表示、スマートフォン幅、キーボード操作まで正しい証明ではありません。
証拠レベル表
証拠には強弱があります。報告を読むときは、どのレベルまでそろったかを明示します。
| 証拠レベル | 状態 | 例 | 完了判定 |
|---|---|---|---|
| L0 | 主張だけ | 「すべて完了しました」 | 不可 |
| L1 | 作業内容の説明 | 「3ファイルを変更し、テストしました」 | 不可 |
| L2 | 対象を特定できる記録 | 絶対パス、変更ファイル名、実行予定の検査名 | 原則不可 |
| L3 | 機械が出した結果 | ファイル一覧、差分、終了コード、生出力、ハッシュ | 対象範囲では可 |
| L4 | 代表ケースの再現 | 正常系、境界値、失敗系を同じ手順で再現 | 条件付きで可 |
| L5 | 要件と証拠の対応 | 全要件にL3またはL4の証拠が付き、未確認が分離済み | 完了候補 |
| L6 | 独立検品 | 作成者とは別の人または別工程が差分と実結果を確認 | 採用判断に強い |
小さな文言修正ならL3と目視で十分なことがあります。認証、決済、個人情報、削除、本番公開のように失敗時の影響が大きい仕事では、L5だけでなく独立検品も必要です。NISTのソフトウェア検証資料は、自動テスト、静的解析、秘密らしき文字列の検出、ブラックボックステスト、履歴上の不具合を使うテストなど、複数の技法を組み合わせることを推奨しています。一つのテストですべてを証明しようとしない考え方と一致します。
最初にAIへ渡す短い依頼文
初心者は、次の依頼文をそのままコピーし、角かっこ内だけ自分の作業に合わせて置き換えられます。
目的: [直したいこと、作りたいもの]を、安全に確認できる状態まで完成させてください。
対象: [作業フォルダまたはファイルの絶対パス]
変更範囲: [変更してよいファイル]
合格条件:
1. 指定した成果物が実在する
2. 変更ファイル一覧と差分を示す
3. 実行した検査のコマンド、終了コード、生出力を省略せず示す
4. 正常系、境界値、失敗系の代表ケースを確認する
5. 未確認事項、失敗ログ、外部通信やデータ変更の有無を示す
6. APIを使う場合は公式ドキュメントの該当URLを示し、外部副作用のない最小再現で確認する
7. 秘密情報らしき値を成果物と差分に含めていないことを確認する
やらないこと:
- 指定外のファイルを変更しない
- 公開、送信、課金、削除をしない
- 実行していない検査を実行済みと書かない
- 確認できなかった項目を完了扱いしない
最後に「成果物」「差分」「検査結果」「失敗」「代表ケース」「未確認」「外部副作用」「秘密検査」の順で報告してください。この依頼文の役割は、AIに長文を書かせることではありません。証拠の置き場所を先に作ることです。具体的な合格条件の作り方は、AIコーディングを完了単価で比べる方法の「まず完了を定義する」考え方とも共通します。
完了報告に必ず入れる八つの箱
1. 成果物一覧
相対パスだけでなく、検品する人が迷わない絶対パスを付けます。新規、変更、削除を分け、サイズも記録します。
成果物:
- 新規: D:\work\site\src\pages\contact.astro 4,218 bytes
- 変更: D:\work\site\src\styles\global.css 9,604 bytes
- 削除: なし
指定外変更: なしファイル数の多い仕事では一覧を機械生成し、その出力を保存します。AIの文章で再入力すると、転記漏れが起きるためです。
2. 差分
差分は「何を意図したか」ではなく「実際に何が変わったか」を示します。まず変更量の要約を読み、その後に生の差分を見ます。
確認する観点は次のとおりです。
- 指定外のファイルがないか
- 依存関係や設定が勝手に増えていないか
- デバッグ用の記録や固定値が残っていないか
- 認証、権限、送信先、削除条件が変わっていないか
- 既存の安全チェックが弱くなっていないか
- 同じ処理を別の場所へ重複追加していないか
差分が大きすぎて人が読めないなら、それ自体が検品上のリスクです。目的ごとに分割するか、なぜ大きい必要があったかを成果物一覧へ添えます。
3. 実行コマンドと生出力
「テスト成功」だけでは、どのテストを、どの場所で、いつ実行したか分かりません。最低限、次を一組で残します。
作業ディレクトリ: D:\work\sample
実行コマンド: [プロジェクトの公式手順に書かれたテストコマンド]
開始時刻: 2026-07-24 14:32:10 +09:00
終了コード: 0
標準出力:
[端末に表示された内容を省略せず貼る]
標準エラー:
[表示がなければ「出力なし」]コマンド名はAIに創作させません。package.json、README、CI設定、既存の開発手順に書かれたものから選びます。見つからなければ「テスト手順を特定できなかった」と未確認へ残します。推測したコマンドを実行して、別の処理が偶然成功するより安全です。
生出力には、成功件数だけでなく、スキップ、警告、再試行、対象外になったテストも含めます。終了コード0でも、実行対象が0件なら証拠にならない場合があります。
4. 失敗ログ
最後に成功しても、途中の失敗は消しません。失敗は、どこが不安定だったか、何を直したか、再発時にどこを見るかを教える証拠です。
失敗1:
- 段階: 入力検証テスト
- 終了コード: 1
- 生出力: [実際の出力]
- 原因: 空文字を空欄として扱う条件が抜けていた
- 変更: 空白除去後の長さを検査するよう修正
- 再確認: 同じテストと関連する既存テストを再実行
- 現在状態: 再実行では合格「最終的に通ったから失敗は不要」とすると、偶然通ったのか、正しく直したのかを判別できません。特に通信、時刻、並列処理に関わるテストは、再試行だけで通ることがあります。
5. 代表ケース
全組み合わせを確認できなくても、最低限三種類を固定します。
| 種類 | 目的 | 例 |
|---|---|---|
| 正常系 | 普通の入力で目的を達成できるか | 正しいメールアドレスで送信確認画面へ進む |
| 境界値 | 条件の端で壊れないか | 最小文字数、最大文字数、0件、1件 |
| 失敗系 | 誤入力や通信失敗を安全に扱うか | 必須欄なし、存在しないID、応答失敗 |
成功例だけでは不十分です。失敗時に処理が止まり、利用者へ分かる表示が出て、途中データを壊さないことも完成の一部です。
6. 未確認事項
未確認事項は欠点の告白ではなく、完了範囲を正確に区切る欄です。
未確認:
- 実機のスマートフォン表示は未確認
- 本番用の外部サービスには接続していない
- 1万件を超えるデータの性能は未計測
- 管理者以外の全権限パターンは未確認未確認が一つでもあれば必ず未完成、とは限りません。事前の合格条件に含まれる未確認なら不合格、範囲外なら条件付き完了です。大切なのは、読み手が境界を誤認しないことです。
7. 外部副作用
副作用とは、ファイル変更以外に外部へ起きる変化です。次の確認票を使います。
| 項目 | 結果 | 証拠 |
|---|---|---|
| 外部への送信 | なし／あり／未確認 | 接続先一覧、実行記録 |
| データベース更新 | なし／あり／未確認 | 使用環境、更新件数 |
| メール・通知 | なし／あり／未確認 | 宛先を伏せた送信記録 |
| 公開・デプロイ | なし／あり／未確認 | 対象環境、公開URL |
| 課金につながる呼び出し | なし／あり／未確認 | 利用サービス、回数 |
| アカウント・権限変更 | なし／あり／未確認 | 変更対象、前後状態 |
| 削除・上書き | なし／あり／未確認 | 対象、復旧方法 |
「外部副作用なし」は、単に依頼文へそう書いた証拠ではありません。使用した道具、接続先、ログ、差分から確認します。副作用が必要な仕事は、テスト環境と本番環境を分け、本番の実行前に人の承認を置きます。
8. 秘密検査
APIキー、トークン、パスワード、秘密鍵、接続文字列が、ソース、差分、ログ、スクリーンショットへ混ざっていないかを確認します。
| 確認場所 | 結果 | 注意点 |
|---|---|---|
| 新規・変更ファイル | 合格／不合格／未確認 | 長いランダム文字列、認証用ヘッダー |
| 差分 | 合格／不合格／未確認 | 一度書いて削除した秘密も履歴に残り得る |
| テスト出力 | 合格／不合格／未確認 | 環境変数や応答本文の表示 |
| 失敗ログ | 合格／不合格／未確認 | 接続先、利用者情報、認証情報 |
| 画像 | 合格／不合格／未確認 | 画面上のメール、トークン、通知 |
| 生成した設定例 | 合格／不合格／未確認 | 本物ではなく明確なダミー値か |
GitHubは秘密検査を、APIキーやトークンなどを検出する仕組みとして公式に説明しています。ただし自動検査だけで完全とは言い切れません。組織固有の形式や短い秘密は検出できないことがあるため、差分の目視と併用します。
三つのケースで証拠を組み立てる
ここからは、Web制作、データ変換、API連携で、完了証拠がどう変わるかを見ます。
ケース1: Web制作
依頼
問い合わせページを追加し、名前、メールアドレス、本文の入力確認が働くようにする。ただし実送信はせず、送信直前の確認画面までを作る。
合格条件
- 指定URLでページが表示される
- 名前、メールアドレス、本文にラベルがある
- 必須欄が空なら送信段階へ進まない
- 不正な形式のメールアドレスを拒否する
- 正しい入力なら確認画面へ進む
- キーボードだけで入力とボタン操作ができる
- 320px幅とデスクトップ幅で内容が重ならない
- 外部送信は発生しない
- 指定外ページの見た目を壊さない
必要な証拠
- 新規・変更ファイルの絶対パス
- 既存の公式手順に沿ったビルドとテストの生出力
- ブラウザで開いたURLと画面サイズ
- 正常系、空欄、メール形式不正の操作結果
- キーボードのフォーカス順
- モバイル幅とデスクトップ幅のスクリーンショット
- ネットワーク要求または送信処理が発生していない確認
- 既存の代表ページを再表示した結果
ここでビルド成功だけでは、フォームの操作や表示崩れを証明できません。逆に、目視で一度送れたことだけでは、ビルドの再現性、空欄、既存ページへの影響を証明できません。
OWASP ASVSは、Webアプリケーションの技術的なセキュリティ制御を検証するための基準を提供しています。WSTGはWebアプリケーションとWebサービスのテスト手法を扱います。一般的な画面確認に加え、入力、認証、権限、セッションなど、機能に該当する安全項目を選んで確認します。すべての案件で全項目を機械的に実施するのではなく、機能と影響に合わせて範囲を決めます。
ケース2: データ変換
依頼
顧客一覧のCSVを、新しい列構成のCSVへ変換する。元データは変更せず、変換後ファイルを別名で作る。個人情報は外部へ送らない。
合格条件
- 入力ファイルを上書きしない
- 出力先は指定フォルダ内だけ
- ヘッダー名と列順が仕様どおり
- 入力行数と、正常行・除外行・エラー行の合計が一致
- カンマ、改行、引用符を含む値を壊さない
- 空欄と0を混同しない
- 日付変換の規則が固定されている
- 不正行を黙って捨てず、件数と理由を残す
- 文字コードが指定どおり
- 外部通信がない
必要な証拠
入力:
- 絶対パス
- バイト数
- ハッシュ
- 総行数
出力:
- 絶対パス
- バイト数
- ハッシュ
- ヘッダー
- データ行数
集計:
- 正常行
- 除外行
- エラー行
- 合計一致
代表ケース:
- 通常の1行
- 空欄と0を含む1行
- カンマ、改行、引用符を含む1行
- 不正な日付を含む1行データ変換では、ファイルが生成されたことより「件数保存」と「値の意味が変わっていないこと」が重要です。先頭数行だけを見て完了にすると、末尾の欠落、引用符の崩れ、文字化けを見逃します。
安全な検品では、元データそのものを記事やAIの外部サービスへ貼りません。代表ケースは、実データから個人情報を除いた合成データで作れます。ハッシュはファイルが同一かを比較する印であり、内容が正しいことを単独で保証するものではありません。
ケース3: API連携
依頼
既存システムから公式APIを読み取り専用で呼び、取得した項目を画面へ表示する。書き込み、削除、課金対象の処理は行わない。
合格条件
- API名、エンドポイント、認証方式が公式文書に存在する
- 使うバージョンまたは更新日を記録する
- 必須引数と戻り値の根拠URLを示す
- 読み取り専用の最小権限を使う
- 認証情報をソースやログへ出さない
- 正常応答を必要な項目へ変換できる
- 認証失敗、対象なし、回数制限、サーバー側失敗を区別する
- 時間切れで無限再試行しない
- 失敗時に既存データを壊さない
- 外部呼び出し回数と送信データの範囲を記録する
架空APIを見分ける手順
架空APIの検品は、次の順だけに絞ります。
- 提供元の公式ドキュメントURLを開く
- API名、エンドポイント、HTTPメソッド、認証、必須引数、戻り値を同じ公式文書で確認する
- SDKを使うなら、公式SDKの文書でクラス名とメソッド名を確認する
- 公式文書の更新日またはバージョンを記録する
- 実データを書き換えない最小再現を作る
- 認証情報を含めず、静的なサンプル応答で変換部分を先にテストする
- 実接続が必要なら、読み取り専用の試験環境と最小権限で一回だけ確認する
- 公式文書と実応答が食い違えば、推測で埋めず未確認に戻す
「それらしいURLへ接続してみる」は検品ではありません。外部サービスへの無差別な要求、実データの書き込み、削除APIの試行、認証回避は行いません。最初は公式文書と保存済みのサンプル応答で確かめます。
Anthropicのtool use文書では、ツール定義に名前、説明、入力スキーマを含め、応答のtool_useブロックから名前、ID、入力を取り出し、実際のツールを実行して結果を対応付けます。この構造を使う場合も、モデルが作った入力がスキーマに合うこと、呼び出し先の実装が存在すること、結果が同じ呼び出しIDへ対応することを別々に確認します。
完了判定チェックリスト
次の確認票は、そのまま作業カードへ貼れます。項目数を減らす場合も、削った理由を残してください。
対象と成果物
- 1. 作業対象の絶対パスが記録されている
- 2. 新規ファイルの絶対パスが一覧になっている
- 3. 変更ファイルの絶対パスが一覧になっている
- 4. 削除ファイルの有無が明記されている
- 5. 指定外ファイルの変更有無を確認した
- 6. 各成果物が実際に存在する
- 7. 空ファイルや極端に小さい仮置きがない
- 8. 指定された文字コードと形式で読める
差分と設計
- 9. 生の差分を確認した
- 10. 変更量の要約を確認した
- 11. 依頼にない依存関係や設定追加がない
- 12. 過設計になった箇所がない、または必要性が説明されている
- 13. 既存の安全チェックを削除または弱体化していない
- 14. デバッグ用の固定値や一時記録が残っていない
テストと生出力
- 15. テストコマンドの根拠がREADME、設定、既存CIのいずれかにある
- 16. 実行した作業ディレクトリが記録されている
- 17. 実行コマンドが記録されている
- 18. 終了コードが記録されている
- 19. 標準出力が省略されず保存されている
- 20. 標準エラーが省略されず保存されている
- 21. テスト件数とスキップ件数を確認した
- 22. 途中の失敗ログと修正内容を残した
- 23. 修正後に同じ失敗ケースを再実行した
- 24. 関連する既存テストも再実行した
代表ケースと実画面
- 25. 正常系の代表ケースが合格した
- 26. 境界値の代表ケースが合格した
- 27. 失敗系の代表ケースが安全に失敗した
- 28. Webの場合は実際のブラウザで対象URLを開いた
- 29. Webの場合は主要操作を最後まで行った
- 30. Webの場合はスマートフォン幅とデスクトップ幅を確認した
- 31. Webの場合はキーボード操作とラベルを確認した
要件、外部副作用、安全
- 32. 要件一つずつに証拠が結び付いている
- 33. 未確認事項が独立した欄にある
- 34. 外部送信の有無を確認した
- 35. データベース更新の有無を確認した
- 36. 公開、通知、メール送信の有無を確認した
- 37. 課金につながる処理の有無を確認した
- 38. 削除、上書き、権限変更の有無を確認した
- 39. ソース、差分、ログ、画像の秘密検査を行った
- 40. APIは公式文書URLと最小再現で存在を確認した
- 41. 本番で未確認の項目を本番確認済みと書いていない
- 42. 合格、不合格、条件付き合格のいずれかを根拠付きで判定した
チェックを付けた数だけで合格にはしません。重要項目一つの不合格を、別の軽い項目の合格で相殺できないためです。たとえば秘密情報の混入や指定外の公開があれば、表示確認が多数合格していても採用を止めます。
要件と証拠の対応表
最後に、要件を表へ戻します。これが「要件を満たした」を証明する中心です。
| 要件ID | 要件 | 証拠 | レベル | 結果 | 未確認・制限 |
|---|---|---|---|---|---|
| R-01 | 指定ページが表示される | 対象URL、ビルド出力、画面記録 | L4 | 合格 | 試験環境のみ |
| R-02 | 空欄なら進まない | 失敗系操作記録、テスト出力 | L4 | 合格 | なし |
| R-03 | 外部送信しない | 実装差分、接続記録 | L3 | 合格 | ブラウザ拡張の通信は対象外 |
| R-04 | 320px幅で崩れない | 画面記録 | L4 | 合格 | 実機は未確認 |
| R-05 | 指定外変更なし | 変更ファイル一覧、生差分 | L3 | 合格 | なし |
証拠欄には「確認済み」とだけ書かず、別の人が同じものを見つけられる場所を書きます。結果は「合格」「不合格」「未確認」に限定すると、曖昧な言い回しを減らせます。
機械検査と人の検品を分担する
機械に向くのは、同じ入力なら同じ判定になる項目です。
- ファイルの実在
- 必須項目
- 文字数やバイト数
- 形式
- テストの終了コード
- リンク先の実在
- 禁止されたファイル変更
- 既知の秘密形式
- 代表入力に対する出力
人に向くのは、目的、使いやすさ、読みやすさ、変更範囲の妥当性など、文脈を含む判断です。
- 読者や利用者の目的に合うか
- 過設計でないか
- 画面の優先順位が自然か
- エラー文が利用者に理解できるか
- 未確認の残り方を受け入れられるか
- 安全上の残リスクを許容できるか
GitHubのテスト文書も、AIが生成したテストがすべての場面を覆うとは限らないため、生成コードを確認し、必要なテストを追加するよう案内しています。AIにテストを書かせた場合、テスト対象とテストの両方が同じ誤解を共有することがあります。仕様から独立した代表ケースを人が少なくとも一つ加えると、この共倒れを見つけやすくなります。
よくある誤判定
「終了コード0だから全部合格」
終了コード0は、そのコマンドが定義する成功条件を満たした証拠です。画面、全要件、秘密、指定外変更まで自動的に証明しません。実行対象が0件、重要な検査がスキップ、警告だけで継続、といった場合もあります。
「スクリーンショットがあるから動く」
一枚の画像は、その瞬間の表示を示します。ボタンを押せるか、入力を送れるか、失敗時に戻れるか、別の画面幅で崩れないかは別の証拠が必要です。
「差分がきれいだから要件を満たす」
差分の読みやすさは重要ですが、書かれたロジックが実際の入力で期待どおり働くかはテストします。レビューと実行は代替関係ではありません。
「公式SDKの名前に似ているから存在する」
似た名前は根拠になりません。公式ドキュメントの該当ページを開き、現在のバージョンに同じ名前、引数、戻り値があるか確認します。
「AIが自分で再確認したから独立検品」
同じ文脈、同じ前提、同じ成果を作ったAIによる再確認は有用ですが、独立検品とは分けます。作成時の思い込みを引き継ぐ可能性があるためです。機械検査や別担当のレビューを追加します。
FAQ
Q1. 小さな修正でも全部の証拠が必要ですか
影響に合わせて縮小できます。文言一か所なら、対象ファイル、差分、表示確認、指定外変更なしで足りることがあります。ただし公開、課金、削除、認証、個人情報に触れる場合は、小さな差分でも外部副作用と秘密検査を省きません。
Q2. テストがない古いプロジェクトではどうしますか
テスト済みと書かず、現状を未確認として分離します。そのうえで、今回の変更に対する小さな再現手順、既存機能の代表確認、差分レビューを行います。新しいテスト基盤の導入が大きすぎる場合は、勝手に過設計せず別の改善候補にします。
Q3. AIが生出力を省略したらどうしますか
完了判定を止め、同じコマンドの終了コード、標準出力、標準エラーをそのまま求めます。長すぎる場合は、完全ログの保存先と、冒頭、末尾、失敗箇所、件数の要約を分けます。要約だけを完全ログの代わりにしません。
Q4. 成功したテストのスクリーンショットだけでよいですか
不十分です。画像は読みにくく検索もしにくいため、コマンドと文字の生出力を正本にし、画面は補助証拠にします。ブラウザ操作の結果はスクリーンショットや動画が役立ちますが、対象URL、環境、操作手順も添えます。
Q5. 架空APIを実際に呼ばず見分けられますか
まず公式ドキュメントで名前、パス、メソッド、引数、戻り値を確認できます。変換処理は静的なサンプル応答で試せます。実接続が必要な項目だけを未確認として残し、読み取り専用の試験環境が用意できた時に最小再現を行います。
Q6. テストが通れば人のレビューは不要ですか
不要にはなりません。テストは書かれた条件を検査します。要件の書き忘れ、指定外変更、過設計、分かりにくい画面、誤った前提は別に確認します。機械で白黒が付く部分を自動化し、人は残った判断へ集中します。
Q7. 失敗ログを残すと報告が長くなりませんか
長くなりますが、同じ失敗の再発防止に使えます。本文には原因、変更、再確認の要点を置き、完全な生出力はログファイルへ分ける方法があります。秘密や個人情報は伏せ、伏せた場所を明記します。
Q8. 未確認事項があれば「失敗」ですか
事前の合格条件に含まれるかで決めます。必須要件が未確認なら完了ではありません。範囲外の実機確認や本番接続を意図的に行わなかった場合は、「試験環境では合格、本番は未確認」のように条件付きで示します。
Q9. 証拠をAI自身にまとめさせてもよいですか
まとめさせて構いません。ただし、元になるファイル一覧、差分、生出力、画面記録を残します。AIの要約と元証拠が食い違う場合は、元証拠を優先します。
Q10. どの時点で作業を止めるべきですか
指定外変更、秘密の混入、意図しない外部送信、課金、削除、本番影響が見つかったら、追加操作を止めて影響範囲を確認します。テスト失敗だけなら、安全な範囲で原因を直して再試験できます。停止条件も依頼文へ先に書くと判断が安定します。
公式資料から読み取れる検証の共通点
2026年7月24日に確認した公式資料には、提供元が違っても共通する考え方があります。
第一に、評価条件を明示します。OpenAIのEvalsは、評価をテスト基準とデータの組として扱います。Anthropicの評価ツールは、複数のテストケース、出力比較、評価を扱います。普段のAIコーディングでも、「良さそう」ではなく、入力と期待結果を先に固定する考え方へ置き換えられます。
第二に、ツール利用とツール結果を分けます。モデルがツール利用を選んだこと、ツールが実行されたこと、結果が正しかったことは別段階です。API連携やコマンド実行では、呼び出し要求だけで完了にしません。
第三に、複数の検証技法を組み合わせます。NISTの検証資料は、自動テスト、静的解析、秘密らしき文字列の検出、ブラックボックステスト、構造に基づくテスト、過去の不具合を使うテストなどを挙げています。OWASP ASVSとWSTGも、Webアプリケーションの安全要件とテストの観点を体系化しています。
第四に、人のレビューを残します。GitHubのコーディングエージェントは変更後のレビューを前提にし、テスト生成の文書も生成されたテストを人が確認して不足を補うよう案内しています。AIが作り、AIが「できた」と言っただけで採用を閉じない設計です。
公式出典
以下は2026年7月24日に確認した公式ページです。製品仕様や文書の内容は更新されるため、利用時点で再確認してください。
- OpenAI「Evals API Reference」
https://platform.openai.com/docs/api-reference/evals - OpenAI「Data controls in the OpenAI platform」
https://platform.openai.com/docs/models/default-usage-policies-by-endpoint - Anthropic「Tool use overview」
https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview - Anthropic「How to implement tool use」
https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/implement-tool-use - Anthropic「Using the Evaluation Tool」
https://docs.anthropic.com/en/docs/test-and-evaluate/eval-tool - GitHub Docs「About third-party coding agents」
https://docs.github.com/en/copilot/concepts/agents/about-third-party-coding-agents - GitHub Docs「Testing code」
https://docs.github.com/en/copilot/tutorials/copilot-cookbook/testing-code - GitHub Docs「Writing tests with GitHub Copilot」
https://docs.github.com/en/copilot/tutorials/write-tests - GitHub Docs「Requesting a code review with GitHub Copilot CLI」
https://docs.github.com/en/copilot/how-tos/copilot-cli/use-copilot-cli/agentic-code-review - NIST「Guidelines on Minimum Standards for Developer Verification of Software」
https://www.nist.gov/publications/guidelines-minimum-standards-developer-verification-software - NIST「Recommended Minimum Standards for Vendor or Developer Verification」
https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-supply-chain-security-guidance-0 - NIST「Secure Software Development Framework References」
https://csrc.nist.gov/Projects/ssdf/references - OWASP「Application Security Verification Standard」
https://owasp.org/www-project-application-security-verification-standard/ - OWASP「Web Security Testing Guide」
https://owasp.org/www-project-web-security-testing-guide/ - OWASP「Software Component Verification Standard」
https://scvs.owasp.org/
まとめ
AIエージェントの完了報告を信頼できる形へ変える方法は、AIへもっと強く「絶対に確認して」と頼むことではありません。完了を四層に分け、層ごとに別の証拠を要求することです。
- ファイルを書いた証拠は、実在、一覧、サイズ、差分
- テストした証拠は、コマンド、終了コード、生出力、失敗ログ
- 画面で動いた証拠は、環境、URL、操作手順、代表ケース
- 要件を満たした証拠は、要件と証拠の対応表
- 安全の証拠は、外部副作用と秘密検査の確認票
- APIの証拠は、公式ドキュメントURLと外部副作用のない最小再現
過設計、指示無視、完了の食い違い、架空APIは、モデルへの精神論では防げません。成果物、差分、実行結果、実画面、要件の五つを別々に読み、未確認を未確認のまま残す運用で防ぎます。
最初から完璧な検品基盤を作る必要はありません。次の依頼から、短い依頼文へ「変更ファイル一覧」「実行コマンドと生出力」「未確認事項」の三つを足してください。それだけでも、AIの「できました」は、採用できるかを判断できる報告へ変わり始めます。
本記事は2026年7月24日に確認したOpenAI、Anthropic、GitHub、NIST、OWASPの公式資料と、AIコーディング運用で発生しやすい検品上の問題を基にまとめたものです。特定の製品やモデルの優劣を断定するものではありません。外部サービスの仕様と安全要件は、利用時点の公式文書で再確認してください。