要約プロンプトの書き方｜長文・技術文書を要約させるテンプレート集

要約プロンプトは、「誰が・何のために読むか」「残す項目」「出力の形」の3つを指定すると質が決まります。 「この文章を要約して」だけでは、AI は何を残して何を削るかを自分で決めることになり、読む人が知りたかった数値や期限が落ちることがあります。

この記事では、3点を埋めるだけの基本テンプレート、仕様書・設計書・障害報告・変更履歴・API ドキュメント・長いやり取りの6種の技術文書向けテンプレート、長文を章ごとに要約してからまとめる手順、原文に無い内容や数値の抜けを確かめる検証用プロンプトとスクリプトをまとめました。会議の記録（議事録）は扱わず、文書の要約に絞っています。

確認環境：Ubuntu 24.04、Python 3.11.15（確認日 2026-10-05）。文書を章ごとに分けるスクリプト、要約の形を数えるスクリプト、数値を照合するスクリプトの出力は、架空の「備品予約システム 機能仕様書」を使ってこの環境で実行した結果です。プロンプトの考え方は、同日に開いた Anthropic と OpenAI の公式ドキュメントの記載に沿っています。この記事はテンプレート集で、AI の回答例は載せていません。

この記事の結論

• 指定するのは読む人と目的・残す項目・出力の形の3つ
• 長さは文字数ではなく、「箇条書き5点・各1文」のように個数と文の数で指定する
• 技術文書は、目的・前提・決まったこと・未決のこと・数値・期限を残す項目にする
• 長文は章ごとに要約 → まとめの2段階にし、数値と固有の名前は原文のまま運ぶ
• 要約は原文と照らして確かめる。数値は機械的に、内容は引用を出させて確かめる

要約プロンプトの早見表

基本テンプレート：3点を指定する

{ } を書き換えて使います。文書を先に、指示を後ろに置いています。

<document>
{要約したい文書をここに貼る}
</document>

上の文書を要約してください。

# 読む人と目的
- 読む人：{例：この仕組みを初めて担当する開発者}
- 目的：{例：来週の改修に向けて、決まっていることと決まっていないことを把握する}

# 残す項目
{例：目的、前提、決まったこと、未決のこと、数値、期限}

# 出力の形
- {例：箇条書き5点。各項目は1文}
- 数値・日付・固有の名前は、原文の表記のまま書く
- 残す項目のうち、原文に書かれていないものは「記載なし」と書く

# 守ること
- 文書に書かれていることだけを使う。一般的な知識で補わない
- 意見や評価は加えない

Anthropic の公式ガイドには、長い文書は質問や指示より前に置くこと、文書をタグで囲むことが載っています。OpenAI のヘルプ記事には、指示と文脈を区切り記号（### や """）で分けることが載っています。どちらにも共通するのは、指示と文書の境目をはっきりさせることです。上のテンプレートでは document タグで囲んでいます。

「誰が・何のために」で要約は変わる

同じ仕様書でも、読む人によって残すべき情報が変わります。

「分かりやすく要約して」より、「誰が読んで、読んだあと何をするか」を1行ずつ書くほうが、残る情報が安定します。

長さは文字数ではなく個数と文の数で指定する

長さは「箇条書き5点・各1文」のように、個数と文の数で指定します。

生成AIは文章を「トークン」という単位で扱います。Anthropic の用語集では、トークンは単語・単語の一部・文字などに対応する最小の単位で、言語によって1トークンに対応する文字数が変わると説明されています。文字を1つずつ数えながら書いているわけではないので、「200字ちょうど」のような指定は合わせにくい指定です。OpenAI のヘルプ記事も、長さは「かなり短く」のようなあいまいな言い方ではなく、「3〜5文の段落で」のように具体的な数で指定する例を挙げています。

個数と文の数を数えるスクリプト

指定どおりかどうかは、目で数えるよりスクリプトに任せると確実です。

"""要約が「箇条書き N 点・各 M 文」の指定どおりかを数える"""
import re
import sys

path, want_items, want_sentences = sys.argv[1], int(sys.argv[2]), int(sys.argv[3])
text = open(path, encoding="utf-8").read()
items = [l[2:].strip() for l in text.splitlines() if l.startswith("- ")]

