AIコーディング時代の「セキュリティの民主化」

こんにちは、ひろかずです。

AIコーディングによる開発が爆発的に普及して、セキュリティやガバナンス側に摩擦が起きているのを見かけたので、一筆書きます。

「素晴らしいツールを入れたのに、誰も使ってくれない」「締め付けたらシャドウITが増えた」——そんな板挟みになっている情シスや開発チームの方に向けて、これからの守り方を整理してみました。専門家でなくても読み進められるように、用語はその都度かみ砕いて説明していきます。

目次

1. 忙しい人向けの要約
2. なぜ中央集権的な統制は追いつかないのか？
3. そもそもリスクってどう考えるの？
4. AIに「脆弱性を作るな」と指示すればいいのでは？
5. AIコーディング環境ってどうなってるの？
6. どこが狙われるのか？（攻撃表面）
7. なぜチェックはAIの「外」でやるべきなのか？
8. 決定論的チェックの2つのアプローチ
9. 民主化に必要な4つの要素とは？
10. 組織は事前に何を用意すべきか？
11. スキャン機構に求められる機能は？
12. それを支える土台：ゼロトラストと教育
13. ゲームチェンジャーは何か？
14. おわりに
15. 用語集

忙しい人向けの要約

• AIコーディングは開発者だけでなく非エンジニアにまで広がっていて、従来の「セキュリティチームが中央集権的にチェックして是正させる」やり方では追いつきません。
• かといって締め付けるとシャドウIT（管理の外で勝手に使われるIT）に流れるだけ。普及はもう止められないので、受け皿を用意する発想に切り替えるのが現実的です。
• 脆弱性は完全には防げません。だからこそ、AIの「外」で決定論的なセキュリティチェックを回す仕組みが要になります。
• 民主化に必要なのは「シフトレフト」「コードの集約」「ワークロードの集約」「検出結果の本人へのデリバリ」の4点。これを組織が用意する環境（リポジトリ・IaaS・SaaS・PC・スキャン機構）で支えます。
• これらを束ねるゲームチェンジャーとして、包括的なスキャンプラットフォームである Wiz を紹介します（開発者にフォーカスするなら Snyk という選択肢も）。

なぜ中央集権的な統制は追いつかないのか？

結論から言うと、「使わせる」ことを目指している限り、セキュリティは民主化しないからです。

開発において、セキュリティは上流から下流まで常につきまとう重要事項です。ところが現場は、ビジネスのコア機能の実装やアップデート、不具合修正に追われていて、セキュリティ対応はどうしても後追いになりがちです。

そこへトップダウンでセキュリティツールを入れても、こうなります。

• 開発者は習熟する時間が取れず、使いこなせない。
  • 「日頃から管理画面を見てくれれば」というのは、残念ながら甘い幻想です。
• 結局、従来のセキュリティチームが中央集権的にツールを回してチェックし、是正を求めて回る——という構図に逆戻り。
  • これでは件数に追いつけませんし、そもそもツールを使わせること＝民主化ではありません。

そして、AIコーディングが非エンジニアであるビジネスパーソンにまで広がる中で、この傾向は決定的になります。

• AIコーディングで好き勝手に開発されると、統制が追いつかない。
  • いわゆる AI Slop（AIが量産する玉石混交の生成物）が積み上がっていきます。
• だからといって締め付けると、今度はシャドウITにつながります。
  • データを持ち出して、統制の外で勝手に使い始める——という、いちばん避けたい流れです。
• AIコーディングの爆発的な普及は、もはや止められません。

止められないなら、閉め出すのではなく、安全に受け止められる受け皿を先に用意しておく。これが出発点になります。

そもそもリスクってどう考えるの？

ここで原則論を一つ。リスクは次の式で捉えられます。

リスク ＝ 脅威 × 脆弱性 × 発生可能性

図1：リスクを構成する3つの要素。掛け算なので、どれか一つを下げれば全体のリスクが下がる。

