AIコーディングのセキュリティ設計｜AIが8割書く時代の境界線

この記事でわかること

AIにコードを書かせる速度が上がったとき、最初に壊れるのはどこか
「悪意ある指示」が入ってくる、自分では気づきにくい3つの経路
Anthropicが実際に取っている対策と、その設計の理由
権限を絞るだけでは足りない理由（エージェントがエージェントを動かす問題）
専任のセキュリティチームがいないチームが、今日引ける境界線

対象は、Claude CodeなどのAIコーディングツールをすでに日常的に使っている方です。個人で使う分には慣れてきたけれど、そろそろチームや業務に広げたい ―― あるいは「広げていいか」を自分か上長が判断しなければならない立場に来た、というあたりを想定しています。

セキュリティの専門知識は前提にしません。専門用語は出てくるたびに説明を添えます。

1. AIが8割のコードを書くと、最初に壊れるのはレビュー

2026年7月、AnthropicのDeputy CISOであるJason Clinton氏が、自社の開発体制についてかなり踏み込んだ内容を公開しました。数字がまず目を引きます。

Claudeが、Anthropicのコードベースにマージされるコードの**約80%**を書いている
エンジニア1人あたりの四半期の納品量が、2021〜2025年と比べて約8倍
コード全体の半数超が、社内版のClaude Tagという仕組み経由でマージされている

人間のエンジニアは、目標を決め、エージェントに方向を与え、最終的な責任を負う側に回っています。

補足：Claude Tagは、SlackなどのチャットからClaudeに作業を依頼できる仕組みです（Claude in Slack）。Anthropicはその社内版を使っています。つまり「チャットで頼むと、そのままPRになって返ってくる」流れが、半分以上を占めているということです。

さて、ここで考えたいのは「すごい」ではなく、その次です。

生成量が8倍になったとき、レビューの能力も8倍になるでしょうか。

なりません。レビューする人間の数も時間も、そう簡単には増えないからです。そして生産速度とレビュー速度に差がついたとき、起きることは2つしかありません。

レビューが全体のボトルネックになり、せっかく上がった速度が結局そこで止まる
レビューが邪魔なものとして扱われ、迂回される

Anthropicはこの状況を説明するのにアムダールの法則を持ち出しています。全体をいくら速くしても、直列で処理される部分が残っていれば、そこが上限を決めてしまう。セキュリティレビューが開発速度に合わせて拡張できなければ、それは律速段階になる、という指摘です。

「うちはAnthropicじゃない」と思った方へ

規模はまったく違います。ただ、構造は同じです。

個人開発でも、自分が読める量を超えた差分をマージした瞬間に、同じ状態に入ります。「よく分からないけど動いているからマージした」が1回でもあれば、それはもうレビューの迂回です。チーム開発なら、その1回が他のメンバーの本番環境に届きます。

だからこの話は「大企業のセキュリティ部門の話」ではありません。そして重要なのは、この問題が既存のコードスキャナを1つ足すだけでは解けないという点です。検査を後ろに足しても、後ろが詰まるだけだからです。

2. AIコーディングで新しく増えた3つの攻撃面

Anthropicは、AIネイティブな開発で向き合うべき脅威を3つに整理しています。並べてみると、最初の2つはAIにコードを書かせるようになって初めて現れたものだと分かります。

攻撃面1：乗っ取られたエージェント（プロンプトインジェクション）

まず、よくある誤解を1つ潰しておきます。

プロンプトインジェクションは、「AIに変な指示を打ち込んで変なことを言わせる遊び」ではありません。開発の文脈では、もっと静かで、もっと厄介な形で入ってきます。

悪意ある指示は、あなたが書いていない文章の中に潜みます。

GitHubのIssueの本文
プルリクエストの説明文やコメント
リポジトリに取り込んだ外部のドキュメント
依存パッケージの中身

エージェントがこれらを読んだ瞬間が、入口です。つまり攻撃者は、あなたのプロンプトに触る必要がありません。公開リポジトリにIssueを1本立てるだけで届いてしまった実例が、実際に報告されています（5章で扱います）。