print(f"全体 {len(text)} 字 / 箇条書き {len(items)} 点（指定 {want_items} 点）")
ok = len(items) == want_items
for i, item in enumerate(items, 1):
    n = len([s for s in re.split(r"[。！？]", item) if s.strip()])
    mark = "OK" if n == want_sentences else "要確認"
    ok = ok and n == want_sentences
    print(f"{i}. {n} 文 / {len(item):>2} 字  {mark}")
sys.exit(0 if ok else 1)

手で書いた要約（summary.txt。あとの検証で使うため、わざと誤りを3つ入れてあります）で試した結果です。

- 社員約160名が、30点の備品を Web 画面から予約できるようにする。
- 予約は30分単位で最長8時間、当日から14日先まで受け付ける。
- 開始の15分前までは、予約した本人が取り消せる。
- 受け入れテストは2026年11月13日、利用開始は2026年12月1日。
- 予約一覧は2秒以内に表示し、チャットにも通知する。

python3 check_shape.py summary.txt 5 1

全体 167 字 / 箇条書き 5 点（指定 5 点）
1. 1 文 / 36 字  OK
2. 1 文 / 31 字  OK
3. 1 文 / 24 字  OK
4. 1 文 / 36 字  OK
5. 1 文 / 25 字  OK

形は指定どおりです。ただし、形が合っていることと、中身が正しいことは別です。この要約に入れた3つの誤りは、後半の検証で確かめます。

どうしても文字数で収めたいとき

入力欄の上限などで文字数が決まっている場合は、次の順で進めます。

1. まず個数と文の数で要約させる
2. スクリプトや表計算ソフトで文字数を数える
3. 超えていたら、数えた結果を伝えて直させる

いまの要約は {数えた文字数} 字でした。上限は {上限の文字数} 字です。
情報を落とす順番は「背景 → 補足の説明 → 例」とし、数値・期限・未決のことは残して、
各項目を短く書き直してください。項目の数は変えないでください。

「短くして」ではなく、いまの文字数・上限・落とす順番を渡すのがポイントです。

技術文書向けの要約テンプレート6種

どのテンプレートも、基本テンプレートの「読む人と目的」と document タグを付けて使います。ここでは「残す項目」と「出力の形」の部分を載せます。

表計算ソフトに貼れるタブ区切り版です。

文書の種類   残す項目    読む人の例
仕様書 目的、前提、決まったこと、未決のこと、数値、期限    開発者、テストを作る人
設計書 構成、方式を選んだ理由、制約、他との接続、未決のこと  引き継ぐ開発者
障害報告    起きたこと、影響、原因、対応、再発を防ぐ策、残っている作業   責任者、関係する部門
変更履歴    追加、変更、修正、互換性に関わる変更、利用者がやること 利用する開発者
APIドキュメント   入口、認証、主な操作、制限、エラー、版 呼び出す側の開発者
長いやり取り  経緯、決まったこと、未決のこと、誰が何をするか、期限  途中から参加する人

1. 仕様書の要約テンプレート

# 残す項目と出力の形
次の見出しで要約してください。各見出しは箇条書きで、1項目1文です。

## 目的（1〜2点）
何のための仕組みか。いま困っていること。

## 前提（3点まで）
利用者、利用する環境、既存の仕組みとの関係。

## 決まったこと（5点まで）
ルール、条件、制約。数値は原文の表記のまま。

## 未決のこと（すべて）
「未定」「検討中」「〜で決める」「範囲に含めない」と書かれている事柄。いつ決まるかが書かれていれば添える。

## 数値（すべて。表で）
| 項目 | 値 | 原文の章 |

## 期限（すべて）
日付と、その日に何があるか。

# 守ること
- 原文に書かれていない見出しは「記載なし」と書く
- 「決まったこと」と「未決のこと」を混ぜない。範囲に含めないと書かれたものは「未決のこと」に入れる

2. 設計書の要約テンプレート

# 残す項目と出力の形
次の見出しで要約してください。各見出しは箇条書きで、1項目1〜2文です。

## 全体の構成（3〜5点）
登場する部品（画面、サーバー、データベース、外部の仕組み）と、それぞれの役割。

