AIエージェントが本当にタスクを完了したか確認する方法

Claude Code、Codex、または別のエージェントに、ファイル整理、表計算の更新、業務レコードの作成を依頼したとします。エージェントが「完了しました」と返し、目立つエラーもありません。しかし、分かるのは実行が終了したことまでで、業務上の結果が保存されたことまでは証明できません。

確実に受け入れるには、期待する終端状態を先に定義し、保存先のシステムから実データを読み戻します。欠落だけでなく、重複書き込みや余計な通知などの想定外の副作用も確認します。結果が不明なら、全体を再実行する前に記録を検索します。

ツールの成功がタスク完了の証明にならない理由

エージェントは安心できそうな信号を返します。ツールがsuccessを返す、プロセスが終了コード0で終わる、レポートが生成される、最後のメッセージで全手順の完了を宣言する、といった信号です。それでも次の点は未確認です。

• 正しいファイルが正しい場所に正しい内容で保存されたか
• 表やデータベースに全レコードが永続化されたか
• 行、注文、通知、ファイルが重複していないか
• 非同期ジョブがまだキューに残っていないか、後でロールバックされていないか
• エージェントが参照だけ行い、必要な更新を省いていないか

Microsoftの公開 ThinkingBox-Bench v1.0 は、実運用の事故率ではなく合成研究ベンチマークです。5つの業務領域にまたがる507件の実行可能タスクを含み、終端状態、副作用、指定された対話属性のチェックがすべて通ったときだけ合格します。固定バージョンの文書では部分点はありません。本記事の「部分完了」「未確認」は運用上の受け入れ状態であり、ベンチマークの採点ではありません。

実行前に受け入れ条件を決める

最終条件を先に書いておくと、確認は大幅に簡単になります。

項目	決める内容	例
必須状態	存在すべきオブジェクト、項目、件数、関係	120ファイルを改名し、表に120個の一意なIDを追加
禁止状態	起きてはいけない変更や副作用	元ファイルを削除しない、2通目を送らない、他のシートを変えない
正式な情報源	受け入れを決める保存先	保存先フォルダー、実セル、CRM、チケット状態
再実行の識別子	今回の業務操作を識別するキー	現在のタスク／操作に紐づく operation_id または注文番号。顧客ID、ファイル名、オブジェクトID、マニフェストハッシュは検索対象の識別子であり、それだけでは今回の操作を証明しない

エージェントの操作ではなく業務結果を書きます。「表更新ツールを呼んだ」は終端状態ではありません。「対象シートに120行あり、顧客IDが一意で、合計が元データと一致する」が終端状態です。

不可逆な操作や重複しやすい操作には順序も設定します。まず取り消し可能なファイルとレコードを更新して確認し、その後にメール、注文、支払いを実行します。前半の失敗で後半まで盲目的に繰り返す必要がなくなります。

実行を特定できる証拠を残す

1回の実行と書き込みを結び付けるため、最低限次を保存します。

• 元の依頼、変更可能範囲、期待する終端状態
• 開始・終了時刻、作業ディレクトリ、対象一覧
• エージェントのセッションIDと返されたjob ID
• operation_idなどの一意な業務キー
• 実行前の件数、版、主要項目、ハッシュ
• 明示されたエラー、タイムアウト、権限拒否、未実行の手順

モデルの非公開な推論過程は受け入れに不要です。必要なのは再現可能な入力、識別子、範囲、保存先の状態です。APIキー、トークン、顧客の秘密情報は記録しません。

最後の返答ではなくシステムの終端状態を待つ

アップロード、一括インポート、レポート生成、外部システムへの書き込みは、返答後も続く場合があります。job IDを保存し、正式なシステムを妥当な間隔で問い合わせ、成功、失敗、取消、タイムアウトのいずれかが確定するまで待ちます。

進捗と最終更新時刻も記録します。結果が遅れて反映されるシステムでは、あらかじめ待機時間を決め、経過後に読み直します。直後に見えないだけで失敗と決めず、無期限にも待ちません。時間切れでも書き込みの有無を判断できない場合は「未確認」であり、「未実行」ではありません。

6段階で結果を読み戻す

1. 対象が存在し、この実行に属することを確認する

パス、ファイル名、レコードID、更新時刻、バージョンを確認します。同名の古いファイルは証拠になりません。別の顧客にひも付く新規レコードも不正解です。

2. 内容と業務上の不変条件を確認する

件数、一意性、合計、必須項目、関連、形式を照合します。表ならID、行数、合計。ファイルなら一覧、サイズ、ハッシュ、または抽出内容。業務レコードなら状態、金額、所有者、対象期間を確認します。

3. 正式なシステムを基準にする

エージェントの要約、端末出力、ローカルキャッシュは補助証拠です。ファイルサービス、実際のセル、CRM、チケット、データベース、決済台帳など、結果を保存するシステムから受け入れを判断します。

4. 必須の副作用をすべて確認する

