OpenAI の技術スタッフが語る、モデル改善でも解決しないエージェント失敗の教訓

OpenAI の技術スタッフであるスチュアート・シ氏が繰り返し指摘する失敗があります。あるシステムでは、30 回から 50 回の会話に 1 回程度、エラーも出ず、ダッシュボード上で明らかな誤答が表示されるわけでもないのに会話が停止してしまう現象が観測されました。

エージェントを実環境へデプロイした経験がある開発者なら誰でもこの問題に直面しているはずです。頻度が高すぎて無視できない一方で、他の時間には隠れてしまうバグです。しかし、まさにその頻度が、この問題を見過ごす原因となっています。数十回に一度の失敗は、集計された品質スコアを有意に変えるほど頻繁ではないかもしれませんが、実環境では無視できるレベルではありません。

シ氏の診断は、モデル自体の外側から始まります。「基本的に、モデルの知能がボトルネックになっているわけではありません」と彼は言います。エンジニアリング上の課題は、モデル周辺で何が起きたかを理解し、失敗を測定し、その証拠に基づいてシステムを改善することです。

なぜ能力のあるモデルでも失敗するのか？

「基本的に、モデルの知能がボトルネックになっているわけではありません」とシ氏は述べています。問題は、能力の過剰さ（キャパビリティ・オーバーハン）にあります。モデルはすでにチームが求める作業を実行する能力を持っていますが、「実際には利用可能なツールやコンテキストによって制約されていることが多い」のです。

エージェントが失敗した場合、モデルを差し替えるかどうかを決める前に、まずその実行で実際に何が見えたのか、そして何が許可されていたのかを確認することから始めるべきです。

同じパターンは、さまざまなタイプのエージェントに共通して見られます。強力なモデル上で動作するサポートエージェントでも、アカウント状態へのアクセスができない場合や、チケットを解決するためのツールを呼び出せない場合には失敗します。同様に、コーディングエージェントが論理的に正しい変更点を導き出したとしても、テストランナーが利用できない環境やファイル書き込みの権限が付与されていない環境では失敗します。どちらの場合も、その失敗はモデル自体の能力不足というよりも、タスクに必要なリソースを周囲のシステムが提供できていなかったことに起因していることが多いのです。

優れたモデルであっても、周囲のシステムのすべての欠陥を補うことはできません。エージェントが受け取る情報の範囲は「コンテキスト」によって決まり、利用可能なツールや状態、実行できるアクションは「ハレス（環境）」によって制御されます。単にモデルをアップグレードしただけでは、ツールの欠落、文脈の断絶、あるいは権限エラーが静かに見過ごされるといった問題は解決できません。

モデルを変更する前に、以下の4点を自問してください。

• エージェントは必要なドキュメント、状態情報、およびツール結果を受け取っていたか？
• 必要なツールが利用可能で、かつモデルが使用できるスキーマを持っていたか？
• ツールの呼び出しが失敗し、タイムアウトしたか、あるいは空のペイロードを返してモデルがそれを事実として扱ったか？
• 同じコンテキストとツールを持つ人間であれば、タスクを完了できたか？

もしこれらのいずれかの層に問題がある場合、より大規模なモデルに移行してもコストが増えるだけで、根本的な問題は解決されません。

タスク特化型モデルから、コンテキスト、プロンプト、評価へと重心が移っています。

Sy氏の2点目は、現在エンジニアリングリソースをどこに注力すべきかという問題に関わっています。

「以前、ユーザーフィードバックの感情分類や構造化された分類体系への分類を行いたい場合、特定のモデルを訓練する必要がありました」と彼は語ります。その結果、「非常に効率的ではあるが単用途に限定されたツール」が生み出されました。

その代替案となるのは、基盤モデルとそれを支える周辺システムです。「適切なコンテキストエンジニアリング、プロンプト設計、そしてプロンプトやツールの設定方法を改善するための正しい評価セット」が必要です。

モデルを一定期間固定して学習し、その後入力や周囲のツールを変化させて、それぞれの変更が実際に結果に寄与したかどうかを測定します。

