shirokuronoir

AIツール台帳で先に決める5項目

AIツール台帳で先に決める5項目

AWSは2026年8月31日、AIエージェント、ツール、スキル、MCPサーバーを一元管理するAWS Agent Registryの一般提供を発表しました。検索できる台帳を作るだけでなく、登録、審査、承認、廃止までを同じ運用へ載せるサービスです。

ただし、台帳を導入しても登録項目が曖昧なら、似たツールが増え、所有者不明の古いエンドポイントが検索結果へ残ります。最初に決めるべきなのは製品設定より、何がそろえば再利用可能と判定するかです。

先に結論

AIツール台帳では、次の5項目がそろった承認済みレコードだけを検索対象にします。

1. 重複しない名前とレコード種別

2. 運用責任を持つ所有者

3. development、QA、production、deprecatedの段階

4. 呼び出し先またはリポジトリ

5. 承認状態と変更履歴

今回、架空の6レコードへこのゲートを適用しました。結果は公開可能1件、停止3件、要審査1件、非表示1件で、期待結果との不一致は0件でした。AWS Agent Registry自体へ接続した性能試験ではなく、登録前に不足を止めるローカル運用テストです。

一次情報で確認したこと

AWSの一般提供の発表では、Agent Registryを組織内のエージェント、ツール、スキル、MCPサーバー、カスタムリソースのための非公開カタログと説明しています。AWS CLI、SDK、コンソール、MCP経由で利用でき、CloudFormation、Terraform、CDKによる管理にも対応しました。

公式ブログは、公開者がレコードを登録し、管理者やキュレーターが審査し、利用者が承認済みカタログから検索する流れを示しています。目的は「作る前に既存機能を見つけること」と「利用可能なものを統制すること」です。

レジストリ作成手順では、検索時の認証にIAMまたはJWTを選び、レコードの自動承認を有効にするかを設定します。公式ドキュメントには移行上の注意もあり、新しい`agent-registry`名前空間が開始され、プレビュー時の`bedrock-agentcore`名前空間は2026年9月17日にサポート終了予定です。

対応レコード種別と記述子では、`AGENT`、`MCP`、`SKILL`、`CUSTOM`の種別、名前、説明、バージョン、タグ、記述子を扱います。MCPとA2Aのレコードは公式スキーマに対して検証されます。

主要機能では、キーワードと意味検索、承認ワークフロー、EventBridge通知、IAM/JWT認証、外部レコード同期、CloudTrail監査が説明されています。検索できることと、実行を許可することは別の境界です。

実際に試したこと

実データや本番エンドポイントを使わず、6件の架空レコードをCSVにし、次の順で判定しました。

1. 同名レコードがすでに存在すれば停止

2. 所有者が空なら停止

3. 呼び出し先またはリポジトリが空なら停止

4. 承認待ちは検索対象にせず審査へ送る

5. deprecatedは通常検索から隠す

6. すべて満たすproductionレコードだけを公開可能にする

| ケース | 状態 | 判定 |

|—|—|—|

| productionのエージェント、所有者・URL・承認あり | 完備 | ALLOW |

| 既存名と重複したMCP | 重複 | BLOCK_DUPLICATE |

| 所有者のないスキル | 責任者不明 | BLOCK_OWNER |

| 呼び出し先のないカスタムツール | 実体不明 | BLOCK_TARGET |

| QA段階で承認待ちのエージェント | 未審査 | REVIEW |

| deprecatedのMCP | 廃止済み | HIDE |

6件すべてが期待どおりに分かれました。この確認で分かったのは、名前と説明だけでは再利用可否を決められないことです。所有者、段階、実体、承認状態を検索結果と一緒に見せる必要があります。

5項目を運用へ落とす

1. 名前と種別

名前は組織内で一意にし、`AGENT`、`MCP`、`SKILL`、`CUSTOM`を混同しません。表示名が同じでも実行方式が違う場合は、用途とバージョンを識別子へ含めます。

2. 所有者

個人名だけでなく、保守責任を引き継げるチーム名、問い合わせ先、最終確認日を持たせます。所有者が不在になったレコードは自動で審査待ちへ戻します。

3. 段階

development、QA、production、deprecatedを分け、既定の検索はproductionかつ承認済みだけにします。検証中のツールを本番エージェントが偶然選ばないようにします。

4. 呼び出し先

実行可能なエージェントやMCPはエンドポイント、スキルはリポジトリまたは配布場所を記録します。URLが存在するだけでなく、認証方式、利用範囲、タイムアウト、停止手順も関連情報として残します。

5. 承認と履歴

新規登録と更新を同じ承認済み扱いにしません。エンドポイント、権限、ツール定義が変わったら再審査し、誰がいつ何を承認したかを監査ログへ残します。自動承認は、スキーマ検証と組織ポリシーの両方を通る場合に限定します。

今日から行う3つのアクション

1. 既存のAIエージェント、MCP、スキルを20件まで棚卸しし、5項目の空欄を数える

2. 承認済みproductionだけを通常検索へ出し、QA、承認待ち、deprecatedを別ビューへ分ける

3. 新規登録、更新、所有者不在、廃止の4イベントで再審査が起動するかをテストする

自然文の運用ルールを停止条件へ変える方法は「AIルールを曖昧にしない4条件」で整理しています。案件や文書の権限境界は「法務AI導入で先に分ける5境界」も参照してください。

判断基準

最初の20件で、所有者不明0件、呼び出し先不明0件、承認待ちの通常検索表示0件、deprecatedの新規実行0件を確認できた場合だけ登録範囲を広げます。検索件数ではなく、誤って再利用できるレコードを0件にできるかで判断します。

関連記事

出典

著者情報

執筆・検証: しろのあ。AWSの一次情報、2026年9月1日のローカル判定、AWS環境では未検証の部分を分けて記載しています。