長文ドキュメントのLLM要約設計パターン｜stuff・map-reduce・refine・抽出ハイブリッドの使い分け

「3時間の会議ログを要約して」「200ページの仕様書の変更点をまとめて」という依頼は、LLMを業務に組み込むとほぼ必ず出てきます。短い議事録なら丸ごと投げれば済むのに、長くなった途端に要点が抜ける、日付や金額が違う、後半の話ばかり書かれる、といった崩れ方をする。この記事では、長文要約で使われる代表的な4つの設計パターンと、その使い分け、精度が落ちる境目、そして「うまくいっているか」をどう測るかを、実装判断に使える粒度で整理します。

なぜ「全部そのまま投げる」が長文で崩れるのか#

まず、長文を一括で投げたときに何が起きているのかを分解します。原因は一つではありません。

入力上限だけの問題ではない#

最も分かりやすいのはコンテキストウィンドウの上限です。入力が上限を超えればAPIはエラーを返すか、ツール側で切り詰められます。ただし、上限に収まっていれば安心かというとそうではありません。

長い入力の中で情報の位置が精度に影響することは、査読論文でも報告されています。Liuらの「Lost in the Middle: How Language Models Use Long Contexts」(TACL 2024)は、複数文書QAとkey-value検索という2つのタスクで、関連情報の位置を変えると性能が大きく変わることを示しました。同論文は「性能は関連情報が入力コンテキストの先頭または末尾にあるときに最も高くなることが多く、長いコンテキストの中間にある情報へアクセスしなければならない場合には著しく低下する。これは明示的に長コンテキスト向けとされたモデルでも同様である」と述べています。

指示が薄まる#

長い本文の中に指示を埋めると、指示が相対的に埋没します。Anthropicの公式ドキュメントは、大きな文書やデータ量の多い入力(20k+ トークン)を扱う際の推奨として、長い文書や入力をプロンプトの上部、つまりクエリ・指示・例示より前に置くことを挙げています。同ドキュメントには「クエリを末尾に置くことで、複雑な複数文書入力では特に、テストにおいて応答品質が最大30パーセント向上し得る」という注記もあります。指示を先頭に書いて長文をその後ろに続ける書き方は、直感的ですが不利になり得るということです。

出力側の上限で切れる#

見落とされがちなのが出力トークン上限です。入力が10万トークンあっても、出力上限を超える長さの要約は作れません。「網羅的にまとめて」と頼んだ結果、途中で文章が切れる、あるいはモデルが自発的に圧縮して重要事項を捨てる、という形で現れます。上限値はモデルとAPIによって異なるため、実装前に使用するモデルの公式ドキュメントで確認し、必要なら要約を分割生成する設計にします。

4つの基本パターン#

長文要約の実装は、突き詰めると次の4系統に整理できます。フレームワークによって呼び名は違いますが、考え方は共通です。

1. 一括投入(stuff)#

全文を1回のプロンプトに入れて、そのまま要約させる最も単純な方法です。LlamaIndexの応答モードでいえば、全テキストを1プロンプトに収まるよう切り詰めるsimple_summarizeが近い位置づけで、公式ドキュメントでも「詳細が失われる可能性はあるが手早い要約に適する」と説明されています。

仕組みが単純なので、文書全体の関係性(冒頭の前提が末尾の結論にどう効いているか)をモデルが直接見られるのが最大の利点です。API呼び出しは1回で済み、レイテンシもコストも読みやすい。

向くのは、コンテキストウィンドウに余裕をもって収まる長さの単一文書です。1時間程度の会議の文字起こし、数十ページの報告書などは多くの場合これで足ります。

向かないのは、上限を超える文書と、上限内でも「網羅性」が強く求められる文書です。全体を一度に見せると、中間の細部が薄まり、モデルが目立つ話題に引っ張られやすくなります。典型的な失敗は、会議の後半で決まった結論だけが書かれ、前半の懸案が消えるパターンです。

