パイソンエンジニア部
未読 47 件、長スレッド 14 件、9:30 までに 35 分。
そのなかで、いちばん時間が溶けるのは「14 通連鎖した長スレッド」を 1 通ずつ遡って読む作業ではないでしょうか。件名は Re: Re: Re: Re: で並んでいて、本文の冒頭はいつも「前回のメールを引用すると…」から始まる。1 スレッドに 5 分かけて、6 本目で集中が切れて、結局スマホで Slack を開く。9:25 までにメールは 5 通しか読めていない。
これが Copilot 導入前の月曜 9:00 です。
ところが、Outlook Copilot を入れた瞬間に、この 30 分は 3 分に縮みます。読まないからです。
Before / After ─ 朝の 30 分が 3 分に縮む内訳
gantt title 月曜 9:00 ─ 14通の長スレッド処理時間 dateFormat HH:mm axisFormat %H:%M section Before (Copilot 無し) スレッド1 読む :a1, 09:00, 5m スレッド2 読む :a2, after a1, 5m スレッド3 読む :a3, after a2, 5m スレッド4 読む :a4, after a3, 5m スレッド5 読む :a5, after a4, 5m 返信下書き手書き :a6, after a5, 10m section After (Copilot あり) Summary x3 (30秒×3) :b1, 09:00, 2m Draft with Copilot :b2, after b1, 2m 人間チェック・送信 :b3, after b2, 1m
After は Before の 30 分 → 3〜5 分。同じ「14 通連鎖したスレッドを処理する」ゴールに対する所要時間が、構造的に縮みます。
「全部読む」をやめる
スレッドを最初から最後まで読む必要は、もうありません。
Outlook（新しい Outlook for Windows / Outlook on the web / 対応するクラシック版）でメールスレッドを開くと、右上に 「Summary by Copilot」 ボタンが表示されます。クリックすると、30 秒待たないうちに「誰がいつ何を決めたか」が箇条書きで出ます。発言者の名前と日付が出典として横に添えられているので、出どころも追えます。
公式仕様は Microsoft Support の Summarize an email thread with Copilot in Outlook ページに書かれている通りです。要約の対象はメール本文と添付ファイル内のテキスト。画像内の文字や、保護がかかった添付は対象外です。
実際に出てくる要約のイメージを書きます。
要点 - 4/30 山田さん（取引先）: 見積もり 3 案提示、A案を推奨 - 5/2 佐藤さん（社内・経理）: 価格 5% 削減を要望 - 5/7 山田さん: 削減は B案でしか難しい旨を回答 - 5/9 田中さん（社内・営業部長）: A案推奨、ただし納期を 2 週間短縮できないか確認依頼 アクション - あなた: 5/13 までに A/B どちらかを選んで返信 - 佐藤さん: 経理に B案の予算妥当性を確認
この箇条書きを 30 秒眺めて、私が気づいたのは「自分が今日判断するのは A or B の 1 つだけだった」ということでした。
そのために 14 通を 1 通ずつ開いて、引用部分を読み飛ばしながら経緯を追っていたわけです。5 分が 30 秒に縮みます。ほかの 13 通の長スレッドも同じやり方で処理すれば、1 時間半が 5 分に縮みます。
「読むこと」が必要だと思い込んでいたのは、要約ボタンが画面の隅にあったからです。
Outlook 上での操作シーケンス ─ クリック 1 回で何が動いているか
sequenceDiagram participant U as 私 participant Outlook as Outlook<br/>(クライアント) participant Copilot as Copilot サービス participant Graph as Microsoft Graph<br/>(メール本文) U->>Outlook: スレッドを開く U->>Outlook: "Summary by Copilot" クリック Outlook->>Copilot: 要約リクエスト + スレッド ID Copilot->>Graph: 当該スレッドのメール本文を取得 Graph-->>Copilot: 14通分の本文 + 添付テキスト Copilot->>Copilot: 要約生成 + 出典付与 Copilot-->>Outlook: Key points + Action items Outlook-->>U: 右ペインに表示 (約30秒)
クリック 1 回の裏で、Graph API がスレッド 14 通分の本文を引っ張ってきて、Copilot が要約と出典を返している、という流れです。要約に時間がかかるのはスレッドが長い時、というのはここから来ています。
返信下書きは Copilot に書かせる ─ Draft with Copilot
要約で「A案を選んで返信するだけ」と分かったら、次は返信の下書きです。
返信メールの入力ボックスに 「Draft with Copilot」 が出ているはずです（公式仕様: Draft an email message with Copilot in Outlook）。クリックすると、プロンプトを 1 行入れる欄が出ます。
ここで多くの人が、こう書きます。
A案で返信して、丁寧に。
返ってくる下書きは、「いつもお世話になっております。ご提案いただきありがとうございました。慎重に検討させていただいた結果、A案でお願いしたく存じます。何卒よろしくお願いいたします。」のような、無難で空虚な文章です。誰の文章でもありません。
私自身、最初の 2 週間はこれで満足していました。「Copilot が書いてくれた」という事実に。中身を見ずに送信ボタンを押していました。
3 週間目に、上司から「最近のあなたの返信、温度感がないね」。
GCES 4 要素を、Outlook の返信下書きで実演する
ここでシリーズ #01 統合概論 で扱った GCES が効きます。
GCES は Goal / Context / Expectations / Source の頭文字で、Copilot に何かを書かせるときに「省略すると壊れる 4 要素」を意味します。Outlook の Draft with Copilot に流し込む実物プロンプトを、4 要素を埋めて書き直してみます。
Goal: 山田さんに A案で正式発注すると返信したい。CC は佐藤さん（社内・経理）と田中さん（社内・営業部長）。 Context: 14 通の長スレッドで、5/2 に佐藤さんから 5% 価格削減要望が出たが、5/7 に山田さんから B案でしか難しいと回答済み。社内検討の結果、A案を選定。納期短縮について田中さんから確認依頼が出ている。 Expectations: 200 字以内、敬体、本題から先。冒頭の「お世話になっております」は省略。末尾に「納期を 2 週間短縮可能か」と「請求書フォーマットの希望」を 1 行ずつ確認として入れる。 Source: このスレッドの最新 3 通を参照してください。
返ってくる下書きはこうなります。
A案で正式に発注させていただきます。 社内検討の結果、機能要件・予算ともにA案が最適と判断いたしました。 5/13 を契約日とし、検収は 6/14 を予定しています。 確認させてください。 ・納期を当初の 6 週間から 4 週間に短縮することは可能でしょうか。 ・請求書はインボイス制度対応の電子データで、5/末締めの翌月末払いをご希望です。
200 字に収まり、本題から始まり、納期と請求書の指定が末尾に乗っています。3 行を私の言葉に直して、送信します。所要 2 分。
Before の 30 分が After の 3 分になりました。Summary 30 秒 ＋ Draft 2 分 ＋ 人間チェック 30 秒 です。
GCES 4 要素の構造 ─ どこを省略すると壊れるか
flowchart TD Prompt["プロンプト 1 行"] G["Goal<br/>何を達成したいか"] C["Context<br/>関係性・過去経緯・<br/>社内事情"] E["Expectations<br/>長さ・トーン・<br/>形式"] S["Source<br/>参照させる情報源"] Copilot["Outlook Copilot"] Output["返信下書き"] Prompt --> G Prompt --> C Prompt --> E Prompt --> S G --> Copilot C --> Copilot E --> Copilot S --> Copilot Copilot --> Output C -. "省略すると一番痛い" .-> Output
Goal だけ書いて他を省略すると、Copilot は当該メール本文だけを見て「誰でも書けそうな平均値の返信」を返してきます。Context、つまり関係性・過去経緯・社内事情を 2〜3 行足すかどうかで、出力は別物になります。
なぜ「Context」を省略すると、出力が別物に劣化するのか
雑プロンプト（「A案で返信して、丁寧に」）と GCES プロンプトの違いは何でしょうか。
Goal は雑プロンプトにもありました（「A案で返信」）。Expectations は雑プロンプトにもありました（「丁寧に」）。Source は両方とも当該メールが対象。
決定的に違うのは Context、つまり 4 行目の「14 通の長スレッドで、5/2 に佐藤さんから…社内検討の結果、A案を選定」の部分です。
Outlook Copilot は当該メール本文を読みますが、そのスレッド以外の情報は持っていません。
- 「佐藤さんは社内・経理」「田中さんは社内・営業部長」「山田さんは取引先」という関係性
- 「5/7 にすでに B案でしか難しいと回答が出ている」というスレッド内の決定経緯
- 「社内検討の結果、A案を選定」という Copilot が知り得ない社内判断
これらを Context として人間が 2〜3 行で書き起こすかどうかで、出力は別物になります。
GCES の中で、省略すると一番痛いのが Context です。Goal だけ書いて出力させると、誰でも書けそうな、当たり障りのない一般論しか出てきません。Context を 1 行足すごとに、文章は一気に「私のチーム固有の文書」に近づきます。
これが、Copilot を「便利だけど使いにくいおまけ機能」のままで止めるか、「30 分作業を 3 分にする戦力」に育てるかの分岐点です。
ハマる罠 3 つ
罠 1: Summary を読んで「読んだ気」になる
要約は要約です。本文の細部を全部拾うわけではありません。
特に 金額・期日・固有名詞は、Summary が拾えていないことが結構あります。「あ、5/2 に佐藤さんから値下げ要望」とまでは出ても、その具体的な金額数値「107 万円から 102 万円へ」までは要約に出てこないことがあります。
判断に使う数字・日付・社名は、本文側で確認する癖をつけてください。Summary はあくまで「どこを読むべきか」の地図です。
罠 2: 返信下書きをそのまま送る
Draft with Copilot の出力は、丁寧すぎる／間違った敬称を使う／日付を勝手に確定させる、のどれかが必ず混じります。
私が「最近の返信に温度感がない」と言われたのは、無編集で送り続けたからです。最低 3 行は人間が直す。これは「Copilot 出力品質の限界」ではなく、「私の文章だと相手に伝わる」という運用上の必要です。
具体的には、
- 冒頭か末尾に 1 行、相手との関係性が出る一言を入れる（「先週のオフサイトお疲れさまでした」「ご家族のご様子はいかがですか」など）
- 日付や金額が出ていたら必ず実際の値と照合する
- 敬称（さん／様／部長）を見直す
これだけで「Copilot 臭」は抜けます。
罠 3: GCES の「Context」を端折る
Copilot に渡すプロンプトを書くのが面倒になって、つい Goal だけで済ませてしまう瞬間があります。
「A案で返信」「先週の議事録まとめて」「資料の要約お願い」。これらは Goal だけのプロンプトです。Copilot は当該メール／当該ファイルだけを見て、社外目線でも社内目線でも通用しそうな、平均値の出力を返してきます。
このとき、出力をそのまま使うと、3 週間後に「あなたの最近の文章、温度感がないね」と言われる側に回ります。
Context を 2〜3 行書く時間は、出力を直す時間より圧倒的に短いです。プロンプトを書くのを面倒くさがるほど、後工程の修正で時間を失います。
今週やる 1 つ ─ 明日朝、長スレッド 3 通だけ Summary
具体的なアクションは 1 つだけです。
明日の朝 Outlook を開いたら、未読の中から 長スレッド（5 通以上連鎖しているもの）を 3 通だけ選んで、Summary by Copilot を押してください。返信はしなくて構いません。要約を眺めるだけです。
3 通眺めると、自分の中で「あ、こんな粒度で内容がつかめるのか」という体感がインストールされます。これが入れば、その後の Draft with Copilot や GCES プロンプトへの拡張は自然に進みます。
逆に、いきなり「Draft with Copilot で GCES プロンプトを書いて返信を Copilot に書かせる」ところから始めると、ハードルが高すぎて 1 日でやめます。Summary 3 通だけ、明日の朝。
まとめ
私自身、最初に Summary by Copilot のボタンを押したとき、出てきた箇条書きを見て、少し脱力したのを覚えています。
3 ページ近い長スレッドを 5 分かけて読んでいた時間は、「読まないと不安だから」だったんだ、と気づきました。読まなくてもよかったのに、読むことが仕事だと思い込んでいた。
時間は、最初から余っていたのかもしれません。気づかなかっただけで。
TL;DR
- 長スレッドは「全部読む」をやめ、Summary by Copilot で 30 秒
- 返信下書きは Draft with Copilot に GCES 4 要素のプロンプトを渡す
- 一番省略してはいけないのは Context（社内事情・過去経緯・関係性）
- 罠: Summary を読んで読んだ気になる ／ 下書きをそのまま送る ／ Context を端折る
- 今週やる 1 つ: 明日の朝、長スレッドを 3 通だけ Summary。返信はしない
