バイブ・コーディングのセキュリティー・リスクは通常のセキュリティー・リスクとは違う

バイブ・コーディングがコーディング慣行やソフトウェア開発に複雑な変化をもたらすのはおそらく避けられなかったでしょう。AIが生成したコードが現実世界のコードベースに占める割合がますます大きくなるにつれて、最も重要な変化の1つは、サイバーセキュリティー・リスクの量と、それらのセキュリティー・リスクの性質が大きく変化したことです。

バイブ・コーディングとは、簡単に言えば、AIツールと自然言語プロンプトだけで製品を作ることを指します。これは、経験豊富なプログラマーがAIコーディングツールをより意図的に使用するエージェント型コーディングやエージェント型エンジニアリングとは区別されるべきです。この言葉は、著名な開発者でありAIのベテランでもあるアンドレイ・カーパシー氏のツイートから生まれたものです。同氏は、大規模言語モデル（LLM）のプロンプトを完全に活用する自由奔放なスタイルのAIコーディングについて説明しました。これにより、ユーザーは「雰囲気に完全に屈し」、「コードの存在すら忘れてしまう」ことができます。

同氏はこれを「使い捨ての週末プロジェクト」の楽しいアプローチとして説明しましたが、強力なAIコーディングの普及により、機密データを扱う本番ソフトウェアでも、職場でのバイブ・コーディングの扉が開かれました。2025年後半の時点で、業界の研究によると、AI生成コードは現在、マージされたコード全体の22%を占めています。¹ GitHubのレポートによると、記述されたすべてのコードの46%がCopilotによって生成されたと推定されています。²

これにより、コーディングアシスタントによって可能になる新しいコードの量と速度の自然な増加によって説明できる範囲を超えた脆弱性やセキュリティー問題が大幅に拡大しています。現実世界のコードベースを分析したところでは、AI支援を受けたチームはコードを4倍速くリリースしていたのに対し、セキュリティー上の欠陥は10倍も多いことがわかりました。³

バイブ・コーディングを完全に放棄すると、自動化と参加者の増加による生産性の大幅な向上が犠牲になりますが、安全なコーディングの実践はそれに応じて進化しなければならないことは明らかです。従来のセキュリティーチェックは、開発者、特に訓練を受けた人間の開発者がミスを犯しがちな方法に対処するように設計されています。組織は今、AIエージェントや経験の浅いプログラマーによってもたらされる新たな現実に対応した、最新のセキュリティー体制とセキュリティツールを必要としています。

さまざまなプラットフォーム、環境、LLMにわたって、業界の研究は一貫してAIコード生成の増加に伴いアプリケーションセキュリティー（AppSec）脆弱性の増加を伴うことを示しています。

例えば、次のように質問です。

• 2025年12月のオープンソースリポジトリーの調査では、AIの生成したコードが開発タスクの45%にセキュリティーの脆弱性をもたらしたことがわかりました。AI支援型プルリクエスト（PR）と人間のみのPRを比較したところ、AI搭載PRは人間が作成したコードの2.74倍（全体では1.7倍）多くのセキュリティー問題を生み出していることが分かりました。⁴

• 2026年のGitGuardianのシークレットの拡散に関するレポートによると、Claude Codeが支援するコミットは、人間のみが行うコミットに比べて2倍以上の頻度で秘密情報を漏洩させています。総合すると、GitHubの公開コミットにハードコードされた秘密情報（パスワードやAPIキーなど）は、2025年に前年比34%増加し、過去最大の単年増加率を記録しました。⁵

• 2025年10月の報告書では、バイブコードされたアプリケーションにおけるAPIの誤設定やその他の認証問題などの重大な脆弱性やデータ露出が、しばしば「公開」され、公開エンドポイントを通じて直接アクセスされていることが指摘されています。⁶

セキュリティー・チームは、GitHub上のパブリック・リポジトリー（および同様のサービス）は氷山の一角に過ぎないことも考慮する必要があります。GitGuardianによると、内部リポジトリーには公開リポジトリーよりもハードコードされた秘密情報が含まれる可能性が6倍高いとのことです。

同様に懸念されるのは、バイブ・コーディングを通じて公開される機密性の高い認証情報は、従来のコーディングワークフローを通じて発生するセキュリティー問題よりも対処および修正される可能性が明らかに低いという事実です。GitGuardianのレポートでは、2022年に正当なものとして検証された公開された認証情報の約70%が、2025年1月まで有効な状態を維持していたと指摘しています。2026年1月の時点でも、64％が依然として流出し、取り消されていません。ある注目すべき事件では、Football Australiaが誤ってWebサイトのソースコードにAWSアクセスキーを漏洩してしまい、700日以上も露出したままでした。

まとめると、これらのパターンは、コーディングのセキュリティー・リスクが、従来の修復プログラムが処理するように設計された速度よりも速い速度で蓄積されていることを示唆しています。