2. map-reduce(分割して要約 -> 要約の要約)#

文書をチャンクに分け、チャンクごとに要約を作り(map)、その要約群をまとめて最終要約を作る(reduce)方法です。Anthropicの法務要約ガイドでも、コンテキストウィンドウを超える場合の手法として、文書を扱いやすいチャンクに分けて個別に処理し、各チャンクの要約を統合してメタ要約を作る「meta-summarization」が紹介されています。

最大の利点は並列化です。Google Cloudのブログは、map/reduceとiterative refinementを比較して「refinementでは次のセクションが直前の改良済み要約を使って要約されるため逐次処理になる。map/reduceでは各セクションの要約を並列に作れる(mapの操作)ため、逐次のアプローチより速い」と説明しています。文書が長いほど、この差はそのまま体感時間の差になります。

向くのは、章立てされた長文、複数文書の横断要約、そしてバッチで大量に処理したいケースです。

向かないのは、チャンクをまたいだ関係が要点になる文書です。「Aさんが提案 -> 別の章で否決」のような遠く離れた対応関係は、チャンク単位の要約で片方が落ちると復元できません。また、reduceの入力が長くなりすぎると、そこで再び長文問題が発生します(中間要約をさらに畳み込む段階的な縮約が必要になります)。典型的な失敗は、各チャンク要約が同じような一般論に丸まってしまい、最終要約が「会議では活発な議論が行われました」レベルの無味な文章になることです。

3. refine(逐次改良)#

最初のチャンクで要約を作り、次のチャンクとこれまでの要約を渡して更新する、を繰り返す方法です。LlamaIndexの公式ドキュメントはrefineモードを「取得した各テキストチャンクを順に処理して回答を作成・改良する。ノード/取得チャンクごとに個別のLLM呼び出しを行う」と説明しています。

利点は、直前までの文脈を持ったまま次を読むため、詳細が残りやすいことです。BooookScore論文(ICLR 2024)は、書籍長文書の要約を「チャンク要約を階層的にマージする方式」と「running summaryを逐次更新する方式」で比較し、「逐次更新は階層マージより一貫性スコア(BooookScore)は低いが詳細度は高く、このトレードオフはアノテーターに好まれることもあった」と報告しています。詳細を取るか一貫性を取るかという選択が、実測で示されている点は実務でも参考になります。

向かないのは、レイテンシに厳しい用途と、順序バイアスを避けたい用途です。呼び出しは必ず直列になるので、チャンク数に比例して時間がかかります。また後半のチャンクほど最後の更新に効きやすく、「最後に話した人の意見が要約の主役になる」という偏りが出ます。長い会話ログのように後半が雑談で終わる文書では、この偏りが露骨に出ます。

4. 抽出+生成のハイブリッド#

先に「重要そうな箇所」を機械的に絞り込んでから、絞ったテキストだけで生成する方法です。絞り込みには、検索クエリによる取得(RAG的アプローチ)、埋め込みでクラスタリングして各クラスタの代表チャンクだけを使う方法、ルールベースの抽出(決定事項・アクションアイテム・数値行だけ抜く)などがあります。

利点は、入力量を大きく減らせるためコストとレイテンシが下がり、かつ「どこを見て書いたか」が明示できることです。要約の観点が事前に決まっている業務要約(契約書のレビュー、定例議事録の決定事項抽出)と相性が良く、LlamaIndexのtree_summarizeのような階層的な畳み込みと組み合わせることもできます。

向かないのは、観点が事前に決まっていない探索的な要約と、網羅性が要件の要約です。抽出段階で落ちた情報は生成段階では絶対に復元できません。典型的な失敗は、検索で拾えなかった重要な例外条項が要約から丸ごと消え、しかも要約自体は流暢なので気づかれない、というものです。

パターン比較#

要約のためのチャンク分割#

