Amazon Nova Multimodal Embeddingsとは？使い方・用途別設定・料金とBedrockでの制約

Amazon Nova Multimodal Embeddings（略称Nova MME、モデルID amazon.nova-2-multimodal-embeddings-v1:0）は、テキスト・画像・文書画像・動画・音声を1つのベクトル空間に埋め込むAmazon Bedrockの埋め込みモデルです。2025年10月28日に提供が始まりました。同じ空間に並ぶので、文章で動画の場面を探す、画像で似た商品を探すといったクロスモーダル検索が1モデルで組めます。一方で、提供リージョンはバージニア北部（us-east-1）とGovCloudだけで、東京リージョンでは提供されていません。この記事では、2026年10月31日時点の公式ドキュメント・技術レポート・料金データをもとに、仕様、embeddingPurpose と用途別の設定、次元ごとの精度、boto3の実装、料金、ナレッジベースでの制約、他モデルとの選び分けを整理します。Novaシリーズ全体の性能と料金はAmazon Nova 2世代のモデル比較で扱っています。

まとめ：Nova Multimodal Embeddingsの要点

• できること：テキスト・画像・文書画像・動画・音声を同じ空間に埋め込み、モダリティをまたいで類似検索できます。出力次元は3072・1024・384・256の4種類です。
• 最大の注意点：提供はus-east-1とus-gov-west-1のみで、クロスリージョン推論プロファイルもありません。データを国内で処理する要件があるなら採用できません。
• 設定の基本：索引を作る側は常に GENERIC_INDEX、検索クエリ側は探す対象に合わせて IMAGE_RETRIEVAL などに切り替えます。AWSの用途別ガイドは、商品画像・動画・音声に1024次元、スキャン文書に3072次元を挙げています。
• 次元と精度：技術レポートの表では、3072次元から1024次元に落としたときの低下は各評価で0.7〜1.1ポイントです。256次元まで落とすと文書画像検索で8.5ポイント下がります。
• 公表精度：Amazonの技術レポートでは、動画・音声・文書画像の検索で比較した他社モデルを上回ります。テキスト検索はTitan Text Embeddings V2より5.5ポイント高い一方、GoogleのGemini Embeddingより低い値です。日本語での評価値は公表されていません。
• 入力上限：同期の InvokeModel は動画・音声30秒まで、テキストは直接渡すと8,192文字までです。長いものは非同期の StartAsyncInvoke で分割して埋め込みます。
• 料金：テキスト100万トークン0.135ドル、画像1枚0.00006ドル、動画1秒0.0007ドル（us-east-1）。テキストだけならTitan Text Embeddings V2の6.75倍の単価です。
• 発話は検索できない：音声・動画を埋め込めても、話された言葉の中身は検索に効きません。会議録画やコールセンター音声は文字起こし（Bedrock Data Automation）を経由させます。

Nova Multimodal Embeddingsの仕様：モデルID・リージョン・入力上限

モデルIDと提供リージョン

モデルIDは amazon.nova-2-multimodal-embeddings-v1:0 です。IDには「nova-2」が入っており、2025年12月2日に公開されたNova 2.0の開発者ガイドでも、Nova 2 Lite・Nova 2 Sonicと並ぶモデルとして掲載されています。製品名は「Nova Multimodal Embeddings」で、名前に「2」は付きません。

Bedrockのモデルカードでは、利用できるリージョンはus-east-1（バージニア北部）とus-gov-west-1（GovCloud）の2つだけです。Geo（地域内）とGlobalのクロスリージョン推論もどちらも「Not supported」なので、jp. や global. の推論プロファイルで東京から呼ぶ方法もありません。東京リージョンのアプリから使うと、埋め込み対象の画像や文書は必ず米国のリージョンへ送られます。社内規程で処理地を国内に限っているなら、この時点で候補から外れます。

対応モダリティと入力上限