ポイントはシンプルです。

• 脅威はゼロにできません。 攻撃者の存在をこちらの都合で消すことはできないので、脆弱性と発生可能性をゼロにできない限り、リスクもゼロにはなりません。
• 物事と活動がある限り、脆弱性と発生可能性をゼロにすることも現実的ではありません。なので、現実的なゴールは「リスクをなくす」ではなく「リスクを下げる」ことになります。
• 掛け算の3要素のうち、自分たちでコントロールしやすいのが脆弱性です。つまり、リスク低減＝脆弱性への対応、ということになります。

表1：リスクの3要素と、手を打てるポイント。

AIに「脆弱性を作るな」と指示すればいいのでは？

「だったら、AIコーディングのときに脆弱性を作り込まないよう指示すればいいのでは？」——もっともな発想です。

実際、ある程度はできます。

• 生成AI側で security-guidance プラグイン を使えば、セキュリティのベストプラクティスに沿った実装を促し、脆弱性を検出することができます。
  • security-guidance プラグインは、Anthropic公式の GitHub Marketplace（anthropics/claude-plugins-official） から提供されています。

ただし、ここで楽観はできません。

• プラグインなどを使ってコーディングしたとしても、脆弱性が織り込まれるのは避けられません。
  • AIは確率論的に動作します。加えて、コーディング段階では、ワークロードが組み上がってデータが流れ込んだ後に「結果として」生じる脆弱な状態までは見通せません。
  • そのため、プラグインで対処できるのは、ワークロードを構成するパッケージやプラットフォームの設定ミス、そしてコード自体に含まれる欠陥に限られます。

だからこそ、コーディング段階だけで完結させず、組み上がったワークロードを見る後段の仕組みが必要になります。

AIコーディング環境ってどうなってるの？

対策を考える前に、まず守る対象（環境）の全体像を押さえておきましょう。AIコーディングが関わる環境は、ざっくり4つのレイヤーに分けられます。

• PC：手元でAIエージェントを動かす実行環境。
• Repository：AIコーディングで生成したコードを管理する場所。
• IaaS：AIエージェントで構成したアプリケーションやワークロードが動く場所。AIエージェントやMCPサーバーがここで動くこともあります。
• SaaS：ワークロードから見て、日々の業務で蓄積したデータが格納されている場所。

この図が表していること： 4つのレイヤー（PC・Repository・IaaS・SaaS）を色で分け、AIエージェントを起点に、コードやデータがどう流れ、どのトークン・シークレットを使ってアクセスするかを示しています。なお、図中のトークン・シークレットはその場所にホストされ、アクセスに使われるものであって、線に沿って「流れていく」わけではありません。注目してほしいのは、手元のPCにあるAIエージェント（A）が、LLM・リポジトリ・IaaSのプリンシパル・SaaSのデータ・MCPサーバーへと多方向につながっている点です。さらに、PC上のトークン・シークレット（B）を使って、MCPサーバー（I）経由でSaaSのデータ（G）にアクセスできる経路も描いています。つまり「手元の認証情報を使えば、巡り巡って本番データにアクセスしうる」——この一本の流れが、後で説明する攻撃経路（Attack Path）の正体です。

それでは、この図のどこが狙われるのかを具体的に見ていきます。

どこが狙われるのか？（攻撃表面）

AIコーディングで構成された環境では、こんな脆弱性をよく見かけます。

• インターネットから直接・間接的に到達できるEC2やLambdaが読み取るトークンが、平文のままストレージに格納されている。
• 強すぎる権限：インターネットから到達できるEC2やLambdaが、平文の機微情報に直接アクセスできる権限を持っている。
• 脇の甘い権限設定：ワークロードが使うユーザーやロールから、ガードレールなしでLLMを呼び出せてしまう。

これらを「攻撃表面（攻撃者が狙える接点）」として整理すると、次のようになります。

表2：AIコーディング環境の主な攻撃表面（場所／対象／リスク）。