分割の基本は検索用のチャンク分割と共通ですが、要約では優先順位が少し変わります。検索では「単体で意味が通る小さな断片」が有利ですが、要約では「一つの論点が途中で切れないこと」のほうが効きます。

構造を最優先にします。見出し・章・議題番号・話者の交代・日付の区切りなど、文書がもともと持っている境界で切るのが第一候補です。固定長で機械的に切ると、決定事項の途中で分断されて「〜については」で終わるチャンクが生まれ、map要約がその時点で意味不明になります。

メタデータをチャンク本文に残します。会議ログなら発言者名・タイムスタンプ・議題、報告書なら章番号と見出し、契約書なら条番号です。これがあると、最終要約で「誰がいつ何を決めたか」を書けるようになり、後述する根拠位置の併記も可能になります。逆にメタデータを剥がしてテキストだけにすると、map段階で主語が失われ、reduce時に発言者の取り違えが起きます。

オーバーラップは、検索用ほど大きく取らなくても機能することが多い一方、話題が段落をまたぐ文書(議論が続く会話ログなど)では少量入れると境界の欠落を防げます。分割戦略そのものの詳細は、検索側の記事に整理しています。

数値・固有名詞・否定表現が落ちる問題#

長文要約で最もクレームになりやすいのが、この3種類です。それぞれ落ち方に癖があります。

数値は、丸められる・単位が混ざる・別の数値と入れ替わるという形で壊れます。「1,200万円」と「120万円」のような近い値が同じ文書内にあると特に危険です。固有名詞は、似た名前の人物や部署が統合される、役職が入れ替わるという形で壊れます。否定表現は最も厄介で、「今期は導入しない方針で合意」が「導入する方針で合意」に化けると、要約として致命的でありながら文章としては完全に自然です。

対策は「落ちたら分かる形にする」ことに尽きます。

原文の該当箇所を引用させます。Anthropicの長コンテキスト向け推奨には「回答を引用で裏づける」という項目があり、長文タスクではまず文書中の関連部分を引用させてから本題を実行させると、モデルが関連箇所に集中しやすくなるとされています。要約の各項目に、根拠となった原文の一文をそのまま添えさせれば、数値や否定の取り違えは目視で照合できます。

根拠位置を併記させます。チャンクIDやページ番号、タイムスタンプを各項目に付けさせると、レビュー担当が原文を開いて確認する動線ができます。Anthropicの法務要約ガイドでも、正確な引用を含めるようプロンプトできることが、要約をLLMで行う判断材料の一つとして挙げられています。

構造化出力で項目を固定します。自由文の要約は「書かなかった」ことが見えませんが、スキーマで項目を決めておけば空欄が可視化されます。OpenAIのStructured Outputsは「モデルが常に指定したJSON Schemaに従う応答を生成すること」を保証すると説明されており、決定事項・担当者・期限・金額といったフィールドを必須にしておけば、埋まらない場合に検知できます。ただしサポートされるのはJSON Schemaのサブセットで、allOfやif/then/elseなどの合成キーワードは対象外である点、安全上の拒否はスキーマに従わず別のrefusalフィールドで返る点は公式ドキュメントに明記されています。

要約品質をどう評価するか#

「なんとなく良さそう」で運用を始めると、後から崩れたときに原因を切り分けられません。評価は要約設計とセットで作ります。

忠実性と網羅性は同時に最大化できない#

忠実性(原文にない内容を書かない)を厳しくすると、モデルは安全側に倒れて情報量の少ない要約を出します。網羅性を強く求めると、推測で埋める余地が増えて忠実性が落ちます。まず「この要約は何に使うのか」を決め、どちらを優先するかを明示するのが出発点です。決裁資料の下書きなら忠実性優先、ブレストの材料なら網羅性優先、といった具合です。

