プロと実践！ゼロから始めるバイブコーディング

現役プロに教わるアプリ設計とFirebase・VS Codeの初期設定～コードを書く前の「地味な準備」が肝心？

［第4回］細かい事前設計でアプリ運用時のリスクを抑える

柳谷智宣

2026年3月27日 09:00

　本連載では、プロのエンジニアによるアドバイスで伴走してもらいながら、いま話題の開発手法「バイブコーディング」を実践。初心者がつまずきやすいところなど、はじめの一歩から解説していきながら、オリジナルのウイスキー認識アプリの完成を目指す。

石丸師匠の指導のもと、次の開発環境に移る前の下準備を行った

前回までは……

　「非エンジニアでもアプリを作りたい！」という思いから、生成AIを活用して自作アプリの開発（バイブコーディング）に挑戦するが、「公開の壁」に立ち尽くしてしまう筆者。

　そこで、GMOインターネットグループの現役エンジニア、石丸智輝氏に教えを仰ぎ、Google AI Studioでのアプリ開発をスタートした。夢に見ていた「ウイスキー記録アプリ」が早くも動作したことで興奮を抑えきれない筆者だったが、それはフロントエンドにすぎなかった。

　画面消失トラブルを乗り越えながらフロントエンドを作り込み、スマートフォンでの動作チェックもOK。アプリの名前は「AiLA」に決定し、Google AI Studioの作業は終了。

　いよいよGoogle AI StudioとGitHubを連携させて、ここまで作ったソースコードをアップロードし、データベース作成へ！……というところで、行く手に連携バグが立ち塞がるのだった。

　これは、素人とプロの二人三脚による、泥臭くもリアルな開発ドキュメンタリーである……

　今回は「Google AI Studio」で作ったコードをGitHubにアップロードし、認証やデータベースなどのアプリの基盤を担う「Firebase」（執筆・開発時はAI Studioに非搭載）と、開発に使う「Visual Studio Code（VS Code）」の準備を進める予定だ。

Google AI StudioとGitHubを連携させてコードをアップロードする

　前回は、Google AI StudioとGitHubを連携しようと思ったら、不具合が出てしまった。世界中で同様のトラブルが報告されており、これには打つ手がなかった。石丸氏からしばらく待つように言われたので、毎日朝ログインを試していたら、約2週間後、いきなり接続できて「Sync to GitHub」というメッセージが現れた。

　「New repository name」にアプリ名、「New repository description」にアプリ内容の説明を入力し、［Public］または［Private］を選択する。ソースコードは公開しないので、ここでは［Private］を選択して［Create GitHub repository］をクリックした。

Google AI Studioの［GitHub］アイコンから連携する

今回は動作したのでリポジトリの名前や説明を入力する

アップロードするファイルの一覧が開くので、下にスクロールして［commit］をクリックする

　「repository（リポジトリ）」とは、ソースコードや資料をまとめて保存し、変更履歴まで管理できる保管場所のこと。誰が、いつ、何を修正したかを記録でき、過去の状態に戻すこともできる。

「これで、AI Studioで作ったコードをGitHubに書き出し（Push）できました。GitHubで管理しておけば、VS CodeやClaude Codeなど、他のAIコーディングツールからも同じソースコードを扱えるようになります。ただし現時点では、この連携はAI StudioからGitHubへ書き出すための機能で、GitHub側の変更をAI Studioに取り込む（Pullする）ことはできません。つまり、いったんGitHubに出したら、基本的にはAI Studioには戻らず、VS CodeやClaude Code側で開発を続ける、という前提で進めるとよいでしょう」（石丸氏）

GitHubにログインするとファイルの一覧を確認できた

運用時のリスクを抑えるため、一問一答でアプリの事前設計を行う

　さて、次は「Firebase？」「VS Code？」と思いきや、その前に決めておくことがあるらしい。「飲んだウイスキーを記録するSNSを作りたい」とは伝えてあるはずだが、もっと細かい設計が必要とのこと。

「具体的に“どんなデータを保存するか”、“どういう範囲で公開するのか”、などを決めておく必要があります。公開するアプリケーションの難しいところは、作って終わりではないところです。設計が曖昧な状態で進めると、今後の運用が難しくなってしまうのです」（石丸氏）