## 方式を選んだ理由（方式ごとに1点）
「何を選んだか／理由／比べた別の案」。理由が書かれていないものは「理由の記載なし」。

## 制約と前提（5点まで）
性能、容量、利用する製品の版、守るべき決まり。数値は原文のまま。

## 他との接続（すべて）
接続先、やり取りする情報、向き、頻度。

## 未決のこと・懸念（すべて）

# 守ること
- 図の説明文や表の内容も対象にする
- 設計の良し悪しの評価は書かない

3. 障害報告の要約テンプレート

# 残す項目と出力の形
次の見出しで要約してください。

## 一言で（1文）
いつ、何が、どのくらいの時間起きたか。

## 影響（3点まで）
影響を受けた機能、利用者の範囲、件数。数値は原文のまま。

## 時系列（表）
| 時刻 | 起きたこと・行ったこと |
原文の時刻をそのまま使う。時刻の書かれていない出来事は「時刻の記載なし」。

## 原因（1〜2点）
直接のきっかけと、それを招いた背景。原文で「推定」「調査中」とされているものは、その言葉を残す。

## 対応（3点まで）
その場で行った対応と、その結果。

## 再発を防ぐ策（すべて。表）
| 策 | 担当 | 期限 | 状態 |

## 残っている作業（すべて）

# 守ること
- 原因が確定しているか、推定かを書き分ける
- 個人の責任を問う表現は加えない

4. 変更履歴の要約テンプレート

# 残す項目と出力の形
{版 A} から {版 B} までの変更を、利用する側の立場で要約してください。

## 利用者がやること（すべて。最初に書く）
更新のときに必要な作業。設定の変更、書き換えが必要な呼び出しなど。無ければ「なし」。

## 互換性に関わる変更（すべて）
動きが変わるもの、無くなったもの。変更前 → 変更後の形で。

## 追加（5点まで）
## 変更（5点まで）
## 修正（5点まで）
各項目は1文。原文に番号（課題番号など）があれば末尾に付ける。

# 守ること
- 内部の整理だけの変更（利用者から見えないもの）は「その他 n 件」とまとめる
- 版の番号と日付は原文のまま書く

5. APIドキュメントの要約テンプレート

# 残す項目と出力の形
この API を初めて呼び出す開発者向けに要約してください。

## 概要（2文）
何ができる API か。

## 入口と認証（3点まで）
基本の URL、認証の方式、必要なヘッダー。

## 主な操作（表。10行まで）
| メソッドとパス | できること | 必須の引数 |

## 制限（すべて）
呼び出し回数の上限、大きさの上限、ページ分けの方式。数値は原文のまま。

## エラー（表）
| 状態コード | 意味 | 呼び出す側の対応 |

## 版と変更の予定（あれば）

# 守ること
- 文書に載っていない操作や引数を足さない
- サンプルのコードは作らない（必要なら別に頼む）

6. 長いやり取りの要約テンプレート

メールやチャットのスレッド、課題管理のコメント欄など、複数の人が時間をかけて書いたやり取り向けです。

# 残す項目と出力の形
このやり取りに途中から参加する人向けに要約してください。

## いまの状態（2文）
何について話していて、いまどこまで進んでいるか。

## 経緯（5点まで。日付の早い順）
話の向きが変わった出来事だけを、日付つきで。

## 決まったこと（すべて）
「決まった内容（決めた人、日付）」の形で。

## 未決のこと（すべて）
誰の返事や判断を待っているかを添える。

## 誰が何をするか（表）
| 担当 | やること | 期限 |
期限の書かれていないものは「期限の記載なし」。

# 守ること
- あとの発言で取り消された・変わった内容は、最新のものだけを「決まったこと」に書く
- 提案されただけで合意の書かれていないものは「未決のこと」に入れる
- 発言した人の名前は原文の表記のまま書く

長文を章ごとに要約してからまとめる手順

文書が長いときは、一度に全部を要約させるより、章ごとに要約してから、要約どうしをまとめる2段階にします。途中の章が薄くなるのを防げ、どの章の要約かをたどれるようになります。

手順1：見出しで章に分ける

"""Markdown の文書を「## 」の見出しごとに分け、章ごとの文字数を表示する"""
import pathlib
import re
import sys

