ユーザーが、アクセス権のないファイルに委任されたアクセス許可を持つアプリからアクセスしようとするとどうなりますか？

アプリもそのファイルにアクセスできなくなります。委任されたアクセス許可はユーザーのIDを借用するため、アプリがユーザー個人のアクセス範囲を超えることはありません。

アプリケーションのアクセス許可における主なセキュリティリスクは何ですか？

アプリケーションのアクセス許可は、人の監視なしにバックグラウンドのサービスとして動作します。そのため、アプリの資格情報が侵害されると、攻撃者が社内全体のメールボックス、ファイル、リソースに無制限にアクセスできてしまう可能性があります。

Microsoft GraphはOAuthトークンやアクセス許可とどのように連携しますか？

Microsoft Graphは、Microsoft 365のAPIゲートウェイとして機能します。Graphへのすべてのリクエストには、委任されたアクセス許可またはアプリケーションのアクセス許可のいずれかを定義する特定のスコープを含むOAuthアクセストークンが必要です。

Microsoft Entra IDにおける委任されたアクセス許可とアプリケーションのアクセス許可：管理者が知っておくべきこと

Q: 一般ユーザーは、Microsoft Entra IDでアプリケーションのアクセス許可を承認できますか？

いいえ。アプリケーションのアクセス許可は、サインインしたユーザーがいない状態で動作し、テナント全体に及ぶ範囲を持ちます。そのため、適切なテナント権限を持つ管理者だけがアプリケーションのアクセス許可を付与できます。

By Mirko Peters · 2026-10-28

Microsoft Entra IDの委任されたアクセス許可とアプリケーションのアクセス許可の重要な違いを、セキュリティのベストプラクティスと最小特権の原則とあわせて解説します。

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

サードパーティ製ツールやカスタムアプリケーションをMicrosoft 365環境に統合する際には、委任されたアクセス許可とアプリケーションのアクセス許可の違いを理解することが不可欠です。これは、クラウドのセキュリティを維持し、データ漏えいを防ぎ、Microsoft Entra ID全体で最小特権の原則を徹底するために重要です。

重要なポイント

委任されたアクセス許可には、サインインしたユーザーが必要で、そのユーザーの代わりに動作します。そのため、アプリがアクセスできるのは、ユーザーが閲覧する権限を持つデータのみです。
アプリケーションのアクセス許可は、人間のユーザーなしで動作し、テナント全体に広範なアクセスを許可します。管理者の承認が必要です。
最小特権の原則では、アプリには常に、そのタスクを完了するために必要な最小限のアクセス許可だけを付与すべきとされています。
Microsoft Graphは、Microsoft 365データにアクセスするための統合された入口として機能し、これらのアクセス許可モデルに大きく依存しています。
この違いを理解しておくことで、サードパーティ製アプリケーションに意図しないテナント全体へのアクセス権を与えてしまうなど、深刻なセキュリティの穴を防げます。

MicrosoftクラウドにおけるOAuthアクセス許可の理解

外部の生産性ツールや社内の自動化スクリプトをMicrosoft 365ワークスペースに接続すると、基盤となるOAuth 2.0のワークフローが実行されます。ただし、アクセストークンを取得するだけでは不十分です。実際のセキュリティの境界は、そのトークンで実際に何ができるかによって定義されます。Microsoft Entra ID（旧Azure Active Directory）を中核とするMicrosoftのIDエコシステムでは、アクセス許可は根本的に異なる2つの種類、すなわち委任されたアクセス許可とアプリケーションのアクセス許可に分かれます。

これら2つのモデルを混同することは、IT管理者、開発者、パワーユーザーのいずれにとっても最もよくある落とし穴の一つです。適切でないアクセス許可の種類を選ぶと、社内全体のデータを誤って公開したり、アプリケーションの機能を完全に損なったりする恐れがあります。ここでは、それぞれの仕組み、どこで管理されるのか、そして正しく統制する方法を順に見ていきましょう。

委任されたアクセス許可：ユーザーに代わって動作する

委任されたアクセス許可は、画面の前に人間のユーザーがいるアプリ向けに設計されています。Microsoftアカウントを使用してモバイルアプリやWebサービスにサインインすると、そのアプリは特定の作業のためにあなたのIDを借用します。これが委任されたアクセス許可です。

この場合、アプリはあなたとして動作します。アクセスできるのは、あなたがすでにアクセス権を持っているデータだけで、それ以上はありません。ユーザーアカウントに特定のSharePointフォルダーや同僚のカレンダーへの読み取りアクセス権がなければ、アプリもそこにアクセスできません。影響範囲は個々のユーザーの権限によって自然に制限されるため、ワークフローに人が関わる場合は、委任されたアクセス許可の使用がMicrosoftによって推奨されています。

実際に委任されたアクセス許可が表示される場面

同意のプロンプトをクリックするたびに、委任されたアクセス許可とやり取りしています。スケジュール調整アシスタントが、あなたのカレンダーの読み取りを求める画面を表示することがあります。その要求は、特定のOAuthスコープを表しています。あなたが承認または拒否できる立場にいるため、あなたはリソースの所有者として、クライアントアプリケーションがあなたのプロファイルから借用できる内容を正確に管理しています。