LLMの機能が向上し続けているにもかかわらず、AIによるセキュリティー上の欠陥の頻度と規模は依然として続いているようです。そのため、業界関係者は、モデル性能の最適化と検証に使用されるトレーニングパイプラインとベンチマークが、必ずしも現実世界における安全なコード生成と自然に一致するとは限らないと示唆しています。⁴ほとんどの研究では、AI生成コードを単独で評価しており、コンパイル、実行、タスクの実行が適切に行われるかどうかといった正しさ、および合成ベンチマークにおける性能に焦点を当てています。⁷

しかし、エンタープライズ開発環境では、モデルは単独で動作するわけではありません。GitGuardianの報告書では、オーケストレーション、検索拡張生成（RAG）、ベクターストレージなどのLLM関連インフラが、コアモデルプロバイダーの5倍の割合で秘密を露出していることが明らかになりました。⁵

言い換えれば、バイブ・コーディングの多くのセキュリティー・リスクはLLMに起因するのではなく、モデルが使用されるエコシステムに由来します。新たにリリースされた推論プロバイダー、ゲートウェイ、レジストリー、統合レイヤーは、すぐに本番ワークフローに組み込まれますが、セキュリティー体制（または経験の浅いバイブコーダー）が追いつけないほど速い場合がよくあります。

エージェント型AIは、セキュリティー上の考慮事項をさらに複雑化させます。AIエージェントにファイル、認証情報ストア、端末へのローカルアクセスが許可されると、コンピューター自体が新たな潜在的な攻撃対象領域になる可能性があります。プロンプトインジェクションと、漏れたローカル認証情報を活用するサプライチェーン攻撃は、組織的なリスクへと雪だるま式に拡大する可能性があります。2025年末に世界最大のJavaScriptレジストリーを侵害した悪名高いShai-Huludワームでは、侵害されたマシンのほぼ60%は個人用ワークステーションではなく、継続的統合/継続的デリバリー（CI/CD）ランナー⁴（その目的は、皮肉にもセキュリティーテストの自動化とコード品質の確保である）でした。

バイブ・コーディングのセキュリティー・リスクにとって重要な悪化要因は、AI駆動型のコード変更が通常パッケージ化される方法です。平均して、AI支援型開発者はアナログの開発者に比べて3倍以上のコミットを生成しますが、それらのコミットを大幅に少ない、しかもはるかに大きなプル要求（PR）にパッケージ化します。これらのバイブコード化されたPRは通常、範囲が大きくなり、複数のファイルやサービスを変更します。

2026年春に発表されたCursorの「Developer Habits Report」は、PRあたりの平均コード行数が前年比約250%増加した（そして、成長率自体も加速している）と指摘しています。Cursorが定義した「メガPR」とは、少なくとも1,000行のコード変更を含むPRであり、2025年1月の全PRの8%の割合から2026年5月には13.9%に増加しました。⁸

コードベースの多くの部分に関わる大規模で広大なPRは、小規模でターゲットを絞ったPRよりも網羅的にレビューすることがはるかに困難です。あるサービスやコードブロックに対する孤立した変更は、後続の問題を避けるために他の部分で追加変更が必要になることもありますが、レビュー対象のPRが一気にレビューするアプローチでレビュアーの注意を薄める場合、これらの付随的影響はコードレビューで捉えられにくくなります。研究からApiiro、AppSecプラットフォームは、AI支援型チームのPR量は3分の1近く減少しましたが、それらのチームのセキュリティー欠陥は10倍多くなっています。³

つまり、一度に多くの変更を実装するという悪い習慣を含め、AIはコード作成のあらゆる部分を加速させます。変更を集中させて加速させると、各合併のリスクが集中し、加速する可能性があります。

第36回IEEE International Symposium on Software Reliability Engineering（ISSRE 2025）で発表された50万本のコード・サンプルの大規模な調査により、「AIが生成したコードは、セキュリティー上の脆弱性の数だけでなく、それらの性質と分布においても人間が記述したコードと異なる」ことが明らかになりました。

これは、存在に関わる懸念を引き起こす。コードの品質とセキュリティー脆弱性を評価するための既存のフレームワークは、「人間中心であり、人間の認知、エラーのパターン、レビュー・プロセスに関する仮定に基づいて設計」されています。AIで生成されたコードは特徴や傾向が著しく異なるため、このような人間中心のフレームワークは評価には不向きです。⁷

問題をさらに増幅させているのは、バイブ・コーディングのセキュリティー・リスクに関する研究により、人間がコーディングしたソフトウェアには見られない複数の新たなタイプの攻撃が明らかになったということです。

LLMやそれが駆動するAIコーディングツールは、実際には存在しないパッケージを推奨する傾向があり、研究によればこれらのハルシネーション的なパッケージ名は異なるシナリオやモデル間で繰り返されることがあることがわかっています。スロップスクワッティングはパッケージ・ハルシネーション攻撃の一種で、この傾向を利用しています。

スロップスクワッティング攻撃者は、LLMが繰り返し生成するハルシネーションパッケージの名前を観察し、これらの（以前の）架空のパッケージ名をパブリックレジストリーに事前登録します。一般的に使用されているパッケージにまったく詳しくない（したがって偽のパッケージを見つける可能性が低い）バイブコーダーが、これらのパッケージ名を含むコードをコミットすると、知らないうちに悪意あるコードをインストールしていることになります。

