付録A:実践的なツール・テンプレート集

この付録は、各章で学んだ考え方を実務で使うための「実務オペレーティングキット」です。 テンプレートはそのまま貼り付ける固定文ではありません。業務目的、情報分類、根拠、承認、ログ化をそろえ、AI出力を提出可能な成果物へ変えるための確認枠として使います。

A.0 この付録の使い方

A.0.1 利用ゲート

AIに入力する前に、次の4点を決めます。

確認項目 決めること 不十分な場合の扱い
目的 何を作り、誰のどの判断を支援するか task brief を作る
情報分類 AIへ渡せる情報、抽象化する情報、渡さない情報 data classification card を作る
出力仕様 見出し、表、必須項目、禁止表現、受け入れ基準 output schema template を作る
承認 誰が事実、リスク、契約、配布範囲を確認するか governance / approval checklist を作る

テンプレートを使う順序は、原則として次の通りです。

  1. task brief テンプレで目的、読み手、意思決定点を決める。
  2. data classification card で入力してよい情報を決める。
  3. prompt sheet と output schema template でAIへの依頼を設計する。
  4. evaluation rubric と fact-check log で出力を検証する。
  5. decision memo、meeting / decision log template、proposal skeleton などの成果物に落とす。
  6. governance / approval checklist で承認し、prompt / template の資産化ルールで再利用する。

A.0.2 この付録で扱う成果物

成果物 主な用途 関連章
task brief テンプレ AI利用前の目的、読み手、判断点の定義 第5章、第8章
data classification card 機密、個人情報、契約、公開可否の整理 第9章
prompt sheet 文脈、制約、例示、出力条件の設計 第5章
output schema template structured outputs の考え方に基づく出力仕様 第5章、第6章
evaluation rubric CARE、受け入れ基準、リスク、承認の評価 第6章
fact-check log 根拠、出所、確認日、未確認事項の追跡 第3章、第7章
decision memo template 推奨案、根拠、選択肢、リスク、承認条件の整理 第10章
meeting / decision log template 会議の決定、未決、担当、見直し条件の記録 第12章
proposal skeleton 顧客課題、提案範囲、反論、次アクションの設計 第10章、第13章
governance / approval checklist 人間の確認、承認、ログ化、再利用条件の管理 第9章、第15章
multimodal input inventory 画像、音声、画面、PDFなどの入力素材の出所と利用可否の整理 第14章
prompt / template asset register prompt / template の所有者、適用条件、更新履歴、廃止条件の管理 第15章、第17章
template improvement log 改善理由、効果、次回確認日、関連issueの追跡 第16章、第17章
人間が最終判断すべき点 AIに委ねない判断、承認、例外、責任範囲の明確化 第9章、第10章

A.1 task brief テンプレ

task brief は、AIへ依頼する前に「何を作るのか」を定義する入口です。 目的が曖昧なままAIへ依頼すると、整った文章は得られても、意思決定に使える成果物になりません。

【task brief】
案件名:
作成日:
作成者:

1. 目的
- 何を作るか:
- 誰のどの判断を支援するか:
- 完了後に起きてほしい行動:

2. 読み手 / 利用者
- 主な読み手:
- 最終判断者:
- 関係者:

3. 意思決定点
- 決めること1:
- 決めること2:
- 決めないこと / 今回の対象外:

4. 入力材料
- 事実:
- 仮説:
- 要確認:
- 使ってはいけない情報:

5. 制約
- 期限:
- 形式:
- トーン:
- 参照できる資料:
- 禁止表現:

6. 受け入れ基準
- 必須項目:
- 根拠確認:
- リスク確認:
- 承認者:

7. ログ化
- 保存先:
- 再利用条件:
- 廃止条件:

A.1.1 task brief の確認ポイント

  • 「要約してください」ではなく、「誰が何を判断するための要約か」を書く。
  • 事実、仮説、要確認を分ける。
  • 顧客名、契約条件、個人情報などをAIへ入力してよいか確認する。
  • 完成条件を「読みやすい」ではなく、成果物の受け入れ基準で定義する。

