SoftMatcha 2は、東京大学・国立情報学研究所・Sakana AIなど8機関の研究者が開発した、兆トークン規模のテキストコーパス向けの検索ツールです。語順を保ったまま、似た単語への置換と単語の挿入・削除を許す「柔らかい一致」で探し、1.4兆トークンのFineWeb-Eduでも検索の95%を0.3秒以内に返します。論文は2026年2月にarXivで公開され、ICML 2026に採録されました。この記事では、仕組みと性能の数値、公開デモで実際に検索した結果、手元で動かすコマンド、そして使うべきでない場面までを、論文とGitHubの記述に沿って整理します。
まとめ：SoftMatcha 2の要点
- 何をするか：「olympics gold medalist」で検索すると「olympic gold medallist」「olympics silver medalist」のような近い語の並びも、類似度順に件数付きで返す
- 速さ：1.4兆トークンでソフト検索の中央値89.59ms・p95 278.17ms。完全一致はp95 0.34msで、infini-gramの約33倍
- 仕組み：候補の完全一致確認1回あたりのランダムディスクアクセスを1回に抑える接尾辞配列と、コーパスにない候補を早めに捨てる動的枝刈りの2つ
- 試し方：公開デモで英語・日本語など7言語を検索できる。手元ではuvとRustでビルドし、softmatcha-index・softmatcha-searchの2コマンドで使う（Apache License 2.0）
- 使いどころ：学習データへのベンチマーク混入（汚染）の検査。完全一致の判定に36問を上乗せし、うち29問（81%）が本物の混入だった
- 限界：単語単位の置換なので「U.S.」と「United States」のような語数の違う言い換えは拾えない。文書の意味検索ならベクトル検索を選ぶ
SoftMatcha 2とは：語順を保ったまま言い換え・挿入・削除を許すコーパス検索
LLMの学習データに何が入っているかを調べるには、数兆トークンの中から特定のフレーズを探す必要があります。完全一致では「medalist」と「medallist」の綴り違いやカンマ1つの差で取りこぼします。一方、ベクトル検索は埋め込みモデルによって語順も表現できますが、語順の一致を検索条件として保証する方式ではありません。SoftMatcha 2はこの間を埋める検索で、クエリの各単語を単語埋め込みのコサイン類似度で近い語に置き換えたり、単語を足したり削ったりした並びを、コーパスに実在するものだけ列挙します。
開発体制と公開の経緯
著者はMasataka Yoneda（米田優峻）、Yusuke Matsushita、Go Kamoda、Kohei Suenaga、Takuya Akiba、Masaki Waga、Sho Yokoiの7名で、所属は東京大学・NII・京都大学・総合研究大学院大学・国立国語研究所・Sakana AI・東北大学・理化学研究所の8機関です（プロジェクトページ）。
- 2026年2月11日：arXiv 2602.10908で論文公開（2026年6月10日のv2でICML 2026採録を明記）
- 2026年3月：言語処理学会第32回年次大会で日本語版を発表（Q1-5）。LLM-jp-corpus-v3（約5,380億語）で中央値約0.05秒と報告
- 2026年7月8日：ソウルで開かれたICML 2026で発表（国立情報学研究所のお知らせ）
- 2026年9月29日：PMLR 306に収録
前身の初代SoftMatchaはICLR 2025の論文で、10億トークン規模を対象にしていました。SoftMatcha 2のコードはGitHubのsoftmatcha/softmatcha2でApache License 2.0として公開され、初代から引き継いだ一部のファイルはMIT Licenseです。
grep・infini-gram・Elasticsearch・ベクトル検索との違い
論文（v2）のTable 2は、既存の検索手法を6つの軸で並べています。「1兆で1秒以内」は約10トークンのクエリを1兆トークンから1秒以内に返せるかを示します。SoftMatcha 2だけが全項目を満たし、初代は速さと挿入・削除、infini-gramは語の類似を持ちません。
| 手法 | 索引 | 1兆で1秒以内 | 語の類似 | 挿入・削除 | 語順 | 全件列挙 |
|---|---|---|---|---|---|---|
| grep | × | × | × | ○ | ○ | ○ |
| infini-gram（接尾辞配列） | ○ | ○ | × | × | ○ | ○ |
| infini-gram mini（FM-index） | ○ | ○ | × | × | ○ | ○ |
| 初代SoftMatcha（転置索引） | ○ | × | ○ | × | ○ | ○ |
| Elasticsearch（BM25） | ○ | ○ | × | ○ | × | × |
| FAISS（ベクトル検索） | ○ | ○ | 話題の近さ | 話題の近さ | × | － |
| SoftMatcha 2 | ○ | ○ | ○ | ○ | ○ | ○ |
表のElasticsearchはBM25型の語彙検索としての評価で、製品全体の機能制限ではありません（語順を指定するフレーズ検索もあります）。ただし語彙検索は文書単位で「関連する」ものを返す仕組みで、フレーズの出現箇所を漏れなく数える用途には向きません（転置インデックスの考え方はElasticsearchとは？転置インデックスとシャード設計・ライセンス系列で決める採用可否で解説しています）。ベクトル検索で「AがBを上回る」と「BがAを上回る」をどの程度区別できるかは埋め込みモデルに依存し、語順の違いを必ず検索結果に反映できるとは限りません。違いの整理はベクトル検索とセマンティック検索の違い：目的と手段の関係・仕組みと日本語での実測が参考になります。
SoftMatcha 2の仕組み：接尾辞配列と動的枝刈り
ソフト検索は「クエリに似た単語列の候補を作る→コーパスにあるか完全一致で確かめる」の繰り返しです。候補はクエリが長いほど指数的に増えるので、(1)1回の確認を速くする、(2)確認する候補を減らす、の2点に手を入れています。
完全一致確認ごとのディスクアクセスを抑える接尾辞配列
1.4兆トークンの索引はRAMに載らないためSSDに置きます。素朴な接尾辞配列は二分探索のたびにディスクへランダムアクセスしますが、SoftMatcha 2は索引を段階に分け、完全一致1回あたりのランダムアクセスを1回に抑えました。完全一致のp95は0.34msで、infini-gramの11.05msより約33倍速く、2,730億トークンではinfini-gram mini（151.84ms）の475倍です。
索引は連長圧縮で40.0TBから5.6TBへ85.9%縮み、生テキストを含む全体は21.6TBです。論文はこれを生テキストを除くinfini-gramの索引9.9TBの約2.2倍としていますが、容量に含める範囲が異なる比較です。構築時間は53.8時間で、infini-gramの61.2時間より短く済んでいます。
類似度の定義と3種類の枝刈り
単語列どうしの類似度は、対応する単語の埋め込みのコサイン類似度から計算します。論文の例では、goldとbronzeが0.63、medalとmedalsが0.85のとき、「gold medal」と「bronze medals」は約0.62です。挿入・削除にはコストがかかり、theやofのような語は低いコストで足し引きできます。
- 反復枝刈り：先頭から1語ずつ伸ばし、コーパスに存在しない途中の並びはその時点で捨てる。これが無いとp95もp99も10秒超でタイムアウトする
- k-gram枝刈り：頻出語の2-gram・3-gramの有無をRAMの表で先に判定し、ディスクを読まずに捨てる
- 末尾ビット枝刈り：出現回数の少ない並びは、候補を伸ばす代わりに出現箇所を直接たどって照合する
3つを併用すると、完全一致の確認回数はクエリが1トークン伸びるごとに平均2.30倍の増加で済み、枝刈り無しの5.17倍から大きく下がります。論文はこれを、自然言語のn-gram頻度がべき乗則に従う性質から理論的にも説明しています。
SoftMatcha 2の性能：論文の実測値
実験環境はAWSのi4i.32xlarge（128 vCPU・RAM 1,024GB・NVMe SSD 30TB）です。主な性能値は、Gemini 3.0 Proで半自動生成した10トークン以下のクエリを英語400件・他言語各100件使い、上位20件を出力する設定で測っています。デモと同じ条件にそろえるため、各クエリの後にOSのページキャッシュは消していません。
| 測定 | コーパス | 結果 |
|---|---|---|
| ソフト検索 中央値 | FineWeb-Edu 1.4兆 | 89.59ms |
| ソフト検索 p95 | FineWeb-Edu 1.4兆 | 278.17ms |
| ソフト検索 p95 | C4日本語 1,690億・中国語 383億 | 400ms未満 |
| 完全一致 p95 | FineWeb-Edu 1.4兆 | 0.34ms（infini-gram 11.05ms） |
| 索引サイズ | FineWeb-Edu 1.4兆（6.7TB） | 21.6TB（生テキスト込み） |
| 索引構築 | FineWeb-Edu 1.4兆 | 53.8時間 |
初代SoftMatchaとは5億トークンまでほぼ同じ速さですが、10億トークンを超えると初代は遅延がほぼ線形に伸び、500億トークンを超えるコーパスはメモリ不足で扱えませんでした。初代をSSDから読むモードで動かすと、550億トークンでp95が169.89秒（SoftMatcha 2の688倍）です。数十億トークンを超えるコーパスを検索するなら、初代ではなくSoftMatcha 2を選ぶことになります。
なお、出力件数を80件に増やし、類似度の下限を0.2まで下げた設定では、中央値127.20msに対してp95は5,697.39msまで伸びます。「0.3秒」は既定に近い設定での値で、広く拾う設定にすると秒単位になると見込んでおくべきです。
公開デモで日本語と英語を検索した結果（2026年10月31日）
インストールせずに試すなら、SoftMatcha 2の公開デモが手早い方法です。デモが読み込むコーパス一覧のAPIを2026年10月31日に取得したところ、次の8コーパスが選べました。英語は論文の1.4兆トークンではなく、約1,517億トークン分です。
| 言語 | コーパス | トークン数 |
|---|---|---|
| 英語 | fineweb-edu（既定） | 151,681,365,491 |
| 日本語 | llm-jp-v3 (Ja.) | 102,915,908,354 |
| 日本語 | C4 (Ja./Small) | 2,141,608,812 |
| 中国語 | C4 (Chinese) | 2,241,352,794 |
| ドイツ語 | C4 (German) | 1,099,885,010 |
| イタリア語 | C4 (Italian) | 1,070,947,821 |
| フランス語 | C4 (French) | 978,329,061 |
| ロシア語 | C4 (Russian) | 1,006,500,018 |
同じ日に、デモの検索APIへ論文の例文を1回ずつ送りました。既定の設定は上位20件・類似度の下限0.45です。
- 日本語（llm-jp-v3）「大阪までの2時間半」：サーバー側の検索時間0.0708秒。1位は完全一致（2件）、2位「大阪 まで の 3 時間 半」93.0%、3位「大阪 まで 2 時間 半」84.1%（36件）と、助詞「の」の削除や数字の置換が並び、10位に「京都 まで の 2 時間 半」69.9%が入った
- 英語（fineweb-edu）「olympics gold medalist」：検索時間0.0506秒。完全一致は106件だが、3位の「olympic gold medalist」（86.4%）は10,642件あり、単数形の表記のほうが約100倍多く出現していた
英語の例が示すとおり、完全一致だけで「出現数」を数えると、表記の揺れ1つで桁が変わります。日本語はMeCabで分かち書きされるため、結果も「大阪 まで の」のように単語区切りで表示されます。デモのFAQには、Wi-Fi環境で検索画面が止まる事例があり、モバイル回線への切り替えで改善することがあると書かれています。
SoftMatcha 2を手元で動かす：インストールから検索まで
手順はGitHubのREADMEのQuick Startに沿っています。READMEはapt-getを使うため、Debian・Ubuntu系のLinuxが前提です。pyproject.tomlの要件はPython 3.10以上で、依存にPyTorch・gensim・fasttext・mecab-python3を含むため、ダウンロード量は大きくなります。
ビルドに必要なパッケージとコマンド
uv（Pythonのパッケージ管理）とRustを入れ、Rust製の検索部をmaturinでビルドします。初回だけ、以前の版がダウンロードした単語ベクトルのキャッシュを消す手順が入っています。READMEはリポジトリの取得を省いているため、下の例ではgit cloneとcdを足しています。
rm -rf ~/gensim-data/glove-wiki-gigaword-300
curl -LsSf https://astral.sh/uv/install.sh | sh
export PATH="$HOME/.local/bin:$PATH"
sudo apt-get update
sudo apt-get install -y build-essential python3.12-dev pkg-config libicu-dev git
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source ~/.cargo/env
git clone https://github.com/softmatcha/softmatcha2.git
cd softmatcha2
uv sync
uv run maturin develop --release --manifest-path rust/Cargo.tomlsoftmatcha-indexによる索引構築
コーパスは1つのテキストファイルとして渡します。READMEによると、索引のサイズは小さなコーパスで元テキストの約10倍、大きなコーパスでは3倍未満です。--mem_sizeは構築時、--mem_size_exは検索時に使うメモリ（MB）で、ソース上の既定値は500と100です。大きな--mem_size_exは読み込みを遅くするため、READMEは小さなコーパスでは100程度に抑えるよう勧めています。
uv run softmatcha-index --index corpus --mem_size=5000 --mem_size_ex=1000 corpus.txtsoftmatcha-searchによる検索とsoftmatcha-exactによる用例確認
--num_candidatesで出力件数（既定20）、--min_similarityで類似度の下限（既定0.45）、--max_runtimeで打ち切り秒数（既定10）を指定します。前の章の性能表のとおり、件数を増やし下限を下げるほど遅くなります。見つかった並びの前後の文脈（KWIC）はsoftmatcha-exactで確認します。
uv run softmatcha-search --index corpus --num_candidates=100 --min_similarity=0.2 --max_runtime=20 "olympics gold medalist"
uv run softmatcha-exact --index corpus --display=20 --padding=200 "olympics gold medalist"--display=20 --padding=200は、用例を最大20件、前後200バイトの文脈付きで出す指定です。
日本語コーパスで使う設定
英語以外は、索引構築と検索の両方で--backend=fasttextとモデル名を指定します。READMEに例があるのは日本語・中国語・フランス語・ドイツ語・イタリア語の5つです。論文では英語にGloVe、その他の言語にfastTextの単語ベクトルを使い、日本語の分かち書きはMeCabで行っています。
uv run softmatcha-index --index corpus --backend=fasttext --model=fasttext-ja-vectors corpus.txt
uv run softmatcha-search --index corpus --backend=fasttext --model=fasttext-ja-vectors "金メダル"SoftMatcha 2によるベンチマーク汚染の検出
LLMの評価用の問題文が学習データに含まれていると、点数が実力より高く出ます。論文はinfini-gram miniの方法にならい、問題文から長さ10トークンの連続部分列を1トークン刻みですべて切り出し、各断片に似た並びがFineWeb-Edu（1.4兆トークン）にあるかを調べました。類似度0.6以上の一致が見つかる断片の割合が80%以上の場合に、汚染ありと判定しています。対象はMMLU・MMLU-Pro・GPQA・GSM8K・MATH・HumanEval・ARC-Challengeの7つで、400問を超えるものは400問を抽出しています。
- 完全一致での判定：2,564問中338問（13.2%）が汚染
- SoftMatcha 2で追加された問題：36問（1.4%）
- 人手で確認した結果：29問（81%）が本物の汚染。うち18問はカンマの挿入などの意味的な汚染、11問は数値だけを差し替えたテンプレート流出
たとえばMMLUの「The difference between dc and ac in electric circuits is that in dc, charges flow」は、コーパスに「in」が1語抜けた形で出現していました。完全一致では見逃すこうした混入を、手で確認できる件数まで絞り込める点が実務上の利点です。評価データの作り方全体はLLM評価とは？指標・データセット設計・評価ツールの選び方を実装視点で解説【2026年版】で扱っています。
ただし、検出されなかったことは汚染が無い証拠にはなりません。単語単位の置換しか見ないため、語数の違う言い換えや翻訳された問題文は対象外です。報告書に書くなら「完全一致とSoftMatcha 2の両方で検出されなかった」という範囲にとどめます。
SoftMatcha 2を採用すべき場面と避けるべき場面
論文の限界の節と前の章までの数値から、選ぶ条件は次のように絞れます。
- 向いている：学習コーパスに特定のフレーズや評価問題が含まれるかの監査、表記揺れを含めた出現回数の集計、有害表現やバイアスの所在調査のように「語順を保った短い並び」の類似パターンと出現件数を調べたい場面
- 向いていない（語数の違う言い換え）：「U.S.」と「United States」のように複数語にまたがる言い換えは拾えない。単語ベクトルの和などで対応する案は、候補が増えすぎて低遅延を保てないとして今後の課題にされている
- 向いていない（文書の意味検索・RAG）：質問に関連する文書を探すなら、ベクトル検索やBM25を組み合わせる方式のほうが合う（ハイブリッド検索とは？RAGでBM25とベクトル検索を統合する仕組み・RRF・製品別の実装【2026年版】）
- 向いていない（頻繁に更新されるデータ）：索引はテキストファイル全体から構築する作りで、1.4兆トークンでは構築に53.8時間かかる。追加・削除が日常的に起きるログや社内文書の検索には使いにくい
- 規模の目安：資源はコーパスに比例し、1.4兆トークンでディスク21.6TBが必要になる。ワイルドカード検索にも未対応
数千万〜数十億トークンの自社コーパスを対象に、ファインチューニング前のデータ点検として使うのが現実的な入り方です。デモの日本語コーパスllm-jp-v3は、国立情報学研究所を中心とするLLM-jpが公開している学習コーパスで、同プロジェクトの最新モデルはLLM-jp-4とは？8B・32B-A3B・33Bと4.1の違い・性能・使い方【2026年10月】で紹介しています。学習データの点検を含めて社内で生成AIを使う仕組みを設計する場合は、生成AI導入支援でもご相談を受けています。
よくある質問
SoftMatcha 2とは何ですか？
兆トークン規模のテキストコーパスから、語順を保ったまま似た単語への置換や単語の挿入・削除を許して並びを探す検索ツールです。1.4兆トークンのFineWeb-Eduでp95 278.17msと報告されており、ICML 2026に採録されました。
SoftMatcha 2は無料で使えますか？
使えます。ソースコードはGitHubでApache License 2.0として公開されており、初代由来の一部ファイルはMIT Licenseです。公開デモも無料で使えますが、手元で大きなコーパスを扱うときはディスクとメモリを用意する必要があります。
SoftMatcha 2は日本語に対応していますか？
対応しています。fastTextの日本語ベクトル（fasttext-ja-vectors）を指定して索引を作り、検索時も同じ指定をします。公開デモでは約1,029億トークンのllm-jp-v3コーパスを検索でき、2026年10月31日に「大阪までの2時間半」を1回検索した際、APIが返したサーバー側の検索時間は0.0708秒でした。
初代SoftMatchaとの違いは何ですか？
初代（ICLR 2025）は転置索引を使い、置換には対応していたものの挿入・削除は扱えず、500億トークンを超えるとメモリ不足になりました。SoftMatcha 2は接尾辞配列と枝刈りで1.4兆トークンまで広げ、挿入・削除にも対応しています。
SoftMatcha 2はRAGのベクトル検索の代わりになりますか？
そのまま置き換える用途には向きません。論文では情報検索への応用も評価していますが、公開CLIは主に短い単語列の類似パターンと出現件数を調べるもので、質問に関連する文書を意味で探すRAGの検索とは目的が違います。学習データの監査やフレーズの出現頻度の集計に使い、文書検索にはベクトル検索やハイブリッド検索を使い分けます。
