AIコーディング導入のセキュリティ設計 4層モデルで攻撃面を整理する

TL;DR

• AIコーディングエージェント導入で増える攻撃面は「権限」「流出」「実行時」「設計判断」の4層に分解できる。
• 4層を別々の人/ツールが担うと、議論の対象が明確になり、ガードレール設計が再利用可能になる。
• まず親記事で全体像を掴み、必要な層から子記事へ進めばよい。

シリーズ記事一覧

本記事は「AIコーディングセキュリティ（ai-coding-security）」シリーズの親記事です。各層の詳細は以下の子記事で解説しています。

1. MCP権限設計の判断軸 allowlist粒度とscope命名から組織導入まで
2. GitHub MCP Server で secret scanning を組み込む AIコーディング時代の流出対策
3. Claude Code hooks の実践パターン集 品質担保・監査・安全制御の3用途
4. 認証・認可設計のやり直しガイド JWT / session / RBAC / ABAC を混乱なく使い分ける
5. AI Agent 認可境界の設計パターン4モデル

はじめに

こんにちは、みねです。

Claude Code、Codex、Cursor といった AI コーディングエージェントを本格導入すると、レビュー速度や設計試行のスループットが一気に上がります。一方で、従来のセキュリティ前提では捉えきれない攻撃面が並列に増えます。prompt injection、過剰な権限、コミット前に滑り落ちるシークレット、生成コードの未検査マージ。どれも「気をつける」では済まないし、「全部禁止する」と AI 導入の利点が消えます。

この記事のゴール:

AIコーディング導入のセキュリティを「4層モデル」で整理し、どこから手を打つかの判断軸を提示すること。

この記事がカバーしないこと:

• 各層の具体的な実装手順（→ 各深掘り記事へ）
• 一般的な OWASP Top 10 / Web セキュリティの基礎（→ 別記事）
• LLM そのもののセキュリティ研究（jailbreak 評価など）

1. 攻撃面の4層モデル

AIコーディング導入時のセキュリティ議論は、混ざると終わりません。「MCP の allowlist の話」「シークレットの話」「hooks で何を検知するか」「そもそも誰が決めるのか」を同時に扱うと、結論が出ないまま時間だけが過ぎます。

層を分けます。

L1〜L3 は「実装」、L4 は「設計判断」です。L4 が無いと L1〜L3 の優先順位が現場ごとに異なり、組織横断で再利用できません。

層を分けるメリット

混ざった議論が分離できる。担当者が決まる。ツール選定が層ごとに独立する。この3点だけで、導入のボトルネックが大きく減ります。

graph TD
    L4[L4 設計判断層] --> L1[L1 権限層]
    L4 --> L2[L2 流出検知層]
    L4 --> L3[L3 実行時制御層]
    L1 -.補完.-> L3
    L2 -.補完.-> L3

L4 が上位にあり、L1〜L3 がそれぞれ独立した実装層として並びます。L1（事前防御）と L3（実行時防御）は補完関係で、L1 で塞ぎきれない領域を L3 で監視します。

深掘り記事: MCP権限設計の判断軸 allowlist粒度とscope命名から組織導入まで

2. 流出と検知 - シークレットを防衛線で止める

L2 はシンプルに見えて、AI コーディング時代に再設計が必要な層です。理由は2つあります。

AIで流出経路が変わった

第一に、AIエージェントはコミット粒度が荒くなりがちです。複数ファイルを一気に編集し、.env.example の更新と .env の編集を取り違えるケースが出ます。第二に、AIが生成するコメント内にAPIキーやエンドポイントが平文で混入する事故が観測されています。プロンプトに含めた情報がそのままコメント化されるためです。

防衛線を3点に設置します。

1. エディタ層: hooks や IDE 拡張で、編集中のバッファに対してパターン検知
2. コミット層: pre-commit フックで gitleaks 等を実行し、commit を止める
3. リモート層: GitHub の secret scanning + push protection を必須化（前提: Public リポは無料で有効化可、Private リポは GitHub Advanced Security ライセンスが必要）

