第8章：AI活用の具体的場面
この章で作れる成果物
この章を読み終えると、次の成果物を作れる状態を目指します。
- 業務フロー組み込みマップ: 調査、ドラフト作成、分析、会議、提案、マルチモーダル資料処理を標準業務フローへ対応づける表。
- research workflow sheet: 調査目的、source hierarchy、検索 / retrieval、要確認事項、evidence matrix への反映を整理するシート。
- drafting / review loop: 初稿、レビュー、改善指示、CARE+評価、承認条件を往復させる作成フロー。
- analysis workflow log: データや表を読む前提、分析観点、仮説、確認済み / 未確認、意思決定への示唆を残すログ。
- meeting / proposal workflow checklist: 会議準備、議事録、意思決定ログ、提案骨子、反論処理を安全に作るチェックリスト。
- multimodal intake card: PDF、画像、表、グラフ、スクリーンショット、議事メモ、提案資料をAIに扱わせる前の受け入れカード。
第7章では、AI出力や外部資料を検証し、根拠として使える情報と要確認情報を分けました。本章では、その検証済み情報と CARE+ 評価を、日常の業務フローに組み込みます。目的は、個別のプロンプト例を増やすことではありません。AIを「作業の一部」として位置づけ、どの工程で何を任せ、どこで人間が判断し、どのログを残すかを決めることです。
本章とAI活用の標準業務フロー
本章は、AI活用の標準業務フロー（1枚） の全体を、具体的な業務場面へ展開します。特に次の工程を横断します。
- 1. タスク定義: 調査、資料作成、分析、会議、提案の目的、読み手、意思決定点を決める。
- 2. 情報分類: 公開情報、社内限定、機密、個人情報、契約情報を分け、外部AI投入可否を判断する。
- 3. 文脈設計: 利用資料、前提、用語、除外情報、読み手の状態を context pack にする。
- 4. 出力仕様: 見出し、表、根拠欄、要確認欄、提出形式を output schema として固定する。
- 5. 手段選択: 通常生成、検索 / retrieval、表やPDFの読み取り、tool use / function calling、MCP連携の必要性を判断する。
- 6. 生成: 初稿、比較案、論点、反論、要確認事項を作る。
- 7. 評価: CARE+で、正確性、適切性、関連性、効果性、根拠、リスク、承認条件を点検する。
- 8. ファクトチェック: 第7章の source hierarchy と evidence matrix に戻して確認する。
- 9. 編集・承認: 人間が最終成果物へ編集し、承認者、確認日、残リスクを残す。
- 10. ログ化・再利用: task brief、指示、出力、評価、改善理由、廃止条件を資産化する。
AI活用を業務へ組み込むとは、AIを使う場面を増やすことではありません。業務成果物の品質、説明責任、再利用性を高めるために、AIを置く工程と置かない工程を設計することです。
8.1 この章で扱う業務課題
AIを使い慣れてくると、次のような問題が起きやすくなります。
- 調査、資料作成、分析、会議、提案で、それぞれ別々のプロンプトが散在する。
- どの工程で情報分類を確認したか分からない。
- AIが作った初稿を、誰がどの基準で評価したか残っていない。
- 画像、PDF、表、グラフ、スクリーンショットの読み取り結果が、根拠確認なしに本文へ入る。
- 会議メモや顧客ヒアリングのような機微情報を、外部AIに貼り付けてよいか判断しないまま使う。
- 生成された文章は整っているが、読み手の意思決定点、リスク、次アクションに接続していない。
- 使い回したテンプレートが古くなり、最新の社内ルールや承認条件と合わなくなる。
本章では、業務を「AIに頼む単発作業」ではなく、入口、処理、評価、承認、ログ化を持つワークフローとして扱います。
8.2 業務フロー組み込みマップ
8.2.1 AIを置く工程を先に決める
AI活用を始める前に、対象業務を工程に分け、AIに任せる作業、人間が判断する作業、承認が必要な作業を分けます。
| 業務場面 | AIに任せやすい作業 | 人間が判断する作業 | 主な成果物 |
|---|---|---|---|
| research | 調査観点の整理、情報源候補、比較表の初稿 | 正本の採用、要確認事項、根拠の十分性 | 調査メモ、evidence matrix |
| drafting | 構成案、初稿、表現調整、反論案 | 読み手適合、主張の採否、承認条件 | 1枚サマリー、報告書、稟議メモ |
| analysis | 分析観点、仮説、表の読み取り、可視化案 | データ定義、分析方法、結論の採否 | 分析計画、analysis workflow log |
| meeting | アジェンダ案、論点整理、議事録の構造化 | 決定事項、未決事項、発言の扱い | 会議アジェンダ、意思決定ログ |
| proposal | 提案骨子、価値訴求、想定反論、FAQ | 顧客理解、価格、契約、法務確認 | 提案骨子、反論処理シート |
| multimodal | PDF要約、画像説明、表抽出、スクリーンショット整理 | 原本確認、provenance、利用可否 | multimodal intake card |
この表は、AIを使ってよい範囲を広げるためではなく、責任分界を明確にするために使います。
8.2.2 業務フロー組み込みマップのテンプレート
【業務フロー組み込みマップ】
対象業務:
成果物:
読み手 / 承認者:
意思決定点:
情報分類:
工程:
1. 入口: task brief / data classification / context pack
2. 作成: AIに依頼する作業、人間が作る作業
3. 評価: CARE+、acceptance criteria、差し戻し条件
4. 検証: source hierarchy、evidence matrix、provenance memo
5. 承認: 承認者、承認条件、残リスク
6. 再利用: テンプレート化範囲、廃止条件、更新担当
AIに任せること:
AIに任せないこと:
社内環境でのみ扱うこと:
外部AIでは扱わないこと:
8.2.3 改善前から改善後へ
改善前の運用は、次のようになりがちです。
競合調査をAIに頼み、出てきた表を提案書に貼る。
改善後は、業務フローとして設計します。
【目的】次回提案で、価格訴求、導入支援、運用支援のどれを主軸にするか判断する。
【情報分類】顧客名、契約条件、社内価格表は外部AIに入力しない。
【AIに依頼】公開情報を前提に、競合比較の観点と根拠候補を表にする。
【人間が確認】競合公式情報、社内正本、最新の提案方針を確認する。
【出力仕様】競合名 / 公開情報 / 根拠候補 / 要確認 / 提案への示唆 / 利用可否。
【評価】根拠不明の断定、古い情報、顧客固有情報の混入があれば差し戻し。
【承認】提案責任者が採用可否を決め、提案書には確認済み情報だけを使う。
AIの作業は同じ「競合比較」でも、フロー化すると、情報分類、根拠確認、承認、再利用条件が見えるようになります。
8.3 research workflow
8.3.1 調査は「検索」ではなく「判断材料づくり」である
調査でAIを使うときの目的は、情報を多く集めることではありません。意思決定に必要な主張、根拠、前提、反論、要確認事項を整理することです。
research workflow は、次の順序で進めます。
- 調査目的と意思決定点を定義する。
- 情報分類を行い、外部AIに渡せる範囲を決める。
- source hierarchy を決める。
- AIには調査観点、検索語、根拠候補、比較表の初稿を作らせる。
- 人間が一次情報、社内正本、確認日、適用範囲を確認する。
- evidence matrix に確認済み / 要確認 / 利用不可を残す。
- 調査メモへ、推奨ではなく判断材料として反映する。
8.3.2 research workflow sheet
【research workflow sheet】
調査テーマ:
利用目的 / 読み手:
意思決定点:
期限:
情報分類:
使ってよい情報:
使ってはいけない情報:
source hierarchy:
- 一次情報:
- 社内正本 / 社内確認済み情報:
- 専門情報:
- 報道 / 解説:
- SNS / 口コミ:
- AI出力:
AIに依頼する作業:
- 調査観点の洗い出し
- 検索語 / 情報源候補の提案
- 比較表の初稿
- 反論 / 要確認事項の抽出
人間が確認する作業:
- 一次情報への到達
- 確認日 / 更新日
- 数値定義 / 対象範囲
- 社内正本との整合
- 本文利用可否
成果物:
- 調査メモ
- evidence matrix
- 要確認リスト
8.3.3 調査依頼の例
【目的】新しい営業支援ツールを導入候補に入れるか判断するため、公開情報ベースの調査メモを作る。
【読み手】営業部長、情報システム、購買担当。
【情報分類】顧客名、契約条件、社内売上データは使わない。公開情報だけを扱う。
【依頼】次の観点で、調査すべき情報源候補と確認項目を整理してください。
- 機能範囲
- 価格体系の確認方法
- セキュリティ資料の有無
- 導入支援の範囲
- 既存ツールとの連携
【出力形式】観点 / 確認したい主張 / 情報源候補 / source hierarchy / 要確認 / 判断への影響。
【制約】AI出力を根拠として扱わない。確認済みと未確認を分ける。
この依頼では、AIに「最終結論」を求めていません。調査設計と根拠候補の整理に使い、採否判断は人間が行います。
8.4 drafting / review loop
8.4.1 初稿作成はゴールではない
資料作成でAIを使うと、初稿は短時間で得られます。しかし、初稿をそのまま業務成果物にすると、根拠不足、読み手不一致、過剰な断定、リスクの欠落が残ります。drafting / review loop では、初稿、評価、改善指示、再評価、承認を一連の工程にします。
【drafting / review loop】
1. task brief を作る。
2. output schema と acceptance criteria を固定する。
3. AIに構成案または初稿を作らせる。
4. CARE+で評価し、差し戻し条件を明確にする。
5. 改善指示を出し、変更点をログに残す。
6. 第7章の手順で根拠と要確認事項を確認する。
7. 人間が最終編集し、承認条件を満たすか判断する。
8. 再利用できるテンプレートと、使い回してはいけない前提を分ける。
8.4.2 1枚サマリーの output schema
経営向け1枚サマリーでは、読み手が短時間で判断できる構造が必要です。
【output schema: 経営向け1枚サマリー】
1. 結論 / 推奨判断
2. 意思決定点
3. 背景（確認済み情報のみ）
4. 選択肢
5. 比較軸
6. 根拠候補 / 確認状態
7. 主要リスク / 緩和策
8. 要確認事項
9. 次アクション / 承認者 / 期限
8.4.3 改善指示の例
改善指示:
初稿を、経営向け1枚サマリーとして再構成してください。
修正条件:
- 冒頭に「何を決める資料か」を1文で置く。
- 確認済みの情報と要確認情報を分ける。
- AIが推測した効果は本文で断定せず、要確認欄へ移す。
- 選択肢を3案以内に絞り、比較軸を固定する。
- リスクと緩和策を最低1つずつ書く。
- 最終承認者、確認日、次アクションを入れる。
- 顧客名、契約条件、未公開数値は含めない。
このように、改善指示は「もっと分かりやすく」ではなく、受け入れ基準を満たすための具体条件にします。
8.5 analysis workflow
8.5.1 分析では「計算」より前提を管理する
表やデータをAIに扱わせる場合、重要なのは、AIが計算できるかどうかだけではありません。データ定義、欠損、対象期間、集計粒度、利用権限、解釈の限界を管理することです。
分析にAIを使う場面では、次を分けます。
| 項目 | AIに支援させること | 人間が確認すること |
|---|---|---|
| 分析目的 | 仮説、分析観点、比較軸の提案 | 意思決定点と整合しているか |
| データ理解 | 列名、単位、欠損候補の整理 | データ定義、取得元、利用権限 |
| 可視化 | グラフ候補、表構成、説明文の初稿 | 軸、母集団、誤解しやすい表現 |
| 解釈 | 仮説、要因候補、追加確認事項 | 因果と相関の混同、現場知識 |
| 報告 | サマリー、リスク、次アクション | 承認、根拠、未確認事項 |
8.5.2 analysis workflow log
【analysis workflow log】
分析テーマ:
利用目的 / 読み手:
意思決定点:
データ分類:
データ取得元:
対象期間 / 母集団:
集計単位:
除外条件:
AIに渡した範囲:
AIに渡していない範囲:
分析観点:
仮説:
確認済みの結果:
未確認 / 追加確認:
解釈上の注意:
採用する可視化:
採用しない可視化:
意思決定への示唆:
承認者:
ログ化 / 再利用条件:
8.5.3 分析依頼の例
【目的】月次売上レポートの初稿を作る前に、分析観点と可視化案を整理する。
【情報分類】実データは社内限定であり、外部AIには投入しない。ここでは匿名化した列名とサンプル構造だけを扱う。
【列の概要】月、地域、商品カテゴリ、売上、粗利、案件数、チャネル。
【依頼】経営向けレポートに使う分析観点、必要な確認事項、グラフ候補を提案してください。
【出力形式】観点 / 必要データ / 可視化案 / 誤解リスク / 人間が確認すること。
【制約】数値結果を推測しない。因果関係を断定しない。追加確認事項を明示する。
AIは、分析観点と説明構造の支援に使えます。一方、数値結果の確定、原因の特定、経営判断への採用は、人間がデータ定義と根拠を確認して行います。
8.6 meeting workflow
8.6.1 会議は「発言の要約」ではなく「意思決定ログ」にする
会議でAIを使う場合、単に議事録を作るだけでは不十分です。会議の目的は、情報共有、論点整理、意思決定、合意形成、次アクションの明確化です。meeting workflow では、会議前、会議中、会議後を分けます。
| タイミング | AIに支援させること | 人間が判断すること | 成果物 |
|---|---|---|---|
| 会議前 | アジェンダ案、論点、事前確認事項 | 目的、参加者、決定したいこと | アジェンダ、事前資料 |
| 会議中 | 論点メモ、未決事項候補、ToDo候補 | 発言の意味、合意、決定事項 | 論点整理メモ |
| 会議後 | 議事録構造化、意思決定ログ初稿 | 決定事項、担当、期限、共有範囲 | 議事録、decision log |
会議メモには、個人情報、顧客名、未公開の戦略、評価情報が含まれることがあります。外部AIを使う前に、情報分類と匿名化を行います。
8.6.2 meeting / decision log の output schema
【output schema: meeting / decision log】
1. 会議目的
2. 参加ロール（実名が不要な場合は役割名）
3. 決定事項
4. 未決事項
5. 判断に使った根拠
6. 反対意見 / 懸念
7. ToDo（担当 / 期限 / 成果物）
8. 要確認事項
9. 共有範囲
10. 承認者 / 確認日
8.6.3 会議後整理の依頼例
【目的】会議メモを、意思決定ログと次アクションに整理する。
【情報分類】顧客名、個人名、未公開数値は匿名化済み。外部AIには原文ではなく要点メモだけを渡す。
【依頼】次のメモから、決定事項、未決事項、ToDo、要確認事項を分けてください。
【出力形式】区分 / 内容 / 根拠メモ / 担当 / 期限 / 確認者。
【制約】決定されたと書けるものだけを決定事項にする。発言から推測した内容は要確認へ入れる。
会議後のAI活用では、「それらしい結論」を作らせないことが重要です。合意されていない事項は、未決事項または要確認として残します。
8.7 proposal workflow
8.7.1 提案では「説得」より「判断可能性」を優先する
提案書や営業資料でAIを使うと、表現が滑らかになり、価値訴求も作りやすくなります。しかし、商用レベルの提案では、顧客の意思決定点、根拠、選択肢、リスク、次アクションが明確であることが重要です。
proposal workflow は、次の流れで進めます。
- 顧客課題、制約、意思決定者、承認プロセスを整理する。
- 顧客固有情報を外部AIへ入力してよいか判断する。
- 提案骨子、価値仮説、想定反論をAIに作らせる。
- 人間が顧客理解、契約条件、価格、実現可能性を確認する。
- 第6章の CARE+ で表現、根拠、リスク、承認条件を評価する。
- 第7章の手順で公開情報、顧客発言、社内正本を検証する。
- 最終提案書へ、確認済み情報と要確認事項を分けて反映する。
8.7.2 提案骨子テンプレート
【提案骨子テンプレート】
顧客の状況:
顧客の意思決定点:
確認済みの課題:
仮説段階の課題:
提案の主メッセージ:
選択肢:
推奨案:
根拠:
想定反論:
反論への回答:
リスク / 緩和策:
導入条件:
次アクション:
承認 / 法務 / セキュリティ確認:
8.7.3 反論処理シート
提案でAIを使う価値は、綺麗な説明文だけではありません。反論、懸念、代替案を先に出し、提案の弱点を補うことにもあります。
| 想定反論 | 背景 | 回答方針 | 根拠 | 要確認 | 人間の判断 |
|---|---|---|---|---|---|
| 費用対効果が不明 | 効果測定の前提が未確定 | 試行範囲と評価指標を提示 | 過去案件、社内試算 | 顧客KPI | 提案責任者が採用可否を判断 |
| 導入負荷が高い | 現場工数への懸念 | 段階導入と支援体制を提示 | 導入計画案 | 現場体制 | PMが実現可能性を確認 |
| セキュリティが不安 | データ取扱いの懸念 | 情報分類と権限管理を提示 | セキュリティ資料 | 法務 / 情シス | 専門部門確認後に記載 |
反論処理は、顧客を説得するためだけでなく、自社の提案リスクを早めに見つけるためにも使います。
8.8 multimodal workflow
8.8.1 マルチモーダル資料は「読める」前に「扱ってよいか」を確認する
PDF、画像、表、グラフ、スクリーンショット、議事メモ、提案資料は、AIに読み取らせる前に受け入れ条件を確認します。特に、個人情報、顧客名、契約情報、未公開数値、著作権・利用許諾、加工履歴が問題になります。
8.8.2 multimodal intake card
【multimodal intake card】
対象資料:
形式: PDF / 画像 / 表 / グラフ / スクリーンショット / 議事メモ / 提案資料
利用目的:
読み手:
情報分類:
外部AI投入可否:
匿名化 / マスキング要否:
作成者 / 入手元:
公開日 / 更新日 / 取得日:
加工履歴:
provenance確認:
読み取ってよい範囲:
読み取ってはいけない範囲:
AIに依頼する作業:
AIに判断させないこと:
確認担当:
利用可否: 利用可 / 条件付き利用 / 要確認 / 利用不可
8.8.3 形式別の注意点
| 形式 | AIに依頼しやすいこと | 人間が確認すること |
|---|---|---|
| 目次、要点、論点、引用候補の抽出 | 版、発行元、ページ、引用条件 | |
| 画像 | 写っている要素の説明、分類候補 | 撮影者、加工有無、権利、文脈 |
| 表 | 列の意味、欠損候補、集計観点 | データ定義、単位、母集団、権限 |
| グラフ | 軸、傾向、注記候補 | 元データ、対象期間、誤解リスク |
| スクリーンショット | 画面要素の整理、操作説明の初稿 | 取得日時、原本、個人情報、真正性 |
| 議事メモ | 論点、ToDo、未決事項の整理 | 決定事項、発言者、共有範囲 |
| 提案資料 | 構成レビュー、反論抽出 | 顧客固有条件、契約、法務確認 |
8.8.4 マルチモーダル依頼の例
【目的】公開PDFの要点を、社内検討用の調査メモに整理する。
【情報分類】PDFは公開資料。添付する社内スクリーンショットは外部AIに渡さない。
【依頼】PDFから、意思決定に関係する主張、数値、要確認事項を抽出してください。
【出力形式】ページ / 主張 / 根拠候補 / 要確認 / 調査メモへの使い方。
【制約】ページ番号を明記する。読み取れない箇所は推測しない。PDFの主張を自社にそのまま適用しない。
マルチモーダル活用では、AIの読み取り結果がもっともらしく見えるため、確認ログが特に重要です。読み取り結果は、provenance memo と evidence matrix に接続して使います。
8.9 よくある失敗
8.9.1 プロンプト集だけを配布する
プロンプト例だけを配布すると、情報分類、根拠確認、承認条件が抜け落ちます。テンプレートには、task brief、data classification、output schema、acceptance criteria、ログ化条件を含めます。
8.9.2 AI出力を「業務標準」と誤解する
AI出力は業務標準の候補であり、承認済みの業務手順ではありません。標準化する前に、社内正本、承認者、適用範囲、廃止条件を決めます。
8.9.3 マルチモーダル資料の原本確認を省略する
PDF、画像、表、グラフ、スクリーンショットは、読み取れたように見えても、出所、版、加工履歴、単位、対象期間が不明なことがあります。重要判断には原本確認を組み合わせます。
8.9.4 会議の合意事項をAIに推測させる
AIは発言から結論らしい文を作れますが、実際に合意されたかは別です。決定事項、未決事項、要確認事項を分け、参加者または承認者が確認します。
8.9.5 再利用テンプレートを更新しない
一度作ったテンプレートも、社内ルール、承認者、対象業務、利用可能な環境が変わると不適合になります。更新日、適用範囲、廃止条件を残します。
8.10 人間が最終判断すべき点
AIを業務フローへ組み込んでも、次の判断は人間が行います。
- その業務でAIを使う目的と、使わない目的を分けること。
- 外部AI、社内AI、手作業、専門家確認のどれを選ぶか。
- どの情報をAIに渡してよいか、匿名化やマスキングが必要か。
- AI出力を採用、条件付き採用、差し戻し、不採用、保留のどれにするか。
- 画像、PDF、表、グラフ、スクリーンショットの読み取り結果を根拠にできるか。
- 会議や顧客対応で、発言や要望をどこまで本文に残すか。
- 提案、稟議、顧客向け文書で、誰の承認を必要とするか。
- テンプレートやプロンプトを、どの範囲で再利用してよいか。
- ログに残す情報と、残してはいけない情報を分けること。
章末演習
演習8-1：業務フロー組み込みマップを作る
あなたの業務から、調査、資料作成、分析、会議、提案のいずれかを1つ選び、業務フロー組み込みマップを作ってください。AIに任せる作業、人間が判断する作業、承認が必要な作業を分けてください。
演習8-2：research workflow sheetを作る
「新しい業務ツールを導入候補に入れるか」を題材に、research workflow sheet を作ってください。source hierarchy、使ってよい情報、使ってはいけない情報、evidence matrix への反映方法を含めてください。
演習8-3：drafting / review loopを設計する
経営向け1枚サマリー、稟議メモ、報告書のいずれかを題材に、output schema、acceptance criteria、改善指示、承認条件を設計してください。
演習8-4：meeting / proposal workflow checklistを作る
会議または提案活動を1つ選び、会議前、会議中、会議後、または提案前、提案中、提案後のチェックリストを作ってください。決定事項、未決事項、要確認事項を分けてください。
演習8-5：multimodal intake cardを作る
PDF、画像、表、グラフ、スクリーンショット、議事メモ、提案資料のいずれかを題材に、multimodal intake card を作ってください。外部AI投入可否、匿名化、provenance、読み取ってよい範囲を明示してください。
理解度チェック
□ AI活用を、単発プロンプトではなく業務フローとして設計できる □ research、drafting、analysis、meeting、proposal、multimodal の各場面で、AIに任せる作業と人間が判断する作業を分けられる □ task brief、data classification、context pack、output schema、acceptance criteria を成果物ごとに用意できる □ CARE+評価と source hierarchy / evidence matrix を、調査・資料作成・分析・提案へ接続できる □ PDF、画像、表、グラフ、スクリーンショットを扱う前に、multimodal intake card と provenance を確認できる □ 会議メモや顧客情報を、情報分類と匿名化なしに外部AIへ投入しないと説明できる □ 再利用するテンプレートに、適用範囲、更新日、承認者、廃止条件を残せる
章末の要点
- AI活用を業務へ組み込むとは、AIを使う場所、使わない場所、人間が判断する場所を設計することです。
- research workflow では、AIを根拠ではなく調査設計と根拠候補の整理に使います。
- drafting / review loop では、初稿、CARE+評価、改善指示、再評価、承認を往復させます。
- analysis workflow では、数値結果より前に、データ定義、対象期間、母集団、解釈の限界を管理します。
- meeting workflow では、議事録を発言要約で終わらせず、意思決定ログへ変換します。
- proposal workflow では、説得表現より、顧客が判断できる根拠、選択肢、リスク、次アクションを優先します。
- multimodal workflow では、PDF、画像、表、グラフ、スクリーンショットを、読み取る前に扱ってよいか確認します。
- テンプレートの再利用には、適用範囲、更新日、承認者、廃止条件が必要です。
次章への橋渡し
第8章では、検証済み情報と CARE+ 評価を、調査、資料作成、分析、会議、提案、マルチモーダル資料処理へ組み込む方法を扱いました。次の第9章では、これらのフローを安全に運用するために、情報分類、機密・個人情報、prompt injection、著作権・知財、監査ログ、human-in-the-loop、社内ポリシーと承認フローを扱います。
- 前章: 第7章：批判的思考とメディアリテラシー
- 次章: 第9章：AIリスク管理と倫理的配慮
- リライト方針: 2026年版リライト契約と分割計画