入力はテキスト、画像（PNG・JPEG・WebP・GIF）、音声（MP3・WAV・OGG）、動画（MP4・MOV・MKV・WebM・FLV・MPEG・MPG・WMV・3GP）です。1回のリクエストで渡せるのはこのうち1種類だけです。画像には detailLevel があり、写真は低解像度で処理する STANDARD_IMAGE、PDFのページ画像やスライドのように文字を読ませたいものは高解像度の DOCUMENT_IMAGE を指定します。動画は embeddingMode で、映像と音声を1本のベクトルにまとめる AUDIO_VIDEO_COMBINED か、別々の2本にする AUDIO_VIDEO_SEPARATE を選びます。

AWSの発表では、テキストは最大8Kトークン、最大200言語に対応します。上限は2段階で効きます。まず入力経路の制限として、リクエストに直接書く text.value は8,192文字まで、S3から渡す場合は同期で50,000文字までです。次に、トークン化した結果がモデルの上限を超えると truncationMode に従って切り捨てるか、エラーにします。S3経由にしてもモデルのトークン上限は変わらないので、1本のベクトルに収まらない長文は非同期APIの分割（maxLengthChars）で複数のベクトルにします。

同期の25MBはbase64に変換した後のサイズで、元ファイルは約33%膨らみます。元が19MBを超える画像はS3経由で渡すほうが確実です。各パラメータの定義はAWS公式のNova Embeddingsリクエスト・レスポンススキーマにまとまっています。

EOL下限日（2026年10月28日）を過ぎた後のライフサイクル

モデルカードには「EOL no sooner than: Oct 28, 2026」と書かれています。これは終了予定日ではなく、2026年9月7日より前に提供が始まったモデル向けの旧ライフサイクル規定が定める「提供開始から最低12か月」の下限です。この下限日を過ぎた2026年10月31日時点でも、モデルカードのステータスはActive、EOL日は「N/A」のままで、終了は告知されていません。

この下限日はEOLを迎えられる最も早い日付で、Legacy（終了予定）の告知が始まる日付ではありません。下限日を過ぎただけでは状態は変わらず、終了するときは先にLegacyへの移行が告知されます。Legacyに移ってからEOLまでは最低6か月あります。Legacyに入ると新規顧客は使えなくなり、既存顧客も15日間呼び出しがないとアクセスを失うことがあるので、告知を受けたらEOLを待たずに移行を始めます。旧規定では、Legacy入りから最低3か月後に「公開延長アクセス」の期間に入り、その間は料金が上がる場合があるとされているため、告知では日付と一緒に単価も確認します。埋め込みモデルは乗り換えると全データの埋め込みをやり直すため、モデルIDと次元数を設定ファイルに切り出し、再索引のジョブを最初から用意しておきます。状態はモデルカードのほか、GetFoundationModel APIの応答でも確認できます。

embeddingPurposeの使い分け：索引側とクエリ側の設定値

embeddingPurpose は、同じ入力でも用途に合わせて最適化した埋め込みを返すためのパラメータで、スキーマ上は必須です。検索用途では「索引を作る側」と「検索クエリを埋め込む側」で値を変えるのが基本です。

注意したいのは、IMAGE_RETRIEVAL と DOCUMENT_RETRIEVAL が索引側の detailLevel と対になっている点です。スキャンPDFを DOCUMENT_IMAGE で索引化したのに、クエリを IMAGE_RETRIEVAL で埋め込むと、ドキュメントが想定していない組み合わせになります。写真と文書画像を同じ索引に混ぜるなら、クエリ側は GENERIC_RETRIEVAL にそろえるほうが安全です。

CLASSIFICATION と CLUSTERING は、索引とクエリの組で使う検索用の値とは別系統です。AWS ML Blogの解説は、分類境界を分けやすいベクトルを返すのが前者、クラスタの中心を作りやすいベクトルを返すのが後者と説明しています。分類器を学習させる、素材をテーマごとに自動で束ねるといった、検索をしない処理で使います。AWS News Blogのサンプルの一部は索引側で embeddingPurpose を省略していますが、スキーマでは必須なので毎回明示してください。

