GitHubのアカウント名を変えました。よかれと思ってやりました。

その結果、リリース済みアプリ3本のプライバシーポリシーと利用規約が全部404になり、Google Playの審査に出せなくなりました。

しかも気づいたのは、壊してから数日後です。その間、クローズドテスト中のユーザーは全員404を踏んでいました。

なぜアカウント名を変えたのか

コミット履歴に実メールアドレスが残っていたからです。

個人開発をしていると、git config を適当に設定したまま最初のコミットを打ってしまい、本名やプライベートのメールアドレスがログに刻まれます。リポジトリを公開した時点で、それは誰でも読める状態になります。

これを消すためにアカウント名を変更しました。この判断自体は、いまでも正しかったと思っています。 個人情報がコミットログに残り続けるほうが、はるかに大きいリスクです。

問題は変更したことではなく、変更が何を壊すかを一度も確認しなかったことでした。

何が壊れたのか

GitHub Pagesのドメインは、アカウント名に紐づいています。

https://<アカウント名>.github.io/<リポジトリ名>/privacy.html

アカウント名を変えた瞬間、このアカウントで公開していた全ページのURLが変わります。 旧URLは404になります。リダイレクトは張られません。リポジトリ名は変えていないのに、ドメイン側が丸ごと引っ越すからです。

そして自分は、そのGitHub Pagesにプライバシーポリシーと利用規約を置いていました。3本のアプリ、全部です。

被害は3層に広がっていました。

1層目：アプリ本体が壊れた

設定画面の「プライバシーポリシー」「利用規約」リンクが、旧URLをDartのコードにハードコードしていました。

// lib/constants/legal.dart
const kPrivacyPolicyUrl = 'https://<旧アカウント名>.github.io/kiroku/privacy.html';
const kTermsUrl         = 'https://<旧アカウント名>.github.io/kiroku/terms.html';

これはビルドが通ります。テストも通ります。静的解析にも何も出ません。 ただの文字列なので当然です。壊れていることを教えてくれる仕組みが、どこにも存在しませんでした。

クローズドテスト中の全ユーザーと、将来アプリを触る審査員が、タップした瞬間に404を踏む状態でした。

2層目：Play Consoleが壊れた

ストアに登録したプライバシーポリシーURLも旧URLのままでした。こちらはコードではなく管理画面の設定値なので、リポジトリを全文検索しても引っかかりません。

3層目：データセーフティ申告が壊れた

Google Playには「データ削除リクエスト」の受付ページURLを申告する項目があります。これも同じドメインに置いていました。

Googleはこの申告URLが実際に到達できるかを審査で確認します。結果、審査に提出できなくなりました。 提出ボタンを押しても弾かれる状態です。

なぜ数日も気づけなかったのか

改名した作業と、アプリを運用している作業が、完全に別々に進んでいたからです。

自分はAIエージェントに役割を割り振って開発しています。GitHubの改名を実行したのは「あるアプリの都合で動いていたセッション」でした。そのセッションは、同じGitHub Pagesを他の2本のアプリも参照していることを知りませんでした。

知らないので、影響範囲を確認しようがない。指示した自分も、他のアプリが道連れになるとは考えていませんでした。

実際に発覚したのは、別のアプリで同じ症状を直している最中でした。「これ、他のアプリも同じ構成では？」と横断で検索をかけて、全滅していることがわかりました。

正直、AIに任せていたから起きた事故ではないと思っています。複数のアプリを個人で持っていて、法務系のページを1つのドメインにまとめていれば、誰がやっても同じ地雷を踏みます。 むしろ人間ひとりの頭の中だけで管理していたら、発見はもっと遅れていたかもしれません。

直したあとに変えた運用

同じことを繰り返さないために、3つ変えました。

アカウント名・ドメイン・ホスティング先を変更する前に、そのドメインを参照している全プロジェクトを検索する。 リポジトリ横断で grep を1回打つだけです。1分もかかりません。今回はそれをやらなかっただけでした。

法務系のURLは1ファイルに集約する。 legal.dart のように定数を1箇所にまとめておけば、差し替えは1ファイルで済みます。画面ごとに直書きしていると必ず漏れます。

リリース前チェックリストに「規約類のURLを実際に開く」を入れる。 自動テストでは検知できない領域なので、目視でいいから必ず踏む。これが最後の砦になります。

教訓：外部URLは、壊れたことを教えてくれない依存関係

コードの依存関係には package.json があり、壊れればビルドが落ちます。型が合わなければコンパイラが止めます。壊れたことを機械が教えてくれます。

アプリ内にハードコードされた外部URLには、それが一切ありません。ビルドは通る。テストも通る。ストアの審査に出すまで、あるいはユーザーがタップするまで、誰も気づけません。

そして今回いちばん厄介だったのは、変更した本人が「壊した」という自覚を持てなかったことです。GitHubの設定画面でアカウント名を変えただけ。アプリのコードには一行も触っていない。それでアプリが壊れる、という因果が直感に反しています。

プライバシーのためにアカウント名を変えるのは、これからも正しい判断だと思います。ただしやる前に、壊れる先を数えてからやる。 それだけの話でした。

この事故は、AIエージェントを「社員」として複数走らせている体制で起きました。その体制で何が効いて何が無駄だったかはこちらの記事にまとめています。

Google Play関連ではもう1つ、個人開発者を確実に殴ってくる「クローズドテスト12人×14日」の要件があります。これは別記事で書く予定です。