src = pathlib.Path(sys.argv[1])
out = pathlib.Path(sys.argv[2])
out.mkdir(exist_ok=True)

text = src.read_text(encoding="utf-8")
parts = re.split(r"(?m)^(?=## )", text)
title, chapters = parts[0].strip(), parts[1:]

print(f"文書名: {title.lstrip('# ')} / 全体 {len(text)} 字 / {len(chapters)} 章")
for i, body in enumerate(chapters, 1):
    heading = body.splitlines()[0].lstrip("# ")
    path = out / f"chapter_{i:02d}.md"
    path.write_text(f"{title}\n\n{body}", encoding="utf-8")
    print(f"{path.name}  {len(body):>4} 字  {heading}")

題材にした架空の仕様書（spec.md、6章）です。

# 備品予約システム 機能仕様書 v1.2

## 1. 目的
社内の備品（プロジェクター、会議用マイクなど）を、社員が Web 画面から予約できるようにする。
現在は共有の表計算ファイルで管理しており、同じ時間帯に予約が重なることが月に3〜4件起きている。

## 2. 前提
- 利用者は社員約160名。社内ネットワークからのみ利用する。
- 認証は既存のシングルサインオンを使う。
- 対象の備品は30点。備品の追加・削除は総務担当が行う。

## 3. 予約のルール
- 予約は30分単位、1回につき最長4時間。
- 予約できるのは当日から14日先まで。
- 同じ備品で時間帯が重なる予約は受け付けない。終了時刻と開始時刻が同じ予約は受け付ける。
- 開始時刻の10分前までは、予約した本人が取り消せる。

## 4. 通知
- 予約の確定時と、開始の15分前にメールで知らせる。
- チャットへの通知は、連携方式が決まっていないため今回の範囲に含めない。

## 5. 性能と運用
- 予約一覧の表示は2秒以内（同時利用50人を想定）。
- 予約データは1年間保存する。保存期間を過ぎたデータの扱いは未決。
- バックアップは毎日1回、午前2時に取得する。

## 6. スケジュール
- 2026年11月13日：受け入れテスト開始
- 2026年12月1日：利用開始
- 備品の写真を一覧に表示するかどうかは、11月6日の打ち合わせで決める。

実行した結果です。

python3 split_by_heading.py spec.md chapters

文書名: 備品予約システム 機能仕様書 v1.2 / 全体 628 字 / 6 章
chapter_01.md   108 字  1. 目的
chapter_02.md    94 字  2. 前提
chapter_03.md   133 字  3. 予約のルール
chapter_04.md    76 字  4. 通知
chapter_05.md   101 字  5. 性能と運用
chapter_06.md    93 字  6. スケジュール

分けたファイルの先頭には、文書名を付けています。章だけを渡すと、何の文書の一部かが AI に伝わらないためです。

# 備品予約システム 機能仕様書 v1.2

## 3. 予約のルール
- 予約は30分単位、1回につき最長4時間。
- 予約できるのは当日から14日先まで。
- 同じ備品で時間帯が重なる予約は受け付けない。終了時刻と開始時刻が同じ予約は受け付ける。
- 開始時刻の10分前までは、予約した本人が取り消せる。

見出しの無い文書は、段落の区切りや一定の文字数で分けます。その場合は、文の途中で切れないよう、空行の位置で切ります。

手順2：章ごとに要約する

<document>
{chapter_03.md の中身}
</document>

これは長い文書の一部（1つの章）です。あとで他の章の要約とまとめるための、章の要約を作ってください。

# 出力の形
章：{章の番号と見出しを原文のまま}
- 決まったこと：箇条書き。1項目1文
- 未決のこと：箇条書き。無ければ「なし」
- 数値・期限：「項目＝値」の形で、原文の表記のまま、すべて
- 他の章への言及：あれば、どの章の何を指しているか

# 守ること
- この章に書かれていることだけを使う。他の章の内容を想像で補わない
- 数値・日付・固有の名前は言い換えない

手順3：章の要約をまとめる

<chapter_summaries>
{手順2の出力を、章の順に並べて貼る}
</chapter_summaries>

上は、1つの文書を章ごとに要約したものです。これをもとに、文書全体の要約を作ってください。

