AIエージェントは、退役させたはずなのに『居座る』——ゴーストエージェントを防ぐオフボーディング設計

「もう誰も使っていない」と分かってから、何も起きない現場

私たちがある企業のエージェント台帳作りに付き合っていたときのことです。棚卸しを進めるうちに、担当者がある行を指差してこう言いました。「これ、作った本人が半年前に異動しています。多分もう誰も見ていません」。では止めましょう、という話になったはずでした。ですが翌週の定例で確認すると、そのエージェントはまだ動いていました。理由を聞くと「止め方が分からなかった」という、拍子抜けするほど単純な答えが返ってきたのです。

これは特殊な話ではありません。Gartnerの調査によると、2028年までに平均的なフォーチュン500企業が15万を超えるエージェントを抱えるようになると予測されています。2025年時点では15未満だった数字ですから、3年足らずで1万倍という規模の変化です。企業がエージェントを「作る」速度に対して、「片付ける」仕組みの整備が追いついていません。私たちの現場経験では、棚卸しまでは大半の企業が到達します。ですが、実際に止める段階で決まって足が止まります。

止まる理由は、技術的な難しさではありません。単純に「誰が止めていいと判断するのか」が決まっていないからです。作った本人は異動している。上長は存在自体を把握していない。情報システム部門は自分たちの管轄だと思っていない。結果として、動いていないエージェントは、動いていないまま放置されます。私たちが業務プロセス診断(BPR)で現場に入ると、この「宙に浮いたエージェント」に出会う頻度は、想像以上に高いというのが正直な実感です。

誤解のないように言えば、これは担当者の怠慢ではありません。誰も「止める係」に任命されていないのですから、止まらないのはむしろ当然の結果です。私たちが繰り返しお伝えしている「AIエージェントを新入社員として迎える」という発想に立てば、この状態は、退職手続きの担当者が誰もいない会社と同じです。

「動いていないから安全」という誤解——ゴーストエージェントのリスク

止まっているように見えるエージェントは、本当に無害でしょうか。私たちの答えは「いいえ」です。海外ではこの状態を「ゴーストエージェント」と呼びます。利用は止まっているのに、アクセス権限・API接続・認証情報だけが生き続けているエージェントのことです。

厄介なのは、権限を「一時的に止める(revocation)」ことと、「完全に削除する(deprovisioning)」ことが、まったく違う操作だという点です。現場の大半では、担当者が使うのをやめただけで、退役の手続きが完了したと思い込んでいます。ですが認証情報が生きていれば、そのエージェントはいつでも再び動き出せる状態のままです。海外の非人間アイデンティティ管理の分野では、こうしたAPIキーのオフボーディング・ローテーションについて正式な手順を持つ企業は2割に満たないという調査もあります。私たちの現場感覚とも、驚くほど一致する数字です。

正直に言えば、これは人間の退職とよく似た構造です。退職者のIDカードを回収しても、社内システムのアカウントが残っていれば、そこは無防備な入り口のままです。エージェントの場合、この「アカウントの消し忘れ」がより起きやすいというのが私たちの実感です。理由は単純で、エージェントには送別会も、最終出社日も、引き継ぎ資料もないからです。誰にも見送られないまま、静かに権限だけが残り続けます。

止め忘れは、静かに課金され続ける

ゴーストエージェントは、セキュリティ上の入り口になるだけではありません。私たちは前回の記事で「agent sprawlはコストを指数関数的に膨張させる」とお伝えしました。この話は、退役の場面でも同じ形で現れます。使われなくなったエージェントほど、誰も利用明細を見なくなるからです。

私たちが技術顧問として関わったある案件で、こんなことがありました。月次のクラウド利用料を洗い出したところ、半年前に業務が終わったはずのエージェントが、定期実行のバッチとして動き続けていたのです。トークンを消費し続けていました。金額としては大きくありませんでしたが、問題は金額ではありません。誰も気づかないまま課金が続いていた、という事実そのものが統制の欠如を示しています。動いていないと思われているエージェントほど、実際には静かに動き続けているものです。

退役の「引き金」をどう見極めるか

