なぜ、LLM AIは日本語予測変換が死ぬほど得意なのに、LLM利用IME搭載のPCやスマホは存在しないのか？

はじめに

大規模言語モデル（LLM: Large Language Model） は、膨大なテキストデータを学習して人間に近い自然な文章を生成できる能力を持ち、近年のAI技術を象徴する存在となっています。チャットボットやコード自動生成、要約など、多様な分野で活用されています。

その一方で、日常的に最も頻繁に使うツールである日本語入力システム（IME: Input Method Editor）には、いまだにLLMは本格的に組み込まれていません。Google日本語入力、ATOK、Microsoft IME、Apple日本語入力（macOSやiOS標準IME）といった主要IMEはいずれも、依然としてN-gramやLSTMといった軽量な統計的言語モデルを基盤としています。

これは直感的には不思議に思えます。ChatGPTなどに日本語を入力すれば、漢字変換・語法補完・文法整合性のいずれも極めて高精度に行われるため、IMEとの相性は非常に良いと考えられるからです。

それにもかかわらず、なぜLLM搭載IMEは存在していないのでしょうか。本稿ではその理由を技術的・経済的・運用的観点から整理し、さらにそれが実現したときに副産物的に現れるスタンドアロン通訳ツールの可能性にも触れます。

既存IMEにおけるN-gram・LSTMの役割

現在の主要IMEは、内部で以下のような言語モデルを組み合わせて動いています。

N-gramモデル

N-gramは、直前のN個の単語（または文字）の並びから次に来る単語を確率的に推定する単純な統計モデルです。たとえば「東京にいきたい」と入力する際、「東京」「に」「いきたい」という3-gramを参照し、「東京」の直後には「に」が現れやすい、という過去の統計に基づいて予測します。

• Google日本語入力は、ウェブ上から収集した大量のテキストデータを元に作られた巨大なN-gramモデルを搭載しています。単語やフレーズの出現頻度や共起確率をもとに候補順位を決める仕組みで、非常に軽量で高速です。
• Microsoft IME（Windows標準IME）も基本はN-gramベースで、Microsoft Bingなどから得た大規模なテキストデータの頻度情報を統合しています。
• Apple日本語入力もmacOS/iOS標準IMEとしてN-gramベースを中心に、ユーザーの入力履歴を統計的に学習して予測精度を上げています。
• ATOKも長年にわたりN-gramベースを採用しており、連文節変換や文法規則ベースの解析器と併用することで安定した動作を実現しています。

N-gramは文脈を理解せずとも動作できるため、非常に高速かつメモリ消費が小さく、バッテリーへの負担も軽いという特徴があります。
一方で、文全体の意味や構造は考慮できないため、「文意に沿った自然な文章を生成する」という点では限界があります。

LSTMモデル

**LSTM（Long Short-Term Memory）**は、再帰型ニューラルネットワーク（RNN）の一種で、テキストのような時系列データを扱うために設計されたモデルです。過去の単語情報を内部メモリに保持しながら新しい単語を予測するため、N-gramより長い依存関係を扱うことができます。

近年、一部のIMEではこのLSTMを補助的に取り入れています。

• Google Gboard（Android版Google日本語入力）では、スマホ上で動作する軽量なLSTMモデルを組み込み、N-gramだけでは扱いにくいユーザー固有の文脈や時系列パターンを学習するようになっています。
• Apple日本語入力でも、iOSの内部で軽量ニューラルネット（RNN/LSTM）を組み合わせることでユーザーごとの予測精度を向上させています。

LSTMはN-gramより文脈把握が得意ですが、それでも数十単語を超える長い文脈になると性能が低下しやすく、また計算が直列的なので大規模化すると非常に遅いという弱点があります。

なぜLLMではなくN-gram/LSTMが選ばれ続けているのか

このように、主要IMEはN-gramを基盤とし、LSTMを補助的に導入する構成をとっています。
これには明確な理由があります。

• N-gramやLSTMは極めて軽量で低遅延
• メモリやストレージ消費が小さく、スマホにも適合
• GPUやNPUを必要とせず、CPUだけでミリ秒単位で動作可能
• 安定性が高く、予測の失敗で入力体験を壊さない

これに対し、LLMは圧倒的に高精度ですが、後述するように推論にGPU的な積和演算ユニットを必要とし、巨大で重く、遅延が大きいという性質があります。

つまり、IMEという「常時動作・低遅延・省リソース」が絶対条件のソフトウェアにとって、LLMは物理的・構造的にまだ重すぎるのです。

LLM推論にはGPU的な積和演算ユニットが必須で、IMEの即応性と相容れない