評価軸は既存研究の枠組みが参考になります。SummEval(Fabbriら)は、14種類の自動評価指標と23の要約モデルを一貫した条件で再評価した研究で、公開リポジトリでは要約が一貫性(coherence)・整合性(consistency)・流暢性(fluency)・関連性(relevance)の4次元で評価されたことが示されています。社内のルーブリックを作るときも、この4軸をベースに「数値の正確性」「決定事項の網羅」といった業務固有の軸を足す形にすると設計しやすくなります。

参照要約の作り方#

自動評価には基準となる要約(参照要約)が要ります。全件は無理なので、代表20〜50件を選んで人が書くのが現実的です。選ぶときは、短い/長い、構造がきれい/崩れている、数値が多い/少ない、といった軸で幅を持たせます。同じような文書ばかり集めると、評価が通っても本番で崩れます。

Anthropicの法務要約ガイドは、この工程の難しさを率直に書いています。同ガイドは「どんな文書にも唯一の正しい要約は存在しない。明確な方向づけがなければ、どの詳細を含めるべきかを判断するのは難しい」とし、抽出したい項目をあらかじめ具体的に定めることを勧めています。参照要約を作る前に、抽出項目リストを先に固めるほうが手戻りが減ります。

自動指標とLLM-as-a-judgeの位置づけ#

同ガイドは評価指標として、参照要約との重なりを見るROUGE、n-gramの精度を見るBLEU、埋め込みベクトルの類似度、LLMによるルーブリック採点、そして人手評価を挙げています。ROUGEやBLEUは表現の言い換えに弱く、忠実性の判定にはあまり向きません。実務では、言い換えに強い埋め込み類似度やLLM採点を主にし、ROUGE系は回帰検知の補助指標に留めるのが扱いやすい配分です。

LLM-as-a-judgeは有効ですが限界があります。MT-Bench/Chatbot Arenaの論文(Zhengら)は、GPT-4のような強力なLLM審査員が人間の選好と80%以上の一致率を達成し得ると報告する一方で、位置バイアス・冗長性バイアス・自己選好バイアス・推論能力の限界という4つの制約を明示しています。要約評価では特に、長い要約を高く評価しがちな冗長性バイアスが「網羅性を測っているつもりが長さを測っていた」という事故につながります。採点は「原文にない記述があるか」のように根拠を求める形式にし、比較評価では順序を入れ替えて実施します。

人手スポットチェックの設計#

自動評価を入れても、人手確認をゼロにはできません。設計のコツは、全文を読ませないことです。要約の各項目に根拠引用と位置情報を付けさせておき、レビュー担当は「引用が原文にあるか」「引用から結論が導けるか」だけを見ます。これなら1件あたり数分で回り、週次で数十件をサンプリングできます。同ガイドも、コストと時間はかかるものの、本番投入前の検証として少数の要約に専門家評価を行うのが一般的だとしています。

実装上の注意#

コスト試算の粒度については、Anthropicの法務要約ガイドが具体的な組み立て方を示しています。同ガイドの例では、英語の契約書について1トークンあたり3.5文字と仮定して文字数からトークン数を概算し、入力単価と出力単価をそれぞれ掛けて合計する手順が示されています。日本語ではトークン化の効率が異なるため、この換算値をそのまま使うことはできません。自分のデータでトークナイザを通して実測するのが確実です。

プロンプトキャッシュの条件も公式ドキュメントで確認が必要です。OpenAIのプロンプトキャッシュは「キャッシュヒットはプロンプト内の完全な接頭辞一致でのみ発生する」と説明され、指示や例示のような静的な内容をプロンプトの先頭に、ユーザー固有情報のような可変内容を末尾に置くことが推奨されています。GPT-5.6以降では最低1,024トークンの接頭辞が必要という記載もあります。Anthropicのプロンプトキャッシュも同様に静的な内容を先頭に置く設計を推奨しており、キャッシュ可能な最小トークン数はモデルごとに定められています。長文要約は共通指示が大きくなりがちなので、条件を満たす構成にしておく価値があります。

