委任されたアクセス許可とアプリケーション許可の違い：アプリに適したモデルの選び方

By Mirko Peters · 2026-08-11

ポッドキャストと、Microsoft 365、Azure、そして現代のクラウド エコシステムを支える開発者ツールを習得するための連載へようこそ。Microsoft Graph API を使ってインテグレーションを作成したり、スクリプトを書いたり、エンタープライズ オートメーションをデプロイしたりしたことがあれば、アクセス許可の壁に必ず突き当たったことがあるでしょう。機能するアプリケーションを構築しながらテナントを保護することは、管理者や開発者が直面する最も重要なバランス調整のひとつです。どのアクセス許可モデルを選ぶかは、セキュリティ態勢、デプロイの速度、システム アーキテクチャ全体に直接影響します。

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

ポッドキャストと、Microsoft 365、Azure、そして現代のクラウド エコシステムを支える開発者ツールを習得するための連載へようこそ。Microsoft Graph API を使ってインテグレーションを作成したり、スクリプトを書いたり、エンタープライズ オートメーションをデプロイしたりしたことがあれば、アクセス許可の壁に必ず突き当たったことがあるでしょう。機能するアプリケーションを構築しながらテナントを保護することは、管理者や開発者が直面する最も重要なバランス調整のひとつです。どのアクセス許可モデルを選ぶかは、セキュリティ態勢、デプロイの速度、システム アーキテクチャ全体に直接影響します。

この内容をさらに掘り下げるために、最近詳細なエピソードを収録しました。完全な音声ディスカッションは Microsoft Graph Permissions and Consent Models Explained でご覧いただけます。このコンパニオン ブログ記事では、委任されたアクセス許可とアプリケーション許可の中核的な違いを解説し、同意モデルを確認し、ベスト プラクティスを紹介するとともに、アプリを安全かつコンプライアンスに適合した状態に保つための包括的なフレームワークを示します。

Microsoft Graph API のアクセス許可の概要

特定の認可フローの詳細に入る前に、Microsoft Graph API のアクセス許可が実際に何であるかを理解しておくと役立ちます。Microsoft Graph の本質は、Exchange Online、SharePoint、Microsoft Teams、OneDrive、Azure Active Directory（Microsoft Entra ID）など、Microsoft 365 サービスに存在するデータへの統合ゲートウェイとして機能することです。開発者が複数の独立したエンドポイントに対して個別に認証を行う必要はなく、Microsoft Graph は単一の REST API エンドポイントを提供します。一方で、この API は組織のデジタル資産のほぼすべての領域へのアクセスを可能にするため、保護には堅牢で粒度の細かいアクセス許可の仕組みが欠かせません。

委任されたアクセス許可とアプリケーション許可

Microsoft ID プラットフォームにアプリケーションを登録する際は、アプリがリソースとどのようにやり取りするかを明示的に宣言する必要があります。これは本質的に、2 つの主要なアクセス許可の種類、つまり委任されたアクセス許可とアプリケーション許可のどちらを選ぶかに帰着します。この選択によって、アプリの認証方法、アプリが誰（または何）を代表するか、そして取得できるデータの範囲が決まります。

委任されたアクセス許可は、サインインしたユーザーが実際に操作しているクライアント側のアプリケーションやユーザー向けのアプリ（シングルページ Web アプリ、モバイルアプリ、デスクトップ ユーティリティなど）を想定した仕組みです。このモデルでは、アプリはユーザーの*代理として*動作します。アプリがアクセスしてデータを操作できるのは、そのユーザー自身が実行する権限を持つ範囲に限られます。ユーザーがアプリを起動すると、サインインと明示的な同意を求められ、ユーザーの ID と同意済みのスコープの両方を含む OAuth 2.0 アクセス トークンが発行されます。

一方、アプリケーション許可は、ユーザーのコンテキストに依存せず動作するバックグラウンド サービス、デーモン、Web ジョブ、自動化された Runbook などで使用されます。この場合、アプリは独自の ID で実行されます。クライアント シークレット、公開鍵／秘密鍵の証明書のペア、マネージド ID などのクライアント資格情報を使用して、Azure AD からアプリ専用のアクセス トークンを取得します。認証を行うために画面の前に座っている人間のユーザーがいないため、これらのアクセス許可はテナント全体のリソースにまたがります。そのため、セキュリティ リスクははるかに高く、常にテナント管理者による明示的な同意が必要です。

主な違いとユース ケース

各アクセス許可モデルをいつ実装すべきかを理解することは、アーキテクチャ上のボトルネックやセキュリティの脆弱性を防ぐことにつながります。それでは、簡単な比較を見てみましょう。

