仕組み

なぜこんなに小さいのか？

最大の疑問：従来の形態素解析器が数十MB級の辞書を必要とすることが多いのに、Suzumeはなぜ gzip で約227KiBに収まるのか？

簡潔な答え

IPADIC 系辞書を使う MeCab	Suzume
形態情報を持つ広範な単語リストを読み込む	選択した単語と例外を保存
事前計算済みの接続コスト行列を読み込む	コンパクトな規則から接続を計算
辞書エントリと未知語定義を使う	辞書エントリとパターン生成候補を使う

ポイント

MeCab の語彙・品詞・接続コストは、選択した辞書から供給されます。Suzume は語彙を絞り、文字種と文法のパターンから候補を追加します。このドキュメントで MeCab との比較に使う正確な構成は、比較条件に記載しています。

3つの柱

Suzume は配布する辞書データを小さくし、解析の多くをコンパクトな文法ルールとスコアリングに寄せています。

トークン化とは？

テキストを意味単位（トークン）に分割し、品詞を特定すること。日本語では「東京に行く」のような連続テキストを「東京 / に / 行く」に分割します。

1. 最小限の辞書

従来の解析器は網羅的な単語リストを保存：

# MeCab辞書エントリ（簡略化）
東京,名詞,固有名詞,地域,*,*,*,東京,トウキョウ,トーキョー,0/3,C1

Suzumeは高頻度の機能語、助詞、助動詞、例外語を中心に保存します。多くの内容語は、すべての表層形を辞書に持つのではなく、文字種パターンや文法規則から候補を作ります。

カテゴリ	従来の辞書ベース解析器	Suzume
機能語	辞書に収録	コンパクトなエントリと文法規則
動詞・形容詞	多数の表層形・活用形エントリ	活用規則と選択的な例外
一般名詞・固有名詞	広範な語彙を収録	文字種パターンの候補とコンパクトな辞書
ドメイン固有語	辞書パッケージまたはカスタマイズ	実行時ユーザー辞書

2. パターン認識

すべての単語を保存する代わりに、パターンを認識：

たとえば辞書にないカタカナ列でも、名詞候補としてラティスに載せられます。

パターン	ルール	結果
[カタカナ]+	名詞候補を生成	名詞候補
[漢字]+	複合名詞候補を生成	名詞候補
[漢字]+する	サ変構文の候補を生成	動詞候補
[ひらがな]+い	「い」で終わる = 形容詞候補	形容詞

なぜこれが機能するのか

日本語の文字種と活用語尾は、候補を作る手掛かりになります。Suzume はその手掛かりを辞書エントリや前後の接続スコアと組み合わせます。パターンに一致しただけで、最終的な品詞や境界が決まるわけではありません。

実際に試してみてください：

ブラウザ内で試す

入力した文章はサーバーに送られません。ページに同梱された Suzume WASM が、その場で分割・原形復元・タグ抽出を実行します。

入力昨日ラーメンを食べさせられなかった

WASM を読み込み中...

3. 動的な接続スコアリング

IPADIC などの MeCab 辞書には、事前計算済みの接続コスト行列が含まれます：

# どの単語がどの単語の後に来れるか？（簡略化）
名詞 → 助詞: コスト 100
名詞 → 動詞: コスト 500
助詞 → 名詞: コスト 50
...数百万の組み合わせ

Suzumeはコンパクトなルールで接続スコアを動的に計算します：

自然な品詞のつながりは低コストに、不自然なつながりは高コストにして、Viterbi が文全体で最適な経路を選びます。

判定の一貫性

Suzume は品詞と分割を、辞書エントリに加えて文字種・活用・接続の共通規則から決めます。多くの候補に同じ規則を適用するため、語ごとに調整されたエントリへの依存は減りますが、文脈や競合する候補によって結果が変わることはあります。

