Microsoft 365コネクタのセキュリティと権限制御の仕組み

OAuthの委任認証がそのまま権限の土台になる

Microsoft 365コネクタは、ClaudeがOutlook・SharePoint・OneDrive・Teamsのデータをユーザーに代わって読み書きできるようにする、Anthropicがホストする接続機能です。Free・Pro・Max・Team・Enterpriseのすべてのプランで使えます。結論から言うと、この連携はMicrosoftのOAuth委任認証をそのまま土台にしており、Claude側が独自に権限を判定する仕組みではありません。ユーザーが元々Microsoft 365で持っている権限を、Claudeが代理で行使するだけです。

AnthropicはMicrosoftのパートナー検証プロセスを完了させ、Microsoft Partner Networkアカウントに紐づく組織として身元確認を受けています。コネクタ自体はセキュアプロキシとして動き、文書やメールの実体はユーザーのMicrosoft 365テナント内に留まります。取得するのはクエリが実行された瞬間のデータだけで、ファイルの中身をキャッシュしません。認証情報はAnthropicのバックエンドが暗号化して管理し、MCPサーバー自体は認証情報を保持しない設計です。トークン交換はMicrosoftのAzure SDKがユーザー単位で処理します。実際の接続手順とOutlook・OneDrive・Teamsを横断した使い方はClaude Cowork × Microsoft 365連携で扱っているので、本記事はセキュリティとアクセス制御の仕組みに絞って掘り下げます。

アクセス制御は6層に分かれている

情シスが確認すべきなのは「Claudeが何をできるか」ではなく、「どの層で誰がそれを止められるか」です。アクセス制御は6つの層に分かれています。

1. Microsoft Entraテナントが前提。コネクタを使う全員が、Microsoft Entraテナントに紐づいたMicrosoft 365アカウントで認証する必要があります。@outlook.comや@hotmail.comのような個人アカウントは使えません。Microsoft Entraのグローバル管理者が組織単位の同意を一度完了させるまで、テナント内の誰も接続できません。

2. 組織レベルのゲーティング(Team・Enterprise)。Team・Enterpriseプランでは二段階の承認が必要です。まずOwnerがClaudeの組織設定(Organization settings > Connectors > Browse connectors > Add "Microsoft 365")でコネクタ自体を有効化するまで、メンバーは一切アクセスできません。その後にMicrosoft Entraのグローバル管理者が個別の認証と組織全体への同意を完了させて、初めてメンバーが接続できるようになります。

3. 粒度の細かい権限の取り消し。Microsoft Entra管理センターから、機能ごとに個別に権限を無効化できます。

変更は組織内の全員に即座に反映されます。利用者自身もチャット中にコネクタのツールを個別にオフへ切り替えられます。

4. Microsoft Conditional Access。ここが最も見落とされやすい層です(次節で詳しく扱います)。

5. ユーザーレベルの権限。コネクタは委任権限(delegated permissions)で動くため、ユーザーが元々アクセス権を持つデータしか扱えません。SharePoint検索はSites.Read.Allが前提でテナント全体を横断する設計のため、*.Selected権限によるサイト単位の限定はサポート対象外です。SharePointの共有設定やフォルダ権限を回避することはできず、他ユーザーの非公開ファイルやメールにもClaude経由で届きません。委任アクセス権を付与された共有メールボックスは読み取り専用(Mail.Read.Shared)で検索できますが、個別のオンラインアーカイブ(In-Place Archive)メールボックスまでは検索が及びません。委任権限である以上、Microsoft 365のDLP(データ損失防止)ポリシーもそのまま適用されます。

6. トークン管理。リフレッシュトークンは既定で90日間操作がないと失効し、再認証が必要になります(Microsoft Entra IDのトークン有効期間ポリシーでカスタマイズ可能)。アクセストークンはMicrosoft Entra IDの既定値どおり60〜90分で失効し、自動更新されます。管理者・ユーザーはいつでもMicrosoft Entra ID側からアクセスを取り消せます。コネクタがパスワードそのものを見ることはありません。

Conditional Accessは想定通りに効くか — 位置情報制限だけがすり抜ける理由

Conditional Accessのポリシーはコネクタにも適用されますが、ユーザーがMicrosoft 365を直接操作するときと同じようには効きません。ユーザーが接続した瞬間はEntraがそのサインインに対してポリシーを評価しますが、以降のリクエストはすべてClaudeのサーバーから発行されます。Anthropicの検証では、これらのリクエストはAnthropicのIPレンジ(160.79.104.0/21)から来たものとしてEntraに認識されます。接続時に記録されたデバイスとメンバーの紐づけは引き継がれる一方、メンバーの現在のデバイスやネットワークとしては評価されませんでした。

