Vibe Codingで作ったアプリ、公開する前に確かめる4つのこと【勉強会資料を公開】

こんにちは、kazuです。

2026年9月26日、coen（共創コミュニティ）で開催してきたVibe Codingワークショップの全3回が終了しました。

最終回のテーマは「作ったアプリを、安全に世に出す」。AIと一緒にアプリを作ったあと、公開する前に何を確かめるかを扱いました。

手元ではちゃんと動いている。でも、このURLを人に渡して大丈夫なのか。アプリを作ってみると、そこで迷うことはないでしょうか。

今回は、講義で使った資料を公開したので紹介します。コード・データと認証・公開先・AI機能の4つに分けた確認手順と、公開前チェックリストを収録しています。参加していない方にも、自分のアプリと照らし合わせて使ってもらえる内容です。

全3回で「作る」から「公開する」まで

今回のワークショップは、次の流れで進めてきました。

第1回：Google AI StudioでVibe Coding入門（6月27日）
AIに作りたいものを伝えながら、アプリを形にするところから始めました。

第2回：Claude Code／Codexでアプリ開発（7/25から8/23に延期して開催）
より本格的な開発を扱いました。Claude Codeに設計書を作らせ、その内容を別のAIに渡して実装する「2つのAIの分業」も紹介しました。

第3回：作ったアプリを、安全に世に出す（9月26日）
作ったものを公開する前の点検がテーマです。講義のあとに各自のアプリで確認と公開を進めるもくもく会を行い、最後は発表会へと進みました。

アプリの画面ができることと、ほかの人に使ってもらえる状態にすることは、確認する内容が違います。最終回では、新しい機能を増やすよりも「どこで、何を確かめるか」に時間を使う構成にしました。

第3回の講義資料を公開しました

資料はこちらです。講義資料「作ったアプリを、安全に世に出す」

操作の途中で迷ったときに戻ってこられるよう、各手順の確認ポイントとAIへの依頼例をまとめています。

まず全体像を知りたい場合は13・14ページ、公開前の確認に使いたい場合は59・60ページのチェックリストから見てみてください。以下では、資料を使うときに押さえておきたいところを紹介します。

「動いた」だけでは分からないことがある

講義の入口では、アプリ公開後の事故につながる3つの型を取り上げました。

APIキーが外に出てしまう
APIキーは、外部サービスを使うための鍵にあたります。秘密のキーをコードに書いたまま公開すると、第三者に使われ、利用料金が発生するおそれがあります。

見せるつもりのないデータが読めてしまう
ログイン画面があっても、その先のデータへのアクセス制限が適切とは限りません。自分の情報しか見えない想定なのに、別の利用者の情報も取得できてしまう場合があります。

AIチャットボットが意図しない指示に従う
入力された文章や、読み込んだページに含まれる指示によって、AIが本来の役割から外れた返答や操作をしてしまう問題です。

どれも、普段どおりに操作しているだけでは気づきにくいところです。投稿できる、返事が返る、画面がきれいに表示される。それらが確認できても、権限や秘密情報の扱いまでは分かりません。

講義資料でも触れていますが、公開サイトには自動で調べに来るボットもいます。有名なサービスだけを心配すればよいわけではありません。

普段の操作が成功するかに加えて、「許可していないことができないか」を確かめる。そのために、公開までの流れを4つに分けました。

手順① コードに秘密や確認漏れがないかを見る

最初に確認するのは、APIキーの直書き、認証・権限チェックの抜け、個人情報の扱いです。AIにコードをレビューしてもらい、指摘のあった場所を見ていきます。

このときは「問題ない？」だけで終わらせず、一般公開する予定であることと、どの部分を確認してほしいかを伝えます。講義資料の24ページには、そのまま使えるレビュー依頼例を載せています。

レビューで指摘が出たら、何が問題で、どう直すのかを確認してから修正する。修正後は同じ点をもう一度見る。この往復までをひとまとまりにすると、指摘を読んだだけで終わりにくくなります。

