1兆トークン超のコーパスを0.3秒以内で検索できるSoftMatcha 2の全体像

1兆トークン超のコーパスを0.3秒以内で検索できるSoftMatcha 2の全体像

大規模言語モデル（LLM）の学習データは年々巨大化しており、数兆トークン規模のコーパスを扱うことが当たり前になりつつあります。こうした膨大なテキストの中から特定のパターンを探し出す作業は、モデルの品質管理やバイアス検出、ベンチマーク汚染の検証において欠かせません。しかし従来の検索手法では、コーパスが兆単位に達すると検索速度が著しく低下するか、完全一致しか対応できないという制約がありました。SoftMatcha 2は、意味的な揺れを含むソフトマッチングを兆規模コーパスに対してサブ秒で実行するために設計された、新世代のパターン検索アルゴリズムです。

完全一致では見逃す言い換え・挿入・削除を0.3秒で捕捉するソフト検索の仕組み

従来のn-gramマッチングは表層の完全一致を前提としています。たとえば「olympics gold medalist」と検索した場合、「olympic gold medallist」のようなスペル違いや、「olympics silver medalist」のような意味的に近い表現は検索結果に含まれません。SoftMatcha 2はこの問題を、単語埋め込みに基づくコサイン類似度を使った「ソフトマッチ」で解決しています。

具体的には、クエリ中の各単語に対して意味的に近い候補をコーパスの統計に基づいて動的に列挙し、置換・挿入・削除の3種類の操作を許容しながらパターンを探索します。この仕組みにより、言い換えや表記揺れを含む一致を高速に検出でき、FineWeb-Edu（1.4兆トークン）に対しても0.3秒以内での検索を実現しています。完全一致だけに頼っていた従来のアプローチでは捕捉できなかった汚染パターンや有害表現の検出精度が、大幅に向上する点が最大の特徴です。

東京大学・Sakana AIなど8機関が共同開発した2026年2月公開の研究背景

SoftMatcha 2は、東京大学、国立情報学研究所（NII）、京都大学、総合研究大学院大学（SOKENDAI）、国立国語研究所（NINJAL）、Sakana AI、東北大学、理化学研究所（RIKEN）の8機関に所属する研究者が共同で開発しました。2026年2月にarXivでプレプリント論文が公開され、GitHubでソースコードがオープンソースとして公開されています。

主要な開発者は米田昌孝氏で、共著者には松下裕介氏、鴨田剛氏、末永幸平氏、秋葉拓哉氏、和賀正樹氏、横井翔氏が名を連ねています。前身となる初代SoftMatchaは2025年4月にICLR 2025で発表され、10億トークン規模のコーパスに対するソフト検索を実現していました。SoftMatcha 2はその成果を大幅に拡張し、1兆トークン超のコーパスへのスケールアップと、挿入・削除を含む可変長マッチへの対応を達成した次世代版です。

FineWeb-Edu 1.4兆トークンでの実証実験が示すサブ秒レイテンシの実測値

SoftMatcha 2の性能評価は、HuggingFaceが提供する教育コンテンツ特化型コーパスFineWeb-Edu（約1.4兆トークン）を用いて行われています。論文の実験結果によれば、ソフト検索のp95レイテンシ（95パーセンタイル値）が0.3秒以内であり、これは既存手法であるinfini-gram、infini-gram mini、初代SoftMatchaのいずれよりも大幅に低い値です。

さらに厳密検索（完全一致）においても、infini-gramに対して約33倍の高速化を達成しています。この速度は、ベンチマーク汚染の大規模な自動スキャンや、学習データ中の有害コンテンツ検出のように、数千〜数万のクエリを繰り返し実行する実務シナリオにおいて極めて重要な意味を持ちます。サブ秒の応答速度があるからこそ、研究者がインタラクティブにコーパスを探索し、仮説を検証するワークフローが現実的になるためです。

コーパスサイズが10倍に増えても検索時間がほぼ変わらないスケーラビリティ特性