用途別の設定：商品画像・スキャン文書・動画・音声

AWS ML BlogのA practical guide to Amazon Nova Multimodal Embeddings（2026年2月5日）は、4つの用途についてパラメータの組み合わせを示しています。索引側はどれも GENERIC_INDEX です。

文書だけ3072次元なのは、表やグラフを含むページの構造を細かく区別する必要があるからです。後述の技術レポートでも、次元を下げたときの落ち幅が最も大きいのは文書画像の検索でした。逆に、文字の少ない商品写真に DOCUMENT_IMAGE を指定しても検索品質が改善するかは、素材ごとの検証が必要で、単価は確実に10倍になります。AWSの用途別ガイドに従い、通常の商品写真は STANDARD_IMAGE にします。

商品の分類について、同ガイドは CLASSIFICATION を使う方法ではなく、新しい商品画像で似た商品を上位K件取り、そのカテゴリを多数決で決める方法を示しています。ラベル付きの商品が既にベクトルDBにあるなら、分類器を別に学習させずに済むこの方法から試すのが手早いです。テキスト文書の扱いは、図や表がないならPDFをページ画像にせずテキストを抽出して分割するよう書かれています。文字だけの文書をページ画像で埋め込むと1ページ0.0006ドルかかり、同じページを1,000トークンのテキストとして埋め込む場合（約0.000135ドル）の4倍以上になります。

この表に当てはまらない構成として、写真・文書・動画を1つの索引に混ぜる場合は、クエリ側を GENERIC_RETRIEVAL にします。研修動画のように映像と発話の両方を探したい素材は、この表の動画の設定だけでは足りません。理由はナレッジベースの章で説明します。

次元数の選び方：3072・1024・384・256

出力次元は3072・1024・384・256から選び、省略すると3072になります。4つの次元はMatryoshka表現学習（MRL）で学習されています。Amazon Scienceの技術レポートは、256次元のベクトルは3072次元のベクトルの先頭256個を取り出すだけで得られると説明し、次元ごとの検索スコアを表3に載せています。指標は動画・音声・画像がRecall@1・Recall@5・Recall@10の平均、文書画像がNDCG@5、テキストがNDCG@10です。異なる指標の数値を横断して比較することはできません。

3072次元から1024次元への低下は、どの評価でも0.7〜1.1ポイントに収まっています。3072次元から384次元への低下は2.6〜5.3ポイントです。256次元では、3072次元に比べて文書画像が8.5ポイント、DiDeMoが5.8ポイント下がります。容量を3分の1にして1ポイント前後の低下なら、多くの用途では1024次元が釣り合う点です。文書画像だけは低下が大きいので、AWSのガイドどおり3072次元を基本にします。

次元を決めるときに外せない制約が2つあります。1つは、異なる次元のベクトルは比較できないことです。索引を1024次元で作ったら、クエリも1024次元で埋め込みます。もう1つは、ベクトルストア側で次元を後から変えられないことです。たとえばAmazon S3 Vectorsのインデックスは、作成後に次元・距離関数を変更できず、作り直しになります。

ベクトル本体の容量はfloat32で「次元×4バイト」です。100万件なら3072次元で12,288,000,000バイト（約11.4GiB）、1024次元で約3.8GiB、256次元で約0.95GiBになります。S3 Vectorsの保存料金はus-east-1で1GBあたり月0.06ドルなので、ベクトル本体だけなら3072次元でも月約0.69ドルです。実際の課金にはキーとメタデータの容量も加わります。この規模なら、保存費だけを理由に次元を落とす必要はありません。差が出やすいのは、OpenSearchのようにベクトルをメモリに載せて検索する方式でのメモリ量と、検索レイテンシです。

