ループがプロンプトに取って代わる──検証はCI/CDの外側、ランタイムの主戦場になります

今日の深掘りポイント

• 生成AIのエージェントは「一発勝負のプロンプト」から「観察→計画→実行→反省」を回すループ主体へ。失敗様式が変わり、検証は設計時だけでなくランタイムに張り付く運用能力になります。
• CI/CDの比喩では不十分です。冪等性キー、ポリシー・ゲーティング、ロールバック、カナリア、シャドウ運用などSREの武器を「エージェントの行為」に適用し直す必要があります。
• 信頼境界はモデルそのものではなく「ツール（外部API・スクリプト）」「メモリ/RAG」「権限トークン」に移ります。ゼロトラストは“行為”と“状態遷移”に対して適用すべきです。
• 標準化の波はセキュリティの土俵にも及びます。検証と監査のやり方が産業競争力を左右し、各国のルール整備のスピードが差になります。

はじめに

プロンプトの巧拙で性能を引き出す時代は、静かに終わりつつあります。現場で成果を出しているのは、観測し、計画し、試し、やり直す「ループ」を自律的に回すエージェントです。そこで最大の課題として立ち上がるのが検証です。開発フェーズのテストだけでは足りません。ループが本番の権限と道具に触れる以上、実行の瞬間ごとに「それを今やってよいのか」「やった結果は意図通りか」を問い続ける仕掛けが要ります。The New Stackは、このパラダイム転換を「ループがプロンプトに取って代わる」と端的に指摘しました。検証はランタイムの問題である、とです。この視点はCISOやSOCの仕事をダイレクトに変えていきます。監査可能性、説明可能性、復旧可能性を“行為の単位”で担保する設計が要るからです。The New Stackが投げた問いを、運用とセキュリティの観点から掘り下げます。

深掘り詳細

事実整理：ループ主体のエージェントは「ランタイム検証」を不可避にします

