10月14日、Postmanが「AI Sprawl Is the New Shadow IT: How Postman Got Ahead of Ours」と題した記事を公開した。この記事では、社内で把握できていなかったAIエージェントの数が実は866件に上っており、Postmanがそのガバナンス整備に取り組んだ経緯と手法について詳しく紹介されている。
「何件動いてる？」と社内に聞いたら5通りの答えが返ってきた
Postmanの社内で「Slackから呼び出せるAIエージェントやコパイロットは今いくつ動いているか」と聞いて回ったところ、5人から5通りの答えが返ってきた。実際にシステムのログから集計した数字は866件だった。誰の予想よりもはるかに多かった、と記事は述べている。
この状況は、かつてSaaSの野良導入（シャドーIT）やクラウドスプロール（無秩序な拡張）で各社が直面したものと構造が同じだ。「作るのが簡単すぎるため、ガバナンスの整備が追いつかない」という繰り返しである。AIエージェントが異なるのは、一つ作るのに午後半日もかからないという点だ。SaaSやクラウドの波より明らかに速い。
なぜ今、AIエージェントのガバナンスが問題になるか
記事は主に3つの理由を挙げる。
1. コストがエージェント単位で見えない
AIの利用コストは使用量に比例して膨らむ。承認した1月の予算と3月の請求書が別物になる。ループに陥っているエージェントも、有用な作業をしているエージェントも、請求書の上では区別できない。
2. プロダクションに出た瞬間、それは本番ソフトウェアだ
「週末のハックで作ってSlackに繋いだもの」も、本番データにアクセスするクレデンシャルを持った瞬間、他の本番コードと同等のリスクを持つ。エージェントは自律的に動くため、誰かが「そこまでの権限を与える」と明示的に決めた覚えがなくても、タスクキューとクレデンシャルの組み合わせがそれを実現してしまう。
3. 同じ失敗を繰り返している
未パッチのシステムは侵害につながった。シャドーITとクラウドスプロールはセキュリティチームを長年追いかけっこさせた。APIスプロールはアクセス制御を複雑にした。AIが「コードが自動生成される」という性質を持つからといって、同じ結末から免れる理由にはならない、と記事は指摘する。
Postmanが実際にやったこと
ステップ1：使用記録からインベントリを作る
「意見を聞く」のをやめ、使用ログから一覧を生成した。これが866件という数字の出所だ。その一覧を社内で開発したエージェントプラットフォーム「Astro（Astropods）」のトップページに配置し、以後すべてのエージェントはAstro上でホストする運用に切り替えた。なお、AstroはPostman社内向けのプラットフォームであり、外部公開されているサービスではない。
ステップ2：「存在する」だけでなく「何をしているか」を把握する
インベントリは存在の有無しか答えない。誰がどの頻度で使い、何のモデルに何トークン費やし、どのシステムに触っているかをテレメトリとして取得することで、「許可するかどうか」という問いが「これは何をしていて、費用に見合っているか」という問いに変わる。Astroにエージェントを載せることでこのデータがデフォルトで取得できる設計になっている。
ステップ3：オーナーに連絡してから廃止する
エージェントを一方的に削除するのではなく、まずオーナーに使用状況の数字を添えて連絡し、返答を待った上で判断した。このプロセスは手作業ではなくスクリプト化されており、処理が中断しても途中から再開できるよう、結果をCSVに書き戻す設計になっている点がポイントだ。
# One admin API call retires one Slack app.
resp = session.post(
"https://slack.com/api/admin.apps.uninstall",
json={"app_id": app_id, "enterprise_id": enterprise_id},
headers={"Authorization": f"Bearer {token}"},
timeout=30,
)
if resp.json().get("ok"):
row["Status"] = "Uninstalled" # written back to the CSV, so the run resumes if interrupted
結果、「低使用・未使用」と判定された618件のうち592件（約95.8%）を廃止し、残りはAstroへ移行した。元記事でも同じ数字が示されており、処理件数・廃止件数ともに原文の記述に基づいている。
ステップ4：移行はClaudeで自動化した
既存エージェントをAstro向けにリポジトリ単位で作り直す作業は手動では現実的でないため、**Claude**をスキルとして呼び出すシェルスクリプトで一括変換した。各リポジトリをクローンし、Claudeがastropods.yml・Dockerfile・AGENT.mdを自動生成し、コンテナのビルドと起動を確認する流れだ。エージェントのロジック自体は変更しないよう明示的に指示している点が、実運用での安全弁になっている。
claude -p "Use the migrate-to-astropods skill to port this project to Astropods. \
Detect the runtime and entry point from the code, add astropods.yml, Dockerfile, \
and AGENT.md, and do not modify any agent logic. Proceed autonomously." \
--permission-mode acceptEdits \
--allowedTools "Read,Edit,Write,Bash,Skill"
実行結果の例：
| App | Files added | Status | Notes |
|---|---|---|---|
| ticket-triage-agent | astropods.yml, Dockerfile, AGENT.md | ✅ | built & started |
| release-note-helper | astropods.yml, Dockerfile, AGENT.md | ✅ | built & started |
| sales-research-agent | astropods.yml, Dockerfile | ✅ | built & started |
テーブルの各行は「どのエージェントに・何のファイルが追加され・正常起動を確認できたか」を示している。AGENT.mdはエージェントの目的・オーナー・依存システムを記述するドキュメントファイルであり、後からインベントリを検索・棚卸しする際の手がかりになる。
「一度の大掃除」では意味がない
記事が最も強調するのはここだ。掃除だけでは元に戻る。今回のインベントリは過去の一時点を対象にしたものだったため、作業を終えた時点で、その後に作られたエージェントは既に「見えない存在」になっていた。
解決策はシンプルだ。エージェントが作られる瞬間にガバナンスをかけること。Astro経由でしか新規エージェントを作れない運用フローをIT部門が強制することで、オーナー情報とコスト帰属が初日から付いてくる設計にした。
「監査の瞬間にガバナンスをかける会社」と「作成の瞬間にガバナンスをかける会社」の差が、最終的なコントロール可能性を分ける、と記事は結んでいる。
詳細はAI Sprawl Is the New Shadow IT: How Postman Got Ahead of Oursを参照していただきたい。
