1. はじめに

Google OAuth認証を利用し、Googleカレンダーと連携するiOSアプリをApp Storeの審査（App Review）に提出した際、Google側のセキュリティ仕様に起因するサインイン不可を理由に、ガイドライン Guideline 2.1(a) - Information Needed でリジェクト（却下）される事例が発生しました。

デモアカウント側であらかじめ2段階認証を無効化（OFF）に設定していたにもかかわらず、米国の審査拠点など「普段と異なる環境（IP・デバイス）」からのアクセスであるため、GoogleのセキュリティAIにより不審なアクティビティと判定され、強制的に本人確認画面（Verify it's you）が発動してしまうのが原因です。

日本と海外の審査拠点では時差があるため、審査員がログインを試みるタイミングに合わせて、手元の開発端末でリアルタイムにプッシュ通知を承認（「はい、私です」のタップ）することは現実的ではありません。

本記事では、アプリのソースコードを一切修正することなく、Googleアカウント側のセキュリティ機能をあえて有効化し、「2段階認証のバックアップコード」を審査員に提示することで、このログインブロックを確実に自力突破してもらったワークアラウンドについて記録します。

2. 前提（アプリの仕様とOAuth必須の理由）

今回審査に提出したアプリは、Googleカレンダーのイベント（予定）データを同期・活用する、Googleカレンダーを日記帳へ変身させるアプリ「G-Journal」です。

G-Journal（App Storeリンク）: https://apps.apple.com/jp/app/id1604070612

※Android版もあります。

本アプリは、以下の仕様を前提として開発されています。

ユーザーのGoogleアカウントから、Googleカレンダーと紐付けをする
GoogleカレンダーにG-Jounral専用のカレンダーを作成し、そこにログ（日記）を作成・編集・削除できるようにする

アプリの全コア機能がGoogleカレンダーのデータ構造およびAPI連携に直接依存しているため、認証をスキップしたダミーのローカル環境や、中身が空のモック画面では、アプリ本来の挙動や機能性をレビュー担当者が検証することができません。

したがって、審査を正しく進めてもらうためには、本物のGoogleアカウントを使用したOAuth認証フローを通過し、実際のAPI連携動作を確認してもらうことが不可欠な要件となっていました。

3. 発生した問題

Appleの審査員に提供するデモ用のGoogleアカウント（通常の @gmail.com アカウント）は、審査がスムーズに進むよう、事前に「2段階認証プロセス」をあえて無効化（OFF）に設定していました。

しかし、審査員が米国の審査拠点からログインを試みた際、Googleのセキュリティシステムにより「普段と異なる環境（IPアドレス・デバイス・地域）からの不審なアクセス」と判定され、ログインが強制的にブロックされました。

Appleのレビュー担当者から不合格通知と共に送られてきたスクリーンショットには、通常のID・パスワード入力画面の後に、リアルタイムの端末承認を求める 「Verify it's you（本人確認）」 の画面が表示されていました。

実際にAppleから送られてきたスクリーンショット

日本と海外の審査拠点では大きな時差があるため、審査員がいつログインを試みるかを予測することはできません。そのため、手元の開発端末に届くプッシュ通知をタイミングよくリアルタイムに承認して対応することは、運用上不可能という限界に直面しました。

4. 解決策：2段階認証を有効化し、バックアップコードを発行する

GoogleのセキュリティAIによる自動ブロックを完全に無効化する手段は提供されていないため、アプローチを逆転させました。セキュリティを意図的に「下げる（OFFにする）」のではなく、あえて「上げる（2段階認証をONにする）」ことで、認証の制御権をこちら側で確保する手法をとりました。

具体的な手順は以下の通りです。

2段階認証の有効化: デモ用Googleアカウントのセキュリティ設定を開き、「2段階認証プロセス」を有効化します
バックアップコードの発行: 2段階認証のメニュー内にある「バックアップコード」を選択し、1回限りの使い捨てログインコード（8桁の数字×10件のリスト）を新規に発行・保存します

このバックアップコードは、手元に認証端末（スマホ）がない場合でも、コードを入力するだけで2段階認証をパスできる仕組みです。これを審査員に事前提示することで、時差に関係なく、審査員のタイミングで自力ログインしてもらうことが可能になります。

5. App Store Connect での提出・対応方法

審査員がGoogleのログイン画面でバックアップコードを使用してもらえるよう、App Reviewに以下のように返信し、再審査の願いを出しました。

実際に送信した英文（テンプレート）

[Message for the reviewer]
Thank you for providing the screenshot. Since our teams are in different time zones, it is very difficult to coordinate the timing for the real-time push notification ("Verify it's you") sent to my device.

To bypass this and ensure a smooth login for your review, I have newly configured 2-Step Verification and generated single-use backup codes. Please use them by following the steps below.

How to log in:
1. Enter the credentials below.
2. If the "Verify it's you" screen appears, click "Try another way" at the bottom left.
3. Select "Enter one of your 8-digit backup codes".
4. Enter any single code from the list below to complete sign-in.

Credentials:
- ID: [demo mail address]
- Pass: [demo passowrd]

Backup Codes (Single-use):
- [0000 0000]
- [0000 0000]
- [0000 0000]
- [0000 0000]
- [0000 0000]

6. 運用上の注意点

このワークアラウンドを運用するにあたり、以下の技術的仕様に注意する必要があります。

コードは1回限りの使い捨て（ワンタイム）: 各バックアップコードは、1度ログインに成功するとそのコードのみ即座に失効します。審査員が複数回テストを行うケースや、入力をミスする可能性を考慮し、コードは1つではなく、いくつかリストアップして提示するのが安全だと思います。なお、コード自体に有効期限（何日以内に使わなければ失効する等）はないようです。
再発行による古いコードの全滅: Googleアカウントの設定画面で「新しいコードを取得（再発行）」ボタンを誤ってクリックしてしまうと、それまでに発行されていた古いコード（審査員に提示したものを含む）は、未使用であってもすべて即座に無効化されます。審査に提出した後は、ステータスが「承認」に変わるまで、絶対にGoogle側のセキュリティ設定を変更しないよう注意が必要です。

7. まとめ

通常の @gmail.com アカウントをデモ用に提供する以上、Google側のセキュリティアルゴリズムを開発者側で完全にコントロールすることはできません。

アプリのソースコードに手を加えて「審査専用のダミーログインモード」をわざわざ実装する時間的猶予がない場合、今回ご紹介した「あえて2段階認証をONにしてバックアップコードを渡す」というアプローチは、最も低コストかつ確実性の高い回避策となります。

同じエラーとリジェクトによって、時差に悩まされる開発者の参考になれば幸いです。