次元を下げる方向と上げる方向では手間が違います。3072次元で生成しておけば、先頭を取り出すだけで1024次元にも256次元にもできるので、下げるときは再埋め込みが要らず、作り直すのはベクトルストアの索引だけです。一方、1024次元で生成したものを3072次元に上げるには全件の再埋め込みが必要です。切り詰めたベクトルと、APIで最初から1024次元を指定したベクトルは同じ索引に混ぜず、クエリも同じ手順で切り詰めてください。判断としては、3072次元で生成して原本をS3に残し、索引には1024次元を使う構成が手堅いです。

精度の公表値と自社データでの評価方法

技術レポートの表2（未取得の評価値に関する注記は2025年12月時点）は、各社の埋め込みモデルとNova MMEを、テキストを質問にした検索（テキスト・画像・文書・動画・音声を探す）で比べています。Gemini Embeddingの値はGoogleの公表値、それ以外の他社の値はNovaチームがBedrockまたは各社の公開APIで測った値です。指標は表3と同じです。

※「−」は原典で当該検索用途の比較対象外とされたセルで、入力モダリティ自体の非対応とは限りません。Marengo・Vertex AIはそれぞれTwelveLabs Marengo Embed、Google Vertex AIのマルチモーダル埋め込み。

Nova MMEがはっきり先行しているのは、動画・音声・文書画像の検索です。画像検索では、MSCOCOでMarengo 2.7（78.9）、TextCapsでMarengo 3.0（89.2）がわずかに上回り、首位ではありません。テキスト検索では、Titan Text Embeddings V2より5.5ポイント、Cohere Embed 4より2.2ポイント高い一方、GoogleのGemini Embedding（67.7）より3.9ポイント低い値です。動画や音声をテキストと同じ索引で探すならNova MMEを選ぶ理由になりますが、テキストだけの検索精度を最優先するなら、表の中では最も高いモデルではありません。

表の値はGemini Embeddingを除いてAmazonによる評価です。ViDoRe v2の質問は英語・フランス語・スペイン語・ドイツ語です。日本語での成績は示されていません。レポートは、200を超える言語のデータで学習したとしつつ、テキストと文書の用途では使う言語で自社テストをするよう勧めています。音声も、発話の認識に関する評価が限られていたため幅広いテストを勧めています。AWS AI Service Cardには、プログラミング言語では学習していないとの記述もあります。ソースコードの検索を主目的にするなら、コード向けの埋め込みモデルと比べてから決めてください。

初期評価では、社内の質問と正解の組を50〜100件用意する方法があります。用途・言語・モダリティごとの質問を含め、各質問の正解を1件と定め、その正解が上位5件に入る割合（この条件でのRecall@5）を、同じ検索条件（topK・距離関数・メタデータフィルタ）のまま比べます。初期評価では「Nova MMEの1024次元と3072次元」と「Nova MMEと現在使っているモデル」を比較します。既存モデルがない新規構築では、入力形式と処理リージョンの条件を満たす候補モデルを比較対象にします。日本語のテキストだけで差がなければ、単価が6.75分の1で東京でも使えるTitan Text Embeddings V2を選ぶ根拠になります。

Bedrockからの呼び出し手順（boto3）

前提として、us-east-1のBedrockコンソールでモデルを使える状態にし、IAMに bedrock:InvokeModel を付けます。非同期APIでは、モデルに加えて async-invoke リソースへの bedrock:InvokeModel と、状態確認用の bedrock:GetAsyncInvoke、入出力先S3の読み書き権限が要ります。ナレッジベースのサービスロールの公式ポリシー例も、この組み合わせで許可しています。以下はboto3による実装例です。実際のAWS環境での動作は確認していないので、使う前にスキーマの入力仕様、IAM権限、S3の入出力設定と照らし合わせてください。

同期InvokeModelによる画像・テキストの埋め込み

商品画像を索引用に埋め込み、文章のクエリで探す例です。画像はbase64文字列を source.bytes に入れます。

import base64
import json
import boto3

MODEL_ID = "amazon.nova-2-multimodal-embeddings-v1:0"
DIM = 1024  # 索引とクエリで同じ次元にそろえる
brt = boto3.client("bedrock-runtime", region_name="us-east-1")