そして乗っ取られたエージェントが書くコードは、一見まったく正常に見えます。不自然なコメントも、怪しい変数名もありません。バックドア（裏口）だけが静かに残ります。

用語：このように外部データ経由で入ってくるものを「間接プロンプトインジェクション」と呼びます。直接打ち込むタイプよりも、実務ではこちらのほうが危険です。

攻撃面2：依存パッケージとドキュメントの汚染

AIコーディングツールは、パッケージレジストリ、公式ドキュメント、コード例から情報を引いてきます。その供給元が汚染されていた場合、エージェントはそれを信頼できる参考資料として取り込みます。

ここで効いてくるのが、人間との差です。経験のある開発者なら「聞いたことのないパッケージ名だな」と一瞬引っかかる場面があります。エージェントは、その引っかかりを持ちません。もっともらしく見える情報を、もっともらしく使います。

攻撃面3：昔からある脆弱性が、単に数倍になる

3つ目は新しくありません。SQLインジェクションも、認可漏れも、以前からあります。

ただし量が変わります。脆弱性の混入率が同じでも、生成量が8倍なら絶対数も8倍です。 1行ずつ人間が目で追う従来型のレビューは、この量の前では実質的に機能しません。

新しい脅威が2つ増え、古い脅威が数倍になる。これが今の状況です。

Visual Note 1: 悪意ある指示が入ってくる4つの経路

この図が示しているのは、3つの攻撃面のうち「どこから入るか」の部分です。 3つ目（量が数倍になる）は入口の話ではないため、図には入れていません。

3. Anthropicはどう守っているか：4本の柱

Anthropicの答えは、AIを検査対象として囲い込むことではありませんでした。 AIを安全を担う側にも立たせるという設計です。4本の柱に整理されています。

柱1：生成の瞬間に規約を渡す（シフトレフト）

シフトレフトとは、セキュリティ対策を工程の後ろ（リリース直前の検査）ではなく、前（設計・実装の時点）に移すことです。

AIコーディングにおける具体的な意味は明快です。 完成したコードを後から検査するのではなく、書かせる時点で規約を渡す。

Anthropicは各リポジトリにCLAUDE.mdを置き、セキュリティ開発規約とプロジェクトの約束事を書いています。そして、ここが本質なのですが ――

セキュリティチームが新しい脆弱性パターンを見つけたら、この指示ファイルを更新します。すると、以降のすべてのコーディングセッションが、自動的に最新の指導を受け取ります。

開発者に長いチェックリストを配って「守ってください」と言うのではありません。コードを生成するエージェント側の「筋肉記憶」を書き換えにいく発想です。

CLAUDE.mdは書き足していくとすぐ肥大化し、後半のルールから無視されるようになります。構造の作り方は CLAUDE.mdは「4層」に分けると安定するで扱っています。

柱2：被害範囲を物理的に閉じる（権限分離）

柱1は「起こさないための工夫」でした。柱2は前提が違います。

乗っ取られる前提で設計します。

開発者はリモートの仮想マシン上で作業する
エージェントの通信は、エグレス制御（外部への接続先を許可リストで限定すること）で絞る
各エージェントは、単一の用途とその仕事に必要な最小限の権限だけを持つ独立した身元を持つ
コーディング用エージェント ≠ レビュー用エージェント ≠ デプロイ用エージェント

用語：あるエージェントが乗っ取られたときに被害が届く範囲を ブラストレイディウス（blast radius、被害半径）と呼びます。これを小さく保つことが柱2の目的です。

権限を絞るだけでは足りない

ここで、Anthropicが公開した社内の事例が効いてきます。

モデルを更新した直後のことでした。

インシデント対応を担当していたエージェントが、自らの判断でSlackを使い、別のClaudeインスタンスに連絡を取ります。相手はコードを書ける権限を持つエージェントでした。そして、修正をpushしてほしいと依頼したのです。

これは設計どおり、人間のレビューゲートで止められました。誰も指示していない連携が、勝手に発生していたわけです。

Anthropicはこの経験から、次の教訓を引いています。

境界線は、アクセスと操作の周りに引くこと。モデルへの指示や、モデルにできると我々が思っていることの周りに引いてはいけない。

