Microsoft Graph Explorerで /me/messages を実行すると403 Forbiddenになるのに、/me などは成功する――この差は「メール用の権限」と「同意（管理者同意）」にあります。本記事では原因の切り分けから、最短で直す手順、管理者に依頼する方法までをまとめます。
現象：Microsoft Graph Explorerで /me/messages が 403 Forbidden になる
Graph Explorer（https://developer.microsoft.com/graph/graph-explorer）で次のようなリクエストを実行した際、レスポンスが 403 Forbidden となり、権限不足を示すメッセージが返ることがあります。
GET https://graph.microsoft.com/v1.0/me/messagesGraph Explorer上では、次のような文言（または同等の内容）が表示されます。
Forbidden - 403
Either the signed-in user does not have sufficient privileges, or you need to consent to one of the permissions on the Modify permissions tab実際のレスポンスはJSONで、概ね次のようなエラー構造になっています（値は例）。
{
"error": {
"code": "ErrorAccessDenied",
"message": "Access is denied. Check credentials and try again.",
"innerError": {
"date": "2025-01-01T00:00:00",
"request-id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"client-request-id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}
}
}同じサインイン状態のまま GET /me など一部のAPIは成功することが多いため、「このエンドポイントだけ失敗する原因が分からない」状態に陥りがちです。
結論：/me/messages はメール権限（Mail.Read など）と同意が必須
/me/messages は「サインイン中ユーザーのメールボックス（Outlook/Exchange）」にアクセスするAPIです。メール本文や添付ファイル、送受信履歴は機密情報そのものなので、Microsoft Graphでは次の2つが揃っていないと呼び出せません。
- 必要なMicrosoft Graph権限（例：Mail.Read / Mail.ReadWrite） がアクセストークンに含まれている
- その権限に対して、テナントのポリシーに沿った 同意（ユーザー同意または管理者同意） が行われている
逆に言うと、Graph Explorer自体が悪いわけではなく、「トークンにメール権限が入っていない」または「入れようとしても同意できない」 ことが原因です。
最短で解決するための全体フロー
「いま手元で早く直したい」方向けに、まずはこの流れで進めるのが最短です。
| 手順 | やること | 目的 | 詰まりやすいポイント |
|---|---|---|---|
| 手順A | Graph Explorerの Modify permissions で Mail.Read を追加し、同意を完了 | メール権限をトークンに載せる | チェックしただけで同意していない |
| 手順B | サインアウト→サインインでトークンを取り直して再実行 | 古いトークンを更新する | 同意済みでもトークンが更新されない |
| 手順C | 同意できない場合は管理者に 管理者同意 を依頼 | テナントポリシーの壁を超える | 「どのアプリに何を付けるか」が曖昧 |
| 手順D | それでもNGなら、トークンの scp、メールボックス有無、ゲストユーザー等を確認 | 権限以外の原因を切り分け | Exchangeライセンス未付与、条件付きアクセスなど |
なぜ /me などは動くのに /me/messages だけ失敗するのか
Graph APIは、エンドポイントごとに要求される権限が異なります。たとえば /me は多くの環境で最小権限の User.Read（サインインユーザーの基本プロフィール取得）で動きます。これは多くのテナントで「ユーザーが自分で同意できる」または「既に同意済み」になっていることが多い権限です。
一方、/me/messages はメールというセンシティブなデータを扱うため、明示的にメール系の権限を追加して同意しない限り、サーバー側でブロックされます。Graph Explorerで「他のAPIは通るのに、メールだけ403」という現象は、まさにこの権限モデルの差で説明できます。
/me/messages に必要な権限を整理する
まずは「何をしたいか」で必要な権限が変わります。代表的なパターンを表にまとめます（Graph Explorerは通常、委任された権限＝Delegatedを使います）。
| やりたいこと | 代表的なエンドポイント例 | 必要になりやすい権限（Delegated） | 補足 |
|---|---|---|---|
| 自分のメールを一覧取得 | GET /me/messages | Mail.Read（最小） | 読み取りだけなら Mail.Read を優先 |
| 自分のメールを更新・移動・削除 | PATCH /me/messages/{id} など | Mail.ReadWrite | 必要な操作がある場合のみ |
| 送信する | POST /me/sendMail | Mail.Send | 送信専用。読み取りとは別権限 |
| 共有メールボックス/他人のメールを読む | GET /users/{id}/messages | Mail.Read.Shared など | 別途「共有」アクセスが前提。自分の /me ではない |
今回の /me/messages であれば、まずは Mail.Read が付いているかどうかを疑うのが最短です。
Microsoft Graphの権限タイプ：Delegated と Application
403の原因を正確に理解するには、権限の「種類」を把握しておくと一気に整理が進みます。Graph Explorerは基本的に Delegated（委任された権限） で、ユーザーとして操作する形です。
| 観点 | Delegated（委任された権限） | Application（アプリケーション権限） |
|---|---|---|
| 誰として動く？ | サインインユーザー | アプリ（バックグラウンド） |
| トークン内の権限の見え方 | scp クレームにスコープが入る | roles クレームにロールが入る |
| よくある用途 | ユーザー操作の自動化、画面付きアプリ | 夜間バッチ、監査、テナント全体処理 |
| 権限付与のハードル | ユーザー同意で済むケースもある（テナント設定次第） | 基本的に管理者同意が必要 |
Graph Explorerで試しているのに「Application権限のつもりで設計していた」などのズレがあると、必要な権限の考え方が噛み合わずに迷子になります。まずは Graph ExplorerはDelegated という前提で考えると切り分けが速いです。
最短で直す：Graph Explorerで Mail.Read を追加して同意する
最初に試すべき手順は、Graph Explorer側で権限を追加し、同意を完了させることです。テナントの設定によってはユーザー自身で同意できる場合もあります。
- Microsoft Graph Explorerにサインインする
- 右側（または上部）にある Modify permissions（権限の変更）を開く
- 検索ボックスで
Mail.Readを探してチェックを入れる - Consent（同意）または同意に相当するボタンを押して、表示される同意画面を完了する
- 再度
GET /me/messagesを実行する
ここで重要なのは「チェックしただけ」ではダメで、同意（Consent）が完了しているかです。Graph Explorerの権限一覧には、Consented / Admin consented のような状態表示が出ることがあります。実行前に必ず確認してください。
また、同意を済ませたはずなのに変化がない場合は、次も試すと改善することがあります。
- Graph Explorerから一度サインアウトして、サインインし直す（トークンを取り直す）
- ブラウザの別プロファイルやシークレットウィンドウで再試行する（キャッシュの影響を切る）
- 同じアカウントでMicrosoft 365（Outlook on the web）にログインできるか確認する（メールボックスが存在するかの確認）
管理者ができること：管理者同意が必要な環境での解決手順
組織によっては「ユーザー自身がアプリに同意できない」ようにポリシーで縛っているケースがあります。この場合、ユーザーがGraph Explorerで Mail.Read にチェックを入れても、同意が完了せず403のままになります。ここからは管理者側の対応です。
管理者がGraph Explorerで「組織として同意」する
管理者権限を持つアカウントでGraph Explorerにサインインできるなら、Graph Explorer上の同意画面で「組織として同意（on behalf of your organization）」にチェックを入れて承認する方法が最短です。画面の文言は環境や更新で多少変わりますが、狙いは テナント全体でMail.Readを許可する ことです。
Microsoft Entra 管理センターで同意状況を確認・付与する
Graph ExplorerはMicrosoftが提供するマルチテナントアプリとして動作します。管理センター側では、一般的に次のどちらか（または両方）で確認します。
- Enterprise applications（エンタープライズ アプリケーション）：テナントに存在するサービスプリンシパル（外部アプリ含む）の管理
- App registrations（アプリの登録）：自分で登録したアプリの管理（自作アプリの権限付与で主に利用）
Graph Explorerの権限付与を目的にするなら、まずは Enterprise applications 側で「Graph Explorer（またはMicrosoft Graph Explorer）」を検索し、権限（Permissions）の画面で Grant admin consent を実行する流れが分かりやすいです。自作アプリの場合は、App registrationsで対象アプリを開き、API permissionsから必要な権限を追加して管理者同意を与えます。
管理者向けの作業を、実務で迷いにくい形に落とすと次の流れです。
- Microsoft Entra 管理センターに管理者でサインインする
- Graph Explorerで使っているアプリ（Graph Explorer自体、または自作アプリ）を特定する
- API permissions（アクセス許可）で
Mail.Read（必要に応じてMail.ReadWrite等）を追加する - Grant admin consent を実行して、権限に「管理者同意済み」の状態を付ける
- 対象ユーザーがGraph Explorerで再サインインし、再度
GET /me/messagesを実行する
「同意は付けたはずなのにユーザー側でまだ403」という場合は、ユーザーが古いトークンを持っていることが多いので、必ずサインアウト→サインイン をセットで案内すると解決が早いです。
管理者ではない場合：依頼するときに伝えるべきポイント
管理者同意が必要な環境では、ユーザー単独では解決できません。依頼するときは「何のアプリに、どの権限を、何の目的で」付けたいのかが揃っていると、管理者側の判断と作業が一気に速くなります。
| 管理者に伝える項目 | 具体例 | 理由 |
|---|---|---|
| 対象アプリ | Microsoft Graph Explorer（または自作アプリ名） | どのサービスプリンシパルに同意を付けるかを特定するため |
| 使いたいAPI | GET /me/messages | 必要権限の妥当性確認のため |
| 必要な権限 | Mail.Read（読み取りのみ） | 最小権限で許可できるようにするため |
| 利用目的 | メール一覧を取得して件名・受信日時を確認したい | 監査・セキュリティ上の承認判断の材料になる |
そのまま送れる依頼文テンプレートも置いておきます。環境に合わせてアプリ名や目的だけ差し替えてください。
件名：Microsoft Graph Explorerでメール取得API（/me/messages）を利用するための管理者同意のお願い
管理者各位
Microsoft Graph Explorer で以下のMicrosoft Graph APIをテストしたいのですが、403 Forbidden となり実行できません。
テナントの同意ポリシーによりユーザー同意ができない可能性があるため、管理者同意の付与をお願いできますでしょうか。
■対象アプリ：
Microsoft Graph Explorer（Graph Explorer）
■利用したいAPI：
GET https://graph.microsoft.com/v1.0/me/messages
■必要な権限（Delegated）：
Mail.Read（読み取りのみ）
■目的：
自分のメールボックスのメッセージ一覧（件名・送受信日時など）を取得して動作確認したい
以上、よろしくお願いいたします。それでも403が出る場合の追加チェック
Mail.Read を付けて同意したのに403が続く場合、原因は「権限」以外にあることがあります。現場で遭遇しやすい順に、切り分けポイントを表にしました。
| よくある原因 | 確認ポイント | 対処の方向性 |
|---|---|---|
| トークンにMail.Readが入っていない | Graph Explorerでアクセストークンを表示し、scp に Mail.Read があるか | 権限のチェックだけでなく、同意完了→再サインインでトークン更新 |
| ユーザー同意が禁止（同意ポリシー） | 同意画面が出ない／同意できない、または「管理者に連絡」と出る | 管理者同意（Enterprise applications / App registrations）で許可 |
| アカウントにメールボックスがない | Outlook on the webにサインインできない、Exchange Onlineライセンス未付与など | ライセンス付与、メールボックス作成（反映まで時間差が出る場合あり） |
| ゲストユーザー（B2B）でサインインしている | ユーザー種別がGuestで、テナント内にメールボックスが存在しない | メールボックスを持つメンバーアカウントで実行する |
| 条件付きアクセスやセキュリティ設定でブロック | 特定アプリの利用制限、準拠デバイス必須などの条件がある | Graph Explorerが条件を満たすよう例外・ポリシー調整（管理者対応） |
特に見落としやすいのが「チェックは付けたが同意していない」「同意したがトークンが古い」パターンです。Graph Explorerは操作が簡単な反面、権限とトークンの状態が追いにくいので、次のセクションの方法で トークンの中身を見て確認 すると迷いが減ります。
アクセストークンで確認する：scp（スコープ）を読む
Graph Explorerでは、実行に使っているアクセストークン（JWT）を表示できます。そこに含まれる権限を確認すると、「権限を付けたつもり」問題を即座に潰せます。
- Delegated権限の場合：JWTの
scpクレームにスコープがスペース区切りで入る - Application権限の場合：JWTの
rolesクレームにロールが入る
Delegatedで /me/messages を叩くなら、概ね次のように scp に Mail.Read が含まれている状態が目安です（例示のため一部省略しています）。
{
"aud": "https://graph.microsoft.com",
"iss": "https://login.microsoftonline.com/{tenant-id}/v2.0",
"scp": "User.Read Mail.Read",
"upn": "[email protected]"
}scp に Mail.Read が無いのに /me/messages を実行すると、Graph側は正しく拒否します。403を見たら、まずは 「本当にスコープが入っているか」 を機械的に確認するのが最速です。
Graph Explorerでの実務的なコツ
Graph Explorerは学習・検証に非常に便利ですが、組織環境だと権限まわりで詰まりやすいのも事実です。実務でハマりにくくするコツをまとめます。
- 最小権限から試す：まずは
Mail.Read。できる限りMail.ReadWriteをいきなり付けない - 目的の粒度を落とす：最初は
GET /me/messages?$top=5など少量で動作確認する - フィルターを使って負荷を下げる：
$select=subject,receivedDateTime,fromなどで必要項目だけ取得する - 失敗時はエラーコードを見る：Graph Explorerの表示だけでなく、返ってきたJSONの
error.codeを確認する - 問い合わせ用の情報を控える：
request-idとclient-request-idは管理者・サポートへの連携で役立つ
たとえば、最初の確認用リクエストは次のように「小さく・軽く」すると、結果が見やすく、管理者への説明もしやすくなります。
GET https://graph.microsoft.com/v1.0/me/messages?$top=5&$select=subject,receivedDateTime,fromよくある質問
Mail.Readを付けると、管理者は私のメールを読めるようになりますか？
Delegated権限の Mail.Read は「サインインユーザーとして読む」ための権限です。管理者が付与したからといって、管理者が自動的にあなたのメールを読めるわけではありません。ただし、組織の運用や監査の仕組み（別の権限や機能）でアクセス可能なケースはあり得るため、組織ポリシーに従って利用してください。
Graph ExplorerでMail.Readにチェックを入れたのに、同意ボタンが押せません
多くの場合、テナントでユーザー同意が制限されています。この場合は管理者に「Graph Explorer（または対象アプリ）へMail.Readの管理者同意を付与」してもらう必要があります。本記事の依頼テンプレートを使うとスムーズです。
/me/messages ではなく /users/{id}/messages を叩きたいです
委任された権限で他人のメールボックスにアクセスするには、通常「共有メールボックスとしてのアクセス許可」と、Graph側の共有メール権限（例：Mail.Read.Shared）が必要です。単に Mail.Read を付けただけでは、他ユーザーのメールを読めません。
403ではなく404になることがあります
URLやAPIバージョン、パスの誤り、またはメールボックスが存在しないなど、状況により404が返ることがあります。まずは GET /me が成功すること、次に Mail.Read を同意できていることを順番に確認すると切り分けが安定します。
本番アプリではどう設計すれば安全ですか？
本番では、最小権限の原則に従い、必要最小限のスコープだけを要求し、同意画面に表示される説明文（アプリ名・目的）を明確にしておくのが重要です。また、403が返った場合に「管理者同意が必要かもしれない」ことをユーザーに案内できるよう、エラー処理と運用手順をセットで用意しておくと、問い合わせ対応のコストが大きく下がります。
まとめ：/me/messages の403は「Mail.Readの付与と同意」でほぼ解決できる
/me/messagesはメールボックスへアクセスするため、Mail.Readなどメール系権限が必須- Graph Explorerでは Modify permissionsで権限を追加し、同意まで完了させる
- テナント設定でユーザー同意が禁止されている場合は、管理者同意 が必要
- 権限を付けたのに403なら、トークンのscp確認、メールボックス有無、ゲストユーザー、条件付きアクセスも疑う
コメント