Josh Haasは、アイデアをコーディング不要でスケーラブルなアプリに変換するAIビジュアル開発プラットフォームBubbleの共同創業者兼共同CEOです。
こんなシナリオを想像してみてください：あなたは、ニュースやフォーラムで見かけたAIプラットフォームを使って、夢のヘルスケア製品を開発しました。アイデアからプロトタイプへの移行に必要だったのは、一連のプロンプトだけでした。6か月後、実際の患者記録を処理し、需要も増加しています。そんなとき、スタートアップの夢が悪夢に変わります。
ハッキングされたのです。AIがミスを犯し、コードに重大な脆弱性を残していたことが判明しました。気づく前に、すべての医療ファイル、患者全員のソーシャルセキュリティ番号、大量の保険情報が流出してしまいました。
規制当局は責任者を問い、5万人の患者が説明を求めています。
これは仮説的な話ですが、同様のシナリオは既に毎日のように起きています。
本番環境対応？見た目に騙されないために
本番環境のアプリにおけるAI作成コードの割合は急増しています。経験豊富なエンジニアリングチームがコード品質の管理に奔走する一方、多くの非技術系創業者は何が危険なのかを理解していません。数時間や数日でアプリを構築できるという約束に引き込まれていますが、大多数は自分のコードを読むことができず、それを確認するエンジニアリングチームもありません。残念ながら、プロトタイプの見た目は、その表面下に潜むものを隠してしまうことがあります。
これは、中身を知らずに料理を提供するレストランのようなものです。そんな料理を提供したり、注文したりしますか？もちろんしません。しかし、バイブコーディングプラットフォームは、創業者に材料リストを気にせず、見た目と香りだけで判断するよう促しています。
これらのアプリにおける認証システムの欠陥、SQLインジェクションのリスク、ハードコードされたAPIキーなどの脆弱性に関するドキュメントは簡単に見つかります。これらは経験豊富な開発者が夜も眠れなくなるようなセキュリティ上の欠陥であり、AI生成コードにしばしば含まれています。
バイブコーディングツールは、ソフトウェアを構築する能力とそれを安全にする能力を切り離してしまいました。これを修正しなければ、現在のソフトウェア時代はペーパークリップとゴムバンドで継ぎ接ぎされたものになってしまいます。セキュリティ侵害は、大きな被害が出る前に捕捉される単発の事例から、より高いリスクを伴う定期的な出来事へと変わっていくでしょう。
責任の連鎖
では、侵害が発生した場合、誰が責任を負うのでしょうか？
創業者がまず最初にユーザーと向き合い、非難の矛先となります。その理由は明白です：創業者がアプリをデプロイし、ビジネスの顔であり、利用規約に「同意」をクリックしたのですから、「知らなかった」という言い訳は通用しません。
しかし、多くの人はコーディングの専門知識なしでエンタープライズ対応の製品を提供するプラットフォームの犠牲になっています。これらの創業者はセキュリティ実装を評価する技術的知識を持たず、宣伝通りのものを提供するツールを信頼していました。
AIコーディングプラットフォームは責任を転嫁します。彼らは自分たちのツールを「本番環境対応」としてマーケティングしていますが、ほとんどのプラットフォームはコードの品質が大きく変動することを知っています。セキュリティガードレールや必須のコードレビューを実装することもできますが、代わりに責任をユーザーに押し付ける利用規約に頼っています。技術系の創業者は本番環境にプッシュする前に手動で詳細を確認できるかもしれませんが、初めての、あるいは非技術系のビルダーにとっては、高くつく教訓が待ち受けています。
この連鎖の基盤には大規模言語モデル（LLM）のプロバイダーがいます。彼らのモデルは革新的ですが、何十年にもわたる脆弱なパターンで訓練されているため、安全でないコードを生成することがあります。
彼らの主張は通常、「インフラを提供しますが、その使い方はコントロールしません」というものです。確かにその通りですが、これらの企業はソーシャルメディアプラットフォームの教訓から学び、まだ初期段階にある今のうちに適切な安全策を講じる機会があるとも言えます。
現実には、法制度はソーシャルメディアに対応できておらず、これにも対応できていません。現在のフレームワークは、コードをデプロイする人がそれを理解しているか、理解できる人にアクセスできることを前提としています。
安全でないAI生成アプリに関連した集団訴訟やGDPR違反による高額な罰金が既に見られます。さらなる法的問題として、AIツールが帰属表示なしに自分のコードで訓練されたと主張する開発者からの著作権侵害の申し立てもあります。
検証されていないAIコードに起因する最初の10億ドル規模の侵害がこの業界を定義づけることになり、どの創業者も企業もその例となりたくはないでしょう。
共同責任フレームワークの必要性
事後に裁判所がこの問題に答えを出すのを待つことは、ビルダーとプラットフォームの両方にとってリスクがあります。これは、手遅れになる前に共同責任フレームワークを作成する機会です。
それが確立されるまで、創業者の最善の防御策は、選択するプラットフォームに内在するリスクについて自己教育し、アプリをデプロイする際の責任を理解することです。これは、従来のコーディングやより確立されたコーディング代替プラットフォームのセキュリティチェックとバランスを持たない「AI生成」ソリューションを立ち上げることの意味を認識することを意味します。
事後的にAI出力を安全にするだけでは不十分です。開発プラットフォームは「本番環境対応」を定義する必要があります。AIを使用してソフトウェアを構築するプラットフォームは、AIがセキュリティ関連コードに変更を加えることを防ぐため、初日からセキュリティを考慮して設計される必要があります。
業界の一部では既に、セキュリティガードレールを備えたプラットフォームを構築し、制約付き生成を活用してAIの出力を自己完結型モジュールに制限し、セキュリティ関連のミスの機会を制限するように慎重に設計された構造を利用しています。これらのプラットフォームは、すべてのユーザーに対する注意義務を受け入れる基準を設定しています。しかし、エンドユーザーにとって悪影響のリスクを最小限に抑えるためには、すべてのプラットフォームが全面的に取り組む必要があります。
LLMプロバイダーは、セキュリティベンチマークを最適化し、既知の制限と脆弱性を明確に文書化し、多くのソーシャルメディアプラットフォームがしてきたように意図しない結果から自らを免責するのではなく、将来を見据えて構築すべきです。
エコシステム全体として、業界標準、認証プログラム、この新しい現実に合わせた保険商品を推進する必要があります。
選択
現在の道筋は、必然的に壊滅的な侵害、それに続くパニックと反応的な規制へと導き、誰もが敗者となります。代わりに、今すぐ共同責任を受け入れ、安定した基盤の上に業界を構築する機会があります。
早期に行動する企業は単に生き残るだけでなく、次の10年間の責任あるAI開発の定義を推進することになるでしょう。
あなたは崩壊の一部になりますか、それとも解決策の一部になりますか？
