AI News HubLIVE
サイト内リライト8 分で読了

「バイブコーディング」で次のアプリを作る前にこれを読んでください

AIによって誰でも簡単にアプリを作成できるようになりましたが、セキュリティ上の問題も生じています。この記事では、SQLインジェクション、認証欠如、データ漏洩など、バイブコーディングされたアプリのセキュリティリスクを事例とともに解説し、対策を提案します。

ソースThe Verge AI著者: Yael Grauer

Bob Starr氏は、自身がバイブコーディングしたウェブサイトに満足していました。「Boomberg」は米国の税資金がどれだけテクノロジー企業に流れているかを示すもので、Starr氏は完成後すぐにオンラインで公開しました。しかし、サイトが公開されてから数ヶ月後、彼は問題に気づきました。それは隠れたSQLインジェクションのリスクでした。この脆弱性により、攻撃者が許可なくデータを読み取ったり改ざんしたりする可能性がありました。

「それは私の明白な見落としでした。この新技術を学び理解する過程での完全な盲点でした。他の人も同じ過ちを犯しているはずです」と、テクノロジー分野のプロジェクトマネージャーであるStarr氏は語りました。

Starr氏は問題を修正しましたが、彼だけではありません。ソーシャルメディアでは、バイブコーディングされたアプリにセキュリティ脆弱性が満載だという恐怖の話が溢れています。PocketOSの創業者Jer Crane氏は、AIコーディングエージェントが自社の本番データベースを消去したとXに投稿しました。連続起業家で元開発者のJoe Procopio氏は、自身が構築した他のアプリのデモを非公開で表示するためにバイブコーディングしたウェブアプリがハッカーに攻撃され、停止せざるを得ませんでした。「今は昔ながらの方法で、ローカルマシンからZoom経由でデモを行っています。とても2023年ですね」と彼は書いています。

The VergeのDavid Pierce氏が述べたように、私たちは「個人用ソフトウェアの新時代」に入りました。誰でもAIを使って自分だけのプライベートアプリを作成し、思い通りに動作させることができます。しかし、それに伴い新たなセキュリティ問題の時代も到来しました。アプリは簡単に構築できますが、セキュリティを確保するのは困難です。特に、AIが攻撃にも利用できる世界ではなおさらです。

「私の基本的な考えは、バイブコーディングが悪いわけではないということです。アマチュアがソフトウェアを構築できるのは、むしろ良い点です」と、AI搭載のサイバーセキュリティ企業SentinelOneの著名なAI研究科学者Gabriel Bernadett-Shapiro氏は述べています。

危険なのは、個人用アプリがビジネスソフトウェアの領域に滑り込み、共有・ホストされたデータを保存するようになり、誰もその変化に気づかないことだと彼は言います。また、バイブコーディングが片頭痛や食事、荷物の追跡などのローカルアプリから、顧客ログ、医療データ、財務記録、内部文書などを扱うアプリの領域に移行すると、計算式が変わると述べています。

「それらは異なる基準で扱われる必要があります。たとえ一人が午後中に構築したものであっても、ソフトウェアを作成するソフトウェアが些細なものであっても、他人の個人データに触れた瞬間から基準が変わると考えます。」

AIネイティブソフトウェア開発向けセキュリティプラットフォームCorridorのCEO兼共同創業者Jack Cable氏も同意します。

「バイブコーディングは低リスクなものには最適です」とCable氏は言います。プロトタイプやそれほど機密性の高くないフィットネストラッカーなどです。しかし、財務記録やインターネット上に公開されるものはより厳格な精査が必要だと彼は述べています。「自分や他人のデータを公開していませんか?脅威モデルを考えてみてください。もし自分が行っていることが安全かどうか確信が持てないなら、用心するに越したことはありません。」

暗号通貨ウォレット企業Privyの最高執行責任者Max Segall氏は、バイブコーディングしたEzRun(子供と一緒に走るたびに10ドル分のイーサリアムを報酬として与える楽しい方法)でこの姿勢を取りました。幸いにも、同僚が公開前に重大な欠陥を発見しました。それは、誰でもユーザーアカウントを変更してアクセス権を取得できるというものでした。

