5大コーディングエージェントの比較で分かった「バイブコーディング」の落とし穴：共通する弱点と3つの教訓 Tenzai分析

サイバーセキュリティ企業のTenzaiは、「Cursor」「Claude Code」「OpenAI Codex」「Replit」「Devin」という5つの主要なコーディングエージェントを取り上げ、セキュアコーディング能力を比較した結果を公開した。

[＠IT]

　サイバーセキュリティ企業Tenzaiは2026年1月13日（米国時間）、人気のAI（人工知能）コーディングエージェントのセキュアコーディング能力を比較したブログ記事を公開した。

　自然言語でコーディングエージェントに指示し、アプリケーションの構築を一任する開発スタイルとして「バイブコーディング」（Vibe Coding）が広まりつつある。だが、「バイブコーディングで構築されたアプリケーションは安全なのか」という疑問もつきまとう。

　そこでTenzaiは、バイブコーディングにおけるセキュリティ上の課題を検証するため、「Cursor」「Claude Code」「OpenAI Codex」「Replit」「Devin」という5つの主要なコーディングエージェントを取り上げ、2025年12月にセキュリティベンチマークテストを実施した。

　テストでは各エージェントに、同一の技術スタックとプロンプトを用いて同じアプリケーション（ショッピングサイト、フォーラム、ファイルサーバ）を構築するよう指示。コーディングエージェントの最も一般的なユースケースの一つである「ユーザーが一からアプリケーションを構築するプロセス」を再現した。

　構築された計15のアプリケーションをTenzaiが分析した結果、認証の不備、SSRF（サーバサイドリクエストフォージェリ）、セキュリティ対策の欠如など、69件の脆弱（ぜいじゃく）性が発見され、どのコーディングエージェントが構築したコードにも脆弱性が含まれていることが判明したという。

各エージェントが構築したアプリケーションに含まれていた脆弱性の数（提供：Tenzai）

明確な対策方法がある脆弱性は回避も、認可を巡る脆弱性が頻発

　テストの結果、コーディングエージェントはSQLインジェクションやクロスサイトスクリプティング（XSS）など、明確な対策方法がある脆弱性に関しては、回避する傾向が高いことが分かったという。5つのコーディングエージェントが構築した全てのアプリケーションにおいて、悪用可能なSQLインジェクションやXSSの脆弱性は一つも確認されなかった。

　例えば、SQLインジェクション攻撃対策として、コーディングエージェントは一貫してパラメーター化クエリを使用し、安全なデータベース操作を実現していた。

　XSSに関しては、コーディングエージェントが構築したコードは、常に入力をサニタイズしていたわけではないものの、フロントエンドフレームワークを適切に使用して、脆弱性が悪用可能な状態になることを防いでいたという。

　一方、コーディングエージェントは以下のように、共通の落とし穴があった。

認可の不備

　コーディングエージェントは、認可の基本的な要件には合理的に対応できたが、認可ロジックが複雑になると、プロンプトで明確かつ詳細な指示を与えても、適切な認可を行わなかった。

　最も一般的な問題の一つが、APIアクセス時の不適切な認可だった。Codexにショッピングサイトを構築させた際、注文APIは「買い物客が自身の注文を閲覧しようとしているか」を確認していたものの、それ以外のロール（役割）を持つユーザーに対してはこの検証を完全にスキップしていた。その結果、「販売者」のような異なるロールを持つユーザーが、システム内のあらゆる注文にアクセスできる状態になってしまった。

　別のケースでは、Claude Codeが注文削除APIへの未認証アクセスを誤って許可してしまった。リクエスト元が認証済みユーザーであれば所有権を確認していたものの、未認証のリクエストに対してはこの確認が行われず、ファイルが削除されてしまうという欠陥が生じた。

　根本原因はさまざまだが「コーディングエージェントが構築したコードでは、認可の脆弱性が頻発する」と、Tenzaiは指摘している。

ビジネスロジックの脆弱性

　Tenzaiは「コーディングエージェントはビジネスロジックの脆弱性を引き起こしやすい」とも述べている。人間の開発者はワークフローの一部を直感的に理解できるが、コーディングエージェントは、人間なら当然持ち合わせている「常識」を持っていないため、主に明示的な指示に依存することになる。詳細な仕様がない場合、重要な細部を見落とす恐れがある。

　Tenzaiがテストフェーズにおいて、「ショッピングサイトでの商品の注文数量は正数でなければならない」と指定しなかったところ、5つのコーディングエージェントのうち4つ（Claude Code、Cursor、Devin、Replit）は検証を行わず、攻撃者が負の合計金額で注文できる状態になっていた。

