長文コンテキストを扱う設計方法は、入力上限より先に、必要な根拠をどの方式で残すかを決めることです。 長文をすべて入力できても、必要な箇所を正しく使えるとは限りません。本記事では、契約・会議・障害調査を例に、全投入・検索・段階要約の選択、トークン予算、位置依存の評価、責任分担までを実装順に整理します。
長文コンテキストの全投入・検索・段階要約を選び分ける
長文を扱う設計で最初に決めるのは、利用できる最大トークン数ではなく、回答に必要な証拠をどう残すかです。契約書レビューなら条番号と例外条項、会議記録なら決定事項と担当者、障害調査なら発生時刻とログ行を欠かせません。必要な証拠を列挙してから、資料をそのまま入れる「全投入」、質問に近い断片を選ぶ「検索」、章ごとの中間要約を積み上げる「段階要約」を比較します。
OpenAI「Model catalog」はモデルごとにコンテキスト上限が異なることを示していますが、上限内に収まることは品質保証ではありません[4]。Liuらの原著論文「Lost in the Middle: How Language Models Use Long Contexts」は、関連情報の位置によって長文からの抽出性能が変わる現象を報告しています[1]。したがって、本文中央に置いた証拠も取り出せるかを評価ケースへ含めます。
契約書で方式を選ぶ確認例では、更新期限、解約条件、価格改定、例外承認の四論点から各3問、計12問を作ります。根拠を文書の先頭・中央・末尾へ分散させ、全投入、検索、段階要約で同じ質問を実行します。回答だけでなく条番号、例外の併記、見つからない場合の停止を照合してください。中央の例外だけ欠ける方式は、平均正答率が高くても契約判断には採用しません。12問は検証を始めるための構成例であり、一般的な合格基準ではありません。
| 業務条件 | 第一候補 | 採用理由 | 見送る条件 |
|---|---|---|---|
| 1案件が20ページ前後で、全条項の相互参照が必要 | 全投入 | 資料全体の関係を保ちやすく、引用位置も追跡しやすい | 複数案件を混ぜる、または入力費用が案件予算を超える場合 |
| 規程が数千ページあり、質問は一つの手続に限定 | 検索 | 対象部署、版、施行日で候補を絞り、不要な文脈を減らせる | 検索語が定まらず、表や別紙をまたぐ回答が大半を占める場合 |
| 月次報告を12か月分まとめ、変化と例外を確認 | 段階要約 | 月別の事実を固定した後に四半期・年間へ集約できる | 中間要約から元ページへ戻れない、または数値照合を自動化できない場合 |
| 権限の違う文書が同じ保管場所にある | 方式選定前に停止 | 検索結果や要約へ閲覧不可情報が混ざる危険がある | 認可済み文書だけを取得する仕組みと監査ログを用意できるまで再開しない |
「入るか」ではなく、「必要な根拠を再現でき、不要な情報を渡さずに済むか」で方式を決めます。
長文案件を本番へ載せる6工程
工程1：正本と補助資料を分ける
文書台帳へ文書ID、版、施行日、所有部署、閲覧区分、ページ数を登録します。メール添付と共有フォルダに同名ファイルがある場合は、所有部署が指定した正本だけを回答根拠にします。口頭説明は補助情報と明記し、正本の記載を上書きさせません。
工程2：質問を証拠単位へ分解する
「この契約を更新してよいか」という質問なら、更新期限、中途解約、価格改定、通知方法の四項目に分けます。一つの巨大な指示で結論まで求めず、各項目について該当箇所、該当なし、矛盾ありのいずれかを返す仕様にします。否定条件が見つからないときに推測で補わないことも完成条件です。
工程3：投入単位とメタデータを固定する
全投入では文書境界をタグで示し、検索では見出し・ページ・版・アクセス区分を断片へ付与します。段階要約では、要約本文とともに元文書ID、対象ページ、抽出した数値、未解決事項を保存します。Anthropicの長文向けプロンプト資料は、複数文書の境界を明示し、長い資料の後ろに質問を置く方法を案内しています[2]。これは同社モデルでの推奨であり、採用モデルごとに配置を再検証します。
工程4：回答形式に出典欄を組み込む
結論だけでなく、根拠文書ID、ページ、短い根拠要約、確信できない理由を必須項目にします。検索機能を使う場合も、取得件数と採用した断片をログへ残します。OpenAIのFile searchは検索結果を回答生成へ渡す仕組みを説明しているため[5]、業務側ではさらに正本判定と閲覧権限を付加します。
工程5：位置を変えた固定テストを行う
同じ証拠を先頭、中央、末尾へ移した3ケースを作り、抽出結果を比較します。表の脚注、例外条項、二重否定、改訂前の記載も別ケースにします。OpenAI「Working with evals」が示す代表的なテストデータの考え方[3]を用い、正常例だけでなく「根拠なし」と答えるべき質問を全体の20％以上にします。
工程6：限定運用で差分を記録する
最初の利用部署を一つに絞り、AI回答、担当者の修正、最終判断、修正に要した分数を案件単位で記録します。文書更新、モデル変更、検索設定変更のいずれかが起きたら、同じ固定テストを再実行します。人が結論を変えた案件は「プロンプトの失敗」と一括りにせず、文書不足、取得漏れ、要約損失、判断規則の不足へ分類します。
稟議資料120ページを扱う想定例
以下は実績値ではなく、設計比較のための想定例です。稟議資料120ページを1ページ平均700トークンと置くと、本文は約84,000トークンです。質問と指示を6,000トークン、回答上限を4,000トークンとすれば、1回の全投入は約94,000トークンを使用します。10人が月40件ずつ確認すると、入力だけで約3,360万トークンです。
想定入力トークン = 120ページ × 700 = 84,0001案件の総トークン = 84,000 + 指示6,000 + 回答上限4,000 = 94,000月間入力トークン = 84,000 × 10人 × 40件 = 33,600,000検索方式の想定入力 = 8断片 × 900 + 指示6,000 = 13,200
検索方式で900トークンの断片を8件取得するなら、質問前の入力は約13,200トークンです。ただし、費用が小さいだけでは採用できません。全投入で正答し、検索方式で例外条項を落とすなら、検索の候補数、分割方法、メタデータ条件を直します。逆に両方式の根拠一致率が同等であれば、応答時間と費用を含めて検索方式を選べます。
| 指標 | 計算方法 | 試行合格の例 | 注意点 |
|---|---|---|---|
| 根拠一致率 | 正しい文書・ページを示した件数÷対象件数 | 固定50問で90％以上 | 正しい結論でも根拠が違えば不合格 |
| 重要情報保持率 | 金額・期限・例外・否定条件の保持数÷期待数 | 重要項目は100％ | 平均点で重大な欠落を隠さない |
| p95応答時間 | 遅い方から5％地点の所要秒数 | 利用画面の待機上限内 | 検証端末と本番回線を分けて記録 |
| 確認短縮分 | 導入前の読解分数－導入後の確認分数 | 案件中央値でプラス | AI処理時間だけを短縮効果にしない |
位置依存と要約損失を見逃さない合否判定
固定テストは、質問の難易度だけでなく証拠の位置と形式で層別します。最低でも、先頭・中央・末尾、本文・表・脚注、単一文書・複数文書、最新版のみ・旧版混在の組み合わせを用意します。同じ問いを3回実行する場合は、3回中2回正解を合格にするのではなく、重要情報を一度でも落としたかを別に記録します。
- 公開可：重要項目の欠落が0件で、根拠一致率と応答時間が部署の基準を満たす。
- 条件付き：特定の文書形式だけ失敗し、その形式を対象外として画面でも明示できる。
- 再設計：証拠位置の移動で結論が変わる、旧版を優先する、引用ページを再現できない。
- 中止：アクセス区分の異なる文書が混ざる、または人が確認できない件数で自動判断へ進む。
合格率は方式別に出します。全投入、検索、段階要約の結果を一つの平均へ混ぜると、どの構成が失敗したのか分かりません。テスト票には文書集合のハッシュ、モデル識別子、投入順、検索条件、実行時刻を残し、再現できない結果は採用判断へ使わないでください。
文書所有者・実装担当・利用部門の責任境界
| 役割 | 決めること | 決めてはいけないこと | 残す証跡 |
|---|---|---|---|
| 文書所有部署 | 正本、改訂日、閲覧区分、失効文書 | モデルや検索方式の技術設定 | 文書台帳と承認履歴 |
| 実装担当 | 投入方式、分割、検索、ログ、停止処理 | 契約・規程の最終解釈 | 設定版、テスト結果、障害記録 |
| 業務利用者 | 質問内容、回答の利用可否、修正理由 | 閲覧権限外の資料追加 | 確認結果と最終判断 |
| 情報セキュリティ担当 | データ送信条件、保存期間、アクセス監査 | 個別案件の業務結論 | 例外承認と定期点検記録 |
AIは根拠候補を整理しますが、資料の正本性や法的解釈を確定する主体ではありません。人の確認を省けるのは、誤りの影響が限定され、正解を機械的に照合できる抽出だけです。契約締結、与信、採用、医療・安全判断のように誤りが権利や安全へ直結する用途では、専門担当者が元資料を確認します。
開始条件と撤退条件を一枚にまとめる
実装を始める前に、対象文書、対象質問、回答の利用先、正本管理者、許容待ち時間、月額上限、停止権限者を記入します。空欄があるままモデル選定へ進むと、長い入力を処理できても業務では使えません。特に「根拠が見つからない場合に誰へ返すか」を決めておくと、推測回答を下流へ流す事故を減らせます。
| 確認項目 | 開始可 | 停止または差し戻し |
|---|---|---|
| 正本 | 版と所有部署を特定できる | 同名異版の優先順位が不明 |
| 権限 | 取得前に利用者権限で絞り込める | 生成後に表示だけ隠す設計 |
| 評価 | 根拠付きの固定問題と不回答問題がある | 担当者の印象だけで良否を決める |
| 費用 | 入力・出力・検索を案件単位で集計できる | 月末まで利用量を把握できない |
| 撤退 | 元の手順へ戻せ、文書とログを移行できる | 要約だけが残り元資料との対応を失う |
長文処理が向かないのは、文書の権限を判定できない案件、正解を照合する資料がない案件、数秒以内の応答が必須なのに入力を大幅に減らせない案件です。その場合は、文書管理の整理、定型検索、専門家への振り分けを先に改善します。AIへ渡す量を増やすことは、情報管理の不足を補う方法にはなりません。
コンテキスト窓・会話履歴・外部記憶を区別する
コンテキスト窓は、モデルが一回の応答を作る際に参照できる入力と出力の上限です。長い会話を無期限に覚える「記憶」や、社内文書を保管する「データベース」と同じではありません。会話履歴、システム指示、ツール定義、検索した断片、画像、生成途中の出力も上限を共有するため、資料だけが上限内でも応答余地が足りなくなることがあります。
業務設計では、保持すべき状態を三層に分けます。案件番号、承認状況、利用者権限はアプリケーションの構造化データへ保存します。過去の発言から次の応答に必要な内容は、検証可能な会話要約として渡します。規程や契約書の本文は文書保管庫に置き、質問ごとに必要範囲を取得します。モデル入力だけを状態管理の置き場にすると、履歴の切り詰めや要約更新によって重要な条件が消えても検知できません。
| 情報 | 推奨する保持先 | モデルへ渡す時点 | 消失時の影響 |
|---|---|---|---|
| 案件ID・担当者・期限 | 業務DB | 各処理の開始時 | 別案件との混同、期限超過 |
| 確定済みの決定事項 | 承認記録と会話要約 | 後続判断に必要なとき | 同じ論点の再決定、条件逆転 |
| 規程・契約・マニュアル | 版管理された文書庫 | 検索または全投入時 | 旧版回答、根拠不明 |
| 一時的な推論や下書き | 必要な場合だけ実行ログ | 原則として次回へ持ち越さない | 業務上の確定事項でなければ限定的 |
長期の案件で会話要約を更新する場合は、「確定」「提案」「未確認」を混ぜません。要約を作った時刻、元メッセージID、更新者を保存し、利用者が訂正できる画面を用意します。要約だけを正本にせず、紛争や監査が想定される業務では元記録へ戻れる状態を維持します。
投入前に文書を正本・構造・権限で整える
長文処理の失敗はモデル入力後ではなく、資料を集める段階から始まります。同じ規程の2025年版と2026年版、草案、説明会スライドが混在していれば、モデルはどれを優先すべきか判断できません。最初に文書ID、版、施行期間、所有部署、承認状態、閲覧区分を台帳へ登録し、正本以外は補助資料または対象外として扱います。
PDFをテキスト化した後は、ページごとの文字数、表の行列、脚注、見出し階層、改ページ位置を原文と照合します。画像PDFで文字が抽出されないページ、縦書きで順序が崩れるページ、二段組みが混ざるページは自動的に要確認へ回します。契約書の「ただし」「除く」、規程の別表、マニュアルの警告欄は、本文だけを要約すると落ちやすいため、重要構造として明示します。
| 検査 | 確認方法 | 合格例 | 差し戻し例 |
|---|---|---|---|
| 版 | 台帳と表紙・プロパティを照合 | 現行版と適用期間が一致 | ファイル名だけで最新版と推定 |
| 抽出 | ランダム10ページと重要ページを目視 | 表・脚注・ページ番号を再現 | 金額列や否定語が欠落 |
| 権限 | 所有部署のアクセス表と照合 | 利用者グループを取得前に適用 | 生成後に伏字へするだけ |
| 追跡 | 断片から元ページを開く | 文書IDとページで一意に戻れる | 要約文しか保存されていない |
OCRや変換器の更新後は、全件を信頼して再取り込みせず、文書形式ごとに代表ファイルを再検査します。抽出品質を測れないスキャン文書が主要根拠なら、その形式を対象外とするか、人が確認したテキスト版を正本として登録するまで公開を見送ります。
入力・出力・余白を含むトークン予算を決める
トークン予算は、モデル上限から文書量を引くだけでは作れません。システム指示、利用者質問、会話要約、ツール定義、検索断片、回答上限、再試行時の追加情報を別々に見積もります。最大上限まで詰めると、回答が途中で切れたり、ツール結果を追加できなかったりするため、業務上の最大ケースでも余白を残します。
利用可能な文書予算= モデルのコンテキスト上限- システム指示- ツール定義- 会話状態- 利用者入力- 回答上限- 安全余白想定例:128,000 - 4,000 - 6,000 - 8,000 - 2,000 - 8,000 - 10,000= 文書へ使える上限 90,000トークン
この数値は想定例であり、特定モデルの保証値ではありません。実際にはOpenAI「Model catalog」など採用モデルの公式仕様[4]と、SDKが返す利用量を確認します。日本語は文字数とトークン数が一致しないため、「1ページ何文字」だけで請求額や上限を決めず、代表文書を実際にトークン化します。
月間費用の試算では、成功した一回分だけでなく、再試行率、検索用の埋め込み、キャッシュ、評価実行、ログ保存も含めます。想定案件1,000件、平均入力50,000トークン、再試行率8％なら、生成入力は5,400万トークンです。単価を掛けるときは入力・キャッシュ入力・出力を分け、参照した料金表の日付と通貨を記録します。
| 優先 | 見直すもの | 残すもの |
|---|---|---|
| 1 | 重複資料、古い草案、定型署名 | 正本、例外、否定条件 |
| 2 | 質問と無関係な章 | 引用に必要な前後関係 |
| 3 | 会話の逐語履歴 | 承認済み決定と未解決事項 |
| 4 | 出力の装飾や冗長な説明 | 結論、条件、根拠、不明点 |
回答が崩れた場所を入力・選択・生成で切り分ける
長文回答が誤っても、直ちにモデルを変更してはいけません。正本が入力に存在したか、必要部分を選べたか、選んだ根拠を回答へ反映したかを順に確認します。原因ごとに対策が異なるため、最終回答だけを見て「長文が苦手」と結論づけないことが大切です。
| 症状 | 最初に確認 | 主な原因 | 対処 |
|---|---|---|---|
| 金額が旧版 | 入力文書IDと適用日 | 正本選択または版フィルター | 台帳と検索条件を修正 |
| 例外だけ抜ける | 例外条項が同じ断片にあるか | 分割・要約損失 | 構造単位の分割と重要項目保持 |
| 中央の記述を無視 | 証拠位置を変えたテスト | 位置依存または競合情報 | 検索で絞る、順序を変える、複数回抽出 |
| 引用は正しいが結論が違う | 回答指示と出力 | 条件統合・推論の失敗 | 項目別抽出後に結論を作る |
| 毎回答えが変わる | 入力順、設定、検索候補 | 候補集合や生成の揺れ | 固定条件で複数回測定し、重要項目を決定的処理へ移す |
TACL 2024の「Lost in the Middle」は、関連情報が長い入力の中央にある場合に性能が低下し得ることを報告しています[1]。この知見を「すべてのモデルが必ず中央を無視する」と一般化せず、自社で使うモデルと文書形式を位置別に試します。
障害票には、利用者質問、文書集合、投入順、選択断片、回答、期待値、モデル・設定、実行時刻を残します。個人情報を含む入力をそのまま開発チケットへ転記せず、アクセスを制限したログと匿名化した再現ケースを分けます。再現できない事象は、同時刻のモデル応答だけでなく検索索引の更新や文書差替えも調べます。
文書更新とモデル変更を別々に監視する
本番後の品質低下には、モデル変更、プロンプト変更、文書改訂、抽出器更新、検索設定変更が関係します。これらを同日にまとめて反映すると原因を追えません。文書改訂は版と差分、モデル変更は識別子と評価結果、検索変更は候補順位の比較をそれぞれ記録し、重要業務では一度に一要素ずつ変更します。
| 監視対象 | 頻度 | 担当 | アラート例 |
|---|---|---|---|
| 正本反映遅延 | 文書更新ごと | 文書管理・データ担当 | 施行後も旧版が検索上位 |
| 重要項目保持 | 週次と変更時 | 品質担当 | 期限・金額・例外の欠落 |
| 権限外取得 | 全リクエスト | セキュリティ担当 | 1件でも即時停止 |
| 入力・出力利用量 | 日次 | 運用・費用管理 | 案件単価が予算を連続超過 |
| p95応答時間 | 時間帯別 | アプリ運用 | 待機上限を3区間連続超過 |
利用量が増えたら一律に文書量を削らず、質問種別ごとの入力、正答、確認時間を見ます。少数の巨大案件が費用を押し上げているなら、案件だけを段階要約へ切り替えます。短い質問まで同じ構成へ寄せると、コストを下げても検索漏れが増える可能性があります。
停止権限はシステム担当だけに置きません。文書所有者は誤版を見つけたとき、業務責任者は重大な誤判断を見つけたとき、セキュリティ担当は越権取得を見つけたときに、それぞれ対象文書・機能・全体のどこまで止めるかを事前に決めます。再開には原因、修正、固定テスト、影響確認の記録を必要とします。
契約・会議・障害調査で長文の扱いを変える
同じ100ページでも、業務が違えば残すべき情報と処理順は変わります。契約レビューでは条件と例外の関係、会議記録では発言より確定した決定と担当、障害調査では時系列と環境差が重要です。文書量だけで一つの長文処理パターンへ統一すると、必要な根拠を削ったり、不要な逐語記録へ費用を使ったりします。
| 業務 | 最初に抽出 | 保持する関係 | 人へ戻す条件 |
|---|---|---|---|
| 契約レビュー | 当事者、期間、金額、解除、責任制限 | 本文と定義、ただし書き、別紙、準拠法 | 条項競合、法的評価、相手方修正案 |
| 会議の引き継ぎ | 決定、保留、担当、期限、依存関係 | 決定を覆す条件と発言元 | 担当未確定、二つの議事録で結論が違う |
| 障害調査 | 発生時刻、環境、変更、症状、復旧 | ログ時刻と作業時刻、試行と結果 | 安全影響、データ損失、原因未特定の本番変更 |
| 申請審査 | 申請者、対象、必要書類、条件、例外 | 規程版と申請時点 | 裁量判断、本人確認不足、権利に関わる否決 |
契約レビューでは、段階要約を作る場合も条文番号と原文引用を失わないようにします。「標準的」「合理的」など解釈が必要な語は、AIが意味を確定せず、論点として法務担当へ渡します。金額と日付は抽出後に元ページと機械照合し、単位や税の扱いまで確認します。
会議記録は逐語録を毎回投入するより、会議ごとに決定事項、保留理由、担当、期限を構造化して保存した方が後続処理に向きます。ただし、決定の根拠を争う可能性がある会議では、元音声・逐語録への参照を保持します。AI要約を参加者の承認なく正式議事録として確定しません。
障害調査では、時刻のタイムゾーンとログ取得元を統一します。異なるサーバーのログを文面だけで並べると順序を誤るため、アプリ側で正規化した時刻とイベントIDを渡します。AIは仮説と確認済み事実を別欄へ出し、本番変更を提案しても自動実行しません。
長文処理の共通基盤は持てますが、何を落としてはいけないかと誰が最終判断するかは業務ごとに定義します。
長文コンテキスト設計の次の一歩
候補案件を一件選び、正本、必要な証拠、利用者権限、回答の利用先を記入してください。次に、同じ証拠を入力の先頭・中央・末尾へ置いた固定問題を作り、全投入・検索・段階要約の三方式で根拠一致率、重要情報保持率、p95応答時間、確認時間を比較します。重要な期限・金額・例外を一度でも落とす方式は、平均点が高くても本番候補から外します。方式を決めたら、文書所有者、実装担当、業務確認者、停止権限者を指名し、限定利用で記録を取り始めます。
採否会議へ出す検証票には、少なくとも次の六項目を残します。これは製品性能を示す実測値ではなく、自社検証を始めるための記入例です。
- 入力条件：正本の件数、総文字数、PDF・表計算・メールの構成比、最大文書長、改訂版の有無を固定する。
- 問題構成：通常質問35件、複数資料をまたぐ質問10件、相反する版を含む質問5件など、難しさの内訳を明示する。
- 比較方式：資料の全投入、検索で選んだ抜粋の投入、章別要約から詳細へ進む方式を、同じモデルと同じ質問で各3回実行する。
- 品質基準：根拠箇所が一致した割合95％以上、期限・金額・適用除外の欠落0件、根拠のない断定0件を合格例とする。
- 運用基準：p95応答時間15秒以内、確認者が原文へ戻るまで2分以内、1件当たりの推定費用を予算内に収める。
- 停止条件：権限外資料の混入、旧版を現行版として引用、確認できない要約の再利用のいずれかが起きたら限定利用を止める。
費用は、1回の入力・出力トークン数に利用モデルの単価を掛け、想定月間件数と再試行率を加えて試算します。たとえば初回応答1,000件に対して20％が再質問になるなら、月間呼び出しは1,200回として計算します。一方、応答時間、正答率、確認時間はテスト環境で測った値として別欄に記録し、試算と混ぜません。検証の再現性を保つため、実行日、モデル版、設定値、資料スナップショットの識別子、検証票の保管先も結果と一緒に保存します。全投入が品質基準を満たしても、文書追加のたびに費用と待ち時間が増える場合は検索方式へ切り替えます。検索が必要な例外条項を落とすなら、対象文書を絞るか、人が資料を選んでからAIへ渡す運用を選びます。最終決裁者は平均点ではなく、重大な誤りの有無と月次費用の上限を確認して方式を承認します。
参考文献・出典
- Liuほか「Lost in the Middle: How Language Models Use Long Contexts」。長文コンテキスト内の情報位置と利用性能を検証した原著論文、Transactions of the Association for Computational Linguistics, Vol.12, 2024, pp.157-173（2026-07-30参照）
- Anthropic公式ドキュメント「Prompting best practices」。大量文書の区切りと長文入力時の配置方法を確認、現行Web版、版・更新日表記なし（2026-07-30参照）
- OpenAI公式ドキュメント「Working with evals」。代表ケースを用いた評価手順を確認、現行Web版、版・更新日表記なし（2026-07-30参照）
- OpenAI公式ドキュメント「Model catalog」。LLMのモデル別コンテキスト上限を確認、現行Web版（2026-07-30参照）
- OpenAI公式ドキュメント「File search」。検索結果を回答生成へ渡す公式仕様を確認、現行Web版、版・更新日表記なし（2026-07-30参照）
