Mozkey（もずきー）

Mozc をベースに、通常変換・遅延付きライブ変換・ローカル Zenz 補正を組み合わせ、
縦書き対応・外観カスタマイズ・柔軟な入力操作と学習制御を備えた日本語入力ソフトウェアです。

Mozkey（もずきー）は google/mozc をベースにした非公式フォークです。

Mozkey は、Mozc の通常変換を基盤に、遅延付きライブ変換、ローカル Zenz による文脈補正、縦書き対応、柔軟な外観・入力操作のカスタマイズを組み合わせた日本語入力ソフトウェアです。Mozc の変換資産を活かしながら、候補の表示方法から学習の仕組みまで、使い手に合わせて調整できます。

本プロジェクトは Google 日本語入力ではありません。 Google または google/mozc の公式配布物ではありません。 Google によるサポートや品質保証の対象ではありません。

upstream Mozc との追従性および既存インストールとの互換性を保つため、 一部の内部実行ファイル名、パス、実装上の識別子には mozc / Mozc 名が残ります。

Mozkey の特徴

• 遅延付きライブ変換とルビ表示： スペースキーを押す前から未確定文字列を変換。開始までの待機時間や文字数、読みを示すルビ風の表示を調整できます。
• Mozc と Zenz の二層構成： Mozc の通常変換を維持しながら、ローカルの Zenz で文脈に応じた補正を追加。補正が適さない場合は Mozc の結果へ戻せます。
• 文脈と表記を尊重する補正： 前後の文脈を利用し、助詞・機能語や文節のつながりを改善。ユーザー辞書、英字・技術用語、数字、記号の表記を不用意に置き換えないための保護も備えています。
• 選べる Zenz の表示タイミング： 通常のライブ変換結果を先に表示する動作に加え、Zenz の応答を一定時間待ってから表示する方式も選択できます。
• 学習と候補のコントロール： Zenz の採用・却下フィードバック、保存済み結果の再利用、Mozc 変換履歴への学習を個別に設定。学習データの管理、候補の履歴削除・非表示、確定直後の取り消しにも対応します。
• 縦書きに対応した入力 UI（Windows / macOS）： 候補・サジェスト・用例・ルビを縦書きに合わせて配置し、対応するキー設定では候補や文節の移動方向も調整します。
• 変換状態インジケータ（Windows / macOS）： 未確定文字の近くで「入力中・Mozc・Zenz処理中・Zenz適用済み」を表示し、配色・形状・位置を調整できます。macOS での新しいインジケータの実機検証は未完了です。
• 幅広い外観カスタマイズ： 候補・サジェスト・ルビの配色（ライト／ダーク／自動／カスタム）、サイズ、角丸、透明度、影を個別に設定。Windows ではフォント・文字の太さ・未確定文字の色や下線、IME インジケータも調整できます。
• 柔軟なローマ字入力とキー設定： ローマ字テーブルの編集、曖昧な規則の途中表示、句読点・記号の単打確定、複数コマンドや待機ステップを組み合わせたキー割り当てに対応します。
• 日本語の変換品質と辞書の拡張： 日常語彙・固有名詞・口語表現を補強し、文節分割や不自然な漢字化を抑制。日付・曜日の変換候補も拡張しています。
• ローカルファーストと OS 連携： Zenz の推論はローカルで実行し、利用統計の送信機能を無効化。シークレット入力への配慮や、Windows Search などの入力欄での候補表示にも対応しています。

詳しい仕様・設定項目は、下記の「主な追加機能」と「修正詳細」で説明しています。

ダウンロード / インストール

現在 GitHub Releases で公開しているビルド済みインストーラーは Windows 向けです。各リリースで実際に利用できるファイルは、その Release の Assets を確認してください。macOS Universal PKG は開発・検証中で、まだ一般公開していません。

• Windows x64: x64 向け MSI を使用してください。
• Windows ARM64: ARM64 向け MSI が公開されているリリースでは、その MSI を使用してください。ARM64 版は Mozkey 本体と Zenz runtime をネイティブ構成で含みます。
• macOS: Apple Silicon / Intel 対応の Universal PKG を開発・検証していますが、現時点では Releases から配布していません。
• Linux: upstream Mozc は Linux に対応していますが、Mozkey 固有の機能は未検証で、インストーラーも公開していません。

Windows の universal MSI は、製品全体を x64 / ARM64 の両方でネイティブ動作させるパッケージではありません。通常の利用では、対応するアーキテクチャ専用 MSI を優先してください。Zenz 同梱パッケージにはローカル推論 runtime と GGUF モデルが含まれるため、ファイルサイズが大きくなります。Windows 向け MSI にはローカル生成の daily 辞書が含まれる場合があります。出典とライセンスは Third-party notices を参照してください。

[!NOTE] Mozkey は Google または google/mozc の公式配布物ではありません。現時点で公開中の Windows MSI は未署名で、OS によっては警告が表示されます。開発用 macOS PKG は Apple Developer ID 署名・公証済みの一般配布物ではありません。macOS の警告については Apple の案内 を参照してください。

コード署名ポリシー（Code signing policy）

現在公開しているWindows向けMSIインストーラーは未署名です。MozkeyはSignPath FoundationのOSS向け無料コード署名への申請を準備しています。現時点でSignPath Foundationの承認を得ている、または署名済みリリースを公開しているという意味ではありません。

署名対象の予定、開発・承認の責任体制、プライバシー、およびリリースの検証方法については、Code signing policyを参照してください。

macOS の初期設定（検証用PKG）

現在、一般向けの macOS PKG は公開していません。次の手順は、検証済みのインストール可能な開発用 PKG を導入した場合のものです。通常の OSS ビルドで作成される guarded PKG は、誤インストール防止のためインストールを拒否します。詳細は macOS インストーラーの検証手順 を参照してください。

1. PKG をインストールしたら、「システム設定」→「キーボード」→「テキスト入力」の「編集」を開きます。
2. 「Hiragana (Mozkey)」（環境によっては「ひらがな（Mozkey）」）が登録されているか確認します。なければ「+」→「日本語」から追加します。
3. メニューバーの入力メニューで Mozkey のひらがな入力ソースを選択します。
4. 入力ソースが表示されない場合は、macOS からログアウトして再ログインし、もう一度確認してください。

詳しくは Apple の入力ソース設定ガイド を参照してください。

主な追加機能

• 曖昧なローマ字規則でも途中表示できるオプションを追加
• ローマ字テーブル編集画面に、そのオプション用のチェックボックス UI を追加
• カスタムローマ字テーブルの 1 規則あたりの出力を UTF-8 で 1024 bytes 未満まで扱えるように拡張。入力・次入力の上限は従来どおり 300 bytes 未満
• 句読点・記号を単打で確定できるオプションを追加
• 単打確定の対象を設定画面のチェックボックスで選択可能
• 句読点変換と句読点・記号の単打確定は排他的に動作
• 変換確定直後に Backspace や Cancel キーで取り消した場合のユーザー履歴学習の扱いを改善
• 変換中に Esc / Ctrl+Z などのキャンセル操作でひらがなへ戻し、そのまま Enter または句読点・記号の単打確定で確定した場合、F6 ひらがな化確定に近い表記選好として学習されるようにした
• 複数文節の変換キャンセル後は、キャンセル直前の文節境界を可能な限り保持し、全体 1 件としてではなく文節単位のひらがな表記選好としてユーザーセグメント履歴へ反映
• 句読点・記号の単打確定でも、直前の通常変換確定による学習を次の実テキスト入力まで保留し、Backspace / Escape / Ctrl+Z などの Cancel 相当キー / Revert / Reset / Undo などでは取り消し、IMEOff / MakeSureIMEOff では確定扱いにするようにした
• ライブ変換機能を追加。未確定文字列を自動変換し、確定前の読みをルビ風 overlay で表示
• ライブ変換は設定画面から ON/OFF、変換開始までの遅延時間、変換開始の最小文字数を変更可能
• ハイフンなし7桁の郵便番号（例：1000001）を、既存の郵便番号辞書を使って住所へ変換可能。ライブ変換では数字表記を第1候補に保ち、キー設定の ConvertNext（次候補、標準では Space）で住所などの後続候補を選択可能
• ライブ変換を使わない場合も、既定で初回の変換操作で第1候補のまま候補ウィンドウを開ける（設定で無効化可能）
• ライブ変換は入力直後の不要な変換ちらつきを抑えるため、文字入力後に短いデバウンスを挟んで実行
• ローマ字入力中、単なる未解決の Roman suffix では直前の passive suggestion を保持して候補ウィンドウのちらつきを抑制。一方、カスタムローマ字規則の「曖昧なローマ字規則の途中表示」によって有効な読みが現れ、予測クエリが変化した場合は、suffix が未解決のままでもサジェストを更新。候補へ移動する場合は画面に表示中の候補集合を使用
• 明示的に選んで確定したサジェストについて、候補が持つ全文の読みと、通常変換で検証できた文節・候補順位を使ってユーザーセグメント履歴の学習を補強。確定結果やサジェスト履歴は従来どおり維持し、検証できない文節や順位は推測で学習しない
• デフォルトでは 1 文字だけの未確定文字列で、助詞などの誤変換を避けるためライブ変換を実行しない
• え~、えー、ん？ のような「かな1文字 + 装飾的な末尾記号」でも、短すぎる漢字化を避けるためライブ変換を抑制
• うっそ、くっそ、やっば、すっげぇ、めっちゃ、ちっす、ちょりっす、ほえ～、ほぇ～、ほっほーん などの expressive kana を生成辞書で自然なかな候補として補強
• 確定済みの左文脈や直前の文節、限定的な右文脈を参照し、mainにマージしました、githubには、彼になった、彼なのか、2名しかいない、追記したい、山梨県立美術館、滋賀方面 のような文脈で、助詞・複合機能語・名詞相当の左文脈に続く叙述・疑問の機能語列・機能表現・接尾的な語構成・地名接尾構成が同音漢字候補に負ける挙動を抑制
• キー設定エディタで、1つのキー入力に対して複数のコマンドを順序付きで割り当て可能
• ForceZenzLiveCorrection により、未確定文字列へ手動で Zenz 補正を要求可能。Zenz の自動ライブ補正が OFF でもキー設定から明示実行できる
• ForceZenzLiveCorrectionWithoutFeedback により、保存済み Zenz feedback の自動利用をこの実行に限り無視して手動補正可能。通常の Mozc 履歴・ユーザー辞書および明示的な手動ブロックは維持し、新しい確定結果の学習も設定に従う
• キー設定のコマンド列に Delay(700) などの待機ステップ（0～5000 ms）を追加。選択文字列の再変換後に待機して手動 Zenz 補正する操作にも対応
• 変換候補・予測候補をキー操作から履歴削除または非表示にできる機能を追加。標準キー設定では Ctrl+Delete を使用し、履歴から削除できる候補はまず学習履歴だけを削除。それでも残る候補はユーザー辞書「非表示候補」の抑制単語として登録し、元のユーザー辞書候補そのものは削除しない。「非表示候補」から該当する抑制単語を削除すると再表示可能。候補ウィンドウのフッターには、選択中の候補の状態と現在のキー設定に応じて履歴削除または候補非表示の操作案内を表示
• 通常変換では、Mozc が顔文字として意味的に識別できる候補（標準の顔文字候補、およびユーザー辞書で品詞「顔文字」として登録された候補）が、学習によって第1候補へ上がらないように制御。候補自体は一覧に残し、同じ表記でも「顔文字」以外の品詞として登録した候補は通常の順位付け・学習を許可。Zenz が独立して生成した表記は、文字列の見た目だけを理由に顔文字扱いしない
• 標準の EmojiRewriter が生成する絵文字候補についても、通常変換の第1候補へ学習で昇格しないように制御。絵文字自体は候補一覧に残し、同じ表記をユーザー辞書で「記号」などとして明示的に登録した場合は通常の順位付けを許可
• 複数コマンドは Commit|IMEOff のような形式で保存され、設定画面では Commit → IMEOff のように編集可能
• MS-IME 風キー設定では、確定済み文字列を選択した状態で Space を押すと再変換し、未選択時は従来どおり空白を入力
• Windows 版のキー設定で、Ctrl / Shift の左右条件を独立して「左右どちらでも / 左のみ / 右のみ」から選択可能。従来の汎用 Ctrl / Shift 割り当ても維持し、競合する異なるコマンドの割り当ては保存時に検出
• Windows 版で IMEOn / IMEOff に割り当てたキーを押した場合、すでに同じ状態でも IME モードインジケータを表示
• Windows 版で Shift などによる一時的な半角英数字入力中に IMEOn を押すと、未確定文字列を確定せずにひらがな入力へ復帰
• Windows 版の設定画面から、Mozkey を Windows の既定 IME として明示的に設定し、変更前の既定 IME 設定へ戻せるボタンを追加
• Windows 版の設定画面から、タスクバーや IME 一覧に表示される Mozkey の IME アイコンを、既定 / モノクロ（ライト・ダーク対応）/ モノクロ（黒）/ モノクロ（白）から選択可能
• Windows Search などの immersive TSF ホストでは、候補ウィンドウ・サジェストウィンドウ・ライブ変換中のルビをホストプロセス内の renderer 経路で表示し、前面表示とマウス操作を安定化。未選択のサジェストは mouse-down だけで通常変換へ移行せず、mouse-up で実際に押したサジェストを確定
• Windows / macOS 版の候補ウィンドウ・サジェストウィンドウ・ライブ変換中のルビ表示について、ライト / ダーク / 自動（システムテーマに合わせる）/ カスタム配色、サイズ、角丸、透明度、影を設定画面から個別に調整可能。新規設定では3項目とも「自動」が既定
• Windows 版のルビ表示は、表示先モニターの DPI に合わせて位置・サイズを補正し、左右の余白、上下の余白、入力文字との距離を設定可能
• サジェストウィンドウとルビ表示は、候補ウィンドウの配色に追従するか、個別のテーマ・カスタム配色を使うかを選択可能。「自動」は各ウィンドウがシステムテーマを直接参照し、「候補ウィンドウに追従」とは別の設定
• Windows 版の候補ウィンドウ・用例ウィンドウ・ライブ変換中のルビ表示に使うフォントを設定画面から変更可能
• Windows 版の候補ウィンドウ・サジェストウィンドウ・ライブ変換中のルビ表示について、主要テキストの太さを 100～900 の範囲で個別に設定可能
• Windows / macOS 版の縦書き入力で、候補ウィンドウ・サジェスト・用例表示・ライブ変換中のルビを縦書きレイアウトとして表示し、対応するキー設定では候補・文節移動も視覚方向に合わせて操作可能
• Windows / macOS 版では、縦書き時の連鎖候補ウィンドウを現在候補から本文の外側へ展開するよう配置し、必要に応じて反対側へフォールバック
• ライブ変換中のルビ表示を設定画面から ON/OFF 可能
• Windows / macOS 版に、未確定文字の近くで「入力中 / Mozc / Zenz処理中 / Zenz適用済み」を示す変換状態インジケータを追加。ルビとは独立して表示でき、位置・状態別配色・形状・フォント・サイズ・影を設定可能
• Windows 版で未確定文字の文字色・背景色・下線色を設定画面からカスタマイズ可能。「入力中の文字」「変換中の文節」「Zenz 補正中の文字」を個別に設定でき、「Zenz 補正中の文字」の下線は新規・未設定プロファイルで既定 ON、既定色は #C4DC6C
• Windows 版のローマ字入力で、変換規則の途中にある末尾の未確定ローマ字だけを薄く表示する opt-in 機能を追加。既定は OFF で、薄さは 0～100%（既定 85%）の範囲で調整可能。100% は背景色と同じになり不可視
• Windows 版の IME 切り替えインジケータは、設定画面から「システムテーマに合わせる / ダーク / ライト / カスタム」を選択可能。カスタムでは入力モード別の配色とサイズ・角丸・枠線・影を調整でき、画面端付近では表示位置を自動調整
• Windows TSF の IS_PRIVATE が指定された入力では、保存済みの Mozc 学習履歴と Zenz feedback を引き続き利用しながら、新しい永続学習を書き込まない。Mozkey のシークレットモードとは別に扱い、private input 中はタスクバーの入力モード表示と IME 切り替えインジケータに盾を表示。タスクバーの通常入力モード・private・無効表示は Windows のライト / ダークテーマへ追従
• system dictionary 強化用の追加辞書生成パイプラインを追加
• 日常語彙・実務語彙・外来語・英語綴り候補を小さな manual override 辞書として段階的に補強し、通常語彙は自然な第一候補、英語綴りは補助候補として扱う評価運用を追加
• merge-ut-dictionaries 由来の地名・SudachiDict 系語彙を system dictionary に取り込めるようにした
• dic-nico-intersection-pixiv 由来のネット・サブカル系固有名詞を、既存辞書との差分として daily 辞書に追加可能
• mozcdic-ut-personal-names 由来の人名辞書を、既存辞書や nico/pixiv delta との重複を除いた弱い daily 辞書として追加可能
• 文節区切り崩れを抑えるための syntax guard 辞書を daily 辞書生成パイプラインに追加し、と打ちたいのに、に分ける、した方が、したにもかかわらず、にまで、までに、までも、肌身離さず などの高影響な経路を保護
• 大規模な生成辞書は Git に含めず、ローカルで再生成して Bazel の辞書入力へ切り替える運用に
• には や してたの のような自然な機能語かな列が、二は や して他の のような 1 文字漢字候補に過剰変換される挙動を抑制
• にじ のような 2 文字ひらがな入力で、に|じ のような短すぎる文節分割が全体候補を隠す挙動を抑制
• 日付入力を強化し、20260927 のような8桁数字や、2026/9/27、2026-9-27、2026.9.27、9/27 などから日付候補を生成。全角入力にも対応し、存在しない日付は日付候補として展開しない
• きんよう / きんようび などの曜日入力では、通常の「金曜」「金曜日」を優先したまま、今週・来週・先週の該当日を追加候補として提示
• ほんじつ / みょうにち などの日付表現を補強し、9/27 など明示的に入力された日付表記は候補順位でも尊重
• llama.cpp ベースのローカル Zenz live correction pipeline を追加
• Zenz 文脈処理を共通化し、通常 Mozc の preceding_text / following_text とは分離した zenz_preceding_text / zenz_following_text を使用
• Zenz が必要とする preceding / following の長さを Server から Client へ通知し、Windows TSF / macOS IMK では要求された方向・長さだけ surrounding text を追加取得。右文脈は有効時に設定可能で、取得長の既定は 6 文字
• Zenz の前方・後方文脈を用途に応じて独立して選択し、Unicode-aware な文字種判定と privacy filtering を共通処理として適用
• Windows 版では、Zenz 補正を mozc_server から named pipe 経由で mozc_zenz_scorer.exe に依頼し、llama-server.exe の localhost endpoint でローカル推論
• Windows の Zenz named pipe では、同名パイプの先取りとリモート接続を拒否し、クライアントが接続先 scorer のセッション・ユーザー SID・実行イメージパスを入力送信前に照合。検証できない接続先にはプロンプトを送信しない
• Zenz 補正開始までの遅延時間を設定画面から変更可能。新規・未設定時のデフォルトは 700 ms（保存済みの設定値は維持）
• Zenz 補正開始の最小文字数を設定画面から変更可能
• 「Zenz 補正結果が返るまで通常のライブ変換結果を表示しない」opt-in 設定を追加。待機中は直前まで安定して表示されていた Zenz 補正部分を可能な範囲で維持し、未解決のローマ字 suffix はその表示へ追従。Zenz が採用されない場合は現在の Mozc ライブ変換結果へフォールバック
• deferred 表示専用の最大待機時間を設定画面から変更可能。既定は Zenz 補正要求の送信後 250 ms で、期限を超えた generation は破棄して、すでに計算済みの Mozc ライブ変換結果へフォールバック
• deferred 表示中の Enter / Shift による英字入力では、裏側の Mozc baseline ではなく、その時点でユーザーに見えている presentation を確定。Enter 確定後の Undo でも同じ presentation を復元
• Zenz 出力が確定済み左文脈の長い suffix を現在入力の先頭へ反復する context echo を検出して拒否し、通常の Mozc ライブ変換結果へフォールバック
• Zenz の最終候補が通常 Mozc 変換結果の明白な先頭・末尾の欠落になっている場合は、逆変換を使わない軽量な検証で拒否。保存済みフィードバック由来の候補にも適用し、確定済み左文脈の表記と現在の入力が重なる境界が曖昧な場合は、無理に左文脈を削らず通常 Mozc 結果へ戻す
• 「厳密な読み保持（実験的）」を追加。初期値は OFF で、ON の場合のみ Zenz 最終候補を逆変換して入力した読み全体と照合。読みが一致しない場合や取得できない場合は通常 Mozc 結果へ戻すが、正しい候補や保存済みフィードバックの補正が採用されない場合があり、処理時間も増える可能性がある
• Zenz の学習機能を「Zenz 学習（Mozc変換履歴）」と「Zenz 学習（補正フィードバック）」に整理し、次の3設定を独立して ON/OFF 可能にした。A：Zenz 補正の採用・却下を TSV に記録する、B：保存済み feedback を候補順位・高速再利用・自動ブロックへ利用する、C：明示的に確定した Zenz 補正を Mozc の通常変換履歴へ追加学習する。A=OFF でも B=ON なら既存 feedback を利用でき、A=OFF でも C=ON なら Mozc 履歴へ追加学習できる。旧統合設定からは未設定の新項目だけ値を引き継ぐ
• 同音異義語が多く文脈によって適切な表記が変わりやすい短い読みで、Zenz feedback の過剰な学習反映を避けるため、保存済み feedback の自動適用を既定では読み全体が 7 文字以上の場合に限定。設定画面から ON/OFF と最小読み文字数（1～20 文字）を変更可能。短い読みの採用・却下履歴は記録・保持し、手動ブロックは引き続き有効
• シークレットモードでは Zenz のローカル推論を継続したまま Zenz feedback personalization（学習・保存済み feedback の再利用）を無効化。新しい feedback は保存せず、既存 feedback 自体は削除しない
• Zenz feedback の自動ブロック設定を追加。同じ読み全体・同じ文脈クラス・同じ補正結果について、通常却下回数が「最低拒否回数」と「採用回数 + 通常却下回数に占める最低拒否割合」の両方に達した場合だけ自動ブロックする。未保存の設定では既定で有効、最低拒否回数は 1 回、最低拒否割合は 50%。自動ブロックは TSV に hard reject を固定保存せず、現在の設定と既存 feedback から動的に再評価する
• 自動ブロック中も Zenz 推論は shadow observation として継続する。同じ読みで非表示の Zenz 結果と最終確定値が一致すれば accepted feedback を加算して自己回復でき、拒否割合がしきい値を下回れば自動的にブロックを解除する。同じ読みで異なる値が確定した場合は通常却下を加算し、入力継続などで最終的な読みが変わった場合は neutral として扱う。明示的な hard reject はこの自己回復の対象外
• 同じ読み全体・同じ文脈クラス・同じ補正結果で通常却下回数が採用回数を上回る場合は、auto-block 無効時でも Zenz feedback による優先候補・保存済み feedback による即時補正としては使わず、「却下数優勢」の中立状態として扱います。これは hard block ではなく、Zenz が新しく同じ補正を返すことや通常 Mozc 候補を削除することはありません。
• フィードバック記録（A）が ON の場合、Zenz 補正結果が表示されただけでは保存せず、Enter や句読点・記号の単打確定などで明示的に確定された時点で accepted feedback をローカル TSV へ即時保存する。採用記録の書き込みに失敗した場合は、Undo で補償レコードを追記して以前の正常な採用履歴を減算しないようにする
• rollback window 内の Backspace / Escape / Revert / Undo / Ctrl+Z などでは、書き込みに成功した accepted 記録だけ accepted_rollback で補償する。これは rejected feedback ではない。Mozc 変換履歴（C）の取消は別の可逆履歴ハンドルで処理する。次の実テキスト入力や確定後の context transition で window が閉じた場合は accepted を保持し、IMEOff / MakeSureIMEOff も確定扱いにする
• Zenz 補正表示後に Space や候補移動などで通常変換へ移った場合は、その操作だけで rejected feedback を即時確定せず、通常 Mozc 側で最終的に確定された値を確認してから判定する。最終確定値が Zenz 補正結果と異なる場合は通常却下として記録し、同じ結果を確定した場合は不要な reject を残さない。通常操作由来の rejected feedback は候補を殺す hard reject ではなく、順位調整用の弱い negative signal として扱う
• Zenz 補正表示中に Space で Mozc 通常変換結果へ戻した場合は、次の文字入力や句読点・記号の単打確定で、戻した通常 Mozc の結果を先に最終確定値として取得する。句読点・記号の単打確定後も短い rollback window を維持し、直後の Backspace / Escape / Ctrl+Z / Revert / Undo などでは pending な Zenz reject を破棄する。次の通常入力や確定後の context transition、Windows Search などでの pass-through Enter を含む通常の pass-through 操作へ進んだ時点で rollback window を閉じ、最終確定結果に基づいて feedback を確定する
• Zenz のフィードバック学習データを設定画面から管理できる UI を追加。TSV を直接編集せず検索、インポート、エクスポート、選択項目削除、全削除が可能。ここで管理・削除するのは A/B の記録であり、C で Mozc の通常変換履歴に学習済みの内容は削除しない
• フィードバック学習データ管理画面から、選択した Zenz 補正を明示的に手動ブロック可能。手動ブロックは B の自動利用設定が OFF でも Zenz 補正の採用判定に有効。解除するには該当エントリを削除し、必要なら再学習する
• B が ON の場合は Zenz feedback を通常変換候補の ranking に利用。1 文節の通常変換では保存済み feedback を score 化し、既存候補の cost を調整するか synthetic candidate を自然な位置へ追加。accepted は順位を上げ、通常操作由来の rejected は候補を除外せず順位を下げる
• 文節境界を壊さないため、複数文節に分かれた通常変換では Zenz feedback による通常候補 ranking を行わない
• 複数文節に分かれるライブ変換では、全文補正の学習を保つため、accepted Zenz feedback を session-level live correction fast path として再利用
• sensitive-like context で得られた feedback は、通常文脈の候補 ranking / reuse には使わない
• Mozc 変換履歴への追加学習（C）が ON で通常の履歴学習・プライバシー条件を満たす場合、明示的に確定した Zenz 補正を commit 点で Mozc の user history に即時学習する。A の記録設定とは独立。学習後は in-process の rollback handle を保持し、直後の Backspace / Escape / Revert / Undo などでは Mozc history 側の学習を revert する
• accepted Zenz 補正は、直前の通常 Mozc ライブ変換文節へ安全に対応付けられる場合、既知の文節境界を優先してユーザー履歴を参照しない固定境界再評価を行い、必要な範囲だけ Mozc native の再文節化で検証してから外部 multi-segment commit として Mozc history に学習。複数の境界解釈が残る範囲や安全に解決できない範囲では、その推定境界を使った局所・境界学習を行わず、句読点などの区切りもまたいで学習しない。通常変換候補を再利用できる場合は candidate 構造を引き継ぎ、Zenz が実際に変更した語彙単位だけを強い選択履歴として扱う。安全な局所学習を1件も確定できなかった場合は、別経路の full-sequence Mozc-history fallback を試みる
• 通常 Mozc ライブ変換で現在の結果として現れているユーザー辞書由来候補や ASCII / mixed-script 表記を、Zenz live correction の採用時に保護
• ASCII / mixed-script 表記は、読みを安全に特定できる場合に Zenz prompt 内で一時 placeholder 化し、応答後に元の表記へ復元。もずきー -> Mozkey のような表記が モズキー へ上書きされるのを避けつつ、前後の文は補正できるようにした
• 通常 Mozc が選んだ表記を orthographic baseline として保持し、東京 -> Tokyo、コンピュータ -> computer のように Zenz だけが新しい英字表記を持ち込む場合は、文節へ安全に逆投影できる範囲で該当部分だけ通常 Mozc 表記へ戻す。GitHub、iPhone、AI、C++、GPT-5 など、通常 Mozc がすでに選んでいる Latin / technical token は維持する
• ASCII の数字リテラル（符号付き整数・小数を含む）は Latin / technical token とは分離して保護し、Zenz prompt 内では placeholder 化せずに残す。数字表記そのものと非日本語の隣接境界は維持しつつ、1日、100円、スマートフォン1台、第1回、3.14倍 のような日本語隣接部分は Zenz で補正可能にする
• Zenz が （ ） / ( )、？ / ?、！ / !、： / : などの記号幅・記号スタイルを正規化して返した場合でも、元の未確定文字列または通常 Mozc ライブ変換結果でユーザーが使っていた表記へ復元
• Zenz が左文脈などから ！ / !、？ / ?、。、…、〜 などの文末・表現記号を、現在の未確定文字列または通常 Mozc ライブ変換結果の末尾にある数を超えて追加した場合は、余分な末尾記号だけを抑制し、漢字・語彙などの補正結果は保持
• 日本語のみのユーザー辞書語は、自然な読みを Zenz prompt に残したまま、Zenz 応答後に表記の境界を検証し、余分なかな付着を安全に修復できる場合だけ採用するようにした
• Zenz prompt に使う左文脈は sanitizer を通し、URL、email、file path、token、長い数字列など sensitive-like な文脈は prompt に含めない
• Zenz feedback は full-sequence 単位だけを保存し、raw left context や segment-local feedback は保存せず、非可逆な context class のみを保存
• Zenz model / llama.cpp runtime の third-party license notice を MSI に同梱
• 自分の Windows / macOS 開発環境向けのビルド調整

