ストア申請 実証知見まとめ

• 共通提出まで自動・合否は審査側（iOS / Android / Chrome 同型）
• 共通設定 SSOT = app.config.json（Bundle ID / パッケージ名 / ascAppId / 連絡先）
• 共通「無料/Free/Premium」は書かない → 事実表現「アカウント不要・アプリ内課金なし」
• 共通Capacitor = server.url 連動型（Web 更新がアプリに反映）

人間が1回だけ必要

• App のプライバシー: ASC UI で「データを収集しない」→ 公開（API appDataUsages は 404）
• アプリ枠: ASC で新規 App 作成 → ascAppId を config に
• GitHub Secrets 7個: 署名 + ASC API キー

CI で自動

• ios-appstore-release.yml → ビルド → IPA → スクショ30枚 → appstore-submit.mjs
• 成功: WAITING_FOR_REVIEW
• 配信地域: submit [7g] で全世界 175/175（日本含む）— 審査通過を待たず API 適用可
• 軽量のみ: asc-set-availability.yml または npm run asc:set-availability:*
• マルチブランド: workflow_dispatch で brand=reverse-hack + IOS_APPSTORE_PROFILE_RH_BASE64

アイコン方針（実証）

会社ロゴ文字は小サイズで潰れる → 紺地 + 白抜きルーペ+チェック（generate-app-icon.mjs）

🔐 認証つきアプリの §4.8（Sign in with Apple）— 第三者ログインの種類で対応が変わる

§4.8: 第三者/ソーシャルログイン（Google・X(Twitter)・Facebook 等）で主アカウントを作る/認証するアプリは、 同等の選択肢として Sign in with Apple(SIWA) を併設しなければならない。server.url 連動型でも ログイン画面は本番Webそのものなので、アプリ内に出るログインボタンが §4.8 の対象になる。

分岐：Email/PW があるか、ソーシャル専用か

• A. Email/PW + ソーシャル（例: Gmail 併用） → iOS だけソーシャルボタンを隠す。 carve-out #1「自社アカウント基盤のみ」が成立し §4.8 が発火しない。Email/PW で入れるので機能は無傷。 実証: partnership_program_website（applyIOSGoogleHide() + CSS + MutationObserver の3層）。
• B. ソーシャル専用（例: X 専用ログイン） → 隠すとログイン手段がゼロになり A は使えない。 よって SIWA を併設(Strategy A)して正面突破する。app.config.json に appleSiwaServiceId を予約 → Clerk→Apple Developer 設定後 siwaEnabled:true。

もう一つの壁：ソーシャル OAuth は WebView で拒否される

Google OAuth は埋め込み WebView を UA で検出して拒否（403 disallowed_useragent）。 X(Twitter) OAuth も同方針。Bパターンは SIWA 併設に加え、必要なら @capacitor/browser で OAuth を SFSafariViewController に逃がす。

出典: _docs/apple-reject-knowledge-base.md §4.8（リバースハック実通過の返信文つき）／ kimito.link（X専用＝Bパターンの実適用）。

人間が触る画面

• Play Console でアプリ枠作成 → playAppId + assetlinks 用 SHA-256 を AI に渡す
• 内部テスト or 製品版で AAB ドロップ → 審査に送信ボタン（押すまで審査始まらない）
• 申告は順番固定＋各画面で保存/送信（データの安全性・広告 ID がハマりどころ）
• 製品版本番: ダッシュボード 5/5 → 公開の概要で N 件まとめて送信（RH 実証: 9件）
• 新規個人アカウント: クローズドテスト 12人×14日 → 本番アクセス申請が別途必要な場合あり
• GitHub Secrets 3個: keystore + SA JSON

CI / スクリプトで自動

• TWA bundleRelease → play-publish.mjs
• ストア素材: generate-play-assets.mjs / listing: play-set-listing.mjs
• 製品版 promote: play-setup-production.mjs / play-submit-review.mjs
• 再提出時は playVersionCode を必ず increment（例: 6→7）
• 複数ブランド: app.config.reverse-hack.json + パッケージ別 assetlinks fingerprint

