プロと実践！ ゼロから始めるバイブコーディング
ついにアプリをクラウドへ！ AIに丸投げでステージングデプロイしてみた ～「ローカル」「ステージング」「本番」の違いを知る
［第9回］「作っている」から「公開する」への下準備、次回はいよいよ最終回
2026年6月19日 09:00
「非エンジニアでもアプリを作りたい！」という思いから、生成AIを活用して自作アプリの開発（バイブコーディング）に挑戦するが、「公開の壁」に立ち尽くしてしまう筆者。
そこで、GMOインターネットグループの現役エンジニア、石丸智輝氏に教えを仰いだ。Google AI Studioでフロントエンドを作り込み、アプリの名前を「AiLA」に決定。開発の場をClaude Codeに移し、数々のトラブルを乗り越えながら、ローカル環境で動くウイスキーアプリをいったん仕上げ、AIによる公開前レビューで足りない機能や危ないポイントを洗い出した。
これは、素人とプロの二人三脚による、泥臭くもリアルな開発ドキュメンタリーである……
今回は、いよいよ自分のPCの中だけで動いていたアプリを、外から見える場所に出していく。いわゆる「ステージング環境へのデプロイ」だ。「作っている」から「公開する」へ、いちばん大きく踏み出す回になる。
「ローカル」「ステージング」「本番」の違いを押さえる
まずは作業環境のおさらいから。
これまで筆者がアプリを動かしてきたのは、自分のPC上の「ローカル環境」だ。これに対して、実際にユーザーが使う「本番環境」は、動く場所からして違う。
「本番環境といまの開発環境の大きな違いは、パソコン上で動作するのか、Googleのサーバー上で動くのか、です。バックエンドの仕組みも、いまはエミュレーターを使っているものを、実際のFirebaseに変えていきます。もうひとつ重要なのがAPIキーの管理です。現在はローカルのパソコン上にあるものをそのまま読み込んでいますが、サーバー上のセキュアな管理方法に移して、アプリがそこから読み取る仕組みが必要になります」（石丸氏）
ローカルと本番には、これだけの差分がある。そこをいきなり本番でぶっつけにすると事故が起きやすい。
そこで、本番とほぼ同じ構成のテスト環境を間に挟む。それが「ステージング環境」だ。ローカルと本番のちょうど間にあるもの、とイメージするとわかりやすい。
「本番環境と同じ構成のテスト環境、というイメージですね」（石丸氏）
今回はコードをガリガリ書くというより、Firebaseの設定画面をいじったり、ローカルのソースコードをステージングへ持っていったり、という地味な作業が多くなるとのこと。ただし、その地味な作業の中でも、設定ファイルの作成などはAIに任せられる。
なお、データベースを持たないシンプルなアプリなら、ここまでの手順はほとんど不要で、簡単にデプロイできるらしい。今回のようにデータベースや認証を持つアプリだからこそ、手間がかかっているのだ。
Firebaseでデータベースとストレージを用意する
下準備として、Firebaseの設定をチェックする。
最初のポイントは料金プランだ。今回はAPIキーをセキュアに管理するために、後述する「Cloud Functions」というサービスを使う。これは無料の「Sparkプラン」では使えず、従量課金の「Blazeプラン」に切り替える必要がある。
従量課金と聞くと、たしかに身構えるが、使った分だけ請求される仕組みなので、Google Cloudの設定で予算アラートを設定しておけば、設定金額に達したときにメールが送られてくるので、使い過ぎに気が付くことができる。
次に、Firebaseの設定画面、いわゆる「コンソール」で設定を進める。
データベースには「Firestore」を使うので、今回新しく作成する。方法としては、エディションを選び、ロケーションは日本向けのサービスなのでアジアの中から東京を選ぶ。画像を保存するストレージも、ほぼ同じ手順で用意する。いずれも本番環境モードで開始した。
「こういう設定画面をコンソールと呼びます。設定は、コンソールのGUIで行う方法と、コマンドで行う方法の2パターンがあります。最初は画面のほうがわかりやすいと思います」（石丸氏）
ここまでで、認証・データベース・ストレージ・アプリの設定と、ひと通りの下準備が完了した。
あわせて、アプリとFirebaseをつなぐための「設定値（コンフィグ）」も取得しておく。これはアプリをFirebaseにつなぐための設定値で、Gemini APIキーのように漏れると直接悪用される秘密情報とは性質が異なる。実際、Firebaseの設定値はクライアント側のコードに含めて公開されることを前提に設計されており、それ自体が見られても即座に問題になるものではない。ただし、プロジェクトIDやバケット名といったプロジェクト固有の情報を不用意に公開する必要もないため、ステージング用の環境ファイルはGitHubに上げないよう、Gitの管理対象から除外しておく。
ここからはVisual Studio Code（VS Code）に戻り、Claude Codeにつなぎ込みを任せていく。
石丸氏があらかじめ用意してくれたプロンプトを送る。このプロンプト自体も石丸氏がClaude Codeに作ってもらったものだが、あえて専門用語を最小限にして「非エンジニアが自然に書きそうな表現」にしてあるとのこと。AIに渡す指示を、AIに考えてもらう。いかにもバイブコーディングらしいやり方だ。
ローカルで動いているこのFirebaseアプリをステージング環境にデプロイしたいです。最初に何を準備すればいいですか？Firebaseの設定値の取り方や、ローカルとステージングを切り替える仕組みも教えてください
すると、Claude Codeは、全体像と手順を一気に提示してきた。
設定値を環境ファイルにまとめ、それをGitの管理から除外し、ステージング用の参照を作り、外部からアクセスできるようホスティングを設定し……といった6ステップのとても長い流れだった。この時点ではまだ「やり方を教えてくれているだけ」で、AIは何も実行していない。いわば地図を見せてもらっている段階だ。
手順に沿って、ステージング用の環境ファイルを作っていく。といっても、筆者がやるのはコピー＆ペーストだけだ。Claude Codeにテンプレートを作ってもらい、そこにFirebaseの設定値を一つずつ貼り付けていく。
途中、引用符（ダブルクォーテーション）を付けるか、付けないかといった細かいところがわかりにくいことがあった。こういうときも自己判断せず、Claude Codeに確認すると「引用符は付けず、Firebaseコンソールの値をそのまま使ってください」などと直してくれる。
APIキーだけは自分でターミナルから登録する
ここからが今回のメインとなる。
とはいえ、AIが少し先走った。環境ファイルを設定し終えたあたりで、Claude Codeが早々にデプロイを始めようとしたのだ。だが、Gemini APIキーの安全な設定も、Googleログインの設定もまだ終わっていない。このまま出しても正常には動かない。
「Claude Codeが早まって、もうデプロイしようとしています。いまデプロイしても、ログインやAPIキーの問題で正常に動かないので、この作業は進める必要はありません」（石丸氏）
なぜこうなったのか聞いたところ、今回のゴールである「Gemini APIキーをセキュアに管理したい」という意図を、最初にClaude Codeへ伝えていなかったからだという。情報が足りないまま走り出した結果、先回りしてデプロイへ向かってしまったためだが、開発の現場でもこういうことはよくあるそう。
ここで筆者が学んだのは2つ。ひとつは、やりたいことの全体像は最初にまとめてAIへ伝えておくとよいということ。もうひとつは、AIが勝手に走り出しても、慌てず前提条件を足せば軌道修正できるということだ。今回は、まだ伝えていなかった「Gemini APIキーを安全に管理したい」という条件を改めて入力し、流れを正しい方向へ戻した。
Gemini APIキーをセキュアに管理したいです。Firebaseをすでに使っているので、できるだけFirebase内で完結させたいです
すると、Claude Codeが提案してきたのは、Cloud FunctionsとSecret Managerという2つの仕組みの組み合わせだった。
「Cloud Functionsはサーバー側で安全に処理を実行する仕組みで、Secret ManagerはAPIキーを保存する場所です。いまはアプリの中にAPIキーを持ってしまっているため、そのままリリースするとアプリにキーが埋め込まれた状態になってしまうので、そこを分離する手順です」（石丸氏）
実装はClaude Codeに任せられる。だが、APIキーそのものをSecret Managerに登録する操作はAIに任せられないので、ターミナルから自分の手で行う。
「Claude Codeに作業を任せられる場面もあります。ただ、APIキーのような秘密情報は、AIの入力欄に直接貼り付けるべきではありません。今回は、キーの登録だけは自分で行い、それ以外の実装をClaude Codeに任せる形にしました」（石丸氏）
ここで素人にとっての大きな壁が現れる。「ターミナル」だ。
普段はVS CodeとClaude Codeの会話だけで進んできたのに、急に「ターミナルでこのコマンドを実行してください」と言われる。多くの非エンジニアがつまずくポイントだろう。
とはいえ、ここは越えるしかない。VS Codeに組み込まれたターミナルを開き、提示されたコマンドを実行する。すると「APIキーを入力してください」と表示されるので、そこにキーの値を貼り付けて［Enter］を押す。これで登録は完了だ。やってみればそれほど難しくはなかった。「APIキーの設定が完了しました。次の手順を進めてください」とチャットに報告すると、作業を再開してくれた。
クラウドに出たアプリは誰でも見られる前提で守る
いよいよデプロイだ。しかし、ここでも一つ引っかかりがあった。
今回必要なGoogle Cloud側の操作を、Claude Codeが「できない」と言ってきたのだ。理由は、操作に必要なツール（gcloud CLI）の準備ができていなかったから。これまでのFirebase関連の操作は、過去の開発でFirebaseの環境がPCに整っていたからこそ動いていたが、Google Cloudの操作は今回が初めてだった。
とはいっても、「その準備（gcloud CLIの環境構築）も君がやって」と頼むだけで、Claude Codeは黙々とセットアップを進めてくれる。ただし、認証はユーザーが行う必要がある。
これでステージングデプロイが完了。VS Codeに表示される、タスク完了の緑チェックがいい感じ。筆者は特に難しいことはしていないのだが、アプリ開発が進んでいるのがすごい。
ステージングのURLを開くと、アプリが表示され、Google ログインの動作も確認できた。自分のPCの中だけで動いていたアプリが、外から見える場所へ出た瞬間だ。スマホからURLを叩いても利用できる。
ここで石丸氏から指摘が入る。デプロイした時点で、このステージング環境は「全世界から見える」状態になっている、というのだ。
「Google ログインが必要なので、見えるだけなら問題はないと思います。とはいえ、Googleの検索結果に拾われるのは好ましくないので、検索から除外する対応をしたいと思います」（石丸氏）
Webページは、どこかからリンクされたり、URLが知られたりすると、Googleのクローラー（ボット）に巡回され、検索結果に出てしまうことがある。今回は基本的に外部からリンクしていないが、可能性はゼロではない。 ページ数が多いとその分だけ巡回され、Firebaseの利用料金にも響く可能性もある。そこでClaude Codeに検索からの除外を指示し、対応してもらった。
さらに石丸氏は、もう一歩踏み込んだ守り方も教えてくれた。ステージング環境を社外に見せたくない場合は、URLにアクセスした段階でもう一段のID・パスワードを挟む「ベーシック認証」や、特定のIPアドレスだけを許可する「IP制限」といった方法があるという。
「開発段階のものを出しているので、たとえば承認制にしていた部分が、今後の開発のどこかで実は外れてしまったり、ログインが突破される作りになってしまったり、ログイン画面に出してはいけない情報が出てしまう可能性がバイブコーディングだとゼロではありません。そういうときにアクセス制限がないと問題になる可能性があります」（石丸氏）
なるほど。AI任せで開発していると、いつの間にか守りが外れてしまうことが起こり得るので、どこかミスがあっても、もう一枚の壁を用意しておけば安心だ。リスクは頭に入れつつ、今回のステージング環境はテスト段階で、Google ログインも必須としているため、ひとまず見送ることにした。本格的な運用が始まったタイミングで改めて検討したい。
最後に、ログインまわりとデータベースの仕上げをした。
ローカルとサーバーで仕様を分け、ローカル環境は引き続きID・パスワードでのログインと、環境ファイルでキー管理を行う。ステージングと本番環境は、Google ログインと、Cloud Functions経由でのセキュアなキー読み取り機能を利用する。この使い分けを、Claude Codeに指示して実装してもらった。
デプロイ直後はユーザーがゼロのため、管理者すらいない状態だった。これではアプリを管理できない。そこでClaude Codeに相談すると、筆者のアカウントを管理者として登録してくれた。
テストの途中で画像解析の機能が一度うまく動かないトラブルもあった。だが、Google Cloud側の設定が済んでいたため、Claude Codeはサーバー上のログを確認できた。エラーの内容を読み取り、原因になっていそうな設定を特定し、修正案を出してくれた。
これで、ステージング環境へのデプロイと、最低限の動作確認、Google アカウントへの移行までが完了した。ゴールがぐっと近づいた。
今回は、ローカル・ステージング・本番という3つの環境の違いを学んだ。また、AIに丸投げすれば公開までできてしまうが、それが安全とは限らないことも知った。そして、APIキーの登録と認証だけは自分の手で行い、それ以外はAIに任せるという線引きも教えてもらった。クラウドに出たアプリは「誰でも見られる」前提で、守りを一枚多く用意しておくことも重要だ。
なお、今回で仕様がかなり変わったので、AIへの指示書ともいえるCLAUDE.mdも大きく更新された。前回、仕様が変わったら自動で更新するようにルールを書いておいたので、ある程度は勝手に追記されていく。最後にコミットしてプッシュし、セーブしておく。
次回はいよいよ最終回。ステージングで動いているアプリを、本番環境へデプロイする。あわせて、本番リリースに向けたセキュリティの最終強化や、利用規約・プライバシーポリシーの整備も行う予定だ。「作っている」から「公開する」へ。バイブコーディングで作ったアプリが本番稼働する日が近づいてきた。
（最終回へ続く）
著者プロフィール：柳谷 智宣
IT・ビジネス関連のライター。キャリアは26年目で、デジタルガジェットからWebサービス、コンシューマー製品からエンタープライズ製品まで幅広く手掛ける。近年はAI、SaaS、DX領域に注力している。日々、大量の原稿を執筆しており、生成AIがないと仕事をさばけない状態になっている。
・著者Webサイト：https://prof.yanagiya.biz/