これらに脆弱性を作り込まないことが肝心ですが、生成AIの特性を踏まえると、セキュリティチェックはAIコーディングの「外」で実行すべきです。理由は次のセクションで。

なぜチェックはAIの「外」でやるべきなのか？

生成AIには、こういうクセがあります。

• 生成AIは「十分条件を満たそう」とするため、必要最低限になりにくい。
  • 結果として、権限などが過剰に盛られがちです。
• AIのルール遵守は確率論的に動きます。「だいたい守る」けれど「必ず守る」わけではありません。

一方で、セキュリティチェックに求められるのは決定論的な保証です。「条件を満たすか・満たさないか」を取りこぼしなく判定したい。だから、確率論的に振る舞うAIの中だけで完結させず、AIの外で決定論的なチェックを別途回す必要があるわけです。

そして、それを網羅的にやるには、AIコーディングで実装された環境を包括的に監査する仕組みが要ります。

• 冒頭で触れたとおり、統制が追いつかないからとAIコーディングを締め出すと、シャドウITが加速して、いざ統制しようにも手に負えなくなります。
• たとえ今は統制が追いついていなくても、将来統制できるように、従業員がAIコーディングで作った環境を受け入れる「受け皿」を先に用意しておく——これが現実的な構えです。

決定論的チェックの2つのアプローチ

決定論的なチェックには、大きく2つのアプローチがあります。両者はどちらか一方ではなく、補完関係として両方やるのが前提です。

アプローチ1：コード開発段階のシフトレフト

シフトレフトとは、セキュリティチェックを開発の早い段階（左側）に前倒しする考え方です。プラットフォームの構成や、使うパッケージ・ライブラリに含まれる脆弱性を、コーディング段階で検出して直してからプッシュします。

• ここで見つけたい脆弱性の例：
  • ハードコードされたシークレット
  • package.json や Dockerfile を構成するコンポーネントの脆弱性
  • クラウドの設定ミス（0.0.0.0/0 からのアクセス許可、ストレージのインターネット公開など）
• ポイントは、いかに透過的にスキャンをかけるかです。
  • 「このツール使ってね」と渡すだけでは使われません。
  • 仮に使っても、使い方を覚える負担が増え、実行漏れのリスクも残ります。

そこで、2つの手法を組み合わせます。

• 手法1：リポジトリ側で、プルリクエストに対してセキュリティスキャンを自動実行する。
• 手法2：ローカルのコーディング環境で、プッシュにフックしてスキャンをかけ、直さないとプッシュできないようにする。

この2手法は排他ではなく補完関係なので、両方を実施します。

アプローチ2：実装されたワークロードへの継続的なセキュリティチェック

コードを一つずつ見るだけでは見つからない問題があります。ワークロードとして組み上がって初めて見える脆弱性です。

• 具体例：
  • 機微情報にアクセスできるコンポーネントに、過剰な権限が付与されている。
  • 使われていない強い権限が付いたプリンシパルが残っている。
  • ガードレールなしでLLMを呼び出せるプリンシパルがいる。
  • 平文のままストレージに格納されたシークレットがある。
• さらに、ワークロードを構成するOS・ミドルウェア・ライブラリに、新しく見つかった脆弱性やEOL（サポート終了）がないかも継続的に見つけます。

2つのアプローチを並べると、役割の違いがはっきりします。

表3：2つのアプローチの比較。入口（シフトレフト）と稼働後（継続的チェック）で守備範囲が異なる。

民主化に必要な4つの要素とは？

ここまでを踏まえると、AIコーディング時代の「セキュリティの民主化」——つまり、AIコーディングに携わるビジネスパーソン自身がセキュリティを手に負える状態——に必要なのは、次の4つに整理できます。

1. シフトレフト：ビジネスパーソンが、意識せずにコードへスキャンを実行できる状態をつくる。
   • コマンド実行型ツールなら、インストールからコーディング中の実行までを自律的にこなす「スキル」を作って配布する、というアプローチが考えられます。
