Security 2026年8月28日

第1回 AIで作る時代の攻撃面 — 何が新しく危険になり、どこからが自分の責任か

AI開発セキュリティ実践の第1回。攻撃面をエージェント層・生成物層・実行基盤層の3つに分け、従来のWebセキュリティとの差分、lethal trifecta という設計原則、プラットフォームとの責任分界、そして全12回の読み進め方を整理します。

#情報セキュリティ #プロンプトインジェクション #Claude Code #Codex #リスク管理
難易度基本的な操作を一度試したことがある前提です種別学習コース

この回のキーメッセージ

新しくなったのは「何が危ないか」ではなく「非信頼な入力がどこから入るか」です。攻撃面をエージェント層・生成物層・実行基盤層に分けると、どこまでが自分で設定しなければ守られない範囲かが見えます。

Claude Code や Codex を日常的に使うようになると、コードの生産量は読める量を簡単に追い越します。書く速度は上がりましたが、人が一行ずつ目で追う速度は変わっていません。差分は「誰にも読まれないまま本番へ出るコード」として溜まっていきます。

ここで最初に確認しておきたいのは、従来のWebアプリケーションセキュリティの知識が無効になったわけではない、ということです。認可の抜け、入力検証の欠落、秘密情報のハードコード——事故の中身は以前と同じものが大半です。変わったのは、そこに 開発に使っているエージェント自体が攻撃面になる という層がひとつ積み上がったことと、生成物が人のレビューを通過する割合が下がったことの2点です。

この連載は全12回で、Claude Code / Codex を使い、Cloudflare / Vercel / Supabase でアプリを動かしている開発者を対象にします。扱うのは脅威のカタログではなく、どこを見れば安全か危険かを自分で判断できるか、そして どの設定を自分で入れなければならないか です。第1回では全体の地図を描きます。

1. まず前提を置く — 読まれないコードが増える

「AIは危険なコードを書くのか」という問いは、実務ではあまり有効ではありません。人間も危険なコードを書きます。実務で効いてくるのは、同じ品質のコードでも、人の目を通る割合が下がる という構造の変化のほうです。

秘密情報の混入について、GitGuardian の State of Secrets Sprawl 2026 では、Claude Code の支援を受けたコミットでの秘密漏洩率が 3.2%、全体のベースラインが 1.5% と報告されています。同レポートは 2025年に公開 GitHub コミットへ新規に混入したハードコード秘密を 2,865 万件（前年比 34% 増）としています。

この差は「AIが秘密情報を作り出す」ことを意味しません。テスト用の接続文字列やサンプルキーを含むコードが生成され、確認されないままコミットされる回数が増えた、と読むのが妥当です。つまり レビューの目が減ったことの実測値 に近い数字です。

ここから導かれる方針はひとつです。目視レビューの総量を増やして追いつこうとしないこと。人が見る前に機械で落とせるものは機械で落とし、人が見るべき箇所を絞り込みます。分担の決め方は第7回以降で扱います。

2. 攻撃面を3層に分ける

この連載の背骨になるのが、次の3層モデルです。層を分ける基準は「壊れたときに、最初に何を失うか」です。

層何を指すか壊れたとき最初に失うもの扱う回
エージェント層Claude Code / Codex が手元で持つ権限。ファイル読み書き、シェル実行、ネットワーク到達、MCP 経由の外部サービス開発者のマシンと、そこにある認証情報第2回〜第6回
生成物層AIが書いたコードそのもの。認証・認可、入出力の扱い、外部連携の実装本番環境のユーザーデータ第7回〜第9回
実行基盤層Cloudflare / Vercel / Supabase の設定、秘密情報の保管、依存パッケージ、CI上の2つを含む全部第10回〜第12回

エージェント層 — 手元の権限が攻撃面になる

エージェントは、開発者の権限をそのまま借りて動きます。ホームディレクトリにあるクラウド認証情報も、SSH 鍵も、ブラウザのセッションが載った設定ファイルも、原理的には同じプロセスの視界に入ります。ここが従来との最大の差分です。

各ツールはこの前提のうえで境界を用意しています。たとえば Claude Code のサンドボックスは Bash ツールとその子プロセスに対する OS レベルの強制機構で、ワークツリー外への書き込みを禁止します。ただし読み取りは既定で広く許可されており、~/.ssh や ~/.aws/credentials も読めます。これを塞ぐには sandbox.credentials や denyRead を明示的に設定する必要があります。ネットワークはサンドボックス外のプロキシ経由で制御され、既定では許可ドメインがひとつもありません。ただし適用対象は Bash 系の実行であり、Read/Edit や MCP、Hooks は別のレイヤーです。「サンドボックスを有効にしたから全部安全」とは読めません。

権限の具体的な設計は第2回（Claude Code）と第3回（Codex）で扱います。仕様そのものは既存記事の Claude Code の初期設定 と Codex の承認モードとサンドボックス にあります。

生成物層 — 従来のレビュー観点が効く場所

