Firebase Authの導入は「AI」で爆速スタート
最近は、新しく対応した「ウ-321 / ウ-341 納品書」の検証や、サブスクリプション版に向けた「ユーザー登録機能」の開発で大忙しの日々を送っています。
サブスクリプション機能を安全に運営するため、ユーザー認証基盤としてGoogleの「Firebase Authentication（Firebase Auth）」を採用することにしました。 セキュリティやパスワード管理を自前で実装するのはリスクが伴うため、実績のある信頼された仕組みに頼るのがベストプラクティスだからです。 近年トレンドとなっている「生成AIを活用した開発（バイブコーディング）」を試してみたところ 、Spring Boot（Java）用の設定クラスやトークン検証のロジック、フィルタ処理のコードなどをAIがあっという間に生成してくれました。 ローカル環境でテスト接続を確認すると、驚くほど簡単にログイン処理が動作。 「これはすぐにリリースできるぞ！」と、この時は確信していました。
サーバーへデプロイした瞬間に沈黙するシステム
ところが、いざ開発したコードをGCPのステージング環境（Cloud Run）にデプロイした瞬間、システムが全く動かなくなってしまいました。 画面を操作しても、ログイン処理のところでエラーが発生し、完了画面の前に通信が途絶えてしまう状態です。 「ローカルはあんなに完璧に動いていたのに、なぜ……？」 そこからGCPのCloud Loggingと睨めっこしながら、原因追求の長い旅が始まりました。
丸1日かけて気づいた「設定ファイル」の罠
原因を突き止めるまでに、実に丸1日を費やすことになりました。 結論から言うと、原因はJavaプログラムが参照する 「Firebase Admin SDKの設定ファイル（サービスアカウントの秘密鍵情報）」が、デプロイ先の環境に合っていなかったこと でした。
- ローカル環境： ローカルPC上では、エミュレータ用のダミー認証情報や、gcloud auth application-default loginコマンドで取得したローカルPC用のデフォルト資格情報（ADC）を使って接続していました。
- サーバー環境（GCP）： しかし、GCPの実機（Cloud Runなど）にデプロイすると、実際のステージング用プロジェクトのサービスアカウント権限や、環境変数 GOOGLE_APPLICATION_CREDENTIALS に紐づく「本番用の設定ファイル」を厳密に指し示す必要があります。
Spring Bootのプロファイル設定（application-dev.properties や application-prod.properties）を使って、ローカルとGCPサーバー側で読み込む設定ファイルを動的に切り替えるようにインフラ側の設定を調整したところ、今までのエラーが嘘のように、サーバー上でもスムーズに認証機能が動作するようになりました。
AIを使っても「基本」を握るのは人間である
今回のトラブルを通じて、非常に大切な教訓を得ました。 AIは「プログラムのコード（Javaなど）」を驚くほどきれいに書いてくれます。しかし、そのコードが「ローカルと実機サーバーという、異なるインフラ環境の境界線」を越えるときにどう振る舞うかというインフラの設計思想までは、完璧にフォローしてくれません 。
- サービスアカウントの権限管理（IAM）はどうなっているか。
- 環境ごとに読み込むべきプロファイルや環境変数が正しく適用されているか。
classファイルの設定や環境変数、セキュリティ周りの「基本部分」については、AIに任せきりにするのではなく、私たち人間（エンジニア）がしっかりと理解し、気を配らなければならないと痛感しました。
