AIエージェントにも引退を：エンタープライズAIの廃止に向けたプレイブック

エンタープライズAIに関する文献には、ライフサイクルにおける盲点があります。エージェントのデプロイに関するガイドは至る所にありますが、 引退 させるためのガイドは極めて稀です。ライフサイクルのプロビジョニング（準備）側は、ID、スコープ、予算、評価、ローンチなど、詳細に文書化されています。しかし、廃止側は組織がすべての「終わり」に対して行うのと同じ扱い、つまり「自然に解決するだろう」という放置状態にあります。実際にはそうはならず、2026年のアイデンティティ調査は、「自然に解決する」という考えが何をもたらすかを示唆しています。 Graviteeによる2026年の調査 によると、エンタープライズのエージェント群は四半期ごとにほぼ倍増している一方で、エージェントのIDを個別に管理しているチームは全体の約5分の1に過ぎません。その結果生じる不可視のレイヤー、つまり誰が作成したか特定できない認証情報やアクターの集団には、 適切に廃止されなかったエージェントや認証情報が含まれている可能性があります。例えば、パイロット運用は終了したのにサービスアカウントは残っているもの、より優れたワークフローに置き換わったのに古いエージェントのキーが機能し続けているもの、退職したエンジニアの実験用トークンがそのまま残っているものなどです。廃止されていないエージェントは、最も防ぎやすい形の「ダークマター」です。急いでプロビジョニングしたからではなく、オフボーディングを怠ったために不可視のレイヤーに質量が加わっているのです。本稿では、ライフサイクルの欠けている後半部分、つまりエージェントの廃止に実際に何が必要か（単にプロセスを停止する以上の作業です）、そして「インベントリ、リダイレクト、取り消し、保持、墓碑銘、検証」という6ステップのプレイブックについて解説します。また、監査義務があるために、即座に一括削除することが、 誤った 判断となる理由や、その根底にある構造的なポイントについても触れます。引退のコストが低く、確実に行えるかどうかは、エージェントが稼働中にどれだけ適切に管理されていたかに完全に依存します。だからこそ、廃止はプラットフォームに対する最終的な論拠であり、これから作成するあらゆるエージェントについて最初に問うべきことなのです。

1. なぜ引退がライフサイクルの「難しい半分」なのか

プロビジョニングがうまくいくのは、すべてが現在進行形であり、明確な動機があるからです。チームはエージェントを必要とし、予算があり、ローンチのためにチェックリストが守られます。引退はこれらすべての条件を逆転させるため、静かに、そして頻繁に失敗します。動機は失われ、チームは代替手段へ移行し、パイロットのスポンサーは異動し、OKR（目標）に「何かを停止する」と書いている人はいません。知識も失われます。エージェントのキーの場所を知るエンジニアは去り、エージェント自体も個別に管理されていなかったため、インベントリには存在しません。さらにインセンティブも逆転しています。何かを停止すれば、誰かが忘れていた依存関係を壊すリスクがありますが、そのままにしておけば今日目に見えるリスクはありません。そのため、局所的には「そのままにしておく」のが合理的な行動となります。その結果、メカニズムが歯止めなく動き続けます。プロビジョニングがインベントリや引退のペースを上回ると、元のワークロードが消滅した後もIDや認証情報が蓄積され続けます。そして、エージェント特有の深刻な問題は、残されたものが単なる不活性なキーではなく、 自律的に動作し続けているということです。廃止されていないエージェントは、単に攻撃対象領域として存在するだけでなく、誰も目的を管理していない状態で、行動し、リソースを消費し、データにアクセスし続けます。今年のインシデントは、この教訓を裏付けています。侵害された、あるいは誤作動を起こしたエージェントは、その権限を取り消すことで封じ込めることができますが、誰も存在を覚えていないエージェントは、見つけることさえできないため、封じ込めることができません。廃止を規律として行うことは、組織がその資産状況を正確に把握し続けるための方法であり、ダークマターの分析が示すように、その正確な把握こそが、すべてを支える基盤なのです。

2. 6ステップのプレイブック

