AIエージェント レジストリは、エージェント名を並べるだけの資産台帳ではありません。誰が業務上の必要性を説明し、誰が技術を管理し、どのデータとツールへ、どの権限で、どの公開チャネルから接続し、変更・停止・廃止の判断をどう残すかを一つにつなぐ運用基盤です。生成AIのPoCが部門ごとに増えた企業では、同じエージェントが複数環境へ複製され、担当者の異動後も権限が残り、どの版が本番か分からない状態が起こります。本稿は、タイを含む複数拠点でAIエージェントを導入する発注者向けに、ベンダー中立の台帳項目、RFP、PoC、90日計画、更新・停止・廃止、証跡の作り方を解説します。
結論：AIエージェント 台帳とcontrol planeを分けて設計する
先に要点を示します。
- 台帳は「現在の説明責任」を持つ正本、control planeは「実行時の許可・拒否・観測」を担う仕組みと定義する。
- 技術ownerとbusiness sponsorを分け、少なくとも各エージェントに業務上の責任者を置く。
- エージェント単位ではなく、開発・検証・本番などのinstance単位でID、権限、公開チャネル、データ依存を記録する。
- 「閲覧可能」と「利用可能」を分け、誰が発見でき、誰が起動でき、誰の代理で何を実行できるかを別々に管理する。
- 更新・停止・廃止を登録時に設計し、期限、再審査、kill path、証跡保持までをRFPの納品物にする。
- 最初の90日は全社製品統一を目指さず、発見、基準化、制御接続、運用定着の順で進める。
Microsoftの現行ドキュメントでは、Agent 365を全社のエージェントを発見・管理する統合レジストリ／control plane、Microsoft Entra Agent IDをIDとアクセス制御の基盤として位置づけています。また、Microsoft 365管理センターのレジストリは、Microsoft製、外部パートナー製、自社公開、作成者共有という異なる供給形態を一つの一覧で扱います。この方向性は重要ですが、発注者が作る社内標準は特定製品の画面項目に閉じてはいけません。Microsoft以外のクラウド、オンプレミス、製造業の独自API、RPA、MCPサーバー、業務SaaSにまたがる実態を同じ管理語彙で表せるようにします。
なぜ今、AIエージェント 管理を「台帳」から始めるのか
従来のアプリ台帳は、システム名、サーバー、担当部署、契約、障害連絡先を中心に作られてきました。AIエージェントでは、それだけでは実際の能力が分かりません。モデルが文章を生成するだけなのか、メールを送れるのか、ERPへ登録できるのか、ユーザー権限を代理行使するのか、夜間に自律実行するのかで、同じ「AIツール」でも影響が大きく変わります。
Microsoftはエージェントを、環境を理解し、判断し、利用可能なツールを使って目標達成を試みるアプリケーションとして説明しています。構成要素にはモデル、オーケストレーション、メモリ、ツールがあり、ツールにはWeb検索、データベース、API、ファイルシステムなどが含まれます。したがって登録対象はチャット画面だけではありません。オーケストレーター、実行ID、ツール接続、メモリ、知識源、公開チャネル、下流システムまで含めて初めて「何ができるか」を説明できます。
見えないエージェントは統制できない
現場では次のようなshadow agentが生まれます。
- 個人が作成し、Teamsや社内ポータルで共有したエージェント
- SIerがPoC環境へ残したサービスIDとコネクタ
- RPAへLLM判断を追加したが、AI案件として登録されていない自動化
- 複数エージェントを呼ぶ親エージェントの配下で動く子エージェント
- 廃止済みと認識されているが、APIキーとスケジュールが残るジョブ
- 同じ名前で開発、UAT、本番が存在し、利用者が区別できない公開物
Microsoft 365管理センターのレジストリでも、所有者不在や管理外のエージェントを区別して表示する考え方が示されています。ここから得るべき実務上の教訓は、最初から100%正確な台帳を作ることではなく、「発見→仮登録→責任者確認→制御接続→定期再確認」の流れを継続することです。
ID一覧と業務台帳は同じではない
Microsoft Entraの一覧では、agent identity objectだけでなく、サービスプリンシパルを使うエージェントも表示対象になり、状態、Object ID、Blueprint App ID、ownerとsponsor、権限、監査・サインインログへアクセスできます。一方、会社が必要とする業務台帳には、目的、対象プロセス、利用部門、期待効果、禁止用途、データ分類、法的根拠、停止時の代替手順も必要です。
したがって、IDディレクトリをそのまま台帳の正本にするのではなく、両者を安定した識別子で連携します。IDがまだ無いエージェントも仮登録し、「identity status = missing」として是正対象にします。逆にIDが存在しても、業務目的とsponsorが確認できなければ本番承認しません。
AIエージェント レジストリの最小データモデル
最初から項目を増やしすぎると更新されなくなります。必須項目、条件付き項目、証拠リンクを分け、入力者と自動取得元を明示します。
| 領域 | 最低限の項目 | 管理上の質問 |
|---|---|---|
| 識別 | Registry ID、名称、instance ID、環境、版 | 同じエージェントのどの実体か |
| 目的 | 業務目的、対象プロセス、利用者、禁止用途 | なぜ必要で、何には使わないか |
| 責任 | technical owner、business sponsor、運用窓口、代行者 | 技術変更と業務継続を誰が判断するか |
| 公開 | チャネル、対象ユーザー、discoverable/deployed/pinned | 誰が見つけ、誰が利用できるか |
| ID | principal、認証方式、委任／自律、credential保管 | 誰の権限で動作するか |
| 権限 | tool、action、resource、scope、期限、承認 | 何を読み、何を変更できるか |
| データ | 情報源、分類、保存先、越境、保持、学習利用 | 何が入力・記憶・出力されるか |
| 依存 | model、orchestrator、MCP/API、下流システム | 一つの変更がどこへ波及するか |
| 運用 | SLO、監視、相関ID、当番、障害時手順 | 異常を誰がどう発見するか |
| ライフサイクル | 登録日、承認日、次回審査、停止条件、廃止日 | いつ見直し、どう止めるか |
| 証拠 | 設計、承認、テスト、権限差分、ログ、廃止記録 | 判断を後から再現できるか |
Registry IDとinstance IDを分ける
一つの業務エージェントに、開発、結合試験、UAT、本番、災害復旧環境がある場合、業務目的は共通でも権限とデータは異なります。Registry IDは論理的な製品／ユースケースを表し、instance IDは実行実体を表します。例として、購買照会エージェントをAGR-PROC-017、本番実体をAGR-PROC-017-PRD-TH01とします。クラウドのObject ID、アプリID、ワークロードIDはinstanceに関連づけます。
technical ownerとbusiness sponsorの責任を混ぜない
Microsoft Entra Agent IDの管理モデルでは、ownerは設定、資格情報、運用を扱う技術管理者、sponsorは目的、アクセスレビュー、更新・保持・廃止の判断に責任を負う業務代表として区別されています。現行ドキュメントでは、agent identityとblueprintには少なくとも一人のsponsorが必要で、ownerは任意です。またownerにはユーザーやサービスプリンシパルを割り当てられますがグループは使えず、sponsorには一定種類のグループも利用できます。
社内標準では製品仕様をそのままコピーせず、次のように責任を定義すると分かりやすくなります。
| 役割 | 主な責任 | 単独で決めてはいけないこと |
|---|---|---|
| Business sponsor | 目的、利用範囲、費用、継続・停止、残余リスク | 資格情報や本番設定の直接変更 |
| Technical owner | 構成、ID、権限、監視、更新、障害復旧 | 業務必要性の自己承認 |
| Data owner | データ利用条件、分類、保持、越境、削除 | エージェント全体の本番承認 |
| Security/IT | 基準、例外、権限レビュー、インシデント | 業務価値の代理判断 |
| Service operator | 日次監視、一次対応、証拠収集 | 範囲拡大や高リスク変更 |
異動や退職に備え、ownerとsponsorの代行者、引継ぎ期限、未割当時の自動停止条件を登録します。グループをsponsorに使う場合も、実際に会議へ出て継続判断できる代表者を別途明記します。Microsoftの資料では動的グループをsponsorに使う場合、メンバーシップ変更後の認可確認に最大24時間かかる可能性があるため、緊急引継ぎ経路をグループ同期だけに依存させません。
公開チャネルと権限を分ける
Teams、Outlook、Copilot、SharePoint、Web、モバイル、API、バッチなど、チャネルは利用者がエージェントへ到達する面です。チャネルが同じでも、利用者グループ、テナント、国、端末条件、時間帯が違えばリスクは変わります。「公開」は少なくとも次の状態へ分けます。
- Discoverable: 検索やカタログで存在を確認できる。
- Available: 指定ユーザーが自分で追加できる。
- Deployed: 管理者が対象者へ配布済み。
- Pinned: 目立つ位置に固定表示される。
- Callable: APIや別エージェントから機械的に呼び出せる。
画面に見えないAPI呼出しは、チャネル欄が空ではなくA2A/APIとして記録します。親エージェントからのみ呼ばれる場合も、利用者の代理権限、呼出元allowlist、レート、再帰制限を残します。
AI control planeで実行時に制御するもの
レジストリへ正しい情報を書いても、それだけでは過剰権限の呼出しを止められません。control planeは台帳を参照し、実行時のID、ポリシー、ツール、データ境界、観測、停止をつなぎます。製品は一つでなくても構いません。ID基盤、API gateway、秘密管理、ポリシーエンジン、SIEM、承認ワークフローを組み合わせられます。
一意なIDと最小権限
Microsoftのleast privilegeガイダンスは、エージェントごとに専用ID、owner/sponsor、承認者を置き、目的、データアクセス、ツール依存、実行環境を文書化することを推奨しています。権限はロール名だけでなく、resource、data、actionの境界で定義し、未審査のツールやクロステナント経路を既定で拒否します。
台帳の権限欄には「ERPアクセス可」と書かず、次の粒度で記録します。
| 項目 | 良い記録例 | 避ける記録 |
|---|---|---|
| Action | purchase_order.read | ERP利用 |
| Resource | TH法人、Plant 01、承認済みsupplier | 全社 |
| Data | 金額、納期、品目。銀行口座は除外 | 購買データ |
| Mode | 自律読取、書込は人の承認後 | user permission継承 |
| Duration | 90日、四半期審査 | 無期限 |
| Evidence | policy ID、承認番号、テスト結果 | メールで合意 |
高権限が必要な操作は、常設ロールではなく短命トークン、JIT、個別承認を検討します。複数の狭い権限を組み合わせた結果、実質的に広い操作が可能になる場合があるため、ツールごとの権限だけでなく、ワークフロー全体のeffective permissionをレビューします。
toolとactionのallowlist
「MCP接続可」「プラグイン利用可」では広すぎます。サーバー、ツール、action、入力schema、対象resource、最大件数、タイムアウト、再試行、冪等性、human approvalを登録します。検索エージェントに削除actionは不要です。チケット作成エージェントにはcreate/updateだけを許し、deleteとadminを拒否します。大量更新、外部送信、支払、権限変更などは個別ゲートを置きます。
下流システムはオーケストレーターの判定だけを信用せず、毎回IDとscopeを再検証します。AIが「許可済み」と文章で主張しても権限証明にはなりません。ポリシー決定、実際のAPI認可、結果を同じ相関IDで結びます。
監査証跡は会話ログだけでは足りない
必要な証拠は、要求者、agent identity、代理対象ユーザー、role、scope、tool、action、resource、ポリシー版、承認、結果、相関ID、時刻です。プロンプト全文を無制限に保存すると個人情報や秘密が増えるため、目的、マスキング、保持期間、閲覧権限を決めます。再現に必要な構造化イベントと、機密を含み得る会話本文を分けます。
停止は四層で設計する
停止ボタン一つでは不十分です。
- Discovery停止: 新規利用者から非表示にする。
- Invocation停止: 新規セッション、API呼出し、スケジュールを拒否する。
- Privilege停止: トークン失効、鍵ローテーション、role削除、下流allowlist解除を行う。
- Data/Lifecycle処理: queue、memory、監査ログ、成果物、法的保持、削除を処理する。
停止後に再開できるのか、廃止として不可逆にするのかも区別します。incident containmentでは迅速なdisable、計画廃止では依存先移行と証拠保全が中心になります。
90日でAIエージェント 台帳を立ち上げるロードマップ
90日は完全な統合の期限ではなく、管理不能な状態を脱して継続運用を始める目安です。製品購入から始めるのではなく、情報モデルと意思決定を先に揃えます。
0〜15日：発見と仮登録
まずIT、セキュリティ、データ、購買、主要業務部門で共通定義を決めます。「AIエージェント」を、モデルを持つものだけに限定せず、自律的に計画しツールを呼ぶ仕組み、他のエージェントから呼ばれる実行単位まで含めます。
発見元は、IDディレクトリ、クラウドのアプリ登録、API gateway、秘密管理、SaaS管理画面、ネットワークログ、経費・契約、ブラウザ拡張、RPA、MCP設定、開発リポジトリ、部門アンケートです。自動検出の結果は即本番台帳へせず、discovered/unverifiedで仮登録します。
この段階の成果物は、登録基準、最小項目、責任分担、仮一覧、重大度分類、未確認owner一覧です。公開停止を一斉に行うのではなく、所有者不明かつ高権限、外部共有、機密データ、決済・削除機能を持つものから隔離・確認します。
16〜30日：責任者とリスクTierを確定
各エージェントへtechnical ownerとbusiness sponsorを割り当て、業務目的、対象者、公開チャネル、データ、ツール、環境を確認します。ownerが見つからないものは暫定管理者へ移し、期限内にsponsorが決まらなければ停止します。
リスクTierはモデル性能ではなく、行動能力と影響で決めます。
| Tier | 代表例 | 最低統制 |
|---|---|---|
| T1 | 公開情報の検索・要約 | 利用規約、出典、基本ログ |
| T2 | 社内情報の検索、下書き | ID、データ境界、owner/sponsor、アクセス審査 |
| T3 | 業務システムへの制約付き書込 | 個別ID、action allowlist、承認、negative test、停止試験 |
| T4 | 高影響の自律実行、権限変更、外部送信 | 独立承認、JIT、強化監視、演習、経営レベル残余リスク受容 |
31〜45日：レジストリとID基盤を接続
台帳のinstance IDを、クラウドObject ID、service principal、workload identity、API clientへ結びます。IDが無いものは発行計画を作り、共有credentialを段階的に廃止します。開発と本番でIDを共用しません。
自動同期は、状態、最終サインイン、credential期限、role、owner、公開チャネルなど客観情報に使います。業務目的、禁止用途、sponsorの判断、残余リスクは人が承認します。自動同期が空欄を上書きしたり、手動の承認記録を消したりしないよう、field ownerを定めます。
46〜60日：権限・チャネル・依存を可視化
エージェントからtool、data source、下流systemまでの依存グラフを作ります。APIキーだけでなく、ユーザー委任、managed identity、service account、webhook、バッチ、queueを含めます。権限をread/write/adminに粗く分類した後、T3/T4はactionとresourceへ分解します。
公開チャネルごとにdiscoverable、available、deployed、pinned、callableを確認し、対象グループと外部共有を記録します。廃止候補を非表示にするだけでなく、API呼出しとスケジュールも停止できるか確認します。
61〜75日：PoCでcontrol planeと停止を検証
低・中・高リスクから一件ずつ選び、台帳を参照して実行時ポリシーを適用します。許可試験だけでなく、禁止されたresource、期限切れapproval、別チャネル、別tenant、過剰件数、重複要求、owner不在、credential失効を試します。
既存のAIエージェント受入試験ガイドに沿って、想定入力、異常系、承認、証拠を試験ケース化します。API運用の監視、冪等性、再試行、rate limitはAIエージェントAPI運用設計と組み合わせます。本稿の焦点は、個々の回答品質ではなく、全社の台帳とライフサイクル統制です。
76〜90日：運用会議とKPIを定着
週次で新規登録、owner不在、期限切れ権限、失敗した同期、高リスク変更を確認します。月次でsponsorへ継続必要性と利用実績を示し、四半期または重大変更時にアクセスレビューを行います。KPIは登録件数の増加だけにしません。
- 本番エージェントのうち一意なidentityを持つ割合
- technical ownerとbusiness sponsorが有効な割合
- 権限に期限と承認証拠がある割合
- tool actionを端から端まで相関IDで追跡できる割合
- owner不在を発見してから暫定措置までの時間
- disable要求から新規呼出し拒否、token失効までの時間
- 期限切れ、未使用、重複エージェントを廃止した件数
- 重大変更後に再審査・再試験を完了した割合
RFPに入れるべきAIエージェント レジストリ要件
製品名ではなく、検証可能な能力と納品物で要求します。
1. 発見と登録範囲
「対応プラットフォーム」を列挙させるだけでなく、Microsoft製、他社SaaS、自社開発、オンプレミス、APIのみ、サービスプリンシパル利用、ID未付与、親子エージェントをどう発見・重複排除するかを回答させます。手動CSV取込も初期移行では有効ですが、更新元と差分検知を要求します。
2. データモデルとAPI
論理エージェントとinstanceを分離できること、拡張項目、履歴、タグ、証拠リンク、import/export、API、webhook、変更イベントを確認します。製品解約時に台帳と履歴を取り出せる形式、IDの安定性、削除後の監査保持も契約します。
3. owner／sponsorと承認
technical owner、business sponsor、data owner、代理者を別項目で持てること、異動・退職を検知できること、owner不在の通知と期限付き是正、グループ割当、職務分離、再審査を確認します。単に「所有者」一列では不十分です。
4. ID・権限・チャネルの連携
agent identity、service principal、workload identity、委任ユーザー、credential、role、scope、tool actionを関連づけられることを要求します。チャネルはTeamsなどの名称だけでなく、対象者、discoverable/deployed/pinned/callable、外部公開を記録できるようにします。
5. ライフサイクルと変更管理
draft、review、approved、active、suspended、retiring、retiredなどの状態遷移、承認者、SLA、期限、再開条件を確認します。モデル、prompt、tool、data source、permission、公開範囲の変更を別々に検出し、リスクに応じて再承認を起動できるようにします。
6. 監査と証拠
誰が、いつ、どの項目を、何から何へ変え、誰が承認したかを改ざん耐性のある形で残します。実行ログとは相関IDでつなぎ、SIEMへ出力できることを求めます。保持期間、検索、export、時刻同期、マスキング、法的holdも確認します。
7. 停止・廃止と出口
カタログ非表示だけでなく、session拒否、schedule停止、token失効、credential rotation、role削除、queue隔離、下流webhook解除までを自動またはrunbookで実施できるか確認します。製品障害時の手動停止、ベンダー撤退時の移行、データ返却・削除証明もRFPに含めます。
RFP提出を求める証拠
- サンプルの論理／instanceデータモデルと項目辞書
- 発見コネクタの対象、権限、同期頻度、失敗時動作
- owner不在、期限切れ権限、未登録agentのデモ
- action単位の許可・拒否と監査ログ
- disableからtoken失効までの試験記録
- exportされた台帳、履歴、証拠リンクのサンプル
- 障害復旧、バックアップ、RTO/RPO、サポート分担
- license前提と、機能ごとに追加費用が発生する条件
ライセンスやpreview機能は変わり得るため、RFPでは文書のコピーではなく、自社tenantと契約で利用できる機能をベンダーに証明させます。Microsoftの現行資料でも一部のregistry機能やrisk表示には契約条件があり、製品名だけで全要件を満たすとは限りません。
PoCの合否基準：一覧表示ではなく運用閉ループを試す
PoCのシナリオは「登録できた」で終わらせません。次の流れを一周させます。
- 未登録エージェントを一つ発見し、仮登録する。
- technical ownerとbusiness sponsorを別々に割り当てる。
- 本番instanceへ専用IDと期限付き権限を結びつける。
- 許可されたチャネルと利用者だけへ公開する。
- action許可と禁止を実行し、下流ログまで追跡する。
- modelまたはtool変更を検知し、再審査へ戻す。
- sponsor異動を発生させ、引継ぎと期限を確認する。
- 緊急disableを行い、session、token、queue、scheduleを確認する。
- 廃止後に権限が残っていないことを照合し、証拠を保存する。
合否は、表示された項目数ではなく、必須field completeness、同期遅延、誤検出、未検出、権限差分、停止時間、監査再現性、運用工数で判定します。テストデータには、同名agent、owner削除、IDなし、複数instance、別tenant、共有credential、期限切れapprovalを含めます。
更新・停止・廃止の判断ルール
更新を再審査するtrigger
モデルのマイナー更新をすべて経営会議へ上げる必要はありません。変更を能力への影響で分類します。
- prompt文言のみで、tool、data、権限、対象者が不変：ownerレビューと回帰試験
- model変更で出力特性が変わる：品質・安全・多言語の再試験
- toolまたはaction追加：権限、脅威、監査、停止の再審査
- data sourceや保持先変更：data owner、privacy、越境の再承認
- 利用者・チャネル・国の拡大：sponsor、セキュリティ、法務の再承認
- 自律度、件数、金額、設備範囲の拡大：新規ユースケース相当の審査
一時停止のtrigger
owner/sponsor不在、credential漏えい、異常な権限増加、監査欠落、禁止action成功、重大なデータ誤送信、契約失効、再審査期限超過は自動または緊急停止の候補です。停止条件と判断者を登録時に決め、事故の最中に責任を探さないようにします。
廃止の完了条件
画面から削除しただけでは廃止ではありません。次を照合します。
- 公開チャネル、共有リンク、API endpoint、scheduleを停止した。
- identity、token、secret、certificate、role、group membershipを失効・削除した。
- tool、MCP、webhook、queue、下流allowlistを解除した。
- memory、vector store、cache、成果物を保持方針どおり移管・削除した。
- 依存する親子エージェントと利用部門へ代替手順を通知した。
- 監査証拠、承認、最終利用、削除記録を保持した。
- 後日のdiscovery scanで再出現しないことを確認した。
よくある失敗
「Excelを一度作って完了」にする
静的台帳はすぐ古くなります。自動発見・同期する客観項目と、人が判断する業務項目を分け、期限切れを会議で処理します。CSVは移行手段でありcontrol planeではありません。
ownerを作成者に固定する
作成者は異動し、外注先は契約を終えます。technical ownerとbusiness sponsorを分け、後任、グループ、暫定管理者、停止期限を設計します。
エージェント名だけで重複排除する
同名の開発・本番や、多言語版、地域版は別instanceです。逆に名前が違っても同じIDと権限を共用していることがあります。stable ID、credential、endpoint、manifest、owner、tool graphで照合します。
control plane製品を買えば統制できると思う
製品は観測と制御を助けますが、目的、責任、禁止用途、risk acceptance、廃止判断は会社が決めます。ベンダー画面に項目が無ければ外部GRCやCMDBと連携します。
監査ログがあるから追跡できると思う
会話、orchestrator、tool、下流APIで時刻とIDがつながっていなければ再現できません。相関IDと必須event schemaを先に決め、PoCで一件を端から端まで再構築します。
FAQ：AIエージェント 管理と台帳
AIエージェント レジストリとは何ですか？
企業内のAIエージェントを、目的、instance、owner、business sponsor、ID、権限、チャネル、データ、ツール、状態、証拠とともに管理する正本です。アプリ一覧より細かく、実行ログそのものより上位の説明責任を持ちます。
AIエージェント 台帳はCMDBやアプリ台帳で代用できますか？
拡張できるなら活用できます。ただし論理agentとinstance、委任／自律ID、tool action、model・prompt・memory、公開チャネル、sponsor、再審査triggerを表せる必要があります。表せない部分は専用registryと連携します。
AI control planeとレジストリの違いは何ですか？
レジストリは「何が存在し、誰が責任を持ち、何を許可したか」を記録します。control planeは、その情報を使って実行時のidentity、permission、tool、policy、monitoring、停止を適用します。両方を一製品で実現する場合でも、役割は分けて評価します。
ownerとbusiness sponsorは同じ人でもよいですか？
小規模なPoCでは兼務する場合がありますが、責任は別に記録します。本番や高リスク用途では、技術変更を行う人と業務継続・残余リスクを判断する人を分ける方が望ましいです。最低でも代行者と上位承認者を定めます。
IDがないエージェントは登録対象外ですか？
いいえ。むしろidentity missingとして優先的に仮登録します。発見できないものをID化できないため、台帳はID整備の前段にもなります。本番継続には専用ID、権限範囲、停止方法を要求します。
何日ごとにレビューすべきですか？
固定周期だけでなく変更triggerを使います。高リスク権限は短い期限、一般的な本番agentは四半期など組織基準に合わせ、owner/sponsor変更、tool追加、data source変更、チャネル拡大、incident時には周期を待たず再審査します。
90日で全エージェントを統制できますか？
大企業では完全網羅は困難です。90日の目標は、定義、発見、責任者、最小データモデル、ID連携、停止試験、会議体を動かし始めることです。高影響のエージェントから優先し、未確認項目を可視化したまま継続改善します。
まとめ：台帳を「止められる運用」へつなぐ
AIエージェント レジストリの価値は一覧の美しさではなく、誰が必要性を説明し、誰が構成を直し、どの権限とチャネルが実際に使われ、いつ再審査し、異常時にどこまで止められるかを即答できることです。論理agentとinstanceを分け、technical ownerとbusiness sponsor、identity、tool action、data、channel、dependency、evidenceを結びます。その情報をAI control planeへ渡し、最小権限、許可・拒否、監査、停止、廃止を運用閉ループにします。90日では、全社製品統一よりも、発見から廃止までの一周を高リスクな数件で証明することを優先してください。
TOMAS TECHでは、製品選定前の項目設計、既存ID・API・CMDBの棚卸し、RFP、90日PoC、運用会議、停止・廃止試験まで整理できます。まだ利用中のエージェント数が分からない段階でも、お問い合わせいただけます。
Primary sources
- Microsoft Learn, “Manage agent registry in Microsoft 365 admin center”: https://learn.microsoft.com/en-us/entra/agent-id/publish-agents-to-registry
- Microsoft Learn, “Agent Registry convergence with Microsoft Agent 365”: https://learn.microsoft.com/en-us/entra/agent-id/agent-registry-convergence
- Microsoft Learn, “View and filter agent identities in your tenant”: https://learn.microsoft.com/en-us/entra/agent-id/agent-lists
- Microsoft Learn, “Manage agents with no agent identities”: https://learn.microsoft.com/en-us/entra/agent-id/manage-agents-without-identity
- Microsoft Learn, “What are agent identities?”: https://learn.microsoft.com/en-us/entra/agent-id/what-are-agent-identities
- Microsoft Learn, “Add and manage owners and sponsors for agent identities and blueprints”: https://learn.microsoft.com/en-us/entra/agent-id/manage-owners-sponsors-agents
- Microsoft Learn, “Administrative relationships in Microsoft Entra Agent ID”: https://learn.microsoft.com/en-us/entra/agent-id/agent-owners-sponsors-managers
- Microsoft Learn, “Governing Agent Identities”: https://learn.microsoft.com/en-us/entra/id-governance/agent-id-governance-overview
- Microsoft Learn, “Least privilege for AI agents”: https://learn.microsoft.com/en-us/security/zero-trust/sfi/least-privilege-for-ai-agents
本稿は公開一次情報をもとにしたベンダー中立の実務ガイドです。製品の機能、preview状態、ライセンス、画面、制約は変更されるため、導入時点の公式文書と契約条件を確認してください。