• グループベースのアクセス制御: 効きます。特定のセキュリティグループにポリシーを絞るか、両方のClaudeアプリケーションに「割り当てが必要」を設定します。
• 多要素認証(MFA): 効きます。メンバーが接続時にサインインする瞬間にMFAが強制されます。特定アプリケーションを対象にしたMFAポリシーがコネクタのサインインに適用されない場合は、両方のClaudeアプリケーションを対象にした条件なしの別ポリシーを作る必要があります。
• デバイス準拠: 効きますが、評価のタイミングが違います。ポリシーはメンバーが接続した瞬間のデバイスに対して評価され、基準を満たさないデバイスは接続画面で止まりません。その代わり最初のツール呼び出しから失敗し始めます。接続はそのデバイス記録を引き継ぎ、次にメンバーが再接続するまではその記録に対して継続的に評価されます。デバイス記録は、メンバーのブラウザが組織にサインインした状態でEntraに証明できたときだけ作られます。そのため準拠デバイスでも、組織にサインインしていないブラウザプロファイルからだと「非準拠」扱いになります。ブロックされたメンバー(AADSTS53000)は、組織にサインイン済みのブラウザで基準を満たすデバイスから再接続すれば解消します。
• 位置情報・ネットワーク制限: 効きません。サーバー側のリクエストは常にAnthropicのIPレンジから来るように見えるため、社内ネットワークやVPNへのサインインを限定するポリシーは、メンバーの実際の所在地に関わらずコネクタ全体をブロックしてしまいます。サインイン頻度ポリシーも同様です。

この一覧が示すのは、「MFAやデバイス準拠を厳しくすれば位置情報制限の代わりになる」という発想が通用しないという点です。MFAの証明は保存された接続に同じように引き継がれるため、デバイス要件やMFA要件を回避策として強化しても、結局は全メンバーに対して条件が満たされたことになり、デバイス要件が実質的に機能しなくなります。位置情報でコネクタを制限したい組織は、Anthropicのアプリケーション2つに対するIPレンジ除外をポリシー側で設定する必要があります。除外はこのIPレンジ条件に対してだけ行うべきで、Claudeのアプリケーション2つ自体をポリシーの割り当てから外すと、デバイス準拠やMFAのチェックそのものが効かなくなる点に注意が必要です。

組織外のClaudeアカウントに仕事用アカウントを接続させたくない場合は、「検証済みドメインのコネクタを組織内に制限する」設定を有効にします。これは接続先の制限であり、Conditional Accessの位置情報制限とは別の設定です。

認証フローとデータの流れ

認証はOAuth 2.0のOn-Behalf-Of(OBO)方式です。パブリッククライアントはPKCE(Proof Key for Code Exchange)で認可コードの横取りを防ぎ、二段階のトークン交換を行います。まずユーザーがMCPサーバー向けのアクセストークンを取得し、続いてMCPサーバーがそのトークンを機密クライアント資格情報付きのOBOフローでMicrosoft Graph API用のトークンに交換します。このOBOトークン自体には、ユーザー本人もClaudeクライアントもアクセスできません。ユーザーのデータへアクセスできるのはMCPサーバーだけです。Microsoftのパスワードそのものが共有されることはなく、アクセストークン・リフレッシュトークンはClaudeのバックエンドにキャッシュされる間、暗号化されています。

データの流れも一時的です。文書などのコンテンツはアクティブなクエリの最中にだけ取得され、チャットとして保存されたツール呼び出しの結果は保持されます。チャットをリクエストした本人はツール呼び出しの結果とClaudeの回答を見られますが、そのチャットを共有された他のユーザーはClaudeの回答だけを見られ、元のツール呼び出し結果は見えません。各リクエストはそのつど新しいデータフローを作り、応答を返したあとにクリーンアップされます。

マルチテナントの分離は暗号的に保証されています。Microsoft Entraテナントは共通スコープのマルチテナント構成のもとで互いに暗号的に分離され、デジタル署名されたアクセストークンが各ユーザーを所属組織のテナントに紐づけます。

読み取り専用ツールと書き込みツール、有効化の既定値

コネクタが提供する読み取り専用ツールは、SharePoint検索(sharepoint_search、Sites.Read.All)、メール検索(outlook_email_search、Mail.Read)、カレンダー検索(outlook_calendar_search、Calendars.Read)、空き時間検索(find_meeting_availability)、Teamsチャット検索(chat_message_search、Chat.Read)など、権限に対応した粒度で分かれています。

組織が書き込みツールを有効化すると、メール送信・転送・下書き作成、カレンダーイベントの作成・更新・削除、メールボックス設定の変更、OneDrive・SharePointへのファイル作成・更新まで扱えるようになります。Teamsだけは書き込みに対応せず、読み取り専用のままです。書き込みツールには次の安全策が組み込まれています。