def embed(purpose, **content):
    body = {
        "taskType": "SINGLE_EMBEDDING",
        "singleEmbeddingParams": {
            "embeddingPurpose": purpose,
            "embeddingDimension": DIM,
            **content,  # text / image / audio / video のどれか1つ
        },
    }
    res = brt.invoke_model(
        modelId=MODEL_ID,
        body=json.dumps(body),
        contentType="application/json",
        accept="application/json",
    )
    return json.loads(res["body"].read())["embeddings"][0]["embedding"]


# 索引側：商品画像は GENERIC_INDEX で埋め込む
with open("catalog/shoe-001.jpg", "rb") as f:
    img_vec = embed(
        "GENERIC_INDEX",
        image={
            "format": "jpeg",
            "detailLevel": "STANDARD_IMAGE",
            "source": {"bytes": base64.b64encode(f.read()).decode("utf-8")},
        },
    )

# クエリ側：画像だけの索引を文章で探すので IMAGE_RETRIEVAL
query_vec = embed(
    "IMAGE_RETRIEVAL",
    text={"truncationMode": "END", "value": "白いソールのランニングシューズ"},
)

truncationMode はテキストが上限を超えたときの扱いで、END は末尾を、START は先頭を切り捨てます。NONE にすると超過時にエラーになります。切り捨てが起きた場合は、レスポンスの truncatedCharLength に切った位置が入るので、ログに残しておくと検索漏れの原因を追えます。

非同期StartAsyncInvokeによる長尺動画の分割埋め込み

30秒を超える動画・音声と、分割したい長文は非同期APIを使います。入力はS3に置く必要があり、結果もS3に書き出されます。segmentationConfig.durationSeconds は1〜30秒（既定5秒）、テキストの maxLengthChars は800〜50,000文字（既定32,000文字）です。

import json
import time
import boto3

MODEL_ID = "amazon.nova-2-multimodal-embeddings-v1:0"
brt = boto3.client("bedrock-runtime", region_name="us-east-1")
s3 = boto3.client("s3", region_name="us-east-1")

job = brt.start_async_invoke(
    modelId=MODEL_ID,
    modelInput={
        "taskType": "SEGMENTED_EMBEDDING",
        "segmentedEmbeddingParams": {
            "embeddingPurpose": "GENERIC_INDEX",
            "embeddingDimension": 1024,
            "video": {
                "format": "mp4",
                "embeddingMode": "AUDIO_VIDEO_COMBINED",
                "source": {"s3Location": {"uri": "s3://my-media/seminar-2026.mp4"}},
                "segmentationConfig": {"durationSeconds": 10},
            },
        },
    },
    outputDataConfig={"s3OutputDataConfig": {"s3Uri": "s3://my-embeddings/out/"}},
)

while True:
    st = brt.get_async_invoke(invocationArn=job["invocationArn"])
    if st["status"] != "InProgress":
        break
    time.sleep(15)

if st["status"] != "Completed":
    raise RuntimeError(st.get("failureMessage"))

# 出力先（ジョブIDを含む）の segmented-embedding-result.json から各モダリティの jsonl をたどる
out = st["outputDataConfig"]["s3OutputDataConfig"]["s3Uri"]
bucket, prefix = out[len("s3://"):].split("/", 1)
key = prefix.rstrip("/") + "/segmented-embedding-result.json"
result = json.loads(s3.get_object(Bucket=bucket, Key=key)["Body"].read())

for r in result["embeddingResults"]:
    if r["status"] == "FAILURE":
        print(r["embeddingType"], r.get("failureReason"))
        continue
    b, k = r["outputFileUri"][len("s3://"):].split("/", 1)
    for line in s3.get_object(Bucket=b, Key=k)["Body"].read().decode().splitlines():
        seg = json.loads(line)
        meta = seg["segmentMetadata"]
        if seg["status"] != "SUCCESS":
            print("failed", meta["segmentIndex"], seg.get("failureReason"))
            continue
        print(meta["segmentIndex"], meta["segmentStartSeconds"], meta["segmentEndSeconds"])

