7月20日、Steef-Jan Wiggersが「AWS Releases Loom, an Open-Source Reference Platform for Governing AI Agents at Enterprise Scale」と題した記事を公開した。エージェントが複数のシステムをまたいで自律的に動作する時代、「誰の権限でどのデータにアクセスしているか」を各ホップで追跡・制御するID管理とガバナンスは、エンタープライズ導入における最大の難題になりつつある。AWSはその答えのひとつとして、AIエージェントの構築・デプロイ・ガバナンスを網羅するオープンソース参照プラットフォーム「Loom」を公開した。

AWSがAIエージェント統治の参照実装「Loom」をOSSで公開

AWSは、AIエージェントをエンタープライズ規模で安全に運用するための参照プラットフォーム「Loom」をAWS Labsでオープンソース公開した。Strands Agents SDKでエージェントを構築し、Amazon Bedrock AgentCore Runtime上で実行するアーキテクチャを採用している。AWSはLoomを「マネージドサービスではなく、組織が自社のエージェントプラットフォームを構築する際の具体的な参考例」と明示している。

もともとAWSのプリンシパルソリューションズアーキテクトであるHeeki ParkがMediumにプロトタイプを公開し、その後AWS Labsに移行したプロジェクトだ。

最大の難所：エージェント越しのID伝播をどう解決するか

Loomが解決しようとする7つの課題のうち、最も技術的に複雑なのがID伝播（Identity Propagation）だ。

ユーザーの代理としてエージェントが動作し、MCPサーバーを呼び出し、さらにREST APIを叩く——そのホップごとに「誰の権限で動いているか」を保持したアクセストークンが必要になる。Loomはユーザー操作に対してOAuthの認可コードフローを実装し、RFC 8693のトークン交換プロセスをAgentCore Identityと組み合わせることで、エンドユーザーとエージェント双方のIDをダウンストリームのアクセストークンに乗せつつ、委任チェーンを維持する。

エージェント→MCPサーバー→Amazon API Gatewayエンドポイントの各ホップで、それぞれon-behalf-ofトークンが付与された状態を可視化できる。ダウンストリームのシステムは、元のユーザーが許可されたデータのみを返す設計だ。

「コードを変えない」デプロイモデル

Loomのデプロイ思想は明確だ。ランタイムでのコード生成を意図的に排除している。

デプロイされるのは、あらかじめ書かれた設定可能なPythonエージェント（Strands Agents製）であり、デプロイ時に動作ガイドライン・メモリリソース・MCPやA2A設定を注入する。デプロイ間でコードは変わらず、変わるのは設定だけだ。これにより、プラットフォームチームはエージェントコードを一度スキャンしてエンタープライズ要件（ロギング要件など）を加えれば、すべてのデプロイで再利用できる。

シークレットや認証情報はLoomには一切保存されない。AWS Secrets Managerに置かれ、必要時のみ取得される。

ガバナンスの仕組み：タグとロールの2軸

ガバナンスは2つのメカニズムで実現する。

• タグプロファイル：loom:application、loom:group、loom:ownerの3つを全デプロイリソースに必須タグとして強制。コストセンター識別子などカスタムタグも追加可能。
• アクセス制御：ロール種別（できることと見えるビューを決定）とグループタグ（見えるリソースを決定）の2次元で管理。管理者はカタログダッシュボードへ、エンドユーザーはチャット画面・自分のグループのエージェント・自分の会話履歴のみに制限される。

エージェントディスカバリーはパブリックプレビュー中のAWS Agent Registryと統合し、A2Aのエージェントカード仕様とMCPツールスキーマに準拠する。ただし、Parkの別記事では一点の摩擦が指摘されている。レジストリのARNにレジストリ名ではなくランダムな英数字文字列が含まれるため、レジストリ操作のIAMポリシーでワイルドカードリソースを使わざるを得ない点だ。

Human-in-the-loopレビューは、Strands AgentsのHookフレームワークとMCPのelicitation機能を使って3通りの方法で実装されており、センシティブなツール呼び出しは実行前に人間の承認待ちで一時停止する。

コミュニティの反応：有望だが「自分でも1週間で作れる」

コミュニティの反応は様子見ムードだ。Redditのスレッドでは、2日間でデプロイ報告がゼロ。唯一の実質的な評価コメントが、参照実装特有の「使うか自作するか」問題を端的に表している。

Loomはこれまでに登場した注目の新製品の中でも有望なもので、企業のAIエージェントロールアウトプロジェクトでは検討に値する。ドキュメントやダッシュボードを見ると、よく考えられた良い意味でのopinionatedな設計だ。ただ、自分でも1週間で同じものを作れるとは思う。
— Reddit ユーザー

コスト面では、Loom自体は無償のオープンソース。費用は下層のマネージドサービス（Bedrock AgentCore等）に発生する。

競合との位置付け

同カテゴリとして、InfoQが別途報じたAnthropicのClaude Apps Gatewayは、企業がClaudeへのアクセスをポリシーベースで一元管理し、コストや利用状況を制御するためのゲートウェイレイヤーだ。対してLoomは、カスタムエージェントワークロードのプラットフォームレイヤー（ID・デプロイ・レジストリガバナンス・承認ワークフロー）を担う位置付けであり、両者は競合というより補完関係に近い。

成熟度の差は明確で、Claude Apps Gatewayはサポート付きプロダクトだが、LoomはAWS Labsが公開した参照実装であり、既存資産に縛られない新規構築（いわゆるグリーンフィールド構築）を行うプラットフォームエンジニアリングチームを主な対象としている。RBACモデルにはデモ用の足場が残っており、本番投入にはチームによる追加実装が前提となる。

詳細はAWS Releases Loom, an Open-Source Reference Platform for Governing AI Agents at Enterprise Scaleを参照していただきたい。