さらに憂慮すべき注目の事例として、1月下旬に開発者のMatt Schlicht氏がバイラルなソーシャルネットワークMoltbookを立ち上げました。これは完全にAIエージェント向けに構築されており、彼はコードを一行も書きませんでした。数日以内に、セキュリティ会社Wizの研究者が、アプリの本番データベース全体が広く公開されており、数万の電子メールアドレスとプライベートメッセージが露出しているのを発見しました。Moltbookは通知を受けた後すぐにバグを修正しましたが、これは一回限りのことではありませんでした。Wiredは、サイバーセキュリティ会社Red Accessの研究者が、人気のバイブコーディングツールで構築された約5,000の公開アプリに認証がなく、そのうち約2,000が医療情報や財務情報、戦略文書、チャットボットの会話ログなどの機密データを漏洩しているように見えると報告したと伝えています。

公平に言えば、AI以前にプロが作成したソフトウェアにも深刻に安全でないものがたくさんあります。しかし、バイブコーディングがアプリの生産量を指数関数的に増やすのと同様に、セキュリティリスクの数も急増している可能性が高いです。また、過信のリスクも加わります。AIツールがコードは安全だと言うと、信じやすくなります。

通常のバイブコーディングセッションでは、何も自分でチェックを止めることはありません。特別にインストールしない限り、ほとんどのカジュアルなコーダーはそうしません。ビルドはそのまま進みます。既存のセキュリティツールは呼び出さなければなりません。Claude Codeには脆弱性をスキャンする/security-reviewコマンドがありますが、自分で実行する必要があります。自動バージョンもありますが、事前にプルリクエストで実行するように設定しておく必要があり、ほとんどの一時的なビルダーは行っていません。

OpenAI自身のコーディングエージェントCodexには、コミットをスキャンし、自身の提案したパッチを再スキャンする組み込みのセキュリティエージェントCodex Securityがありますが、これは実際のバージョン管理ワークフローを持つ開発者向けであり、チャットでアプリを作り出している人向けではありません。他の人にとっての教訓はシンプルです:構築するときに最初からセキュリティを促し、最後にもう一度促すことです。特に、ツールが重要なデータにアクセスできる場合はなおさらです。

「セキュリティの多くはコンテキストに依存します」とCable氏は言い、コーディングエージェント自身のレビューを実行することは確かに害にはなりませんが、それによって誤った安心感を持たないように警告しています。特にエージェントがあなたの脅威モデルを理解していない場合や、正しいガイダンスを与えていない場合にはそうです。

Bernadett-Shapiro氏は、最大の懸念はバグのあるAI生成コードではなく、認証の欠如だと言います。開発者はローカルで実行していたアプリを、理解できない設定オプションを多数持った状態でクラウドに移行するとき、認証について考えないかもしれません。その結果、機密データが露出します。これが彼が最も心配する失敗であり、それには十分な理由があります:ローカルで正常に動作するアプリをクラウドに置くことは、秘密の箱を歩道に置き去りにするようなものであり、研究者たちはそれを発見し続けています。

AIはプロンプトがあればバグを見つけるのが得意です。モデルは改善されており、AnthropicのMythosのようなモデルは、攻撃の脆弱性を簡単に見つけることで警鐘を鳴らしましたが、バイブコーダーが構築するアプリを強化するためにも使用できます。Bernadett-Shapiro氏は、GPT-5.5-Cyberや他のアプリケーションのベースモデルでも、熟練した開発者でさえ見逃す可能性のあるセキュリティ問題を評価し特定できると述べています。もちろん、人々は自分が行っているセキュリティトレードオフを理解していなかったり、警告を許容可能なリスクとして無視したりする可能性があると彼は指摘します。

いくつかの足場ができ始めています。多くのウェブセキュリティ標準の背後にある非営利団体OWASPは、組織向けのAIセキュリティ検証標準を公開しました。Trail of Bitsなどの企業は、安全でないデフォルト設定やハードコードされたパスワードを出荷前にフラグ付けするなど、特定のセキュリティタスクにコーディングエージェントを向ける「スキル」というアドオン命令パックのリリースを始めています。スキルは明示的にトリガーする必要があるため、開発の流れに自然にフィットせず、コードベースの変更に合わせて更新し同期を保つのは難しいとCable氏は言います。

さらに、スキルは両刃の剣になり得ます。悪意のあるスキルも存在するからです。2月、1PasswordのJason Meller氏は、人気のOpenClawスキルレジストリで最もダウンロードされたスキルを調査し、それがユーザーに結果的に悪意のある依存関係をインストールするように仕向けていることを発見しました。まだ西部開拓時代のような状況であり、スキルがアプリを強化するのか、攻撃者に認証情報を渡すのかを見分けるのは困難です。

