形態素解析ツール比較｜MeCabとSudachiの違い、JUMAN++・GiNZA・Janome・Webツールの選び方

形態素解析の定義や仕組みは形態素解析とは？仕組み・具体例・ツールの選び方をわかりやすく解説で扱っています。この記事は「どのツールを使うか」に絞り、MeCab・Sudachi・JUMAN++・GiNZA・Janomeを比べます。カタログ情報の比較ではなく、2026年10月1日に同じ文と同じコーパスで各ツールを動かした実測結果を根拠にし、10月16日に最新の辞書で測り直しました。インストールせずにブラウザで試せるWeb茶まめやYahoo!のテキスト解析APIも、使える範囲と制限を添えて取り上げます。あわせて、2026年9月24日公開のSudachiPy 0.7で辞書形式が変わり、GiNZAを後から入れるとSudachiPyが0.6系に戻されてfull辞書が読めなくなる問題と、MeCabからSudachiへ移すときに分割の差分をどう確かめるかも取り上げます。

まとめ：MeCabとSudachiの違いと用途別に選ぶツールの結論

MeCabとSudachiの差は、速度と分割の考え方にあります。実測ではMeCab（IPAdic）がSudachiPyの約5倍速く、一方でSudachiは同じ文を短単位・中単位・長単位の3通りに切り分けられ、「附属」を「付属」に寄せる表記正規化も持っています。

• 大量のテキストを速く処理する：MeCab。Pythonからは pip install mecab-python3 と辞書パッケージだけで動き、MeCab本体の別途インストールは要りません。
• 検索や集計で表記ゆれと複合語の扱いを揃えたい：Sudachi。辞書が年に数回更新され、分割単位を用途で選べます。
• 係り受けや固有表現まで1つのAPIで扱う：GiNZA。ただし速度は桁違いに落ちます（実測で約1,400字／秒）。
• 研究で文脈を踏まえた解析精度を詰める：JUMAN++。最新版は2023年10月のプレリリースv2.0.0-rc4で、本体のビルドが前提です。
• まず手元の文で結果を見たいだけ：インストール不要のWeb茶まめ。国立国語研究所の公開サービスで、MeCabとUniDic（2025年12月版）で解析し、辞書を2つ並べて比べられます。
• Janomeは総文字数と処理期限で判断する：Pure Python製で辞書を同梱し、C拡張のビルドや辞書の追加導入が不要です。一方、今回の実測ではMeCab＋IPAdicの約140倍の時間がかかりました（31.8万字で46秒）。この時間が許容できない処理量ならMeCabかSudachiに替えます。

SudachiPyはパッチ版まで固定してください。2026年9月公開の0.7は辞書のバイナリ形式が変わり、GiNZA 5.3.0は0.7未満を要求します。0.7環境にGiNZAを追加するとSudachiPyが0.6系に戻され、別に入れていたfull辞書は新形式のまま残って読み込みに失敗します。GiNZAを使うなら0.6.11と辞書20260723、使わないなら0.7.0と辞書20261015の組み合わせで固定します。

すでにMeCabで動いている仕組みをSudachiへ移すかどうかは、手元のデータで分割が変わる行の割合を数えてから決めます。移すと決めたら、検索インデックスとユーザー辞書は作り直しになります。

主要5ツールの比較表：導入判断に使う最新版・ライセンス・実測速度の一覧

最新版はPyPIとGitHub Releasesで2026年10月1日に確認し、10月16日に再確認した値です。速度は後述の条件で、『吾輩は猫である』本文（約31.8万字）を解析した3回の中央値です。GiNZAだけは同じ本文の先頭500行（118,369字）で計測し、JUMAN++は本体をビルドしていないため計測していません。

MeCab本体の最終版0.996は2013年2月18日の公開で、以後は版が出ていません（MeCab公式サイト）。現在のPython環境で使われているのは、本体を同梱したラッパーのmecab-python3（1.0.12は2025年11月公開）です。SudachiPyの版と公開日はPyPIのSudachiPyで確かめられます。PyPIにあるJanomeの最新版は2023年7月1日公開の0.5.0です。GiNZAの速度は係り受け解析と固有表現抽出まで含めた値なので、分かち書きだけの他ツールとは処理の範囲が違います。どのツールも無料で商用利用できますが、本体だけでなく、同梱・追加する辞書やモデルのライセンスと告知事項も確認してください。Janomeの同梱辞書やSudachiDictの収録資源も対象です。