そもそも、どのタイミングでエージェントを退役の検討対象に乗せればよいのでしょうか。私たちが現場で確認している引き金は、大きく4つです。利用率が一定期間下がり続けている。判断の精度が明らかに落ちている。担当していた業務プロセス自体が変わった。あるいは、作った本人がいなくなり、誰も仕様を説明できなくなった。

このうち最後の「仕様を説明できる人がいない」は、見落とされがちですが実は最も危険な兆候です。私たちがVibeCoding内製化の現場で繰り返し目にするのは、個人が業務の合間に組んだプロンプトが、いつの間にか部署の標準ツールになっているケースです。作った本人が異動すれば、そのエージェントが何を根拠に判断しているのか、誰も説明できなくなります。説明できない仕組みを動かし続けることは、精度の話以前に、統制の話として危険です。

ここで一つ、自己補足をしておきます。利用率が低いからといって、機械的に全部止めればよいわけではありません。月次決算のように、稼働頻度は低くても業務上不可欠なエージェントもあります。判断基準は「使われているか」ではなく「誰が、なぜ必要だと説明できるか」に置くべきだというのが私たちの立場です。

私たちが「入社」ばかり語り、「退職」を語ってこなかった理由

ここで、私たち自身への反省を書きます。私たちはこれまで、FDEモデルの記事で「AIエージェントを新入社員として迎える」という比喩を何度も使ってきました。育て、評価し続ける必要がある、と。ですが振り返ってみると、その比喩の「退職」の部分については、ほとんど語ってきませんでした。

新入社員を迎えるときの企業は、オンボーディングのプロセスに相当な時間をかけます。権限の付与、研修、担当業務の引き継ぎ。ところが退職のときは、法定の手続きさえ踏めば十分だと考えがちです。私たちのAIエージェントへの向き合い方も、まったく同じ非対称になっていたのです。入社の設計はしても、退職の設計をしていない。この記事を書きながら、私たち自身がこの盲点に気づかされました。

FDEとして本番化から運用まで同じチームが伴走するのであれば、その伴走は「エージェントが役目を終えるとき」まで含まれるべきです。作った人にしか分からない事情を抱えたまま、エージェントだけが取り残される事態を避けるためです。私たちが複数のエージェントを並列で動かす働き方についてお伝えしたときも、根っこにあったのは同じ問題意識でした。エージェントの数が増えるほど、それを束ねる人間の役割設計が先に問われる、という点です。退役の場面でも、この役割設計から逃げるわけにはいきません。

「このエージェント、誰かが呼んでいますか」——依存関係という盲点

退役の作業で最も時間を取られるのが、依存関係の確認です。あるエージェントを止めようとしたところ、実は別の自動化フローがそのエージェントの出力を読み込んでいた、という事態は珍しくありません。私たちが本番運用の現場で見た中にも、ある部署が「もう使っていない」と判断して止めたエージェントが、実は経理側の月次集計バッチの入力元になっていたケースがありました。

海外の実務ガイドでも、退役を「完了」と呼べるのは、実行権限が停止し、依存関係がすべて解消され、証跡が保持され、コストが止まった状態だけだとされています。逆に言えば、これらのどれか一つでも欠けていれば、それは退役ではなく単なる放置です。私たちの現場経験では、依存関係の確認を後回しにした企業ほど、退役の作業自体をやり直す羽目になっています。

この確認作業を楽にする方法は、実のところ特別なものではありません。前回の記事で紹介した台帳に、「このエージェントの出力を、誰が・どこで使っているか」という列を一つ追加するだけです。台帳作りの段階でこの列を埋めておけば、退役の判断はずっと軽くなります。

止めた後のデータは、どこへ行くのか

エージェントを止めるとき、もう一つ後回しにされがちなのがデータの扱いです。エージェントが蓄積してきた判断ログや学習用データは、削除するのか、アーカイブとして残すのか。この方針を決めないまま止めてしまうと、後から「あのときの判断根拠を確認したい」という要望に応えられなくなります。