2. コードの集約：シフトレフトをやりきれなかった場合の防波堤。
   • リポジトリへのプルリクエストにスキャンをかけるアプリを、Organization や Team などのテナント単位で設定します。重大な脆弱性が出たらマージを拒否して修正を促し、メインブランチへの混入を防ぎます。
   • 「シフトレフト」と「コードの集約」を押さえると、コーディング中のスキャンのサイクルが飛躍的に上がり、集約側でも生成コードを漏れなくスキャンできるようになります。
3. ワークロードの集約：生成AIで構成したワークロードを、組織が管理するプラットフォームに集約する。
   • こうすることで、組織による包括的なスキャンの恩恵を全体で受けられます。
4. 検出事項のデリバリ：ワークロードへの包括的スキャンと、その結果を本人に届けること。
   • ビジネスパーソンはセキュリティツールを学ぶ意欲が乏しく、結果を自分から見に行くことは期待できません。だから、検出結果を本人に直接デリバリして是正を促す必要があります。

組織は事前に何を用意すべきか？

上の4要素を成立させるために、組織側が先に用意しておくべきものがあります。4要素と対応づけると、こうなります。

表4：民主化の4要素と、組織が用意する構成要素の対応。

それぞれの中身を補足します。

• リポジトリ（GitHub Team / Enterprise など）：生成されたコードをすべて収容し、ビジネスパーソンが使うリポジトリをその中に置きます。
• プラットフォーム（IaaS：AWS Organization / GCP / Azure）：生成コードを実行する環境を収容するプラットフォームを用意し、各個人にアカウントを払い出します。
• データ保管先（SaaS）：実行環境からアクセスするデータをホストするクラウドサービスは、組織で管理しておきます。ワークロードが使うトークン・シークレット・OAuthアプリを棚卸しし、管理するうえで必要です。
• AIコーディングを行う環境（PC）：組織が管理するPCで統制しておき、AIエージェントを構成するパッケージ・ライブラリ・スクリプト・アプリの脆弱性を管理し、ネットワーク越しのデータの流通を捕捉できるようにします。
• 包括的なセキュリティスキャン機構：次のセクションで詳しく見ます。

スキャン機構に求められる機能は？

包括的なスキャン機構には、守る場所ごとに役割の異なる機能が求められます。アルファベットの略語が並びますが、それぞれ「どこを・何を見るのか」で整理すると分かりやすいです。

表5：スキャン機構に求められる主な機能と、その守備範囲。

それを支える土台：ゼロトラストと教育

上記の機能を活かすために、土台として2つを添えておきます。

• ゼロトラストアーキテクチャ
  • リポジトリ・クラウドプラットフォーム・各種SaaSのID・権限・認証認可を統制し、組織が管理する信頼できる構成のPCからのみ接続できるようにします。これで、管理されていないユーザーや脆弱なPCからのアクセスを制限できます。
  • SaaS・IaaS・PCを統制し、信頼に足るアクセスだけを許可することで攻撃表面が減り、AIコーディング普及下で本当にやるべきセキュリティ対策に集中できるようになります。
• 教育
  • ビジネスパーソン向けに全体観を解説し、その中で開発してもらうことで、自然とセキュリティが保たれた状態になることを理解してもらいます。

ゲームチェンジャーは何か？

ここまで挙げた機能（SAST・CWPP・CSPM・DSPM・SSPM）は数が多く、バラバラに導入すると運用が破綻しがちです。これらを統合したセキュリティスキャンプラットフォームが Wiz です。

• Wizは、リポジトリやワークロード、AIコーディングで生成したコードとワークロード、プラットフォームの構成情報を包括的にスキャンします。
• そして、膨大な脆弱性情報の中から実際に悪用しうる脆弱性を組み合わせた攻撃経路（Attack Path）を、Issueとして識別します。
  • 単体では軽微に見える弱点も、つながると一本の経路になる——図1で触れた「手元の認証情報が本番データに届く」流れを、機械的にあぶり出してくれるイメージです。