MeCabとSudachiの違い：同じ文で比べた分割単位と正規化の結果

同じ文を、MeCab（IPAdic・unidic-lite）、SudachiPy 0.7.0（SudachiDict 20260723.1のcoreとfull）、Janome 0.5.0で解析しました。10月16日に辞書を最新の20261015へ上げて解析し直しても、下の表と正規化の結果は1語も変わりませんでした。

分割単位の比較：「外国人参政権」と「選挙管理委員会」の実測結果

MeCab＋IPAdic、MeCab＋unidic-lite、Janome（IPAdic同梱）は、どれも「外国人参政権」を「外国／人参／政権」と切りました。「人参（にんじん）」が混ざる誤りで、今回の実行ではIPAdicとunidic-liteのどちらでも同じ結果になりました。Sudachiはモードを変えると単位だけが変わり、どのモードでも「人参」は出ません。SudachiPyの公式APIはAを短単位、Bを中単位、Cを長単位と定義し、モードを指定しなければCで解析します。実装の本体はsudachi.rsのGitHubリポジトリで公開されています。

使い分けの基準は、検索の取りこぼしを嫌うか、集計の粒度を揃えたいかです。全文検索ではAかBで細かく切っておくと、「参政権」や「外国人」といった部分語での検索に対応しやすくなります。ただし検索語の側も同じ辞書とモードで解析しないと、索引の語と一致しません。キーワード集計や固有表現の抽出では、Cで「選挙管理委員会」を1語に保つ方が数えやすくなります。

表記正規化：normalized_formによる表記ゆれの統一

Sudachiの形態素は、表層形・辞書形とは別に正規化表記（normalized_form()）を返します。実測では「附属」が「付属」、「シュミレーション」が「シミュレーション」、「SUMMER」が「サマー」、「かつ丼」が「カツ丼」、「打込む」が「打ち込む」になりました。MeCab＋IPAdicには同じ仕組みがないため、表記ゆれを揃えるには自前の置換表が必要です。Sudachiに替えても、集計に surface() を使い続けると正規化は効きません。問い合わせログや口コミを数えるときは、集計キーを normalized_form() にしてください。集計の設計全体はテキストマイニングとは？手法・やり方・無料ツールから企業の導入判断まで解説で扱っています。

辞書の更新：IPAdicは2007年版、SudachiDictは年に数回

MeCabで使われるIPAdicは、Homebrew・PyPIの ipadic・Ubuntuのいずれも上流版2.7.0-20070801のままです。新語を拾うために使われてきたmecab-ipadic-NEologdも、定期更新は2020年9月の版が最後です。SudachiDictはPyPI上で20260116・20260428・20260723と年に数回の版が出ており、2026年9月には新形式に対応した20260723.1、10月15日には20261015が公開されました。READMEによると、2026年10月版以降の辞書は新形式（V1）でしか配布されません。0.6系のSudachiPyで使える配布済みの辞書は20260723が最後で、それより新しい語彙を旧形式で使うには、辞書のソースから自分でビルドする必要があります。辞書の収録方針と更新履歴はSudachiDictのGitHubリポジトリにあります。辞書はsmall・core・fullの3種で、wheelのサイズはsmallが約43MB、coreが約77MBです。fullはソース配布のみで、インストール後の容量はcoreが209MB、fullが321MBでした。

辞書を大きくすれば良いとは限りません。fullで「すもももももももものうち」を解析すると、モードに関係なく「すもももももも／もも／の／うち」になりました（coreは「すもも／も／もも／も／もも／の／うち」）。fullは固有名詞を厚く収録しており、作品名などの見出し語が一般の文に割り込むことがあります。固有名詞の取りこぼしが実際に問題になってからfullへ切り替える、という順番が安全です。

処理速度の実測比較：MeCabはSudachiPyの約5倍の速さ

