App Store Connect API 4.5.1のスクリーンショットAPI移行はどうする？2026

Appleのリリースノートでは、App Screenshot Sets、App Screenshots、App Preview Sets、App Previewsと、一部のアプリ内イベント媒体リソースが非推奨として示されています。移行先はApp Asset Libraryの画像、動画、placementです。旧リソースの即時停止日は同ノートに記載されていないため、停止済みと決めつけず、依存箇所を特定して計画を立てます。リリースノートの非推奨項目

どの旧リソースを先に洗い出すべきですか。
リポジトリ、CI設定、運用スクリプトを検索し、旧リソースへのAPI呼び出しと、その応答に含まれるIDの保存先を記録します。バージョンのローカライズ、Custom Product Page、アプリ内イベントのどれを更新しているかも、呼び出し元と一緒に残してください。

次に、API呼び出しだけでなく、リソースIDを後続ジョブがどう利用するかを追います。旧IDを直接参照するテスト、失敗時の再実行処理、削除処理が残っていると、新しい素材を登録しても切り替え後に誤更新や誤削除が起こり得ます。

App Asset Libraryでは、画像や動画という素材と、それを表示するplacementを分けて扱います。同じ素材を複数のストアページで使う設計でも、旧スクリーンショット集合を新しいplacementと同一視しないでください。Appleの素材ライブラリAPI概要とストア画面への素材配置の説明に沿い、ページ、ローカライズ、素材種別、表示順の対応を保ちます。

App Screenshot Setsのデータをそのままplacementに置き換えられますか。
機械的な置換は避けてください。旧セットと新しい配置先の意味が一致するとは限りません。各素材に、用途、ローカライズ、ページ、表示順を対応付けてから新しい関係を作ります。素材を複数ページで共有する場合は、片方のページで素材を差し替えたり削除したりしても、別ページの表示が壊れないことを検証します。

API 4.5.1では、利用可能な素材仕様を確認するための参照データAPIが追加され、iPhone Duoの表示カテゴリも含まれます。寸法や制限を恒久的な定数として埋め込まず、実行時に返された表示タイプと仕様を確認してください。根拠となる仕様情報は、Appleの素材仕様を参照するAPI資料とスクリーンショット仕様で確認できます。

アプリ内イベントのスクリーンショットや動画はどう扱いますか。
旧イベント媒体の関連付けを残したまま、新しい素材とplacementの関係を別に作成します。イベントのローカライズ、画像か動画かという種別、表示対象を照合し、別のページでも使っている素材を誤って削除しないよう参照関係を確認します。アップロード成功だけでなく、イベント画面に意図した媒体が出るところまでテストします。

素材生成、素材の予約、アップロード、送信、処理状態の確認、placement作成を、それぞれ判定できる工程として扱います。APIが成功応答を返したことは、素材の処理完了やストア画面への表示成功を意味しません。Appleのアップロード手順を基準に、各工程の応答と状態を記録してください。

アップロード完了と正しい表示はどう判定しますか。
アップロードの応答、素材の処理状態、配置先との関連、対象ページでの実表示を別々に確認します。Mac CIスクリーンショットアップロードのジョブは、最終画面の確認結果まで同じ実行IDにひも付けると、API成功後に止まった箇所を追いやすくなります。

以下のチェック項目を、隔離したアプリまたは非本番の公開経路で実行します。

• [ ] 旧APIを呼び出すジョブと、参照・保存されるリソースIDを一覧化する。
• [ ] 素材ごとにページ、言語、媒体種別、表示順、利用先を記録する。
• [ ] 参照データAPIから現在の表示タイプと仕様を取得する。
• [ ] 新しい素材をアップロードし、処理状態が完了するまで確認する。
• [ ] 対応するplacementを作り、画面上の表示と並び順を確認する。
• [ ] 同一素材を共有する別ページやイベントへの影響を確かめる。
• [ ] 失敗時の再実行、旧経路への復帰、ログとリソースIDの追跡を検証する。

API移行だけでMac CIノードも作り直す必要がありますか。
素材を生成する工程が別環境で完結し、Mac固有のツールや処理を使わないなら、API移行を理由にノードを再構築する必要はありません。macOS上でスクリーンショット生成や関連ツールの実行が必要な場合に限り、そのジョブの実行環境と権限を確認します。

旧経路と新経路を並行稼働させる期間は、素材の対応関係、表示順、失敗からの復旧を比較できるようにします。呼び出しログ、素材ID、処理状態、対象ページの確認記録を残し、証拠がそろう前に全公開経路を切り替えないでください。

• 新旧の素材が同じページ、ローカライズ、順序で表示され、再実行と復旧も検証できた場合は、対象を限定して新経路へ切り替えます。
• アップロードは成功しても処理状態や画面表示を確認できない場合は、旧経路を維持し、失敗箇所のログを追加します。
• 共有素材の削除・置換が他ページに及ぼす影響を説明できない場合は、削除を伴う切り替えを保留します。
• 旧リソースが非推奨という情報だけで期限を設定せず、Appleの公開情報に変更があれば計画を再確認します。

この移行で先に決めるべきなのは、APIを利用するノードの買い替えではなく、素材生成にmacOSが必要かどうかです。既存のMac CIを使う方法は環境を維持しやすい一方、稼働しない時間の設備費、保守、容量調整を自社で担います。素材生成がmacOSに依存し、手元のノードの保守や余剰容量が課題なら、CALMVPSのリモートMacの料金と利用条件を比較対象にできます。

一時的な移行検証や増設用の環境が必要な場合は、CALMVPSの利用案内でリモートMacの利用方法を確認してください。長期にわたり安定した高負荷処理を続ける場合や物理機器への接続が必要な場合は、自社保有のMacが適しています。素材が別環境で生成されるチームなら、API移行のためだけにMac CIを変更せず、アップロードから画面表示までの検証を先に完了させてください。