Wordressサイトの投稿アプリですが、Googleからの最新回答（リジェクト）により、アプリ停止は一旦見送られたものの、再度審査に出すと「また審査員がログインできない」という結局同じエラーになりました。
Googleのサポートの方には何度も下記のようなメールを送りました
アプリが、前回と同じ「Failed host lookup」というDNSエラーで再び却下されました
（添付のスクリーンショット 参照）。
これは認証情報の問題ではなく、同じDNS解決の失敗です。
以下の対策を実施したにもかかわらず：
- CloudFlare IPv6（AAAAレコードは全世界で有効）
- test-concertサブドメイン専用のDNS Aレコード
- アプリコード内でのIPv4 DNS事前解決
- 自動再試行メカニズム
この問題はGoogleの審査環境でのみ発生しています。
審査チームの皆様には、以下の対応をお願いできますでしょうか：
- 別のネットワークまたはデバイスからログインを試みてください
- 審査担当者がブラウザで https://sampleXX.net にアクセスできるか確認してください
- 審査環境におけるDNS/ネットワークの制限事項があれば共有してください
アプリはテストしたすべてのデバイスで動作し、Appleの審査も通過しています。
また、Googleのサポートの方に下記の質問をしました。
でも返ってきた答えはまた技術的な問題には全く触れていない定型文でした。
ご提出いただいた異議申し立てを審査した結果、お客様のアプリは、依然としてGoogle Playポリシーに違反していることが判明しました。
Googleの審査は、Appleに比べて高度に自動化されており、人間が介入する場合も「マニュアル（手順書）」に縛られているように思います。
担当者の権限不足: 窓口のサポート担当者は、審査環境のネットワーク構成（DNSやプロキシの設定）を詳細に把握しているエンジニアではありません。
定型文の裏側: 彼らの仕事は「ガイドラインに合致しているか」を判定することであり、「なぜ他社（Apple）で通るのか」という比較論は、彼らの業務スコープ（評価対象）から外れてしまっています。
審査員の手元で「Failed host lookup」が出ている以上、彼らにとってはそれが「真実」なのだと、
ようやく諦める気持ちが固まりました。
審査担当者が絶対にログインできるモードを作ることを決心
「審査担当者がかならずログインできるようにする！」それが私に唯一残された選択肢でした。
アプリを自社のサーバーに接続させる代わりに、審査のためにサーバー接続を一切必要としないデモ／オフラインモードを作成する。
そうすれば、審査担当者は外部サーバーに接続することなく、アプリの機能を確認できる。
アプリがテスト用認証情報でのログインを検知した場合、外部サーバーへの接続を試みる代わりに、あらかじめ読み込まれたデモデータを表示するようにします。
これなら直面しているDNSの問題を完全に回避できる！
デモモード実装
ネットワークエラーの強制回避:
審査員がログインボタンを押した際に、外部サーバーへの名前解決（DNSルックアップ）を行わず、アプリ内部のダミーデータやローカル処理で「ログイン成功」の状態へ遷移させることで、あの忌々しい Failed host lookup を物理的に発生させないようにします。
「機能していること」の証明:
審査の最大の壁は「中身が見られないこと」でした。デモモードで主要な画面やUIが動いている様子を見せられれば、Google側も「アプリは完成している」と判断し、承認（Approved）につながる可能性が飛躍的に高まります。
全部の機能が使えるのではないのですが、アプリの機能（イベント一覧、作成、編集、削除）をすべて見せられるデモモードを実装しました。
条件をつけ、審査員用のID以外は通常ユーザーは自分のWordPress URLで接続できるようにしました。
ビルドして再提出
今は審査結果を待つだけの、最も落ち着かない時間です。
しかし、これまでの経緯を振り返れば、下記のことをやりました。
- サーバーの海外制限解除とWAFオフ
- 自動再試行メカニズム
- FlutterでのIPv4優先ルックアップの実装
- Cloudflare導入によるIPv6（AAAAレコード）対応
- 論理的な証拠画像と動画による異議申し立て
- そして今回の、通信環境に左右されないデモモードの実装
小さな私がやれることはすべてやりました。
良い知らせを待ちたいと思います。
