航空宇宙部品の代替品選定、「数日かかる作業」をマルチエージェントで数分に — AWSがAS9100準拠の承認証跡付き実装を公開

11月3日、AWSが「Agentic engineering intelligence with Amazon Nova Multimodal Embeddings and Amazon Bedrock AgentCore」と題した記事を公開した。この記事では、航空宇宙部品の代替品評価に要していた数日間の作業を、マルチエージェントシステムによって数分に短縮する実装手法について詳しく紹介されている。

「数日かかる作業」をシステムに任せる

航空宇宙機器に使用される部品が製造中止になったり、納期が長期化したりした場合、エンジニアはベンダーのデータシート、インタフェース制御文書（ICD）、適格性評価記録を手動で突き合わせながら代替品を選定する。この作業には数日を要し、判断根拠がメールや属人的知識に散在するため、後からレビュー担当者が検証する術がない。

航空宇宙分野でLLMの自律的判断が敬遠されてきた背景には、認証・責任・ドキュメンテーション要件の厳しさがある。部品の採用判断には設計変更管理（Engineering Change Order）プロセスが伴い、根拠の完全な文書化と担当エンジニアによる署名承認が義務付けられている。**AS9100は航空宇宙・防衛産業向けの品質マネジメントシステム規格**であり、ISO 9001をベースに、設計変更の追跡可能性（トレーサビリティ）・サプライヤー管理・リスク管理に関する要求事項を上乗せしている。同規格のセクション8.4（外部提供プロセス・製品・サービスの管理）およびセクション8.5.6（変更の管理）は、部品代替を含む変更の記録保持を明示的に求めており、「誰が、いつ、何を根拠に判断したか」が事後検証できなければならない。LLMが自律的に代替品を承認してしまうと、この要件を満たせないのだ。

本記事はAWSが提案する解決策として、Amazon Bedrock AgentCore・Amazon Nova Multimodal Embeddings・オープンソースのStrands Agents SDKを組み合わせたマルチエージェント・エンジニアリング・アシスタントの構築方法を解説する。

アーキテクチャの核心：3つの設計原則

システム全体は「エンジニアがすべての決定を下し、システムはその根拠を揃える」という一つの設計ルールのもとに構築されている。LLMを使う箇所と決定論的コードを使う箇所を明確に分けることが、航空宇宙という高信頼性が求められる領域での採用条件となっている。

設計原則1：決定論的スペック適合評価（LLMを使わない部分）

代替候補のスペック評価はPythonコードによる確定的処理で行う。電圧バスの一致、質量の許容偏差（±20%以内）といったルールをスキーマとして定義し、score_substitution_fit関数が各スペックをpass/flagで判定する。同じ入力には必ず同じ結果が返るため、エンジニアリングレビューパッケージとして正式に提出できる。

{
  "categories": {
    "reaction_wheel": {
      "critical_specs": [
        {"field": "voltage_v", "label": "Bus voltage (V)",
         "rule": "match", "required_from_user": true},
        {"field": "mass_g", "label": "Mass (g)",
         "rule": "candidate_lte_reference_within_pct", "tolerance_pct": 20,
         "required_from_user": false}
      ]
    }
  }
}

設計原則2：3専門エージェントによるマルチエージェント orchestration

クエリはプランナーが受け取り、以下3つの専門エージェントへルーティングする。

Catalogエージェント：ナレッジベース検索とスペックフィルタリングで候補部品を発見
Evaluationエージェント：スペック比較、視覚的類似度スコアリング、代替理由書の生成
Knowledgeエージェント：データシート・ICDへの質問応答、ライブWebからのEOL（製造終了）情報取得

複数の専門エージェントが回答した場合のみ、スーパーバイザーが結果を統合する。単一エージェントの回答に対してスーパーバイザーを通すと約8秒の遅延が発生するためスキップする設計だ。プランナー（高速・低コストモデル）→専門エージェント（中間モデル）→スーパーバイザー（高性能モデル）という3段階でコストと応答品質をステージに合わせている点が実装上の重要な工夫だ。

# Step 1: Planner（高速モデル）がルーティング計画を立案
plan_response = planner(planning_prompt)
ordered_specialists = _parse_specialist_plan(str(plan_response))

