Microsoft Entra のアプリ ギャラリーで、SSO（シングル サインオン）および SCIM（プロビジョニング）に関する新規登録が一時停止されています。本記事では、再開見通し、既存 SSO アプリに対する SCIM 追加の考え方、そして当面の代替手段（非ギャラリー提供）まで、実装者・事業責任者の双方がすぐ動けるレベルで整理します。
目次
Microsoft Entra アプリ ギャラリーの新規登録一時停止とは
現在、Microsoft Entra の「アプリ ギャラリー」に対する 新規の SSO／SCIM アプリの掲載申請は受け付けられていません。背景には、プラットフォーム全体の耐性・既定セキュリティ基準を底上げする取り組み（セキュア・フューチャー・イニシアチブ：Secure Future Initiative）があり、公開フローの品質・審査をより厳格化する方向へと舵が切られています。
ここで重要なのは、ギャラリーへの「新規掲載」だけが停止であり、すべての Entra 連携が止まっているわけではないという点です。企業は引き続き、非ギャラリー（カスタム）エンタープライズ アプリとして SSO/SCIM を設定し、自社のテナント内で運用できます。
対象・非対象の整理
| 項目 | 現在の扱い | 補足 |
|---|---|---|
| ギャラリーへの新規 SSO アプリ掲載 | 一時停止 | 新規ブランド・新規エントリは申請不可 |
| ギャラリーへの新規 SCIM アプリ掲載 | 一時停止 | SCIM プロビジョニングを伴う新規エントリは不可 |
| 既存ギャラリー SSO アプリへの SCIM 追加 | 個別審査 | 要件適合性・安全性を中心に厳格なレビュー |
| 非ギャラリー（カスタム）としての利用 | 可能 | 各顧客テナントごとに手動で設定 |
ポイント：停止は「ギャラリー申請」という配布経路に対する制限。企業内利用・PoC・限定提供は、非ギャラリー手法で継続可能です。
登録再開はいつ？ 現実的な見通しと計画の立て方
公式な再開時期は明示されていませんが、業界では少なくとも 6 か月程度の長期化を見込んだ計画立案が現実的と受け止められています。運用・開発の観点では、以下の 3 つのシナリオで準備を進めるのが妥当です。
| シナリオ | 再開目安 | 推奨アクション |
|---|---|---|
| 早期再開 | 〜3 か月 | 非ギャラリーでの導入を進めつつ、提出物（マニフェスト、セキュリティ白書、SCIM スキーマ）を即時提出できる状態に。 |
| 標準再開 | 3〜6 か月 | 導入ガイドの多言語化、監視・アラートの整備、サポート Q&A のテンプレ整備。デザインパートナーでの運用実績を蓄積。 |
| 長期化 | 6 か月〜 | 非ギャラリー前提の商用運用（SLA/レート制御/サポートフロー）に切り替え。ギャラリー再開後は移行ガイダンスを提示。 |
いずれのシナリオでも、「今できる準備」を前倒しで完了させることが、再開後の掲載・拡販スピードを大きく左右します。
既存ギャラリー SSO アプリに SCIM を追加するには（“個別審査”の通し方）
既存のギャラリー掲載アプリに対して SCIM 機能を後付けする場合、個別審査（ケースバイケース）となります。ここでは、審査観点を踏まえた提出物・実装要件の要点を整理します。
提出が求められやすいドキュメント
- SCIM スキーマ定義（RFC 7643/7644 ベース、User/Group 拡張属性を含む）
- プロビジョニング動作仕様（Create/Update/Deactivate/Group Membership の整合性）
- セキュリティ設計（認可方式、トークン保護、監査ログ、PII 取り扱い）
- レートリミットとスロットリング方針（429/503 時のリトライ戦略、Exponential Backoff）
- 可観測性とサポート（メトリクス、トレーシング、アラート、連絡先、SLA）
実装で外さない 10 の要点
- Idempotency：PUT/PATCH の冪等性、重複リクエストへの安全性。
- ETag / If-Match：競合（409/412）の正しい扱い。
- フィルタとページング：
filter=userName eq "..."、startIndex/countの上限・既定値。 - 部分更新：PATCH の
add/replace/removeを完全実装。 - グループ階層：大規模グループ（数十万メンバー）での遅延・分割処理。
- 非アクティブ化：削除と停止（soft delete / suspend）の設計、再有効化の整合性。
- ユニーク制約：
userName重複時のエラー整形。 - 属性マッピング：NameID・mail/UPN・外部ID の対応方針を明確化。
- スキーマ拡張：
urn:ietf:params:scim:schemas:extension:enterprise:2.0:Userなど拡張属性の扱い。 - 監査と可視化：テナント・対象・操作・結果・相関 ID をログ化し、サポートが追跡可能に。
提出用サンプル：SCIM User
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],
"userName": "[email protected]",
"name": {"givenName": "Taro", "familyName": "Yamada"},
"active": true,
"emails": [{"value": "[email protected]", "primary": true}],
"externalId": "ext-12345",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
"employeeNumber": "E0001",
"department": "Sales"
}
}審査に向けたセルフチェック
| 観点 | 判定 | 証跡/メモ |
|---|---|---|
| 429/503 発生時に指数バックオフで自動再試行する | Yes/No | 最大待機/総試行回数/ジャitter の設定 |
| PATCH の全操作（add/replace/remove）をサポート | Yes/No | 配列属性のマージ/置換の方針 |
| グループ 10 万人規模でもタイムアウトしない | Yes/No | 分割・非同期バッチ・最終整合の説明 |
| GDPR/個人情報の保護要件を満たす | Yes/No | データ保持/削除/マスキングの規程 |
代替手段：非ギャラリー（カスタム）エンタープライズ アプリでの提供
ギャラリー掲載が止まっている間でも、顧客は Azure ポータルから 「非ギャラリー エンタープライズ アプリ」を作成し、SSO と SCIM を構成できます。ベンダー側は、顧客が迷わないように手順書と設定値を明確に提示しましょう。
SSO（SAML/OIDC）のガイド例
| 項目 | SAML | OIDC |
|---|---|---|
| 識別子 | Entity ID（例：https://idp.example.com/saml） | Client ID（アプリ登録で取得） |
| 応答先/リダイレクト URI | ACS URL（例：https://app.example.com/sso/acs） | Redirect URI（例：https://app.example.com/callback） |
| 要求するクレーム/スコープ | NameID=email、given_name、family_name | openid、profile、email |
| 署名/暗号化 | アサーション署名（推奨：SHA-256）、証明書ロールオーバー対応 | JWKs ローテーションと kid 管理、nonce 検証 |
| 多要素・条件付きアクセス | 顧客側ポリシーで強化。必要なエラー UI とリトライ UX を設計。 | |
SCIM（プロビジョニング）のガイド例
- Base URL：
https://scim.example.com/scim/v2/ - 認証方式：Bearer Token（テナント単位に発行／失効）
- サポート API：/Users、/Groups、/Schemas、/ServiceProviderConfig
- レート制限：例）
100 req/min/tenant、バースト時は 429 - ログ：correlationId で一連操作を追跡可能に
ギャラリー vs 非ギャラリー：メリット/デメリット
| ギャラリー | 非ギャラリー（カスタム） | |
|---|---|---|
| 検索・発見性 | 高い（キーワードで発見） | 低い（手順書配布が鍵） |
| 自動設定テンプレ | あり（ボタン数回で構成） | なし（顧客が手動設定） |
| レート・監視 | 一定の既定・保護あり | ベンダー実装に依存 |
| カスタマイズ性 | 標準化重視 | 柔軟（顧客別チューニング可） |
| 導入スピード | 再開までは不可 | 即日〜（顧客側で実施可能） |
当面の運用戦略：「今できる準備」完全ガイド
提出物セット（再開後すぐ申請できる状態に）
- アプリ マニフェスト：SSO/SCIM の要件、サポート範囲、制限事項を 1 枚で俯瞰。
- SCIM スキーマとマッピング表：顧客側属性（mail、userPrincipalName、employeeId など）との対応表。
- セキュリティ白書：データフロー図、暗号化、鍵管理、脆弱性管理、第三者アセスメント。
- 稼働実績：非ギャラリーでの導入社数、成功率、平均所要時間、主要事例。
- 運用手順：障害時の連絡経路、復旧目標（RTO/RPO）、ロールバック手順。
非ギャラリー導入手順書（日本語/英語）に含めるべき章立て
- 前提条件（テナント要件、必要なロール、ライセンス）
- SSO 設定値一覧（SAML/OIDC）とスクリーンショット
- SCIM エンドポイント・トークン発行手順・回収手順
- 属性マッピング例（ユーザー／グループ）
- テスト計画（サンプルユーザー、期待結果、ロールバック手順）
- トラブルシューティング（代表エラーと対処表）
- 問い合わせ窓口とサービスレベル
代表エラーと対処表
| 症状 | 原因候補 | 一次切り分け | 推奨対処 |
|---|---|---|---|
| SSO 直後に 401/403 | クレーム不足、aud 不一致、無効トークン | JWT デコード、aud/iss/nbf/exp を確認 | 必要スコープ追加、クレーム発行規則を修正 |
| SCIM 429 が頻発 | バースト投入、テナント並列過多 | 時系列での投入数と 429 閾値を確認 | 指数バックオフ＋ジャitter、キュー制御 |
| グループ同期の欠落 | 大規模配列の PATCH 処理ミス | 差分の適用ログと correlationId を追跡 | 分割適用・最終整合チェックを追加 |
| ユーザー再有効化で属性欠落 | Deactivate/Reactivate の実装差 | 以前の snapshot と比較 | 停止時の保持属性と再適用フローを見直し |
SCIM 実装のベストプラクティス（実コード例つき）
指数バックオフ（擬似コード）
// 429/503 時のリトライ（最大 6 回）
for (int i = 0; i <= 6; i++) {
Response r = callScim();
if (r.status < 500 && r.status != 429) break;
long delay = (long)Math.pow(2, i) * 1000 + jitter(0, 500);
Thread.sleep(delay);
}PATCH の完全サポート例
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{"op": "replace", "path": "name.givenName", "value": "Hanako"},
{"op": "add", "path": "emails", "value": [{"value":"[email protected]","primary":true}]},
{"op": "remove", "path": "urn:...:enterprise:2.0:User.department"}
]
}監視メトリクスの最低ライン
- 成功率（ユーザー単位/グループ単位）
- 平均レイテンシ／P95／P99
- バースト時のキュー長・滞留時間
- 属性マッピング失敗率（属性ごと）
- 429/5xx の発生回数と原因内訳
- API 利用テナント数・同時並列数
法務・セキュリティ観点で押さえるべき点
- データ最小化：SCIM で不要な属性は要求しない。need to know 原則。
- 保存期間：退職者データの保持日数・匿名化手順を明文化。
- 監査可能性：誰が何をいつ同期したか、外部から証跡提示が可能。
- 鍵管理：トークンと JWKs のローテーション計画。
- テナント分離：論理分離＋レート制御はテナント単位で。
90 日アクションプラン（非ギャラリー前提での商用運用）
| 期間 | 主なタスク | 成果物 |
|---|---|---|
| Day 1–30 | 要件定義、属性マッピング、スキーマ凍結、負荷試験設計 | 属性対応表、テストデータ、非機能要件 |
| Day 31–60 | 実装（SCIM/SSO）、監視・アラート、ドキュメント化、デザインパートナー導入 | 動作する PoC、導入手順書（JP/EN）、サポートFAQ |
| Day 61–90 | 大規模テナント検証、運用受け入れ、SLA/サポート体制確立 | 性能レポート、運用Runbook、契約付帯文書 |
社内外コミュニケーションの要点（テンプレ付き）
顧客向けアナウンス（例）
件名：Microsoft Entra アプリ ギャラリー掲載に関するご案内
平素よりお世話になっております。
現在、Microsoft Entra のアプリ ギャラリーにおける新規掲載申請が一時停止中です。
弊社製品は、当面「非ギャラリー（カスタム）」として SSO/SCIM をご利用いただけます。
導入手順書（JP/EN）と設定値一覧をご提供しますので、お申し付けください。
再開後はギャラリー版への移行手順をご案内します。営業・CS 向け FAQ（抜粋）
| 質問 | 回答の骨子 |
|---|---|
| ギャラリー再開はいつ？ | 公式未定。少なくとも 6 か月程度の長期化も見込み、非ギャラリーでの運用を前提にご提案。 |
| セキュリティ水準は？ | 認証・認可・監査・レート制御を明文化。第三者診断やログ監査で担保。 |
| 移行コストは？ | ギャラリー再開後はメタデータ移行用のガイドを提供。顧客手作業は最小限に。 |
「待つ」か「非ギャラリーで進める」か：意思決定の指針
| 条件 | 推奨アクション | 理由 |
|---|---|---|
| 導入急務（数週間〜数か月） | 非ギャラリーで開始 | 即時提供が可能。運用実績は審査でもプラス。 |
| ブランディング重視・大量配布 | 資料整備＋再開待機（並行で限定導入） | ギャラリー再開後の一気通貫ローンチに備える。 |
| 既存 SSO に SCIM を加えたい | 個別審査を打診＋非ギャラリーで提供 | 審査は時間を要する可能性。顧客要望には先行対応。 |
要点の再掲：いまは「待つ」か「非ギャラリーで手動提供」の二択。再開時期は未定だが、半年以上の長期化を想定して計画を。既存 SSO への SCIM 追加は停止ではないがハードルが高く、追加審査用の技術資料を早めに準備しましょう。
非ギャラリー導入チェックリスト（顧客配布用）
- テナント情報：ドメイン、テナント ID、管理者連絡先
- SSO：SAML/OIDC のどちらを使用するか、必要クレーム
- SCIM：Base URL、Bearer Token、テストユーザー 3 名、テストグループ 2 つ
- 属性マッピング：メール、表示名、社員番号、部署、役職
- ロールバック手順：SSO 無効化、SCIM トークン失効、手動復旧
- サポート窓口：営業時間、連絡手段、SLA
移行ガイダンス（ギャラリー再開後）
非ギャラリーで運用していた顧客をギャラリー版へ移す際は、設定の差分を最小化することが成功の鍵です。
- カスタム側の SSO/SCIM 設定値をギャラリーの既定に合わせる（識別子、クレーム名、属性マッピング）。
- メタデータの切り替え手順を 10 分以内で完了できるように手順化（スクリーンショット込み）。
- 移行ウィザードを用意できるなら、旧→新のマッピングを自動化（検証モードで差分を提示）。
- リスク低減のため、限定ユーザーから段階移行し、最終段で全体切替。
まとめ
Microsoft Entra アプリ ギャラリーへの新規登録は一時停止中で、SSO/SCIM の新規掲載は受け付けられません。既存 SSO アプリへの SCIM 追加は個別審査で継続可能ですが、基準は厳格です。目線としては少なくとも 6 か月程度の長期化を想定し、非ギャラリー提供での実運用・証跡づくりに注力するのが賢明です。いま整えるべきは、テナント設定情報・SCIM スキーマ・マニフェスト・ログ/監視・手順書の 5 点。再開時には、資料一式をもって迅速に申請し、早期掲載とスムーズな顧客移行を実現しましょう。
コメント