計測環境はMacBook Pro（Intel Core i9-9880H 2.3GHz、メモリ16GB、macOS 26.6.2）、Python 3.12.13です。青空文庫の『吾輩は猫である』（テキスト版）からルビと注記を除いた2,256行・318,457字を1行ずつ解析し、3回の中央値を取りました。辞書の読み込みとトークナイザーの生成は計測時間に含めていません。MeCabはparseToNode、Sudachiはtokenize、Janomeはtokenizeを呼び、返ったトークン数を数えるところまでを測っています。

10月16日に同じ環境と同じ本文で、辞書をSudachiDict 20261015に上げて測り直した結果は、MeCab＋IPAdicが0.31秒、SudachiPy coreのモードAが1.64秒、モードCが1.67秒でした。辞書の更新で速度の関係は変わっていません。Sudachiはモードと辞書の大きさで速度がほとんど変わりませんでした。初回の試行は多くのツールで遅く、SudachiPyのfullでは3.0秒かかっています。ネット上の比較記事には「SudachiPyはMeCabの数百倍遅い」とする計測が残っていますが、SudachiPyが2021年11月の0.6.0で内部実装をRust（sudachi.rs）に移す前の数値です。今回の環境とコーパスでは差は約5倍でした。採用判断では、日次の総文字数に加え、処理期限やオンライン処理の応答時間を実データで確認してください。

JUMAN++・GiNZA・Janome・fugashiの位置づけと向いている場面

MeCabとSudachiのほかに選択肢になる4つは、それぞれ得意な場面がはっきり分かれています。

JUMAN++：RNN言語モデルによる解析とv2.0.0-rc4の公開状況

JUMAN++は京都大学のku-nlpが開発する、RNN言語モデルを使った解析器で、係り受け解析器KNPの入力として使われてきました。GitHub Releasesの最新は2023年10月3日のv2.0.0-rc4で、プレリリースのまま正式版は出ていません。本体はReleasesの配布パッケージ（約300MB）からビルドします。公式READMEの注意事項は、学習済みモデルを含むのは配布パッケージだけで、gitのソースからビルドしても解析には使えないという点です。Pythonからはrhoknp（2026年10月12日時点の最新は10月6日公開の1.8.1）を使います。旧来の pyknp は保守が終了しており、公式リポジトリがrhoknpへの移行を勧めています。業務システムの組み込みより、KNPと組む言語研究に向く選択肢です。

GiNZA：係り受け・固有表現まで1回で、速度は約1,400字／秒

GiNZAはリクルートのMegagon LabsがspaCy上に作った日本語パイプラインで、分割と品詞付けにはSudachiPyを使います。2026年9月30日に5.3.0が公開され、spaCy 3.8.16以上とPython 3.10以上が条件です。実測では「外国人参政権について選挙管理委員会が発表した」を「外国人参政権」「選挙管理委員会」の長単位で切り、「選挙管理委員会」を主語（nsubj）、「発表」を文の中心（ROOT）とする係り受けまで返しました。代わりに先頭500行（118,369字）で中央値81.8秒、試行ごとに64〜134秒とぶれました。形態素の分割だけが目的なら、GiNZAを通さずSudachiPyを直接呼ぶ方が100倍以上速く済みます。係り受けや固有表現が業務でどう使われるかは自然言語処理（NLP）とは？仕組み・事例・LLMとの関係と導入判断をわかりやすく解説で整理しています。

Janome：Pure Python実装と総文字数に応じた処理時間

JanomeはPure Python製でIPAdicを同梱しており、Cコンパイラも辞書の追加ダウンロードも要りません。分割結果はMeCab＋IPAdicとほぼ同じで、「外国人参政権」も同じく「外国／人参／政権」になりました。処理時間の目安は31.8万字で46秒で、この環境では1分あたり約40万字です。判断は件数や頻度ではなく、処理する総文字数と処理の期限で行います。たとえば1日1,000万字を1時間以内に終えたいなら、Janomeでは計算上約24分かかり、MeCab＋IPAdicなら10秒ほどです。迷った場合はMeCabを選びます。mecab-python3はmacOS・Linux・64bit Windows向けのwheelがあり、pipだけで入ります。Janomeが有利なのは、こうしたwheelが用意されていない環境で、Cの拡張モジュールを使えない場合です。

