AIエージェントの検証可能性｜残すべき5つの証跡

はじめに

AIエージェントを業務へ入れると、「正しい答えを出したか」だけでは足りない場面が増えます。メールを下書きした、CRMを更新した、請求書候補を抽出した。結果だけを見れば成功に見えても、どの情報を根拠にし、どの条件で判断し、実際にどこまで反映されたかが分からなければ、担当者は安心して任せられません。

必要なのは、AIの思考を丸ごと保存することではありません。業務上の判断と操作を、後から第三者がたどれる形にすることです。本記事では、これを「検証可能性」と呼びます。

NISTは2026年5月に公開した Building Evaluation Probes into Agentic AI で、信頼できる文書との照合や、エージェントの処理途中へ検証器を組み込む研究を紹介しています。また、NIST AI 600-1 は、生成AIのリスク管理において、導入前テストだけでなく継続的な監視やインシデント記録を重視しています。実務に置き換えると、完成した文章だけでなく「その結果を確かめられる証跡」を仕様に含める必要がある、ということです。

検証可能性はログの量では決まらない

ログを大量に残せば安全になるわけではありません。プロンプト全文、モデルの応答、ツールの生データを無差別に保存すると、個人情報や機密情報の保管範囲が広がり、必要な記録を見つけにくくなります。

残すべきなのは、次の問いに答えられる最小限の証跡です。

• 何を根拠にしたか
• どのルールで処理したか
• 何を実行したか
• 実行後に何を確認したか
• 人へ何を引き継いだか

この5つを共通の実行IDで結ぶと、担当者は結果から根拠へ戻れます。障害時にも、モデルの誤り、古いデータ、権限不足、外部サービスの失敗を切り分けやすくなります。

残しておきたい5つの証跡

1. 入力根拠：参照元と時点を残す

最初の証跡は、回答や判断に使った入力の出所です。本文を何でも複製するのではなく、文書ID、レコードID、URL、版、取得日時など、正規の情報へ戻れる識別子を残します。

たとえば契約条件を確認するエージェントなら、「契約書を読みました」では不十分です。対象契約のID、参照した版、該当ページ、取得時刻まで分かれば、人が原本を確かめられます。検索結果の要約だけを根拠にせず、可能な限り原本へ到達できる形にします。

ここで重要なのは鮮度です。顧客情報、在庫、予定、請求状況などは変わります。「以前取得した情報」と「今回の実行時点の現在値」を区別できるようにします。期限切れのキャッシュを最新情報のように扱う事故は、モデル性能よりデータ設計の問題です。

2. 判断記録：適用したルールと結論を残す

二つ目は、どの業務ルールを適用して結論を出したかです。長い内部推論を保存する必要はありません。必要なのは、人が検証できる短い判断記録です。

たとえば「外部送信は下書きまで」「金額が10万円以上なら承認へ回す」「対象顧客が特定できない場合は停止する」といった条件と、その判定結果を構造化して残します。

ルールには版を付けます。同じ入力でも、運用ルールが変われば結論が変わるからです。判断記録があれば、「AIがなぜそうしたか」という曖昧な議論を、「どのルールが適用されたか」という業務上の確認へ変えられます。

3. ツール実行：対象と結果を分けて残す

三つ目は、外部システムへの操作記録です。AIエージェントは、回答を作るだけでなく、メール、カレンダー、CRM、ストレージなどを操作します。そのため「ツールを呼んだ」ことと「変更が反映された」ことを分けて記録します。

最低限、ツール名、操作種別、対象ID、要求時刻、結果状態、返却された処理IDを残します。再試行する処理では、同じ論理操作を識別するキーも必要です。通信が切れたからといって別のキーで再送すると、メールやレコードが重複する可能性があります。

秘密情報や本文全体をログへ出す必要はありません。対象IDと結果コードで追跡できる設計にし、詳しい内容は権限管理された正規システムで確認します。

4. 読み戻し：受付ではなく反映を確かめる

四つ目は、操作後の確認結果です。APIが「受け付けた」と返しても、保存や配信が完了したとは限りません。非同期処理、権限不足、検証エラーによって、途中で止まる場合があります。

CRM更新なら同じレコードを読み戻し、期待した項目が反映されたか確認します。ファイル作成ならパス、形式、サイズに加え、必要に応じて実際の表示も確認します。Pull RequestならURLができただけで終わらず、対象ブランチ、変更ファイル、CI、プレビューを別々に確かめます。

この読み戻し結果を証跡として残すと、状態を「要求済み」「処理中」「反映確認済み」「失敗」に分けられます。成功か失敗かの二択に押し込まないことが、再試行時の重複を防ぎます。

5. 人への引き継ぎ：未完了と次の判断を残す

五つ目は、人に渡した時点の状態です。AIエージェントが安全に止まっても、「確認してください」だけでは担当者が困ります。何が完了し、何が未完了で、どの判断が必要かを明示します。

引き継ぎには、対象、完了済みの処理、確認できた事実、未確認事項、推奨する次の操作を含めます。承認が必要なら、承認後に実行される操作も示します。エラーなら、同じ操作を再送してよいのか、まず現在値を照合すべきかを区別します。

これは例外処理だけの話ではありません。通常運用でも、人が最終確認する業務では引き継ぎが成果物です。AI社員の引き継ぎ設計 と合わせて、停止条件と引き継ぎ項目を先に決めておくと運用が安定します。

5つの証跡を受け入れ条件へ変える

証跡は運用開始後に追加するのではなく、要件定義の段階で受け入れ条件にします。

たとえば「問い合わせ内容からCRMタスクを作る」機能なら、次のように試験できます。

1. 入力根拠として問い合わせIDと取得時刻が残る
2. 優先度を決めたルールIDと判定が残る
3. CRM操作の対象IDと処理結果が残る
4. 作成後のレコードを読み戻して内容を照合する
5. 顧客を特定できない場合は停止し、候補と不足情報を人へ渡す

OpenAIの Trace grading も、最終回答だけでなく、ツール選択や途中経路を評価して失敗箇所を見つける考え方を示しています。ただし、特定製品のトレースを保存するだけでは業務要件になりません。自社の対象ID、承認条件、確認方法へ変換して初めて、実運用で使える評価になります。

評価ケースには正常系だけでなく、古い参照元、権限不足、タイムアウト、重複要求、読み戻し不一致も入れます。AIエージェントの受入テスト｜仕様書の6項目 のように、期待出力と禁止動作を分けて定義すると、証跡の不足も見つけやすくなります。

Kakusillで「結果」から「根拠」へ戻れる仕様を作る

検証可能なAIエージェントには、画面や機能の説明だけでなく、入力、判断、操作、確認、引き継ぎのつながりが必要です。業務フローと各工程の受け入れ条件を同じ仕様の中で管理すると、実装者、運用担当者、承認者が同じ境界を見られます。

Kakusill（カクシル） は、ヒアリングや議事録から要件を整理し、AI実装へ渡せる仕様へつなげるためのサービスです。「どの証跡を残すか」「どこで人へ渡すか」まで含めて、AIエージェントの業務仕様を整理できます。

AIエージェントの信頼は、もっともらしい回答ではなく、結果を確かめられる設計から生まれます。まず一つの業務を選び、5つの証跡を受け入れ条件として書き出してみてください。

KakusillでAIエージェントの仕様を整理する際は、各操作に必要な証跡と確認方法を受け入れ条件に含めてください。