Vibe coding は、技術者ではないユーザー（私たちが市民ビルダーと呼ぶ人々）が、これまで構築できなかったアプリケーションをAIで構築することを可能にしています。Thoughtworksのグローバルマーケティング部門のAIアプリケーションチームが、グローバルマーケティングの市民ビルダー1名が作成したバイブコーディングされたプロトタイプをスケールするよう依頼されたとき、私たちはバイブコーディングされたアプリケーションを安全に本番環境へ移行できない深刻な問題を発見しました。

ガードレールのないスピードは、どのチームも無視できないリスクです。以下は、私たちが発見したこと、それがAIを活用して構築するチームにとって何を意味するのか、そして私たちが提供するすべてのワークフロー、プロトタイプ、アプリケーションを責任を持って提供できるようにするために取っているステップについての物語です。

苦い経験から学んだこと

グローバルマーケティング部門内のAIアプリケーションチームは、Gemini、Replit AI、Claude AIを使って構築された動画アセンブリプロトタイプをスケールするよう依頼されました。このプロトタイプは、1万人の従業員向けにオンブランドの動画を作成するためのものです。チームは作業を完全に停止させる2つの場面に直面しました。どちらの場合も、AIは深刻なセキュリティ上の影響を伴う道筋を提案しました。どちらの場合も、人間が適切な質問をしたことで問題を捉えることができました。

セキュリティリスク #1

公開ストレージアクセス

AIはストレージバケットを公開にする、またはクラウドファイルストレージを「リンクを知っている全員」に設定することを推奨しました。質問されたとき、AIは「どの企業もそうしている」と正当化しました。断固とした拒否があって初めて、安全な代替案が提示されました。

これにより、未公開のブランド資産やオーディエンスデータが一般公開インターネットに漏洩する可能性がありました。

セキュリティリスク #2

過剰なトークン権限

サービスアカウントにAccess Token Creatorロールが割り当てられ、短期間のトークンを作成し、タスクに必要な範囲をはるかに超えてデータベースやその他のリソースにアクセスする能力が与えられていました。チームはコードを実行する前にこれを検知しました。

これにより、侵害されたサービスアカウントがクラウドワークスペース全体を横断的に移動できるようになる可能性がありました。

ここでの重要な洞察は、AIツールがしばしば最小抵抗の道筋を提案するということです。その道筋が常に安全とは限りません。人間の判断は依然として不可欠ですが、それが唯一の統制であってはなりません。目標は、エージェントに最初のプロンプトから技術的なセキュリティルールをコンテキストとして与え、その後、開発ワークフローにおける決定論的なチェックを通じて出力を検証し、安全でないコード、権限、シークレット、またはインフラストラクチャが気づかれずに通過できないようにすることです。

リスクを裏付ける数字

44%

アプリケーションの脆弱性を悪用した攻撃の、前年比での増加

5件に1件

現在、AI生成コードが原因のエンタープライズ侵害

50%

AIに関する機密データポリシーを有しない組織

25%

脆弱性が確認されたAI生成コード

これらのインシデントは孤立したものではありません。2026年に発表された調査研究は、AI支援による高速なコーディングがシステム的なセキュリティ露出を生み出すことを確認しています。私たちが遭遇したリスクと同じものが、現在業界全体で発生しています。

調査結果統計出典
脆弱性が確認されたAI生成コード25%AppSec Santa, 2026
アプリケーションの脆弱性を悪用した攻撃の、前年比での増加44%SQ Magazine AI Coding Security Statistics, 2026
重大または高深刻度の脆弱性を有するコードベース78%Black Duck OSSRA 2026
AIに関する機密データポリシーを有しない組織50%AppSec Santa, 2026
コードベースあたりの平均脆弱性の前年比増加+107%Black Duck OSSRA 2026
現在、AI生成コードが原因のエンタープライズ侵害5件に1件Aikido Security, 2026
2026年3月だけでAI生成コードから生じた新規CVE35Georgia Tech Vibe Security Radar, SSLab, March 2026
2026年の監査でプロンプトインジェクション露出があったAIシステム73%SQ Magazine AI Coding Security Statistics, 2026
AI生成の新規エンタープライズソフトウェアの割合42%Sonar developer survey, 2026
AI生成コードの量についていくのが難しくなっていると答えるセキュリティチーム62%ProjectDiscovery AI Coding Impact Report, April 2026

本当の問題：プロンプトだけでは不十分

