AIが自分の書いたコードの穴を探し始めた｜Claude SecurityとCodex Securityが変えること

この記事は前後編の【前編】です。 ・前編（本記事）：Claude Security と Codex Security が何をするものなのか、AI生成コードの脆弱性問題がどこまで軽減されるのか ・後編：AIがセキュリティ検査までやる時代に、それでもエンジニアが必要な理由：それでも人間のエンジニアが必要な理由と、役割がどこへ移るのか

AIにお願いすればアプリが作れる時代になりました。プログラミングの経験がない人でも、やりたいことを言葉で伝えるだけで動くものができあがる——いわゆる「バイブコーディング」です。

ただ、この数年でひとつはっきりしたことがあります。動くことと、安全であることは別だということです。

そして2026年、その「安全であること」の側をAI自身に担わせる道具が、AnthropicとOpenAIの両方から出てきました。Anthropicは7月22日に Claude Code向けの「Claude Security」プラグインをベータ公開し、OpenAIは3月6日に 「Codex Security」 をリサーチプレビューとして公開しています。

この記事では、この2つが具体的に何をするものなのか、そして「AIが作ったアプリは脆弱」という問題がどこまで解決に向かうのかを、実務目線で整理します。

まず前提：AIが書いたコードは、けっこう穴があいている

この話は「AIのコードは危ないぞ」という印象論ではなく、実際に測られています。

Veracodeの GenAI Code Security Report では、100を超えるモデルに80種類のコーディング課題を解かせ、生成されたコードを検査しました。結果は、約45%がOWASP Top 10（代表的な脆弱性の分類）に該当する問題を含むというものでした。クロスサイトスクリプティング（XSS）への防御に失敗した割合は86%、ログインジェクションは88%。言語別ではJavaが最も悪く、失敗率72%です。

しかも、2026年3月の更新版でも合格率は約55%で横ばいでした。モデルの性能は上がり続けているのに、セキュリティの合格率だけはほとんど改善していない、という結果です。

別の調査もあります。Apiiroが大企業のコードベースを分析したところ、AIが生成したコードには人間が書いたコードの2.74倍の脆弱性が含まれ、権限昇格につながる経路は322%多かったと報告されています。

なぜこうなるのか。理由はシンプルです。AIは「動くコード」を書くよう最適化されており、攻撃者の視点を明示的に求められていない限り、そこを考えないからです。加えて、学習元となった世の中のコードにも脆弱なものが大量に含まれています。

そして、ここに構造的な問題がありました。穴があいていることに気づけるのは、セキュリティを分かっているエンジニアだけだったのです。エンジニアが関わっていないプロジェクトでは、脆弱性は「見つからない」のではなく「見られていない」まま公開されていました。

この非対称性を崩そうとしているのが、今回の2つの機能です。

Claude Security：ターミナルの中で、複数のAIが脆弱性を探す

Anthropicが公開した Claude Security プラグインは、Claude Code のセッションの中から脆弱性スキャンを走らせる仕組みです（公式ページ）。

導入は2コマンドで、使うときは /claude-security を叩くとメニューが出ます。

/plugin install claude-security@claude-plugins-official
/reload-plugins

できることは3つです。

注目すべきは「変更分のスキャン」です。コミットする前に、その変更だけを検査できる。つまり、脆弱性を世の中に出してから探すのではなく、出す前に止められる位置に検査が来ています。

もうひとつの特徴として、Anthropicはコードを利用者の環境の外に出さない点を挙げています。コードを外部のスキャンサービスに丸ごと預ける必要がありません。

中身は「複数のAIによる分業」

このプラグインが単純なパターン検索と違うのは、内部が6段階の分業になっている点です。

この5段目が、実務的にはいちばん重要です。指摘が報告書に載るには3体のうち2体以上が「本物だ」と判定する必要がある（2/3のクォーラム）という設計になっています。全員一致なら確信度は「高」、判定が割れたら「中」に抑えられます。

さらに、この票の集計はモデルが自己申告するのではなく、レポート生成側のプログラムが計算します。「ちゃんと検証しました」というAIの自称ではなく、検証したという事実が構造として担保されている、という作りです。

従来の静的解析ツールが「危ないかもしれない箇所」を大量に並べて最終判断を人間に丸投げしていたのに対し、こちらは誤検知を落としてから出すことに設計上の重心が置かれています。

