Jira と Microsoft Entra ID（旧 Azure AD）を OAuth 2.0 で連携しようとすると、同意を付与したはずなのに AADSTS65001（The user or administrator has not consented…）が出続けて先に進めないことがあります。本記事では、authorize URL の点検からテナント設定、エンタープライズ アプリ側の同意まで、原因の切り分けと解決策を具体的に整理します。
発生している現象：Jira の OAuth 2.0 連携で AADSTS65001 が解消しない
Jira と OAuth 2.0 を使って連携（Entra ID 側に「jira oauth2.0」などのアプリ登録がある）しようとすると、次のようなエラーで止まるケースがあります。
- AADSTS65001
- The user or administrator has not consented to use the application …
いったん「ユーザー同意」や「管理者同意」を実施したつもりでも、認証フローを再実行すると同じエラーを繰り返すのが特徴です。
AADSTS65001（同意がない）の本質：何が不足しているのか
AADSTS65001 は、ざっくり言うと「このアプリが要求している権限（スコープ）に対して、同意（consent）が付与されていない」状態で発生します。ポイントは、“同意したつもり”と“実際に同意が成立している”の間にズレが起きやすいことです。
典型的なズレは次の 2 つです。
- 要求している API 権限（scope / resource）が、アプリ登録側の想定と一致していない（例：v2 エンドポイントなのに v1 相当の指定をしている、scope の書き方が誤っている、URL エンコード不備など）
- アプリ登録に「権限を追加」しただけで、テナント（サービス プリンシパル）側に同意が付与されていない（＝「許可を追加」≠「同意済み」）
このエラーは Jira 特有というより、Entra ID の同意モデル（ユーザー同意・管理者同意、サービス プリンシパルの作成と許可付与）に起因することがほとんどです。したがって、再現性の高い手順で「どこで同意が成立していないか」を潰すのが最短ルートになります。
最初に整理：アプリ登録とエンタープライズ アプリは別物
同意トラブルを早く解くために、まず用語をそろえます。Entra ID では、よく似た画面が出てきますが役割が違います。
| 要素 | 管理場所 | 役割 | ここがズレると起きがちなこと |
|---|---|---|---|
| アプリ登録（App registration） | Entra ID → アプリの登録 | アプリの「設計図」。client_id、リダイレクト URI、要求権限（API permissions）などを定義 | 「権限を追加したからOK」と思い込みやすい（同意は別） |
| エンタープライズ アプリ（Enterprise application） | Entra ID → エンタープライズ アプリケーション | テナント内に作られる「実体」（サービス プリンシパル）。誰が使えるか、同意が付与されたかがここに反映される | サービス プリンシパルが存在しない／同意が付いていないと AADSTS65001 が続く |
| 同意（Consent） | 主にエンタープライズ アプリ側で成立 | ユーザーまたは管理者が「このアプリにこの権限を許可する」と承認する行為 | 同意がブロックされていると永遠に同意できない |
結論として、「アプリ登録で権限を追加」しただけでは足りません。最終的には、テナントに存在するサービス プリンシパル（エンタープライズ アプリ）に対して、必要な権限の同意が付いている必要があります。
切り分けは「authorize URL の中身」から始める
AADSTS65001 は「同意がない」と言われる一方で、根本原因は“同意の対象が想定と違う”ことが少なくありません。そこで、最初にやるべきことは Jira が投げている 認可リクエスト（authorize URL）を正確に把握することです。
authorize URL を取得する方法（実務で確実なやり方）
- ブラウザのアドレスバーに表示される認可 URL をコピー（途中でリダイレクトされるので、可能なら最初の URL を控える）
- ブラウザの開発者ツール（Network）で authorize リクエストを確認
- 環境によっては Fiddler などでキャプチャ（Jira 側がサーバーからリダイレクトを生成する場合に有効）
見るべきパラメータ一覧（ここがズレると同意が成立しない）
| パラメータ | 意味 | よくある落とし穴 | チェック観点 |
|---|---|---|---|
| tenant / authority | どのテナントで認証・同意するか | common / organizations を使って別テナントで同意しようとしている | 想定の Tenant ID（GUID）やドメインになっているか |
| client_id | アプリ（アプリ登録）を識別 | 別のアプリの client_id を参照している（環境差し替え時に起きがち） | アプリ登録の「アプリケーション（クライアント）ID」と一致するか |
| redirect_uri | 認可コードやトークンの戻り先 | 末尾スラッシュ有無・URL エンコード不備・登録されていない URI | アプリ登録の Authentication に同一文字列で登録されているか |
| response_type | OAuth フロー種別 | code のはずが token になっている等（構成不整合） | Jira 側が想定するフローと合っているか |
| scope（v2） | 要求する権限（スコープ） | スペース区切り・URL エンコード・指定する API のスコープ名が誤り | Entra ID 側で定義済みのスコープ／Graph 権限と一致するか |
| resource（v1） | アクセス先リソース（v1 の指定方式） | v2 エンドポイントに resource を付ける／v1 に scope を付ける | エンドポイントと指定方式（v1/v2）が一致しているか |
| prompt | 同意画面を出すか等の制御 | prompt=consent を付けても、テナント設定で同意が禁止だと意味がない | テナントの同意設定（後述）と矛盾していないか |
v1 と v2 の混在は、同意トラブルの温床
Entra ID では OAuth のエンドポイントが大きく v1 と v2 に分かれます。ここが混ざると、同意したつもりでも別物として扱われたり、要求している権限が解釈されずに失敗したりします。
| 項目 | v1 | v2 | 実務の注意点 |
|---|---|---|---|
| 認可エンドポイント | /oauth2/authorize | /oauth2/v2.0/authorize | URL を見て「どっちを叩いているか」を最初に確定する |
| 権限指定 | resource | scope | 指定方式が違う。混ぜると意図した同意になりにくい |
| スコープ表現 | リソース単位 | スコープ（例：User.Read）単位 | v2 の scope は URL エンコードとスペース区切りが重要 |
Jira 側の設定画面に「Authorization URL」「Token URL」を入れるタイプの連携では、テンプレとして v1/v2 が混在している例もあるため、実際に送信されている URL が何かに立ち返るのが安全です。
テナントで「ユーザー同意」が許可されているか確認する
次に、テナント全体の同意ポリシーを確認します。ここが「禁止」だと、ユーザーが何度同意しようとしても成立せず、結果として AADSTS65001 が続くことがあります。
確認の考え方はシンプルで、以下のどれに該当するかを整理します。
| 状態 | ユーザーが同意できるか | 起きやすい挙動 | 対処の方向性 |
|---|---|---|---|
| ユーザー同意が広く許可 | 可能（権限の種類による） | prompt=consent で同意画面が出て進める | scope が正しいか、要求権限が過剰でないかを確認 |
| ユーザー同意が制限（推奨構成） | 一部のみ可能 | 権限によっては「管理者の承認が必要」になりやすい | 必要権限を最小化、または管理者同意を実施 |
| ユーザー同意が禁止 | 不可 | 同意したつもりでも成立しない／常に管理者同意が必要 | 管理者同意 URL の利用、またはポリシー見直し |
特に企業テナントでは「ユーザー同意は禁止」または「制限」が一般的です。Jira 連携が開発者個人の検証環境では動いたのに、本番テナントで急に AADSTS65001 になるのは、この差が原因になりがちです。
「管理者の承認が必要」になる代表例
API 権限には、ユーザーが自分で同意できるもの（Delegated permissions）と、管理者が同意しないといけないものが混在します。例えば次のようなケースでは管理者同意が必要になりやすいです。
- 組織内の広い情報にアクセスする権限（例：全ユーザー/全グループに関わる読み取り）
- アプリ単体で動く「アプリケーション権限（Application permissions）」を要求している
- セキュリティ上の理由で「ユーザーは同意不可」に分類されている権限を要求している
Jira 連携の要件を満たすために権限を盛りすぎると、管理者同意が必須になり、ユーザー同意の操作では永遠に解決しません。まずは 「何の API の何の権限を要求しているのか」を言語化しましょう。
「正しいテナント」に App ID が存在するか確認する
同意エラーで見落とされがちなのが「同意しようとしているテナントが違う」パターンです。次のような状況があると、同意の操作自体が別テナントに対して行われてしまいます。
- ブラウザに複数テナントのアカウントがサインイン済みで、意図しないディレクトリで同意している
- authority が common や organizations になっており、ユーザーが別テナントでログインしてしまう
- Jira 側に設定した Tenant ID が検証用のままになっている
確認手順（最短）
- アプリ登録（「jira oauth2.0」など）で アプリケーション（クライアント）ID を控える
- 同じテナントの エンタープライズ アプリケーションで、その ID（またはアプリ名）を検索する
- サービス プリンシパル（エンタープライズ アプリ）が存在するかを確認する
ここでエンタープライズ アプリが見つからない場合、よくある原因は次のいずれかです。
- そもそも同意が成立しておらず、サービス プリンシパルが作成されていない
- 別テナントで作業している（ディレクトリ切り替えミス）
- アプリがマルチテナント前提なのに、利用テナント側で初回同意が未実施
この状態では「同意を付けたつもり」でも、同意の付け先が存在しないため、AADSTS65001 を繰り返しやすくなります。
「権限を追加」＝「同意済み」ではない（ここが一番ハマる）
Entra ID のアプリ登録画面で「API のアクセス許可」を追加すると、一見「設定できた」ように見えます。しかし、それは“このアプリはこの権限を要求する設計です”という宣言に過ぎず、実際に組織として許可したことにはなりません。
同意が成立するまでの流れを、誤解が起きないように分解すると次のイメージです。
| 段階 | どこで行う | 何が起きる | 不足しているとどうなるか |
|---|---|---|---|
| 権限を追加（設計） | アプリ登録 → API のアクセス許可 | 要求する権限の一覧が構成される | 同意はまだ。実行時に AADSTS65001 になりうる |
| 同意（許可） | ユーザー同意 or 管理者同意 | テナント（サービス プリンシパル）に同意が記録される | 同意が無いと AADSTS65001 が続く |
| 割り当て（任意） | エンタープライズ アプリ → ユーザーとグループ | アプリ利用者を制限する（設定による） | 割り当て必須設定の場合、別エラーで止まることがある |
特に注意したいのが「同意」の段階です。管理者が “管理者の同意を付与” しないと進まない権限を要求しているのに、ユーザー同意だけで済ませようとしていると、同意したはずなのに失敗し続ける状態になりやすいです。
管理者同意 URL で組織全体に同意を付与して再試行する
権限がすでに構成済みで、「あとは同意を付けるだけ」なら、管理者同意 URL を使うのが早い場合があります。以下の形式です。
https://login.microsoftonline.com/<Tenant-ID>/adminconsent?client_id=<App-ID>これを 管理者権限のあるアカウントで開き、同意を完了させたうえで Jira 側の連携フローを再実行します。
管理者同意 URL を使う前に確認したいこと
- Tenant-ID が正しいか（別テナントで同意すると、期待する環境では解決しません）
- client_id が Jira 側で使っているものと同一か（環境差し替えでズレやすい）
- 要求権限が過剰でないか（必要以上の権限を要求すると審査・承認に時間がかかり、運用面でもリスク）
管理者同意は組織全体に影響します。テスト目的の一時的な権限追加・同意付与を本番テナントで行うと、後で棚卸しが困難になります。Jira 連携に必要な権限を最小限にし、同意の根拠（何のための権限か）を残しておくのがおすすめです。
監査ログ／サインインログで「同意できない理由」を特定する
同意トラブルを短時間で突破したいなら、Entra のログ確認が最も効きます。エラーメッセージだけだと「同意がない」としか見えませんが、ログには同意がブロックされた具体理由が出ることがあります。
| ログ種別 | 見る場所 | 見るポイント | 分かること |
|---|---|---|---|
| サインイン ログ（Sign-in logs） | Entra ID → 監視（Monitoring） | Status / Failure reason / Additional details | 実際にどのユーザーで、どのアプリに、どの失敗理由で落ちたか |
| 監査ログ（Audit logs） | Entra ID → 監視（Monitoring） | 失敗イベントの Status reason | 同意のブロック、ポリシー、条件付きアクセスなどの影響 |
特に監査ログの「Status reason」や、サインインログの「Additional details」は重要です。例えば、同意がポリシーで禁止されている、リスク判定でブロックされている、要求している権限が管理者同意必須、などの手掛かりが得られます。
現場で多い「同意したのに直らない」パターン集
ここからは、実際に AADSTS65001 が長引きやすいパターンを、原因と対処の形で整理します。上から順に潰すと、遠回りしにくくなります。
scope の書き方が原因（v2）
- 症状：同意画面に進めない、または進んだように見えても失敗が続く
- 原因：scope に含めた値が「存在しないスコープ名」または「意図した API ではない」
- 対処：scope を最小構成にして 1 つずつ増やす（例：まず openid / profile だけで疎通し、その後 API スコープを追加）
scope はスペース区切りが基本です。URL に入るときはエンコードされます（スペースが %20 になっているか等）。このエンコード崩れは、連携設定画面に貼り付けた URL を中間システムが再加工することで起きることがあります。
v1/v2 の取り違え（resource と scope の混在）
- 症状：同意が成立しない／想定の権限が付かない
- 原因：v2 エンドポイントなのに resource を指定、または v1 に scope を指定
- 対処：まず URL で v1/v2 を確定し、指定方式を合わせる
同意を付けたテナントが違う
- 症状：管理者同意までしたのに、別環境では解決しない
- 原因：ブラウザに複数アカウントが残っている、authority が common になっている、Tenant-ID の設定ミス
- 対処：Tenant-ID を明示した URL で実行、シークレットウィンドウでサインインし直す、サインインログでテナントを確認
「権限追加」だけで止まっている
- 症状：API permissions に権限が見えているのに AADSTS65001 が消えない
- 原因：同意（Grant）が付いていない／管理者同意が必要なのにユーザー同意で済ませている
- 対処：エンタープライズ アプリ側の同意状況を確認し、管理者同意 URL を利用
条件付きアクセスやリスク制御が絡む
- 症状：あるユーザーだけ失敗する／同じ手順でも日によって失敗する
- 原因：条件付きアクセス（CA）、ユーザー リスク、コンプライアンス要件でブロック
- 対処：サインインログの「条件付きアクセス」結果、監査ログの理由を確認してポリシー側を調整
手順で迷わないためのチェックリスト（Jira × Entra ID × AADSTS65001）
最後に、作業をやり直すときのためにチェックリストをまとめます。上から順に埋めていけば、原因がどこにあるかが明確になります。
| チェック | 確認方法 | OK の目安 | NG のときの対処 |
|---|---|---|---|
| 認可エンドポイントが v1/v2 どちらか確定 | authorize URL を目視 | /v2.0/authorize などが明確 | Jira 側の設定（Authorization URL/Token URL）を統一 |
| client_id が正しい | アプリ登録の Application (client) ID と照合 | 完全一致 | 環境差し替え・複数アプリ混在を解消 |
| redirect_uri が登録済み | アプリ登録 → Authentication | 同一文字列（末尾/大小文字も一致） | 登録追加、URL エンコードを見直す |
| scope/resource の指定が正しい | authorize URL のパラメータ確認 | v2 なら scope、v1 なら resource | 指定方式の修正、scope を最小化して増やす |
| ユーザー同意が許可されている | テナント設定を確認 | 必要な範囲で許可 or 管理者同意前提 | 管理者同意 URL を使用、ポリシー調整 |
| エンタープライズ アプリが存在する | Enterprise apps で App ID 検索 | サービス プリンシパルが見つかる | 正しいテナントで同意を実施（adminconsent など） |
| ログで失敗理由を確認 | サインインログ／監査ログ | 失敗理由が「同意未付与」以外も含めて把握できる | ポリシー・権限・テナント誤りを確定して修正 |
よくある質問
「prompt=consent」を付けても AADSTS65001 が消えません。なぜですか？
prompt=consent は「同意画面を出してほしい」という要求に過ぎず、テナント側でユーザー同意が禁止されていたり、要求している権限が管理者同意必須だったりすると、同意が成立しません。まずはテナントの同意設定と、要求している権限の種類（Delegated / Application）を確認してください。
アプリ登録で権限を追加し、「管理者の同意を付与」も押しました。それでも直りません。
この場合は「正しいテナントで作業しているか」「Jira が実際に投げている authorize URL がそのアプリを指しているか」を疑うのが近道です。特に、client_id の取り違え・別テナント同意・v1/v2 混在は、見た目では気づきにくいのに再現性高く発生します。サインインログで失敗したアプリ ID とテナントを確認すると一気に進みます。
Jira 側は触れず、Entra ID 側だけで直すことはできますか？
scope/resource の指定が誤っている場合は Jira 側（または中間の連携設定）を直さない限り解決しません。一方で「ユーザー同意が禁止」「管理者同意が未付与」「サービス プリンシパルが無い」といった問題は Entra ID 側の作業で改善できる可能性があります。まず authorize URL を確定し、Entra 側で何が足りないかを切り分けるのが安全です。
コメント