プライバシー / ネットワークアクセス

この fork は、通常の IME 利用時に Mozc の実行時プロセスがネットワーク通信を行わない構成を目指しています。

upstream 由来の使用統計・クラッシュレポート送信オプションは、管理ダイアログおよび設定ダイアログから削除しています。

この fork では StatsConfigUtil のデフォルト実装を Null 実装に固定しており、通常の実行経路から使用統計を有効化できません。

Windows 向けリリースバイナリについては、Mozc core runtime executable が winhttp.dll, wininet.dll, urlmon.dll などの代表的なネットワーク関連 DLL を import していないことを検査します。

この fork では、llama.cpp ベースのローカル Zenz 推論 runtime を同梱する場合があります。Zenz runtime はローカル推論用として使用し、外部ネットワークサービスを公開したり、入力内容を外部サーバーへ送信したりする目的のものではありません。

Windows 向け Zenz 同梱構成では、llama-server.exe を 127.0.0.1 のみに bind するローカル推論 server として使用します。Windows 版の Zenz helper process は、同梱された llama-server.exe と localhost endpoint のみで通信します。この local HTTP endpoint は推論処理を分離するための内部的なプロセス境界であり、外部ネットワークアクセスを目的としたものではありません。

Zenz の localhost 通信は、固定 endpoint に依存しないようにし、内部 request も誤接続を避けるための保護を加えています。

Zenz feedback learning は、完全な読み、完全な候補、粗い文脈クラス、採用/却下回数、理由 marker などの full-sequence 単位のローカル学習情報だけを保存します。生の左文脈は保存しません。feedback に使う文脈は、empty、japanese_only、japanese_with_punctuation、mixed_japanese_ascii、sensitive_like などの非可逆な context class に落とします。segment-local や lexical-unit の学習は Zenz feedback TSV には保存せず、安全な局所学習は Mozc history 側の責務として扱います。

シークレットモードでは、Zenz のローカル推論自体は継続しますが、Zenz feedback personalization は無効になります。保存済み feedback は候補 ranking、session-level fast path、feedback decision に参照せず、新しい accepted / rejected / accepted_rollback feedback も保存しません。既存の feedback TSV は削除せず、シークレットモードを終了すると再び利用できます。

Windows TSF の IS_PRIVATE は、Mozkey のシークレットモードとは別の privacy signal として扱います。Chrome Incognito、Edge InPrivate、Firefox Private Browser など、入力欄の TSF input scope に IS_PRIVATE が含まれる場合、保存済みの Mozc 学習履歴（変換・サジェスト）と Zenz feedback は読み取り可能なまま維持し、Zenz のローカル推論も継続します。一方、その private input を起点とする新しい Mozc history、サジェスト履歴、Zenz feedback、および Zenz から Mozc history への永続学習は書き込みません。既存の学習データ自体は削除しません。IS_PRIVATE と password input scope は別に扱い、password field の既存の保護は維持します。

さらに、リリース時には Mozc core runtime binaries にテレメトリ、アップデータ、クラッシュアップロード、使用統計関連の危険な marker が含まれないことを確認します。

http://, https://, googleapis.com などの汎用的な URL 風 marker は、manifest、XML namespace、コメント、license file、ライブラリ metadata に由来する場合があるため、監査用に表示しますが hard failure にはしていません。

ソースからビルドする場合、ビルド依存関係の取得にネットワーク接続が必要になる場合があります。これは、インストール済み IME の実行時通信とは別です。

Windows 版では、追加のオフライン防御層として、インストーラーが Mozc の実行ファイルに outbound 通信をブロックする Windows Firewall rule を追加します。Zenz 同梱構成では mozc_zenz_scorer.exe と llama-server.exe も対象です。これらの rule はアンインストール時に削除されます。

関連ドキュメント:

• Secure Offline Guarantee
• Secure Offline Release Checklist

修正詳細

曖昧なローマ字規則の途中表示

このオプションを有効にすると、たとえば

• ms -> ます
• mst -> ました

のような規則で、ms を入力した時点で ます を未変換表示し、続けて t を入力すると ました に更新されます。

長い曖昧規則の途中まで進んだ後、その規則が成立しない場合は、最後に表示できていた曖昧結果まで戻り、残りの入力を通常のローマ字として再解釈します。

たとえば

• ctn -> ことに
• ctnnr -> ことになる
• ctnnc -> ことなのか

のような規則がある場合、ctnnaru は ctn + naru として解釈され、ことになる になります。 一方で、ctnnr や ctnnc のように長い規則として成立する入力は、従来どおりその規則が使われます。

長いカスタムローマ字テーブル出力

カスタムローマ字テーブルでは、1 規則あたりの出力を UTF-8 で 1024 bytes 未満まで扱えます。入力と次入力の上限は従来どおり 300 bytes 未満です。

従来は入力・出力・次入力のすべてが 300 bytes 未満に制限されていたため、一般的な 3-byte UTF-8 の日本語文字では、1 規則の出力は最大 99 文字相当でした。この fork では出力だけを拡張し、最大 1023 bytes、3-byte 文字なら 341 文字相当まで扱えるようにしています。

この上限はローマ字テーブルの 1 規則に設定する出力に対するものです。変換器全体の入力長制限を変更するものではありません。

ライブ変換

ライブ変換を有効にすると、スペースキーを押さなくても、入力中の未確定文字列が自動で変換されます。

入力途中の不要な中間変換表示を抑えるため、この fork では文字入力後に短い設定可能なデバウンス時間を挟んでからライブ変換を実行します。に、を、が のような助詞として使われやすい入力を誤って漢字化しないように、デフォルトでは 1 文字だけの未確定文字列ではライブ変換を行いません。ライブ変換を開始する最小文字数は設定画面から変更できます。

また、え~、えー、ん？ のように、かな1文字の後ろに装飾的な記号だけが続く場合もライブ変換を抑制します。これにより、入力途中の え~ が 絵～ のように短すぎる漢字候補へ変換される挙動を避けます。

サジェストについては、意味のある読みがまだ増えていない未解決ローマ字の打鍵ごとに候補を再生成し、候補ウィンドウがちらつくのを抑えるため、ライブ変換とは別に passive suggestion の更新を一時的に HOLD します。たとえば 今日は の後で s、sh と入力している間は直前の候補集合を保持し、shi が し に解決すると、現在の読み 今日はし に対するサジェストを更新します。新しい composition の先頭では、未解決のローマ字が 2 文字以下なら従来どおり更新を許可します。

ただし、カスタムローマ字テーブルの「曖昧なローマ字規則の途中表示」（DisplayAmbiguousResult）が有効な規則では、後続の入力で変化する可能性のある未解決のローマ字でも、すでに有効な日本語の読みを表示できます。この状態で予測クエリが変化した場合は HOLD を解除し、新しい読みのサジェストを生成します。たとえば a → あ、ms → ます、msn → ません を持ち、ms と msn がさらに長い規則の接頭部分でもあるテーブルでは、am の候補は保持しますが、ams では あます、amsn では あません に対応して更新します。先頭からの msn のように未解決部分が 3 文字以上でも、同じ条件で更新できます。曖昧な読みが表示されない単なるローマ字 prefix については、従来の HOLD を維持します。

保持中に Down / Tab で候補へ入る場合は、その時点で画面に表示されていた候補集合を再 prediction せずにそのままフォーカスします。Space は通常変換のままです。Shift による一時英字入力、modifier 付き入力、software / mobile keyboard からの明示的な text input はこの HOLD の対象にしません。ライブ変換と Zenz 自体は pending suffix 中も従来どおり継続します。

完成した expressive kana については、生成辞書に自然なかな候補を追加します。これにより初期状態では不自然な漢字分割に寄りにくくしつつ、ユーザーが ウッソ、クッソ、ヤッバ、チッス、ホェ～ などのカタカナ表記を明示的に選んだ場合には、ユーザー履歴やユーザー辞書による表記選好が反映される余地を残します。

対象には、たとえば以下のような入力が含まれます。

• うっそ、くっそ、やっば、やっべぇ
• すっご、すっげぇ、めっちゃ
• ちっす、ちょっす、ちょりっす
• うひょ、うひゃ、ほほう、ほっほーん
• ほえー、ほえ～、ほぇ、ほぇー、ほぇ～

これらは通常変換そのものを禁止するものではありません。完成した表現は通常の変換候補として扱われるため、Space 変換やユーザー履歴による候補順位の調整も従来どおり有効です。

たとえば:

• kyouha と入力
• デバウンス時間の経過後、Space を押す前に未確定文字列が 今日は のように表示される
• 続けて文字を入力しても途中の変換結果は確定されず、同じ未確定文字列として再変換される
• ローマ字テーブルで v. -> … や v, -> ‥ のような省略記号を入力する場合も、直前まで表示されていたライブ変換結果を保ったまま入力を継続する
• Shift による英字入力へ移る場合は、表示中のライブ変換結果を先に確定してから英字入力を開始する
• Backspace / Delete では、削除後の状態をすぐにライブ変換結果へ反映する
• Enter で現在のライブ変換結果を確定する

ライブ変換中は、変換後の文字を表示しながら元の読みも分かるように、未確定文字の上付近に Mozc 独自のルビ風 overlay window を表示します。

ライブ変換は設定画面から ON/OFF を切り替えられます。また、変換開始までの遅延時間と、ライブ変換を開始する最小文字数も設定画面から変更できます。

ハイフンなし郵便番号の変換

「郵便番号変換」が有効な場合、100-0001 のような従来のハイフン付き郵便番号に加えて、1000001 のようなハイフンなし7桁からも住所候補（例：東京都千代田区千代田）を取得できます。全角数字で入力した場合も、変換用のキーを正規化して扱います。既存のハイフン付き郵便番号辞書を検索時に参照する方式で、住所エントリを二重登録するものではありません。

ライブ変換ONでは、7桁の数字部分を含む変換文節について、数字表記を第1候補に保ち、住所は後続候補として残します。単独の郵便番号 1000001 がすでにライブ変換されていれば、キー設定で ConvertNext に割り当てたキー（標準では Space）を押すと、候補を再生成せず次の候補へ進めます。住所が次候補に並んでいれば、その操作で住所を選択できます。候補順位は辞書・履歴などの影響を受けるため、住所が必ず第2候補になるとは限りません。きょうは1000001です のような文章内でも、周囲の日本語のライブ変換を継続しつつ数字表記を優先します。文節をまたぐ場合は、通常の文節選択操作で対象の郵便番号文節に移動してください。

ライブ変換OFFでは、数字表記を第1候補へ強制移動せず、従来の辞書・学習履歴による候補順位を維持します。「郵便番号変換」をOFFにすると、ハイフンなし郵便番号の住所エイリアスと専用の候補順位制御は適用しません。

英数字の識別子を誤認識しないよう、ID1000000、1000000ABC、1231000000 など、7桁の直前・直後にASCII英数字が連続する場合は、ハイフンなし郵便番号エイリアスを生成しません。現在の境界保護はASCII英数字を対象とし、あらゆる記号やUnicode英数字を含む識別子の判定を保証するものではありません。なお、ここでの ConvertNext は通常の Mozc ライブ変換の候補移動です。Zenz 補正結果の表示中に Space で Mozc 結果へ戻す処理は別経路で、一部は物理 Space キーを判定するため、別キーに ConvertNext を割り当てても完全に同じ動作になるとは限りません。

ライブ変換 OFF 時の初回変換操作での候補表示

ライブ変換を使わない場合の補助機能として、初回の変換操作で候補ウィンドウを開く設定を追加しています。この設定は既定で有効です。

この設定が有効な場合、未確定文字列の入力中に通常変換コマンドを実行した時点で、第1文節の候補ウィンドウを表示します。このとき選択候補は第1候補のままで、第2候補へは進みません。さらに次候補キーを押した場合は、従来どおり次候補へ進みます。

この一般設定はライブ変換がOFFの場合だけ適用されます。Space以外のキーに通常変換を割り当てている場合も、keymapでConvertに解決された初回の変換操作で同じように適用されます。ライブ変換がONの場合は、通常のライブ変換から候補選択への移行を優先します。ただし、「郵便番号変換」ONかつ単独の7桁（またはハイフン付き7桁）の郵便番号を明示変換する場合は、この一般設定とは独立して初回の候補ウィンドウを表示する特例があります。一般設定を無効化すると、郵便番号以外のライブ変換OFF時の表示タイミングを従来どおりに戻せます。

Zenz ライブ補正

ライブ変換と Zenz ライブ補正の両方を有効にすると、通常は Mozc のライブ変換結果を表示したうえで、ローカルの Zenz runtime に非同期で補正を依頼します。

設定画面の「Zenz 補正結果が返るまで通常のライブ変換結果を表示しない」を有効にすると、Zenz 補正を実行する入力では、新しい Mozc ライブ変換結果を応答待ちの間は先に表示しません。すでに安定して表示できている Zenz 補正部分がある場合は、その表示を可能な範囲で維持し、入力途中の未解決ローマ字 suffix はその後ろへ追従表示します。Mozc 側の再文節化だけを理由に、一度安定した Zenz 表示を不用意に細分化・巻き戻ししないように扱います。Zenz が失敗、タイムアウト、検証拒否、または Mozc と同一の結果になって採用されなかった場合は、その時点の通常 Mozc ライブ変換結果へフォールバックします。

この deferred 表示には、Zenz 補正要求を実際に送信してからの最大待機時間を設定できます。既定は 250 ms です。この期限までに結果が得られなければ、その generation の Zenz 補正を中止して、すでに計算済みの Mozc ライブ変換結果を表示します。遅れて返った同じ generation の Zenz 結果は採用しません。Zenz 補正開始前のデバウンス時間はこの 250 ms には含まれません。

Windows 版では、Zenz request は mozc_server から Windows named pipe 経由で mozc_zenz_scorer.exe に送られます。scorer は同梱された llama-server.exe の localhost endpoint を呼び出し、ローカル推論を行います。この localhost 通信は固定 endpoint に依存しないようにし、内部 request も誤接続を避けるための保護を加えています。

Windows の Zenz named-pipe 通信は、接続・request/response I/O を有限の deadline で扱い、停止時には待機中の I/O を明示的に解除します。scorer または peer が応答しない場合でも Zenz worker / scorer が無期限に待機せず、stall から復帰した後は次の request を処理できるようにしています。macOS の Unix-domain socket 経路でも、停止時に待機中の poll を明示的に解除します。

Windows の scorer は FILE_FLAG_FIRST_PIPE_INSTANCE で同名のパイプが先に作成されていた場合の起動を拒否し、PIPE_REJECT_REMOTE_CLIENTS でリモート接続を拒否します。パイプのアクセス制御は SYSTEM と現在のユーザーに限定します。クライアント側では、接続したパイプハンドルから Windows が返すサーバープロセス ID を取得し、同じ Windows セッション・ユーザー SID と、Mozkey の実行ディレクトリにある mozc_zenz_scorer.exe の実行イメージパスを照合してから要求ヘッダーと入力プロンプトを送信します。照合に失敗した場合は送信を中止し、Zenz 補正を採用しません。scorer が停止している場合は、後続の補正要求で再起動を試みます。

この保護は OS が報告するプロセス情報と、一般ユーザーが実行ファイルを置き換えられないインストール先を前提とします。同一ユーザー権限での任意コード実行や管理者権限の侵害に対する完全な認証ではありません。Windows x64 では通常変換・scorer 自動復旧・別プロセスによる偽サーバー拒否を検証していますが、この変更の Windows ARM64 実機検証は未実施です。

Zenz に渡す surrounding context は、通常 Mozc の generic context とは分離した専用 field を使用します。Server は Zenz 補正に必要な preceding / following length を Client へ通知し、Windows TSF と macOS IMK は要求された方向・長さだけを追加取得して、zenz_preceding_text / zenz_following_text として渡します。通常 Mozc の surrounding text semantics は変更しません。

Zenz 補正は設定可能なデバウンス時間の後に実行されます。新規・未設定時のデフォルトは 700 ms です。すでに遅延時間が保存されている場合は、そのユーザー設定値を維持します。また、Zenz 補正を開始する最小文字数も設定画面から変更できます。Zenz 結果が返る前に入力内容が変わった場合、古い結果は generation / key の検査により破棄されます。

deferred 表示で Zenz の応答を待っている間に Space を押した場合は、候補を次へ進めず、まずその時点の Mozc 通常変換結果を表示します。Enter はその瞬間に見えている presentation をそのまま確定し、Undo では同じ presentation を未確定状態として復元します。Shift による英字入力へ移る場合も、表示中の presentation を先に確定してから英字入力を開始します。Backspace では削除後の Mozc 結果を即時に反映し、そのキー操作だけで新しい Zenz 補正を直ちに走らせず、続く実テキスト入力から通常の deferred Zenz scheduling を再開します。

Zenz 出力は表示前に検証されます。空出力、短すぎる入力、Mozc 結果と同一の出力、長すぎる出力、不正な文字列、安全でない可能性のある文字列は拒否されます。さらに、確定済み左文脈の長い末尾部分を Zenz 出力の先頭へ繰り返す context echo についても、現在の読み・Mozc 結果から見て不自然に長い反復だけを検出して拒否します。短い一致や、現在の読みそのものが同じ語句の反復を要求している場合は一律には拒否しません。拒否された場合は、その時点の通常 Mozc ライブ変換結果へフォールバックします。

Zenz の明白な欠落防止と厳密な読み保持（実験的）

通常設定では、Zenz の最終候補が通常 Mozc 変換結果の明白な先頭・末尾の欠落になっている場合、候補を拒否して通常 Mozc 結果へ戻します。この軽量な検証は、Zenz の新しい応答だけでなく保存済みフィードバック由来の候補にも適用します。確定済み左文脈の末尾と今回の入力が表記上重なる場合も、左文脈の反復なのか入力自体の一部なのか安全に区別できなければ、先頭を機械的に削らず通常 Mozc 結果へ戻します。

これは表記から判断できる明白な欠落を減らす保護であり、ユーザーが入力した読み全体の保持を保証するものではありません。通常時に追加の逆変換は行いません。

設定画面の 「厳密な読み保持（実験的）」 を ON にすると、採用直前の Zenz 候補を Mozc で逆変換し、その読みが入力した読み全体または正規化した入力の読みと一致するか確認します。読みが一致しない場合や読みを取得できない場合は、通常 Mozc 変換結果を使用します。初期値は OFF で、明示的に保存した ON 設定は維持します。

