LLMエージェントを企業システムと連携させると、ツール応答の履歴が膨らみコストと失敗率が読めなくなります。ただし、全履歴を渡さず「直近数回＋要約」だけに絞ると、完了率もトークン量も同時に改善する余地があります。
本記事では、Microsoftの研究チームが2026年6月8日にarXivで公開した『Less Context, Better Agents: Efficient Context Engineering for Long-Horizon Tool-Using LLM Agents』(Abhilasha Lodha、Mahsa Pahlavikhah Varnosfaderani、Abir Chakraborty、Abhinav Mithal、arXiv:2606.10209)を取り上げます。要点、実験結果、限界を整理し、日本企業がツール使用型AIエージェントを本番に載せる際の判断材料を解説します。
要点1: 全履歴を渡すほど賢くなるという直感は成り立たない。全会話履歴を渡した構成では完了率は71.0%に留まり、コスト面でも148万トークン・14.56時間を消費していました。
要点2: 直近5回のツール呼び出しに絞るだけでも、完了率は79.0%に上がり、トークン量は約1/3に落ちます。履歴の重みを取り除くことが精度改善に直結する場面がある、というのが論文の中心主張です。
要点3: そこに「削除される会話の要約」を挟むと、完了率は91.6%、金額の明細化率は99.64%まで伸びました。要約による軽い記憶が、選別的な保持と両立する設計です。
LLMエージェントは本番システムに接続すると、ツール応答が数百〜数千トークン規模で戻ってきます。会話履歴を全て抱えたまま推論すると、コンテキストが溢れ古い状態を参照してしまう問題が起きます。
論文は、Microsoft Dynamics 365 Finance and Operations(D365 F&O)への経費明細化を題材にこの課題を検証しました。ホテル領収書1件を23種類の副カテゴリに正しく割り振り、残額をちょうど0円に合わせる必要があります。
冗長な履歴を持たせるほど、モデルが「既に処理した明細」を再処理したり、古い金額に引きずられて失敗します。エージェントを本番に載せた企業が最初にぶつかる、実務そのままの現象です。
直感は明快で、必要なのは全履歴ではなく「直近の状態＋古い出来事の要約」だという設計です。長い会話をそのまま渡すより、モデルが読むべき情報だけに絞ります。
技術要点はAlgorithm 1に整理されています。
要約は専用の圧縮モデルや学習済みモジュールではなく、標準的なLLMを1パス回しているだけです。特別なアーキテクチャ変更は要らないため、既存のエージェント基盤にも移植しやすい構成です。
既存手法との差は「何を残すか」の考え方にあります。従来のツール応答削減は「古い応答から順に切る」だけでした。提案手法は「切る前に要点を残す」ため、履歴の連続性が壊れにくくなります。
対象はホテル経費50件、モデルはGPT-5(検証用にClaude Sonnet 4.5)、5回の独立実行の平均です。ユーザー役の対話にはGPT-4.1が使われています。
| 構成 | 完全明細化率 | 金額明細化率 | トークン合計 | 総実行時間 |
|---|---|---|---|---|
| C1: ユーザーモデルなし | 8.0% | 未報告 | 未報告 | 未報告 |
| C2: 全履歴保持 | 71.0% | 未報告 | 1,480,996 | 14.56時間 |
| C3: 直近5回のみ | 79.0% | 未報告 | 535,274 | 5.39時間 |
| C4: 直近5回＋要約 | 91.6% | 99.64% | 553,374 | 5.79時間 |
読み方は3つあります。1つ目は、C2からC3で「情報を減らしたのに精度が上がっている」点です。エージェント運用では「持たせすぎ」が精度低下の主因になり得ることを示しています。
2つ目は、C3からC4でトークン量がほぼ横ばい(535kから553k)のまま完了率が12.6ポイント伸びていることです。要約を挟むコストは、実務上ほぼ無料と見てよい水準です。
3つ目は、金額の明細化率99.64%です。件数ベースの完了率91.6%とセットで見ると、部分的にでも金額が合っている割合が非常に高く、後段の人手レビューが軽くなります。
著者は結論で「特定の企業ツール使用ワークフローに対する強い証拠であり、普遍的な一般化ではない」と明記しています。この位置づけを守って読む必要があります。
具体的な限界は次のとおりです。
実務側の注意も分けて整理します。要約LLMが誤った要約を出せば、下流の判断も引きずられます。要約プロンプトの品質と、要約後の状態確認の両方に設計コストがかかります。
また、要約を挟むこと自体は「監査ログとして何が消えたか」を曖昧にします。金融、経費、契約など後追いが必要な業務では、要約の元履歴を別途保管する運用が要ります。
企業のエージェントを本番に載せる前に、次の5点を確認するのが現実的です。
論文が示す91.6%という数字は、コンテキスト設計を丁寧に詰めた結果です。同じ数字を他業務で狙うより、「全履歴保持を捨てる」判断を先に置き、要約設計を業務ごとに磨く方が現実的です。
要約に使うLLMは、必ずしも本推論と同じ最上位モデルにする必要はありません。要約は短く、失敗の影響も本推論より軽いため、コスト面ではより安いモデルを選ぶ余地が広いです。
この論文の価値は、エージェント設計論を「モデル選び」から「コンテキスト設計」に引き戻したことにあります。日本企業でも同じ順序で議論すべき論点です。
Blackfordがエージェント導入を支援する場面でも、最初にぶつかるのはモデル選定ではなく、既存業務システムのツール応答の粒度です。SAP、Oracle NetSuite、freee、マネーフォワードなど、応答が数千トークン単位で戻る場面は多く、そのままLLMに流すと今回の論文と同じ現象が起きます。
BlackfordのAI開発支援サービスでは、ツール応答の圧縮設計、要約プロンプトの業務別テンプレート、監査用ログ保管の3点をまとめて設計する進め方をご提案しています。データ活用基盤側の整理はDataRoidで支援します。
論文の91.6%という数字を営業文句として輸入するのではなく、自社ワークフローで「どの構成なら再現できるか」を設計するのが、本番運用側の現実解です。
Q. Less Context, Better Agentsは日本語で読めますか？
A. 論文本文は英語のみで、日本語版は2026年7月時点で公式には公開されていません。原文はarXiv:2606.10209から無料で読めます。
Q. 直近5回、要約対象3回という数字は自社でも同じにするべきですか？
A. 論文もこの2値は「固定値」であり、他タスクへの適応化は将来課題としています。自社ワークフローでは、ツール応答のトークン量と業務手順の長さから調整する前提で検討してください。
Q. 提案手法はコード付きで公開されていますか？
A. 論文本文には再現手順と統計計算スクリプトの説明がありますが、公式なコードリポジトリのURLは明示されていません。実装は各社側で行う必要があります。
Q. Claude Sonnet 4.5でも同じ結果になりますか？
A. 論文でも検証モデルとして触れられていますが、主結果はGPT-5での計測です。他モデルでの再現性は今後の検証項目とされています。
Q. Model Context Protocol以外のツール連携でも効きますか？
A. 本論文はModel Context Protocol経由のツール応答を前提としていますが、コンテキスト膨張の構造自体はHTTP APIや独自コネクタでも共通します。同じ設計思想は移植可能です。
Less Context, Better Agentsは、エージェント本番運用の勝ち筋が「モデルを賢くする」より「渡す情報を減らす」側にあることを、Microsoft社内の実業務ベンチマークで示した論文です。完了率91.6%、金額明細化率99.64%という数字は、コンテキスト設計を丁寧に詰めた結果として重い意味を持ちます。
ただし、対象タスクとモデルは限定的で、要約プロンプトの品質、監査ログの扱いなど、本番導入に固有の設計コストは残ります。自社エージェントに落とし込む際は、ツール応答の粒度と業務手順の長さから、保持数と要約設計を業務ごとにチューニングする前提で計画してください。
