【ITニュース解説】Why We Trained 0.8B and 4B Transliteration Models for Mixed-Script Input Methods (No Mode-Switching)
2026年11月07日に「Dev.to」が公開したITニュース「Why We Trained 0.8B and 4B Transliteration Models for Mixed-Script Input Methods (No Mode-Switching)」について初心者にもわかりやすく解説しています。
ITニュース概要
複数の言語が混在した文章(例: 日本語と英語)を入力する際、従来のIMEはモード切り替えが煩わしく、一般的なLLMは意図しない翻訳をする。これを解決するため、モード切り替えなしでラテン文字から適切なスクリプトへ変換する「Transliteration 2.0」モデルと入力メソッド「UnimeType」を開発。高速かつ正確な変換を実現し、多言語入力のストレスを軽減する。
ITニュース解説
ソフトウェア開発の現場では、英語と日本語、中国語、ヒンディー語、アラビア語といった複数の言語を混ぜて文章を作成する場面が日常的にある。例えば、ソフトウェアのドキュメント作成、Slackでのやり取り、あるいは自分用のメモなど、様々な状況で、ラテン文字(アルファベット)の英語と、それ以外の文字体系の言語が入り混じった文章を書く必要に迫られるのだ。
従来のIME(Input Method Editor、日本語入力ソフトなど)を使うと、この作業には大きな負担が伴う。例えば、日本語のローマ字入力で文章を書いている途中で、「README」や「useEffect」、「v1.0.22」といった英語の単語やコードの識別子を書きたい場合を想像してほしい。通常のIMEでは、一度日本語入力モードを解除し、英数入力モードに切り替えて英語を入力し、その後再び日本語入力モードに戻すという操作が必要になる。この「モード切り替え」のたびに、Ctrl+Spaceキーを押したり、地球儀アイコンのキーを押したりする手間が発生し、作業の流れが何度も中断されてしまうのだ。これは、地味だが積み重なると大きなストレスとなる。
一方で、最近登場したGPTのような大規模言語モデル(LLM)を使った翻訳ツールではどうかというと、また別の問題がある。例えば、「kyou wa Tokyo de meeting ga arimasu(今日は東京でミーティングがあります)」のような、ローマ字と英語が混在した文章を入力すると、これらのツールは「Today there is a meeting in Tokyo.」のように、文章全体を一つの言語(この場合は英語)に翻訳してしまおうとする。しかし、私たちは「Tokyo」や「meeting」といった単語を意図的に英語のまま残したい場合が多い。このように、文中に意図的に異なる言語を混ぜて使う「コードスイッチング」の状態をそのまま維持するのではなく、全てを翻訳してしまう点が、一般的なLLM翻訳ツールの弱点だった。
こうした従来のIMEと一般的なLLM翻訳ツールの両方が抱える課題を解決するために開発されたのが「UnimeType」という新しい入力メソッドであり、それらを支える「Transliteration 2.0」という専門的なモデル群だ。この技術の目的は、モードを切り替えることなく、複数の文字体系が混在した文章をスムーズに入力できるようにすることにある。
この技術の核心は「Transliteration(翻字)」という考え方にある。これは「Translation(翻訳)」とは根本的に異なる。「翻訳」が意味を別の言語に完全に変換することであるのに対し、「翻字」は、入力されたラテン文字を、その発音に対応する目的の言語の文字に変換しつつも、文中に含まれる英語の単語はそのままラテン文字で維持するというものだ。例えば、「women xiazhou release v2.1, qing xian check PR」というピンイン(中国語のローマ字表記)と英語が混在した入力に対して、UnimeTypeは「我们下周 release v2.1,请先 check PR」という出力を生成する。ここで、「release v2.1」や「check PR」といった英語の部分はそのまま残されているのがわかる。日本語の例なら、「kyou wa Tokyo de team meeting ga arimasu」という入力から、「今日は Tokyo で team meeting があります」と、Tokyo や team meeting が英語のまま表示される。
このような入力メソッド用のモデルには、一般的なチャット用のLLMにはない、三つの厳しい制約がある。
一つ目は「境界保持」だ。認識された英語の単語、プログラミングコードの識別子、URL、ユーザー名などは、ラテン文字のまま維持されなければならない。もしそれらが目的の言語の音節として発音される場合を除いて、勝手に他の文字に変換されてしまっては困る。例えば、中国語のピンイン入力中に「you」と打った時、それが英語の「you」なのか、中国語の「有(yǒu)」や「又(yòu)」なのかを区別し、英語の場合は英語のまま、中国語の場合は漢字に変換する必要がある。
二つ目は「文脈による同音異義語の曖昧性解消」だ。例えば、「you」(英語の「you」と中国語ピンインの「有/又」)や、「main」(英語の「main」とヒンディー語の「मैं (main)=私」)、あるいは「de/to」(英語の前置詞と中国語/日本語の助詞)といった、同じ発音を持つ単語が文脈によって意味や役割が異なる場合がある。これらの単語がどちらの意味で使われているかを正しく判断するには、その単語だけでなく、前後の句や文全体を見て判断する高度な能力がモデルに求められる。
三つ目は「サブ秒の遅延と会話的な応答の排除」だ。入力メソッドは、ユーザーがキーを打つたびに瞬時に反応しなければならない。そのため、変換結果が出るまでに数秒も待たされることは許されないし、「変換されたテキストはこちらです」といった余計な会話的な応答も不要だ。一般的なチャットLLMのように、思考プロセスを経て回答を生成するような時間は、入力メソッドでは使えない。
これらの厳しい制約を満たし、デスクトップ環境での高速な推論や低遅延のクラウド利用を実現するために、UnimeTypeは「Qwen/Qwen3.5」という既存の大規模言語モデルをベースに、二つの異なるサイズのモデルを専門的にファインチューニング(追加学習)した。
一つは「UnimeType/Transliteration-2.0-0.8B」というモデルだ。「B」はbillion(10億)を意味し、この場合はモデルが持つパラメーターの数を示している。0.8Bというモデルは非常に軽量で、サイズも約500~800MBと小さく、ラップトップのCPUやGPUで即座に動かせるように設計されている。もう一つは「UnimeType/Transliteration-2.0-4B」というモデルだ。こちらはより大規模な4Bモデルで、より複雑なコード混在文や、地域の方言(例えばアラビア語のエジプト方言など)、多音節の漢字の選択といった、より高度で精度の高い変換が求められる場面で威力を発揮する。
両モデルともに、高速な出力を実現するために工夫が凝らされている。例えば、「Short-Protocol (v2.1)」というコンパクトなシステムプロンプトを使用し、モデルの「思考(enable_thinking=False)」機能を無効にすることで、最初の出力トークンがすぐに生成されるようになっている。これにより、入力メソッドに求められるサブ秒の応答速度を達成しているのだ。これらのモデルの性能は、900以上の多言語テストケース、同音異義語の衝突、英語保持のストレステストなど、厳格なベンチマーク手法を用いて評価されている。
このUnimeTypeの技術は、すでにブラウザベースの無料コンバーターとして提供されており、特別なインストールなしで誰でも試すことができる。例えば、ピンインから中国語への変換、ローマ字からひらがな・漢字への変換、ヒンディー語のラテン文字からデーヴァナーガリー文字への変換などが、Webブラウザ上で体験できる。さらに、VS Code、Slack、Notion、WeChatといったあらゆるネイティブアプリケーションでシステム全体にわたる変換機能を利用したい場合は、macOS、Windows、iOS、Android、Linux、ChromeOS向けの専用クライアントが提供されている。また、ローカル環境でオフライン推論を行うためのガイドも公開されており、利用者は自分の環境に合わせて最適な方法を選ぶことが可能だ。
このように、UnimeTypeは、従来の入力メソッドや一般的な翻訳ツールの限界を乗り越え、多言語を日常的に扱うユーザー、特にシステムエンジニアのような技術者が、ストレスなく、より効率的に文章を作成できる未来を提示している。この技術は、異なる言語が混ざり合う現代のデジタルコミュニケーションにおいて、私たちの作業効率を大きく向上させる可能性を秘めている。