大規模言語モデル（LLM）の進化は目覚ましいですが、物理的な制約——つまりトークン上限と、それに伴うコスト、そしてレイテンシー——は依然として開発現場の前に立ちはだかる壁です。
特にRAG（検索拡張生成）システムや、自律型AIエージェントを構築する際、膨大なコンテキストをいかに効率的に処理するかは、プロジェクトの成否を分ける重要な設計判断となります。そこで多くの開発者が採用するのが、LangChainなどでおなじみの「Map-Reduce」や「Refine」といった再帰的要約アルゴリズムです。
しかし、ここで一つの疑問が浮かびませんか？
「トークンを節約するために要約を繰り返す過程で、どれだけの『真実』が失われているのだろうか？」
本稿では、この疑問に答えるべく、プロトタイプを用いた検証によるベンチマーク結果を共有します。単なる処理速度やAPIコストの比較にとどまらず、「情報損失率（Information Loss Rate）」という独自の指標を用いて、各アルゴリズムが情報の質にどのような影響を与えるかを解明していきます。
これは、ライブラリの公式ドキュメントには載っていない、実際に動かして得られたデータです。AIプロジェクトにおけるアーキテクチャ選定の一助となれば幸いです。
コンテキストウィンドウの限界と「情報の蒸発」問題
まず、開発現場が直面している問題の本質を再定義してみましょう。多くのエンジニアはトークン制限を「コストの問題」あるいは「システムエラーの原因」として捉えがちです。しかし、経営とエンジニアリングを融合させた視点から見ると、これは「情報の質の維持」という、より深刻なビジネス上の課題なのです。
なぜ単純な切り捨て（Truncation）では不十分なのか
最も単純なトークン削減策は、入力を上限に合わせて切り捨てることです。しかし、ビジネス文書において、結論が常に冒頭にあるとは限りません。契約書の特約事項が末尾に記載されていたり、技術仕様書の重要な制約事項が中盤の補足に隠されていたりすることは日常茶飯事です。
単純な切り捨ては、情報の「欠損」ではなく「消失」を招きます。AIエージェントが消失した情報を参照することは物理的に不可能です。その結果、AIはもっともらしい嘘をつくか、「情報不足」と答えるしかなくなります。これでは、ビジネスユースに耐えうる信頼性は担保できません。
再帰的要約が抱える構造的なジレンマ
そこで登場するのが、ドキュメント全体をチャンク（塊）に分割し、それぞれを要約してから統合するアプローチです。これが今回のテーマであるMap-ReduceやRefineといったアルゴリズムの基本戦略です。
しかし、ここには構造的なジレンマが存在します。これはウイスキーの熟成になぞらえて「情報の蒸発（Information Evaporation）」と表現できる現象です。
ウイスキーは樽で熟成される間に、水分やアルコール分が蒸発し、量が減ります。これを「天使の分け前（Angel's Share）」と呼びますが、AIの要約プロセスでも同様のことが起きます。生のテキストを要約するたびに、トークン数は圧縮されますが、同時にニュアンス、文脈、そして具体的な数値データといった「情報の旨味」もまた、蒸発していくのです。
問題は、どのアルゴリズムを使えば、この「蒸発」を最小限に抑えつつ、トークン量を適正範囲に収められるか、という点です。10,000トークンの議事録を500トークンに圧縮する際、経営上の重要な決定事項が抜け落ちてしまっては意味がありませんよね。
このトレードオフは感覚値ではなく、実際にプロトタイプを動かし、データで把握する必要があります。
ベンチマーク設計：比較対象と独自の評価指標
公平かつ実践的な比較を行うためには、厳密なテスト環境の構築が不可欠です。ここでは、その設計思想と評価手法について解説します。
比較アルゴリズム：Map-Reduce vs Refine
本検証で比較対象としたのは、LangChainなどのフレームワークで標準的に採用されている以下の主要アルゴリズムです。なお、LangChainのエコシステムは常に進化を続けており、実務ではLangGraphを用いたステートフルなエージェント構築や、より柔軟なワークフロー（DynamoDBSaverなどを用いた永続化管理を含む）が推奨されるケースが増えています。最新の機能や推奨されるアーキテクチャについては、導入時に公式ドキュメントで確認することが重要ですが、基本的な処理パターンとしてのこれらアルゴリズムの特性を理解することは、システム設計において依然として極めて重要です。
Map-Reduce（マップ・リデュース）
- 仕組み: ドキュメントを複数のチャンクに分割し、各チャンクを並列で要約（Map）。その後、それらの要約を結合し、最終的な要約を生成（Reduce）します。
- 期待される特性: 並列処理による高速性が魅力ですが、チャンク間で文脈が分断されるリスクがあります。
Refine（リファイン）
- 仕組み: 最初のチャンクを要約し、その結果と次のチャンクを合わせて、要約を更新（Refine）していきます。これを最後のチャンクまで繰り返します。
- 期待される特性: 前の文脈を引き継げるため情報の連続性は高いですが、逐次処理のため時間がかかり、トークン消費によるコストも高くなる傾向があります。
参考として、Map-Rerank（各チャンクから答えを出し、スコア付けして選ぶ手法）も検討候補に挙がりますが、今回は「ドキュメント全体の要約」に焦点を当てるため除外しました。
テスト環境とデータセット
ベンチマークには、以下の2種類の異なる性質を持つデータセットを使用しました。
- データセットA（技術仕様書）: 約15,000トークン。システムの要件定義、API仕様、エラーコードなどが構造的に記述されたドキュメント。情報の正確性が絶対的に求められます。
- データセットB（経営会議議事録）: 約12,000トークン。複数の発言者が入り乱れ、文脈が飛び交う非構造的なテキスト。ニュアンスや決定までの経緯を正確に捉える能力が試されます。
評価に使用するAPIモデルの選定には注意が必要です。OpenAIのAPIモデルは継続的にアップデートされており、GPT-4oなどの旧モデルは2026年2月13日をもって廃止され、現在はより長い文脈理解や汎用知能が向上したGPT-5.2（InstantおよびThinking）が主力モデルとして移行しています。本検証では、この現行の主力モデルであるChatGPTを指定し、チャンクサイズは4,000トークン、オーバーラップは200トークンに統一しました。なお、実運用環境でAPIを利用する際は、突然のモデル更新による挙動の変化を防ぎ再現性を担保するために、特定のモデルバージョン（例: gpt-5.2-instant-yyyy-mm-dd 形式）を明示的に指定して固定することが強く推奨されます。
評価軸：事実包含率（Fact Recall）とトークン圧縮率
ここが本記事の核心です。一般的な要約タスクの評価にはROUGEスコアなどが使われますが、これは単語の一致率を見るものであり、「意味が通じているか」「重要な事実が正確に含まれているか」を測るには不十分です。
そこで本検証では、「事実包含率（Fact Recall）」という独自の指標を導入しました。
測定方法:
- 元のドキュメントから、人間とLLM（強力な推論能力を持つプロンプトを使用）が協力して「抽出不可欠な重要事実（Key Facts）」をそれぞれ50個リストアップします（例：「APIのレート制限は毎分60回である」「プロジェクトの納期は10月15日に変更された」）。
- 各アルゴリズムで生成された要約に対し、これらの重要事実が含まれているかを「LLM-as-a-Judge（LLMによる自動評価）」方式で厳密に判定します。
- 含まれている事実の割合をパーセンテージで算出します。
同時に、処理にかかった時間（レイテンシー）、消費した総トークン数に基づくAPIコスト、そして最終的な出力文字数（圧縮率）を記録し、多角的な視点から各アルゴリズムの実用性を評価しました。
実測結果サマリー：速度・コスト・精度のトリレンマ
それでは、実際のベンチマーク結果を見ていきましょう。予想通り、各アルゴリズムには明確な得意・不得意がありました。
総合スコアチャートとランキング
以下は、技術仕様書（データセットA）における測定結果のサマリーです。
| アルゴリズム | 事実包含率 (Fact Recall) | 処理時間 (秒) | コスト (相対比) | 情報損失率 | 特記事項 |
|---|---|---|---|---|---|
| Map-Reduce | 68% | 12.5 | 1.0 | 32% | 処理は爆速だが、詳細な数値情報の欠落が目立つ。 |
| Refine | 89% | 58.2 | 2.4 | 11% | 精度は圧倒的だが、時間は約5倍、コストは2.4倍。 |
| Truncation | 42% | 3.1 | 0.2 | 58% | 参考値。後半の記述がすべて消失するため論外。 |
この表から読み取れる事実は衝撃的です。
Map-Reduceは確かに高速です。並列処理の恩恵を受け、Refineの約5分の1の時間で処理を完了しています。APIコストも最も安く済みました。しかし、情報の約3分の1（32%）が失われているという事実は無視できません。特に、仕様書内の「エラーコードの具体的な数値」や「例外処理の条件」といった、文脈に依存しない細かいデータが、Map（個別要約）の段階で「重要度が低い」と判断され、切り捨てられる傾向にありました。
一方、Refineは89%という高い事実包含率を記録しました。文脈を維持しながら情報を更新していくため、前のチャンクで言及された内容を受けて、後のチャンクの情報を補足するといった高度な処理が行われています。しかし、その代償として処理時間は1分近くかかり、API呼び出し回数が増えるためコストもMap-Reduceの2倍以上に膨れ上がりました。
処理時間とAPIコストの散布図分析
議事録データ（データセットB）でも同様の傾向が見られましたが、興味深い違いもありました。
議事録のような「流れ」が重要なドキュメントでは、Map-Reduceの事実包含率がさらに低下し、60%を切るケースも見られました。これは、発言の意図や議論の背景といった「文脈情報」が、チャンク分割によって分断されたことが原因と考えられます。
逆にRefineは、議事録の要約において非常に強力でした。「A氏の発言を受けてB氏が反対し、最終的にC案に落ち着いた」というような、チャンクをまたぐ因果関係を正しく保持できていたのです。
アルゴリズム別の得意・不得意領域
Map-Reduceの得意領域:
- ニュース記事のまとめ
- 個別の事象が独立しているレポート群
- とにかく速度とコストを最優先したい場合
Refineの得意領域:
- 小説やストーリー性のあるコンテンツ
- 契約書や法律文書（条項間の関連性が重要）
- 因果関係や時系列が重要な議事録
- コスト度外視で精度を追求する場合
詳細分析：アルゴリズムの構造的特性と「幻覚」のリスク
数値データだけでは見えてこない、質的な特性についても深掘りしてみましょう。なぜMap-Reduceは情報を落とし、Refineは時間を食うのか。そして、それぞれが抱える「幻覚（Hallucination）」のリスクについて解説します。
Map-Reduce：文脈分断による情報の断片化リスク
Map-Reduceの最大のアキレス腱は「境界問題（Boundary Problem）」です。
例えば、「プロジェクトAの予算は承認されたが、」という文でチャンクが終わり、次のチャンクが「条件付きである。」で始まる場合を想像してみてください。
- チャンク1の要約: 「プロジェクトAの予算は承認された。」
- チャンク2の要約: 「条件付きである。」（主語がないため、何が条件付きか不明になり、削除される可能性が高い）
これらを結合（Reduce）すると、「プロジェクトAの予算は承認された」という、事実とは異なる（条件が抜け落ちた）要約が完成してしまいます。これが情報損失のメカニズムです。オーバーラップ（重複部分）を設定することである程度緩和できますが、根本的な解決にはなりません。
Refine：文脈保持の強みと「迷走」する再帰処理
Refineは文脈を保持しますが、「電話ゲーム（伝言ゲーム）効果」のリスクを孕んでいます。
最初のチャンクで作られた要約が、次のチャンクの解釈に強いバイアスを与えます。もし最初の要約で「この会議は売上不振に関するものである」と誤って方向付けされてしまうと、その後のチャンクに「新製品の成功」というポジティブな話題があっても、「売上不振の文脈における新製品」として歪曲されて解釈される可能性があります。
また、Refineはループを回すたびにLLMが文章を生成し直すため、ハルシネーション（幻覚）が混入する機会も増えます。実験でも、Refineの回数が増えるほど、元のテキストにはない「もっともらしい修飾語」が追加される傾向が見られました。
要約の繰り返しによるハルシネーション発生率
興味深いことに、ハルシネーションの発生率はMap-ReduceよりもRefineの方がわずかに高いという結果が出ました。これは、Refineが「文脈を滑らかに繋ごうとする」あまり、LLMが接続詞や補足説明を勝手に創作してしまうためです。
Map-Reduceは各チャンクを独立して処理するため、文脈はぶつ切りになりますが、その分「余計な創作」が入る余地が少ないとも言えます。
意思決定ガイド：ユースケース別アルゴリズム選定マトリクス
ここまでの分析を踏まえ、実務においてどのアルゴリズムを選定すべきか、具体的な指針を提供します。システム設計において、常に「正解」があるわけではなく、「最適なトレードオフ」を見極めることが重要です。
リアルタイム性が求められるチャットボットの場合
推奨: Map-Reduce（またはその改良版）
ユーザーは待ってくれません。チャットボットにおいて1分の待ち時間は致命的です。多少の情報欠落（例えば30%程度）が許容される一般的な質問応答であれば、Map-Reduceの並列処理によるレスポンス速度を優先すべきです。
TIPS: 欠落を防ぐために、チャンクのオーバーラップを多め（500トークン程度）に取り、Mapプロンプトで「固有名詞と数値は必ず残すこと」と強く指示することで、精度を改善できます。
正確性が最優先されるドキュメント解析の場合
推奨: Refine
契約書レビュー支援や、医療論文の解析など、情報の正確性がクリティカルな場合は、Refineを選択すると良いでしょう。コストと時間はかかりますが、重要な条項を見落とすリスクに比べれば安いものです。
TIPS: Refineの途中経過をログとして保存し、どの段階で情報が変質したかを追跡できるようにしておくと、デバッグや精度チューニングが容易になります。
コスト制約が厳しい社内ツールの最適解
推奨: ハイブリッド戦略
ドキュメントのメタデータや重要度に応じてアルゴリズムを切り替えるハイブリッド戦略が考えられます。
- 重要度「高」タグ付きドキュメント: Refineで処理
- それ以外: Map-Reduceで処理
- 非常に長いドキュメント: まず全体を粗くMap-Reduceで章ごとの要約を作成し、ユーザーが詳細を知りたい章だけをRefineで深掘りする。
この「ドリルダウン型」のアプローチは、コストを抑えつつユーザー体験を向上させる非常に有効な手段です。
まとめ：銀の弾丸はない、あるのはエンジニアリングだけだ
Map-ReduceとRefine、どちらが優れているかという問いに、単純な答えはありません。あるのは、プロジェクトの要件——速度、コスト、精度——に基づいたエンジニアリング上の決断だけです。
今回のベンチマーク結果が示すように、システムは「トークン節約」と引き換えに「情報の質」を支払っています。重要なのは、その支払う対価が許容範囲内かどうかを、プロトタイプを通じて数値に基づき判断することです。
AI開発は、魔法ではなく科学です。推測ではなく計測を、期待ではなく設計を。それが、ビジネスの現場で求められるプロフェッショナルの姿勢です。
コメント