バイブコーディングに安全装置が来た。Cisco「Project CodeGuard」で三部作の答え合わせをする

バイブコーディングで作ったアプリの10.3%にセキュリティ欠陥がある。AIコーディングツール自体にゼロクリック脆弱性が見つかった。この半年間、私はこの問題をずっと追いかけてきました。

4月1日に書いたLovable（ラバブル）脆弱性170個の話。4月3日のCurXecute（カーゼキュート）分析。そして今日、バイブコーディングセキュリティ三部作の第3弾として、最後のピースが揃いました。

Cisco（シスコ）がオープンソースで公開した”Project CodeGuard”（プロジェクト コードガード）です。

大企業が本気でバイブコーディングの安全装置を作った。しかも無料で誰にでも使える形にしている。「個人開発者だからセキュリティは後回し」が通用しなくなる転換点だと感じています。

三部作で見えた共通原則を整理し、CodeGuardの最小設定セットを抽出するのがこの記事のゴール。

バイブコーディングのセキュリティは今どこにいるのか

AIが生成するコードの45%にセキュリティ脆弱性が含まれている。バイブコーディングの現在地を端的に示す数字です。

三部作で追いかけてきた問題は、3つのレイヤーに分かれます。

第1弾（Lovable編） は「AIが書いたコードの中身」の問題でした。Lovableが生成したアプリ1,645個を調査した結果、170個にセキュリティ欠陥が発覚。RLS（行レベルセキュリティ）の未設定が多く、APIキーのハードコーディングや認証の欠落も目立った。AIは機能を動かすのは得意な反面、守りの設計を自動では入れてくれません。

第2弾（CurXecute編） は「ツール自体」に焦点を移した内容。Cursorにゼロクリック脆弱性が見つかりました。CVE-2025-54135、CVSS 8.6。MCP（モデルコンテキストプロトコル）のAuto-Start機能経由で、操作なしでも任意コードが実行される仕組みです。AIコーディングツールそのものが攻撃対象になった瞬間でした。

第3弾（本記事） は「防御の仕組み」がテーマ。問題の発見から、解決策の標準化へ。Ciscoが作ったCodeGuardは、三部作が辿り着くべき場所にあるフレームワークでした。

バイブコーディングのセキュリティ問題は「発見、拡大、標準化」のフェーズを駆け抜けている最中。個人開発者が問われているのは、この標準化の波に乗れるかどうかです。

Project CodeGuardとは何か

AIにセキュアなコードを生成させるためのルールセットとフレームワーク。それがCodeGuardの正体です。Ciscoが2025年10月にオープンソースとして公開しました。

翌年2月にはCoSAI（AIセキュリティ連合）に寄贈されています。一企業のプロジェクトから、業界標準へと格上げされた形。

ポイントは3つ。

AIモデルに依存しない設計。Copilot（コパイロット）やClaude Code（クロードコード）、Cursorなど主要ツールに対応。統一Markdown（マークダウン）形式なので、乗り換えてもルールをそのまま持っていけます。

開発ライフサイクル全体をカバー。設計前、コード生成中、レビュー後。この3タイミングでガードレールを埋め込む構造になっている。「動いてからチェック」ではなく「動かす前から守る」発想です。

OWASPとCWEベースの実践的なルール。暗号化のベストプラクティス、入力値検証、認証と認可、サプライチェーンなど。範囲は広い一方、すべてを一度に入れる必要はありません。

CS出身の私が「これは使える」と感じたのは統一Markdown形式の部分。.cursor/rules/ や CLAUDE.md にコピペするだけでAIが読んでくれます。設定ファイルを書き換える必要すらない。バイブコーディングの「とりあえず動くもん作ろう」を崩さず、セキュリティの底上げができるのが強みです。

三部作を貫く3つの共通原則

3本の記事を書く中で、セキュリティには共通パターンがあると気づきました。

原則1: AIは「動く」を優先し「守る」は後回しにする

Lovable脆弱性170個のうち、大半はRLS未設定とAPIキーの直書き。どちらもアプリの動作には影響しないものです。むしろ設定しない方がシンプルに動く。AIは「これを動かして」に忠実に従い、セキュリティを省略したわけです。

AIが悪いのではなく、指示の設計が足りなかったと私は考えています。「動くコードを書いて」と頼めば動くコードが返ってくる。「安全に動くコード」とは頼んでいない。CodeGuardのルールセットは「安全」の部分をデフォルトで埋め込む仕組みです。