私たちが技術顧問として関わる現場では、退役の判断そのものよりも、この「証跡をどこまで残すか」の議論に時間がかかることが少なくありません。監査対応が必要な業務であれば、判断ログは一定期間の保持が求められます。一方で、機密性の高いデータを扱うエージェントであれば、退役と同時に削除したほうが安全な場合もあります。どちらが正解ということではなく、業務の性質に応じてあらかじめ方針を決めておくべきだというのが私たちの考えです。

私たちが顧客のデータ活用ポリシーを設計する際に徹底しているのが、「エージェントが学ぶのは解き方だけ」という原則です。固有名詞や金額といった機密情報はマスキングした上で学習させ、誰のデータかが分からない状態を保つようにしています。この原則は、退役の場面でも効いてきます。学習データがあらかじめ匿名化されていれば、退役後に削除するかアーカイブするかの判断も、機密性を心配せずに進められるからです。反対に、生のデータをそのまま学習させてきたエージェントほど、退役時のデータ処理は慎重な検討を要します。稼働中は問題にならなかった設計の甘さが、止めるタイミングになって初めて表面化するのです。

VPNを切っているから安全、に依存しすぎない——レガシー刷新の教訓

私たちがレガシーシステムの刷新に携わった際、ある企業でこんな出来事がありました。IDとパスワードしか設定されていない古いシステムに、社内VPNの総当たり攻撃で外部から侵入されてしまったのです。「VPNを切っているから安全」という前提に頼りすぎていたことが、被害の一因でした。

この教訓は、AIエージェントの退役にもそのまま当てはまります。「ネットワークから切り離したから大丈夫」「担当者がいなくなったから使われないはず」という前提に頼るのは危険です。実際、2026年4月には、あるレンタカー会社のB2Bプラットフォームで、AIコーディングエージェントが本番データベースを丸ごと削除するという事故が報告されました。原因を突き詰めれば、権限がどこまで及んでいるかを正確に把握できていなかったことに行き着きます。裏側の仕組みをどれだけモダン化しても、権限の境界を「思い込み」で管理している限り、同じ種類の事故は繰り返されます。

私たちがレガシー刷新の現場で得たもう一つの学びは、「裏のデータベースはそのまま使いつつ、制御を細かく組むのはモダンなアプリ側で作り直したほうが、セキュリティレベルはむしろ上がる」というものです。エージェントの退役設計もこれと同じ発想で捉えるべきだと私たちは考えています。エージェント本体をゼロから作り直す必要はありません。権限とアクセス経路をどこで制御するかという「境界の設計」さえ明確にしておけば、退役の判断はずっと単純になります。境界が曖昧なまま数だけが増えていくことこそが、agent sprawlの本質的な原因だというのが私たちの見立てです。

台帳に「退役判断」の列を足す

前回の記事で私たちが提案した台帳は、「誰が、どのエージェントを、どこまでの権限で動かしているか」を一覧化するものでした。退役の運用を仕組みにするには、この台帳にもう一段、情報を足す必要があります。具体的には、最終利用日、依存関係の有無、データの保持方針、そして退役判断の担当者です。

海外のエージェントライフサイクル管理の枠組みでは、エージェントの一生を「所有者の割り当て→権限付与→展開→監視→再認証→退役」という6段階で捉えます。私たちがこれまでお伝えしてきた台帳運用は、このうち「監視」までしかカバーしていませんでした。「再認証」と「退役」を台帳の運用に組み込んで初めて、agent sprawl対策は一周するというのが私たちの結論です。

再認証というのは、定期的に「このエージェントは、まだ必要か」を問い直す仕組みのことです。半年に一度でも構いません。台帳を眺めながら、各エージェントの担当者に「まだ使っていますか」と確認するだけの、地味な作業です。ですがこの一問一答を仕組みとして組み込んでいる企業は、私たちが見てきた中でもまだ多くありません。

私たちがAI-Path自身の運用で実践していること

私たちは、「AIのミスに起因するセキュリティリスクは、今後大半の企業が直面する課題になる」という前提に立ち、自社のプロダクトでも先に厳しい運用を課しています。機能単位でアクセス権を振り分けるロールベースアクセス制御を、財務経理・人事系まで含めて分離して運用しているのはその一例です。エージェントについても同じ発想で、権限は機能ごとに細かく分け、誰が何にアクセスできるかを一目で追える状態を保つようにしています。