SoftMatcha 2が特に高い評価を得ているのは、コーパスサイズの増加に対して検索時間がほぼ一定に保たれるスケーラビリティです。初代SoftMatchaでは1Bトークンを超えたあたりからレイテンシがほぼ線形に増加し、大規模コーパスへの適用が困難でした。一方、SoftMatcha 2はディスクアウェアな接尾辞配列設計と動的枝刈りの効果により、コーパスが10倍、100倍に膨張してもp95レイテンシの増加はごくわずかにとどまります。

この特性は、英語のFineWeb-Edu（1.4兆トークン）だけでなく、日本語のC4 Japanese（1,690億トークン）、中国語のC4 Chinese（383億トークン）でも一貫して確認されています。コーパスの規模が今後さらに拡大しても検索速度を維持できるこのスケーラビリティは、数兆〜数十兆トークン規模の次世代学習データに対応するうえで不可欠な性質といえます。

grepやベクトル検索では対応できない「n-gram粒度のソフトマッチ」という着眼点

テキスト検索の既存手法は大きく2つに分かれます。1つはgrepや正規表現による表層一致で、高速ですが言い換えや表記揺れに対応できません。もう1つは密ベクトル検索（dense vector search）で、意味的な類似性を扱えるものの、文書単位の粗い粒度での検索が中心であり、特定のn-gramレベルでの精密なマッチングには不向きです。

SoftMatcha 2は、この2つの手法の隙間を埋めるポジションに位置しています。n-gram単位の語順を保持しつつ、各単語の意味的近似を許容するという設計により、「このフレーズの言い換えがコーパス中に何件あるか」「この問題文と類似した表現がどこに存在するか」といった問いに直接的に回答できます。これはベンチマーク汚染検出のように、特定のテスト問題がわずかに書き換えられた状態で学習データに紛れ込んでいないかを調べるユースケースで、従来手法では達成できなかった精度を提供するものです。

接尾辞配列と動的枝刈りで組合せ爆発を抑えるSoftMatcha 2のコア技術

SoftMatcha 2の高速性を支えるのは、2つの核心的なアルゴリズム設計です。1つ目はディスクの物理特性を考慮した接尾辞配列（suffix array）の参照方式、2つ目はコーパス中の単語出現統計を利用した動的な枝刈り（pruning）です。ソフトマッチングではクエリの各単語に類似候補が複数存在するため、候補の組合せ数はクエリ長に対して指数関数的に増加します。この組合せ爆発をいかに抑制するかが、兆規模コーパスでのサブ秒検索を実現する鍵となっています。

ディスクアウェア設計でHDDの逐次読みを活かした接尾辞配列の高速参照方式

接尾辞配列は、コーパス中の全接尾辞を辞書順に並べた索引構造です。1990年にManberとMyersが接尾辞木の省スペース代替として提案したもので、部分文字列の出現位置を二分探索で高速に特定できるため、テキスト検索の基盤技術として広く利用されています。しかし兆トークン規模のコーパスでは、索引データ自体がメインメモリに収まらないため、ディスクからの読み込みが検索速度のボトルネックになります。

SoftMatcha 2のディスクアウェア設計は、HDDのランダムアクセスが遅く逐次読みが比較的速いという物理特性を正面から受け入れた索引レイアウトです。スパースインデックスをRAM上に保持しつつ、詳細なデータはディスク上に配置し、アクセス順序を最適化することで同じ接尾辞配列でも体感性能を大きく改善しています。この設計により、GPU不要のCPU環境でも兆規模コーパスに対するサブ秒検索が可能になっている点は、高価なGPUクラスタを前提とする手法と比較して導入障壁が格段に低いという実務上の利点につながります。

クエリ長に対して指数的に膨張する検索空間を自然言語の統計特性で抑制する理論的根拠

ソフトマッチングでは、クエリ中の各トークンに対して意味的に近い単語が複数候補として列挙されるため、クエリがN語であれば候補の組合せは理論上指数的に膨張します。たとえば各語に10個の類似候補がある3語のクエリでは、探索すべきパターンは最大1,000通りにもなり、5語に増えれば10万通り、クエリが長くなるほど爆発的に増大します。

SoftMatcha 2は、自然言語の統計特性を利用してこの組合せ爆発を理論的に抑制できることを証明しています。具体的には、自然言語のコーパスにおいて大部分の単語組合せは実際には出現しないというZipf則に基づく偏りを活用し、コーパス中に存在しない組合せを早期に枝刈りすることで、実効的な探索空間をクエリ長に対してサブ指数的に抑えることが可能です。この理論的保証があるからこそ、10トークン以上の長いクエリでもタイムアウトせずに安定した検索性能を維持できる設計となっています。