　たしかにその通りかもしれない。とはいえ、筆者にはこれ以上何を設計すればよいのかわからない。そこで、石丸氏との一問一答が始まった。

「ログイン方法ですが、IDとパスワードを自分たちで用意する方法のほか、GoogleやXなど外部サービスのアカウントでログインする方法もあります。ただ、最初から複数のログイン方法を用意すると、設定の管理や動作確認、問い合わせ対応が増えて運用が大変になりがちです。また外部サービスを使う場合は、サービス側の仕様やポリシー、設定要件が変わったときに対応が必要になることもあります。一方で、IDとパスワードを自前で運用する場合も、パスワード再設定や不正ログイン対策など“運用とセキュリティ”の負担が大きくなりやすい点には注意が必要です。まずはどれか1つに絞って、シンプルに始めるのがよいと思います」（石丸氏）

　もちろんそれはOK。独断でGoogle ログインから始めようと思う。

「次に、ログインしていないユーザーに何を見せますか？」（石丸氏）

　筆者としては、まずはログインした人だけが使える形で十分だ。たしかに、ログイン前でも「どんなウイスキーが登録されているのか」を見せられれば、アプリの雰囲気や価値が伝わりやすく、新規ユーザーにも親切だろう。

　一方で、登録内容を外部に見せる設計にすると、公開範囲の設計やプライバシー面の検討が増え、初期段階ではやることが一気に膨らんでしまう。そこで今回は、未ログインの状態ではログイン画面だけを表示する方針にした。

「次は“誰がログインできるようにするか”も決めておきましょう。多くのサービスでも、最初はクローズドベータのように一部のユーザーだけが使える形で始めて、様子を見ながら段階的に広げていくことがあります。最初は承認制にして、クローズドで始めるのが安全です。例えば、Google ログイン自体は通しても、初回は『承認待ち』の状態にしておき、柳谷さんが許可した人だけがアプリを使えるようにする、という形ですね」（石丸氏）

　最初から誰でも使える状態で公開してしまうと、不正利用やスパム登録で登録内容が散らかったり、画像解析などの処理回数が増えてコストが膨らんだりする可能性がある。承認制にしておけば、そうしたリスクを抑えやすいという。

　加えて、まずは身近な人に限定して使ってもらえるので、フィードバックを集めながら機能や画面を落ち着いて直せるのもメリットだ。管理に慣れてから段階的に公開範囲を広げられる、という点でも安心できる。

細かい設計のために必要な一問一答が続いた

「続いて、SNSの機能はどこまで作りますか？アプリに登録したウイスキーの情報を誰が、どこまで見られるか、という許可の範囲を決める必要があります」（石丸氏）

　本当は、InstagramやFacebookのような交流機能も欲しいが、そんなことを言い出すときりがない。まずは、自分だけが閲覧できる機能をきちんと動作させよう。

「その方が安全だと思います。次は、細かい仕様で、何の情報を登録するかを決めます。まず、画像は必須だと思いますが、他には何がありますか？」（石丸氏）

　登録した情報はせっかくなので全部記録しておきたい。しかし、データを預かる場合は、意図しないデータを公開してしまうリスクもある。非エンジニアの場合は、リスクを抑えるためにも、できるだけ影響範囲が小さい状態にして公開したほうがよいという。

　この話は最初にも聞いたので、ログインIDやパスワード、氏名や連絡先といった個人情報を取得しないようにしていた。ただ、ここでふと、ウイスキーを飲んだ店の情報はどうなるのか気になった。

「店名そのものは、単体で直ちに個人を特定する情報とは限りません。ただし、登録日や写真、他の投稿内容と組み合わさると、行動が推測できてしまうことがあります。クローズドのつもりでも、公開範囲の設定ミスなどで外部に見えてしまう可能性はゼロではないので、最初は扱いに注意したほうがよいですね」（石丸氏）

　情報を漏えいさせるつもりは毛頭ないが、なにせ素人なので万一には備えておきたい。そこで店名の項目は削除することにした。自分で記録する際は備考に入力すればよい。

