検証と停止条件を組み込む — AI Agent の「できました」を確かめるやり方

ループの完了は、Agentの自己申告ではなく、外部から確認できる証拠で判断します。

これは現場の用心深さの問題ではなく、評価という営み全体が移っている先でもあります。Towards More Standardized AI Evaluation（2026年2月）は、問うべきことが「このモデルは良いか」から 「変化とスケールのもとで、意図どおりに振る舞うと信頼できるか」 へ移ったと述べ、集計されたスコアがかえって挙動を見えなくすること、評価の仕組み自体が静かな失敗を生みうることを指摘しています。

つまり「良い結果が出た」よりも、「どういう条件なら壊れるかを確かめた」の方が、完了の根拠として強いということです。

何をどう検証するか

検証の5段階

仕事のリスクとコストに応じて、検証を組み合わせます。

1. 形式確認: 必須項目、ファイル形式、文字数、出力場所を確認する
2. 整合確認: 入力資料との件数・数値・固有名詞の一致を確認する
3. ルール確認: 社内ルール、禁止事項、対象範囲に違反していないか確認する
4. 実行確認: テスト、プレビュー、サンプル実行などで実際に動かす
5. 人間確認: 外部公開、重要判断、不可逆な操作の前に担当者が承認する

すべての仕事に5段階すべてが必要なわけではありません。社内メモなら形式確認と整合確認で足りる場合があります。一方、公開物や本番変更なら、実行確認と人間確認を省略しません。

検証は実体・反例・実行後まで見る

検証を「成功したケースが1つある」だけで終えると、対象外への影響や失敗時の挙動を見落とします。少なくとも次の順で、完了条件を証拠へ結び付けます。

1. 正本との照合：数値、件数、対象、版などを事実の基準と比べる
2. 実体の確認：作成されたファイル、変更差分、保存先、実行結果を実際に見る
3. 反例の確認：入力不足、権限不足、対象外、同じ処理の再実行などで安全に止まるか試す
4. 代表環境の確認：本番に近い実行経路や実際の利用経路で、期待した結果になるか見る
5. 復旧情報の確認：対象、実行時点、版、エラー、取り消しや再開に必要な状態が残っているか確認する

「成功レスポンスが返った」は通信の結果であって、利用者に届く品質や実環境の状態そのものではありません。完了を報告するときは、何を確認し、何が未確認かを分けて記録します。

Goal構文を別Agentに精査させる

検証は成果物ができてから始まるのではありません。実行前に、Goal構文自体が検証可能かを別のAI Agentに読ませると、曖昧な目標のままループを回し始める失敗を減らせます。

役割を分ける

• Goalレビュアー: 実行前にGoal構文の目的、範囲、制約、証拠、停止条件、上限を精査する
• メーカー／実行Agent: 人間が承認したGoalに従って行動する
• 検証Agent: 各反復または最後に、成果物と証拠を完了条件へ照合する

低リスクな仕事では同じAgentが検証を担当しても構いませんが、公開・本番変更・機密情報を扱う仕事では、Goalレビューと成果物検証を別Agentまたは人間に分けます。役割を分けても、別Agentの判定が自動的に正しいとは限りません。精査基準と証拠を先に固定します。

Goalレビューのチェックリスト

Goalレビュアーには、次のような入力を渡します。

次のGoal構文を、実行前の仕様レビューとして精査してください。
1. 目的と完了条件は測定可能か
2. 対象範囲と禁止操作は明確か
3. 完了を裏付ける証拠はAgentの自己申告以外から取得できるか
4. 停止条件・人間へ相談する条件・予算上限はあるか
5. 目標ドリフトや、都合のよい自己採点が起きないか
問題がなければ PASS、1つでも重大な不足があれば BLOCK と理由を返す。
Goalを書き換えて実行を開始してはいけない。

レビュー結果がBLOCKなら、実行Agentは動かさず、Goalを人間と修正します。PASSでも、最終的なGoalの版とレビュアーの判定を記録します。実行途中で目標を変更したくなった場合は、変更後のGoalを再レビューし、承認を取り直します。

/goal の「完了」をそのまま信じない

CodexやClaude Codeの /goal は、Agentが完了条件に届いたと判断すると止まります。OpenAIのガイドも、「たぶん終わった」というモデルの見立てで完了にせず、ファイル・テスト・ログなどの具体的な証拠と照らし合わせてから完了にすべきだとしています。

ツールにループを任せても、このレッスンの考え方はそのまま使います。/goal が止まったら、それは「検証を始める合図」です。完了を判定するのは、Goalレビューで決めた証拠と、別のAgentか人による照合です。

誤診を避ける3つの視点

うまくいかないとき、原因を取り違えたまま対策すると費用だけが増えます。実運用で特に誤診しやすかった3点です。