コサイン類似度ベースの単語埋め込みで置換候補を絞り込むスコアリング設計

SoftMatcha 2では、クエリ中の各単語に対する置換候補の選定にコサイン類似度を用いています。英語ではGloVe（Global Vectors for Word Representation）、日本語・中国語などではfastTextの単語ベクトルが利用されており、2つの単語ベクトル間のコサイン距離が類似度スコアとして算出されます。

初代SoftMatchaでは、最も類似度が高い1語だけを候補とするハード選択方式を採用していましたが、SoftMatcha 2ではユーザーが指定する類似度閾値（min_similarity）以上のすべての単語を候補として列挙するソフト選択方式に変更されています。この変更により、「olympics gold medalist」と「olympics silver medalist」のように類似度の異なる複数のバリエーションをスコア付きで検出できるようになりました。スコアリング結果はランキング形式で出力され、各マッチの類似度とコーパス中の出現回数が確認できます。

k-gram枝刈りと高頻度語の事前チェックによる実行時ルックアップ回数の削減手法

動的枝刈りに加えて、SoftMatcha 2はk-gram枝刈りと高頻度語の事前チェックという2つの補助的な最適化手法を実装しています。k-gram枝刈りでは、高頻度語のみで構成される2-gramおよび3-gramについて、コーパス中に実在するかどうかを事前にRAMに保持しておき、実行時に不要なルックアップを省略します。高頻度語同士の組合せは候補数が膨大になりやすく、ルックアップコストが支配的となるため、この事前チェックの効果は特に顕著です。

論文中の実験では、これらの枝刈り技法を有効化した場合と無効化した場合で、厳密文字列マッチングのルックアップ回数に大きな差が生じることが確認されています。特にFineWeb-Edu全体（1.4兆トークン）において、枝刈りなしではタイムアウト（10秒制限）が頻発するクエリでも、枝刈りを有効にすることで安定してサブ秒の応答が得られるようになります。この実行時ルックアップの削減は、ソフト検索の実用性を支える重要な要素です。

GloVeとfastTextを使い分ける英語・日本語・中国語など多言語対応の埋め込み戦略

SoftMatcha 2は7言語（英語、日本語、中国語、ドイツ語、イタリア語、フランス語、ラテン語）でのコーパス検索に対応しています。多言語対応のポイントは、言語ごとに最適な単語埋め込みモデルを選択できるバックエンド切り替え設計にあります。英語ではGloVe（glove-wiki-gigaword-300）がデフォルトで使用され、その他の言語ではfastTextの各言語対応ベクトルが利用されます。

fastTextは文字n-gramを内部的に活用するため、日本語のように形態素が豊富な言語や、ラテン語のように活用変化が複雑な言語でも未知語に対する表現を生成可能です。この埋め込み戦略の柔軟性により、英語圏に限定されない多言語コーパスの分析ニーズに対応できる点が、infini-gramやinfini-gram miniにはない独自の強みとなっています。インデックス構築時に--backend=fasttext --model=fasttext-ja-vectorsのようにオプションを指定するだけで、言語に応じた埋め込みモデルが自動的に適用されます。

infini-gramや初代SoftMatchaと比較して見えるSoftMatcha 2の優位性と制約

SoftMatcha 2の性能を正しく理解するには、既存の大規模コーパス検索ツールとの比較が欠かせません。主な比較対象はinfini-gram（2024年公開）、infini-gram mini（EMNLP 2025 Best Paper）、そして初代SoftMatcha（ICLR 2025）の3つです。それぞれが接尾辞配列やFM-indexをベースとした高速検索を提供していますが、対応するコーパス規模、検索の柔軟性、索引のサイズとトレードオフが異なります。

厳密検索で33倍高速かつソフト検索も可能という既存3手法との検索速度比較

SoftMatcha 2は厳密検索（完全一致）においてinfini-gramの約33倍のスループットを達成しています。加えて、infini-gramとinfini-gram miniが厳密一致のみをサポートするのに対して、SoftMatcha 2は意味的な類似を含むソフト検索も実行でき、しかもそのソフト検索でさえ0.3秒以内に完了します。

