本番稼働中のAIエージェントが「使われなくなっても停止されないまま権限を保持し続ける」現象——いわゆるゾンビエージェント——は、2026年時点で企業AI運用の代表的なガバナンス課題になっている。PoC終了後に放置されたエージェントが古いAPIキーを持ったまま動き続け、セキュリティ侵害の踏み台になるケースが報告されている。エージェントをソフトウェアと同様にライフサイクル全体で管理する設計を解説する。
本記事はAIエージェントガバナンスのピラーコンテンツに連動しています。
AIエージェントのライフサイクルとはなにか
AIエージェントのライフサイクルは計画から廃止まで6ステージで構成され、各段階に固有のガバナンス要件があります。
ソフトウェアのSDLCやMLOpsの概念はエージェントにも適用できるが、エージェントはツール呼び出し・マルチステップ計画・状態管理を行うため、単純なモデルデプロイより広範な制御が必要だ。
各ステージで管理すべき主な成果物:
| ステージ | 成果物・制御 |
|---|---|
| 計画 | 用途・スコープ・オーナー定義（エージェント憲章） |
| 開発 | コード・プロンプト・ツール定義のバージョン管理 |
| 評価 | 行動テスト・回帰テスト・レッドチーム |
| 本番稼働 | カナリアデプロイ・品質ゲート |
| 監視 | トレース・コスト計測・異常検知 |
| 廃止 | 権限失効・データ移行・監査ログ封印 |
なかでも「廃止」フェーズは設計が不十分になりやすい。廃止プロセスが整備されていなければ、エージェントはPoC終了後も権限を保持したまま動き続ける。監査ログ管理と組み合わせ、廃止時のログ封印まで一気通貫で設計することが重要だ。
4層バージョニングはどう設計するか
エージェントのコード・プロンプト・モデル・ツールAPIは独立して変化するため、4層バージョニングで個別に追跡することが有効です。
単一のバージョン番号でエージェントを管理しようとすると、プロンプト変更とモデルアップグレードが混在して問題の切り分けが困難になる。次の4層で識別する:
| 層 | 対象 | 変更の例 |
|---|---|---|
| ALV（Agent Logic Version） | 推論パターン・オーケストレーション | ReAct→Reflexionへの切り替え |
| PPV（Prompt & Policy Version） | システムプロンプト・安全制約 | ガイドライン追加・禁止事項拡張 |
| MRV（Model Runtime Version） | 使用モデルのピン止め | claude-sonnet-4-6→claude-sonnet-5 |
| TAV（Tool & API Interface Version） | 外部ツールのスキーマ契約 | CRM API v3→v4 |
識別子の例: support-agent:ALV-2.3.1_PPV-4.1.0_MRV-claude-sonnet-5_TAV-1.4.2
各層のSemVer分類はスキルにも適用する。ツール名の変更・入力スキーマの削除はMAJOR（破壊的変更）、後方互換のフィールド追加はMINOR、プロンプト最適化のみはPATCHとして扱う。これにより、プロンプト修正だけならPPVのPATCHを上げるだけでよく、モデル切り替えはMRVを上げてALVは維持するという粒度で追跡できる。
この4層バージョニングはシステムプロンプトの版数管理と相補的な関係にある。PPVはプロンプトガバナンスの一部として、GitOpsと統合して管理するとよい。
廃止プロセスはどう自動化するか
廃止は「タグ付け・監視・警告・完全削除」の4フェーズで自動化し、最終フェーズで権限失効とログ封印を完了することがゾンビ化防止の核心です。
手動の廃止プロセスは見落としやすく、エージェントが権限を保持したまま放置されるリスクを生む。以下の4フェーズを運用に組み込む:
Phase 1 — タグ付け: ツール定義のメタデータに@deprecatedタグを付与し、代替エージェントのエンドポイントを明記する。プロンプト内にも「本エージェントは廃止予定です」と記載し、LLMが自己申告できるようにする。
Phase 2 — 監視: テレメトリで呼び出し回数を計測し、移行の進捗をダッシュボードで可視化する。呼び出しゼロが30日続いたら自動フラグを立てる。
Phase 3 — 警告ペイロード: 呼び出し成功時もレスポンスに廃止日時を付与する:
``json``
{ "warning": "このエージェントは2026-09-01に削除予定です。新エージェントへ移行してください" }
Phase 4 — 完全削除: 停止・OAuth/APIキー失効・監査ログ封印を一括実行する。以降の呼び出しには移行先を明示したエラーメッセージを返す。
ゾンビエージェントをどう防ぐか
ゾンビエージェントは停止されずに権限を保持し続けるエージェントで、セキュリティ侵害の踏み台になるため、TTLと定期棚卸しで防止します。
成熟したガバナンスの指標の一つは「価値を生まなくなったエージェントをサンセットできるか」だ。ゾンビ化を防ぐ3つの制御を設計する:
- TTL（Time To Live）設定: エージェント定義にデフォルトのTTLを設け、更新がなければ「要レビュー」ステータスへ自動遷移させる。90日ごとの手動確認をトリガーするだけでも効果がある。
- エージェントレジストリ: デプロイ済みエージェントの一覧を管理し、オーナー・最終更新日・依存サービスを記録する。オーナーが異動・退職した際のハンドオフを手順化しておくことが重要だ。
- 定期廃止レビュー: 四半期ごとに「90日間呼び出しゼロ」のエージェントをリストアップし、廃止または継続を判断する会議を設ける。
規模別の留意点（SMB / エンタープライズ）
SMBへの提言: 4層バージョニングの完全実装は初期には過剰だ。PPV（プロンプトバージョン）とMRV（使用モデルのピン）だけをGitで管理し、エージェントごとにオーナーを指定するところから始める。廃止は四半期ごとの棚卸しシートで手動管理しても十分機能する。KuuのAi-Ops（AIエージェント運用管理サービス）では、小規模向けライフサイクル台帳テンプレートを提供している。
エンタープライズへの提言: 複数チーム・複数エージェントが並存する環境では4層バージョニングを完全実装し、廃止の4フェーズをCI/CDパイプラインに組み込む。エージェントレジストリをIDP（Internal Developer Portal）と統合し、オーナーシップの自動引き継ぎ通知と四半期アクセスレビューを連動させることで、ゾンビエージェントの残存を制度的に防げる。大規模体制の設計はRDEサービス（Reinvention Deployed Engineering）が対応する。
参考
- Versioning Agent Skills: SemVer, Compatibility, Deprecation — AIQuinta
- Versioning, Rollback & Lifecycle Management of AI Agents — Medium
- Trustworthy AI Agents: Agent Lifecycle Management — Sakura Sky
まとめ
AIエージェントのライフサイクルを6ステージで管理し、4層バージョニング（ALV/PPV/MRV/TAV）で変更を追跡し、廃止の4フェーズを自動化することでゾンビエージェントを防止できる。SMBは最小限のPPV＋MRVとオーナー台帳から着手し、エンタープライズはCI/CD統合まで段階的に拡張するとよい。エージェントガバナンス体制の設計・運用については、Kuuの運用管理サービス（Ai-Ops）への問い合わせを歓迎する。