アプリケーションのアクセス許可：バックグラウンドサービスとテナント全体へのアクセス

アプリケーションのアクセス許可は、まったく異なる考え方に基づいています。バックグラウンドで動作するデーモン、自動同期スクリプト、そして誰もサインインしていない深夜3時に稼働するバックエンドサービスのために設計されています。組織内のすべてのメールボックスからデータを集計する自動レポートツールを想像してください。

ユーザーが存在せず、ID のコンテキストを提供する主体がないため、アプリケーションは独自の資格情報（クライアント資格情報フローによるクライアント ID やクライアントシークレットなど）を使用して認証します。その結果、アプリケーションのアクセス許可によって、ツールは組織全体に対して自らの権限で操作できるようになります。アプリにメールを読み取るアプリケーションのアクセス許可がある場合、テナント内のすべてのユーザーのメールを読み取ることができます。

管理者の同意が必須である理由

アプリケーションのアクセス許可は非常に強力なため、一般ユーザーは同意できません。標準的な従業員は自分の予定表に対する委任されたアクセス許可を承認できますが、アプリケーションのアクセス許可には、グローバル管理者または特権ロール管理者による明示的な承認が必要です。この厳格な管理により、悪意のあるアプリや不適切にコーディングされたアプリが、組織全体のデータをひそかに収集することを防ぎます。

Microsoft Graph と OAuth スコープの役割

アプリケーションが委任されたアクセス許可を使うか、アプリケーションのアクセス許可を使うかにかかわらず、最終的にはすべてのリクエストが Microsoft Graph という単一の強力な窓口を経由します。呼び出し元のアプリが有効な OAuth アクセストークンを提示すれば、Microsoft Graph の背後にあるすべてのチャット、SharePoint ドキュメント、OneDrive ファイル、Outlook のメールにアクセスできます。

トークンを適切に制限するための安全策は「スコープ」と呼ばれます。スコープとは、トークン内に埋め込まれた明確なラベルで、予定表の読み取りとメールの送信のように、正確な境界を定義します。開発者が必要以上に広いスコープ（単純な読み取りアクセスで足りる場面で読み取りと書き込みの両方を要求するなど）を要求する場合、中核となるセキュリティのベストプラクティスに反します。管理者は、アプリの登録レビューの際にこれらのスコープを慎重に監査する必要があります。

Microsoft Entra ID でテナントの最小特権を徹底する

Microsoft Entra ID におけるセキュリティのベストプラクティスは、常に一つの黄金律に立ち返ります。それが最小特権の原則です。すべてのアプリ、サービスプリンシパル、自動化スクリプトには、そのタスクを完了するために必要な最小限のアクセス権のみを付与する必要があります。

人間のユーザーがアプリを操作する場合は、常にアプリケーションのアクセス許可よりも委任されたアクセス許可を優先してください。
同意の確認画面を精査し、アプリが不要なスコープを要求していないことを確認してください。
Microsoft Entra ID に登録されているエンタープライズアプリケーションを定期的にレビューし、孤立したトークンや未使用のアプリ登録を取り消してください。
ヘッドレス環境で動作するクライアント資格情報フローには、必ず管理者による監視を確保してください。

まとめ

最新のクラウド ID の仕組みを理解するには、単純なサインインボタンの先にある、基盤となるアクセス許可の構造に目を向ける必要があります。委任されたスコープを使うユーザー向けのモバイルアプリを管理する場合でも、アプリケーションのアクセス許可に依存する大規模なエンタープライズ自動化を管理する場合でも、こうした境界を理解することは、安全な Microsoft 365 環境にとって不可欠です。

これらの認証のしくみの基礎をさらに深く理解するには、ポッドキャストのエピソード全編をお聴きください。OAuth 2.0、トークンのライフサイクル、認証に関わる 4 つの役割について、専門用語を抑えたわかりやすい解説があります。

よくある質問

一般ユーザーは Microsoft Entra ID でアプリケーションのアクセス許可を承認できますか？

いいえ。アプリケーションのアクセス許可は、サインインしているユーザーなしで動作し、テナント全体に及びます。そのため、適切なテナント権限を持つ管理者のみがアプリケーションのアクセス許可を付与できます。

委任されたアクセス許可を持つアプリを通じて、ユーザーがアクセス権のないファイルにアクセスしようとするとどうなりますか？

アプリもそのファイルへのアクセスをブロックされます。委任されたアクセス許可はユーザーの ID を借用するため、アプリがユーザー個人のアクセス範囲を超えることは決してありません。

アプリケーションのアクセス許可の主なセキュリティリスクは何ですか？

アプリケーションのアクセス許可は人の監視なしにバックグラウンドサービスを実行するため、侵害されたアプリの資格情報によって、攻撃者が会社全体のメールボックス、ファイル、リソースに無制限にアクセスできてしまう可能性があります。

Microsoft Graph は OAuth トークンおよびアクセス許可とどのように連携しますか？

Microsoft Graph は Microsoft 365 の API ゲートウェイとして機能します。Graph へのすべての要求には、委任のアクセス許可またはアプリケーションのアクセス許可を定義する特定のスコープを含んだ OAuth アクセストークンを付与する必要があります。