エージェントに「あとはよろしく」と長時間の作業を任せたとき、一番厄介な問題は「終わったかどうかを誰が判断するか」です。エージェント自身に「完了しました」と言わせるだけでは、テストが落ちたままでも自己申告で終了してしまうことがあります。固定ターン数で打ち切る方式も、タスクの難易度によって足りたり余ったりして扱いづらい。
この問題に対して、Anthropicが2026年5月にClaude Codeへ実装した /goal コマンドは、一つの明確な設計解を示しています。本記事はAIエージェントガバナンスの評価設計に連動する内容として、この仕組みを技術的に分解し、自社のエージェント基盤に応用する方法を整理します。
AIエージェントの完了判定はなぜ難しいのか
自己申告による完了判定は「作業した本人が採点する」構造的な利益相反を抱えており、タスクが複雑になるほど誤判定が増えます。
エージェントが自分の出力を自分で「完了」と判定する方式には、構造的な弱点があります。作業を行ったコンテキストと判定を行うコンテキストが同一であるため、途中の推論過程に引きずられて「やることはやった」という結論に寄りやすいのです。これは人間のセルフレビューでバグを見落としやすいのと同じ力学です。
一方で、ターン数や時間による打ち切りは判定の質を保証しません。単純なリファクタリングに20ターンは過剰かもしれませんし、大規模なモジュール移行には20ターンでは全く足りないこともあります。「タスクが終わったこと」を機械的に確認する仕組みが必要になります。
検証可能な終了条件とは何か
検証可能な終了条件とは、テストの終了コードやファイル状態など、会話ログに現れる形で証明可能な単一の終了状態を指します。
/goal の核となる考え方は「verifiable end state（検証可能な終了状態）」です。条件は最大4,000文字まで記述でき、次の3要素を含むことが推奨されています。
- 測定可能な単一の終了状態 — テスト結果、ビルドの終了コード、ファイル数、空になったキューなど
- 証明方法の明示 — 「
npm testが exit 0 で終わる」「git statusがクリーンである」といった、Claudeが自分の出力で示せる形の指示 - 崩してはいけない制約 — 「他のテストファイルを変更しない」など、達成の過程で守るべき条件
例えば「test/auth 配下の全テストが通り、lintがクリーンな状態、または20ターンで停止する」という条件を設定すると、Claude Codeはこの条件を最初のディレクティブとしてターンを開始し、以降は自律的に作業を継続します。
``text``
/goal test/authの全テストが通り、lintがクリーンな状態。または20ターンで停止する
評価者を作業から分離するとなぜ有効か
評価専用の軽量モデルを作業モデルと分離することで、判定が作業の推論過程に引きずられる問題を構造的に防げます。
/goal の実装は、セッション単位のプロンプトベースStopフックとして動作します。1ターンが終わるたびに、条件とそれまでの会話をデフォルトでHaiku相当の小型・高速モデルに渡し、次の3種類の判定を返させます。
| 判定 | 意味 | 挙動 |
|---|---|---|
| Not yet met（未達成） | 条件を満たしていない | 判定理由をガイダンスとして次のターンを開始 |
| Met（達成） | 条件を満たした | ゴールを解除し、達成ログを記録 |
| Impossible（不可能） | 条件を満たすことが原理的に不可能と判定 | ゴールを解除し、理由とともに失敗ログを記録 |
評価者は作業エージェントの推論過程を見ず、会話に現れた結果だけを判定材料にします。これはManaged Agents Outcomesのルーブリック採点エージェントが作業エージェントの思考にアクセスしない設計と同じ思想です。評価者自身はツールを呼び出さず、ファイルを直接読みにいくこともできません。したがって、条件文は「Claudeの出力が証明できる形」で書く必要があります。
無限ループへの安全弁も組み込まれています。評価者に対する応答だけが続きツール使用が数ターン続かない場合、Claude Codeはループを止めて警告を出し、制御をユーザーに戻します。またサブエージェントやバックグラウンドのシェルコマンドが実行中のターンでは評価そのものをスキップし、待機が30分を超えると進捗確認を挟む設計になっています。
自社のエージェントに完了判定をどう組み込むか
既存のエージェント基盤に組み込む場合は、独自のStopフックとして評価者ロジックを実装するのが最も移植しやすい方法です。
/goal を直接使わないエージェント基盤でも、同じ設計パターンは移植できます。プロンプトベースのStopフックとして、ターン終了時に軽量モデルへ条件と会話履歴を渡し、3値判定を返させる構成をそのまま実装できます。
設計時に押さえておくべき点は次の3つです。
- 評価モデルは作業モデルと分離する: 同一モデル・同一コンテキストでの自己採点は避け、別セッションまたは低コストモデルで判定させる。評価トークンは主作業に比べて無視できる規模に収まることが多い
- 条件は「証明可能な形」で書く: 「品質が良い」ではなく「テストが通る」「ファイルが特定サイズ以下」など、エージェントの出力自体が証拠になる条件にする
- 停止条件を必ず入れる: ターン数や時間の上限を条件文に含め、評価者にも進捗を報告させることで、無限ループのリスクを下げる
こうした完了判定の設計は、エージェントの監査ログ設計と組み合わせることで、いつ・どの条件で・どの判定によってエージェントが停止したかを追跡可能にできます。長時間の自律実行を安全に運用する基盤づくりには、KuuのAI Opsサービスで設計支援を提供しています。
規模別の留意点(SMB / エンタープライズ)
中小企業がまず着手する場合は、CI上のテストコマンドやlintのように既に「合格/不合格」が明確なタスクから完了条件を書き始めるのが現実的です。既存のCIコマンドをそのまま条件文に転用できるため、新しい仕組みを一から作る必要がありません。
大規模な組織では、複数チームが独自の完了条件を運用すると評価基準がばらつきます。条件テンプレートと評価モデルの選定基準を共通化し、監査ログに判定理由を残す設計が必要になります。マルチチームでの評価基盤統制を検討する場合は、KuuのRDE(Reinvention Deployed Engineering)サービスでも支援しています。
参考
まとめ
自律的に長時間動くエージェントほど、「終わったかどうか」を誰がどう判定するかの設計が重要になります。作業を行うモデルとは別に、軽量モデルが検証可能な終了条件を都度判定する構成は、自己申告や固定ターン数打ち切りの弱点を構造的に補います。
自社のエージェント基盤にこのパターンを組み込む際は、条件を「証明可能な形」で書くこと、評価者を作業から分離すること、停止条件を必ず含めることの3点から始めるのが実践的です。長時間実行するエージェントの完了判定設計や監査体制の構築については、Kuuにお問い合わせください。