Amazon Bedrock Agents vs. コントロールプレーン: アーキテクチャレビュー

AWS環境内で運用するDevOpsエンジニアやアーキテクトにとって、 Amazon Bedrock Agents—アーキテクチャ上は AgentCore runtime—が、エージェントワークフローを構築するための標準的な方法です。これは、エージェントに必要な複雑な再帰ループを標準化し、開発者が以前 LangChainのようなライブラリを使って手作業で実装していた推論、メモリ、APIオーケストレーションを処理します。

しかし、マネージドエージェントフレームワークを採用することは、多くの場合、初期の開発速度と長期的なアーキテクチャ制御との間でトレードオフを必要とします。これにより、アプリケーションロジックが特定のクラウドプロバイダーのオーケストレーション思想に結合されます。本レポートでは、Amazon Bedrock Agentsの技術アーキテクチャを分析し、可観測性に関する運用上の現実を評価し、そして TrueFoundry Platformを使用したアグノスティックなコントロールプレーンアプローチと比較します。

Amazon Bedrock Agent Runtimeの構造

Bedrock Agentsは、多段階のタスクを実行するように設計されたオーケストレーションエンジンとして機能します。ステートレスなInvokeModel API呼び出しとは異なり、エージェントはステートフルなループとして動作します。

Bedrockでエージェントを定義する際、開発者は3つの異なるプリミティブを設定します。

1. アクショングループ： エージェントの機能を定義する OpenAPI schema 。これらは通常、 AWS Lambda 関数。ツール実行のためのコンピューティング層を提供します。
2. ナレッジベース： ベクターストアとの統合（通常は Amazon OpenSearch Serverless）で、モデルの根拠付けのためのRAG機能を提供します。
3. オーケストレーションテンプレート： ユーザー入力をどのように解釈し、正しいLambdaを選択し、出力を解析するかをモデルに指示するプロンプトエンジニアリングロジックです。

推論ループ

主な利点は、推論ステップを自動化することです。ユーザーが「アイテムXの在庫を確認し、データベースを更新してください」と要求すると、ランタイムはこのリクエストを次のように分解します。

• ステップ1： CheckInventory Lambdaが必要であると判断します。
• ステップ2： ペイロードを構築します。
• ステップ3： Lambdaを実行し、レスポンスを読み取ります。
• ステップ4： 以前の出力に基づいて、UpdateDatabaseが次の論理的なステップであると判断します。

図1：AWS Bedrock Agentsによって管理される再帰的なオーケストレーションループ。

運用上のトレードオフ

マネージドサービスは初期デプロイを加速しますが、デバッグ、スケーリング、移行といったDay 2オペレーションでは、抽象化の代償が明らかになることがよくあります。

可観測性に関する考慮事項

フルマネージドランタイムでは、プロンプトループは 抽象化されています。システム指示とツール定義はAWSによって構築され、サービス境界の背後にあるLLMに送信されます。

エージェントがハルシネーションを起こしたり、誤ったツールを呼び出したりした場合、生のコンテキストウィンドウや中間推論ステップが暗黙的に管理されることが多いため、デバッグは複雑になる可能性があります。これにより、チームは 最終出力のデバッグ に注力することになり、詳細な推論プロセスを検査するのではなく、その結果に焦点を当てがちです。

TrueFoundryのようなAIゲートウェイを使用するアーキテクチャは、オーケストレーションロジックを透過的に保ちます。エージェントの「頭脳」はあなたのインフラストラクチャ上で動作し、すべてのプロンプト、トークン、推論ステップが、次のようなトレースツールで可視化されることを保証します。 OpenTelemetry または Arize。

AWS中心のツールチェーン

Bedrock AgentはAWSエコシステム向けに最適化されています。ツールをネイティブに呼び出すことは、通常、そのツールがLambda関数として存在することを意味します。

企業が外部ツール（Snowflakeデータベース、Salesforce API、Azureでホストされているサービスなど）を使用する場合、開発者はそのギャップを埋めるために、AWSのラッパーLambdaを介して調整することがよくあります。これにより、追加のレイテンシーとメンテナンスのオーバーヘッドが発生する可能性があります。