この比較表が示すとおり、ソフト検索、可変長マッチ、兆規模コーパスへの安定対応、多言語サポートの4要素すべてを満たすのはSoftMatcha 2のみです。研究目的でコーパスの意味的な探索が必要な場合に、現時点で最も機能的な選択肢といえます。

初代SoftMatchaが1Bトークン超で線形に遅延増加する問題を解消したスケール耐性

初代SoftMatchaはICLR 2025で発表された画期的なツールでしたが、スケーラビリティに明確な課題を抱えていました。英語Wikipediaのサブセット実験では、コーパスサイズが10億トークンを超えたあたりからレイテンシがほぼ線形に増加し、数十億トークン規模になるとインデックス構築自体がメモリ不足やタイムアウトで失敗するケースが報告されています。

SoftMatcha 2では、ディスクアウェア設計によりインデックスの大部分をディスク上に保持できるため、メモリ消費が大幅に抑えられています。加えて動的枝刈りの効果により、コーパスが1,000億トークンから1.4兆トークンに増加してもレイテンシの中央値にほとんど変化がないことが実験で確認されています。日本語コーパス（C4 Japanese、1,690億トークン）でもこのスケール耐性は一貫して再現されており、初代からの最も顕著な技術的進化のひとつです。

infini-gram miniのFM-indexと接尾辞配列ベースの索引サイズ・構築時間の差異

infini-gram miniはEMNLP 2025のBest Paperに選出された手法で、FM-index（Burrows-Wheeler変換に基づく圧縮索引）を採用しています。FM-indexの最大の利点はストレージ効率で、元テキストの約44%のサイズで索引を構築でき、元のinfini-gramの接尾辞配列（約6倍のストレージ乗数）と比較すると約7%にまで圧縮されると報告されています。一方、SoftMatcha 2の接尾辞配列ベースのインデックスは、小規模コーパスで約10倍、大規模コーパスでも3倍未満のサイズとなります。

ただしinfini-gram miniは、1.4兆トークン規模のFineWeb-Eduに対してインデックス構築でタイムアウトやエラーが発生するケースが報告されており、実用上のスケール上限が存在します。SoftMatcha 2はストレージ効率では劣るものの、兆規模での安定した構築と検索速度、さらにソフト検索機能を備えている点で用途の幅が広くなっています。研究者は目的に応じて、ストレージ効率を優先するかソフト検索を優先するかでツールを選択する必要があります。

可変長マッチに非対応だった初代の制約を克服し挿入・削除を扱える拡張範囲

初代SoftMatchaはクエリと同じトークン数の系列に対する置換のみを許容するソフトマッチでした。つまり「machine learning」（2語）で検索した場合、結果も必ず2語の系列でなければならず、「importance of machine learning」（4語）のように語数が異なる表現はマッチしません。この制約は、自然言語における挿入（単語の追加）や削除（省略）を捕捉できないという実用上の問題を意味していました。

SoftMatcha 2は置換に加えて挿入と削除の操作をサポートする可変長マッチを実現しています。論文の実験例では、「importance of machine learning」のようにクエリよりもトークン数が多い系列や、逆に短い系列もマッチ結果に含まれることが確認されています。この拡張により、ベンチマーク汚染の検出精度が向上し、単純な言い換えだけでなく文構造の微妙な変化も捕捉可能になりました。

単語レベル埋め込みに依存するため文全体の意味変形は検出困難という現時点の限界

SoftMatcha 2の制約として、論文著者自身が明示的に指摘しているのが、単語レベルの埋め込みに依存している点です。コサイン類似度はあくまで個々の単語間の意味的距離を測定するものであり、文全体の論理構造が変化するような大規模な言い換えや、長距離の推論を伴う同値変形は検出が困難です。

たとえば「The cat sat on the mat」と「A feline was resting on the rug」は人間には同じ意味だと容易に判断できますが、語彙レベルでの類似度だけでは捕捉しきれないケースがあります。論文では、より洗練された構成的意味論（compositional semantics）を取り入れることが今後の研究方向として挙げられています。現時点では、SoftMatcha 2の結果を「見つかれば汚染の強い証拠、見つからなくても汚染がないとは断定できない」という位置づけで活用することが推奨されます。