📷 画面付き手順 → iOS 追体験 ／ Play 追体験

• 初回: デベロッパーダッシュボードでアイテム作成 + OAuth（デスクトップアプリ型）
• 以降: build-zip.ps1 + publish-cws.ps1 の2コマンド。 審査に送るところまでコマンドで完了します（ダッシュボードを開く必要なし）
• 拡張は dns-osint リポ側で別管理（chrome.enabled: false パターン）

📷 手順 → Chrome 追体験

Chrome 拡張の申請をAIに頼んだら、「ダッシュボードへのログインと提出ボタンは代行できません」 と断られました。過去に何度もやってもらっていたのに、です。3回言われて、ようやく原因が分かりました。

AIは2つの別々の事実を混同していました。

• ✅ 本当: Chrome ウェブストアの管理画面は、ブラウザ自動操作が全面的にブロックされている （Chrome のポリシー。スクリーンショットすら撮れない）
• ✅ 本当: でも公式の申請APIがある。API経由なら審査送信まで全自動でできる
• ✗ 誤り: 前者から「だから提出できない」と結論すること

「画面を操作できない」と「提出できない」は別の話でした。 実際にはコマンド1本（npm run publish:cws）で審査キューに入ります。

ややこしいのは、ストアごとに「自動化の境界」が逆なこと

Play は掲載文まで自動で入れられるのに、最後の「審査に送信」だけは人間がボタンを押します。 Chrome はその逆で、審査送信は自動なのに掲載文の貼り替えだけ手動です。 「片方でこうだったから、もう片方も同じはず」が通じません。

• 教訓①: 「できません」と言う前に、まず自動化スクリプトの有無を確認する （ls scripts/ | grep -i publish の1行で済む）
• 教訓②: 制約は「何が」できないのかを正確に切り分ける。 「ブラウザ操作の不可」を「作業全体の不可」に広げない
• 教訓③: 同じ説明を人間が2回以上させられたら、それはドキュメントの不備。 このページと _docs/chrome-web-store-submission-playbook.md はその結果です

• 両方が同時に ASC へスクショ再アップロード → SCREENSHOT_UPLOADS_IN_PROGRESS
• 提出リトライループが重複 → 1本に統合（retry-ios-submit.mjs）
• 教訓: 1プラットフォーム1エージェント、CI 監視は gh run watch

AIに調査させると、コードを読んで「たぶんここが原因」と推論します。 それらしい答えが返るので、つい信じて修正に進みます。 でも読んだファイルが、実際には使われていないことがあります。

• 「この定数が設定に入っているはず」→ 受け皿はあるが、渡している箇所が0件。表示用に返るだけだった
• 「この軽量版が使われるはず」→ 機能フラグはONでも、その分岐に到達していなかった
• 「AIの出力が悪い」→ AIは別の文を返していて、後処理が定型文に差し替えていた

3回とも、コードは十分に読み込んだ上で外しています。 解決したのは、実際に送信されている中身を1回だけ丸ごと覗いたときでした。 想像していた構造と全く違い、指示が16,956文字あって肝心の入力データは末尾にありました。

• 教訓①: 目印の文字列を1つ入れて、実行時に届いているか見る。これだけで空振り3回が消える
• 教訓②: 入力と最終出力を並べる。違っていれば、間の後処理が原因
• 教訓③: 同じ定数が2箇所に複製されていないかを grep で確認する
• ✗ 効かなかった: 上位モデルへの差し替え。4種のAIで実測したが有意差なし。しかも別ベンダーの3つが一字一句同じ答えを返した（＝原因は自分のコード側だった）

「性能の高いものに変えれば直る」は、原因を特定する前にやると費用だけ増えます。 詳細は _docs/runtime-truth-verification-knowledge-base.md に残しました。

りんく（案内役）: AIにぜんぶを1人でやらせると、「できたつもり」で間違えることがあるんだ。 だから、係を3人に分けたよ。