fugashi・Vibrato：MeCab系の新しい選択肢と互換性

fugashi（1.5.2）はMeCabをCythonで包んだラッパーで、UniDicとの組み合わせを前提に作られています。unidic-lite は2013年のUniDic 2.1.2を小さくした版、unidic パッケージが提供するのはUniDic 3.1.0で、ディスク上で約770MBを使い、インストール後に別途ダウンロードが必要です。国立国語研究所が公開するUniDic自体はこれより新しく、Web茶まめでは2025年12月版が選べます。同じunidic-liteを使った計測では、fugashiは0.73秒、mecab-python3は0.55秒で、fugashiの処理時間は約33％長くなりました。VibratoはMeCabをRustで再実装した解析器（最新v0.5.2）で、MeCabより速いトークナイズを目標にしています。ただし既定の設定ではMeCabと異なる分割結果を返すことがあり、MeCab互換の出力にするにはオプションの指定が必要です。

インストール不要で試せる形態素解析ツール：Web茶まめとYahoo!テキスト解析API

手元の文がどう切れるかを確かめたいだけなら、何もインストールせずにブラウザやWeb APIで解析できます。ただし入力した文は運営元のサーバーへ送られるため、社外秘の文書や個人情報を含むテキストには使わないでください。

Web茶まめ：UniDic 2025年12月版で2つの辞書を並べて比べられる国語研のサービス

Web茶まめは国立国語研究所が公開する解析サービスで、入力した文やアップロードしたファイルをMeCabで解析します。辞書は現代語のUniDicのほか、話し言葉・近現代口語小説・近世江戸口語・中古和文・上代語・関西方言などと、IPAdic（現代語）から選べます。辞書の版は2025年12月版・2024年12月版・2023年9月版の3つです。UniDic辞書は一度に2つまで選び、同じ文の分割を並べて比較できます。IPAdicはこの2辞書比較には使えません。出力はHTML表示のほか、CSV・Excel・Chakiインポート形式などで、アップロードする入力テキストの上限は、CSV出力を選ぶ場合は1ファイル5MB、Excel出力を選ぶ場合は1ファイル100KBです。pipで入る unidic-lite は2013年のUniDic 2.1.2を元にしているので、最新のUniDicでの分割を確かめる用途にも使えます。

Yahoo!テキスト解析API：1リクエスト4KB・1分300回までのWeb API

プログラムから呼べるWeb APIでは、LINEヤフーの日本語形態素解析（V2）が現在も公開されています。Yahoo! JAPAN IDでアプリケーションを登録してClient IDを取得し、JSON-RPC形式のPOSTで文を送ります。1リクエストの最大サイズは4KBで、テキスト解析APIのFAQによると、1つのClient IDで1分に300回を超えると429エラーが返ります。上限を上げる申請は受け付けていません。応答では品詞・品詞細分類・活用型が別々に返され、「普通名詞」は品詞細分類、「イ形容詞イ段」は活用型に当たります。UniDic品詞体系に準拠した版も試験提供されています。長い文章は4KB以内に分けて送り、送信間隔を空ける実装が要ります。大量に処理するなら、通信時間を含む所要時間をローカルの解析器と比べてから選んでください。

ブラウザ上で使える個人運営の解析ツールの中には、so-zou.jpの形態素解析ツールのように、入力をこのYahoo!のAPIへ送って結果を表示しているものがあります。画面に送信先が明記されているか、使う前に確かめてください。比較記事で今も紹介されることの多いgooラボのAPIは、2026年10月16日の確認時点でドメイン（labs.goo.ne.jp）の名前解決ができず、利用できませんでした。

2026年9月のSudachiPy 0.7で変わった点とGiNZA同居時の落とし穴

既存の環境を0.7へ上げる前に、次の変更点を確認してください。SudachiPyは2026年9月24日に0.7.0を公開し、公式のリリースノートは0.7系を「v1の前の中間リリース」と位置づけたうえで、パッチ版でも挙動が変わりうるため版を厳密に固定するよう求めています。

