オプション 1
架空のデータを使ってアイデアを試している場合。
使い捨てのプロトタイプを使用しましょう。
実際のアカウントや機密記録へのアクセスを許可せずに、操作の流れをテストできます。それでも、プロトタイプが外部サービスへ送信する内容は確認してください。
信頼できる範囲と限界
次のプロジェクトでバイブコーディングを使っても安全？
バイブコーディングはプロトタイプ作成に役立ちますが、プレビューが動くことはアプリの安全性の証明にはなりません。特に個人データ、シークレット、決済、他人のアカウントを扱う場合、生成されたコードは未レビューの下書きとして扱ってください。
3つの誤解（表）
結論は、アプリが何をするか、そして他の人が使う前に何を確認するかによって変わります。
実際には何なのか
よくある3つの思い込みによって、AIが生成したアプリは実際より安全に見えてしまいます。
1
誤解：動くなら安全
ページが表示されても、不正なアクセス、危険なアップロード、データ漏えいが起こり得ます。見た目を確認するテストでは、アクセス制御が機能しているかは確かめられません。
代わりにすべきこと
ログアウトした訪問者として、また別のユーザーとして操作を試し、サーバー側のチェックを誰かに確認してもらいましょう。
2
誤解：AIは自分の仕事を検証済み
モデルは、依存関係や設定、デプロイ環境での動作を検証していなくても、自信を持ってコードを説明することがあります。
代わりにすべきこと
生成された変更をレビューし、関連するテストを実行して、重要な説明が正しいか実際に動くアプリで確かめましょう。
3
誤解：非公開のプロンプトならシークレットも非公開のまま
認証情報をプロンプトに貼り付けたり、クライアント側のコードに埋め込んだりすると、画面の見た目に関係なく情報漏えいのリスクが生じます。
代わりにすべきこと
テストデータを使い、認証情報をプロンプトやブラウザー側のコードに含めないでください。漏えいした可能性のあるシークレットは更新してください。
守るべき条件
小さなプロトタイプでも、共有する前に、見栄えのよいプレビューだけでは確認できない部分を点検してください。
必須
任意
-
作成やテストには、架空のデータまたは使用が承認されたテストデータを使ってください。 — 実際の顧客情報、パスワード、非公開文書をプロンプトに貼り付けないでください。
-
APIキーやデータベースの認証情報を、ブラウザーに配信されるコードに含めないでください。 — ソースファイルだけでなく、ビルド後のアプリも確認してください。
-
各ユーザーのデータを誰が閲覧、変更、削除できるかテストしてください。 — ボタンを非表示にしても、アクセス権を制御したことにはなりません。
-
ユーザーを招待する前に、依存パッケージとデプロイ設定を確認してください。 — 生成されたコードに、意図しないパッケージや設定が含まれる場合があります。
-
機密性の高い処理は、経験豊富な開発者にレビューを依頼してください。任意 — アプリが金銭、健康情報、または機密記録を扱う場合は、必須にしてください。
関連する安全対策ガイド
これらのガイドを使って、特定のリスクを調べたり、プロジェクトに必要なレビューの程度を判断したりしてください。
レビューの対象範囲
- コードを確認する
- 機密情報を保護する
- 権限をテストする
生成されたコードは、安全性の証明ではなく草案として扱いましょう。
Vibe Codeは、アイデアを動くプロトタイプに近づけるのに役立ちます。ただし、個々のアプリがデータを保護し、権限を適切に適用し、法的要件を満たしていることは保証できません。それらはコード、接続先のサービス、デプロイ環境、テストの結果によって決まります。
初期の実験は、失敗しても影響が小さい範囲にとどめましょう。公開したり実際の情報を収集したりする前に、アプリがブラウザーへ送信する内容を確認し、サーバー側の権限を検証してください。問題が起きた際に誰かに危害が及ぶ可能性がある場合は、適切な資格を持つ専門家のレビューを受けてください。プロンプトの書き方では、これらの確認を代替できません。
使用すべきでない場合
人による監督の程度は、最初の草案を作る速さではなく、ミスが起きた場合の影響に応じて決めましょう。
または
または
または
オプション 2
他の人がサインインしたり、情報を保存したりする場合。
共有する前に技術的なレビューを加えましょう。
認証、認可、バックアップ、削除時の動作は、それぞれ明示的にテストする必要があります。見栄えのよいインターフェースでは、そのどれも検証できません。
オプション 3
アプリが健康、財務、安全、または機密データに関わる場合。
レビューを受けていない生成アプリに頼らないでください。
デプロイ前に、適切な専門知識を持つエンジニアによるレビューと、該当分野の専門家によるレビューを受けてください。プロンプトを使って作成した草案は、どちらの代わりにもなりません。
安全性をめぐる問いはどう変わってきたか
コード生成の進歩により、ソフトウェアを作るスピードは上がりました。しかし、検証が不要になったわけではありません。
-
コードの提案が一般的に
GitHub Copilotのテクニカルプレビューにより、AI生成コードが日常の開発ワークフローに入りました。それでも開発者は、提案されたコードを確認し、テストする必要がありました。
-
チャットによるコード作成が普及
ChatGPTにより、確立した開発ワークフローを持たない人も含め、日常的な言葉でコードを依頼しやすくなりました。
-
バイブコーディングという名前が広まる
この言葉は、望む動作を説明し、結果を見ながら繰り返し修正して作る方法に注目を集めました。その手軽さは、コードレビューを省きたくなる要因にもなりました。
-
公開前の確認は今も重要
試作品を実際のユーザーに提供する前に、データの扱い、権限、依存関係、障害時の動作を、そのアプリの実際のリスクに応じて確認する必要があります。
小さく始めて、検証する
架空のデータを使い、範囲を絞ったアイデアを試しましょう。変更を一つずつ確認し、ユーザーごとに何にアクセスできるかをテストしてください。機密情報を接続したり、影響の大きいアプリを公開したりする前には、立ち止まって専門家のレビューを受けましょう。
よくある質問
AI生成コードの安全性を一律に判断することはできません。架空のデータを使うシンプルなローカルの試作品と、個人情報を保存する公開アプリでは、リスクが異なります。ユーザーに提供してよいか判断する前に、実際のコードとデプロイ設定を確認してください。
完成しているように見える画面からは、サーバー側の権限設定や認証情報の漏えいについて、ほとんど分かりません。ログアウト状態の訪問者や他のユーザーが何にアクセスできるかをテストし、そのリクエストを処理するコードを確認してください。
使用中の秘密情報はプロンプトに入力しないでください。下書きにはプレースホルダーを使い、実際の認証情報は適切なサーバー側の設定で管理してください。認証情報が漏えいしたと思われる場合は、その情報を変更してください。
レビューされていない下書きに、実際の金融情報、健康情報、機密情報を扱わせたり、人に害を及ぼしかねない判断をさせたりする前に、そのまま使うのをやめてください。適切な専門家にレビューを依頼し、生成された画面だけでなく、デプロイされたシステム全体をテストしてください。