複数のツールをつなぎ合わせて仕事をこなすAIがあるとしよう。毎週月曜の朝、このAIが社内システムをあちこち調べて週次の状況レポートをまとめる。ところが資料を取ってくるツールが突然応答を止める。それと同時に、報告を受ける上司が割り込んでくる。「今回は先週じゃなくて、今四半期の累計で見てくれ」。ツールは応答せず、基準は変わった。この瞬間、AIはどうすればいいのか。
こうしたAIを「エージェント」と呼ぶ。一問一答のチャットボットとは違い、エージェントはツールを呼び出し、その結果を見てから次の行動を自分で決める。問題は、現実のツールがチャットボットへの質問のようにおとなしくはない点にある。タイムアウトが起き、権限で弾かれ、ユーザーが途中で方向を変える。人間のオペレーターなら動じないような場面だ。エージェントは違う。
中国人民大学（Renmin University of China）とシンガポール国立大学の研究チームが打ち出したAgent-Reflexは、このズレに正面から取り組む。発想はシンプルだ。失敗した作業の記録から「こういう状況でこうつまずいたら、こう復旧せよ」というルールを抜き出し、デプロイする前にモデルへあらかじめ埋め込んでおく。
エージェントを育てる訓練環境には、こうした変数がほとんどない。現実のツールは揺れるのに、訓練場は過度にきれいなのだ。
ここでいう「環境」とは、特定の業務に使うツール・データ・作業条件のまとまりを指す。社内の課題トラッカーが一つ、運用データベースが一つ、それぞれが一つの環境だ。従来の訓練環境は、これらのツールが常にきれいな値を返してくると仮定する。だからエージェントは、失敗を検知して引き返す練習を一度もしないままデプロイされる。
抜け落ちているのは二種類の揺れだ。一つはツールが吐くエラー。もう一つはユーザーの割り込み——「そうじゃなくてこっちで」と方向を変える訂正だ。とりわけ従来のユーザーシミュレーターは定型のテンプレートにとどまり、実際のユーザーの多様な訂正指示や口調をほとんど再現できない。
これは小さなモデルだけの問題でもない。論文のFigure 1を見ると、GPT-5.2やClaude-4.5-Sonnetのような最上位モデルでさえ、ノイズがないとき、ユーザーが割り込むとき、ツールがエラーを返すときで成功率がガクンガクンと変わる。フロンティア級でも環境が揺れれば一緒に揺れる。小さなモデルはもっとひどい。
この問題に手を付けてきたやり方はいくつかある。作業の途中でモデルが自分自身に批評を加えて直すやり方は、その批評が間違ったまさにそのモデルから出てくるため、もっともらしいエラーを除けない。失敗記録を復旧を含んだ形で学習し直すやり方は、復旧がその作業一回きりにとどまり、次に取り出して使えるルールとして残らない。解けるタスクと環境をさらに量産するやり方は、環境は増やせても、その中の失敗を復旧の知識に変える仕掛けがない。Agent-Reflexは最後のやり方に近いが、失敗を環境を増やす素材ではなく、環境ごとに積み上がる再利用可能なルールへと還元する点が異なる。（各方式の代表的な研究は付録に。）
Agent-Reflexの核心は、省察をモデルが生まれつき備えるのを待つのではなく、失敗から抜き出して埋め込める技術として扱うところにある。失敗一件がどうやってルールになり、そのルールがどう行動を変えるのか、追いかけてみよう。
カレンダー照会ツールが応答を止める（タイムアウト）。あるエージェントはそのまま作業を諦めた——これが失敗記録だ。ところが同じタイムアウトに出くわした別の記録は、少し待ってからもう一度呼び出し、次のステップへ進んだ——これが成功記録だ。二つの記録を並べて見ると、分かれ道がくっきりする。ここからルールが一つ生まれる。「一時的なタイムアウトなら、短く待ってから一度だけ再試行する。ただし権限拒否や入力エラーのように、呼び直しても結果が同じになるエラーには適用せず、ただちに別の経路を探す」。
このルールが単なる「エラーが出たら再試行」と分かれるところは、ラベルだ。いつ使うか（一時的なタイムアウト）と、いつ止めるか（権限・入力エラー）を併せて付けている。こうして、でっち上げたエラーではなく実際に観測されたエラーからだけルールを抜き出して積み上げると、557の環境から1,170のルールが収められた「スキルライブラリ」ができあがる。一つのモデルではなく複数のモデルが残した記録を混ぜることで、特定モデルの思考の癖にルールが偏らないようにした。
ルールを手にしたからといって終わりではない。デプロイされたモデルは、このライブラリを参照できない。だからルールをモデルに染み込ませなければならない。三つの道筋で教える。失敗した地点まで巻き戻したうえでルールを参照して自力で続けさせ（自己省察）、そもそも立てた計画自体が間違っていたなら環境を初期状態に戻してタスクを組み直させ（スキル復旧）、ルールをユーザーの訂正メッセージに変えて、ユーザーが途中で割り込んだかのように差し込む（ユーザー中心省察）。三つの道筋いずれもルールを「参照用」にのみ使い、学習データには残さない。そうすることで、モデルは「ルールを見て直す方法」ではなく「ルールなしでも自力で復旧する方法」を身につける。
最後に、モデル自身の実行からさらに復旧を引き出す。同じタスクをきれいな環境とノイズ混じりの環境で何度も解かせたうえで、二種類のシグナルを重ね合わせる。「作業を最後まで成功させたか」は結果を教えてくれるが、どこで間違えたかは粗くしか指し示さない。「その瞬間の行動が復旧ルールに合っていたか」は何を直すべきかをピンポイントで指し示すが、作業全体の成否とはズレることがある。さっきのタイムアウトに戻ろう。「諦める」の代わりに「待ってから再試行」を選んだ側は、復旧ルールをあらかじめ見た採点で高い点を得る。その点差のぶんだけ、ルールを見ていないモデルの選択を再試行の側へ引き上げる。粗い結果シグナルと細かい行動シグナルが、互いを補正し合うわけだ。
すべての学習手法は、同じ小さなモデル（Qwen3-8B）から出発する。出発点をそろえてこそ公正な比較になる。測る能力は二つ。異なるツール環境で長い作業を最後までやり切る力、そしてノイズが混じったときに持ちこたえる力だ。比較相手は、同じサイズの省察系・環境スケーリング系のモデルたち、そして参照用に商用フロンティアモデルと29倍大きいオープンモデルだ。
この比較で測れないものもはっきりさせておこう。推論コストや応答遅延といった運用指標はここにはない。成功率は「できるか」を測るだけで、「どれだけ安く速くやるか」は測らない。（ベンチマークの一覧と平均の算式は付録に。）
この記事の出発点は「ツールが応答せず、基準が変わった瞬間」だった。その成績からまず見よう。ノイズ対応を測るAgentNoiseBenchでAgent-Reflexの総合スコアは29.1だ（アブストラクト基準）。同じサイズの環境スケーリング系・省察系のベースラインは上回った。しかし参照表のGPT-5.2（55.8）とはまだ距離が遠い。
正直に読もう。ノイズへの頑健性を引き上げたのは事実だ。その絶対水準がフロンティアに届かないのも事実だ。研究チームも付録で、AgentNoiseBenchがこの手法にとって分布外（out-of-distribution、学習時に見ていない種類の状況）だと明かしている。復旧を学習で埋め込むという発想が通用し始めたという兆しであって、ノイズ問題を解いたという宣言ではない。
ではノイズの少ない平凡な長い作業に移ろう。ここでは話が違う。
| モデル（いずれも同じ小さなモデルから出発） | 長期ツール使用の平均 |
|---|---|
| Qwen3-8B（ベースライン） | 40.2 |
| NoisyAgent-8B | 43.4 |
| Reflexion-8B | 44.7 |
| EnvScaler-8B | 50.9 |
| Agent-World-8B | 53.6 |
| Agent-Reflex-8B | 58.6 |
| 参照 — Qwen3-235B-A22B | 57.7 |
| 参照 — GPT-5.2 | 64.4 |
| 参照 — Claude-4.5-Sonnet | 72.6 |
| 参照 — Gemini 3 Pro | 72.8 |
小さなモデルが、29倍大きいQwen3-235B-A22B（57.7）を総合スコアでわずかに上回った。商用フロンティアとの差は依然あるものの、同サイズのモデルたちの中では頭一つ抜けている。ベンチマーク別でも、VitaBench 17.5%（Reflexion-8B 6.8%）、ACEBench 78.0%（NoisyAgent-8B 52.0%）、τ²-Bench 62.1%（Agent-World-8B 54.6%）と先行する。
得があがったのがどこかも覗いてみる価値がある。ACEBenchは二つを別々に測る。個々の行動一つの正確度は85.0%でベースラインとほぼ同じ。一方、一ターンの中のツール呼び出しをすべて当てたターンの割合（ターン単位の正確度）は73.3%とさらに差が開く。ただしこの73.3%は複数ターンを最後まで完走した割合ではなく、一ターン単位の正確度なので、その数字そのものを長い作業の復旧効果の直接的な証拠として読んではいけない。行動一つひとつの正確度よりも、一ターンを丸ごと取りこぼしなく埋める側で相対的な得が大きかった、という程度に読むのが正しい。
二つの成績を一つにまとめて読んではいけない。58.6は平凡なツール作業、29.1はノイズ対応——別々のベンチマークのまとまりだ。
著者が認めた限界はノイズ環境での汎化だ。その上に、私がもっと深く突き詰めたい点がある。
作業が成功したからといって、それを引き出した復旧ルールまで正しいと見なせるのか。ルールは成功記録と失敗記録の対比から分析モデルが抜き出す。ところが、ある復旧行動はその状況でたまたま通用しただけかもしれない。
同じタイムアウトの状況を二つの記録で並べてみよう。一方は再試行だけしたところ、たまたまサーバーが生き返って作業を終えた。もう一方は再試行がまた弾かれたので、別のツールへ経路を切り替えて終えた。結果ラベルはどちらも「成功」だ。だが前者を終わらせたのは復旧行動ではなく運だったかもしれない。ここで、ルールが「いつ適用されるのか」（適用範囲）と「そのルールのおかげで成功したのか」（因果）は別の問いになる。因果を見極めるには、同じ状況でその復旧行動をしたときとしなかったときを並べて比較しなければならない。その対照なしには、たまたまの成功と復旧の実際の効果を切り分けられない。ルールの正確さをどう保証するのかは、この手法が分析モデルと検証器の品質に丸ごと寄りかかっている、という事実と直結する。
現実的な制約も二つある。パイプラインが重い——557の環境を作り、9つのモデルで記録を集め、1,170のルールを抜き出し、その上に2段階の学習まで。再現コストは小さくない。ただしコード・モデル・データが公開されており、ゼロから組み直す必要は少ない。そしてルールは環境単位でインデックスされる。557のトピックの中での再利用は強みだが、まったく新しいタイプのツールエコシステムへどれだけ移植できるかは、この結果だけでは断定しづらい。
ONTLEはAIプロジェクトマネージャーを派遣型で付けるサービスだ。まずはっきりさせておくことがある。論文はモデルを再学習させて復旧を埋め込んだが、ONTLEの復旧基準は再学習ではなく、運用ロジックとプロンプトのレベルで設計される。発想は借りつつ、同じ効果がそのまま移るかどうかは別途確かめる必要がある。
さきほどの月曜のレポートをONTLEのAI PMが担ったとしよう。課題トラッカーがレートリミット（429、リクエストが多すぎて一時的に弾かれるエラー）で止まり、運用DBの照会がタイムアウトし、社長が集計基準を変える。肝心なのは、どのエラーを自動で再試行し、どの変更を人に尋ねるかが、顧客企業ごとに違うという点だ。
事例を一つ、最後まで追ってみよう。429は少し待ってから再試行する。それでも弾かれたら、キャッシュされた過去のスナップショットで代替するが、「この数値は何日基準か」を必ず表示する。ここまでは自動だ。ところが「四半期累計に変えろ」という指示は違う。照会範囲が広がればコストがかさみ、触れるデータの権限も変わる。コスト・権限・データ範囲が動く変更——これが人の確認を要する線だ。単に「計画が変わるから」ではなく、変わるものが何かで線を引く。
だから最初の一歩は一つだ。自社の中核ツールを数個に絞って二つの数字を測ること。従来の方式に比べた「復旧の後に作業を実際に最後までやり切った割合」、そして「誤った代替データを使った割合」。完走率だけを見ると、急いで誤ったデータで埋めてしまったケースを見落とす。二つの数字が一緒に出てこそ、残りの設計が意味を持つ。
論文が付けた段階の名前は、復旧ルールの発掘（RSD）、ルールを行動に変える（ReSFT）、自分自身の実行から磨く（ORPO）だ。三つの学習戦略は、自己省察（SR）・スキル復旧（KR）・ユーザー中心省察（UR）と表記される。
従来のアプローチ三つの流れの代表研究と限界は次のとおり。
| アプローチ | 代表研究 | 限界 |
|---|---|---|
| 実行中に省察する | Reflexion, Self-Refine, ExpeL | 批評が間違ったそのモデル自身から出てくるため、もっともらしいエラーをふるい落とせない |
| 失敗記録で訓練する | Agent-R, ReflectRL, LoongReflect, NoisyAgent | 復旧がその作業一回きりにとどまり、次に取り出して使えるルールとして残らない |
| 練習環境を増やす | EnvScaler, ScaleEnv, Agent-World, EnvACE / Simia, GenEnv | 環境は増やせても、失敗を復旧に変える仕掛けがない。一部はフィードバックをでっち上げるため幻覚のリスクもある |
評価ベンチマーク。長期ツール使用はBFCL-v4、ACEBench、ToolSandbox（200の層化タスク）、τ²-Bench（Barres et al.）、VitaBenchの五つで、ノイズ相互作用はAgentNoiseBench（τ²-Bench・VitaBenchのツール・ユーザーノイズ設定の上で測定）だ。総合スコアは五つのベンチマーク平均の単純平均であり、BFCL-v4とACEBenchの下位平均は各ベンチマーク公式の採点方式に従う。比較群には、省察系（Reflexion, ExpeL, Agent-R, NoisyAgent）、環境スケーリング系（Simulator, TOUCAN, AWM, EnvACE, EnvScaler, Agent-World）、軌跡レベルのRLアルゴリズム群、参照用のフロンティアモデル（GPT-5.2, Claude-4.5-Sonnet, Gemini 3 Pro）とQwen3-235B-A22Bが入る。
環境構築。Agent-Worldの方式に倣い、検索・ブラウザ・コーディング・OSツールを備えたリサーチエージェントがトピック別のデータベースを作り、コーディングエージェントがツールと単体テストを作る。コンパイルが通り、テストに合格し、状態遷移の制約と検証を満たすツールだけが残る。各環境はデータベース、検証されたツール集合、検証器（verifier、タスクがきちんと終わったかを判定する採点装置）で構成され、トピックごとに60の検証可能なタスクが付く。長い軌跡はルールベースの指標だけでは評価しづらいため、分析モデルと検証器が一緒に各軌跡へ成功・失敗のラベルを付ける。
データ収集。9つの公開ベンチマークでエージェントを走らせ、ツール返り値177,700件を集め、そのうちエラーが24,510件あった。これを表面に現れる形に応じて八つの「エラーファミリー」にまとめ、各環境のツール返り値に確率的に混ぜ、まれなエラーも復旧を学べるだけ積み上がるよう八つのファミリーのバランスをとった。軌跡は5系列・4Bから284Bにわたる9つのモデルから集めた。
学習の目的関数。結果ベースの強化学習と、トークン単位の省察誘導蒸留（on-policy distillation）を組み合わせる。一つのグループをロールアウトするとき、きれいなものと汚染されたものを別々に正規化せず、混ぜて正規化するのが肝だ。そうすることで、本物の失敗が別の対照群として切り離されず、オンポリシー分布の中に残る。ルールを見たバージョン（教師）と見ていないバージョン（生徒）のスコア差は、信頼度で重み付けしたOPD目的関数（Wu et al., 2026, SEED方式）に変換される。勾配は教師の枝には流れず生徒の枝にのみ流れ、教師が認めたトークンで生徒のスコアが上がるよう最適化される。
小さなモデルを使いたい理由はデプロイと運用の側にある。ただしこの論文は推論コストや応答遅延を直接測っていないので、「コスト対効果で有利だ」をこの研究の結論として掲げることはできない。参照に使われたQwen3-235B-A22Bは、総計235Bパラメータのうち22Bだけを活性化するMoE（専門家混合）構造なので、総サイズが29倍だからといって運用コストがそのぶん開く、と断定するのも難しい。この論文が実際に示したのは二つだ。Figure 1が示すように大きなモデルもノイズが混じれば揺れるという点、そして小さなモデルが特定環境の復旧を身につければ同サイズのモデルたちを上回り、参照表のQwen3-235B-A22Bとも競える水準に達したという点だ（成功率ベース）。
エージェントが外部ツールにつながる標準的な通路であるMCPから来ている。研究チームはSmitheryでよく使われるMCPサーバー仕様557件を環境のトピックとした。実際のデプロイでこの通路がタイムアウトやサービスエラーといったノイズを返すという点こそ、まさにこの論文が狙った現実であり、標準のMCPフォーマットで評価したという点も実際のデプロイ条件に近い。
いいえ。ルールは学習時に「参照用」にのみ使って捨てる——モデルがルールなしでも自力で復旧できるようにするのが目的だからだ。例外が一つある。ユーザーの訂正メッセージはデプロイ時にも実際に画面に見える情報なので、それだけは入力に残す。