InfoQ が “Securing Autonomous AI Agents on Kubernetes: Trust Boundaries, Secrets, and Observability” を公開 しました。Kubernetes 上で動く自律 AI エージェントを 信頼境界・シークレット・可観測性 の 3 軸で守るためのアーキテクチャ指針が示されています。
受託開発の現場では、顧客の本番 K8s クラスタに 「夜間バッチで自律的にコードを修正・デプロイする AI エージェント」 を展開するケースが急増しています。これは従来の “ステートレス Web アプリ” とは異なるリスクプロファイルを持ち、従来の K8s 運用の延長線では守れない 領域です。本記事では、受託で顧客 K8s に自律 AI エージェントを展開する際の標準設計を整理します。
なぜ “従来の K8s 運用” では足りないのか
通常の Web アプリと自律 AI エージェントの本質的な違いを整理します。
| 観点 | 通常の Web アプリ | 自律 AI エージェント |
|---|---|---|
| 動作の決定性 | 高（同じ入力 → 同じ出力） | 低（同じ入力でも挙動が変わる） |
| 外部呼び出し範囲 | 設計時に固定 | 実行時に動的決定 |
| 必要権限 | 機能から逆算可能 | 実行してみないとわからない |
| 失敗時の挙動 | エラーを返して終了 | リトライ・別経路探索・自己修正 |
| 監査の容易さ | ログで追跡可能 | なぜその判断をしたか不明瞭 |
特に 「実行時に動的に外部呼び出し範囲が決まる」 性質は、K8s の NetworkPolicy で「許可された出口だけを開ける」設計と相性が悪く、過剰に開けるか、過剰に閉じてエージェントが詰まるか の二択になりがちです。
信頼境界の設計 — 3 層モデル
InfoQ 記事と弊社の実装経験を統合した 3 層信頼境界モデル です。
┌─────────────────────────────────────────────────┐
│ Layer 3: Outer Boundary（顧客環境境界） │
│ - VPC / Cluster Egress Gateway │
│ - NetworkPolicy で外部 LLM API のみ許可 │
└─────────────────────────────────────────────────┘
↑
┌─────────────────────────────────────────────────┐
│ Layer 2: Tenant Boundary（テナント境界） │
│ - Namespace ごとの ResourceQuota / LimitRange │
│ - PodSecurityAdmission（restricted） │
│ - サービスアカウント・RBAC の最小権限化 │
└─────────────────────────────────────────────────┘
↑
┌─────────────────────────────────────────────────┐
│ Layer 1: Agent Boundary（エージェント境界） │
│ - gVisor / Kata Containers（カーネル隔離） │
│ - read-only root filesystem │
│ - capabilities: drop ALL │
│ - 実行ツールは sidecar 経由で呼ぶ │
└─────────────────────────────────────────────────┘Layer 1（Agent Boundary） が最も重要です。自律 AI エージェントは「外部から細工された入力で意図しない操作を行う」可能性があるため、エージェント Pod 自身を gVisor 等で隔離 し、ツール実行は sidecar コンテナ経由 に分離します。エージェント Pod が破損しても、ホスト OS や他テナントへの影響を最小化できます。
これは HashiCorp Vault 2.0 と Identity Federation で扱った “エージェントの最小権限化” の思想と一体で、Vault の短寿命 secret 配布を Layer 1 内のみで完結 させるのが受託標準です。
シークレット配布 — “落ちている secret” を作らない
受託環境で最もやらかしやすいのが、エージェントに secret を渡す方法です。
Anti-Pattern 1: 環境変数に静的 API キー
env:
- name: OPENAI_API_KEY
value: "sk-..." # ← 絶対やらないエージェント Pod が侵害された瞬間、API キーが抜かれて 顧客アカウント全体が乗っ取り される構造です。
Anti-Pattern 2: ConfigMap に secret
kind: ConfigMap # ← Secret じゃない
data:
api-key: "sk-..."ConfigMap は監査ログから漏れやすく、バックアップ経由で secret が長期保存 されてしまうため避けます。
Recommended Pattern: 短寿命トークンの動的取得
[Agent Pod 起動時]
↓
[Vault / Workload Identity 経由で OIDC トークン取得]
↓
[OIDC トークンを LLM プロバイダの "STS 風" エンドポイントに提示]
↓
[15 分有効の API キーを発行]
↓
[15 分ごとに自動ローテーション、ファイルにも残さない]このパターンでは エージェント Pod 内に静的 secret が存在しない ため、Pod 侵害から secret 流出への直接の攻撃チェーンが切れます。
| secret 種別 | 配布方式 | 寿命 |
|---|---|---|
| LLM API キー | OIDC + STS 風エンドポイント | 15 分 |
| DB 接続情報 | Vault dynamic secrets | 1 時間 |
| クラウド IAM | Workload Identity | リクエスト毎 |
| 顧客 API キー | Vault + Transit | 用途ごと |
ツール実行の sandboxing
自律 AI エージェントが呼び出すツール（コード実行、シェル、ファイル操作）は、エージェント本体とは別 Pod / 別コンテナ で動かします。
[Agent Pod]
├ agent コンテナ（LLM 推論・判断）
├ tool-executor サイドカー（ツール実行ゲートウェイ）
└ observability サイドカー（ログ・トレース送出）
[Tool Pod（ジョブ単位で起動）]
├ shell-runner Pod（gVisor）
├ python-runner Pod（gVisor）
└ db-query-runner Pod（最小権限 SA）Tool Pod はジョブ単位で使い捨て にし、ファイルシステム・ネットワークを完全に切り離します。これにより、エージェントが「悪意ある shell コマンド」を生成しても、被害を Tool Pod 内に閉じ込められます。
これは AI エージェント本番DB削除ガードレール で扱った “破壊的操作の隔離” と同方向で、AI 本体に直接 DB 接続権限を持たせない設計が決め手です。
可観測性 — “なぜそうしたのか” を残す
自律 AI エージェントの可観測性は、通常のメトリクス・ログ・トレースに 「意思決定ログ」 を加えた 4 軸で構成します。
| 軸 | 内容 | 保管先 |
|---|---|---|
| メトリクス | リクエスト数、トークン消費、ツール呼び出し数 | Prometheus |
| ログ | 通常のアプリログ | Loki / CloudWatch |
| トレース | LLM 呼び出し → ツール呼び出しの連鎖 | Tempo / Jaeger |
| 意思決定ログ | プロンプト全文・出力全文・選択した経路 | 長期保管 S3 + 暗号化 |
意思決定ログ は、インシデント発生時に 「なぜ AI がこの操作を選んだのか」 を再現するために必須です。プロンプトと出力を すべて長期保管 することで、3 ヶ月後の事後調査にも耐えられます。
ただし、意思決定ログには顧客データが含まれるため、保管先の暗号化・アクセス制御・保持期間 の設計が必須です。
OPA / Kyverno による Pod 起動ポリシー
エージェントが新しい Pod を起動するケース（並列ジョブ、Tool Pod など）では、OPA Gatekeeper / Kyverno で起動許可ルール を強制します。
| ポリシー | 内容 |
|---|---|
| 許可された image registry のみ | 顧客の Container Registry 以外を拒否 |
| privileged: false の強制 | privileged Pod の起動を全面禁止 |
| read-only root filesystem の強制 | rootfs 書き込み Pod を拒否 |
| 特定 Namespace 限定 | エージェントは指定 Namespace 内でのみ Pod 起動可 |
| imagePullPolicy: Always 強制 | 古いイメージのキャッシュ攻撃防止 |
「エージェントが OPA に弾かれた Pod を生成しようとした」 という監査ログ自体が、エージェントの異常行動の早期検知に使えます。
受託サービス化 — 価格設計
自律 AI エージェント運用基盤の構築・保守を受託サービスとして提供する際の価格設計です。
| プラン | 構築費 | 月額 | 対象 | 内容 |
|---|---|---|---|---|
| Starter | 80〜150 万円 | 15〜30 万円 | 単一 K8s クラスタ、エージェント数 1〜2 | 信頼境界 + secret 配布の基礎構築 |
| Standard | 200〜400 万円 | 40〜80 万円 | マルチクラスタ or 高可用性要件 | Starter + OPA + 意思決定ログ + 24/5 監視 |
| Enterprise | 500〜1,000 万円 | 100〜250 万円 | 機微情報を扱う本番、コンプラ要件 | Standard + 監査資料 + 24/7 + ペネトレ年 2 回 |
構築費の内訳は 設計（30%）+ 実装（40%）+ 運用引継ぎ（20%）+ 監査対応（10%） が目安です。月額には 意思決定ログのストレージ費用 が大きな比重を占めるため、保持期間を顧客と握っておくことが重要です。
受託でハマりやすい 5 つの落とし穴
落とし穴 1: 顧客が “AI 用 Namespace” を区別できていない
既存のアプリ Namespace に AI エージェントを同居させると、事故時の切り分けが困難 になります。「AI 専用 Namespace + 専用ノードプール」 を契約条件に明記します。
落とし穴 2: GPU ノードのコスト爆発
エージェントの並列度を制御せずに走らせると、GPU ノードのオートスケールでコストが想定の 3〜5 倍 に化けます。Pod レベルでの並列上限 を OPA で強制します。
落とし穴 3: LLM プロバイダ障害時の挙動
OpenAI / Anthropic 障害時にエージェントがリトライループに陥り、ログが指数的に膨張 します。Circuit Breaker + 障害時の人間エスカレーション をデフォルトで組み込みます。
落とし穴 4: 意思決定ログの容量爆発
プロンプトを全保管すると 月数 TB に達する ケースがあります。「重要度別に保持期間を分ける」 ポリシーを設計時に決めます。
落とし穴 5: 顧客側の運用引継ぎ失敗
構築は完了したが、顧客側で運用できずに 「全部弊社が見続ける」 状態になりがちです。ランブック + Day-1 〜 Day-90 の運用訓練 を必ず納品物に含めます。これは Vercel Open Agents 受託保守 で扱った “顧客が運用できる形での納品” の思想と一体です。
まとめ — “AI を K8s に乗せる” の質を上げる
自律 AI エージェントを K8s に乗せる事例は急増していますが、信頼境界・secret 配布・可観測性 が標準化されないままの実装が多く、1 顧客の事故が業界の AI 導入機運を冷やす リスクが現実的になりつつあります。
弊社では、本記事の標準アーキテクチャに沿った K8s 自律 AI エージェント基盤の構築・保守 を Starter / Standard / Enterprise の 3 段階でパッケージ化しています。「自社 K8s に AI エージェントを安全に乗せたい」「既存のエージェント基盤を再設計したい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