監査するのは指示書ではなく、実際に送られた指示

ここは実運用で最も高くついた失敗です。設計図や依頼文にはきちんと書いてあるのに、Agent に実際に届いた指示からは本文が抜け落ちていた、ということが起こります。

途中で要約したり、テンプレートに差し込んだり、長さを詰めたりする処理が入ると、肝心の作業内容が落ちて、制約や注意書きだけが届くことがあります。この状態になると、次のようになります。

• モデルの性能とは無関係に失敗する
• 並列で数を増やしても改善しない
• 「依頼した」というログだけが残る

したがって、点検すべきなのは次の組です。

うまくいかないとき、多くの人は指示の書き方を練り直します。しかしその前に、書いた指示がそのまま届いているかを確認してください。届いていなければ、どれだけ推敲しても結果は変わりません。

検証は「届いたか・拾えたか・数えられたか」に分ける

もう1つ、誤診しやすい失敗があります。Agent は正しく仕事を終えているのに、進捗として数えられていない状態です。

このとき「AI が仕事をしていない」と結論づけると、対策を間違えます。次の3つを分けて確認します。

1. 届いたか：結果そのものが返ってきているか（成果物・ファイル・応答が存在するか）
2. 拾えたか：返ってきた結果を、判定するタイミングで回収できているか
3. 数えられたか：回収した結果が、進捗の集計対象として登録されているか

3つのどこで落ちているかで、打つ手がまったく違います。1 なら依頼の作り直し、2 なら判定前に短い回収時間を置く、3 なら集計対象の登録漏れを直す。この切り分けをせずに「並列を減らす」「モデルを上げる」と対処すると、原因が残ったまま費用だけが増えます。

監査は手元でできることから始める

検証のたびに別の AI を起動すると、費用がかさむうえに、確認結果自体が不確かになります。順序を決めておきます。

1. 手元のファイル・差分・ログ・実行記録で確かめられることは、そこで確かめる
2. 機械的に判定できる規則は、スクリプトや既存の点検コマンドに任せる
3. AI による点検は、判断が要る場面だけに絞る

「AI が確認したと言っている」は証拠になりません。手元で確認できる事実に置き換えられるものは、すべて置き換えます。

研究側でも、実行結果そのものを検証の土台に据える方向が整理されています。Code as Agent Harness（2026年5月）は、コードを推論・行動・環境のモデル化・実行にもとづく検証を支える基盤として位置づけたうえで、不完全なフィードバックのもとでの検証を未解決の課題として挙げています。

裏返すと、確実に判定できるところは機械に寄せ、判定しきれない部分が残ることを前提に設計するのが現在の到達点です。すべてを AI に確認させる設計は、この未解決部分をそのまま踏むことになります。

止め方を設計する

リトライには上限を置く

失敗したら何度もやり直す、という設計は危険です。同じ原因を解決できないまま繰り返すと、時間・費用・外部サービスの利用量だけが増えます。

1回目：実行する
  ↓ 失敗
原因が分かり、修正方法が安全 → 2回目を実行
  ↓ 失敗
同じ原因／新しい原因が不明／上限に達した
  ↓
停止して、証拠と未解決事項を人間へ渡す

停止条件は、少なくとも次のように具体化します。

• 同じ種類の失敗が2回続いた
• 合計3回の試行で完了しなかった
• 予定時間・トークン・費用の上限に達した
• 想定時間を超えても応答が返ってこない
• 入力データが不足している、または矛盾している
• 変更範囲が当初の目標を超えた
• 外部送信、削除、公開などの承認が必要になった

「想定時間を超えても応答が返ってこない」は見落とされがちです。処理が長引いているとき、「時間がかかっている＝難しい仕事を頑張っている」と解釈しがちですが、実運用ではむしろ依頼の切り方が悪いことの兆候でした。上限を超えたら止め、同じ内容で再送せずに、依頼の書き方へ戻る方が早く終わります。

Anthropic も Building effective agents で、エージェントは費用が高く誤りが積み重なりやすいとして、最大反復回数のような停止条件を置いて制御を保つこと、隔離した環境での十分な試験と防護策を勧めています。上限は性能を削るための制約ではなく、制御を手放さないための装置です。

停止は失敗ではありません。安全に判断を人間へ戻すための正常な状態です。

失敗時は証跡を残してから止める

停止条件に達したら、リトライを続けるのではなく、次の情報を残して人間へ渡します。

• どのGoal、対象範囲、入力の版で実行したか
• どこまで成功し、どの条件で失敗したか
• 期待値と実際の結果の差分
• 変更した実体と、変更していない保護対象
• 取り消し、再開、再試行に必要な状態

