この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。OpenAIの現在のモデルガイダンスとGoogleのプロンプト設計・Structured Outputs公式情報を確認し、旧版の複雑な多段指示を、事実抽出・構成・執筆・校正という明確な工程へ整理しました。検証ステータス：📘 OpenAI・Google公式情報確認済み／特定文字数・特定モデルでの比較試験は未実施
長いインタビュー録や議事録をそのままLLMへ渡して「技術記事にして」と頼むと、要点が抜けたり、逆に元資料にない説明が足されたりすることがあります。
そこで、抽出・構成・執筆・校正を別工程に分けると、どこで情報が変わったか確認しやすくなります。
4段階に分ける
flowchart LR
A[生データ] --> B[事実抽出]
B --> C[構成案]
C --> D[本文執筆]
D --> E[校正・照合]
Step 1: 事実抽出
最初は文章をきれいにせず、元資料に書かれている事実だけを抜き出します。
元資料から次を抽出してください。
- 技術的課題
- 実施した対策
- 数値・日付
- 固有名詞
- 発言者の意見
- 未確認事項
元資料にない補足は追加しないでください。
この段階では、記事らしさよりも出典との対応を優先します。
Step 2: 構成案
抽出した事実を使って、読者向けの順序へ並べます。
| 章 | 役割 |
|---|---|
| 導入 | 何が課題だったか |
| 背景 | なぜその課題が重要か |
| 対応 | 何を実施したか |
| 結果 | 何が変わったか |
| 注意点 | 再現時に気を付ける点 |
各章に、Step 1のどの事実を使うかIDを付けると追跡しやすくなります。
Step 3: 本文執筆
構成案と抽出済み事実だけを使って本文を書いてください。
ルール:
- 未確認事項を事実のように断定しない
- 数値と固有名詞を変更しない
- 補足が必要な箇所は [要確認] とする
- 章ごとの目的を変えない
Step 4: 校正・照合
最後に、読みやすさだけでなく元資料との一致を確認します。
- 元資料にない事実が追加されていないか
- 数値・日付・製品名が変わっていないか
- 発言者の意見と事実が混ざっていないか
- 重要な事実が構成から落ちていないか
- [要確認] が残っていないか
中間成果物を残す
最終記事だけ保存すると、後から「この記述はどこから来たか」を追えません。
01-source.txt
02-facts.json
03-outline.md
04-draft.md
05-review.md
工程ごとに保存しておけば、人間レビューや再生成もしやすくなります。
構造化できる部分は型を使う
事実抽出のように機械処理したい部分は、対応APIのStructured Outputsで型を固定できます。たとえば、fact_id、category、source_quote、statusのような項目を定義しておけば、次工程へ渡しやすくなります。
ただし、形式が正しいことと内容が正しいことは別なので、元資料との照合は必要です。
長文では「何を渡すか」を絞る
執筆工程で毎回1万字の全文を渡すのではなく、必要なら抽出済み事実と該当箇所だけを渡します。固定ルールは前、変動する素材は後ろに置くと、プロンプトの再利用やキャッシュもしやすくなります。
まとめ
長文から記事を作るときは、1回の生成で完成させるより、事実抽出 → 構成 → 執筆 → 校正に分ける方が管理しやすくなります。
中間成果物を残し、元資料との対応を追えるようにすると、AIが使えない状況でも人間が確認・修正を続けられる工程になります。
公式情報・一次情報
- OpenAI API ― Model guidance
- Google AI for Developers ― Prompt design strategies
- Google AI for Developers ― Structured outputs
この記事の更新履歴
- 2026-09-13 追加：4段階パイプライン、中間成果物、元資料照合、Structured Outputsの使い分けを追加。
- 2026-09-13 変更：複雑な多段指示から、成果物単位で確認できる編集工程へ変更。
- 2026-09-13 削除：style_prompt、本文H1、旧モデル前提、自己採点だけで品質を保証する記述を削除。