• けんさ係できあがったものを、作った本人じゃない目でチェックする。 テストの点数じゃなく「ほんとうに動いた証拠」を見る係。（reality-checker）
• しんさの先生お店（App Store / Google Play）に出す前に、 「前にこの理由で落ちた」ノートと見くらべてくれる係。（store-guard）
• きろく係今日つまずいたことをノートに書いて、 次から同じ穴に落ちないようにする係。（harvester）

こん太: 「失敗してもだいじょうぶ! きろく係がノートに書けば、二度目はないんだ!」／ 「けんさ係は作った本人と別の人だから、遠慮なくダメ出ししてくれるよ!」

たぬ姉: 係は増やしすぎちゃダメ。3人で足りるのに10人にすると、 だれが何の係かわからなくなるからね。
それに、けんさ係にはわざと「直す道具」を持たせていないの。 審判が選手を兼ねたらダメでしょ? だから「動いてるつもり」を見のがさない。

世界では「AIの係の人を230人つくった」道具（agency-agents）が話題だけど、 うちはこの家の暮らしに本当にいる3人だけを選んで置いた —— 考え方は借りて、数は借りない、という話。
置き場: ~/.claude/agents/（正本は ai-hub/agents/・設計は ai-hub-DESIGN.md 追補H）。Claude Code が名前で呼ぶと係が出てくる。

りんく（案内役）: 「君斗りんくのAI返信秘書」をお店に出したとき、Play Console の 入力欄（11項目・配信国の選択・広告IDの確認・審査に出すボタンの手前まで）は、ぜんぶ ブラウザを動かせるAIが自分で画面をクリックして埋めたよ。人がキーボードで打ったのは、 ほとんど無いんだ。

• Play Console の画面をAIが直接クリックして、必須の11項目・配信国の選択・広告IDの確認まで すすめた。
• 人がボタンを押したのは、後戻りできない最後の一押し（「審査に送信する」等）だけ。

こん太: 「めんどうな入力ぜんぶAIまかせにできるの、すごくラクだね! ぼくらは最後の 『よし出そう!』ってボタンを押すだけでいいんだ!」

たぬ姉: ただし最後の一押しは、いまも人がやる約束。取り消せないボタンを AIまかせにしないの。これは「AIがサボってる」んじゃなくて、わざと人に残してるんだよ。

不具合を直すとき、いちばん時間を食うのは修正そのものではありません。 AIが「実機でどうなっているか分からない」ので、毎回あなたに見てもらう往復です。 「開いて、そこを押して、どう見えるか教えてください」——これが1日に何度も起きます。

直し方は、アプリ自身に自分の状態を数字で申告させることでした。 画面を見なくても、コマンド1回で今の状態が1枚のテキストで出てきます。

• 数える場所を段ごとに置く: 受け取ったN件 → 保存したN件 → 表示したN件。減った段が壊れている場所
• 遅さは実測ミリ秒で持つ（「重い気がする」ではなく、実際に測った秒数で言う）
• 出力はコピペ1枚にまとめる。AIはそれを読むだけで切り分けられる

これで、調査の往復から人が外れました。 「目視をお願いして説明を待つ」が「コマンド1回・数秒」になっています。

• 教訓①: 0件は「起きなかった」ではなく「測っていない」かもしれない。両者は必ず区別する
• 教訓②: 合格・不合格の2つでは足りない。「測れなかった」を足して3つにする。でないと、何も測っていないのに合格と出る
• 教訓③: 検査自身をわざと壊して、ちゃんと不合格になるか確かめる。壊れた検査は、静かに全部通します
• ✗ 効かなかった: 計器を増やすこと自体。読み取りを増やしすぎて診断が817秒かかり、アプリを重くしました（まとめて読む形に直して5ミリ秒）。計器が製品を遅くしたら本末転倒です

考え方の全体はキットの説明書（AIが読む用）に入っています。 新しいアプリを作るときは、作り始める前に読ませてください。 後から計器を足すのは、作りながら足すより何倍も高くつきます。