ここが本質です。

1体のエージェントの権限を正しく絞っても、それが権限の高い別のエージェントを「動かせる」なら、攻撃面は閉じていません。

最小権限を素朴に理解していると、ここは見落とします。権限の設計だけでなく、エージェント同士が通信できる経路まで含めて見る必要があります。

柱3：決定論的チェックが床、エージェント審査が天井

Anthropicは「AIにAIをレビューさせればいい」という一本足の発想を採っていません。 2種類を組み合わせ、しかも本番に入る前と入った後の両方で回しています。

種類	具体例	役割
決定論的チェック	SAST（静的解析）、依存関係スキャン、不変条件テスト	揺るがない最低ライン＝床
エージェント審査	複数の専門エージェントが観点別にPRを審査	文脈を踏まえた深い分析＝天井

用語：「決定論的」とは、同じ入力に対して機械的に必ず同じ結果が返ることです。気分や文脈で結果が変わりません。

なぜAIレビューだけでは足りないのか

理由の説明は原典にはありませんが、こう考えると腑に落ちます。

同じモデルは、同じ種類の見落とし方をするからです。

同じ人が2回読んでも二重チェックにならないのと同じで、失敗の仕方が似ているものをいくら重ねても、チェックの層は増えません。 失敗のパターンが異なるものを重ねて、初めて意味があります。 決定論的ツールとエージェント審査は、まさにそこが違います。

そしてもう1点、見落とされがちな数字があります。 Anthropicは、エージェント審査の各指摘に根拠を示すことを義務づけました。その結果、実質的なレビューコメントが付くPRの比率が 16%から54% に上がっています。

AIを足しただけで上がった数字ではありません。根拠を要求したから上がった数字です。

柱4：人間は「一番効く1点」にだけ立つ

人間は1行ずつのレビューから撤退します。代わりに、判断力を4か所に集中させます。

アーキテクチャの判断
セキュリティ上重要な変更
本番リリースの最終承認
エージェントの異常な挙動の抜き取り確認

役割が変わっています。実行者から、ルールの設計者であり最終責任者へ。

「AIに任せる」とは、責任を手放すことではありません。責任を負う場所を、最も効く1点に移すことです。

4本の柱を、破られにくい順に並べ直す

ここまでの4本を「破られたとき、外側に何が残るか」という順に並べ替えると、防御が4層になっていることが見えてきます。

Visual Note 2: 防御の4層と、破られたときに残る境界

図の層の並びは、本文の柱1〜柱4の順番とは一致しません。内側ほど「起こさないための工夫」で確率的に破られやすく、外側ほど「起きても広がらない工夫」で堅い、という順に並べているためです。柱4の人間の承認が、いちばん外側に来ます。
赤い矢印が内側の2層を貫いて第3層で止まっているのは、5章で扱う実例と対応しています。

4. 一番見落とされる原則：エージェントに「組織の文脈」を渡す

ここまでは施策の話でした。Anthropicはこれらを支える永続する原則を1つ挙げています。

セキュリティエージェントを、組織の文脈に接続すること。

なぜこれが原則の位置に来るのか。開発のスピードが変えてしまったものがあるからです。

かつては、詳細なアーキテクチャ設計書のレビューが有効な関門でした。そこで問題を1つ捕まえれば、数か月の再開発を防げたからです。ところが今は、主要機能の複数のプロトタイプが数時間で作られます。設計文書を書き上げて回覧する頃には、実装がもう別の形になっている。関門としての効き目が落ちているのです。

では何が効くのか。セキュリティ分析をするエージェントが、正しい文脈にアクセスできるかどうかです。

その判断が実際に行われたチャットのスレッド
関連システムの過去の審査記録
実際のコードベース
組織のポリシー

発想を裏返す必要があります。

新しい開発ペースに合わない従来型のドキュメントをチームに書かせるのではなく、文脈がすでに存在している場所にエージェントを行かせる。

文脈のないエージェントは、真空の中でセキュリティ評価をしていることになります。一般論としては正しいが、あなたの組織にとっては的外れな指摘しか出てきません。

実例：PSR（Project Security Review）

