iPhone Duoのスクリーンショット要件が公開、2026年の企業CIはどう備える？

公開時期が近づいても、どのアプリの画面素材を直せばよいか把握できていない。 今週はアプリ・言語・素材の担当を棚卸しし、iPhone Duoのスクリーンショット要件を公開前チェックへ追加してください。要件だけを理由に、CI基盤やMacノードを入れ替える必要はありません。

企業のiOS公開担当者：製品ページの素材とバージョン提出を調整する方が対象です。
CI基盤の担当者：スクリーンショット確認と公開証跡を自動化したい方に向いています。
複数アプリを管理するIT責任者：素材管理が既存の公開統制に与える影響を確認できます。

最終確認：2026年10月13日。AppleのApp Store Connect公開情報とリリースノートを照合しています。要件や提出手順は更新される可能性があるため、実際に公開する前にも各公式ページを再確認してください。

公開要件の発表と実際の適用は分けて管理する

AppleはiPhone Duo向けスクリーンショット要件を案内しており、対象となるアプリまたはゲームの提出には2026年以降の4月から適用すると公表しています。つまり、2026年10月13日時点では「発表済み」と「すでに提出条件として適用中」は同じ意味ではありません。適用時期はAppleの発表とApp Store Connectのリリースノートで確認し、公開計画には公式記載を根拠として残してください。

ここで整理したいのは、スクリーンショット要件と端末互換性テストの違いです。製品ページ用の画面素材を用意することは、アプリが新しい端末で正しく表示・動作することの検証とは別の作業です。AppleのiPhone Duoデザインガイドは画面設計の確認に使えますが、素材準備だけで端末検証まで完了したと判断しないでください。

iPhone Duoのスクリーンショット要件はいつから適用されますか？
Appleの案内では、2026年以降の4月から対象アプリまたはゲームの提出に適用されます。実務では、発表日を適用開始日と取り違えず、公式ページに記された対象範囲と時期を公開計画に転記してください。記載に変更があれば、社内の公開日程も更新します。

公開計画の初期段階で素材の持ち主を特定する

素材の不足は、提出直前になってから発覚すると、撮影・確認・翻訳の担当調整が一度に発生します。公開計画を作る段階で、アプリごとに対応するプラットフォーム、言語、製品ページ、素材の保管場所、作成担当者を一覧にしてください。

既存素材を「流用できる」「更新が必要」「未確認」に分け、iPhone Duo向け素材が不足しているアプリには担当者と確認期限を割り当てます。Appleが定めた適用対象・時期と、社内の先行準備日や完成目標は別の欄に記録し、社内の目標を公式要件のように扱わないことが大切です。

この棚卸しは、アプリ単位だけでは不十分です。同じアプリでも言語や製品ページが異なると、必要な素材や確認状況が分かれるためです。アプリ名、バージョン、言語、素材の版、レビュー担当、提出可否を一つの台帳で追跡できるようにします。

素材作成前に仕様と画面の意味を照合する

App Store ConnectのiPhone Duo向けスクリーンショットには何を合わせますか？
サイズ、向き、ファイル形式、表示対象を、Appleのスクリーンショット仕様で確認します。数値や対応条件は更新される場合があるため、過去の素材台帳や別端末向けの設定値だけで判断せず、作成時点の公式仕様を参照してください。

画面の内容も仕様確認と同時に見ます。実際のアプリ体験を示すスクリーンショットと、文字や装飾を加えた販促用デザイン素材は役割が異なります。提出用画像が何を表しているのか、製品の現行動作と矛盾しないかを確認し、スクリーンショットに関する審査ガイドラインも照合してください。

シミュレーターで作った画像なら、すべて審査要件を満たしますか？
シミュレーター画像を使えるかどうかだけで、提出要件への適合を決めないでください。画像の寸法や形式を仕様と照合し、画面内容が実際のアプリを正確に示しているかを別に確認します。シミュレーターからの出力は素材作成手段の一つであり、審査で受け入れられることを保証するものではありません。

生成・保管工程を既存の公開フローへ接続する

素材の作成主体は、製品チーム、QA、公開担当のいずれかを曖昧にしないでください。誰が撮影し、誰が仕様を確認し、誰が製品ページへ登録するかを定め、元画像、加工後の画像、言語版、アプリバージョン、承認状態を追跡できる形で保存します。

スクリプトやXcodeの機能を使う場合は、チームの現行環境で同じ入力から同じ形式の成果物を再生成できるかを先に試します。Xcode 27.1のリリースノートも参照できますが、特定のツールが撮影、翻訳、画像加工、承認まで自動で完了すると決めつけないでください。自動化の対象と、人が確認する工程を分けて設計します。

CIの検査と提出前の人手確認を別の門にする

企業のiOS CIでは、素材の不足をどう検知できますか？
アプリと対象言語に対応する素材が登録されているか、ファイルを読み取れるか、現行のスクリーンショット仕様に沿っているかを提出前に検査します。検査結果はビルドの識別情報と一緒に保存し、あとからどの素材を確認したか追えるようにします。

次の条件で自動化の範囲を決めてください。

• 必須ファイルの有無と命名規則を機械判定できる場合は、CIで不足を検出します。
• 画像の寸法や形式を検査できる場合は、仕様値を更新可能な設定として管理し、チェック失敗時に対象ファイルを報告します。
• 画面内容の正確さ、言語表現、製品ページ上での見え方を判断する場合は、人の確認を残します。
• Appleへのアップロードと製品ページのプレビュー確認が終わっていない場合は、CIの合格を提出完了として扱わず、公開判定を保留します。

この境界を明確にすると、CIは欠落や形式不備を早く見つける一方、審査受け入れの判断を代行しない設計になります。App Store Connectへの登録手順は、スクリーンショットとアプリプレビューのアップロード説明で確認してください。

小規模な試行で提出完了までの責任を確かめる

全アプリへ一斉適用する前に、代表するアプリを一つ選び、素材の準備から仕様確認、CI検査、アップロード、製品ページのプレビュー確認までを通します。各工程の担当者、結果、使用した素材の版を記録し、失敗があれば「素材不足」「仕様不一致」「内容確認待ち」「アップロード後の表示確認」といった原因に分けて手順を直してください。

試行が通った後に、他のアプリへ展開するかを判断します。iPhone Duoのスクリーンショット要件で、既存のApp Store Connect提出フローを全面変更する必要はありますか？ 基本的には、素材準備と検査の工程を追加し、責任者と提出前確認を明確にすれば対応できます。要件だけを根拠にCI基盤やMacノードを変更せず、既存環境で再現性のある素材検査と公開作業ができるかを先に検証してください。

公開作業が一時的に増える場合は、現行CIを保ったまま作業用のMac環境を分ける方法も比較できます。固定した重い処理が継続するチームなら、自社保有環境のほうが適することがあります。一方で、短期の検証用環境を追加購入すると、調達、保守、利用終了後の管理が残ります。必要な期間だけ環境を用意したい場合は、VMSPINの料金情報を確認し、既存設備の維持と比較してください。

まずは代表アプリで素材の棚卸しから製品ページのプレビューまでを通し、CIが担う検査と人が担う承認を分けてください。短期のスクリーンショット検証や公開作業のために独立したmacOS環境が必要なら、VMSPINの利用手続きも選択肢として確認できます。要件への対応だけを理由に現行のCIやMacを一新するのではなく、実際の公開負荷と運用期間を基準に判断するのが妥当です。