エディタ層だけだと「commit すれば通ってしまう」のでダメ、コミット層だけだと「--no-verify でバイパスされる」のでダメ、リモート層だけだと「履歴に残ってから通知される」ので遅い。3点全部いります。

特に GitHub MCP Server 経由でのコミット/PR 操作を許可している場合、エージェントが pre-commit を回避するルートが増えます。MCP 経由でも secret scanning を強制する設定が必要です。また、MCP ツール応答経由の prompt injection（外部取得結果に仕込まれた指示でエージェントが秘密を外部URLへ送信する）も 2025〜2026 年の主要脅威として無視できません。L2 は「コミット前」だけでなく「エージェントの出力先 URL」も監視対象に含めます。

深掘り記事: GitHub MCP Server で secret scanning を組み込む AIコーディング時代の流出対策

3. 実行時制御と監査 - hooks で何を見るか

L3 はエージェントが「動いている最中」に介入する層です。L1 が「触れる範囲」を事前に絞るのに対し、L3 は「触り方」を実行時に観察・制御します。

Claude Code hooks を例にすると、用途は3つに大別できます。

用途を分ける判断

「hooks に全部入れる」は失敗パターンです。品質担保は CI 側でも担保されるべきで、hooks に集めると CI が壊れた時の代替手段が無くなります。逆に安全制御は hooks でしかタイミングが取れないので、必須で仕込みます。

L1（権限層）と L3（実行時制御層）の役割分担は次の判断で決めます:

• 静的に決まる（このツールは絶対に使わせない）→ L1 で禁止
• 動的に判定が必要（このコマンドが安全かは引数次第）→ L3 で検査

たとえば「git は使わせる、ただし git push --force は本番ブランチにのみ禁止」は L1 だけでは表現できないので L3 の出番です。

深掘り記事: Claude Code hooks の実践パターン集 品質担保・監査・安全制御の3用途

4. まとめ

AIコーディングのセキュリティは、4層に分けると議論が速くなります。

1. L4 から決める: 誰が判断するか、何を許容するかを先に文書化
2. L1 で塞ぐ: 静的に禁止できるものは MCP allowlist / scope で塞ぐ
3. L2 で多層検知: エディタ・コミット・リモートの3点で流出を止める
4. L3 で実行時に補完: 動的判定が必要なものは hooks で押さえる

優先順位に迷ったら、L4 → L2 → L1 → L3 の順で着手するのが安全です。L4 が無いと現場が迷い、L2 が無いと事故が即座に外部公開され、L1 が無いと攻撃面が広いまま、L3 はその上で動的判定を担います。

全層に共通する原則: fail-closed

4層いずれも、検査・判定が実行できなかった場合は deny（fail-closed） に寄せます。hooks 実行失敗、secret scanner クラッシュ、MCP 応答タイムアウトなど、「分からないときは止める」が基本です。fail-open は攻撃者の観点ではバイパスの温床になり、OWASP 2025 A10（Exceptional Conditions）の観点でもアンチパターンです。

各層の実装は独立で進められます。今のチームで一番痛い層から子記事へどうぞ。

• 次に読む: MCP権限設計の判断軸 allowlist粒度とscope命名から組織導入まで
• 次に読む: GitHub MCP Server で secret scanning を組み込む AIコーディング時代の流出対策
• 次に読む: Claude Code hooks の実践パターン集 品質担保・監査・安全制御の3用途
• 次に読む: Node.js セキュリティリリース前にやること 告知から48時間で慌てない準備チェックリスト
• 次に読む: GitHub Agentic Workflows と CI/CD の境界設計 導入判断テンプレ
• 次に読む: AIコーディング組織展開の段階設計 — 本記事の4層セキュリティ設計を、Pilot → Champion → Wave → Steady の組織展開タイムラインに位置づける親記事
• 次に読む: PlanGate v8.6 Hookで承認境界を強制する — L3 実行時制御層で「承認なし、コードなし」を 10 hooks で強制する OSS（s977043/PlanGate）の運用設計