Cohere Embed 4（embed-v4.0）の仕様と使い方｜Embed 5との違い・Bedrock東京での実装

Cohere Embed 4は、Cohereが2025年4月15日に公開した埋め込みモデルで、APIで指定するモデルIDは embed-v4.0 です。テキスト・画像・テキストと画像が混在したPDFのページを1本のベクトルにでき、コンテキスト長は128kトークン、出力次元は256〜1536から選べます。2026年9月30日には後継のEmbed 5（embed-v5.0-pro／embed-v5.0-fast）が公開されましたが、Amazon BedrockのCohere埋め込みモデルは2026年10月30日時点でEmbed 4までで、東京リージョンで使えるのもEmbed 4です。この記事では、Embed 4の仕様、Cohere APIとBedrockでの呼び出し方、Embed 5へ移すかどうかの判断材料を、各社の公式ドキュメントの値で整理します。

まとめ：Embed 4の仕様とEmbed 5が出たあとの選び方

• モデルID：Cohere APIは embed-v4.0、Amazon Bedrockは cohere.embed-v4:0、OCI生成AIは cohere.embed-v4.0。呼び名が違うだけで同じモデルです。
• 仕様：128kトークン、出力次元256／512／1024／1536（既定1536）、出力形式はfloat・int8・uint8・binary・ubinary。1回のリクエストで入力は最大96件です。
• Embed 5との違い：Embed 5は次元が最大2048（既定2048）に増え、Cohereの自社評価ViDoRe V3でEmbed 4の77.0に対しPro 85.8。テキスト入力の単価はPro 0.12ドル、Fast 0.08ドル、画像入力は両モデルとも0.40ドル（各100万トークンあたり）です。
• 移行の判断：Bedrockで使っている、または索引を作り直す工数を取れないならEmbed 4のまま。図表の多い文書の検索精度が課題で、Cohere API・Microsoft Foundry・SageMakerのどれかを使え、自社の評価用クエリで改善を確認できた場合にEmbed 5へ移します。移行時は全件の再埋め込みが前提です。
• 提供状況：Cohereの廃止一覧（Deprecations）にEmbed 4は載っておらず、BedrockのモデルカードもLifecycleはActiveで終了日はN/Aです。

embed-v4.0の仕様一覧（Cohere公式の値）

仕様はCohereのEmbedモデル一覧とEmbed APIリファレンスの記載です。公開日はCohereのリリースノートで2025年4月15日とされています。

次元はMatryoshka方式で、1536次元のまま保存せず256次元に落としても使える学習がされています。前世代の embed-multilingual-v3.0 はコンテキスト512トークン・1024次元固定だったため、長い文書を1本のベクトルにしたい用途ではv4.0との差が大きく出ます。画像を含む入力をベクトル化する考え方はマルチモーダルの仕組みと業務応用を解説した記事で整理しています。

画像入力の画素上限とトークン換算

APIリファレンスでは、Embed v4.0以降は1リクエストの画像枚数に上限を設けず、画像の合計サイズを20MBまでとしています。AWSのEmbed v4パラメータ解説はさらに具体的で、2,458,624画素を超える画像はその画素数まで縮小、3,136画素未満は拡大され、画像1枚のトークン数は「画素数÷784×4」と書かれています。

この式に当てはめると、上限の2,458,624画素ちょうどの画像は12,544トークンです。A4のPDFページを解像度2倍（144dpi）で画像化すると1190×1684画素（約200万画素）で、縮小されずに約10,224トークンになります。テキストの課金とは桁が違うので、ページ画像を大量に埋め込む前に、この式で1ページあたりのトークン数を見積もっておくと請求額を読めます。

プラットフォーム別のモデルIDと制約の違い

Embed 4はCohere APIのほか、Amazon Bedrock・Microsoft Foundry・OCI生成AIでも提供されています。モデルIDの書式と入力の制約が少しずつ違うので、ドキュメントを読むときはどのプラットフォームの記載かを確認します。

