--- title: "Microsoft Harrierとは？harrier-oss-v1の27b・0.6b・270mの違いと使い方" url: "https://www.issoh.co.jp/tech/details/11734/" published: 2026-04-10 updated: 2026-09-30 categories: ["LLM・RAG"] publisher: "株式会社一創" --- # Microsoft Harrierとは？harrier-oss-v1の27b・0.6b・270mの違いと使い方 Microsoft Harrier（harrier-oss-v1）は、MicrosoftのBingチームが公開した多言語のテキスト埋め込みモデルです。Hugging Faceへの登録は2026年3月30日、Bingブログでの発表は4月7日で、ライセンスはMITです。270m・0.6b・27bの3サイズがあり、27bは発表時点でMultilingual MTEB v2の1位でした。 この記事では、モデルカードとconfig.jsonから読める仕様、MTEB v2スコアの読み方、クエリに命令文を付ける使い方、270mと0.6bを日本語でCPU実行した結果を順に整理します。数値は2026年9月30日時点で取得したものです。 ## まとめ：harrier-oss-v1の要点 - **何か**：デコーダーオンリーのLLMを埋め込み専用に学習させたモデル群。最後のトークンの隠れ状態を取り出し、L2正規化して1本のベクトルにします。 - **サイズ**：270m（640次元・MTEB v2 66.5）、0.6b（1,024次元・69.0）、27b（5,376次元・74.3）。入力上限はいずれも32,768トークンです。 - **使い方の注意**：クエリ側に1文の命令文（Instruct）を付けます。文書側には付けません。付けないと性能が落ちると公式FAQが明記しています。 - **選び方**：まず0.6bで自社データを評価し、CPUや端末で回すなら270m、GPUを1枚占有できるなら27bを比較対象に加える順番を勧めます。直近30日のダウンロードも0.6bと270mで合計56万件を超え、27bは5,690件でした。 - **注意点**：参照した公式発表とモデルカードには、Harrier単独の論文へのリンクや学習データそのものの公開先は記載されていません。GGUFやONNXはコミュニティ変換版です。 ## Microsoft Harrierの正体：Bingチームの多言語埋め込みモデル Harrierは、検索エンジンBingを運営するチームが発表した埋め込みモデルです。発表記事の著者にはXiaolong Huang、Liang Wang、Furu Weiらが並びます。3人はMicrosoftの埋め込みモデルE5とE5-mistralの論文の共著者でもあり、発表記事はHarrierを、E5、Multilingual E5、E5-mistral、GritLMといった先行研究の上に作ったと位置づけています。 学習の説明は[Bingブログの発表記事（2026年4月7日）](https://blogs.bing.com/search/April-2026/Microsoft-Open-Sources-Industry-Leading-Embedding-Model)にあります。複数のソースから多言語のテキスト対を集め、GPT-5で合成データを大量に生成し、対照学習の事前学習用に20億件超の弱教師ありデータ、ファインチューニング用に1,000万件超の高品質データを用意しました。27bを先に学習し、それを教師にして270mと0.6bへ知識蒸留しています。ノイズの多いデータの除去には、LLMベースのリランカーを使ったとしています。 ### BERT系エンコーダーとの違い：デコーダーオンリーとラストトークンプーリング 従来の埋め込みモデルの多くは、BERTのような双方向エンコーダーでした。全トークンが前後の文脈を見られるので、\[CLS\]トークンや全トークンの平均を文のベクトルにできます。multilingual-e5-largeもこの系統で、入力上限は512トークンです。 Harrierは、GPT系と同じく前のトークンしか見ない因果的なアテンションを持つデコーダーです。27bと270mのconfig.jsonは `use_bidirectional_attention: false` のままで、双方向に作り替えてはいません。前方しか見ないため、文全体を見終えた最後のトークンの状態を文のベクトルにします。これがラストトークンプーリングです。Harrierのモデルカードは、3サイズとも入力上限を32,768トークンとしています。この上限は各モデルの設定・学習に依存し、デコーダー構造やラストトークンプーリングだけで決まるものではありません。 埋め込みモデル一般の仕組みと日本語モデルの選び方は[埋め込みモデルとは？仕組みと日本語モデルの選び方・RAG実装での判断基準](/tech/details/16044/)で、エンコーダーを2本並べるバイエンコーダと文対を一緒に読むクロスエンコーダの違いは[クロスエンコーダとは？バイエンコーダとの違いと精度・速度の判断基準](/tech/details/16051/)で解説しています。 ## 27b・0.6b・270mの仕様比較と選び方 [Hugging Faceの公式モデルカード](https://huggingface.co/microsoft/harrier-oss-v1-0.6b)の表に、各モデルのconfig.jsonとHugging FaceのAPIから取った値（2026年9月30日取得）を加えると次のとおりです。ベースのアーキテクチャはconfig.jsonの記載で、どの事前学習済み重みから始めたかはモデルカードに書かれていません。 | モデル | パラメータ | アーキテクチャ | 次元 | MTEB v2 | 重み(BF16) | DL(直近30日) | | ------------------- | ----- | --------------- | ----- | ------- | -------- | --------- | | harrier-oss-v1-270m | 2.68億 | Gemma3TextModel | 640 | 66.5 | 約0.54GB | 255,713 | | harrier-oss-v1-0.6b | 5.96億 | Qwen3Model | 1,024 | 69.0 | 約1.19GB | 307,287 | | harrier-oss-v1-27b | 270億 | Gemma3TextModel | 5,376 | 74.3 | 約54.0GB | 5,690 | 次元数はベクトルDBの容量に直結します。float32で保存するとベクトル本体は1本あたり270mが2.5KiB、0.6bが4KiB、27bが21KiBで、100万チャンクなら27bはベクトル本体だけで約21.5GBです（索引構造やメタデータは別にかかります）。モデルカードはMatryoshka型の次元削減に触れていないため、次元を切り詰めて使うなら自社の評価セットで精度を確かめてからにしてください。 ### 0.6bを基準にする理由と270mを選ぶ条件 0.6bは重みが約1.19GBで、GPUが無い環境でも動きます。MicrosoftのFoundryブログも2026年4月13日の紹介記事で0.6bを取り上げ、Microsoft Foundryにデプロイしたエンドポイントで英仏独日の社内文書を検索する例を示しています。迷ったらここから始めるのが妥当です。 270mを選ぶのは、CPUやエッジ端末で大量の文書を埋め込むときです。後述の実測では、約4,600トークンの長文を1本埋め込むのに270mは6.6秒、0.6bは約5,600トークンで33.9秒かかりました。スコア差は2.5ポイントなので、処理量が効く用途では270mが現実的です。 ### 27bを比較対象に入れる条件 27bの重みはBF16で約54GBあり、GPU上に全重みを置く場合は、重みに加えて推論時の作業領域も確保する必要があります。CPUへのオフロードや量子化を使う構成では必要なGPUメモリが変わります。74.3というスコアは魅力ですが、ダウンロード数は0.6bの2%に届きません。埋め込みは文書の追加や更新のたびに全件を計算し直すことがあるので、再索引の計算時間まで含めて0.6bとの差が見合うかで判断します。 ## MTEB v2スコア74.3の読み方 MTEB v2のスコアは、分類・検索・クラスタリング・文類似度・対訳マイニングなど131タスクの平均です。発表記事の表では、27bが74.3で、比較対象にした既存の最高値72.3を2.0ポイント上回りました。Borda Count（タスクごとの順位を点数化して合計する方式）の順位は27bが1位、0.6bが10位、270mが15位です。ただしこの順位は3月16日時点の仮の値で、今後の提出で変わりうると本文に注記があります。 商用APIとの比較も同じ記事に載っています。 | モデル | MTEB Multilingual 平均 | | ----------------------------- | -------------------- | | OpenAI text-embedding-3-large | 58.92 | | Amazon titan-embed-text-v2 | 60.37 | | harrier-oss-v1-270m | 66.55 | | Gemini Embedding 1 | 68.33 | | harrier-oss-v1-0.6b | 69.01 | | Gemini Embedding 2（マルチモーダル） | 69.9 | | harrier-oss-v1-27b | 74.27 | この表から言えるのは、多言語の平均では0.6bがOpenAIのtext-embedding-3-largeを約10ポイント上回るということまでです。Microsoft自身が作った表で、タスク別の内訳は示されていません。Gemini Embedding 2は画像や音声も扱うモデルなので、テキストだけの平均で比べても用途の優劣は決まりません。Gemini Embedding 2の料金と仕様は[Gemini Embedding 2とは？料金・仕様・OpenAI比較とマルチモーダルRAG実装を解説](/tech/details/11341/)にまとめています。 もう1つ押さえておきたいのが、学習データが非公開である点です。GPT-5で生成した合成データの中身が見えない以上、ベンチマークの問題に近い文が学習に混ざっていないかを第三者が確かめる方法はありません。1位という数字は候補を絞る材料に留め、採用の判断は自社データの検索精度で下すべきです。現在の順位は[MTEBリーダーボード](https://huggingface.co/spaces/mteb/leaderboard)で確認してください。 ## 使い方：Sentence TransformersとTransformersのコード いちばん短いのはSentence Transformersを使う方法です。モデルカードのコードを、日本語の例に置き換えました。 ``` from sentence_transformers import SentenceTransformer model = SentenceTransformer("microsoft/harrier-oss-v1-0.6b", model_kwargs={"dtype": "auto"}) queries = ["有給休暇は何日もらえる？"] documents = ["年次有給休暇は、入社6か月後に10日付与されます。"] # クエリ側だけに命令文を付ける（文書側は付けない） query_embeddings = model.encode(queries, prompt_name="web_search_query") document_embeddings = model.encode(documents) scores = (query_embeddings @ document_embeddings.T) * 100 print(scores.tolist()) ``` macOSでは、MPSが利用可能な環境でGPU（MPS）が自動選択されます。AMD Radeon Pro 5500Mを積んだIntel Macとtorch 2.2.2の組み合わせでは、BF16の重みをMPSへ載せる段階で「BFloat16 is not supported on MPS」となり止まりました。この場合は `SentenceTransformer(..., device="cpu")` のようにCPUを指定すると動きます。 Transformersで直接読み込む場合は、プーリングを自分で書きます。パディングが左寄せか右寄せかで最後のトークンの位置が変わるため、モデルカードの関数は両方に対応しています。 ``` import torch import torch.nn.functional as F from transformers import AutoTokenizer, AutoModel def last_token_pool(last_hidden_states, attention_mask): left_padding = (attention_mask[:, -1].sum() == attention_mask.shape[0]) if left_padding: return last_hidden_states[:, -1] sequence_lengths = attention_mask.sum(dim=1) - 1 batch_size = last_hidden_states.shape[0] return last_hidden_states[torch.arange(batch_size), sequence_lengths] name = "microsoft/harrier-oss-v1-0.6b" tokenizer = AutoTokenizer.from_pretrained(name) model = AutoModel.from_pretrained(name, dtype="auto").eval() task = "Given a web search query, retrieve relevant passages that answer the query" texts = [f"Instruct: {task}\nQuery: 有給休暇は何日もらえる？", "年次有給休暇は、入社6か月後に10日付与されます。"] batch = tokenizer(texts, max_length=32768, padding=True, truncation=True, return_tensors="pt") with torch.no_grad(): out = model(**batch) emb = F.normalize(last_token_pool(out.last_hidden_state, batch["attention_mask"]), p=2, dim=1) print((emb[:1] @ emb[1:].T) * 100) ``` ### クエリ側の命令文：3つのプリセットと自作 config\_sentence\_transformers.jsonには、次の3つのプロンプトが登録されています。いずれも「Instruct: 」で始まり、改行のあとに「Query: 」が続く形式です。 | prompt\_name | 命令文 | 用途 | | ------------------ | ----------------------------------------------------- | ------ | | web\_search\_query | Given a web search query, retrieve relevant passages… | 検索・RAG | | sts\_query | Retrieve semantically similar text | 類似文の検索 | | bitext\_query | Retrieve parallel sentences | 対訳の抽出 | 自作の命令文を使うときは、「Instruct: 」と命令文、改行、「Query: 」までを1つの文字列にして `prompt=` に渡します。`prompt=` は渡した文字列をそのまま先頭に付けるだけなので、命令文だけを渡すと学習時の形式から外れます。社内規程の検索なら `prompt="Instruct: Retrieve relevant internal documents that answer the question\nQuery: "` のように書きます。MTEBの131タスクそれぞれで使った命令文は、リポジトリのmteb\_v2\_eval\_prompts.jsonに公開されているので、近いタスクの文言を下敷きにするのが早道です。クエリ側の命令文だけを変える場合、文書側の埋め込み処理が同じなら索引の再計算は不要です。ただし検索順位は変わりうるため、評価セットで検索品質を確認してから切り替えます。 ## 日本語で動かした実測：270mと0.6bをCPUで比較 日本語の短い社内FAQを想定した架空の3質問・5文書で、L2正規化済みベクトルの内積（コサイン類似度）を100倍して比較しました。表の数値は正答率ではありません。文書は有給休暇・パスワード再設定・経費精算の日本語3本、有給休暇を英語で書いた1本、無関係な社員食堂の案内1本です。実行環境はIntel Core i9-9880H（8コア）のmacOS機で、推論はCPUのみ、Python 3.12.13、torch 2.2.2、transformers 4.57.6、sentence-transformers 5.7.0、float32です。 | 質問「有給休暇は何日もらえる？」 | 270m 命令あり | 270m 命令なし | 0.6b 命令あり | 0.6b 命令なし | | ---------------- | --------- | --------- | --------- | --------- | | 有給休暇（日本語・正解） | 61.6 | 63.3 | 66.8 | 67.5 | | 有給休暇（英語） | 47.1 | 46.2 | 49.9 | 49.4 | | 経費精算 | 44.4 | 48.1 | 46.7 | 51.4 | | 社員食堂 | 41.9 | 49.6 | 41.8 | 48.0 | | パスワード再設定 | 36.0 | 39.5 | 38.7 | 44.9 | 結果から読めることは3つあります。 - **正解の1位は変わらない**：3つの質問とも、命令文の有無にかかわらず正解の文書が1位でした。この規模のテストでは、命令文を付けない影響は1位の入れ替わりとしては出ません。 - **命令文を外すと無関係な文書が浮く**：命令文なしでは無関係な文書のスコアが軒並み上がり、英語で書いた同じ内容の文書が2位から3位へ落ちました。270mでは社員食堂の案内（49.6）が、0.6bでは経費精算（51.4）が英語版を追い越しています。今回の候補は5文書なので、上位5件を渡す場合は文書の集合は変わらず、順序だけが変わります。回答への影響は、このテストでは測っていません。 - **日英の言語をまたいで同じ内容を拾う**：命令文ありでは、日本語の質問に対して英語で書いた有給休暇の文書が、両モデルとも2位に入りました。言語をまたぐ検索を業務に使うなら、自社の文書で同じ確認をしてから採用してください。 処理時間は、3件の質問の埋め込みが270mで0.07秒、0.6bで0.29秒でした。長文1本は270mが4,642トークンで6.6秒、0.6bが5,641トークンで33.9秒です（トークナイザーが違うため同じ文章でもトークン数が変わります）。プロセスの最大メモリは270mが約2.0GB、0.6bが約2.7GBでした。CPUで長い文書を大量に埋め込む場合は、チャンク分割後の総処理時間と検索精度を比較してください。今回の実測では、分割あり・なしの速度差は測っていません。チャンクの大きさの決め方は[チャンクとトークンの違いとは？チャンク分割の手法とRAGのサイズ設計を日本語で実測](/tech/details/8016/)で解説しています。 ## 本番導入の論点：量子化・推論サーバー・Foundry・ライセンス ### GGUF・ONNX変換版の提供元と互換性 Microsoftが公開しているのはBF16のsafetensorsだけです。Hugging Faceには、onnx-community/harrier-oss-v1-0.6b-ONNX、mradermacher/harrier-oss-v1-0.6b-GGUF、Abiray/harrier-oss-v1-27b-GGUFなど第三者の変換版が登録されています。Ollamaの公式ライブラリには無く、個人のアカウントが上げた0.6bがあるだけです。量子化版はベクトルが元のモデルとずれるので、同じ索引に元のモデルと量子化版のベクトルを混ぜてはいけません。量子化形式の違いは[GGUFとは？量子化モデルフォーマットの仕組みとGPTQ・AWQとの違い・採用判断を解説](/tech/details/13788/)を参照してください。 ### 推論サーバーとMicrosoft Foundry Hugging FaceのText Embeddings Inferenceは、対応アーキテクチャにQwen3とGemma3を挙げています。ただし対応表のモデル一覧にHarrierの名前はありません。サーバー経由で出したベクトルが、Sentence Transformersで出したものと一致するかを数件で照合してから本番に載せてください。マネージドで使うなら、Microsoft Foundryのモデルカタログからデプロイできます。リージョンや課金はデプロイ画面で確認が必要です。 ### MITライセンスと確認しておきたい点 3サイズともMITライセンスで、商用利用や改変、再配布ができます。一方で、270mと27bはアーキテクチャがGemma 3系、0.6bはQwen3系で、どの事前学習済み重みから学習を始めたかはモデルカードに書かれていません。社内の法務審査で基盤モデルの利用条件まで問われる組織では、学習開始時の重みと適用条件を確認事項に入れてください。 ## Web IQとBing：発表後に明らかになったHarrierの使われ方 4月の発表記事は、Harrierと同じ技術で次世代のグラウンディングサービスを開発中で、Bingにも取り込むと予告していました。2026年6月2日、MicrosoftはAIエージェント向けの検索基盤「Web IQ」を発表します。その発表記事は、中核部品として「最高水準の埋め込みモデル」を挙げ、そこからHarrierの発表記事へリンクしています。同日公開のエンジニアリング記事にも「Harrier: Embedding as the geometry of the system」という節があり、検索でどの文書を近いと見なすかを決める部品として説明されています。 つまりHarrierは研究用の公開モデルではなく、Microsoftが自社の検索基盤に使う系統のモデルです。公開版と社内版の重みが同じかどうかまでは書かれていないため、「Web IQと同じ精度が出る」とは読まないでください。 ## Harrierを選ばないほうがよい場面 - **画像やPDFの見た目ごと検索したい**：Harrierはテキスト専用です。画像・音声・動画を同じベクトル空間に置くなら、Gemini Embedding 2のようなマルチモーダルモデルを選びます。 - **学習データの開示を監査要件にしている**：学習データそのものの開示が必須の審査では、公開情報だけで要件を満たすことはできません。 - **既存の索引が別モデルで数千万件ある**：モデルを替えると全件の再計算が必要です。切り替えは、自社データで測った検索品質の改善と、全件再計算・索引更新・運用変更の費用を比較して判断します。上位の並び替えだけならリランカーを足す手もあり、[リランクモデルとは？ベクトル検索と組み合わせる種類・仕組み・選び方](/tech/details/4413/)で比較しています。 ## よくある質問 ### Microsoft Harrierは無料で商用利用できますか？ できます。harrier-oss-v1の3サイズはMITライセンスで、商用利用・改変・再配布が認められています。自社サーバーで動かす限り、APIの利用料はかかりません。 ### harrier-oss-v1は日本語に対応していますか？ 対応しています。モデルカードの言語タグには日本語（ja）を含む93言語が並びます。日本語3問・5文書の小さなテストでは、270mと0.6bのどちらも正解の文書を1位に置き、英語で書いた同じ内容の文書も2位に拾いました。 ### harrier-oss-v1-0.6bはQwenがベースですか？ config.jsonのアーキテクチャはQwen3Modelです。270mと27bはGemma3TextModelです。どの学習済み重みから始めたかはモデルカードに書かれていないため、「Qwen3を微調整したもの」とは断定できません。 ### OpenAIのtext-embedding-3-largeより精度は高いですか？ Microsoftの発表記事の表では、MTEB Multilingualの平均がtext-embedding-3-largeの58.92に対して0.6bが69.01、27bが74.27です。多言語の平均では上回りますが、Microsoftが作成した比較で、タスク別の内訳は非公開です。自社データの評価で確かめてから切り替えてください。 ### クエリに命令文を付けないとどうなりますか？ 公式FAQは、学習時の形式と合わなくなり性能が落ちるとしています。日本語の小さなテストでは1位は変わりませんでしたが、無関係な文書のスコアが上がり、2位以下の並びが崩れました。文書側には命令文を付けません。 ## 関連記事 - [埋め込みモデルとは？仕組みと日本語モデルの選び方・RAG実装での判断基準【2026年版】](/tech/details/16044/) - [Gemini Embedding 2とは？料金・仕様・OpenAI比較とマルチモーダルRAG実装を解説](/tech/details/11341/) - [ベクトルデータベースとは？ベクトル化・インデックス構造・製品比較【2026年版】](/tech/details/7691/) - [チャンクとトークンの違いとは？チャンク分割の手法とRAGのサイズ設計を日本語で実測【2026年版】](/tech/details/8016/) - [リランクモデルとは？ベクトル検索と組み合わせる種類・仕組み・選び方【2026年版】](/tech/details/4413/) --- 出典: [Microsoft Harrierとは？harrier-oss-v1の27b・0.6b・270mの違いと使い方]()（株式会社一創）