AWSはCSVと自然文から分析し、検証と図表を含む文書を作るDeep Insightを紹介しました。役割分担、人の承認、実行環境の分離を説明しています。 複数エージェントでは、モデル選択に加えて実行順序と失敗時の経路が重要です。計算の検証と生成コードの隔離を評価する材料になります。 試作から本番へ進む際の課題を構成で解く AWSは10月21日、複数のエージェントでデータ分析を行うDeep Insightを公開しました。分析用CSVと自然文の指示を受け、計画、コード実行、計算の検証、図表と文書の作成を分担します。試作のエージェントを作ることと、業務の手順や検証を守って運用することには差があると説明しています。記事は3回の連載の第1回で、実行順序や本番の基盤に関する5つの課題を扱います。Strands Agents SDK、Amazon Bedrock、AgentCoreなどを組み合わせ、指示文の調整だけに頼らず、処理の流れそのものを設計する考え方を示しています。 計画を承認してから専門役へ処理を渡す Deep InsightではCoordinator、Planner、Supervisor、Coder、Validator、Reporter、Trackerが協働します。計画を利用者へ示し、承認後に分析を実行する構成です。記事のデモは架空の食品企業の広告データを使い、列の定義も与えています。分析を担当する組織や、レポート作成を支援する基盤の開発者が対象です。Graphで順序や人の承認を表現し、必要に応じて専門エージェントをツールとして呼ぶ方式を紹介しています。役割によってBedrockのモデルを選び、費用と品質を調整します。生成コードの実行は、ALBとECS on Fargateを使って分離すると説明しています。回答文の自然さだけでなく、入力の意味、処理の順序、計算の根拠を扱う仕組みが含まれます。個々の役割を増やすだけで品質が決まるわけではありません。 検証と隔離に必要な運用費用も測る 実務では、分析結果を誰が承認するかと、生成コードが触れる範囲を先に決めることが論点です。複数の役割を用意すると、推論の呼び出しや通信が増え、処理時間や費用が変わる可能性があります。Validatorがいることだけを正しさの証明とせず、元データと計算結果を追えるかを確認する必要があります。入力の列定義や欠損値の扱いが曖昧なら、複数のエージェントが同じ前提を誤る場合も考えられます。試験では代表的なデータで出力を比較し、途中の失敗や再実行も含めて評価する方法があります。サンプルの構成と自社の情報管理を照らし、セッション間の分離や記録の範囲も確認する対象です。分析の自動化率と、完成した報告を確認する負担を合わせて測ることが、本番へ進む判断材料になります。承認後の処理変更をどう扱うかも重要です。