【ITニュース解説】Bringing Open JTalk to Elixir/Nerves: Make Your Pi Speak Japanese 🇯🇵

システムエンジニアを目指す初心者にとって、このニュース記事は、組み込みシステム開発の具体的な事例と、その中で直面する課題、そしてそれらを解決していくプロセスを理解する良い教材となる。

このニュース記事は、Raspberry Piという小型コンピューターをElixirとNervesという技術を使って日本語で話させる、というプロジェクトについて解説している。Raspberry Piは、組み込みシステム開発やIoTデバイスによく使われるコンピュータで、ElixirとNervesは、安定性と並行処理に優れたプログラミング言語と、それを使って組み込みシステム用のOSイメージを簡単に作成できるフレームワークである。そして、「Open JTalk」は、テキストを音声に変換する日本語のオープンソースエンジンである。プロジェクトの目的は、このOpen JTalkをElixir/Nerves環境で動かすことだった。

Open JTalkは、MeCabという日本語の単語を解析するツール、HTS Engineという音声合成の核となる部分、そしてこれらのツールが使う日本語辞書と具体的な音声データ（「Mei」という声モデル）、そしてそれら全てを動かすC言語製のコマンドラインツールで構成される。特に、インターネット接続なしでオフラインで動作するため、Raspberry Piのような組み込み環境で非常に役立つ技術だ。

しかし、Open JTalkをNerves環境で動かすのは容易ではない。一つ目の課題は、C言語で書かれたOpen JTalkをRaspberry Pi向けにコンパイルする「ネイティブビルド」の複雑さである。Open JTalkが使う「Autotools」というビルドツールは、現代のクロスコンパイル（ある環境で別の環境向けのプログラムを生成すること）にそのまま対応していない場合が多く、手作業での調整が必要となる。二つ目の課題は、Open JTalkが動作に必要とする辞書ファイル（約60MB）や音声モデルファイル（約40MB）といった「アセット」のサイズである。これらを全て組み込みシステムのファームウェアに含めると、ファームウェアのサイズが大きくなりすぎ、ユーザーが別途ダウンロードする方式では使い勝手が悪くなる。

これらの課題に対し、開発者は「ベンダー」「バンドル」「シェルアウト」という手法を採用した。「ベンダー」とは、Open JTalkのC言語のソースコードをElixirライブラリのビルド時に一緒にコンパイルすることだ。「バンドル」とは、辞書や音声モデルといったアセットファイルを、Elixirライブラリと一緒にパッケージングすることである。そして「シェルアウト」とは、Elixirのプログラムから、コンパイルされたOpen JTalkのコマンドラインツールを外部プログラムとして実行し、その結果（音声データなど）を受け取る方法である。この手法により、ユーザーはライブラリをインストールするだけで、必要なプログラムとデータが全て揃った状態で日本語音声合成を利用できるようになった。ファームウェアサイズが気になる場合は、アセットのバンドルを無効にするオプションも提供している。

この解決策にたどり着くまでに、いくつかの他の方法も検討されたが、それぞれに欠点があった。例えば、Open JTalkをNervesシステムの基本イメージに組み込む「カスタムNervesシステム」という方法は、開発やテストのたびにシステム全体を再ビルドする必要があり、開発効率が低いと判断された。また、ElixirからC言語の関数を直接呼び出す「NIFs（Native Implemented Functions）」という方法は、高速だが、C言語の不具合がElixirの実行環境全体をクラッシュさせるリスクがあり、また異なるCPUアーキテクチャへの移植も難しいという課題があったため、採用を見送った。さらに、Elixirから外部プログラムと簡単な通信をする「Elixir Port」という方法も試されたが、Open JTalkのような複雑な入出力（文字コードの問題や一時ファイルの扱い、多数の引数など）には不向きで、開発の手間が大きいと判断された。

最終的に採用されたビルドシステムは、Makefileとシェルスクリプトを組み合わせて、Open JTalkの必要なC言語ライブラリのソースコードをダウンロードし、プラットフォーム固有のパッチを適用してコンパイルし、CLI実行ファイルとアセットファイルをElixirライブラリの適切なディレクトリに配置するという流れだった。

このプロジェクトでは、異なるプラットフォームで動作させるための「クロスプラットフォーム対応」にも多くの苦労があった。C言語のビルドツールであるAutotoolsは、現代のLinuxやmacOS、Raspberry Piのような環境を自動的に認識できないことが多く、最新の環境設定ファイルを注入する必要があった。macOSでは、特定のコマンドの挙動がLinuxと異なるため、対応するスクリプトを追加したり、静的リンク（プログラムに必要なライブラリを全て一つのファイルにまとめること）ができないという制約に対応したりする必要があった。Nerves環境でのクロスコンパイルは、Nervesが提供するツールチェーンを適切に使うことでスムーズに実現できた。

完成したElixirライブラリは非常にシンプルに使える。例えば、OpenJTalk.say("こんにちは")という一行のコードでRaspberry Piが日本語を話すようになる。音声のピッチ（高さ）、レート（速さ）、音質、音量などの調整もオプションで可能である。また、必要なファイル（Open JTalkの実行ファイル、辞書、音声モデル）は、環境変数で指定された場所、ライブラリにバンドルされた場所、またはシステムに通常インストールされる場所の順で自動的に探索されるようになっている。

この開発を通じて、いくつかの重要な教訓が得られた。一つは、ユーザー体験を考慮し、必要なアセットはデフォルトでライブラリにバンドルしておくべきだということ。次に、Nervesのような組み込み開発フレームワークを使う際は、そのフレームワークの慣習に従うことが、スムーズな開発につながるということ。また、Autotoolsのような古いビルドツールは、現代の環境ではそのままでは使えないことが多く、修正や対応が必要であるということ。macOS特有の問題にも注意を払うべきであり、異なるOS環境でのテストの重要性が示された。そして、複雑なネイティブプログラムをElixirから利用する際には、NIFsやPortsといった直接的な連携方法よりも、コマンドラインツールを外部から呼び出す「シェルアウト」方式の方が、シンプルで安全、かつデバッグしやすいという知見も得られた。最後に、Makefileはシンプルに保ち、複雑なロジックはシェルスクリプトに任せるべきであり、ARMアーキテクチャ（Raspberry Piなどで使われるCPU）でのテストを早期に行うことの重要性も再確認された。

このプロジェクトは、単にRaspberry Piを日本語で話させるという目標達成に留まらず、数十年前のC言語ライブラリを現代の組み込みシステムで活用するための、クロスプラットフォーム対応のビルドシステムと、クリーンなユーザーインターフェースを持つライブラリを構築するという、実践的なシステム開発の多くの側面を示している。