PAP-40-Layer Framework 第24層のアイキャッチ

長文要約で後半の条件や例外を落とさないための依頼方法

  • URLをコピーしました!

長文要約で後半が薄いと感じたら、まず原文の後半まで渡せているかと、回答が途中で切れていないかを確かめます。そのうえで、章ごとに残す論点を決め、末尾の条件や例外を抽出してから要約させます。前半と後半の文字数を同じにするより、判断を変える情報が残っているかを原文との対応表で確認する方が、修正する箇所を特定できます。

「全文を詳しく要約して」と繰り返すだけでは、不足している箇所や条件が明示されません。前半の説明が長いことと、後半にある重要条件が欠けることは、別々に見ます。短い後半でも必要な条件が残っていれば、章の長さを揃える必要はありません。

この記事は、入力は収まっているのに要約の後半が薄くなる問題を扱います。入力そのものが長すぎて分割が必要な場合は「トークン制約に合わせて長文を分割し統合する方法」で扱います。

目次

後半が薄くなる原因を一つに決めない

最初に調べるのは、入力の範囲です。添付の読み取りで後半が取得できていない、ページが抜けた、表や脚注が抽出されていない、といった場合は、要約の指示より前に資料の取得を直す必要があります。目次が読めたことと、各章の本文まで読めたことも区別します。

次に、出力が完了したかを見ます。文が途中で終わる、指定した後半の見出しが出ないなどの症状があれば、出力上限や処理状態を確認します。たとえば2026年10月12日に確認したOpenAI APIのReasoning modelsでは、対象の推論モデルの出力予算には可視の回答だけでなく推論用トークンも関係し、上限で不完全な応答となり得ることが説明されています。このAPIの条件を、すべてのサービスや画面の共通仕様として扱うことはできません。

入力が揃い、出力も完了しているなら、何を重要とするかの指定と説明配分を確認します。背景の詳しい説明を求める一方で、例外を残す指示がないなど、依頼の配分が偏っていないかを見ます。ただし、実際の原因をログや比較で確認していない段階では、モデルの性質だけに決め付けません。

長文中の情報利用を調べたLost in the Middleは、当時のモデルによる多文書質問応答と合成的な検索課題で、重要情報の位置や入力長による成績差を報告しています。成績が高かったのは関連情報が入力の冒頭か末尾にある場合で、下がったのは長い入力の中ほどにある場合でした。つまり「末尾ほど使われない」という結果ではなく、まして「すべてのモデルが要約の後半を省く」と示した研究でもありません。章ごとの配分指定で今回の要約が改善するかも、別に確認する必要があります。

架空の規程で残す情報を決める

架空の出張申請規程を要約する例を考えます。資料は全六章で、次のような内容があるとします。実在組織の規程や実際のAI出力ではありません。

  • 第1章:規程の目的と対象者
  • 第2章:出張前に申請し、承認を受けるという原則
  • 第3章:申請書に記入する事項
  • 第4章:精算に使う資料
  • 第5章:緊急時は事前に承認担当者へ電話で確認できる。ただし申請書は帰着後の翌営業日までに提出する
  • 第6章:この緊急時の扱いでも、通常の経費上限は変わらない

利用目的は、担当者が「通常時と緊急時で何をすればよいか」を把握することです。この目的なら、第1章の背景を何段落も説明するより、第5章の事前連絡と後日の書類、第6章の上限維持を残すことが重要になります。

悪い要約例を、「出張は事前申請と承認が必要です。申請には目的と日程などを記入します。緊急時には例外があります」とします。末尾に例外という語はあっても、緊急時に何を行うのか、通常ルールのどこが変わらないのかが分かりません。

ここで「後半をもっと長く」と頼むだけでは、第5章の一般説明が増えて第6章の上限が残らないかもしれません。先に章ごとの論点を取り出し、要約へ残す情報を指定します。

章の配分は重要性と役割に合わせる

この規程なら、目的・対象は短く、通常の手順は一まとまりに、緊急時の条件と変わらない制約は省略しない、と配分できます。各章に同じ字数を割り当てる方法だけでは、短い例外条項が持つ重要性を表せません。

原文の場所 要約に残す論点 説明の配分 確認する対応
第1章 対象者と利用場面 背景説明は短くする 対象者を広げていないか
第2〜4章 通常の申請、承認、記入・精算資料 手順が分かる範囲でまとめる 申請と承認を一つの状態にしていないか
第5章 緊急時の事前電話確認、帰着後の翌営業日の提出 行動と期限を両方残す 電話だけで手続きが完了した表現になっていないか
第6章 緊急時も経費上限は維持される 第5章の例外と一緒に示す 例外を上限免除へ広げていないか