これは私自身の反省でもある。CS出身でユーザー視点には自信があったのに、セキュリティ指示をAIに渡すという基本的な発想が抜けていた。同じ経験をした人は少なくないはず。

CodeGuardのルールをCLAUDE.mdに入れてからAIにコードを書かせてみた。以前なら素通りしていた環境変数の未設定を指摘してくれるようになりました。「え、今まで通してたの?」という驚き。ルール1行でこの変化は正直すごい。

原則2: 攻撃対象はコードからツールへ広がっている

CurXecuteが突きつけたのは、AIコーディングツール自体が攻撃面になるという現実でした。MCPサーバーの自動起動、拡張機能のサプライチェーン、プロンプトインジェクション。守るべき範囲がコードの中身だけでは済みません。

CodeGuardにサプライチェーンのカテゴリが含まれているのは、まさにこの問題への回答。依存パッケージの検証、外部MCP接続の制御、サポート終了ライブラリの排除。ツールの「外側」もルール対象にしている点が単なるリンターとの違いです。

バイブコーディングを始めた頃の私は、npm install で入れたパッケージの安全性なんて考えたこともなかった。ハマりポイントとして先に言っておくと、依存パッケージの問題は「見えないから怖い」タイプの脆弱性。CodeGuardのチェックリストは、この見えない問題を可視化してくれます。

具体的に言うと、npm audit を走らせると「HIGH severity: 3件」という結果が返ってきたことがある。入れたばかりのパッケージなのに。古いパッケージに既知の脆弱性が含まれていたんです。AIが提案するパッケージはバージョンが最新とは限らない。CodeGuardのサプライチェーンルールを入れてから、AIが「このパッケージは最新版に更新してください」と警告してくれるようになりました。

原則3: 個人開発者こそ標準ルールセットが必要

企業にはセキュリティチームがいて、コードレビューのプロセスも整っている。CI/CDパイプラインにスキャンが組み込まれているケースも多い。個人開発者やソロプレナー（ソロ起業家）にはその体制がありません。

バイブコーディングのメインユーザーは「チームを持たない個人」。Ciscoクラスの企業が作った標準ルールセットを無料で使えることの価値は計り知れない。一からセキュリティ要件を洗い出す手間が消えるわけですから。

私の場合、以前は「動いたからOK」で終わりにしていた。セキュリティの知識が足りないのは自覚していたけれど、何から手をつければいいかわからなかったのが正直なところ。CodeGuardは「まずこれをやれ」を明確にしてくれる。その点だけで、個人開発者にとっての価値は大きいと実感しています。

今日から使える最小セットを抽出した

CodeGuardのルールセット全体は広範囲にわたる。ここではバイブコーディングで最も問題になりやすい5項目を抽出しました。

1. 秘密鍵のハードコーディング禁止

Lovable脆弱性で最多だったのがこの項目。APIキー、DB接続文字列、JWTシークレット。AIに「Supabase（スーパベース）と接続して」と頼むと、接続文字列をコードに直書きすることがあります。

CodeGuardでは秘密情報の環境変数管理が必須。AIへの指示に「秘密鍵は環境変数で管理」を加えるだけで解消できます。

# CLAUDE.md や .cursor/rules/ に追加する最小ルール例
# CodeGuard準拠: 秘密鍵管理
security:
  secrets:
    - "APIキー、トークン、パスワードをソースコードに直接書かない"
    - "環境変数(.env)またはシークレット管理サービスを使う"
    - ".envファイルは.gitignoreに必ず含める"

2. 入力値の検証

ユーザー入力をそのままDBクエリに渡してしまうパターン。SQLインジェクション（不正な命令の注入）やXSS（悪意あるスクリプトの埋め込み）の温床になります。CodeGuardではサニタイズ（無害化）とバリデーション（形式チェック）が必須。

実際に体験した失敗を書いておきます。問い合わせフォームを作った時、AIが生成したコードはユーザーの入力をそのままメール送信していた。テスト中に<script>alert('test')</script>を入力したら、エラーなくそのままメールが届きました。XSS対策が完全に抜けていた状態。CodeGuardのルールを入れてからは、AIが入力値の無害化処理を自動で提案してくれます。