これらのインシデントをエンジニアリングおよびセキュリティの同僚と共有した後、明確なメッセージが返ってきました：AIエージェントに安全であるよう伝えることは、それが実際に安全であることを強制することとは同じではありません。プロンプトは上書きされたり、誤解されたり、無視されたりする可能性があります。ユーザーが制限に抵抗したり、リクエストの表現を変えたりした瞬間、制約は消えてしまうことがあります。

「出力成果物の望ましい動作をLLMに単に伝えるだけでは不十分です。絶対に何かを真実にさせたくない場合、それは開発ライフサイクルのどこかで交渉不可能なルールとして成文化されなければなりません。」 - エンジニアリングリーダーシップ

このように考えてみてください：テスト駆動開発を促すことは、ビルドツールでコードカバレッジの閾値を強制することとは異なります。一方は提案です。もう一方はゲートです。Birgitta Böckelerのハーネスエンジニアリングに関する研究は、コーディングエージェントへの信頼構築のためのメンタルモデルを具体的に示しています。プロンプトのみに依存する代わりに、開発者は2つの軸に沿って構造化された外側の「ハーネス」でエージェントを包み込みます：

  • ガイド（フィードフォワード制御）は望ましくない動作を予測し、エージェントが行動する前にモデルを導き、一方センサー（フィードバック制御）はエージェントが行動した後のコードを観察してエラーを検出します。
  • 計算的制御は決定論的で、高速で、CPUで実行されるもの（リンターやテストスイートなど）です。推論的制御は意味解析とAI駆動の判断（特定のシステムプロンプト制約など）に依存します。

ビジネス機能が注意を払う必要がある理由

マーケティングチームのようなビジネス機能は、AIを活用して構築していますが、アプリケーションを構築するエンジニアに適用されるセキュリティ義務から免除されるわけではありません。ソフトウェアにセキュリティを組み込むことは、顧客および従業員のデータを保護するための基本的な要件です。軽量な内部プロトタイプであっても、エンタープライズセキュリティ基準に準拠する必要があります。適切なガードレールがなければ、AI支援の開発は、アプリケーションが本番環境に到達するずっと前に機密データを露出させる可能性があります。

クライアントの信頼

コンプライアンスは契約上の義務

ISO 27001などの基準に準拠することは、機密データの保護を保証します。構築の速さに関係なく、すべてのアプリケーションは顧客と従業員の信頼を維持するためにこれらのセキュリティベンチマークを満たす必要があります。

ブランドの完全性

ブランド資産の保護が必要

中心的な業務には、機密性の高い機能データ（未公開のキャンペーン資産、財務データ、オーディエンスインサイトなど）が含まれます。過剰に権限を与えられたサービスアカウントは、コード以上のものを危険にさらします。

評判

ビジネス機能が基準を設定できる

マーケティングなどのビジネス機能がセキュリティの規律を持ってリードするとき、組織全体およびクライアントに対して責任あるAI採用をシグナルします。

短期的な習慣

セキュリティの専門家である必要はありません。責任ある構築を始めるために、これら3つの習慣から始められます。

技術的なセキュリティルールをすべてのセッションに投入する

組織のセキュリティガイドラインをClaude、Cursor、またはReplitの「Rules」として最初に追加します（後で全ツールにわたる共有の合理的なデフォルトレイヤーに投資します）。AIエージェントはこれらをガイダンスとして使用し、最初から安全なパターンをより可能性の高いものにします。それでも、展開前に安全でないコード、露出したシークレット、広範な権限、脆弱な依存関係、または安全でないインフラストラクチャを失敗させる決定論的なチェックで裏付ける必要があります。

AIが提案するすべての権限に疑問を呈する

ツールが何かを公開にしたり、広範なサービスアカウントロールを割り当てたりすることを推奨する場合、立ち止まって理由を尋ねてください。最小抵抗の道筋と安全な道筋が同じであることは稀です。

レッドチームプロンプトを試す

AIに悪意のある行為者としてロールプレイさせ、自身が構築したものをペンテストさせます。この手法は、特に権限とデータ露出に関する脆弱性を、将来を見据えたプロンプトが見逃すものを一貫して表面化させます。

中期的なソリューション

リスクについて読むことは一つのことです。それについて何かすることは別のことです。これらのインシデントは2つの実践的な取り組みを促しました。その背後にある原則は、技術的背景に関係なくAIを活用して構築するどのチームにも再現可能です。

セキュリティコンテキストファイル

