第14章：日常業務での実践

この章で作れる成果物

この章を読み終えると、次の成果物を作れる状態を目指します。

• daily work task brief: メール、チャット、報告、相談、資料確認の目的、読み手、制約、判断点を整理する入口メモ。
• communication intent card: 誰に、何を、どの粒度で、どの媒体で伝えるかを決める意図カード。
• async message draft: メールやチャットで、結論、背景、依頼、期限、確認事項を明確にした非同期メッセージ案。
• chat decision capture: チャット上の決定、保留、担当、期限、根拠を流れない形で残す記録。
• report / status update brief: 進捗、課題、リスク、判断依頼、次アクションを読み手別に整理する報告メモ。
• consultation / decision request memo: 相談や判断依頼で、事実、論点、選択肢、推奨案、必要承認を提示するメモ。
• multimodal input inventory: PDF、画像、表、グラフ、スクリーンショット、議事メモなどの入力資料を分類する一覧。
• source / evidence extraction table: 資料から抽出した事実、出所、ページ、日時、要確認点を残す表。
• chart / screenshot reading note: グラフ、画面、表、図から読み取った事実、解釈、限界を分けるメモ。
• work follow-up log: 日常業務の依頼、回答、判断、未決事項、再利用可能なテンプレを残すログ。

第13章では、営業ヒアリング、提案骨子、反論処理、交渉を扱いました。本章では、メール、チャット、報告、相談、提案フォロー、PDFや画像を含む資料確認など、毎日の業務をAIと協働しながら安全に回す方法へ展開します。

日常業務は小さな作業の集合に見えます。しかし、曖昧な依頼、文脈不足のチャット、根拠のない報告、未分類の資料入力が積み重なると、意思決定の遅延、誤解、情報漏えい、手戻りにつながります。AIを使う場合も、文章を整える前に、目的、読み手、入力資料、情報分類、承認範囲、ログ化方法を決めることが重要です。

本章とAI活用の標準業務フロー

本章は、AI活用の標準業務フロー（1枚） のうち、主に次の工程に対応します。

• 1. タスク定義: daily work task brief で、目的、読み手、判断点、期限、承認要否を定義する。
• 2. 情報分類: multimodal input inventory で、公開情報、社内限定、顧客情報、個人情報、契約情報、画像・PDF内の機密を分類する。
• 3. 文脈設計: communication intent card で、読み手の立場、前提知識、必要な粒度、媒体を決める。
• 4. 出力仕様: async message draft、report / status update brief、consultation / decision request memo、chart / screenshot reading note の形式を定義する。
• 5. 手段選択: メール、チャット、ドキュメント、会議、チケット、共有資料、手作業確認を使い分ける。
• 6. 生成: AIに下書き、要約、論点整理、資料からの抽出、比較表、次アクション案を作らせる。
• 7. 評価: CARE+、読み手適合、事実と解釈の分離、情報分類、承認条件、実行可能性で点検する。
• 8. ファクトチェック: source / evidence extraction table と chart / screenshot reading note で、出所、ページ、画面、表の意味を確認する。
• 9. 編集・承認: 人間が送信、共有、対外回答、意思決定、機密情報の扱いを承認する。
• 10. ログ化・再利用: chat decision capture と work follow-up log に、決定、保留、担当、期限、再利用できる型を残す。

AIに「このメールをいい感じにして」と渡す前に、何のために、誰に、どこまで確定した内容として伝えるのかを定義します。

14.1 この章で扱う業務課題

日常業務の失敗は、文章力だけの問題ではありません。多くは、目的、読み手、資料、判断、承認の設計不足から生じます。

• チャットで依頼したつもりだが、期限、成果物、判断者が書かれていない。
• メールの文面は丁寧だが、相手が何をすればよいか分からない。
• 報告が「頑張ったこと」の列挙になり、判断材料やリスクが見えない。
• PDFやスクリーンショットをAIに渡す前に、機密情報や個人情報を確認していない。
• グラフから読み取れる事実と、そこからの解釈を混同している。
• AIの要約をそのまま会議メモや顧客回答に転用し、誤記や未確認事項を見逃す。
• チャット上の合意が流れ、後から誰が何を決めたのか分からなくなる。
• よく使う依頼文や報告テンプレが個人任せで、チームの品質が安定しない。

本章では、日常業務を「文章作成」ではなく「小さな意思決定と情報処理の連鎖」として扱います。