• 委任されたアクセス許可: アプリはユーザーのために動作します。ユーザーはサインインして同意する必要があります。アプリは、ユーザーが参照できるデータしか参照できません。このモデルは、個人の予定表やメールなどの個人データを読み書きするクライアント アプリに最適です。
• アプリケーション許可: アプリは自身として動作します。サインインするユーザーは不要です。管理者による同意が必要です。アプリは、テナント全体のデータを参照および変更できます。このモデルは、バックグラウンドの同期、管理レポート、自動化されたガバナンス ジョブに最適です。

適切なモデルの選択は、アプリケーションのアーキテクチャに完全に依存します。たとえば、ユーザーのプロファイルと個人の受信トレイを表示する対話型ダッシュボードを構築する場合は、委任されたアクセス許可を使用する必要があります。逆に、コンプライアンス監査のために組織内のすべてのメールボックスを毎晩深夜にスキャンする自動化スクリプトを開発する場合は、アプリケーションのアクセス許可が必要です。

Microsoft Graph における委任されたアクセス許可

委任されたアクセス許可の仕組み

委任されたアクセスは、ユーザーのIDと深く結び付いています。アプリが委任されたアクセス許可を要求すると、基本的には、定義された範囲内でサインインしているユーザーになりすます許可を認可サーバーに求めることになります。OAuth 認可コード フローを通じて返されるアクセス トークンには、ユーザー固有の権限とアプリが要求したアクセス許可の両方を反映した、特定のスコープ クレームが含まれています。

• 委任されたアクセスとは、アプリがユーザーとして直接動作することを意味します。
• アプリの登録と個々のユーザーの両方が、適切な基礎となる権限を持っている必要があります。
• スコープは、アプリがユーザーに代わって実行できることの正確な上限を定義します。
• 結果として得られるアクセス トークンは、アプリケーションのIDとユーザーのコンテキストを一体化させます。

委任されたアクセス許可の一般的なシナリオ

委任されたアクセス許可は、日常的な生産性向上の連携の大部分を支えています。たとえば、企業向けのメモアプリがユーザーの OneDrive アカウントにファイルを同期する必要がある場合は、Files.ReadWrite スコープを要求します。ユーザーに特定のドキュメントへのアクセス許可がない場合、アプリのスコープが技術的に許可していても、Graph API はその要求を拒否します。同様に、Microsoft Graph SDK を使用してユーザーに代わって自動メール通知を送信するアプリは、Mail.Send のような委任スコープを利用します。

セキュリティと同意に関する考慮事項

委任されたアクセス許可は、ユーザーの制約によって範囲が限定されるため、テナント全体のアプリケーションのアクセス許可よりも本質的に安全です。しかし、それでも固有のセキュリティ上の課題があります。たとえば、ユーザーのメールボックス全体やディレクトリ プロファイルへのフル アクセスといった過度に広範なスコープをアプリが要求すると、フィッシング攻撃やアプリの侵害が成功した場合に、機密性の高い個人データが露出するおそれがあります。開発者は最小特権の原則を厳守し、当面の機能に必要な特定のスコープのみを要求する必要があります。

Microsoft Graph におけるアプリケーションのアクセス許可

アプリケーションのアクセス許可の仕組み

アプリケーションのアクセス許可は、認証の過程から人の関与を取り除きます。サインイン プロンプトで操作する代わりに、アプリはクライアント資格情報を使用して Microsoft Entra ID に直接認証します。結果として得られるトークンには委任されたスコープではなくアプリ ロールが含まれ、サービス プリンシパルにテナント全体のリソースへの広範で制約のないアクセスを付与します。

• アプリケーションのアクセス許可は、サインインしたユーザーがいなくても完全に機能します。
• アプリは、リソースに問い合わせるためにアプリ専用のトークンを取得します。
• アクセスは、個々のユーザーの権限ではなく、サービス プリンシパルに割り当てられたアプリ ロールによって管理されます。

アプリケーションのアクセス許可を使用する場面

アプリケーションのアクセス許可は、バックエンドのワークロード、無人で動作するデーモン、システム間連携に厳密に限定すべきです。例としては、ユーザー プロビジョニングの自動化エンジン、集中型のバックアップ システム、セキュリティ インシデント対応ツール、テナント移行スクリプトなどがあります。

管理者の同意とセキュリティへの影響

アプリケーションのアクセス許可は個々のユーザーの制約を迂回し、テナント全体へのアクセスを付与するため、一般ユーザーは同意できません。アプリケーションの同意を付与できるのは特権管理者のみです。信頼できない、またはコーディングの不十分なバックグラウンド アプリに Directory.ReadWrite.All や Mail.ReadWrite.All を付与するといった誤った構成は、Microsoft 365 テナント全体が完全に侵害される脆弱性につながるおそれがあります。エンタープライズ アプリケーションのサービス プリンシパルは、必ず定期的に監査してください。

Microsoft Graph API アクセス許可のメリットとデメリット

メリット