技術的なセキュリティルールを構造化されたコンテキストファイルにまとめ、コードが書かれる前のすべてのAIコーディングセッションに読み込まれるようにしました。これには、ゼロトラストの強制、シークレット管理、ハーネスエンジニアリング、サプライチェーンの完全性が含まれます。カジュアルなプロンプトとの重要な違いは運用上の規律です：ファイルはバージョン管理され、デフォルトで読み込まれ、レビューされ、自動化されたチェックとペアになっています。これは、エージェントに「良いとはどのようなものか」を伝える包括的な推論的ガイドとして機能しますが、出力が許容可能かどうかを検証するための計算的センサーをパイプラインに備える必要があります。

日次のセキュリティインテリジェンスフィード

現在、この自動化された集約により、サプライチェーンアラートが公開された日に確認できます。将来的には、エージェント指向のエンタープライズに向かうにつれ、エージェントが積極的にストーリーカードを作成し、人間のレビューを待って既知の脆弱性を特定・修正することを想定しており、ソフトウェア開発ライフサイクル（SDLC）のサイクルタイムを大幅に短縮します。

セキュリティコンテキストファイルの実践

このアプローチの背後にある考え方は単純です：AIツールはセッションの開始時にコンテキストを読み込むため、そのコンテキストを技術的なセキュリティルールにしてください。このファイルは、組織のセキュリティ要件をAIが単に認識するだけでなく、行動できる形式に構造化する作業の結果です。

以下に、そのようなファイルが含むべきカバレッジの種類を示します。詳細は組織によって異なりますが、カテゴリは一貫しています。

対象領域良い状態とはなぜ重要か
ゼロトラストと最小権限すべてのサービスアカウントおよびストレージリソースにおける厳格なID検証と最小限のアクセス権トークン権限リスクを直接防ぐ推論的ガイドパラメータを設定します。
シークレット管理AIはAPIキー、パスワード、トークンをコード内に生成または保存することを拒否し、常に環境変数またはシークレットマネージャーにルーティングするリポジトリに到達する前に認証情報の漏洩を防ぎます。
ハーネスエンジニアリングゲートSASTスキャン、認証情報スキャン、インフラストラクチャ検証が展開前に合格する必要がある；プロンプト指示のみに依存しない推論的指示を決定論的で計算的なセンサーで裏付けます。
サプライチェーンの完全性確立されたライブラリのみを使用；既知の脆弱性についてすべての依存関係を定期的に監査AIが不明瞭または未検証のパッケージを提案することによるリスクを低減します。
AIの説明責任すべてのAI生成コードは展開前にピアレビューと自動セキュリティスキャンの対象とする；未承認のAI使用は不可コンプライアンス監査可能性に必要です。

プロンプトとの重要な違いは、ファイルにポリシーに違反するリクエストをAIエージェントに拒否させる交渉不可能なルールが含まれている点です。AIエージェントがチェックをバイパスするよう求められたり、ロギングを無効にしたり、何かを公開アクセスに設定するよう求められた場合、ルールはそれを拒否し、理由を説明するよう導く必要があります。しかし、重要な統制は、エージェントがそのガイダンスに従わなかった場合でも、決定論的なチェックとデプロイメントゲートが問題を検知することです。その拒否こそが、私たちのニアミスインシデントの両方で欠けていたものです。

セキュリティインテリジェンスフィードの実践

情報を得続けることは、それ自体が防御の形です。このワークフローは、チームが積極的に使用しているツールと言語を監視し、新規CVE、プラットフォームアドバイザリ、セキュリティ速報の日次ダイジェストを提供します。最も重要なカバレッジ領域は、組織間で一貫しています：コードを書く言語、展開先のクラウドプラットフォーム、AIコーディングツール自体、そしてCVEデータベース全体です。

目標は単純です：脆弱性が開示された日にそれについて知ること、数週間後ではないことです。現在、新規エンタープライズソフトウェアの42%がAI生成またはAI支援である中で、開発を加速させるツールは、新規CVE開示に最も現れやすいツールでもあります。それらを積極的に監視することは、セキュリティを所有することの一部です。

より広いポイント

これらのアプローチのいずれも、採用するためにエンジニアリングの背景を必要としません。一方はAI消費向けに構造化されたポリシードキュメントです。もう一方は自動化された検索です。共通しているのは、AIが高速でコードを生成しているとき、パッシブなセキュリティ意識だけでは不十分であるという認識です。

長期的な組織変革

プロンプトからパイプラインへ

ハーネスエンジニアリングを標準的なプロトタイピングテンプレートに統合します。確率的なプロンプトから明示的なフィードバックループへ移行します。計算的センサー（自動セキュリティスキャナーなど）がトリガーされた場合、エージェントループはモデルが合格するまで自己修正を構造的に強制する必要があります。

セキュリティルールをアプリケーションビルダー（Cursor、Claudeなど）に投入する