ここでは、文献では省略されがちな、典型的な失敗モードを防ぐための手順を紹介します。 インベントリ： エージェントが保持し、アクセスしているすべてのものを列挙します。認証情報（公式のものだけでなくコピーもすべて）、ツールのスコープ、予算項目、スケジュールされたトリガー、消費しているキュー、呼び出し元のシステム、参照しているダッシュボードなどが含まれます。エージェントがプラットフォーム上で個別に管理されていればインベントリ作成は容易ですが、そうでなければ考古学的な調査が必要になります。いずれにせよ、このステップを飛ばすと、ステップ3で本番環境に支障をきたすことになります。 リダイレクト（およびドレイン）： 権限を取り消す前に、インテーク（入力）を停止し、依存関係を移行してください。スケジュールされたトリガーを無効にして新規の処理が開始されないようにし、キューを排出または転送し、実行中の処理はチェックポイントを作成するか完了させ、子エージェントを停止します。また、アプリケーションプラットフォームが維持するエージェントレベルのサービスエイリアス、ワークフローレジストリ、ゲートウェイルート、あるいはその他の間接レイヤーを通じて、呼び出し元を後継先に誘導し、ダウンストリームのワークフローが接続先を失うことがないようにします。間接レイヤー経由で呼び出す依存関係は、1つのエントリを変更するだけで移行できます。エンドポイントをハードコードしている依存関係については、モデルの廃止を管理する際と同じ段階的な切り替え手順を、1つ上のレイヤーに適用して調整を行います。ただし、退役のモードによって判断が分かれる点に注意が必要です。計画的な置き換えにはリダイレクトが適していますが、侵害された、あるいは安全でないエージェントの場合は、通常は フェイルクローズ させるべきです。つまり、呼び出し元にはエラーを返し、誤った前提を引き継いだ後継先へ黙って接続させるようなことは避けます。 取り消し（Revoke）： すべての認証情報を無効化し（認証情報の取り消しは、そのコピーにも適用されます。これらは同一の認証情報であるためです）、スコープを削除し、IDを無効にします。また、エージェントが専用の仮想アカウントを持っている場合や、予算ルールと照合するための識別子が確実に伝播されている場合は、その支出ルールをゼロに設定し、ゲートウェイを通過するモデル呼び出しがこれ以上発生しないようにします。これは、インシデント対応のランブックにある封じ込め措置を恒久的に適用するものです。 保持（Retain）： 削除の衝動に駆られて見落としがちなステップです。退役したエージェントのトレース、意思決定、ガードレールの結果、評価履歴には、多くの場合、エージェントの寿命を超えて保持義務（監査、法的保持、組織自身の学習など）が伴います。一方で、データ最小化、契約上の義務、プライバシー保護、顧客からの削除要請などにより、逆の対応が求められる記録もあります。退役はエージェントを沈黙させますが、記憶を消去するわけではありません。何をどのくらいの期間保持するかは、直感ではなく文書化されたポリシーに従うべきです。中央トレースストレージこそが、この分離を単なる理想ではなく実現可能なものにします（監査体制）。ここで知識の継承についても触れておきます。エージェントが蓄積したプロンプト、スコープ、評価ケース、インシデントから得られたルールは、後継者への遺産です。これらを移行することこそが、資産の検証レイヤーをリセットするのではなく、世代を超えて積み上げていく方法なのです。 墓碑（Tombstone）： エージェントレジストリ、CMDB、ガバナンス台帳、または監査データベースなどに退役記録を保持します。これにより、退役したIDが所有者と終了日を持つ実在のプリンシパルとして特定可能になり、古い権限を継承するために名前が密かに再利用されるのを防ぎます。プラットフォームがエージェントの登録とともにIDを削除する場合でも、墓碑はランタイムではなくガバナンスの記録システム内に残ります。 検証（Verify）： 属性記録に対して4つのチェックを実行します。退役したエージェントに紐付くトラフィックの成功（ゼロである必要があります。それ以外の場合は取り消しが不完全か、別の認証情報が存在することを意味します）、取り消された認証情報を提示する失敗した試行（インベントリから漏れたコピーの無害な兆候であり、現在はロックアウトされています）、同じワークロードにマッピングされる未定義のIDからの成功した呼び出し、そして管理されたルート外でエージェントの依存先に到達するトラフィックです。プレイブックにおいて最も価値のある成果は、多くの場合、この検証ステップです。テレメトリによって、インシデントが発生する前にコピーやバイパスを捕捉できるからです。

3. プレーンの特性としての退役 — そしてプロビジョニングのテストとして

ここでTrueFoundryの役割が明確になります。このプレイブックの主張は構造的なものです。エージェントの運用ライフが管理されたレイヤーを通じて行われていれば、すべてのステップは低コストで済みますが、そうでない部分が多いほどコストは増大します。エージェントが、そのスコープ、予算、トラフィックがプレーンの記録として管理されている登録済みプリンシパルであれば、インベントリの確認はクエリを実行するだけで済みます（アクセス制御; 分析）——そして、アクセス権が環境変数に貼り付けられた共有キーである場合、それはフォレンジックプロジェクトとなります。これは「ダークマター」プロビジョニングパターンが予測可能な結末を迎える瞬間です。リダイレクトとは、プラットフォームが維持する間接レイヤーを通じて依存先が呼び出しを行う、単一のレジストリまたはルートエントリのことです。エンドポイントがハードコードされている場合、チームをまたいだ調整が必要な移行作業が発生します。IDが個別に管理されていれば、無効化は外科手術のようにピンポイントで行えます（1つのプリンシパルを無効にするだけで、他に影響は及びません）。しかし、認証情報が共有されていると、付随的な被害が生じます。これが、退職者のアカウント削除がいつまでも先延ばしにされる理由です。他の11個のサービスが使用しているキーを無効化する勇気など、誰にもないからです。保持については、定義されたポリシーに基づきリクエスト単位で中央にトレースが記録されていればシンプルで信頼性が高いですが、証拠がデプロイ先のローカルストレージに散らばっていると非常に脆弱になります。検証（トラフィックゼロのチェック）でさえ、ダークマター分析が提案した「属性レート」の仕組みそのものであり、1つのプリンシパルに対して実行されるものです。これらを踏まえると、本稿の結論は逆説的になります。 廃止はプロビジョニングのテストである。「どうすればこれをオフにできるか？」という問いを、最初の1リクエストが来る前のローンチ当日に投げかけることは、そのエージェントがガバナンスの下で誕生しているかどうかを一行で監査することに他なりません。つまり、個別のID、タスク由来のスコープ、強制された予算、エイリアス化された依存関係、中央集権的なトレースが備わっているかということです。この問いに答えられるエージェントは、午後には退役させることができます。答えられないエージェントは、組織を考古学的な調査プロジェクトに縛り付けるか、あるいは、より可能性が高いことですが、永久に退役させることができなくなります。Graviteeの2026年のデータによれば、四半期ごとに倍増していると言われる資産全体で「永久に退役させない」という事態が積み重なれば、目に見えないレイヤーが肥大化していくのは当然です。ライフサイクルの両端は、時制が異なるだけで、同じ規律を指しているのです。