この表は要約を作る前の配分案です。章ごとに何文字と指定する場合も、数値は作業上の目安とし、重要な条件が収まらなければ配分を変えます。原文の長さに比例させるだけでは、短い否定やただし書きを落とすおそれがあります。

全体の文字数を厳しく指定する場合は、削ってよい説明も指定します。この例では背景の詳細や同じ原則の反復を減らせます。一方、「帰着後の翌営業日」と「通常の経費上限」は、行動を変える条件なので、短くするために削る対象にはしません。

改善する依頼文と期待する要約

最初の依頼が「この規程を短く要約してください」だったなら、利用目的と残す情報を加えます。次は未実行の依頼例です。

「担当者が通常時と緊急時の手続きを理解するために要約してください。まず全六章から、原則、条件、例外、例外でも変わらない制約を、章の位置付きで整理してください。第1章の背景は短くし、第5章の事前連絡と提出期限、第6章の経費上限を残してください。その後に要約を作り、各文と原文の章の対応を示してください。未取得の章は内容を推測せず、未確認と記してください。」

章数、対象の章、読者の利用目的は、実際の資料に合わせて差し替えます。六章という指定だけでは全文取得を保証しないため、回答後には原資料の章と取得範囲も確認します。許可されていない機密規程を、例文どおりに外部のAIへ入力することは避けます。

この例で期待する要約は、「通常は出張前に申請し、承認を受けます。緊急時は事前に承認担当者へ電話で確認でき、申請書は帰着後の翌営業日までに提出します。この場合も通常の経費上限は変わりません」です。これは例の重要条件を示す抜粋であり、申請項目や精算資料の詳細まで網羅した手引きではありません。

条件を保持するため、例外の説明は原則から離し過ぎないようにします。「緊急時の例外は別章を参照」とだけ書くと、読者が原則だけを読んで判断する可能性があります。短い要約でも、通常手順と例外の関係が分かる位置に置きます。

原文との対応を確認してから仕上げる

作成後は、章の見出しが並んだかではなく、必要な論点が要約のどの文に残ったかを確認します。第5章に対応する文で、事前の電話確認と帰着後の書類提出が両方あるかを見ます。第6章に対応する文では、経費上限を維持する条件が残っているかを見ます。

先ほどの悪い要約を、原文との対応表に当てはめると次のようになります。

原文の場所 残すべき論点 対応する要約の文 判定
第2章 事前申請と承認 出張は事前申請と承認が必要です 残っている
第3章 申請書の記入事項 申請には目的と日程などを記入します 残っている
第4章 精算に使う資料 対応する文なし 欠落。ただし今回の利用目的では一文の言及で足りる
第5章 事前の電話確認、帰着後の翌営業日の提出 緊急時には例外があります 行動と期限が欠けている
第6章 緊急時も経費上限は変わらない 対応する文なし 欠落

表にすると、「冒頭だけ詳しい」という印象を、どの章の何が欠けたかへ置き換えられます。通常時と緊急時の手続きを知るという目的では、第4章は一文足せば足りますが、第5章と第6章は行動を変える条件なので、対応する文を書き直す必要があります。前半の文を削っても、この欠落は埋まりません。

抜けがあれば、その箇所と依存する結論を直します。上限が抜けた場合は第6章の文を足すだけでなく、要約全体に「緊急時は通常手続きが免除される」といった広い表現が残っていないかも照合します。

原文の該当箇所を取得できない場合は、対応表に未確認を残し、確認した章と未取得の章を明示して渡します。取得済みの章だけの部分要約を作るか、資料の再取得を待つかは、利用目的で決めます。緊急時の判断に使う要約なら、欠けた例外を推測で埋めず、その判断を保留します。

後半の情報量だけを増やすことが目標ではありません。原則を詳しく説明できたかと、後半にある条件を保持できたかを別々に確認し、必要な意味が揃ったところで仕上げます。章別の配分と対応表は、その確認を行うための手掛かりとして使います。

長い入力で重要な条件が抜けたときの切り分け方は「長い入力で重要条件が抜けたとき、量・位置・重複を切り分ける」で解説しています。

出典・参考資料

  1. OpenAI「Reasoning models」(確認日:2026年10月12日)
  2. Nelson F. Liuほか「Lost in the Middle: How Language Models Use Long Contexts」(確認日:2026年10月12日)
よかったらシェアしてね!
  • URLをコピーしました!

この記事を書いた人

さかっぺのアバター さかっぺ PAP Research運営 / AIガバナンス・アーキテクト / プロンプトデザイナー

ITインフラの実務経験をもとに、AIの安全性と実用性を両立する仕組みを研究。PAP Researchでは、AIモデルの継続観測と、プロンプト・AI技術の実務解説を発信しています。

経歴や研究方法、発信方針は運営者プロフィールで紹介しています。

目次