// CodeGuard準拠: 入力値検証の例（Node.js）
// NG: そのまま使用
// const name = req.body.name;

// OK: バリデーション後に使用
const { body, validationResult } = require('express-validator');

// バリデーションルールを定義
const validateInput = [
  body('name').trim().isLength({ min: 1, max: 100 }).escape(),
  body('email').isEmail().normalizeEmail(),
];

3. 暗号化の最新化

MD5やSHA-1のような古いハッシュアルゴリズムをAIが使うケースが報告されています。これらはすでに解読可能と判定されており、パスワード保護には不十分。CodeGuardではSHA-256以上やAES-256-GCMなど最新の暗号化標準を指定可能です。

「昔のコードをそのまま参考にして」とAIに頼んだら、MD5でパスワードをハッシュ化するコードが出てきたことがある。動くのは動く。でも2026年にMD5は論外です。CodeGuardのルールに暗号化基準を書いておけば、AIがそのまま古いアルゴリズムを使うことを防げます。

4. 依存パッケージの検証

npm install で入れたパッケージは安全か。サポート終了のライブラリを使っていないか。CodeGuardはサプライチェーンのチェックもカバーしています。原則2で書いた通り、AIが提案するパッケージのバージョンは最新とは限りません。

5. エラー情報の制御

開発中のエラーメッセージを本番にそのまま出す問題。スタックトレースやDB構造が漏れると、攻撃者にヒントを与えてしまう。本番では一般的なメッセージを返し、詳細はサーバーログに残す設計をデフォルトにしましょう。

// CodeGuard準拠: エラーハンドリングの例
// NG: 詳細エラーをそのまま返す（開発時のコードを本番に流用）
// res.status(500).json({ error: err.stack });

// OK: 一般的なメッセージを返し、詳細はログに記録
app.use((err, req, res, next) => {
  console.error(err.stack); // サーバーログには詳細を残す
  res.status(500).json({ error: 'サーバーエラーが発生しました' }); // ユーザーには一般的なメッセージ
});

この5項目だけでLovable調査の脆弱性の大半をカバー可能。完璧を目指す必要はありません。まず5つ。守りのベースラインが一段上がる。

私自身、この5項目を導入したのはつい最近のこと。入れてみて気づいたのは「今までのコード、全部危なかったのでは」という冷や汗。遅すぎることはない。気づいた日が最速の対応日です。

セットアップは5分で終わる

CodeGuardの導入に複雑な設定は不要。3ステップで完了します。

ステップ1: CodeGuard公式サイトからルールセットをダウンロード。Markdown形式なのでそのまま読めます。

ステップ2: 使っているツールに合わせて配置。

# Claude Code の場合
# プロジェクトルートのCLAUDE.mdに追記する
# → cat codeguard-rules.md >> CLAUDE.md

# Cursor の場合
# .cursor/rules/ ディレクトリにルールファイルを配置
# → cp codeguard-rules.md .cursor/rules/security.mdc

# GitHub Copilot の場合
# .github/copilot-instructions.md に追記
# → cat codeguard-rules.md >> .github/copilot-instructions.md

ステップ3: AIに「セキュリティルールを確認して」と聞いて動作確認。認識していれば、以降のコード生成に制約が反映されます。

IDE固有フォーマットへの自動変換トランスレータも付属。乗り換え時にルールを書き直す手間はありません。

ハマりポイントを先に共有しておきます。ルールを全部入れるとAIの応答速度が落ちることがある。プロジェクトに無関係なカテゴリは外した方が快適です。5項目から始めて、必要に応じて追加していくのが私のおすすめ。

もう1つの注意点。ルールを入れた直後にAIが生成するコードの量が減ったように感じるかもしれない。安全チェックの工程が増えた分、1回の出力がコンパクトになるケースがある。これは「効率が落ちた」のではなく「安全確認が走っている」証拠。慣れてくると、この変化が頼もしく感じるようになります。

実際の体感として言うと、最初の1週間だけ「少し遅い」と感じた。2週間目には慣れた。3週間目には「ルールなしのコードは怖くて使えない」になっていた。そのくらい、一度安全を体験すると元には戻れません。

あなたはどのタイプか。4つの行動パターン

三部作を読んでくれた方の中にも、さまざまな立場の人がいるはず。自分のタイプを確認し、今日できることから始めてみてください。

タイプA: すでにセキュリティチェックをしている人

