Microsoft Entra documentation update: Added deprecation banner は、Microsoft Entra IDそのものやSAML認証全体の終了ではありません。今回確認すべきポイントは、Microsoft Entra IDとJiraを連携する「JIRA SAML SSO by Microsoft」プラグインが非推奨になったことです。
2026年5月5日に更新されたMicrosoft Learnの該当ドキュメントでは、このプラグインが2026年5月1日に非推奨になったと明記され、今後のJIRA向けシングルサインオン設定では、サポートされるAtlassian側のSAML統合を使うか、Atlassian Cloudへ移行する方向が案内されています。既に本番環境で利用している管理者は、すぐに停止するかどうかだけでなく、SSO方式・利用中のJira基盤・代替プラグイン・Microsoft Entra側の設定を棚卸しする必要があります。(Microsoft Learn)
Microsoft Entraのドキュメント更新で何が変わったのか
今回の変更は、Microsoft Entra IDの新機能追加ではなく、Microsoft Learn上の「JIRA SAML SSO by Microsoft for Single sign-on with Microsoft Entra ID」構成手順に、非推奨を知らせる警告バナーが追加されたものです。
GitHubのPR「Added deprecation banner #1960」では、対象ファイルが docs/identity/saas-apps/jiramicrosoft-tutorial.md の1件で、ms.date が 05/05/2026 に更新され、本文冒頭に非推奨通知が追加されたことが確認できます。公開中のMicrosoft Learnページでも、最終更新日は2026年5月5日になっています。(GitHub)
| 確認項目 | 内容 |
|---|---|
| 対象ドキュメント | JIRA SAML SSO by Microsoft と Microsoft Entra ID のSSO構成手順 |
| 更新日 | 2026年5月5日 |
| 追加された内容 | 非推奨バナー |
| 非推奨日 | 2026年5月1日 |
| 主な案内 | 今後のJIRA SSO設定では、サポートされるAtlassian SAML統合またはAtlassian Cloudへの移行を検討 |
| 直接の対象 | JIRA SAML SSO by Microsoftプラグインを使っている環境 |
重要なのは、「Microsoft Entra IDでSAMLが使えなくなる」という意味ではない点です。Microsoft Entra IDは引き続きSAMLベースのエンタープライズアプリ連携を提供しています。今回の対象は、Microsoftが提供していたJira向けSSOプラグインと、その構成ドキュメントです。
誰が対応すべきか
対応が必要なのは、Microsoft Entra IDとJiraを「JIRA SAML SSO by Microsoft」で連携している組織です。特に、オンプレミスのJira Server、Jira Data Center、古いMicrosoft Azure Active Directory名義のJira SSOプラグインを運用している場合は、影響確認を優先してください。
| 利用状況 | 対応優先度 | 判断のポイント |
|---|---|---|
| 本番環境でJIRA SAML SSO by Microsoftを利用中 | 高 | 非推奨対象のため、代替方式の検証計画が必要 |
| 新規にJira SSOを構築予定 | 高 | このプラグイン前提で新規構築しない |
| Jira Serverを継続利用中 | 高 | Atlassian Server製品自体のサポート終了も考慮 |
| Jira Data CenterでMicrosoft製SSOプラグインを利用 | 中〜高 | Data Center対応の代替SAMLアプリを確認 |
| Atlassian Cloudで別方式のSSOを利用 | 低〜中 | 直接対象外の可能性が高いが、Entra側のエンタープライズアプリ名を確認 |
| Jiraを使っていない | 低 | Microsoft Entra ID全体の設定変更は基本的に不要 |
Atlassianは、Server製品について2024年2月15日以降はサポートとバグ修正を提供していないと説明しており、対象にはJira Software Server、Jira Core Server、Jira Service Management Server、Server向けMarketplaceアプリなどが含まれます。Jira Server上でこのSSOプラグインを使い続けている場合、Microsoft側のプラグイン非推奨とAtlassian Serverのサポート終了が重なるため、単なる設定変更ではなく基盤移行として扱うべきです。(アトラシアン)
影響範囲は「Entra ID」ではなく「Jira連携プラグイン」
今回のMicrosoft Entra documentation updateを読むときは、影響範囲を正しく切り分けることが大切です。
Microsoft Learnの該当ページは、Microsoft Entra IDと「JIRA SAML SSO by Microsoft」を統合し、Jiraへのアクセス制御、自動サインイン、アカウント管理を行う手順を説明しています。また、このプラグインはSAML 2.0を使ってフェデレーションするものと説明されています。(Microsoft Learn)
つまり、今回見直すべき対象は次のようになります。
| 領域 | 影響の見方 |
|---|---|
| Microsoft Entra IDのSAML機能 | SAML機能そのものが廃止されたわけではない |
| エンタープライズアプリ | 「JIRA SAML SSO by Microsoft」が登録されているか確認 |
| Jira側プラグイン | Microsoft製プラグインを使っている場合は代替検討が必要 |
| 条件付きアクセス | 既存ポリシーは残るが、代替アプリ切替時に対象アプリの見直しが必要 |
| ユーザー割り当て | 新しいエンタープライズアプリに移る場合、再割り当てやグループ設計が必要 |
| SAML証明書・メタデータ | 代替方式への移行時に再発行・再登録が必要になる可能性がある |
誤解しやすいのは、「非推奨バナーが追加されたから、今すぐJiraにログインできなくなる」と考えてしまうことです。非推奨は、一般に「今後の利用継続や新規利用を推奨しない」という意味で使われます。ただし、セキュリティ更新、互換性、サポート対応の観点では、非推奨になった時点で移行計画を始めるのが現実的です。
まず確認すべきMicrosoft Entra側の設定
管理者が最初に確認すべき場所は、Microsoft Entra管理センターのエンタープライズアプリです。対象アプリ名は「JIRA SAML SSO by Microsoft」です。
Microsoft Learnの手順では、Microsoft Entra管理センターにCloud Application Administratorなどの権限でサインインし、Enterprise appsからアプリを追加し、Single sign-onでSAMLを選択する流れが説明されています。SAML構成では、Identifier、Reply URL、Sign-on URLなどをJira側の値に合わせて設定します。(Microsoft Learn)
管理者向けチェックリスト
| 確認場所 | 見るべき項目 | 判断基準 |
|---|---|---|
| Enterprise applications | JIRA SAML SSO by Microsoftの有無 | 存在すれば影響確認対象 |
| Single sign-on | SAMLが有効か | SAML連携中なら代替方式の設計が必要 |
| Basic SAML Configuration | Identifier、Reply URL、Sign-on URL | 代替アプリ移行時に再設定が必要 |
| Attributes & Claims | Name ID、UPN、メール、ゲストユーザー条件 | JiraのユーザーIDと一致しているか確認 |
| Users and groups | 割り当て済みユーザー・グループ | 新アプリ移行時の再割り当て対象 |
| Conditional Access | 対象クラウドアプリ | 切替後にポリシー漏れが起きないか確認 |
| SAML Signing Certificate | 有効期限、メタデータURL | 移行テスト時に証明書更新も同時確認 |
特に注意したいのは、Name IDの扱いです。Microsoft Learnでは、Name ID属性を任意のユーザー属性にマッピングでき、例として user.userprincipalname が説明されています。また、外部ゲストユーザーではMembersとExternal Guestsで値を分ける手順も示されています。移行先のSAMLアプリでName IDの形式が変わると、Jira側で既存ユーザーと紐づかず、ログイン失敗や新規ユーザー作成の誤動作につながります。(Microsoft Learn)
Jira側で確認すべきポイント
Jira側では、どのプラグインが実際にSSOを処理しているかを確認します。Microsoft Learnの手順では、Jira管理者としてログインし、Add-onsからMicrosoft提供プラグインをアップロードし、Manage add-onsでConfigureを選ぶ流れが説明されています。設定画面では、Microsoft Entra ID側のApp Federation Metadata URLを貼り付け、Identifier、Reply URL、Sign-on URLをEntra側に反映する構成になっています。(Microsoft Learn)
確認時は、次の項目を記録しておくと移行がスムーズです。
| Jira側の項目 | 記録する内容 |
|---|---|
| プラグイン名 | Microsoft製のJIRA SAML SSOプラグインか |
| プラグインバージョン | 現在のバージョン、更新履歴 |
| Jira基盤 | Server、Data Center、Cloudのどれか |
| Jiraバージョン | 代替アプリが対応しているか |
| SAML設定 | Entity ID、ACS URL、ログインURL |
| ユーザー照合 | Jira usernameとEntra Name IDの対応 |
| JITプロビジョニング | 自動ユーザー作成を使っているか |
| 既定グループ | 新規作成ユーザーに付与するグループ |
| 強制ログイン | Entraログイン強制の有無 |
| 管理者ログイン経路 | SSO障害時にローカル管理者で入れるか |
「Force Azure Login」を有効にしている環境では、SSO障害時に管理者がログインできなくなるリスクがあります。Microsoft Learnでは、強制ログイン時に既定のログインフォームを表示するためのURLパラメーターも説明されています。移行テスト前に、必ずローカル管理者の緊急ログイン手順を確認してください。(Microsoft Learn)
新規構築ではこのプラグインを前提にしない
これからMicrosoft Entra IDとJiraのSSOを構築する場合、JIRA SAML SSO by Microsoftを前提にした新規設計は避けるべきです。
公開ドキュメントの警告では、JIRA向けSSOを継続して設定するには、サポートされるAtlassian SAML統合を使うか、Atlassian Cloudへ移行する案内が出ています。非推奨になったプラグインで新規環境を作ると、構築直後から移行課題を抱えることになります。(Microsoft Learn)
現実的な選択肢は、次の3つです。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| Atlassian Cloudへ移行 | Jira Serverの老朽化、クラウド運用へ移行したい組織 | データ移行、権限、アプリ互換性の検証が必要 |
| Jira Data Centerで対応SAMLアプリを利用 | オンプレミスまたは自社管理基盤を継続したい組織 | Marketplaceアプリの対応バージョン、サポート範囲、費用を確認 |
| 既存構成を一時維持し、段階移行 | すぐに切替できない本番環境 | 非推奨リスクを受け入れたうえで期限付きの暫定運用にする |
「まだ動いているからそのままでよい」と判断するのは危険です。SSOは障害時の影響が大きく、認証できなければJiraの課題管理、開発ワークフロー、ITSM運用が止まる可能性があります。非推奨の通知が出た時点で、代替方式の検証環境を作るところまで進めるのが安全です。
移行時に見るべき設定確認の観点
移行は、単に「新しいSAMLアプリを入れる」だけでは終わりません。Microsoft Entra IDとJiraの双方で、同じユーザーを同じIDとして認識できるかを確認する必要があります。
移行手順の全体像
| 手順 | 作業内容 | 成功条件 |
| -: | ————————– | ——————————————— |
| 1 | 現在のJira基盤とSSO方式を棚卸しする | 対象環境、対象ユーザー、対象アプリが明確になる |
| 2 | 代替方式を決める | Atlassian Cloud、Data Center向けSAMLアプリなどの方針が決まる |
| 3 | 検証環境を用意する | 本番Jiraではなく開発・ステージング環境でテストできる |
| 4 | Entra側に新しいエンタープライズアプリを構成する | SAMLメタデータ、証明書、属性が設定できる |
| 5 | Jira側に新しいSAML設定を構成する | EntraからのSAML応答を受け取れる |
| 6 | ユーザー照合をテストする | 既存Jiraユーザーに正しくログインできる |
| 7 | 条件付きアクセスと割り当てを確認する | 対象ユーザーにだけアクセス権がある |
| 8 | パイロットユーザーで検証する | 管理者、一般ユーザー、外部ユーザーのログインが確認できる |
| 9 | 本番切替とロールバック手順を準備する | 失敗時に旧方式または管理者ログインへ戻せる |
| 10 | 旧アプリを整理する | 利用停止後に不要な証明書、割り当て、条件付きアクセス対象を削除する |
Microsoft Learnでも、本番環境ではなく開発環境やステージング環境で統合をテストしてから本番利用することが推奨されています。SSO移行では、ログイン失敗が即業務停止につながるため、この原則は特に重要です。(Microsoft Learn)
失敗しやすいポイント
非推奨対象を取り違える
今回の対象は、Jira向けのMicrosoft製SSOプラグインです。Microsoft Entra IDのエンタープライズアプリ機能やSAML連携全体が廃止されるわけではありません。社内通知では、「Jira連携プラグインの非推奨」と明記し、Entra ID全体の障害や廃止と誤解されないようにしましょう。
Name IDの変更で既存ユーザーと紐づかない
Jira側のユーザー名がメールアドレスなのか、UPNなのか、別のログインIDなのかを確認せずに移行すると、SAML認証は成功してもJiraユーザーに一致しないことがあります。特に、ゲストユーザーやメール変更済みユーザーがいる環境では、パイロットテストで必ず確認してください。
条件付きアクセスの対象漏れ
新しいSAMLアプリを作ると、Microsoft Entra ID上では別のエンタープライズアプリとして扱われることがあります。旧アプリにだけ条件付きアクセスを適用していると、移行後のアプリがポリシー対象外になる可能性があります。MFA、準拠デバイス、場所ベース制御、セッション制御を使っている場合は、切替前に対象アプリを見直してください。
証明書とメタデータを軽視する
SAML証明書の有効期限、フェデレーションメタデータURL、Jira側に取り込まれた証明書情報は、移行時の典型的なつまずきポイントです。新旧アプリを並行検証する場合は、どの証明書をどのJira環境に登録したかを台帳化しておくと、切り戻し時の混乱を避けられます。
管理者のロックアウト対策を忘れる
SSOを強制している環境では、SAML設定の誤りによって全員がログインできなくなることがあります。移行作業の前に、ローカル管理者アカウント、緊急ログインURL、メンテナンス時間帯、切り戻し担当者を決めておきましょう。
社内で共有するなら、こう伝える
管理者や開発チームに共有する場合は、次のように整理すると誤解が少なくなります。
| 伝える相手 | 伝える内容 |
|---|---|
| 情シス・ID管理担当 | JIRA SAML SSO by Microsoftが非推奨になったため、Entra側アプリとSAML設定を棚卸しする |
| Jira管理者 | Jira側でMicrosoft製プラグインを使っているか、代替SAMLアプリが必要か確認する |
| セキュリティ担当 | 条件付きアクセス、MFA、証明書、ログ監査への影響を確認する |
| 開発・業務部門 | すぐにJiraが止まる通知ではないが、SSO移行テストに協力が必要になる可能性がある |
| 経営・管理部門 | Jira Server継続利用の場合は、認証だけでなく基盤移行のリスクとして扱う |
社内アナウンスで避けたいのは、「Microsoft EntraがJira連携を終了」といった大きすぎる表現です。正しくは、「Microsoft Entra IDとJiraを連携するMicrosoft製プラグインが非推奨になったため、利用有無を確認し、必要に応じてAtlassian側の対応SAML統合やCloud移行を検討する」です。
今回の更新から取るべき次の行動
Microsoft Entra documentation update: Added deprecation banner は、小さなドキュメント変更に見えますが、Jiraを認証基盤に組み込んでいる組織にとっては見逃せないサインです。
まず、Microsoft Entra管理センターで「JIRA SAML SSO by Microsoft」が登録されているかを確認してください。次に、Jira側でMicrosoft製プラグインを使っているか、Jira ServerなのかData Centerなのか、Atlassian Cloudへ移行済みなのかを切り分けます。
利用中であれば、次の順で進めるのが現実的です。
- 現行のEntraアプリ、Jiraプラグイン、SAML属性、証明書を棚卸しする
- 新規構築ではJIRA SAML SSO by Microsoftを使わない
- Atlassian CloudまたはサポートされるAtlassian SAML統合を候補にする
- 開発・ステージング環境でName ID、ゲストユーザー、条件付きアクセスを検証する
- 本番切替前に管理者ログインと切り戻し手順を準備する
今回の変更は、単なる警告バナーの追加ではなく、「Jira SSOの運用を古い前提のまま続けていないか」を確認するタイミングです。特にJira Serverや古いSSOプラグインを使っている環境では、認証設定だけでなく、Jira基盤そのものの移行計画と合わせて見直すことが重要です。
コメント