この記録があれば、次の人やAgentが同じ確認を最初から繰り返さずに済みます。復旧手順が決まっていない不可逆な操作は、実行前に人間の判断へ戻します。

メーカーとチェッカーを分ける

同じAgentに「作成して、自分で正しいか確認して」と頼むと、作成時の思い込みを検証時にも引き継ぐことがあります。可能なら、作成と検証の観点を分けます。

• メーカー: 目標に沿って成果物を作る
• チェッカー: 完了条件と証拠だけを見て、合格・差し戻し・人間確認を判断する

この分け方には名前があります。Anthropic は、一方の LLM が生成し、もう一方が評価とフィードバックをループで返す構成を、代表的な型の1つ（evaluator-optimizer）として挙げています。ただし同記事は、この型が効くのは評価基準がはっきりしていて、繰り返すことで測れるだけ良くなる場合だとしています。裏を返せば、何をもって良しとするかが曖昧なままでは、役を分けても改善しません。分ける前に、合格条件を決めてください。

チェッカーを別のAgentにしても、最終的な正しさが保証されるわけではありません。検証ルールが曖昧なら、二つのAgentが同じ誤りを見逃す可能性があります。チェック項目と証拠を先に決め、必要な場合は人間が確認します。

修正の続きと、最終確認は別に扱う

同じ論点を続けるときは、前回の続きから再開する方が速く安く済みます（第2回）。ただし公開直前の最終確認だけは例外です。

最終確認を前回の会話ごと引き継ぐと、一度合格にした判断がそのまま通ってしまいます。かといって毎回まっさらでは、前回の指摘を忘れます。そこで前回の指摘は会話ではなく指摘の一覧表で引き継ぎ、確認そのものは新しい状態で行います。人ではなく記録に覚えさせる、という分担です。

失敗パターンと対策

ここまでの検証と停止条件は、次回の演習で自分の業務に当てはめます。読んで分かることと、1周回して分かることは別です。表を眺めて納得した気になったところで止めず、必ず手を動かしてください。

まとめ

• 「できました」という報告ではなく、観測可能な証拠で完了を判断する
• 形式・整合・ルール・実行・人間確認の検証を、リスクに応じて組み合わせる
• リトライ回数、時間、費用、変更範囲に上限を設ける
• 停止して人間へ相談することを、ループの正常な終了状態として設計する
• 作成と検証の役割を分けても、検証ルールと証拠は人間が設計する
• Goal構文は実行前に別Agentで精査し、PASS／BLOCKと理由を記録する
• 点検対象は手元の依頼書ではなく、実際に送信された指示と返ってきた応答
• 未達に見えるときは、届いたか・拾えたか・数えられたかを切り分ける
• 手元で確かめられることは手元で確かめ、AI による点検は判断が要る場面に絞る
• 最終確認だけは前回の会話を持ち越さず、前回の指摘は一覧表で引き継ぐ

振り返り

• 自分の業務で「完了した」と言うために必要な証拠は何ですか？
• 何回、何分、いくらまでなら安全にリトライできますか？
• どの操作の直前に、人間の承認を置くべきですか？
• 直近でうまくいかなかった依頼について、実際に送られた指示の全文を確認しましたか？

出典・クレジット

本文中の運用上の知見（実際に送られた指示を点検対象にする、届いたか・拾えたか・数えられたかの切り分け、時間上限で止めて依頼の切り方へ戻る、最終確認を持ち越さない）は、株式会社COMPASS が自社プロダクト開発で複数 AI Agent を運用した際の実測と記録にもとづく自社作成の内容です。

そのうえで、次の一次資料を参照し、内容を独自に再構成しています。資料本文の転載は行っていません。arXiv の論文は査読前の preprint であり、確立した業界標準としてではなく、比較的新しい実務概念を整理する参考資料として扱っています。すべて 2026-08-30 に確認しました。

• Anthropic「Building effective agents」 https://www.anthropic.com/engineering/building-effective-agents — 生成役と評価役を分ける構成、最大反復回数などの停止条件、隔離環境での試験と防護策を確認。
• Towards More Standardized AI Evaluation: From Models to Agents https://arxiv.org/abs/2602.18029 — Ali El Filali, Inès Bedar, CC BY 4.0
• Code as Agent Harness https://arxiv.org/abs/2605.18747 — Xuying Ning et al., CC BY 4.0
• Stop Hand-Holding Your Coding Agent https://arxiv.org/abs/2607.00038 — Sandeco Macedo, CC BY 4.0
• OpenAI「Follow a goal」「Using Goals in Codex」、Anthropic「Claude Code Docs」（/goal・/loop）— Codex と Claude Code に組み込まれたループ機能の仕様を参照（2026-10-01確認）