# Step 2: 専門エージェントを順次実行し、コンテキストを引き継ぐ
accumulated_context = ""
for spec_name in ordered_specialists:
    specialist = specialists[spec_name]
    specialist_response = specialist(spec_prompt)
    accumulated_context += f"\n[{spec_name.upper()}]: {specialist_response}\n"

# Step 3: 2つ以上のエージェントが実行された場合のみ統合
if len(ordered_specialists) == 1:
    final_text = steps[0]["response"]
else:
    final_text = str(supervisor(synthesis_prompt))

設計原則3：Human-in-the-loop：システムは承認しない

システムが生成するのは代替理由書（Substitution Justification Memo）と統合影響評価書（Integration Impact Assessment）のドラフトのみ。代替品の承認は常にエンジニアが行う。すべての評価結果はAS9100のセクション8.4および8.5.6に準拠した監査証跡として記録される。LLMはあくまで「根拠の収集と整形」を担い、「判断と署名」は人間が担う——この役割分担こそが規格準拠の核心だ。

Amazon Nova Multimodal Embeddingsの2つの役割

本システムで特徴的なのが、Nova Multimodal Embeddingsをテキストと画像の両方で活用している点だ。

① マルチモーダル検索：データシート、ICD、トルクカーブのグラフ画像を同一のベクトル空間にインデックスする。エンジニアが「0.06 Nmsホイールのトルクカーブ」とテキストで質問しても、グラフ画像をアップロードして部品を照会しても、同じ検索パスで答えが返る。テキストのみのパイプラインでは拾えない図表内の情報が検索対象になる。

② 視覚的類似度スコアリング：2つの候補部品の製品写真をNova Multimodal Embeddingsでベクトル化し、コサイン類似度を算出する。マウントパターン、コネクタ配置、筐体形状の差異をLLMが言語で説明し、スペック比較の補足証拠として付加する。

なお、画像をクエリとして使う場合（例：グラフ画像のアップロード）はAmazon Bedrock Managed Knowledge Basesの検索APIが画像入力を受け付けないため、Amazon S3 Vectorsインデックスを直接呼び出す経路が用意されている。

サンプルデータの構造

記事で使用されるサンプルは、架空メーカー「AnyCompany」の7種類のリアクションホイール（運動量保存装置。衛星の姿勢制御に使われる部品）で、0.003〜5.0 Nmsの運動量範囲をカバーする。各部品フォルダは以下の構成だ。

data/synthetic-parts-data/rw_rl_0060/
├── specs.json          # 機械可読スペック＋ライフサイクル情報
├── description.txt     # テキスト検索用フラットテキスト
├── AC-ICD-00068-RW3-0.06-Interface-Control-Document-v2.2.pdf
├── datasheet_page.png  # レンダリング済みデータシートページ
├── datasheet_chart.png # グラフ切り出し画像（画像クエリ用インデックス）
└── photo.png           # 製品写真（視覚的類似度＋グラフ照合用）

specs.jsonにはエンジニアリングスペックに加え、lifecycleフィールドとして製造状況・製造終了予測年・リードタイム・推奨スクリーニング基準が含まれており、EOLリスクの自動フラグに使われる。

実装の前提条件

記事では以下の環境が必要とされている。

AWS アカウント（us-east-1リージョンでのAmazon Bedrockアクセス）
Amazon Bedrock でのモデルアクセス（Nova Multimodal Embeddings、および各ステージで使用するClaude各モデル）
Amazon Bedrock Managed Knowledge Bases（Nova Multimodal Embeddingsを使用）
Amazon S3 Vectors インデックス（製品写真・グラフ画像用）
Amazon Bedrock AgentCore Gateway（Web Searchコネクタ付き）
Python 3.10以降・Jupyter
Docker（AgentCore runtimeへのデプロイ時）

完全なサンプルコードは5本のJupyter NotebookとしてGitHubリポジトリで公開されている。各Notebookは独立して実行可能で、サンプルデータも同梱されている。

詳細はAgentic engineering intelligence with Amazon Nova Multimodal Embeddings and Amazon Bedrock AgentCoreを参照していただきたい。