• 辞書のバイナリ形式がV1に変わった：0.6までの辞書（V0形式）は0.7で読めません。PyPIのSudachiDict（small・core・full）で0.7が使えるのは20260723.1以降です。
• ユーザー辞書は作り直しが必要：ユーザー辞書にはビルドに使ったシステム辞書の識別情報が記録されるようになり、異なるシステム辞書と組み合わせるとエラーになります。システム辞書を上げるたびに再ビルドが要ります。
• 同じ辞書でも分割結果が変わることがある：Java版と挙動を揃えるため、未知語の扱いやカタカナ語の結合の算出方法が修正されました。
• Python APIの変更：Dictionary.create() は非推奨になり、Dictionary.tokenizer() に置き換わりました。WordInfo クラスと get_word_info は廃止です。

変更の全体は公式のsudachi.rsの移行ガイド（v0.6からv0.7）にまとまっています。

実際に問題になるのはGiNZAとの同居です。PyPIのGiNZA 5.3.0とja_ginza 5.3.0は依存として SudachiPy<0.7.0,>=0.6.11 を指定しています（2026年10月16日にPyPIのメタデータで再確認）。2026年10月15日公開のSudachiDict 20261015からは、辞書パッケージ側にも SudachiPy>=0.7.0 という依存が書かれるようになりました。この変化で、10月16日にuvで試した結果は次のように分かれました。

• coreだけの環境：SudachiPy 0.7.0とsudachidict-core 20261015の環境にGiNZAを追加すると、SudachiPyは0.6.11へ、coreは20260723へ一緒に戻され、そのまま解析できました。
• fullを別に入れた環境：sudachidict-fullはGiNZAの依存に含まれないため、20261015のまま残ります。SudachiPyだけが0.6.11に下がり、fullを読み込むと Invalid header version で失敗しました。full 20260723.1を入れていた場合も同じです。

この食い違いは、追加の直後に uv pip check を実行すれば、sudachidict-fullが要求する sudachipy>=0.7.0 に対して0.6.11が入っている不整合として検出できます。pipでも、インストールの最後に同じ内容の依存衝突がERRORとして表示されます。GiNZAを使うプロジェクトでは、SudachiPy 0.6.11と辞書20260723の組み合わせで固定するのが2026年10月時点の現実的な回避策です。GiNZAを使わずSudachiPyだけを使うなら、0.7.0と辞書20261015を同時に固定してください。

固定は依存定義ファイルに版を書くだけで済みます。GiNZAを使う場合と使わない場合の2通りを示します。

# GiNZAを使う構成（2026年10月時点）
ginza==5.3.0
ja-ginza==5.3.0
sudachipy==0.6.11
sudachidict-core==20260723

次はGiNZAを使わない別環境用です。上の依存定義とは別のファイルに保存してください。

# GiNZAを使わずSudachiPyだけを使う構成
sudachipy==0.7.0
sudachidict-core==20261015

どちらの構成でも、辞書パッケージの版を省略しないでください。GiNZAの構成で辞書を最新に任せると、依存の書かれていない20260723.1のような版が入り、同じ読み込みエラーになることがあります。

Pythonでの導入と最小コード：MeCab・SudachiPy・JUMAN++の実行例

MeCabとSudachiPyのコードは、上記の環境で実行して出力を確かめたものです。

MeCab：mecab-python3のwheelと辞書パッケージによる導入

mecab-python3のmacOS・Linux・64bit Windows向けwheelにはMeCabのライブラリが同梱されているため、MeCab本体を先に入れる必要はありません。同梱されないのは辞書で、pip install mecab-python3 ipadic のように辞書パッケージを一緒に入れます。辞書もシステムのMeCab設定ファイルもない状態で MeCab.Tagger() を呼ぶと、Failed initializing MeCab という例外が出て、詳細に default dictionary path: None と表示されます。逆にHomebrewなどでMeCab本体を入れたマシンでは、その設定ファイルが読まれて意図しない辞書で動くことがあるため、辞書は引数で明示する方が安全です。