ここは新種の脅威が出てくる場所ではありません。OWASP Top 10 の 2025年版で1位を維持している Broken Access Control をはじめ、認可の判断がクライアント側に寄っている、リソースの所有者チェックが抜けている、といった古典的な欠陥がそのまま出ます。

注意したいのは、AIが書くコードは 見た目の完成度が高い ことです。命名は整い、エラーハンドリングの体裁も揃っているため、認可チェックが1行足りないことに気づきにくくなります。レビュー観点を暗黙知のままにせず明文化する必要があるのはこのためです。第7回で全体像、第8回で認証・認可、第9回で入出力と外部連携を扱います。

実行基盤層 — 設定は生成物ではない

デプロイ先の設定、秘密情報の置き場所、依存パッケージ、CI のワークフロー。ここはコードレビューの視野から外れやすい一方、壊れたときの影響範囲が最も広い層です。OWASP Top 10 の 2025年版で Software Supply Chain Failures が独立したカテゴリとして新設され、Security Misconfiguration が5位から2位へ上がったことは、この層の比重を示しています。第10回から第12回で扱います。

層が違えば打つ手が違う

「APIキーが漏れた」という同じ事象でも、層によって対処はまったく別になります。

起きたこと層効く対策
エージェントが .env を読み、その内容が外部へ渡ったエージェント層読み取り自体を Hooks / 権限設定で止める（第4回）
生成されたコードがキーをクライアントバンドルへ露出させた生成物層レビュー観点と型・命名規約での検出（第9回）
プラットフォーム側の変数保管が復号可能な設定のままだった実行基盤層保管方法の見直しとローテーション（第11回）

最初に決めるべきは「どの層の話をしているか」です。層を取り違えると、正しい対策を間違った場所に入れることになります。

3. 何が本当に新しいのか

非信頼な入力の入口が増えた

従来、「ユーザー入力を信用しない」という原則の適用先は、フォームやAPIのリクエストボディでした。エージェントを使う開発では、モデルが読むものはすべて入力 になります。

入口具体例誰が中身を書いているか
Webページエージェントが参照したドキュメント、ブログ、検索結果第三者
Issue / PR コメント自動修正を任せたバグ報告の本文外部の投稿者
依存パッケージREADME、CHANGELOG、インストール時に表示される文言パッケージの公開者
MCP サーバーツールの説明文、ツールが返すレスポンスサーバーの提供者
ログ・エラー出力外部サービスが返したメッセージ本文そのサービスと、そこへ入力した誰か

いずれも「データとして扱っているつもりのもの」がモデルの文脈に入り、指示として解釈されうる、という共通点があります。プロンプトインジェクションが厄介なのは、脆弱性の悪用が要らないためです。攻撃者は文章を置いておくだけで済みます。

MCP は特にこの入口が広く、公式のセキュリティベストプラクティスでも、ローカル MCP サーバーがクライアントと同一権限で任意コードを実行できること、広範なスコープの一括付与がトークン漏洩時の被害を拡大することなどが明示されています。詳細は第5回で扱います。

lethal trifecta — 3つ揃わせない

この状況を設計に落とすとき、有効な整理が Simon Willison が 2025年6月に提唱した lethal trifecta です。次の3つが同時に揃ったとき、非信頼コンテンツに置かれた指示だけでプライベートデータの窃取と外部送信が成立します。

要素具体例外し方の例
プライベートデータへのアクセスリポジトリ、認証情報、社内API作業ディレクトリを絞る、読み取り先を明示的に制限する
非信頼コンテンツへの露出Web取得、Issue本文、外部ツールの応答取得先を許可制にする、外部入力を扱うセッションを分ける
外部への通信能力任意ドメインへのHTTP、外部へ書き込むMCPツール送信先ドメインを許可制にする、書き込み系ツールを外す

重要なのは、2つまでなら被害が成立しにくい という点です。防御の設計は「攻撃を検知する」よりも「3つ目を揃わせない」ほうが安定します。Claude Code のサンドボックスが既定で許可ドメインを持たない設計になっているのは、3つ目の要素を初期状態で外しているためだと読めます。

モデル側の対策だけには寄りかからない

モデル提供者側も対策を進めています。Anthropic は、強化学習によってプロンプトインジェクション耐性をモデルの能力へ組み込み、分類器で非信頼コンテンツを走査していることを公表しています。同時に、ブラウザ操作（Claude for Chrome）における内部評価で 攻撃成功率が 1% 残っており、問題が解決したわけではない と明言しています。この 1% はブラウザ操作の測定値であり、コーディングエージェントや MCP 全般の数値ではありません。環境によってはこれより大幅に高い成功率が報告されています。

1% という数字の読み方には注意が必要です。1回の試行で見れば低い値ですが、エージェントが1日に数百回外部コンテンツへ触れる運用では、確率としては十分に高い部類に入ります。つまりモデル側の防御は「入口の一枚目」であって、境界の代わりにはなりません。権限の設計とネットワークの制限は、モデルが騙された場合を前提に組む必要があります。