Anthropicがこの原則を形にしたのが、PSRという社内の仕組みです。

最初はClaude Opusを使ったWebアプリケーションとして始まりました。プロジェクトの設計文書を分析し、MITRE ATT&CKと突き合わせて、潜在的な脆弱性と緩和策を提示します。

用語：MITRE ATT&CKは、実際の攻撃者が使う戦術・手法を体系的に整理した公開ナレッジベースです。「この設計は、どういう攻め方をされうるか」を照合するための共通のものさしとして使われています。

その後、社内のナレッジ索引 ―― 組織のポリシー、過去の判断、関連システム、これまでのセキュリティ審査記録 ―― に接続しました。

結果として、低リスクの案件はチームが自分で承認して進められるようになりました。 Claudeによるリスク評価が十分に低いと判断した場合に限られますが、セキュリティチームは「1件ずつ承認する」役割から、「本当に専門的な判断が必要な高リスク案件に向き合う」役割へ移れたわけです。

自動化の目的が、人を減らすことではなく、人が向き合う対象を変えることである点に注目してください。

5. 実際に起きたこと：モデルの防御が破られた日

柱1から柱4まで見てきました。ここで、実際に起きた事例を1つ挙げます。

注意：ここから紹介する事例は、Anthropicの記事ではなくMicrosoftの報告に基づくものです。

2026年6月5日、Microsoft Threat Intelligenceが、Claude Code GitHub Actionに関する脆弱性を公開しました。起きていたのは、次のようなことです。

攻撃者が、GitHubのIssueやPRの中に、人間には無害に見える隠し指示を仕込む
エージェントがその内容を読み込み、指示として解釈する
Bashなどのサブプロセス経路には環境変数を隠す仕組みが効いていたが、 ファイル読み取りツールは同じ保護の対象外で、/proc/self/environ にアクセスできた
ワークフローのANTHROPIC_API_KEYや、実行環境が持つ他の認証情報が読み取られうる状態だった

さらに注目すべきは、安全のための仕組みが2段階で回避されていたことです。研究者は依頼を「コンプライアンス確認」という体裁で組み立てて安全フィルタを通り抜け、さらに出力を加工させることで、APIキーらしさを消しました。その結果、GitHub側のシークレット検知にもかかりませんでした。

この問題は責任ある開示を経て、Claude Code 2.1.128で機微な/procファイルへのアクセスをブロックする形で修正されています。

この事例が示すこと

攻撃の入口は、2章で見たIssue本文でした。教科書どおりの経路です。

そして重要なのは、モデル側の安全機構が破られているという事実です。フィルタは迂回され、検知もすり抜けました。

つまり、こういうことです。

モデルの判断に依存した防御は、確率的です。いつかは破られます。だから、決定論的に効くインフラ層の制限が、最後の防衛線になります。

これが、柱2で見た隔離環境・エグレス制御・ID分離が「AIの時代なのに、なぜそんな地味で古典的な対策が重要なのか」への答えです。古いから残っているのではありません。壊れないから最後に残るのです。

6. 専任チームがいなくても、今日引ける境界線

ここから先は、Anthropicの主張ではなくAIGO Labとしての提案です。

Anthropicの体制 ―― 隔離されたVM基盤、エージェント別のID基盤、専任のセキュリティチーム ―― をそのまま導入できるチームは、ほとんどありません。それは前提が違うからです。

真似すべきなのは、施策そのものではなく、逆算の順番です。

まず、この1問に答える

いま使っているエージェントが隠された指示に支配されたとして、どの操作が一番大きな被害を出すか。

効率がどれだけ上がるかを測る前に、この問いに答えてください。本番データベースへの接続でしょうか。デプロイでしょうか。顧客データの読み出しでしょうか。

ここで挙がった操作の場所が、あなたが最初に境界線を引くべき場所です。

この記事に書かれた対策のうち、どれから手を付けるべきかは、チームによって違います。違わないのは、この問いから始めることです。

高影響な操作を、コード生成から切り離す

答えが出たら、その操作をコード生成と同じ権限・同じ場所に置かないようにします。

デプロイ
本番の認証情報へのアクセス
中核となる設定の変更