ベンチマーク汚染検出やコーパス言語学に広がるSoftMatcha 2の実務活用法

SoftMatcha 2の最も注目される応用先は、LLMのベンチマーク汚染検出です。モデル評価に用いるテスト問題が学習データに含まれてしまうベンチマーク汚染は、モデル性能の信頼性を根本から揺るがす問題であり、完全一致検索だけでは見逃される巧妙な汚染パターンを検出する手段として、SoftMatcha 2のソフト検索機能が実際の研究に活用され始めています。

FineWeb-Eduで完全一致が見逃した36件の汚染を追加検出しうち81%が真の汚染

SoftMatcha 2の論文では、FineWeb-Edu（1.4兆トークン）を対象に7つのベンチマークの汚染検出実験が実施されています。標準的な完全一致検索では、2,564サンプル中338件（13.2%）が「ダーティ」として検出されました。SoftMatcha 2のソフト検索は、完全一致では見逃された追加36件（1.4%）を新たに検出しています。この数値は全体の母数に対して小さく見えますが、評価の信頼性に影響する汚染が1件でも存在すればベンチマークスコアの解釈に疑義が生じるため、追加検出の意義は数の大小にとどまりません。

重要なのは、この追加検出分に対して手動検証が行われている点です。検証の結果、追加検出された36件のうち約81%が真の汚染（意味的言い換えまたはテンプレート漏洩）であることが確認されました。残りの約19%は偽陽性（false positive）でしたが、この精度は実運用において十分に実用的な水準です。完全一致だけに頼る検査では、学習データ中の巧妙な汚染を見逃し続けるリスクがあることを、この実験結果は明確に示しています。

ARC・HellaSwag・MMLUなど7ベンチマークを対象にした10トークン刻みの検査手法

論文の汚染検出実験では、ARC（AI2 Reasoning Challenge）、HellaSwag、MMLU、SocialIQA、OpenBookQA、SQuAD、AGIEvalの7つのベンチマークが対象とされました。質問と解答で構成されるベンチマークについては質問パートのみをパターンとして使用し、10トークン刻みの部分文字列を抽出して検索クエリとしています。

この10トークンのストライドは、infini-gram miniの50文字刻みとは異なるアプローチです。トークン単位で刻むことで、サブワードの境界に依存しない一貫性のある検査が可能になります。各サンプルにおいて最大類似度が0.6以上であれば「ダーティ」と判定し、類似度が1.0未満（完全一致ではない）のケースをソフト検索による追加検出と分類しています。400サンプルを超えるデータセットではランダムサンプリングにより評価規模を調整している点も、大規模実験の設計として参考になります。

テンプレート漏洩と意味的言い換えを区別する手動検証プロセスの判断基準

SoftMatcha 2のソフト検索で追加検出された汚染候補に対しては、3分類の手動検証プロセスが適用されます。第1の分類は「意味的汚染（semantic contamination）」で、テスト問題の内容が言い換えられた形でコーパス中に存在するケースです。第2は「テンプレート漏洩（template leakage）」で、問題文の構造やフォーマットがそのまま流出しているケースを指します。第3は「偽陽性（false positive）」で、類似度は高いが実際には汚染ではないケースです。

この3分類の判断基準は、単に表面的な一致度だけでなく、テスト問題の正解に影響を与えうる情報がコーパス中に存在するかどうかを基準としています。たとえば問題文の一部が百科事典的な記述として自然に出現している場合は偽陽性と判断され、一方で問題文と選択肢がセットでリフレーズされていれば意味的汚染と分類されます。この手動検証の存在が、SoftMatcha 2の汚染検出結果に高い信頼性を与えています。

ラテン語の複雑な活用変化を一括検索できるコーパス言語学への応用実績

SoftMatcha 2はNLP研究だけでなく、コーパス言語学の分野でも応用可能性が示されています。初代SoftMatchaの論文では、ラテン語を対象にした実験が行われました。ラテン語は名詞・動詞・形容詞のいずれも複雑な語形変化（活用・曲用）を持つため、特定の語彙をコーパスから網羅的に検索するには、すべての活用形を手動でリストアップし個別に検索する必要がありました。この作業は言語学者にとって大きな負担であり、網羅性の担保も困難でした。