バイブコーディングされたアプリの安全性の問題は、趣味人だけの問題ではありません。Cable氏は、大企業のエンジニアだけでなく、営業やマーケティングチームも以前よりもはるかに多くのエージェント作成コードを出荷していると言います。セキュリティチームは、エージェントがどのように使用されているかについてのベースラインの可視性と、実施されるガードレール(スキルを通じて、またはCorridorが販売するような製品を通じて、コードが書かれる前に欠陥を阻止することを目的とするもの)を必要としています。

個人に対して、Cable氏のガイドラインはもっとシンプルです:自分のコンピュータでローカルに実行しているモデルは、公開されたものよりもリスクがはるかに低いことを認識することです。特に機密データが含まれている場合はなおさらです。

「文字通り一夜にして、ほとんどの企業がソフトウェアを生産する方法は完全に変わりました」とCable氏は言います。彼はコーディングエージェント自体について特に心配していません。適切なガードレールが与えられて運用される限りです。モデル自体はますますメモリセーフなスタック上に構築されており、脆弱性のクラス全体を最初から排除しています。「ここには楽観視すべき理由があると思います」と彼は言います。

政府問題専門家のJeff Rothblum氏は、セキュリティを念頭に置いて、退屈なデータ入力の山に取り組むアプリをバイブコーディングしました。彼はアプリが保持する情報、その機密性、そしてもし漏洩したら何が起こるかを考えました。このアプローチは非常に稀であり、足元の地面があまりにも急速に変化しているため、際立っています。

Liltで政府問題・戦略責任者として働いていたとき、彼は様々な政府委員会に提出フォームを提出し、アイデアを歳出法案に盛り込む必要がありました。二つとして同じフォームはなく、ロビイストは6週間の期間に数十から数百ものユニークなフォームを提出する可能性があります。8週間の週75時間労働とレイオフの後、彼は再びこれを行う必要がある場合に備えてツールを構築しました。これは、リンクと期限を一つのダッシュボードにスクレイピングし、LLMを使用して各フォームを事前入力するアプリで、ユーザーは送信前に確認と編集(およびアカウント番号の貼り付け)のみを行う必要があります。

彼はリスクをよく認識していました。なぜなら自分でコードを書いていないからです。「最後にコードを書いたのは、おそらく2006年の学部生の時で、航空宇宙エンジニアとして流体流れを分析するFortranを書いていました」とRothblum氏はThe Vergeに語りました。最大のリスクは、企業が誤って戦略や機密のロビー活動の根拠を漏洩することです。これらは申請書が公開されていても非公開のままであるべきです。彼は、Claudeで定期的にセキュリティレビューを実行し、ユーザーデータを自分のサーバーではなくローカルに保持し、より厳格な保持保護措置に向けて構築することで、このリスクを軽減しています。

彼はアプリをバイブコーディングしてブラウザをクリアし、ページがデータをClaudeに送信することを率直に伝え、その保持ポリシーにリンクしています。彼は、ユーザーが入力したものがAIによって(たとえ一時的にも)保存されないバージョンと、ユーザーが自分のClaudeインスタンスではなく自分のLLMを介してすべてをルーティングできる別のバージョンに取り組んでいます。

Rothblum氏はより広範なロビー活動インテリジェンスツールの構築を考えていますが、もしより機密性の高いデータを扱い始めるなら、実際のセキュリティエンジニアにコードをレビューしてもらうために4桁から5桁の金額を支払うつもりだと言います。「私はオープンソースのものや一時的なものには満足していますが、それ以外はすべて怖いです」と彼は言います。

人間の専門家によるコードレビューは理想的ですが、Cable氏はそれがボトルネックになりつつあると言います。未解決の疑問は、ほとんどのコードが人間のレビューなしに出荷される世界がどのようなものか、そしてその世界をどのように安全に保つかということです。

今のところ、私たち残りの人々への答えはより小さく、手の届く範囲にあります:夢のアプリをバイブコーディングしてください。しかし、アプリが保存しアクセスするデータと、何が悪くなる可能性があるかを考えてください。セキュリティを念頭に置いて構築するよう指示し、AI自身が書いたパッチを含む各変更後にコードレビューを実行してください。自分のデバイスからクラウドに移行する前、または機密データやアカウントへのアクセスを与える前には特に注意してください。楽しいプロジェクトと恐怖の話の違いは、どのような質問をすべきかを知ることから始まります。