第10章：論理的な文書作成
この章で作れる成果物
この章を読み終えると、次の成果物を作れる状態を目指します。
- document task brief: 文書の目的、読み手、意思決定点、情報分類、承認者を定義する設計メモ。
- one-page summary canvas: 経営向け1枚サマリーを、結論、根拠、選択肢、リスク、依頼事項に分けるキャンバス。
- proposal skeleton: 提案書を、課題、提供価値、導入範囲、費用、リスク、次アクションへ展開する骨子。
- report / approval memo schema: 報告書と稟議メモを、事実、解釈、選択肢、推奨、承認条件へ分ける出力仕様。
- evidence-to-document traceability matrix: 文書内の主張、根拠、出所、確認日、未確認事項を結び付ける表。
- document review checklist: CARE+、読み手適合、リスク、承認、再利用条件を確認するレビューリスト。
- executive narrative / decision memo template: 経営説明や意思決定メモへ転用できる論理展開テンプレート。
第9章では、AIを安全に運用するための情報分類、リスク登録、prompt injection 対策、privacy / IP review、承認、監査ログを扱いました。本章では、その安全な運用を前提に、AIと協働しながら、1枚サマリー、提案書、報告書、稟議メモを「読んだ人が判断できる文書」へ仕上げます。
論理的な文書とは、きれいな文章ではありません。読み手、意思決定点、根拠、選択肢、リスク、依頼事項が明確で、読み手が次の行動を決められる文書です。AIは構成案、要約、表現案、レビュー観点の生成に有効ですが、結論、根拠採用、リスク許容、承認依頼の責任は人間が持ちます。
本章とAI活用の標準業務フロー
本章は、AI活用の標準業務フロー（1枚） のうち、主に次の工程に対応します。
- 1. タスク定義: 文書の目的、読み手、意思決定点、承認者、利用場面を決める。
- 2. 情報分類: 文書に入れてよい情報、匿名化する情報、AIに渡さない情報を分ける。
- 3. 文脈設計: 読み手の前提知識、制約、判断基準、参照資料を context pack にする。
- 4. 出力仕様: 文書種別ごとに、見出し、表、主張、根拠、未確認欄を schema 化する。
- 5. 手段選択: 検索 / retrieval、PDF・表の確認、tool use / MCP、手作業確認、専門部門確認の要否を決める。
- 6. 生成: AIに構成案、要約案、比較表、反論候補、表現案を出させる。
- 7. 評価: CARE+、読み手適合、文書構成、リスク、承認条件で点検する。
- 8. ファクトチェック: evidence-to-document traceability matrix で、主張、数値、引用、社内正本、出典、確認日を突き合わせる。
- 9. 編集・承認: 人間が最終版を編集し、意思決定者へ渡せる状態にする。
- 10. ログ化・再利用: task brief、出力仕様、採用版、根拠表、レビュー結果を資産化する。
AIに文書作成を依頼するときは、「文章を書いて」ではなく、「誰が、何を判断するために、どの根拠で、どの形式の成果物を必要としているか」を先に定義します。
10.1 この章で扱う業務課題
ビジネス文書の失敗は、文章表現よりも上流の設計不足から起きます。
- 読み手が、報告を求めているのか、承認を求めているのか、比較検討を求めているのかが曖昧である。
- 事実、解釈、仮説、推奨が混ざり、どこまで確認済みか分からない。
- AIが整えた文章をそのまま使い、根拠不明の数値や断定が残る。
- 提案書に顧客固有情報、契約条件、未公開情報を入れる前に、情報分類を確認していない。
- 稟議メモで、承認者が判断すべき論点、代替案、リスク、却下時の影響が見えない。
- 報告書が詳細すぎて、結論、要因、打ち手、次アクションが埋もれる。
- 1枚サマリーが要約ではなく、元資料の縮小版になっている。
- 文書を再利用するときに、どの根拠、どの版、どの承認条件に基づくかが残っていない。
本章では、文書を「成果物」として扱います。AIに文章を作らせるのではなく、成果物の仕様を設計し、根拠をつなぎ、レビューし、承認できる状態にします。
10.2 document task brief
10.2.1 文書作成は task brief から始める
document task brief は、文書作成の前提を1枚で定義するメモです。AIに入力する前に、人間が次の項目を決めます。
【document task brief】
成果物名:
文書種別: 1枚サマリー / 提案書 / 報告書 / 稟議メモ / その他
利用目的:
読み手:
読み手の関心事:
意思決定点:
依頼したい判断: 共有 / 合意 / 承認 / 予算化 / 差し戻し / 保留
期限:
情報分類: 公開 / 社内限定 / 機密 / 個人情報 / 顧客情報 / 契約情報 / 著作物
AI利用環境: 外部AI / 社内AI / AI利用不可 / 手作業中心
参照してよい資料:
AIに渡してはいけない資料:
確認済みの根拠:
未確認事項:
承認者:
最終判断者:
再利用条件:
この brief がないと、AIはもっともらしい一般文書を作れますが、実務で提出できる文書にはなりません。とくに、意思決定点、情報分類、参照してよい資料、未確認事項は先に決めます。
10.2.2 文書種別で「読み手の問い」を変える
同じ情報でも、文書種別が変わると答えるべき問いが変わります。
| 文書種別 | 読み手の主な問い | 文書の中心 | AIに任せやすい作業 | 人間が決めること |
|---|---|---|---|---|
| 1枚サマリー | 何を判断すればよいか | 結論、根拠、選択肢、依頼事項 | 要約、構成案、表現案 | 結論、優先順位、依頼内容 |
| 提案書 | なぜこの提案を選ぶのか | 課題、解決策、導入範囲、価値 | 骨子、比較表、反論候補 | 提案可否、価格、契約条件 |
| 報告書 | 何が起き、なぜそう見ているか | 事実、分析、示唆、次アクション | 論点整理、要約、表作成 | 解釈、責任範囲、対応方針 |
| 稟議メモ | 承認してよいか | 目的、費用、代替案、リスク、承認条件 | 初稿、抜け漏れ確認 | 承認依頼、リスク許容、予算判断 |
文書の目的が曖昧な場合は、本文を書き始める前に、次のように確認します。
この文書は、共有用ですか、合意形成用ですか、承認依頼用ですか。
読み手は、読み終わった後に何を決める必要がありますか。
今回の文書で決めないことは何ですか。
根拠が未確認の項目は、本文から外しますか、要確認欄へ分けますか。
10.2.3 context pack を作る
AIに文書を作らせる前に、context pack を用意します。context pack は、AIに渡す文脈、渡さない情報、出力上の制約をまとめたものです。
【context pack】
読み手:
背景:
今回の判断:
前提条件:
制約:
利用してよい根拠:
引用してよい資料:
使ってはいけない表現:
未確認として扱う情報:
出力形式:
文体:
禁止事項:
顧客名、個人情報、契約条件、営業秘密、未公開ロードマップなどは、第9章の data classification card に従って扱います。外部AIに渡せない情報は、役割名、抽象化した状況、ダミー値に置き換えるか、社内承認済み環境で扱います。
10.3 成果物の基本設計
10.3.1 結論からではなく「判断」から設計する
よくある文書作成手法では「結論から書く」と言われます。実務では、その前に「何を判断してほしいか」を決めます。
【判断から設計する順序】
1. 読み手が判断すること
2. 判断に必要な選択肢
3. 選択肢を比較する評価軸
4. 採用した根拠
5. 未確認事項とリスク
6. 推奨案
7. 依頼事項
結論は、この順序の結果として書きます。AIへ依頼するときも、最初に「判断」と「評価軸」を指定します。
【依頼例】
次の情報をもとに、部門長が来月の施策優先順位を決めるための1枚サマリー案を作成してください。
判断対象は、A案を先行するか、B案を先行するか、両方を保留するかです。
評価軸は、顧客影響、実行負荷、リスク、期限適合です。
根拠が不足している項目は、本文で断定せず「要確認」に分けてください。
10.3.2 主張と根拠を evidence-to-document traceability matrix でつなぐ
AIが作った文章は、表現が整っていても根拠が曖昧な場合があります。本章では、標準業務フローの evidence matrix を文書内の主張、本文での扱い、確認状態まで接続した派生成果物として、evidence-to-document traceability matrix と呼びます。この表はステップ8のファクトチェックで作り、ステップ7の評価では参照して、結論や表現の採否を判断します。
| 文書内の主張 | 根拠 | 出所 | 確認日 | 状態 | 本文での扱い |
|---|---|---|---|---|---|
| A案は短期導入しやすい | 既存運用手順と共通部分が多い | 社内手順書、担当者確認 | 作成時に記録 | 確認済み | 本文へ採用 |
| B案はコストが低い可能性がある | 見積前の概算 | 担当者メモ | 未確認 | 要確認 | 断定せず注記 |
| 顧客満足度が改善する | 根拠なし | なし | なし | 未採用 | 本文から削除 |
この表は、文章の裏側に置く管理表です。顧客向け提案書や稟議では、必要に応じて一部を「根拠一覧」「確認事項」として本文に入れます。
10.3.3 output schema を文書種別ごとに持つ
AIに自由記述で依頼すると、必要な項目が抜けます。文書種別ごとに出力仕様を指定します。
【共通 output schema】
1. タイトル
2. 目的
3. 読み手が判断すること
4. 結論または推奨
5. 根拠
6. 選択肢
7. リスクと制約
8. 未確認事項
9. 依頼事項
10. 次アクション
11. 確認者 / 承認者
schema は、AI出力を縛るためだけでなく、人間のレビュー観点にもなります。必要項目が空欄の場合は、AIに補完させるのではなく、情報が不足している理由を確認します。
10.4 one-page summary canvas
10.4.1 1枚サマリーの役割
1枚サマリーは、情報量を減らす資料ではありません。意思決定者が短時間で状況、判断対象、根拠、リスク、依頼事項を把握するための文書です。
【one-page summary canvas】
タイトル:
読み手:
判断してほしいこと:
結論 / 推奨:
背景:
主要根拠:
選択肢:
リスク / 制約:
未確認事項:
依頼事項:
次アクション:
1枚に収めることを目的にしすぎると、重要なリスクや未確認事項が消えます。1枚サマリーでは、詳細を省く代わりに、参照先、確認日、未確認事項を明示します。
10.4.2 改善前と改善後
【改善前】
AI活用を進めるべきです。業務効率化や品質向上が期待できます。
各部門で利用が広がっているため、当社でも導入を検討します。
【問題点】
- 何を判断してほしいか分からない。
- 根拠が一般論で、当社の状況とつながっていない。
- リスク、承認条件、次アクションがない。
【改善後】
判断してほしいこと:
来月から営業提案書の初稿作成に、承認済み社内AI環境を試験導入するか。
結論 / 推奨:
限定導入を推奨します。対象は公開情報と匿名化済み顧客課題を使う提案骨子作成に限ります。
根拠:
- 提案骨子の作成は、task brief と proposal skeleton に分解しやすい。
- 顧客名、契約条件、価格情報を除外すれば、外部漏えいリスクを下げられる。
- 第9章の policy / approval matrix により、提案責任者と法務確認を組み込める。
リスク / 制約:
- 未確認の効果数値は顧客提示資料に入れない。
- 顧客固有情報を扱う場合は社内AI環境に限定する。
- 最終版は提案責任者が承認する。
依頼事項:
2週間の試験運用と、承認済みテンプレート作成の承認をお願いします。
改善後の例は、数値効果を断定していません。根拠が未確認の情報は、本文の主張ではなく、制約または要確認事項として扱います。
10.4.3 AIで要約する前に削るものを決める
AIに長文を要約させると、重要な判断条件を落とすことがあります。要約前に、残す項目と落としてよい項目を決めます。
| 残す項目 | 理由 |
|---|---|
| 判断対象 | 読み手の行動に直結するため |
| 結論 / 推奨 | 文書の主目的であるため |
| 根拠と出所 | 説明責任に必要なため |
| リスク / 制約 | 承認判断に必要なため |
| 未確認事項 | 断定を避けるため |
| 依頼事項 | 次アクションに必要なため |
落としてよいのは、背景説明の重複、詳細な作業経緯、本文に影響しない例、未採用の表現案などです。ただし、監査上必要な情報は本文から外してもログに残します。
10.5 proposal skeleton
10.5.1 提案書は「説得」ではなく「合意形成」の文書
提案書は、相手に買わせるための文章ではありません。相手の課題、制約、判断基準を明示し、合意できる範囲を広げる文書です。
【proposal skeleton】
1. 表紙 / 提案目的
2. 相手の課題理解
3. 現状と影響
4. 提案方針
5. 解決策の範囲
6. 導入ステップ
7. 期待できる効果の扱い
8. 前提条件 / 除外範囲
9. リスクと対策
10. 体制 / 役割分担
11. 費用 / 契約条件の扱い
12. 次アクション
期待効果を書く場合は、出典、前提、算定方法、適用範囲を示します。根拠がない改善率、導入効果、他社事例は、本文の主張に使いません。サンプル値を使う場合は、サンプルであることを明記します。
10.5.2 提案書のAI協働プロセス
【提案書作成フロー】
1. document task brief を作る
2. data classification card で入力可否を確認する
3. 顧客課題を匿名化または抽象化する
4. proposal skeleton を指定して骨子を作る
5. evidence-to-document traceability matrix で主張と根拠を確認する
6. 反論・懸念・リスクをAIに列挙させる
7. 人間が提案範囲、価格、契約条件、承認条件を確定する
8. document review checklist で最終確認する
9. 承認ログと再利用条件を残す
AIには、相手の反論候補、質問候補、抜け漏れ、表現の分かりやすさを確認させると有効です。一方で、顧客課題の真偽、提案可否、価格、契約条件、法的表現、公開可否は人間が判断します。
10.5.3 反論処理を本文に組み込む
提案書では、都合のよい情報だけを並べると信頼を失います。想定反論を先に扱い、回答可能なもの、要確認のもの、受け入れるものを分けます。
| 想定反論 | 回答方針 | 根拠 | 本文での扱い |
|---|---|---|---|
| 導入負荷が高い | 段階導入を提案する | 導入範囲表、体制案 | 導入ステップへ記載 |
| 効果が不確実 | 効果測定指標を合意する | KPI候補、検証計画 | 期待効果の前提へ記載 |
| セキュリティが不安 | 情報分類と承認フローを示す | policy / approval matrix | リスク対策へ記載 |
| 費用対効果が不明 | 見積後に再評価する | 見積未確定 | 要確認事項へ記載 |
反論は、隠すものではなく、合意条件を明確にする材料です。
10.6 report / approval memo schema
10.6.1 報告書は「事実」と「解釈」を分ける
報告書では、事実、解釈、仮説、推奨を分けます。AIに要約させる場合も、この区分を schema に入れます。
【report schema】
件名:
報告目的:
対象期間 / 対象範囲:
確認済み事実:
観察された変化:
解釈 / 仮説:
根拠:
要確認事項:
リスク:
推奨アクション:
担当者 / 期限:
【表現の区分】
事実: 5月の問い合わせ件数は前月より増加した（出所: 問い合わせ管理表）。
解釈: 新機能公開後の問い合わせが増えた可能性がある。
仮説: ヘルプページの導線が不足している可能性がある。
推奨: 問い合わせ分類を見直し、上位3項目のFAQを更新する。
要確認: 問い合わせ増加が一時的か継続的かは、翌月分で確認する。
数値や順位を使う場合は、出所、抽出条件、確認日を記録します。AIが生成した数値や比率は、根拠確認なしに本文へ入れません。
10.6.2 稟議メモは承認条件を見える化する
稟議メモでは、承認者が「承認してよいか」を判断します。したがって、目的、費用、代替案、リスク、承認条件、却下時の影響を明示します。
【approval memo schema】
件名:
申請目的:
承認してほしいこと:
背景 / 課題:
推奨案:
代替案:
費用 / 工数 / 期間:
期待効果の前提:
リスクと対策:
却下または保留時の影響:
承認条件:
未確認事項:
関係部門確認:
実行責任者:
次回レビュー時点:
稟議メモでAIを使う場合は、申請内容を正当化する文章だけを作らせないようにします。代替案、反対理由、保留条件、撤退条件を出させることで、承認者が判断しやすくなります。
10.6.3 decision memo へ転用する
1枚サマリー、報告書、稟議メモの要素は、decision memo に統合できます。
【executive narrative / decision memo template】
1. 何を決めるか
2. なぜ今決めるか
3. 選択肢は何か
4. 推奨案は何か
5. 推奨案を支える根拠は何か
6. 主なリスクと緩和策は何か
7. 未確認事項は何か
8. 承認後に誰が何をするか
9. 次回見直し条件は何か
decision memo は、経営説明やプレゼンの土台になります。次章では、この文書をもとに、聞き手に合わせたプレゼン構成、想定Q&A、反対意見への対応を扱います。
10.7 AI協働によるドラフト・レビュー・承認
10.7.1 AIに任せる範囲 / 任せない範囲
| 作業 | AIに任せやすい範囲 | 人間が責任を持つ範囲 |
|---|---|---|
| 構成設計 | skeleton案、見出し案、並べ替え案 | 文書目的、読み手、意思決定点 |
| 要約 | 長文の要点候補、重複削除 | 重要論点の採否、機密情報の除外 |
| 表現改善 | 平易化、トーン調整、箇条書き化 | 断定可否、法務・契約表現 |
| 根拠整理 | 主張と根拠の対応表案 | 出所確認、根拠採用、確認日 |
| リスク抽出 | 反論候補、抜け漏れ候補 | リスク許容、承認条件、停止判断 |
| 最終版 | 校正観点、チェックリスト | 提出、承認、共有範囲、再利用条件 |
AIの出力は、初稿、観点、候補です。採用版は、人間が根拠、リスク、承認条件を確認して作ります。
10.7.2 drafting / review loop
【drafting / review loop】
1. task brief を作る
2. output schema を指定する
3. 初稿を生成する
4. 主張と根拠を evidence-to-document traceability matrix に分解する
5. CARE+で評価する
6. 読み手の問いに答えているか確認する
7. 未確認事項を本文から分離する
8. リスク、反論、承認条件を追記する
9. 人間が最終編集する
10. 承認ログと再利用条件を残す
この loop は、1回で完了するものではありません。文書のリスクが高いほど、task brief、情報分類、根拠確認、承認を前倒しします。
10.7.3 文書レビューのチェックリスト
【document review checklist】
目的:
□ 文書の目的と読み手が明確である
□ 読み手が判断することが明記されている
□ 今回決めないことが分かる
論理:
□ 結論、理由、根拠、依頼事項がつながっている
□ 事実、解釈、仮説、推奨が分かれている
□ 代替案と反論を検討している
根拠:
□ 主張ごとに出所、確認日、状態がある
□ 未確認の数値や断定を本文で採用していない
□ 引用、著作物、第三者資料の扱いを確認した
リスク:
□ 情報分類とAI利用環境が適切である
□ prompt injection や外部資料の影響を確認した
□ privacy / IP / 契約 / セキュリティの要確認事項を分けた
承認:
□ 承認者、確認者、共有範囲が明確である
□ 承認条件と保留条件が明記されている
□ ログ化、再利用条件、廃止条件を残した
レビューは、文章の美しさではなく、判断可能性を点検する作業です。
10.8 よくある失敗と改善策
10.8.1 AIの整った文章を「完成」と誤解する
整った文章でも、根拠、出所、確認日、承認条件がなければ実務文書として不十分です。AI出力は必ず evidence-to-document traceability matrix に分解します。
10.8.2 読み手の問いに答えていない
経営層は判断を、現場責任者は実行条件を、法務・情報システムはリスクと承認条件を見ます。読み手ごとに文書の中心を変えます。
10.8.3 数値や効果を根拠なしに置く
時短、売上増、コスト削減、満足度向上などの数値は、出所、算定条件、対象範囲が必要です。出典がない場合は削除するか、サンプル値、仮置き、要確認として扱います。
10.8.4 提案書が自社都合になる
機能、価格、導入ステップを並べるだけでは、相手の判断材料になりません。相手の課題、制約、懸念、代替案、合意条件を先に整理します。
10.8.5 稟議で代替案と却下時影響を書かない
承認者は、推奨案だけでは判断できません。代替案、保留条件、却下時の影響、撤退条件を提示します。
10.8.6 文書テンプレートを更新しない
AI利用後に得た改善点をテンプレートへ戻さないと、同じ失敗を繰り返します。承認後に、task brief、schema、review checklist、禁止表現、要確認欄を更新します。
10.9 人間が最終判断すべき点
AIと協働しても、次の判断は人間が行います。
- 文書の目的、読み手、意思決定点、依頼事項。
- AIに渡してよい情報、渡してはいけない情報、社内環境で扱う情報。
- どの根拠を本文へ採用し、どの情報を要確認または削除するか。
- 期待効果、費用、リスク、契約条件をどこまで書くか。
- 提案書、報告書、稟議メモの承認者と共有範囲。
- 反論、代替案、保留条件、撤退条件をどう扱うか。
- 顧客向け、公開、法務、セキュリティ、人事に関わる文書を提出してよいか。
- AI出力を再利用してよい範囲、テンプレート化してよい範囲。
- ログに残す情報、残してはいけない情報、廃止条件。
- 文書の最終責任者。
章末演習
演習10-1：document task brief を作る
自分の業務で作る予定の文書を1つ選び、document task brief を作ってください。文書種別、読み手、意思決定点、情報分類、AI利用環境、承認者を明示してください。
演習10-2：one-page summary canvas を作る
経営向け、部門長向け、プロジェクト責任者向けのいずれかを想定し、one-page summary canvas を作ってください。結論、根拠、リスク、未確認事項、依頼事項を分けてください。
演習10-3：proposal skeleton を作る
顧客向け提案、社内改善提案、研修導入提案のいずれかを題材に、proposal skeleton を作ってください。相手の課題、提案範囲、リスク、次アクションを含めてください。
演習10-4：report / approval memo schema を適用する
月次報告、障害報告、ツール導入稟議のいずれかを題材に、report schema または approval memo schema を適用してください。事実、解釈、仮説、推奨、承認条件を分けてください。
演習10-5：evidence-to-document traceability matrix と document review checklist を作る
演習10-2から10-4で作った文書案のうち1つを選び、evidence-to-document traceability matrix と document review checklist を作ってください。未確認の主張を本文に残さないように整理してください。
理解度チェック
□ document task brief を使い、文書の目的、読み手、意思決定点、情報分類を定義できる □ 1枚サマリー、提案書、報告書、稟議メモの違いを、読み手の問いで説明できる □ output schema を使い、AIに文書種別ごとの構成を指定できる □ evidence-to-document traceability matrix で、主張、根拠、出所、確認日、未確認事項を対応付けられる □ 1枚サマリーで、結論、根拠、リスク、未確認事項、依頼事項を分けられる □ 提案書で、相手の課題、提案範囲、反論、合意条件を扱える □ 報告書で、事実、解釈、仮説、推奨を分けられる □ 稟議メモで、代替案、リスク、承認条件、却下時影響を示せる □ document review checklist で、CARE+、読み手適合、根拠、リスク、承認を点検できる □ AIに任せる範囲と、人間が最終判断する範囲を分けられる
章末の要点
- 論理的な文書は、文章表現より先に、読み手、意思決定点、根拠、リスク、依頼事項を設計します。
- document task brief は、文書作成の目的、読み手、情報分類、承認者を定義する入口です。
- 1枚サマリーは、元資料の縮小版ではなく、判断に必要な結論、根拠、リスク、依頼事項を集約する文書です。
- 提案書は、相手の課題と制約を踏まえて、合意条件を明確にする文書です。
- 報告書は、事実、解釈、仮説、推奨を分けることで、読み手が状況を判断しやすくなります。
- 稟議メモは、推奨案だけでなく、代替案、リスク、承認条件、却下時影響を示します。
- evidence-to-document traceability matrix は、AIが整えた文章を、根拠確認できる実務文書へ変えるための管理表です。
- document review checklist は、CARE+、読み手適合、リスク、承認、再利用条件を確認するために使います。
次章への橋渡し
第10章では、AIと協働しながら、1枚サマリー、提案書、報告書、稟議メモを、判断可能な文書へ仕上げる方法を扱いました。次の第11章では、これらの文書をもとに、聞き手に伝わるプレゼンテーション、経営説明、想定Q&Aへ展開します。
- 前章: 第9章：AIリスク管理と倫理的配慮
- 次章: 第11章：説得力のあるプレゼンテーション
- リライト方針: 2026年版リライト契約と分割計画