A.2 data classification card

data classification card は、AIへ入力してよい情報、抽象化すべき情報、入力禁止情報を整理するカードです。 本書では、機密情報を外部AIへ入れない前提を維持します。社内AI環境を使う場合でも、社内ルールと契約条件を確認します。

【data classification card】
対象業務:
作成日:
確認者:

1. 情報区分
- 公開情報:
- 社内限定情報:
- 機密情報:
- 個人情報:
- 契約 / 法務に関わる情報:
- 顧客固有情報:

2. AI入力可否
- 入力可:
- 要約 / 匿名化すれば入力可:
- 入力不可:
- 要承認:

3. 抽象化ルール
- 顧客名:
- 個人名:
- 金額:
- 契約条件:
- 障害 / セキュリティ詳細:

4. 出力時の注意
- 断定禁止事項:
- 出典必須事項:
- 承認が必要な表現:
- 外部共有不可の内容:

5. 承認
- 情報オーナー:
- セキュリティ確認者:
- 法務確認者:
- 確認日:

A.2.1 入力禁止情報の例

情報 扱い 理由
顧客名、取引先名 原則入力しない 顧客固有情報の保護
個人名、評価、連絡先 原則入力しない 個人情報と人事情報の保護
見積金額、契約条件 要承認 契約、法務、営業上の制約
障害ログ、脆弱性詳細 要セキュリティ確認 悪用可能性と機密性
未公開ロードマップ 原則入力しない 事業機密の保護

A.3 prompt sheet

prompt sheet は、AIへの依頼を一回限りの文章ではなく、再利用できる業務設計として残すものです。

【prompt sheet】
プロンプト名:
用途:
想定利用者:
機密区分:

【役割】
あなたは次の業務を支援します:

【目的】
この出力で達成したいこと:

【背景 / 文脈】
- 読み手:
- 意思決定点:
- 既知情報:
- 不明点:
- 制約:

【入力データ】
- 事実:
- 仮説:
- 要確認:
- 除外した情報:

【出力仕様】
- 見出し:
- 表形式:
- 必須項目:
- 文字量:
- 禁止事項:

【評価基準】
- CARE:
- 章固有基準:
- 受け入れ基準:

【人間が確認すること】
- 事実確認:
- リスク確認:
- 承認:

【ログ】
- 版:
- 作成日:
- 改訂理由:

A.3.1 プロンプト改善の指示例

次の出力を、提出前レビュー用に改善してください。

改善条件:
- 事実、仮説、要確認を分ける
- 根拠がない数値や断定を削除する
- 読み手が判断するための選択肢、リスク、次アクションを入れる
- 機密情報、個人情報、契約条件を推測しない
- 最後に人間が確認すべき点を列挙する

A.4 output schema template

output schema template は、AI出力を「自由文」ではなく、評価しやすい構造へそろえるための出力仕様です。 API実装の詳細ではなく、非技術職でも使える structured outputs の考え方として扱います。

【output schema template】
成果物名:
利用場面:

1. metadata
- 作成日:
- 作成者:
- 読み手:
- 機密区分:
- 承認者:

2. objective
- 目的:
- 意思決定点:
- 対象範囲:
- 対象外:

3. input_summary
- 事実:
- 仮説:
- 要確認:
- 除外した情報:

4. output_body
- 結論:
- 根拠:
- 選択肢:
- リスク:
- 推奨:
- 次アクション:

5. validation
- 出典 / 根拠:
- 未確認事項:
- 受け入れ基準:
- 人間の確認事項:

6. log
- 版:
- 変更理由:
- 再利用条件:

A.4.1 出力仕様の禁止事項

  • 根拠がない効果数値を本文に入れない。
  • 顧客名、個人名、契約条件を推測しない。
  • 「必ず」「確実に」など、保証に見える表現を無条件で使わない。
  • 承認前の価格、納期、法務、セキュリティ例外を確定事項として書かない。

A.5 evaluation rubric