4. 境界線、平易な説明

スコープと誠実さ。この6ステップのプレイブックは、サービスアカウントやワークロードIDの世界におけるライフサイクル管理の実践を、エージェント向けに適応させ、我々のダークマター分析やIDセンサス分析で引用したID調査記録に基づいて編集・統合したものです。これは標準規格ではありません。特に保持のステップは、管轄区域や業界によって異なる法的・規制上の義務と交差するものであり、ここに記載されている内容は法的助言ではなく、何をどのくらいの期間保持すべきかという専門的な助言に取って代わるものではありません。我々の関心は、すでに周知の通り、このプレイブックはガバナンスの効いたプレーン上では安価に実行できるが、そうでない場合は高コストになるという点にあります。我々はそのプレーンを販売しているため、手順自体はベンダー中立に保ちました（すべてのステップは、個別のID、取り消し可能なスコープ、強制された予算、エイリアス化されたルーティング、中央集権的なトレースを提供するあらゆるスタックで実行可能です）。また、製品マッピングは差別化要因ではなく、依存関係のステートメントとして構成しました。正確を期すために2つの補足事項を挙げます。TrueFoundryの仮想モデルはモデルレイヤーのルーティング（プロバイダーターゲット上の安定した名前）であり、エージェントサービスレジストリではありません。そのため、リダイレクトのステップでは間接レイヤーを汎用的に呼称しています。また、プラットフォーム上のエージェントIDはエージェントの登録と1対1で対応しており、現在はベータ版です。したがって、このプレイブックにおける「墓石（tombstone）」は、プラットフォームのライフサイクル状態ではなく、ガバナンスシステムが維持する記録を指します。本稿の限界として2点挙げます。第一に、このプレイブックはエージェントの運用フットプリントを対象としています。エージェントは以下のようなものも残します。 出力 ——作成されたドキュメント、変更された記録、影響を受けた意思決定など。これらは保持するシステム側のライフサイクルに属するものであり、アクター（エージェント）を廃止しても、生成された成果物までが自動的に処理されるわけではありません。第二に、墓石化と保持は組織が履歴を必要としていることを前提としていますが、特定の記録に対しては逆の対応を義務付ける正当なデータ最小化の体制も存在します。保持義務と削除義務が衝突する場合、それはエンジニアではなく弁護士が判断すべきトレードオフです。我々が明確に主張したいのは、本稿が埋めようとしているギャップについてです。業界はエージェントのライフサイクルの「誕生」については千回も書いてきましたが、「死」についてはほとんど書いてきませんでした。不適切な退役は、誰もが調査している「目に見えないエージェント層」を生み出す防ぎようのある要因の1つです。目に見える状態を維持できる組織とは、「どうすればこれをオフにできるか？」をローンチのゲートキーパーとして扱う組織でしょう。なぜなら、企業が運用する他のあらゆるものと同様に、エージェントもまた退役するからです。

参考文献

• 背景 — Gravitee, State of AI Agent Security 2026 （エージェントフリートの成長、約5分の1というID個別化の数値）。従来のサービスアカウントおよびワークロードIDのライフサイクル実践を適応。
• TrueFoundryのドキュメント — AI Gatewayの紹介（公式図）; アクセス制御; 仮想モデル（モデルレイヤー・ルーティング）; エージェントID（ベータ版）; 予算（公式イメージ）; 分析およびアトリビューション。
• 本ブログでは — MCPレイヤーにおけるOAuthおよびトークン管理; TBAC：タスクベースのアクセス制御; AIガバナンスおよび監査; コストアトリビューションおよび予算。

直接的な引用は行っておらず、調査の文脈は引用元のGraviteeレポートに基づき要約したものです。また、本プレイブックはコンプライアンス基準ではなく、編集上の統合案です。保持および削除の義務は管轄区域によって異なり、本内容は法的助言を構成するものではありません。本プレイブックが依拠するプラットフォームに対する当社の商業的関心については本文中で開示しており、手順自体は記載された機能を提供するあらゆるスタックで実行可能です。製品機能は執筆時点の公開ドキュメントに基づき要約しており、製品画像はTrueFoundryのドキュメント資産を帰属表示の上で転載したものです。

‍