AIエージェントを業務システムに接続すると、ログ上の SUCCESS と「業務が完了した」は別の意味になります。
たとえば、CRMの更新APIが200を返した、返金メールを送った、Slackへ招待を送った。これらはすべて実行された操作の証拠です。しかし、顧客が「Qualified」になっていること、返金が実際に受理されていること、必要な権限が付与されていることの証拠ではありません。
この記事では、AIエージェントの自己申告ではなく、外部システムの最終状態で完了を判定する設計をまとめます。
「実行完了」と「成果完了」を分ける
エージェント実行では、少なくとも次の3つを区別します。
| 状態 | 意味 | 例 |
|---|---|---|
| 実行完了 | モデルやワークフローが最後まで進んだ | 最終メッセージが返った |
| 操作成功 | 1つのツール呼び出しが受理された | CRM API が 200 を返した |
| 成果完了 | 必要な外部状態がすべて成立している | リードがQualifiedで、フォローアップタスクも存在する |
問題になるのは、上の2つを根拠に3つ目まで「完了」と扱ってしまうことです。ここではこれを false completion（完了誤認） と呼びます。
典型的な完了誤認
CRMのリード作成
エージェントはコンタクトを作成して「リードを登録しました」と返します。しかし実際には、会社ドメインが欠けていたためライフサイクルステージが更新されず、営業が追うべきリードとしては未完了です。
返金対応
エージェントは顧客へ返金案内メールを送りました。しかし、決済プロバイダ側では返金条件に合わずリクエストが拒否されています。メール送信の成功は、返金完了の証拠にはなりません。
オンボーディング
アカウント作成、Slack招待、歓迎メッセージの投稿までできました。一方で、対象のグループにユーザーが追加されていなければ、本人は必要なシステムにアクセスできません。これも部分完了です。
完了条件を先に書く
対策の起点は、プロンプトに「正確に実行してください」と足すことではありません。何をもって完了とするかを、エージェントの応答とは別に定義します。
CRM登録なら、次のように書けます。
const completionConditions = [
verify.crm.contactExists({ email }),
verify.crm.fieldEquals({ email, field: "lifecycle_stage", value: "qualified" }),
verify.crm.followUpTaskExists({ email }),
];
ポイントは、エージェントが返したテキストや直前のツール結果を再利用せず、CRMをあらためて読んで確認することです。
最小の検証ループ
実装は次のループに落とせます。
const result = await agent.run(task);
const checks = await Promise.all([
crm.contactExists(email),
crm.lifecycleStageIs(email, "qualified"),
crm.followUpTaskExists(email),
]);
if (checks.every(Boolean)) {
return { status: "verified_completed", result };
}
return { status: "incomplete", missing: completionConditions };
重要なのは agent.run() が返った時点で completed にしないことです。外部検証が通るまでは、状態を incomplete または needs_recovery に保ちます。
単純なリトライが危険な理由
外部操作を含む業務では、失敗したら最初から再実行、は安全ではありません。
- メールを二重送信する
- 返金を二重に実行する
- チケットを重複作成する
- すでに成功した権限付与を上書きする
そのため、検証に失敗したときは「何が欠けているか」で分岐します。
- 実行前後の外部ID・入力・結果を記録する
- 成功済みの操作は再実行しない
- 欠けている条件だけを修復する
- 取り消しが必要なら補償操作を実行する
- 修復後も独立検証を行う
- 安全に直せない場合は人間へ引き継ぐ
この記録は Action Ledger として持つと扱いやすくなります。最低限でも、idempotency key、外部ID、実行前後の状態、取り消し方法を残します。
計測すべき指標
まず見るべきは、エージェントの成功率ではありません。
False Completion Rate
= 「成功」と報告したが、外部の完了条件を満たさなかった実行数
÷ 「成功」と報告した実行数
併せて、次も分けて記録します。
- Partial Completion Rate: 一部の条件だけ満たした割合
- Duplicate Action Rate: 復旧や再実行が重複操作を起こした割合
- Recovery Rate: 人間を介さずに完了条件へ復帰できた割合
- Human Escalation Rate: 安全な自動修復ができず引き継いだ割合
成功・失敗の二値だけでは、どこに信頼性の問題があるのか見えません。
実装で見落としやすい点
結果整合性を考慮する
外部SaaSには反映遅延があります。書き込み直後に1回だけ読むのではなく、許容する待機時間、ポーリング回数、最終的に人間へ渡す条件を明示します。
検証器はエージェントと独立させる
同じ曖昧な情報をモデルに再評価させるだけでは、検証として弱くなります。API、DB、ブラウザ、ファイル、メール配信結果など、システム・オブ・レコードに近い事実を読みます。
「戻す」を最初から設計する
外部副作用を伴う処理では、失敗時に何を取り消せるかを実行前に決めます。すべてをロールバックできないなら、その境界で承認を求める設計にします。
まずは1業務で確認する
大規模なエージェント基盤を作り替える必要はありません。
- 本番で動いている1つの業務を選ぶ
- 完了条件を3〜5個に分解する
- システム・オブ・レコードを読み直す検証を追加する
- 「成功」と報告した過去実行を照合する
- 完了誤認・部分完了・重複操作を分類する
エージェントが壊れず最後まで動いたことと、ユーザーが望んだ仕事が現実に終わったことは違います。
運用の信頼性を上げる最初の一歩は、エージェントの自己申告ではなく、外部状態で完了を閉じることです。
この課題を継続的に検証するため、Agent False Completionの定義・例・計測方法を公開しています。
https://outcome-runtime-audit.onyx-fit.chatgpt.site/agent-false-completion