日本語入力システムSumibiの開発 part16: アンビエント変換で変換キー不要に

はじめに

「アンビエントコンピューティング」という言葉をご存知でしょうか。テクノロジーが環境に自然に溶け込み、ユーザーが意識することなく動作する、という考え方です。
今回、この考え方を開発中のLLMを使った日本語入力システムSumibiに取り入れてみました。Emacsでローマ字を入力し続けていると、IMEが空気を読んで「今変換すべきタイミングだな」と判断し、自動で変換してくれる機能です。
これまでCtrl-Jで変換指示を出していた操作が不要になり、文脈に応じて適切なタイミングで自動変換が発動します。例えば、助詞「ni」「wo」「ha」や句読点「,」「.」「?」を検知したときに、自動的に変換が発動するようになっています。

高精度な変換エンジンが前提

自動変換を実用的にするには、「誤変換がほとんど起きない」ことが絶対条件です。変換後に修正が必要では、かえって効率が悪くなってしまいます。

Sumibiでは、GPT-5.1やGeminiなどの最新LLMを使ってローマ字かな漢字変換を行っているため、非常に高い変換精度を実現できています。実際に使っていても、誤変換（語彙の選定ミス）を修正することはほとんどありません。

この文章も、自動変換が有効な環境で書いています。ストレスなく執筆できているのは、変換精度の高さのおかげです。

ちなみに、2026年1月現在では、WindowsやmacOSの標準搭載IMEの変換精度はそれほど高くありませんので、従来型のIMEで同様の自動変換を実現するには、あと2〜3年は技術の進歩を待つ必要があるでしょう。
macOSのライブ変換を試された方はご存じだと思いますが、かなり誤変換があり、使いにくいと感じた方もいらっしゃるでしょう。

開発アプローチ

実装にあたっては、ヒューリスティックな対処を入れるなど、試行錯誤しながら改善しています。Claude Codeで開発しているので、トークンのリミットに達するまで何度でも試すことができ、実質的に体力は無限です。
実際にプロトタイプで試している内容について書いていきます。以下のようなタイミングで自動変換が発動するようになっています。

ローマ字の判定条件

1. ローマ字をできる限りひらがなに変換してみて、ひらがなになった文字数が50%以上の場合は変換する

2. 英単語辞書と照らし合わせて、80%が英単語にマッチしたら英語の文章と判断し変換しない。

ローマ字変換の発動タイミング

以下のタイミングで自動変換のチェックが行われ、上記の判定条件で「変換すべき」かどうかが決まります。

1. 句読点を検知したとき (. , ?)

句点や読点は、日本語の文や節の区切りとして使われます。このタイミングで変換を発動することで、自然な文章入力が可能になります。

例えば、shimashita. と入力すると、ピリオド . が検知された瞬間に しました。 へ自動変換されます。arigatou, yoroshiku. と入力すれば、カンマとピリオドのタイミングで ありがとう、よろしく。 と変換されます。

2. スペースを検知したとき

スペースキーは単語の区切りとして使われることが多いため、変換トリガーとして最適です。ただし、前述の判定条件により英語入力中は変換されません。

例えば、kyou とスペースを入力すると、 今日 に自動変換されます。続けて ha iitenki desu. と入力すれば、スペースとピリオドのタイミングで段階的に変換され、最終的に 今日はいい天気です。 となります。

自動変換してほしくないバッファなど

自動変換は便利な機能ですが、全てのバッファで有効にすると問題が生じる場合があります。以下のようなバッファでは、自動変換を無効にしています。

シェルバッファ (shell)

シェルバッファでは、コマンドラインでの操作が主体となります。ファイル名やコマンド名、オプション引数などはローマ字の連続で構成されることが多く、これらを日本語に変換してしまうと操作に支障をきたします。

例えば、ls -la Documents/project-alpha/ というコマンドを入力しようとした際に、ディレクトリ名が自動変換されてしまうと意図しない結果になります。また、Gitのブランチ名（feature/user-authentication）やファイルパス、環境変数名なども同様です。

前述の英単語辞書による判定があるものの、ローマ字のディレクトリ名やプロジェクト名は英単語として認識されない可能性があります。誤変換のリスクを避けるため、シェルバッファでは自動変換を完全に無効化しました。

暗号化ファイル (.gpg拡張子)

GPG（GNU Privacy Guard）で暗号化されたファイルには、パスワードや秘密鍵、個人情報などの機密データが含まれている可能性が高いです。

Sumibiは変換処理にLLM（GPT-5.1やGemini）を使用するため、入力された文字列はOpenAIやGoogleのAPIサーバーに送信されます。暗号化ファイルの内容を復号化した後に編集する際、その内容が外部APIに送信されることは、セキュリティ上のリスクとなります。

パスワードマネージャーのデータベースや、SSH秘密鍵、API認証情報などの機密ファイルを扱う場合、誤ってクラウドに送信されることは絶対に避けなければなりません。そのため、.gpg拡張子のファイルでは自動変換を無効にし、機密情報の漏洩を防ぎます。

ミニバッファ

Emacsのミニバッファは、ファイル名やバッファ名、コマンド引数などの入力に使用される特別な入力エリアです（M-x find-fileやM-x grepなど）。このエリアで自動変換が発動すると、操作に大きな支障をきたします。

例えば、M-x find-fileでa.txtというファイル名を入力しようとした際、ドット.のタイミングで自動変換が発動してしまい、意図しない文字列に変換されてしまいます。また、M-x grepでコマンドを入力中に句読点で自動変換が発動したり、バッファ名やディレクトリ名の入力中に誤変換が発生したりすると、作業効率が著しく低下します。

ミニバッファでの入力は、日本語の文章ではなく、システムへの指示や識別子の入力が主な用途です。そのため、ミニバッファでは自動変換を完全に無効化し、正確な入力を保証します。

おわりに

今回紹介した自動変換機能は、日常的な文章入力を大きく効率化してくれます。LLMの高い変換精度のおかげで、同音異義語の誤変換に悩まされることはほとんどありません。

ただし、Sumibiには制約もあります。文章の語彙選択はLLMに委ねられるため、「どの単語を漢字で書くか、ひらがなで書くか」といった細かな表記の制御が必要な文章には向いていません。小説や公式文書など、言葉の選択を厳密に管理したいユースケースでは、従来通り手動で変換を確定する方が良いでしょう。

一方で、現代のタスクでは、コーディングエージェントへの指示出しや、チャットでのクイックなコミュニケーションなど、時間効率が重視される場面が増えています。こうした用途では、Sumibiの自動変換が真価を発揮します。

いずれは、WindowsやmacOSの標準IMEにも同様の機能が搭載される日が来るかもしれません。それまでの間、Sumibiで快適な日本語入力を楽しんでいただければ幸いです。
(注意:自動変換は開発中です)