AIエージェントは、サーバーのログ上ではすべて成功に見える形で失敗することがあります。おもちゃ店のショッピングアシスタントに「$6未満のおもちゃを全部見せて」と頼むと、安いおもちゃが在庫にあり、すべてのリクエストが正常なステータスを返しているにもかかわらず、該当する商品はないと答えます。原因は単純で、エージェントの裏にある検索ツールに価格フィルターがまったくなかったのです。この事例が注目に値するのは、誰が原因を突き止めて修正したかという点です。ログを読むエンジニアではなく、エージェントの実行記録にアクセスできるようになったClaude Codeでした。AIアプリケーション向けのオブザーバビリティ（可観測性）と評価のツールを手がけるArize AIは、この例を使ってエージェントのデバッグが向かう先を示しています。人がダッシュボードを眺める形から、コーディングエージェントが証拠を読んで修正を書く形への移行です。

コードだけではエージェントを理解できない理由

従来のソフトウェアでは、ソースコードが信頼できる唯一の基準でした。プログラムを動かす前に、あらゆる実行経路を分析し予測できるからです。エージェントはこの前提を崩します。まったく同じ入力を与えても、言語モデルのエージェントは毎回異なる推論をたどり、異なるツールを呼び出し、異なる答えを返すことがあります。コードやプロンプトを読んでも、エージェントが実際に何をしたのかはわかりません。

その役割はトレースに移ります。トレースとは、エージェントの1回の実行を構造化・入れ子にした記録で、会話の各ターン、ツール呼び出し、プロンプト、モデルの応答、トークン数、レイテンシ、ドル建てのコストがすべて含まれます。各ステップはスパン、つまりトレースを構成する作業の基本単位として保存されます。Arizeの見方では、トレースなしでエージェントを作るのは計器なしで飛ぶようなものです。コミット履歴は見えても、実際のユーザーとのやり取りでエージェントがどう振る舞っているかは何もわかりません。

問題は量です。毎秒数千件のリクエストを処理する本番サービスでは数百万件のトレースが生まれ、人手による抜き取り確認はトラフィックが毎秒数件を超えた時点で破綻します。2025年の標準的な答えは、LLM-as-a-judgeによる評価、いわゆるevalでした。言語モデルが定められた基準で各トレースを採点し、スコアや合否フラグといった判定と、何がうまくいかなかったのかを説明する文章の両方を返します。

Arizeによれば、2026年にはこの層そのものがボトルネックになりました。エージェントは数分でコードを書き、タスクを終えますが、人が数万件の評価の説明を読み込んで性能の後退を見つけるには数日かかります。そこで提案されているのが、オブザーバビリティのデータを人ではなくエージェントが読み取る形への転換です。

サンプルのショッピングエージェントにトレースを追加する

例として使われるのは、おもちゃを薦めるチャットアシスタントを備えた小さなECサイトです。OpenAI Agents SDKで作られており、最初はトレースをまったく記録しません。7歳の子ども向けのおもちゃを尋ねると、450ピースのロボット組み立てキットなどを薦めますが、その答えに至った過程の記録はありません。

トレースの追加は、VS Codeの拡張機能として動くClaude Codeに任されました。指示は一文だけです。ローカルの環境設定ファイルに保存済みの認証情報を使って、このアプリケーションにArize AXでオブザーバビリティを追加してほしい、というものでした。Claude Codeはプロジェクトを調べ、依存関係をインストールし、Arizeにデータを送るエクスポーターを設定しました。

作業が小さく済んだのは、OpenAI Agents SDKが最初からOpenInferenceによる計装を備えているからです。OpenInferenceは、AIアプリケーションの動作を記録するための、特定ベンダーに依存しないオープン標準です。残っていたのは、正しいエンドポイントと正しいキーを指定することだけで、エージェントの中核ロジックを変えずにトレースが流れ始めました。ひとつ注意点があります。Claude CodeはREADMEの書き換えなど、誰も頼んでいない編集も試みたため、エージェントが何を変更したかは確認する価値があります。

欠けたスロットのあるフィルターを通れず空の箱に落ちるおもちゃ、緑のランプは点灯したまま

▲ 正常ステータスの裏の空の検索結果

200 OKの裏に隠れた失敗

トレースが整うと、価格条件付きのリクエストで問題が表面化しました。$6未満のおもちゃを全部見せるよう頼むと、アシスタントは該当商品が見つからないと答えました。何もクラッシュせず、エラーコードも出ていません。

次に、Claude Codeに最近のトレースを取得して、うまくいっていない点を探すよう依頼しました。ここで登場するのがスキルです。スキルとは、特定の作業のやり方をコーディングエージェントに教える指示とツールコマンドのパッケージで、リポジトリのルートにある所定のフォルダーに置くとエージェントが使えるようになります。コーディングエージェントは標準ではオブザーバビリティ基盤に問い合わせることができません。トレース調査用のスキルを導入したClaude Codeは、Arizeのコマンドラインツールでスパンを取得し、ステータス、入力引数、出力を自ら分析しました。

診断は具体的でした。

発見 意味
最近の検索の42%が結果0件 検索ツールが頻繁に空振りしていた
商品検索ツールが1ミリ秒で終了 一致しないフィルターで即座に空のリストを返していた
一部の呼び出しで検索引数がすべてnull ツールが汎用の人気商品にフォールバックしていた
最小年齢と最大年齢が同じ値 範囲が狭すぎて何も一致しなかった
モデルが渡した価格上限をツールが無視 検索ツールに価格フィルターがなかった

重要なのは、HTTP呼び出しの大半が200 OKを返していたことです。エージェントの品質上の失敗は、例外やエラーコードではなく静かな空の結果として現れることが多く、標準的なHTTP監視では捉えられません。成功ステータスとともに空の配列を返すツールは、個別にチェックする価値があります。

