Nova Multimodal EmbeddingsとAgentCoreで、仕様書、図表、写真、ウェブ情報を照合します。許容差の判定はコードで行い、技術者が最終判断する構成です。 画像の類似度と仕様への適合を分け、根拠の出所を残すことが焦点です。架空部品のサンプルを実際の承認プロセスへ移す際の検証が論点になります。 供給終了時の資料照合を支援する例 AWSは11月2日、航空宇宙部品の代替検討を支援するエージェント構成を公開しました。部品が供給終了や長納期になった際、仕様書や認定記録を横断して根拠を集める作業を扱います。従来の検索で拾いにくい図表や写真も対象です。Nova Multimodal Embeddingsによる検索に、AgentCoreとStrands Agents SDKを組み合わせています。前段の検索を、評価資料の下書きまでつなぐ実装例です。中心に置く原則は、技術者が判断し、システムは根拠をまとめることです。生成モデルが部品の代替を承認するものではありません。安全に関わる部品で、資料の収集と適否の決定を明確に分けた設計を示しています。 仕様と画像を別の根拠として扱う 構成は、計画を立てる役から、カタログ、評価、知識を扱う専門エージェントへ処理を渡します。複数の担当が動いた場合に、統括役が結果をまとめます。仕様への適合はPythonの許容差ルールで採点し、同じ入力なら同じ結果になるよう設計しています。一方、写真の類似度は埋め込みによる指標で、形状の違いを説明する補助情報です。見た目が近いことだけで適合としない点が特徴です。対象は、調達や設計変更の資料を作成する技術者と、その根拠を確認するレビュー担当と見られます。検索結果の出所を添え、仕様比較と説明文をたどれる形にする狙いがあります。文書検索と画像を入力する検索では経路も異なるため、アプリ側が問い合わせの種類を扱う必要があります。 架空の部品データから現場へ移す条件 サンプルの部品群は、架空のメーカーのリアクションホイールです。公開例が動くことは、実在部品の代替に十分な精度を証明したことにはなりません。実装を移す際は、仕様の単位や許容差、認定状態を正しく入力する体制が論点になります。原文は、メーカー名をファイル名や写真から推測せず、構造化データの値を使う規則も示しています。情報の取り違えを避けるための具体的な制約です。費用面では、複数のモデル呼び出しに加え、図表の埋め込みと検索用データの維持を考える必要があると見られます。専門役ごとに利用できる道具を絞り、出力の誤りが次の担当へ広がらないかを確認することも、運用へ移す前の評価対象になると考えられます。この準備も導入費用に含まれます。 監査用の記録と実際の承認を区別する 構成例は監査用の記録や、統合への影響を扱う文書の下書きを作ります。規格の条項に沿う記録を出す設計と、組織の認定や承認を得ることは別です。実務では原資料の版と取得時点を揃え、評価コードの条件をレビューできることが判断点になります。ウェブ上の供給状況も変化するため、出所と鮮度の確認が必要です。最終文書を誰が確認し、変更を承認するかまで含めて導入範囲を決めることが論点になります。承認責任を記録に残す設計も確認対象です。