LLMの推論は、数千万〜数十億以上のパラメータを用いた巨大な行列演算を必要とし、GPU的な積和演算ユニット（MAC: Multiply-Accumulate）を必須とします。

IMEは入力するたびに即座に候補を提示する必要があり、数ミリ秒以内の応答が求められます。しかし、CPUは逐次的な処理に適した汎用プロセッサであり、膨大な積和演算を高速にこなすには不向きです。そのため、LLMをリアルタイムIMEに組み込むにはGPUやNPUといった専用演算器を常時占有する必要があります。

しかしスマホやPCでは、GPU/NPUを常時使用する設計にはなっておらず、他のアプリとのリソース競合や電力・発熱の制約もあって、常駐IMEでGPUを占有することは事実上不可能です。

GPU/NPUを常時動作させると、電力・発熱・パフォーマンスに深刻な影響が出る

GPU/NPUは高負荷演算を得意とする一方で、稼働中は数W〜数十Wの電力を消費します。IMEがこれらを常時利用すると、

• スマホでは発熱やバッテリー急減
• PCではバッテリー駆動時間の短縮やファン常時稼働
• 他のアプリとのGPUリソース競合

といった問題が起こります。

IMEは「常駐・低負荷・即応答」が前提なので、高負荷ハードウェアと設計思想が根本的に合わないのです。

モデルサイズとメモリ・ストレージ制約

高精度な日本語生成を行うには、数億〜数十億パラメータ規模（数百MB〜数GB級） のモデルが必要です。

IMEはOS起動直後から常駐し、常に即応答が求められるため、巨大モデルのロードやキャッシュで遅延が生じる構造は不適です。また、他アプリとのリソース共有を圧迫する恐れもあります。

クラウド実行も現実的ではない

クラウド実行で端末負荷を避ける方法もありますが、これには

• 通信遅延（数百ms単位でも体感悪化）
• 通信圏外で動作不可
• 入力内容を送信することへのプライバシー懸念
• 膨大なGPUコストによる採算性の問題

などの制約があります。通信遅延とコストの両立は現実的ではありません。

蒸留・量子化など軽量化技術でも根本的制約は解消できていない

蒸留や量子化により、巨大モデルを数十MB程度まで圧縮する研究は進んでいます。しかし、

• 軽量化しても構造上、積和演算量は多いまま
• CPUでは遅く、GPU/NPUは電力が大きい
• IMEに必要な「数ms以下・数W以下」の条件を満たせない

といった理由から、根本的な実用条件をまだ満たせていません。

LLM搭載IMEが実現すれば、スタンドアロン通訳ツールも同時に実現する

ここまで述べてきたとおり、IME用のLLMをオンデバイスで動かすには軽量・高速・省電力なNPU推論基盤が必要です。
実はこれは、そのままスタンドアロン通訳ツールにも転用できます。

• IMEはキーボード文字を受けてテキストを返す
• 通訳ツールは音声入力を受けてテキスト（または音声）を返す

という違いこそありますが、どちらも本質的には「入力文脈を理解して次に来るテキストを生成する」という同じLLM推論タスクです。

項目	IME	通訳ツール
入力	キーボード文字列	音声（→音声認識でテキスト化）
処理	テキスト→テキスト	テキスト→翻訳テキスト（→音声合成）
出力	テキスト候補	音声またはテキスト訳文

つまり、IME用に作った軽量LLMは、そのまま通訳器にも使えるのです。
これにより、通信圏外でも動作する完全オフライン通訳が可能となり、災害現場・山岳・軍事・航空といった分野での即応性や安全性にも大きな価値を持ちます。

まとめ

LLMは本質的に日本語予測変換に非常に適しています。しかし、IMEが要求する「常駐・即応答・低負荷」という条件は、現状のLLMが持つ「高負荷・大規模・GPU依存」という性質と根本的にかみ合っていません。

特に以下の制約が、LLM搭載IME実現を阻んでいます。

• GPU/NPUを常時使わないと間に合わない計算量
• 常時稼働による電力・発熱・リソース競合
• モデルサイズとメモリ/ストレージ制約
• クラウド実行は遅延・コスト・プライバシー問題で非現実的
• 軽量化してもIME用途の条件を満たせていない
• 無料IMEというビジネス構造上、投資回収が難しい

一方で、NPU搭載端末と軽量LLMの登場によって、端末内でLLM推論を実用的に動かすための基盤は整いつつあります。
これが実現すれば、IMEの爆速化だけでなく、スタンドアロン通訳ツールも副産物のように同時に実現される可能性が高いのです。