AIエージェントは一度うまく動いただけでは信頼できない: ログ、評価、フィードバックループで運用する

1. 概要: 一度の成功は運用品質ではない

AIエージェントのデモは、最終出力がきれいに見えるため説得力があります。検索し、下書きを作り、ツールを呼び、最後に自信のある回答を返します。しかし本番品質は第一印象とは違います。

Anthropicは、エージェントの評価が難しい理由として、複数ターンで動き、ツールを使い、状態を変え、途中の結果に合わせて振る舞いを変える点を挙げています。最終回答が正しく見えても、古い情報源を使った、不要なツール呼び出しを繰り返した、ポリシー確認を飛ばした、もっともらしく別の問題を解いた、ということがあります。

OpenAIのトレーシング文書も同じ運用上のポイントを示しています。エージェント実行には、モデル生成、ツール呼び出し、引き継ぎ、ガードレール、カスタムイベントを含む包括的な記録が必要です。ビジネスの言葉で言えば、会社にはレシートが必要です。

2. やさしい用語整理: ログ、トレース、eval、ゴールドセット

ログはレシートです。何が起きたかを残します。入力、出力、ツール呼び出し、承認、エラー、変更内容がログです。ログがないと、チームは記憶だけで議論することになります。

トレースは経路図です。ログが一枚のレシートだとすれば、トレースは一つの仕事が始まりから終わりまでどの道を通ったかを示します。OpenTelemetryはトレースを複数サービスを通るリクエストの経路として説明しますが、AIエージェントでもモデル呼び出し、ツール、人の確認地点を通る道として読むと分かりやすくなります。

Eval、つまり評価はAIシステムの試験です。「なんとなく良くなった」ではなく、固定した課題を与え、成功したかどうかを採点します。Anthropicは、エージェント評価では最終文章だけでなく、タスク、環境、結果、実行記録を見るべきだと説明しています。

ゴールドセットは基準問題集です。チームが重要だと考える実例を集めた小さな問題集です。難しい返金依頼、紛らわしい顧客質問、CRM更新の例外、危険なツール呼び出し、過去の失敗を入れます。ゴールドセットで悪化した変更は出してはいけません。

• 可観測性: ログ、トレース、メトリクス、ダッシュボードを通じて、システム内部で何が起きているかを見えるようにする力。
• メトリクス: 成功率、人の修正率、ツール呼び出し回数、遅延、コスト、ロールバック率、ポリシー違反率のように追跡する数字。
• LLM-as-a-judge: 別のAIモデルにAI出力を採点させる方法。便利ですが、補正が必要で、唯一の判断基準にしてはいけません。
• ロールバック: 前のプロンプト、SOP、ツール権限、モデル、記録状態に戻せるようにする道。

3. ログとトレース: 答えだけでなく過程を見る

危険なエージェントの失敗は、最終回答だけでは見えないことがあります。丁寧な回答をしていても、古いSOPを読んだ、同じツールを何度も呼んだ、見るべきでない個人メモを使った、承認ステップを飛ばした、ということがあります。

有用なトレースには、入力、検索した情報源、ツール呼び出し、変更された記録、承認、エラー、再試行、コスト、遅延、最終出力が必要です。これはエンジニアだけの資料ではありません。非エンジニアの運用担当者も、AIが何を見て、何をし、どこで人が入ったのかというタイムラインとして読めます。

ただし、OpenAIが注意するように、トレースには設定によって機密データが含まれることがあります。したがって記録とは「すべてを永遠に保存すること」ではありません。ログ自体にもマスキング、保存期間、アクセス権限が必要です。

• 最小ログ: ユーザー依頼、ワークフロー名、エージェント版、利用した情報源、ツール呼び出し、変更フィールド、人の承認、最終出力、エラー状態、時刻。
• 最小トレース: 各ステップの順序、ステップ理由、ツール入出力の要約、自動処理か人の承認か。
• 最小プライバシールール: 秘密情報、認証情報、不要な個人データ、私的メモをトレース内に保存しない。

4. 評価: 不満を反復可能な試験に変える

ユーザーが「エージェントが悪くなった」と言ったとき、最悪の対応は勘で直すことです。より良い対応は、その失敗をテストケースに変えることです。どの入力で問題が起きたのか、本来どうすべきだったのか、どの情報源を使うべきだったのか、どの行動を避けるべきだったのかを残します。

Anthropicは、評価がないチームは反応的な修正ループにはまりやすいと説明します。一つの失敗を直して別の失敗を作り、本当の改善なのかノイズなのか分からなくなります。小さなチームにとっても、巨大なベンチマークより、実際の失敗から作った20から50個の簡単なタスクで始める方が実用的です。

Guildexのような業務運用では、評価は最終回答とプロセスの両方を見るべきです。タスクは解決したか、正しいポリシーを使ったか、危険なツール呼び出しを避けたか、承認を求めたか、人がどれだけ書き直したかを見る必要があります。

• 結果評価: ワークフローが正しいビジネス結果を出したか。
• プロセス評価: 正しい情報源、ツール、順序、承認ゲートを使ったか。
• コスト評価: トークン、ツール呼び出し、レビュー時間を使いすぎていないか。
• 安全評価: 機密データ、禁止行動、広すぎる実行権限を避けたか。

5. ゴールドセットとスコアカード: 品質を見える数字にする

ゴールドセットは最初から大きい必要はありません。代表性が重要です。簡単なケース10個と難しいケース10個は、曖昧な例100個より役に立ちます。大事なのはケースを固定し、変更前後を比べられるようにすることです。