ファイル作成だけでなく、索引更新、関連レコード、通知が必要な場合があります。同じ業務キーで全項目を確認します。一つでも欠ければ部分完了です。

5. 起きてはいけない副作用を探す

重複行、重複レコード、余計なメール、削除されたファイル、範囲外変更、誤った対象への書き込みを探します。想定外の副作用がある場合、再実行で被害が増えるため自動処理を止めます。

6. システム間で照合する

ファイル、表、業務アプリをまたぐ場合は、まず現在の operation_id またはタスク範囲で各検索を限定し、その上で顧客／オブジェクトID、必要な状態やバージョン、マニフェストを照合します。オブジェクト識別子が一致しても、今回の操作が反映された証明にはなりません。ID集合を比較し、欠落と余分を列挙します。

結果を4つの状態に分類する

状態	使う条件	次の操作
完了	必須条件をすべて確認し、許容できない余分な副作用がない	証拠を保存して終了
部分完了	一部は確認できたが、具体的な欠落がある	欠落だけを補修
未確認	システムに接続できない、反映待ち、または書き込みの有無を判断できない	問い合わせまたは待機。盲目的に再実行しない
想定外の副作用	重複、削除、範囲外変更、誤った対象への書き込みがある	自動化を止めて人が確認

「未確認」は「失敗」ではありません。まだ分からないという状態です。

再実行はこの順序で判断する

1. まず今回の操作を検索する。 記録システムの検索を operation_id または注文番号で現在のタスクに限定し、ファイル名、顧客／オブジェクトID、必要な状態またはバージョンを組み合わせます。対象が見つかっただけでは今回の書き込みを証明できません。
2. 完了済みの境界を特定する。 正しい対象と欠落対象を一覧にします。
3. 冪等に補修する。 同じキーで2件目が作られない保証がある場合だけ、欠落分を送ります。冪等性が不明な不可逆操作は自動再実行しません。
4. レコード、通知、取引を分ける。 レコードがありメールだけ失敗したならメールだけ再送します。メール済みでレコードが不明なら、先にレコードを問い合わせます。
5. 想定外の副作用があれば止める。 誤った対象を修復またはロールバックしてから、人が再開を決めます。

要約すると、未書き込みを確認できた場合だけ再実行し、部分書き込みなら欠落だけを補い、結果不明なら先に検索し、誤った書き込みがあれば停止します。

例：ファイル、表、CRM

以下は仮の例であり、顧客事故や実運用ログではありません。

120ファイルを改名し、追跡表へ120行を書き、CRMに12件の集約レコードを作り、完了メールを1通送るタスクを考えます。読み戻すと、ファイルと表は正しく、CRMは9件だけで、メールはすでに送信済みでした。

正しい状態は「部分完了」です。安全な復旧は次のとおりです。

• operation_idと12個の期待キーでCRMを検索する
• 既存の9件を特定し、重複防止キーを使って欠落3件だけを作る
• 最終12件のCRM IDをファイルと表の集約結果に照合する
• ファイルを再改名せず、120行を書き直さず、メールを再送しない

CRMを検索できない場合は「未確認」です。この状態で全体を再実行すると、重複レコードと2通目の通知が生じる可能性があります。

そのまま使える受け入れ記録

項目	記録する内容
タスクと範囲	目的、変更可能な場所、禁止される変更
期待する終端状態	オブジェクト、項目、件数、関係、最終状態
実行識別子	セッションID、job ID、operation_id、業務キー
正式な証拠	保存先オブジェクト、問い合わせ時刻、ID、リンク
欠落した効果	必須なのに存在しない対象や操作
余分な効果	重複、削除、範囲外変更、余計な通知
受け入れ状態	完了、部分完了、未確認、想定外の副作用
次の操作	終了、待機、補修、再実行、ロールバック、人への引き継ぎ

「確認済み」とだけ書かず、ID一覧、差分、問い合わせ時刻を添えます。

BetterTokenはモデル接続を提供し、業務結果の受け入れはしない

BetterToken経由でClaude Codeを接続する場合は、現在の設定と接続確認ガイドを参照します。接続やモデルのエラーがない通常の応答は設定確認になりますが、ファイル、表、外部レコードが期待状態に達した証明ではありません。

セッション識別子は対象実行を探す手掛かりになりますが、受け入れは保存先システムで行います。モデルが利用可能であること、正常な応答、トークン消費は業務完了の証拠ではありません。

最後に3つだけ確認する

1. エージェントの説明だけでなく、正式なシステムに期待する終端状態が見えるか。
2. 欠落、重複、その他の想定外の副作用を確認したか。
3. 結果不明なら、一意な業務キーで検索してから補修や再実行を決めるか。

3つが明確になってから終了します。次の重要な実行前に上の記録をコピーし、終端状態、禁止状態、再実行識別子を埋めてください。重複処理を後から解くより、小さな準備の方が安く済みます。