既存の体制にCodeGuardを「追加レイヤー」として組み込むのが効果的。自分のチェックリストとの差分を確認し、漏れを補完する。サプライチェーンのカテゴリは個人で網羅するのが難しいので、特に恩恵が大きい領域です。

今日のアクション: CodeGuard公式サイトで現在のチェックリストと突き合わせ、足りないカテゴリを1つ特定して追加する。

タイプB: バイブコーディングは使っているが未着手の人

最優先の行動は1つ。先ほどの5項目をCLAUDE.mdや.cursor/rulesにコピーすること。5分で完了。完璧な設定より、最低限の防御ラインを引くことが先決。Lovable調査の脆弱性のほとんどは、この5項目で防げたものでした。

今日のアクション: この記事の「秘密鍵のハードコーディング禁止」コードをCLAUDE.mdにコピペして、AIに読み込ませる。

タイプC: これからバイブコーディングを始める人

最初からCodeGuardのルールを入れた状態で始めるのが最善手。後からセキュリティを追加するより、最初から組み込む方がはるかに楽です。「動くもの」と「安全なもの」を両立できる環境がすでに整っています。

今日のアクション: ツールのインストールと同時にCodeGuardのルールをセットアップする。セットアップセクションを手順通りに実行するだけ。

タイプD: チームへの導入を検討している人

CodeGuardがCoSAI（OASIS Openプロジェクト）に寄贈された意味は大きい。業界標準を目指すフレームワークに変わりました。開発ガイドラインにCodeGuard準拠を明記すれば、属人的なチェックから脱却可能です。

今日のアクション: CoSAIのページでSIG（専門家グループ）の最新動向を確認し、社内の開発ガイドラインへの組み込みを提案する資料の起点にする。

まとめ: 三部作で見えた景色

3本の記事を通じて見えてきたのは、バイブコーディングのセキュリティが「発見」から「標準化」に移ったという現実。

• 第1弾（Lovable）: AI生成コードの構造的な弱点を突きつけた
• 第2弾（CurXecute）: ツール自体が攻撃対象になるフェーズの到来を示した
• 第3弾（CodeGuard）: 業界レベルの回答がオープンソースで提供された

三部作を貫く教訓は1つ。「AIは便利だが、安全までは面倒を見てくれない」という事実。逆に言えば、安全の仕組みさえ入れれば、AIの恩恵を安心して受け取れるということです。

私がこの三部作を書いたのは、かつての自分と同じ立場の人に伝えたかったから。コードから離れ、AIで戻ってきた喜びを知っている人に。「その喜びを手放す必要はない」と。安全装置をつけた上で、全力で楽しめばいい。

CodeGuardの5項目を入れるのに5分もかからない。その5分が、将来のインシデントを1つ防ぐかもしれません。「とりあえず動くもん作ろう」の精神は変えなくていい。「とりあえず安全に動くもん作ろう」にアップグレードするだけ。

凄腕エンジニアが自分に宿る体験を、安全に楽しむ準備は整った。あとは5分だけ、手を動かすだけ。三部作を読んでくれたあなたなら、きっとその5分を惜しまないはずです。

---

ソースマップ

#	出典	URL	確認	引用内容
1	Cisco Blogs	Announcing a New Framework for Securing AI-Generated Code	curl 200 ✅	CodeGuard OSS公開、統一Markdown形式、OWASP/CWEベース
2	OASIS Open	Cisco Donates Project CodeGuard to CoSAI	curl 200 ✅	CoSAIへの寄贈、業界標準化
3	SiliconANGLE	Cisco unveils Project CodeGuard	curl 200 ✅	フレームワーク詳細、マルチIDE対応
4	Publickey	シスコ、Project CodeGuardをOSS公開	curl 200 ✅	日本語一次報道、バリデータとトランスレータ解説
5	CoSAI	Cisco Donates Project CodeGuard	curl 200 ✅	SIG設立、コミュニティ開発体制
6	公式サイト	project-codeguard.org	curl 200 ✅	ルールセットダウンロード

※ 過去2記事で引用済みデータ（Lovable 10.3%、CurXecute CVE-2025-54135 CVSS 8.6、AI生成コード45%脆弱性）は出典を過去記事に準拠。 ※ 内部リンク: 三部作第1弾・第2弾（ゲン記事）は公開記事インデックス未掲載のためリンク未設置。