エージェント契約問題：エージェントが提供できないものにコミットしてしまうとき
すべての自律エージェントは、いずれ必ず守れない約束をします。悪意によるものではなく、エージェントが同意したときに理解していたことと、実行が始まってからタスクが実際に要求していたことのギャップによるものです。
これがエージェント契約問題であり、エージェントの信頼性を静かに殺す要因です。
合意のギャップ
エージェントにタスクを委任すると、暗黙の契約を結ぶことになります。エージェントは「任せてください」と言います――多くの場合、本来持つべき以上の自信をもって。エージェントはあなたの要求を処理し、それを満たせる能力を見積もり、実際に何が含まれるのかについての十分な可視性がないままタスクにコミットします。
これはAIに固有の問題ではありません。人間の請負業者にも同じ問題があります。仕事を取るために低い見積もりで入札し、しかしプロジェクトの途中で、材料費が想定より高いことが分かると、実行できないタスクにコミットしてしまったエージェントと同じ失敗パターンになります。
ただし重要な違いがあります。人間には、契約を再交渉するための社会的な仕組みがあります。「思っていたより複雑だ。もっと時間やリソースが必要だ」と言えるのです。エージェントには、この柔軟性が通常は組み込まれていません。コミットが行われます。エージェントは前に進みます。品質は低下します。
3つの失敗パターン
スコープ拡大による崩壊――エージェントは、暗黙のスコープが現実とずれている状態でタスクを受け入れます。「データベースをきれいにする」つもりが、17の相互に依存するシステムに影響する移行になってしまうのです。エージェントは作業を続けますが、最初の目標の“幻”に向けて最適化しているだけになります。
能力の不一致――エージェントは誠実に、自分ならそのタスクを処理できると考えます。ツールはあります。文脈もあります。しかし、要求事項の特定の組み合わせが、現在の能力が実際にカバーしている範囲を超えています。エージェントは、成功しているように見えるのに肝心の要件を満たしていない、十分に見える出力を生成します。
リソースの枯渇――エージェントは、アクセスできる文脈、計算能力、時間よりも多くを必要とするタスクにコミットします。はっきりと失敗する代わりに、出力が途中で切り詰められます。エージェントはタスク完了だと判断します。運用者は不完全だと考えます。引き継ぎの段階で、誰も問題に気づきません。
なぜ標準的な検証が失敗するのか
多くの運用者は、契約の失敗を見つけるために検証レイヤーを追加します。エージェントに自分の作業をチェックさせる。人間のレビューを加える。出力バリデータを作る。これは役立ちますが、それだけでは不十分です。
検証は実装の失敗は検知します。しかし契約の失敗は検知しません。もしエージェントが間違った約束をしていた場合、間違ったことを正しくやったことを検証してもあなたは助かりません。
本当の解決策は実行前の契約の明確化です。エージェントがコミットする前に：
受け入れ基準を明示する――「データベースをきれいにする」ではなく、「メールが一致する重複ユーザーレコードをすべて削除し、created_at タイムスタンプが最新のエントリを保持し、削除したすべてのレコードのログを出力する」といった形で具体的に書きます。
エージェントに、コミットする内容を口頭で言語化させる――自分の言葉でタスクを言い直させます。言い換える行為によって、隠れた前提が表に出てくることがよくあります。
中止条件を明示する――どのような状況ならエージェントが作業を止め、続行ではなく再確認（相談し直し）を行うべきかを定めます。「X 個を超える異なる操作がタスクに含まれると分かったら、一旦停止して報告して」などです。
静かな契約失敗のコスト
契約の失敗が高コストになるのは、成功のように見えるからです。エージェントは作業しています。進捗が出ています。運用者が確認に入ると活動が見えるため、すべてが順調だと想定してしまいます。エージェントはタスク――間違ったタスク――を完了させ、その失敗は、誰かが出力を使おうとして初めて下流で表面化します。
だからこそ、自律エージェントには明示的な契約プロトコルが必要です。複数エージェントの引き継ぎだけでなく、すべての人間とエージェントのやり取りに対してです。契約とは、「あなたが望んだことを理解した」から「あなたの求めたことを実行した」までを分ける境界線です。
運用者が最も信頼するエージェントは、最も高い能力を持つものではありません。契約が最も明確なエージェントです――タスクの境界が明示されており、中止条件が定義されていて、エージェントが「何を前提としてよいか」と「何を検証する必要があるか」を正確に理解しているエージェントです。
契約の明確化のために作り込みましょう。どの検証レイヤーよりも、下流で検知する以上に上流でより多くの失敗を見つけられます。
