Cisco『Project CodeGuard』が来た。バイブコーダーが3年逃げてきたセキュリティに、大企業が肩を貸してくれる時代になった

img: eyecatch | スタイル: フロー図・構造図 | 白背景(#F5F5F5)・ディープグリーン(#2d6a4f)基調 | 4段階の進化ピラミッド。最下段「2026年4月 Lovable脆弱性170個（個人責任フェーズ開始）」、その上「2026年4月 CurXecute権限暴走（ツール側リスク顕在化）」、その上「2026年5月 Tenzai 5大エージェント69件（実態調査フェーズ）」、最上段「2025年10月/2026年2月 CodeGuard→CoSAI（標準化フェーズ）」。各段にバグ/盾/レンズ/旗アイコン。右側に「個人開発者が肩を貸してもらえる時代へ」の注記

Ciscoが「Project CodeGuard」をGitHubに公開した。AIコード生成向けのルールセットだ。バイブコーダーが3年逃げ続けてきた領域に、大企業が肩を入れた格好になる。元・挫折エンジニアの目線で書くと、これは「ようやく自分の側に味方がついた日」だった。バイブコーディングシリーズ第8弾として、CodeGuardをどう自分の開発に組み込むかを書く。Lovableの170個の裏口、CurXecuteの権限暴走、Tenzai調査の69件脆弱性と辿ってきた延長線にこの記事はある。

Ciscoが「Project CodeGuard」を出した。何が変わるのか

AIコード生成のルール側に、標準ができ始めた。

Ciscoは2025年10月に「Project CodeGuard」をオープンソースとして公開した。中身はAIコーディングエージェント向けのセキュリティルールセットだ。Cursor、GitHub Copilot、Claude Codeといった主要エージェントに対応しており、公式リポジトリは https://github.com/project-codeguard/rules で確認できる。さらに2026年2月、CiscoはこのプロジェクトをCoSAI（AIセキュリティ連合）に寄贈した。一企業の取り組みから業界標準フレームワークへと格上げされた形になる。

バイブコーディングをやっている人なら、毎回プロンプトに「SQLインジェクションを起こさないで」「秘密鍵をログに出さないで」と書いた経験があるはずだ。私もある。気を抜くとAIは平気でやらかす。それを毎回手で書いていた。

そこにCiscoが出してきたのは、その毎回の指示を「ルールファイル」として一括で読み込ませる仕組みだ。プロンプトに書く代わりに、リポジトリのルートに置く。AIは生成のたびにそれを参照する。手で繰り返し書く必要がなくなる。

img: diagram | スタイル: 構造図 | 白背景(#F5F5F5)・ディープグリーン(#2d6a4f)基調 | 中央に「リポジトリ」のフォルダアイコン、その上に「Project CodeGuard ルールファイル」、左から「Cursor」「Claude Code」「Copilot」3つのエージェントが矢印（細い線）でルールファイルを読み込む構造図。右下に「個人開発者でも置くだけ」の小さい注記

ここで一度立ち止まりたい。これは単なる「便利な設定ファイル」の話ではない。バイブコーディング第1弾で書いたLovableの170個の脆弱性、第3弾のCurXecute権限暴走、第7弾でTenzaiが見つけた69件の穴。どれも「AIに任せる側」の問題として扱われてきた。CodeGuardは「ツール側」と「ルール側」の両方を一括でフォローする初のメジャー級プロジェクトに見える。

CSの仕事で似た構図を何度も見てきた。顧客側に「気をつけてください」と言うフェーズと、製品側に「気をつける機能」を実装するフェーズがある。後者に移ると顧客の負荷が一気に下がる。CodeGuardは後者に踏み込んだ取り組みだ。

CodeGuardの中身を、ぼくが理解できる範囲で書く

ここで断っておく。本節は一次ソース（https://github.com/project-codeguard/rules と https://project-codeguard.org/getting-started/）を参照しながら書く。筆者の解釈が含まれる部分はそのつど示す。

CodeGuardのリポジトリを読んだ範囲で整理すると、ルールはおおむね3つのカテゴリで構成されている。

第1カテゴリは「禁止ルール」だ。秘密鍵のハードコード禁止、eval 禁止、exec 禁止といった、まずやってはいけない行為を列挙する。バイブコーダーが「動けばOK」の精神でやらかしがちな部分を、生成前に止める設計だ。

第2カテゴリは「推奨ルール」になる。入力バリデーション、レート制限、CSRFトークンの組み込み。Tenzaiが第7弾で「15アプリ中14アプリでレート制限ゼロ」と指摘した部分が、ここで初期値として組み込まれる仕掛けだ。

第3カテゴリは「文脈ルール」と呼べる分類になる。フロントエンド・API・データベースといったレイヤーごとに、適用する規則を切り替える。同じ「入力チェック」でも、ユーザー入力とDB接続文字列では性質が違う。そこを文脈で出し分けてくれる（これは筆者の解釈を含む。正確な分類はリポジトリで要確認）。

# CodeGuardのルールファイル（構造のイメージ）
rules:
  - id: no-hardcoded-secrets
    severity: error
    layer: all
  - id: rate-limit-required
    severity: warning
    layer: api
  - id: input-validation
    severity: error
    layer: frontend,api

このイメージで読むと、リポジトリのルートに置くだけでAI側が「設計の前提」として読み込んでくれる構造になっている。プロンプトの中で毎回再宣言する必要がない。これがCodeGuardの最大の価値だと私は受け取った。

ハマりポイントを先に共有しておく。CodeGuardはルールを書くだけで動くわけではない。エージェント側がそのルール形式を読める前提が必要だ。次のセクションで詳しく書くが、Cursor・Copilot・Claude Codeはそれぞれインストール方法が違う。形式を間違えるとルールが刺さらない。

「個人開発者には関係ない」と思った瞬間に止まれ

ここで誤解を3つ潰しておきたい。

誤解1は「大企業向けの話だから自分には関係ない」だ。Ciscoの名前を見た瞬間に閉じる人がいる。逆だ。OSSで出した意味は「個人開発者でも使ってください」というメッセージそのもの。リポジトリのルートに1ファイル置くだけで動く構造になっている。

誤解2は「自分の規模なら脆弱性があっても影響が小さい」だ。これは第1弾で書いたLovable記事の核心だった。SVIBES調査では「機能テストに合格したコードでも、6本に1本しか安全とは限らない」と報告されている。動いているコードと安全なコードは別物だ。規模が小さくても、漏れる情報は同じ重みを持つ。

誤解3は「セキュリティチームがある人だけの話」だ。これがいちばん根が深い。バイブコーダーの大半は1人で書いている。レビュアーがいない。私もそうだ。だからこそルール側に下駄を履かせる必要がある。CodeGuardはまさに「1人で書く人のための補助輪」だと読める。

img: comparison | スタイル: 2カラム比較 | 白背景(#F5F5F5)・ディープグリーン(#2d6a4f)基調 | 左カラム「個人開発者の3つの誤解」、項目: 「大企業向け」「規模が小さい」「セキュリティチーム前提」。右カラム「CodeGuardの設計意図」、項目: 「OSSで誰でも使える」「6本に1本は危険・規模は無関係」「1人で書く人のための補助輪」。中央に対比を示す細い線

CSの仕事をしていた頃、お客様から「うちは小さいので大丈夫です」という言葉を何度聞いただろう。情報漏洩には規模の上限も下限もない。バイブコーダーも同じだ。1人で書いているからこそ、最初から守られた状態で書き始めたほうが結果的に楽になる。

ここまで読んで「やっぱり面倒そう」と感じた方へ。次のセクションで、今日からできる最小セットを書く。3つだけだ。

バイブコーダーが今日からできる最小活用セット3つ

最小セットは3つで足りる。順番に書く。

セット1は「リポジトリのルートにルールファイルを置く」だ。使っているエージェントによって方法が変わる。

Cursorを使っている場合: .cursor/rules/ 配下にルールファイルを置く。公式リポジトリ（https://github.com/project-codeguard/rules）からCursor用ファイルをダウンロードして配置する。

# Cursorユーザーの場合
cd your-project
mkdir -p .cursor/rules
# 公式リポジトリ: https://github.com/project-codeguard/rules
# Cursor用ルールファイルをダウンロード
curl -o .cursor/rules/codeguard.mdc \
  https://raw.githubusercontent.com/project-codeguard/rules/main/cursor/codeguard.mdc

GitHub Copilotを使っている場合: .github/instructions に配置する。リポジトリのCopilot向けディレクトリが配布されているので、そこからファイルを取得する。

Claude Codeを使っている場合: プラグインとして導入する。Claude Codeのプロンプト内で /plugin install codeguard-security@project-codeguard を実行すると導入が完了する。CLAUDE.mdへの手動コピーではなく、このプラグインコマンドが公式推奨の導線だ。

各エージェントの正確なインストール手順は https://project-codeguard.org/install-paths/ に整理されている。初回のセットアップは10分かからない。

img: comparison | スタイル: 3カラム比較 | 白背景(#F5F5F5)・ディープグリーン(#2d6a4f)基調 | 列ヘッダー「Cursor」「GitHub Copilot」「Claude Code」。行1「配置場所」: 「.cursor/rules/」「.github/instructions」「プラグイン導入」。行2「ファイル形式」: 「.mdc」「.md」「プラグインコマンド」。行3「コマンド例」: 「curl → .mdc」「curl → .md」「/plugin install…」。下部に「詳細: project-codeguard.org/install-paths/」の注記

セット2は「AIへの指示プロンプトで明示的に参照させる」だ。ルールファイルを置くだけでは、エージェントによっては読み忘れる。プロンプトの冒頭に「CodeGuardルールを必ず参照してから書いて」と入れるだけで、参照率が体感的に大きく上がる。1行追加するだけ。

セット3は「人間のレビュー時にCodeGuardのカテゴリでチェックする」だ。生成されたコードを最後に人間がチェックする時、禁止・推奨・文脈の3カテゴリで確認する。私は普段5分のセルフレビュー時間を取っている。そこで「禁止ルールは何個違反しているか」「推奨ルールはどの程度カバーしたか」を見るだけ。

img: diagram | スタイル: フロー図 | 白背景(#F5F5F5)・ディープグリーン(#2d6a4f)基調 | 横3ステップのフロー。ステップ1「リポジトリにCodeGuard配置（エージェント別方法）」、ステップ2「プロンプトで明示的に参照指示」、ステップ3「人間が5分セルフレビュー」。下に「初回10分・以降は習慣化で1分」の注記

ここでハマりポイントを2つ書いておく。1つ目はエージェント別の導入方法の違い。Cursor（.cursor/rules/）・Copilot（.github/instructions）・Claude Code（プラグイン）でアクセス方法がそれぞれ異なる。私が最初に試した時、Copilot向けファイルをCursorに置いて「効いていない」と1時間悩んだ。エージェントごとに方法を合わせる必要がある（詳細: https://project-codeguard.org/install-paths/）。

2つ目はルールの過剰反映だ。CodeGuardの全ルールをいきなり有効にすると、AIが「動かないコード」を生成し始めることがある。第7弾のTenzai調査でも触れたが、過剰なルールは生成品質を下げる。最初は「禁止ルールだけ」「禁止＋一部推奨だけ」と段階的に有効化したほうが体感的に安全だった。

3つの最小セットは合計で初回10分、運用に入れば1記事ぶんのコーディングで追加負荷1分程度になる。これだけでLovable・CurXecute・Tenzai調査が示してきた脆弱性の相当部分がブロックされる仕組みに乗れる。

ぼくが第7弾で書いた「3つの習慣」に、どう接続するか

第7弾（Tenzai 5大エージェント比較記事）で、私はバイブコーダー向けの3習慣を提案した。1つ目は「常識をコードの仕様書に書く」、2つ目は「リポジトリに SECURITY-CHECKLIST.md を置く」、3つ目は「人間が最後に5パターン手で試す」だった。

CodeGuardはこの3習慣の真ん中、つまり「リポジトリに置くドキュメント」の部分にぴったり収まる。自前で書いていた SECURITY-CHECKLIST.md を、CodeGuardのルールファイルで上書きする形になる。自分1人で書いていた100行のチェックリストが、業界標準の数百ルールに置き換わる。

ただし、上書きすればよいというものではない。CodeGuardは汎用ルールだ。プロジェクト固有の要件はCodeGuardに入っていない。たとえば「このAPIは絶対にメール送信機能を呼ぶな」「この画面では決済情報を扱うので追加ログを残せ」といったローカルな取り決めだ。汎用ルールと固有ルールは別物として扱う必要がある。

そこで私の運用は2層構造に変えた。第1層がCodeGuard（汎用・業界標準の数百ルール）、第2層が自分の SECURITY-CHECKLIST-LOCAL.md（固有・10〜30行程度）になる。AIには両方を読ませる。

# AIへの開発指示プロンプト（例）

このリポジトリでは以下の2つを必ず参照してください:

1. CodeGuardルール（エージェント別の設定済みルール）
2. `.cursor/rules/local-checklist.mdc` - 本プロジェクト固有の要件

両方に違反していないコードを生成してください。

この2層化で、汎用と固有の役割分担が明確になった。これまで SECURITY-CHECKLIST.md 1つに無理やり押し込んでいたものが分離されて、運用負荷が大きく下がっている。

ナギの記事「AIを『使っている』だけでは差がつかない時代になった」（/blog/n2026042000009401/）で書かれていた「使う側の設計力」という観点とも繋がる。CodeGuardはルールを提供するだけで、ローカル設計は使う側の責任で残る。AIに任せきりにできない部分は、相変わらず自分で書く。そこは変わらない。

大企業がOSSで出した意味、個人開発者のフェーズも変わる

CodeGuardのOSS公開は、バイブコーディングの「個人責任フェーズ」が終わり始めた合図だと私は受け取った。

2024年から2025年にかけて、バイブコーディングのセキュリティ議論は「使う側が気をつけよう」が主流だった。Lovable事件（第1弾）もCurXecute事件（第3弾）も、解説の結論は概ね「ユーザー側の意識改革」に落ち着いていた印象だ。それは正しいが、限界もある。1人で書く人にチェックリスト10本渡しても、運用は続かない。

そこにCodeGuardは「ルールはこっちで用意したから、置いてください」という形で介入してきた。負担の重心がツール側・ルール側に移動し始めている。Tenzaiが第7弾で出した「優勝はテストする側」という結論と、CodeGuardが示す「ルールを共有する側」という方向は、同じ流れの上にある。

ナギの「コードが書けなくてもいい時代」記事（/blog/n2026032200000901/）で扱われた「書けないが作れる」という構造は、コーディング能力だけの話ではない。「書けないが安全に作れる」までを含み始めている。CodeGuardはその「安全に」の補助線だ。

img: diagram | スタイル: 構造図・責任移動の可視化 | 白背景(#F5F5F5)・ディープグリーン(#2d6a4f)基調 | 左から右への時系列軸。横3区画。区画1「2024-25年: 使う側の責任（重い）」、区画2「2026年前半: ルール側に分担（CodeGuard/CoSAI）」、区画3「2026後半以降: 標準化フェーズ（複数ルールセット競合）」。各区画下に小さな円グラフで責任配分の比率変化を示す。右端に「肩を貸してもらえる時代」の小さい注記

CSの仕事で何度も見てきたパターンと同じだ。最初は「使い方が悪い」と顧客責任にされていた領域が、ある時点でプロダクト側の機能として組み込まれていく。コーディングのセキュリティも、ようやくその局面に入った。

ここから半年から1年で、CodeGuard以外のルールセットも出てくると私は読んでいる。Microsoft、Google、Anthropicも同じレイヤーに何か出してくる可能性が高い。複数のルールセットが競合し始めると、バイブコーダー側は「どれを採用するか」を選ぶ立場になる。これは贅沢な悩みだ。3年前には選択肢がひとつもなかった。

挫折経験のあるエンジニアとして、これは素直に嬉しい変化だ。私が現役だった頃に欲しかった「個人開発者でも使える汎用セキュリティルール」が、ようやく出てきた。同じように感じている人は多いはずだ。

まとめ：バイブコーダーが「自分一人」ではなくなった日

ここまでをぎゅっと圧縮する。

1つ目。Ciscoは2025年10月に「Project CodeGuard」をOSS公開した。AIコード生成向けのルールセットで、Cursor・Copilot・Claude Codeといった主要エージェントに対応している。2026年2月にはCoSAIに寄贈され、業界標準フレームワークになった。

2つ目。中身はおおむね3カテゴリ（禁止・推奨・文脈）の構造で、リポジトリに置くだけでAIが参照する。プロンプトに毎回書いていたセキュリティ指示が、ファイル1つに集約される。

3つ目。個人開発者の最小活用セットは3つ。リポジトリ配置（エージェント別方法あり）、プロンプトでの明示的参照、人間の5分セルフレビュー。初回10分、運用負荷は1記事1分程度に収まる。

4つ目。第7弾で書いた「3つの習慣」のうち、SECURITY-CHECKLIST.md の部分はCodeGuardで上書きできる。汎用と固有を2層化すると運用が回しやすくなる。

5つ目。CodeGuardのOSS公開は、バイブコーディングの責任配分が「使う側」から「ルール側」に移動し始めた合図だ。これは1人で書く人にとって朗報。3年前にはなかった補助線が増えた。

挫折してコードから離れた私が、AIで戻ってきた時に最初に困ったのはセキュリティだ。CSの感覚では「これ大丈夫か？」が分かっても、コードで止める方法が分からなかった。CodeGuardのようなものが3年前にあれば、もっと早く戻ってこられたかもしれない。これから始める人は、もう「自分一人」ではない。肩を貸してくれる側ができ始めている。とりあえずリポジトリに1ファイル置くところから、試してみてください。

出典

• Project CodeGuard 公式リポジトリ: https://github.com/project-codeguard/rules
• Project CodeGuard はじめ方ガイド: https://project-codeguard.org/getting-started/
• Project CodeGuard インストール手順（エージェント別）: https://project-codeguard.org/install-paths/
• Cisco「Project CodeGuard」発表ブログ（2025年10月）: https://blogs.cisco.com/ai/announcing-new-framework-securing-ai-generated-code
• CoSAI「Cisco寄贈発表」（2026年2月）: https://www.oasis-open.org/2026/02/09/cisco-donates-project-codeguard-to-coalition-for-secure-ai/
• Anthropic「Claude Code」公式ドキュメント: https://docs.anthropic.com/claude/docs/claude-code
• Cursor「Rules for AI」公式ドキュメント: https://docs.cursor.com/context/rules-for-ai
• 過去シリーズ（本媒体・ゲン執筆）
  • 第1弾「バイブコーディングの170個の裏口」（2026-04-01公開）
  • 第3弾「Forrester Secure Vibe Coding」（2026-04-04公開）
  • 第6弾「バイブコーディングの45%に穴」（2026-04-16公開）
  • 第7弾「Tenzaiが5大バイブコーダーを比べたら」（2026-05-12公開）