まず、App Store Connectで設定したメッセージか、サーバーがリアルタイムAPIで選ぶメッセージかを判別し、該当する経路に沿って状態、購読との関連付け、Sandboxでの取消手順を確認してください。Sandboxのテスターには最新の草稿が表示される場合があるため、未承認だけを原因と決めつけないでください。リアルタイムAPIを使う場合は、サーバー応答とフォールバック設定も確認します。
iOSの自動更新サブスクリプションを開発していて、Sandboxの取消フローでメッセージが出ない方に向けた内容です。
StoreKitやサーバーを担当し、購読・特典の適用条件や応答を確認したい方にも役立ちます。
CIやリリースを担当する方は、ビルド環境の問題とSandboxでの受け入れ確認を分けて判断できます。
最終更新：2026年11月8日。Appleの2026年11月4日付のRetention Messages発表、App Store Connectの設定・状態資料、SandboxおよびAPIの公式文書をもとに確認しています。
設定型とリアルタイムAPI型では、どこを切り分けるべきか
Retention Messagingは、App Store Connectであらかじめ作成する設定型と、App Storeからのリクエストにサーバーが応答して表示内容を選ぶリアルタイムAPI型とで、確認すべき証拠が異なります。Appleは2026年11月4日の発表で、サブスクリプションの取消フローに文案、画像、オファーを表示できる機能として案内しています。発表内容とWWDC26の公式説明を踏まえ、最初に実装経路を特定してください。
| 確認項目 | App Store Connectの設定型 | リアルタイムAPI型 |
|---|---|---|
| 最初に見る場所 | メッセージの状態、対象購読、オファー条件 | App Storeからの要求、サーバー応答、選択したメッセージ |
| 代表的な見落とし | 別の購読に紐付けた、草稿や審査状態の取り違え | 応答形式や識別子の不一致、タイムアウト |
| フォールバック確認 | 設定したメッセージと対象条件 | API応答、App Store Connectで設定したメッセージ、APIのデフォルトメッセージ |
| 先に保存する証拠 | 設定画面とプレビュー | 要求・応答ログ、選択結果、失敗種別 |
設定型なら、まずRetention Messageの設定手順で対象と内容を照合します。リアルタイム型なら、設定画面だけで判断せず、該当する要求と応答をログで追ってください。APIのフォールバック優先順位はRetention Messaging APIの公式資料で確認し、成功応答、無効な応答、タイムアウトを別々の事象として記録します。
なお、App Store Connect API 4.6という名称を見かけても、設定型の画面表示やリアルタイムAPI応答と同じ経路だとみなさないでください。調べているAPIの役割と、アプリが実際に呼び出すAPIを先に分けると、無関係なAPIキーやCI設定の調査を減らせます。
Sandboxで未承認のメッセージを試せるのか
Sandboxでは、テスターが最新の草稿を見られる場合があります。そのため、未承認であることだけを理由に「Sandboxでは表示されない」と結論づけず、状態と実際のテスト環境を併せて確認します。Appleのメッセージ状態の定義では、草稿、審査待ち、承認済み、却下などが区別されています。状態名とテスト中の環境を対応させ、想定外の状態遷移がないか見てください。
Sandboxで最新の草稿を確認できることと、すべてのアカウント・購読条件で必ず表示されることは同じではありません。プレビューが正しくても、取消フローでの表示は別に検証してください。
ここで確認するのは、テスト対象がSandboxか本番か、メッセージがどの状態か、そして画面プレビューと実際の取消フローのどちらで問題が起きているかです。状態の名前だけで表示可否を推測せず、実際に発生した経路を基準に記録してください。
購読との関連付けが済んでいるのに表示されない場合
メッセージが存在していても、テスト中の自動更新サブスクリプションと紐付いていなければ、対象の取消フローには出ません。また、オファー付きのメッセージでは、Sandbox Apple Accountがそのオファーの適用条件を満たさない場合に、特典が期待どおり表示されないことがあります。メッセージ自体の問題と、オファーの適格性の問題を分けて検証してください。
- 対象のメッセージと、現在テストしている自動更新サブスクリプションの識別情報を照合します。
- オファーなしのメッセージをプレビューし、文案や画像が設定どおりか確認します。
- オファー付きのメッセージは、対象条件とテストアカウントの適格性を別途確認します。
- 購読、アカウント、環境の組み合わせを記録し、別の組み合わせの結果を混同しないようにします。
App Store Connectの設定ガイドで対象購読とメッセージを照合し、プレビューと実際の取消フローを分けて確認すると、表示設定の問題と特典条件の不一致を切り分けやすくなります。
Sandboxの取消フローとリアルタイムAPIを順に再確認する
メッセージが表示されるのは、アプリ内に用意した独自の「解約」ボタンを押したときではなく、Appleが定めるサブスクリプション取消の流れをテストしたときです。Sandbox用Apple Account、テスト対象の購読、環境が揃っているか確認し、AppleのSandboxで自動更新を無効にする案内に沿って取消を実行してください。アプリ内で取消画面を模倣しただけでは、実際のシステムフローを検証したことになりません。
次の順で再現確認を進めます。
- 経路を特定します。 App Store Connectの設定型か、サーバー選択型のリアルタイムAPIかを、実装と設定の両方で確認します。
- 状態を記録します。 メッセージの状態を公式の状態定義と照らし、Sandboxで確認していることも記録します。
- 対象を照合します。 メッセージに関連付けた購読、テストする購読、Sandbox Apple Account、適用するオファーを確認します。
- プレビューを確認します。 オファーなしとオファー付きの内容を分けて見て、文案や画像、特典条件に問題がないか確認します。
- 正規の取消経路を実行します。 アプリ独自の模擬画面ではなく、AppleのSandboxテスト案内に沿って取消を行い、表示の有無を記録します。
- リアルタイムAPIの証跡を追います。 API型の場合は要求、応答、選択されたメッセージ識別子を照合し、タイムアウト、形式不備、正常応答を区別します。
- フォールバックを確認します。 API応答がない場合や無効な場合に、公式文書で示される設定メッセージやデフォルトメッセージへの経路が意図どおりかを調べます。
API型のチームは、Sandboxでの表示確認だけで終えず、本番前にAppleが案内する性能テストの要否と手順も確認してください。性能テストの開始方法とAPIのレート制限に関する説明を読み、要求処理の検証とSandboxの表示確認を別の合格条件として管理します。これらの資料にない応答時間や成功率を独自の確定値として扱う必要はありません。
再現した症状から、次の確認先を決める
- プレビューの時点で文案や画像が違う場合： 表示の取消フローより先に、設定内容、状態、対象購読を見直します。
- プレビューは正しいがSandboxの取消時に出ない場合： テスト環境、Sandbox Apple Account、正規の取消経路、購読の紐付けを再確認します。
- 設定型は出るがリアルタイムAPI型だけ出ない場合： 要求の到達、応答形式、選択したメッセージ識別子、フォールバックの記録に範囲を絞ります。
- メッセージは出るがオファーが違う場合： メッセージ本体ではなく、オファーの設定とテストアカウントの適用条件を確認します。
この順序なら、表示問題を直すために開発環境全体を作り直す前に、どの境界で再現するかを特定できます。MacやXcodeのビルド・署名環境が不足していると判明した場合に限り、開発用の遠隔Mac環境に関するガイドを参照し、ビルドの準備とSandboxでの取消確認を別工程として扱ってください。
Linux環境だけではXcodeを使うビルドや署名を完結できない一方、テスト対象によってはすべての調査にMacが必要なわけではありません。Macを購入すると、検証頻度が低い場合にも保守・更新を担う必要があり、共有の開発機ではビルド待ちや環境差が生じます。macOS上でのビルドや署名がボトルネックなら、日本向けMac miniの利用案内を含め、購入・手元のMac・レンタルを比較し、必要な期間だけ遠隔Macを使う選択肢も検討できます。なお、遠隔Macの利用だけで実機接続や物理デバイスの検証が可能になるとは限らないため、実機確認が必要かどうかはプロジェクトのテスト経路に基づいて判断してください。