Vibe Coding セキュリティチェックリスト：AI でコードを書くチームのための 10 の規律 · Insights

速度は上がった、規律はまだ追いついていない

Vibe Coding——自然言語で意図を伝え、AI に実装させる手法——は、もはや一部の技術者の実験ではありません。多くのチームで、足場づくりから業務ロジックの実装まで、相当な割合の作業を担うようになっています。

問題は、セキュリティプロセスが「コードは人が書く」という前提で設計されている点です。人は自分がどのライブラリを入れたか覚えていますし、見慣れない依存関係には警戒しますし、Stack Overflow のコードを貼る前に一瞬ためらいます。AI はそのいずれもしません。存在しないパッケージ名、元のライセンスを伴った OSS の断片、学習データから覚えた古い書き方を含めて、極めて自然に見えるコードを高い確信度で出力します。

これは AI によるコード生成に反対する主張ではありません。むしろ逆です。今後も定着し比率が上がり続けるからこそ、それを支える規律を整える必要があります。以下の 10 項目は開発フローの 5 工程に沿って整理しており、そのままチームの規範に書き込める形にしています。

工程 1：プロンプト

規律 1 · 制約は後から直すのではなく、プロンプトに書き込みます。

同じ「ファイルアップロード API を書いて」でも、「プロジェクト既存の validation ユーティリティを使い、新規依存は追加せず、パス処理はディレクトリトラバーサルを防ぐこと」を加えるだけで、得られるコードの質は桁違いに変わります。技術スタックの制約、セキュリティ要件、依存関係ポリシーをプロンプトテンプレートとして蓄積するほうが、コードレビューで毎回指摘するより効率的です。

規律 2 · 機微な文脈は公開モデルに入れません。

本番環境の設定、実際の認証情報、顧客データ、未公開の業務ロジック。これらを公開チャットボットに貼り付けた瞬間、管理下から離れます。チームには明確なデータ分級が必要です。どのコード領域なら公開 AI ツールを使ってよいのか、どこは社内配備モデルを使うのか。この規律の難所は技術ではなく、開発者が迂回しない程度に使いやすい代替環境を用意できるかどうかにあります。

工程 2：生成

規律 3 · AI は多産なジュニアエンジニアであって、シニアの専門家ではありません。

ジュニアのコードがレビューを通るように、AI が生成したコードも同じレビューを通します。違いは生産速度です。AI ははるかに速く出力するため、レビューの仕組みは自動化されている必要があります。生成されたコードを一行ずつ人手で読む運用では、チームのほうが先に消耗します。

規律 4 · コミット時ではなく、生成時にスキャンします。

リスクの発見が遅れるほど、修正コストは上がります。理想的な形は IDE 内でのリアルタイム検出です。AI がコードを書いたその時点で、セキュリティエンジンが汚染解析、依存関係チェック、ライセンス照合を終えている状態です。これが AI 時代におけるシフトレフトの必然的な行き着く先——コード生成の瞬間まで左に寄せることです。

工程 3：依存関係の導入

規律 5 · 依存関係の許可リストを設け、AI にはその範囲内で選ばせます。

AI が依存関係を選ぶ根拠は学習データ上の人気度であり、自社の技術スタック計画でもライセンス方針でもセキュリティ基準でもありません。統制された依存関係の集合の中で AI に作業させるほうが、導入されたライブラリを事後に一つずつ審査するより現実的です。

規律 6 · 存在しないパッケージに能動的に備えます。

AI は実在しないパッケージ名を、まったく自信のある口調で参照します。攻撃者はこうした頻出する架空の名前を組織的に登録しています。これがスロップスクワッティングです。防御は 3 層で考えます。インストール前にパッケージが実在し妥当な公開履歴を持つか検証すること、内部レジストリミラーを運用し内部優先で解決すること、新規依存の初回インストールには人の確認を挟むことです。

規律 7 · 推移的依存も対象です。

AI が導入した 1 つのパッケージが、数十の推移的依存を連れてくることがあります。それらも同様に攻撃面となりライセンス義務の源となりますが、誰の視野にも入らないまま残ります。完全な依存ツリーの解決と継続的な脆弱性照合は、AI 時代の依存関係管理における前提条件です。

工程 4：レビュー

規律 8 · スニペット単位の検出で OSS の再現を捉えます。

AI は学習データ中の OSS コードをそのまま再現することがあります。こうした断片はどの依存関係宣言ファイルにも現れないため、マニフェストのみを読むツールでは検出できません。しかし断片が伴うライセンス義務は現実のものです。スニペット単位の指紋照合が現時点で唯一この種のリスクを可視化する手段であり、AI 生成コードの比率が上がるほど、この能力は「あると良い」から「必要」へと変わります。

規律 9 · レビューの重点は構文ではなく業務ロジックに置きます。

AI が生成したコードは通常、構文的に正しく、スタイルも統一されています。人が書いたものより整っていることさえあります。誤りが生じやすいのは別の場所です。業務ルールの理解のずれ、境界条件の考慮漏れ、権限判定の位置の誤り、緩すぎる例外処理。人のレビュアーは、機械が苦手とするこうした判断にこそ注意を向けるべきで、構文とスタイルはツールに任せます。

工程 5：マージ

規律 10 · 生成元の記録を残します。

どのコードが AI 生成か、どのモデルで、いつ、どのようなプロンプトから。この情報は 3 つの場面で突然重要になります。セキュリティインシデントの追跡、ライセンス紛争での立証、そして今後現れうるコンプライアンス監査への対応です。コストはコミット時にマーカーを 1 つ増やすことだけで、必要になったときに根拠を示せるという利点が得られます。

10 の規律をゲートに変える

10 の規律が文書の中にあるだけでは、定着率は上がりません。有効なのはフローに埋め込むことです。プロンプトテンプレートは IDE プラグインへ、依存関係の許可リストはレジストリ設定へ、スキャンは IDE と CI へ、生成元マーカーはコミットテンプレートへ。そして最後に CI ゲートが導入可否を判定します。基準を満たさないコードは主幹に入りません。

AI はコードの生産速度を一桁引き上げました。セキュリティ能力も同じ速度で追いつく必要があります。これは開発者に負担を課すためではなく、強力な道具を安心して使えるようにするためのものです。

---