14.2 daily work task brief

14.2.1 小さな仕事にも入口を作る

daily work task brief は、メール、チャット、報告、相談、資料確認を始める前に、目的と制約を決める入口メモです。

【daily work task brief】
業務名:
利用場面: メール / チャット / 報告 / 相談 / 依頼 / 資料確認 / 提案フォロー
読み手 / 相手:
読み手の役割: 上長 / 同僚 / 部下 / 顧客 / 他部門 / 経営層 / 外部パートナー
目的:
相手にしてほしいこと:
判断が必要な点:
期限:
入力資料:
情報分類: 公開 / 社内限定 / 顧客情報 / 個人情報 / 契約情報 / 画像内機密 / AI利用不可
AI利用環境: 外部AI / 社内AI / AI利用不可 / 手作業中心
出力形式: メール / チャット / 報告メモ / 相談メモ / 要約 / 表 / チケット
確定している事実:
仮説 / 推測:
要確認事項:
承認者:
ログ化先:
再利用条件:

日常業務ほど、brief を省略しがちです。しかし、短いメッセージでも、目的、期限、相手の次アクションが曖昧なら手戻りが起きます。AIに下書きを依頼する場合も、brief があると、不要な補足や断定を減らせます。

14.2.2 作業の型を選ぶ

同じ情報でも、媒体によって適切な粒度が変わります。

AIに任せる前に、どの成果物を作るのかを決めます。成果物が曖昧なまま生成すると、読みやすいが使いにくい文章になりやすくなります。

14.3 communication intent card

14.3.1 誰に何をしてもらうかを決める

communication intent card は、非同期コミュニケーションの意図を明確にするカードです。

【communication intent card】
相手:
相手の前提知識:
媒体: メール / チャット / ドキュメント / チケット
目的: 報告 / 相談 / 依頼 / 共有 / 合意 / 注意喚起
相手に求める反応: 了承 / 回答 / 判断 / 作業 / レビュー / 共有のみ
重要度:
期限:
本文に含めること:
本文から外すこと:
断定できないこと:
確認質問:
添付 / 参照資料:
送信前の承認要否:

「共有です」「相談です」「判断してください」が混ざると、読み手は動きにくくなります。AIには、相手に求める反応を明示してから文面を作らせます。

14.3.2 媒体別の設計

短いチャットで済む内容を長いメールにする必要はありません。一方で、重要な決定をチャットの流れに残すだけでは不十分です。媒体を選ぶことも論理設計の一部です。

14.4 async message draft

14.4.1 メールとチャットを成果物として扱う

async message draft は、非同期で相手が動けるようにする文面案です。

【async message draft】
件名 / 冒頭:
結論:
背景:
相手に依頼したいこと:
期限:
判断に必要な材料:
未確定事項:
相手が迷いそうな点:
次アクション:
添付 / 参照:

文章の丁寧さより先に、相手が次に何をすればよいかを設計します。

14.4.2 改善前と改善後

改善前:

お疲れさまです。先日の資料について、念のため確認いただけますでしょうか。
問題なければ進めたいと思っています。よろしくお願いします。

問題点:

• どの資料か分からない。
• 何を確認すればよいか分からない。
• いつまでに回答が必要か分からない。
• 「問題なければ」の条件が分からない。

改善後:

件名: 提案資料ドラフトの確認依頼（5月27日午前まで）

結論: 提案資料ドラフトについて、顧客へ共有してよい状態か確認をお願いします。

確認してほしい点:
1. 顧客名、契約条件、価格表記に共有不可情報が含まれていないか
2. 効果に関する表現が、未測定の断定になっていないか
3. 次回会議で顧客に依頼する事項が明確か

期限: 5月27日午前まで
未確定事項: 効果測定の数値は未確定のため、本文では「試験で確認する」と表現しています。
次アクション: 問題がなければ、5月27日午後に顧客へ送付します。

改善後は、相手の確認観点、期限、未確定事項、次アクションが明確です。AIに改善を依頼する場合は、この観点を受け入れ基準として指定します。

14.4.3 チャットの決定を流さない

チャットは便利ですが、決定と雑談が混ざりやすい媒体です。決定が出たら、chat decision capture に移します。

【chat decision capture】
話題:
決定事項:
根拠:
保留事項:
担当:
期限:
関連資料:
承認者:
ログ化先:

例:

話題: 提案資料の顧客共有
決定事項: 価格表を除いた版を先に共有する
根拠: 契約条件は購買確認前のため
保留事項: 価格表の共有可否、効果測定表現
担当: 営業担当が価格表除外版を作成、法務が契約表現を確認
期限: 次回会議前営業日
ログ化先: work follow-up log

AIには、チャットの要約だけでなく、決定、保留、担当、期限の抽出を依頼します。ただし、チャットに含まれる個人情報や未公開情報は、利用環境に応じて匿名化または除外します。

14.5 report / status update brief

14.5.1 報告を読み手の判断材料にする

report / status update brief は、進捗や状況を、読み手が判断できる形にする報告メモです。

【report / status update brief】
件名:
読み手:
今回の結論:
進捗:
完了したこと:
未完了 / 遅延:
課題 / リスク:
判断してほしいこと:
支援してほしいこと:
次アクション:
期限:
根拠資料:
要確認事項:

報告は、作業量の説明ではなく、読み手の判断を支援するためにあります。特に上長や関係部門向けの報告では、進捗、リスク、判断依頼を分けます。

14.5.2 事実、解釈、依頼を分ける

AI要約は、事実と解釈を混ぜることがあります。報告に使う前に、どこが事実で、どこが仮説かを人間が確認します。

14.6 consultation / decision request memo

14.6.1 相談を「困っています」で終わらせない

consultation / decision request memo は、相手に判断してもらうための相談メモです。

【consultation / decision request memo】
相談したいこと:
背景:
決める必要があること:
事実:
制約:
選択肢:
推奨案:
推奨理由:
リスク:
判断期限:
必要承認:
次アクション:

相談では、完璧な答えを持っていく必要はありません。ただし、何を決めたいのか、どこまで調べたのか、どの選択肢があるのかは整理します。

14.6.2 選択肢を比較する

【選択肢比較】
論点: 顧客向け資料にスクリーンショットを含めるか

| 選択肢 | メリット | リスク | 必要確認 | 推奨度 |
| --- | --- | --- | --- | --- |
| そのまま掲載 | 画面イメージが伝わる | 顧客名や内部IDが見える可能性 | 画像内機密の確認 | 低 |
| マスクして掲載 | 具体性と安全性を両立しやすい | マスク漏れの確認が必要 | security確認 | 中 |
| 図に作り直す | 機密を避けやすい | 作成工数が増える | デザイン確認 | 高 |

AIに比較表を作らせる場合は、前提と評価軸を指定します。評価軸がない比較表は、見やすくても判断に使えません。

14.7 multimodal input inventory

14.7.1 PDF、画像、表、グラフ、スクリーンショットを入力として扱う

multimodal input inventory は、AIに渡す、または人間が確認する入力資料の一覧です。

【multimodal input inventory】
案件 / 業務名:

| 資料 | 種別 | 出所 | 更新日 | 情報分類 | AI入力可否 | 使う目的 | 注意点 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 提案資料.pdf | PDF | 顧客共有予定資料 | 2026-05-25 | 社内限定 / 顧客情報含む | 社内AIのみ | 要約、論点抽出 | 顧客名、価格表記 |
| 画面.png | スクリーンショット | 検証環境 | 2026-05-25 | 社内限定 | 匿名化後可 | 操作説明 | ユーザー名、ID |
| 売上表.xlsx | 表 | 社内管理資料 | 2026-05-25 | 社内限定 | 集計値のみ可 | 傾向確認 | 個別顧客名 |
| グラフ画像 | 画像 | 報告書下書き | 2026-05-25 | 社内限定 | 要確認 | 読み取り確認 | 軸、単位、注記 |

マルチモーダル活用では、画像やPDFの中に機密情報が埋もれることがあります。ファイル名だけで判断せず、画面内の氏名、ID、顧客名、契約条件、価格、内部 URL、通知内容を確認します。

14.7.2 AI入力可否を決める

AIに資料を渡す前の分類が曖昧な場合は、AIを使わず、関係部門に確認します。

14.8 source / evidence extraction table

14.8.1 要約の前に根拠を抽出する

source / evidence extraction table は、PDF、表、議事メモ、提案資料から、使ってよい根拠を抽出する表です。

