Windows 64bitでMeCab(とKyTea)を使う方法 2018

Aki Ariga
10 min readDec 1, 2018

--

こんにちは、日本語のテキスト処理してますか。

最近はBERTやらTFhubで使えるのEmbeddingのモデルが一段と増えてきて、楽しいですね。BERTで用いられるWordPieceや、MeCabの作者としても有名な工藤さんの新作、SentencePieceといった新しいTokenizerが出てくる一方で、TFhubで用意されているNNLMのtokenizerは公開されていないので結局MeCabで頑張らないといけない(少なくとも当初Tokenizerなんて要らないよという返事をされた)など、2018年の今でもMeCabの重要性は変わらず続いています。

そこで、今回はWindowsでも形態素解析をしたいという人にどうしたらいいんだっけという話の2018年12月版をしたいと思います。

tl;dr

なぜこの記事を書くに至ったか

今年に入って、MeCab/SentencePieceの作者の工藤さんによる形態素解析本も出てきて、ますます皆さんの日本語処理熱は高まっているかと思います。

PythonでのモダンなNLPの処理向けのライブラリspaCyでは、他の言語との兼ね合いでPure Python実装のJanomeからUnidicベースのMeCabに移行されました。需要は高まっています。

https://spacy.io/usage/models Spacy depends on MeCab (mecab-python3)

また、日本語の機械学習の本が新たに出ていますが、大抵の場合Pythonでmecab-python3を使いましょうとありますが、現状まだwheelの提供もないためSWIGも用意しsourceからのビルドが前提です。Windowsの人にそれを要求するのはハードルが高いです。

64bit WindowsでMeCabを使うには

メモリ16GBは人権という言葉もありますが、この前提には4GB以上のマシンでは64bit OSを使っているということが前提だと思います。とはいえ、MeCabの公式サイトには32bit版のバイナリしか存在しておらず、自前のビルド環境を用意していないことが多いWindowsの皆様におかれましては面倒くさい状況になっていると言えます。まさか、8年前の自分の記事が役に立つときが来るとは…。

しかし、3年前のMinGW用の修正が今年になってマージされたときにMSVCでのビルドが壊れてしまいました。一応PRを投げましたが、いつマージされるかはわからない状況です。

また、ikegami-yukinoさんという方が64bit版exeを配布されていますが(windows用wheelも)、CIでexe実行してインストーラ回すのどうすればいいんだっけということで、zipで固められたものがほしいなぁと思いました。

韓国の先立ちはCIでWindows向けMeCab、 辞書(ipadic)、 Python用のwheelをbuildしているのを見つけました。

これはいい。ということで、車輪の再発明をしました。

Yet another MeCab binaries for Windows x64 & x32

GitHubのreleaseにて最新のMeCabをベースにしたWindowsの64bit & 32bitバイナリを公開しています。

やったことは、appveyor.ymlbuild.batにだいたい詰まっていますが、先程送ったPRをベースにMSVC用のMakefileを改めて作り、それらをCIでビルドしています。また、各Pythonバージョンごとのwheelも作っています。

libmecab.dllを使えばRubyなど別の言語のMeCabバインディングからも利用することができます。libmecab.dllがあるとnatto経由で使えて便利というのを手元で確認しています。

なお、Unidicは同梱しようと思えばできると思うのですが、皆大好きnelodogdはshell scriptやawk、perlの塊でビルドする必要があり、WSL使ってUbuntu用意するのが最短のようです(敗北感しかない)。

Python拡張モジュールのbuildの話

そもそも、Pythonのパッケージでは予めビルドされたwheelという仕組みがあります。これのおかげで、ユーザは自分の環境でビルドすることなくさくっと pip install awesome-package するだけでC拡張があるパッケージが入れられるわけです。Rubyでいうところの gem install nokogiri で苦しまなくても良いような仕組みがあるということです。

WindowsのPython拡張周りの辛さ

Windows用のPython拡張モジュールを用意するためには、PythonのバージョンにマッチしたVisual Studioのバージョン(あるいはビルドツール)を用意しないといけません。詳しくはPythonコミッター稲田さんの以下の記事をご参照ください。

考えようによっては、MSVCの環境を用意すればWindowsのバージョンに依存しないバイナリパッケージが用意できるので、非常に楽です。少なくともmacOSはもっと楽なのですが、なぜ楽と言えるのかについてもお話しようと思います。

余談: Linux用wheelを用意する

Linuxにおいては、様々なディストリビューションの違いがある中で、各種環境で共通のwheelを用意するのは難しい問題でした。しかし、Windows/macOSでwheelが使われるようになり、その恩恵をLinuxでもあずかれるようにということでmanylinuxという枠組みができました。最初にできたのはmanylinux1というもので、互換性を考慮してCentOS 5のDocker imageをベースとしてwheelをビルドします。PEP 513に詳細は記述されています。

作り方等々は稲田さんの記事と、PyPAのpython-manylinux-demoリポジトリが参考になるでしょう。

お気づきの方もいらっしゃるかもしれませんが、CentOS 5ベースのgccで新しいプロダクトのbindingを用意するのは地獄です。現に(非常に議論が沸き起こっているところですが)TensorFlowはmanylinux1というタグを使っているにもかかわらずもっと新しい環境で用意したwheelを用意しています。

これに対してCent OS 5もEOLになることなどを踏まえて、manylinux 2010が準備されています。以下のissueを見る限りでは、次のpipからmanylinux2010を扱えるようになり、そろそろ準備が整ってきているようです。

KyTeaのWindowsバイナリとPythonバインディング

MeCabで得た知見を生かして、ついでにKyTeaもWindows用バイナリとPythonバインディングをpip installできるようにしました。本家にもPRを送ったんですが、appveyorの設定がまだされていないので、fork版をお使いください。

なお、 pip install kyteaWindowsも入るようになっています。(WindowsのPython 2.7は除く)issueがあればこちらにどうぞ。

--

--

Aki Ariga

ML Engineer at Arm Treasure Data. Previously Cloudera. Love machine learning, data analysis, Ruby and Python.