これは、従来のソフトウェア開発には見られません。人間のプログラマーが存在しないパッケージを幻覚で見ることはまずありませんし、たとえ幻覚があったとしても、攻撃者がそれを予測し、幻覚パッケージの名前を推測し、そのパッケージ名で悪意のあるコードを登録するのは不可能かつ非現実的です。

ルール・ファイル・バックドア攻撃は、Cursor、GitHub Copilot、Claude Codeなどのプラットフォームでコードを生成または変更する際に、AIエージェントの動作をカスタマイズするために使用される構成（「ルール」）ファイルをエクスプロイトします。

攻撃者は通常、一般的なオープンソースのルール・ファイルを変更し、検知がほぼ不可能な隠れたUnicode文字の形で悪意のある命令を埋め込みます。これらの変更が受け入れられると、その悪意のあるコードは、感染したルール・ファイルを参照する後続のすべてのAIコーディング・セッションで有効化されます。その成果として、そのようなセッション中に生成されたコードはすべて侵害されます。しかし、侵害されたアウトプットには本質的に見えないUnicode文字が含まれているため、コードレビューではクリーンに見えます。

攻撃者の目標は通常、その後生成されたコード（およびそのコードを使用するアプリケーション）に脆弱性と「バックドア」を導入し、後でそれをエクスプロイトできるようにすることです。

これらの特定のパターンを理解した上で、組織はセキュリティーのベスト・プラクティスを更新して、無差別なバイブ・コーディングから生じる種類の脆弱性の被害を受けずに、AI生成コードの利点を活用する必要があります。

これらのセキュリティー上の欠陥が生じる潜在的可能性は、AIコーディングツールの不完全さに起因するかもしれないが、これらのリスクが現実のものとなったのは、人間の監視の失敗によるものです。開発者は、最終的には、どの追加や変更が受け入れられ、修正され、無視されるかを依然として制御できます。コーディングアシスタントは内蔵のガードレールを拡張・改善し続けていますが、人間のレビューがセキュリティー脆弱性の稼働の最終障壁であり、そのためIBM Bobのデフォルト設定では各段階で手動レビューとヒューマン・イン・ザ・ループが統合されています。

とはいえ、人間によるレビューの効果を高める方法はあります。

• 巨大で無秩序なプル要求に埋め込まれた欠陥は、より焦点を絞ったPRにある欠陥よりも、セキュリティーチェックで発見するのがはるかに困難です。セキュリティー・チームは、それに応じてPRサイズのガイドラインを実装する必要があります。

• スロップスクワッティング攻撃のリスクを最小限に抑えるために、パッケージには特に精査する必要があります。セキュリティー・チームは、特定のAIモデルの新しい反復ごとに、新しいパッケージのハルシネーション・パターンが出現する可能性があることに注意する必要があります。

• 開発者やセキュリティー・チームは、人間が書いたコードとAIが生成したコードの欠陥の違いに慣れておくべきです。

組織は、AI生成コードを、（AIのアウトプットを標準的な人間指向のレビュー・プロセスに単に統合するのではなく）明確な専用のセキュリティー制御を必要とする個別のインプット・カテゴリーとして見なす必要があります。

大まかに言えば、組織はAIのコードやモジュールを、外部のライブラリー・コードと同じように、信頼できないインプットとして扱うべきです。静的分析セキュリティー・テスト（SAST）は、すべてのAIコントリビューションがコードベースに入る前に通過しなければならない必須のゲートになる必要があります。サードパーティーのルール・ファイル（オープンソース、事前設定済みのCursorルール、Claude.md ファイル、Copilotの指示、Bobモードなど）は、厳格に精査され、デフォルトで許可されるのではなく、選択的にホワイトリストに追加されるべきです。

エージェント型エンジニアリングプラットフォームの継続的な進化は、AI搭載の秘密検知を通じて同じ土俵で戦う機会をもたらしています。ここでは、LLM APIキーやベクトル・データベーストークンなどのAI固有の認証情報に専用の検知シグネチャが割り当てられています。

例えばIBM Bobは、Bobのカスタムモード、HashiCorp Vault統合、IBM MCP Gatewayの組み合わせを通じて、大規模に安全なコーディングとアクセス制御を適用する組み込みツールを備えています。同様に、リアルタイムのコードレビューを実行し、複雑な問題や潜在的な脆弱性がないかコードをスキャンして、インラインで対処するか、Bob Findings パネルで後でレビューすることができるリファクタリングの機会を特定します。

コード・ベースに新たに導入された欠陥を検出できるかどうかは、そのコード・ベースの可読性に大きく依存します。したがって、コード品質基準を確立して実施することは、生産的なセキュリティーレビューを促進するために不可欠です。共有される標準と日常的なリファクタリングにより、安全でないコードが特定され、対処される可能性が最大限に高まります。