Microsoft 365環境でAIを入れる場合、Outlookのメールと予定表は最も価値の高いデータ源です。同時に、権限設計を間違えると最も事故が大きい場所でもあります。
Gmail環境との違いを含めて、実務で確認すべき点を整理します。Google Workspace側の事情はGmailを対象にする場合に、方式そのものの選び方は権限の引き継ぎ方にまとめています。
先に確認：純正Copilotが読める範囲は決まっている
設計に入る前に、ひとつ前提があります。Microsoft 365 Copilotがメールを読める範囲は製品側で固定されていて、設計で広げられる部分ではありません。
Microsoft Copilot is only supported on primary mailboxes that are hosted on Exchange Online. It isn’t available on a user’s archive mailbox, group mailboxes, or shared and delegate mailboxes that they have access to.
（Copilotがサポートするのは Exchange Online 上のプライマリメールボックスのみ。アーカイブメールボックス、グループメールボックス、アクセス権を持つ共有・代理人メールボックスでは利用できない）
さらに紛らわしいのが、「Copilot」と呼ばれるものが複数あり、読める範囲がそれぞれ違うことです。同じ名前で会話していると、要件定義の途中で前提がずれます。
| どのCopilotか | 共有メールボックス | できること |
|---|---|---|
| Copilot in Outlook Outlook内の要約・下書き |
対象外 | プライマリメールボックスのみ |
| Copilot Chat in Outlook | 可 | 要約と下書き。操作や予定表の管理はできない。フォルダー単位の権限にも対応 |
| Microsoft Copilot アプリ | 可 | 読み取りと操作。代理人メールボックスはフル代理アクセスが必要で、対象者にもライセンスが要る |
オンプレミスに残っているメールボックスは対象外
公式が挙げているのは Exchange Online 上のプライマリメールボックスです。ハイブリッド構成でメールボックスがオンプレミスに残っている利用者は、純正Copilotの対象になりません。移行状況の確認は、要件定義より先に行ってください。後から判明すると、対象人数の前提が崩れます。
Outlook特有の3つの前提
Google Workspaceと比べたとき、設計に影響するのは次の3点です。
| 項目 | Outlook側の事情 |
|---|---|
| 共有メールボックス | 組織で広く使われており、権限が個人と別建て |
| 予定表 | 既定は「空き時間のみ」（AvailabilityOnly）。件名を見せるには権限を緩める操作が要る |
| パブリックフォルダ | 古い組織では残っていて、権限が把握されていないことが多い |
誰も管理していないパブリックフォルダ
長く運用されている環境では、過去の重要なやりとりが残っていることがあります。ここを無自覚に参照範囲へ入れると、想定外の情報が回答に出ます。連携前に一覧を出して、中身を確認してください。
予定表を含めるかどうかは分けて考える
メールと予定表をまとめて「Outlook連携」と扱いがちですが、機微さの性質が違います。
- メール：本文の中身が機微。件名だけなら比較的安全
- 予定表：誰と誰がいつ会っていたかが機微。件名すら見せられないことがある
予定表は、件名すら見せられないことがある
人事面談、与信の相談、M&Aの打ち合わせ。予定表の件名は、それ自体が漏れてはいけない情報を含みます。「AIに聞けば誰の予定でも分かる」状態は、社内の信頼を損ないます。
| 判定 | 対象 | 理由 |
|---|---|---|
| ○ | 自分の予定 | 本人の情報。問題なし |
| ○ | 会議室・設備の予約状況 | 日程調整の用途はこれで足りる |
| △ | 他人の空き時間のみ | 既定の AvailabilityOnly がこれ。件名は出ない |
| ✕ | 他人の予定の件名 | LimitedDetails 以上が必要。面談・与信・M&Aが混ざる |
既定のままなら、件名は出ない
Exchange Onlineの予定表は、既定の権限が AvailabilityOnly（空き時間のみ）です。件名を見るには LimitedDetails 以上へ緩める必要があります。つまり危ないのは初期状態ではなく、過去に誰かが「見えないと不便だから」と緩めた組織です。AI連携の前に、実際の設定値を確認してください。
実務的な落とし所
予定表は「自分の予定」と「会議室・設備の予約状況」に限定し、他人の予定は対象外にする。これで日程調整の用途はほぼ満たせます。
「他人の予定も見たい」という要望が出た場合、それがAIの機能要件なのか、そもそも組織として公開してよいのかを分けて議論してください。後者が決まっていないのにAI側で実装すると、責任の所在が曖昧になります。
共有メールボックスから始める
ここからは自前で構築する場合、またはCopilot Chat・Copilotアプリを使う場合の話です。前述のとおり、Outlook内の Copilot in Outlook は共有メールボックスを対象にできません。
その前提で言えば、最初に手を付けやすいのは共有メールボックスです。理由は、もともと複数人が見ている前提のデータだからです。
「権限の議論が発生しない」わけではない
共有メールボックスにも権限はあります。Copilotアプリで代理人メールボックスを扱うにはフル代理アクセスが必要で、フォルダー共有の権限しかない場合は読み取りも操作もできません。「共有箱だから誰でも見える」という前提で設計しないでください。誰にFull Accessが付いているかを、先に一覧化する必要があります。
info@— 問い合わせの履歴。過去の回答パターンがそのまま資産になるsupport@— サポート対応。FAQ化されていない知見が溜まっているsales@— 引き合いの履歴
この3つだけで、社内問い合わせの相当数に答えられる
個人メールボックスへの拡張は、ここで有効性を確認してからで間に合います。共有箱は閲覧者がもともと限定・明示されているぶん、範囲を決めるのが個人箱より速く済みます。
アクセス権の棚卸しが先に必要になる
権限引き継ぎ型を選ぶ場合、前提として現在の権限が正しい状態である必要があります。ところが実際には、ここが崩れていることが珍しくありません。
- 退職者のメールボックスに、当時の担当者のアクセス権が残っている
- 終了したプロジェクトの共有フォルダが、全員閲覧可のまま
- 異動した人が、前の部署のメールボックスをまだ見られる
AIは、いまの権限状態を忠実に再現する
「AIが見せてはいけないものを見せた」のではなく、もともと見えていたものが可視化されただけですが、発覚するのはAI導入のタイミングです。
棚卸しは導入の障害ではなく成果
棚卸しは障害ではなく成果
「AI導入が権限問題を掘り起こした」と捉えると、プロジェクトが後ろ向きになります。実際には放置されていたリスクが見つかったわけで、成果として報告すべき内容です。稟議の振り返りにも使えます。
導入前に決めておく4項目
- 対象：共有メールボックスのみか、個人も含めるか
- 予定表：含めるか、自分の予定だけか、対象外か
- 期間：何年分を遡るか（直近1〜2年から始めるのが現実的）
- 権限方式：共通アカウントか、利用者の権限を引き継ぐか
決まっていない状態で見積もりを取ると、後から膨らむ
この4つが決まっていれば、実装の見積もりは正確に出せます。逆に決めずに各社へ投げると、それぞれが違う前提で書くので比較もできません。
共有・代理人メールボックスの制約を、確認してまとめました
共有フォルダー権限だけではCopilotは動かず、フル代理アクセスが要ります。Copilot Chat は共有・代理人メールボックスでアクションの実行と予定表の管理ができません。ライセンスの数え方も変わります。主要4サービスの契約条件とあわせた表です。
この記事について：Copilotが対象とするメールボックスの範囲は Microsoft Learn「App and network requirements for Microsoft Copilot admins」、共有・代理人メールボックスでの振る舞いは Microsoft サポートの各ページ、予定表の既定権限（AvailabilityOnly / LimitedDetails）は ExchangePowerShell のリファレンスに基づいています。Copilot の仕様は更新が速いため、導入検討時には最新の公式文書をご確認ください。パブリックフォルダーの運用実態については公式の統計がなく、断定していません。