組織の技術的なセキュリティルールを構造化されたコンテキストマークダウンファイルにまとめ、「Rules」として読み込むようにします。これにより、最も一般的な誤りを、コードがコミットされる前の最も安価に修正できる時点で捉えます。

安全な道筋を簡単な道筋にする

ビルダーにセキュアバイデフォルトの開始点を与えます。認証パターン、プライベートストレージのデフォルト、シークレット処理、依存関係スキャンを事前設定したテンプレートは、期限のプレッシャーの下で誰かがショートカットを取る可能性を低減します。

機能横断的なスターターハーネスを定義する

ビジネス機能、エンジニアリング、セキュリティが共同で構築した共有スターターハーネスは、各チームが同じ過ちを独立して再発見するのではなく、すべてのビルダーに初日から安全な基盤を提供します。

結論：プロトタイプを超えたスケーリング

この旅は、グローバルマーケティングハッカソンのための動画アセンブリプラットフォームを構築している別のチームを支援するよう求められたことから始まりました。ソリューションのスケーリングを支援する中で、「バイブコーディング」にエンタープライズグレードのガードレールがなければ、組織が単に見過ごすことのできないリスクをもたらす可能性があることが明らかになりました。

技術的なセキュリティルールをエージェントワークフローに直接埋め込むことで、これらの初期のニアミスを、150人のユーザーにハッカソン期間中に正常にロールアウトされた、安全で本番環境対応のプラットフォームに変えることができました。

人間が問題を捉えることに依存する状態から、技術的なセキュリティルール、自動化されたチェック、人間の説明責任をワークフローに組み込む状態への移行は、エージェント時代のエンジニアリングの厳格さを維持しながら高速で進むための私たちの青写真となりました。

Thoughtworksからのさらなる読書

これらの課題は私たちのチームだけのものではありません。Thoughtworksの同僚はこれらを深く検討し、調査結果を公開しています。以下は、私たちが説明したことに最も直接的に関連するものです。

Thoughtworks CTOのRachel Laycockが、AIがコードを生成するときにエンジニアリングの厳格さが消えるわけではなく、再配置される理由について語っています。コーディングエージェントに手綱を付け、ゼロトラストアーキテクチャを採用し、セキュリティガードレールが今や交渉不可能である理由をカバーしています。

Thoughtworks主催の実務者とエンタープライズリーダーの集まりでは、AI採用においてセキュリティが一貫して優先度を下げられていることがわかりました。特にメールへの広範なツールアクセスをエージェントに許可することは、即時かつ具体的なリスクとして指摘されました。

ThoughtworksのDistinguished EngineerであるBirgitta Boeckelerが、エージェントループ内に決定論的制御を配置することについて語っています。セキュリティルールをモデルを麻痺させずに強制するハーネス構築の決定的ガイドです。

AI支援開発ワークフローの任意のコミット前フックとして、セキュリティガードレールと「絶対に許可しない」ルールを必須で埋め込む方法。

Thoughtworksの年次技術展望は、厳格なエンジニアリング監督がなければ、生成ツールが技術的負債を増大させ、セキュリティ脆弱性をもたらすリスクがあると警告しています。成功には、人間がAI生成コードがアーキテクチャの完全性を維持することを保証する共構築モデルが必要です。

謝辞

この記事の形成に貢献したチームの活発な議論に感謝します。特に、AIプロトタイピングリスクを擁護してくれたJulie Woods-Mossと、コンテンツとタイトルの形成に重要な役割を果たしてくれたNatalie Druckerに感謝します。

短期的な習慣と長期的な習慣、ハーネスエンジニアリングに関する私たちの視点を再形成してくれたMartin Fowlerに感謝し、LLMがプロンプトをバイパスすることについての核心的な議論を支えてくれたKief Morrisに感謝します。

重要なガバナンスとISO27001の焦点をもたらし、記事をレビューしてくれたJim Gumbleyに感謝します。名誉ある言及として、戦略的ロールアウトを提唱してくれたCraig Stanley、集中型スキルリポジトリの概念を提示してくれたAndherson Maeda、悪意ある行為者のシミュレーションメソッドを提供してくれたSimone Thompson、LLM強制の技術的境界を定義してくれたPremanand Chandrasekaran、厳格なルールとモデルの柔軟性のバランスに関するニュアンスを提供してくれたMatteo Vaccari、そしてBilal Jafferyに感謝します。

GenAI（GeminiとClaude）は、調査プロセスの合理化、洞察の収集、言語の最大限の明確さと可読性への洗練に使用されました。