修正パッチの扱いは、かなり慎重

パッチ生成の作りも特徴的です。

• パッチは作業ツリーとは別のクローンの中で作られる。手元のコードには触らない
• 別の検証AIがパッチをレビューし、プロジェクトのテストを実行する
• 「その問題を実際に直しているか」「新しい脆弱性を持ち込んでいないか」「他の挙動を壊していないか」の3点が確認できたときだけ、パッチが書き出される
• 認証を緩めた、テストを無効化した——といったセキュリティを弱める方向の変更は自動で却下される
• 出力されたパッチは patches/ に置かれるだけで、適用するかどうかは人間が git apply で決める

つまり「AIが勝手に直してくれる」ものではありません。AIが直し方を提案し、人間が採否を決めるという境界が、実装レベルで引かれています。

コストと前提条件

現実的な制約も押さえておきます。

• 有料のClaude Codeプランが必要（v2.1.154以降）
• スキャンはプランのトークン枠を消費する。負荷は4段階の「深さ」で調整でき、浅い設定なら最大12構成要素・1観点1担当、深い設定なら最大24構成要素・1観点2担当まで広がる
• 全エージェントは読み取り専用ツールに制限されている
• プラグイン自体は隔離環境を持たない。信頼できないコードを検査するときは、別途サンドボックスを併用するようAnthropic自身が案内している

Codex Security：サンドボックスで「本当に攻撃できるか」を試す

OpenAI側は、実は先に出しています。Codex Security は2026年3月6日にリサーチプレビューとして公開されました（OpenAIの発表）。ここは誤解されやすい点ですが、Claudeが先ではありません。

こちらはローカルのプラグインというより、リポジトリを接続して使う専用のセキュリティ機能という位置づけです。流れは3段階です。

1. プロジェクトを理解する リポジトリを解析し、そのシステムが何をしていて、何を信頼していて、どこが最も外部にさらされているかを把握します。そのうえでプロジェクト固有の脅威モデルを作ります。

2. 脆弱性を検証する 作った脅威モデルを文脈として使い、「このシステムにおいて、現実にどれだけの影響があるか」で問題を分類します。そして可能な場合は、隔離されたサンドボックス環境で問題を実際に再現させ、悪用可能性を確認してから報告に載せます。

3. 修正案を出す 周辺のシステム全体の文脈を踏まえてパッチを作り、リグレッション（別の機能を壊すこと）を最小化することを狙います。パッチはプルリクエストとして提出できる形で提示されます。

OpenAIがここで解こうとしている問題は明確です。従来のセキュリティツールは弱い指摘を出しすぎる。一般的なスキャンでは重大に見える問題が、実際のアプリケーションではほとんど影響がなかったり、逆にアーキテクチャや信頼境界に絡む微妙な問題は完全に見落とされたりする。検出精度の問題ではなく、システムの文脈が欠けていることが原因だ、という整理です。

提供対象は ChatGPT の Enterprise・Edu・Business・Pro プランです。

2つを並べて見る

実装も提供形態も違いますが、目指している方向はほぼ同じです。

• コード生成とセキュリティ検査を、同じ道具の中で一体にする
• パターン照合ではなく、コードベース全体の文脈を理解して探す
• 候補を列挙するだけでなく、本当に成立する問題かを検証する
• 重大度を「一般論」ではなく「このシステムにおける実際の影響」で評価する
• 修正パッチまで作る
• ただし、最終的に反映するかは人間が決める

これまでは、AIが生成したコードを人間や既存のSASTツールが後から追いかける形でした。今後は、作るAIと検証するAIが対になり、生成と検証を往復しながら進む開発が標準になっていくと考えられます。

なぜ「プラグイン」「リサーチプレビュー」なのか

どちらもまだ常時オンの標準機能ではありません。この理由は、憶測を並べるより公開されている仕様から読み取ったほうが正確です。

• コストが実際にかかる。Claude側は「スキャンがプランのトークン枠を消費する」と明記しており、負荷を4段階で選べるようになっています。深いスキャンほど担当AIの数と検査範囲が増える設計です。つまり、毎回最大深度で回す前提には作られていません
• 毎回必要とは限らない。設定ファイルの誤字を直したコミットに、脅威モデルの再構築から始まる6段階のスキャンを走らせる必要はありません
• 速度と精度のバランスは利用者が選ぶべきもの。だから深さが設定項目として露出しています
• セキュリティの基準は組織ごとに違う。何を重大とみなすか、何を許容するかは企業のポリシー次第です
• まだ評価中である。ベータ／リサーチプレビューという表記そのものが、誤検知率や修正精度を実運用で測っている段階だという表明です