SoftMatchaのソフトマッチ機能を使えば、見出し語の1形を入力するだけで、活用変化を含む出現箇所をまとめて検索できます。SoftMatcha 2はこの能力をさらに兆規模のコーパスへと拡張したため、古典語だけでなく現代の多言語コーパスに対しても同様のアプローチが適用可能です。言語学者がフィールドワークの代わりに大規模コーパスを分析する「コーパスベースの言語研究」の効率を大幅に向上させるツールとして期待されています。

学習データ中の有害表現やバイアスを大規模に洗い出すデータ監査への展開可能性

ベンチマーク汚染の検出以外にも、SoftMatcha 2はLLMの学習データに含まれる有害表現やバイアスの検出に活用できる可能性があります。初代SoftMatchaの実験では、英語・日本語Wikipediaを対象に、ヘイトスピーチや差別的表現のクエリに対してソフト検索を行い、表面的には異なるが意味的に有害な表現を検出する事例が報告されています。完全一致では「特定のヘイト用語」しかマッチしませんが、ソフト検索であれば言い回しを変えた同質の有害コンテンツまで捕捉できます。

兆規模コーパスに対してこの監査を実行できるようになったSoftMatcha 2は、LLMの安全性評価プロセスにおけるデータ品質チェックの自動化に貢献する可能性を秘めています。モデルが有害なバイアスを学習してしまうリスクは学習データの品質に直結しており、ソフト検索による広範なスキャンは完全一致では見落とされる微妙な表現パターンの検出を可能にします。今後、データ監査のワークフローにSoftMatcha 2を組み込む動きが広がることが予想されます。

7言語対応のインストールからインデックス構築・検索実行までの導入手順

SoftMatcha 2はGitHubでオープンソースとして公開されており、研究者やエンジニアが自身の環境で構築・実行できます。対応言語は英語、日本語、中国語、ドイツ語、イタリア語、フランス語、ラテン語の7言語で、各言語に応じた埋め込みモデルの指定が必要です。ここでは、環境構築からインデックス作成、検索実行までの一連の手順を解説します。

Rust・Python 3.12・ICUライブラリなど構築に必要な5つの依存関係と環境準備

SoftMatcha 2の構築には、Python 3.12、Rust（最新安定版）、ICUライブラリ（libicu-dev）、build-essential、そしてパッケージマネージャのuv（Astral社製）が必要です。Rustはパフォーマンスクリティカルな接尾辞配列操作を担うため必須であり、ICUライブラリは多言語テキストの正規化処理に使用されます。

環境構築の基本的な流れとしては、まずuvとRustのインストールスクリプトを実行し、続いてシステムパッケージ（build-essential、python3.12-dev、pkg-config、libicu-dev）をインストールします。その後uv syncでPython依存パッケージを一括取得し、uv run maturin develop --releaseでRust拡張をビルドします。初回セットアップ時には、GloVeやfastTextのキャッシュをクリアする手順も推奨されています。依存関係の数は多いものの、公式リポジトリのREADMEに記載されたコマンドを順に実行すれば、特別なトラブルなく環境を構築できる設計です。

softmatcha-indexコマンドで小規模10倍・大規模3倍未満のインデックスを生成する手順

インデックスの構築はsoftmatcha-indexコマンドで実行します。基本的な書式はuv run softmatcha-index --index [出力ディレクトリ] [テキストファイル]で、指定したテキストファイルから接尾辞配列ベースのインデックスを生成します。インデックスの最終ファイルサイズは、小規模コーパスでは元テキストの約10倍、大規模コーパスでは3倍未満に圧縮されます。

構築時間はコーパスサイズとハードウェアに依存しますが、接尾辞配列の構築は一度実行すれば再構築の必要がないため、初期コストとして割り切れる性質のものです。大規模コーパスを扱う場合はHDDまたは大容量SSDの確保が前提となり、1.4兆トークン規模では数TBのストレージが必要になります。インデックス構築後は、同じインデックスに対して何度でも高速検索を繰り返し実行できるため、構築コストに見合うだけの利用価値が得られます。

