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

この記事は前後編の【後編】です。 ・前編：AIが自分の書いたコードの穴を探し始めた｜Claude SecurityとCodex Securityが変えること：Claude Security と Codex Security が何をするものなのか、AI生成コードの脆弱性問題がどこまで軽減されるのか ・後編（本記事）：それでも人間のエンジニアが必要な理由と、役割がどこへ移るのか

前編では、Anthropicの Claude Security プラグイン（2026年7月22日ベータ）とOpenAIの Codex Security（同3月6日リサーチプレビュー）が、脆弱性の検出・検証・修正案生成まで担うようになったことを整理しました。まだ読んでいない方は、前編から読むのがおすすめです。

ここから先が本題です。**AIがコードを書き、AIが脆弱性を探し、AIが検証し、AIが修正案を出す。**この流れが成立するなら、人間のエンジニアは何をする人になるのか。

結論から書くと、実装作業者としての価値は下がり、設計者・検証者・意思決定者としての価値が上がる、という移動が起きます。以下、その中身を具体的に切り分けます。

1. 「AIが検査した」は、安全の証明ではない

まず最初に潰しておくべき誤解があります。AIによるセキュリティレビューを通したことは、安全性の証明にならないという点です。

Claude Security の設計はかなり真面目に作られています。3体の独立した検証エージェントが「到達可能か（REACHABILITY）」「影響があるか（IMPACT）」「既存の防御で止まらないか（DEFENSES）」という別々のレンズで投票し、2/3以上が本物と判定したものだけを報告に載せる。しかも票の集計はモデルの自己申告ではなくレポート生成側のプログラムが行う。Codex Security 側は、隔離サンドボックスで実際に問題を再現して悪用可能性を確認します。

それでも埋まらない穴があります。検証のレンズが、いずれも「コードとシステムの実際の姿」を対象にしていて、「仕様が正しいか」を対象にしていないということです。

共通原因による見落とし

具体的な失敗経路はこうです。

1. AIが業務仕様を誤解する
2. 誤った理解のまま認可処理を実装する
3. 同じ理解を持つAIがセキュリティレビューする
4. 「仕様どおりに動いている」と判定して通過する

このとき、到達可能性は確認できます。影響も評価できます。防御が効いているかも見られます。ただし、その「防御」自体が間違った仕様の写しであることは検出できません。

これは冗長化の古典的な失敗、共通原因故障（common cause failure）です。同じ前提を持つ検証器を何体並べても、前提そのものの誤りは消えません。生成とレビューをAIに任せるだけでは解消しない種類の問題です。

実務で必要な多層化

したがって、AIレビューを入れたうえで、なお次のような多層化が必要になります。

このうち4番目が、共通原因故障に対する唯一の実質的な対抗手段です。仕様の理解を共有していない誰か（何か）が、独立に期待値を作るという工程を残さない限り、生成と検証が同じ誤りに合意する経路は閉じません。

Anthropic自身も、このプラグインを従来のSAST・依存関係スキャン・コードレビューの置き換えではなく、「必要なときに深く掘る層」として位置づけています。AIによるセキュリティレビューは、安全性の保証ではなく防御レイヤーの一枚です。

2. 自動化されやすい脆弱性と、されにくい脆弱性

役割の話に入る前に、境界線をはっきりさせておきます。どこまでが道具の仕事になり、どこから先が人間の仕事として残るのか。

自動化が進む：既知パターンを持つ脆弱性

これらは判定基準がコードの中に閉じているため、コードベース全体の文脈を読めるAIとは相性がいい。この層は今後かなり潰されていきます。

自動化されにくい：業務ロジックに依存する脆弱性

一方、次のような問題は難しい。

• 解約後も家族の情報を閲覧できる
• 承認処理の順序を変えると課金を回避できる
• 複数のAPIを組み合わせると利用上限を超えられる
• 返金とポイント付与を同時実行すると二重取得できる
• テナント管理者が他社の顧客IDを推測できる
• 本人確認前に重要な手続きを進められる

これらに共通するのは、コードを見ても、それが不具合なのか正しい業務仕様なのか判断できないという性質です。「解約後も家族情報が見える」は、遺族対応のための意図的な仕様かもしれない。「承認をスキップできる」は、緊急時の運用として設計されたものかもしれない。

つまり判定に必要な情報が、コードの外にあります。契約、業務フロー、法規制、顧客の期待——そこを知らない限り、脆弱性かどうかを決められません。

