この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。OpenAI・Google・Anthropicの現在の長文処理、構造化出力、プロンプト設計に関する公式情報を確認し、旧版の「長いCoTを出力させながら一気にホワイトペーパーを作る」構成を、抽出・構成・執筆・検証に分けるパイプラインへ見直しました。検証ステータス：📘 OpenAI・Google・Anthropic公式情報確認済み／大規模文書でのモデル横断ベンチマークは未実施
長い議事録、調査メモ、仕様書をLLMへまとめて渡し、「これでホワイトペーパーを書いて」と頼むことはできます。しかし、資料が増えるほど、どの記述がどの根拠に基づくのか追いにくくなります。
そこで、完成原稿を一度に作らず、抽出 → 構成 → 執筆 → 検証の4段階に分けます。5372の記事が「コンテキストの境界設計」を扱うのに対し、この記事では長文から成果物を作る工程に焦点を当てます。
Step 1：元資料から「事実カード」を作る
最初に文章を書かせず、使える事実だけを取り出します。各資料にIDを振っておくと、後で根拠を戻れます。
[
{
"fact_id": "F-001",
"source_id": "DOC-03",
"topic": "認証方式",
"fact": "2027年度から新方式へ移行予定",
"evidence": "該当箇所の短い抜粋",
"status": "confirmed"
}
]ここで重要なのは、モデルが「うまくつなぐ」ことより、元資料に存在する情報と、存在しない情報を分けることです。
Step 2：章立てだけ作る
次に、事実カードを材料に章立てを作ります。まだ本文は書かせません。
目的:
- 経営層向けに10分で読める説明資料を作る
必須章:
1. 背景
2. 現状
3. 課題
4. 選択肢
5. 推奨案
6. 未確定事項
ルール:
- 各章に利用するfact_idを付ける
- fact_idがない主張を追加しないこの段階で「章はあるのに根拠がない」箇所を発見できます。
Step 3：章ごとに本文を書く
全章を一気に生成するのではなく、章ごとに必要な事実カードだけを渡します。これにより、別章の情報を混ぜるリスクを下げられます。
<section>課題</section>
<facts>
F-004 ...
F-007 ...
F-011 ...
</facts>
<requirements>
- 600〜800字
- 事実と提案を分ける
- 未確定事項は断定しない
</requirements>Step 4：完成原稿を「元資料へ戻して」検証する
最後に、文章のうまさではなく、主張が元資料に戻れるかを確認します。
| チェック | 確認内容 |
|---|---|
| 出典 | 主要主張にsource_id / fact_idがあるか |
| 数値 | 日付、金額、比率が元資料と一致するか |
| 矛盾 | 章ごとに異なる前提を使っていないか |
| 未確定 | 推測を確定事項として書いていないか |
| 構造 | 要求された章と形式を満たすか |
矛盾は「解決させる」前に残す
旧版では、矛盾を見つけたらモデルに仮説を作らせて解消する構成でした。しかし、業務資料では矛盾そのものが重要なことがあります。
{
"conflict_id": "C-002",
"source_a": "DOC-04",
"source_b": "DOC-09",
"issue": "導入予定日が異なる",
"status": "needs_human_review"
}根拠がないのにモデルへ「最も合理的な案を選べ」とすると、もっともらしい補完が入ります。まず未解決の矛盾として残し、人が判断できるようにします。
構造化出力を使えるところは使う
事実カード、矛盾一覧、章立てなど、中間成果物はJSON Schemaなどで型を決めやすい部分です。GoogleのStructured Outputsは構文上のJSONを安定させるために役立ちますが、値の意味が正しいことまでは保証しないため、元資料との照合が必要です。
長文では「重要度ラベル」より具体的な用途を書く
[PRIORITY: HIGH] のような独自ラベルを大量に付けるより、「この資料は契約条件の確認に使う」「この表は数値の正本」と役割を具体的に書く方が保守しやすくなります。
工程をファイルで残す
自動化する場合は、中間生成物を捨てずに残すと再現しやすくなります。
01-sources/
02-facts.json
03-conflicts.json
04-outline.json
05-sections/
06-draft.md
07-validation.jsonどの段階で誤りが入ったかを切り分けられるため、300ページの資料を最初から再生成する必要が減ります。
まとめ
長文資料から成果物を作るときは、コンテキスト窓の大きさだけに頼らず、工程を分けます。
事実を抽出する → 根拠付きで構成する → 章ごとに書く → 元資料へ戻して検証する。この4段階にすると、抜け、混同、矛盾、根拠不明の文章を発見しやすくなります。
公式情報・一次情報
- OpenAI API ― Model guidance
- Google Gemini API ― Structured outputs
- Anthropic ― Prompting best practices
この記事の更新履歴
- 2026-09-13 追加：fact_id/source_id、矛盾管理、中間成果物、章単位生成、元資料への逆照合を追加。
- 2026-09-13 変更：一括生成型から、抽出→構成→執筆→検証の4段階パイプラインへ変更。
- 2026-09-13 削除：style_prompt、本文H1、長いCoT出力、根拠なく矛盾を自動解決する手順、「最強プロンプト」表現を削除。
