AIエージェントはプロダクションでどう失敗するのか — 14の失敗モード、そしてリトライが安全ではない理由

はじめに — プロダクションエージェントをめぐる3つの本当の質問
エージェントは実際にどこで失敗するのか — MASTの14のモード
各失敗カテゴリは何を請求してくるのか
なぜリトライは安全ではないのか
MCPは冪等性を保証してくれるのか — ヒントはあるがメカニズムはない
では業界標準はどこまで来たのか — 5年半もドラフトのまま
エージェントのコストをどう測るのか — OTelにはコスト指標がない
トークンを素朴に足すとなぜ間違うのか
何を計装すべきか — そしてオプトインの罠
直せば実際に良くなるのか — 正直な介入結果
では、何をすべきか — 決定ルール
いつ、これら全部をやるべきでないのか
おわりに
参考資料

はじめに — プロダクションエージェントをめぐる3つの本当の質問

デモではよく動くエージェントをプロダクションに載せると、質問が変わります。「これは動くのか?」から「これはなぜ動かなかったのか、いくら燃やしたのか、もう一度試してもいいのか?」へ。本稿はその3つの質問に順番に答えます。

まず結論から。失敗の大半はモデルではなくシステム設計から生まれます。 UCバークレーの研究チームがマルチエージェントシステムの実行トレース1642件を分類した結果、失敗の44.2%がシステム設計の問題、32.3%がエージェント間の不整合、23.5%がタスク検証の失敗でした。そして最も多い2つの失敗モードはステップ反復(15.7%)と終了条件の未認識(12.4%) — 合わせると全体の28.1%です。この2つは単なる「失敗」ではありません。エージェントが同じ仕事を繰り返し、止まり方を知らないという意味であり、それはトークンの請求書であると同時に、副作用が二度起きるという意味でもあります。

ここで3つ目の質問が出てきます。非決定的な呼び出し側(LLM)が本物の副作用(決済、メール送信、チケット作成)を回すとき、リトライは安全なのか? 答えは「あなた自身が安全にしない限り、安全ではない」です。エージェントがツールを呼ぶ標準プロトコルであるMCPには、冪等性を宣言するヒントはあっても、冪等性を保証するメカニズムがありません。そしてこの問題の業界標準というべきIETFのIdempotency-Keyヘッダードラフトは、2020年に始まってまだRFCではありません — 2026年4月に失効した状態です。

エージェントは実際にどこで失敗するのか — MASTの14のモード

最も引用に値する資料はMAST(Multi-Agent System Failure Taxonomy)です。UCバークレーとIntesa Sanpaoloの研究チーム(Cemri、Pan、Yangら、arXiv:2503.13657)がNeurIPS 2025 Datasets & Benchmarksトラックに出した論文で、マルチエージェントシステムの失敗を経験的に分類した最初の試みです。

まず方法論から。研究チームは5つのオープンソースフレームワークのトレース150件あまり(1件あたり平均1万5千行を超えます)をグラウンデッド・セオリー(Grounded Theory)で分析して分類体系を作り、6名の専門アノテーターが参加しました。アノテーター3名がトレース15件を独立にラベリングしてアノテーター間一致度カッパ0.88を確保したうえで、その定義を基準にOpenAI o1ベースのLLM-as-a-judgeパイプラインを作り、全1642件をラベリングしました。

分類結果はこうです。括弧内は全1642件に対する各モードの出現比率です。

[カテゴリ1] システム設計の問題 (System Design Issues)          44.2%
  1.1 タスク仕様への違反     (Disobey Task Specification)      11.8%
  1.2 役割仕様への違反       (Disobey Role Specification)       1.50%
  1.3 ステップ反復           (Step Repetition)                 15.7%   <- 最多
  1.4 会話履歴の喪失         (Loss of Conversation History)     2.80%
  1.5 終了条件の未認識       (Unaware of Termination Conditions) 12.4%