各行の segmentStartSeconds と segmentEndSeconds を検索結果に持たせると、ヒットした場面へ動画プレーヤーを頭出しできます。失敗はセグメント単位でも返り、failureReason には RAI_VIOLATION_INPUT_IMAGE_DEFLECTION（入力がAIポリシーに抵触）や RATE_LIMIT_EXCEEDED が入ります。全体が PARTIAL_SUCCESS で終わることもあるので、成功件数を数えて欠けたセグメントを再投入する処理を入れておきます。2時間の動画を10秒刻みにすると720セグメントで、上限の1,434に収まります。5秒刻みでは1,440になり上限を超えるので、長尺は刻みを広げてください。

S3 Vectorsへの格納と類似検索

格納先にAmazon S3 Vectorsを使う例です。前の同期の例で作った img_vec と query_vec を使います。インデックスの次元は埋め込みの次元と必ず一致させます。S3 Vectors側の操作と料金はAmazon S3 Vectors APIの解説にまとめています。

import boto3

s3v = boto3.client("s3vectors", region_name="us-east-1")

s3v.create_vector_bucket(vectorBucketName="media-vectors")
s3v.create_index(
    vectorBucketName="media-vectors",
    indexName="nova-mme-1024",
    dataType="float32",
    dimension=1024,          # 作成後は変えられない＝埋め込みの次元と一致させる
    distanceMetric="cosine",
)

# 1回の put_vectors は500件まで
s3v.put_vectors(
    vectorBucketName="media-vectors",
    indexName="nova-mme-1024",
    vectors=[{
        "key": "shoe-001",
        "data": {"float32": img_vec},
        "metadata": {"modality": "image", "s3_uri": "s3://my-media/catalog/shoe-001.jpg"},
    }],
)

hits = s3v.query_vectors(
    vectorBucketName="media-vectors",
    indexName="nova-mme-1024",
    queryVector={"float32": query_vec},
    topK=5,
    returnDistance=True,
    returnMetadata=True,
)
for v in hits["vectors"]:
    print(v["key"], round(v["distance"], 4), v["metadata"]["modality"])

メタデータに元ファイルのS3 URIとモダリティを入れておくと、検索結果から元の画像や動画を取り出せます。S3 Vectorsは東京リージョンにもありますが、この例は埋め込みをus-east-1で生成する前提なので、ベクトルストアも同じus-east-1に置いて生成・格納・検索を1つのリージョンにそろえています。アプリ自体を東京で動かす場合は、アプリとus-east-1の間の通信は別に発生します。

料金：モダリティ別単価とバッチ割引

単価はモダリティごとに単位が違います。次の表はAWS Price List APIのAmazonBedrock（us-east-1）の値です（publicationDateが2026年10月30日のデータを10月31日に取得。usagetypeは USE1-NovaMultiModalEmbeddings-*）。最新の単価はAmazon Bedrockの料金ページで確認してください。バッチはBedrockのバッチ推論で処理した場合の単価です。

文書画像は写真の10倍の単価です。スキャンPDF1万ページなら6ドル、同じ枚数の商品写真なら0.6ドルです。動画は1,000時間（360万秒）で2,520ドル、バッチでも2,016ドルと、ほかのモダリティより桁が大きくなります。動画の費用は分割の刻みではなく秒数で決まるので、無音や静止画が続く区間を先に切り落とすほうが効きます。バッチの割引はテキストと標準画像が50%、文書画像・動画・音声が20%と分かれているため、「バッチなら半額」で動画の予算を組むと足りなくなります。

テキストだけの用途では割高です。Titan Text Embeddings V2は1,000トークン0.00002ドルで、Nova MMEはその6.75倍です。1億トークンを埋め込むとNova MMEは13.5ドル、Titan V2は2ドルになります。画像や動画を同じ索引で扱う予定がないなら、テキスト専用モデルのほうが安く、東京リージョンでも使えます。

