Microsoft 365 と Claude を連携：2方式の設計と実装

はじめに

Outlookで本日の予定を確認し、OneDriveから関連資料を引き、Teamsで関係者に要約を共有する。こうしたアプリ横断の定型操作は、多くの組織で1日に何度も繰り返されています。画面操作型RPAで自動化を試みた現場もありますが、Outlookのリデザインやボタン位置の変更で頻繁に壊れ、結果として保守工数のほうが上回るケースが少なくありません。

この領域に対するアプローチが、ClaudeとMicrosoft 365の組み合わせで実用段階に入りました。コネクタ機能を使えば自然言語で横断検索ができ、Claude Codeを使えばメール送信やファイル更新まで含むワークフローを構築できます。アクセスする層が画面ではなくMicrosoft Graph APIのため、UIの変更で動かなくなる事象が原理的に発生しません。

本記事の対象読者は、Claudeの基本的な使い方やAPI連携の概念は把握していて、業務システムへの本格適用を検討している層を想定しています。2つの連携経路の特性、最小実装のコード例、セキュリティ設計の論点に絞って扱います。

1. 基礎知識：2つの連携経路

ClaudeをMicrosoft 365に接続する方法は、現時点で大きく2系統に分かれます。

1.1 Claude.ai の Microsoft 365 コネクタ

Anthropicが公式に提供するネイティブ連携です。Claude.aiの設定画面からMicrosoftアカウントでサインインし、Outlook、OneDrive、SharePoint、Teamsに対してOAuth 2.0の認可コードフローで読み取り権限を付与します。内部的にはMicrosoft GraphへのAPI呼び出しが走りますが、利用者はそれを意識する必要がありません。チャット欄に「先週の請求関連メールを要約して」と書けば、メール検索と要約をClaudeが背景で実行します。

Claude for Team / Enterpriseで利用可能です。テナント全体のアプリ承認は情シス側で行い、ユーザーはサインインのみで使い始められます。

1.2 Claude Code 経由でのプログラマブル連携

開発者向けエージェントであるClaude Codeから、ターミナル経由でMicrosoft 365を操作する方式です。実装手段はいくつかあります。

• CLI for Microsoft 365(m365コマンド)を呼ぶ
• Microsoft Graph PowerShell SDKを通じてPowerShellを実行する
• Microsoft Graph SDK(Python、Node.js等)を直接呼び出すスクリプトを用意する
• Microsoft 365用のMCPサーバを立てる(自前またはコミュニティ実装)

認証はEntra ID(旧Azure AD)にアプリケーションを登録し、対話的にはデバイスコードフロー、無人実行ではクライアントクレデンシャルフローでトークンを取得します。読み取り(Mail.Read、Files.Read.All等)に加えて、書き込み(Mail.Send、Files.ReadWrite.All、Calendars.ReadWrite等)も付与できるため、メール送信、ファイル更新、予定登録までエージェント側で実行可能です。

1.3 2方式の比較

標準的な切り分けは、対話的な検索・要約はコネクタ、書き込みを含む定型ワークフローはClaude Codeに寄せる、というものです。両者は対立するものではなく、業務フェーズによる使い分けと考えるのが実際的です。たとえば全社展開の入口はコネクタ、特定部署の業務自動化はClaude Code、という棲み分けが組みやすくなります。

2. 実装のステップ：Claude Code 方式での議事録自動化

ここでは、もっとも需要が大きい「Teams会議の議事録を自動生成してOneDrive保存・メール通知する」ワークフローを題材に、Claude Code方式での実装フローを示します。所要時間は、Entra ID側の権限承認待ちを除けば2〜3時間程度で動く水準まで持っていけます。

2.1 Entra ID でのアプリ登録とスコープ設計

Azureポータルの「App registrations → New registration」でアプリケーションを作成し、API permissionsに必要なスコープを追加します。議事録自動化に必要な最小スコープは次のとおりです。

テナント管理者承認(Admin consent)を経て、アプリトークンが利用可能になります。なおFiles.ReadWrite.Allはテナント全体に作用する強い権限のため、可能であればSites.Selectedで対象サイトを限定し、議事録保存先のサイトだけを許可する設計を推奨します。

2.2 CLI for Microsoft 365 のセットアップ

Claude Codeを実行する端末から、CLI for Microsoft 365(m365)をインストールしてログインします。動作確認まで含めても数分で完了します。

