App Store Connect API 4.6：INSTALLSレポート停止後はどうする？2026

Appleのリリースページでは、App Store Connect API 4.6の公開日が2026年11月4日とされています。(Appleのバージョン公開情報) この変更後、新しいINSTALLSレポートが生成されなくなっても、過去のレポートを取得できる範囲は別に確認できます。新規データがないだけで、CIの認証失敗や通信障害と決めつけて再試行を続けないでください。

適する：レポートの生成状態を確認し、履歴を保管してから、CIとダッシュボードの「データなし」の扱いを変更する運用です。適さない：別の指標を検証せずINSTALLSと同じ意味で扱ったり、新規レポートを取得できないたびに一律再試行したりする運用です。

この記事は、App Store Connect APIのレポート取得を保守する開発者、macOS CIの定期タスクを担当するエンジニア、配信データの傾向を管理する担当者向けです。確認するのは、レポートの状態と通常の障害の切り分け、過去データの保存、ダッシュボードとタスクの変更です。

最終更新：2026年11月7日。 AppleのAPI 4.6リリースノート、売上・トレンドレポートの取得仕様、レポートの利用可能期間を照合した情報です。Appleが仕様や履歴データの取得条件を更新した場合は、運用変更の前に該当資料を再確認してください。

App Store Connect API 4.6 INSTALLSレポートの状態

App Store Connect API 4.6後も、新しいINSTALLSレポートは生成されますか。
AppleのAPI 4.6に関する案内で、INSTALLSレポートの新規生成が停止する変更を確認した場合、取得結果がないこと自体を一時的なジョブ障害と扱わないでください。一方で、過去のレポートが取得できるかどうかは、新規生成の状態とは分けて確認します。利用可能期間と取得範囲は、Appleのレポート利用可能性に関する説明を基準にしてください。

取得失敗と仕様変更を見分ける際は、リクエスト先、認証、HTTP応答、実行ログを順に確認します。認証エラーや接続エラーが出ているなら通常の障害対応が必要ですが、リクエストが正常に完了して対象レポートだけがない場合は、レポートの生成状態と履歴取得条件を調べます。

この区別が重要なのは、空の取得結果を「インストール数ゼロ」に置き換えると、事実と異なる傾向がグラフや集計に残るためです。また、無期限の再試行はログを増やし、認証やネットワークの本当の異常を見つけにくくします。

INSTALLS履歴の取得と保管

INSTALLSの過去レポートはAPIから取得できますか。
過去レポートの取得可否は、レポートの種類とAppleが示す利用可能期間、リクエスト条件に従います。新規生成の停止を理由に、過去データがすべて消えたとも、いつまでも取得できるとも判断せず、売上・トレンドレポートのAPI仕様と利用可能性の説明を照合してください。

すでに取得したファイルがある場合は、APIから再取得できることを前提にせず、チーム管理の保管先へ移します。ファイル名やメタデータには対象期間、レポート種別、取得時刻を残し、元ファイルと加工後データを区別します。保管先のアクセス権限やバックアップ方針も確認し、特定のCIホストだけに履歴が残る状態を避けてください。

ダッシュボードでは、レポートの欠落をゼロ値として埋めないようにします。「値がゼロ」「対象データなし」「取得処理の失敗」を異なる状態として扱い、傾向線や合計値に欠損日が混ざらないことを確かめてください。データがない期間を過去の値で補間する場合も、実測値と推定値を識別できる表示が必要です。

指標の置き換えを検討する基準

INSTALLSが停止した後、別の指標で埋められますか。
まず、必要なのがインストール数、ユーザー獲得、アプリの利用やその他の行動のどれなのかを定義します。名称や用途が近く見える指標でも、集計対象や計測条件が異なれば、既存のINSTALLSと同じ意味では使えません。

Appleの分析指標の定義を確認し、候補の指標について対象ユーザー、イベント、集計単位、対象期間を比較します。Appのインストールと削除に関する説明やPlatform App Installsの定義も、名称だけで判断せず、定義と自社の用途を照合してください。Appleが同等性を明示していない指標は、同一の系列として連結しないのが安全です。

置き換えが必要なら、ダッシュボード上で指標名と定義の変更点を明示し、旧系列との境界を分けます。過去のINSTALLSを新しい値で書き換えるのではなく、切り替え日以降の系列として管理してください。集計ルールの変更は、レポートの利用者にも伝わる形で記録します。

macOS CI定期タスクの変更手順

macOS CI定期タスクは、レポートが存在しない状態を成功・失敗のどちらかに機械的に寄せず、取得処理の結果とレポートの生成状態を分離します。以下の項目を順に確認してください。

• [ ] リクエスト先、レポート種別、対象期間を記録し、想定したINSTALLSレポートを要求しているか確認します。
• [ ] 実行ログから認証、通信、API応答の異常と、対象レポートがない状態を区別します。
• [ ] 過去のレポートを取得できる条件を確認し、取得したファイルをチーム管理の保管先へ移します。
• [ ] 新規レポートがない場合の処理を定義し、同じ条件で無期限に再試行しないようにします。
• [ ] ダッシュボードと下流の集計が、欠損をゼロや正常値に変換しないことを確認します。
• [ ] 過去データの取得経路と、実際の定期タスクの結果をそれぞれ確認し、ログと通知の内容を見直します。

実行結果が成功でも、新しいINSTALLSレポートが生成され続けているとは限りません。成功判定は「タスクが所定の処理を完了した」ことを示すようにし、レポートがない状態は別の結果としてログや通知に残します。反対に、過去データの取得失敗を仕様変更だと決めつけず、認証やリクエスト条件も引き続き確認してください。

定期タスクのスケジュールを変える前に、欠損時の表示、アラート、下流の集計まで確認してください。取得処理だけを直しても、後段が空値をゼロに変換すれば、誤った傾向は残ります。

運用環境を見直すときの選択肢

レポート取得そのものは、AppleのAPIへアクセスできる環境であれば、Mac上でなければ実行できない処理とは限りません。必要なのは、認証情報の管理、ログの保存、タスクの監視、履歴の保管を継続できることです。たとえば、Mac環境の選び方に関するガイドを参照し、既存のCIを維持する場合と、macOS上での継続実行を追加する場合を分けて検討できます。

既存環境を使い続ける方法は、環境を増やさずに済む一方、ホストの保守や停止への備えを自分で担います。Macを購入すれば実機や周辺機器を直接管理できますが、初期費用と継続的な保守が必要です。短期の検証や追加のmacOS実行環境が必要なら、日本向けMacレンタルも比較対象になりますが、物理機器への直接接続が必要な用途や、長期にわたり安定した高負荷を継続する用途では、自前の実機など別の選択が適する場合があります。

今回の変更で優先すべきなのは、Macを追加することではなく、履歴を保全し、レポートがない状態を障害やゼロ値と混同しない設計に変えることです。現在のCIホストの保守、稼働状態の確認、データ保管を自分で担う負荷が問題になっているなら、必要な期間だけMac環境を借りる選択肢もあります。タスクの実行場所としてMacが必須かを先に確認し、必要な期間や保守体制に合うかを見てから判断してください。