コンテキストエンジニアリングとは、モデルが目にする情報を決定する実践です。具体的には、事実情報、セッションの状態、利用可能なツール、そしてそれらを包むフォーマットです。プロンプトの文言も重要ですが、それは一つの層に過ぎません。残りの要素は、どのような証拠を抽出するか、それをどう圧縮するか、どのツールのスキーマを公開するか、そして失敗後に同じセットを再実行できるかどうかといった点にかかっています。

評価セット（eval set）は、この反復プロセスに安定した目標を与えます。プロンプトやコンテキスト、ツールを変更し始める前に、成功の基準を定義するものです。感情分類器を置き換えるチームは、一般的な有用性スコアではなく、ラベル付けされた実際のフィードバックサンプルに対して評価を行うべきです。同様に、分類モデルを置き換えるチームは、新しい設定がケースを適切なノードにルーティングできるか、ラベルが不明確な場合に判断を保留（abstain）できるかをチェックする必要があります。評価セットは、チームにとって重要な振る舞いが維持されたか、あるいは改善されたかを判断する手がかりとなります。

この緊密なループは以下のようになります：

実在する事例、特に断続的に発生する失敗の例を少数集めましょう。

その失敗を明確に定義する狭い基準を作成します。

文脈、ツール、またはプロンプトのいずれか一つを変更し、同じケースで再実行します。

評価結果が改善した場合のみ、その変更を採用してください。

再帰的な自己改善は、自ら構築しなければならないフィードバックループです。

「研究分野でも応用組織においても、大きなテーマの一つが『再帰的な自己改善』の概念です」とSy氏は語ります。「どのようにして、より良い状態へと登っていくための自動ループを構築するか」を考える必要があります。

ここで言う自己改善とは、エージェントが自律的にコードを書き換えたり、自身の重み（ウェイト）を更新したりすることを意味するわけではありません。このループは、生産現場での実証データを元に、文脈やプロンプト、ツール、評価基準、あるいは周辺システムへの変更を加えるように設計されたプロセスで構いません。

OpenAIにおけるこのループの起点は「量」です。「ChatGPTの利用者が10億人に近づきつつある今、私たちは非常に多様なソースから膨大なフィードバックを受け続けています」とSy氏は説明します。「それは、人間が手作業で一つずつ読み込み、理解し、優先順位をつけ、対応するといった処理を一度にすべて行うにはあまりにも膨大です」

そのため、彼らは1日に数百万件のデータを処理し、その流れに対する共通の理解を形成するシステムを構築しました。「この規模のデータを扱うためには、間違いなく高度な従来のソフトウェアエンジニアリングが必要です」とSy氏は指摘します。

ほとんどのチームが1日に数百万件のイベントを処理する必要はありません。それでも、このプロセスは十分に適用可能です。

評価、チケット、チャット修正、トレースの失敗を一つのイベントモデルに統合し、生テキストと会話 ID またはトレース ID を紐付けて管理します。

既知の失敗事例から簡易な分類体系（ツールエラー、文脈不足、ラベル誤り、セッション放棄など）を構築します。

直近の未処理データをクラスタリングすることで、誰かが可視化チャートを作成する前に新たな失敗モードを検出できるようにします。

確認されたクラスタを実行評価ケースとして昇格させ、リリース後もその挙動を追跡します。

なぜエージェントの評価にはプロセス指標が必要なのか

エージェントの実行時間が長くなるほど、最終出力のスコアだけでは隠れてしまう失敗が増えます。

「最終出力だけでなく、プロセス内で何が起きているかに注意を払う必要があります」と Sy は指摘しています。開発者は以下の問いに答えられるべきです。

• どのようなツール呼び出しが行われ、その回数はどれくらいか？
• それらの呼び出しに伴うエラー率やレイテンシはどうか？
• モデルが使用する思考の量（計算コスト）は最終出力に影響を与えるのか？

あるコード生成エージェントは、12 回の失敗したツール呼び出し、3 回のタイムアウト、そしてテスト結果を反映しない試行錯誤を繰り返した後、一見正しく見えるパッチを出力するかもしれません。最終的な差分のみを評価する仕組みでは、こうしたプロセス上の失敗を見逃してしまいます。トレースがあれば、その問題が浮き彫りになります。