スコアカードは、事業責任者が読めるほど単純であるべきです。よいエージェントスコアカードは、タスク成功、情報源の正確性、ポリシー順守、人の修正率、承認の正しさ、ロールバック率、完了タスクあたりのコスト、顧客向けリスクを見ます。

これによりAI改善は運用会話になります。「新しいプロンプトの方が良さそう」ではなく、「成功率は上がったがツール呼び出しが倍になり、人の修正率は下がっていない」と言えます。つまり、そのワークフローにはまだレビュー負債があります。

• ゴールドセット入力: 過去の実タスク、匿名化した顧客依頼、既知の例外、失敗実行、承認が重要なシナリオ。
• スコアカード出力: 合格/不合格、失敗理由、人の修正メモ、使用情報源、ツール呼び出し、コスト、遅延、ロールバック判断。
• レビュー頻度: 毎週サンプルを読み、大きな変更前にゴールドセットを再実行し、毎月新しい失敗を追加する。

6. LLM-as-a-judge: 便利だが判断の代替ではない

LLM-as-a-judgeは、自由記述の出力を大規模に採点できるため便利です。返信が指示に従っているか、要約が重要点を落としていないか、トーンがルールに反していないかを確認できます。

しかし限界があります。MT-BenchとChatbot Arenaの論文は、LLM judgeに位置バイアス、長文好み、自分のモデルへの好み、限定的な推論能力があり得ることを示しました。したがってモデル審査員を、誰も見えない管理者にしてはいけません。

安全な形は混合評価です。決め打ちできるものはルールで確認し、曖昧な基準はLLM judgeに助けてもらい、定期的に人が補正します。簡単に言えば、AIに採点を手伝わせるが、採点表とエスカレーション経路は人が持つ、ということです。

• 良い使い方: 二つの下書き比較、抜けたポリシー項目の検出、トーン確認、失敗タイプ分類、人の修正内容の要約。
• 悪い使い方: 支払い承認、法令順守の認証、人のレビューの上書き、補正なしの高リスク行動採点。
• 補正ルール: モデルjudgeと人のレビュアーを定期的に比べ、ずれが出たら採点表を直す。

7. フィードバックループ: 修正を仕組みの変更に戻す

フィードバックループは、エージェントを記憶や偶然に頼らず改善する方法です。運用担当者が実行を確認し、失敗にラベルを付け、SOPやプロンプトを直し、ゴールドセットを再実行してから変更を出します。

x-inbox-routerで拾ったXのシグナルも同じ方向を示していました。SkillOptはエージェントのskillを訓練可能な外部手順として扱い、Vibe trainingは本番エージェントにはドメイン固有の失敗を拾う評価器が必要だと主張し、OpenHarnessは権限、hook、memory、task、observabilityをモデル周辺のインフラとして提示しています。これは公式な証明ではなくソーシャルシグナルですが、価値はモデル単体ではなく運用ループにある、というパターンは一貫しています。

重要なのは境界のある改善です。エージェントに自分のルールを自由に書き換えさせてはいけません。人の修正は、小さく名前の付いたSOP、プロンプト、skill、ツール権限の変更として反映し、その変更を再評価するべきです。

• 実行が起きる: エージェントがタスクを完了するか失敗する。
• トレースを読む: 情報源、ツール呼び出し、承認、エラー、出力を見る。
• 失敗にラベルを付ける: 情報源ミス、ポリシー抜け、ツール乱用、過剰実行、コスト急増、承認漏れに分ける。
• 仕組みを直す: SOP、プロンプト、skill、権限、基準、ゴールドセットを更新する。
• 再評価する: 本当に良くなったか、既存ケースを壊していないかを確認する。

8. 避けるべき失敗パターン

一つ目の失敗は、最終出力だけを評価することです。最終回答だけを見ると、遅すぎるツール呼び出し、危険な権限、抜けたポリシー、レビュー負債を隠してしまいます。

二つ目の失敗は、ダッシュボード疲れです。グラフが多いだけでは運用になりません。サンプルを読み、失敗を分類し、仕組みを直さなければ意味がありません。

三つ目の失敗は、境界のない自己改善です。自動改善は魅力的に見えますが、ゴールドセットとロールバック経路なしでエージェントが自分の指示を書き換えると、会社はいつ品質が崩れたのか分からなくなります。

• 成功したデモ一つを品質保証の証拠にしない。
• 問題が起きた時だけevalを回す状態にしない。
• 同じモデルに作業、採点、承認、ルール作成をすべて任せない。
• 誰も読まないログを集めすぎない。
• 保存期間とアクセスルールなしに機密トレースデータを残さない。

9. Guildexチェックリスト: エージェントを本物のワークフローとして運用する

AIエージェントを会社の運用に入れる前に、Guildexは七つの成果物を求めます。ワークフロー責任者、権限表、ログ形式、トレース画面、ゴールドセット、スコアカード、ロールバックルールです。

責任者は誰が結果を所有するかを示します。権限表はエージェントが何を読み、書き、実行できるかを示します。ログとトレースは何が起きたかを示します。ゴールドセットとスコアカードは品質が良くなっているかを示します。ロールバックルールは、エージェントが悪くなった時に会社がどう戻すかを示します。

これは「AIが一度うまくやってくれた」と「AIが信頼できる運用資産になった」の違いです。初日から完璧な自動化を作る必要はありません。ミスを見えるようにし、修正が仕組みに戻るループを作る必要があります。