# CLI for Microsoft 365 のインストール
npm install -g @pnp/cli-microsoft365

# デバイスコードフローでログイン
m365 login --authType deviceCode

# 動作確認：受信トレイの最新メール5件を取得
m365 outlook mail list --folderName inbox --output json | head -50

ここまで動けば、Claude Codeに「先週から今日までの請求書関連メールを抽出してCSVに整形してほしい」のような指示を出すと、Claude Codeがm365 outlook mail listに適切なクエリを組み立てて実行し、結果をCSVに整形するところまで自動でこなします。

2.3 議事録生成スクリプトの最小実装

Microsoft Graph SDK for Pythonを使うサンプルです。会議トランスクリプトを取得し、Claude APIで要点・決定事項・アクションアイテムに整形、OneDriveに保存するまでの骨格を示します。コードの目的は冒頭にコメントで明記しています。

# 目的：Teams 会議のトランスクリプトを取得し、Claude で議事録に整形して OneDrive に保存する
# 認証：クライアントクレデンシャルフロー（無人実行を想定）
# レート制限：429 受信時は Retry-After ヘッダに従う前提（簡略化のため本サンプルでは省略）

from azure.identity import ClientSecretCredential
from msgraph import GraphServiceClient
from anthropic import Anthropic

# 1. Graph クライアント初期化
credential = ClientSecretCredential(
    tenant_id="...",
    client_id="...",
    client_secret="...",
)
graph = GraphServiceClient(credentials=credential)

# 2. 指定会議のトランスクリプトを取得
meeting_id = "..."
transcripts = await graph.users.by_user_id("organizer@example.com") \
    .online_meetings.by_online_meeting_id(meeting_id).transcripts.get()
transcript_text = await graph.users.by_user_id("organizer@example.com") \
    .online_meetings.by_online_meeting_id(meeting_id) \
    .transcripts.by_call_transcript_id(transcripts.value[0].id).content.get()

# 3. Claude で議事録フォーマットに整形
client = Anthropic()
summary = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=2048,
    messages=[{
        "role": "user",
        "content": (
            "以下の会議トランスクリプトを、次の3項目に整形してください。\n"
            "1. 議題と要点(箇条書き)\n"
            "2. 決定事項\n"
            "3. アクションアイテム(担当者・期限を含む)\n\n"
            f"{transcript_text}"
        )
    }]
).content[0].text

# 4. OneDrive へ Markdown 保存
file_content = summary.encode("utf-8")
await graph.users.by_user_id("organizer@example.com").drive \
    .items.by_drive_item_id("root:/Meetings/2026-05-12.md:").content.put(file_content)

実運用では、ここに次の3点を必ず加えます。これらの「現場のハマりどころ」を抑えておくと、エージェントの自律実行を任せられる水準に上がります。

• レート制限のリトライ:Graph APIは429 Too Many Requestsを返すことがあり、Retry-Afterヘッダの秒数だけ待ってから指数バックオフでリトライする実装が必要
• 例外ハンドリング:トランスクリプトがまだ生成中(404相当)のケースを想定し、ポーリング前提のループを組む
• 要承認操作のフラグ管理:メール送信などの破壊的操作は、--dry-runモードと本実行モードを分け、本実行時のみ承認ゲートを通す

これらの定型コードはClaude Codeに書かせるのが現実的です。「Retry-Afterを尊重した指数バックオフ付きで書き直して」と指示すれば、適切なラッパー関数まで含めて出力されます。

3. 応用・発展

3.1 Microsoft 365 Copilot との設計境界

Microsoft 365をAIで扱う議論で必ず出るのが、Microsoft 365 Copilotとの関係です。実際の検討場面でも「Copilotがあるのに、なぜClaudeを併用するのか」という質問は頻出します。結論を先に置くと、両者は競合関係ではなく、動作するレイヤと得意領域が異なります。

設計判断としては、アプリの中で「いま書いている文章・いま作っている表」を支援する場面はCopilot、Outlook → Teams → SharePointを跨いだ後処理や定期実行はClaudeに寄せる、という分業が自然になります。課金構造の違いも判断材料になります。Copilotは対象ユーザー数が費用の主変数、Claude(特にAPIとClaude Code経由)は処理ボリュームが主変数です。配布対象が広く日常利用させたいならCopilot、特定の自動化に処理を集中させたいならClaude側、という切り分けが目安です。