# 読む人と目的
{基本テンプレートと同じ}

# 出力の形
{文書の種類に合うテンプレートの見出し}
各項目の末尾に、もとになった章の番号を（3章）のように付ける。

# 守ること
- 章の要約に書かれていることだけを使う
- 章どうしで食い違う内容があれば、まとめずに「食い違い：」として両方を書く
- 数値・期限は、章の要約にあるものをすべて残す

章の番号を付けさせると、気になる項目を原文で確かめるときに、読む場所がすぐ分かります。

原文に無い内容や数値の抜けを確かめる

要約は、読みやすく整っているほど、誤りに気づきにくくなります。機械的に確かめられる部分はスクリプトで、内容は検証用プロンプトで確かめます。

数値を機械的に照合する

"""要約に出てくる数値が原文にあるか、原文の数値が要約に残っているかを確かめる"""
import re
import sys
import unicodedata

PATTERN = r"\d+(?:\.\d+)?(?:年|月|日|時間|時|分|秒|名|人|点|件|回|%|円|字)?"


def numbers(path: str) -> list[str]:
    text = unicodedata.normalize("NFKC", open(path, encoding="utf-8").read())
    text = re.sub(r"(?m)^#+ .*$|^## \d+\.", "", text)  # 見出し（章番号・版）は除く
    seen = []
    for m in re.findall(PATTERN, text):
        if m not in seen:
            seen.append(m)
    return seen


src, summ = numbers(sys.argv[1]), numbers(sys.argv[2])
print("要約にあって原文に無い数値:", [n for n in summ if n not in src] or "なし")
print("原文にあって要約に無い数値:", [n for n in src if n not in summ] or "なし")

先ほどの summary.txt（誤りを3つ入れた要約）と、原文の spec.md で実行した結果です。

python3 check_numbers.py spec.md summary.txt

要約にあって原文に無い数値: ['8時間']
原文にあって要約に無い数値: ['3', '4件', '1回', '4時間', '10分', '50人', '1年', '2時', '6日']

• 「8時間」は原文に無い数値として見つかりました（原文は「最長4時間」）
• 「原文にあって要約に無い数値」は、落とした数値の一覧です。「10分」「50人」「1年」など、読む人に必要なものが落ちていないかを、この一覧で判断します

一方で、要約の3行目「開始の15分前までは取り消せる」は誤りですが（原文は「10分前まで」。15分は通知の時刻）、「15分」という数値は原文の別の場所にあるため、この照合では見つかりません。5行目の「チャットにも通知する」（原文は「今回の範囲に含めない」）も、数値ではないので対象外です。こうした誤りは、次の検証用プロンプトで確かめます。

検証用プロンプト：1文ずつ根拠を引用させる

<document>
{原文}
</document>

<summary>
{確かめたい要約}
</summary>

summary の各文が document の内容と合っているかを、1文ずつ確かめてください。

# 手順
1. summary を1文ずつに分け、番号を付ける
2. 各文について、根拠になる document の箇所を、一字一句そのまま引用する
3. 引用と文を見比べて、次のどれかに判定する
   - 一致：文の内容が引用と合っている
   - 食い違い：数値・条件・肯定と否定・主語が引用と違う
   - 根拠なし：対応する箇所が document に無い

# 出力の形
| 番号 | summary の文 | document の引用 | 判定 | 違っている点 |

そのあとに、次の2つを箇条書きで挙げる。
- document にある数値・日付・期限のうち、summary に無いもの
- document で「未定」「検討中」「範囲に含めない」とされているのに、summary で決まったことのように書かれているもの

# 守ること
- 引用は document の文字をそのまま写す。言い換えや要約をしない
- 引用が見つからないときは、無理に近い箇所を当てはめず「根拠なし」とする

Anthropic の公式ドキュメントには、長い文書を扱うときは先に一字一句の引用を取り出させること、主張ごとに根拠の引用を示させ、引用が見つからない主張は取り下げさせることが、誤りを減らす方法として載っています。上のプロンプトはその形です。同じドキュメントには、これらの方法で誤りは減るが無くなるわけではなく、大事な情報は確かめるように、とも書かれています。

人が確かめるチェック表

要約・抜き出し・言い換えの違いと選び方

