はじめに
Dress Code Advent Calendar 2025の8日目の記事です。
こんにちは！
最近、ビジネスネームを持った方が続々入社されて、自分も何か欲しいなぁと思う今日この頃です。
この記事では、 Microsoft Graph API を活用した新機能を実装する際に調査・検討した3つの認証方式について解説します。
Microsoft 365 / Microsoft Entra ID と連携する機能を開発する際、「どの認証方式を選べばいいんだろう？」と悩んだ経験はありませんか？
実は認証方式によって、実装の複雑さ、セキュリティ、運用コスト、スケーラビリティが大きく変わってきます。
この記事では、それぞれの認証方式の特徴、適したユースケース、そして実装のポイントを詳しく解説します。
公式ドキュメントも充実してる Microsoft Graph API ですが、解釈に自信を持つために他の記事を探してる方の参考になればと思います。
想定読者
この記事は 「Microsoft Graph API を SaaS に組み込むことを検討しているエンジニア」 を想定しています。（数ヶ月前の私ですね）
OAuth 2.0 や Microsoft Entra ID（旧Azure AD）の基本的な知識がある前提で解説しますが、初めて触れる方でも理解できるよう、重要な用語には説明を加えています。
TL;DR
Nano Banana Proにこの記事の概要を作成してもらいました。良い時代ですね
前提知識：Microsoft Graph API とアプリ登録
まず、本題に入る前に基本的な概念を押さえておきましょう。
Microsoft Graph API とは？
Microsoft Graph API は、Microsoft 365 のデータ（ユーザー情報、メール、カレンダー、ファイルなど）やその他のMicrosoft クラウドサービスに統一的にアクセスできる REST API です。
https://graph.microsoft.com/v1.0/me
↑ このような URL で Microsoft 365 や Microsoft EntraID のデータを取得・操作できる
様々な Microsoft サービスのデータを、単一のエンドポイントで扱えるのが特徴です。
「アプリの登録」とは？
Microsoft Graph API を使って単一ユーザーだけでなくテナント内の複数ユーザーやテナント自体の情報にアクセスするには、
まず Microsoft Entra 管理センター でアプリを登録 する必要があります。
アプリ登録によって以下が払い出されます
- Client ID（アプリケーションID）: アプリを一意に識別するID
- Client Secret（クライアントシークレット）: アプリの認証に使う共有シークレット
- 権限設定: どのデータにアクセスできるかの設定
これらを使って、Microsoft のサーバーに「私はこのアプリです」と証明し、データにアクセスします。
アプリ登録 = API を使うための「利用証明書の発行」
アプリ登録によって、アプリと Microsoft ID プラットフォームの間に信頼関係が確立されます。
参考: アプリケーションの登録
「マルチテナントアプリ」とは？
SaaS企業側で1つのアプリ登録を作成し、複数の顧客テナントから利用できるようにする仕組みです。
SaaS企業のテナント
└─ マルチテナントアプリ（Client ID: abc123）
↓ Admin Consent
├─ 顧客A のテナント（同意済み）
├─ 顧客B のテナント（同意済み）
└─ 顧客C のテナント（同意済み）
これにより、顧客ごとにアプリを登録する必要がなく、スケーラブルな運用が可能になります。
アプリはどこに登録するのか？
ここが重要なポイントです。アプリ登録には 2つの選択肢 があります。
-
顧客のテナントに登録
- 顧客が Client ID/Secret を管理
- 顧客ごとに個別のアプリが存在
-
SaaS企業側のテナントに登録
- SaaS企業が Client ID/Secret を管理
- 複数の顧客に対して同じアプリを使い回せる（マルチテナントアプリ）
この違いが、後述する認証方式の選択に大きく影響します。
Microsoft Graph API の3つの認証方式
1. ユーザー委任（Delegated Permissions）
特徴
- Authorization Code Flow を使用
- ユーザー本人として認証し、そのユーザーのデータにアクセス
- OAuth 2.0 の標準的な使い方
- SaaS企業側のテナントでアプリ登録が必要（ただしマルチテナント設定は不要）
適している用途
カレンダー、メール、OneDrive などの個人データ操作に向いています。
特に、SaaSアプリへの初回ログイン時の連携設定や、UI 上でユーザー自身がトリガーする機能には最適です。
- 例: 「自分の予定を確認する」「自分のファイルをアップロードする」
- 初回同期の設定操作
- 本人のデータへのアクセスが必要な機能
Authorization Code Flow の仕組み
ユーザーが直接ログインして、アプリに権限を委任する流れです。
トークンは「ユーザーの代理」として機能するため、ユーザーがアクセスできるデータのみ取得可能です。
この方式を選ぶ場合の考慮点
バックグラウンド同期や全社横断のデータ取得には向いていません。
ユーザーのセッションに依存するため、バッチ処理での利用は避けた方が良いでしょう。また、トークンの有効期限管理も複雑になりがちです。
参考: Authorization Code Flow の詳細
2. 顧客側アプリの利用（Application Permissions）
特徴
- Client Credentials Flow を使用
- 顧客のテナント内にアプリを登録
- 顧客が Client ID/Secret を管理
適している用途
セキュリティ要件が厳しい大企業や、金融・医療など高度なコンプライアンスが必要な領域に向いています。資格情報を自社で完全管理したい顧客にとっては、最も安心感の高い選択肢です。
Client Credentials Flow の仕組み
アプリが独立して認証し、ユーザーなしでデータにアクセスする流れです。
ユーザーのログインが不要で、アプリ自身の権限でデータにアクセスします。バッチ処理に最適な方式です。
この方式を選ぶ場合の考慮点
顧客ごとにアプリ登録作業が発生するため、スケールしにくいという課題があります。
オンボーディングの工数やサポートコストが高くなるため、顧客数が多い SaaS では運用が大変になる可能性があります。
また、顧客が SaaS アプリに Client ID/Secret を提供する際は、以下のセキュリティ上の配慮が重要です。
- 安全な転送方法: Client Secret は必ず暗号化された経路（HTTPS、専用の設定画面など）で提供してもらう
- 最小権限の原則: アプリ登録時に、必要最小限の API 権限のみを設定してもらうようガイドを提供
- 定期的なローテーション: Client Secret の有効期限を設定し、定期的に更新してもらう運用を推奨
- 取り消し可能性: 顧客側でいつでも Secret を無効化できることを説明し、透明性を確保
参考: Client Credentials Flow の詳細
3. SaaS企業側アプリ + Admin Consent の利用（Application Permissions）
特徴
- Client Credentials Flow を使用
- SaaS企業側でマルチテナントアプリを登録
- 顧客管理者が Admin Consent（管理者同意） 経由で権限を付与
適している用途
多数企業向け SaaS での利用に最適です。全社横断のデータ収集・同期や、バッチ処理、スケジュール実行など、スケーラブルな運用が求められる場面で力を発揮します。
導入が容易（同意 URL をクリックするだけ）で、1つのアプリで複数テナントに対応できるため、運用がシンプルになります。
Admin Consent（管理者同意）の仕組み
Admin Consent は、顧客の管理者が SaaSアプリに権限を付与する仕組みです。
裏側の仕組みとしては「2. 顧客側アプリの利用」と同じですが、
ユーザー（顧客管理者）の体験としては「1. ユーザー委任」と似て権限を委任する流れに近いです。
（わたしは「SaaS企業が作成した利用証明書に、顧客管理者がハンコを押す」イメージで理解してます。）
この方式を選ぶ場合の考慮点
資格情報を SaaS企業側で管理するため、顧客への透明性が重要です。
共有シークレット（Client Secret）の定期ローテーションや Azure Key Vault での安全な保存、Managed Identity の活用など、セキュリティ対策が必要になります。
また、過剰権限の付与を避けるため、最小権限スコープの設計（必要な権限のみ要求）や、権限変更時の顧客への通知、定期的な権限レビューも重要です。
同意が取り消された場合に備えて、同意取り消しイベントの検知や、定期的な API チェックによる同意状態の確認、適切なエラーハンドリングと顧客通知の仕組みも用意しておくと良いでしょう。
参考: 管理者の同意エクスペリエンス
まとめ
Microsoft Graph API を使った新機能開発では、要件に応じた認証方式の選択が重要です。
3つの認証方式の比較
調査結果を表にまとめると以下のようになります。
| 方式 | OAuth Flow | アプリ登録場所 | 資格情報管理 | 導入の手間 | スケーラビリティ | 主な用途 |
|---|---|---|---|---|---|---|
| 1. ユーザー委任 | Authorization Code | SaaS テナント | ユーザー | 低 | 低 | 個人データ操作 |
| 2. 顧客側アプリの利用 | Client Credentials | 顧客テナント | 顧客 | 高 | 中 | 高セキュリティ要件 |
| 3. SaaS企業側アプリ + Admin Consent の利用 | Client Credentials | SaaS テナント | SaaS | 低 | 高 | 多数企業向け SaaS |
なぜ顧客側でのアプリ登録が高セキュリティ要件に適してるのか？
顧客テナント内にアプリを登録すると、以下のメリットがあります。
-
資格情報の管理主体が顧客
- 共有シークレット（Client Secret）を顧客が管理
- SaaS企業にシークレットを渡しても顧客側でいつでも無効化可能
-
権限の完全なコントロール
- 顧客の管理者がアプリに付与する権限を直接設定
- Microsoft Entra 管理センター で権限を追加・削除できる
- より厳格な監査が可能
-
データの所在の明確性
- データが顧客テナントから外部に流れる経路が明確
- コンプライアンス要件に適合しやすい
これらの理由により、顧客視点では「自分たちが発行した鍵で、自分たちのデータにアクセスさせる」ことになるため、より安心感が高くなります。
選択のポイント
-
個別に個人データの操作を行う
- → 権限を広げすぎず個別に承認がしやすい「ユーザー委任」を選択
-
複数テナント・ユーザーデータの一括操作を行う
- → スケーラビリティを重視して「SaaS企業側アプリ + Admin Consent の利用」を選択
-
複数ユーザーデータの一括操作を行う(高セキュリティが求められる)
- → 細かな要件は顧客側で満たしてもらうため「顧客側アプリの利用」を選択
-
SaaSじゃないけど自社の複数ユーザーデータの一括操作を行う
- → スケーラビリティが必要ないので「顧客側(というか自社)アプリの利用」を選択
これまでの内容を踏まえて、わたしの思う認証方式選択のポイントを以上のようにまとめました。
もし、このポイントのまとめ方や他情報の認識に誤りがあると感じられた方は是非コメントにてご指摘いただけると嬉しいです！
終わりに
「Microsoft系のドキュメント、情報量多いし専門用語多くて難しいよぉ」とMicrosoftで働く友人にボヤいたら、「ChatGPTに聞いたことを正として、手を動かすのが一番理解早いよ！」と言ってました。
このAI時代にエンジニアやれて幸せだなぁ。
参考リンク
Discussion