import MeCab
import ipadic

tagger = MeCab.Tagger(ipadic.MECAB_ARGS)
node = tagger.parseToNode("外国人参政権について選挙管理委員会が発表した")
while node:
    if node.surface:
        print(node.surface, node.feature.split(",")[0])
    node = node.next

出力の先頭は「外国 名詞」「人参 名詞」「政権 名詞」です。辞書ごとの出力形式の違いやユーザー辞書の作り方はMeCabとは？インストール・出力の読み方・辞書選びとPython実装を実測で解説にまとめています。

SudachiPy：分割モードの指定と正規化表記を取り出すコード例

pip install sudachipy==0.7.0 sudachidict_core==20261015 で導入し、0.7では Dictionary.tokenizer() でトークナイザーを作ります。

from sudachipy import Dictionary, SplitMode

tokenizer = Dictionary(dict="core").tokenizer()
for mode in (SplitMode.A, SplitMode.B, SplitMode.C):
    words = tokenizer.tokenize("外国人参政権について選挙管理委員会が発表した", mode)
    print(mode, [m.surface() for m in words])

for m in tokenizer.tokenize("附属のシュミレーションソフト", SplitMode.C):
    print(m.surface(), m.part_of_speech()[0], m.normalized_form())

モードBの行は「外国人／参政権／に／つい／て／選挙／管理／委員会／が／発表／し／た」の12語になります。後半は「附属 名詞 付属」「の 助詞 の」「シュミレーション 名詞 シミュレーション」「ソフト 名詞 ソフト」の4行です。ユーザー辞書はSudachiPy付属のコマンド sudachipy ubuild でビルドします。

JUMAN++：本体のビルドとrhoknpからの呼び出し手順

JUMAN++本体（v2.0.0-rc3以降）をReleasesの配布パッケージからビルドしてPATHに通したうえで、pip install rhoknp を実行します。rhoknpはPython 3.10以上が条件です。以下はrhoknpのREADMEに沿った呼び出し方で、本記事の環境ではJUMAN++本体をビルドしていないため実行結果は確認していません。

import rhoknp

jumanpp = rhoknp.Jumanpp()
sentence = jumanpp.apply_to_sentence("外国人参政権について選挙管理委員会が発表した")
for morpheme in sentence.morphemes:
    print(morpheme.text, morpheme.pos)

MeCabからSudachiへ移す手順：分割差分の確認と検索索引の再構築

MeCabで動いている集計や検索をSudachiに替えるとき、まず必要なのは自社のデータで分割がどれだけ変わるかの実測です。前章の比較は新聞記事風の文と小説で取ったもので、問い合わせ文や商品名が多いデータでは差の出方が違います。

移行前に数える：MeCabとSudachiで分割が変わる行の割合

次のスクリプトは、テキストファイルを1行ずつ両方のツールで解析し、分割結果が一致しない行を数えます。使っているAPIは前章の2つのコードと同じものだけです。sample.txt には実データから抜き出した数千行を置いてください。

import MeCab
import ipadic
from sudachipy import Dictionary, SplitMode

tagger = MeCab.Tagger(ipadic.MECAB_ARGS)
tokenizer = Dictionary(dict="core").tokenizer()

def mecab_words(text):
    words = []
    node = tagger.parseToNode(text)
    while node:
        if node.surface:
            words.append(node.surface)
        node = node.next
    return words

def sudachi_words(text, mode=SplitMode.B):
    return [m.surface() for m in tokenizer.tokenize(text, mode)]

with open("sample.txt", encoding="utf-8") as f:
    lines = [line.strip() for line in f if line.strip()]

changed = 0
for line in lines:
    a, b = mecab_words(line), sudachi_words(line)
    if a != b:
        changed += 1
        if changed <= 20:
            print("MeCab  :", " | ".join(a))
            print("Sudachi:", " | ".join(b))

print("分割が変わった行:", changed, "／", len(lines))

