レオは、ソフトウェア開発の素晴らしい近道を見つけたと思ったのです。
今年初め、リードジェネレーション向けマーケティングソフトウェアのスタートアップを創業したレオネル・アセベド氏（プログラミング初心者）が、 AI を用いて完全に作成されたSaaS（Software-as-a-Service）アプリケーションをリリースしました。 彼は、自ら直接コードに触れたことは一度もありませんでした。 その代わりに、彼はAIツールにプロンプト（指示）を入力し、システムに作業を任せたのです。 その後、彼はXの の投稿（ ）を通じて、自身の成果を誇らしげに世界中に伝えました。
大きな間違いでした。
その2日後、彼が作り出したものは攻撃を受けていました。 ハッカーたちは、彼のアプリケーション・プログラミング・インターフェース（API）キーを上限まで使い切り、アプリ間の通信を制御するシステムを実質的に機能停止状態に追い込みました。 彼らは、有料ユーザー以外をブロックするように設計された彼のサブスクリプションシステムを迂回しました。 その後、彼らは彼のデータベースに無作為なエントリを作成し始め、データを好き勝手に改ざんできることを示しました。
「私が犯したミスを公に共有しただけで、ネットユーザーの半数が私のアプリをクラッシュさせようとしている」と、アセベド氏は書き、すぐにアプリを停止させました。 「一番ひどいことって、何だと思いますか？ 「彼らはただ楽しみのためにやっているのです。」
その崩壊は瞬く間に起こり、多くの教訓を与えてくれました。
Vibeコーディング（）とは、AIモデルを用いて、 の自然言語プロンプト（）から完全なアプリケーションを作成する手法であり、ソフトウェア開発の主流な手法となっています。 「プログラミングの参入障壁は、かつてないほど低くなっています」と、Google Brainの創設者であるアンドリュー・ン氏は、月曜日に開催されたSnowflakeのBuildカンファレンスで行われた の講演「 」で述べました。 しかし、Vibeコーディングをこれほど魅力的にしている迅速な開発期間と低コストは、ITセキュリティのレビューがほとんど、あるいはまったく行われないまま、レビューされていない自動生成コードをパイプラインに組み込んでしまうことで、リスクも生み出しています。 その結果、業務を停滞させる可能性のある記録的な数の不具合や、ハッカーが容易に発見・悪用できる脆弱性を含むソフトウェアを使用せざるを得なくなる個人や組織が、今後ますます増えていくことになるでしょう。
「優れたプログラマーであれば、AIから多くの助けを得ることができます。なぜなら、何を探すべきか、そしてどのようにAIを誘導すべきかを理解しているからです」と、RSAカンファレンス（RSAC）リサーチでアプリケーションセキュリティ（AppSec）を担当するシニア・テクニカル・ディレクター、アーレンド・オフトedal氏は述べました。 「しかし、もしあなたが下手なプログラマーであれば、自分が開発しているものをどのようにレビューすべきか理解できていないため、事態はさらに悪化するだけです。」 「ただやみくもに量産しているだけですね。」
「バイブ・コーディング」：良い雰囲気、悪い雰囲気、そしてベンチャーキャピタルにまつわるあれこれ
「vibe coding」という用語は、AI研究者のアンドレイ・カルパシー氏によって最近造語されたものであり、つい先週『 』誌が「 」を今年の言葉に選出したばかりですが、AIを活用してコード作成を導くという手法自体は、決して新しいものではありません。
「プログラミングを始めるためのハードルは、かつてないほど低くなっています。」アンドリュー・ン氏、Google Brainの創設者
実際、その起源は 2010s年の初頭にさかのぼります。当時、研究者たちは、コード補完やプログラム合成のために、 の機械学習におけるニューラルネットワーク――脳の学習メカニズムを大まかにモデル化したソフトウェア――を使い始めました。 これにより、 2016 年のDeepCoderやGoogleの初期のシーケンス・トゥ・シーケンスモデルといったツールの登場への道が開かれ、2020s年初頭には、OpenAIのCodexやGitHub Copilotといったシステムによって、AIを活用したコーディングが主流となりつつありました。
この長きにわたる取り組みの最新の展開として、 のChatGPT（）、GitHub Copilot、Anthropic社のClaude、そしてCursor（アセベド氏が使用していたもの）といった生成型ツールが登場し、コーディングをさらに迅速かつ容易にし、企業にとってより魅力的なものとしています。 Checkmarx/Censuswideによる「 」調査（）によると、昨年、中堅・大企業の開発者の 90％以上が、AIを活用したコード生成を行っていることを認めています。 And 30% to 40% of organizations now actively promote vibe coding, according to a 2024 GitHub survey, presumably to cut costs and accelerate software development lifecycles (SDLs).
[関連記事：バイブ・コーディングとは？ 【メリット、デメリット、および論争点】
公平に言えば、ソフトウェア企業は、競合他社に先駆けて市場に投入するという目的から、完成前にコードをリリースしてきたものです。 新しいオペレーティングシステムやアプリケーションには、数多くの動作上の不具合やセキュリティ上の脆弱性が含まれていることで知られており、企業がそれらにパッチを適用して修正するには数ヶ月を要する場合があります。 における、パッチ適用を先延ばしにするという危険な慣行 が、もはや常態化してしまっています。 しかし、セキュリティの専門家たちが現在懸念しているのは、AIを活用したコーディングによって、あまりにも大規模な脆弱性が生じ、その多くが 決して 特定も修正もされない可能性があるということです。
実際、それはすでに起こっています。 Veracodeが最近実施した「 」調査（）によると、テスト対象となった 100 件以上のAI生成コードサンプルのうち、45％がセキュリティテストに不合格となり、Webアプリケーションに重大なセキュリティリスクをもたらしていました。
こうした懸念があっても、ベンダーや投資家が「バイブコーディング」の流行に飛びつくのを止めることはできません。 In fact, vibe coding tool startups have recently attracted significant venture capital funding, including Cursor-maker Anysphere, which raised $900 million; Replit, which secured $250 million; and Lovable, which raised $200 million.
純粋にセキュリティに特化したものではありませんが、これらのツールの多くには、コードに悪用可能な脆弱性がないかを確認するセキュリティスキャンや、漏洩した認証情報を悪用される前に検出してブロックする自動APIキー保護などの機能が含まれています。 しかし、彼らは問題の検出にとどまりがちで、その根底にある保護策が実際に機能しているかどうかを検証することまでは行わない傾向があります。
Vibe Codingで最もリスクを恐れない人々
新しいツールの急増は、バイブ・コーディングにおいて誰が最も大きなリスクを負っているかという点にも影響を与えています。 Secure Code Warriorの共同創業者兼CEOであるピーター・ダンヒュー氏は、スタートアップ企業はより積極的にこれを採用する傾向にある一方、大企業は依然として人間が出力をレビューする「アシスト型コーディング」にこだわっていると述べました。
「機密データを含むアプリケーションを、それを保護するスキルを持たずに開発することは、災いを招く行為です。」Secure Code Warriorの共同創業者兼CEO、ピーター・ダンヒュー氏
「バイブ・コーディングは、優れた技術力を持つ創業者が迅速な展開を望んでいる小規模なスタートアップで広く採用されていると思います。こうしたスタートアップでは、実際にはコードをじっくり確認することなく、アプリケーションの開発とデプロイを始めてしまうのが実情です」とダンヒュー氏は述べました。
彼は、大企業ほど慎重であると説明しました。 開発者たちは、AIを使って再利用可能な小さなコードの断片を作成することもありますが、それでもデプロイ前には必ず結果を確認しています。
[関連記事：従業員が「シャドウAI」を積極的に活用している――それが企業のデータを危険にさらしている]
一見、より安全に見えるものの、ダンヒュー氏は、そうした点検は単なる誤った安心感を与えるに過ぎない可能性があると警告しました。
Secure Code Warriorの 調査 によると、開発者の 86％がセキュアコーディングを優先していないことが判明しました。また、いくつかの人気のあるLLMツール は、セキュアコーディングの課題、特に認証やセキュリティ設定の誤りといったより主観的なカテゴリーの課題の解決に苦戦していることがわかりました と、ダンヒュー氏は述べました。
Vibeコーディングの盲点と機密データ
ダンヒュー氏は、言語や脆弱性の種類によって違いが生じると指摘しました。 モデルは、コード内のスペルミスや、明確なパターンに従う明らかな問題など、単純なミスを検出する傾向があります。 しかし、彼らは、システムがどのように設計されているかという、より根本的な問題に直面しており、その中には、アプリが誰が何を許可されているかを適切に確認しているかどうかといった点も含まれています。 これにより、見落としが生じます。というのも、AIが生成したコードは表面的には整っているように見えても、ユーザーを危険にさらす脆弱性を依然として含んでいる可能性があるからです。
「 そこが危険なのです。」 一見説得力があり、本番環境で動作するものの、適切なレビューを一度も受けていないコードが出来上がります。 バグは目につく場所に潜んでいます。「」RSAカンファレンス（RSAC）リサーチのシニア・テクニカル・ディレクター、エルレンド・オフトedal氏
同様の傾向は、アプリケーション開発の分野以外でも見られ始めており、 や VibeScamming といった悪用パターンにおいて、自然言語処理AIツールが意図的に利用され、一見正当に見えるものの、従来の信頼性指標を迂回するフィッシングページや詐欺インフラを生成し、急速に改良を繰り返しています。
経験豊富な開発者であれば、こうした隠れた脆弱性に気づくかもしれませんが、初心者の場合、それを見つけるのに必要な経験や直感を持っていない可能性が高いと、ダンヒュー氏は述べました。 彼は、そのリスクを浮き彫りにする最近の事例を挙げています。 昨年の春、コーディングプラットフォーム「Lovable AI」上で作成された 1,645 件のプロジェクトを対象に、による包括的なスキャン（ ）を実施したところ、同ツールで構築された170 のアプリケーションにわたり、303 件の脆弱性のあるエンドポイントが発見されました。これは、分析対象となったプロジェクトの約10％に相当します。
「 の機密データを含むアプリケーション を、それを保護するためのスキルを持たずにコーディングすることは、災いを招くことになりかねません」と彼は述べました。
現在利用可能な技術は、特にコードが大量に生成される場合、セキュリティ上の問題を検出するという課題にはまだ十分に対応できていないため、かえって事態を複雑にしてしまいます。 RSACのオフトedal氏は、「AIを活用したツールが間もなく検知に役立つようになるかもしれませんが、それでもまだ不十分でしょう」と述べました。
「多くの企業は、自社のオープンソース ガバナンス がAIも対象としていると考えていますが、そうではありません」と彼は述べました。 「そこが危険なのです。」 一見説得力があり、本番環境で動作するものの、適切なレビューを一度も受けていないコードが出来上がります。 「虫たちは、目につく場所に隠れているのです。」
[関連記事：自動化のためのAIを正しく活用する方法――効率向上、イノベーションの推進、ITワークフローの変革を実現するための包括的なガイド]
オフトedal氏は、開発者自身が、AIに対してより安全なコードを書くよう促したり、他の信頼できる開発者が採用しているセキュリティ手法を模倣させたりすることで、貢献できると指摘しました。 また、作業を次の段階に進める前に、AIに特定のツールを実行させて自分の作業内容を確認させることもできる、と彼は述べました。
現状把握：CEOやセキュリティ責任者が今すぐ講じるべき措置
ダンヒュー氏やオフトedal氏のような専門家にとって、今後の道筋は、 が透明性 と監督体制を確保することから始まります。
「実用的な『セキュア・バイ・デザイン』の取り組み……は、制御不能な技術的負債や、コストのかかる後期段階のセキュリティ対策に対する特効薬となります。」ダンヒュー
企業のリーダーが、自社のコンピュータネットワーク上に存在する のコンピュータ、タブレット、その他のエンドポイント の膨大な種類を把握し、オペレーティングシステムに関するリアルタイムのデータやパッチ管理 の要件を把握する必要があるのと同様に、の最高情報セキュリティ責任者 は、開発者がどのAIコーディングモデルを使用しているかを把握し、その利用範囲を定める必要がある、と彼らは述べました。 安価な旧型モデルでは、セキュリティ上の脆弱性を含むコードが生成される可能性があります。また、監視体制が整っていない場合――例えば、アプリの構成要素やサードパーティの依存関係をリストアップするための のソフトウェア部品表（SBOM）など――組織は、自社の環境で何が実行されているのか全く把握できていないことがよくあります。
「おそらく、開発者に対して『Claudeのバージョン3以上やChatGPT-4以上は使用してもよいが、それより古いバージョンは使用してはならない』というガイドラインが設けられるような状況になるかもしれません。なぜなら、それより古いバージョンから生成されるコードはセキュリティ上の問題を抱えていることがわかっているからです」とダンヒュー氏は述べました。
開発者の育成は、この方程式のもう一方の要素です。 作家がAIからより優れた文章を引き出す方法を学ぶのと同様に、彼らもプロンプトエンジニアリングや、モデルをより安全な出力へと導く方法を学ぶ必要があります。 全社的なツールが、あらゆる統合開発環境内でポリシーを確実に適用できるようになるまでは、意識啓発と研修が一時的な対策となります。
[関連記事：優れたAI政策はなぜ従業員の教育から始まるのか]
しかし、ダンヒュー氏にとっての指針は「セキュア・バイ・デザイン」であり、これはソフトウェアの開発当初からセキュリティを組み込むことを意味します。
「セキュリティに精通した開発者たちによって支えられる、実効性のある『セキュア・バイ・デザイン』の取り組みこそが、制御不能な技術的負債や、コストのかかる開発後期段階でのセキュリティ対策に対する特効薬なのです」と彼は述べました。 「脅威アクターはすでに企業のセキュリティチームに対して優位に立っていますが、SDLの初期段階からセキュリティを優先することで、形勢を我々に有利な方向へと逆転させることができます。」
ダンヒュー氏は、長期的な懸念として、バイブ・コーディングによってソフトウェア開発が企業の開発パイプラインからリビングルームへと押し出され続け、その結果、 脅威の範囲を拡大させる可能性のある脆弱性がさらに増えることになると警告しました。 プロの開発者であっても完璧とは限りませんが、それでも必要なチェックは確実にこなしています。 プログラミング初心者はそうしません。そして、彼らのソフトウェアが普及するにつれて、攻撃対象領域は拡大し、システムへの信頼は低下していきます。
ダンヒュー氏は、この格差を是正することが、問題がさらに拡大する前に極めて重要であると主張しています。「「このセキュリティ上の問題を解決しなければ、数年後には状況はさらに悪化するだろうと思います」と彼は述べました。
オフトedal氏もその緊急性を強調しました。
「バグはすでにそこら中に広がっています」と彼は言いました。 「今すぐこの問題に取り組まなければ、すでに遅れをとっていることになります。」