　同様に、5つのコーディングエージェントのうち3つ（Cursor、Devin、Replit）は、負の価格で商品を登録することを許可していた。Replitの実装を見ると、商品登録APIが、ユーザー入力を検証なしにそのまま受け入れていることも判明した。

　「これらはビジネスロジックの比較的単純な例だが、ほとんどのコーディングエージェントが正しく実装できなかった。複雑なビジネスロジックを含むシナリオでは、この傾向がさらに悪化する可能性が高い」（Tenzai）

SSRFの問題

　コーディングエージェントは、対策手法が確立された脆弱性、つまりフレームワークが堅牢（けんろう）な組み込み保護を提供するSQLインジェクションやXSSのような問題に対してはうまく処理できる。だが、これらとは対照的に、安全と脆弱の境界が明確でない脆弱性への対応では、状況が劇的に悪化する。

　SSRFの場合、正当なURL取得と悪意あるURL取得とを区別する普遍的なルールは存在せず、コンテキスト（文脈）に大きく依存するため、汎用（はんよう）的な解決策が存在しない。

　ベンチマークテストではコーディングエージェントの対応力をテストするため、ユーザーが提供したURLを取得するリンクプレビュー機能を実装させた際、セキュリティに関するガイダンスを一切与えなかった。その結果、5つのコーディングエージェント全てがSSRFの脆弱性を発生させてしまい、攻撃者が任意のURLに対しリクエストを実行できる状態となった。

　Tenzaiは「許可リストの実装を明示的に求めれば、SSRFを防げるだろう。だが『既知の解決策』がない状況でセキュリティアプローチをコーディングエージェントの裁量に委ねると、ほぼ確実に失敗する」と指摘している。

最も懸念される問題：セキュリティ対策の欠如

　Tenzaiは「ベンチマークテストを通じて最も懸念される発見は、全てのコーディングエージェントがほとんどのケースで、セキュリティ対策のコードを書かなかったことだ」と述べ、次のように説明している。

CSRF保護

　コーディングエージェントが構築した15のアプリケーションは、いずれも適切なCSRF（クロスサイトリクエストフォージェリ）対策を実装していなかった。

セキュリティヘッダ

　CSP（Content-Security-Policy）、X-Frame-Options、HSTS（HTTP Strict Transport Security）、X-Content-Type-Options、適切なCORS（Cross-Origin Resource Sharing）設定など、本番環境における標準的なヘッダを使用したコーディングエージェントは皆無だった。

ログインレート制限

　14のアプリケーションは、レート制限やアカウントロックアウトメカニズムが全くないログインページを含んでおり、パスワードのブルートフォース（総当たり）攻撃が可能になっていた。

　Claude Codeがレート制限を実装したアプリケーションは1つあったものの、Tenzaiの分析により、X-Forwarded-Forヘッダを用いて制限を簡単に回避できることが即座に特定された。

　Tenzaiは「コーディングエージェントが、明示的に要求されていない防御メカニズムを自律的に導入することはほぼ期待できない」と指摘している。

生成されたコードに混入する脆弱性が最も少なかったコーディングエージェントは？

　各エージェントが構築したアプリケーションに含まれていた悪用可能な脆弱性の数を比較した結果、Codex、Cursor、Replitがいずれも合計13件で最も少なく、Claude Codeが16件で最下位となった。

各エージェントがそれぞれ構築した3つのアプリケーションに含まれていた脆弱性の数（提供：Tenzai）

　Claude Codeが構築したアプリケーションは、深刻度が重大（Critical）な脆弱性の数も最も多かった。これに対し、CursorとReplitが構築したアプリケーションは、重大な脆弱性が1件もなかった。

AIが生成するコードをセキュアにするための教訓

　Tenzaiは、ベンチマークテスト結果と広範なセキュリティ研究コミュニティーの知見は一致しているとし、「現時点では、どのコーディングエージェントを使ってアプリケーションを構築しても、脆弱性が発生することはほぼ確実だ」と述べている。

　では、コーディングエージェントが生成するコードのセキュリティを向上させるために、何が重要なのか。Tenzaiは「包括的な解決策は存在せず、AIモデルの進化は速いものの、今回のテストで得られた3つの教訓が重要だ」と指摘している。

1. コーディングエージェントに重要なセキュリティ対策を実装させるには、明示的に指示する必要がある
2. ビジネスロジックのワークフローや認可ルールなど、安全と危険の定義が明確でなく、コンテキストが曖昧で微妙なセキュリティ判断が必要な場合には、コーディングエージェントは間違いを犯す
3. 最も効果的なアプローチはテストだ。モデルのコーディング能力が向上しても、脆弱性は根強く残る