比べるモードは、移行後に使う予定のモードに合わせます。検索用ならA、集計用ならCに書き換えて回してください。表示されるのは、入力順で最初に見つかった差分20行です。「人参」のような誤分割の改善、複合語の分割単位の変更、新たな誤分割がないかを確認してください。誤分割の改善が多ければ移す価値があり、単位の変更ばかりなら集計キーの付け替え作業が増えるだけです。新たな誤分割が目立つ場合は、ユーザー辞書で補えるかを先に確かめます。

MeCabからの移行後に作り直すユーザー辞書・検索索引・集計キー

• ユーザー辞書：MeCabのCSV辞書はSudachiでは形式が違うため、そのままは読めません。Sudachiのユーザー辞書形式に書き直し、sudachipy ubuild でビルドします。0.7ではシステム辞書を上げるたびに再ビルドが要ります。
• 検索索引：索引の語はMeCabの分割で作られています。解析器を替えたら全件を再インデックスし、検索語の解析も同時に切り替えます。片方だけ替えると、索引の語と検索語が一致しなくなります。
• 集計キーと過去の集計値：normalized_form() を集計キーにすると、「附属」と「付属」の件数が合算されます。過去の月次レポートと数字が連続しなくなるため、移行月に新旧両方の値を出して差を記録しておきます。

Elasticsearch移行用のanalysis-sudachi設定例

Elasticsearchでkuromojiから移す場合は、Sudachi公式のanalysis-sudachiを入れます。最新の3.6.0（2026年6月1日）の対応対象は、Elasticsearch 8.10〜8.19系と9.0〜9.4系です。プラグインの導入に加えて、対応するシステム辞書の配置が必要です。READMEの手順では、SudachiDictから取得した system_core.dic をElasticsearchの config/sudachi/ に置きます。3.6.0が内部に持つSudachiは0.8.0で、SudachiDictのREADMEによると新形式（V1）を読めるのはSudachi 0.8.2以降です。2026年10月版以降の辞書は新形式でしか配布されないため、このプラグインには旧形式で配布された20260723までの辞書を使います。以下は辞書の配置を済ませた環境で使うanalyzerの設定例です。

PUT products
{
  "settings": {
    "index": {
      "analysis": {
        "tokenizer": {
          "sudachi_c": {
            "type": "sudachi_tokenizer",
            "split_mode": "C"
          }
        },
        "analyzer": {
          "ja_sudachi": {
            "type": "custom",
            "tokenizer": "sudachi_c",
            "filter": ["sudachi_normalizedform", "sudachi_part_of_speech", "sudachi_ja_stop"]
          }
        }
      }
    }
  }
}

POST products/_analyze
{
  "analyzer": "ja_sudachi",
  "text": "附属のシュミレーションソフト"
}

READMEは、sudachi_normalizedform が sudachi_split・sudachi_baseform・sudachi_readingform と同じanalyzerに並ぶと上書きされると書いています。長単位と短単位の両方で拾う sudachi_split（mode: search）と表記正規化は、1つのanalyzerでは両立しません。両方ほしい場合に必要なのは、analyzerを分けた2つのフィールドへの索引作成です。READMEもA単位とC単位の両方で検索したいときは、トークナイザーを複数使うよう案内しています。kuromoji側の構成はElasticsearchの日本語全文検索｜kuromojiのanalyzer構成と辞書追加、N-gram併用の判断で扱っています。

用途別の選び方と避けるべき構成：検索・集計・RAGでの判断基準

Elasticsearchで日本語検索を組む場合は、公式プラグインのkuromoji（IPAdicを使うLucene実装）か、Sudachi公式のanalysis-sudachiが候補です。設定の違いは前章のとおりで、表記ゆれの多い社内文書ならanalysis-sudachiを選びます。

RAGの検索部分でも、形態素解析器の選択は検索結果に影響する要素です。ベクトル検索と並べてキーワード検索を走らせる構成では、キーワード側のスコアをBM25とは？読み方・計算式とk1・bの意味、Python実装（rank_bm25・bm25s）の落とし穴で計算し、その前処理に分かち書きを使います。ここで「外国人参政権」が「人参」を含む3語に割れると、「人参」を含む無関係な文書にも一致する可能性があります。順位への影響は検索条件と文書集合で変わります。両者を統合する方法はハイブリッド検索とは？RAGでBM25とベクトル検索を統合する仕組み・RRF・実装コードにまとめました。社内文書を対象にしたRAGの検索精度で迷っている場合は、一創のRAG構築支援で、分かち書きと辞書の選定から検索基盤の構築まで相談できます。