秘密のキーを.envなどに分けた場合は、そのファイルがGitの管理対象から外れているかも確認します。すでにキーを公開してしまっていたら、コードから消すだけでは足りません。過去の履歴に残っている可能性があるため、キーの無効化・再発行が必要です。

また、AIが追加しようとするパッケージも確認対象です。名前が出てきたからとすぐにインストールせず、公式の情報や配布元を確認します。AIのレビューは確認を助けるものとして使い、合格証のようには扱わないことが大切です。

手順② データを「誰が、何をできるか」で確かめる

データベースやログイン機能を使うアプリでは、この手順が必要です。講義ではSupabaseを例に、RLS（行レベルセキュリティ）を扱いました。

RLSは、データベースの行ごとにアクセスを制御する仕組みです。
ログインした人が誰かを確かめる「認証」と、その人がどのデータを読んだり変更したりできるかを決めることは、分けて考えます。

たとえば、本人だけが読むメモなら、別のアカウントから読めてはいけません。一方、公開掲示板の投稿なら、誰でも読めることが意図した動作です。ただし、誰でも他人の投稿を書き換えられてよいとは限りません。

先に「見せてよい範囲・変更してよい範囲」を決め、そのとおりに制限されるかを試します。RLSのスイッチだけでなく、ポリシーと操作権限も確認します。未ログイン状態と別アカウントで、読めるもの・読めないもの、変更できるもの・できないものを確かめてください。

画像やファイルを扱う場合は、Storageの公開設定も別に見ます。データベースの設定が正しくても、ファイルの置き場が意図せず公開されていることがあるためです。

公式資料：SupabaseのRLS

手順③ 公開先でも、秘密のキーと見える範囲を確認する

講義ではVercelでの公開を例にしました。公開先を選んだあとも、キーの設定と公開範囲の確認は続きます。

ここで気をつけたいのが「環境変数に入れたから大丈夫」とは限らない点です。Next.jsのNEXT_PUBLIC_のように、ブラウザ側へ値を渡すための環境変数があります。秘密のキーをそこへ入れると、コードへの直書きをやめても、利用者から見える状態になってしまいます。

公式資料：Next.jsの環境変数

Supabaseも、ブラウザで使うpublishableキーと、サーバー側だけで扱うsecretキーを区別します。
旧形式のanonキーはpublishableキー、service_roleキーはsecretキーと同じ扱いです。
キーが見えるかどうかだけでなく、そのキーを見せてよいかを確認する必要があります。

公式資料：SupabaseのAPIキー

開発中のプレビューURLも、どこまで閲覧できる設定か確かめます。「まだ本番ではない」ことと「外から見られない」ことは同じではありません。

利用料金の設定も確認項目に入れました。利用上限が設定できるサービスでは上限を、あわせて予算アラートを確認します。通知を受け取る設定と、利用を止める設定は別なので、アラートを入れただけで請求が止まると思わないようにしてください。

手順④ AI機能には、権限と回数の制限を用意する

AIチャットなどを組み込んだアプリでは、プロンプトインジェクションも考えます。AIが読む文章に別の指示が紛れ込み、アプリ側の意図と違う動作を引き起こす問題です。

入口はチャット欄だけではありません。AIがページを読んで要約したり、アップロードされたファイルを読んだりするなら、そこに含まれる文章も対象になります。

講義では、システムプロンプトに秘密を入れないこと、AIに強すぎる操作権限を渡さないこと、出力をそのまま実行しないことを取り上げました。メール送信やデータ削除などは、実行前に内容を確かめられる仕組みを挟みます。

「秘密を話さないで」と書くことだけに頼るのではなく、AIから秘密へアクセスできる範囲や、実行できる操作そのものを制限する。ここは、作る段階から考えておきたいところです。

もうひとつは利用回数です。AI機能が繰り返し呼び出されると、API料金も増えていきます。一定時間内の利用回数を制限するレートリミットと、サービス側の利用上限を組み合わせて考えます。

なお、データベースを使わないアプリには手順②の作業が不要な場合がありますし、AI機能がなければ手順④は対象外です。全部を形式的に埋めるより、自分のアプリに何があるかを見て進めてください。

59・60ページのチェックリストを、公開のたびに使う