ここから、必要な能力が変わります。プログラミング知識だけでなく、顧客の業務とドメインを理解し、悪用シナリオを構成する能力が求められるようになります。

3. エンジニアの役割はどこへ移るか

3-1. コードを書く人から、安全性の基準を決める人へ

AIは、与えられた条件に沿ってコードを書き、一般的な脆弱性を見つけられます。しかし何を危険とみなすかは、システムと事業によって変わります。

同じ1本のAPIについて、次の項目はすべて人間が決めるものです。

• 誰がアクセスできるのか
• どのデータまで閲覧できるのか
• 管理者にどこまで権限を与えるのか
• テナント間の分離をどう保証するのか
• どの操作を監査対象にするのか
• どの程度のリスクを許容するのか
• 障害時にサービスを止めるのか（fail-close）、処理を継続するのか（fail-open）

AIは、定義されたルールを実装し検証することには強い。一方で、そもそも正しいルールが何かを決める仕事は人間に残ります。

そしてこれは、AIの性能が上がっても移譲されません。「正しいルール」は技術的に導出できるものではなく、事業判断だからです。

3-2. 実装者から、問題設定者へ

これまでエンジニアは、仕様書の内容をコードに変換する作業に多くの時間を使ってきました。その変換自体が自動化されるので、価値の重心は前段に移ります。

• 顧客が本当に解決したい問題は何か
• 要求同士に矛盾がないか
• 例外ケースが抜けていないか
• 悪意ある利用者はどう悪用するか
• どのデータを収集しない方がよいか
• 何をシステム化せず、人間の判断として残すか

AIは曖昧な要求からでもコードを作れます。ただし、**曖昧な要求から作られたコードは、曖昧なまま高速に間違います。**しかも大量に。

ここで効いてくるのが、要求を明確な制約・受入条件・禁止事項に変換する能力です。前節で挙げた「仕様書から独立してテストケースを作る」も、この能力の延長線上にあります。

3-3. コードレビューから、根拠と証拠のレビューへ

AIが短時間で大量のコードを生成するようになると、人間が全行を目で追う運用は成立しません。レビュー対象が、コードそのものから証拠に移ります。

6番目の「何が対象外として飛ばされたか」は特に重要です。Claude Security は棚卸しフェーズで、トップレベルの各ディレクトリについて検査するか、飛ばす理由を書くかのどちらかを強制する設計になっています。これは裏を返せば、「飛ばした理由が妥当か」を人間が読む前提の設計です。スキャン結果の「検出0件」より、「何を見ていないか」のほうが情報量が多い場面は珍しくありません。

レビューの目的は「コードがきれいか」ではなく、システムが要求どおりに動き、許容できないリスクが残っていないことを確認することになります。

3-4. AIが安全に働ける環境をつくる

これは新しく増える仕事です。

AIコーディングエージェントには、ソースコード、シェル、クラウド、データベース、CI/CDへのアクセス権が渡されます。エージェントが高性能になるほど、誤操作やプロンプトインジェクションを受けたときの影響も大きくなります。

そこで、人間側が設計しなければならないものが出てきます。

• 最小権限のアクセス制御
• 本番環境への直接アクセス禁止
• サンドボックス内でのコマンド実行
• ネットワークアクセスの制限
• シークレットの分離
• 承認が必要な操作の定義
• 実行ログと監査証跡の保存
• AIが変更できるファイル・リソースの範囲制限
• 自動テストとポリシーチェックの関門
• 問題発生時のロールバック手順

興味深いのは、Claude Security プラグイン自体がこの原則で作られている点です。

• 全エージェントは読み取り専用ツールに制限されている
• パッチは作業ツリーとは別のクローンの中で作られ、手元のコードに触らない
• 生成されたパッチの適用は人間が git apply で行う
• セキュリティを弱める方向の変更（認証の緩和、テストの無効化）は自動で却下される
• プラグイン自体は隔離環境を持たないため、信頼できないコードを扱うときは別途サンドボックスを併用するよう明記されている

つまり、権限を絞り、書き込みを隔離し、適用を人間の手に残す。セキュリティ機能を作っている側が、自分のエージェントに対して最小権限を適用しているわけです。これは自分のプロジェクトでAIに権限を渡すときの、そのまま使える設計の型です。