辞書とコスト表を使う設計では、文法上の役割が似たエントリでも異なるラベルやコストを持ち得ます。構文単位の共通規則はその差を減らしますが、辞書候補と前後の文脈は選択される経路に引き続き影響します。

たとえば名詞述語に続く「じゃ」は、「本じゃない」「本じゃなかった」「本じゃな」で原形「だ」の助動詞として解析されます。ただし最後の例の後続「な」は助詞で、単独の「じゃない」は一語の形容詞になる場合があります。使役受身の規則も、文脈を解決しながら同等の構文を同じ形へ正規化することを狙っています（MeCab との違い の該当節を参照）。

この一貫性は、どの分割単位が「正しい」かとは別の話です。Suzume が採る解釈が唯一の正解という意味ではなく、採用した規則が入力全体に均一に適用される、という性質を指します。規則にも適用範囲の限界があり、そこでは判定が揺れる場合があります（制約 を参照）。

最適化対象の違い

目的で選ぶ

Suzume は、ブラウザ・エッジ・ネイティブアプリ向けのコンパクトで検索しやすいトークン化に最適化されています。完全な辞書を持つ解析器は目的の異なる道具であり、その辞書カバレッジや詳細な形態論体系が要件なら、そちらを選びます。両者の出力は相互互換を意図していないため、MeCab との一致率は Suzume の評価指標ではありません。要件ごとの詳しい比較は 使い分けの指針 を参照してください。

ここで説明した辞書・パターンによる候補生成・Viterbi スコアリングのパイプラインは常に動きます。SuzumeOptions では、正規化と分割、辞書の読み込み、スコアラー設定、JavaScript インスタンスごとに独立した WASM ランタイムを使うかどうかを指定できます。全項目は API リファレンスを参照してください。

トークン化の調整

mode: 'search' | 'split'とmergeCompoundsを使うと、複合語をどこまで細かく分割するか、あるいはまとめるかを用途に合わせて調整できます。詳しくはAPIリファレンスを参照してください。

技術的な詳細

ラティスとは？

テキストを分割するすべての可能な方法を表すグラフ構造。ラティスを通る各パスが1つのトークン化候補です。「すもも」の場合、「すもも」（李）や「す/もも」（酢＋桃）などのパスがあります。

Viterbiアルゴリズムとは？

ラティスを通る最適なパスを見つける動的計画法アルゴリズム。すべての可能な組み合わせを評価する代わりに、以前の計算を再利用して効率的に最適な分割を見つけます。

解析パイプライン

複数の分割候補を最後まで残し、スコアリングで最も自然な経路を選びます。

未知語処理

Suzumeが「スカイツリー」のような未知語に遭遇した場合：

1. 辞書にない — 登録エントリなし
2. パターンマッチ — カタカナ列として認識
3. 候補生成 — 名詞仮説を作成
4. ラティスで競合 — 他の可能性とスコアリング
5. 最適選択 — Viterbiが最適な分割を発見

動詞活用

Suzumeは各活用形を保存せず、数百の活用パターンを認識します：

基本形: 食べる
├── 食べ + ない → 否定
├── 食べ + ます → 丁寧
├── 食べ + た → 過去
├── 食べ + て → て形
└── 食べ + れば → 仮定

各活用形ではなく、ルールが保存されています。

まとめ

疑問	答え
なぜ MeCab + IPADIC 構成は大きい？	IPADIC が広範な語彙と事前計算済み接続コストを提供するため
なぜSuzumeは小さい？	ルール + 最小辞書を保存
MeCab と Suzume の出力は互換？	いいえ。目的、境界、品詞体系が異なります
MeCabを使うべき時は？	MeCab 辞書の語彙カバレッジと解析規約が必要な時
Suzumeを使うべき時は？	ブラウザ・サーバーランタイム・Python・Go・C/C++ でコンパクトな検索/表示用トークン化が必要な時

関連ページ

• APIリファレンス
• MeCabとの比較
• はじめに