10月24日、AWSが「How Bayer Crop Science built an agentic decision engine on Amazon Bedrock AgentCore with AWS Unified Operations」と題した記事を公開した。Bayer Crop ScienceがAmazon Bedrock AgentCore上に農業向けマルチエージェントシステム「Agentic Decision Engine（ADE）」を構築し、障害診断にかかる時間を1時間以上から10分以内に短縮した事例だ。22の専門エージェントが協調するエンタープライズ規模のシステムを本番に持っていくまでの設計判断と実装詳細が詳しく公開されている。
背景：ワークフロー実行から「理解」へのボトルネックシフト
Bayer Crop Scienceは、ゲノミクス・圃場試験・画像・環境データ・モデル出力といった多様なデータを基に植物育種の意思決定を行っている。同社はすでに「Connected Decision Engine（CDE）」と呼ばれるMLワークフロー基盤を運用しており、作物・地域・チームをまたいで数百のMLモデル設定を管理している。
CDEの採用が広がるにつれ、ボトルネックはワークフローの「実行」から「理解」へ移行した。あるワークフローが失敗した理由を調べるには、API・ドキュメント・メタデータストア・ダッシュボード・ログを個別に横断する必要があり、エンジニアのサポートを待つケースも多かった。かつて1時間以上かかっていた障害診断が、ADE導入後は10分以内に短縮されたというのが象徴的な成果だ。
ADEのアーキテクチャ：22の専門エージェントが協調する構造
ADEは4層構造で設計されている。
- ユーザー体験層：ReactのWebフロントエンド。Microsoft Entra ID経由の認証プロキシを経由してエージェントに接続
- エージェントオーケストレーション層：LangGraph（LangChainが開発するグラフベースのエージェントオーケストレーションフレームワーク）ベースのSupervisor Agentがリクエストを分類し、適切な専門エージェントにルーティング
- 専門エージェント層：本番環境で22の専門エージェントが稼働。各エージェントは固有のドメインとツールセットを持つ
- ツール・データソース層：AgentCore Gateway（AWS上のAPIアクセス管理・ツール公開レイヤー）を通じてCDE APIなどバックエンドサービスをMCP（Model Context Protocol）ツールとして公開。MCPはAnthropicが策定したオープン標準で、AIモデルが外部ツールやデータソースと構造化されたインターフェースで通信するためのプロトコルだ
データ基盤としては、LangGraphのチェックポイント状態をAmazon DynamoDBに保存、セッション記録・フィードバック・分析データをAmazon Aurora PostgreSQLに格納、エージェント応答のキャッシュにAmazon ElastiCacheを使用、RAGにはAmazon Titan Text Embeddings V2でエンベディングしたドキュメントをAmazon OpenSearch Serverlessに格納する構成だ。
初期フェーズの時点で、エンジニア介入なしにユーザー質問の約80%を解決している。
本番化に向けた5つの設計判断
記事の核心は、AWS Unified OperationsのTAM（Technical Account Manager）とDSE（Domain Specialist Engineer）がチームに組み込まれる形で行われた設計判断の詳細だ。
1. オーケストレーション状態の外部化
Amazon Bedrock AgentCoreのランタイムセッションはアクティブな実行コンテキストを保持するが、マルチステップワークフローの永続ストアではない。ADEはLangGraphのチェックポイントをDynamoDBに書き出し、スケールアウトやセッション境界をまたいでワークフローを再開できるようにした。
2. エンタープライズIDとゲートウェイアクセスの分離
Entra IDをユーザーIDの源泉として維持しつつ、サービス間認可にはIAMを使用し、CDE下流サービスへのアクセスはAgentCore Gatewayが処理する。「トークンが一方の境界で有効だからといって、次の境界でも再利用しない」という設計思想だ。
3. モデル選択をインターフェース契約として扱う
ビルド中、推論モード付きの新モデルバージョンを評価したが、ツール使用と構造化出力の組み合わせが既存実装と互換性がないことが判明し、既存モデルを維持した。「新しいモデルが自動的に互換の代替品になるわけではない」という原則は、ツール呼び出しエージェントの実装者に刺さる知見だ。
4. ツールカタログのスコープ制御
CDEは500以上のモデル設定を管理している。APIごとにMCPサーバーを立てる代わりに、OpenAPI仕様をAgentCore Gatewayに登録してRESTオペレーションをMCPツールとして公開する構成を採用した。ツール定義はプロンプトのトークンを消費し、モデルの判断空間を広げるため、各専門エージェントに必要なツールのみスコープを絞った。大規模カタログにはAgentCore Gatewayのセマンティックツール検索機能を活用できる。
5. 複雑な機能のツールからエージェントへの昇格
Visualizationは当初、他のエージェントから呼ばれるツールとして実装されていたが、独自のデータ取得・チャート選択ロジック・リトライ・エラーハンドリングが必要になり、専門のVisualizationエージェントに昇格させた。同エージェントはAgentCore Code Interpreter（コンテナ化されたサンドボックスコード実行環境）上でmatplotlibとPlotlyを使ってチャートを生成し、Amazon S3経由でデータをやり取りする。
本番運用前に表面化した問題
コスト帰属の分析では、VisualizationエージェントとOperationalエージェントが最もトークンを消費していることが判明した。また、起動準備中に大きな繰り返し入力プレフィックスを持つワークロードでプロンプトキャッシュが機能していないケースを発見。安定した命令とツール定義をキャッシュ可能なプレフィックスに配置することで、入力トークンコストを20〜30%削減した。
セキュリティと起動準備については、Unified OperationsがCritical Workload ReviewとWell-Architected Review（Generative AI Lens）を実施した。DSEがワークロードを把握していたため、一般的なベストプラクティスではなくADE固有の障害モードに絞ったレビューとなった。指摘事項にはスーパーバイザー・専門エージェント間の障害可視性の欠如、ミュータブルなコンテナイメージタグ、脆弱性スキャンの不備などが含まれ、チームはイミュータブルバージョン管理イメージへの切り替えやAmazon ECRでのスキャン設定で対応した。ロードテストでは、空レスポンスを返すネットワーク障害モードを本番前に発見・修正している。Unified Operationsとの協働で35件のブロッカーを解消してから本番リリースに臨んだ。
産業AIの実装事例として、エンタープライズ規模のマルチエージェントシステムを本番に持っていくための具体的な判断基準が詳細に公開されているのは珍しい。LangGraphをAmazon Bedrock AgentCore上で動かすための設計判断や、MCPツールのスコープ管理など、実装者にとって参考になる内容が多い。
詳細はHow Bayer Crop Science built an agentic decision engine on Amazon Bedrock AgentCore with AWS Unified Operationsを参照していただきたい。