「短くしてほしい」と思ったとき、やりたいことは3種類に分かれます。

抜き出しのプロンプトの例です。

<document>
{原文}
</document>

document から、数値・日付・期限が書かれた文をすべて、原文のまま抜き出してください。
| 章 | 原文の文（そのまま） | 数値・日付 |
言い換えや省略はしないでください。該当する文が無い章は「なし」と書いてください。

仕様書のテンプレートで「数値」を表にさせているのは、要約の中に抜き出しを組み込むためです。まとめ直してよい部分と、原文のまま運ぶ部分を分けると、読みやすさと正確さを両立できます。

確かめて分かったこと

• 形の確認と中身の確認は別に必要だった。誤りを3つ入れた要約でも、「箇条書き5点・各1文」の確認はすべて OK になりました
• 数値の照合で見つかるのは、原文に無い数値だけ。原文の別の場所にある数値が違う項目に付いた誤り（10分と15分の取り違え）は見つからず、引用との見比べが要りました
• 「原文にあって要約に無い数値」の一覧は、落とした情報の点検表として使えた。6章・628字の文書でも9個の数値が落ちており、必要かどうかを一覧で判断できました
• 章に分けるときは、各ファイルの先頭に文書名を付けると、章だけを渡しても何の文書かが伝わる形になります
• 肯定と否定の入れ替わり（範囲に含めない → 通知する）は、数値を含まないので機械的な照合の対象外。「含めない」「未決」などの語を原文で検索する確認が有効です

よくある質問

Q. 要約プロンプトには何を書けばよいですか？ A. 「誰が・何のために読むか」「残す項目」「出力の形」の3つを書きます。加えて、数値や日付は原文のまま書くこと、原文に無いことは「記載なし」と書くことを指定すると、あとで確かめやすくなります。

Q. 要約の文字数を指定しても守られないときはどうすればよいですか？ A. 文字数の代わりに「箇条書き5点・各1文」のように個数と文の数で指定します。文字数の上限がある場合は、できた要約の文字数を数え、いまの文字数と上限、落とす順番を伝えて直させます。

Q. 長文が一度に入らないときはどうすればよいですか？ A. 章ごとに要約してから、章の要約をまとめます。章の要約では数値・期限を原文のまますべて残し、まとめるときは各項目に章の番号を付けさせると、原文で確かめやすくなります。

Q. 要約と抜き出しの違いは何ですか？ A. 要約は内容を選んでまとめ直すこと、抜き出しは条件に合う箇所を原文のまま取り出すことです。数値や期限を1つも落としたくないときは、抜き出しを使います。

Q. 要約が正しいかどうかは、どう確かめればよいですか？ A. 数値は原文と機械的に照合し、内容は1文ずつ原文の引用を出させて見比べます。「根拠なし」「食い違い」と判定された文と、未決のことが決まったことのように書かれていないかを重点的に見ます。

まとめ

• 要約プロンプトは読む人と目的・残す項目・出力の形の3つを指定する
• 長さは個数と文の数（箇条書き5点・各1文）で指定し、スクリプトで数えて確かめる
• 技術文書は目的・前提・決まったこと・未決のこと・数値・期限を残す項目にする
• 文書の種類ごとに見出しを固定した6種のテンプレートを使い分ける
• 長文は章ごとに要約 → まとめ。数値と固有の名前は原文のまま運び、章の番号を付ける
• 数値は機械的に照合し、内容は1文ずつ引用を出させて確かめる
• 正確さが要る部分は抜き出し、全体像は要約と使い分ける

参考・出典

• Anthropic「Prompting best practices」 https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices （2026年10月5日に閲覧）
• Anthropic「Reduce hallucinations」 https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-hallucinations （2026年10月5日に閲覧）
• Anthropic「Glossary」 https://platform.claude.com/docs/en/about-claude/glossary （2026年10月5日に閲覧）
• OpenAI Help Center「Best practices for prompt engineering with the OpenAI API」 https://help.openai.com/en/articles/6654000-best-practices-for-prompt-engineering-with-the-openai-api （2026年10月5日に閲覧）
• OpenAI「Prompt engineering」 https://developers.openai.com/api/docs/guides/prompt-engineering （2026年10月5日に閲覧）

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。