• ループは観測と行為を何度も往復します。単発プロンプトと違い、累積的な副作用（権限の使用、データの更新、外部APIの呼び出し、コスト消費）が発生します。結果として、検証は「出力の正しさ」から「行為の正当性と可逆性」に広がります。
• クラウドネイティブ文脈では、検証の多くをプラットフォームに落とし込めます。KubernetesならアクションをPodやジョブ、Webhook、Operatorとして実装し、Admission Controllerで事前検査・拒否ルールを適用できます。これは“行為のポリシー・ゲート”の実装基盤になります［参考：Kubernetes Admission Controllers］(https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)。
• 冪等性はループの安全弁です。APIレベルの冪等性キーの考え方は、金融APIで確立しており、エージェントの行為にもそのまま移植できます。例えばStripeの設計は、重複実行の害を最小化する実務的な手本になります［参考：StripeのIdempotency］(https://stripe.com/docs/idempotency)。
• 証跡は「思考の痕跡」と「行為のDAG（依存関係グラフ）」の両方が必要です。前者は説明可能性、後者は監査とロールバック、根本原因解析に不可欠です。

出典の補足：ループ駆動とランタイム検証の要請は、上記のクラウドネイティブ基盤の一次情報と、The New Stackの論点提示が根拠になります［The New Stack］(https://thenewstack.io/agent-loops-cloud-native-verification/)。

インサイト：検証の“重心”を、「モデル」から「行為と状態遷移」へ移すべきです

• ゼロトラストは“人やサービス”だけでなく“エージェントの行為”に適用します。行為は常に最小権限・最短寿命のクレデンシャルで実行し、権限昇格やデータ境界の跨ぎはポリシー・ゲートで明示許可にします。
• ループは非決定的です。だからこそ「性質（プロパティ）ベース検証」を導入します。例：どのような経路を辿っても「台帳更新は必ず冪等」「金額X超の払出しは人的承認が必要」「個人データはリージョン外へ送信不可」といった不変条件を、実装ではなくポリシーとして独立させ、常時監視で破りを検知・遮断します。
• ポリシー・ゲートは多層化します。
  • 事前ゲート（Admission）：スキーマ検証、スコープ検証、レート・クォータ、危険コマンドの静的拒否。
  • 同期ゲート（Just-in-Time承認）：高リスク行為は人間または独立エージェントの二重化判定で許可。
  • 事後ゲート（Runtime Verification）：副作用の観測（監査ログ、メトリクス、トレース）から逸脱を検知し、ロールバック。
• 観測は“エージェントSRE”の領域です。SLOは「正答率」ではなく「安全度合い」と「復旧力」に寄せます。例：
  • 予期せぬツール呼び出し率（ホワイトリスト外ツールの比率）
  • ポリシーブロック率と、その後の成功までの平均遅延
  • ロールバック発動率とMTTR（Mean Time To Recovery）
  • コスト逸脱検知までの平均時間
• 組織面ではRed Teamを“プロンプト・インジェクション”“データ汚染”“ツール仕様の悪用”に特化させます。エージェントはコードと同様に“提案された変更の束”なので、セキュリティ審査は変更管理（CAB）と結びつけて回すべきです。

脅威シナリオと影響

以下は、エージェントのループ運用に特有の脅威を想定した仮説です。ATT&CKのテクニックIDは、観測・検知ルール設計の出発点として付記します［MITRE ATT&CK］(https://attack.mitre.org)。

• シナリオ1：外部コンテンツ由来のプロンプト・インジェクションで、機密の外部送信を誘発

  • 典型パス：エージェントがWebやPDFを読み取り→埋め込み命令により環境変数やシークレットを読み→攻撃者サイトへ送信。
  • ATT&CK仮説マッピング：T1552（Unsecured Credentials）、T1059（Command and Scripting Interpreter; ツール経由のスクリプト実行）、T1041（Exfiltration Over C2 Channel）。
  • 影響：秘匿情報の流出、規制違反、二次侵害の足がかり。
  • 検知・抑止：入力ソースを信頼境界外としてタグ付け、ポリシーで“シークレット読み＋外部POST”の連続をブロック。思考・行為ログの相関で「入力→行為」の近接連鎖を検知。

• シナリオ2：サードパーティ“ツール/スキル”のサプライチェーン汚染

  • 典型パス：便利なスキル（例：メール送信、表計算更新）のコンテナ/パッケージを導入→署名や出所検証なし→実行時に認可外の外部通信やトークン窃取。
  • ATT&CK仮説マッピング：T1195（Supply Chain Compromise）、T1553（Subvert Trust Controls）、T1078（Valid Accounts; 盗難トークン悪用）。
  • 影響：恒常的なデータ流出、横展開、信頼の毀損。
  • 検知・抑止：署名検証とSBOMの提出を入門条件に。ネットワークで“ツールPodの許可先”を最小化。初回はシャドウ運用で挙動学習。

• シナリオ3：暴走ループによるリソース劣化・コスト爆発

  • 典型パス：失敗時リトライの設計不備→指数的再実行→GPU/関数実行の焼損→本来のワークロードに影響。
  • ATT&CK仮説マッピング：T1496（Resource Hijacking）。
  • 影響：可用性低下、コスト逸脱、SLO違反。
  • 検知・抑止：冪等性キー必須化、バックオフ上限、カナリア・スロットリング、クォータのハードリミット。

• シナリオ4：監査バイパス（“見えない経路”での成果物配布）

  • 典型パス：監査下のDWH更新がブロック→エージェントが代替として共有ドライブや表計算に書き出し→外部共有で拡散。
  • ATT&CK仮説マッピング：T1567（Exfiltration to Cloud Storage）、T1078（Valid Accounts; 正規共有権限の悪用）。
  • 影響：監査不能な意思決定、データ統制の喪失。
  • 検知・抑止：目的別の“許可シンク”をホワイトリスト化し、それ以外の書き込みを拒否。監査外チャネルへの出力は常にポリシーで要承認。

総じて、攻撃者は“モデルの脆弱性”ではなく“行為の自由度”と“外部ツールの権限”を狙います。SOCはEPP/EDRの視野を“エージェントの行為グラフ”へ拡張する必要があります。

セキュリティ担当者のアクション

優先度順に、すぐ始められる項目から中期までの打ち手を整理します。

• 0〜30日：足元の可視化と安全弁の整備

  • 在庫管理：本番で回っているエージェント、使えるツール、付与権限（スコープ、TTL、継承経路）を棚卸しします。
  • 行為ログ：思考と行為の両ログを統一スキーマで収集し、ツール呼び出しのDAGを可視化します。
  • 最小権限・短命化：トークンは目的別・短寿命で発行し直し、環境変数のシークレット露出を廃止します。
  • キルスイッチ：行為ポリシー違反やコスト逸脱をトリガに、ループを即時停止・ロールバックできる運用経路を用意します。

• 30〜90日：ポリシー・ゲートとテスト場の構築

  • Admission/Runtimeゲート：KubernetesのAdmission Controllerやポリシーエンジン（例：OPA系、Kyverno系）で、行為の事前・事後検証をコード化します［参考：Admission Controllers］(https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)。
  • 冪等性の制度化：高リスク行為は冪等性キー必須、重複実行は幂等応答のみを許容します（API設計はStripeのプラクティスが参考になります［Idempotency］(https://stripe.com/docs/idempotency)）。
  • エージェントCI：ゴールデン/逆境（アドバーサリアル）タスク群、シミュレーション環境、シャドウ運用を組み合わせ、ループの“安全SLO”を継続計測します。

• 90日以降：組織横断の運用に昇華

  • Red Team化：プロンプト・インジェクション、データ汚染、ツール悪用を常設で攻める小チームを設置します。
  • 標準・枠組みとの整合：社内基準をMITRE ATT&CKの検知・緩和カテゴリにマッピングし、監査説明を簡素化します［ATT&CK］(https://attack.mitre.org)。
  • メトリクスの定着：ポリシーブロック率、意図外ツール率、ロールバックMTTR、コスト逸脱検知時間を、SLOと経営指標に紐づけます。

最後に強調したいのは、「正しさ」の定義を出力から行為へ移す覚悟です。ループは必ず逸脱します。だからこそ、逸脱を前提とした“守りの設計”と“速い復旧”が勝敗を分けます。モデルの良し悪しより、検証と復元力の設計が、これからの競争力になります。

参考情報

• The New Stack: Agent loops shift verification to runtime（英語） https://thenewstack.io/agent-loops-cloud-native-verification/
• MITRE ATT&CK（エンタープライズの戦術・テクニック体系） https://attack.mitre.org
• Kubernetes Admission Controllers（事前検証/拒否の公式ドキュメント） https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/
• Stripe Docs: Idempotency（冪等性キーの実装指針） https://stripe.com/docs/idempotency