「要約してください」とだけ送ると、AI は当たり障りのない短文を返します。同じ資料でも、対象・用途・読み手・粒度の 4 つを渡すと、そのまま実務に使える要約に変わります。この記事では、長文・PDF・議事録という 3 つの典型を、それぞれどんな「型（テンプレート）」で頼めばよいかを、2026 年時点の AI の実力を踏まえて具体的に説明します。
FIG.1 同じ資料でも、4 要素を渡すかどうかで出力は別物になる
01長文：一括で読めても「2 段」で縮める
2026 年の主要モデルは桁違いに長い文章を一度に扱えます。Claude Opus / Sonnet 4.6 は 100 万トークン、Gemini 3.1 Pro は 200 万トークン、GPT-5.5 は 51.2 万トークンが標準です。日本語で数十万字の資料でも、技術的には「丸ごと貼って要約」が可能になりました。
ところが、入れられる量と正確に読める量は別です。研究では、長い文脈の中盤に置かれた情報は取りこぼされやすく（U 字型の精度カーブ。文脈が長くなるほど中央の精度が 30% 以上落ちることもある）、この現象は「lost in the middle」「context rot」と呼ばれます。だから長文は、一括で入る場合でも次の2 段階に分けると安定します。
FIG.2 章ごとに縮めてから統合すると、長い資料でも前半の取りこぼしが減る
章・節ごとに 200〜500 字で要約させる
見出し単位で分けると粒度がそろい、どの章由来かも追える。中盤の取りこぼし対策になる。
その要約を集めて最終要約に統合する
章ごとの要約を渡し、800〜1,500 字へ。元の長さに引きずられず、章間の重複も整理できる。
章ごとに頼むときのプロンプト例です。「保持するもの」と「やらせないこと」を明示するのがコツです。
以下の章を 300 字で要約してください。
- 重要な数値・固有名詞・日付はそのまま保持
- 著者の主張と、その根拠を分けて書く
- あなた自身の解釈・評価は加えない
[本文]入れられる量と、正確に読める量は別物。だから「2 段」は今も効く。
02PDF：まず「そのまま添付」、崩れたら抽出に切り替える
2026 年の主要モデルはマルチモーダル対応で、PDF をそのまま添付して読ませるのが最も手軽です。図表混じりのレポートでも、文章＋レイアウトをまとめて理解してくれます。まずはこれで十分なことが多い、というのが出発点です。
うまくいかないのは、スキャン画質が悪い・段組みが複雑・表が多い PDF です。ここでは専用ツールが効きます。文書解析のベンチマーク（OmniDocBench 等）では、表・数式・複雑レイアウトの素の読み取りについて、小型の専用 OCR モデルが汎用の大型モデルを上回る場合があると報告されています。実務の定石は次の使い分けです。
| そのまま添付（マルチモーダル） | 先に抽出してから渡す |
|---|---|
| テキストが選択できる通常の PDF | スキャン画像・写真の PDF |
| 多少の図表・体裁なら丸ごと理解 | 複雑な段組み・大きな表・数式が多い |
| 手間ゼロで試せる（最初の一手） | pdftotext / OCR / 抽出ツールで一旦テキスト化 |
表や項目を後工程（集計・転記）で使いたいときは、文章ではなく構造（JSON）で抽出させると扱いやすくなります。
この PDF を次の構造で抽出してください。
{
"title": string,
"sections": [{ "heading": string, "content": string }],
"tables": [{ "caption": string, "rows": [[string]] }],
"key_findings": [string]
}
読み取れない欄は空にし、推測で埋めないこと。大量ページを機械的に処理する用途では、まず安価な抽出（OCR）で大半を捌き、読み取りに失敗した分だけ画像としてモデルに回す「抽出ファースト＋必要時だけ画像」の二段構えがコスト効率で定番になっています。
03議事録：「要約」より「分解」で価値が出る
議事録は、なめらかな要約文よりも、決まったこと・宿題・未決を切り分けることに価値があります。会議録音の文字起こしや Slack スレッドを、次の構造に整形させましょう。
FIG.3 議事録は要約しきらず、後で動ける単位に「分解」する
以下の会話ログを次の構造で整理してください。
## 決定事項（具体的に決まったこと）
## アクション（担当者 / 内容 / 期限）
## 論点（議論されたが未決）
## 主要発言（発言者 / 要点）
## 次回までに準備するもの
担当者・期限が曖昧なものは勝手に埋めず「要確認」と明記。04用途別の「粒度」早見表
最初に粒度を決めておくと、毎回ぶれません。用途ごとの目安です。
| 用途 | 粒度の目安 |
|---|---|
| 1 行サマリ（共有メッセージ用） | 30〜50 字 |
| エグゼクティブサマリ | 200〜300 字 / 5 ポイント |
| 記事ティザー | 500〜800 字 / 続きを読みたくなる構成 |
| 業務レポート要約 | 1,500〜3,000 字 / 根拠込み |
| 逐語サマリ | 原文の約 1/3 / 論理構造を保持 |
05「誰向けか」で要約は変わる
同じ文書でも、読み手が変われば残すべき情報が変わります。プロンプトに「[役割] 向けに要約」と一言足すだけで視点が切り替わります。
経営層向け
結論を先に。事業への影響と、いま決めるべき意思決定ポイントを。
技術者向け
実装の要点と、技術的なトレードオフ・制約条件を具体的に。
顧客向け
メリット・価格・申込方法など、相手の行動につながる情報を。
06品質を上げる 5 つの指示と「原典で検証」
要約の最大のリスクは、AI が原文にない解釈や数値をもっともらしく補完することです。指示で抑えつつ、最後は必ず原典と照らし合わせます。
- 「自分の意見・評価は入れない」と明示する
- 「一次情報の数値・固有名詞・日付は保持」と指定する
- 「重要度の高い順に上位 N 件だけ」で量を絞る
- 要約後に「この要約に欠けている重要点は？」と聞く（自己点検）
- 要約から元の論点を復元できるか確かめる（逆再構成テスト）
ただし、これらはあくまで失敗を減らす工夫です。要約を鵜呑みにせず、重要な判断に使う数値・結論は原典に当たって検証する——この一手を省かないことが、長文・PDF・議事録のどれにも共通する最後の砦です。
07よくある勘違い・失敗パターン
- 長すぎて結局読まれない：先に粒度（字数・ポイント数）を決める
- 重要な数値が抜ける：「原文の数値・日付を保持」と明示する
- 原文にない解釈を足される：「解釈を加えない」と指定し、出力を原文と照合する
- 「素晴らしい」「画期的」など主観が混じる：修飾語の禁止を指示する
- 機密の取り扱い：社外秘・顧客情報は利用規約と入力ポリシーを確認し、必要なら匿名化してから渡す
08まとめ
要約は 対象 × 用途 × 読み手 × 粒度 を渡せば、AI の力をそのまま実務に乗せられます。長文は「一括で入っても 2 段」、PDF は「まず添付・崩れたら抽出」、議事録は「要約より分解」——この使い分けと、最後に原典で検証する習慣を覚えておけば、毎回ぶれません。次の記事では、書いた文章を AI で磨く「校正・推敲・トーン調整」を扱います。
