Visual Studio App Center のリタイアは、モバイル開発チームだけでなく、Microsoft Entra ID（旧 Azure AD）の条件付きアクセスを運用している情シスにも不安を与えがちです。本記事では、リタイア後の条件付きアクセスへの影響と、Android アプリが App Center SDK を使い続けた場合の挙動、そして実務で今すぐ取るべき対応を、エンジニア視点で整理して解説します。
Visual Studio App Center リタイアの全体像
まずは前提となるタイムラインと影響範囲を整理します。
| 項目 | 内容 |
|---|---|
| サービス名称 | Visual Studio App Center |
| 主な提供機能 | ビルド、テスト、配信、CodePush、Analytics（分析）、Diagnostics（クラッシュ・エラー報告）など |
| リタイア日 | 2025年3月31日（サインインとほぼ全機能が終了） |
| Analytics / Diagnostics | 2026年6月30日まで延長サポート（SDK からのログ送信と閲覧が継続） |
| サインイン / API | 2025年3月31日以降はサインインや API 呼び出しは不可 |
| 主な推奨移行先 | ビルド: Azure Pipelines / GitHub Actions テスト: BrowserStack App Automate など 分析・診断: Azure Monitor（モバイル対応を開発中）＋ Azure Native ISV（Datadog, Dynatrace, New Relic 等） |
ポイントは「ポータルとしての App Center は 2025/3/31 で終了したが、Analytics/Diagnostics のみは 2026/6/30 まで延命されている」という二段階構造になっていることです。これを踏まえて、条件付きアクセスやアプリへの影響を見ていきます。
App Center リタイア後の条件付きアクセスへの影響
条件付きアクセスのエンジンは別物なので“壊れない”
Microsoft Entra 条件付きアクセスは、Microsoft Entra ID（旧 Azure AD）の中にあるポリシーエンジンであり、App Center とは別サービスです。条件付きアクセスは「ユーザーがどのクラウドアプリやリソースにアクセスするか」をトリガーに動作し、その判定ロジック自体は App Center の有無に依存していません。
したがって、結論から言うと:
- 条件付きアクセス全体の機能・他アプリ向けポリシーには影響なし
- 「Visual Studio App Center」をターゲットにしていたポリシーだけが、対象アプリ消失により実質“発火しなくなる”
App Center 向け条件付きアクセスを設定する場合、公式ドキュメントでは「Cloud apps or actions」で「Visual Studio App Center」を選択する手順が案内されていました。
しかし 2025/3/31 以降、ユーザーが App Center にサインインすること自体ができないため、App Center をターゲットにした条件付きアクセス ポリシーが評価される機会はほぼなくなります。他のクラウドアプリ（Microsoft 365 や自社アプリなど）に対するポリシーは、そのまま通常通り動作します。
やっておきたい「App Center ターゲット ポリシー」の棚卸し
App Center にだけ適用していたポリシーが大量に残っていると、将来の運用で「このポリシーまだ生きている？」と誤解を生む原因になります。以下のような手順で棚卸しをおすすめします。
- Microsoft Entra 管理センターにサインイン
- [保護] > [条件付きアクセス] > [ポリシー] を開く
- 一覧から以下を確認
- ターゲットリソース（Cloud apps or actions）に「Visual Studio App Center」のみが指定されているポリシー
- もしくは、複数アプリのうち一つとして App Center が含まれているポリシー
- 以下の方針で整理
- App Center 専用のポリシー：無効化または削除してよい候補
- 他のクラウドアプリも含むポリシー：App Center のターゲットだけを外す（またはそのままでも挙動は変わらないが、ドキュメント上は修正推奨）
こうしておくことで、後から条件付きアクセスを調査する別チーム（SOC や監査部門など）が「App Center 用ポリシーが動いている」ように見えて混乱する事態を防げます。
「Require approved client app」廃止は App Center とは別の話
よく一緒に話題になるのが、条件付きアクセスの付与コントロール「承認済みクライアント アプリを要求（Require approved client app）」の廃止です。
Microsoft は、この付与コントロールを 2026年3月頃にリタイアし、それ以降は「アプリ保護ポリシーを要求（Require application protection policy）」への移行を推奨しています。
重要なのは、これは App Center のリタイアとは無関係な別イベント であり、以下のようなモバイルアプリへのアクセス制御に関わる機能だという点です。
- 対象：Outlook や Teams などの「承認済みクライアント アプリ」からのみアクセスを許可する条件付きアクセス
- リタイア後：「Require approved client app」だけを条件にしているポリシーは、強制力を失う（選んでいても効かなくなる）
- 推奨：Intune のアプリ保護ポリシーを利用し、「Require application protection policy」へ切り替える
したがって、条件付きアクセスの観点で 2025〜2026 年にやるべきことは大きく 2 つです。
| タスク | 対象 | 期限イメージ |
|---|---|---|
| App Center をターゲットにしたポリシーの整理 | クラウドアプリ「Visual Studio App Center」 | 2025年中に棚卸し（リタイア直後〜） |
| 「Require approved client app」使用ポリシーの移行 | Entra 条件付きアクセスの付与コントロール | 2026年3月までに「アプリ保護ポリシーを要求」へ移行 |
この 2 つは似たタイミングで話題に出るため混同されがちですが、技術的にも運用的にも別テーマとして扱うのがおすすめです。
Android アプリは App Center SDK を使い続けて良いのか
Analytics / Diagnostics は 2026/6/30 まで利用可能
App Center の公式アナウンスでは、Analytics と Diagnostics について次のように明記されています。
- App Center 自体は 2025年3月31日にリタイア
- ただし Analytics & Diagnostics は 2026年6月30日まで、従来と同様に利用可能
この延長は、Azure Monitor 側でモバイル向け Analytics 機能を実装する時間を確保するためと説明されています。
つまり、App Center SDK を組み込んでいる Android アプリから送信されるクラッシュやイベントのログは、2026/6/30 まではこれまで通り集計・閲覧できます。その一方で、ビルドや配信、CodePush などその他の機能は予定通りリタイアしている点に注意が必要です。
アプリ本体への影響：基本的には少ないが、実装次第で変わる
一般的な解析系 SDK（App Center 含む）は、ネットワーク障害やサーバ停止があってもアプリ本体の動作に影響を与えないよう配慮されています。トラッキングの送信が失敗してもリトライしてキューに溜めるだけ、という設計が多いです。
とはいえ、実アプリ側の書き方によっては例外が表に漏れてクラッシュを引き起こす可能性があります。例えば:
- アプリ起動時に App Center 初期化に失敗すると
RuntimeExceptionをそのまま投げてしまう - クラッシュレポート送信の結果を待ち合わせる同期処理を実装しており、タイムアウトで UI が固まる
- 独自ラッパーのバグで例外が握りつぶせていない
このため、Analytics/Diagnostics を今すぐ止める必要はないが、「App Center SDK を無効化／削除した場合にアプリが問題なく動くか」は必ず検証しておくのが安全です。
SDK 無効化時の動作確認のポイント
Android アプリ側では、次のような観点でコードレビューとテストを行うと安心です。
- App Center の初期化コードをフラグで切り替えられるようにしているか
- 初期化やイベント送信の例外を try-catch で握りつぶしているか
- オフラインや DNS ブロックなど「App Center に接続できない状況」をエミュレートしてもクラッシュしないか
- SDK を完全に削除したビルドがストアに出せる状態か
例えば、Kotlin ベースのアプリであれば、以下のようなラッパー実装にしておくと、将来的に App Center を外す際も影響範囲を局所化できます（あくまでイメージコードです）。
object Telemetry {
private const val ENABLED = BuildConfig.APPCENTER_ENABLED
fun init(application: Application) {
if (!ENABLED) return
try {
AppCenter.start(
application,
BuildConfig.APPCENTER_SECRET,
Analytics::class.java,
Crashes::class.java
)
} catch (e: Exception) {
Log.w("Telemetry", "App Center init failed. Disable telemetry only.", e)
}
}
fun trackEvent(name: String, properties: Map<String, String> = emptyMap()) {
if (!ENABLED) return
try {
Analytics.trackEvent(name, HashMap(properties))
} catch (e: Exception) {
Log.d("Telemetry", "trackEvent failed. ignore.", e)
}
}
}このように「失敗してもアプリ本体には影響させない」方針で組んでおけば、Analytics/Diagnostics のサポート終了時にフラグをオフにするだけで安全に切り離せます。
Analytics / Diagnostics の移行先候補
App Center のリタイアに合わせて、Microsoft は Azure Monitor との連携強化と、Azure Native ISV（Datadog, Dynatrace, New Relic など）の活用を推奨しています。
| 用途 | 候補 | 特徴 |
|---|---|---|
| モバイル＋バックエンド一体監視 | Azure Monitor（Application Insights 等） | Azure サービスと統合しやすく、将来的にモバイル対応が進む方向性が公式に示されている。 |
| クラウドネイティブなフルスタック監視 | Datadog / Dynatrace / New Relic | いずれも Azure Native ISV として公式連携があり、Azure リソースとアプリケーションを横串で監視できる。 |
| クラッシュ・エラー集中管理 | Sentry など | クライアントクラッシュとサーバーエラーを統合してトラッキングしやすい。App Center からの移行事例も多い。 |
| モバイル向けクラッシュ＋配信 | Firebase Crashlytics / App Distribution など | Android と iOS に強く、Google Play Console との親和性が高い。 |
どれを選ぶにしても、「App Center 時代に送っていたイベント（画面表示 / 操作 / 購買など）を、そのまま移植するのか」「この機会に設計を見直すのか」 を一度棚卸しするのがおすすめです。
ビルド・配信・CodePush の代替
Analytics/Diagnostics 以外の機能は 2025/3/31 で終了しているため、すでに別基盤へ移行済みのチームも多いと思いますが、改めて整理しておきます。
| App Center 機能 | 推奨代替先の例 | ポイント |
|---|---|---|
| ビルド（CI/CD） | Azure Pipelines / GitHub Actions | App Center から Azure Pipelines へのビルド定義エクスポート機能が案内されている。既存の YAML 化も検討。 |
| 実機テスト | BrowserStack App Automate など | 20,000 台以上の実機デバイスをクラウドで利用可能。App Center からの移行を意識した CLI も提供。 |
| アプリ配信（テスト／社内配布） | iOS: TestFlight / App Store Android: Google Play（内部テストトラック等） | App Center Distribute の代わりに、ストアのプレビュートラックや MDM 製品の利用を検討。 |
| CodePush（OTA 更新） | App Center 依存のない独立版 CodePush（GitHub 配布） | React Native 向けに App Center から独立した CodePush バージョンが案内されており、継続利用が可能。 |
これらの移行は、一気にやるよりも 「ビルド」「配信」「解析」のフェーズごとに段階的に置き換えていく 方がリスクが低く、障害発生時の切り戻しもしやすくなります。
すぐにやることチェックリスト（ロール別）
ここからは、実務担当者のロール別に「今すぐ手を付けたいこと」をまとめます。
| ロール | タスク | ポイント |
|---|---|---|
| Entra ID 管理者 | App Center 参照ポリシーの棚卸し | 条件付きアクセスの「クラウドアプリ」に Visual Studio App Center を含むポリシーを検索し、専用ポリシーは無効化／削除、複数アプリ対象なら App Center を外すかコメントを追記。 |
| Entra ID 管理者 | 「Require approved client app」使用状況の調査 | 条件付きアクセス ポリシーの付与コントロールを確認し、該当するものを 2026/3 までに「アプリ保護ポリシーを要求」へ移行。Intune 側のアプリ保護ポリシー設計も併せて見直し。 |
| モバイル開発者 | App Center SDK 利用箇所の洗い出し | リポジトリを検索し、Analytics / Diagnostics / Distribute / CodePush など、どの機能をどのプラットフォームで使っているか一覧化。2026/6/30 までに代替基盤へイベント設計を移設。 |
| モバイル開発者 | SDK 無効化時の動作確認 | App Center SDK の初期化をフラグで ON/OFF できるようにし、OFF ビルドでの結合テスト／QA を実施。ネットワーク遮断状態でもクラッシュしないか確認。 |
| CI/CD 担当（DevOps） | ビルド・配信パイプラインの移行 | App Center Build から Azure Pipelines や GitHub Actions への移行、配信を TestFlight / Google Play に統合。テスト自動化は BrowserStack などのサービスを併用。 |
| 運用・サポート | 運用手順書・ヘルプの更新 | 「App Center ポータルへのサインイン」「App Center API 呼び出し」は不可となった旨を手順書から削除し、代替手順（Azure Monitor 画面や新ツールへのリンク）に差し替える。 |
実務では「とりあえずログだけ 2026 年まで App Center に送り続ける」判断も十分ありえます。その場合でも、今のうちに SDK の切り離しテストと代替基盤の候補選定だけは進めておくと、期限ギリギリで慌てる事態を避けられます。
補足：名称変更と公式サポート窓口
Azure AD は「Microsoft Entra ID」に名称変更済み
条件付きアクセスまわりのドキュメントを読むと、「Azure Active Directory」「Azure AD」と「Microsoft Entra ID」が混在していて混乱しがちです。Microsoft は Azure AD を Microsoft Entra ID にリブランディングしており、名称だけが変わって中身は同一サービスです。
- 旧称：Azure Active Directory / Azure AD / AAD
- 新称：Microsoft Entra ID
- 条件付きアクセスも「Azure AD Conditional Access」→「Microsoft Entra Conditional Access」と表記が変化
社内資料や運用手順書では「Microsoft Entra ID（旧 Azure AD）」のような併記にしておくと、過去資料との整合性が取りやすくなります。
App Center に関する公式サポート窓口
App Center のリタイアや移行に関して公式サポートに問い合わせる場合は、以下が案内されています。
- App Center ポータル右上の「?」メニュー > Contact support
- メール：[email protected]
Analytics / Diagnostics 延長や Azure Monitor 側のモバイル対応状況など、公式ロードマップが気になる場合は、ここから問い合わせるか Azure サポート経由で確認すると良いでしょう。
まとめ：条件付きアクセスとモバイル運用を安全に“ソフトランディング”させる
最後に、本記事のポイントをコンパクトに整理します。
- 条件付きアクセス自体への影響はなし App Center は単なる「対象クラウドアプリ」の一つであり、リタイアしても Entra 条件付きアクセスのエンジンや他アプリ向けポリシーはそのまま動作します。App Center をターゲットにしたポリシーだけ、今後は実質発火しなくなるため整理しましょう。
- 「Require approved client app」廃止への対応は別途必要 2026年3月までに、該当ポリシーを「アプリ保護ポリシーを要求」へ移行する計画を立ててください。これは App Center とは無関係ですが、同時期にやってくる条件付きアクセス周りの大きな変更です。
- Analytics/Diagnostics は 2026/6/30 まで延命される Android アプリに含まれる App Center SDK は、少なくともこの日まではクラッシュやイベントを送信し続けられます。ただし将来的な廃止を前提に、SDK 無効化時の動作確認と代替基盤（Azure Monitor や Datadog など）への移行設計を進めておきましょう。
- ビルド・配信・CodePush は早めに新基盤へ ビルドは Azure Pipelines / GitHub Actions、配信は TestFlight / Google Play、実機テストは BrowserStack、OTA 更新は独立版 CodePush といった形で、段階的に置き換えるのが現実的です。
App Center のリタイアは面倒ではありますが、モバイル開発パイプラインとセキュリティ基盤（条件付きアクセス）をアップデートする良い機会でもあります。焦って場当たり的に移行するのではなく、「いつまでに何を止めるか」「何をどの基盤に移すか」を明文化して、期限までにソフトランディングさせることを意識して進めてみてください。
コメント