目錄
ここ2年ほど、AI Agentをめぐる議論の多くは、どうやって各要素を接続するかに集中してきました。MCP Server、Tools、Skills、Agent Frameworkが次々に登場するなか、まずWorkflowを動かすことのほうが、その後の管理問題よりも優先されるのが一般的でした。しかし、同じ企業内で数十、数百のAgentが動き始めると、別の問題が浮上します。ある機能はすでに誰かが作っていないか、現在そのAgentの責任者は誰か、どのToolがすでに保守されていないのか、そして一見使えそうなMCP Serverが社内審査を通過しているのか、といった問題です。
2026年8月31日、AWS Agent RegistryがGeneral Availabilityとなりました。モデルの推論能力を高めるものでも、別のAgent Builderでもありません。組織内のAgents、MCP Servers、Agent Skills、そのほかのカスタムリソースを、検索・審査・管理できるRegistryとして整理するための、一元化されたカタログ兼Discovery Layerです。AWS自身も課題を端的に表現しており、Agent Systemが少数のToolsから数百規模へ成長すると、真のボトルネックは「Finding what already exists and trusting what you find」へ移るとしています。
この種の製品は、新しいモデルの発表ほど派手には見えませんが、Agentが実際の業務環境に入ったあとに直面する問題をよく表しています。MCPに接続できるかどうかだけが難題なのではありません。接続後に何が存在するのか、誰が利用しているのか、どのVersionがまだ有効なのか、どのリソースをほかのAgentが見つけられるのかという点が、新たな作業レイヤーになります。
Automationが数個しかないスタジオにとって、AWS Agent Registryは当然ながら大がかりすぎます。ただし、その背後にある考え方は、かなり早い段階から必要になります。Agentが3個、5個のうちは整理していなくても何も変わらないように見えますが、Toolを何度か入れ替え、OAuth権限が増えていくと、半年後に最初に分からなくなるのはPromptではなく、どのWorkflowが今も動いているのかです。
AWS Agent RegistryはPreviewからGAになり、どの問題を解決するのか？
AWS Agent Registryは2026年4月9日にPreviewとして公開され、8月31日にGAとなりました。その間は約4か月と3週間です。Previewの時点ですでに、一元登録、Semantic＋Keyword Search、Approval Workflow、URL-based Discovery、MCP Endpoint、CloudTrail連携といった主要機能が備わっていました。GAではさらにInfrastructure as Code、Tags、AWS RAMによるクロスアカウント共有、AgentCoreリソースの自動検出、Amazon QuickやKiroなど利用経路の拡充が加わっています。
この時間軸で「AWSがPreview製品を早く正式版にした」こと以上に注目したいのは、PreviewからGAまでに追加された機能のほとんどが、企業が実際に導入してから直面する問題に対応している点です。Accountをまたいでどう共有するか、IaCでどう管理するか、どう分類してコストを帰属させるか、自主的に登録されていないAgentをどう見つけるかが対象になっています。
つまりRegistryの課題は、最初から「Agentを作れるか」ではなく、作ったあとに信頼できるInventoryがあるかどうかでした。
企業がAI Agentを大量導入したあと、最もよく直面する3つの管理問題は？
AWSはGAの記事で問題を分かりやすく整理しています。1つ目は一元化されたInventoryがなく、組織内にどのAgent、Tools、Skillsがあり、Ownerが誰なのか分からないことです。2つ目はチーム横断のDiscoveryが不足し、同じ機能がすでに存在していても別チームが見つけられず、同じものを作り直してしまうことです。3つ目は、見つけたリソースを信頼できるかどうかです。Owner、Version、Approval Status、Description、Endpointが明確でなければ、検索できても安心して再利用できません。
Registryに登録できるのはAgentだけではなく、4種類のRecord Type
現在、正式にサポートされる最上位のrecordTypeはAGENT、MCP、SKILL、CUSTOMの4種類です。Agent RecordはA2A Agent Cardを使ってAgentとSkillsを記述できます。MCP RecordはMCP Serverの定義を保存し、そのServerが提供するTool Definitionsも収録できます。SkillはAgent Skill Definitionを保存し、Customはそのほかの組織固有リソースをCustom Metadataとして管理するために使えます。
注意したいのは、MCP Toolが独立した5番目のRecord Typeではなく、通常はMCP Server RecordのTool Definitionsに格納される点です。この違いは、API、CLI、IaCでRegistry Recordを実際に作成するときに重要です。
Keyword SearchとSemantic Searchを組み合わせてリソースを探す
Registryの検索は、名前の一致だけではありません。SearchDiscoverableRegistryRecordsはSemantic SearchとKeyword Searchを同時に実行して結果を統合・順位付けするため、正確な名前で検索することも、「Ticket Routingを処理できるToolを探している」のように自然言語で要件を説明して探すこともできます。MCP Server内のTool Name、Description、Input Schemaなども検索対象になります。
全員があるToolの名前を事前に知っていなければ見つけられないのであれば、それは見栄えの良いExcelにすぎません。本当のDiscoveryは、利用者が「今何をしたいか」だけを知っていて、社内ですでにその機能にどんな名前が付けられているかを知らなくても検索できる必要があります。
Approvalは設定可能だが、Discoveryに表示されるのはApproved Recordsだけ
原稿では「Recordは管理者の承認後に検索できる」とされています。方向性は近いものの、もう少し正確に整理できます。RegistryはManual Approvalにもauto_approveにも設定できます。固定されているのは、Discovery Planeの一般的なSearch、Browse、MCP Discoveryに表示されるのが、最新Revisionの状態がAPPROVEDであるRecordだけという点です。Draft、Pending Approval、Rejected、Deprecatedは通常のConsumer Searchには表示されません。
Recordを更新すると、再びDraftへ戻り、設定済みのLifecycleをもう一度たどります。Tool Version、Endpoint、機能が変更された場合、以前のApprovalがそのまま適用できるとは限らないため、登録後に永久に有効となる仕組みより合理的です。
CloudTrailには監査機能があるが、すべてのイベントが標準で完全保存されるわけではない
AWS Agent RegistryはCloudTrailと正式に連携しています。RegistryのCreateやUpdateなどのManagement Eventsは標準でCloudTrail Event Historyに入り、90日間保持されます。DiscoveryなどのData Eventsも記録したい場合は、Trailを別途作成または変更し、Agent RegistryのData Event Selectorを追加する必要があります。
したがって、「Registryへのすべてのアクセスが標準で完全にCloudTrailへ記録される」という説明は正確ではありません。Registryは完全なCloudTrail Auditの構成をサポートしており、Management Eventsは標準で追跡可能ですが、Data Eventsは必要に応じて別途有効化します。
Registry自体もMCP Endpointを提供する
これはAgent Registryで特に興味深い点です。各RegistryはMCP-compatible Endpointを提供でき、MCP Clientはsearch_discoverable_registry_records、list_discoverable_registry_records、batch_get_discoverable_registry_recordを直接呼び出せます。つまりRegistryは、管理者がConsoleで検索するためだけのものではありません。IDEやAgent自身もDiscovery Toolとして利用し、承認済みのリソースを確認してから、接続するToolやAgentを決められます。
AWSのGA記事では、ConsumersをDevelopers、Business Users、Autonomous Agentsと明確に定義しています。つまり「Agentが自らRegistryを検索してToolを探す」という使い方は、拡張的な想像ではなく、製品が明確にサポートしている方法です。
ただし、RegistryがEndpointとAuthentication Informationを返すからといって、検索者が基盤となるToolへの権限を自動的に得るわけではありません。その後AgentやMCP Serverを実際に呼び出すには、各リソースのOnboardingとCredentialsに従って認証を完了する必要があります。
GA版ではPreviewからどのような企業向け管理機能が増えたのか？
GA以降、RegistryはAWS CloudFormation、Terraform、AWS CDKを通じてInfrastructure as Codeで作成・管理でき、Registryの設定をConsoleだけに残す必要がなくなりました。RegistriesとRecordsにはTagsも追加でき、組織化、Cost Allocation、Access Controlに利用できます。
AWS RAMを使えばRegistryをAWS Accounts間で共有でき、各Accountが互いに見えないCatalogを個別管理するのではなく、企業全体のOrganization-wide Registryを構築できます。またGAでは、AWS Organization全体にあるAgentCore RuntimeとAgentCore GatewayのリソースをAuto-detectionする機能も追加されました。新しくデプロイされたAgentやMCP Endpointは、まずDraft Recordとして検出され、その後Review／Approvalのプロセスへ進められます。
この点では、現在の機能とroadmapの境界に注意が必要です。現時点のGAで自動検出できるのはAgentCore RuntimeとAgentCore Gatewayです。AWSのGA Blogでは、今後EC2、EKS、ECSなどの環境へ広げ、FederationによってAWS外のリソースも可視化する構想が示されていますが、これは今後の方向性であり、現在すでに全面対応しているわけではありません。
利用経路も増えています。Registry ResourcesはAmazon Bedrock AgentCore、Amazon Quick、Kiroから見つけられるようになりました。Quickでは、組織のRegistryにある承認済みAgentやMCP Serverを直接検索し、Chat、Agents、Apps、Flows、Deep Researchで利用できるようにできます。
AI AgentにRegistryが必要になり始めた理由
MCPが普及したことで、外部ToolをAgentへ接続する方法は以前より統一されました。REST API、Database、社内ServiceをMCP Serverで包み、モデルが理解できるToolsとして提供できます。確かにIntegration Frictionは下がりましたが、「導入コストがほぼゼロになった」とまでは言えません。Authentication、Permission、Schema、Deployment、Observability、Runtime Maintenanceは依然として必要です。
本当の変化は、接続しやすくなったことでTool作成のハードルが下がり、組織内に似た機能が大量に並存しやすくなったことです。事前に検索できる場所がなければ、Shadow Agents、重複したMCP Servers、誰が保守しているのか分からないToolsが自然に生まれます。AWSも「Teams build in isolation」と「rebuild what already exists」をRegistryが対処すべき中心課題に挙げています。
この流れは過去のSoftware Engineeringによく似ています。Packageが増えればPackage Registryが必要になり、Container Imageが増えればImage Registryが必要になり、APIが増えればCatalog、Gateway、Governanceが必要になります。AgentとMCP Toolが実運用へ入ったあとにRegistryが加わるのは不自然ではなく、AI Toolも同じAsset Managementの段階へ進んだということです。
同じ日にAWSがObservabilityとMulti-tenant Isolationも取り上げたことは何を意味するのか？
8月31日のAWS Machine Learning Blogには、観測可能なAgentic Retrieval、Managed Bedrock Knowledge Base上でのMulti-tenant Data Isolation、AgentCore Runtime上のMCP ServerをAmazon Quickへ接続する実装など、Production Agentic Systemsに関する記事が複数掲載されました。
同日に並んだこれらの記事からは、Agentを作ったあと、Retrievalを追跡できるか、Tenant間でデータが混ざらないか、既存Toolを再利用できるかが次の課題になっているという共通テーマが見えます。ただし、これはAWSが同時期に公開した内容から整理できる製品上の観察であり、AWSが公式に「Agent時代は構築から後始末へ移った」と発表したという意味ではありません。
より慎重に言えば、2026年のAgent Infrastructureでは、Governance、Observability、Isolation、DiscoveryといったProduction Concernが明らかに増えています。
AWSがForresterのAI Infrastructure Leaderに選ばれたこととAgent Registryには直接の関係があるのか？
8月31日、AWSは『The Forrester Wave: AI Infrastructure Solutions, Q4 2025』で評価対象となった13社のうちLeaderに選ばれ、Strategy Categoryで最高スコアを獲得したと発表しました。
これは、AWSが同時期にAI Infrastructureを強調している背景としては使えますが、「Agent RegistryのおかげでAWSがLeaderになった」ことの証明にはなりません。Forresterの評価範囲はTraining、Fine-tuning、Inference Infrastructure、全体戦略を含むさらに広いものであり、評価時期もAgent Registryが2026年にPreview公開される前のQ4 2025だからです。
同様に、「モデルの能力が均質化していくため、GovernanceこそCloud Providerの本当のmoatになる」という主張は、市場についての推論として扱うべきで、この数本のAWS文書から直接証明できる結論ではありません。現時点で確実に言えるのは、Cloud Platform間の競争がすでにモデルそのものだけではなく、Agent Runtime、Identity、Gateway、Evaluation、Registry、Observability、Governanceまで含むようになっていることです。
AWS Agent Registry導入前に注意すべき2つのGovernanceリスク
RegistryのMetadata自体が社内アーキテクチャを露出させる可能性がある
AWSはEnterprise Considerationsで、「Resourceを検索できる権限」と「新しいResourceを登録できる権限」をまったく同じにすべきではないと明記しています。Tool MetadataにはInternal EndpointやArchitecture Detailsが含まれる場合があり、それ自体が攻撃者にとって価値ある情報になります。そのため、広く検索可能なRegistryにどのMetadataを載せ、どの情報をより厳格なAccess Boundary内に残すかを検討する必要があります。AWSは、誰がRegistryを検索しているか、検索頻度はどの程度かもAuditするよう勧めています。
つまりRegistryの構築は、すべてのアーキテクチャ情報を一か所に集め、全社へ自由に検索させることではありません。Catalog自体にもData ClassificationとIAM Boundaryが必要です。
登録されているからといって安全でも、Security Review済みでもない
もう一つ正確にしておくべき点は、現在のAWS Agent Registryには、すべてのSecurity Scan、Duplicate Detection、Compliance Assessmentを自動で完了する機能が内蔵されているわけではないことです。
現在AWSが提供しているのはRecord Lifecycle、Approval States、EventBridge Hooks、Approval APIであり、企業は自社の審査プロセスを組み込めます。GA BlogでAWSが最低限推奨しているのは、公開前に類似リソースがないか確認し、Agent／Tool／SkillのSecurity Scanを実施し、最後に人間のApproverがMetadataの完全性、元の開発チーム以外にも理解できるDescriptionになっているか、Registryへ登録すべきリソースかを確認することです。最初は簡単なCI/CD ChecklistやSlack Approval Flowでも対応できます。
Security／Vulnerability Assessments、Compliance Evaluations、De-duplication AnalysisがApproval Workflowへより直接組み込まれるのは今後の予定であり、AWSもこれらをWhat's nextとして明記しています。現時点ではRoadmapです。
したがって「Approved」が意味するのは、組織が設定したApproval Barを通過したということであり、AWSがそのAgentの包括的な安全認証を完了したということではありません。
企業が本当にAgent Registryを必要とする前にできること
最初の一歩は、すぐRegistryを購入することではなく、現在何があるかを把握することです。Agent、Automation、MCP Server、Skill、重要なIntegrationをInventoryにまとめ、少なくとも名称、用途、Owner、現在の環境、アクセスするデータ、Write Permissionの有無、最終検証日、現在の状態を記録します。この表を作るだけでも、重複しているものや保守担当がいないものをかなり見つけられます。
次に、軽量な公開基準を設けます。Toolを初めてほかの人に提供するとき、同種の機能がすでにないか、AuthenticationとPermissionは妥当か、誰が保守するか、問題が起きたとき停止できるかを確認します。小さなチームで10段階のApprovalを設計する必要はありません。ChecklistとReviewer 1名だけでも、Governanceがまったくない状態より大幅に前進します。
3つ目はLifecycleを完成させることです。Agentは「存在する」だけの状態にせず、少なくともDraft、Active、Deprecated、Retiredに分け、Replacement Linkを残せます。AWS Agent Registryも同様のLifecycleを採用しており、不要になったApproved RecordはCuratorがDeprecatedにできます。
個人クリエイターや小規模スタジオにAWS Agent Registryは必要か？
多くの場合、必要ありません。AgentやAutomationが数個しかないなら、管理のためだけにAWS Registryを導入するとSystemがかえって複雑になります。ただしRegistryが解決しようとしている問題は、小規模な環境でも早い段階から現れます。Workflowの名前を思い出せない、OAuthの認可が大量に残る、同じ処理を2Version作ってしまう、どちらがまだ動いているのか分からない、Automationが壊れて初めて元のToolが数か月前から停止していたと分かる、といった問題です。
より簡単な方法は、既存のKnowledge Toolに「Automation／Agent Registry」の表を一つ作ることです。
| 項目 | 記録する内容 |
| 名称 | Agent、Automation、MCPの名称 |
| 用途 | 実際に何を解決するかを一文で説明 |
| Owner | 現在の保守担当者 |
| Trigger | 手動、Schedule、Webhook、そのほかの条件 |
| Tools／Connections | Gmail、Notion、Drive、Slack、GitHubなど |
| Access | Read-only／Write／Delete／Sendなど |
| コスト | 月額料金、Tokens、Credits、APIコスト |
| Status | Draft／Active／Deprecated |
| 最終確認日 | 最後に実際に正常動作した日 |
| Replacement | 停止済みの場合に置き換えた新しいWorkflow |
大切なのは表をきれいに作ることではなく、半年後に見覚えのないIntegrationを見つけたとき、何なのかを確認するためにチャット履歴を掘り返さずに済むことです。
Automationが3個だけなら、この表を1か月開かないこともあるでしょう。しかし十数個のToolsを接続し、Agentを何度か入れ替え、OAuth画面に長い認可リストが並ぶようになると、その価値は急にはっきりします。
AWS Agent Registryが本当に示しているのは、AgentがAsset Managementの段階へ入ったこと
AWS Agent Registryは、Agentの回答精度を上げるものでも、安全でないMCP Serverを自動的に安全にするものでもありません。扱うのは、より現実的な別の問題です。Agent、Tools、Skillsが記憶だけでは管理できないほど増えたとき、何が存在し、どれが現在の利用基準を満たし、誰が担当しているのかを把握する場所が必要になります。
AWSはAgent自身にもMCP経由でRegistryを検索させています。これは、このCatalogがIT管理者向けのAsset Listにとどまらず、Agent Discoveryそのものの一部になり得ることを示しています。
ただしRegistryだけですべてのGovernance作業が完了するわけではありません。Security Scan、Duplicate Analysis、きめ細かなDiscovery Policy、追加のObservability機能には、企業側で構築しなければならないものもあれば、AWSのRoadmap上にあるものもあります。これは現在のAgent Ecosystemの実情をむしろよく表しています。Agentを作るToolはすでに多い一方、それらを長期的に見つけられ、理解でき、保守担当者がいる状態に保つ仕組みは、まだ整備の途中です。
小規模チームでも、この問題への対応をAgentが1,000個になるまで待つ必要はありません。「このWorkflowは今も動いているのか」という質問に答えられなくなった時点で、Registryを残すべきタイミングに来ています。
よくある質問
AWS Agent Registryは、Amazon Bedrock AgentCore EcosystemでAWSが提供する一元化されたAgent Catalogです。組織内のAgents、MCP Servers、Agent Skills、そのほかのカスタムリソースを登録・管理できます。Agentを作成するものでも、モデルの性能を高めるものでもありません。主にResource Discovery、重複開発、Owner不明、Version Management、Governanceの問題に対応します。Keyword SearchとSemantic Searchをサポートするため、Toolの正確な名前を知らなくても、自然言語で要件を説明して検索できます。
AWS Agent Registryは2026年4月9日にPreviewとして公開され、2026年8月31日にGeneral Availabilityとなりました。GA版ではInfrastructure as Code、Tags、AWS RAMによるクロスアカウント共有、AgentCore Runtime／Gatewayリソースの自動検出など、企業向けの管理機能が追加されています。PreviewからGAまでは約4か月と3週間であり、4か月未満ではありません。
課題が「Agentを作れるか」から「Agentが増えたあとにどう管理するか」へ移っているからです。各チームがAgent、MCP Server、Skillsを素早く作れるようになると、重複開発、Shadow Agent、Owner不明、停止済みToolの継続利用といった問題が生じます。Registryの価値はAIの能力を高めることではなく、既存の能力を見つけやすく、理解しやすく、管理しやすくすることです。また、保守を続けるべきリソースと廃止できるリソースも把握しやすくなります。
いいえ。Registryが解決するのはDiscoveryとGovernanceであり、Resourceの品質を自動的に保証するものではありません。利用前にはOwner、Version、Authentication、Permission Scope、現在も保守されているか、社内のSecurity／Compliance Reviewが完了しているかを確認する必要があります。Registry Metadata自体にEndpointやArchitecture情報が含まれる可能性もあるため、「誰が検索できるか」と「誰がRecordを作成・変更できるか」の権限も分けて設計すべきです。
多くの場合、AWS Agent Registryを直接導入する必要はありませんが、同じ管理ロジックを取り入れる価値はあります。複数のAgent、Automation、MCP Server、OAuth Integrationがあるなら、名称、用途、Owner、Trigger、Tools／Connections、Read／Write権限、コスト、Status、最終動作確認日を記録した簡単なRegistryから始められます。整理が必要になるのはAgentが1,000個になったときではなく、「このWorkflowは今も動いているのか」に答えられなくなったときです。
RegistryはAWS CloudTrailと連携していますが、Management EventsとData Eventsを分けて考える必要があります。作成や更新などのManagement OperationsはCloudTrail Event Historyに表示されます。DiscoveryやSearchなどのData Eventsも記録するには、Trailを別途作成または調整し、該当するData Event Selectorを有効にする必要があります。そのため「すべてのRegistry操作が標準で完全保存される」と単純化はできませんが、AWSは完全な監査を構成するための基盤を提供しています。
はい。GA版ではAWS Resource Access Manager、つまりAWS RAMが追加され、RegistryをほかのAWS Accountsと共有できます。各Accountが互いに見えないカタログを個別に管理するのではなく、より一元化されたOrganization Registryを構築できます。RegistryとRecordsにはTagsも付けられ、分類、コスト配分、Access Controlに利用できます。
MCPが解決するのは「AIが外部Toolsへ一貫した方法で接続する仕組み」です。Agent Registryが解決するのは「MCP ServersやAgentsが増えたとき、何が存在し、何が承認済みで、誰が保守しているかを把握する方法」です。RegistryはMCP Server DefinitionとTool Metadataを保存し、既存のMCP Endpointから情報を同期できます。さらにRegistry自体もMCP Endpointを提供するため、MCP Clientは組織内の承認済みリソースを検索できます。両者は代替関係ではなく、異なるレイヤーのInfrastructureです。
はい。Agent RegistryはMCP-compatible Endpointを提供し、MCP Clientは承認済みのRegistry Recordsを検索、一覧表示、取得できます。開発者がIDEなどから検索できるだけでなく、Agent自身もRegistryをDiscovery Layerとして使い、利用可能なAgent、MCP Server、Skillを確認してから、使用するリソースを決められます。ただしRegistryでToolを見つけたからといって、基盤Systemへの権限を自動取得するわけではありません。実行時には、そのService固有のAuthenticationとAccess Controlを満たす必要があります。
現時点では、そのようには理解できません。AWS Agent RegistryはApproval Workflow、Record Lifecycle、EventBridge Hooks、関連APIを提供しており、企業はSecurity Scan、Duplicate Check、Compliance Review、人による審査を独自の公開プロセスに組み込めます。しかし完全なAutomated Security AssessmentとDe-duplication Analysisが、現在のGAにすべて内蔵されているわけではありません。AWSは、より自動化されたSecurity／Compliance／Dedup Signalsの一部を今後の方向性に挙げています。したがってAPPROVEDは組織の審査基準を満たしたことを意味し、AWSがそのAgentの包括的な安全認証を完了したことを意味しません。
必ずしもそうではありません。RegistryはManual ApprovalにもAuto-approveにも設定できます。固定されているのは、一般的なDiscovery Planeで検索・発見できるのが、現在の状態がAPPROVEDである最新のRecord Revisionだけという点です。Draft、Pending Approval、Rejected、DeprecatedのRecordは通常のConsumer Searchに表示されません。Recordを後から変更するとLifecycleへ再度入り、一度の承認で同じ状態が永久に続くわけではありません。
現在、正式にサポートされる最上位のRecord TypeはAGENT、MCP、SKILL、CUSTOMの4種類です。MCP Serverが提供するToolsはMCP RecordのTool Definitionsに格納されます。そのため、実際にはMCP Toolsを検索・管理できますが、Toolは独立した5番目のRecord Typeではありません。最初の3種類に当てはまらないものの、企業がGovernanceの対象にしたいリソースはCustom Metadataで保存できます。