ICML 2026で分かった本番エージェント86システムの「地味な設計」という解

Ai Workforce 事業部で、R&D グループのリサーチ・エンジニアをしている平澤（@toshohirasawa）です。

プロダクトを作っていると、エージェントに自分で計画を立てさせ、使える道具を増やし、人に確認せず進める範囲を広げる方向へ、つい手が動くものです。7 月上旬にソウルで開かれた機械学習の国際会議 ICML 2026 へ「もっと賢いエージェントの作り方」を探しに行ったつもりでした。ところが、現地で聴いた中でいちばん頭に残ったのは、世界で稼働する本番エージェント 86 システムを調べた研究でした。そこに成功パターンとして並んでいたのは、追加学習をしない・人が確認するまでの自律ステップを 10 未満に抑える・事前に決めた手順に沿わせる、という驚くほど地味な設計です。

この記事は、その「地味さ」の正体をたどる報告です。評価・記憶・安全性の 3 つの領域で、同じ向きの変化が起きていました。設計への持ち帰りまでまとめます。

1. なぜ、この 3 領域だけを追ったのか

Ai Workforce は、企業の業務に合わせてワークフローや道具を組み合わせて使う、法人向けの AI エージェントのプラットフォームです。ここ数か月で使える機能が増え、実際の業務に載せる場面も出てきました。そうなると、作っている側の関心は「もっと賢くできるか」の先へ移ります。

任せた仕事が本当に終わったかどうかを、どうやって確かめるのか。何度もやり取りする案件の文脈を、どこにどう持たせるのか。手元の文書を検索できるようにしたとき、誰に何まで読ませてよいのか。

どれも、モデルを賢くすれば消える問いではありません。1 つめは、うまくいったかどうかを誰がどう決めるのかという評価の話。2 つめは、必要な文脈をどこからどう供給するか。記憶も検索もデータベースもここに入ります。3 つめの安全性で気になっていたのは、モデルそのものより、その周りに置いた仕組みのほうでした。

2. 本番のエージェントは、驚くほど「地味」に作られていた

論文: Measuring Agents in Production、TG-RAG: A Retrieval-Augmented Framework for Reasoning Guidance in Specialized Domains

本番の LLM（大規模言語モデル）エージェントがどう作られているかを一次データで調べた、最初の報告です。20 件の詳細インタビューと 306 名へのアンケートから、本番・パイロット段階の 86 システム（26 業種）を分析しています。

見えてきた姿は、一貫して「簡潔さと制御」に振れていました。

ひとつ補っておくと、「7 割が追加学習をしていない」は「3 割はしている」でもあります。追加学習が消えたのではなく、まず試す既定の手段ではなくなった。そういう順序の話として捉えるのがよさそうです。

面白いのは理由のほうでした。追加学習を避けるのは技術力の問題ではなく、そのほうがモデルが更新されても壊れにくく、開発サイクルも速いからです。最大の壁は能力ではなく信頼性で（38% で首位）、その解決策もアルゴリズムではなく、読み取り専用で動かす・隔離環境に置く・権限を役割ごとに絞る、というシステム設計の側にありました。

2.1. 人の確認は、どういう条件なら外せるのか

「人の確認が支配的 74%」は、裏返せば「まだ外せていない」という報告でもあります。では、外せている残りは何をしているのでしょうか。

人の確認を使っていないチームも、評価をしていないわけではありませんでした。本番で動いている 31 件のうち、人の確認を使わないのは 8 件。論文の併用表から数え直すと、そのうち評価手法を 1 つも持たないのは 1 件だけでした。残りの 7 件は、ルールでのチェックや、別のデータとの突き合わせで回しています。

人の確認を使わないのは、速い自動判定が効く領域です。論文は「コーディングエージェントは、コンパイルとテストで検証できる稀なケース」と書いています。分かれ目は業界でも規模でもなく、正しさを機械が数秒で判定できるかでした。判定できないなら、人の確認が必要になります。

真似できそうなのは、機械の判定を合否ではなく仕分けに使うアプローチです。聞き取りをした 20 件では、LLM を採点役に使うチームはすべて人のレビューと併用していて、単独運用はゼロでした。確信度の低いものを専門家へ回し、高いものからも一定の割合を抜き取って確認し続ける。採点役が壊れたときに気づく仕掛けを残しているのが肝です。

2.2.「手順に沿わせる 80%」は、設計思想の選択ではなかった