「機能制限はどうしますか？ユーザーによっては、1日100回とか解析すると、APIコストがかさんでしまう可能性があります。ここは、開発しながら柔軟に調整できるので、覚えておいていただければ大丈夫です」（石丸氏）

　それぞれの質問は聞いてもらえればすぐに判断できるが、これらの項目を自分でAIに指示するのは無理だ。筆者には石丸氏がいたから問題ないが、一般的にバイブコーディングする際はどうすればよいのだろうか。

「やはり、AIに聞くとよいと思います。例えば『このアプリを公開する上で、セキュリティやコストの観点で注意すべきことは？』と聞いて、公開前のチェックリストやリスクを洗い出してもらってみてください。AIを“作るための相棒”としてだけでなく、“レビュー役”としても使うイメージです。エンジニアでも、抜け漏れを防ぐためにそうした壁打ちやレビューを日常的に行っています」（石丸氏）

Firebaseでログインとデータベースの構築準備を進める

　次のステップでは、アプリへのログイン機能と、ユーザーが投稿したデータや画像を保存する仕組みを準備する。

　今回は、Googleが提供するモバイル・Webアプリ開発向けバックエンドサービス（BaaS）の「Firebase」を利用するとのこと。Firebaseを使うと、サーバーを一から構築して運用する手間を減らしながら、ログイン認証やデータベース、画像保存など、アプリに必要な裏側の機能を組み合わせて整えられる。必要に応じて、通知やアクセス解析といった機能も追加できるのが特徴だ。

　まずは、FirebaseのWebサイトを開き、［Get started in console］をクリック。2段階認証を有効にしたGoogle アカウントでログインする。

FirebaseにGoogle アカウントでログインする

　Firebaseが開いたら［Firebaseプロジェクトを設定して開始］をクリック。プロジェクト名を入力するのだが、アプリ名の「AiLA」にしようとしたら、石丸氏から全部小文字にするように指示が飛んだ。プロジェクト名をもとに決まる「プロジェクトID」には、英小文字・数字・ハイフンしか使えないというルールがあるからだ。最初からこれに合わせて入力し、プロジェクト名とIDを揃えておくのがエンジニアの作法らしい。

　また、プロジェクト名には「-stg」と付けたほうがよいとアドバイスしてくれた。「stg」は本番前の検証用である“ステージング環境”を表しているという。本番環境の場合は、プロダクションなので「-prod」を付ける。非エンジニアだと、こういう作法がわかりにくいので、師匠がいるのはありがたい。

新規プロジェクトを作成する

　Firebaseは、Googleのログイン設定がすでに用意されているのが便利なところ。［Authentication］から［ログイン方法］―［Google］を選択。続けて、プロジェクト用のサポート用メールアドレスを設定する。

Googleアカウントでのログイン機能を利用する

「いまは自分のメールアドレスで大丈夫です。本格的にアプリケーションとして運用する場合は、例えば、ウイスキー系のドメインを取って、そのメールアドレスをサポートメールとして公開するといった方がよいかもしれませんね」（石丸氏）

　設定が終わると「Firebase SDKの追加」という画面に、何やらコードが表示され、ここで認証系の準備は完了とのこと。あとでアプリと紐づけるという。

　それぞれの操作は簡単だし、理解はできるのだが、いろいろなツールでさまざまなことを行っているとこんがらがってくる。

「そうですね。ログイン機能を導入して、権限管理が必要なデータや画像を保存し、さらに外部に公開するとなると、急に考えることが増えます。裏側でデータを扱う仕組みが必要になると、セキュリティやコスト、想定外の使われ方まで考慮する必要が出てくるので、どうしても地味な準備が増えるんです。逆に、ログインなし・データ保存なし、あるいは保存しても端末内だけで完結するようなツールなら、バイブコーディングを活用すれば、短期間で公開まで進めやすいです」（石丸氏）

VS CodeとGitHubを連携させてコードをダウンロードする

　最後に、VS Codeをセットアップする。

　公式サイトからインストールし、VS Codeを起動する。まずはメニューを日本語化するため、［Ctrl］＋［Shift］＋［P］キーを押してコマンドパレットを開く。そこに「language」と入力すると、コマンドの候補が表示されるので、［Configure Display Language］を選んで［日本語］を選択する。