疑似コードで見るmap-reduce#

前提は、チャンク分割済みのテキストリストがあり、llm(prompt)が文字列を返す同期関数であることです。エラー処理・リトライ・並列実行は省いています。

# 前提: chunks は構造(見出し・話者・日時)を尊重して分割済みの文字列リスト
# 前提: llm(prompt) -> str。temperature は低めに固定して呼ぶ

MAP_PROMPT = """以下は議事録の一部です。
この範囲だけから、決定事項・保留事項・数値を箇条書きで抽出してください。
各項目には根拠となる原文を1文そのまま引用して添えてください。
範囲外の推測は書かないでください。

<chunk id="{cid}">
{text}
</chunk>"""

REDUCE_PROMPT = """以下は同一会議の部分要約です。
重複を統合し、矛盾があれば両論併記のうえ矛盾がある旨を明記してください。
引用と chunk id は保持してください。

<partial_summaries>
{joined}
</partial_summaries>"""

def map_reduce_summary(chunks, max_reduce_chars=20000):
    partials = [
        llm(MAP_PROMPT.format(cid=i, text=c))
        for i, c in enumerate(chunks)
    ]
    # 部分要約が大きすぎる場合は段階的に畳み込む
    while sum(len(p) for p in partials) > max_reduce_chars:
        grouped = [partials[i:i + 5] for i in range(0, len(partials), 5)]
        partials = [
            llm(REDUCE_PROMPT.format(joined="\n\n".join(g)))
            for g in grouped
        ]
    return llm(REDUCE_PROMPT.format(joined="\n\n".join(partials)))

ポイントは3つあります。map側で「範囲外の推測を書かない」と明示すること、引用とIDを最後まで持ち回ること、そしてreduce入力が膨らんだときに段階的に畳み込むループを最初から入れておくことです。3つ目を後回しにすると、長い文書を入れた瞬間にreduceで上限超過が起きます。

LLMに向かない要約#

正直に線を引いておきます。次のケースでは、LLM要約は主役にしないほうが安全です。

一言一句が効力を持つ文書の要約は向きません。契約条項・法令・医療上の指示などは、言い換えた時点で意味が変わり得ます。Anthropicの法務要約ガイドも、本番投入時の考慮事項として、要約の誤りが組織や顧客の法的責任につながり得ることを理解し、AIが生成した要約であり法務専門家のレビューが必要である旨の免責表示を提供することを挙げています。要約は原文へのナビゲーション(どこを読むべきかの案内)として使い、判断は原文で行う運用にします。

数値集計そのものも向きません。「全支店の売上合計」「該当件数」といった集計は、要約ではなく計算です。原文から数値を抽出させるところまでをLLMに任せ、合計や比較は決定的なコードで行うほうが、速く正確で監査もしやすくなります。

監査証跡が必要な一次記録も向きません。株主総会や取締役会のように、記録そのものが証跡になる議事録では、AI要約を一次記録に据えるべきではありません。録音と人手による確定版を一次記録とし、AI要約は関係者向けのダイジェストという位置づけに留めます。

モデルごとの最大出力トークン数、プロンプトキャッシュの最小トークン数やTTL、構造化出力の対応スキーマ範囲は、各社の公式ドキュメントで更新されます。実装前に使用モデルの現行仕様を確認してください。本記事で挙げた研究の数値は、それぞれの論文の実験条件下での報告値です。

よくある質問#

まとめ#

長文要約は、モデルを新しくすれば解決する種類の問題ではありません。どこで切り、何を残し、どこで検証するかという設計の問題です。まずmap-reduceのような単純な構成で基準線を作り、評価セットで測りながら一要素ずつ変えていく。地味ですが、これが結局いちばん早く安定します。要約の前提となる分割やトークンの見積り、評価の作り方もあわせて押さえておくと、崩れたときの原因を切り分けやすくなります。