BedrockのEmbed v4モデルカードでは、リージョン内（In-Region）推論に対応するのは米国東部（バージニア北部）・欧州（アイルランド）・アジアパシフィック（東京）の3リージョンです。東京はIn-RegionとGlobalに対応し、地域単位のGeo推論（APAC）には対応していません。データを国内で処理したい場合は cohere.embed-v4:0 を東京リージョンで呼び、global. 付きのIDは使いません。

OCI生成AIのEmbed 4ページには、1ペイロードに含められる画像は1枚、画像の言語サポートは英語のみ、コンソールからは1回96件・各512トークンまでという制約が書かれています。Cohere APIの「枚数制限なし」と同じつもりで実装すると落ちます。OCIで使えるモデル全体と東京からの呼び出し方はOCI生成AIのモデル・料金・東京からの使い方を解説した記事にまとめています。

Embed 4とEmbed 5の違い（2026年9月30日公開）

CohereのEmbed 5リリースノートによると、Embed 5は品質重視のProと低遅延のFastの2本立てで、ProとFastは埋め込み空間を共有します。Proで作った索引をFastのクエリで検索できるため、Cohereは「索引はPro、クエリはFast」の構成を推奨しています。

ViDoRe V3の値はCohereの公式ブログに載っている自社評価（RCP-nDCG@10）で、Embed 5 ProはEmbed 4より8.8ポイント高いとされています。ただし、これは解析済みテキストを用いて固定候補を並べ替える評価で、検索の第1段階における検索漏れや画像入力の性能を直接示す値ではありません。同じ評価でVoyage 4 Largeは83.7、Gemini Embedding 2は83.2です。PDFをテキスト化した文書の評価群でもPro 84.8・Fast 83.4に対しEmbed 4は78.6でした。どれもベンダー自身の測定なので、自社の文書で再現するかは確かめる必要があります。表のテキスト単価はCohereの価格ページ、画像単価は同じ公式ブログの表の値で、2026年10月30日時点でEmbed 4の単価は同ページに載っていません。Gemini側の単価と使い方はGemini Embedding 2の料金と使い方の記事で比べられます。

Embed 4を使い続ける条件とEmbed 5へ移す条件

Embed 4とEmbed 5のベクトルは混ぜられません。Cohereが空間の共有を明記しているのはEmbed 5のProとFastの間だけで、Embed 4との互換には触れていません。移行は「新しい索引を作って全文書を再埋め込みし、クエリ側も同時に切り替える」作業になります。OCIのドキュメントがEmbed 3からEmbed 4への移行で案内している手順（新しい次元の索引を別に作り、移入とテストが済んでから切り替える）が、そのまま参考になります。

• Embed 4のままにする：Amazon Bedrockで使っている（Embed 5はBedrockに無い）。東京リージョン内で処理を完結させる必要がある。索引が数千万件規模で、再埋め込みの費用と期間を今は取れない。
• Embed 5へ移す：スキャン文書・スライド・決算資料など図表の多いページで、検索漏れが実際に問題になっている。Cohere API・Microsoft Foundry・SageMakerのいずれかを使える。新規に索引を作る段階で、作り直しの費用がかからない。

出力形式にも差があります。Embed 5の発表で挙がっている形式はfloat・int8・binaryの3つで、Embed 4でuint8やubinaryを使って索引を作っている場合は、移行時にベクトルDB側の型設定も見直します。

Cohere APIの実装例（Python SDK 7.3.0）

Python SDKはPyPIのcohereで、2026年10月30日時点の最新は2026年10月21日公開の7.3.0（Python 3.10以上）です。pip install cohere==7.3.0 numpy pypdfium2 pillow boto3 で掲載例の依存パッケージを入れ、CohereのAPIキーを環境変数 CO_API_KEY に設定します。そのうえで、v2 APIのクライアント ClientV2 を使います。embed は model と input_type が必須で、input_type を省くと例外になります。

テキスト埋め込みと検索クエリの類似度計算

検索用途では、保存する文書を search_document、利用者の質問を search_query で埋め込みます。両方を同じ値にすると、モデルが想定する非対称な検索の形にならず精度が落ちます。

import os
import numpy as np
import cohere

co = cohere.ClientV2(api_key=os.environ["CO_API_KEY"])