厳密モードは保守的な検証です。漢字の複数の読みや逆変換の限界により、正しい候補でも拒否される場合があります。また、読みを検証できない保存済みフィードバックによる通常候補の順位調整・候補追加などは制限され、追加の逆変換処理によって応答が遅くなる可能性があります。通常の Zenz 補正やフィードバック活用を優先する場合は、既定の OFF のまま利用してください。

通常 Mozc ライブ変換で現在の結果として現れているユーザー辞書由来候補や ASCII / mixed-script 表記は、Zenz 採用時に保護されます。ASCII / mixed-script 表記は、読みを安全に特定できる場合に Zenz prompt 内で一時 placeholder 化し、Zenz 応答後に元の表記へ復元します。これにより、もずきー -> Mozkey のような表記が モズキー のように上書きされることを避けつつ、対象語の前後にある文の補正は採用できるようにしています。

通常 Mozc が選んだ表記は、Zenz 採用時の orthographic baseline としても扱います。Zenz だけが 東京 -> Tokyo や コンピュータ -> computer のような Latin 表記を新たに導入したり、通常 Mozc が選んだ Latin / technical token を削除・変形したりした場合、文節境界へ安全に逆投影できるときは問題のある文節だけを通常 Mozc の表記へ戻し、ほかの Zenz 補正は維持します。安全に逆投影できない場合や、保存していた baseline 文節が欠落・不整合な場合は、表記上安全でない遷移を含む Zenz 結果を採用しません。一方、通常 Mozc がすでに GitHub、iPhone、AI、C++、GPT-5、UTF-8、HTTP/2、Windows11 などを選んでいる場合、それらは正当な baseline として維持します。

ASCII の数字リテラルは、この Latin / technical identity とは別に扱います。符号付き整数・小数を含む数字表記そのものは Zenz prompt 内で placeholder 化せず、応答後も同じ表記・同じ出現数を要求します。各数字リテラルの左右について、通常 Mozc の baseline で隣接文字が日本語なら Zenz 側でも日本語文字であることを要求し、日本語部分の変更は許可します。一方、baseline の隣接文字が非日本語なら同じ文字を、文字列端なら同じ端位置を要求します。これにより 1代 -> 1台 のような助数詞・単位側の補正や周囲の文脈補正を許可しつつ、100円 -> 100¥、100% -> 100$、2026/09/23 -> 2026-09-23、HTTP/2 -> HTTP 2 のように数字自体または非日本語境界を変える出力は採用しません。

また、Zenz が括弧、疑問符、感嘆符、一部の全角 ASCII 記号 などを正規化して返した場合でも、採用前にユーザー可視の記号スタイルを復元します。これは全角化ではなく、現在の未確定文字列または通常 Mozc ライブ変換結果に現れていた表記の保存です。たとえば （テスト） は （ ） のまま、(test) は ( ) のまま維持します。URL、path、ASCII token 風の文脈では、ASCII 記号を不用意に全角化しないよう保守的に扱います。

さらに、Zenz が左文脈の文体などを引き継いで、現在の未確定文字列や通常 Mozc ライブ変換結果にない文末・表現記号を末尾へ追加する場合があります。Mozkey は ！ / !、？ / ?、。、…、〜 などについて、現在の未確定文字列と通常 Mozc ライブ変換結果の末尾に既にある数を上限として、超過した末尾記号だけを採用前に取り除きます。これにより、漢字・語彙などの Zenz 補正は残しつつ、文脈だけから追加された余分な末尾記号を抑制します。文中の記号はこの repair の対象にしません。

日本語のみのユーザー辞書語は、自然な読みを Zenz prompt に残したまま、Zenz 応答後に表記の境界を検証します。たとえば保護対象の直後に余分なかなが付着した場合は、安全に修復できる場合だけ採用し、修復できない場合は通常の Mozc ライブ変換結果に戻します。

Zenz が保護対象の表記を落としたり変更したりし、placeholder 復元や安全な repair でも必要な出現数を満たせない場合、その Zenz 結果は採用せず、通常の Mozc ライブ変換結果を表示します。保護対象はユーザー辞書に登録されている全候補ではなく、現在の通常ライブ変換結果に実際に現れた表記です。

Zenz ライブ補正は password field では実行されません。また、入力途中の raw romaji のように日本語文字シグナルを含まない読みは補正対象外です。日本語文字を含む英字混じりの入力は、privacy gate を通る場合に限り補正対象になり得ます。

Windows TSF の password input scope と macOS の Secure Event Input では、application の surrounding text を Zenz 用に取得せず、Zenz extended context acquisition も実行しません。

Zenz 学習の独立設定

設定画面では、「Zenz 学習（Mozc変換履歴）」 と 「Zenz 学習（補正フィードバック）」 を別の項目として設定できます。

A・B・C は相互に独立しています。例えば A=OFF / B=ON なら既存データの利用だけを続けられ、A=OFF / C=ON ならフィードバック TSV を増やさずに Mozc 変換履歴への追加学習を行えます。新規 Mozkey 設定では3つとも ON が既定です。旧統合設定を保存済みの場合は、新項目がまだ明示されていないときだけその値を引き継ぎ、設定済みの新項目は上書きしません。

A が ON の場合でも、Zenz 補正を表示しただけでは記録しません。Enter や句読点・記号の単打確定などで明示的に確定した場合に、full-sequence accepted feedback を TSV へ追加します。C による Mozc 履歴の学習は別の保存先・条件で動作します。

短い読みの Zenz feedback 自動適用制限

短い読みは同音異義語が多く、適切な表記が前後の文脈によって変わりやすいため、少数の Zenz feedback を一般的な表記選好として強く再利用すると、別の文脈でも特定の候補が過度に優先・抑制されるおそれがあります。これを防ぐため、feedback の記録は継続しながら、短い読みへの自動的な学習反映を控える設計にしています。7 文字は同音異義性の有無を厳密に判定する境界ではなく、誤った優先・抑制の影響を抑えるための調整可能な初期値です。

初期設定では「短い読みでは Zenz feedback を自動適用しない」が ON、最小読み文字数は 7 文字です。判定はローマ字の打鍵数や UTF-8 バイト数ではなく、feedback の読み全体に含まれる Unicode コードポイント数（Unicode scalar value に相当）で行います。たとえば あしたはあめ（6 文字）は対象外、おねがいします（7 文字）は対象です。設定画面では制限の ON/OFF と最小値（1～20 文字）を変更できます。

対象外の読みでも、Zenz 補正の新規推論および採用・却下 feedback の記録は継続します。ただし、保存済み feedback に基づく通常候補の順位調整・補正の即時再利用・自動ブロックには利用しません。読みの長さにかかわらず、ユーザーが明示した 手動ブロック（hard reject）は有効です。記録そのものは削除されず、制限を OFF にするか最小文字数を下げると、保存済みの履歴が再び自動適用の判定対象になります。

これは「Zenz 補正を開始する最小文字数」とは別の設定です。新規推論の開始条件、通常の Mozc 変換・ユーザー履歴学習、確定済み Zenz 結果から Mozc 履歴へ学習する別経路を、この feedback 再利用制限だけで停止するものではありません。

シークレットモード中は例外で、Zenz 推論は通常どおり利用できますが、Zenz feedback personalization の読み取り・書き込みを停止します。保存済み feedback による candidate ranking、複数文節 live correction の fast path、auto-block を含む feedback decision は適用せず、新しい feedback record も保存しません。シークレットモードを解除すると、削除せず保持していた既存 feedback を再び利用します。

明示的確定後は、その accepted に対する短い rollback window を session 内に保持します。次の実テキスト入力や確定後の context transition で window が閉じる前に Backspace、Escape、Revert、Undo、Ctrl+Z などの修正操作が入った場合は、実際に追記に成功した accepted だけ accepted_rollback で補償します。採用記録の追記が失敗したときは補償レコードも追記しないため、以前の正常な採用履歴を誤って減算しません。accepted_rollback は rejected feedback ではないため、通常却下回数や auto-block の negative evidence を増やしません。IMEOff / MakeSureIMEOff は取り消しではなく確定後のモード変更として扱い、accepted を保持したまま rollback window を閉じます。表示中の Zenz 補正から Space や候補移動などの通常変換操作へ移った場合は別で、その Zenz 結果を rejected feedback として扱います。ただし Space などの通常操作由来の rejected feedback は、候補を永久に抑止する hard reject ではなく、以後の candidate ranking で順位を下げるための negative signal として扱います。

Zenz feedback の自動ブロックは、通常却下回数だけではなく拒否割合も使って判定します。同じ full-sequence feedback entry について、通常却下回数 >= 最低拒否回数 かつ 通常却下回数 / (採用回数 + 通常却下回数) >= 最低拒否割合 の両方を満たした場合にだけブロックします。既定値は最低拒否回数 1 回、最低拒否割合 50% で、境界値も含むため accepted=1 / rejected=1 の 50% はブロック対象です。明示的な hard reject はこの割合計算とは別の絶対ブロックとして扱います。

通常の自動ブロック中は、Zenz の内部生成自体を止めず、結果だけをユーザーには表示しない shadow observation を続けます。その状態で同じ読みが最終確定され、非表示の Zenz 結果と確定値が一致した場合は accepted feedback を 1 件加算します。この hidden match は Zenz feedback の回復観測であり、Mozc user history への追加学習は行いません。一致が積み重なって拒否割合がしきい値を下回れば、たとえば accepted=2 / rejected=1 の 33% のように自動ブロックは解除されます。同じ読みで異なる値が確定した場合は通常却下を加算し、入力継続などで最終的な読みが shadow observation の読みと異なる場合は feedback を更新しません。明示的な hard reject は shadow observation を行わず、自動回復しません。

Zenz feedback TSV は、完全な読み key、完全な補正 value、粗い非可逆 context class からなる full-sequence 単位に限定します。segment-local や lexical-unit の feedback は保存しません。accepted Zenz 補正は C が ON でプライバシー保護や通常履歴設定の条件を満たす場合、明示的確定の同じ commit 点で Mozc user history へ外部変換結果として即時学習されます。これは A の ON/OFF とは独立した Mozc-history 経路であり、Zenz feedback store の追加 record ではありません。この generalized learning では in-process の rollback handle を保持し、rollback window 内の Backspace、Escape、Revert、Undo などでは直前の学習を revert します。次の実テキスト入力や ResetContext / IMEOff などで window が閉じた後は学習を保持します。exact TSV の accepted / accepted_rollback と generalized Mozc-history の revert は別々の仕組みです。また、この rollback は process 内の短い取り消し窓を対象とするもので、crash や process termination をまたぐ durable transaction / ACID rollback ではありません。局所学習では、まず直前の通常 Mozc ライブ変換で既知の文節境界を優先し、ユーザー履歴を参照しない固定境界再評価で accepted surface を正確に再現できるか確認します。その境界で説明できない範囲だけ Mozc native の再文節化と forward verification を行い、accepted surface を説明する境界・読みの経路が一意に検証できる場合だけ、その推定境界を局所学習に使います。複数の境界解釈が成立する範囲や安全に解決できない aggregate は、推定境界を学習せず非学習の barrier として扱います。その前後に独立して安全な lexical island があれば、そこは別々に学習できます。句読点などの非学習単位も lexical island の区切りとして扱い、その区切りをまたぐ境界履歴は作りません。Zenz が実際に変更したことを最終的な key/value 対応で確認できる語彙単位だけを強い選択履歴として扱います。安全な structured / local commit が1件でも成立した場合は、同じ accepted result を全文単位で重ねて Mozc history に学習しません。一方、安全な projected / local evidence を1件も commit できなかった場合は、曖昧な局所境界を捏造せず、別経路として exact accepted result の full-sequence Mozc-history fallback を試みます。Zenz feedback store 側の full-sequence accepted record はこの局所境界判定とは別に保持されます。privacy / password gate に該当する入力は、この Mozc-history 学習自体の対象外です。

特に Space は、Zenz 補正を単にキャンセルしてライブ変換中の入力列へ戻すキーではなく、通常変換候補へ戻る候補変更操作として扱います。deferred 表示でまだ Zenz の応答待ちの場合は、最初の Space でその時点の Mozc 通常変換結果を表示しますが、候補は次へ進めません。すでに Zenz 補正が表示されている場合も、Space を押すと補正前の Mozc 変換結果を通常変換状態として表示し、候補ウィンドウはまだ開きません。そのまま次の文字を入力した場合は、戻した Mozc 変換結果を確定してから新しい入力を開始します。さらに Space を押した場合は、従来どおり通常変換の候補ウィンドウを開いて次候補へ進みます。

Zenz feedback の再利用方法は、単文節と複数文節で異なります。

単文節の通常変換では、Zenz feedback は rewriter chain 内の ranked candidate reuse として再利用されます。保存済み feedback は accepted / rejected reason を score 化し、既存候補があれば score に応じて cost を調整します。候補にない場合は synthetic candidate として候補集合へ追加できますが、無条件に先頭へ挿入するのではなく、feedback-adjusted cost に基づく自然な位置へ挿入します。通常操作由来の rejected feedback は候補を削除する命令ではなく順位を下げる signal として扱い、明示的な hard reject reason だけを強い抑止として扱います。その後に UserSegmentHistoryRewriter が走るため、明示的なユーザー選択履歴が最終順位を決めます。

複数文節に分かれるライブ変換では、converter の文節境界を feedback ranking で壊さないため、rewriter chain では通常変換候補を書き換えません。その代わり、session-level の live correction fast path として再利用します。これにより、かれはてんてきです → 彼は天敵です のような全文補正の学習も再利用できます。

sensitive_like context で得られた feedback は、通常文脈への候補 ranking / reuse には使いません。

フィードバック学習データは設定画面から管理できます。管理画面では、学習済みエントリを読み取り専用 table で表示し、検索、インポート、エクスポート、選択項目削除、全削除を行えます。ここで削除しても、C によって Mozc の通常変換履歴へすでに反映された学習は消えません。ユーザーが TSV ファイルを直接編集する必要はありません。短い読みの履歴も残り、管理画面の「feedback適用」列には「対象外（記録のみ）」、明示的な手動ブロックでは「手動ブロック有効」と表示されます。

また、選択した補正を「この補正をブロック」から明示的にブロックできます。ブロック済みの補正は再ブロックできません。ブロックを解除したい場合は、該当エントリを削除してから必要に応じて再学習します。

Zenzai v3/v3.2 条件フィールド

Zenz ライブ補正では、Zenzai v3/v3.2 の特殊トークン形式に沿って、追加の条件フィールドを設定できます。これらは ChatGPT の system prompt ではなく、Zenzai が学習時に見ている条件付き入力形式に対応する短いヒントです。

• profile: U+EE03 profile として、書き手や用途の短い説明を渡します。
• topic: U+EE04 topic として、現在の話題を渡します。experimental なフィールドです。
• style: U+EE05 style として、文体や用途を渡します。experimental なフィールドです。
• settings: U+EE06 settings として、変換方針の短いヒントを渡します。experimental なフィールドです。
• 右文脈: Zenz 専用のカーソル右側テキストが利用可能な場合、U+EE07 right context として Zenzai v3.2 の prompt に含めます。右文脈の取得長は設定可能で、既定は 6 文字です。

profile、topic、style、settings は空欄なら prompt に含めません。右文脈はユーザーが固定文を入力する欄ではありません。Windows TSF / macOS IMK では、Server が要求した必要量をカーソル右側から自動取得し、zenz_following_text として渡します。

確定済み左文脈を使った変換補正

この fork では、現在の未確定文字列の直前にある確定済みテキストを、可能な範囲で左文脈として参照します。

たとえば、main を確定した直後に にまーじしました と入力した場合、

• mainにマージしました

のような結果を優先し、

• main二マージしました

のように助詞 に が同音の漢字・数字候補へ過剰に変換される挙動を抑制します。

空白、改行、句読点、括弧などの強い区切りの直後では、左文脈は接続しません。

内部的には、名詞相当の確定済み左文脈を history segment として復元し、に、を、が、へ、で などの短い助詞候補が、同音の漢字・数字・記号・濁点付き仮名候補に負けにくくなるように候補順位を補正します。

また、名詞相当の左文脈の後では、には、にも、では、でも、とは のような保守的な複合機能語も補正対象にします。たとえば github を確定した直後に には と入力した場合、github二は よりも githubには を優先しやすくします。

さらに、名詞相当の確定済み左文脈の直後では、現在入力の先頭にある機能語 prefix や、なのか、なのだ、なんです、なら、ならば、ならでは のような名詞述語・条件表現に続く機能語列が、担った、七日、奈良 のような内容語候補に食われるケースも抑制します。たとえば 彼 を確定してから になった や なのか と入力した場合、彼担った / 彼七日 ではなく、彼になった / 彼なのか を優先しやすくします。また、練習 を確定してから なら と入力した場合、練習奈良 ではなく 練習なら を優先しやすくします。

また、名詞や数量表現の後に続く しか + 否定表現 のような機能表現も保護します。たとえば 2めいしかいない では、途中の 2名司会...、2名視界...、2名士会内 のような同音漢字経路よりも、2名しかいない を優先しやすくします。

また、サ変接続名詞や行政地名・施設名のような直前文脈、地名に続く場所接尾語のような限定的な右文脈も一部補正対象にします。たとえば 追記したい では 追記死体 のような同音名詞候補を避け、サ変接続名詞を確定した直後の した、したの、したん では 下、舌、シタン のような内容語候補に寄りすぎる挙動を抑制します。山梨県立美術館 では 山梨県率美術館 のような接尾的構成の崩れを抑制します。また、滋賀方面 や 佐賀空港 のような語では、子が方面 のような短い 内容語 + が 分割を避けやすくします。

句読点・記号の単打確定

句読点・記号の単打確定オプションを有効にすると、設定した記号を入力した時点で未確定文字列全体をそのまま確定できます。

たとえば

