AIエージェントが100体に増えたら、権限、コスト、ミスは誰が管理するのか？

カタログ（Catalog）は検索でき、ID管理とつながっている必要があります。オーナー、スポンサー、バージョン、モデル、ナレッジ、ツール、環境、KPI、コスト、依存関係を記録します。ステータスにはDraft、Testing、Approved、Suspended、Retiredを用意し、承認の証跡も残します。

チームがユースケースを提案できる受付プロセスを設け、新しいエージェントの作成を認める前に、既存のエージェントで足りないかを確認します。共通のテンプレートとコネクターを使えば、重複が減ります。有効期限も設定します。使われていない場合やスポンサーが継続を確認しない場合は、システムが自動で権限を絞るか停止します。

共有アカウントは使いません。専用のIDを作り、どの操作がどのエージェントから来たのかをたどれるようにします。責任を負うスポンサーを決め、権限は最小権限の原則で与えます。ユーザーの代理として動くエージェント（Acting-on-behalf-of）と、セッションに人がいない状態で動く自律型エージェント（Autonomous Agent）は区別します。

期限付きのアクセス、承認、条件付きポリシーを使います。エージェントが読むのは、そのタスクに必要なデータだけです。連携を楽にするためだけに管理者権限を与えてはいけません。シークレットはVaultに保管し、ローテーションできるようにします。スポンサーが異動したら、担当の引き継ぎかエージェントの停止が自動で行われるようにします。

リスク区分によって、評価、監視、承認の方法と、アクセス権を見直す頻度が決まります。会議の要約に、融資の承認と同じ手続きを踏ませる必要はありません。ただし、どの区分でも責任者と、使ってよいデータは決めておきます。

ログには、リクエスト、計画、ツールの呼び出し、データソース、ポリシーによる判定、人の承認、結果をひとつながりで記録します。トレースIDを使って、複数のエージェントにまたがる処理を追跡します。機密データは必要以上に残さず、保存期間はリスクに応じて決めます。

ダッシュボードには、成功、例外、レイテンシ、コスト、ポリシー違反、結果を表示します。エージェントがいつもと違うパターンで動いたとき、ツールを異常に多く使ったとき、品質がドリフトしたときにはアラートを出します。リリースのたびに、サンプルを抜き出して再実行（リプレイ）し、ゴールデンケースでテストします。

複数の段階を踏むエージェントは、モデルやツールを何度も呼び出すことがあります。予算の上限は、タスク単位、エージェント単位、チーム単位、月単位で設定します。分類や抽出には小さなモデルを使い、高価なモデルは本当に推論が必要な場面に限ります。データはキャッシュし、ループの回数を制限します。

プレイブックを決めておきます。手順は、検知（Detect）、封じ込め（Contain）、権限の取り消し（Revoke）、ロールバック（Rollback）、通知（Notify）、振り返り（Learn）です。エージェントやツールごとのキルスイッチと、全体を止める緊急モードを用意します。エージェントが誤ったデータを大量に送ってしまった、認証情報が漏れた、といった想定で机上演習を行います。

重要なワークフローについては、手作業での代替手段と、最低限の処理能力を確保しておきます。設定、プロンプト、ポリシー、データリネージはバックアップします。ベンダー側で障害が起きても、仕事の進み具合がわからなくなる事態は避けなければなりません。RTO（目標復旧時間）とRPO（目標復旧時点）は、影響の大きさに応じて決めます。

フェデレーテッド型の体制をとります。中央のプラットフォームチームとセキュリティチームがID、ポリシー、オブザーバビリティ、カタログを担当し、各事業部門のチームがワークフロー、ナレッジ、成果に責任を持ちます。AI/エージェント委員会を設けて標準と高リスクの案件を扱い、日々のタスクを1つずつ承認することはしません。

四半期ごとにポートフォリオを見直し、エージェントごとにScale、Improve、Merge、Retireのいずれかを決めます。台帳のカバー率、アクセス権の見直し、インシデントを、事業上の価値と合わせて測ります。重要なエージェントは、作った人から独立したレッドチームや品質チームにテストさせます。