--- title: "Cohere Embed 4（embed-v4.0）の仕様と使い方｜Embed 5との違い・Bedrock東京での実装" url: "https://www.issoh.co.jp/tech/details/6744/" published: 2025-05-14 updated: 2026-10-30 categories: ["LLM・RAG"] publisher: "株式会社一創" --- # 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モデル一覧](https://docs.cohere.com/docs/cohere-embed)と[Embed APIリファレンス](https://docs.cohere.com/reference/embed)の記載です。公開日は[Cohereのリリースノート](https://docs.cohere.com/changelog/embed-multimodal-v4)で2025年4月15日とされています。 | 項目 | embed-v4.0 | | ------- | -------------------------------------- | | 公開日 | 2025年4月15日 | | 入力 | テキスト／画像／テキストと画像の混在（PDFのページ等） | | コンテキスト長 | 128kトークン | | 出力次元 | 256／512／1024／1536（既定） | | 出力形式 | float／int8／uint8／binary／ubinary／base64 | | 類似度 | コサイン類似度・内積・ユークリッド距離 | | 1回の入力件数 | texts・inputsとも最大96件 | | 対応言語 | 100以上（日本語を含む） | 次元はMatryoshka方式で、1536次元のまま保存せず256次元に落としても使える学習がされています。前世代の `embed-multilingual-v3.0` はコンテキスト512トークン・1024次元固定だったため、長い文書を1本のベクトルにしたい用途ではv4.0との差が大きく出ます。画像を含む入力をベクトル化する考え方は[マルチモーダルの仕組みと業務応用を解説した記事](/tech/details/13444/)で整理しています。 ### 画像入力の画素上限とトークン換算 APIリファレンスでは、Embed v4.0以降は1リクエストの画像枚数に上限を設けず、画像の合計サイズを20MBまでとしています。[AWSのEmbed v4パラメータ解説](https://docs.aws.amazon.com/bedrock/latest/userguide/model-parameters-embed-v4.html)はさらに具体的で、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の書式と入力の制約が少しずつ違うので、ドキュメントを読むときはどのプラットフォームの記載かを確認します。 | 提供元 | モデルID | 主な違い | | ----------------- | ------------------------ | ------------------- | | Cohere API | embed-v4.0 | truncateはSTART／END | | Amazon Bedrock | cohere.embed-v4:0 | truncateはLEFT／RIGHT | | Bedrock Global推論 | global.cohere.embed-v4:0 | 処理リージョンが世界に広がる | | Microsoft Foundry | embed-v-4-0 | 画像は最大200万画素と記載 | | OCI生成AI | cohere.embed-v4.0 | 1ペイロードに画像1枚 | [BedrockのEmbed v4モデルカード](https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-cohere-embed-v4.html)では、リージョン内（In-Region）推論に対応するのは米国東部（バージニア北部）・欧州（アイルランド）・アジアパシフィック（東京）の3リージョンです。東京はIn-RegionとGlobalに対応し、地域単位のGeo推論（APAC）には対応していません。データを国内で処理したい場合は `cohere.embed-v4:0` を東京リージョンで呼び、`global.` 付きのIDは使いません。 [OCI生成AIのEmbed 4ページ](https://docs.oracle.com/en-us/iaas/Content/generative-ai/cohere-embed-4.htm)には、1ペイロードに含められる画像は1枚、画像の言語サポートは英語のみ、コンソールからは1回96件・各512トークンまでという制約が書かれています。Cohere APIの「枚数制限なし」と同じつもりで実装すると落ちます。OCIで使えるモデル全体と東京からの呼び出し方は[OCI生成AIのモデル・料金・東京からの使い方を解説した記事](/tech/details/3712/)にまとめています。 ## Embed 4とEmbed 5の違い（2026年9月30日公開） [CohereのEmbed 5リリースノート](https://docs.cohere.com/changelog/embed-v5)によると、Embed 5は品質重視のProと低遅延のFastの2本立てで、ProとFastは埋め込み空間を共有します。Proで作った索引をFastのクエリで検索できるため、Cohereは「索引はPro、クエリはFast」の構成を推奨しています。 | 項目 | embed-v4.0 | embed-v5.0-pro | embed-v5.0-fast | | --------------- | ---------- | -------------- | --------------- | | 公開日 | 2025-04-15 | 2026-09-30 | 2026-09-30 | | パラメータ数 | 記載なし | 約24億 | 約10億 | | 出力次元 | 256〜1536 | 256〜2048 | 256〜2048 | | 既定の次元 | 1536 | 2048 | 2048 | | コンテキスト長 | 128k | 128k | 128k | | ViDoRe V3平均 | 77.0 | 85.8 | 84.5 | | テキスト入力／100万トークン | 価格表に掲載なし | 0.12ドル | 0.08ドル | | 画像入力／100万トークン | 価格表に掲載なし | 0.40ドル | 0.40ドル | | Amazon Bedrock | あり（東京可） | なし | なし | ViDoRe V3の値は[Cohereの公式ブログ](https://cohere.com/blog/embed-5)に載っている自社評価（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の価格ページ](https://cohere.com/pricing)、画像単価は同じ公式ブログの表の値で、2026年10月30日時点でEmbed 4の単価は同ページに載っていません。Gemini側の単価と使い方は[Gemini Embedding 2の料金と使い方の記事](/tech/details/11341/)で比べられます。 ### 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](https://pypi.org/project/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` を指定します。検索の上位候補を並べ替える段まで含めるなら、[リランクモデルの種類と選び方を解説した記事](/tech/details/4413/)にある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の記事](/tech/details/10464/)が参考になります。Novaは東京リージョンで呼べないため、国内処理が条件ならEmbed 4が残ります。 ## 次元と精度の選び方：保存容量の試算 文書件数、更新頻度、検索回数、保存期間によっては、埋め込みのAPI料金よりベクトルの保存・検索費用が大きくなります。Embed 4の出力を1本保存するのに必要なバイト数と、100万チャンク分の容量を計算すると次のとおりです（索引構造やメタデータの分は含みません）。 | 次元と形式 | 1本あたり | 100万本 | | -------------- | -------- | ------ | | 1536次元 float32 | 6,144バイト | 約6.1GB | | 1024次元 int8 | 1,024バイト | 約1.0GB | | 512次元 int8 | 512バイト | 約0.5GB | | 256次元 binary | 32バイト | 約32MB | Cohereは公式ブログで、Embed 5について「int8はほぼfloatと同等の検索品質を保ち、多くの構成では1024次元のint8が性能と効率の釣り合う点」と推奨しています。Embed 4では1024次元int8を容量削減の候補とし、1536次元floatを基準に自社の評価用クエリで検索精度を比較してから採用します。binaryは1本32バイトまで縮む代わりに精度が落ちるので、binaryで候補を広く拾い、float等で並べ替える2段構成で使います。ベクトルDB側の検索方式との関係は[ベクトル検索とセマンティック検索の違いを整理した記事](/tech/details/9159/)で解説しています。 Cohere APIの128kトークンは入力1件あたりのコンテキスト上限であり、チャンクをその上限まで大きくすることを勧める値ではありません。AWSのドキュメントも「RAGでは小さなチャンクのほうが検索精度と費用の両面で有利なことが多い」と書いています。関連の薄い情報を1本のベクトルにまとめると、特定の一文を検索する精度が下がる場合があります。契約書の条項検索のように細部を引きたいなら数百〜千トークン、文書全体の類似度で束ねたいなら長めのチャンク、と用途で分けます。社内文書の検索基盤を設計から任せたい場合は、弊社の[RAG構築支援](/service/ai/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提供開始の告知](https://aws.amazon.com/about-aws/whats-new/2025/10/coheres-embed-v4-multimodal-embeddings-bedrock/)（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の仕組み・業務応用と実装判断を解説](/tech/details/13444/) - [ベクトル検索とセマンティック検索の違い：目的と手段の関係・仕組みと日本語での実測](/tech/details/9159/) - [Gemini Embedding 2の料金と使い方｜GA版の単価・1件あたりの実額と001からの移行【2026年10月】](/tech/details/11341/) - [Amazon Nova Multimodal Embeddingsとは？使い方・料金・次元の選び方とBedrockでの制約](/tech/details/10464/) - [リランクモデル（リランカー）とは？種類・2026年の代表モデルと選び方](/tech/details/4413/) --- 出典: [Cohere Embed 4（embed-v4.0）の仕様と使い方｜Embed 5との違い・Bedrock東京での実装]()（株式会社一創）