長い文脈は武器か罠か——入れる前の契約

目次▼

1. 1結論を先に
2. 2まず用語の地図
3. 3全文投入の「本当のコスト」
4. 4RAGの「本当の難しさ」
5. 5要約の「見落とされがちな力」
6. 6具体例：長文コンテキストでの検証ゲート
7. 7よくある偏り
8. 8いまの一手

長い文書をモデルに渡すとき、全文投入・検索（RAG）・要約のどれを選ぶかは運用設計の話だ。ベンダー優劣ではなく、判断軸だけを残す。

---

この記事の使い方

決めること 長文コンテキストを使う場面で、全文投入・検索（RAG）・要約の三択をどう選ぶか。

決めないこと 特定モデルやベンダーの優劣。ここでは構造的な判断基準だけを扱う。

前提 コンテキストウィンドウが10万トークンを超えるモデルが実用に入ってきた2024年以降の話。それ以前の「RAG一択」時代とは前提が変わっている。

---

結論を先に

状況	推奨する手	理由の一言
文書全体の構造・矛盾を問いたい	全文投入	検索では拾えない文脈間の関係が必要
大量文書から特定事実を引く	検索（RAG）	全文投入はコスト・速度で割に合わない
長い文書を短くして次工程に渡す	要約	後工程のプロンプトを節約できる
文書が頻繁に更新される	検索（RAG）	全文投入は都度再投入になり運用が重い
文書が1〜3本・更新が少ない	全文投入 or 要約	RAGのインデックス構築コストが無駄になる
回答の根拠を明示したい	検索（RAG）	チャンク単位で出典を返せる

---

まず用語の地図

用語	短い言い換え
コンテキストウィンドウ	モデルが一度に「見られる」文字数の上限。トークン単位で数える
トークン	単語より少し小さい意味の塊。日本語は1文字≒1〜2トークンが目安
RAG（検索拡張生成）	全文を渡す代わりに、関連箇所だけ検索して取り出してからモデルに渡す手法
チャンク	RAGで文書を分割する単位。段落・文・固定文字数など切り方は複数ある
ロストイン・ザ・ミドル	長いコンテキストの中間部分をモデルが見落としやすい現象。論文名がそのまま定着した
プリフィルコスト	コンテキストを読み込む際に発生するコスト。長いほど高く、キャッシュで軽減できる場合もある

---

全文投入の「本当のコスト」

コンテキストウィンドウが広がったことで「とりあえず全部入れる」が技術的には可能になった。ただし可能と最適は別の話だ。

お金と速度の現実

100万トークンのモデルに10万トークンの文書を投入すると、プリフィルだけで相応の費用が発生する。同じ質問を100回繰り返す運用なら、1回あたりのコストは小さく見えても月次で積み上がる。

コスト試算の目安（概算）

文書量（トークン）	想定用途	全文投入の懸念
〜4,000	メール・短い仕様書	ほぼ問題なし
4,000〜32,000	契約書・技術仕様	繰り返し呼び出しで注意
32,000〜200,000	書籍・大型レポート	コスト・速度ともに要検討
200,000〜	大量ログ・コードベース	RAGか要約への分解が現実的

ロストイン・ザ・ミドル問題

スタンフォード大学らの研究（2023）で示されたこの現象は、モデルが長いコンテキストの先頭と末尾には強く反応するが、中間部分の情報を見落としやすいというものだ。モデルの改善は進んでいるが、「入れれば読む」は今も保証されていない。

検証ゲート：全文投入を選ぶ前に確認する4点

• 文書の中間部分に重要情報があるか（あるなら追加テストが必要）
• 同じ文書に対して1日何回クエリを投げるか（多いならキャッシュ戦略を持つ）
• 文書の更新頻度はどのくらいか（高頻度なら再投入コストを試算する）
• 回答に出典箇所の明示が必要か（必要ならRAGの方が構造的に向いている）

---

RAGの「本当の難しさ」

RAGは「検索してから生成する」という構造上、検索の精度がそのまま回答の質に直結する。全文投入より安く速いが、設計の手間は全文投入より大きい。

チャンクの切り方が命

文書をどう分割するかで、検索ヒット率が大きく変わる。よくある失敗は「固定文字数で機械的に切る」だ。段落の途中で切れると、意味の単位が壊れて検索精度が落ちる。

チャンク戦略	向いている文書	注意点
固定文字数	構造が均一なログ・データ	意味の途中で切れやすい
段落・セクション単位	仕様書・契約書・記事	セクションの長さにばらつきがある場合は調整が必要
意味単位（セマンティック）	会話ログ・インタビュー	実装コストが高い
階層型（親子チャンク）	長い技術文書	検索は子、返却は親、という二段構えで精度と文脈を両立

