植物の品種改良の意思決定は、ゲノミクス、圃場試験、画像、環境条件、モデル出力にまたがるデータに依存しています。Bayer Crop Scienceは、作物、地域、チームを横断してこのデータに対し数百の機械学習 (ML) モデル構成を実行しており、各実行は再現可能で管理されたものである必要があります。この要件を満たすため、BayerはConnected Decision Engine (CDE) を構築しました。これはMLワークフローをデプロイ、オーケストレーション、監視、再利用するためのシステムです。CDEは、ブリーダー、アナリスト、研究者、データサイエンティスト、データエンジニアに、実行履歴と運用管理を維持しながらアナリティクスを実行する一貫した方法を提供します。
採用が拡大するにつれ、ボトルネックはワークフローの実行からワークフローの理解へと移りました。結果を説明するには、API、ドキュメント、メタデータストア、ダッシュボード、ログから文脈を組み立てる必要がありました。ワークフローがなぜ失敗したのか、モデルが何をしたのか、結果がどこから来たのかを知りたいユーザーは、どのシステムを調べればよいのかを依然として知っている必要がありました。このギャップを埋めるため、BayerはCDE上のマルチエージェント型自然言語インターフェイスであるAgentic Decision Engine (ADE) を構築しました。スーパーバイザーエージェントが各質問を専門エージェントにルーティングし、専門エージェントが関連システムから文脈を取得し、ユーザーは運用スタックを操作することなく回答を受け取ります。最初のフェーズでは、ADEはユーザーの質問の約80パーセントをエンジニアを介さずに解決しています。
ADEは Amazon Bedrock AgentCore上で動作します。これは、あらゆるフレームワークやモデルを使って大規模にエージェントを構築、接続、最適化するためのAWSのサービスです。AgentCoreにより、チームは独自のエージェントホスティング、セッション分離、ツールアクセス層を構築・運用する代わりに、エージェントの動作に集中できました。この選択を後押ししたのは、AgentCoreの3つの機能です。各ユーザーセッションを分離するマネージドランタイム、AgentCore Gateway(Amazon Bedrock AgentCoreの機能)によるAWS Identity and Access Management (IAM) スコープのツールアクセスにより認証と認可をエージェントコードの外部に保つ仕組み、そしてチームが独自のLangGraphオーケストレーションとモデルの選択を持ち込めるフレームワーク非依存の設計です。
ローンチに備え、その後ADEを運用するために、Bayerは AWS Unified Operationsを活用しました。このエンゲージメントにより、専任のTechnical Account Manager (TAM) と生成AIドメインスペシャリストエンジニア (DSE) が提供され、設計から本番までADEチームの延長として活動しました。TAMはBayerの戦略アドバイザーとして、Bayerの運用モデルとビジネス上の優先事項に対する確立された理解をもたらしました。DSEはAWSにおける生成AIのドメイン専門知識をもたらしました。週3回のテクニカルスタンドアップで、チームは設計の検討と決定を行いました。DSEはADEワークロードとBayerチームの運用方法に関する実務知識を構築したため、技術的ガイダンスはAWSサービスの動作とBayerの状況の両方を反映したものになりました。本記事ではその道のり、すなわちADEのアーキテクチャ、構築中に行われた5つの設計決定、プラットフォームの本番準備の作業、そしてローンチ後の運用方法を追います。
アーキテクチャの概要
ADEは4つの層で構成されています。ユーザーエクスペリエンス、エージェントオーケストレーション、専門エージェント、そしてそれらのエージェントが呼び出すツールとデータソースです (図1)。ユーザーはReactのWebフロントエンドを通じてADEにアクセスし、リクエストはエージェントに到達する前にMicrosoft Entra IDのアイデンティティプロキシを通過します。GitHub Actionsがエージェントのコンテナイメージをビルドし、 Amazon Elastic Container Registry (Amazon ECR)にプッシュし、Amazon Bedrock AgentCoreの機能であるAgentCoreランタイムにデプロイします。
Amazon Bedrock AgentCoreランタイムがエージェントをホストし、このランタイムはフレームワーク非依存のため、チームは独自のLangGraphベースのオーケストレーションをその上で直接実行しています。チームがLangGraphを選んだのは、明示的なグラフベースの制御フローと、マルチステップワークフローのためのチェックポイント機能によるものです。LangGraphがワークフローをオーケストレーションし、Supervisor Agentがエントリーポイントとして各リクエストを分類し、スペシャリストを選択し、質問が複数の領域にまたがる場合には結果を統合します。データプレーンは責任ごとに分離されています。 Amazon DynamoDB はLangGraphのチェックポイント状態を保存します。 Amazon Aurora PostgreSQLはセッションレコード、ユーザーフィードバック、分析データを保存します。 Amazon ElastiCache は有効期限 (TTL) 付きでエージェントの応答をキャッシュします。 Amazon Simple Storage Service (Amazon S3) 内のドメインコンテンツはAmazon Titan Text Embeddings V2で埋め込み化され、Retrieval Augmented Generation (RAG) のために Amazon OpenSearch Serverlessにインデックスされています。 Amazon CloudWatch はランタイムおよびアプリケーションのテレメトリーを取得します。AgentCore GatewayはバックエンドAPIをModel Context Protocol (MCP) ツールとしてエージェントに公開し、認証と認可をエージェントコードの外部に保ちます。
図1: Amazon Bedrock AgentCore上のエージェント型ディシジョンエンジン (ADE) のアーキテクチャ
ADEは本番環境で22個のスペシャリストエージェントを実行しており、それぞれが独自のツールとデータソースを持つ単一のドメインにスコープされています。例えば、Domain Expert AgentはRAGを通じて概念的な質問に回答します。Operational AgentはCDEからワークフローのライブステータスと結果を取得します。Troubleshooting Agentは運用テレメトリーを分析します。Visualization Agentはチャートを生成したり、既存のダッシュボードを返したりします。顧客固有の Models as Skill パターンは、モデルのコードとドキュメントを中央レジストリに保存されたスキル定義に変換するため、エージェントは一般的なモデル知識ではなく、そのモデルの実装に基づいてモデル固有の質問に回答できます。
ブリーダーが「なぜ昨日、私のフェノタイピングワークフローが失敗したのですか？」と尋ねると、スーパーバイザーがインテントを分類し、リクエストをTroubleshooting Agentにルーティングします。そのエージェントはCloudWatch内のワークフローのテレメトリーを読み取り、AgentCore Gatewayを通じてCDE APIからステータスを取得し、失敗点を特定して、スーパーバイザー経由で診断を返します (図2)。ブリーダーはログを直接検索する必要はありません。Troubleshooting Agentにより、以前は手作業でのログ調査とエンジニアのサポート待ちで1時間以上かかっていた診断が、10分未満で完了するようになりました。
図2: ADEのリクエストフロー: インテント分類、キャッシュ参照、スペシャリストへのルーティング、応答
本番稼働への道のりにおける5つの設計上の決定
Unified OperationsのTAMとDSEは、事後のエスカレーション先としてではなく、作業チームのメンバーとして以下の決定に参加しました。これにより、Bayerは各設計を確定する前にAWSのサービス動作に対して検証でき、アーキテクチャの所有権と最終決定権は自らに保持しました。
1. ランタイムをステートレスとして扱わずにオーケストレーション状態を外部化する
AgentCoreランタイムは、セッションのライフサイクル内の複数の呼び出しにわたって実行コンテキストを保持する分離されたセッションを提供します。しかし、そのコンテキストはマルチステップワークフローのための永続ストアではありません。ADEはLangGraphのチェックポイントをDynamoDBに書き込むことで、スケールアウトイベント、再起動、セッション境界の後でも、特定の実行環境が稼働し続けることに依存せずにグラフを再開できます。
原則: ランタイムセッションはアクティブな実行に使用し、ワークフローの再開または再構築に必要な状態は永続的なサービスに保存します。
2. エンタープライズID、ゲートウェイアクセス、下流の認可を分離する
BayerはユーザーIDにMicrosoft Entra IDを標準化しており、一方、ADEのサービス間はAWSネイティブのメカニズムで相互に認可します。1つのトークンをすべての信頼境界にまたがって強制するのではなく、チームは各境界に固有のメカニズムを割り当てました。
Entra IDは引き続きユーザーIDのソースです。AWS Identity and Access Management (IAM) がサービス間呼び出しを認可します。AgentCore Gatewayのアウトバウンド認可が下流のCDEサービスへのアクセスを処理します。リクエストインターセプターとして機能するAWS Lambda関数がカスタム検証を行い、下流のツールが必要とする認可属性を渡します。チームは各ホップでのトークン契約についてDSEと協議しました。
原則: エージェントシステムにおけるIDの失敗は、ユーザーID、エージェントID、ツールIDの間の遷移部分に集中します。ある境界で有効なトークンを次の境界で再利用するのではなく、すべてのホップでissuer、audience、クレーム、スコープ、資格情報の有効期間を定義してください。
3. モデル選択をインターフェース契約として扱う
構築中、チームは推論モードを有効にした新しいモデルバージョンを評価しました。そのバージョンでは、ADEが依存するツール使用と構造化出力の組み合わせが、エージェントの実装方法と互換性がありませんでした。DSEがこの制約を確認し、チームはリリースには現行のモデルを維持しました。
原則: ツールを使用するエージェントにとって、モデルの選択はインターフェース全体によって制約されます。ツール呼び出し、構造化出力、ストリーミング動作、推論機能、レイテンシ、クォータの可用性、そしてモデル固有のリクエストセマンティクスです。より新しいモデルが自動的にそのまま置き換え可能だとは限りません。
4. ツールサーフェスがプロンプトを支配する前に、それを制御する
CDEは500を超えるモデル構成を管理しています。APIごとに専用のMCPサーバーを用意すると、デプロイ、認証、バージョン管理のオーバーヘッドが増えていました。ADEは代わりに、OpenAPI仕様をAgentCore Gatewayに登録し、RESTオペレーションをMCPツールとして公開しています。APIの追加や変更は、新しいサーバーのデプロイではなく、スキーマとゲートウェイ構成の変更で対応できます。
ツールのスキーマや説明も入力トークンを消費し、ユーザーのリクエストや取得されたコンテキストと競合します。ADEは、すべてのエージェントに完全なカタログを与えるのではなく、専門エージェントごとにツールをスコープしています。より大きなカタログについては、AgentCore Gatewayがセマンティックツール検索をサポートしており、エージェントは毎ターンでカタログ全体を読み込むことなく関連するツールを見つけられます。
原則: ツールカタログをエージェントごとにスコープする。ツール定義はすべてトークンを消費し、モデルの意思決定空間を広げます。
5. 複雑なケイパビリティをツールからエージェントへ昇格させる
可視化は、当初は他のエージェントから呼び出されるツールでした。成長するにつれて、独自のデータ取得、チャート選択ロジック、リトライ、エラーハンドリング、そしてチャートを生成するか既存のダッシュボードを返すかの判断が必要になりました。チームはこれを専門のVisualization Agentに移行しました。このエージェントは、サンドボックス化されたコード実行環境を提供するAmazon Bedrock AgentCoreのケイパビリティであるAgentCore Code Interpreter上で、matplotlibとPlotlyを使ってオンデマンドのチャートを生成し、Amazon S3を通じてデータをやり取りします。事前構築済みのダッシュボードがより適切な回答である場合は、エージェントは既存のAmazon QuickまたはPower BIのアセットを返します。
原則: ツールは限定的な操作を実行するもの。ケイパビリティが状態、リトライ、計画、ポリシー、またはプレゼンテーションの判断を担うようになったら、エージェントとしてモデル化します。
ADEの本番準備
構築がローンチに向かうにつれて、焦点は設計から運用性へと移りました。エージェントの障害検出、推論コストの帰属、デプロイの強化です。
オブザーバビリティ: 例外だけでなくタスクの失敗を測定する
スーパーバイザーアーキテクチャでは、1つのユーザーリクエストが、モデル呼び出し、ツール呼び出し、エージェント間のハンドオフの連鎖に変わります。すべてのHTTPリクエストが成功していても、最終的な回答が誤っている可能性があります。ADEはこれを直接経験しました。アプリケーションの例外ハンドラーがエージェントのエラーを捕捉し、モニタリングでは成功としてカウントされるレスポンスを返していたのです。DSEでこの問題を再現した後、チームは失敗パス内にカスタムCloudWatchメトリクスを追加し、ツール呼び出しエラー、スロットリング、モデルのタイムアウト、構造化出力の検証失敗といったエージェント固有の条件に対するアラームを設定しました。トレースと呼び出しログが、各リクエストをスーパーバイザーとスペシャリスト全体にわたって追跡します。
原則: トランスポートの成功とタスクの成功を区別する。エージェントのオブザーバビリティは、タスクが完了したか、どのエージェントやツールが結果を変えたか、レスポンスが期待されたソースを使用したかを示すべきです。
コスト帰属: 請求帰属とリクエストレベルのテレメトリーを組み合わせる
1回のADEリクエストで複数のモデルやツールを呼び出すことがあるため、アカウントレベルのAmazon Bedrockの支出ではユニットエコノミクスを説明できません。チームはDSEとともに、異なる問いに答える3つのメカニズムを使って帰属アプローチを設計しました。Amazon Bedrockのアプリケーション推論プロファイルは、請求対象のモデル使用量をアプリケーションやワークロードに帰属させます。リクエストメタデータとモデル呼び出しロギングは、トークン使用量を特定のエージェント、機能、またはリクエストに関連付けます。IAMプリンシパル帰属は、アイデンティティの次元を追加します。これらを組み合わせることで、チームはインタラクションごとのコストを見積もり、高コストなエージェントを特定し、プロンプト、取得されたコンテキスト、ツール定義のどれがトークン使用を driving しているかを判断できます。実際、MCPツールと複数のツール呼び出しに依存するVisualizationエージェントとOperationalエージェントが、最も多くのトークンを消費しました。
同じテレメトリーにより、ローンチ準備中に、大きな繰り返し入力プレフィックスを持ちプロンプトキャッシュのアクティビティがないワークロードが明らかになりました。対応しているモデルでは、安定した指示とツール定義をキャッシュ可能なプロンプトプレフィックスに配置することで、繰り返しの入力処理が削減され、レイテンシーとトークンコストが下がります。ADEでは、安定したプロンプトプレフィックスをキャッシュすることで、入力トークンコストを20–30パーセント削減しました。
セキュリティとローンチ準備
IAMロールは各エージェントの責務にスコープされています。Troubleshooting Agentは診断に必要な運用データを読み取ることができますが、ワークフローを変更することはできません。Domain Expert Agentは自身の検索インデックスを照会できますが、無関係なCDE APIを呼び出すことはできません。現在の本番環境では、ADEのエージェントレスポンスは、最小権限、各エージェントにスコープされた読み取り専用のツールアクセス、エージェントレスポンスに対する構造化出力の検証、そして自由な生成ではなく取得されたCDEデータとテレメトリーに基づく回答によって管理されています。Bayerはまた、CDEのマルチターンワークフローで既に使用されているカスタム安全チェックを補完する追加レイヤーとして、Amazon Bedrock Guardrailsの評価も計画しています。
ローンチ前に、Unified OperationsはADEチームとともに、Critical Workload Reviewと、Generative AI Lensを用いたWell-Architectedレビューを実施しました。DSEが既にワークロードを把握していたため、両レビューは一般的なベストプラクティスではなく、ADE固有の障害モード、キャパシティリスク、デプロイのギャップに焦点を当てました。指摘事項には、スーパーバイザーとスペシャリストエージェント間の障害可視性の不足、変更可能なコンテナイメージタグ、限定的なイメージトレーサビリティ、脆弱性スキャンの欠如が含まれていました。チームは、より強力なアラーム、不変のバージョン管理されたイメージ、Amazon ECRでのプッシュ時スキャン、未使用イメージのライフサイクルポリシーで対応しました。
DSEはチームとともにスケーリングとクォータ要件も確認しました。ロードテストにより、アプリケーションとそのサービスクォータの両方が検証され、空のレスポンスを返すネットワークの障害モードが明らかになり、チームは本番イベントの前にこれを修正しました。ローンチまでに、チームはUnified Operationsとともに35のブロッカーを解決まで追跡しました。
ローンチ、運用、そして次のステップ
BayerはADEを組織全体に一斉に公開するのではなく、限定されたグループに展開しました。ローンチ以来、Bayer Crop Science全体で100人を超えるユーザーがADEを利用しており、その中にはブリーダー、アナリスト、研究者、データサイエンティスト、エンジニアが含まれます。22の専門エージェントに加えて、ADEは約20のAPIツールを公開しており、拡大に伴いサードパーティのエージェントをホストすることもできます。APIごとに専用サーバーを立てるのではなくAgentCore Gatewayを通じてこれらのAPIを公開することで、APIごとの統合オーバーヘッドを99パーセント以上削減しました。最初のフェーズで、ADEはユーザーの質問の約80パーセントをエンジニアを介さずに解決しました。
CDEは引き続き、分析のためのガバナンスされた実行レイヤーです。ADEはその上に自然言語レイヤーを追加し、ユーザーは基盤となる各システムの場所やインターフェースを学ぶことなく、ワークフローのステータス、結果、モデルの挙動、障害について質問できるようになりました。
その後、エンゲージメントはローンチ準備から継続的な運用へと移行しました。DSEは引き続きチームと会合を持つため、問題のトリアージや運用レビューは、新たな立ち上げではなくADEに関する既存の知識から始まります。ADEの重要なCloudWatchアラーム(先述のエージェント固有のアラームを含む)は、AWS Incident Detection and Responseにオンボードされています。アラームが発報すると、AWS Incident Management Engineersが5分以内に対応し、ゼロからではなくワークロードのコンテキストに基づいて作業を開始します。セキュリティ面では、AWS Security Incident Responseのエンジニアが潜在的または実際のセキュリティイベントの際にチームを支援するため、ADEは運用とセキュリティの両方の問題についてAWSの監視および対応体制でカバーされています。
エージェント間通信がすでに整備されていることを受け、Bayerは次にハイブリッドクラウドにおけるエージェントの相互運用性に注力しています。チームは、異なる環境で実行されるエージェントが手動の設定なしに互いを発見し通信できるようにする方法を検討しています。
結論
Bayerは分析プラットフォームをADEに置き換えたのではありません。CDEをより問い合わせやすく、運用しやすくしたのです。本番環境での作業の大部分は、プロンプトの外側にありました。すなわち、永続的なステート、アイデンティティの境界、ツールのスコープ設定、タスクレベルのオブザーバビリティ、コストの帰属、そしてローンチ準備です。Bayerはアーキテクチャとそれらの各決定を自ら所有していました。AWS Unified Operationsを通じて指定DSEおよびTAMと連携し、チームは設計段階でこれらの決定をAWSサービスの挙動に対して検証し、同じコンテキストを本番環境へと持ち込みました。
詳しく知るには、以下をご覧ください: Amazon Bedrock AgentCore, Amazon Bedrock cost attribution, AWS Well-Architected Generative AI guidance、および AWS Unified Operations.
著者は、ADEの設計、開発、ローンチに貢献してくださったSijie Shi、Jorge Gomes、Naveen Reddy、Iago Fonseca、Mateus Silva、Sushimitha Jarugulaの皆様に感謝いたします。