• 送信元の明示: Claudeが送るメールにはエージェントが起点であることを示すヘッダーが付きます(ファイル・カレンダーの書き込みには現時点でタグが付きません)
• レート制限: 送信・書き込み・宛先数にユーザー単位の上限があります
• 添付ファイルの制限: 送信・転送・下書き作成のいずれも、添付ファイル付きのメッセージは拒否されます
• 既定でブロック: 書き込みツールが実装される前からコネクタを使っていた組織は、管理者が明示的に有効化するまで書き込みツールがブロックされたままです

outlook_send_mail・outlook_forward_mail・outlook_send_draft・outlook_create_event・outlook_update_eventは「常に許可」の設定が使えず、実行のたびに確認が必要です。組織としてどこまで書き込みを許可するかを設計する際は、Claude Connectorsの権限設定でよくある失敗と対策や業務SaaS連携は読み取り専用アクセスから始める理由も合わせて確認すると、初期設定の判断基準が補えます。

現在の制限事項

• Teamsは読み取り専用: Claudeはチャットの投稿もTeams設定の変更もできません。他の書き込みツールは管理者による個別の有効化が前提です
• ユーザーレベルのアクセスのみ: サービスプリンシパル認証には対応していません
• オンラインアーカイブは検索対象外: メール検索はユーザーの主要メールボックス(アーカイブフォルダを含む)とアクセス権のある共有メールボックスをカバーしますが、保持ポリシーで移動された別のオンラインアーカイブ(In-Place Archive)メールボックスまでは検索が及びません

よくある質問

全社展開の前に小規模なパイロットでテストできますか

できます。推奨手順はアプリの割り当てで対象を絞る方法です。Team・Enterpriseのオーナーが組織設定でコネクタを有効化する(個人プランのユーザーは直接接続可能)、Microsoft Entra管理者が事前同意の設定を完了する、Microsoft Entraのエンタープライズアプリ割り当てで特定ユーザーやグループ(例:「ITセキュリティテストグループ」)だけにアプリを割り当てる、という順に進め、段階的にグループを拡大します。

マルチテナント環境で他組織へのデータ漏洩は起きませんか

多層の分離が保証されています。サーバーは任意のMicrosoft Entra IDテナントからのトークンを受け付ける共通テナント構成を使いますが、各ユーザーのトークンには所属テナントのID(tidクレーム)が含まれ検証されます。OBO経由で取得するGraph APIトークンは自動的にユーザーとそのテナントにスコープが限定され、テナントをまたいだトークンアクセスはMicrosoft GraphのOAuth 2.0実装そのものによって暗号的に防止されています。

個人のMicrosoftアカウントで接続しようとするとどうなりますか

コネクタはMicrosoft Businessプランに紐づくMicrosoft Entraテナントを必須にしています。@outlook.comや@hotmail.comなどの個人アカウントでは認証できず、接続を試みると認証エラーになります。

コンプライアンス向けの監査ログはありますか

あります。コネクタが行うGraph APIの呼び出しはすべて組織のMicrosoft 365監査ログに記録され、M365コンプライアンスセンターから確認できます。タイムスタンプ・ユーザー・実行された操作・アクセス先リソースが記録され、保持期間は組織のMicrosoft 365監査ポリシーに従います。加えてAnthropic側でも認証とツール実行のイベントをログに残しています。

不正利用が発覚した場合にアクセスを取り消せますか

複数の取り消し方法があります。個人単位ではユーザー自身がカスタマイズ > コネクタから切断できます。管理者単位ではTeam・Enterpriseプランのオーナーが組織設定でコネクタを無効化でき、組織全体のメンバーに影響します。権限単位ではMicrosoft Entra管理センターで個別の権限を取り消せ、テナント単位ではすべての権限を一括で取り消せます。

まとめ

Microsoft 365コネクタのセキュリティは、Claude側の独自ロジックではなくMicrosoft Entraの委任認証とOAuthのOBOフローに支えられています。OAuthスコープを土台にした権限設計は他のプリビルドConnectorとも共通しており、BoxのClaude連携の権限設計と比べると、テナント側で制御できる範囲の違いが見えてきます。テナント要件・組織レベルのゲーティング・粒度の細かい権限取り消し・Conditional Access・ユーザーレベルの委任権限・トークン管理という6層が、それぞれ異なる主体によって制御されます。とりわけConditional Accessは、MFAやデバイス準拠は想定どおりに効く一方、位置情報やネットワーク制限だけはAnthropicのIPレンジ経由になるため機能しません。社内ネットワーク限定のポリシーに依存している組織は、この点をIPレンジ除外の設定で補う必要があります。導入を検討する情シス担当者は、書き込みツールを有効化する前に読み取り専用の範囲で運用実績を積み、Microsoft Entra管理センターの監査ログとあわせて挙動を確認する進め方が安全です。