num_candidatesやmin_similarityを調整して検索精度と速度を制御するパラメータ設計

SoftMatcha 2のソフト検索コマンドsoftmatcha-searchには、検索の精度と速度のバランスを調整するための主要パラメータが用意されています。--num_candidatesは検索結果の最大候補数を指定するパラメータで、値を大きくするほど網羅的な結果が得られますが、出力処理に時間がかかります。--min_similarityは最小類似度閾値で、この値を下げるとより緩いマッチが許容される反面、偽陽性が増加します。

--max_runtimeは検索の最大実行時間（秒）を制御し、タイムアウト防止に使用します。実務での推奨設定例としては、ベンチマーク汚染検出では--min_similarity=0.6 --num_candidates=100 --max_runtime=20、探索的なコーパス分析では--min_similarity=0.2 --num_candidates=100のように目的に応じた使い分けが有効です。これらのパラメータを適切に調整することで、研究目的や利用可能な計算資源に応じた検索戦略を柔軟に設計できます。

英語のGloVeと日本語・中国語のfastTextでbackendモデルを切り替える多言語設定

英語以外の言語でSoftMatcha 2を使用する場合は、インデックス構築時にバックエンドモデルの指定が必要です。デフォルトでは英語用のGloVeが使用されますが、日本語では--backend=fasttext --model=fasttext-ja-vectors、中国語では--model=fasttext-zh-vectorsのように言語コードに応じたモデルを指定します。

fastTextは訓練データに含まれない未知語に対しても文字n-gramから表現を合成できるため、形態論的に豊富な言語で特に有効です。言語ごとの埋め込みモデルが類似度計算の精度に直結するため、対象コーパスの言語に適したモデルを正しく選択することが検索品質を左右する重要な判断ポイントとなります。

softmatcha-exactによるKWIC表示で検索結果の前後文脈を200バイト確認する実務例

ソフト検索に加えて、SoftMatcha 2はsoftmatcha-exactコマンドによる完全一致のKWIC（Key Word In Context）表示もサポートしています。KWICとは、検索パターンの前後文脈を一定範囲で表示する出力形式で、コーパス言語学では標準的な分析手法として広く利用されています。

基本的な実行例としては、uv run softmatcha-exact --index corpus --display=20 --padding=200 "olympics gold medalist"のように指定します。--display=20は最大20件の出力、--padding=200はパターン前後200バイトの文脈を表示するオプションです。このKWIC表示により、検索でヒットした表現がどのような文脈で使われているかを即座に確認でき、汚染判定やバイアス分析の根拠資料として活用できます。ソフト検索で候補を絞り込んだ後に、完全一致のKWIC表示で詳細な文脈確認を行うという二段階の分析フローが実務上は効果的です。

LLMの安全性評価を担う大規模コーパス検索ツールとしての将来展望

SoftMatcha 2は2026年2月に公開されたばかりのツールですが、LLMの事前学習データの品質管理や安全性評価において中核的な役割を果たす可能性を持っています。ベンチマーク汚染の問題はLLM評価の信頼性に直結するため、ソフト検索による精密な汚染検出は今後さらに重要性を増すと考えられます。同時に、現時点の技術的制約や運用上の注意点を理解したうえで活用することが不可欠です。

「見つかれば強い証拠・見つからなくても汚染ゼロとは限らない」運用上の判断指針

SoftMatcha 2を汚染検出ツールとして運用する際に最も重要なのは、検索結果の解釈に関する適切な判断指針です。ソフト検索でマッチが見つかった場合は、そのベンチマーク問題がコーパス中に類似した形で存在する強い証拠となります。論文の実験では、追加検出の約81%が真の汚染であることが確認されており、偽陽性率は比較的低水準に抑えられています。検出結果を手動検証する工程を組み合わせれば、さらに高い精度でのスクリーニングが可能です。

一方で、マッチが見つからなかったからといって、そのコーパスに汚染が存在しないと断定することはできません。SoftMatcha 2は単語レベルの類似度に基づくマッチングであるため、文全体の構造が大きく変化した高度な言い換えや、異なる表現体系での記述は検出範囲外です。この「非対称な証拠」の性質を正しく理解し、ソフト検索を「汚染の有無を断定するツール」ではなく「汚染リスクを評価するスクリーニングツール」として位置づけることが運用上の鍵になります。