避けるべき構成は次の3つです。

• 分割だけが目的で、GiNZAやJanomeでは処理期限を超えるバッチ：実測ではGiNZAが118,369字に81.8秒（31.8万字に換算すると約220秒）、Janomeが31.8万字に46秒かかりました。処理量が増えればその比率で時間が伸びます。分割だけが目的ならMeCabかSudachiPyに替えます。
• 新語対策をNEologdだけに頼る：定期更新は2020年9月の版が最後で、その後に出た製品名・サービス名への継続的な追随は期待できません。
• SudachiPyの版を固定せずにGiNZAと同居させる：0.7の章のとおり、依存解決でSudachiPyだけが下がり、別に入れたfull辞書が新形式のまま残って読み込みに失敗します。

なお、LLMの入力に使うトークナイザーはBPEなどのサブワード分割で、形態素解析とは目的が違います。違いはトークナイザーとは？BPE・WordPiece・Unigramの違いと日本語での実装判断を解説【2026年版】を参照してください。

よくある質問

形態素解析ツールの選定で寄せられやすい質問を5つ取り上げます。

形態素解析ツールは無料で使えますか？

この記事で比べた5つはすべて無料で、商用利用もできます。MeCab本体はGPL・LGPL・BSDから選択、Sudachi・SudachiPy・SudachiDictとJanome、JUMAN++はApache License 2.0、GiNZAはMIT Licenseです。MeCabは組み合わせる辞書のライセンスが本体とは別なので、製品に同梱するときは辞書側も確認してください。インストール不要のWeb茶まめも無料で使えます。

JanomeとMeCabはどちらを選ぶべきですか？

現在はMeCabです。以前はMeCab本体のビルドが難しいことがJanomeを選ぶ理由でしたが、mecab-python3はpipだけで導入できます。Janomeと、IPAdicを組み合わせたMeCabの分割結果はほぼ同じで、実測ではMeCab＋IPAdicが約140倍速く処理しました。Cの拡張モジュールを使えない環境でなければ、MeCabを選びます。

SudachiPyの辞書small・core・fullはどれを使えばよいですか？

まずcoreを使ってください。smallは語彙を絞った軽量版、fullはcoreに固有名詞などを足した版です。fullは「すもももももも」のような作品名まで一般の文に当てはめることがあるため、固有名詞の取りこぼしが実際に問題になってから切り替えるのが安全です。

英語の形態素解析ができるツールは？

PythonならspaCyの英語モデルやNLTKがよく使われます。英語は単語が空白で区切られているため、日本語のような分かち書きよりも、見出し語化（running→run）と品詞付けが処理の中心です。spaCy 3.8.16とen_core_web_smで「The researchers were running faster models.」を解析すると、researchersはresearcher（名詞）、wereはbe（助動詞）、runningはrun（動詞）、fasterはfast（形容詞）と返りました。MeCabやSudachiは日本語用の解析器なので、英語の文には使いません。

形態素解析にPythonは必須ですか？

必須ではありません。MeCab・JUMAN++・Sudachiはコマンドラインから単体で動き、SudachiにはJava版もあります。Elasticsearchのkuromojiやanalysis-sudachiのように、検索エンジンのプラグインとして組み込む使い方もあります。解析結果を集計や機械学習につなげる場合にPythonが多く使われる、という位置づけです。

関連記事

• 形態素解析とは？仕組み・具体例・ツールの選び方をわかりやすく解説
• MeCabとは？インストール・出力の読み方・辞書選びとPython実装を実測で解説
• Elasticsearchの日本語全文検索｜kuromojiのanalyzer構成と辞書追加、N-gram併用の判断
• ハイブリッド検索とは？RAGでBM25とベクトル検索を統合する仕組み・RRF・実装コード
• テキストマイニングとは？手法・やり方・無料ツールから企業の導入判断まで解説