• ビジネスパーソンは、シフトレフトで脆弱性をプロアクティブに潰しつつ、検出されたIssueに基づいてAIを使って対応していく、という回し方ができます。

開発者にフォーカスするなら Snyk という選択肢もあります。ただ、これらの機能を網羅しつつ、ターゲットをAIコーディングを行うビジネスパーソンにまで広げるのであれば、コードからクラウドまでの一貫性を示してくれるCode to Cloud機能と傑出した可視性を持つWizが頭一つ抜けている、というのが現状の見立てです。

おわりに

AIコーディングの普及はもう止められません。だとすれば、閉め出して影に追いやるより、安全に受け止める受け皿を先に用意するほうが、結局は近道です。「使わせる」から「自然と守られる」へ。これがセキュリティの民主化の肝だと考えています。

なにかの参考になれば幸いです。

今日はここまでです。
お疲れ様でした。

用語集

• シフトレフト：セキュリティチェックを開発の早い段階（工程の「左側」）に前倒しする考え方。問題を後工程で見つけるより、コーディング中に潰すほうが安く早い、という発想です。
• SAST（静的アプリケーションセキュリティテスト）：プログラムを動かさずにソースコードを解析し、脆弱性の作り込みを見つける仕組みです。コードそのものを対象にします。
• CWPP（クラウドワークロード保護プラットフォーム）：仮想マシンやコンテナ、サーバーレスなど多様なワークロードを、環境を問わず脅威から一元的に保護するセキュリティソリューションです。
• CSPM（クラウドセキュリティ態勢管理）：クラウド基盤（IaaS）の設定ミスや脆弱性を検出する仕組みです。「ストレージが全世界に公開されている」といった危ない設定を見つけます。
• DSPM（データセキュリティ態勢管理）：データそのものに着目し、機微情報や個人情報がどこにあるか・混入していないかを把握する仕組みです。
• SSPM（SaaSセキュリティ態勢管理）：SaaSの設定ミスや、トークン・シークレット・OAuthアプリといった認証まわりを管理する仕組みです。
• シャドウIT：会社の管理・承認を経ずに、現場が勝手に使うITサービスやツールのこと。便利な反面、把握できないため、漏えいなどのリスク源になります。
• AI Slop：生成AIが大量に吐き出す、品質がまちまちな生成物を指す俗語。玉石混交のまま積み上がると、管理や品質維持が難しくなります。
• ゼロトラスト：「社内ネットワークだから安全」と無条件に信頼せず、アクセスのたびに本人・端末・権限を検証する考え方です。信頼できる構成の端末からだけ接続を許す、といった運用につながります。
• MCPサーバー（Model Context Protocol サーバー）：AIエージェントが外部のデータやツールに接続するための仲介役となるサーバーです。便利な一方、出どころ不明な「野良」のものはデータ流出経路になり得ます。
• Attack Path（攻撃経路）：単体では小さな弱点でも、つなげると本番データなどの重要資産に届いてしまう一連の経路のこと。「実際に悪用できるか」を起点に優先度を判断する考え方です。
• 最小権限：必要な作業に必要な権限だけを与え、それ以上は持たせない原則です。権限が過剰だと、万一突破されたときの被害が大きくなります。
• IaaS / SaaS：IaaSはサーバーやネットワークなどの「基盤」を借りて、自分でアプリを動かす形態（例：AWS、GCP、Azure）。SaaSは完成したアプリをサービスとして使う形態（例：各種クラウド業務サービス）です。
• EOL（End of Life）：ソフトウェアやOSのサポート終了のこと。EOLを過ぎると脆弱性が見つかっても修正されず、リスクが上がります。
• プリンシパル：操作の主体となるユーザーやロール（役割）のこと。誰が・何の権限で動いているかを表す単位で、権限設計の中心になります。