Bedrock Knowledge Basesで使うときの制約

ナレッジベースから使う場合は、モデル単体よりも制約が増えます。Bedrockのナレッジベースそのものの構築手順はAmazon BedrockでRAGを実装する手順を参照してください。

使えるナレッジベースの種類とデータソース

• 画像・動画を直接埋め込めるのはベクトルストア型だけ：作成画面で「Knowledge Base with vector store」を選んだ場合に、マルチモーダル埋め込みモデルとして選べます。マネージド型ナレッジベースでも「カスタム埋め込み」の対応モデルにNova MMEが入っていますが、この方式は次元1024・float32固定のテキスト埋め込みとしての利用で、マネージドのリランカーも使えなくなります。マネージド型で画像・音声・動画を直接埋め込む「カスタムマルチモーダル埋め込み」で選べるのは、2026年10月31日時点でTwelveLabs Marengo Embed 3.0だけです。
• us-east-1のみ：Nova MMEを使うマルチモーダル処理は米国東部（バージニア北部）だけで提供されています。文字起こし側のBDAは、オレゴン・フランクフルト・ムンバイ・シドニーなど8リージョンにあります。
• データソースはS3が中心：マルチモーダル検索はS3データソースだけが対象で、Confluence・SharePoint・Salesforce・Webクローラーから取り込んだ画像や動画はスキップされます。カスタムデータソースはbase64で10MBまでのインライン投入に対応します。
• マルチモーダル保存先が必須：処理済みファイルを置くS3バケットを指定する必要があり、データソースとは別のバケットが推奨されています。一時データの削除漏れに備えて、transient_data のパスだけにライフサイクルルールを付けます。

パーサーの選び方：画像を画像のまま埋め込む条件

ナレッジベースでは、取り込み時にまず「パーサー（解析）」が走り、その出力が埋め込みモデルに渡ります。作成手順のページが挙げるパーサーは次の3つです。

画像の見た目で似たものを探したいなら、デフォルトパーサーを選びます。作成手順のページは、BDAパーサーとNova MMEを組み合わせるとBDAの処理が先に走り、画像・音声・動画のネイティブな埋め込みは作られないと注記しています。BDAの制約として「画像同士の類似検索はできない」とも書かれています。

その代わり、ネイティブに埋め込んだ場合は、回答を生成する RetrieveAndGenerate とリランクがテキストのコンテンツに限られます。画像のヒットは Retrieve で受け取ってアプリ側で表示する作りになります。チャットで「この図の内容を説明して」と答えさせたいなら、BDAで説明文にしたほうが RetrieveAndGenerate をそのまま使えます。どちらの検索結果が良いかは素材によるので、同じデータで2つのナレッジベースを作り、実際の質問で比べてから決めます。

発話を検索したい素材の扱い

最も見落とされやすいのが音声です。比較ページは「Nova Multimodal Embeddingsは音声・動画の発話内容を効果的に処理できない」と明記し、会議録画やサポート通話のように話の中身で検索したい素材にはBDAによる文字起こしを推奨しています。音声を埋め込めることと、話の中身で検索できることは別で、「解約の相談をしている通話」のような意味での検索には向きません。研修動画のように映像と発話の両方が大事な素材は、映像をNova MMEで、発話をBDAの文字起こしで、と2系統の索引に分ける構成が現実的です。図表や画像を含む文書のRAG全般の設計はマルチモーダルRAGの仕組みと実装方式の選び方で比較しています。

他の埋め込みモデルとの選び分け

Bedrockで選べる主な埋め込みモデルを、対応する入力と東京での利用可否で並べます。埋め込みモデル全般の選び方は埋め込みモデルの仕組みと選び方で解説しています。

※Amazon製モデルの単価はPrice List APIのus-east-1の値。リージョンと入力はBedrockのモデル別リージョン対応表と各モデルカード（2026年10月31日時点）。