4. 責任分界 — マネージドだから安全とは限らない

マネージドプラットフォームは多くの面倒を引き受けてくれますが、引き受ける範囲は製品ごとに違い、既定値が安全側とも限りません。よくある期待と実際のずれを整理します。

期待しがちなこと実際自分でやること
WAF が有効なら攻撃は止まる無料プランは基礎的なマネージドルールのみで、カスタムルールや詳細な制御は上位プラン側にあることが多い契約プランで何が有効かを確認し、アプリ側の検証を省かない
プレビュー環境は関係者しか見ない保護機能が別途用意されているということは、既定で保護が掛かっていないことを意味するプレビュー環境の到達制御を明示的に設定する
環境変数に入れておけば秘密は安全保管方式によって、復号可能な状態で保持されるものがある秘密の等級に応じて保管方式を選ぶ（第11回）
データベースは認証すれば安全行レベルの制御は明示的に有効化・設計しない限り効かないポリシー設計と実クエリでの検証（第10回）
依存パッケージは署名があれば安全正規の発行経路が乗っ取られれば、署名も正当なまま汚染版が配られる取り込みまでの時間差と lockfile の運用で受ける（第12回）

この「マネージドだから安全とは限らない」を具体的に示したのが、Vercel が公表した 2026年4月のセキュリティインシデントです。サードパーティ製AIツールの OAuth アプリ侵害を起点に従業員アカウントへ到達され、Sensitive フラグが付いていない環境変数（APIキーやDB認証情報を含む）が一部顧客で列挙・復号された と報告されています。Sensitive 環境変数、npm パッケージ、OSS プロジェクトへの影響はなかったとされています。

ここから読み取るべきは「Vercel が危険だ」ということではありません。同じサービスの中に、復号可能な保管と復号不可能な保管という2種類の等級があり、どちらを使うかは利用者側の設定で決まっていた という点です。プラットフォームが用意した安全側の選択肢を、明示的に選ばない限り既定にはならない。この構造は他のサービスにも当てはまります。

責任分界を見るときに使える問いは3つです。

  1. 既定で有効か、自分で有効にするものか。 機能があることと、掛かっていることは別です
  2. 自分の契約プランで使えるか。 機能一覧とプラン別対応表は分けて読みます
  3. 提供者側が侵害されたとき何が露出するか。 秘密の保管方式とローテーション手順が、この問いへの答えです

利用者としての判断軸は 生成物と外部入力の扱い でも整理しています。本連載は、その先の「実装者として何を設定するか」を扱います。

5. この連載の読み方

全12回の対応は次のとおりです。

回テーマ層
第1回攻撃面の全体像と責任分界（本記事）全体
第2回Claude Code の権限設計エージェント層
第3回Codex の承認モード・サンドボックス・Rulesエージェント層
第4回Hooks でガードレールを組むエージェント層
第5回MCP・外部連携とプロンプトインジェクションエージェント層
第6回生成AIツール側の設定で守るエージェント層
第7回AI生成コードのレビュー観点の全体像生成物層
第8回認証・認可のレビュー各論生成物層
第9回入出力と外部連携のレビュー各論生成物層
第10回デプロイ基盤の本番前チェック実行基盤層
第11回秘密情報とサプライチェーン実行基盤層
第12回運用と初動実行基盤層

順に読むのが基本ですが、目的が決まっているなら入り口を選べます。

  • エージェントに広い権限を渡したまま使っている — 第2回・第3回から。設定ファイルを一度開くのが最短です
  • 外部のWebやIssueを読ませている — 第5回から。lethal trifecta の3要素を自分の環境で数えます
  • 今週リリースを控えている — 第10回・第11回から
  • AI生成コードのレビュー基準がチームにない — 第7回から。AIコードレビューの運用設計 と CI/CDガードレール を併読すると分担を決めやすくなります

各回では仕様の逐一の解説より「何をどう設定し、何を確認するか」を優先し、個別ツールの仕様は既存記事（Claude Code の Hooks、Codex のセキュリティモデル、Vercel 安全度マップ、Supabase 安全度マップ）へ接続します。

まとめ

  • 従来のWebセキュリティの知識は今も有効です。新しく積み上がったのは、開発に使うエージェント自体が攻撃面になる という層です
  • 攻撃面はエージェント層・生成物層・実行基盤層の3つに分けられます。同じ事象でも層が違えば効く対策が違うため、最初に層を特定します
  • 非信頼な入力の入口は、Webページ・Issue・依存パッケージの説明文・MCPサーバーの応答へ広がりました。防御の設計は lethal trifecta の3要素を揃わせないことを基本にします
  • モデル側の耐性向上は入口の一枚目です。Anthropic 自身がブラウザ操作の評価で攻撃成功率 1% が残ると述べており、権限とネットワークの制限は「騙された場合」を前提に組みます
  • マネージドプラットフォームの保護は、既定で有効なものと自分で選ぶものに分かれます。Vercel の 2026年4月のインシデントは、その選択が利用者側にあったことを示す事例です

参考リンク