7月24日、Neel Shahが「AI Agents Are Writing Your Infrastructure Code. Is Anyone Governing It?」と題した記事を公開した。AIエージェントが生成するインフラコードは「構文として正しい」が「安全かどうか」は別問題だ——この当たり前のようで見落とされがちな事実が、2026年のプラットフォームエンジニアリングチームに突きつけられている。コードは高速に生成され、承認フローは追いつかず、ガバナンスは「すべての変更に人間の名前が付いていた時代」の設計のまま動いている。
セキュリティ合格率55%という数字の意味
元記事が引用するVeracodeのデータによると、AIによるコード生成タスクのうち、セキュアなコードを生成できるのは約55%に過ぎない。この数字は2年間ほとんど変化していない。一方で構文の正確さは95%を超えており、「コンパイルが通る」と「安全に実行できる」の間には大きな乖離がある。
より細かく見ると、脆弱性の種類によって合格率に大きな差がある。
| 脆弱性クラス | セキュア生成率 |
|---|---|
| SQLインジェクション（CWE-89） | 82% |
| 安全でない暗号アルゴリズム（CWE-327） | 86% |
| クロスサイトスクリプティング（CWE-80） | 15% |
| ログインジェクション（CWE-117） | 13% |
この調査は80のコーディングタスク、4言語、4つの脆弱性カテゴリを対象に、150以上のLLMを評価した結果だ。
XSS（CWE-80）の15%、ログインジェクション（CWE-117）の13%という数字は特に注目に値する。これらが極端に低い背景として、元記事は「文脈依存の出力エスケープやログ出力先の仕様をLLMが適切にモデル化できていない」点を示唆している。SQLインジェクション対策はパラメータ化クエリというパターンとして訓練データに広く存在するが、XSSやログインジェクションは出力先・フレームワーク・エンコーディング仕様の組み合わせによって正解が変わるため、汎用モデルが一貫して正しく生成するのが難しい構造にある。
最新のフラッグシップモデルについても元記事は言及しているが、全体的な合格率は同水準に留まるとされている。唯一の例外は推論特化型モデルで合格率が70〜72%程度に達するとされるが、それでも本番環境への無審査デプロイには不十分だ。
※編集部の考察：元記事では具体的なモデル名（GPT-5.1/5.2、Gemini 3、Claude 4.5/4.6等）の記載が確認できなかったため、上記では「最新のフラッグシップモデル」と表現した。元記事に記載のある数値・傾向のみを引用している。
特に危険なのはIAM（Identity & Access Management）ロールやセキュリティグループの設定だ。 複数リソースにまたがる権限フローの文脈的な推論が求められるこの領域は、LLMが最も苦手とするカテゴリと重なる。AIエージェントがIAMポリシーやネットワークポリシーをスケールで定義するとき、1つのミスが環境全体を露出させるリスクを持つ。元記事はその深刻さを補強するデータとして、複数環境にまたがる侵害の平均解決コストが数百万ドル規模、特定・封じ込めには数百日単位の時間を要するという業界レポートの傾向を参照している。
なぜこれはAppSecではなくプラットフォームエンジニアリングの問題か
アプリケーションコードの脆弱性は通常1つのサービスに閉じている。だがインフラコードの脆弱性——過剰なIAMポリシー、オープンなセキュリティグループ、設定ミスのあるストレージバケット——は環境全体を危険にさらす。この違いが、ガバナンスの責任をAppSecチームではなくプラットフォームエンジニアリングチームに引き寄せる理由だ。
プラットフォームチームは「paved road（整備された道）」——つまりTerraformが1行も書かれる前の段階でテンプレートとガードレールを定義する役割を担う。その対象はAIエージェントも例外ではない。エージェントが生成するコードも、同じガードレールを通過しなければならない。
元記事が指摘するもう一つの構造的リスクが設定ドリフトだ。インフラの実態とコードの乖離が頻繁に発生するチームは、IaCの品質が安定しているチームと比べて変更失敗率が有意に高いことが複数のDevOps調査で示されており、AIが高速生成するインフラ変更はこのドリフトを加速させる。量が増え、しかもセキュリティ品質が追いついていない——これが2026年のインフラリスクの核心だと元記事は述べている。
成熟したチームが実践する4つのガバナンス手法
記事では、AI生成インフラコードに対応している成熟したチームに共通する実践として以下の4点を挙げている。
生成前のPolicy as Code適用: CI/CDパイプラインでポリシー違反を検出するのでは遅い。HashiCorp Sentinelを使ってプラン前にポリシー検証を行うアプローチにより、ポリシー違反起因のビルド失敗を大幅に削減できるとされる。「修正による準拠」ではなく「設計による準拠」を実現する考え方だ。
AIエージェントへのRBAC・スコープ適用: エージェントを「新入社員」と同様に扱い、本番環境への広範なアクセスではなく、スコープを絞った権限と監査ログを付与する。最小権限の原則を人間だけでなくエージェントにも徹底することで、侵害時の爆発半径を抑える。
ドリフト検出の自動修正化: アラートを出して人間を待つ時代は終わりつつある。未承認の変更を自動でロールバックし、真に判断が必要な例外のみをフラグする仕組みへの移行が進んでいる。これにより、高速な生成サイクルに対してガバナンスのスループットが追いつく構造になる。
生成ステップへのコンプライアンス検証の組み込み: コードを生成してからスキャンするのではなく、生成時点でポリシーと照合することで、問題が下流に流れるコストそのものを減らす。
自チームの現状を確かめる5つの問い
記事は、プラットフォーム・DevOps・SREチームが現状を把握するための確認事項を提示している。
- 直近四半期のインフラ変更のうち、AIが生成したものを識別できるか
- AIエージェントは最も権限の少ないエンジニアと同等のRBAC・クォータ制約下にあるか
- ポリシー検証はコード生成前に行われているか、それとも提出後か
- ドリフト検出は自動修正するか、アラートを積み上げるだけか
- 特定の本番インフラ変更を誰（何）が承認したか、監査証跡を今日提示できるか
これらに自信を持って答えられないチームは、技術的に遅れているのではなく、ガバナンスが「すべての変更に人間の名前が付いていた時代」のまま設計されているということだ。 AIエージェントの導入速度に対して、承認・追跡・ロールバックの仕組みが追いついていない——この非対称性こそが、今チームが向き合うべき本質的な問題だと元記事は結論づけている。
詳細はAI Agents Are Writing Your Infrastructure Code. Is Anyone Governing It?を参照していただきたい。