3.2 セキュリティと運用設計

書き込みアクセスを持つエージェントをMicrosoft 365に常駐させる以上、本番投入前に詰めておくべき論点があります。

スコープの最小化:「とりあえず便利だから」とFiles.ReadWrite.AllやMail.Sendをアプリ登録時に付与すると、後から外すのは難しくなります。アプリ登録は最小スコープから始め、ユースケース追加のたびに必要分のみ追加してください。SharePointの特定サイトに限定するSites.Selected、特定メールボックスに限定するApplicationAccessPolicyといった細粒度の制御を可能な限り使います。読み取り専用と書き込みありで別アプリとして登録し、用途別にトークンを分離するのも有効です。

条件付きアクセス:サーバサイドの無人実行ではクライアントクレデンシャルフローを使うことになります。委任権限ではなくアプリ権限になるため、原則としてテナント全体に作用します。Entra IDの条件付きアクセスポリシーで実行端末・IP・MFAを縛る対応が並行して必要です。

監査と可逆性:削除、外部共有、一斉送信といった可逆性の低い操作には、人間の承認ゲートを設けます。Microsoft 365監査ログの保管期間と通知先を事前に設定し、「誰のアプリトークンがどのAPIを叩いたか」を後から追える状態にしておきます。

3.3 CLAUDE.md でのガードレール設計

Claude CodeにMicrosoft 365操作を任せる際、リポジトリ直下のCLAUDE.mdに禁止事項と要承認事項を明文化しておくと、エージェントが自律実行を停止して人間に確認を求めやすくなります。否定形・上限値で書くと効きやすいというのが、運用してみての知見です。

# Microsoft 365 操作のガードレール

## 触れてはいけない場所
- OneDrive 上の `Confidential/` 配下のファイル
- SharePoint サイト `legal-team` 配下のすべて
- ユーザー個人の `Personal/` フォルダ

## 必ず人間の承認を取る操作
- 外部ドメイン宛のメール送信（1通でも要承認）
- ファイルの削除
- ファイルの外部共有リンクの作成・更新
- カレンダーへの第三者招待

## 上限値・しきい値
- メール一斉送信は1回あたり10件まで
- API のリトライは1リクエストあたり最大3回まで
- 1セッションでの書き込み API 呼び出しは合計100回まで

## 失敗時の動作
- 429 を3回受け取った場合は処理を停止し、人間に通知する
- 4xx/5xx が連続した場合は即座に停止する

Claude Codeはこのファイルを毎セッション参照し、定義された制約に違反する操作を実行する前に確認を求めます。Human in the Loop活用例で扱った承認フローの考え方と組み合わせることで、エージェントを自律実行させつつ事故を抑えられます。

4. まとめと結論

本記事の要点を整理します。

• 連携経路は2系統:対話的な検索・要約はコネクタ方式、書き込みを含む定型処理はClaude Code方式。前者は数クリック、後者はアプリ登録とスコープ設計が必要
• API レイヤへの直接アクセスが堅牢性の源泉:画面操作型RPAよりUI変更耐性が高く、Microsoft 365監査ログでトレーサビリティが取れる。一方、レート制限への対応は実装側の責任
• Microsoft 365 Copilotとは分業:アプリ内の生成支援はCopilot、アプリ横断の自動化はClaude。課金構造も異なるため、配布人数中心か処理量中心かでコスト試算の主変数が変わる
• 運用設計を事前に固める:スコープの最小化、委任権限とアプリ権限の使い分け、条件付きアクセス、CLAUDE.mdでの破壊的操作ガードレールを最初に決める

これまでの業務オートメーションは、画面の見た目に縛られていました。Microsoft Graphを介して構造化されたデータに直接触れ、自然言語で操作内容を記述できるようになったことで、保守性と拡張性の両面でこれまでとは別の選択肢が用意された段階に入っています。技術選定の前に「誰が、何の権限で、いつ動かすのか」を定義しておくことが、安定運用の前提になります。

---

※本記事の情報は2026年5月時点のものです。Microsoft Graph APIのスコープ仕様、CLI for Microsoft 365のコマンド体系、Claude Codeの機能は更新される可能性があります。コードサンプルは骨格を示すものであり、本番投入時はレート制限のリトライ・例外処理・ロギング・テストを必ず追加してください。