docs = ["経費精算の締め日は毎月25日です。", "有給休暇は入社6か月後に10日付与されます。"]
doc_res = co.embed(
    model="embed-v4.0",
    input_type="search_document",
    texts=docs,
    output_dimension=1024,
    embedding_types=["float"],
)
q_res = co.embed(
    model="embed-v4.0",
    input_type="search_query",
    texts=["経費の締め切りはいつ？"],
    output_dimension=1024,
    embedding_types=["float"],
)

D = np.array(doc_res.embeddings.float)
q = np.array(q_res.embeddings.float[0])
scores = D @ q / (np.linalg.norm(D, axis=1) * np.linalg.norm(q))
print(docs[int(scores.argmax())], scores.round(3))

文書側とクエリ側で output_dimension を必ず揃えます。1024次元の索引に1536次元のクエリを投げると、ベクトルDBが次元不一致で弾きます。分類なら classification、クラスタリングなら clustering を指定します。検索の上位候補を並べ替える段まで含めるなら、リランクモデルの種類と選び方を解説した記事にあるCohere Rerankとの組み合わせが定番です。

PDFページ画像とメタデータの埋め込み

図表を含むページは、テキストを抜き出さずにページ画像のまま inputs に渡します。1件の content にファイル名やページ番号などのテキストと画像を並べると、1本のベクトルにまとまります。AWSのドキュメントは texts と images を同じリクエストに入れないよう求めており、テキストと画像を組み合わせるときは inputs を使います。

import base64
import pypdfium2 as pdfium

# 前節のcoを使用。実行前に12ページ以上あるPDFをこの名前で配置します。
pdf = pdfium.PdfDocument("kessan_2026q2.pdf")
pdf[11].render(scale=2).to_pil().save("page12.png")  # A4なら1190x1684画素

def to_data_url(path):
    with open(path, "rb") as f:
        b64 = base64.b64encode(f.read()).decode()
    return f"data:image/png;base64,{b64}"

res = co.embed(
    model="embed-v4.0",
    input_type="search_document",
    inputs=[{
        "content": [
            {"type": "text", "text": "2026年度 第2四半期 決算説明資料 p.12"},
            {"type": "image_url", "image_url": {"url": to_data_url("page12.png")}},
        ]
    }],
    output_dimension=1024,
    embedding_types=["int8"],
)
vec = res.embeddings.int8[0]  # 1024個の整数（-128〜127）

render(scale=2) は72dpiの2倍で描画する指定で、A4は約200万画素になり2,458,624画素の上限に収まります。scale=3 にすると約450万画素になり、API側で縮小されるうえにアップロード量だけが増えます。ページ画像は固定枚数で区切らず、画像の合計サイズを20MB以内、inputsの件数を96件以内に収めて分割します。

Amazon Bedrock東京リージョンの実装例

Bedrockではboto3の invoke_model にJSONを渡します。リクエストの項目名は input_type・texts・inputs・embedding_types・output_dimension とCohere APIに揃っていますが、truncate の値はCohere APIの START／END ではなく LEFT／RIGHT です。

import json
import boto3

client = boto3.client("bedrock-runtime", region_name="ap-northeast-1")
body = {
    "input_type": "search_query",
    "texts": ["経費の締め切りはいつ？"],
    "embedding_types": ["float"],
    "output_dimension": 1024,
}
resp = client.invoke_model(modelId="cohere.embed-v4:0", body=json.dumps(body))
out = json.loads(resp["body"].read())

emb = out["embeddings"]
vec = emb["float"][0] if isinstance(emb, dict) else emb[0]
print(len(vec))  # 1024

AWSのドキュメントでは、応答の embeddings はfloatだけを要求したときに配列、複数の形式を要求したときに形式名をキーにした辞書になると説明されています。一方で同じページのint8単独の例は辞書で返っているため、上のコードは両方の形を受けられるようにしています。Bedrockで使える他のマルチモーダル埋め込みと比べるなら、Amazon Nova Multimodal Embeddingsの記事が参考になります。Novaは東京リージョンで呼べないため、国内処理が条件ならEmbed 4が残ります。

次元と精度の選び方：保存容量の試算