ただし方向としては、明示的に起動するものから、標準で走るものへ移っていく可能性が高いと見ています。コード生成の直後、コミット、プルリクエスト、デプロイ——それぞれの段でセキュリティ検査が当たり前に挟まる形です。実際、Claude側の「差分スキャン」はすでにその位置に置かれています。

で、AI製アプリの安全性はどこまで改善するのか

ここが本題です。期待できることと、期待しすぎてはいけないことを分けます。

改善が期待できる領域

既知のパターンを持つ脆弱性は、かなりの割合が自動で潰されるようになるはずです。

• SQLインジェクション
• クロスサイトスクリプティング（XSS）
• パストラバーサル
• ハードコードされた秘密情報（APIキーの直書きなど）
• 危険な暗号アルゴリズムの使用
• 安全でないデシリアライズ
• 脆弱な依存ライブラリ
• 基本的な認可漏れ

先ほどのVeracodeの調査で「45%が該当した」のは、まさにこの層です。検査する人がいなかったから残っていた問題であり、検査を道具側が担えるなら、平均的な安全性は確実に上がります。

エンジニアが関わっていないプロジェクトほど恩恵が大きい、という点も重要です。これまで完全に検査されていなかったコードに、初めて検査が入るからです。

期待しすぎてはいけない領域

一方で、「AIが検査したから安全」とは言えません。理由は3つあります。

1つ目：業務仕様に依存する脆弱性は、コードを見ても判定できない。 「解約後も家族の情報が見える」「承認処理の順番を変えると課金を回避できる」——こうした問題は、コードだけを見ても、それが不具合なのか正しい仕様なのか区別がつきません。

2つ目：作るAIと検査するAIが、同じ誤解を共有しうる。 AIが業務仕様を誤解した状態で認可処理を書いた場合、同じ理解を持つAIが検査しても「仕様どおり」と判定して通してしまう可能性があります。Claude側の3体独立検証パネルは「到達可能か・影響があるか・防御で止まるか」を検証する仕組みで、そもそもの仕様が間違っているかどうかは検証範囲の外です。

3つ目：道具自体に前提条件がある。 Claude Security は隔離環境を自前で持たないため、信頼できないコードを検査するなら別途サンドボックスが必要です。また公式にも、これは従来のSAST・依存関係スキャン・コードレビューを置き換えるものではなく、**「必要なときに深く掘る層」**として位置づけられています。

つまり、AIによるセキュリティ検査は安全性の保証ではなく、防御を構成するレイヤーの一枚として扱うのが正しい理解です。

まとめ

• Anthropicは2026年7月22日に Claude Code向け Claude Security プラグインをベータ公開。ターミナル内で6段階のマルチエージェント・スキャンを走らせ、3体の独立検証AIの投票を通った指摘だけを報告し、パッチも別クローンで検証済みのものを出す。適用は人間が手動で行う
• OpenAIは同年3月6日に Codex Security をリサーチプレビュー公開。プロジェクト固有の脅威モデルを作り、サンドボックスで実際に再現して悪用可能性を確認してから報告する
• 両者の方向は共通していて、生成と検証を対にする開発への移行を示している
• AI生成コードの約45%が代表的な脆弱性を含み、その合格率は改善していないという調査結果がある。検査する人がいなかったことが原因の脆弱性は、今後かなり潰されていく
• ただし、業務仕様に依存する脆弱性、作るAIと検査するAIの前提共有、道具側の前提条件は残る。AIの検査は保証ではなく防御レイヤーの一枚

では、AIがここまでやるようになったとき、人間のエンジニアの役割はどう変わるのか。なくなるのか、それとも移るのか。後編で扱います。

→ 後編：AIがセキュリティ検査までやる時代に、それでもエンジニアが必要な理由

参考にした一次情報

• Claude Security（Anthropic）: https://claude.com/product/claude-security
• Codex Security: now in research preview（OpenAI）: https://openai.com/index/codex-security-now-in-research-preview/
• AI生成コードの脆弱性割合: Veracode「GenAI Code Security Report」（2026年3月更新版を含む）、Apiiro による大企業コードベース分析