Microsoft Graph の OAuth 2.0 を理解する: 委任されたアクセス許可とアプリケーションのアクセス許可

By Mirko Peters · 2026-08-11 · Updated 2026-08-28

ブログへようこそ。Microsoft 365 の自動化を深く掘り下げてきた方なら、ネイティブ コネクタや従来のスクリプトの制約にぶつかった経験があるのではないでしょうか。M365 を自動化する際、認証の仕組みは複雑になりがちで、堅牢なセキュリティと円滑な機能性の両立は難しい課題です。カスタムのエンタープライズ アプリケーションを構築する場合も、自動化されたバックグラウンド処理を設定する場合も、認証モデルをしっかり理解することが欠かせません。この記事では、トークン、スコープ、同意フローを解説し、ユーザー中心の処理と無人のバックグラウンド ジョブのどちらに適したモデルを選ぶべきかを整理します。では早速、OAuth 2.0 が Microsoft Graph API をどのように支えているのかを見ていきましょう。

Automatically translated with AI from the original post. Read the English original

ブログへようこそ。Microsoft 365 の自動化を深く掘り下げてきた方なら、ネイティブ コネクタや従来のスクリプトの制約にぶつかった経験があるのではないでしょうか。M365 を自動化する際、認証の仕組みは複雑になりがちで、堅牢なセキュリティと円滑な機能性の両立は難しい課題です。カスタムのエンタープライズ アプリケーションを構築する場合も、自動化されたバックグラウンド処理を設定する場合も、認証モデルをしっかり理解することが欠かせません。この記事では、トークン、スコープ、同意フローを解説し、ユーザー中心の処理と無人のバックグラウンド ジョブのどちらに適したモデルを選ぶべきかを整理します。では早速、OAuth 2.0 が Microsoft Graph API をどのように支えているのかを見ていきましょう。

Microsoft Graph 認証の概要

Microsoft Graph は、Microsoft 365 エコシステム全体への統合ゲートウェイです。Exchange、SharePoint、Teams、Azure Active Directory(現在の Microsoft Entra ID)それぞれに個別に分かれた API を使う代わりに、開発者や IT 管理者は単一のエンドポイントからこれらのサービスすべてにアクセスできます。一方で、Graph は機密性の高い企業データへのアクセスを制御するため、このゲートウェイの保護には厳格な認証の仕組みが必要です。ID、アクセス トークン、アクセス許可がどのように関係するかを理解することが、負荷がかかっても壊れず、セキュリティ フラグを立てられない信頼性の高い自動化を構築する第一歩になります。

Microsoft 365 における OAuth 2.0 の仕組み

Microsoft Graph の認可の中核には OAuth 2.0 プロトコルがあります。アプリケーションやスクリプトが Graph と通信する場合、資格情報をそのまま送信することはできません。代わりに、Microsoft ID プラットフォーム(Entra ID)からアクセス トークンを取得する必要があります。このアクセス トークンは、安全なデジタル パスポートの役割を果たします。誰がリクエストしているのか、どのアプリケーションが使われているのか、そして最も重要な点として、そのトークンにどの具体的なアクセス許可(スコープ)が付与されているのかを Microsoft Graph に伝えます。有効なトークンがなければ、Graph は標準の未承認エラーで即座にリクエストを拒否します。

委任されたアクセス許可: ユーザーとして実行する場合

どの権限モデルを選ぶかは、ワークロードの性質に完全に依存します。委任されたアクセス許可は、サインインしたユーザーの権限を借りて動作するアプリ向けに設計されています。委任されたアクセス許可を使用すると、アプリは現在サインインしているユーザーの代理として動作します。ユーザーが自分の予定表を読み取ったりプロフィール写真を更新したりするスクリプトを実行した場合、Graph はそのアプリに許可された操作だけでなく、そのユーザー自身がアクセスできる範囲も基に要求を評価します。ユーザーが特定のメールボックスを表示する権限を持っていなければ、委任されたトークンでもそのメールボックスにはアクセスできません。このモデルは、ユーザー向けのアプリケーション、対話型ツール、個人の生産性向上スクリプトに最適です。

アプリケーションのアクセス許可: 無人のバックグラウンド ジョブを実行する

一方で、キーボードの前にユーザーがいない深夜にスクリプトやサービスを実行する必要がある場合はどうでしょうか。無人のバックグラウンド ジョブ、デーモン サービス、テナント全体のレポート ツールには、アプリケーションのアクセス許可が必要です。このモデルでは、アプリケーションはどのユーザーのコンテキストからも独立して動作し、独自の ID で実行されます。対話的にサインインして同意を与える人間のユーザーがいないため、アプリケーションのアクセス許可には、テナント管理者による明示的な事前承認が必要です。いったん付与されると、アプリは組織全体のデータにアクセスできます。そのため、管理の自動化、オンボーディング スクリプト、コンプライアンス監視に非常に強力ですが、厳格なセキュリティ監視も求められます。

スコープ、トークン、同意フローの理解

認証と認可の用語は難しく感じられることがありますが、処理の流れを分解して見ると理解しやすくなります。スコープとは、アプリケーションが要求する具体的なアクセス許可のことです。たとえば User.Read.All や Mail.Read などがあります。ユーザーや管理者がアプリを承認するとき、これらのスコープを確認し、承認しています。承認されると、ID プラットフォームが JSON Web Token（JWT）を発行します。コードは、Microsoft Graph へ送信するすべてのリクエストの HTTP Authorization ヘッダーにこのトークンを含めます。同意を正しく管理しておけば、予期しない障害に遭遇することなく、アプリはスムーズにトークンを取得できます。

管理者の同意待ちで足止めされないために

