100万トークンのコンテキストウィンドウ実務ガイド：契約書、研究資料、repoをどこまで一度に読ませるか

契約書：読ませるなら、要約ではなくレビュー作業として依頼する

単一の契約書全文は、100万トークンのコンテキストウィンドウと相性がよい候補です。契約書は、定義、条項番号、別紙、義務主体、期限が文書内で相互に参照されるため、長い範囲を一度に見られる利点があります。公開資料でも、大型ドキュメントは1M contextで扱える用途として挙げられています。

ただし危ないのは、モデルが読めないことよりも、出力が「それらしいが確認できない要約」になることです。単に「この契約書の問題点を教えて」と聞くより、条項の位置、原文抜粋、リスク分類を必ず出させる方が実務向きです。

たとえば、次のように依頼します。

条項番号ごとに、支払義務、解除・解約権、責任制限、秘密保持義務、違約時の効果を整理してください。各項目には、該当する原文抜粋と条項番号を付け、法律専門家による確認が必要な点を分けて示してください。

この聞き方なら、モデルにまず契約本文へ戻らせることができます。法務、購買、営業、事業開発の現場では、長文脈モデルは初期レビューや論点整理には役立ちますが、最終的な法律意見の代わりにはなりません。

研究資料：一番向いているのは、文書をまたいだ比較

研究資料で価値が出やすいのは、1本ずつの要約ではなく、複数文書を横断した整理です。どの結論が一致しているのか。前提や定義はどこで違うのか。数値や方法論に矛盾はないのか。各研究の限界は何か。こうした作業は、同じコンテキスト内に複数資料を置けるほどやりやすくなります。

向いている依頼は、たとえば次のようなものです。

1. 複数の報告書を同じ比較表にまとめる。
2. すべての資料が共通して支持している結論を抜き出す。
3. 互いに衝突する定義、仮定、結果を示す。
4. 各研究の方法、サンプル、制約、未回答の問いを抽出する。
5. 次の調査テーマやインタビュー項目を作る。

研究資料では、最初から「証拠マトリクス」を求めるのが効果的です。各結論の横に、出典文書、該当段落、原文抜粋を並べさせます。長文脈は複数資料を同時に参照しやすくしますが、外部分析が指摘するように、検索、分割処理、人手での確認を完全に置き換えるものではありません。

Repo：ZIPで丸ごとではなく、先に整理してから読ませる

コードリポジトリは、100万トークンのコンテキストウィンドウで最も魅力的に見える用途の一つです。TestingCatalogは大型コードベースと大型文書を1M contextの用途として挙げており、技術分析でもGPT-4.1が長いコンテキスト内の理解と情報探索に向けて訓練されたと説明されています。

ただし、repoはノイズ密度が高い素材です。モデルが本当に必要とするのは、全ファイルではなく、タスクに関係する構成、入口、設定、主要モジュール、エラーログ、再現手順です。何も選別せずに丸ごと渡すと、限られた文脈容量を低価値のファイルで消費しやすくなります。

通常、最初の入力から外すか、後回しにしたいものは次の通りです。

• node_modules/、vendor/ などのサードパーティ依存ディレクトリ
• 問題そのものが生成結果でない限り、大きなgenerated files
• build artifactsや一時出力
• バイナリファイル、画像、モデル重み
• 大量のfixture、snapshot、テストデータ
• タスクに関係しない過去の出力、バックアップ、一時ファイル

比較的安定する渡し方は、まずディレクトリツリー、README、アーキテクチャ文書、主要な設定ファイルを入れることです。次に、作業対象に関係するコアコードを追加します。最後に、エラーメッセージ、再現手順、失敗しているテスト、期待する挙動を補足します。これにより、モデルがプロジェクトの文脈を組み立てやすくなります。

よくある3つの誤解

1. 100万トークンは、全部入れるべきという意味ではない

100万トークンの上限は、大型文書やコードベースを扱いやすくします。 しかし、重複、生成物、依存ライブラリ、OCRの誤字、関係の薄いファイルが多ければ、モデルの注意は低価値な材料にも分散します。容量が大きいほど、入力の整理はむしろ重要になります。

2. モデル上限と利用環境の上限は違うことがある

「モデルが1M contextに対応」とされていても、すべてのAPI、クラウド環境、製品UIで同じ条件で使えるとは限りません。Microsoft Q&Aでは、Azure OpenAIでgpt-4.1を使ったユーザーが、100万トークン未満でも「context window exceeded」に遭遇したと報告しています。これはすべての環境で必ず起きるという結論ではなく、デプロイや製品仕様による差に注意すべきという警告として読むのが妥当です。

3. 長文脈は完全な検索ではない

資料をコンテキストに入れたからといって、モデルが必ずすべての重要箇所を安定して見つけるわけではありません。GPT-4.1の1M contextについての批判的な分析も、この能力を印象的だとしつつ、現実のユースケースをすべて満たすには不十分だと位置づけています。

実務フロー：先に清掃し、次に証拠を出させる

契約書、研究資料、repoを長文脈モデルに入れるなら、次の順番が扱いやすいです。

1. トークン数を見積もる。 ページ数、ファイル数、MBだけでは判断しない。言語、ファイル形式、コードの書き方でトークン化の結果は大きく変わります。
2. ノイズを削る。 重複、無関係な添付資料、生成ファイル、依存ディレクトリ、スキャン由来の誤字、過去の出力を外します。
3. 構造を残す。 文書なら見出し、ページ、段落、条項番号。repoならパス、ファイル名、ディレクトリツリーを残します。
4. 先に証拠抽出を求める。 条項、段落、ファイルパス、コード片を先に列挙させてから、要約や判断に進めます。
5. 質問を狭める。 「全部見て問題を教えて」ではなく、「支払条項の衝突を探す」「8本の研究の結論差を比較する」「このエラーに関係するモジュールを特定する」と聞きます。
6. 高リスクの出力は分割して検証する。 契約、財務、医療、セキュリティ、本番コード変更は、1回の長文脈出力だけで決めない方が安全です。

分割処理や検索に切り替えるべき場面

資料が継続的に更新される場合、逐語的な引用追跡が必要な場合、バージョン差分を細かく見る場合、またはrepoが多数の無関係モジュールを含む場合、長文脈だけで押し切るのは最適とは限りません。

その場合は、100万トークンのコンテキストを「全体像をつかむ層」として使い、検索、分割要約、テストログ、人手レビューを組み合わせる方が現実的です。これは、1M contextは強力だが実務ワークフロー全体の完全な解決策ではない、という既存の分析とも一致します。

最後に：実用上の線引き

• 単一の契約書全文：多くの場合は候補になります。 ただし、条項番号、原文抜粋、リスク分類を必ず求めます。
• 一式の研究資料：かなり向いています。 複数文書の比較、共通結論、矛盾点、証拠マトリクスに使いやすい領域です。
• repo全体：整理済みの小〜中規模プロジェクト、または明確な調査タスクなら有力です。 大規模モノレポ、依存ディレクトリ、生成ファイルが多い場合は、先に選別するか検索型の流れに切り替えます。
• 入るからといって、1回の出力をそのまま信じない。 100万トークンが解決するのは「より多くの材料を入れられる」という容量の問題です。安定して見つける、引用する、判断するには、プロンプト設計、証拠抽出、分割検証、人手の確認がなお必要です。