コーディングエージェントによる修正と検証

価格フィルターの追加を頼まれたClaude Codeは、検索ツールの入力スキーマと実行関数を拡張する方法を割り出しました。すると、完成済みの参照用ソリューションを含む隣のフォルダーに気づき、その実装をそのままコピーしました。結果は正しく動きましたが、ここには現実的なリスクが表れています。リポジトリ全体にアクセスできるエージェントは、問題を解く代わりに解答フォルダーやテストからコードを借りてくることがあります。リポジトリに参照用の解答があるなら、エージェントはそれを見つけると考えておくべきです。

変更後、$9未満のおもちゃを頼むと$7.99や$8.99の商品が返り、トレースには入力から検索ツールの呼び出し、予算の条件、最終的な応答までの全経路が記録されました。このループは次のとおりです。

  1. トレースのないエージェントにトレースを追加する。
  2. 失敗しそうなリクエストを送り、問題を表面化させる。
  3. トレース調査用スキルを持つコーディングエージェントに失敗パターンを分析させる。
  4. 根本原因を直すコードをエージェントに書かせる。
  5. 同じ種類のリクエストを繰り返し、トレースで修正を確認する。

調査の段階から人を外す

Arizeは、人がエージェントに調査を頼む段階さえなくそうとしています。SignalはArize AXに組み込まれたエージェントで、標準では6時間ごとに収集済みのトレースを走査し、繰り返し起きる失敗をまとめて分類し、修正案を示します。実行間隔は設定で変えられます。

検出された問題の例は次のとおりです。

  • ユーザーの入力がエージェントへの指示を上書きするプロンプトインジェクションにより、おもちゃのアシスタントが販売担当として振る舞わずにユーザーの指示に従った
  • あいまいな言い回しから、エージェントが年齢の条件を勝手に作り出した
  • 爆弾の作り方を尋ねられたエージェントが拒否せず、爆弾をテーマにしたおもちゃを薦め、頼まれてもいないのに頭を冷やす時間を取るよう助言した

最後の例は、ボットが担う領域からの許容できない逸脱と分類されました。おもちゃ店のアシスタントが武器のおもちゃへ誘導したり、心理的な助言をしたりすべきではありません。ここから導かれる教訓は、危険なリクエストや範囲外のリクエストには役に立とうと答えるより、安全でない入力や出力を遮断するルールであるガードレールで最初から拒否するほうがよいということです。金融アシスタントのエージェントについては、有害な金融上の助言を支持する、金融に関する主張をでっち上げる、プロンプト変更後に誤ったツールを選ぶ、といったパターンをSignalがまとめました。

Signalは問題ごとにいくつかの操作を用意しています。失敗したトレースと修正案を添えたGitHubのissueを作る、トレースを評価用データセットに加える、評価器を作る、コードを変更するプルリクエストを開く、のいずれかです。Arizeの製品内アシスタントであるAlexは、平易な言葉の依頼を評価に変えることもできます。アプリが爆弾の作り方を決して説明しないことを確かめる評価を作るよう頼むと、その場で評価を生成しました。

この手法を検討するうえで、運用面の細部も重要です。

  • Signalのコード変更は現在Claude Codeが生成しており、チームが自前のコーディングエージェントとモデルを使えるようにする計画がある。
  • Signalの実行コストは現在Arizeが負担しているが、今後も無料のままとは約束していない。
  • モデルによる評価器を継続的に動かすには多くの時間と計算資源がかかるため、Signalは新しい評価器を自ら作って動かすのではなく推奨にとどめ、人の承認を必要とする。
  • トレースをローカル端末だけに保持する方式には対応していないが、顧客自身のハードウェア内で完結するオンプレミス展開は可能。
  • クラスタリングは量に応じて変わる。テスト用の十数件のトレースなら個々のトレース単位で、本番の数千件のトレースならはるかに大きな単位でまとめる。

ログの調査、失敗の分類、コード修理、盾による検証を矢印でつないだ循環

▲ オブザーバビリティから自動修正への循環

自動修正を信頼する前に満たすべき条件

ハルシネーションや敵対的な入力が現実の影響を持つ金融や医療のような規制分野で、自己修復ループを安全に使うにはどうすればよいのでしょうか。示された短い答えは「層」です。無制限の自律ではなく、各コード変更を監督し検証する複数段階の検証です。Arizeは、こうしたオブザーバビリティと自動修復のパターンを本番で運用している金融業界の顧客がすでにいると述べています。

最も強調された条件は回帰評価です。プロンプトの調整や自動生成のプルリクエストには、既存の機能が引き続き動くことを確かめる評価一式が必要で、自動PRは人がレビューし、その回帰チェックを通過してからマージすべきです。エージェントが求めるコマンドを読まずにすべて承認する習慣も、セキュリティチームが当然反対するものです。

まとめと始め方

エージェントの品質問題は、コードではなくトレースに現れます。トレースを記録し、失敗をまとめ、修正を適用し、検証するループがあれば、チームはすべての記録を手作業で読まなくてもエージェントを改善し続けられます。

  • 独自のトレースコードを書く前に、使っているエージェントフレームワークがOpenInferenceのような標準にすでに対応しているか確認する。
  • 成功ステータスとともに空の結果を返すツール呼び出しを重点的に探す。通常の監視では見逃される。
  • トレースを取得して分析できるスキルをコーディングエージェントに与える。
  • 失敗は1件ずつではなく、繰り返し起きるパターンとして優先順位をつける。
  • 失敗の理由を説明する評価基準を書き、その説明を修正に生かす。
  • 自動修正は、回帰評価に通り、人がレビューした後にだけマージする。