• tesuto. → てすと。
• tesuto? → てすと？
• kakko( → かっこ（
• tesuto/ → てすと・（記号スタイルで / が中黒になる場合）

のように動作します。

対象は、句点、読点、疑問符、感嘆符、丸括弧、鉤括弧、中黒から選択できます。「、」 はそれぞれ独立した設定で扱います。中黒 ・ は、語や句を並列・区切りとしてつなぐ日本語の約物として独立した設定で扱います。

ローマ字テーブルで句読点・記号を出すように設定している場合も、出力された文字が単打確定の対象に含まれていれば、その時点で確定されます。

たとえば、ローマ字テーブルで zz -> 。、qq -> ？、md -> ・ のように設定している場合でも、出力先の記号を単打確定の対象にしていれば、tesutozz → てすと。、tesutoqq → てすと？、tesutomd → てすと・ のように確定されます。

どの句読点・記号を単打確定の対象にするかは、設定画面のチェックボックスで選択できます。

ただし、数字直後の句点・読点系文字は、数値入力を妨げないよう単打確定の対象外として扱います。これにより、句読点・記号の単打確定を有効にしたままでも、3.14 や 1,000 のような数値を途中で確定せずに入力できます。通常の日本語入力での句点・読点の単打確定は従来どおり動作します。

ライブ変換が有効な場合、句読点・記号の単打確定では、ひらがなの未変換文字列ではなく、現在表示されているライブ変換結果を確定します。

句読点・記号の単打確定でも、直前の通常変換確定による学習は次の実テキスト入力まで保留されます。次の操作が Backspace、Escape、Revert、Reset、Undo などの場合、その保留学習は保持せず取り消します。一方、IMEOff / MakeSureIMEOff は取り消しではなく確定後のモード変更として扱い、保留学習は確定扱いにします。

句読点・記号の単打確定直後に Ctrl+Z など、現在のキー設定で Cancel に相当するキーが押され、そのキーがアプリケーションへ渡される場合も、Mozkey 側の保留学習は破棄します。実際に確定済み文字列が取り消されるかどうかは、アプリケーション側の Undo 挙動に従います。

変換キャンセル後のひらがな確定学習

変換中に Esc / Ctrl+Z など、現在のキー設定で Cancel に割り当てられた操作で変換をキャンセルし、ひらがなの未確定文字列に戻したうえで、そのまま Enter、Commit → IMEOff、IMEOff / MakeSureIMEOff、または句読点・記号の単打確定で確定した場合、このフォークではそのひらがな表記をユーザーが明示的に選んだ候補として扱います。

たとえば、きょう を変換して 今日 が表示されたあと、Esc で きょう に戻して Enter や Commit → IMEOff で確定した場合、IMEOff で確定して直接入力へ戻した場合、または きょう。 のように句読点・記号の単打確定で確定した場合、F6 でひらがな化して Enter 確定した場合に近い形で、ひらがな本体の きょう をユーザーセグメント履歴へ反映します。これにより、次回以降の同じ読みで、ひらがな候補が上がりやすくなります。

複数文節に分かれていた変換をキャンセルした場合は、可能な限りキャンセル直前の文節境界を保持します。たとえば おつかれぺん が お疲れ | ペン のように複数文節として変換されていた場合、キャンセル後に おつかれぺん をそのまま確定すると、全体 1 件としてではなく、おつかれ -> おつかれ、ぺん -> ぺん のような文節単位のひらがな表記選好としてユーザーセグメント履歴へ反映します。

この強い学習は、キャンセル直後の未確定文字列が編集されず、そのまま Enter、Commit → IMEOff、IMEOff / MakeSureIMEOff、または句読点・記号の単打確定で確定された場合だけ有効です。句読点・記号の単打確定では、句読点・記号を含む全文ではなく、キャンセル直後のひらがな本体だけを表記選好として扱います。通常の未変換 Enter、キャンセル後に編集した文字列、1文字だけのひらがな、ひらがな以外の文字列、パスワード欄での入力は対象外です。

ライブ変換が有効な場合も、ユーザーが Esc / Ctrl+Z などのキャンセル操作で明示的にひらがなへ戻し、そのまま Enter、Commit → IMEOff、IMEOff / MakeSureIMEOff、または句読点・記号の単打確定で確定した場合は同じ扱いになります。一方で、入力継続などの内部処理としてライブ変換状態が解除されただけの場合は、この強い学習の対象にはなりません。

確定直後の修正による履歴学習の取り消し

変換確定直後に Backspace、または現在のキー設定で Cancel に割り当てられたキーが入力された場合、このフォークでは直前に確定した学習結果を取り消し対象として扱います。

句読点・記号の単打確定のように、確定文字列がすでにアプリケーションへ送られており Mozkey 側の通常の Undo context に乗らない場合でも、直後の Ctrl+Z などの Cancel 相当キーは保留学習の取り消しシグナルとして扱います。この場合、キー入力自体はアプリケーションへ渡し、画面上の文字列を実際に戻すかどうかはアプリケーション側の Undo 挙動に任せます。

確定した文字列全体を削除した場合は、その確定によるサジェスト履歴およびユーザーセグメント履歴が、以後のサジェストや変換順位に残らないようにします。

一方で、Backspace により確定文字列の末尾だけを削除した場合は、残っている部分の履歴は保持し、削除された末尾に対応する履歴だけを取り消します。

たとえば:

• いしとは を 医師とは として確定
• Backspace を2回押して とは だけを削除
• 残っている 医師 の履歴は保持
• 医師とは としての末尾込みの学習は取り消し

これにより、変換確定直後の修正操作がユーザーの意図に近い形で履歴学習へ反映されます。

サジェスト確定時の全文読み・文節単位の学習

入力途中の短い読みから、より長い文章のサジェストを明示的に選んで確定した場合、Mozkey は候補が保持する全文の読みを確認し、通常変換で得られる候補と文節構造を使って、ユーザーセグメント履歴に表記選好を反映できるようにしています。

たとえば わたし の入力中に、全文の読みが わたしのなまえ である 私の名前 がサジェストとして表示され、それを選んで確定した場合、読みと表記の対応を検証できた文節について、その後の通常変換へ選択履歴を反映します。入力した短い接頭部分だけを、全文の読みと取り違えて学習することは避けます。

学習用の検証では、候補の元データに文節境界があればそれを参照し、境界がなければ通常変換や安全な逆読み解析から対応関係を探します。実際の通常変換で候補がどう並ぶかを基準に、先頭候補ではない表記を明示的に選択した場合の強い学習を判断します。辞書の内部的な候補順だけを表示順位として扱いません。候補・読み・文節境界・順位の対応を十分に検証できない場合は、推測に基づく文節単位の追加学習を見送ります。

この検証は元の確定結果を差し替えず、通常のサジェスト履歴や、他の確定時処理を重複して実行しません。Undo で直前の学習が取り消された後に同じ読みを再確定した場合には、保留中の古い取り消し処理を新しい学習および候補順位の検証より前に適用し、新しく確定した選好が誤って消されることを防ぎます。

通常の履歴学習が無効な場合や、シークレットモード、パスワード欄、private input などの学習禁止条件では、この追加学習を行いません。対象は対応する通常のデスクトップサジェスト確定であり、モバイル向け mixed conversion や zero-query suggestion へ無条件に拡張するものではありません。Zenz 補正フィードバックの保存・再利用とは別の Mozc サジェスト学習経路です。

この追加学習経路は Windows でビルド・回帰テスト・実機確認を行っています。macOS での本変更の実機動作は未検証です。

複数コマンドのキー割り当て

キー設定エディタで、1つのキー入力に対して複数のコマンドを順序付きで割り当てられるようにしました。

たとえば、次のような割り当てができます。

• Composition + Ctrl Enter -> Commit → IMEOff
• Composition + Ctrl Space -> Convert → ConvertNext
• Conversion + Ctrl Enter -> Commit → IMEOff

コマンド列は左から右へ順に実行されます。途中で入力状態が変わった場合、後続コマンドはその時点の状態に合わせて解決されます。たとえば Convert → ConvertNext では、まず未変換状態から変換状態へ入り、その後に次候補へ移動します。

設定ファイル上では、複数コマンドは Commit|IMEOff や Convert|ConvertNext のように | 区切りで保存されます。設定画面では Commit → IMEOff のように表示され、コマンドの追加、削除、並べ替えができます。

手動 Zenz 補正と遅延コマンド列

キー設定エディタでは、従来の手動 Zenz 補正 ForceZenzLiveCorrection（「Zenz補正を未確定文字に対し実行」）、フィードバック無視の手動補正 ForceZenzLiveCorrectionWithoutFeedback（「Zenz補正を未確定文字に対し実行（フィードバック学習を無視）」）、およびコマンド列の途中で待機する Delay(ms)（「遅延」）を利用できます。

• 通常の手動 Zenz 補正: 入力中（Composition）または変換中（Conversion）の未確定文字列に対して、現在の Mozc 変換結果を基準に Zenz 補正を非同期で要求します。保存済み Zenz feedback の利用設定は通常どおり適用されます。
• フィードバック無視の手動補正: この実行に限り、保存済み Zenz feedback による通常候補の順位調整・補正結果の高速再利用・統計的な自動ブロックを無視します。変換中から実行した場合は、フィードバック抜きの Mozc 変換結果を再計算して基準にします。通常の Mozc 学習履歴とユーザー辞書は利用でき、ユーザーが明示的に指定した手動ブロック（hard reject）は引き続き有効です。「無視」は過去の feedback の参照についてであり、補正結果を確定した場合の新しい feedback 記録（A）や Mozc 履歴への学習（C）は、それぞれの設定に従って行われます。
• 両コマンド共通: 自動の「Zenz ライブ補正を有効にする」が OFF でも実行でき、手動実行には自動補正開始用の最小読み文字数を適用しません。パスワード欄やプライバシー・入力内容の適格性検査は維持し、Zenz の出力が必ず採用されるわけではありません。変換中のフィードバック無視補正で再変換が失敗した場合、元の候補・入力モード・学習取り消し情報を維持します。
• 遅延: Delay(700) は後続コマンドを 700 ms 後に再開する指定です。設定できる値は 0～5000 ms で、Delay(0) は待機しません。これは自動ライブ変換や自動 Zenz 補正の遅延設定とは独立した、キー割り当て専用の待機です。

実用的なキー割り当て例（カスタム設定例であり、標準の既定割り当てではありません）:

Precomposition + Space -> ReconvertSelectionOrInsertSpace|Delay(700)|ForceZenzLiveCorrection
Composition + Shift Space -> ForceZenzLiveCorrection
Conversion + Shift Space -> ForceZenzLiveCorrection
Composition + Ctrl Shift Space -> ForceZenzLiveCorrectionWithoutFeedback
Conversion + Ctrl Shift Space -> ForceZenzLiveCorrectionWithoutFeedback

1行目は Windows TSF 向けです。「入力文字なし」の Space を、選択テキストがある場合だけ再変換 → 700 ms 待機 → 手動 Zenz 補正とし、選択されていなければ従来どおり空白を入力します。アプリケーション側の再変換対応が必要です。2・3行目は Shift+Space で通常の手動補正、4・5行目は Ctrl+Shift+Space でフィードバック無視の手動補正を実行する例です。入力中と変換中では別々のキー設定行を作成します。

制約と操作上の注意:

• Delay はコマンド列の先頭には置けません。設定画面では待機時間を入力して追加し、コマンド列の Delay をダブルクリックすると再編集できます。通常コマンドのダブルクリックは従来どおり削除操作です。
• ForceZenzLiveCorrection と ForceZenzLiveCorrectionWithoutFeedback は、どちらもコマンド列の最後にのみ配置できます。たとえば ForceZenzLiveCorrectionWithoutFeedback|Delay(700)|Commit は設定できません。Zenz の非同期応答処理を後続コマンドで上書きしないための制約です。
• Space / Shift+Space に別のコマンドが既に割り当てられている場合は、同じ入力状態の既存行を置き換えてください（重複行を追加しない）。特に Shift+Space は従来の別種の空白入力などを置き換える可能性があり、他のアプリケーションや OS のショートカットに先取りされる場合もあります。
• 待機中に別のキー操作、候補のマウス選択、入力先の切り替えなどが行われた場合、古いコマンド列が後から入力へ作用しないよう、保留していた再開処理を無効化します。
• 手動補正後も Space で通常の Mozc 変換へ戻れます。再度手動補正を実行するには、変換中に割り当てたキーを使用します。「Zenz補正中」専用キー設定が追加されており、Zenz補正結果が表示中はその設定が優先されます。

※ 選択文字列の再変換（ReconvertSelectionOrInsertSpace）は Windows 専用です。手動 Zenz 補正と遅延コマンド列の組み合わせについては、macOS・Linux での動作を保証していません。

ライブ変換・Zenz補正中のキー設定

キー設定には「ライブ変換中」（LiveConversion）と「Zenz補正中」（ZenzConversion）があります。前者は Mozc のライブ変換中、後者は Zenz の補正結果が表示されている間に適用されます。

標準キー設定での Backspace の動作は次のとおりです。

Zenz補正中は、標準キー設定の Space で補正結果を確定せずに元の Mozc 変換結果へ戻せます。ライブ変換から移行した場合は、戻った後も読みを編集するとライブ変換が続きます。通常変換から手動で補正した場合は、通常変換に戻ります。

ZenzConversion + Space -> RevertZenzToMozc

「通常のMozc変換に戻す」（RevertZenzToMozc）は、キー設定エディタで別のキーにも割り当てられます。このコマンドは単独で指定してください。カスタムキー設定で明示的に割り当てた操作がある場合は、その設定が優先されます。

候補の履歴削除・非表示

変換中または予測候補の表示中に DeleteSelectedCandidate を実行すると、選択中の候補を履歴から削除するか、候補一覧から非表示にできます。標準キー設定では Prediction / Conversion の Ctrl+Delete にこの操作を割り当てています。

操作時は、まず選択候補に対応するユーザー履歴の削除を試みます。履歴削除に成功した場合はそこで処理を終え、候補を抑制単語として登録しません。履歴削除の対象ではなく、それでも非表示可能な候補である場合だけ、読みと候補文字列の組をユーザー辞書「非表示候補」へ SUPPRESSION_WORD として登録します。

このため、system dictionary と学習履歴の両方から同じ候補が出ている場合、最初の操作では学習履歴だけが削除され、system dictionary 由来の候補が残ることがあります。その候補にもう一度同じ操作を行うと、「非表示候補」へ登録されて候補一覧から抑制されます。

ユーザー辞書由来の候補も非表示にできますが、元のユーザー辞書エントリ自体は削除しません。「非表示候補」に作成された対応する抑制単語をユーザー辞書ツールから削除すると、元の候補を再び表示できます。非表示操作によって通常候補が1件も残らなくなる場合や、コマンド候補・無効な候補など、非表示対象として扱えない候補では抑制を行いません。

候補ウィンドウのフッターでは、候補番号を維持したまま従来のロゴ表示を省略し、選択中の候補の状態と現在のキー設定に応じて操作案内を表示します。標準の Ctrl Delete 割り当てでは、履歴削除可能な候補に Ctrl+Delで履歴削除、履歴削除の対象ではないが非表示可能な候補に Ctrl+Delで候補非表示 と表示します。DeleteSelectedCandidate を別のキーへ割り当てた場合は、その実際の割り当てを短縮表記して使用し、たとえば Alt Delete なら Alt+Delで候補非表示、Prediction で Ctrl Backspace に割り当てた場合は Ctrl+Bkspで履歴削除 のように表示します。現在の候補カテゴリに有効な DeleteSelectedCandidate の割り当てがない場合は、この操作ラベルを表示しません。

CUSTOM キー設定では、既存のユーザー設定を上書きしないように扱います。変換状態ですでに DeleteSelectedCandidate が別キーへ割り当てられている場合や、Conversion + Ctrl Delete が別コマンドに使われている場合は自動変更しません。どちらにも該当せず、CUSTOM テーブルが有効な場合だけ Conversion + Ctrl Delete -> DeleteSelectedCandidate を実際のカスタム設定として追加・保存します。

設定画面の「学習履歴のクリア」直下にも、非表示にした候補がユーザー辞書「非表示候補」に抑制単語として保存されることと、再表示する場合の削除方法を案内しています。

顔文字候補の第1候補抑制

通常変換では、Mozc 内部で「顔文字」として意味的に識別できる候補が、ユーザーの選択履歴によって第1候補へ上がらないようにしています。標準の顔文字候補に加え、ユーザー辞書で品詞「顔文字」として登録した候補も対象です。顔文字候補そのものを削除する機能ではないため、対象候補は第2候補以下に残り、必要な場合は従来どおり選択できます。

この制約は、候補の表層文字列が顔文字らしいかどうかではなく、Mozc 内部で保持している候補の意味的な由来に基づいて適用します。そのため、たとえば同じ (^_^) という表記でも、ユーザー辞書で「記号」など「顔文字」以外の品詞として登録した候補はこの制約の対象にならず、通常の順位付けや学習によって第1候補になることができます。

一方、Zenz が独立して生成した候補については、その表層文字列だけを見て顔文字かどうかを推測し、この制約へ追加することはしません。既存の Mozc 候補が持つ意味情報はそのまま尊重しつつ、Zenz 固有の生成結果を文字列パターンだけで分類しない方針です。

絵文字候補の第1候補抑制

標準の EmojiRewriter から追加される絵文字候補にも NO_TOP 制約を付与します。通常変換の最終順位決定後、第1候補になっていた場合は制約のない候補を優先します。絵文字自体は削除せず、第2候補以下から選択できます。

新しく学習する絵文字候補ではこの制約を履歴へ保存します。既存の学習履歴も、標準 EmojiRewriter による「絵文字」description が保存されている場合は制約を復元します。同じ読み・表記をユーザー辞書で「記号」などとして明示的に登録した場合は、その登録を優先して通常の第1候補を許可します。Unicode の字形だけによる絵文字判定は行わず、Zenz が独立生成した候補も表層文字列だけでは制約対象に追加しません。

選択文字列の Space 再変換（Windows / MS-IME 風キー設定）

Windows 版の MS-IME 風キー設定では、確定済みテキストを範囲選択した状態で Space を押すと、その選択文字列を再変換します。何も選択していない場合は、従来どおり空白を入力します。

この挙動は、キー設定画面では「選択文字列を再変換（未選択時は空白）」というコマンドとして表示されます。Space キーを無条件に横取りするものではなく、MS-IME 風キー設定で「入力文字なし」の Space にこのコマンドが割り当てられている場合だけ有効です。ユーザーが Space の割り当てを変更している場合は、そのキー設定が優先されます。

既存のカスタムキー設定を使っている場合は、MS-IME 風キー設定を選び直すか、キー設定画面で「入力文字なし」の Space に「選択文字列を再変換（未選択時は空白）」を手動で割り当てることで有効にできます。

左右 Shift / Ctrl の個別キー割り当て（Windows）

Windows 版では、左 Shift / 右 Shift / 左 Ctrl / 右 Ctrl にそれぞれ IME の操作を割り当てられます。たとえば右 Shift で IME を有効化し、左 Shift で無効化することもできます。

設定例:

• DirectInput + RightShift -> IMEOn
• Precomposition + LeftShift -> IMEOff
• Composition + LeftShift -> IMEOff
• Conversion + LeftShift -> IMEOff
• DirectInput + RightCtrl -> IMEOn
• Precomposition + LeftCtrl -> IMEOff

キー設定エディタでは、Ctrl と Shift の左右条件をそれぞれ独立して指定できます。キーを入力した後、該当する修飾キーについて「左右どちらでも」「左のみ」「右のみ」を選択します。Ctrl / Shift が割り当てに含まれない場合、その修飾キーの選択欄は無効になります。

「左右どちらでも」は従来の汎用 Ctrl / Shift と同じ意味です。Ctrl j のような既存のキー設定は、左 Ctrl / 右 Ctrl のどちらでも動作します。キー入力を取り込んだ直後は、検出できた左右の物理キー指定を初期値として使用します。

従来の汎用割り当てを残したまま、左右を限定した割り当ても作成できます。ただし、同じ入力状態で同じ物理キー操作に一致し得る割り当てを、異なるコマンドに設定すると保存時に競合として拒否されます。 たとえば、同じ入力状態の Ctrl Delete と LeftCtrl Delete に別々のコマンドを割り当てることはできません。

CapsLock が有効な場合も、左右指定の照合と汎用ショートカットへのフォールバックを行います。Windows 専用の VK_IME_ON / VK_IME_OFF は、CapsLock のトグル状態だけを理由に修飾キー付き操作として扱われません。

左右両方を同時に押す特殊な操作、特に修飾キー単独の組み合わせにおける TSF のキー解放タイミングは、すべての挙動を保証するものではありません。また、外部から取り込んだ「左右両方を同時に要求する」設定は、3択の選択欄では表現できないため、元の設定を保持したままその欄の編集を無効にします。

IMEOn または IMEOff に明示的に割り当てたキーを押した場合は、すでに同じ状態であっても IME モードインジケータを表示します。たとえば、IME がすでに無効の状態で IMEOff キーを押しても、直接入力状態のインジケータを表示します。

これにより、IME 有効化・無効化キーを「状態を切り替えるキー」としてだけでなく、現在状態を視覚的に確認するためのキーとしても使えます。

一時英数字入力から IME ON でひらがなへ復帰（Windows）

Shift などによって半角英数字の一時入力モードに切り替わっている場合、IMEOn に割り当てられたキーを押すと、既存の未確定文字列を確定せずに入力モードだけをひらがなへ変更します。タスクバーの入力モード表示も「あ」に更新されます。

たとえば、Shift による一時英数字切り替えが有効な設定で Shift+G → o → o → IMEOn → a と入力すると、Gooあ を同じ未確定文字列のまま入力できます。カタカナ入力から一時的に英数字へ切り替えた場合も、IMEOn の復帰先はひらがなです。

対象は、現在の入力モードが半角英数字で、復帰先として異なる入力モードが保持されている場合です。通常のひらがな入力中や、復帰先も半角英数字である明示的な半角英数字入力中は、従来どおり IMEOn で入力モードを変更しません。IMEOff による直接入力への切り替えも従来どおりです。

Windows 既定 IME 設定

Windows 版では、設定画面の「その他の設定」→「既定の IME」から、Mozkey を Windows の既定 IME として明示的に設定できます。

この操作はログオン時に自動実行されるものではなく、ユーザーが設定ボタンを押した場合だけ実行されます。

設定時には、変更前の Windows 既定 IME の上書き設定と、日本語入力方式リストの順序を保存します。「以前の Windows 既定 IME 設定に戻す...」ボタンを押すと、保存していた設定へ戻します。

すでに Mozkey が既定 IME として設定されている場合や、未復元のバックアップが残っている場合は、変更前の復元点を上書きしないようにしています。

Windows IME アイコン設定

Windows 版では、設定画面から Mozkey の IME アイコンを切り替えられます。

選択肢は以下です。

• 既定
• モノクロ（ライト・ダーク対応）
• モノクロ（黒）
• モノクロ（白）

「モノクロ（ライト・ダーク対応）」は、既存の黒モノクロアイコンの形状を維持しつつ、透明背景側に細い白の逆色エッジを加えた静的アイコンです。ライト / ダークのどちらでも視認しやすくするためのもので、Windows のシステムテーマに応じてアイコン自体を切り替える機能ではありません。

この設定は、Windows の TSF language profile に登録されている Mozkey の IconFile / IconIndex を更新し、タスクバーや IME 一覧に表示される IME アイコンへ反映します。

適用時には、管理者権限の確認が表示される場合があります。また、Windows 側のアイコン cache や入力方式一覧の更新タイミングにより、タスクバーや IME 一覧のアイコンがすぐに更新されない場合があります。その場合は Windows を再起動してください。

Windows Search / immersive TSF 対応

Windows 版では、Windows Search の検索 UI のような immersive TSF 環境で、候補ウィンドウ、サジェストウィンドウ、ライブ変換中のルビ表示がホスト側の表示階層の背面へ隠れないように、TSF ホストプロセス内の専用 renderer UI thread で Win32 renderer を動かす経路を使用します。候補・サジェスト・ルビの各ウィンドウはホスト側の top-level window を owner として作成し、入力先のフォーカスを奪わない形で表示します。

通常の変換候補では、従来どおり mouse-down で候補をハイライトし、mouse-up でその候補を選択します。

一方、まだ候補がフォーカスされていない passive なサジェストでは、mouse-down だけでは候補のハイライトや通常変換状態への移行を行いません。押されたサジェストの candidate ID をその mouse gesture 中だけ保持し、mouse-up 時に SUBMIT_CANDIDATE として確定します。

ライブ変換中の passive Suggestion は、画面に表示する候補を通常の live-conversion context とは別の cloned ImeContext で生成します。そのため、表示された Suggestion と通常変換候補で同じ数値の candidate ID が別の候補を指す場合があります。Mozkey は表示した Suggestion を生成した cloned context も保持し、mouse-up 時の candidate ID をその同じ converter state で解決することで、画面上で押した Suggestion とは別の通常変換候補が確定されることを防ぎます。

サジェストを押したまま候補外へ移動して mouse-up した場合は確定せず、通常候補のクリック操作は従来の挙動を維持します。

候補ウィンドウ・サジェストウィンドウ・ルビ表示の外観設定（Windows / macOS）

Windows / macOS 版では、設定画面から候補ウィンドウ、サジェストウィンドウ、ライブ変換中のルビ表示の外観を調整できます。

候補ウィンドウ、サジェストウィンドウ、ルビ表示は、ライト / ダーク / 自動（システムテーマに合わせる）/ カスタム配色を選択できます。新規設定では3項目とも「自動」が既定です。「自動」では現在のシステム外観を参照し、OS のライト / ダークテーマを変更した場合は次の renderer 更新から新しい外観を反映します。

ライト / ダーク / カスタム配色を明示的に選択した場合は、システムテーマの変更には追従しません。サジェストウィンドウとルビ表示には「候補ウィンドウに追従」もあり、候補ウィンドウで解決された配色やカスタム配色を引き継ぎます。「自動」と「候補ウィンドウに追従」は別の設定です。

カスタム配色では、候補ウィンドウとサジェストウィンドウについて、背景、文字、選択背景、選択枠、枠線、ショートカット、説明、フッター、スクロールバーなどの色を調整できます。ルビ表示については、背景、文字、枠線の色を調整できます。

各ウィンドウの表示サイズ、角丸、透明度、影の広がり、濃さ、方向、距離も設定できます。影の方向は画面座標基準の角度で指定し、0° は右、45° は右下、90° は下を表します。影の距離を 0 にすると、全方向に均等な影になります。変換候補・用例などの候補系表示には候補ウィンドウ設定を使い、予測・サジェスト系表示にはサジェストウィンドウ設定を使います。

Windows 版のルビ表示では、左右の余白、上下の余白、入力文字との距離を個別に設定できます。これらは固定の物理ピクセル値ではなく、ルビ表示のサイズ設定と表示先モニターの DPI に応じて拡大縮小されます。複数モニター環境では、入力位置があるモニターの DPI を基準にフォント、余白、角丸、影、入力文字との距離を再計算し、TSF から得た入力位置も物理座標へ変換して配置します。

候補ウィンドウ、用例ウィンドウ、ライブ変換中のルビ表示に使うフォントも設定画面から変更できます。既定フォントに戻すこともでき、選択したフォントを候補表示に適用できない場合は、候補ウィンドウが消えないように既定フォントへフォールバックします。

候補ウィンドウ、サジェストウィンドウ、ライブ変換中のルビ表示については、主要テキストの太さもそれぞれ 100～900 の範囲で個別に設定できます。既定値は 400（標準 / Regular）です。候補番号、説明、フッター、用例ウィンドウ内の文字などの補助情報は対象外で、従来の太さを維持します。

ライブ変換中のルビ表示は、設定画面から ON/OFF を切り替えられます。

変換状態インジケータ（Windows / macOS）

未確定文字の近くに、現在の変換処理の状態を示す小さなインジケータを表示できます。ライブ変換のルビ表示や、IME の有効・無効を示す「IME 切り替えインジケータ」とは別の機能です。設定画面の「入力・表示」内にある「変換状態インジケータ」から変更できます。新規・未設定のプロファイルでは既定で表示 ON ですが、明示的に保存済みの OFF 設定は維持します。ルビ表示を OFF にしても、インジケータ自体は利用できます。

これは現在の表示・処理状態であり、未確定文字列の各文字が Mozc / Zenz のどちらに由来するかを示すものではありません。特に「Zenz処理中」は、表示中の文字列すべてが Zenz で生成済みであることを意味しません。

設定画面では、カプセル / 円形 / 角丸四角形の形状、名称 / 記号 / 色のみのラベル、状態別の色、文字色・枠線色、フォント、サイズ、透明度、角丸、枠線、影、表示位置、間隔と水平・垂直方向の補正を調整できます。「標準 / ミニマル / 詳細」プリセットの適用にも対応し、変更内容が既存のプリセットと一致しなければ「カスタム」として表示します。プレビューは4状態を同時に表示し、インジケータの表示設定が OFF でも利用できます。初期の状態色は Mozc #586B85、Zenz処理中 #847438、Zenz適用済み #338D85、入力中 #747D8C です。

表示位置は「自動（重なりを回避）」「ルビの横」「ルビの上」「未確定文字の上」「未確定文字の下」から選択できます。横書きの「ルビの横」はルビと上下中央を揃え、縦書きでは同項目がルビの下に相当し、左右中央を揃えます。一方、横書きの「ルビの上」は左端を、縦書きでルビ列の外側に置く配置は上端を基準にします。水平・垂直方向の補正は、こうした基準位置の決定後に適用されます。ルビがない場合も未確定文字の位置を基準に配置します。

候補を明示的に選択・移動している間はインジケータを隠します。ただし、候補をまだ選択していない受動的なライブ変換サジェストの表示だけでは隠しません。未確定文字、ルビ、候補ウィンドウとの重なりを避け、指定した固定位置に安全に配置できない場合は、別方向へ無理に移動せず非表示にします。

Windows 版の IME 切り替えインジケータは、設定画面から「システムテーマに合わせる / ダーク / ライト / カスタム」を選択できます。「システムテーマに合わせる」では Windows のライト / ダークテーマに追従し、「ダーク」「ライト」を明示した場合は Windows のテーマ変更に追従せず、その配色を維持します。「カスタム」では英数字・ひらがな・カタカナの背景色・枠線色・文字色・影色に加え、幅・高さ・角丸・文字サイズ・枠線幅・影のぼかし・濃さ・位置を調整できます。

入力位置がモニターの作業領域端付近にある場合は、インジケータが画面外にはみ出さないよう表示位置を自動調整します。外観設定の「リセット」はテーマとカスタム値を既定値へ戻しますが、インジケータの表示 ON/OFF 設定は変更しません。

Windows TSF プライベート入力（IS_PRIVATE）

Windows 版では、TSF input scope に IS_PRIVATE が含まれる入力を、Mozkey のシークレットモードとは別の private-input 状態として扱います。Chrome Incognito、Edge InPrivate、Firefox Private Browser など、この scope を通知する環境では、既存の Mozc 学習履歴や Zenz feedback を候補生成・ranking に利用でき、Zenz のローカル推論も継続しますが、その private input を起点とする新しい永続学習は保存しません。

具体的には、通常の DEFAULT_HISTORY はその request だけ READ_ONLY 相当として扱い、既存履歴の読み取りを維持したまま Mozc history / サジェスト履歴への新規書き込みを止めます。Zenz feedback も保存済みデータの読み取りは維持しますが、新しい feedback の保存と、accepted Zenz 結果から Mozc history への追加学習は行いません。もともと READ_ONLY / NO_HISTORY に設定されている場合は、その設定を上書きしません。

private input 中は、Windows のタスクバーに表示される入力モードアイコンと IME 切り替えインジケータに小さな盾を重ねて表示します。この盾は TSF IS_PRIVATE の状態を示すもので、Mozkey のシークレットモードだけでは表示しません。タスクバー側の通常入力モード文字、private の盾、IME 無効時の × は Windows のシステムテーマに合わせて黒 / 白を切り替え、テーマ変更にも追従します。IME 無効状態では × 表示を優先します。

縦書き対応（Windows / macOS）

Windows / macOS 版では、縦書き入力時に候補ウィンドウ、予測・サジェスト、用例表示、ライブ変換中のルビを縦組みに合わせて表示します。横書き時の既存動作は維持します。

縦書きの候補操作では、Windows / macOS のどちらでも、縦書き状態を session 側へ伝え、現在のキー設定が対応する既存コマンド割り当てに一致する場合に、視覚方向に合わせて矢印キーを解釈します。

• Suggestion では Left で候補へ移動
• Conversion / Prediction では Left / Right で候補の前後へ移動し、Up / Down で前後の文節へ移動
• Conversion では Shift+Up で文節幅を縮小、Shift+Down で文節幅を拡大
• 既存の Shift+Left / Shift+Right による文節幅変更も互換操作として維持

通常の横書き動作、通常 Composition 中のカーソル操作、Ctrl+Shift 系の操作、および対応するコマンド割り当てを持たないキー設定は従来動作を維持します。

Windows

Windows 版では、縦書きの入力位置を検出し、候補や用例の主要テキストを DirectWrite の縦書き描画で表示します。

候補ウィンドウは縦書きの入力位置に対して左側への配置を優先し、アプリケーションから渡される入力行の幅が狭い場合でも、入力文字と候補表示が近づきすぎないように配置を補正します。アプリケーション名ごとの個別分岐ではなく、入力位置の geometry に基づいて調整します。

縦書きの候補列は、候補ごとの文字量や説明の有無に応じた自然な幅・高さで配置します。長い候補がある場合でも、他の候補列まで一律に引き伸ばさず、それぞれの候補に必要な大きさを保ちます。選択中の候補は、文字列自体が短い場合でも候補本文領域の下端まで選択背景を伸ばし、縦書きの列として現在位置を確認しやすくしています。

連鎖候補ウィンドウは、現在選択している候補を基準に、縦書き本文から見て外側となる左側への展開を優先します。候補ウィンドウや入力位置との重なり、または画面端の制約により左側へ配置できない場合は右側へフォールバックします。通常の横書き時は従来の配置を維持します。

ライブ変換中のルビも縦書き composition に追従します。Word などで未確定文字列が複数の縦列へ折り返す場合は、すでに表示されている composition 列と重ならない位置へルビを配置します。

macOS

macOS 版では、IMK 側で取得した writing direction をレンダラーへ伝播し、候補・用例・ルビの主要テキストを Core Text の縦書き描画で表示します。

候補／サジェストでは、Core Text が全文を確実に描画できる技術的な text frame と、画面上で実際に見せる候補列の幅を分離しています。表示幅は CJK の標準的な列幅を下限としつつ、実際のグリフ幅がそれを超える場合だけ拡張します。これにより、日本語・ASCII・半角カナなどが混在しても、必要以上に太い候補列になりにくいようにしています。

縦書き時の候補／サジェストと本文との間隔は 6 pt とし、ライブ変換中のルビも実効 6 pt の間隔で配置します。横書き時の既存の間隔・配置は変更しません。

用例表示（Infolist）は縦書き時に列ごとの Core Text frame を使って描画し、縦組みの表示方向に合わせて配置します。ルビ表示も、描画用 frame を確保しつつ、可視部分は CJK の標準列幅と実際のグリフ幅に基づいて過不足なく配置します。

連鎖候補ウィンドウは、現在の候補位置を基準に、縦書き本文から見て外側となる左側への展開を優先します。候補ウィンドウや preedit との重なりを避けられない場合は右側へフォールバックし、同じ階層の連鎖候補同士も重ならないように配置します。

これらの縦書き処理は macOS 専用の layout / writing-direction ロジックとして分離し、候補レイアウト、Infolist レイアウト、writing direction、ウィンドウ配置の単体テストを追加しています。通常の横書き経路は従来動作を維持します。

Windows 未確定文字の表示と表示色

Windows 版では、ローマ字入力時に「未確定のローマ字を薄く表示する」を有効にすると、変換規則の途中にある末尾の未確定ローマ字だけを通常の preedit と分けて表示できます。この機能は表示だけを変更し、入力文字列、変換用の key、確定結果は変更しません。

この設定は opt-in で、設定値がまだ存在しない新規・未設定のプロファイルでは既定 OFF です。すでに明示的な ON / OFF が保存されている場合は、そのユーザー設定を維持します。薄さは 0～100% の範囲を 1% 単位で設定でき、既定値は 85% です。値を大きくすると背景色に近づいてより薄く見え、0% は高いコントラスト、100% は背景色と同じになって不可視になります。

未確定ローマ字の表示情報は通常の入力中だけでなく、ライブ変換や Zenz 補正を表示している経路でも、元の segment の key / value を壊さず安全に保持できる範囲で引き継ぎます。表示のために key を value から合成することはせず、安全に分割できない segment は元の key / value のまま扱います。

この表示は Windows TSF の専用 display attribute として適用します。Firefox などの Gecko 系ホストでは、編集面の背景を安全に取得できた場合だけ、その背景に合わせた薄い文字色を使用します。選択範囲、clipped な geometry、非均一な背景など信頼できない状態は背景色として固定せず、互換表示へフォールバックします。また、この機能が OFF のときは背景取得のための画面 sampling を行いません。

あわせて、Windows 版では設定画面から「入力中の文字」「変換中の文節」「Zenz 補正中の文字」について、それぞれ以下の表示色を個別に設定できます。

• 文字色
• 背景色
• 下線色

新規・未設定のプロファイルでは、入力中の下線色は #30DCC8、変換中の文節の下線色は #C1A5AB が既定です。「Zenz 補正中の文字」では専用の下線色が既定で有効になり、既定色は #C4DC6C です。Zenz 専用の文字色・背景色は既定では無効で、無効な色チャネルは変換中の文節側のカスタム色が有効ならそれを引き継ぎ、そうでなければ Windows TSF の既存表示へフォールバックします。すでに各色やその有効 / 無効を明示的に保存している場合は、その既存設定を維持します。

日本語入力中・変換中の未確定文字を見やすくするための機能です。特に、視認性を高めたいユーザー向けのアクセシビリティ改善として追加しています。

これらの設定は Windows TSF の表示属性として反映されます。対応アプリでのみ有効です。Chrome や Edge など、一部のアプリでは反映されない場合があります。

system dictionary の強化

この fork では、外部辞書を元に Mozc の system dictionary を強化するための生成スクリプトを追加しています。

また、外部辞書とは別に、Mozkey 独自の小さな manual override 辞書で、日常語彙・実務語彙・外来語・英語綴り候補を段階的に補強します。通常の日本語語彙は自然な第一候補として、英語綴り候補は第一候補ではなく補助候補として出ることを重視します。評価方針と検証手順は Koyasi Dictionary Data から参照できます。

daily local 辞書は主に以下を元に生成できます。

• merge-ut-dictionaries
  • 地名
  • SudachiDict 由来語彙
• dic-nico-intersection-pixiv
  • 固有名詞、ネットスラング、作品名、キャラクター名、サブカル系語彙
  • 生成済み daily 辞書または Mozc 標準辞書に既に存在する key/value は除外
  • 末尾に ☆、★、♡、♪、※ などの装飾記号が付く表記は daily 変換ではノイズになりやすいため除外
• mozcdic-ut-personal-names
  • 人名・芸名・活動名などを含む人名辞書
  • 生成済み daily 辞書、nico/pixiv delta、Mozc 標準辞書に既に存在する key/value は除外
  • 短すぎる読み、長いカタカナ塊、グループ名風表記、ASCII 表記、記号を含む表記などは除外または弱める
• Mozkey syntax / expressive kana guard 辞書
  • 文節区切り崩れの影響が大きいケースだけを小さな生成辞書として補強
  • 例: と打ちたいのに、に分ける、した方が、したにもかかわらず、にまで、までに、までも、肌身離さず、になってしまいます、になっちゃいます のような経路を保護
  • 例: うっそ、くっそ、やっば、ちっす、ほえ～、ほぇ～ のような完成済み expressive kana を自然なかな候補として補強

巨大な生成辞書ファイルは、このリポジトリには commit しません。src/data/dictionary_koyasi/generated/ 以下にローカル生成します。

リリース MSI には、ローカル生成した daily system dictionary profile を同梱する場合があります。外部辞書の出典とライセンス note は Third-party notices および Koyasi Dictionary Data を参照してください。

強化辞書を有効にした状態で package build する前に、daily 辞書をローカルで再生成してください。

.\tools\dictionary\prepare_daily_dictionary.ps1

詳細:

• Koyasi Dictionary Data
• Third-party notices

開発者向けドキュメント

ソースからのビルド、Zenz runtime の同梱、インストーラーの検証は、以下の文書を参照してください。

• Windows ビルド手順
• macOS Universal Zenz runtime / PKG ビルド手順
• macOS インストーラーの検証手順
• Linux ビルド手順

English

Mozkey is an unofficial fork of google/mozc. It preserves the standard Mozc conversion engine while adding delayed live conversion, context-aware correction with local Zenz inference, vertical-writing support, extensive appearance customization, and flexible input and learning controls.

Mozkey is not an official Google Japanese Input or google/mozc distribution.

Key features

• Delayed live conversion and reading overlay: Converts compositions before Space is pressed, with adjustable debounce delay, minimum length, and ruby-like display of the reading.
• Layered Mozc + Zenz conversion: Keeps normal Mozc conversion as the baseline and adds optional local Zenz correction, falling back to Mozc when a correction is not adopted.
• Context-aware correction with spelling safeguards: Uses available preceding and following context while protecting user-dictionary entries, Latin/technical spellings, numeric literals, and punctuation choices.
• Optional deferred presentation: Choose whether to display Mozc live conversion immediately or briefly wait for Zenz before showing a result.
• Controllable learning and candidates: Configure Zenz accept/reject recording, feedback reuse, and Mozc-history learning independently; manage feedback, hide unwanted candidates, and undo recent commits.
• Vertical-writing UI on Windows and macOS: Candidate, suggestion, infolist, and ruby layouts adapt to vertical text; supported keymaps can follow the visual navigation direction.
• Conversion-status indicator (Windows / macOS): Displays Reading, Mozc, Zenz processing, or Zenz applied near the composition, with adjustable position, shape, and colors. The new macOS indicator has not yet been verified on native macOS hardware.
• Extensive appearance customization: Configure colors (light/dark/system/custom), dimensions, rounded corners, opacity, and shadows per window. Windows additionally supports font/weight, preedit colors and underlines, and IME-indicator styling.
• Customizable romaji and shortcuts: Edit romaji rules, show intermediate output for ambiguous sequences, commit punctuation with one key, and assign ordered key commands with delays.
• Improved Japanese conversion and dictionaries: Enhances everyday expressions and names, reduces unwanted segmentation and kanji conversion, and adds date and weekday suggestions.
• Local-first operation and OS integration: Runs Zenz inference locally, disables inherited usage-statistics reporting, supports privacy-aware input behavior, and improves candidate display in Windows Search and other immersive TSF hosts.

For implementation details and settings, see the feature list and detailed explanations below.

Download / platform availability

The GitHub Releases currently provide prebuilt Windows installers. Check each release's Assets for the packages actually available. A public macOS Universal PKG is not yet available.

• Windows x64: Use the x64 MSI.
• Windows ARM64: If an ARM64 MSI is published in a given release, use it for Windows on Arm. That package contains native ARM64 Mozkey and Zenz runtime components.
• macOS: A Universal PKG for Apple Silicon and Intel Macs is under development and validation; it is not currently published as a Release asset.
• Linux: Upstream Mozc supports Linux, but this fork's features have not been validated there and no Linux installer is distributed.

The Windows universal MSI is not a fully dual-native x64/ARM64 package. Prefer the architecture-specific MSI. Zenz-enabled packages bundle a local inference runtime and GGUF model, so they are larger. Some Windows MSIs also include a generated daily dictionary. See Third-party notices for provenance and licenses.

[!NOTE] Mozkey is not an official Google or google/mozc distribution. The currently published Windows MSIs are unsigned and may trigger operating-system warnings. Development macOS PKGs are not publicly distributed Developer ID-signed and notarized packages; see Apple's guidance.

Code signing policy

Mozkey's currently published Windows MSI installers are unsigned. The project is preparing an application for free open-source code signing through SignPath Foundation; no approval or signed release is implied at this stage.

See the Code signing policy for the proposed signing scope, project responsibilities, privacy disclosures, and release verification process.

macOS initial setup (development PKGs)

No public macOS installer is currently available. These instructions apply only after installing an audited, explicitly installable development PKG. Ordinary guarded OSS builds refuse installation; see the macOS installer test guide.

1. After installing the PKG, open System Settings → Keyboard → Text Input → Edit.
2. If Hiragana (Mozkey) is not listed, click +, choose Japanese, and add the Mozkey Hiragana input source. The name may be localized.
3. Select Mozkey's Hiragana input source in the menu-bar input menu.
4. If it does not appear, log out of macOS and log back in, then check again.

See Apple's input-source settings guide for details.

Privacy / Network Access

This fork is designed to run without network communication from Mozc runtime processes during normal IME operation.

The usage-statistics and crash-report option inherited from upstream has been removed from the administration and configuration dialogs.

The default StatsConfigUtil implementation is fixed to the null implementation in this fork, and usage statistics cannot be enabled through the normal runtime path.

Windows release binaries are checked so that Mozc core runtime executables do not import common networking libraries such as winhttp.dll, wininet.dll, or urlmon.dll.

This fork may also bundle a local Zenz inference runtime based on llama.cpp. The Zenz runtime is used for local inference and is not intended to expose an external network service or send user input to external servers.

In the Windows Zenz-bundled configuration, llama-server.exe is used as a local-only inference server and is expected to bind to 127.0.0.1. On Windows, the Zenz helper process communicates with the bundled llama-server.exe only through a localhost endpoint. This local HTTP endpoint is used as an internal process boundary for inference and is not intended for external network access.

The Zenz localhost transport is hardened so that it does not rely on a fixed endpoint, and internal requests include protection against accidental or stale local endpoint mismatches.

Zenz feedback recording (A) stores only full-sequence local learning records such as the complete reading, the complete candidate, coarse context class, accepted/rejected counts, and reason markers. Raw left context is not stored. Context used for feedback is reduced to a non-reversible class such as empty, japanese_only, japanese_with_punctuation, mixed_japanese_ascii, or sensitive_like. Segment-local or lexical-unit learning is intentionally not stored in the Zenz feedback TSV; safe local learning belongs to Mozc history.

In Secret / Incognito mode, local Zenz inference remains enabled, but Zenz feedback personalization is disabled. Stored feedback is not consulted for candidate ranking, session-level fast-path reuse, or feedback decisions, and no new accepted, rejected, or accepted_rollback feedback is persisted. Existing feedback is left intact and becomes available again after leaving Incognito mode.

On Windows, TSF IS_PRIVATE is treated as a privacy signal distinct from Mozkey Secret / Incognito mode. In environments such as Chrome Incognito, Edge InPrivate, and Firefox Private Browser that include IS_PRIVATE in the input scope, stored Mozc learning history (conversion and suggestion) and Zenz feedback remain readable, and local Zenz inference remains available. New persistent writes originating from that private input are suppressed for Mozc history, suggestion history, Zenz feedback, and Zenz-to-Mozc-history learning. Existing learning data is not deleted. IS_PRIVATE is also kept separate from password input scopes, whose existing protections remain in place.

Additional release checks verify that Mozc core runtime binaries do not contain hard-deny telemetry, updater, crash-upload, or usage-statistics markers.

Generic URL-like markers such as http://, https://, and googleapis.com are reported for audit, but they are not treated as hard failures because they can come from manifests, XML namespaces, comments, license files, or library metadata.

Building from source may require network access to download build dependencies. This is separate from runtime behavior of the installed IME.

On Windows, the installer also adds outbound Windows Firewall block rules for Mozc runtime executables as an additional offline hardening layer. For Zenz-bundled builds, the rules also cover mozc_zenz_scorer.exe and llama-server.exe. These rules are removed during uninstall.

See also:

• Secure Offline Guarantee
• Secure Offline Release Checklist

Main branches

• main: main branch for daily use
• master: upstream tracking branch
• pr/*: upstream-oriented proposal branches

Main features added in this fork

• Adds an option to display ambiguous romaji rules before the input is fully disambiguated
• Adds a checkbox UI for that option to the romaji table editor
• Allows a custom romaji-table rule to produce output shorter than 1024 UTF-8 bytes while keeping the existing input and pending limits below 300 bytes
• Adds an option to directly commit punctuations and symbols with a single key press
• Allows choosing direct-commit punctuations and symbols from the config dialog
• Makes punctuation conversion and punctuation/symbol direct commit mutually exclusive
• Improves user-history learning behavior when a committed conversion is immediately corrected with Backspace or Cancel
• Learns a hiragana choice when an active conversion is canceled with Esc, Ctrl+Z, or another key bound to Cancel and the restored hiragana preedit is immediately committed with Enter or a direct-commit punctuation/symbol, similarly to F6 -> Enter
• For multi-segment conversions canceled back to hiragana, preserves conversion-time segment boundaries when possible and learns each hiragana segment as a spelling preference, rather than as a single whole restored preedit
• Keeps learning caused by direct-commit punctuations/symbols pending until the next real text input, reverts it on Backspace, Escape, cancel-equivalent keys such as Ctrl+Z, Revert, Reset, or Undo, and confirms it on IMEOff / MakeSureIMEOff
• Adds live conversion that automatically converts the current composition and shows a ruby-like overlay for the original reading
• Allows enabling/disabling live conversion and configuring its debounce delay and minimum start length from the config dialog
• Supports seven-digit postal codes without a hyphen (for example, 1000001) using existing postal dictionary entries; live conversion keeps the numeric literal first, and a key bound to ConvertNext (Space in the standard keymap) advances to later candidates
• Applies live conversion after a short debounce delay to avoid noisy intermediate conversions
• Reduces candidate-window flicker by holding passive suggestions for unresolved Roman prefixes that do not change the prediction reading; when a custom DisplayAmbiguousResult rule exposes a meaningful reading and changes the prediction query, suggestions refresh even while the Roman suffix remains pending. Entering the candidate list uses the exact displayed candidates
• For explicitly accepted suggestions, verifies the complete reading, native segment mapping, and actual normal-conversion candidate order before learning segment-level preferences; preserves the original committed text and suggestion history, and skips speculative learning when the mapping or displayed ranking cannot be verified
• By default, suppresses live conversion for one-character compositions to avoid over-converting particles
• Suppresses live conversion for very short kana compositions with decorative trailing symbols such as え~, えー, or ん？
• Reinforces expressive kana forms such as うっそ, くっそ, やっば, すっげぇ, めっちゃ, ちっす, ちょりっす, ほえ～, ほぇ～, and ほっほーん with natural-kana generated dictionary candidates
• Uses committed left context, previous segments, and limited right context to reduce unnatural homophone results in cases such as mainにマージしました, githubには, 彼になった, 彼なのか, 2名しかいない, 追記したい, 山梨県立美術館, and 滋賀方面
• Allows assigning multiple commands to a single key binding as an ordered command sequence
• Adds ForceZenzLiveCorrection to explicitly request Zenz correction for uncommitted text, including when automatic Zenz live correction is disabled
• Adds ForceZenzLiveCorrectionWithoutFeedback to request a one-shot correction without automatically reusing stored Zenz feedback, while retaining normal Mozc history, user-dictionary entries, explicit manual blocks, and settings-controlled learning of newly committed results
• Adds Delay(700)-style waiting steps (0–5000 ms) in keymap command sequences, including after selected-text reconversion
• Adds a candidate history-delete / hide action for conversion and prediction candidates. The standard keymaps use Ctrl+Delete: history-backed candidates are removed from learned history first, while candidates that still remain can be stored as suppression words in the 非表示候補 user dictionary. The original user-dictionary entry is not deleted, and removing the corresponding suppression entry restores the candidate. The candidate footer shows history-delete or hide guidance for the currently selected candidate using the active key binding
• Prevents candidates that Mozc can semantically identify as emoticons—built-in emoticon candidates and user-dictionary entries registered with the 顔文字 POS—from being promoted to the first candidate in ordinary conversion through learning. The candidates remain visible, while the same surface registered under a non-emoticon POS remains eligible for normal ranking and learning. Independently generated Zenz surfaces are not classified as emoticons from string shape alone
• Also prevents built-in EmojiRewriter emoji candidates from being promoted to the top of ordinary conversion by learning. Emojis remain selectable below the first candidate, and explicit user-dictionary symbol entries with the same spelling retain ordinary ranking eligibility
• Stores command sequences as Commit|IMEOff and shows them in the keymap editor as Commit → IMEOff
• In the MS-IME style keymap, pressing Space while committed text is selected reconverts that selection; with no selection, Space still inserts a normal space
• On Windows, allows independently selecting Either side / Left only / Right only for Ctrl and Shift in the keybinding editor; generic Ctrl/Shift shortcuts remain supported, while conflicting bindings for different commands are rejected when saving
• Shows the IME mode indicator even when a key assigned to IMEOn or IMEOff is pressed while Mozc is already in that state
• On Windows, pressing IMEOn during temporary half-width ASCII input restores hiragana input without committing the existing preedit
• Adds explicit Windows default IME controls to the config dialog, with restore support for the previous default IME setting
• Allows choosing the Windows Mozkey IME profile icon from Default, Monochrome (Light/Dark), Monochrome (Black), and Monochrome (White) in the config dialog
• Supports candidate, suggestion, and live-conversion ruby rendering in immersive TSF hosts such as Windows Search through an in-process renderer path, keeping the UI above the host presentation layer and preserving correct mouse selection; an unfocused passive suggestion does not enter normal conversion on mouse-down, and mouse-up commits the suggestion that was actually clicked
• Allows configuring light/dark/auto (follow system theme)/custom color themes, size, corner radius, opacity, and shadow separately for the candidate window, suggestion window, and live-conversion ruby display on Windows and macOS; new configurations default all three theme selectors to Auto
• Makes the Windows ruby display use target-monitor DPI-aware positioning and scaling, and allows configuring its horizontal padding, vertical padding, and distance from the input text
• Allows the suggestion window and ruby display to either follow the candidate window color theme or use their own theme/custom colors; Auto follows the OS system theme directly and is distinct from Follow Candidate
• Allows changing the font used for the Windows candidate window, infolist window, and live-conversion ruby display from the config dialog
• Allows configuring the primary text weight independently from 100 to 900 for the Windows candidate window, suggestion window, and live-conversion ruby display
• Adds vertical-writing layouts for candidate, suggestion, infolist, and live-conversion ruby displays on Windows and macOS, with candidate and segment navigation aligned to the visual writing direction when the active keymap uses the supported command bindings
• On Windows and macOS, places cascading candidate windows outward from the focused vertical candidate, with fallback to the opposite side when necessary
• Allows enabling or disabling the ruby display shown during live conversion from the config dialog
• Adds an independent conversion-status indicator for Windows/macOS near the composition, with Reading / Mozc / Zenz processing / Zenz applied states and configurable placement, colors, shape, font, size, and shadow
• Allows customizing Windows preedit text color, background color, and underline color from the config dialog for input text, converting segments, and "Text being corrected by Zenz" separately; the underline for Zenz-corrected text defaults to enabled with #C4DC6C for new or otherwise unset profiles
• Adds an opt-in Windows feature for Roman input that dims only the unresolved trailing romaji still forming an incomplete conversion-rule prefix; it defaults to OFF and the dimness can be adjusted from 0% to 100% (default 85%); 100% matches the background and becomes invisible
• Allows choosing System theme, Dark, Light, or Custom for the Windows IME mode indicator, including per-mode colors and geometry/shadow customization, with automatic screen-edge repositioning
• On Windows TSF input marked with IS_PRIVATE, keeps existing Mozc learning history and Zenz feedback available for reading while suppressing new persistent learning. This is separate from Mozkey Secret / Incognito mode; private input is marked with a shield in the taskbar input-mode icon and IME mode indicator, while normal/private/disabled taskbar mode glyphs follow the Windows light/dark system theme
• Adds an enhanced system dictionary generation pipeline
• Adds a small tracked manual override dictionary for daily vocabulary, practical vocabulary, loanwords, and secondary English spelling candidates, with regression checks that keep Japanese candidates first
• Allows incorporating place names and SudachiDict-derived vocabulary from merge-ut-dictionaries into the system dictionary
• Allows adding internet/subculture proper nouns from dic-nico-intersection-pixiv as daily-dictionary differences
• Allows adding a weak personal-name dictionary from mozcdic-ut-personal-names after removing entries already covered by the generated daily dictionary, nico/pixiv delta dictionary, or base Mozc dictionaries
• Adds a syntax guard dictionary generation pipeline to reduce high-impact segmentation failures, including guarded paths such as と打ちたいのに, に分ける, した方が, したにもかかわらず, にまで, までに, までも, and 肌身離さず
• Keeps large generated dictionary files out of Git and switches Bazel dictionary inputs to locally generated files
• Reduces over-conversion of natural functional kana sequences such as には and してたの
• Reduces cases where short two-character hiragana inputs such as にじ are split too aggressively
• Improves date input conversion for compact forms such as 20260927 and separated forms such as 2026/9/27, 2026-9-27, 2026.9.27, and 9/27; full-width input is also recognized, and invalid calendar dates are not expanded as date candidates
• For weekday readings such as きんよう / きんようび, keeps the normal lexical candidates 金曜 / 金曜日 ahead of additional candidates for the matching date in this week, next week, and the previous week
• Adds date expressions such as ほんじつ / みょうにち while preserving explicitly typed date forms such as 9/27 at the front of the candidate order
• Adds a local Zenz live correction pipeline based on llama.cpp
• Uses dedicated zenz_preceding_text / zenz_following_text fields for Zenz context without changing the normal Mozc preceding_text / following_text semantics
• Lets the Server request the required preceding / following lengths and lets Windows TSF / macOS IMK acquire only the requested directions and lengths; right-context acquisition is configurable and defaults to 6 characters when enabled
• Selects preceding and following Zenz context independently and applies shared Unicode-aware script analysis and privacy filtering
• On Windows, sends Zenz correction requests from mozc_server to mozc_zenz_scorer.exe through a named pipe and performs local inference through the localhost endpoint of llama-server.exe
• Hardens the Windows Zenz named pipe against pre-existing same-name pipe instances and remote clients; before sending input, the client verifies the scorer process session, user SID, and executable image path, and sends no prompt to an untrusted peer
• Allows configuring the Zenz correction debounce delay from the config dialog. The default is 700 ms for new or otherwise unset profiles; explicitly saved delay values are preserved
• Allows configuring the minimum number of characters to start Zenz correction
• Adds an opt-in Do not show the normal live-conversion result until Zenz correction returns mode. While waiting, Mozkey preserves the previously stable Zenz-corrected presentation when possible and appends unresolved raw-romaji suffixes to that visible presentation; if Zenz is not adopted, it falls back to the current Mozc live-conversion result
• Adds a configurable deferred-presentation wait limit. The default is 250 ms after the Zenz correction request is submitted; when the deadline expires, that generation is discarded and Mozkey reveals the already-computed normal Mozc live-conversion result
• Commits the presentation that is actually visible to the user, rather than a hidden Mozc baseline, when Enter or Shift-based ASCII input ends a deferred presentation; Undo after Enter restores the same visible presentation
• Detects and rejects likely context echo where Zenz repeats a long suffix of already committed left context at the beginning of the current output, then falls back to the normal Mozc live-conversion result
• Applies lightweight omission guards to fresh Zenz responses and stored-feedback candidates, rejecting obvious leading/trailing truncation relative to the normal Mozc result. Ambiguous overlaps with committed left context fall back to Mozc rather than blindly stripping a matching prefix
• Adds Strict Reading Preservation (Experimental) as an opt-in setting, OFF by default. When enabled, the final Zenz candidate undergoes reverse-reading verification against the complete typed reading; mismatch or unavailable reading falls back to Mozc. Valid candidates and saved-feedback corrections can be rejected, and additional processing may increase latency
• Separates Zenz personalization into three independent settings: A records Zenz accept/reject observations to a local TSV; B automatically reuses existing feedback for candidate ranking, fast-path correction, and statistical auto-blocking; C learns explicitly committed Zenz corrections into regular Mozc conversion history. Recording can be disabled without disabling reuse or Mozc-history learning, and pre-existing legacy preferences are inherited only for new settings that have not yet been explicitly saved
• Limits automatic reuse of stored Zenz feedback to full readings of at least 7 Unicode code points by default, to avoid over-applying learned preferences to short readings with many homophones and context-dependent interpretations. The threshold (1–20) and the gate can be configured; shorter readings are still recorded, and explicit manual hard blocks still apply
• In Secret / Incognito mode, keeps local Zenz inference enabled while disabling Zenz feedback personalization; stored feedback is not reused or consulted for decisions, no new feedback is persisted, and existing feedback is left intact
• Adds adaptive Zenz feedback auto-blocking. For the same full reading, context class, and correction value, auto-blocking activates only when both the minimum ordinary-reject count and the minimum reject percentage over accepted plus ordinary-rejected observations are met. For configurations without a saved value, auto-blocking defaults to enabled with a minimum of 1 rejection and 50%. Auto-blocking does not persist irreversible hard-reject rows; it is re-evaluated dynamically from the current settings and stored feedback.
• Keeps evaluating an auto-blocked Zenz result as a hidden shadow observation. If the final committed value for the same reading matches that hidden Zenz value, accepted feedback is added so the entry can recover automatically once its reject percentage falls below the threshold. A different final value for the same reading adds an ordinary rejection; a changed final reading is neutral. Explicit hard rejects are not eligible for shadow recovery.
• Stops reusing a Zenz feedback entry as a preferred candidate or live-correction fast path when ordinary rejected observations outnumber accepted observations for the same full reading, context class, and correction value. This is a neutral reject-count-dominant state, not a hard block, so it does not delete ordinary Mozc candidates or prevent newly produced Zenz corrections by itself.
• When feedback recording (A) is ON, does not persist a correction merely because it was displayed; only an explicit commit appends accepted full-sequence feedback. A failed append is not treated as a successful observation for Undo compensation
• If Backspace, Escape, Revert, Undo, Ctrl+Z, or a similar correction action occurs inside the rollback window, Mozkey appends accepted_rollback only for an acceptance successfully written to the feedback TSV. Failed writes are not compensated, preventing accidental subtraction from earlier valid acceptance records. Mozc-history revert uses a separate handle. IMEOff / MakeSureIMEOff confirm rather than cancel the commit
• Treats a visible Zenz correction as rejected feedback when the user moves to normal conversion operations such as Space or candidate movement. Ordinary rejected feedback from these operations is used as a negative ranking signal rather than as a hard command to suppress the candidate
• When Space restores the underlying Mozc normal conversion from a visible Zenz correction, the next text input commits that restored conversion before starting a new composition
• Adds a feedback-learning data management UI to the config dialog. Users can search, import, export, delete entries, and clear the feedback TSV. Deleting this feedback does not delete separately learned Mozc conversion history from C
• Allows explicitly blocking selected Zenz corrections from the feedback management UI. Manual hard rejects continue to apply even when automatic feedback reuse (B) is OFF; unblocking requires deleting the corresponding entry
• When automatic reuse (B) is ON, ranks normal single-segment candidates using stored feedback and may insert synthetic candidates at feedback-adjusted positions. Accepted observations raise ranking; ordinary rejections lower it without deleting the candidate
• Does not apply Zenz feedback ranking to multi-segment normal conversions, to avoid collapsing phrase boundaries
• Reuses accepted Zenz feedback via the session-level live-correction fast path for multi-segment live conversion to preserve learned full-phrase corrections
• Does not reuse feedback obtained from sensitive_like context for ordinary-context candidate ranking
• When Mozc-history learning (C) is ON and privacy/history conditions allow it, learns explicitly committed Zenz corrections into Mozc user history independently of feedback recording (A), retaining an in-process revert handle for immediate Undo or similar cancellation
• For accepted Zenz corrections that can be mapped safely onto the previous normal Mozc live-conversion segments, prefers known boundaries, verifies them with a history-free fixed-boundary conversion, and uses Mozc-native resegmentation only for ranges that still need resolution before learning an external multi-segment commit. If multiple boundary interpretations remain, Mozkey does not learn local or boundary history from that inferred split; punctuation-like separators are not crossed either. Candidate structure is reused when possible, and only lexical units with verified Zenz-change evidence are marked as strong user-selected history. If no safe projected/local Mozc-history evidence can be committed at all, the separate full-sequence Mozc-history fallback may still be attempted.
• Protects user-dictionary candidates and ASCII / mixed-script surfaces that appear in the current normal Mozc live-conversion result before adopting Zenz live-correction output
• For ASCII / mixed-script surfaces, temporarily replaces the reading with a placeholder in the Zenz prompt when it can be identified safely, then restores the selected surface after the response, so entries such as もずきー -> Mozkey are not silently overwritten as モズキー while surrounding text can still be corrected
• Treats the surface selected by normal Mozc as an orthographic baseline. When Zenz alone introduces or mutates a Latin / technical spelling such as 東京 -> Tokyo or コンピュータ -> computer, Mozkey restores the affected safely projectable segment to the Mozc surface; Latin / technical tokens already selected by Mozc, such as GitHub, iPhone, AI, C++, GPT-5, UTF-8, HTTP/2, and Windows11, remain valid
• Protects ASCII numeric literals, including signed integers and decimals, separately from Latin / technical tokens and leaves them visible in the Zenz prompt instead of replacing them with placeholders. The exact numeric spelling and non-Japanese boundaries are preserved, while adjacent Japanese text in expressions such as 1日, 100円, スマートフォン1台, 第1回, and 3.14倍 remains eligible for Zenz correction
• Preserves user-visible punctuation style when adopting Zenz live-correction output, so brackets and symbols such as （ ） / ( ), ？ / ?, and ！ / ! stay in the style chosen by the current composition or Mozc live-conversion result
• Suppresses only excess trailing sentence-final or expressive punctuation introduced by contextual Zenz output beyond what is already present at the end of the current composition or normal Mozc live-conversion result, while preserving the rest of the correction
• For Japanese-only user-dictionary surfaces, keeps the natural reading in the Zenz prompt and validates the selected surface boundaries after the response, accepting the result only when any extra kana attachment can be repaired safely
• Sanitizes left context before using it in Zenz prompts, and excludes sensitive-like context such as URLs, email addresses, file paths, tokens, and long digit sequences
• Stores only full-sequence Zenz feedback with non-reversible context classes, never raw left context or segment-local feedback
• Bundles third-party license notices for the Zenz model and llama.cpp runtime in the MSI
• Includes build adjustments for my own Windows / macOS development environments

Examples

Ambiguous romaji display

With the custom option enabled:

• ms -> ます
• mst -> ました

Typing ms shows ます in preedit, and then typing t updates the preedit to ました.

If the input temporarily follows a longer ambiguous rule but the longer rule later fails, Mozc falls back to the last displayed ambiguous result and replays the remaining input.

For example, with rules such as:

• ctn -> ことに
• ctnnr -> ことになる
• ctnnc -> ことなのか

typing ctnnaru is interpreted as ctn + naru, resulting in ことになる, while valid longer rules such as ctnnr and ctnnc still work.

Long custom romaji-table outputs

A custom romaji-table rule can produce output shorter than 1024 UTF-8 bytes. The input and pending fields keep their existing limits below 300 bytes.

Previously, input, output, and pending all shared the same limit below 300 bytes. For typical Japanese characters encoded as three UTF-8 bytes, this limited one rule's output to the equivalent of 99 characters. This fork raises only the output limit, allowing up to 1023 bytes, or the equivalent of 341 three-byte characters.

This is a per-rule romaji-table output limit. It does not change the converter's whole-composition input-length limit.

Live conversion

With live conversion enabled, Mozc automatically converts the current composition without committing it immediately.

To reduce distracting intermediate conversions, this fork applies live conversion after a short configurable debounce delay instead of converting every character immediately. By default, single-character compositions are not live-converted, because they are often particles such as に, を, or が. The minimum number of characters required to start live conversion can be changed from the config dialog.

Live conversion is also suppressed for very short kana compositions followed only by decorative trailing symbols, such as え~, えー, or ん？. This avoids noisy intermediate conversions such as え~ becoming 絵～ while the user is still typing.

To avoid candidate-window flicker from Roman keystrokes that do not yet add a meaningful reading, Mozkey temporarily holds passive-suggestion refresh separately from live conversion. For example, after 今日は, typing s and then sh keeps the same suggestion set; when shi resolves to し, suggestions refresh for the current reading 今日はし. At the start of a fresh composition, an unresolved Roman prefix of up to two characters can still refresh.

Custom romaji rules with the DisplayAmbiguousResult option can display a meaningful Japanese reading even though their Roman suffix is still pending and may be extended by a longer rule. If that displayed ambiguous result changes the prediction query, Mozkey refreshes suggestions instead of holding the previous set. For example, with a → あ, ms → ます, and msn → ません, where ms and msn are also prefixes of longer rules, typing am keeps the prior suggestions, while ams refreshes for あます and amsn refreshes for あません. The same exception applies to msn at the start of a composition even though its pending Roman suffix is longer than two characters. Ordinary unresolved prefixes without a displayed ambiguous reading continue to use the previous HOLD behavior.

While the list is held, Down / Tab focuses the exact displayed candidates without running prediction again. Space keeps the ordinary conversion path. Shift-triggered temporary ASCII input, modified key events, and explicit text input from software/mobile keyboards are excluded from this hold. Live conversion and Zenz processing continue normally while the Roman suffix is pending.

For completed expressive forms, the generated dictionary adds natural kana candidates such as うっそ, くっそ, やっば, すっげぇ, めっちゃ, ちっす, ちょりっす, ほえ～, ほぇ～, and ほっほーん. This avoids pathological kanji segmentation by default while still allowing explicit user selections, user history, and user dictionary entries such as ウッソ, クッソ, ヤッバ, チッス, or ホェ～ to influence future ranking.

This does not disable normal conversion. Pressing Space still invokes ordinary conversion candidates, and completed expressive words remain ordinary converter candidates.

For example:

• Type kyouha
• After the debounce delay, the preedit can be shown as 今日は before pressing Space
• Typing more characters keeps the same uncommitted composition and schedules another live conversion
• Romaji-table ellipsis rules such as v. -> … or v, -> ‥ keep the visible live-converted prefix instead of falling back to raw kana
• When Shift-based ASCII input starts, the visible live conversion result is committed first, and then ASCII input begins
• Pressing Backspace or Delete updates the live conversion result immediately
• Pressing Enter commits the current live conversion result

During live conversion, this fork shows a small ruby-like overlay window above the preedit text so that the original reading remains visible while the converted text is shown.

The live conversion feature can be enabled or disabled from the config dialog. The debounce delay and the minimum number of characters required to start live conversion can also be configured there.

Hyphenless postal-code conversion

When Postal code conversion is enabled, a seven-digit input such as 1000001 can produce the corresponding address candidate (for example, 東京都千代田区千代田) without typing the hyphen in 100-0001. Full-width digit input is normalized for conversion. Mozkey reuses the existing hyphenated postal-code dictionary entries at lookup time instead of duplicating the address data.

With live conversion ON, the numeric literal remains the first candidate for the postal-code segment, while the address remains available as a subsequent candidate. For a standalone 1000001 that has already undergone live conversion, a key assigned to ConvertNext (Space in the standard keymap) advances through the existing candidate list without rebuilding it. If the address is next, it is selected on that keypress; its exact position may vary with other candidates and user history. Postal codes embedded in Japanese sentences can retain their numeric form while surrounding text continues to convert; use the normal segment-navigation keys when needed. With live conversion OFF, the original dictionary/history ranking is preserved rather than forcing the numeric candidate first.

Disabling Postal code conversion disables the hyphenless address alias and its special numeric-first ranking. To avoid interpreting parts of ASCII-alphanumeric identifiers as postal codes, the alias is suppressed in inputs such as ID1000000, 1000000ABC, and 1231000000. This boundary check covers ASCII letters and digits; it is not a general identifier parser for all punctuation or Unicode alphanumeric forms. This ConvertNext behavior describes ordinary Mozc live conversion. The separate Zenz-to-Mozc revert behavior may check for physical Space, so remapping ConvertNext to another key does not guarantee identical behavior while a Zenz correction is visible.

The separate setting to show the candidate window on the first conversion normally applies when live conversion is OFF. Standalone postal codes are an exception: when live conversion and postal code conversion are ON, an explicit first conversion can open the candidate window independently of that setting.

Zenz live correction

When both live conversion and Zenz live correction are enabled, this fork normally shows the Mozc live-conversion result and asynchronously asks a local Zenz runtime to refine the visible preedit.

When the config option Do not show the normal live-conversion result until Zenz correction returns is enabled, inputs that are eligible for Zenz do not show a newly computed Mozc live-conversion result while the Zenz request is pending. If a stable Zenz-corrected prefix is already visible, Mozkey preserves that presentation when possible and appends unresolved raw-romaji suffixes to it. Mozc resegmentation alone does not cause a previously stable Zenz presentation to be split or rolled back. If Zenz fails, times out, is rejected by validation, or produces the same value as Mozc and is therefore not adopted, Mozkey falls back to the current normal Mozc live-conversion result.

Deferred presentation has a separate configurable wait limit measured from the moment the Zenz correction request is actually submitted. The default is 250 ms. If the result is still unavailable at that deadline, Mozkey abandons that generation and reveals the normal Mozc live-conversion result that was already computed as the Zenz baseline. A late result from that generation is not adopted. The debounce interval before the Zenz request is submitted is not counted toward this 250 ms budget.

On Windows, the Zenz request is sent from mozc_server to mozc_zenz_scorer.exe through a Windows named pipe. The scorer then calls the bundled llama-server.exe on a localhost endpoint for local inference. The localhost transport is hardened so that it does not rely on a fixed endpoint, and internal requests include protection against accidental or stale local endpoint mismatches.

The Windows Zenz named-pipe transport uses finite deadlines for connection and request/response I/O, and explicitly interrupts pending I/O during shutdown. A stalled scorer or peer therefore cannot leave the Zenz worker or scorer waiting indefinitely, and the scorer can recover to serve subsequent requests. The macOS Unix-domain socket path likewise wakes pending poll operations during shutdown.

On Windows, the scorer uses FILE_FLAG_FIRST_PIPE_INSTANCE to refuse pipe creation if an instance already exists under the same name, and PIPE_REJECT_REMOTE_CLIENTS to reject remote clients. Its pipe ACL is limited to SYSTEM and the current user. Before sending the request header or input prompt, the client obtains the server PID from the connected pipe handle and checks the Windows session, user SID, and executable image path against the expected mozc_zenz_scorer.exe beside the Mozkey executable. If these checks fail, it sends no prompt and does not adopt a Zenz correction. A stopped scorer can be relaunched on a subsequent correction request.

This defense relies on OS-reported process identity and a protected install directory where ordinary users cannot replace the executable. It is not complete authentication against arbitrary code execution as the same user or an administrator compromise. Normal conversion, scorer restart, and rejection of a separate-process fake server have been tested on Windows x64; this change has not yet been validated on Windows ARM64 hardware.

Surrounding context for Zenz uses dedicated fields separate from the normal Mozc generic context. The Server reports the required preceding / following lengths to the client; Windows TSF and macOS IMK then acquire only the requested directions and lengths and attach them as zenz_preceding_text / zenz_following_text. The normal Mozc surrounding-text semantics are left unchanged.

Zenz correction is delayed by a configurable debounce interval. The default delay is 700 ms for new or otherwise unset profiles. Previously saved delay values remain unchanged. The minimum number of characters required to start Zenz correction can also be configured. If the current composition changes before the Zenz result arrives, the old result is discarded by generation/key checks.

While a deferred presentation is waiting for Zenz, pressing Space first reveals the current normal Mozc conversion result without advancing to the next candidate. Enter commits exactly the presentation that is visible at that moment, and Undo restores that same presentation as preedit. Shift-based ASCII input likewise commits the visible presentation before starting ASCII input. Backspace immediately reflects the post-deletion Mozc result; that Backspace does not itself start a fresh Zenz correction, and normal deferred Zenz scheduling resumes with subsequent real text input.

Zenz output is validated before display. Outputs that are empty, too short, identical to the Mozc result, too long, malformed, or likely to contain unsafe text are rejected. Mozkey also rejects likely context echo in which the output starts by repeating an unusually long suffix of already committed left context relative to the current reading/Mozc result. Short overlaps are not rejected unconditionally, and legitimate repetition supported by the current reading is still allowed. If validation fails, Mozkey falls back to the current normal Mozc live-conversion result.

Obvious Zenz omission guards and strict reading preservation (experimental)

In the default configuration, lightweight checks reject a final Zenz candidate when it is an obvious leading or trailing truncation of the normal Mozc conversion result. This applies to both fresh Zenz responses and candidates reused from saved feedback. When a surface prefix overlaps with already committed left context and it is unclear whether it belongs to the new input, Mozkey does not blindly strip that prefix; it falls back to the complete normal Mozc result instead.

These checks reduce obvious surface omissions; they do not guarantee preservation of the user's entire typed reading. The default path does not perform extra reverse conversion for this protection.

The optional Strict Reading Preservation (Experimental) setting reverse- converts the final adopted Zenz candidate and checks whether its reading matches the complete typed reading or a normalized form of that reading. When the reading differs or cannot be obtained, Mozkey falls back to its normal conversion result. This setting is OFF by default; explicitly saved ON preferences are preserved.

Strict mode is intentionally conservative. Alternate kanji readings or reverse- conversion limitations can reject otherwise valid candidates. Normal-candidate reranking or insertion based on saved feedback that cannot be verified is also restricted, and the additional reverse conversion may increase latency. Leave strict mode OFF to retain the usual Zenz correction and feedback behavior.

User-dictionary candidates and ASCII / mixed-script surfaces that appear in the current normal Mozc live-conversion result are protected before Zenz output is adopted. For ASCII / mixed-script surfaces, when the protected reading can be identified safely, such as in もずきー -> Mozkey, the reading is temporarily replaced with a placeholder in the Zenz prompt and restored to the selected surface after the response. This prevents Zenz from silently overwriting the protected word as モズキー while still allowing correction of the surrounding sentence.

The surface selected by normal Mozc is also treated as an orthographic baseline for Zenz adoption. If Zenz alone introduces a Latin spelling such as 東京 -> Tokyo or コンピュータ -> computer, or removes or mutates a Latin / technical token already selected by Mozc, Mozkey restores only the affected segment when the result can be projected safely back onto the Mozc segment boundaries, preserving unrelated Zenz corrections. If safe projection is not possible, or if the saved baseline segments are missing or inconsistent, a Zenz result containing an unsafe orthographic transition is not adopted. Latin / technical tokens already selected by normal Mozc, including GitHub, iPhone, AI, C++, GPT-5, UTF-8, HTTP/2, and Windows11, remain valid baseline surfaces.

ASCII numeric literals are handled separately from these Latin / technical identities. Numeric spellings, including signed integers and decimals, remain visible in the Zenz prompt instead of being replaced with placeholders, and the adopted output must preserve the same spelling and occurrence count. For each numeric occurrence, when the normal Mozc baseline has an adjacent Japanese character, the Zenz output may replace it with another Japanese character. A non-Japanese adjacent character must remain exactly the same, and a string boundary must remain a boundary. This allows corrections such as 1代 -> 1台 and surrounding-context corrections while rejecting changes such as 100円 -> 100¥, 100% -> 100$, 2026/09/23 -> 2026-09-23, and HTTP/2 -> HTTP 2.

Zenz output may also normalize visible punctuation style. Before adoption, Mozkey restores the symbol style from the current composition or normal Mozc live-conversion result. This is preservation rather than fullwidth normalization: （test） stays fullwidth when that was the source style, while (test) stays ASCII. ASCII-token-like contexts such as code-like words, paths, and URLs are handled conservatively to avoid unwanted widening.

Zenz can also carry sentence-final or expressive punctuation forward from surrounding context even when the current composition did not request it. Before adoption, Mozkey limits trailing symbols such as ！ / !, ？ / ?, 。, …, and 〜 to the count already present at the end of the current composition or normal Mozc live-conversion result. Only the excess trailing symbols are removed, so semantic and orthographic corrections are preserved; punctuation inside the candidate is not modified by this repair.

Japanese-only user-dictionary surfaces keep their natural reading in the Zenz prompt. After the Zenz response, Mozkey validates the selected surface boundaries. If extra kana is attached immediately after the protected surface, the result is accepted only when the attachment can be repaired safely; otherwise the normal Mozc live-conversion result remains visible.

If a Zenz response drops or changes a protected surface and placeholder restoration or safe repair cannot preserve the required number of occurrences, the response is rejected and the normal Mozc live conversion result remains visible. This does not pin every candidate that merely exists in the user dictionary. Protection is based on surfaces that actually appear in the current normal live-conversion result.

Zenz live correction is disabled for password fields and for composition text that has no Japanese-script signal, such as intermediate raw romaji input. Japanese text mixed with ASCII can still be eligible when it passes the privacy gate.

For Windows TSF password input scopes and macOS Secure Event Input, application surrounding text is not acquired for Zenz and extended Zenz context acquisition is skipped.

Independent Zenz learning controls

The configuration dialog separates Zenz learning (Mozc conversion history) from Zenz learning (correction feedback):

These three preferences are independent. A=OFF/B=ON continues to use existing feedback without adding new observations, while A=OFF/C=ON can still learn into Mozc history. For new Mozkey configurations all three default to ON. Previously saved legacy preferences are inherited only for fields not explicitly saved under the new settings.

With A enabled, a displayed Zenz result is not recorded simply because it was shown. Accepted full-sequence feedback is appended when the user explicitly commits the result (for example with Enter or direct-commit punctuation). C writes to Mozc history separately.

Minimum reading length for automatic Zenz feedback reuse

Short Japanese readings often have many homophones, and the appropriate spelling can depend heavily on context. Reusing a small number of feedback observations as a strong general preference could over-promote or suppress a candidate in unrelated contexts. This gate continues recording feedback while limiting its automatic influence on short readings. The seven-character default is a configurable precaution, not a claim that length alone resolves ambiguity.

For new or otherwise unset configurations, automatic reuse of stored Zenz feedback is enabled only for full-sequence readings of 7 or more Unicode code points. This counts characters in the full reading, not UTF-8 bytes or Roman keystrokes. The setting is enabled by default and can be disabled or adjusted from 1 to 20 characters in the config dialog. For example, あしたはあめ (6) is excluded and おねがいします (7) is eligible.

Shorter readings still undergo fresh Zenz inference, and their accepted and rejected observations are still recorded. However, stored feedback for those readings is not used to adjust normal candidate ranking, immediately replay a previous correction, or automatically block a fresh Zenz result. Explicit manual hard rejects remain effective regardless of reading length. Records are not removed: disabling the gate or lowering the threshold makes previously recorded feedback eligible for reuse again.

This is separate from the minimum length required to initiate fresh Zenz correction. It does not disable ordinary Mozc conversion or Mozc user-history learning, including the separate history-learning path for committed Zenz results.

Secret / Incognito mode is an exception: local Zenz inference remains active, but Zenz feedback personalization stops both reading and writing. Stored feedback is not applied to candidate ranking, the multi-segment live-correction fast path, or feedback decisions including auto-blocking, and no new feedback record is persisted. Leaving Incognito mode makes the existing, unmodified feedback available again.

After that explicit commit, the session keeps a short rollback window for the accepted observation. If Backspace, Escape, Revert, Undo, Ctrl+Z, or a similar correction action occurs before the next real text input or post-commit context transition closes the window, Mozkey appends accepted_rollback only if the preceding acceptance was successfully persisted. If the accepted append failed, Undo will not add a compensation row that could subtract from earlier valid observations. The rollback is not rejected feedback, so it does not increase ordinary-reject or auto-block negative evidence. IMEOff / MakeSureIMEOff are treated as confirmation rather than cancellation and close the rollback window while keeping the acceptance. Moving from a visible Zenz correction to normal conversion operations, such as Space or candidate movement, is separate and starts a pending final comparison instead of immediately persisting rejected feedback. If the final committed value differs from the Zenz correction, Mozkey records an ordinary rejection; if it matches the Zenz correction, Mozkey records an accepted observation instead. If no final commit is observed, the pending comparison is neutralized. Ordinary rejected feedback from these operations remains a negative ranking signal rather than a hard command to permanently suppress the candidate.

Zenz feedback auto-blocking uses both an ordinary-reject count and a reject ratio. For the same full-sequence feedback entry, an auto-block is active only when ordinary rejects >= minimum reject count and ordinary rejects / (accepted + ordinary rejects) >= minimum reject percentage are both true. The defaults are 1 rejection and 50%. The comparison is inclusive, so accepted=1 / rejected=1 is blocked at exactly 50%. Explicit hard rejects are handled separately as absolute blocks and are not part of this ratio decision.

While an entry is ordinarily auto-blocked, Mozkey still lets Zenz produce the candidate internally but keeps it hidden as a shadow observation. If the final commit for the same reading matches the hidden Zenz value, one accepted feedback observation is added. This hidden match is used only for Zenz feedback recovery and does not add another Mozc user-history learning event. Once matching observations lower the reject percentage below the threshold, for example to accepted=2 / rejected=1 (33%), the auto-block clears automatically. If the same reading is committed as a different value, one ordinary rejection is added. If continued typing changes the final reading, the shadow observation is neutral and does not update feedback. Explicit hard rejects do not create shadow observations and therefore do not self-recover.

The feedback TSV is scoped to full Zenz sequences: a complete reading key, a complete correction value, and a coarse non-reversible context class. It does not store segment-local or lexical-unit feedback. With C enabled and privacy/history conditions satisfied, accepted Zenz corrections can also be learned into Mozc user history independently of A, with generalized learning applied at the explicit commit point. This is a separate Mozc-history path rather than an additional Zenz feedback-store record. Mozkey keeps an in-process revert handle for the short rollback window; Backspace, Escape, Revert, Undo, and similar immediate corrections revert the just-applied generalized learning, while the next real text input or a post-commit transition such as ResetContext / IMEOff keeps it. The exact TSV accepted / accepted_rollback compensation and generalized Mozc-history revert are separate mechanisms. This rollback window is an in-process convenience rather than a durable transaction or ACID rollback across a crash or process termination. For local learning, Mozkey first prefers the known segment boundaries from the preceding normal Mozc live conversion and checks whether a history-free fixed-boundary conversion can reproduce the accepted surface exactly. Only ranges that cannot be explained by those boundaries are passed to Mozc-native resegmentation and forward verification. An inferred boundary/reading path is used for local learning only when it is uniquely verified. If multiple boundary interpretations remain, or an aggregate cannot be resolved safely, Mozkey keeps that range as a non-learnable barrier rather than inventing a local split; safe lexical islands on either side can still be learned independently. Punctuation and other non-learnable separators also split lexical islands, so learned boundaries do not cross them. Strong selection history is attached only to lexical units whose final key/value mapping still carries verified evidence of an actual Zenz change. When at least one safe structured/local commit succeeds, Mozkey does not additionally teach the same accepted result as a whole-sequence Mozc-history entry. When no safe projected/local evidence can be committed at all, Mozkey may still try the exact accepted result through the separate full-sequence Mozc-history fallback without inventing ambiguous local boundaries. The Zenz feedback store keeps its accepted full-sequence record independently of this local-boundary decision. Privacy and password gates still exclude the input from this Mozc-history learning path.

Space is treated specifically as a candidate-change operation, not as a plain cancel back into the live-conversion composition. If deferred presentation is still waiting for Zenz, the first Space reveals the current normal Mozc conversion result without advancing to the next candidate. When Space is pressed while a Zenz correction is already visible, Mozkey restores the underlying Mozc conversion as an ordinary conversion result without opening the candidate window yet and keeps the Zenz feedback as a pending final comparison. If the user then types more text, the restored Mozc conversion is committed first and the new text starts a fresh composition.

If the next action is a direct-commit punctuation/symbol, Mozkey first captures the restored Mozc result as the suffix-free final comparison value and keeps the short rollback window open through that punctuation/symbol commit. An immediate Backspace, Escape, Revert, Undo, Ctrl+Z, or equivalent cancellation discards the pending Zenz comparison instead of leaving a rejection behind. A subsequent normal text input, post-commit context transition, or ordinary pass-through key such as the second Enter used to submit Windows Search closes the rollback window and confirms the feedback from the observed final commit. Pressing Space again instead follows the ordinary conversion path and opens the candidate window for the next candidate.

Zenz feedback is reused differently for single-segment and multi-segment conversions.

For single-segment normal conversion, Zenz feedback is reused as ranked candidate augmentation inside the rewriter chain. Stored feedback is scored from accepted counts and rejected reasons. If the feedback value already exists in the candidate list, its cost is adjusted by that score. If it does not exist, a synthetic candidate can be inserted at a natural feedback-adjusted cost position instead of being forced to the top. Ordinary rejected feedback lowers the candidate's ranking without deleting it; only explicit hard-reject reasons act as strong suppression. ZenzFeedbackCandidateRewriter runs before UserSegmentHistoryRewriter, so explicit user selection history can still make the final ranking decision.

For multi-segment live conversion, the rewriter-chain feedback ranking does not rewrite normal conversion candidates, because phrase boundaries are owned by the converter and should not be collapsed. Instead, accepted feedback can still be replayed via the session-level live-correction fast path. This preserves learned full-phrase corrections such as かれはてんてきです -> 彼は天敵です.

Feedback learned in a sensitive_like context is not reused for ordinary-context candidate ranking.

Zenz correction-feedback data can be managed from the config dialog. The management dialog shows feedback entries in a read-only table and supports search, import, export, single-entry deletion, and full deletion. Removing feedback entries does not remove any separately learned Mozc conversion-history entries. This avoids requiring users to edit the TSV file directly. The feedback applicability column identifies shorter readings as 対象外（記録のみ） (record only) and explicit manual hard blocks as 手動ブロック有効 (manual block active).

The management dialog can also explicitly block a selected Zenz correction. Already blocked corrections cannot be blocked again. To unblock a correction, delete the corresponding feedback entry and relearn it if needed.

Zenzai v3/v3.2 condition fields

Zenz live correction can pass additional condition fields using the special-token format expected by Zenzai v3/v3.2. These fields are not ChatGPT-style system prompts; they are short hints mapped to the conditional input format used by the Zenzai model.

• profile: passed as U+EE03 profile for a short description of the writer or use case.
• topic: passed as U+EE04 topic. This field is experimental.
• style: passed as U+EE05 style. This field is experimental.
• settings: passed as U+EE06 settings. This field is experimental.
• Right context: when dedicated Zenz text on the right side of the caret is available, it is passed as U+EE07 right context for Zenzai v3.2. The acquisition length is configurable and defaults to 6 characters.

Empty profile, topic, style, and settings fields are omitted from the prompt. Right context is not a fixed user-entered phrase. On Windows TSF / macOS IMK, the Server requests the required amount and the client automatically acquires text on the right side of the caret and supplies it as zenz_following_text.

Context-aware conversion after committed text

This fork uses committed text immediately before the current composition as left context when possible.

For example, after committing main, typing にまーじしました is more likely to produce:

• mainにマージしました

instead of unnatural homophone results such as:

• main二マージしました

The left context is ignored after hard boundaries such as spaces, newlines, punctuation, or brackets.

Internally, this fork reconstructs noun-like preceding text as a history segment and reranks short particle candidates such as に, を, が, へ, and で against homophone kanji, numeric, symbol, or dakuten-kana candidates.

It also reranks conservative compound functional-particle expressions such as には, にも, では, でも, and とは after noun-like left context. For example, after committing github, typing には is biased toward githubには instead of github二は.

It also protects functional-prefix and whole functional-chain paths immediately after noun-like committed context. For example, after committing 彼, typing になった or なのか is biased toward 彼になった / 彼なのか instead of content-node hijacks such as 彼担った / 彼七日. Conditional chains such as なら, ならば, and ならでは are also protected, so after committing 練習, typing なら is biased toward 練習なら instead of 練習奈良.

It also protects common functional expressions such as しか followed by a negative expression after a noun or quantity-like context. For example, 2めいしかいない is biased toward 2名しかいない instead of intermediate homophone paths such as 2名司会..., 2名視界..., or 2名士会内.

It also protects some context-sensitive noun and suffix constructions. For example, 追記したい is biased away from homophone noun candidates such as 追記死体. After a committed sahen noun, した, したの, and したん are also biased away from content-word hijacks such as 下, 舌, or シタン. 山梨県立美術館 is biased away from broken suffix paths such as 山梨県率美術館, and place-suffix phrases such as 滋賀方面 or 佐賀空港 are biased away from short content + が splits such as 子が方面.

Direct commit for punctuations/symbols

With the direct-commit option enabled, configured punctuations/symbols are committed immediately.

Examples:

• tesuto. → てすと。
• tesuto? → てすと？
• kakko( → かっこ（
• tesuto/ → てすと・ when the symbol style maps / to the middle dot

The selectable targets include periods, commas, question marks, exclamation marks, parentheses, corner brackets, and the middle dot. 「 and 」 are configured independently. The middle dot ・ is handled as an independent Japanese separator symbol.

You can choose which punctuations/symbols are committed directly in the config dialog.

However, period- and comma-like punctuation immediately following a number is excluded from direct commit so that numeric input can continue normally. This allows values such as 3.14 and 1,000 to be entered without being committed at the punctuation, while ordinary punctuation direct commit in Japanese text continues to work as before.

When live conversion is enabled, direct-commit punctuations/symbols commit the currently displayed live conversion result instead of committing the raw kana composition.

For direct-commit punctuations/symbols, learning caused by the immediately committed conversion is also kept pending until the next real text input. If the next action is Backspace, Escape, Revert, Reset, or Undo, the pending learning is reverted instead of being kept. IMEOff / MakeSureIMEOff are treated as post-commit mode changes rather than cancellation, so the pending learning is confirmed.

When a cancel-equivalent key such as Ctrl+Z is pressed immediately after a direct-commit punctuation/symbol and that key is echoed back to the application, Mozkey also discards the pending learning. Whether the already-committed text is actually undone depends on the application's own Undo behavior.

Hiragana learning after conversion cancel

When an active conversion is canceled with Esc, Ctrl+Z, or another key bound to Cancel, the preedit returns to raw hiragana. If the user immediately commits that restored hiragana preedit with Enter, Commit → IMEOff, IMEOff / MakeSureIMEOff, or a direct-commit punctuation/symbol, this fork treats the hiragana spelling as an explicitly selected candidate.

For example, if きょう is converted to 今日, then canceled back to きょう with Esc and committed with Enter or Commit → IMEOff, committed by IMEOff while returning to direct input, or committed as きょう。 by direct-commit punctuation, the hiragana body きょう is learned in user segment history similarly to F6 -> Enter. This makes the hiragana candidate more likely to be promoted for the same reading later.

For multi-segment conversions, this fork preserves the conversion-time segment boundaries when possible. For example, if おつかれぺん had been converted as お疲れ | ペン, then canceled back to おつかれぺん and committed unchanged, the learning is recorded as segment-level hiragana preferences such as おつかれ -> おつかれ and ぺん -> ぺん, rather than as a single whole restored preedit.

This strong-learning path is intentionally narrow. It applies only when the preedit is unchanged after Cancel and is committed immediately with Enter, Commit → IMEOff, IMEOff / MakeSureIMEOff, or a direct-commit punctuation/symbol. For direct-commit punctuation/symbols, only the restored hiragana body is learned as the spelling preference; the punctuation/symbol suffix is not included in that user-segment history entry. The committed hiragana body must be at least two hiragana characters, the reading and committed value must be identical, and the input must not be from a password field. Plain raw preedit commits, commits after editing the canceled preedit, one-character hiragana commits, non-hiragana commits, and password fields are excluded.

With live conversion enabled, the same behavior applies when the user explicitly cancels back to hiragana and immediately commits it with Enter, Commit → IMEOff, IMEOff / MakeSureIMEOff, or a direct-commit punctuation/symbol. Internal live-conversion cancellation used only for continuing input does not trigger this strong-learning path.

Partial revert of history learning after immediate correction

When a committed conversion is immediately followed by Backspace, or by a key assigned to Cancel in the current keymap, this fork treats it as a revert signal for the just-committed learning result.

For direct-commit punctuations/symbols, the committed text may already have been sent to the application without using Mozkey's normal Undo context. In that case, a cancel-equivalent key such as Ctrl+Z still discards Mozkey's pending learning, while the key itself is passed through to the application. Whether the visible text is actually undone depends on the application's own Undo behavior.

If the entire committed text is erased, the just-committed suggestion history and user segment history do not continue to affect later suggestions or conversions.

If only the tail of the committed text is erased with Backspace, the history for the remaining part is kept while the erased tail is reverted.

For example:

• Commit いしとは as 医師とは
• Press Backspace twice and erase only とは
• The remaining 医師 history is kept
• The tail-specific learning for 医師とは is reverted

This makes immediate correction after conversion confirmation behave closer to user intent.

Learning complete readings and segment preferences from accepted suggestions

When a user explicitly selects and commits a suggestion whose reading extends beyond the typed prefix, Mozkey can use the suggestion's complete reading and the segments verified against ordinary conversion to learn spelling preferences in Mozc's user-segment history.

For example, selecting 私の名前 (complete reading わたしのなまえ) from a suggestion shown after typing only わたし can teach the verified individual segments to ordinary conversion. The system does not mistake the shorter typed prefix for the reading of the entire accepted phrase.

If the suggestion provides segment boundaries, Mozkey checks them; otherwise, it may establish correspondence through normal conversion or strictly verified reverse-reading resolution. Strong selection-history markers use the candidate ordering after normal-conversion postprocessing, not the raw dictionary order. If the candidate surface, reading, segment boundaries, or displayed ranking cannot be established reliably, the extra segment-level learning is skipped rather than guessed.

The normal committed text and existing suggestion-history learning are preserved, and other commit handlers are not run a second time. Pending cleanup from a preceding Undo is resolved before examining displayed candidate ranks or writing a new preference, so an earlier deferred Undo cannot remove a newly recommitted preference.

This additional learning obeys the existing history and privacy gates, including Incognito, password fields, and private input. It applies to supported desktop suggestion commits, not indiscriminately to mobile mixed conversion or zero-query suggestions. It is distinct from Zenz correction-feedback learning and reuse.

This learning path has been built, regression-tested, and exercised on Windows. The macOS runtime behavior of this change has not yet been verified.

Multiple commands per key binding

The keymap editor can assign multiple commands to one key binding as an ordered command sequence.

Examples:

• Composition + Ctrl Enter -> Commit → IMEOff
• Composition + Ctrl Space -> Convert → ConvertNext
• Conversion + Ctrl Enter -> Commit → IMEOff

Commands are executed from left to right. If the input state changes during the sequence, the following command is resolved against the current state at that point. For example, Convert → ConvertNext first enters conversion from composition and then moves to the next candidate.

In exported keymap files, command sequences are stored with |, such as Commit|IMEOff or Convert|ConvertNext. In the keymap editor UI, they are displayed with arrows, such as Commit → IMEOff.

Manual Zenz correction and delayed keymap sequences

The keymap editor provides ForceZenzLiveCorrection (normal manual correction), ForceZenzLiveCorrectionWithoutFeedback (manual correction that bypasses automatic reuse of stored Zenz feedback for this invocation), and Delay(ms) (a pause before subsequent commands).

• Normal manual Zenz correction asynchronously refines uncommitted text in Composition or Conversion using the current Mozc conversion as its baseline. Stored Zenz feedback is applied according to the usual settings.
• Manual correction without feedback reuse bypasses stored Zenz feedback for normal-candidate ranking, immediate correction reuse, and statistical auto-blocking on this invocation. When invoked from Conversion, it recomputes a feedback-free Mozc baseline. Normal Mozc user history and user-dictionary entries remain available, and explicit user-defined manual hard rejects still apply. "Ignore feedback learning" refers to previously stored feedback being consulted: new accepted-feedback recording (A) and Mozc-history learning (C) still follow their independent settings when the result is committed.
• Both manual commands work even when automatic Zenz live correction is OFF and bypass the automatic minimum-reading-length threshold. Password/privacy and input eligibility checks remain in effect, and the result is not guaranteed to be adopted. If feedback-bypass reconversion fails, the prior candidates, input mode, and learning rollback ownership are preserved.
• Delay: Delay(700) resumes the remaining steps after 700 ms. Values from 0 through 5000 milliseconds are supported; Delay(0) does not wait. This delay is separate from the automatic live-conversion and Zenz debounce settings.

Practical custom bindings (examples, not the defaults):

Precomposition + Space -> ReconvertSelectionOrInsertSpace|Delay(700)|ForceZenzLiveCorrection
Composition + Shift Space -> ForceZenzLiveCorrection
Conversion + Shift Space -> ForceZenzLiveCorrection
Composition + Ctrl Shift Space -> ForceZenzLiveCorrectionWithoutFeedback
Conversion + Ctrl Shift Space -> ForceZenzLiveCorrectionWithoutFeedback

The first binding is Windows TSF-specific: with selected committed text, Space requests reconversion, waits 700 ms, then requests manual Zenz correction; without a selection, it keeps the usual space-insertion fallback. The application must support reconversion. Lines 2–3 use Shift+Space for normal manual correction; lines 4–5 use Ctrl+Shift+Space to bypass automatic feedback reuse. Configure separate rows for Composition and Conversion.

Constraints and interruption behavior:

• Delay cannot be the first step. In the editor, double-click a Delay step to change its milliseconds; double-clicking a regular step keeps the existing remove behavior.
• Both ForceZenzLiveCorrection and ForceZenzLiveCorrectionWithoutFeedback must be the last step; ForceZenzLiveCorrectionWithoutFeedback|Delay(700)|Commit is invalid. This prevents subsequent commands from replacing an asynchronous Zenz callback.
• If Space or Shift+Space already has a command in the same input state, replace that binding rather than adding a duplicate row. In particular, Shift+Space may replace an existing alternate-space action, and OS/application shortcuts can intercept keys before Mozkey receives them.
• A different key action, mouse candidate selection, or input-context change while waiting invalidates the pending continuation so that an old delayed command does not act on the new input.
• Space can still switch a visible Zenz correction back to ordinary Mozc conversion. A separately bound manual Zenz action can request another correction from conversion state. The ZenzConversion keymap state now allows Zenz-specific bindings.

Note: Selected-text reconversion (ReconvertSelectionOrInsertSpace) is Windows-only. Manual Zenz correction combined with delayed key sequences is not guaranteed to work on macOS or Linux.

Key bindings during live conversion and Zenz correction

The keymap editor includes Live converting (LiveConversion) and Zenz correction (ZenzConversion). The first applies while Mozc live conversion is active; the second applies while a Zenz correction is displayed.

With the built-in keymaps, Backspace behaves as follows:

With the built-in keymaps, Space during Zenz correction restores the underlying Mozc result without committing the Zenz result. If the correction originated from live conversion, you can continue editing the reading with live conversion. Manual Zenz correction originating from ordinary conversion returns to ordinary conversion.

ZenzConversion + Space -> RevertZenzToMozc

Return to ordinary Mozc conversion (RevertZenzToMozc) can also be assigned to another key. Configure it as a single command, not as part of a command sequence. Explicit bindings in CUSTOM keymaps take precedence.

Delete candidate history / hide candidate

While conversion or prediction candidates are visible, DeleteSelectedCandidate removes the selected candidate from learned history when possible, or hides it from the candidate list. The standard keymaps bind this action to Ctrl+Delete in Prediction and Conversion states.

The action first attempts to delete the selected candidate from user history. When that succeeds, the operation stops there and no suppression entry is created. Only when history deletion does not apply and the candidate is otherwise suppressible does Mozkey store the exact reading/value pair as a SUPPRESSION_WORD in the 非表示候補 user dictionary.

As a result, when the same candidate is available from both learned history and the system dictionary, the first action can remove only the learned-history contribution while the system-dictionary candidate remains. Invoking the action again can then add the suppression entry and hide the remaining candidate.

User-dictionary candidates can also be hidden, but hiding never deletes the original user-dictionary entry itself. Removing the corresponding suppression entry from 非表示候補 in the user dictionary tool makes the original candidate visible again. Mozkey does not add suppression when doing so would remove the only regular candidate, or for command/meta/invalid candidates that are not valid hide targets.

The candidate footer keeps the candidate index visible while omitting the legacy logo area, and derives its action text from the active key binding for the current candidate category. With the standard Ctrl Delete binding it shows Ctrl+Delで履歴削除 for a history-deletable candidate or Ctrl+Delで候補非表示 for a suppressible candidate. Custom bindings are reflected using compact key names: for example, Alt Delete becomes Alt+Delで候補非表示, while a Prediction binding of Ctrl Backspace becomes Ctrl+Bkspで履歴削除. If DeleteSelectedCandidate has no applicable binding for the current candidate category, the action label is omitted.

CUSTOM keymaps preserve existing user assignments. Mozkey does not inject Ctrl Delete when Conversion already has DeleteSelectedCandidate on another key or when Conversion + Ctrl Delete is occupied by another command. Otherwise, when a non-empty CUSTOM table is active, Mozkey adds Conversion + Ctrl Delete -> DeleteSelectedCandidate as a real persisted custom-keymap row.

The config dialog also explains below the personalization-history clear button that hidden candidates are stored as suppression words in the 非表示候補 user dictionary and can be restored by deleting the corresponding entry.

Emoticon top-candidate suppression

In ordinary conversion, candidates that Mozc can semantically identify as emoticons are prevented from being promoted to the first candidate by user-selection history. This applies to the built-in emoticon candidates and to user-dictionary entries registered with the 顔文字 POS. The candidates are not removed: they remain available below the first position and can still be selected normally.

The restriction is based on semantic provenance carried by the candidate, not on whether the surface string merely looks like an emoticon. Therefore, the same surface such as (^_^) can remain eligible for ordinary ranking and learning when it is explicitly registered in the user dictionary under a non-emoticon POS such as a symbol.

Independently generated Zenz candidates are not added to this restriction merely by inspecting their surface strings. Existing semantic information carried by Mozc candidates is preserved, while Zenz-specific generated output is not classified with an emoticon-shaped string heuristic.

Emoji top-candidate suppression

Emoji candidates produced by the built-in EmojiRewriter carry NO_TOP ranking constraints. If an emoji reaches rank 0 during ordinary conversion, an unconstrained candidate is preferred at the final ranking step. The emoji remains available further down the candidate list.

Newly committed emoji candidates preserve this constraint in user history. Older history records are recovered when their descriptions retain the semantic 絵文字 label emitted by EmojiRewriter. An explicit non-emoticon user-dictionary entry (for example, a symbol) with the same reading and surface still permits normal top ranking. Emoji-shaped Unicode strings and independently generated Zenz surfaces are not automatically constrained by character-shape heuristics.

Space reconversion for selected text (Windows / MS-IME style keymap)

In the Windows MS-IME style keymap, pressing Space while committed application text is selected reconverts that selected text. When no text is selected, the same key keeps the normal behavior and inserts a space.

In the keymap editor, this command is shown as Reconvert selected text, or insert space if no text is selected. It does not unconditionally intercept the Space key; it is enabled only when the MS-IME style keymap assigns this command to Space in the precomposition state. If the user has customized the Space key binding, that custom keymap takes precedence.

Users with an existing custom keymap can enable this behavior by selecting the MS-IME style keymap again or by manually assigning Reconvert selected text, or insert space if no text is selected to Space in the precomposition state.

Independent left/right Shift and Ctrl key bindings (Windows)

On Windows, you can assign different IME actions to left/right Shift and Ctrl keys. For example, right Shift can turn the IME on and left Shift can turn it off.

Examples:

• DirectInput + RightShift -> IMEOn
• Precomposition + LeftShift -> IMEOff
• Composition + LeftShift -> IMEOff
• Conversion + LeftShift -> IMEOff
• DirectInput + RightCtrl -> IMEOn
• Precomposition + LeftCtrl -> IMEOff

The keybinding editor also lets you select Ctrl and Shift sides independently. After capturing a key combination, choose Either side, Left only, or Right only for each modifier present in that binding. A selector is disabled if the binding does not contain that modifier.

Either side uses the original generic Ctrl / Shift semantics. Existing bindings such as Ctrl j continue to work with either Ctrl key. When available, the physically captured left/right modifier becomes the initial side selection.

Generic and side-specific bindings are both supported, but overlapping assignments in the same input state cannot be saved with different commands. For example, Ctrl Delete and LeftCtrl Delete cannot be mapped to different commands in the same state because a physical left-Ctrl-plus-Delete input would match both.

CapsLock-aware matching preserves the side-specific and generic shortcut fallback behavior. Dedicated Windows VK_IME_ON / VK_IME_OFF keys do not treat the CapsLock toggle alone as a held shortcut modifier.

Simultaneous left-and-right modifier presses, particularly TSF key-up timing for modifier-only chords, do not have fully guaranteed release semantics. An imported binding explicitly requiring both sides of one modifier family is preserved, but its corresponding three-choice side selector is disabled because it cannot represent that condition.

When a key is explicitly assigned to IMEOn or IMEOff, the mode indicator is also shown even if Mozc is already in the requested state. For example, pressing an IMEOff key while IME is already off still shows the direct-input indicator.

This lets you use an IME on/off key not only to change the input mode, but also to visually confirm the current mode.

Return to hiragana from temporary ASCII input with IME ON (Windows)

When temporary half-width ASCII input is active (for example, after a Shift-triggered mode switch), pressing a key mapped to IMEOn changes the input mode to hiragana without committing the current preedit. The Windows taskbar mode indicator updates to hiragana (あ).

With Shift-based temporary ASCII input enabled, typing Shift+G → o → o → IMEOn → a keeps Gooあ in the same uncommitted composition. The return mode is hiragana even if the temporary ASCII input was entered from katakana.

This applies only while the current mode is half-width ASCII and the stored comeback mode differs from it. Pressing IMEOn in ordinary hiragana input or in explicit half-width ASCII input whose comeback mode is also half-width ASCII keeps the previous behavior. IMEOff still switches to direct input as before.

Windows default IME setting

On Windows, the config dialog can explicitly set Mozkey as the Windows default IME.

This operation is not performed automatically at login. It is executed only when the user presses the setting button.

Before changing the setting, Mozkey saves the previous Windows default input method override and the Japanese input method order. The restore button restores those saved values.

If Mozkey is already the default IME, or if an active restore point already exists, Mozkey does not overwrite the previous restore point.

Windows IME icon setting

On Windows, the config dialog can switch the Mozkey IME icon.

The available styles are:

• Default
• Monochrome (Light/Dark)
• Monochrome (Black)
• Monochrome (White)

Monochrome (Light/Dark) preserves the shape of the existing black monochrome icon and adds a thin white inverse-color edge only on the transparent side of the glyph. It is a static icon designed to remain visible on both light and dark surfaces; it does not switch icon resources when the Windows system theme changes.

This setting updates the IconFile / IconIndex values registered in the Windows TSF language profile for Mozkey, and applies to the IME icon shown in the taskbar and IME list.

Administrator approval may be required when applying this setting. Depending on the Windows icon cache or input-method list refresh timing, the taskbar or IME-list icon may not update immediately. If it does not update, restart Windows.

Windows Search / immersive TSF support

On Windows, Mozkey uses an in-process Win32 renderer path for immersive TSF hosts such as the Windows Search UI so that candidate, suggestion, and live-conversion ruby windows are not hidden behind the host presentation layer. The renderer runs on a dedicated UI thread inside the TSF host process, and the renderer windows are created with the host top-level window as their owner while avoiding focus activation.

Ordinary conversion candidates keep the existing mouse behavior: mouse-down highlights the candidate and mouse-up selects it.

For an unfocused passive suggestion list, mouse-down does not highlight a candidate or move the session into ordinary conversion. Mozkey keeps the candidate ID pressed during that mouse gesture and submits it with SUBMIT_CANDIDATE on mouse-up.

A passive Suggestion shown during live conversion is generated from a cloned ImeContext, separately from the converter state used by the active live conversion. The same numeric candidate ID can therefore refer to different values in the visible Suggestion list and the normal conversion list. Mozkey keeps the cloned context that produced the visible Suggestion and resolves the mouse-up candidate ID against that same converter state, preventing an unrelated normal-conversion candidate from being committed instead of the suggestion that was actually clicked.

Dragging outside the suggestion list before releasing the mouse does not commit a suggestion, while ordinary candidate clicking keeps its previous behavior.

Candidate window, suggestion window, and ruby display appearance (Windows / macOS)

On Windows and macOS, the config dialog can customize the appearance of the candidate window, the suggestion window, and the ruby display shown during live conversion.

The candidate window, suggestion window, and ruby display can use Light, Dark, Auto (follow system theme), or Custom colors. New configurations default all three theme selectors to Auto. Auto resolves the current system appearance and uses the corresponding light or dark renderer theme; after the OS appearance changes, the new theme is picked up on the next renderer update.

Explicit Light, Dark, and Custom selections do not follow later system-theme changes. The suggestion window and ruby display can also use Follow Candidate, which inherits the candidate window's resolved or custom appearance. Auto and Follow Candidate are separate settings.

Custom colors can be configured for the candidate and suggestion windows, including the background, text, selected background, selected border, border, shortcut, description, footer, and scrollbar colors. For the ruby display, the background, text, and border colors can be customized.

The display size, corner radius, opacity, and shadow spread, opacity, angle, and distance can also be configured for each window. The shadow angle uses screen coordinates: 0° is right, 45° is down-right, and 90° is down. Set the shadow distance to 0 for an even shadow on all sides. Candidate-like displays such as conversion candidates and usage/infolist windows use the candidate window settings, while prediction/suggestion displays use the suggestion window settings.

On Windows, horizontal padding, vertical padding, and distance from the input text can be configured independently for the ruby display. These are logical design values, not fixed physical-pixel values; they scale with the ruby display size and the DPI of the target monitor. In multi-monitor setups, the renderer recalculates the font, padding, corner radius, shadow, and input-text gap for the monitor that contains the composition target, and converts the TSF geometry to physical coordinates before placing the window.

The font used for the candidate window, infolist window, and live-conversion ruby display can also be changed from the config dialog. The setting can be reset to the default font, and the renderer falls back to the default font if the selected font cannot be used reliably for candidate rendering.

The primary text weight can also be configured independently from 100 to 900 for the candidate window, suggestion window, and live-conversion ruby display. The default is 400 (Regular). Auxiliary text such as candidate shortcuts, descriptions, footer labels, and infolist text keeps its existing weight.

The ruby display shown during live conversion can be enabled or disabled from the config dialog.

Conversion status indicator (Windows / macOS)

An independent indicator near the composition shows the current conversion display/processing status. It is separate from both the live-conversion ruby overlay and the IME on/off mode indicator. The "Conversion status indicator" section of Input/Appearance settings controls it. It defaults to ON for new/unset profiles while respecting an explicitly saved OFF setting, and remains available when the ruby overlay is disabled.

These statuses describe the visible operation, not per-character provenance. In particular, a pending Zenz request does not mean all currently visible characters have already been produced by Zenz.

Appearance settings cover Capsule / Circle / Rounded rectangle, Name / Symbol / Color-only labels, separate status colors, text and border colors, font, minimum width, height, opacity, corner radius, border, shadow, spacing, position, and horizontal/vertical offsets. Standard, Minimal, and Detailed presets are available, with Custom detected when edited settings differ. The preview shows all four statuses together even while the indicator is disabled. The default colors are Mozc #586B85, Zenz processing #847438, Zenz applied #338D85, and Reading #747D8C.

Position options are Automatic (avoid overlap), Beside ruby, Above ruby, Above text, and Below text. Beside ruby is centered vertically on the ruby in horizontal writing; in vertical writing it sits below the ruby column and is centered horizontally. Above ruby retains the leading-edge alignment: left-aligned in horizontal writing, top-aligned outside the ruby column in vertical writing. User offsets are applied after the reference alignment. Without a ruby window, placement uses the composition geometry.

The indicator is suppressed while the user actively selects or navigates a candidate list, but an unfocused passive live-conversion suggestion does not suppress it. Placement avoids covering the preedit, ruby, or candidate window. If an explicitly chosen position cannot be used safely, the indicator is hidden rather than moved to an unrelated side.

The Windows implementation, including its high-DPI drawing correction, has been exercised with real IME input. The new indicator has not yet received native macOS build or runtime verification; the shared placement logic and source-level integration do not constitute a macOS release validation.

On Windows, the IME mode indicator can use System theme, Dark, Light, or Custom. System theme follows the Windows light/dark appearance; explicit Dark or Light keeps that appearance even when the Windows theme changes. Custom allows separate colors for alphanumeric, Hiragana, and Katakana indicators, plus size, corner radius, border, and shadow adjustments.

When the input position is near an edge of the monitor work area, the indicator is automatically repositioned to stay on-screen. Reset restores the indicator theme and custom appearance values to their defaults without changing whether the indicator itself is enabled.

Windows TSF private input (IS_PRIVATE)

On Windows, an input context whose TSF input scope includes IS_PRIVATE is handled as a private-input state distinct from Mozkey Secret / Incognito mode. In environments such as Chrome Incognito, Edge InPrivate, and Firefox Private Browser that report this scope, existing Mozc learning history and Zenz feedback can still contribute to conversion and ranking, and local Zenz inference continues to run, but new persistent learning originating from that private input is not stored.

For the normal DEFAULT_HISTORY setting, the affected request is treated like READ_ONLY: existing history remains readable while new Mozc history and suggestion-history writes are suppressed. Stored Zenz feedback remains readable, but Mozkey does not persist new feedback or teach an accepted Zenz result back into Mozc history from that private input. Existing READ_ONLY and NO_HISTORY settings are preserved rather than being replaced.

While private input is active, Mozkey overlays a small shield on the Windows taskbar input-mode icon and on the IME mode indicator. The shield represents TSF IS_PRIVATE; enabling Mozkey Secret / Incognito mode alone does not show the same badge. The normal taskbar mode glyph, the private shield, and the disabled X switch between black and white with the Windows system light/dark theme and refresh when that theme changes. The disabled X keeps precedence when the IME is disabled.

Vertical writing support (Windows / macOS)

On Windows and macOS, Mozkey lays out the candidate window, prediction/suggestion display, infolist, and live-conversion ruby for vertical writing while preserving the existing horizontal-writing behavior.

For candidate navigation in vertical writing, both Windows and macOS pass the vertical-writing state into the session layer. When the active keymap uses the supported existing command bindings, Mozkey reinterprets arrow keys to match the visual writing direction.

• In Suggestion state, Left enters the candidate list.
• In Conversion / Prediction state, Left / Right move through candidates while Up / Down move between segments.
• In Conversion state, Shift+Up shrinks the segment width and Shift+Down expands it.
• Existing Shift+Left / Shift+Right segment-width operations remain available for compatibility.

Horizontal writing, ordinary cursor movement during Composition, Ctrl+Shift combinations, and keymaps that do not use the supported command bindings retain their existing behavior.

Windows

On Windows, Mozkey detects vertical composition geometry and uses DirectWrite vertical text rendering for primary candidate and infolist text.

The candidate window prefers placement on the left side of a vertical composition. When an application reports a narrow input-line geometry, Mozkey adds placement clearance so that the candidate display does not sit too close to the input text. This adjustment is based on the reported composition geometry rather than application-specific name checks.

In vertical mode, candidate columns keep natural per-candidate geometry based on their own text and description content. A long candidate does not force unrelated candidate columns to expand to the same size. The selection background extends through the candidate body even when the visible text is short, making the currently selected vertical column easier to identify.

Cascading candidate windows are anchored to the focused candidate and prefer expanding to the left, outward from the vertical composition. If the left-side placement would collide with the candidate/preedit region or cannot fit within the working area, the renderer falls back to the right. The existing horizontal cascading placement is preserved.

The live-conversion ruby display also follows vertical composition geometry. When an uncommitted composition wraps across multiple vertical columns, such as in Word, the renderer keeps the ruby outside the already occupied composition span instead of placing it over an earlier column.

macOS

On macOS, Mozkey propagates the writing direction obtained by the IMK input side into the renderer and uses Core Text vertical text rendering for primary candidate, infolist, and ruby text.

For candidate and suggestion rows, the technical Core Text frame required to render the full string is kept separate from the visible candidate-column width. The visible width uses a nominal CJK column width as its floor and expands only when the actual glyph ink requires more space. This avoids unnecessarily wide columns for Japanese, ASCII, and half-width katakana while preserving enough room for genuinely wide glyphs.

The vertical gap between the candidate/suggestion display and the composition text is 6 pt. The live-conversion ruby is also placed with an effective 6 pt gap. Existing horizontal-writing spacing and placement remain unchanged.

The infolist uses compact per-column Core Text frames in vertical mode. The ruby display similarly keeps a sufficiently large technical text frame while sizing the visible pill from the nominal CJK column width and actual glyph ink.

Cascading candidate windows are anchored to the focused candidate and prefer expanding to the left, which is outward from the vertical composition. If that placement would collide with the candidate/preedit region or run out of room, the renderer falls back to the right side. Sibling cascade windows are also kept from overlapping each other.

The macOS vertical-writing implementation is separated into dedicated layout and writing-direction logic, with unit tests for candidate layout, infolist layout, writing direction, and window placement. The existing horizontal-writing path retains its previous behavior.

Windows preedit presentation and display colors

On Windows, enabling Dim unresolved Roman input while using Roman input gives only the unresolved trailing romaji that is still an incomplete conversion-rule prefix a separate, subdued presentation. This is presentation metadata only: it does not change the input string, conversion key, or committed text.

The feature is opt-in. For a new or otherwise unset profile, the default is OFF. If an explicit ON / OFF value has already been stored, that existing user choice is preserved. Dimness is configurable from 0% to 100% in 1% steps, with a default of 85%. Higher values move the unresolved Roman text closer to the background color; 0% keeps high contrast, while 100% matches the background and becomes invisible.

Pending-romaji presentation metadata is also preserved through live-conversion and Zenz-correction display paths when the original segment key/value relationship can be kept safely. Presentation-only splitting never synthesizes segment keys from displayed values; if a segment cannot be split safely, its original key/value is kept unsplit.

The presentation is applied through a dedicated Windows TSF display attribute. In Gecko-based hosts such as Firefox, Mozkey uses a subdued text color matched to the editor background only when that background can be sampled safely. Selection-painted regions, clipped geometry, and non-uniform surfaces are not cached as editor backgrounds; Mozkey falls back to a compatibility presentation instead. When the feature is OFF, no screen sampling is performed for this feature.

The config dialog also allows the following display colors to be configured separately for input text, the converting segment, and "Text being corrected by Zenz":

• Text color
• Background color
• Underline color

For new or otherwise unset profiles, the default underline color is #30DCC8 for input text and #C1A5AB for the converting segment. The "Text being corrected by Zenz" category uses a dedicated underline color that defaults to enabled with #C4DC6C. Its dedicated text and background colors default to disabled; for each disabled Zenz color channel, Mozkey falls back to the corresponding custom converting-segment color when enabled, otherwise to the existing Windows TSF presentation. Explicitly stored color choices and enable/disable states are preserved.

These options are intended to improve the visibility of uncommitted text, especially for users who need stronger visual contrast while composing or converting Japanese text.

The settings are applied through Windows TSF display attributes. They work only in applications that honor those attributes. Some applications, including Chrome and Edge, may ignore them.

Enhanced system dictionary

This fork includes scripts to build an enhanced Mozc system dictionary from external dictionary sources.

Separately from the external generated dictionaries, Mozkey also maintains a small tracked manual override dictionary for daily vocabulary, practical vocabulary, loanwords, and English spelling candidates. Normal Japanese entries are expected to remain natural first candidates, while English spelling entries are treated as secondary candidates. See Koyasi Dictionary Data for the detailed policy and evaluation workflow.

The daily local dictionary can be generated from:

• merge-ut-dictionaries
  • place names
  • SudachiDict-derived vocabulary
• dic-nico-intersection-pixiv
  • additional proper nouns, internet slang, works, characters, and subculture terms
  • entries already covered by the generated daily dictionary or the base Mozc dictionaries are skipped
  • values ending with decorative symbols such as ☆, ★, ♡, ♪, or ※ are rejected because they tend to be noisy in daily conversion
• mozcdic-ut-personal-names
  • personal names, stage names, and activity names
  • entries already covered by the generated daily dictionary, nico/pixiv delta dictionary, or base Mozc dictionaries are skipped
  • risky short readings, long katakana-like names, group-like names, ASCII values, and punctuation-heavy values are filtered or demoted
• Mozkey syntax / expressive kana guard dictionary
  • small generated guard entries for high-impact segmentation failures
  • for example, protecting paths such as と打ちたいのに, に分ける, した方が, したにもかかわらず, にまで, までに, までも, 肌身離さず, になってしまいます, and になっちゃいます
  • also adds natural kana candidates for completed expressive forms such as うっそ, くっそ, やっば, ちっす, ほえ～, ほぇ～, and ほっほーん

Large generated dictionary files are not committed to this repository. They are generated locally under src/data/dictionary_koyasi/generated/.

Windows release MSI packages may include the locally generated daily system dictionary profile. See Third-party notices and Koyasi Dictionary Data for source and license notes.

Before building a package with the enhanced dictionary enabled, regenerate the daily dictionary locally:

.\tools\dictionary\prepare_daily_dictionary.ps1

See:

• Koyasi Dictionary Data
• Third-party notices

Developer documentation

For source builds, Zenz runtime packaging, and installer validation, consult:

• Windows build instructions
• macOS Universal Zenz runtime / PKG build guide
• macOS installer regression test guide
• Linux build instructions

Upstream and licensing

Mozkey is based on Mozc. For the original upstream README and upstream release policy, see google/mozc. License and attribution information is preserved in LICENSE, AUTHORS, CONTRIBUTORS, and Third-party notices.