静的コーパス前提の索引設計が頻繁な追加・削除に弱いという実運用での制約

SoftMatcha 2の接尾辞配列ベースのインデックスは、構築後の追加・削除・差し替えに対応していません。接尾辞配列の構造上、コーパスの一部が変更されるとインデックス全体の再構築が必要となるため、頻繁にデータが更新されるような動的なコーパスには不向きです。この点はinfini-gramやinfini-gram miniも同様であり、接尾辞配列系の索引技術に共通する構造的な制約といえます。

この制約は、SoftMatcha 2が「巨大でほぼ静的なコーパス」を対象とした設計であることに起因しています。FineWeb-EduやCommon Crawlのスナップショットのように、一度取得したら基本的に変更されない事前学習用コーパスの分析には最適ですが、日々更新されるニュースフィードやSNSデータのリアルタイム分析には別のツールが適しています。実運用では、コーパスのバージョンが確定した時点でインデックスを構築し、そのインデックスに対して繰り返し検索を行うというバッチ処理的な運用フローが前提となります。

構成的意味論を取り入れた次世代ソフトマッチの研究方向と実用化への課題

SoftMatcha 2の論文では、現在の単語レベル埋め込みの限界を超えるための研究方向として、構成的意味論（compositional semantics）の導入が言及されています。構成的意味論とは、文の意味がその構成要素（単語やフレーズ）の意味と組合せ規則から体系的に決定されるという言語学的原理であり、これを検索アルゴリズムに組み込むことで、文構造レベルの言い換えも検出可能になると期待されます。

ただし、構成的意味論の導入は計算コストの大幅な増加と直結するため、兆規模コーパスでのサブ秒検索という現在の性能を維持しながら実現できるかが最大の課題です。SoftMatcha 2が自然言語の統計的特性を利用した枝刈りで組合せ爆発を抑制しているように、構成的意味の計算においても効率的な枝刈り手法が必要になります。このトレードオフの解決は、コーパス検索技術全体の次のブレークスルーとなる可能性を秘めています。

OSSとして公開されたSoftMatcha 2を組織内データ監査に導入する際の3つの検討事項

SoftMatcha 2はGitHubでオープンソースとして公開されており、研究者やエンジニアが自由にソースコードを入手・利用できます。組織内のデータ監査ツールとして導入を検討する際には、ライセンス条件をリポジトリで確認したうえで、主に3つの事項を事前に評価する必要があります。

第1にストレージ要件です。兆規模コーパスのインデックスは数TBに達するため、十分なディスク容量の確保が前提となります。第2に計算環境の選定です。SoftMatcha 2はGPU不要でCPU環境でも動作しますが、インデックス構築にはRAMとディスクI/O性能がボトルネックになるため、構築フェーズと検索フェーズで異なるハードウェア最適化が求められます。第3に運用体制です。接尾辞配列インデックスの再構築が必要なタイミング（コーパスのバージョン更新時）を明確にし、構築パイプラインの自動化を整備しておくことが、継続的なデータ監査の実現には不可欠です。

LLM事前学習パイプラインにコーパス検索を組み込むデータ品質管理の未来像

SoftMatcha 2のような高速ソフト検索ツールの登場は、LLMの開発パイプラインにおけるデータ品質管理のあり方を変える可能性があります。現在のLLM開発では、データ収集・クリーニング・重複排除・学習というパイプラインが標準的ですが、ベンチマーク汚染検出やバイアススキャンは多くの場合、学習後の事後評価として行われています。

サブ秒のソフト検索が可能になったことで、学習データの前処理段階でベンチマーク問題との類似チェックを自動的に実行し、汚染リスクの高いデータを学習前に除外するワークフローが現実的になります。さらに、有害表現やバイアスのパターンリストに対するソフト検索をパイプラインに組み込むことで、モデルが問題のあるデータから学習してしまうリスクを事前に低減できます。データの規模が拡大し続けるLLM開発において、SoftMatcha 2のようなツールが品質ゲートとして標準装備される未来は、十分に現実的な展望といえるでしょう。