evaluation rubric は、AI出力をCARE+と受け入れ基準で評価するための表です。 点数化よりも、修正理由と承認可否を説明できることを重視します。

観点 確認すること 判定 修正方針
Correctness / 正確性 事実、数値、出典、引用、前提が正しいか OK / NG / 要確認 fact-check log へ戻す
Appropriateness / 適切性 読み手、目的、機密区分、文体に合うか OK / NG / 要確認 task brief を修正する
Relevance / 関連性 意思決定点に直接答えているか OK / NG / 要確認 output schema template を修正する
Effectiveness / 効果性 次アクション、承認、再利用につながるか OK / NG / 要確認 governance / approval checklist で承認条件を追加する
Evidence / 根拠 主張と根拠が追跡できるか OK / NG / 要確認 fact-check log と source hierarchy へ戻す
Risk / リスク 法務、セキュリティ、誤情報、過剰断定を扱ったか OK / NG / 要確認 data classification card と governance / approval checklist に残す
Approval / 承認 誰が最終判断するか明確か OK / NG / 要確認 governance / approval checklist と meeting / decision log template に残す

A.5.1 受け入れ基準テンプレート

【acceptance criteria】
成果物名:

必須項目:
- [ ] 目的、読み手、意思決定点がある
- [ ] 事実、仮説、要確認が分かれている
- [ ] 根拠、出所、確認日が追跡できる
- [ ] 機密情報と個人情報を除外している
- [ ] リスク、代替案、次アクションがある
- [ ] 人間の承認者が明記されている
- [ ] 再利用する資産の場合、再利用条件と廃止条件がある

判定:
- 採用:
- 修正して採用:
- 不採用:
- 次回確認:

A.6 fact-check log と source hierarchy

fact-check log は、AI出力の主張を根拠に戻すための管理表です。 source hierarchy は、どの情報を優先して確認するかの階層です。

A.6.1 source hierarchy

優先度 情報源 扱い
1 自社の正本、契約書、承認済みポリシー 最優先で確認する
2 顧客が承認した資料、議事録、公式回答 対象案件では強い根拠として扱う
3 公式ドキュメント、一次情報、法令、規制当局資料 最新版と適用範囲を確認する
4 社内ナレッジ、過去提案、FAQ 更新日と適用条件を確認する
5 Web記事、ブログ、SNS、二次情報 補助情報。本文の根拠にする場合は一次情報で確認する
6 AI出力 根拠ではなく、仮説、整理、下書きとして扱う

A.6.2 fact-check log テンプレート

【fact-check log】
成果物名:
確認日:
確認者:

| ID | 主張 / 数値 / 引用 | 出所 | 確認状態 | 本文での扱い | 次の確認 |
| --- | --- | --- | --- | --- | --- |
| F-001 |  |  | OK / 要確認 / 不採用 | 採用 / 注記 / 削除 |  |

未確認事項:
-

削除した主張:
-

承認:
- 確認者:
- 承認者:
- 承認日:

A.6.3 根拠の弱い表現の扱い

  • 出典がない数値は、削除するか、演習用サンプルまたは仮置きとして明記する。
  • 「一般に」「多くの企業で」などの表現は、対象範囲が分からない場合は避ける。
  • 規制、価格、製品仕様、モデル名、期限は、一次情報と確認日を残す。
  • AIの要約を根拠として扱わない。

A.7 decision memo template

decision memo template は、選択肢と推奨案を承認者が判断できる形へ整理するテンプレートです。

【decision memo template】
件名:
作成日:
作成者:
読み手:
機密区分:

1. 決めたいこと
- 意思決定点:
- 決定期限:
- 決定しないこと:

2. 背景
- 事実:
- 仮説:
- 要確認:

3. 選択肢
| 案 | 内容 | メリット | リスク | 前提 |
| --- | --- | --- | --- | --- |
| A |  |  |  |  |
| B |  |  |  |  |
| C |  |  |  |  |

4. 推奨案
- 推奨:
- 根拠:
- 成功条件:
- 失敗時の対応:

5. リスクと対策
- リスク:
- 対策:
- 残る不確実性:

6. 承認条件
- 承認者:
- 確認が必要な部門:
- 承認前に必要な情報:

7. 次アクション
- 担当:
- 期限:
- ログ保存先:

A.8 meeting / decision log template

meeting / decision log template は、会議を「話した記録」ではなく「決定と次アクションの記録」に変えるテンプレートです。

【meeting / decision log template】
会議名:
日時:
参加者 / 参加部門:
欠席 / 共有先:
機密区分:

1. 会議目的
- 決めること:
- 共有だけの議題:
- 決めないこと:

2. アジェンダ
| 時間 | 議題 | 目的 | 必要な判断 |
| --- | --- | --- | --- |
|  |  |  |  |

3. 決定事項
| Decision ID | 決定内容 | 判断理由 | 承認者 | 見直し条件 |
| --- | --- | --- | --- | --- |
| D-001 |  |  |  |  |

4. 未決事項
| ID | 未決内容 | 保留理由 | 確認責任者 | 確認日 |
| --- | --- | --- | --- | --- |
| U-001 |  |  |  |  |

5. action / follow-up tracker
| Action ID | Action | 担当 | 期限 | 状態 | 次回確認 |
| --- | --- | --- | --- | --- | --- |
| A-001 |  |  |  |  |  |

6. 配布前レビュー
- 決定事項の確認者:
- 機密情報の確認者:
- 配布範囲:
- 確定日:

A.9 proposal skeleton

proposal skeleton は、提案書を自社都合の説明ではなく、相手の判断を支援する文書へ整える骨子です。

【proposal skeleton】
提案名:
作成日:
作成者:
読み手:
機密区分:

1. 提案目的
- 相手が判断すること:
- 提案で解決したい課題:

2. 顧客 / 相手の課題
- 事実:
- 仮説:
- 要確認:
- 対象外:

3. 提案方針
- 結論:
- 根拠:
- 代替案:
- 提案しないこと:

4. 提案範囲
- 対象業務:
- 対象外:
- 前提条件:
- 必要な体制:

5. 価値と評価方法
- 期待価値:
- 測定指標:
- 測定方法:
- 未確認事項:

6. リスクと対策
| リスク | 影響 | 対策 | 残る不確実性 | 責任者 |
| --- | --- | --- | --- | --- |
|  |  |  |  |  |

7. 想定反論と回答方針
| 反論 / 懸念 | 背景 | 回答方針 | 保留条件 | 回答責任者 |
| --- | --- | --- | --- | --- |
|  |  |  |  |  |

8. 次アクション
- 顧客確認:
- 社内承認:
- 期限:
- ログ保存先:

A.10 governance / approval checklist

governance / approval checklist は、AI出力を公開、配布、顧客提示、社内承認に進める前の確認表です。

【governance / approval checklist】
成果物名:
確認日:
確認者:

1. 情報分類
- [ ] 機密情報、個人情報、契約条件を除外または承認済みにした
- [ ] 配布範囲を確認した
- [ ] 外部共有可否を確認した

2. 正確性
- [ ] 事実、仮説、要確認を分けた
- [ ] 数値、引用、出典、確認日を確認した
- [ ] AI出力を根拠として扱っていない

3. リスク
- [ ] 法務、知財、セキュリティ、privacy の要確認事項を分けた
- [ ] prompt injection や外部入力の信頼性を確認した
- [ ] 過剰な保証表現や断定を削除した

4. 承認
- [ ] 最終編集者を記録した
- [ ] 承認者を記録した
- [ ] 承認条件と保留条件を記録した

5. ログ化
- [ ] 使用した入力、プロンプト、出力、修正理由を保存した
- [ ] 再利用条件を記録した
- [ ] 廃止条件を記録した

A.11 multimodal input inventory

PDF、画像、表、チャート、スクリーンショット、議事メモ、提案資料を扱う場合は、入力の種類と確認方法を先に整理します。

【multimodal input inventory】
案件名:
確認日:
確認者:

| ID | 入力種別 | 内容 | 機密区分 | AI入力可否 | 確認方法 |
| --- | --- | --- | --- | --- | --- |
| M-001 | PDF |  |  | 可 / 要匿名化 / 不可 | 原本確認 |
| M-002 | 画像 |  |  | 可 / 要匿名化 / 不可 | 目視確認 |
| M-003 | 表 |  |  | 可 / 要匿名化 / 不可 | 数式 / 元データ確認 |
| M-004 | グラフ |  |  | 可 / 要匿名化 / 不可 | 軸、単位、期間確認 |
| M-005 | 議事メモ |  |  | 可 / 要匿名化 / 不可 | 参加者レビュー |

注意点:
- 画像やスクリーンショット内の個人名、顧客名、URL、IDを確認する。
- グラフは軸、単位、期間、母集団を確認する。
- PDFは版、発行日、正本かどうかを確認する。
- AIの画像説明は事実確定ではなく、確認候補として扱う。

A.12 prompt / template の資産化ルール

prompt / template の資産化ルールは、使い捨てのプロンプトを組織で安全に再利用するための運用ルールです。

A.12.1 prompt / template asset register

【prompt / template asset register】
資産 ID:
名称:
用途カテゴリ:
作成日:
オーナー:
機密区分:

1. 利用条件
- 対象業務:
- 想定利用者:
- 入力してよい情報:
- 入力禁止情報:

2. テンプレート本体
- task brief:
- prompt sheet:
- output schema:
- evaluation rubric:

3. 検証履歴
| 版 | 検証日 | 結果 | 修正理由 | 承認者 |
| --- | --- | --- | --- | --- |
| v1 |  |  |  |  |

4. 再利用条件
- 使える場面:
- 使ってはいけない場面:
- 必須確認:

5. 廃止条件
- 前提が古くなった場合:
- 誤出力が増えた場合:
- ポリシー変更があった場合:
- 利用実績がなくなった場合:

A.12.2 ライフサイクル管理

状態 意味 必要な操作
draft 作成中 個人利用に限定する
pilot 試験利用中 検証結果と失敗例を残す
approved 承認済み 利用条件、承認者、改訂履歴を残す
deprecated 非推奨 代替テンプレートと廃止理由を示す
retired 廃止 使用停止日と影響範囲を記録する

A.13 継続改善ログ

テンプレートは、使った後に改善します。出力の失敗、レビュー指摘、CIやリンクチェックの結果、公開後の指摘を次の版へ戻します。

【template improvement log】
対象テンプレート:
版:
記録日:
記録者:

1. 利用結果
- 利用場面:
- 成果物:
- 良かった点:
- 問題点:

2. レビュー指摘
- 指摘内容:
- 原因:
- 修正内容:

3. 検証
- lint:
- link check:
- build:
- 公開確認:

4. 次回改訂
- 変更する項目:
- 変更しない項目:
- 廃止候補:
- 承認者:

A.14 人間が最終判断すべき点

AIを使ってテンプレートを埋めても、次の判断は人間が行います。

  • どの情報をAIへ入力してよいか。
  • どの主張を本文へ採用し、どれを要確認または削除するか。
  • 法務、知財、privacy、セキュリティ、契約条件に関わる扱い。
  • 顧客、社員、取引先への約束に見える表現の採否。
  • 価格、納期、効果、品質、責任分界の確定。
  • 最終成果物の承認、配布範囲、ログ保存、再利用条件。

A.15 関連章

  • 第3章:情報の整理と分析
  • 第5章:AIへの指示(プロンプト)設計
  • 第6章:AIの出力を評価・改善する
  • 第9章:AIリスク管理と倫理的配慮
  • 第10章:論理的な文書作成
  • 第12章:効果的な会議・議論術
  • 第13章:論理的な交渉・説得術
  • 第14章:日常業務での実践
  • 第15章:論理的思考を活かしたリーダーシップ
  • 第16章:プロジェクト管理と問題解決
  • 第17章:継続的学習と思考力向上