[カテゴリ2] エージェント間の不整合 (Inter-Agent Misalignment)  32.3%
  2.1 会話リセット           (Conversation Reset)               2.20%
  2.2 明確化質問の失敗       (Fail to Ask for Clarification)    6.80%
  2.3 タスク脱線             (Task Derailment)                  7.40%
  2.4 情報の秘匿             (Information Withholding)          0.80%
  2.5 他エージェント入力の無視 (Ignored Other Agent's Input)     1.90%
  2.6 推論と行動の不一致     (Reasoning-Action Mismatch)        13.2%

[カテゴリ3] タスク検証 (Task Verification)                    23.5%
  3.1 早すぎる終了           (Premature Termination)            6.20%
  3.2 検証の欠如/不完全      (No or Incomplete Verification)    8.20%
  3.3 誤った検証             (Incorrect Verification)           9.10%

数字が合っているか確認しておくとよいでしょう。11.8 + 1.5 + 15.7 + 2.8 + 12.4 = 44.2、2.2 + 6.8 + 7.4 + 0.8 + 1.9 + 13.2 = 32.3、6.2 + 8.2 + 9.1 = 23.5。3つのカテゴリを足すとちょうど100%です。

ここで一つ警告を。この論文を要約した二次資料の中には「42%が仕様の問題、37%が調整の崩壊、21%が検証不足」と書いたものが出回っていますが、この3つの数字はいずれも論文にありません。 カテゴリ名も違います — 論文の最初のカテゴリは「仕様の問題」ではなく「システム設計の問題」です(初期バージョンから名前が変わった痕跡のように見えます)。引用するなら、論文のFigure 1を直接見ることをおすすめします。

ベースラインの失敗率も心に留めておく価値があります。論文が評価した7つのSOTAオープンソースシステムの失敗率は、41%から86.7%の間でした。最も悪かったのはAppWorldのTest-C(86.7%失敗)、最も良かったのはAG2のOlympiadBench(41%失敗)です。プロダクションに載せる代物のベースラインがこうだ、という意味です。

各失敗カテゴリは何を請求してくるのか

まず正直に言っておくべきことがあります。モード別に「この失敗はいくら」と書かれた公開数値は存在しません。 MASTは出現頻度を数えたのであってコストを測ったのではなく、私が見つけたどの一次資料も、失敗モード別の金額を公開していません。だからここで数字をでっち上げる代わりに、各カテゴリが請求してくるコストの種類を区別します。実務ではこの区別が金額より役に立ちます — 種類が違えば対応も違うからです。

カテゴリ1(システム設計、44.2%)はトークンで請求されます。 ステップ反復(15.7%)と終了条件の未認識(12.4%)がこのカテゴリの半分以上を占めますが、どちらも症状は「エージェントが回り続ける」です。ループ一周ごとにコンテキスト全体が再びモデルに入るため、コストは線形ではなくそれより急峻に積み上がります。このカテゴリの良い点は、最も安く捕まえられることです — ターン数の上限、予算の上限、反復検知は、モデルに触れずに入れられます。

カテゴリ2(エージェント間の不整合、32.3%)は誤った副作用で請求されます。 このカテゴリの最多モードは推論と行動の不一致(13.2%)で、論文の定義どおりに言えば、エージェントの推論と実際の行動が食い違うケースです。これはトークンの問題ではありません。エージェントが「Aをやる」と言ってBを実行すれば、請求書はBが触ったシステムに残ります。タスク脱線(7.40%)も同じ性格です。

カテゴリ3(タスク検証、23.5%)は静かに間違った成果物で請求されます。 検証の欠如/不完全(8.20%)と誤った検証(9.10%)を合わせると17.3%ですが、この2つに共通するのは、失敗が失敗に見えないことです。論文が挙げる例が印象的です — ChatDevが作ったチェスプログラムが、表面的なテストは通過したというのです。このカテゴリは発見が最も遅く、だからたいてい最も高くつきます。

整理するとこうです。

カテゴリ1 (44.2%)  ->  トークンの請求書       ->  最も安く捕まえられる (上限・検知)
カテゴリ2 (32.3%)  ->  誤った副作用           ->  冪等性・権限で防御
カテゴリ3 (23.5%)  ->  静かに間違った結果     ->  発見が最も遅く、最も高くつく

なぜリトライは安全ではないのか

いよいよ核心です。カテゴリ1の2大モード(反復・未終了)とカテゴリ2の最多モード(推論と行動の不一致)を重ねると、一つの文が浮かび上がります。非決定的な呼び出し側が、実際に副作用を起こすツールを繰り返し呼ぶ。

伝統的な分散システムでは、これは見知らぬ問題ではありません。ネットワークが切れるとクライアントはリクエストが処理されたか分からず、リトライすれば重複が生まれます。だから私たちは冪等性キーを使います。ところがエージェントには問題がもう一つあります — 伝統的なクライアントではリトライするかどうかをコードが決めますが、エージェントではモデルが決めます。 モデルはツールが失敗したと判断すれば(あるいは失敗したと誤判すれば)、ただもう一度呼びます。リトライポリシーがプロンプトの中にあるようなもので、それはポリシーではなく確率です。

ここに非常に重要な区別が一つあります。リトライが危険なのは、ツールが失敗したときだけではありません。ツールが成功したのに応答が失われたときの方が危険です。このときモデルに見えるのは「結果なし」で、モデルの合理的な行動はリトライです。そして副作用はすでに起きています。

MCPは冪等性を保証してくれるのか — ヒントはあるがメカニズムはない

では、エージェントがツールを呼ぶ標準プロトコルであるMCPは、この問題をどう扱っているのでしょうか。現行の最新スペックリビジョン(2025-11-25)のスキーマを直接開いてみると、答えは明確です。

MCPにはツールアノテーションがあり、その一つが冪等性ヒントです。スキーマの定義をそのまま移すと、真であれば「同じ引数でツールを繰り返し呼び出しても、環境への追加的な影響はない」という意味です。4つのヒントのデフォルトはこうです。

readOnlyHint      デフォルト false   (ツールは環境を変更すると仮定)
destructiveHint   デフォルト true    (変更は破壊的だと仮定)
idempotentHint    デフォルト false   (反復呼び出しに追加の影響があると仮定)
openWorldHint     デフォルト true    (外部世界と相互作用すると仮定)

デフォルトがすべて悲観的な側に倒してあることは、注目に値します。アノテーションがなければ、すべてのツールは破壊的で冪等ではない書き込み操作として扱うべきだという意味です。これは良い設計です。

ところがスペックは、これらのヒントについてこう釘を刺します(スキーマのコメント原文の訳です)。

ToolAnnotationsのすべてのプロパティはヒントである。これらがツールの動作を忠実に記述している保証はない(titleのような記述的プロパティを含めて)。クライアントは、信頼できないサーバーから受け取ったToolAnnotationsに基づいてツール使用の判断を下してはならない。

ここで本当の問題が姿を現します。2573行のスキーマ全体で、idempotentHintは宣言されるその1箇所にしか登場しません。 そして「retry」という単語は、スキーマに一度も登場しません。 冪等性キーも、リクエストの重複排除メカニズムも、リトライのセマンティクスもありません。

つまりMCPは冪等性について、語彙は与えますが道具は与えません。 サーバーが「私は冪等です」と主張することはできますが、その主張は(a)強制されず、(b)信頼できないサーバーから来たものは信じるなとスペック自身が警告しており、(c)冪等でないツールをリトライ安全にする方法は、プロトコルにまったくありません。

トランスポート層に再送があるのでは、と問うことはできます。Streamable HTTPのスペックには再開(resumability)と再送(redelivery)があります — サーバーがSSEイベントにidを付け、切断後にクライアントがLast-Event-IDヘッダー付きのGETを送ると、サーバーはその地点以降のメッセージを再生できます。しかしこれはサーバーからクライアントへ向かうメッセージを、切断されたそのストリームに限って再生するものであり(スペックは他のストリームのメッセージを再生してはならないと明記します)、ストリーム内のカーソルにすぎません。クライアントが送ったツール呼び出しを重複排除してくれる仕組みではありません。 MCPスペック自体の方向性についてはMCPがセッションを脱ぎ捨てる — ステートレスコアを読むで別途扱います。

では業界標準はどこまで来たのか — 5年半もドラフトのまま

「冪等性キーを使えばいいだけでは」というのが自然な反応です。そのとおりです。ところが驚くべきことに、冪等性キーには標準がありません。

IETF HTTPAPIワーキンググループのIdempotency-Key HTTPヘッダードラフトの履歴をデータトラッカーで直接確認すると、こうなっています。

draft-idempotency-header-00                  2020-11-17  (個人ドラフト)
draft-ietf-httpapi-idempotency-key-header-00 2021-07-01  (WG採択)
                                        -01  2022-05-08
                                        -02  2022-11-09
                                        -03  2023-07-04
                                        -04  2023-11-16
                                        -05  2024-05-27
                                        -06  2025-02-24
                                        -07  2025-10-15  (最新)

現在の状態: Expired (2026-04-18に失効)
IESGの状態: "I-D Exists" — IESGは処理を開始したことがない

2020年11月に始まって8回改訂され、最新の改訂版は2025年10月に上がり、インターネットドラフトの6か月寿命ルールどおり2026年4月18日に失効しました。IESGの状態は「I-D Exists」 — データトラッカーの説明そのままに「IESGはこのドラフトの処理を開始していないか、出版なしに処理を中止した」です。5年半あまり、RFCになれていません。

だから現実の「冪等性キー」は標準ではなく慣行です。その慣行を最もよく文書化しているのがStripeで、実際、上のIETFドラフトが成文化しようとしていたのも、概ねこの慣行です。Stripeのドキュメントで確認できる動作はこうです。

与えられた冪等性キーに対して、最初のリクエストのステータスコードとレスポンスボディを保存し、成功でも失敗でも保存する。
同じキーで来る後続のリクエストには同じ結果を返す — 500エラーまでそのまま再生する。
冪等性レイヤーは、入ってきたパラメータを元のリクエストと比較し、違えばエラーを出す。
キーは少なくとも24時間が経つと整理(prune)される可能性があり、整理された後に同じキーを再使用すると新しいリクエストが生成される。
結果はエンドポイントの実行が始まった後にのみ保存される。パラメータ検証の失敗や同時実行の衝突は保存されないため、リトライできる。

エージェントの観点からは、2行がとくに痛いところです。一つは500まで再生するということ — 冪等リトライは「もう一度試す」ではなく「元の結果をもう一度見せる」です。モデルが失敗を見てリトライすれば、失敗をもう一度見ます。これはバグではなく設計であり、モデルがこれを理解しなければ無限ループに陥ります(そしてそれがまさに失敗モード1.3、ステップ反復です)。もう一つは24時間です。数日にわたって回る長時間実行エージェントが昨日のキーでリトライすれば、それはリトライではなく新しい副作用です。

エージェントのコストをどう測るのか — OTelにはコスト指標がない

次は可観測性です。標準に従いたければOpenTelemetryのGenAIセマンティック規約を見ることになりますが、現在の状態を正確に知ってから始めるのがよいでしょう。

第一に、GenAI規約は引っ越しました。 もともとopen-telemetry/semantic-conventionsリポジトリのdocs/gen-aiにありましたが、いまその経路のファイルには「このページは移動しており、もはやこのリポジトリでは管理されていません」という案内だけが残っています。新しい住まいはopen-telemetry/semantic-conventions-genaiです。

第二に、その新リポジトリは2026年5月5日に作られ、まだリリースが一つもありません。 (本体のセマンティック規約の最新リリースはv1.43.0、2026年7月3日です。)そしてエージェントスパンのドキュメントもMCPのドキュメントも、ドキュメントステータスは「Development」です。開発が止まっているわけではありません — 最後のプッシュは2日前です。ただし、あなたが「標準」と呼んでダッシュボードを建てるその代物は、まだ一度もリリースされたことのない開発中のスペックだという意味です。

第三に、そしてこれが実務でいちばん重要ですが — コスト指標がありません。 GenAIセマンティック規約のメトリクス文書と属性レジストリ全体をcost、price、usd、dollarで検索すると、結果は0件です。定義されているメトリクスは、これで全部です。

gen_ai.client.token.usage
gen_ai.client.operation.duration
gen_ai.client.operation.time_to_first_chunk
gen_ai.client.operation.time_per_output_chunk
gen_ai.server.request.duration
gen_ai.server.time_to_first_token
gen_ai.server.time_per_output_token

標準はトークンをくれます。お金はあなたの仕事です。 トークンを金額に変えるにはモデル別の単価表が必要で、その表はベンダーが変えます。ベンダー各社のコストダッシュボードがそれぞれ独自規格で、互いに数字が合わない理由はここにあります。

トークンを素朴に足すとなぜ間違うのか

コストを自分で計算すると決めたなら、必ず知っておくべき罠が一つあります。属性レジストリに定義されているトークン属性は5つです。

gen_ai.usage.input_tokens
gen_ai.usage.output_tokens
gen_ai.usage.cache_creation.input_tokens
gen_ai.usage.cache_read.input_tokens
gen_ai.usage.reasoning.output_tokens

問題は、これらがフラットではなく入れ子になっていることです。レジストリのコメントが明記しています — キャッシュ生成トークンとキャッシュ読み取りトークンはgen_ai.usage.input_tokensに含まれるべき(SHOULD)であり、入力トークンはキャッシュされたトークンを含め、あらゆる種類の入力トークンを含むべきです。推論トークンも同様にgen_ai.usage.output_tokensに含まれるべきです。

だから、この計算は間違いです。

間違った計算:
  コスト = input_tokens x 入力単価 + output_tokens x 出力単価

なぜ間違いか:
  input_tokens の中に cache_read.input_tokens がすでに含まれている
  キャッシュ読み取りは新規入力より安く課金される (それがキャッシュを使う理由)
  -> キャッシュが効くほど、あなたの計算は実際より高く出る

正しい方向:
  新規入力 = input_tokens - cache_read - cache_creation
  コスト = 新規入力 x 入力単価
       + cache_read x キャッシュ読み取り単価
       + cache_creation x キャッシュ書き込み単価
       + output_tokens x 出力単価
  (単価はベンダー・モデルごとに異なるため、ここに数字は書きません)

エージェントでは、この誤差は小さくありません。エージェントループは毎ターン同じシステムプロンプトとツール定義を再送するため、キャッシュヒット率が構造的に高く、その分input_tokensのうちキャッシュ読み取りの比重が大きいのです。素朴に足すと、キャッシュが効くほど帳簿上のコストが膨らみます。 キャッシングのコスト効果をダッシュボードで確かめようとして、正反対の結論に到達しかねません。

もう一段あります。上の5つの属性はスパン属性であり、メトリクスgen_ai.client.token.usageのディメンションであるgen_ai.token.typeのwell-knownな値は、inputとoutputの2つだけです。つまり、集計されたメトリクスだけを見ていては、キャッシュされたトークンと新規トークンを区別できません。 正確なコストを出すには、スパン単位まで降りる必要があります。(カスタム値を使うことはできますが、その瞬間に標準ではなくなります。)

何を計装すべきか — そしてオプトインの罠

ツール呼び出しの計装はexecute_toolスパンで行います。スパン名はexecute_toolの後ろにツール名を付ける形式で、属性はこうです。

gen_ai.operation.name        Required            (Development)
gen_ai.tool.name             Required            (Development)
error.type                   Recommended         (Stable)
gen_ai.agent.name            Conditionally Req.  (Development)
gen_ai.tool.call.id          Recommended         (Development)
gen_ai.tool.description      Recommended         (Development)
gen_ai.tool.type             Recommended         (Development)
gen_ai.tool.call.arguments   Opt-In              (Development)   <- デフォルト未収集
gen_ai.tool.call.result      Opt-In              (Development)   <- デフォルト未収集

最後の2行が罠です。エージェントがどんな引数でツールを呼び、何を受け取ったのかは「Opt-In」 — つまりデフォルトでは収集されません。それには相応の理由があります(個人情報と保存コスト)。しかし結果として、エージェントがなぜ見当違いのことをしたのかをデバッグするのに、まさに必要なその2つのフィールドがデフォルトでオフになっています。 カテゴリ2(推論と行動の不一致)を追跡するにはこれをオンにする必要があり、オンにした瞬間、トレースに機微情報が入り込みえます。タダ飯ではありません — サンプリング・マスキングとともに意識的に決めるべきトレードオフです。

MCPを使うなら、もう一つ知っておくべきことがあります。MCPセマンティック規約のドキュメントは、HTTPのトレースコンテキスト伝播はHTTPリクエストしかカバーせず、リクエスト/レスポンスストリームの中を行き交う個々のメッセージはカバーできないと指摘します。だから計装はMCPリクエストのparams._metaポケットにコンテキストを注入する必要があり(SEP-414がtraceparent、tracestate、baggageキーの扱いを定義します)、受信側がそれをリモート親として使います。これをやらないと、エージェントのトレースがMCPの境界で切れます。 ロギング・トレーシングの一般論はLLMログとトレーシングを参照してください。

直せば実際に良くなるのか — 正直な介入結果

ここが本稿でいちばん正直であるべき部分です。MAST論文は分類だけで終わらせず、分類を根拠に実際の介入を試しています。結果(論文Table 5)はこうです。

AG2 / GSM-Plus (GPT-4)      ベースライン 84.75 +- 1.94 | プロンプト改善 89.75 +- 1.44 | トポロジー変更 85.50 +- 1.18
AG2 / GSM-Plus (GPT-4o)     ベースライン 84.25 +- 1.86 | プロンプト改善 89.00 +- 1.38 | トポロジー変更 88.83 +- 1.51
ChatDev / ProgramDev-v0     ベースライン 25.0          | プロンプト改善 34.4          | トポロジー変更 40.6
ChatDev / HumanEval         ベースライン 89.6          | プロンプト改善 90.3          | トポロジー変更 91.5

広く引用される「+9.4%」と「+15.6%」はここから来ています。ChatDevのProgramDev-v0で25.0 → 34.4が+9.4、25.0 → 40.6が+15.6です。パーセントではなくパーセントポイントです。

ただ、この数字を引用するなら、必ず併せて言うべきことがあります。

第一に、ProgramDev-v0は32個のタスクです。 32個に対する25.0%は8個、34.4%は11個、40.6%は13個です(計算がぴったり合います)。つまり話題の「+9.4%p」はタスク3個、「+15.6%p」はタスク5個を余分に通過したという意味です。小さなサンプルです。

第二に、最善の介入の後でも成功率は40.6%です。 言い換えれば、依然として約59%が失敗します。論文の表現をそのまま移せば「初期段階の介入は性能向上につながるものの、すべての失敗モードが解消されるわけではなく、タスク完了率は依然として低く、より実質的な改善が必要であることを示唆する」です。

第三に、効果は普遍的ではありません。 AG2では、トポロジー変更はGPT-4でウィルコクソン検定のp値0.4と統計的に有意ではなく、同じ変更がGPT-4oではp値0.03で有意でした。論文の結論は「これらの戦略は普遍的ではなく、その効果は基盤LLMのような要因に依存する」です。

第四に、方向性はあります。 論文は、両システムともトポロジーベースの変更がプロンプトベースの変更より効果的だったと報告しています。そして著者らは、堅牢な信頼性には「孤立した修正以上」が必要であり、「根本的なMAS再設計」に向かうべきだと釘を刺しています。

最後に、この資料自体の限界を。1642件の大半は著者らが作ったo1ベースのLLMアノテーターがラベリングしました。 人間が検証したのは、はるかに小さな部分集合です(カッパ0.88はトレース15件に対するアノテーター3名の一致度です)。著者ら自身が「MASTがあらゆる潜在的な失敗パターンを網羅すると主張するわけではない」と書いています。これは決定的な地図ではなく、これまでに出た中で最も経験的な地図です。

では、何をすべきか — 決定ルール

上の資料から直接に導かれるルールです。

1. ツールをまず副作用基準で分類する。 MCPのデフォルトがすでに正解を教えてくれます — アノテーションがなければ、破壊的・非冪等として扱う。読み取り専用ツールと書き込みツールを混ぜたまま、リトライポリシーを一つで済ませないでください。

2. 冪等性はあなたのレイヤーで実装する。 MCPのidempotentHintはヒントであって保証ではなく、信頼できないサーバーのアノテーションは信じるなとスペック自身が言っています。IETF標準もありません。だから副作用を起こすツールは、あなたのサーバー側でキーを受け取り、最初の結果を保存して再生してください。Stripeの慣行が検証済みの参考実装です — 結果(エラーを含む)を保存し、パラメータの指紋を比較し、保持期間を明示するところまで。

3. キーをモデルに作らせない。 リトライを決める主体が非決定的なのだから、冪等性キーは決定的な場所 — オーケストレーターのステップIDやタスクID — から導出すべきです。モデルが毎回新しいキーをでっち上げるなら、冪等性キーは飾りです。

4. 上限を予算として掛ける。 失敗の28.1%が反復と未終了なら、ターン上限とトークン予算は最適化ではなくサーキットブレーカーです。最も多い失敗カテゴリを最も安く防ぐ方法です。

5. コストはスパンで計算する。 メトリクスだけではキャッシュトークンを分離できません。そしてトークンをそのまま足さないでください — キャッシュ読み取りはすでにinput_tokensの中にいます。

6. 引数と結果の収集は意識的に決める。 デフォルトはオフです。オンにしなければカテゴリ2をデバッグできず、オンにすれば機微情報がトレースに入ります。サンプリングとマスキングを一緒に設計してください。

いつ、これら全部をやるべきでないのか

正直な反対側です。上記の大半は、エージェントが本物の副作用を回すときにだけ価値を持ちます。

読み取り専用のエージェントなら、冪等性インフラは過剰です。 検索・要約・分析しかしないエージェントでは、重複呼び出しはお金を余計に使うだけで、状態を壊しません。上限だけ掛けて先へ進みましょう。
人間がすべての書き込みを承認するなら、リトライのリスクはほぼ消えます。 承認ゲートは冪等性レイヤーより安く実装でき、初期段階ではたいていその方が優れています。
ワークフローで足りるなら、エージェントを使わないでください。 MASTの失敗の大半はシステム設計の問題で、それは「決定をモデルに委ねた分だけ」生まれます。経路が決まっているならコードで書きましょう — 効果的なAIエージェントの作り方で扱ったワークフロー/エージェントの区別が、ここでもそのまま有効です。
単一エージェントで済むなら、マルチエージェントに行かないでください。 MASTの失敗の32.3%はエージェントのあいだで起きました。エージェントを一つ足した瞬間、その32.3%の表面積を新たに買うことになります。

おわりに

整理するとこうです。エージェントの失敗はモデルの失敗ではなく、大半はシステム設計の失敗です(MAST基準で44.2%)。最も多い2つのモードは反復と未終了で(合わせて28.1%)、この2つはトークンを燃やすと同時に副作用を重複させます。そしてその重複を防いでくれるプロトコルレベルの仕組みはありません — MCPは冪等性のヒントをくれるだけで、IETFの冪等性キー標準は5年半もドラフトのまま、いまは失効状態です。可観測性の側も似ています — OTel GenAI規約はリリースが一つもない開発中のスペックで、コスト指標がそもそもなく、デバッグに必要な引数・結果はデフォルトでオフです。

このリストは悲観しろという意味ではなく、どこをあなた自身が埋めるべきかの地図です。標準が埋めてくれると期待して空けておいた欄こそ、プロダクションで請求書が飛んでくる欄です。

そして最後に、介入結果をもう一度見てみましょう。最善の構造的介入の後でも、コード生成の成功率は25.0%から40.6%でした — 依然として半分以上が失敗します。プロダクションエージェントを運用するということは、失敗をなくすことではなく、失敗のコストを知ることに近いのです。どの失敗がトークンを燃やすだけで、どの失敗が状態を壊し、どの失敗が静かに間違った答えを出すのか。その3つを区別できた瞬間から、運用が始まります。エージェントを何でどう測るかという問題はシミュレートされた顧客は決して離脱しないで、エージェントを隔離して回す問題はLambdaマイクロVMエージェントサンドボックスで続きます。