開発者や管理者がよく直面する摩擦の一つが、管理者の承認待ちで止まってしまうことです。アプリケーションが特権の高いアプリケーション スコープや、機密性の高い委任されたスコープを要求すると、Microsoft Entra ID は、トークンを発行する前に管理者による同意を必要とすることがあります。デプロイ パイプラインがユーザー自身による同意を前提としていると、テナントのポリシーによって突然ブロックされ、自動化処理全体が停止してしまいます。こうした事態を避けるには、必要なアクセス許可を事前に洗い出し、ビジネス上の理由を文書化し、必要に応じてグローバル管理者やアプリケーション管理者と連携して、テナント全体の同意を事前に構成しておいてください。

よくある落とし穴と対処法

経験豊富な開発者であっても、Microsoft Graph を扱う際に認可で厄介な問題に突き当たることがあります。よくある問題と解決方法をいくつか見ていきましょう。

• 自分の環境では動くが、他の人の環境では失敗する: 多くの場合、同意の不足または誤ったスコープが原因です。対処法: 必要なスコープを明確に文書化し、適切な場合はテナント全体の管理者同意を構成します。
• 巨大なペイロードを過剰に取得する: ユーザー一覧をフィルターせずに全件取得すると、タイムアウトやスロットリングにつながります。対処法: $select、$top、ページング、デルタ クエリを使用します。
• 401/403 の無限ループ: トークンの有効期限切れや、ユーザーが存在しないジョブで委任されたアクセス許可の種類を使っていることが原因です。対処法: 堅牢なトークン更新処理を実装し、バックグラウンド タスクにはアプリケーション許可に切り替えます。
• レート制限に達する: 429 の応答が返ってくるのは、リクエストを速すぎる速度で送信していることを意味します。対処法: 指数バックオフを実装し、Retry-After ヘッダーに従い、操作をバッチ処理します。
• シークレットの乱立: スクリプトにクライアント シークレットを直接記述することは、重大なセキュリティリスクです。対処法: Azure Key Vault、マネージド ID、または安全な環境変数を活用します。

セキュリティとガバナンスのベスト プラクティス

API 経由で Microsoft 365 テナントへの扉を開くときは、セキュリティを最優先にしてください。最小特権の原則に従い、アプリケーションが機能するために絶対に必要な最小限のスコープだけを要求します。ユーザーの表示名を読むためだけに Directory.AccessAsUser.All を要求することは、決してあってはなりません。どのアプリがテナントにアクセスできるかを示す同意の一覧を整備し、開発、テスト、本番のアプリケーション登録を完全に分離し、クライアント シークレットと証明書を定期的に更新する厳格なスケジュールを定めてください。

最初の実用的なクエリ（例）

認証モデルの準備ができたら、Graph API に対してクエリを実行し始められます。すぐに応用できる実用的な例をいくつか紹介します。

• 指定日以降に入社した新入社員:
  GET /users?$filter=createdDateTime ge 2025-10-01T00:00:00Z&$select=id,displayName,mail,department
• 直近の予定会議:
  GET /me/events?$top=10&$select=subject,start,end,organizer,webLink
• グループのメンバー:
  GET /groups/{group-id}/members?$select=id,displayName,mail
• 変更されたユーザー（デルタ）:
  GET /users/delta?$select=id,displayName,mail

おすすめのツール

適切なツールを使うと、Microsoft Graph のクエリの作成とデバッグがはるかに簡単になります。Graph Explorer は、エンドポイントのテストや同意に関するヒントを確認できる、非常に便利な Web ベースのプレイグラウンドです。コードを書く場合は、Microsoft Graph SDK（.NET、JavaScript、Python）が HTTP 処理の大部分を抽象化してくれます。IDE 内の Postman や REST Client 拡張機能は、コレクションや環境の管理に優れています。Power Automate、Logic Apps、PowerShell は、ビジュアルな運用ワークフローの自動化を見事にこなします。

よくある質問

委任とアプリケーション、どちらを選ぶべきか？

ユーザー中心のタスクには、委任されたアクセス許可が最適です。無人で実行されるジョブ、バックグラウンドのデーモン、広範な管理タスクには、適切な管理者の同意を伴うアプリケーションのアクセス許可が必要です。

スロットリングを回避するにはどうすればよいですか？

$select を使ってペイロードのサイズを抑え、ページングとデルタ クエリを実装し、可能な場合はバッチ要求をまとめてください。また、スクリプトは必ず 429 状態コードを適切に処理し、再試行のロジックを組み込むように作成してください。

コードを書かずに Graph を使うことはできますか？

はい！Graph Explorer でエンドポイントを試作し、Power Automate でワークフローを構成できます。複雑なロジックが必要になったら、公式の SDK または PowerShell スクリプトに移行してください。

Graph はコンプライアンス レポートに使えるほど安全ですか？

もちろんです。最小特権の原則、集中ログ記録、監査可能な同意フロー、安全なシークレット管理に基づいて実装すれば、Microsoft Graph は厳格なエンタープライズのコンプライアンス基準を満たします。

まとめ

Microsoft Graph における認証を習得することは、Microsoft 365 の能力を真に引き出したいすべての管理者、アーキテクト、開発者にとって決定的な鍵となります。委任されたアクセス許可とアプリケーションのアクセス許可の重要な違いを理解し、スコープとトークンを慎重に管理し、厳格なセキュリティ ガバナンスに従うことで、強力かつ安全な自動化を構築できます。このトピックをさらに深く掘り下げ、コード サンプルを確認し、エラー処理とスロットリングの高度な戦略を学ぶには、関連するポッドキャスト エピソード Automate Microsoft 365 with Microsoft Graph API をぜひご覧ください。自動化を楽しんでください！