資料の59ページはコード・データと認証、60ページは公開先・AI機能・公開後の確認です。全文はスライドにあるので、ここでは使い方を紹介します。

まず、自分のアプリに該当する項目を選びます。次に「設定したか」だけでなく「どう確かめたか」を残します。

たとえば、RLSなら「有効にした」で終わらず、「別のテスト用アカウントから、非公開のメモを取得できなかった」まで確認する。秘密のキーなら、設定欄だけでなく、公開されたブラウザ側のコードに含まれていないかも見る。チェックを付ける根拠をひとつずつ持つイメージです。

まだ試せていないものは、確認済みにせず残しておきます。AIに作業を手伝ってもらった場合も、結果を見てからチェックを付けてください。

そして、一度公開したら終わりではなく、機能を追加したときにも使い直す。画像のアップロードやAIチャットを後から加えれば、見る場所も増えます。チェックリストを更新時の手順に入れておくと、最初の公開時だけの確認にならずに済みます。

全3回を終えて

第3回は、講義を聞いたあとに各自のアプリで作業し、最後に発表する流れでした。資料を読むだけでなく、自分が作ったものの設定や動作を確かめる時間を設けています。その後、SlackにURLを共有して、他の参加者にも見てもらい発表しました。

2回目までで作っていたWebアプリを無事に公開できた方もいらっしゃいました。時間の都合上、公開はできなかった方もいらっしゃいましたが、その分、公開する前に確認すべきことの重要性を感じていただけたと思います。

第1回に参加された方の多くは、Claude CodeやCodexを触ったことがありませんでした。それでも3か月ほどで、Webアプリの公開まで進んだ方もいて、とても充実した勉強会になりました。
もちろん、公開できたら終わりではなく、公開したあとが本番です。
安全に運用し続けたり、機能の改善など大変なこともあると思いますが、ぜひ更新を続けていただけると嬉しいです。

参加してくださった方、運営の皆さん、本当にありがとうございました！！
（手元に集合写真がないので、後日受け取り次第差し替える予定です）

まとめ

アプリが動いたら、コード、データと認証、公開先、AI機能を順に見ていく。今回の資料では、公開前に最低限確かめたいポイントをその4つに整理しました。

講義の最後には、次の言葉を置いています。

作る作業をAIに手伝ってもらいながら、公開してよい状態かは実物で確かめる。そのための資料として、使ってもらえたらうれしいです。

この資料だけであらゆる攻撃を防げるわけではありません。個人情報を扱うサービスや本格的な運用では、扱う情報や機能に応じて専門家のレビューも検討してください。

ここまでお読みいただき、ありがとうございました。

よくある質問（FAQ）

Q. ワークショップに参加していなくても、資料を使えますか？
A. 公開したSpeaker Deckから閲覧できます。

Q. Supabaseを使っていなくても、確認する必要はありますか？
A. データを保存する仕組みがあるなら、使っているサービスに応じてアクセス制限を確認します。Supabaseの操作をそのまま行う必要はありませんが、誰がどのデータを扱えるかを確かめる考え方は共通です。

Q. AIにレビューしてもらえば、そのまま公開できますか？
A. レビューの結果だけで判断せず、指摘を直し、設定と動作を確かめてください。もちろん、AIの見落としもあるため、アプリの用途に応じた確認が必要です。

生成AIの実践記録を、メンバーシップでも発信しています

メンバーシップ「生成AIラボ」では、AIツールを試した記録や、実際に使うなかでの工夫をまとめています。手順だけでなく、試して分かったことも読みたい方はのぞいてみてください。

生成AI・AIエージェントを動画で学びたい方はこちら

私が講師を務める講座の内容は、各コースのページでご覧いただけます。

生成AIコース（基礎）

生成AIコース（実践）

AI人材コース

案件のご相談はこちら

AIを使った業務効率化や、AIエージェントの活用を支援しています。ご相談はお問い合わせフォームからお寄せください。

継続的な伴走支援については、AI顧問サービスの詳細はこちらをご覧ください。

#VibeCoding #セキュリティ #Supabase #Vercel #生成AI #個人開発