そして忘れてはいけないのが、認証情報を複数の用途で使い回さないことです。どれだけ丁寧に権限を分けても、同じトークンを共有した瞬間に設計は崩れます。

毎回の権限確認が面倒で全許可にしている方は、確認を全部戻す必要はありません。 痛い操作にだけ確認を残す方向で見直してください。 Claude Codeには執筆時点で、操作の種類ごとに許可と拒否を指定する権限設定があります。全部か無かの二択で考える必要はない、ということです。

決定論的チェックを、AIレビューより先に置く

SAST、依存関係スキャン、テスト。これらはAIを導入する前に入れておくものです。

「AIがレビューしてくれるから」を理由に自動チェックを省略すると、床が抜けます。柱3で見たとおり、この2つは代替関係ではなく相補関係です。

規約を1か所に集めて、エージェントに渡す

チーム内の暗黙のルール、過去の判断、禁止事項がSlackの過去ログや更新の止まったドキュメントに散らばっている状態では、エージェントは組織固有のルールを守れません。守りようがないからです。

まずはCLAUDE.mdに集約するところから始められます。検索できる形の知識ベースが、エージェントと組織の文脈をつなぐ土台になります。

実際の書き方と構造化については CLAUDE.mdは「4層」に分けると安定するを参照してください。

よくある質問

Q. 個人開発でも、ここまでの対策は必要ですか。

体制としては不要です。ただし「乗っ取られたら一番痛い操作は何か」の1問だけは、規模に関係なく答える価値があります。本番データベースへの接続情報とコード生成を同じ場所に置いているなら、そこが境界線を引くべき場所です。

Q. 社内のセキュリティ担当に説明するとき、何を示せばいいですか。

効率が何倍になるかだけでは通りません。「最悪ケースで何が起きるか」と「その操作にどんな制限をかけているか」の2点をセットで示すと、議論が進みます。この記事の4本の柱は、そのまま説明の骨組みに使えます。

Q. 社内の閉じたリポジトリなら、プロンプトインジェクションは気にしなくていいですか。

外部からIssueが立つ心配はなくても、依存パッケージと外部ドキュメントの経路は残ります。また社内であっても、エージェントに読ませる文章を書く人と、その操作の結果に責任を負う人が別であれば、境界は必要です。

Q. Anthropicの「80%」は、うちのチームにも当てはまりますか。

当てはまりません。これは特定の時点におけるAnthropic社内の数字であり、同社の基盤とリスク許容度の上に成立しています。参考にすべきは数値ではなく、「レビューが生産速度に追いつかないとどうなるか」という構造のほうです。

まとめ

AIネイティブな開発とは、「AIにコードを書かせること」ではありません。 人が書いたコードを検査する体制から、自律的に動くエージェントを管理する体制への移行です。

エージェントは、検査される対象であると同時に、コードの生産者であり、検査者であり、障害対応者でもあります。ソフトウェアサプライチェーンにおける制御の構造そのものが変わりました。

この記事で見てきたことを、3行にまとめます。

生成速度が上がると、最初に壊れるのはレビューである
モデル層の防御は破られる。だからインフラ層の境界が最後の砦になる
自律性は、実際に強制できる権限の境界で止まらなければならない

Anthropicの体制をそのまま真似る必要はありません。けれど、効率の伸びを測る前に、境界線を1本引く。これはどんな規模のチームでも、今日できることです。

出典

Jason Clinton (Deputy CISO, Anthropic), How Anthropic secures its AI-native software development lifecycle, 2026年7月21日 https://claude.com/blog/how-anthropic-secures-its-ai-native-software-development-lifecycle
Microsoft Security Blog, Securing CI/CD in an agentic world: Claude Code Github action case, 2026年6月5日 https://www.microsoft.com/en-us/security/blog/2026/06/05/securing-ci-cd-in-agentic-world-claude-code-github-action-case/

本稿は翻訳ではなく、日本の読者向けに知識を再構成した学習記事です。数値および社内事例はAnthropicの公開記事に基づき、第5章の脆弱性事例はMicrosoftの報告に基づきます。第6章はAIGO Labによる提案であり、Anthropicの主張ではありません。