【source / evidence extraction table】
| 抽出内容 | 種別 | 出所 | 位置 | 更新日 | 確認状態 | 使い道 | 要確認 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 顧客は次回会議で導入条件を確認予定 | 事実 | 議事メモ | 2ページ | 2026-05-25 | 確認済み | 報告メモ | なし |
| 既存手順は部門ごとに異なる | 事実 | ヒアリングメモ | 箇条書き | 2026-05-25 | 要確認 | 課題整理 | 対象部門 |
| 効果は試験後に測定する | 方針 | 提案資料 | 5ページ | 2026-05-25 | 確認済み | 顧客回答 | 表現範囲 |
| 画面上に顧客 IDが表示される | 事実 | スクリーンショット | 右上 | 2026-05-25 | 確認済み | 画像マスク | マスク漏れ |

要約は便利ですが、根拠の位置が分からない要約は確認しにくくなります。AIには、要約と同時に出所、ページ、表番号、画面位置を出すように依頼します。

14.8.2 chart / screenshot reading note

chart / screenshot reading note は、グラフや画面から読み取ったことを、事実、解釈、限界に分けるメモです。

【chart / screenshot reading note】
対象:
目的:

| 観点 | 内容 |
| --- | --- |
| 見えている事実 | 棒グラフではAカテゴリが最も大きい。画面右上に内部IDが表示されている。 |
| 出所 / 更新日 | 報告書ドラフト、2026-05-25更新。 |
| 単位 / 範囲 | 集計期間、対象部門、軸の単位を確認する。 |
| 解釈 | Aカテゴリへの対応優先度が高い可能性がある。 |
| 限界 | 元データ、集計方法、除外条件が未確認。 |
| 次に確認すること | 元表、集計条件、表示されている個人情報や顧客情報。 |

画像やグラフは、見た目が強い根拠に見えます。だからこそ、AIの読み取り結果を鵜呑みにせず、軸、単位、凡例、注記、切り取り範囲、マスク漏れを確認します。

14.9 AIと協働する日常業務ワークフロー

14.9.1 AIに任せる範囲

AIに任せやすいのは、構造化、下書き、要約、比較、観点出しです。

• daily work task brief から async message draft の草案を作る。
• 箇条書きメモを report / status update brief に整える。
• 相談内容から consultation / decision request memo の論点と選択肢を出す。
• PDFや表から source / evidence extraction table の候補を作る。
• グラフやスクリーンショットから chart / screenshot reading note の草案を作る。
• チャット履歴から chat decision capture と work follow-up log の候補を抽出する。
• 文体を読み手に合わせて、丁寧、簡潔、正式、社内向けに調整する。

14.9.2 AIに任せない範囲

次の判断は、人間が責任を持ちます。

• 社外送信、顧客回答、契約や価格に関わる表現を確定すること。
• 個人情報、顧客情報、社内限定資料、画像内の機密をAIへ入力してよいか判断すること。
• グラフや表からの解釈を、元データ確認なしに事実として扱うこと。
• 相手への約束、期限、費用、責任分界を確定すること。
• 法務、security、privacy、IP、購買、経理の確認が必要な事項を省略すること。
• AIが作った要約を、出所確認なしに公式記録へ転用すること。

14.9.3 プロンプト例

【入力】daily work task brief、communication intent card、参考メモがあります。
【目的】関係者へ送る async message draft を作成します。
【制約】事実、解釈、要確認事項を分けてください。未確定事項を断定しないでください。
【情報分類】顧客名、価格、個人名は含めないでください。
【出力形式】
1. 件名
2. 結論
3. 背景
4. 依頼事項
5. 期限
6. 未確定事項
7. 次アクション
【評価基準】読み手が次に何をすればよいか、期限、判断点、確認事項が明確であること。

AIに文面を作らせるだけでなく、受け入れ基準を明示します。出力後は、相手、事実、期限、情報分類、承認要否を確認します。

14.10 よくある失敗と改善策

失敗1: 「いい感じに要約して」で始める

資料の目的、読み手、使い道がないまま要約すると、使えない要約になります。daily work task brief で、何の判断に使う要約かを定義します。

失敗2: チャットの合意を記録しない

チャット上で合意した内容は流れます。chat decision capture に、決定、保留、担当、期限、根拠を残します。

失敗3: スクリーンショット内の機密を見落とす

スクリーンショットには、氏名、ID、内部 URL、通知、顧客名、契約条件が映り込むことがあります。multimodal input inventory で分類し、必要ならマスクします。

失敗4: グラフの見た目だけで結論を作る

