結論：非推奨を停止と取り違えず、新しい連携はApp Asset Libraryへ
AppleはApp Store Connect API 4.5.1のリリースノートを2026年10月6日に公開し、旧スクリーンショット、プレビュー、一部のアプリ内イベント素材リソースを非推奨としました。新規連携はApp Asset Libraryを使い、既存連携は素材種別ごとに資産とplacementへ移行して、アプリ単位でアップロード、配置、並び順まで検証してください。非推奨は、ただちにAPIが停止したという意味ではありません。
対象読者 App Storeのスクリーンショットやプレビュー動画を自動登録している独立開発者：旧APIと新しい素材モデルの対応を確認できます。 複数アプリやカスタムプロダクトページを保守する小規模チーム、アプリ内イベント素材を自動化する開発者：分割移行と確認対象を整理できます。
最終更新：2026年10月15日。AppleのAPIリリースノート、App Store Connectの素材管理情報を照合しました。
移行判断を、現在の利用状況で分ける
移行を始める前に、旧インターフェイスが現行の処理で呼ばれているか、どの素材に使われているかを確認します。すべてのチームが同じタイミングで切り替える必要はありませんが、新規実装で非推奨リソースを採用する理由もありません。
- 新しく連携を作る場合：App Asset Libraryを基準に設計します。旧セットモデルを新規実装へ持ち込むと、近い将来に再度モデルを見直す作業が増えます。
- 既存の自動化が旧素材リソースを使う場合：非推奨の対象と呼び出し箇所を棚卸しし、素材種別ごとに移行計画を立てます。公開予定が近いなら、未検証の全面切り替えを避け、変更対象と受け入れ確認を分けます。
- 旧素材リソースを呼び出していない場合：不用意にコードを変更せず、新APIの仕様と素材の運用要件だけ確認します。
注意：非推奨の表記を見て、稼働中の公開ワークフローを一斉に切り替えるのは避けてください。まずAPI呼び出しとApp Store Connect上の状態を照合し、検証可能なアプリから段階的に進めます。
素材と表示先を分離して考える
旧来のセット型モデルでは、表示先に結び付いたスクリーンショットセットやプレビューセットを入口に素材を扱う設計が中心でした。App Asset Libraryでは、画像や動画という素材本体をライブラリで管理し、placementでページやローカライズなどの表示先へ関連付けます。
Appleの素材管理ガイドに沿って整理すると、移行後は「素材が登録されている」ことと「目的のページに表示されている」ことを別々に確認する必要があります。同じ素材を複数箇所で使う設計も可能性として検討できますが、対象placementでの利用可否はAPIの参照データと処理結果を確認し、決めつけないでください。
比較すると、判断は次のようになります。
- 旧セット型：素材セットと表示先の関係を中心に実装します。既存処理の依存関係は追いやすい一方、素材の再利用先や表示位置をセット単位で管理していると、移行時に読み取りや削除まで見直しが必要です。既存運用との適合度は高くても、新規設計の選択肢としては避けるのが妥当です。
- App Asset Library型：画像・動画の資産とplacementを分けて扱います。素材の再利用や表示先の変更を整理しやすい反面、素材IDとplacementの対応、処理状態、順序を別途追跡する必要があります。新規実装との適合度は高く、既存システムでは移行検証の負担を見込むべきです。
API呼び出しを素材種別と操作で棚卸しする
移行漏れは、アップロード処理だけを置き換え、一覧取得、更新、削除、並び替えを旧モデルのまま残すところで起きやすくなります。対象はApp Storeのバージョン素材に限らず、自動化が触れているカスタムプロダクトページ、プロダクトページ最適化テスト、アプリ内イベントの素材まで確認します。
まず、各処理を次のように分けて記録します。
- バージョンのスクリーンショットとプレビュー：素材の取得・アップロードに加え、どのバージョンや表示先に割り当てるかを追います。
- カスタムプロダクトページとテスト素材：通常の製品ページ素材と同じ扱いだと仮定せず、対象ページ、ローカライズ、利用可能なplacementを個別に確認します。
- アプリ内イベント素材：旧イベント素材リソースに依存する読み取り、登録、更新、削除が残っていないかを調べます。
- 共通処理：一覧取得、状態確認、並び替え、関連付け解除、削除を、呼び出し元と素材IDの対応が分かる形で記録します。
| 旧モデルで扱う対象 | 新モデルで確認する対象 |
|---|---|
| スクリーンショット、プレビューなどの素材 | App Asset Libraryの画像または動画 |
| 表示先と結び付いた素材セット | 対象ページ、ローカライズ、placement |
| セット内の順序や削除処理 | placementの順序、関連付け解除、資産削除 |
実務では、呼び出し元、素材種別、操作内容、旧リソース、新しい資産とplacementの対応を一つの台帳にします。未確認の項目が残るなら、アップロードだけを新方式にして本番へ出すのではなく、読み取り・変更・削除まで対応範囲を閉じてから段階移行します。
仕様と対応機種を実行時に確かめる
placementの種類やグループ、素材仕様をコードに固定すると、API側の対応変更やアプリごとの利用条件に追随できません。実装時には、APIが返す参照データから利用可能なplacement、placement group、サイズなどの情報を取得し、対象アプリと表示先に適用できるものを選びます。
API 4.5.1では、iPhone Duoに関する素材表示カテゴリも確認対象になります。ただし、カテゴリが存在することだけを根拠に、特定の画像をすべての表示位置へ割り当てられるとは判断できません。AppleのApp Store素材ステータス情報と実際の参照データ、APIの応答を合わせて確認してください。
確認の観点：対応カテゴリ、素材の寸法条件、placementの利用可否は、固定した一覧ではなく取得時の情報を基準にします。APIが受け付けたこと、素材処理が完了したこと、画面に選択・表示されたことは別々の状態です。
再利用・並び替え・削除を一組で検証する
同じ画像を別のローカライズや複数の表示先でも使いたい場合は、まず素材本体をライブラリへ登録し、その後に利用先ごとのplacementを関連付けます。ローカライズごとに素材を複製する必要があるか、共通素材を再利用できるかは、対応するplacementと参照データを確認して決めます。
素材の内部IDとApp Asset Libraryの資産IDは、アプリ、ファイル、アップロード結果、placementの対応が追える形で保存してください。資産だけを削除しても関連付けが残る、またはplacementを先に消さないことで削除が失敗するといった問題を避けるには、削除順序もテスト対象に含めます。旧セット削除の動作が新しい資産・placement構成でも同じだとは仮定しないでください。
運用上の評価は、素材の再利用性だけでなく、関連付けの追跡可能性、並び順の再現性、失敗後の復旧しやすさで行います。移行による固定の時間短縮や性能向上を前提にせず、チームの素材更新頻度と保守体制に照らして判断します。
編集可能なアプリで端から端まで受け入れ確認する
移行後は、対象アプリの編集可能な素材を使い、API応答とApp Store Connect上の状態を別々に記録します。最低限、次の流れを自動化のテストケースに含めてください。
- 旧リソースを呼び出す処理が残っていないか、ログとコード検索で確認します。
- 対象の画像または動画をApp Asset Libraryへ登録し、API応答と資産IDを記録します。
- 素材の処理状態を確認し、アップロード成功だけで次工程へ進まないようにします。
- 対応するplacementを関連付け、ページとローカライズが意図した対象か確認します。
- 並び順を設定し、API上の値とApp Store Connectでの表示順を照合します。
- App Store Connect画面で素材が選択されていることを確認し、変更後の状態を記録します。
- 必要に応じてplacementの変更・解除・削除も試し、再実行時に重複や残存資産が生じないか確認します。
移行先を決める条件分岐
- 新規に素材自動化を作るなら、App Asset Libraryとplacementを採用します。旧セット型APIを新規処理へ導入する案には戻りません。
- 旧素材APIを本番利用しているなら、素材種別と操作の棚卸しを完了し、編集可能なアプリで一連の配置・並び替えを確認してから切り替えます。
- 旧素材APIを利用していない、または公開直前で検証時間がないなら、無関係な処理は変更せず、対象となる連携の有無と公開資料を確認して移行時期を定めます。
- 参照データ上でplacementや仕様を確認できないなら、サイズや表示先を推測で固定せず、その素材の公開を保留してAPI応答とApp Store Connect上の選択可否を調べます。
よくある質問
App Store Connect API 4.5.1で非推奨になった素材は何ですか？
Appleのリリースノートでは、スクリーンショットセット、スクリーンショット、プレビューセット、プレビュー、および一部のアプリ内イベント素材リソースが非推奨として示されています。非推奨は移行を計画すべき状態ですが、それだけで即時停止や固定の終了日を意味しません。対象アプリで実際に使うリソースを呼び出し単位で確認してください。
App Asset Libraryは旧スクリーンショットセットと何が違いますか？
旧モデルでは、表示先に結び付いた素材セットを作り、その中の画像や動画を扱う設計が中心でした。App Asset Libraryでは素材本体と表示先を分け、保存した画像や動画をplacementで利用先へ関連付けます。したがって、素材レコードだけを確認しても、どのページやローカライズに表示されるかは判断できません。
同じ画像を別のローカライズでも使うには、どう確認しますか？
まず素材ライブラリへ画像を登録し、各ローカライズに対応するplacementを作成または関連付けます。同一画像を複数箇所で再利用できるかは、対象のplacement種別とAPIが返す参照データ、処理結果で確認してください。画像のアップロード成功だけでは、別ローカライズのページで選択できることまでは保証されません。
移行したplacementは何を確認してから公開しますか？
対象ページのplacementが作成されていることに加え、素材の処理状態、ローカライズ、表示順、App Store Connect画面で選択された素材を別々に確かめます。APIの成功応答はアップロードや関連付けの結果を示すにとどまり、ページへの反映や審査通過とは別です。並び順の変更と削除も、旧セットの操作をそのまま流用せず検証します。
素材移行のAPI処理だけなら、App Store Connect APIへ接続できる実行環境があれば進められ、Macは必須ではありません。一方、素材生成やiOS公開スクリプトがmacOS専用ツールに依存する場合、WindowsやLinuxの実行環境ではその工程を担えず、手元のMacではディスク容量の管理や常時稼働の保守が必要になります。そうした作業を一時的に実行する環境が必要なら、MACGPUのリモートMac環境案内とiOS公開自動化に使うMac環境を確認し、手元のMacを維持する場合と比較したうえで、必要な期間だけMACGPUのリモートMacを検討してください。