シリーズ：iOS版『見開きPDFビューア』開発記録
この記事は、ChatGPTと壁打ちしながら作成しました。Gitの変更履歴・ソースコード、当時のCodex・Geminiとの会話、Appleからの通知メール、筆者が提供したApp Store Connectの履歴をもとにしています。
第8回では、任意の応援商品の設定を非消耗型へ変更し、購入復元を実装・テストした経緯を取り上げました。今回は、実機動画などの追加情報を求められた経緯、審査への返信、並行して進めた契約・登録情報の手続きをまとめます。
審査経過の基準日は2026年10月20日です。この時点では「審査中」が続き、サポートへ2回問い合わせて回答を待っていました。その後、10月27日に審査継続の回答が届いたため、末尾付近に追記しています。過去の通知への対応と、その後の連絡を分けて振り返ります。
図1 保存されていた2026年9月30日付の実機録画から、起動前のホーム画面、PDF閲覧、検索の場面を抜粋しました。
App Store Connectに残った経過
以下は、App Store Connectに表示された履歴をもとにした記録です。日時は表示値のままで、画面側のタイムゾーンは別途確認していません。本文中で紹介するCodexの作業ログの時刻は、日本時間に換算しています。通知メールの氏名、個人メールアドレス、各種IDやアカウント専用リンクは掲載していません。
| 日付（2026年） | 主な状態・操作 |
|---|---|
| 8月16日 20:36 | 提出準備中 |
| 9月24日 10:03〜10:04 | 審査準備完了・審査待ちの後、バイナリが無効 |
| 9月24日 21:50〜21:51 | 再び提出準備・審査待ちの後、バイナリが無効 |
| 9月24日 22:22〜22:23 | 提出準備、審査準備完了、審査待ち |
| 9月25日 0:53 | 審査中、却下済み |
| 9月29日 11:15〜9月30日 10:38 | 提出準備から審査待ちへ |
| 10月1日 22:15〜22:28 | 審査中の後、却下済み |
| 10月2日 6:06 | 提出準備中 |
| 10月3日 5:32〜5:46 | 審査準備完了の後、開発者により却下 |
| 10月3日 5:48〜5:58 | 再提出の準備、審査準備完了、審査待ち |
| 10月5日 3:10 | 審査中 |
| 10月20日時点 | 審査中が継続。サポートへ2回問い合わせ、回答待ち |
8月16日の「提出準備中」は、審査開始を表すものとして数えていません。また、10月3日の「開発者により却下」と、Appleによる「却下済み」は分けて記録しました。
購入商品の指摘のほかにも、審査を進めるための追加情報を求められました。却下時の指摘は複数あり、それぞれに対応しています。
実機動画と、アプリの説明を求められた
バージョン1.0.1への通知では、Guideline 2.1として、審査を進めるための追加情報を求められました。内容は、最新OSの実機で撮影した操作動画、アプリの目的と対象読者、主な機能の操作手順、外部サービス、地域による違いなどです。アカウント機能や第三者コンテンツに関する項目も、該当する場合の説明を求める形で含まれていました。
冒頭の図1は、実機でアプリを開いて閲覧・検索する操作を、動画で伝える例です。
9月25日3時55分（日本時間）のXcode内のCodex履歴に、この通知を貼り付けた記録があります。Codexは、アプリの機能と操作手順を整理した英語の返信案を作成しました。
操作項目が多かったため、動画の撮影もCodexへ任せられないかと考えました。9月25日4時13分（日本時間）には、実機とPDFを指定し、起動から閲覧、検索、設定変更、Sandboxでの購入、アイコン変更まで、13項目を連続して撮影するよう依頼しています。
筆者のプロンプト（全文）
実機動画を撮影してください。
デバイス: iPhone 18 Pro 2026
ファイル: iCloud Drive/testdata/TestLightNovel.pdf実機動画で必ず映す内容
動画は編集で途中を省略せず、ホーム画面からアプリを起動するところから始めるのが安全です。
- アプリ起動
- ファイル選択画面からサンプルPDFを開く
- ページ送り
- 画面タップでツールバーとページスライダーを表示
- ページスライダーによる移動
- ピンチズーム
- PDF内テキスト検索
- 設定画面を開く
- 見開き、表紙、左右方向、高画質などの設定変更
- 「Support」を開き、3つの課金商品が表示されることを示す
- Sandbox環境で1商品を購入
- 購入成功後のアイコン変更と、ホーム画面上の変更結果
- PDFを閉じて、再び選択できることを示す
動画には個人情報、Apple ID、通知、私的なPDFを映さないようにしてください。
最初はCodex側で実機を認識できず、接続や実行先を確認するやり取りが続きました。実行先を選び直した後も、当時の端末操作ツールは対応対象をSimulatorとするエラーを返しています。同日4時26分には、Codexから次の案内がありました。
Codexの回答（抜粋）
選択は成功していますが、Xcodeの自動操作機能は物理デバイスをサポートしておらず、Device Hubの動画録画機能もSimulator限定です。物理デバイスでは、iPhone本体の「画面収録」を使用する必要があります。
これは当時の環境についての回答です。履歴では、ホーム画面へ戻り、iPhone本体で画面収録を開始して13項目を操作する手順へ切り替わっています。最終的には、筆者自身が端末を操作して動画を撮影しました。第7回で紹介した公開ページ用のApp Previewとは用途が異なり、ここでは審査で求められた実機操作動画を準備しています。同日15時03分には、審査への返信文を英語で4,000文字以内にまとめるよう依頼しています。
修正内容と確認手順を英文にまとめる
10月3日3時36分（日本時間）には、build 10での修正を審査担当者へ伝える英文を依頼しました。以下では、プロンプトに貼り付けたAppleの通知本文を省略し、通知の見出しと、指摘されたガイドラインの項目を示します。
筆者のプロンプト（通知本文は省略）
App Store Connectの以下のメッセージへの返答を考えてください。ビルド番号10で対応した内容を含めてください。
［Appleの審査通知：App Version — 1.0.3 for iOS（2026年10月1日）／本文省略］
通知で指摘されたガイドライン
- Guideline 2.3.2 - Performance - Accurate Metadata：Bronze／Silver／Goldのアプリ内購入のプロモーション画像に、価格の表記が含まれている。
- Guideline 3.1.1 - Business - Payments - In-App Purchase：消耗型の商品に、非消耗型として機能する内容が含まれている一方、購入を復元する仕組みがない。
Codexの回答（抜粋）
We have addressed both issues in version 1.0.4, build 10.
（中略）
- These purchases permanently unlock their corresponding supporter app icons. Therefore, we changed the products from consumable products to non-consumable products.
- Build 10 includes a “Restore Purchases” button.
- The app synchronizes purchases with the App Store and restores previously purchased supporter icons on devices using the same Apple Account.
返信案は、指摘ごとの変更内容に加え、復元ボタンまでの操作手順も説明する構成でした。
返信文は、添付ファイルの案内をURLに変更したり、添付ファイルやURLのタイトルを調整したりした場合はありますが、それ以外は作成された文章をそのまま使用しました。コードの修正だけでなく、変更内容を審査担当者に伝える英文の作成にもCodexを利用しました。
図2 審査の指摘を整理し、修正と確認手順を返信へまとめる流れ。作成した英文の使い方も含めて示しています。
契約と登録情報の手続きも並行して進めた
アプリの修正と審査への返信に加え、契約・銀行・税務情報の確認も必要でした。メールと会話履歴を読み返すと、これらの作業は初回審査より前から始まり、審査中にも続いていました。
住所の更新と、契約・税務フォームへの反映は別だった
8月29日には、有料アプリ契約（Paid Applications Agreement）の受諾通知が届いていました。メールには、Appleから支払いを受けるために連絡先・銀行・税務情報を登録する案内があります。
9月6日のCodex履歴には、「口座情報の更新が処理中になってから1週間経過している」という相談が残っています。同日には、税務フォームの Permanent residence address が古く、画面上で修正できないことも伝えていました。Codexからは、登録住所を確認し、Appleのサポートへ問い合わせるよう提案されました。
住所変更については、Appleの返信で経過を確認できます。9月10日に新住所を証明する書類を求められ、翌11日には、新しい住所でチーム情報を更新したと連絡がありました。
ただし、住所の更新だけでは確認は終わりませんでした。9月11日の返信には、App Store Connectの「ビジネス」で契約が最新か確認し、更新があれば条項に同意するよう案内がありました。また、Developerアカウントにはすぐ反映されても、Connectの契約への反映には2週間ほどかかる場合があると説明されています。提出済みの納税フォームには古い住所が残るものの、その表示は無視してよい、という個別の回答もありました。
住所変更の処理、契約への反映、提出済みフォームの表示は、同時に更新されるものではありませんでした。画面に古い住所があることだけで、変更申請そのものが未完了だと判断することはできません。
銀行情報と、税務フォームの不足表示を確認する
9月22日には、銀行情報の追加・編集についてFinance Supportが問い合わせを受け付けたメールも届いています。
税務フォームについては、Geminiにも相談していました。「App Store ConnectのW-8BEN送信の必要性」という会話では、U.S. Certificate of Foreign Status of Beneficial Owner の送信が必要かを尋ねた後、次のやり取りがあります。
筆者のプロンプト（全文・原文の表記のまま）
U.F. Form W-8BENのフォームを送信済みですが、さらに必要ですか？
Geminiの回答（抜粋）
すでにForm W-8BENを送信済みであれば、通常それ以上の追加の書類提出は不要です。
一方、「App Store Connectの税務フォーム記入方法」という別の会話では、筆者は「U.S. Form W-8BENを登録しましたが、U.S. Certificate of Foreign Status of Beneficial Ownerに税金情報が不足していますと表示されています」と伝えていました。W-8BENを登録しても、画面には別の項目の不足表示が残っていたことが分かります。
Geminiは反映待ちや入力漏れを候補に挙げましたが、回答中では U.S. Certificate… をW-8BENと同じものとして扱っていました。筆者が伝えた画面上の項目の違いを、十分に整理できていなかったように見えます。Appleの現行ヘルプでは、米国外の開発者には質問への回答に応じた税務フォームと、該当する証明を案内すると説明されています。生成AIの一般的な説明だけで、画面に残っている不足項目まで解決したと判断するべきではありませんでした。Appleの税務情報登録の説明
なお、今回確認した記録からは、各フォームの提出完了日や承認日までは確定できません。ここでは、当時の相談に残った不足表示と、それに対する回答を振り返っています。
審査中にも契約を確認し直した
10月14日には、有料アプリ契約を再び受諾した通知が届いていました。同日には、Apple Developer Program License Agreementに署名したという別の通知もあります。有料アプリ契約とProgramのライセンス契約は、分けて確認する必要がありました。
この時点は10月5日に「審査中」となった後です。ただし、受諾通知だけでは、契約の具体的な変更内容や、それまで未同意だった期間は分かりません。確認できるのは、審査を待つ間にも契約を確認し、受諾する作業があったことです。
図3 住所変更の完了、銀行情報の問い合わせ受付、税務フォームの不足表示、契約の再受諾を分けて整理しました。
これらは、アプリの修正や審査への返信とは別に確認を進めた手続きです。Appleから審査長期化との関係を説明された記録は確認できていません。そこで、契約や登録の状態に加え、審査へ提出したアプリと、その後に開発を進めた版も分けて振り返ります。
提出した版と、開発中の版を分ける
10月20日時点では、筆者はブランチを二つに分けて作業していました。main は、App Store Connectへ登録を申請した版のアプリコードを維持し、必要な変更を最小限にとどめるためのブランチです。一方、testing は、公開後のバージョンアップに向けた機能追加や改善を進める開発用のブランチでした。
Git履歴でも、10月3日の変更以降、main ではREADME、公開ページ、サンプルPDFなどの更新が続く一方、アプリ本体の機能追加は testing 側で進んでいました。10月6日の診断、8日のサンプルダウンロード、9日の右綴じ修正、14日のコード分割、15日の目次追加、17日のCI整備などは、こちらの開発履歴です。
例えば、公開ページに置いたサンプルPDFを main で差し替えることと、アプリ内からダウンロードする機能を testing に追加することは別の変更です。10月8日に追加した機能が、10月3日の再提出版にも含まれていたとは扱えません。また、どちらのブランチへの変更も、提出済みのバイナリへ自動的に反映されるわけではありません。
ローカルには、1.0.3／build 5と、1.0.4／build 10のアーカイブが残っていました。10月1日の通知で審査対象が1.0.3（build 7）だったこと、10月3日の返信案が1.0.4（build 10）への対応を説明していたことは確認できました。ただし、各アーカイブと提出履歴の対応が、すべて確定したわけではありません。ブランチの使い分けだけで、送信したファイルの内容まで証明できるわけではないためです。
この連載で取り上げた開発履歴の基準は、10月20日に確認した testing の 91f0853 です。次回扱う10月23日の追加点検とビルド11の修正は、その後の作業として区別します。
READMEにもバージョン履歴はありますが、その「リリース」表記だけでApp Storeの配布開始を判断することはできません。公開状況は審査履歴と分けて扱います。
図4 main で申請版のアプリコードを維持し、testing で追加開発を進める間も、審査と契約手続きは並行していました。図中の「回答待ち」は10月20日時点の記録です。10月27日の返信は、続く追記で区別して紹介します。
追記：10月27日に審査継続の回答が届いた
ここからは、10月20日時点の記録より後の経過です。10月27日0時33分（日本時間）、10月14日に送った問い合わせに対して、App Review Supportから返信が届きました。内容は、審査は現在も進行中で追加の時間が必要であり、状況が更新された場合や追加情報が必要になった場合には連絡する、というものでした。
これは却下通知や、新たな修正・追加情報の提出要求ではありません。遅延の具体的な理由や完了予定日は示されておらず、契約・登録情報の手続きやアプリの実装が長期化の原因だという説明もありませんでした。問い合わせへの回答は得られましたが、審査結果は引き続き待つことになりました。
返信した内容と、提出した版を記録する
Codexは、指摘への対応を英語で伝える作業でも役立ちました。一方、契約や登録情報では、生成AIの回答と実際の画面表示に食い違いもありました。住所更新の完了通知、銀行情報の問い合わせ受付、税務フォームの不足表示、契約の受諾通知を、それぞれの状態として確認する必要がありました。
10月20日時点では、過去の指摘に対応して再提出したものの、審査が長引いている理由は分かっていませんでした。10月27日の回答でも、具体的な理由は示されていません。次回は、10月23日の追加点検に話を戻し、相談の範囲を審査画面から提出版の実装と配布ファイルへ広げた経緯を取り上げます。