Claudeエージェントの実行履歴を評価する：最終回答だけで見えない失敗

要求・操作・状態を結ぶ

一件の利用者要求へ、ツール呼び出し、検証結果、実行ID、保存先の変化を関連付けます。文章とツールログが別々にあるだけでは、どの操作の結果を説明したかが分かりません。

記録する内容は目的に合わせて絞ります。調査のために全ての顧客本文を保存する必要はなく、必要な識別子やエラー種別を中心にする方法もあります。

経路の一致を正解にしない

同じ仕事を別の妥当な順序で完了できる場合、決めたツール列と違うだけで失敗とは限りません。必須の認可や検証が行われ、最終状態が正しいかを確認します。一方、不要な外部操作や重複更新は、結果が正しくても問題として記録します。

読むだけの操作と、状態を変える操作では失敗の影響が違います。更新前に必要な条件を満たしたかを、実行履歴で確かめられるようにします。

失敗を原因別に集計する

誤ったツールの選択、引数の不足、外部サービスの失敗、結果の読み違い、最終説明の誤りを分けます。全体の失敗率だけでは、ツール定義を直すべきか、復旧処理を直すべきか分かりません。失敗した例を再現可能な入力へ戻すことが改善につながります。

同じ結果でも経路に問題がある例を入れる

最終的に正しい状態へ到達しても、その途中で不要な個人情報を読んだり、同じ通知を二度送ったりしていれば問題です。結果の成功、必須手順の遵守、不要な操作の有無を別の欄で確認します。反対に、想定したツール列と違うという理由だけで失敗にしないよう、業務上必要な不変条件を先に定めます。ツールの順序を暗記する評価にしないことが要点です。

失敗した実行の記録は、そのまま再利用できる評価入力へ整理します。ただし本番の秘密や顧客本文を不用意に複製せず、問題が起きる条件を保った架空例へ変える方法も検討します。実行環境を含めて再現できるかを確認し、モデルの回答だけを保存して原因の情報を失わないようにします。記録の量ではなく、修正先を判断できるかで観測を評価します。

具体例で考える

架空の住所更新で、ツールが権限不足を返したのに最終文が「変更しました」になりました。

ツール選択：対象の更新ツール。
実行結果：認可で拒否。
業務状態：変更なし。
説明：成功と誤って報告。

これは保存処理の障害ではなく、実行結果の解釈と報告の失敗です。再試行で権限を回避させず、実行できなかったことを正しく伝える修正が必要です。

確認課題と合格の目安

一つの操作で、要求から最終状態まで追跡する記録項目を決めてください。

• 文章と実際の状態を別々に確認する。
• 必要な検証を行ったか追跡できる。
• 失敗を修正先が分かる種類へ分けている。