バイブコーディングは安全か?実際のリスクと公開前に確認すべきこと
バイブコーディングは、個人用ツールやプロトタイプには安全であり、実際のユーザーがいる本格的なアプリにも安全に使えます。ただし、「説明して、動くか試す」だけでは省かれてしまうチェックを追加した場合に限ります。危険な問題は画面からは見えません。たとえば、他のユーザーのデータを開けてしまうユーザー、ブラウザ内に置かれた秘密鍵、制限のない公開フォームなどです。このガイドでは、実際にトラブルを引き起こすリスク、秘密情報の扱い方、必要なレビューの量、そして公開前に行うべき30分間のチェックを解説します。
技術的な完全版は、AIで作られたアプリのセキュリティチェックリストをご覧ください。このページは、コードを読まない人向けの短く実践的なバージョンです。
バイブコーディング特有のリスク
バイブコーディングでは、アプリを実際に使うことで良し悪しを判断します。それで壊れたボタンや見栄えの悪いレイアウトは見つかります。しかし、他の人があなたとは違う使い方をしたときにだけ現れる問題は見つかりません。たとえば、見知らぬ人、ボット、URLを書き換えて覗こうとする好奇心旺盛なユーザーなどです。
AIモデルはもっともらしいコードを書きますし、ほとんどは問題ありません。ただしAIは、あなたが頼んだこと(「自分のプロジェクトを表示するダッシュボードを作って」)を最適化するだけで、頼まなかった保護(「ただし他人のプロジェクトは表示しない」)までは入れないことがあります。解決策はバイブコーディングをやめることではありません。必要な保護を明示的に頼み、それをテストすることです。
アプリのリスクはどのくらい?簡単な目安
| あなたのアプリ | リスク | 必要なこと |
|---|---|---|
| 自分だけが使う個人ツールで、機密データがない | 低 | コードの外に鍵を置く。それだけで十分なことが多い。 |
| フォームのある公開サイトやランディングページ | 低から中 | フォームの回数制限、ボット対策、ページ内に秘密情報を置かない |
| ユーザーがサインアップし、自分のデータを保存するアプリ | 中 | このページのすべての項目 |
| 支払い、健康、金融、子どもやIDのデータ | 高 | このページのすべての項目と、開発者によるレビュー |
どの行に当てはまるかは正直に判断してください。多くのアプリは最初は一番上の行から始まり、誰も決めないまま、いつの間にか一番下の行に近づいていきます。
実際にトラブルを引き起こすリスク
1. ユーザー同士がお互いのデータを見られてしまう
これはAIで作られたアプリで最もよくある深刻な問題です。ページには各ユーザー自身のレコードだけが表示されるので、正しく見えます。しかし、誰かがアドレスバーやリクエストの中のIDを書き換えると、サーバーは任意のレコードを返してしまいます。いつも自分自身でテストしているため、この問題は見えません。
確認方法: 2つのアカウントを作成します。ユーザーAでログインし、Aのレコードを1つ開いてアドレスを控えます。次に、プライベートウィンドウでユーザーBとしてログインし、そのアドレスを貼り付けます。表示されるのは「見つかりません」だけであり、Aのデータが見えてはいけません。
プロンプト例:
ユーザーデータを読み取る、変更する、削除するすべてのサーバーエンドポイントを確認してください。各エンドポイントは、ログイン中のユーザーがその特定のレコードにアクセスできるかを必ず確認する必要があります。エンドポイントの一覧を出し、それぞれの確認方法を説明し、確認していないものは修正してください。
2. 秘密情報が間違った場所にある
秘密情報とは、アクセス権を与えるものすべてを指します。AIサービスやメールサービスのAPIキー、データベースのパスワード、決済サービスの秘密鍵などです。ブラウザで動くコードに含まれていれば、誰でも開発者ツールを開いてコピーできます。公開リポジトリにコミットされていれば、ボットが数時間以内に見つけてしまいます。
確認方法: AIに聞いてください。
このアプリが使用しているAPIキー、トークン、パスワードをすべて一覧にしてください。それぞれについて、どこに保管されているか、ブラウザに送られることがあるかを教えてください。コードやフロントエンドにあるものは、サーバー側の秘密情報に移してください。
3. 制限のない公開フォームやエンドポイント
お問い合わせフォーム、サインアップ、AI機能は、ボットに見つかります。制限がなければ、スパム、偽アカウント、あるいはAI APIが何千回も呼び出されることによる高額な請求につながります。
プロンプト例:
サインアップ、ログイン、お問い合わせフォーム、AIサービスを呼び出すすべてのエンドポイントに、レート制限を追加してください。公開フォームにはハニーポットのフィールドを追加してください。選んだ制限の値を教えてください。
4. ブラウザを信頼しすぎる
ブラウザが決めたことは、ユーザーが書き換えられます。価格、割引、クイズの回答、「管理者」フラグなどです。重要なルールは、必ずサーバーで強制しなければなりません。
プロンプト例:
ブラウザが、本来サーバーが判断すべきことを決めている箇所を探してください。価格、合計額、権限、役割、スコアなどが対象です。それらのチェックをサーバー側に移してください。
5. 元に戻す方法がない
悪い変更や悪意のある人物によって、データが削除されることがあります。バックアップも巻き戻しの方法もなければ、小さなミスが取り返しのつかない結果になります。ツールにコードのチェックポイントと、データベースのバックアップがあることを確認してください。アプリのデータベースをバックアップする方法をご覧ください。
秘密情報を正しく扱う
秘密情報は、他のどのことよりも避けられる被害を生みます。そのためのルールを一箇所にまとめます。
- 本物のキーをチャットに貼り付けない。 チャットは保存され、共有され、スクリーンショットにもなります。代わりに、ツールの秘密情報や環境変数に入れてください。(環境変数と秘密情報とは)
- 有料サービスの呼び出しはサーバーから行う。 ブラウザはサーバーに依頼し、サーバーがキーを使ってAIサービスや決済サービスを呼び出します。
- テスト用と本番用で別々のキーを使う。 テスト用キーが漏えいしても、実際のお金に影響しないようにするためです。
- 利用上限を設定する。 AIサービスやメールサービスのダッシュボードで、支出の上限を決めておきましょう。
- 漏えいが疑われたら、すぐにキーを更新する。 新しいキーを作成し、秘密情報を差し替えてから、古いキーを削除します。
Mythexでは、秘密情報はコードの外にあるプロジェクト設定に保存され、エージェントはチャット上に値を表示せずに利用できます。より多くのサービスについては、APIキーを安全に保つ方法で解説しています。
どの程度コードをレビューすべきか?
バイブコーディングでは、すべての行を読まないのが普通です。それで構いません。ただし、一部の行は誰かが確認すべきです。
- 個人用ツール: ここで挙げたチェック以外は不要です。
- ユーザーアカウントのあるアプリ: ログインとデータアクセスの仕組みを見直しましょう。AIに平易な言葉で説明してもらい、その説明が自分の想定と一致するかを確かめるだけでも効果があります。
- 決済や機密データを扱うアプリ: 認証、権限、決済処理、個人データを保存する部分について、開発者に確認してもらってください。作り直すのではなく、数時間の作業です。
開発者がいなくても役立つプロンプトです。
このアプリが、どのユーザーを本人と判断し、そのユーザーに何を見せてよいかをどう決めているかを、平易な言葉で説明してください。該当するファイルを示してください。そのうえで、セキュリティレビューの担当者に確認してもらうべき点を挙げてください。
AIが生成したコードのレビュー方法は、AIが生成したコードをレビューする方法で解説しています。レビュー担当者に渡すこともできます。ツールでコードのエクスポートやGitHub同期ができれば、レビューの手配は簡単です。Mythexでは、どちらもProプランに含まれます。
公開前の30分チェック
このチェックは、リンクを身内以外の人と共有する前に行ってください。
アクセス(10分)
- 2つのアカウント、2つのブラウザを用意します。BはAのレコードをURLで開けますか?開けてはいけません。
- ログアウトした状態で、すべてのページのアドレスに直接アクセスしてください。非公開のページは、ログイン画面に戻されるべきです。
- 通常のユーザーとして、管理者用のアドレスを開いてください。アクセスは拒否されるべきです。
秘密情報(5分)
- 上記のプロンプトを使って、すべてのキーがどこにあるかをAIに尋ねてください。
- アプリを開き、ページのソースを表示して「key」「secret」「token」を検索してください。
フォームと悪用(5分)
- すべてのフォームを、空のまま送信し、非常に長い文章を入れて送信し、短時間に2回連続で送信してください。
- サインアップ、ログイン、AI機能に、レート制限が存在することを確認してください。
データと復旧(5分)
- データがどこにあるか、どのように復元するかを把握してください。
- コードを、以前に正常に動いていたバージョンまで戻せることを確認してください。
法的事項と基本事項(5分)
- 個人データを収集する場合は、プライバシーポリシーを追加し、何を収集しているかを明記してください。利用規約とプライバシーポリシーの書き方をご覧ください。
- 公開したアプリがHTTPSを使っていることを確認してください。Mythexを含め、ほとんどのビルダーがこれを自動で対応しています。
すべて問題なければ、初期の公開には十分な状態です。ログイン、権限、データに大きな変更を加えたあとは、手順1から5を繰り返してください。
バイブコーディングのプラットフォームが守ること、守らないこと
優れたプラットフォームは、HTTPS、分離されたワークスペース、プロジェクトごとのデータベース、秘密情報の保管、バックアップ、巻き戻しなど、インフラの多くを担当します。Mythexでは、各プロジェクトに専用の非公開ワークスペースとデータベースを提供し、秘密情報はコードの外に保管し、成功した変更のたびにチェックポイントを保存して元に戻せるようにしています。
ただし、アプリのルールを知ることは、どのプラットフォームにもできません。顧客同士が互いの請求書を見てはいけないこと、クーポンは1回だけ使えるべきことを知っているのは、あなただけです。こうしたルールはプロンプトに書き、テストで確認する必要があります。
結論
バイブコーディングの安全性は、追加したチェックの質によって決まります。個人用ツールなら、キーをコードの外に置けば、そのまま楽しんで構いません。他の人のデータを扱うなら、公開のたびに上記の30分チェックを行い、決済や機密データについては開発者の目を入れてください。実際のプロジェクトでこうしたリスクを見てみたい方はバイブコーディングの事例を、最初からこれらのチェックを組み込んで作りたい方はバイブコーディングでアプリを作る方法をご覧ください。
よくある質問
バイブコーディングは安全ですか?
機密データを含まない個人用ツールやプロトタイプなら安全です。他の人がサインアップしたり、データを保存したり、支払いをしたりするアプリの場合は、バイブコーディングが省きがちなチェックを追加して初めて安全といえます。具体的には、サーバー側のアクセスルール、コードに含めない秘密情報、公開フォームの回数制限、お金や個人データを扱う部分のレビューです。
バイブコーディングで作られたアプリの最大のセキュリティリスクは何ですか?
アクセス制御の不備です。ログインしている1人のユーザーが、別のユーザーのデータを読み取ったり変更したりできてしまう状態を指します。多くの場合、リクエスト内のIDを書き換えるだけで発生します。自分自身でテストしている限りは表面化しないため、非常によく見られます。2つのアカウントで意図的にテストしてください。
AIが生成したコードが私のAPIキーを漏えいさせることはありますか?
はい、キーが訪問者のブラウザで動くコードに入っていたり、公開リポジトリにコミットされていたりすると起こり得ます。キーはツールの秘密情報や環境変数に保管し、外部サービスの呼び出しはサーバーから行い、どこでキーが使われているかの一覧をAIに出してもらいましょう。
バイブコーディングで作ったアプリに開発者のレビューは必要ですか?
個人用ツールや初期のプロトタイプであれば不要です。直接支払いを受ける前、健康・金融・子どものデータを保存する前、または多くのユーザーに公開する前には、開発者のレビューを受けてください。エクスポートやGitHubへのアクセスがあれば、レビューの手配は簡単です。
バイブコーディングのプラットフォームでは、私のコードとデータは安全ですか?
プラットフォームによって異なるため、セキュリティとプライバシーのページを読んでください。Mythexでは、各プロジェクトが専用の非公開ワークスペースと専用のデータベースで動作し、秘密情報はコードの外に保管され、チェックポイントを使って問題のある変更を元に戻せます。ただし、アプリ自体のロジックには、本ガイドのチェックが引き続き必要です。