業界は現在、 Model Context Protocol (MCP)を中心に集約しつつあります。これは、エージェントがデータソースに普遍的に接続できるオープンスタンダードです。TrueFoundryは MCPネイティブとして設計されており、カスタムのインフラストラクチャラッパーなしで、エージェントがGoogle Drive MCPサーバー、ローカルのPostgresデータベース、AWS Lambda関数に同時に接続できる中立的なハブとして機能します。

TrueFoundry: コントロールプレーンアーキテクチャ

TrueFoundryは コントロールプレーン アーキテクチャを提案しています。モデル、ランタイム、ツールを単一の垂直統合型クラウドサービスにまとめるのではなく、このアプローチではそれらを分離します。

ここでは、クラウドプロバイダー（AWS、Azure、GCP）がコンピューティングとモデルのスケーラブルなバックエンドとして機能し、TrueFoundry Gatewayはアプリケーション向けの管理可能なインターフェースとして機能し続けます。

ルーティングと経済的効率性

Bedrock Agentsの決定的な特徴は、Bedrockモデル（Titan、Claude、Bedrock上のLlama）へのアーキテクチャ的な結合です。複雑なエージェントは多くのステップを実行するため、高性能モデルを Claude 3.5 Sonnet のような再帰ループのすべてのステップで使用すると、コストが高くなる可能性があります。

TrueFoundryは セマンティックルーティングを促進します。Gatewayはステップの複雑さを分析します。エージェントが文字列から日付を抽出するだけでよい場合、リクエストはより費用対効果の高いモデル（例えば Meta Llama）がホストされている AWS Spot Instancesにルーティングされます。ステップが複雑な推論を必要とする場合は、GPT-4oまたはClaude 3.5 Opusにルーティングされます。

図2: TrueFoundryのルーティングロジックは、タスクの複雑さに最も費用対効果の高いプロバイダーを適合させることで、ユニットエコノミクスを最適化します。

機能比較: マネージドサービス vs. コントロールプレーン

この表は、AWSマネージドサービスとTrueFoundryコントロールプレーンの機能を比較しています。

ハイブリッドインフラストラクチャの主張

多くの企業にとって、将来は「AWS一辺倒」や「Azure一辺倒」ではなく、データグラビティとコストによって決まるハイブリッドな状態です。

AgentCoreは、データ取り込みから推論までのデータライフサイクル全体がAWS内で完結する場合に真価を発揮します。しかし、エージェントワークフローが規模を拡大するにつれて、Microsoft SharePoint、Google Cloud上の顧客データプラットフォーム、またはオンプレミスのウェアハウスにあるデータへのアクセスが必要になることがよくあります。

TrueFoundryは クロスクラウドルーティングパターンを可能にします。エージェントのロジックはコントロールプレーンに存在するため、複雑なVPNを経由したり、APIゲートウェイを手動で設定したりすることなく、異なるクラウド上のツールにアクセスできます。これにより、スタックの将来性が確保されます。例えば、 Azure OpenAI Service がClaudeを凌駕する新しいモデルをリリースした場合や、特定のユースケースでLlama 3が実用的になった場合でも、基盤となるエンジンを切り替えることは、コードの書き換えではなく、設定変更で済みます。

図3: クロスクラウドデータアクセスを可能にするTrueFoundryのルーティングアーキテクチャ。

まとめと推奨事項

AWSマネージドサービスとTrueFoundryコントロールプレーンの選択は、実質的に 統合の速度 と アーキテクチャの柔軟性の選択です。

• AWS Bedrock Agentsを標準化する場合: エンジニアリングチームの規模が小さく、アプリケーションロジックがAWS Lambda関数で大部分を構成されており、Bedrockポートフォリオ外のモデルを使用する必要がない場合。
• TrueFoundryを選択する場合: 異なるニーズを持つ複数の社内チームに対応するプラットフォームを構築している場合。AWSとAzure全体で予算とセキュリティポリシーを管理するための一元的なガバナンスが必要な場合。または、大量のエージェントワークロードのユニットエコノミクスを制御するために、スポットインスタンスでオープンソースモデルを活用する予定がある場合。

‍