認定された航空宇宙部品が廃番になったり、納期が長期化したりすると、エンジニアは仕様書、インターフェース制御文書（ICD）、認定記録を何日もかけて照合し、代替品の正当性を文書化してレビューに提出します。飛行クリティカルな部品の誤った代替はミッション失敗につながる可能性がありますが、各決定の証拠はメールや文書化されていない組織知識に分散しており、レビュー担当者が確認できる正式で再現可能なパッケージが存在しないことがよくあります。
以前の投稿「Manufacturing intelligence with Amazon Nova Multimodal Embeddings」では、テキストのみのパイプラインでは見逃されるエンジニアリング図、熱プロット、データシートチャートに埋め込まれた回答をモデルが取得する方法を紹介しました。本投稿はその検索作業を引き継ぎ、これらの機能をマルチエージェントシステムに組み込み、検索から評価草案の作成までの代替証拠の収集を実現します。
本投稿では、Amazon Bedrock AgentCore、Amazon Nova Multimodal Embeddings、オープンソースの Strands Agents SDK を使用して、部品代替評価における手動の照合作業を削減するマルチエージェントエンジニアリングアシスタントを構築する方法を紹介します。プランナーは、マルチモーダル知識ベースを検索し、決定論的な公差ルールで候補をスコアリングし、部品写真を比較し、ライフサイクル主張をライブ Web データで根拠付ける3つの専門エージェントに作業をルーティングします。エンジニアは常に意思決定者であり続けます。システムは証拠を収集し文書を起草しますが、代替を独自に承認することはありません。
ソリューションの概要
アシスタントは1つの設計ルールに基づいて構築されています。それは、エンジニアがすべての決定を行い、システムがそのための証拠を収集するというものです。このルールが、大規模言語モデル（LLM）を使用する場所と決定論的コードを使用する場所を決定します。
アーキテクチャを定義する3つの柱：
決定論的仕様適合評価 – Python で書かれた公差ルールコードが、各候補部品を参照部品とエンジニアの要件に対してスコアリングします。同じ入力が一貫して同じ合格/フラグ判定を生成するため、結果は正式なエンジニアリングレビューに使用できます。
マルチエージェントオーケストレーション – 軽量プランナーが各クエリを3つの専門エージェント（カタログ、評価、知識）の1つ以上にルーティングし、スーパーバイザーは複数の専門エージェントが貢献した場合にのみ調査結果を統合します。「このホイールが製造終了か確認し、代替品を見つけてスコアリングして」といった複雑な質問は、3つの専門エージェントすべてを順番に連携させます。
ヒューマンインザループ意思決定 – システムはエンジニアリングレビュー用の正当性メモと統合影響評価を起草しますが、代替を推奨または承認することはありません。また、すべての評価は AS9100 セクション 8.4 および 8.5.6 に沿った監査証跡エントリを書き込みます。
次の図はアーキテクチャを示しています。
図1：Amazon Bedrock AgentCore 上のマルチエージェントエンジニアリングアシスタントのアーキテクチャ
Amazon Bedrock AgentCore は、任意のフレームワークやモデルでエージェントを大規模に構築、接続、最適化するプラットフォームです。このソリューションでは、エンジニアのアプリケーションからのチャットリクエストが AgentCore ランタイムでホストされるマルチエージェントグラフに流れます。プランナー（Claude Haiku 5.5）がルーティング計画を生成し、専門エージェント（Claude Sonnet 5.5）がツールを実行し、スーパーバイザー（Claude Opus 5.5）が複数の専門エージェントが実行された場合に結果を統合します。専門エージェントは、Amazon Nova Multimodal Embeddings を使用して Amazon Bedrock Managed Knowledge Bases で作成されたマネージド知識ベースから、AgentCore Gateway（Amazon Bedrock AgentCore の機能）を介して検索し、ライブ Web データ用の Web Search コネクタも利用します。画像をクエリとして使用する場合（チャートをアップロードして部品を特定する場合）、エージェントはネイティブの Amazon S3 Vectors インデックスを直接呼び出します。これは、マネージド知識ベースの検索 API が画像入力を受け付けないためです。Amazon S3 Vectors は Amazon Simple Storage Service（Amazon S3）の機能です。別の固定チェーン（知識→評価→スーパーバイザー）が正式な統合影響評価（IIA）文書を生成します。
Amazon Nova Multimodal Embeddings は2つの異なる役割で登場します：
マルチモーダル検索 – データシート、ICD、性能チャートは Nova Multimodal Embeddings で埋め込まれ、テキストと視覚コンテンツが1つのセマンティック空間を共有します。エンジニアは「0.06 Nms ホイールのトルク曲線」と入力するか、チャート画像をアップロードでき、検索は一致する図をソース属性付きで返します。
視覚類似度スコアリング – 2つの候補部品を比較する場合、Nova Multimodal Embeddings はそれらの写真間の定量的なコサイン類似度を生成し、Claude は具体的な物理的差異（取り付けパターン、コネクタ配置、ハウジング形状）を分析します。スコアは決定論的仕様比較の補足証拠を追加しますが、適合判定は決定論的比較に基づきます。
前提条件
フォローするには、以下が必要です：
米国東部（バージニア北部）AWS リージョンで Amazon Bedrock にアクセスできる AWS アカウント。
Amazon Bedrock で Amazon Nova Multimodal Embeddings、Claude Haiku 5.5、Claude Sonnet 5.5、Claude Opus 5.5 へのモデルアクセス。リージョンごとのモデル可用性については、Amazon Bedrock の AWS リージョン別モデルサポートを参照してください。
部品コーパス（データシート、ICD、説明）に対して Amazon Nova Multimodal Embeddings を使用し、テキストおよび文書検索用に Amazon Bedrock Managed Knowledge Bases で作成されたマネージド知識ベース。
部品写真とデータシートチャートクロップに対して、画像クエリパス用の Amazon S3 Vectors インデックス。
Web Search コネクタとマネージド知識ベースターゲットを備えた Amazon Bedrock AgentCore Gateway。
Python 3.10 以降とノートブックを実行するための Jupyter。
ノートブック03のデプロイレシピを適応して AgentCore ランタイムでエージェントをホストする場合は Docker。
GitHub リポジトリのサンプルコード。
ソリューションのウォークスルー
以下のセクションでは、クエリが使用する順序でシステムの各部分を説明します。まず部品コーパスと専門エージェントから始め、次にルーティング、決定論的スコアリング、アシスタントが Nova Multimodal Embeddings を使用する2つの方法、正式文書を生成する固定チェーン、そして AgentCore ランタイムへのデプロイをカバーします。
完全なコードサンプルは GitHub リポジトリの5つの Jupyter ノートブックのセットで、各ノートブックは独立して実行されます。ノートブックは同じフォルダ内のエージェントとツールモジュールの自己完結型コピーである mei_core からインポートし、独自の部品データ、チャートクロップ、評価クエリセットを含みます。他のアプリケーションコードなしで、ノートブックからこの投稿のすべてのスニペットを実行できます。
部品コーパスの構造化
サンプルデータセットは、架空のメーカー AnyCompany の7つのリアクションホイールで、0.003～5.0 Nms の運動量貯蔵範囲にわたります。各パーツはフォルダであり、構造化データとエンジニアが実際に読むソースドキュメントをペアにしています。この組み合わせがコーパスをマルチモーダルにします。specs.json ファイルは決定論的スコアリングを駆動する機械可読フィールドを保持し、ICD、製品写真、レンダリングされたデータシートページは構造化フィールドが省略する視覚的および物語的詳細を伝えます。
各パーツフォルダには、テキストのみのインデックスでは使用できない2つのアセットも含まれています。製品写真は視覚類似度スコアリングに使用され、レンダリングされたデータシートページにはトルクボックスとトルク曲線プロットが含まれ、OCR テキストレイヤーでは捉えられない性能の質問に答えます。Amazon Nova Multimodal Embeddings は両方をテキストと同じベクトル空間に埋め込むため、クエリは仕様値、段落、またはプロットに一致できます。
次のサンプルは、コーパスからの4つのデータシートページを示し、3桁の運動量貯蔵範囲にわたります。
図2：部品コーパスからの4つのデータシートページ（3桁の運動量貯蔵範囲）
テンプレートはファミリー全体で繰り返されますが、製品写真と2つの性能プロットはパーツごとに変わります。これらの領域はハウジング形状、取り付けパターン、トルクエンベロープ、消費電力を示し、仕様フィールドでは直接述べられていないため、テキストと一緒に埋め込みます。
スコープ付きツールで専門エージェントを定義
各専門エージェントは、狭いプロンプトと必要なツールのみを持つ Strands エージェントです。専門エージェントごとにツールをスコープ設定することで、動作を予測可能に保ちます。知識専門エージェントはカタログ発見ツールにアクセスできず、カタログ専門エージェントは評価ツールにアクセスできません。次のコードは評価専門エージェントを作成します。
from strands import Agent
def create_evaluation_specialist() -> Agent: """評価専門エージェント：決定論的な仕様ごとの比較とスコアリング。""" return Agent( name="evaluation_specialist", system_prompt="""あなたは評価専門エージェントです。あなたの仕事は、部品間の決定論的で仕様駆動の比較を実行することです。 ... ルール：
- 比較は決定論的です（コードであり、意見ではありません）
- 推奨または承認を決して行わないでください --- 証拠とフラグを提示し、エンジニアが決定します
- これは証拠のみであるという免責事項を常に含めてください""",
tools=[score_substitution_fit, compare_parts, visual_similarity_score, check_qualification_status, generate_substitution_memo], model="us.anthropic.claude-sonnet-5-5", )
次の図は、プランナーがクエリを専門エージェントにルーティングする方法と、スーパーバイザーが結果を統合するタイミングを示しています。その後のリストは各専門エージェントの役割を説明しています。
図3：プランナーがクエリを専門エージェントにルーティングし、スーパーバイザーが結果を統合するタイミング
カタログ – 知識ベース検索と徹底的な仕様フィルタリングを通じて部品を発見します（kb_search, filter_parts_by_spec, get_part_specs, get_substitution_requirements）。
評価 – 候補を決定論的にスコアリングし、部品を視覚的に比較します（score_substitution_fit, compare_parts, visual_similarity_score, check_qualification_status, generate_substitution_memo）。
知識 – データシートと ICD からの質問に答え、ライブの製造終了状況を確認し、視覚コンテンツを取得します（get_part_specs, web_search_eol, retrieve_visual_content）。
ルーティングには小型モデル、統合には大型モデルを使用
ルーティングはツール呼び出しのない分類タスクであるため、大型推論モデルは必要ありません。Haiku ベースのプランナーは番号付きの
[AIコスト制御のため切り捨て]