Windows のフォントはコピーだけでは使えない: 登録漏れでターミナル設定が巻き戻っていた

朝いちばんのアラート

Windows Terminal を開いたら、フォントが見つからないというアラートが出た。 指定しているのは HackGen Console NF。2日前に自分で入れたばかりのフォントだ。

心当たりがないので、Claude Code に調べさせた。 返ってきた答えははっきりしていた。ttf は %LOCALAPPDATA%\Microsoft\Windows\Fonts に置かれている。ところが Windows 側の登録がない。ファイルはあるのに、Windows は「そんなフォントは知らない」と言っている状態だった。

診断は当たっていた。引っかかったのは、その次に返ってきた推奨のほうだ。

最初に返ってきた推奨

履歴を検索させたところ、HackGen を入れた記録はゼロだという。 だから推奨も、すでに登録済みで Windows が認識している UDEV Gothic NF へ設定を戻すほうが確実、というものだった。レジストリを新しく触らずに済むぶん、失敗の余地が小さいという理屈である。

理屈は通っている。ただ、記憶と合わなかった。

なぜ記録が見つからなかったのか

GrokBot を動かすときに、リモートの Linux を黒いターミナル画面から開いたら、日本語が線になった。それで8月の後半か9月の前半にフォントで直したはずだ。 そう伝えて、もう一度探させた。

記録は出てきた。 最初の「記録ゼロ」は誤りだった、と訂正が返ってきた。HackGen という文字列だけで履歴を探したために、口頭で指示した経緯を拾えていなかったという。

検索語を1つ決め打ちすると、その語が書かれていない経緯はまるごと視界から消える。作業のきっかけが会話だったものは、後からキーワードでは拾えない。

そして推奨は逆を向いた。UDEV Gothic へ戻すのではなく、HackGen を正しく登録するのが筋だ、という結論に変わった。

コピーと登録、どちらが抜けていたか

ユーザー単位のフォントインストールには2手ある。

1. %LOCALAPPDATA%\Microsoft\Windows\Fonts へ ttf をコピーする
2. HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts へ登録する

9月5日の作業は、1で止まっていた。 ttf のフォルダは 2026-09-05 07:19:37 に作られ、settings.json は 08:58 に更新されている。フォントを置いて、ターミナルの設定でそれを指名したところまでは、たしかにやっている。

全セッションの履歴を検索させても、AddFontResource の呼び出しとフォントレジストリへの書き込みは0件だった。 9月5日に書いた記事には「登録した」「バックアップを取った」と書いてある。どちらも実行されていなかった。

設定が黙って元へ戻る仕組み

従来コンソール（黒いウィンドウ）も見せてもらったら、FaceName が Lucida Console に戻っていた。FontSize の値も消えている。

コンソールは、指定されたフォントを解決できないと代替フォントで描画する。そして、その値を終了時にレジストリへ書き戻す。 登録漏れがあると、直した設定が黙って元へ戻るわけだ。5日に名前を書き換えただけだったので、2日に直した分まで巻き戻った。

GrokBot の接続作業で黒いウィンドウから SSH していれば、同じ症状が再発していた。

手当て

1. Documents\TerminalFontBackups\20260907-065440-before-hackgen-register\ に3ファイルを退避（console-before.reg、windows-terminal-before.json、hkcu-fonts-before.txt）
2. HKCU に2値を登録し、AddFontResource と WM_FONTCHANGE のブロードキャストで起動中のウィンドウにも反映させた
3. 従来コンソールの FaceName を x64 と x86 の両方で HackGen Console NF に設定。FontFamily=0x36、FontSize=0x000B0000（高さ11）、FontWeight=400

書けたことと、使えること

設定ファイルやレジストリに書けたことは、Windows がそのフォントを解決できることを意味しない。 9月5日の自分は、そこで終わったつもりになっていた。settings.json に HackGen Console NF と書けたので、入ったのだと思っていた。

だから今日は、書けたかどうかではなく、画面に出るかどうかで確かめさせた。

• InstalledFontCollection の一覧に HackGen Console NF が出ること
• conhost を実際に起動して、日本語とかな、罫線、英数字を撮った。FaceName の実測値も同じ画面に出させた
• Windows Terminal を新規ウィンドウで開き、アラートが出ないことと日本語表示を確認した
• 全角と半角の幅比（あいうえお と ABCDEFGHIJ の行末が揃うこと）

同じ日に2回踏んだ PowerShell の罠

作業の途中で、PowerShell スクリプトが2回落ちた。 どちらも「パラメーターに null をバインドできません」という、フォントとは何の関係もなさそうなエラーだった。

原因は文字コードだった。日本語のコメントを書いた .ps1 を BOM 無しで保存すると、Windows PowerShell 5.1 はそれを ANSI（cp932）として読む。コメント1行が壊れ、後続の変数代入まで巻き込まれて落ちる。

2回とも同じ原因だったので、ルールに書いた。

残したもの

• 9月5日の記事 Windows Terminal のフォントを HackGen に替えた記録 に今日の経緯を追記し、事実と違っていた記述2か所を訂正した
• ~/.claude/rules/windows.md に2件足した。ユーザー単位のフォントインストールは2手であること、確認は設定値ではなくフォント一覧で行うこと。もう1件は .ps1 の BOM

引っかかっているのは、訂正したほうだ。5日の時点で自分は「登録した」と書いていた。それを読んで作業した今日、実行されていなかったと知った。書いた記録と、実際に走ったコマンドが食い違っていたわけである。確認をフォント一覧で取るとルールに書いたので、次は同じ形では通らないはずだ。