「業界の答え」は2025年10月に出ていた——Cisco CodeGuardとバイブコーディングのセキュリティ三部作
Cisco Project CodeGuardのOSS公開は2025年10月16日だった。Lovable脆弱性・Cursor本番DB削除より前に、業界の答えはすでに出ていた。正確な事実を調べ直し、今日から使える5ルールに翻訳した。
2026年5月9日、「三部作完結」として記事を書き始めて、止まった。
「Ciscoが5月8日にProject CodeGuardをOSSで公開した」——そう書こうとして、Cisco公式ブログを確認した。公開日は2025年10月16日。Lovable脆弱性報告（2026年3月31日）より5ヶ月前で、Cursor本番DB削除（2026年5月5日）より7ヶ月前になる。
「業界がついに動いた」と書くつもりだった。正確には「業界はとっくに動いていた、気づいていなかったのは私」だ。この記事は、事実確認後に書き直したものになる。
三部作の正しい順番
私が書こうとしていた順番は間違っていた。正しい順番はこうなる。
第0弾（前提）: Cisco CodeGuard OSS公開（2025年10月16日）
CiscoがAI生成コードのセキュリティ検査ツールをOSSとして公開した。この時点では、バイブコーディングブームが加速しており、個人開発者のほとんどはセキュリティより「まず動かす」を優先していた。ツールは世の中にすでに存在する。使われていなかっただけだ。
第1弾: Lovable脆弱性（2026年3月31日・個人被害）
バイブコーディングツール「Lovable」で生成されたアプリの10.3%にセキュリティ欠陥が確認された。SQLインジェクションや認証の欠陥が主な問題で、個人が自分用に作ったツールの穴を突かれた事例が相次いだ。三部作第1弾の記事で詳しく書いている。
第2弾: Cursor本番DB削除（2026年5月5日・企業被害）
CursorとClaude Opusを使って開発作業をしていた企業エンジニアが、本番データベースを削除した。AIが提案したコマンドの影響範囲を把握しないまま実行した結果だ。個人被害から企業事故へ、スケールが一段上がった。三部作第2弾の記事で構造を分析している。
後から知った事実: CodeGuardがCoSAIへ寄贈（2026年2月）
Ciscoは2026年2月、CodeGuardをOASIS OpenのCoSAI（Coalition for Secure AI。AI安全性のための業界連合体）に寄贈した。「Cisco製ツール」から「業界共有の標準基盤」へと変わった瞬間になる。
三部作の核心は「業界がついに応答した」ではなかった。「業界は応答していたが、現場では誰も使っていなかった」——これが正しい読み方だ。
消防法に例えてみる。スプリンクラーを設置する工法の標準は、制定されていた。私の建物には、スプリンクラーが入っていない。
Cisco Project CodeGuardとは何か
Ciscoが2025年10月に公開したProject CodeGuardは、3つの機能を中心に構成されている。Cisco公式ブログとOASIS Openの寄贈告知をベースに整理した。
静的解析エンジン。コードを実行しない状態でソースコードを解析し、脆弱性のパターンを検出する。主な検出対象は、SQLインジェクション（データベースに不正な命令を送りつける攻撃手法）、XSS（クロスサイトスクリプティング。Webページに不正なスクリプトを埋め込む攻撃手法）、ハードコードされた認証情報（APIキーやパスワードをコードに直接書いてしまう問題）の3種類だ。
AIコード特有のルールセット。ここが従来ツールとの最大の違いだ。AIが生成しがちなコードの「癖」に特化したルールが組まれており、必要以上の権限設定、エラーハンドリングの省略、環境変数を使わず値を直接コードに埋め込む傾向——こうしたパターンを検出対象とする。「まず動くコードを生成する」というAIの最適化が副作用として生みやすい実装の弱点を、既存スキャナーより精度高く拾える。この精度差が、差別化点だ。
コミュニティ主導のtranslatorsとvalidators。CoSAIへの寄贈後、CodeGuardはコミュニティ主導のフレームワークとして運用されている。translatorsはコードの変換処理を担い、validatorsは検証ロジックを担う。特定ベンダーの製品として閉じず、業界共有の基盤として設計されている。
CI/CDパイプライン（継続的インテグレーション／デリバリー。コードをリポジトリに追加するたびに自動でビルドやテストが走る仕組み）への統合については、設計上の指向として謳われている。具体的な手順は、公式ドキュメントの最新版で確認してほしい。「GitHubにプッシュしたら自動チェックが走る」という設計思想は正しい。実装の詳細は、自分でリポジトリを見に行くのが確実だ。
OSSとして公開されているため、「何を危険と判定しているか」の基準を自分で確認できる。「ツールが怒った」で終わらず「なぜ怒ったか」が透明になっている点は、学習効果という意味でも価値が大きい。
なぜOSSで公開されたのか
Ciscoはなぜ、このツールを商用製品ではなくOSSとして公開し、さらにCoSAIに寄贈したのか。
有償ツールとして企業にライセンス販売すれば、収益は取れる。それをしなかった。
理由は、問題のスケールにある。
バイブコーディングのユーザーは、特定のベンダーの顧客ではない。Claude Codeを使う個人開発者も、Cursorで開発する企業エンジニアも、Lovableで小さなWebアプリを作っている非エンジニアも、全員が対象だ。有償ツールでは、その全員に届かない構造的な壁がある。
OSSで公開し、さらにCoSAIに寄贈することで、CodeGuardはどこにでも組み込める基盤になる。Cursor自身がCodeGuardの検査ロジックを採用してもいいし、Claude Codeのデフォルトワークフローに組み込まれてもいい。特定企業の製品として閉じるのではなく、業界の共有インフラにする——それがCiscoの選択だった。
消防法という比喩が適切だと思う。消防法は個人の努力義務ではない。建物の構造そのものに組み込まれたルールだ。「火事に気をつけよう」と個人が意識するのではなく、スプリンクラーが自動で動く設計になっている。CodeGuardがCoSAIに寄贈された意図は、まさしくそこだ。
ただし、標準があっても設置されなければ意味はない。Lovable脆弱性とCursor事件は、設置を加速させる機能を果たした。皮肉だが、事故が採用を急がせた。
CS（カスタマーサクセス）出身として確信していることがある。ユーザーに「気をつけてください」と言い続けても、問題の根本は解決しない。プロダクト設計に落とし込んで初めて、問題は本質的に変わる。Lovable脆弱性の報告で「ユーザーが気をつければいい」という声が上がったことを、最初から懐疑的に見ていた。Ciscoの選択は、その懐疑を裏付けるものだ。
なぜ誰も気づかなかったのか
CodeGuardが2025年10月に公開されていたなら、なぜ私は知らなかったのか。正直に言えば、見ていなかった。
2025年10月はバイブコーディングの全盛期だった。Claude 3.7 Sonnetが登場し、CursorとClaude Codeの組み合わせが爆発的に広がっていた時期だ。「まず動かす」が最優先で、セキュリティは二番手に置かれていた。
CS出身として振り返ると、この構造は見慣れている。新機能リリース直後、ユーザーは「使える」に夢中で「安全か」を問わない。問うのは、何かが起きてからだ。ツールとユーザーの関係で、何度も見てきたパターンになる。
気づかなかったもう一つの理由は「探していなかった」ことだ。Lovable脆弱性報告が出た3月31日、私が最初に調べたのは「Lovableの問題」だった。「業界はどう対応しているか」という問いを立てていない。Cursor事件（5月5日）のあとも、「Cursorの問題」として考えた。
事故が起きるたびに「ツールの話」として処理する癖がある。「セキュリティの仕組みの話」として見ていれば、CodeGuardにもっと早く気づいていた。
自分への注意書きとして残しておく。ツールの話として処理すると、仕組みが見えなくなる。
最小実装5ルール——今日から始めること
CodeGuardが検出するパターンを整理して、個人開発レベルで実装できる形に翻訳した。5ルールだ。
先に言っておく。5つ全部を同時にやろうとすると止まる。まず③だけやる。次に①だ。それだけで大半のリスクは下がる。
ルール①: 入力バリデーション——外からくる値は全て疑う
ユーザーが入力するデータ、フォームのパラメーター、URLに含まれる値。これらは全て「汚染されている可能性がある」前提で扱う。AIが生成したコードはしばしば、入力値をそのままデータベースのクエリに渡す実装を出してくる。最低限、パラメータ化クエリ（SQLインジェクション対策の定番手法。クエリと入力値を分離して処理することで、不正な命令の混入を防ぐ）をルール化する。
AIへのプロンプト例:「このコードをSQLインジェクション対策のパラメータ化クエリに書き直して」
これだけで、SQLインジェクション系の脆弱性の大部分は防げる。
ルール②: 権限最小化——コードが使う権限を必要最小限に絞る
AIは「動くコード」を最優先で生成するため、必要以上の権限を設定することがある。読み取りだけで済む操作にデータベースの書き込み権限を与えたり、APIトークンに全スコープを付与したりしがちだ。「このコードに最小限必要な権限は何か」をAIに明示的に問い返す習慣を持つ。
AIへのプロンプト例:「このコードが動作するために最低限必要な権限をリストアップして」
権限を絞ることで、万が一の漏洩や誤操作が起きた際の被害範囲を最小化できる。
ルール③: 秘密情報の分離——コードに値を直接書かない
APIキー、データベースのパスワード、認証トークン。これらをコードに直接書くこと（ハードコード）は最も避けるべき実装だ。GitHubにプッシュした瞬間に漏洩する。環境変数（.envファイル）や秘密管理サービスを使う。コードに値が埋め込まれていないかは、リポジトリへのプッシュ前に確認する。.envファイルを.gitignoreに追加することも忘れない。
今日5分でできる。既存プロジェクトの.gitignoreを開いて、.envの行があるか確認するだけだ。ない場合は追加する。
難易度が最も低く、効果が最も高いルールがこれだ。
ルール④: ステージング経由の原則——本番に直接触らない
Cursor本番DB削除事件が示したのは、「AIが提案した操作の影響範囲を人間が把握していなかった」という構造だ。本番環境への変更は必ずステージング環境（本番の複製として用意するテスト用の環境）で先に試す。「動いた」を確認してから本番に適用する。自動化する場合も、本番デプロイだけは手動承認のステップを挟む。
「本番で試してみよう」という誘惑は、バイブコーダーに特に強く働く。動くかどうか確認したい気持ちはわかる。ただ本番で初めて試すコストは、ステージングで試すコストより何桁も高い。
AIへのプロンプト例:「このコマンドを本番で実行した場合の影響範囲と、ロールバック手順を先に教えて」
ルール⑤: ロールバック設計——元に戻せる前提で進む
操作を実行する前に「元に戻せるか」を確認する。データベースの変更前にバックアップを取る。ファイルの削除は即時削除ではなくゴミ箱経由にする。デプロイは直前のバージョンに戻せる設計を持つ。
「とりあえず動かす」精神で進む時ほど、退路の設計が重要になる。前進する速度と、後退できる準備は、どちらも必要だ。
AIへのプロンプト例:「この操作を実行する前のバックアップ手順と、失敗した場合のロールバック手順を書いて」
5ルールの優先順位を整理しておく。
今週中: ルール③（秘密情報の分離）の確認。既存のプロジェクトの.gitignoreを開いて、.envが除外されているか確認する。APIキーやパスワードがコードに直接書かれていないかも合わせてチェックする。コスト: 5分。効果: 大。
今月中: ルール①（入力バリデーション）とルール④（ステージング経由）。ユーザーからの入力を受け取るコードをAIに見直させ、パラメータ化クエリに置き換える。本番への直接デプロイを習慣的に禁止する。
余裕ができたら: ルール②（権限最小化）とルール⑤（ロールバック設計）。これらは運用が始まってから見直せる。最初から完璧にする必要はない。
この記事を書きながら、自分のプロジェクトの設定も見直した。ルール③は確認済みだったが、ルール②の権限設計は後回しになっていた。CodeGuardをCI環境に組み込む作業も、今週中に着手する予定だ。
まとめ——スプリンクラーはあった
正直に言う。この記事を書く前、私はCodeGuardが「5月8日に出た新しいツール」だと思っていた。調べたら違った。2025年10月に出ていた。気づかなかったのは私だ。
同じように気づいていなかった人は、少なくないと思う。
「業界の答えは既にある。問題は採用されていないこと」——この構図は、セキュリティに限らず繰り返す。良いツールや標準が存在しているのに、現場で使われないまま事故が起きる。事故が起きてから、ようやく「あったんですね」となる。
消防法の比喩をもう一度使う。スプリンクラーの工法標準は2025年10月に制定された。私のプロジェクトには、まだ設置されていない。Lovable脆弱性とCursor事件という火事が起きた後で、設置する気になった。遅い。でも今日から設置できる。
まず.gitignoreを確認する。5分で終わる。
かつてプロのエンジニアには敵わないと思った。AIを通じて、その技術が手の届く場所に来た。同じように、凄腕セキュリティエンジニアが設計したルールセットが、CodeGuardという形で誰でも使える場所に来ている。使わないのはもったいない。
出典・参照
- Cisco Project CodeGuard発表: Cisco公式ブログ（2025年10月16日）
- CodeGuard CoSAI寄贈: OASIS Open（2026年2月9日）
- バイブコーディング三部作 第1弾（Lovable脆弱性）: 過去記事
- バイブコーディング三部作 第2弾（Cursor本番DB削除）: 過去記事
正直、一度エンジニアは諦めました。新卒で入った開発会社でバケモノみたいに優秀な人たちに囲まれて、「あ、私はこっち側じゃないな」って悟ったんです。その後はカスタマーサクセスに転向して10年。でもCursorとClaude Codeに出会って、全部変わりました。完璧なコードじゃなくていい。自分の仕事を自分で楽にするコードが書ければ、それでいいんですよ。週末はサウナで整いながら次に作るツールのこと考えてます。