これが、ハルネス評価がモデル評価と並列して行われる理由でもあります。ハルネスとは、ツール、文脈、状態、リトライ、停止条件を管理する実行環境です。もしトレースでツールエラー率が高いことが示された場合、次の改善策はシステムプロンプトではなく、ツールのスキーマ変更やリトライポリシーの調整、あるいは権限層の見直しになる可能性があります。

このシリーズの第2部でハメル・フサイン氏は、一般的な指標では実際に問題となる失敗を捉えきれないと指摘しています。有用な評価を行うには、まず実データに目を向ける必要があります。シ氏はその上で、計測（インストルメンテーション）の実装が不可欠だと付け加えています。もし実行時にツール呼び出しやエラー、レイテンシー、思考の労力といった情報が記録されていなければ、データを分析すること自体が不可能だからです。

つまり、最終的なレスポンスだけをレビューするのではなく、実行の軌跡（トラジェクトリ）全体を計測する必要があります。例えば Arize Phoenix や Arize AX では、以下のような詳細を検査できます。

• 各モデル呼び出しやツール呼び出しのスパン：引数、エラー、レイテンシーを含めて確認可能
• リクエストごとのトレースレベルのビュー：最後のメッセージだけでなく、処理の経路全体を可視化
• 複数ターンにわたる作業を対象としたセッションレベルの評価
• 稀な事象に対応するための本番環境でのトレース：例えば「30回に1回だけチャットが停止する」といったケースは、20例からなる固定のゴールデンセットでは決して検出できません。

この「30回に1回の停止」こそが、本番環境での追跡によって初めて発見できるタイプの失敗です。オフライン評価も依然として必要ですが、本番実行を通じてのみ、固定された評価セットにはまだ含まれていない稀な事象や新たに現れる問題を把握できます。

AI エンジニアは、やはりエンジニアでなければならない

会話の終盤、シ氏はこのシリーズが繰り返し問いかけてきた一文を締めくくりました。それは「AI エンジニアとは、基盤モデルや大規模言語モデルの上に利用可能になった新しいプリミティブを活用して、AI プロダクトやシステムを構築する人である」という定義です。

そして、彼はそこに制約を設けます。「堅固な基盤となるエンジニアリングスキルセットは依然として必要です。あなたが構築の土台としている既存システムについて深く理解していることが、何よりも重要です。」

AI エンジニアリングは、これらの既存のエンジニアリングスキルの上に成り立ちつつも、モデル、コンテキスト、ツール、評価、そしてエージェントランタイムに関する新たな課題を伴います。AI エンジニアは、「生成 AI から最大限のパフォーマンスを引き出す方法」や「原理に基づき予測可能な形で活用する技術」を理解している必要があります。Sy のリストにある要素で言えば、これはコンテキストエンジニアリング、ハーンネス（基盤）エンジニアリング、適切なツールの選定、スキル、MCP コネクタの活用、そして生産レベルのパフォーマンスを達成するためにエージェントの状態を十分に把握・観測できる能力を指します。

これは単なる「プロンプトエンジニア」という肩書きよりもはるかに明確な職務記述です。また、これは Michael Grinich が最初の連載で主張した内容とも合致しています。つまり、エージェントを取り巻くシステムこそが、自律性が有用なものとなるのか、それとも失敗する速度が速くなるだけなのかを決定づけるのです。

「原理に基づき予測可能な」という基準は、Sy 氏が語るこの分野にとって有用な指標となります。失敗した実行を再生することで再現性を確保できます。ツールのエラーやレイテンシの分析は、コンテキストに起因する失敗とランタイムに起因する失敗を区別するのに役立ちます。また、生産現場で繰り返し寄せられる不満を評価ケース（eval cases）に変換することで、チームは「次の変更が実際に問題を解決したか」を検証する方法を得られます。

Stuart Sy 氏との対談を含む『AI エンジニアの台頭』エピソードの全編をご覧いただけます。