グラフは、軸、単位、集計対象、欠損、注記で意味が変わります。chart / screenshot reading note で、見えている事実と解釈を分けます。

失敗5: 報告が作業記録だけになる

読み手が必要としているのは、多くの場合、判断材料、リスク、支援要否、次アクションです。report / status update brief で、進捗と判断依頼を分けます。

14.11 人間が最終判断すべき点

日常業務でAIを使うほど、最後に人間が確認すべき点を明確にします。

• 相手に送ってよい表現か。
• 相手が次に何をすればよいか分かるか。
• 事実、解釈、仮説、推奨、要確認が分かれているか。
• 情報分類、入力可否、共有範囲を守っているか。
• PDF、画像、表、グラフ、スクリーンショットの出所、更新日、範囲、機密を確認したか。
• AIの要約や読み取りを、原資料で確認したか。
• 承認者、期限、担当、ログ化先が明確か。
• 再利用する場合、顧客固有情報や個人情報を除外しているか。

章末演習

演習14-1：daily work task brief を作る

今週行うメール、チャット、報告、相談、資料確認のいずれかを1つ選び、daily work task brief を作ってください。目的、読み手、相手にしてほしいこと、入力資料、情報分類、承認者を明示してください。

演習14-2：async message draft を改善する

最近送った、または送る予定のメール・チャットを1つ選び、communication intent card を作ったうえで async message draft に改善してください。改善前後で、依頼事項、期限、未確定事項が明確になったか確認してください。

演習14-3：report / status update brief を作る

現在の業務やプロジェクトについて、report / status update brief を作ってください。進捗、課題、リスク、判断してほしいこと、次アクションを分けてください。

演習14-4：multimodal input inventory を作る

PDF、画像、表、グラフ、スクリーンショットを含む資料を1つ選び、multimodal input inventory と source / evidence extraction table を作ってください。AI入力可否、情報分類、出所、要確認点を明示してください。

演習14-5：chat decision capture と work follow-up log を作る

最近のチャットや会議メモから、決定事項、保留事項、担当、期限、根拠を抽出し、chat decision capture と work follow-up log に整理してください。

理解度チェック

□ daily work task brief で、日常業務の目的、読み手、判断点、情報分類を定義できる □ communication intent card で、媒体、相手、求める反応、期限を整理できる □ async message draft で、結論、背景、依頼、期限、未確定事項を明確にできる □ chat decision capture で、チャット上の決定、保留、担当、期限を残せる □ report / status update brief で、進捗、課題、リスク、判断依頼を分けられる □ consultation / decision request memo で、相談の論点、選択肢、推奨案、必要承認を示せる □ multimodal input inventory で、PDF、画像、表、グラフ、スクリーンショットの情報分類とAI入力可否を判断できる □ source / evidence extraction table と chart / screenshot reading note で、根拠、出所、解釈、限界を分けられる □ work follow-up log で、日常業務の依頼、回答、判断、再利用条件を残せる □ AIに任せる範囲と、人間が最終判断する範囲を分けられる

章末の要点

• 日常業務は、短い文章作成ではなく、小さな意思決定と情報処理の連鎖です。
• daily work task brief は、メール、チャット、報告、相談、資料確認の目的と制約を定義します。
• communication intent card は、誰に、何を、どの媒体で、どの反応を求めるかを明確にします。
• async message draft は、結論、背景、依頼、期限、未確定事項を整理し、読み手が動ける状態を作ります。
• chat decision capture は、チャット上の決定、保留、担当、期限、根拠を流れない形で残します。
• report / status update brief と consultation / decision request memo は、報告や相談を判断材料に変えます。
• multimodal input inventory は、PDF、画像、表、グラフ、スクリーンショットを安全に扱う入口です。
• source / evidence extraction table と chart / screenshot reading note は、AIの要約や読み取りを検証可能にします。
• work follow-up log は、依頼、回答、判断、未決事項、再利用可能な型を残します。

次章への橋渡し

第14章では、日常業務におけるメール、チャット、報告、相談、提案フォロー、マルチモーダル資料の扱いを、AIと協働して成果物化する方法を扱いました。次の第15章では、個人の実践をチーム運用、テンプレート資産、レビュー、責任分界へ広げます。

• 前章: 第13章：論理的な交渉・説得術
• 次章: 第15章：論理的思考を活かしたリーダーシップ
• リライト方針: 2026年版リライト契約と分割計画