Nova MMEを選ぶべきなのは、画像・動画・音声を文章と同じ索引で検索したく、データを米国で処理してよい場合です。Titan Multimodal Embeddings G1とは画像の単価が同じで、テキストはNova MMEのほうが約6分の1と安く、G1のテキスト入力は256トークンまでです。新規に画像検索を作るならNova MMEを優先します。G1が残るのは、テキストと画像を1回の入力で組み合わせて1本のベクトルにしたい場合（Nova MMEは1リクエスト1モダリティ）と、自社の画像とキャプションでファインチューニングしたい場合です。東京で画像も扱いたい場合の候補はCohere Embed v4で、Bedrockでの仕様と実装はCohere Embed 4（embed-v4.0）の仕様と使い方にまとめています。

逆に、次の条件のどれかに当てはまるならNova MMEは採用しません。データを国内で処理する必要がある（東京で使えるCohere Embed v4かTitan Text Embeddings V2にする）、テキストのみを扱い、Titan Text Embeddings V2が自社評価の品質基準を満たす（モデル選定では単価と検索品質を比較する）、話された内容で動画や音声を検索したい（BDAで文字起こしするか、発話を入力に含むMarengo Embed 3.0を検討する）。「マルチモーダルだから新しくて良い」で選ぶと、リージョンと単価で後から作り直しになります。社内の画像・文書・動画をまとめて検索させるRAGの構成から相談したい場合は、RAG構築支援でモデル選定と評価の設計から対応しています。

よくある質問

Nova MMEとは何の略ですか？

Amazon Nova Multimodal Embeddingsの略です。AWSの料金データ（Price List API）や技術レポートでもモデル名が「Nova MME」と表記されています。Bedrockでのモデル名は「Amazon Nova Multimodal Embeddings」です。

amazon.nova-2-multimodal-embeddings-v1:0 はNova 2の別モデルですか？

いいえ、同じモデルです。Nova Multimodal Embeddingsはこの1つのモデルIDで提供されています。AWSは命名の理由を説明していませんが、Nova 2.0の開発者ガイドではNova 2 Lite・Nova 2 Sonicと並ぶモデルとして掲載されています。別のモデルIDは、2026年10月31日時点のモデルカードに載っていません。

東京リージョンで使えますか？

使えません。2026年10月31日時点の提供リージョンはus-east-1とus-gov-west-1だけで、クロスリージョン推論プロファイルもありません。東京のアプリからは、us-east-1のエンドポイントを直接呼ぶことになります。

日本語のテキストに対応していますか？

日本語のテキストも入力できます。AWSは200を超える言語のデータで学習したと説明していますが、日本語を名指しした対応表や日本語での評価値は公表していません。技術レポートも、使う言語で自社テストをするよう勧めています。リクエストに直接書けるテキストは8,192文字までなので、長い日本語文書はS3に置くか、非同期APIで分割して埋め込みます。

1024次元と384次元ではどれくらい精度が違いますか？

技術レポートの表3では、1024次元から384次元に下げると、画像検索（MSCOCO）が75.6から72.9、テキスト検索（MTEB）が62.9から60.4、文書画像検索（ViDoRe v2）が57.7から53.4に下がります。上記3評価の差は2.5〜4.3ポイントなので、メモリ量が厳しい索引では384次元も候補になりますが、文書画像の検索では1024次元以上を使います。

関連記事

• Amazon Novaの性能と料金：Nova 2 Lite・Pro・2.5 Sonicのベンチマーク比較と選び方【2026年10月】
• 埋め込みモデルとは？仕組みと日本語モデルの選び方・RAG実装での判断基準【2026年版】
• マルチモーダルRAGとは？図表・画像を検索する仕組みと実装方式の選び方
• Amazon S3 Vectors APIとは？全21操作・boto3実装・東京の料金と事前フィルタを解説【2026年10月】
• Cohere Embed 4（embed-v4.0）の仕様と使い方｜Embed 5との違い・Bedrock東京での実装