OpenAIも、Codexの安全な運用について、制限された環境・サンドボックス・設定管理・詳細なテレメトリー・高リスク操作に対する人間のレビューを重視する方針を公開しています（OpenAIにおけるCodexの安全な運用）。

まとめると、AI時代の優れたエンジニアは、AIに多くの権限を渡す人ではなく、AIが失敗しても重大事故にならない仕組みを作れる人です。

3-5. 最終的な技術責任を負う

AIは修正案も判断理由も出せます。しかし、次の判断は組織と人間に残ります。

• このリスクを受け入れてリリースするか
• サービスを停止して修正するか
• 顧客へ報告する必要があるか
• 個人情報の漏えいに該当するか
• 法令や契約に違反していないか
• どのリスクを優先して直すか
• 予算と納期の中でどこまで対応するか

AIには、法的・契約的・経営的な責任を負わせられません。実装作業が自動化されるほど、人間の役割は「作業者」から「判断者」へ寄っていきます。

そしてこれは、仕事が楽になるという話ではありません。定型的で判断が要らない部分が道具に移るので、人間の担当範囲がより高リスクで曖昧な領域に集中するという意味です。

4. 価値が下がる業務・上がる能力

下がりやすい業務

• 仕様書どおりのCRUD実装
• フレームワークの定型コード作成
• 一般的なテストコードの作成
• 既知の脆弱性パターンの確認
• 単純なリファクタリング
• エラーメッセージの検索と修正
• 一般的なライブラリの導入
• 定型的なコードレビュー
• 脆弱性に対する定型パッチの適用

「コードを速く書ける」だけでは、長期的な差別化になりません。同じことは道具のスキルにも言えます。「Claude CodeやCodexを使える」という能力も、いずれGitやIDEを使えることと同じ前提スキルになります。

上がる能力

この7つに共通するのは、判断の根拠がコードの外にあるということです。だからこそ、コードを読めるAIには置き換えられません。

5. 開発会社にとっての変化

受託開発の側にも同じ変化が来ます。

「AIを導入して開発速度を上げた」だけでは差別化になりません。速く作れることは、遠からず前提条件になります。顧客に提供する価値は、コードの量や投入人月ではなくなります。

これから重要になるのは、こういう提供の形です。

AIを使って高速に開発しながら、要件・権限・セキュリティ・品質・運用を継続的に管理できる仕組みを提供する

そのとき、コード以外の成果物が価値を持ちます。

• セキュリティ要件
• 脅威モデル
• 権限マトリクス
• データフロー図
• AI利用ポリシー
• テスト戦略
• CI/CDのセキュリティゲート
• SBOM（ソフトウェア部品表）
• 監査ログ設計
• 脆弱性管理手順
• インシデント対応手順
• AIが行った変更と、その検証の履歴

最後の項目は、これから急速に重要になります。Claude Security がスキャンごとにタイムスタンプ付きのディレクトリを作り、人間が読める報告書と機械可読な検出結果、さらに検査時の深さ設定や重大度の内訳を記録した「リビジョンスタンプ」まで残す設計になっているのは、この用途を見据えたものです。「いつ・どの深さで・何を検査し、何が見つかり、何を飛ばしたか」が後から辿れることが、監査や説明責任の場面でそのまま証拠になります。

つまり開発会社は、「安全なコードを書く会社」から、AIを含む開発プロセス全体の安全性を設計・運用する会社へ移る必要があります。

まとめ

• Claude Security や Codex Security は真面目に検証を作り込んでいるが、検証のレンズは「コードの実態」に向いていて「仕様の正しさ」には向いていない。作るAIと検査するAIが同じ誤解を共有する共通原因故障は残る
• 対抗手段は多層化。とくに仕様書から独立して期待値（テストケース）を作る工程を残すことが決定的
• 自動化されるのは既知パターンの脆弱性。残るのは業務ロジックに依存する脆弱性で、これはコードの外の情報がないと判定できない
• エンジニアの役割は、①安全性の基準を決める ②問題を設定する ③コードではなく証拠をレビューする ④AIが安全に働ける実行環境を設計する ⑤技術責任を負う——へ移る
• Claude Security 自身が読み取り専用・別クローンでのパッチ生成・人間による手動適用という最小権限設計になっている点は、自社で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/
• OpenAIにおけるCodexの安全な運用: https://openai.com/ja-JP/index/running-codex-safely/