powered by TechFeed
表示モード
主要ニュース

AWSがAIエージェント統治の参照実装「Loom」をOSSで公開 — 「自分でも1週間で作れる」と言われつつも、ID伝播やガバナンス設計は本格的

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

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:applicationloom:grouploom: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を参照していただきたい。