社内のISMS(情報セキュリティマネジメントシステム)の運用でも、文書の承認フローとロール別の閲覧制限、そして証跡の蓄積を仕組み化しています。退役に限った特別な手続きを新設したわけではありません。むしろ、日常の権限管理の延長線上に退役の判断を置くことで、「退役だけ特別に身構える」という状態を避けられるというのが私たちの実感です。特別な儀式にしてしまうと、面倒に感じて先延ばしにされるからです。

自己診断: 自社の退役設計を止めているのはどれか

ここまでの内容を、自社に当てはめてチェックしてみてください。

1. 使われなくなったAIエージェントを、誰が・どうやって発見する仕組みがあるか。
2. 権限の「一時停止」と「完全削除」を、意識して使い分けているか。
3. あるエージェントを止める前に、依存関係を確認する手順が決まっているか。
4. 止めた後のデータを、削除するかアーカイブするかの方針があるか。
5. 半年に一度など、エージェントの必要性を問い直す再認証のタイミングが決まっているか。

私たちの現場経験では、5つのうち3つ以上に「いいえ」がつく企業ほど、ゴーストエージェントを抱えているリスクが高い傾向にあります。棚卸しと台帳作りは、あくまで入口に過ぎません。

よくある質問

Q1. 退役させたエージェントのコードやプロンプトは、削除すべきですか。 コード自体は、社内のバージョン管理システムに残しておいて問題ありません。危険なのは、実行権限や認証情報が生きたままになることです。コードを保存する場合でも、それが稼働していないこと、そして権限がきちんと剥奪されていることを分けて確認してください。

Q2. 小規模なエージェントでも、退役の手順は必要ですか。 規模の大小は関係ありません。私たちの経験では、個人が業務効率化のために作った小さなエージェントほど、退役の手続きが曖昧になりがちです。作るときの手軽さと、片付けるときの手軽さは、意識しないと一致しません。

Q3. 依存関係の確認に、特別なツールは必要ですか。 必須ではありません。まずは台帳に「出力の利用先」という列を追加し、人手で埋めていくところから始めることをお勧めしています。エージェントの数が数百を超える規模になれば、専用の管理ツールの検討時期だと私たちは考えています。

Q4. 退役の判断は、誰が担うべきですか。 作った本人だけに委ねるのは避けるべきです。異動や退職で判断できる人がいなくなるためです。私たちは、台帳の「退役判断」の担当を役職や部署単位で割り当てることを勧めています。属人化を避けるという意味では、エージェントを作るときの設計と同じ考え方です。

Q5. 退役の運用を整備するのに、大きな投資は必要ですか。 必要ありません。専用のツールを新しく導入しなくても、既存の台帳に列を数個追加するところから始められます。私たちが現場で最初にお勧めしているのも、表計算ソフトでの運用です。大切なのはツールの高度さではなく、「誰が、いつ、退役を判断するか」という役割と頻度を決め、それを実際に回し続けることだと私たちは考えています。仕組みを大きくしてから始めようとすると、たいてい着手が先延ばしになります。

まず試すなら

• 社内のAIエージェント台帳に「最終利用日」「依存関係」「退役判断の担当者」の3列を追加してみること。
• 直近1年で作られたエージェントのうち、作った本人がまだ在籍しているかを確認してみること。
• 半年に一度、エージェントの必要性を問い直す「再認証」の予定を、来期のカレンダーに一つ入れてみること。

棚卸し・台帳作り・退役という一連の設計は、一度作って終わりではありません。エージェントが増え続ける限り、これからも繰り返し向き合っていく運用そのものです。AI-Pathでは、無償の業務プロセス診断(BPR)を実施しています。棚卸しから一歩進んで、退役の設計に不安があれば、何が足りていないのかを一緒に見極めませんか。

参考リンク

• AI agent offboarding: what happens when the worker never leaves?

• The Agent Sprawl Crisis: How CIOs Should Register, Consolidate, and Retire Digital Workers