文書件数、更新頻度、検索回数、保存期間によっては、埋め込みのAPI料金よりベクトルの保存・検索費用が大きくなります。Embed 4の出力を1本保存するのに必要なバイト数と、100万チャンク分の容量を計算すると次のとおりです（索引構造やメタデータの分は含みません）。

Cohereは公式ブログで、Embed 5について「int8はほぼfloatと同等の検索品質を保ち、多くの構成では1024次元のint8が性能と効率の釣り合う点」と推奨しています。Embed 4では1024次元int8を容量削減の候補とし、1536次元floatを基準に自社の評価用クエリで検索精度を比較してから採用します。binaryは1本32バイトまで縮む代わりに精度が落ちるので、binaryで候補を広く拾い、float等で並べ替える2段構成で使います。ベクトルDB側の検索方式との関係はベクトル検索とセマンティック検索の違いを整理した記事で解説しています。

Cohere APIの128kトークンは入力1件あたりのコンテキスト上限であり、チャンクをその上限まで大きくすることを勧める値ではありません。AWSのドキュメントも「RAGでは小さなチャンクのほうが検索精度と費用の両面で有利なことが多い」と書いています。関連の薄い情報を1本のベクトルにまとめると、特定の一文を検索する精度が下がる場合があります。契約書の条項検索のように細部を引きたいなら数百〜千トークン、文書全体の類似度で束ねたいなら長めのチャンク、と用途で分けます。社内文書の検索基盤を設計から任せたい場合は、弊社のRAG構築支援でも埋め込みモデルの選定から対応しています。

よくある質問

embed-v4.0とcohere.embed-v4:0は同じモデルですか？

同じモデルです。embed-v4.0 はCohere APIでのID、cohere.embed-v4:0 はAmazon BedrockでのID、embed-v-4-0 はMicrosoft Foundryのカタログ名です。「Embed 4」「Embed v4」も同じモデルの呼び名で、APIに「embed-4」と渡すとエラーになります。

Cohere Embed 4は日本語に対応していますか？

対応しています。Cohereは100以上の言語に対応すると公表しており、BedrockでのEmbed v4提供開始の告知（2025年10月2日）でも対応言語の例に日本語が挙がっています。ただしOCI生成AIでは画像入力の言語サポートが英語のみとされているため、日本語の文字を含む画像をOCI経由で扱う場合は自社データで精度を確かめます。

料金はいくらですか？無料で試せますか？

2026年10月30日時点のCohereの価格ページに載っているのはEmbed 5の単価で、テキスト入力は100万トークンあたりProが0.12ドル、Fastが0.08ドルです。画像入力は、公式ブログの表で両モデルとも0.40ドルとされています。Embed 4の単価は同ページから外れているため、請求単価はCohereのダッシュボードかBedrockの料金ページで確認してください。CohereのトライアルAPIキーは無料ですが、利用量に上限があります。

Embed 4の出力次元はいくつを選べばよいですか？

256・512・1024・1536（既定）から選べます。1024次元int8は、生のベクトル容量を1536次元float32の6分の1に減らせる評価候補です。検索精度が要件を満たすかは、自社の文書と評価用クエリで比較します。容量が厳しい場合は512次元や256次元のbinaryも比較し、必要な検索精度を維持できる設定を採用します。文書側とクエリ側の次元は必ず揃えます。

Embed 5に移行するとき再埋め込みは必要ですか？

必要です。Cohereが共有を明記しているのはEmbed 5のProとFastの埋め込み空間だけで、Embed 4のベクトルとEmbed 5のクエリを混ぜる使い方は前提にできません。新しい索引を別に作って全文書を埋め込み直し、検証が済んでからクエリ側をまとめて切り替えます。

関連記事

• マルチモーダルとは？複数データを扱うAIの仕組み・業務応用と実装判断を解説
• ベクトル検索とセマンティック検索の違い：目的と手段の関係・仕組みと日本語での実測
• Gemini Embedding 2の料金と使い方｜GA版の単価・1件あたりの実額と001からの移行【2026年10月】
• Amazon Nova Multimodal Embeddingsとは？使い方・料金・次元の選び方とBedrockでの制約
• リランクモデル（リランカー）とは？種類・2026年の代表モデルと選び方