この 80% の中身も意外でした。論文は「既存の業務プロセスをエージェントのワークフローに写しているのであって、完全に自律的な AI の働き手を作っているのではない」と書いています。保険査定のエージェントが固定の順序なのは、査定業務がその順序だからです。裏を返すと、「うちの業務は、もう手順として書けているか」が先に問われます。

では、書けていれば済むのでしょうか。今年の口頭発表にあった TG-RAG という研究は、それでは済まないと言っています。手順書を文書やスクリプトの形で渡しても、強制力のない提案にすぎず、モデルは長い推論の途中で逸脱していくからです。

TG-RAG は手順書を分岐つきのオートマトン（状態遷移の仕組み）に落とし、モデルが 1 つの判断を書き終えた瞬間に推論エンジンのレベルで生成を止めて、次の工程の指示を差し込みます。同じ指示でも、プロンプトに書くか推論の途中に差し込むかで 12 ポイント変わりました。「要するにワークフロー化では」と読めますが、既存のワークフローエンジンとの差が 2 つあります。手順を推論の外側ではなく途中に差し込むこと。そして強制しているのが「選択肢」であって「選択」ではないこと（どの分岐を通るかはモデルが決めます）。全部をワークフローで書き切ることの代わりではなく、判断が残る工程にだけ手順を効かせる道具として使うわけです。

ここまでの数字にも割り引きが要ります。86 システムを調べた研究の「成功」は「本番に到達したこと」だけを指していて、投資対効果も継続率も測っていません。途中で止まった案件との比較もないので、「簡潔にしたから成功した」という因果は示せていません。

3. 記憶・検索・データベースが、ひとつの基盤に合流している

論文: AMA-Bench: Evaluating Long-Horizon Memory for Agentic Applications、HGMem: Hypergraph-based Working Memory to Improve Multi-step RAG for Long-Context Complex Relational Modeling

2 つめの「案件の文脈をどこに持たせるか」という問いに当たる領域です。

文書の検索も、過去のやりとりの記憶も、データベースの参照も、これまでは別々の機能として研究されてきました。今年は、ひとつの基盤に合流しています。

いまのエージェントの記憶は、多くが「記録を貯めておき、似たものを検索して思い出す」方式です。今年の評価研究（AMA-Bench）は、これが長期のタスクでは「履歴を全部そのまま読み込む」素朴なやり方にしばしば負ける、と報告しました。原因は 2 つで、貯めた記憶が事実の断片のままで出来事どうしの関係が失われること、そして検索が「似ているもの」しか思い出せないことです。

また、モデルのスケールアップがタスク性能にあまり効かないという報告もありました。同じ記憶方式のまま土台のモデルを Qwen3-8B から Qwen3-32B に上げても、スコアは平均 +0.038 しか改善しないのに対して、記憶の設計を変えると 0.45 の差が出ます。あとで出てくる HGMem も、中型の公開モデル（Qwen2.5-32B）で、GPT-4o を使う既存手法に並んでいます（62.22 対 61.48）。記憶の設計を比べている段階では、モデルの大きさがほとんど情報を持たない。 賢さではなく設計が差を作る。最初の 86 システムの調査と似た傾向が報告されています。だとすれば、大きなモデルで少数回試すより、小さいモデルで試行回数を稼いだほうが、同じ予算で設計の良し悪しが分かりそうです。

その HGMem は、記憶を検索するだけでなく「統合」する操作を足した研究です。ばらばらの記録から「この複数の出来事はつながっている」という関係そのものを、新しい記憶として作ります。たとえば長い物語で、序盤の登場人物と終盤の出来事のつながりを問われても、似た文書の検索では拾えません。

一方で、HGMem には、忘れる操作がありません。足す・書き換える・統合するの 3 つだけです。それで困らないのは、セッションが終わったら記憶を全部捨てる設計だからです。全部捨てるなら、いつ忘れるかを決める必要はそもそもありません。ただ、案件をまたいで記憶を貯め続けるつもりなら、その「いつ忘れるか」を、今度は自分たちで決めることになります。

といっても、忘れ方のルールを人が書き切れるとは限りません。「捨てなければ解けたのに、捨てたら解けなかった」失敗例を集めて、捨て方を決める指示文のほうを直していく研究（ACON）も出てきました。そして「いつ忘れるか」は今年、安全性の問題としても立ちました。長く覚えているだけで、別の案件の情報が混ざったり、過去のやりとりに引きずられたりする。その害を測るベンチマーク（PersistBench）が出ています。

4. 攻撃される場所が、モデル本体から仕組み全体へ移った

論文: Towards Whole-corpus Reconstruction of Heterogeneous RAG Knowledge Bases

