プロと実践！ ゼロから始めるバイブコーディング
【最終回】バイブコーディングは、簡単で、そして大変だった ～ついに本番公開！ ウイスキーアプリ Ver.1が完成した
［第10回］不安なことはそのまま素人の言葉で「AIに聞く」のが大事
2026年7月3日 09:00
「非エンジニアでもアプリを作りたい！」という思いから、生成AIを活用して自作アプリの開発（バイブコーディング）に挑戦するが、「公開の壁」に立ち尽くしてしまう筆者。
そこで、GMOインターネットグループの現役エンジニア、石丸智輝氏に教えを仰いだ。Google AI Studioでフロントエンドを作り込み、アプリの名前を「AiLA」に決定。開発の場をClaude Codeに移し、数々のトラブルを乗り越えながら、自分のPCの中だけで動いていたウイスキーアプリを、外から見えるステージング環境へデプロイした。
これは、素人とプロの二人三脚による、泥臭くもリアルな開発ドキュメンタリーである……
素人がバイブコーディングでアプリを開発する本連載も、いよいよ最終回となる第10回。今回はついに「本番環境」への公開を目指す。
セキュリティが不安なら、不安なまま素人の言葉でAIに聞けばよい
まずは、公開前のセキュリティ点検から行うことにした。石丸氏が教えてくれたのは、以下のプロンプトだ。
招待制のFirebaseアプリを公開予定ですが、未招待やBAN済みの人がログインだけしたり、画面を使わず直接操作した場合、メール流出・データ改ざん・AI費用増加などが起きるのかわかりません。どこを確認し、何から対策すべきでしょうか。
「招待した人だけが使えるはずのアプリなのに、招待していない人や利用停止にした人が、もしログインだけ済ませたら何ができてしまうのか」という不安を、そのままぶつけたものだ。専門用語を使わなくても、これくらいの粒度で書いておけば、Claude Codeは意図をしっかり汲み取ってくれるという。
送信すると、Claude Codeはアプリのソースコードを次々と読み込み、「本当にリスクがあるか」を実際のコードに当たって調べ始めた。しばらくすると、確認すべき項目を優先度付きでリストアップし、いくつかの課題を「要対策」として挙げてきた。
あまりに手際よく課題が並ぶので、「これ、石丸さんは先にわかっていたのですか？」と尋ねてみた。すると、第8回でGitHubの共同作業者に加わって以降、実際にコードを確認し、本番前に直すべき箇所をいくつも把握していたとのこと。つまり、今回のプロンプトは、筆者に自力で気づかせるための「誘導」でもあったわけだ。
では、非エンジニアがバイブコーディングする際、こうした穴に気づくにはどうすればよいのだろうか。石丸氏の答えはやはり「AIに聞く」のが定番だという。今回のように、不安をそのまま言葉にして点検を頼むことが、最初の一歩として有効だ。
そのうえで、もう一歩踏み込むなら、として、Webアプリでよくある代表的なリスクの“型”を知っておくことが重要だ、と石丸氏はアドバイスしてくれた。例えば、ログインした人に対し、見せてよい情報や操作してよい範囲をきちんと制御できているか、いわゆる「認可」の不備だ。こうした“型”は、まずAI自身に「初心者向けに教えて」と尋ねれば教えてくれる。この観点を持っていれば、不安をより的確な言葉にしてAIに点検を頼める。
今回、要対策として検出されたのも、まさにこの「認証」と「認可」の問題だった。ログインで「あなたが誰なのか」を確認するのが「認証」で、「あなたが何を見たり操作したりしてよいのか」を確認するのが「認可」だ。筆者のアプリではログイン（認証）は動いているが、その先の認可がきちんと効いているかに問題があるとのことだった。
「特定のユーザーに見せるべきものだけを、きちんと見せられているか、という観点が重要です。例えば、一般ユーザーのAさんが、本来見えてはいけないBさんの情報にアクセスできてしまうのは大きな問題なので、こういったことを確実に防ぎたいのです」（石丸氏）
ポイントは、こうした制御を「画面」だけに頼ってはいけないという点だ。
アプリの「画面」の上では、見せたくない情報を隠しているつもりでも、その裏側にあるデータそのものが守れていないことがあるという。画面を経由せず、開発者ツールなどから直接データを操作されると、隠したはずの情報が取れてしまう、というわけだ。守りは「画面」ではなく「サーバー側のルール」に置くのが鉄則だ。
「これは、バイブコーディングで特に抜けやすいところです。AIは『こう動かしたい』と頼めば、その通りに作ってくれます。でも『この人には触らせない』という“させない側”は、意識して指示しないと、抜けてしまうことがあります」（石丸氏）
優先度の高いものから順に対応するようにClaude Codeに指示すると、関連ファイルをすべて把握した上で、安全に直すための作業計画を立て、上から順に対応してくれた。
プロは「コードレビュー」と「テストコード」でこうしたミスを防いでいる
興味本位で、人間がAIではなく人手でこのようなリスクを検出するにはどうしていたのか聞いてみたところ、プロの開発現場では、体系的な仕組みでこうした穴を防いでいるそう。
ひとつは、コードレビューだ。
例えば、新人エンジニアが書いたコードを、上司や先輩が確認し、問題がなければ本番に反映する。人の目を複数通すことで、見落としを防ぐ。今回でいえば、石丸氏が筆者のコードをレビューしてくれたような感じだ。ただ最近は、このコードレビューをAIに任せることも増えてきたという。例を挙げると、Claude Codeで実装したコードを、OpenAIのCodexといった他のAIにレビューさせる、といった具合だ。一人で開発していても、自分以外の視点を取り入れやすくなる。
もうひとつは、テストコードという手法だ。
ざっくり言うと、決まった操作を自動で繰り返しチェックしてくれる仕組み。例えば、Aさんが自動でログインし、ある画面を開いて、Bさんの情報が見えていないか、といったシナリオをあらかじめ書いておき、期待通りの結果になれば合格、という確認を、人の代わりにプログラムが自動で行ってくれるという。加えて、よくある脆弱性を自動で洗い出すセキュリティ診断ツールも使うことが多いとのこと。
「一人で開発するバイブコーディングの怖いところは、やはり一人だけではリスクに気づくのが難しい点です。人でもAIでも、複数の目を用意すること。そして、落ち着いたタイミングで、テストコードのような仕組みを足していくこと。より安全に進めるなら、そこまで踏み込む価値はあります」（石丸氏）
AIがあれば、コードを書く部分はかなり任せられる。しかし、「何を確認すべきか」「どこが危ないか」という観点は、まだ人が持っておく必要がある。AIがない時代の開発を想像すると、よくこれだけのことを人力でやっていたものだと、毎回感心してしまう。
本番環境はステージングとは別のプロジェクトとして新しく用意する
セキュリティの課題をひと通り直したら、もう一つ用意しておくべきものがある。利用規約とプライバシーポリシーだ。誰かに使ってもらうアプリである以上、これは欠かせない。
もちろん、これもたたき台の作成はClaude Codeに任せられる。
「利用規約とプライバシーポリシーを作りたいです」と頼むと、現在のアプリの実装を読み取った上で、文面を作ってくれた。チェックしたところ、筆者の名前が間違っていたり、公開すべきでないメールアドレスが入っていたりしたので修正した。このように、AIの出力を人の目でチェックすることは重要なので、忘れないようにしよう。成果物は、アプリのページ内に組み込む形にした。
続けて、ステージング環境にデプロイして動作を確認する。この手順は前回とほぼ同じだ。Claude Codeに「ステージング環境にデプロイしてください」と頼み、デプロイ後は実際にログインして写真を解析し、問題なく動くことを確認した。
ここからがいよいよ本番だ。
石丸氏からは、本番環境はステージングとは別のFirebaseプロジェクトとして新しく作る、という方針が示された。
「本番とステージングは、プロジェクトごとに分けて運用するのが一般的です。リスクを分散できますし、仮にステージング側で何らかのトラブルが発生しても、本番とは切り離せます。課金も完全に別々にできます。片方で検証したことを本番に適用する、片方が壊れても本番には影響が出ない、という運用ですね」（石丸氏）
正直に言うと、手間は2倍になる。だが、その手間とリスクのどちらを取るか、という話だという。個人開発者の全員がここまで分けているわけではないが、より理想的な構成としてはこうなる。アドバイスするなら「やっておいた方がよい」とのことなので、素直に従うことにした。
本番への移行は、Claude Codeに次のように伝えるところから始まった。
ステージング環境の実装が完了したため、本番環境にデプロイしようと思います。Firebaseのプロジェクトはステージングと本番環境で分けます。今後の手順を教えてください
すると、本番公開までの手順を、フェーズに分けて整理してくれた。作業自体は、これも第9回で行ったステージング構築とほぼ同じだ。Firebaseのコンソールで本番用のプロジェクトを新規作成し、従量課金のBlazeプランにアップグレード、Google ログインを有効化し、データベース（Firestore）とストレージを用意する。ロケーションは日本向けなので東京（asia-northeast1）を選ぶ。最後に、アプリとつなぐための設定値を控えておく。一度経験しているので、今回は迷わず進められた。
ちなみに、ステージングでは「aila-stg」と付けたので、本番ではどう付ければよいか聞いたところ、「aila-prod」と教えてくれた。「プロダクト（製品）」ですね！というと、「いえ、Production（本番用） の略です」と一蹴された。
「APIキーだけは自分の手で登録する」という線引きは変わらない
本番用のプロジェクトができたら、次は秘密情報であるGemini APIキーの登録だ。ここで第9回でも経験した「壁」が、また現れた。
手順の途中で、Claude Codeが「ステージングで使っているキーと同じ値を、プロンプトに貼り付けてください」と案内してきたのだ。何気ない指示に見えるが、非エンジニアにとっては危ういところ。「プロンプトに貼り付け」と言われると、つい目の前のAIのチャット欄に貼り付けたくなる。だが、APIキーのような秘密情報をチャットに貼ると、やりとりの記録として残ってしまい、漏えいのリスクがある。
ここで自己判断せず、石丸氏のアドバイスに従って、Claude Codeに念のため確認してみた。
フェーズ4ですが、キーをここ（チャット）に貼るのはダメですよね。正しい手順を教えてください
するとClaude Codeは、はっきりと正しい流れを示してくれた。チャットに鍵を貼ってはいけない、ここに書いた内容は会話の記録に残るため、秘密情報は自分のターミナルの対話プロンプトにだけ入力するのが正しい、という回答だ。つまり、AIを介さず、自分とサーバーだけのやりとりで登録する。
「最新のClaude Codeでも、APIキーを貼り付けるよう案内してくることがあります。ですが、APIキーをAIに貼り付けるのはNGです。秘密情報をチャットに貼らない、という線引きは、最初に必ず認識しておいてほしいところです。迷ったら今回のように『これは貼ってもいいのか』と確認すれば、AIも正しい手順を教えてくれます」（石丸氏）
あとはClaude Codeの案内通り、Visual Studio Codeに組み込まれたターミナルでコマンドを実行する。入力を求められるので、そこにAPIキーの値を入力する。前回も一度やっているので、今回はそれほど身構えずに済んだ。
補足すると、Gemini APIキーは、本来であれば本番・ステージング・ローカルでそれぞれ分けるのが理想だという。漏れたときの被害を環境ごとに切り離せる上、利用量やコストも把握しやすく、APIキーごとに適切な利用制限もかけられるからだ。今回はベータ版という位置づけなので、ひとまず同じキーで進めることにした。本格的に運用するなら、ここも分けておくのがよさそうだ。
ここまで整えて、いよいよ本番環境へのデプロイだ。Claude Codeにコミット、プッシュ、デプロイを順に依頼する。
ただし、新規に作ったプロジェクトということもあり、最初のデプロイはすんなりとはいかなかった。サーバー側の権限が一部足りず、公開用のURLを開いても、しばらく「ページが見つかりません」と表示される状態が続いたのだ。とはいえ、Google Cloudの操作はすでにClaude Codeに任せられる状態にしてあったので、頼もしかった。
Claude Codeはサーバー上のログを自分で確認し、原因が新規プロジェクト特有の権限不足にあることを突き止め、必要な権限を付与して公開し直してくれた。新しい環境を作ると、こうした設定のズレはよくあることだという。
無事にデプロイが完了すると、本番用のURLでアプリが表示され、Google ログインも動作した。
なお、デプロイ直後はユーザーが誰もいない状態だ。しかも、安全のためにアプリからは管理者を追加できない仕組みにしてあるので、最初の管理者だけは手動でデータベースに登録する必要がある。コンソールでの手作業は手順が細かいので、これも「この手順をやってもらえますか」とClaude Codeに頼むと、筆者のアカウントを管理者として直接登録してくれた。これでついに、自分が作ったウイスキーアプリが本番環境で動き出した。
ひとつ、地味だが役に立つコツも教わった。
本番とステージングは見た目がそっくりで、URLでしか区別がつかない。そこで「ステージングだとひと目でわかるようにしたい」とClaude Codeに頼めば、画面の上部に「これはステージング環境です」という赤い帯を出すなど、視覚的に区別する工夫を入れてくれるという。どちらを見ているのか混乱しがちな筆者には、ありがたい話だった。これも今後の改善案として控えておく。
最後に、大きく仕様が変わったので、AIへの指示書であるCLAUDE.mdを更新してもらい、改めてコミットしてプッシュ。これで、ローカルからステージング、そして本番公開まで、ひと通りの道のりが完了した。
バイブコーディングは、簡単で、そして大変だった
全10回にわたってお届けしてきた本連載も、これでシーズン1の完結となる。なお、本番公開はしたものの、まだ一般には開放していない。セキュリティの確認や使い込んだときの挙動を確認していないためだ。今後、筆者と友人で使い込み、ブラッシュアップを続ける予定だ。
全10回の指導を受けた感想は、とにかく、バイブコーディングは、簡単で、そして大変だった。この両方が本音だ。コードを1行も書けない筆者でも、AIに日本語で頼むだけで、ユーザー登録やデータベースを備えたWebアプリが本当に形になっていくのは感動ものだ。
一方で、毎回「ほうほう、そう来るか」という想定外の連続でもあった。AIに質問することで乗り越えてきたが、その質問にある程度のリテラシーが求められる。そして何より、プログラミングの知識がまったくないままでは、まともなものを作るのは難しいということを、逆説的に痛感した。
ただし、それでもこれまで不可能だったアプリ作成が可能になったのは素晴らしいことだ。この連載で得た知識を使い、すでに数十のアプリを構築し、日々プライベートに仕事に活用している。自分だけで使うのなら気軽なものだ。
とはいえ、ウイスキー管理アプリ「AiLA」は将来、一般公開し、月額課金で収益を上げられるようにしてみたい。そこまでには、セキュリティの強化、決済機能の実装、アプリ化などまだまだやるべきことは多い。これは今後の課題としたい。
最後に、石丸氏に総括とアドバイスをいただいた。
「今回は、ユーザーの情報を扱い、データベースも必要とする難易度の高いアプリケーションを作りました。Webアプリケーション開発未経験の非エンジニアの方が、Claude Codeを活用することで本番へのデプロイまで到達できたのは、本当にすごいことだと思います。一方で、Webアプリケーションの代表的な脆弱性である『認可』の不備や、APIキーの管理、秘密情報の安全な扱いといった部分は、非エンジニアの方がバイブコーディングだけで進めるのは、やはり難しいと感じました。こうしたところは、プロに質問したり、自分でも知識を持った上で進めるのが安全です。最新のAIでも完璧ではありません。ときには、そのまま従うと危うい手順を案内してくることもあります。だからこそ、すべてをAIに任せきるのではなく、要所は人が判断する姿勢を持っておくことが、安全に進めるための鍵だと思います」（石丸氏）
石丸氏は、バイブコーディングを使う上での心構えとして、日々の情報のキャッチアップも挙げてくれた。
AIツールも、セキュリティの常識も、移り変わりは速い。少し前には、AI時代にAPIキーをどう管理するか、というテーマが、Xなどで活発に議論されていた。論点はその時々で移っていくので、常に最新の議論を追いかけ、いまは何が話題になっているのかを把握しておくこと。それも、安全にバイブコーディングを楽しむための、大切な姿勢なのだろう。
そして、これから挑戦してみたいという非エンジニアの方へ、石丸氏からのアドバイス。今回のように、ユーザーのデータを扱い、データベースを必要とするアプリを、知識ゼロからバイブコーディングだけで作るのは、正直おすすめしないという。まずは、サーバーやデータベースが不要で、ユーザーのデータを扱わないアプリから始めるのがよい。最低限のリテラシーはやはり必要になるためだ。
非エンジニアにとっては少し耳の痛い話だが、わからないことはAIに聞きながら、少しずつ学んでいけばよい。詰まったらAIに相談する。その姿勢自体は、これからも変わらず通用するはずだ。
数カ月にわたってお付き合いいただき、ありがとうございました。バイブコーディングで作ったウイスキーアプリは、こうして本番稼働にこぎ着けることができた。これからも「AiLA」の改良と機能追加を続け、いつかWebサービスとして公開し、ウイスキー好きに使ってもらえるようにしたいところだ。
（シーズン1・完）
著者プロフィール：柳谷 智宣
IT・ビジネス関連のライター。キャリアは26年目で、デジタルガジェットからWebサービス、コンシューマー製品からエンタープライズ製品まで幅広く手掛ける。近年はAI、SaaS、DX領域に注力している。日々、大量の原稿を執筆しており、生成AIがないと仕事をさばけない状態になっている。
・著者Webサイト：https://prof.yanagiya.biz/