• 統一されたアクセス許可モデル: すべての Microsoft 365 サービスで一貫した単一の認可の仕組みがあるため、管理が簡素化されます。
• きめ細かなスコープ: 細分化された委任スコープとアプリケーション スコープにより、正確な最小特権のアーキテクチャを実現できます。
• 標準の OAuth2/OpenID Connect: 業界標準のセキュリティ プロトコルを活用し、ID 連携を簡単に実現できます。
• RBAC との統合: Azure AD のロールや条件付きアクセス ポリシーとシームレスに連携し、コンプライアンスを一元的に管理できます。
• 増分同意: 必要な権限をすべて最初に要求するのではなく、アプリが時間をかけて追加の権限を要求できます。

欠点

• 複雑さ: 委任されたスコープ、アプリ ロール、管理者の同意モデルが交差する部分は複雑で、初心者には負担が大きい場合があります。
• 高権限によるリスク: Sites.FullControl.All のような広範な権限を誤って構成すると、大量の企業データが公開される恐れがあります。
• 管理者の同意がボトルネックになる: 影響の大きい権限に管理者の承認を必要とすると、迅速な開発サイクルが遅くなる可能性があります。
• ドキュメントの分散: 開発者は正確な API の動作を把握するために、複数の Microsoft ドキュメント リポジトリを突き合わせて確認する必要があることがよくあります。

同意モデルとベスト プラクティス

Microsoft Graph における ユーザー同意と管理者同意

同意の取得方法を管理することは、組織のガバナンスにとって非常に重要です。ユーザー同意では、個人が自分の個人データへのアクセスをアプリに許可できます。管理者同意では、承認のゲートが IT 管理者に移り、管理者が組織全体を代表してアプリの要求を評価します。現代の企業のセキュリティ ベースラインでは、ユーザー同意を完全に無効にし、すべてのアプリの導入を正式な管理者による事前承認のワークフローで行うことが一般的になっています。

テナント ポリシーがアクセス許可に与える影響

企業のテナント ポリシーは、実行時のアプリの動作を根本的に変えることがあります。管理者が多要素認証 (MFA) や準拠したハイブリッド Azure AD 参加デバイスの要求など、厳格な条件付きアクセス ポリシーを適用している場合、その条件を満たさずに Graph トークンを取得しようとするアプリはブロックされます。開発者は、トークン取得の失敗を適切に処理し、明確なエラーの解決手順を提供するようアプリを設計する必要があります。

スムーズな同意フローのための戦略

ユーザーの手間や管理者側のボトルネックを防ぐため、コードを書く前にアクセス許可の戦略を計画してください。アプリは、最初に基本的な ID スコープだけを要求し、ユーザーが特定の機能に移動したときに初めて専用のリソース権限を要求する増分同意のパターンを実装してください。また、Microsoft Entra ID で自動化された事前承認ワークフローを活用すれば、厳格なセキュリティ監視を維持しながら開発を効率化できます。

Microsoft Graph API のアクセス許可に関して人がよく犯す間違い

• 委任されたアクセス許可とアプリケーションのアクセス許可を混同し、ユーザー コンテキストの要件を誤解すること。
• 最小特権の考え方を採用せず、最初に過剰な権限を要求すること。
• バックグラウンド サービスをデプロイする際に、管理者の同意要件を考慮しないこと。
• トークンを更新せずに、Azure portal での権限の変更が即座に反映されると考えること。
• クライアント資格情報トークンが必要な場面で、委任されたアクセス トークンを提示すること。
• 実行時に Graph API のリクエストをブロックする条件付きアクセス ポリシーを無視すること。
• 実行時にアプリケーション コード内でスコープ要求を検証することを怠ること。
• 付与されたアプリケーションのアクセス許可とサービス プリンシパルを、時間の経過とともに監査しないこと。

Microsoft Graph API アクセス許可のチェックリスト

次の実行可能なチェックリストを使用して、Microsoft Graph API のアクセス許可を安全に設計、実装、監査するチームを導いてください。

まとめ

Microsoft Graph API のアクセス許可は、苦労の種である必要はありません。委任されたアクセス許可（サインイン済みのユーザーを必要とし、ユーザーの制約内で動作する）と、アプリケーションのアクセス許可（制約を受けずにバックグラウンドで実行され、管理者の同意を必要とする）の運用上の違いを正しく理解すれば、安全でスケーラブルなソリューションを設計できます。最小特権の原則を徹底し、厳格な監査を行い、企業のガバナンス ツールを活用することで、イノベーションを妨げることなく Microsoft 365 環境を安全に保つことができます。

クラウド環境のセキュリティについての詳しいガイダンス、実例に基づく戦略、深掘り解説については、関連エピソードの完全版音声解説もぜひお聴きください: Microsoft Graph Permissions and Consent Models Explained。アクセス許可は厳しく、資格情報は安全に保ち、楽しくコーディングしてください！