3 つめは、誰に何まで読ませてよいのか、でした。

これまでの AI 安全は「モデルに変なことを言わせない」が中心でした。今年狙われていたのは、検索の知識ベース、長期記憶、ツール接続といった周辺部分です。

なかでも考えさせられたのが、「問い合わせの窓口しか触れない相手は、知識ベースの中身をどこまで復元できるか」を測った研究でした。想定しているのは外部からの侵入者ではなく、検索は投げられるけれど全文書を見る権限はない立場の人です。たとえば、社内の質問応答ボットは使えるけれど、その裏の文書庫を開く権限までは持たない社員や、委託先のメンバーです。狙うのは 1 件の文書ではなく、知識ベース全体の復元です。

4 つの分野が混ざった設定で復元率は 45〜49%（従来の最良は約 20%）、8 分野でも 32.3% でした。検索側で試された 3 種類の防御では、この数字がほとんど落ちません。

もっとも効果的な対策は、検索が触れる範囲を利用者ごとの最小権限に絞ることになりそうです。読み取り専用・隔離・権限を絞るという、最初の研究で見た地味な設計と同じような答えです。といっても、全文書をわざわざ誰でも検索できるようにしている会社は、まず無いはずです。現実に危ないのは、文書そのものには閲覧制限があるのに、検索の索引がそれを引き継いでいない構成です。文書を開く権限と、検索で断片を引き出せる権限は、意識して揃えないと別々に管理されがちです。

しかも、この攻撃は、どこを既に調べたかを覚えてすらいない素朴なやり方で 3〜5 割に届いています。3〜5 割は性能の上限ではなく下限と考えて、リスクの見積もりをこの数字に縛られないほうがよさそうです。

論文の側にも制約があります。題名にある「全体復元」は達成ではなく方向の宣言で、問い合わせを増やしても過半の断片は復元できません。復元率という指標も、その断片が一度でも検索されたかを数えているだけで、原文どおりに吐き出せたかは測っていません。試された防御も、検索の段階に偏っています。

5. 3 つに共通していたのは「評価の作り直し」だった

そもそも、冒頭の「地味さ」が見えたのも、ベンチマークの点数ではなく、本番の実態を一次データで測り直した研究があったからでした。3 つの領域はどれも、こうした測り直しに行き着いています。記憶は作業の軌跡で、守れているかは攻撃の側から。根っこにあるのは、「測り方が現実に追いついていない」という同じ問題です。

物差し自体が壊れうる、という報告もまとまって出ていました。ソフトウェア開発の課題で測る SWE-Bench Pro は、上位モデルの通過率が 8 か月で 23.3% から 80.3% へ急伸しています。その急伸を受けた OpenAI の監査では、公開分 731 課題の約 30% が壊れている（正しく解いても不合格、不完全でも合格）と判定され、以前出ていた推奨は撤回されました。

6. おわりに

持ち帰りを 3 つ並べると、こうなります。成功している本番エージェントは「地味な設計」に収束している。記憶は貯め方・忘れ方・育て方まで含めて設計する。検索できる知識ベースは、入れた時点では守られていない。

どれも、伸びしろが「モデルをもっと賢くする」以外の場所にある、という話でもあります。

突き詰めると、3 つとも「エージェントが 1 桁増えたときに、現在の仕組みで維持できるのか」という問いに行き着きます。「人の確認 74%」は、いま一番効いている方法論であると同時に、数が増えたときに真っ先に回らなくなる方法論でもあります。だから「どういう条件なら外せるのか」を問う意味がありました。

信頼性の問題は 2 段あります。何をどう測れば「信頼できる」と言えるのかが定まっていないこと。そして方法論がある場面でも、それをスケールさせる手立てがないこと。前者は「定まっていない」と言い切るより、作りにいく段階に入った、と言うほうが観測と合いそうです。

私たちが作っているのは、企業の業務を任せられるエージェントです。だから、今年持ち帰ったもののなかで価値があったのは、新しい手法よりも、どこまでを機械に任せ、どこから人に戻すかの線の引き方でした。まだ答えを持っていないのは、判定を機械に寄せられない側に残る業務のほうです。そこは人の確認を減らす話ではなく、確認の質を上げる話になるはずです。今年見えた線の引き方を足場に、この答えを自分たちのプラットフォームの上で作っていきたいと思います。

EVENT

AIカンファレンス「Bet AI Day 2026」開催概要

開催日時

2026年9月3日（木）12:00 開演

開催方法

オンライン配信

参加費用

無料（事前申込制）

connpass でお申し込み