検証ゲート：RAGを選ぶ前に確認する4点

• 文書が複数あり、横断検索が必要か
• 文書の更新・追加が定期的に発生するか
• 回答に「どの文書のどの箇所か」を示す必要があるか
• チャンク設計・インデックス管理を運用できる体制があるか

---

要約の「見落とされがちな力」

要約は「全文投入もRAGも重い」ときの妥協案に見えるが、実際には独立した強みがある。

要約が本領を発揮する場面

後工程への受け渡し 長い会議録を要約してから別のモデルに渡す、という二段構えは、後工程のコンテキストを節約しながら情報の核を保持できる。

定期バッチ処理 毎日100本のニュース記事を処理する場合、全文をRAGに入れるより、まず要約を生成してそれをインデックスに入れる方が、検索精度と速度のバランスが取れることがある。

人間のレビューとの接続 モデルの出力を人間が確認するフローでは、要約の方が確認コストが低い。全文投入の回答は「どこを根拠にしたか」が見えにくいことがある。

検証ゲート：要約を選ぶ前に確認する3点

• 要約で失われる細部が、後工程で必要になる可能性はあるか
• 要約の品質（何を残すか）をどう定義・評価するか
• 要約→次工程という二段構えのレイテンシ（処理の遅れ）は許容できるか

---

具体例：長文コンテキストでの検証ゲート

切り口は「入れる前の契約」。抽象論で終わらせず、次の三行をチケットに残す。

1. 通ったら終わり — 観測可能な完了条件（数値・ログ・画面のどれか）。
2. 壊れたらこう見える — 失敗1件と、人間が止める地点。
3. 誰が責任を持つか — 客先／本社／ベンダーの分界を一文で。

この三行がない縦スライスは、速さ優先でも信頼優先でもない——ただの未定義作業だ。週次では、ベンダー比較表より先にこの三行を埋める。レビューでは「どのモデルか」より「どのゲートで止めたか」を先に聞く。止める地点が共有されていないチームほど、同じ失敗を別の肩書きで繰り返す。

持ち帰るチェック

• 受け入れ条件は数値か、画面の状態か、ログの一文か——どれか一つに固定する。
• 失敗モードは「起きてほしくないこと」ではなく「起きたときに見えること」で書く。
• 権限を広げた理由がログに残っていない変更は、本番相当に入れない。
• デモ環境と本番相当でデータが違うなら、完了定義も別物として書く。
• 同じ論点が再燃したら、ツール比較より用語表とゲート一覧を先に開く。

よくある偏り

「コンテキストが広いから全部入れる」

技術的に可能になったことと、運用として最適なことは別だ。「128kトークンまで使える」は「128kトークン使うべき」ではない。

「RAGが標準解」という思考停止

2023年時点ではRAGが事実上の標準だったが、コンテキストウィンドウの拡大でその前提は崩れた。文書が少なく更新も少ない場合、RAGのインデックス構築・管理コストが全文投入より高くつくことがある。

要約を「精度が落ちる手」と決めつける

要約の精度は、何を残すかの定義次第だ。「重要な数字・固有名詞・結論を必ず含める」という制約付きの要約プロンプトは、漫然とした全文投入より高い精度を出すことがある。

一度決めたら変えない

文書の種類・量・更新頻度・クエリ頻度は変わる。三択の選択も定期的に見直す設計にしておくことが、長期運用では重要だ。

---

いまの一手

本気で設計に入る人へ

1. 自分の文書を計測する。使っているモデルのトークナイザーで実際の文書量を測る。感覚値と実測値はずれることが多い。
2. 三択を同じ文書で比較する。同じ質問を全文投入・RAG・要約の三通りで試し、回答の質・コスト・速度を記録する。
3. ロストイン・ザ・ミドルを自分で再現する。重要情報を文書の中間に置いたテストケースを作り、モデルが拾えるか確認する。
4. 更新頻度と呼び出し頻度を軸にした選択マトリクスを作る。上の結論表をそのまま使ってもよい。

まだ様子見の人へ

• 「全部入れれば解決する」という直感を一度疑ってみる。それだけで判断の質が変わる。
• 次に長い文書をモデルに渡す機会があったら、「これは全文投入・RAG・要約のどれが向いているか」を30秒だけ考えてから実行する。
• コンテキストウィンドウの拡大はまだ続いている。今の選択基準は1〜2年後に変わる可能性がある。定期的に見直す習慣を持つ方が、特定の手法に習熟するより長持ちする。

---

モデル動向の全体像は modelsシリーズ にまとめている。実際の運用設計（チャンク戦略・インデックス管理・コスト最適化）に踏み込む場合は、fde（現場実装）シリーズ も参照してほしい。