Windows Terminalの日本語が詰まって見える。変更履歴をたどってHackGenに替えた

Windows Terminalの日本語が詰まって見える。少し前、GrokBotの接続作業中に日本語がうまく表示されず、フォントを変更した。その後も読みにくさが残ったが、何から何へ変えたのかを覚えていなかった。

設定ファイル、バックアップ、過去記事、会話履歴を照合すると、現在の指定はBIZ UDGothicの10ptだった。今回はHackGen Console NFの11ptへ変更した。昔ながらの独立したPowerShellウィンドウにも、同じ書体を指定した。

元のフォントは7月の記事に残っていた

最初の手がかりは、7月13日に書いたUDEV Gothicの導入記事だった。当時はフォント名が未指定で、日本語の見た目をそろえるためにUDEV Gothicを導入していた。最後に選んだのはUDEV Gothic 35NFの10ptだ。

9月2日のセッション履歴には、その後の変更も残っていた。下の表はWindows Terminal側の設定を時系列に並べたもの。書体だけでなくサイズも何度か変わっている。

時刻は日本時間。9月2日の途中経過は会話履歴、現在値と一部の変更前の値は実ファイルでも確認した。設定フォルダーには、MS Gothic・12ptの段階とUDEV Gothic NF・12ptの段階のバックアップが残っていた。

7月の記事はGitで管理されていた。一方、Windows Terminalの設定ファイル自体がGit管理されている形跡は、今回確認した範囲では見つからなかった。記事には選んだ理由が残り、バックアップには実際の設定値が残る。この2つを会話履歴でつなぐと、変更の流れをたどれた。

UDEVからBIZ UDへ替えても、日本語は同系統だった

前回の変更には、見直すべき点があった。

UDEV Gothicの公式説明によると、日本語部分はBIZ UDゴシック、英数字部分はJetBrains Monoを組み合わせている。つまりUDEV GothicからBIZ UDGothicへ替えても、日本語は同じ系統の書体だ。加工やサイズの違いはあるが、日本語のデザインを大きく替えたことにはならない。

当時の回答はBIZ UDGothicを「メイリオに近い」と説明していたが、その選び方では希望を十分に捉えられていなかった。さらに11ptから10ptへ縮めている。書体とサイズを同時に変えたため、どちらが読みにくさに影響したのかも切り分けにくくなっていた。

なお、元のUDEV Gothicにも日本語は収録されている。SSH接続時の表示不良では、リモートのロケール設定やtmuxも調べており、履歴上の原因説明も途中で変わっていた。元のフォントが日本語非対応だった、と断定できる記録ではない。日本語を入力できるか、文字データが残っているか、画面で描けるかは分けて確認したい。

今回はHackGen Console NFを選んだ

HackGen（白源）は、英数字のHackと日本語の源柔ゴシックを組み合わせたフォントだ。今まで使っていたBIZ UD系から、日本語部分のデザインを替えられる。

採用したのはHackGen Console NF。Consoleはターミナル向けに記号を扱う版、NFはNerd Fontsのアイコンを含む版を表す。半角と全角の幅が1対2の通常系統を選んだ。35系統は3対5で、英数字の幅も変わるため、今回は比較対象を増やさなかった。

導入したファイルは、公式リリースv2.10.0のNF版アーカイブに入っている次の2つ。

• HackGenConsoleNF-Regular.ttf
• HackGenConsoleNF-Bold.ttf

Windowsでは、展開したTTFを右クリックして「インストール」を選ぶとユーザー単位で導入できる。ユーザー単位インストールの実体は「%LOCALAPPDATA%\Microsoft\Windows\Fonts へのコピー」と「HKCUレジストリへの登録」の2つで、両方そろって初めてWindowsがフォントを解決できる。設定に使うファミリー名は、ファイル名ではなく HackGen Console NF だ。

この日の作業では、コピーだけを実行して登録を飛ばしていた。 そのため設定を書き換えてもフォントは解決されず、2日後にアラートとして表面化した。経緯と手当ては末尾の追記に書いた。

サイズはまず11ptにした。12ptを大きいと感じた履歴を踏まえ、今回はそこまで戻していない。これで読みやすさが決まったわけではなく、実際のターミナルで使いながら好みを確かめる。次に調整するなら書体を固定し、文字サイズを10.5ptにするなど、1項目ずつ変える。

Windows Terminalは既定値と個別設定を確認する

Windows Terminal内で動かしているPowerShellの文字は、Windows Terminal側で設定する。

Ctrl+, で設定を開き、「プロファイル → 既定値 → 外観 → フォントフェイス」から変更できる。Microsoft Store版の設定ファイルは次の場所にある。

%LOCALAPPDATA%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json

共通設定の該当部分はこうなる。これはファイル全体を置き換えるJSONではなく、profiles.defaults の中にあるフォント設定の抜粋だ。

"font": {
  "face": "HackGen Console NF",
  "size": 11,
  "cellHeight": "1.35"
}

今回は共通の既定値に加えて、「Windows PowerShell」と「PowerShell」の各プロファイルにもBIZ UDGothic・10ptが明示されていた。個別指定がある項目は、共通の既定値より優先される。そこで3か所ともHackGen Console NF・11ptへ変更した。

既定値を変えたのに一部のタブだけ変わらないときは、設定画面の各プロファイルの「外観」も見る。フォント名、サイズ、行の高さなどの設定項目は、Microsoftの外観設定ドキュメントで確認できる。

書体を替えた後、行間も少し広げた

フォントを変更した後、「行間に少しスペースがあれば、もっと見やすそうだ」と感じた。Windows Terminalには、文字サイズとは別に行の高さを指定する font.cellHeight がある。今回は上のJSONのとおり "1.35" を追加した。

変更したのは既定値、Windows PowerShell、PowerShellの3か所。HackGen Console NF・11ptは維持し、文字の上下に余裕を持たせる設定にした。ウィンドウの周囲の余白を設定する padding とは別の項目だ。

Microsoftの設定スキーマでは、cellHeight はCSSの line-height に似た設定とされている。未指定時はフォント固有の高さを使うので、1.35は「元の行間から35%増やす」という意味ではない。数値はJSONでは文字列で指定する。

行の高さを増やすと、同じウィンドウに表示できる行数は減る。広すぎると感じたら "1.25" などへ下げ、元の自動設定へ戻すなら cellHeight を削除する。この調整はWindows Terminal内のPowerShellに適用され、従来の独立したコンソールホストの設定は変えていない。行高を変える直前のJSONも別途バックアップした。

従来のPowerShellウィンドウは別の設定を持つ

タブのない従来のコンソールホストで動くPowerShellは、Windows TerminalのJSONとは別設定になる。今回の変更前は、こちらだけUDEV Gothic NFのままだった。

自分の環境では、次のレジストリキーに64bit版と32bit版のPowerShell用設定があった。

HKEY_CURRENT_USER\Console\%SystemRoot%_System32_WindowsPowerShell_v1.0_powershell.exe
HKEY_CURRENT_USER\Console\%SystemRoot%_SysWOW64_WindowsPowerShell_v1.0_powershell.exe

両方の FaceName を HackGen Console NF に変更し、FontSize は高さ11・幅自動の既存値を維持した。従来コンソールのサイズ指定はWindows Terminalのptとは単位が異なり、同じ「11」でも実寸が一致するとは限らない。

ショートカットから起動する場合は、そのショートカットが持つ設定も影響する。新しく開いたウィンドウに反映されない場合は、タイトルバーのメニューから「プロパティ → フォント」を確認する。

変更前を保存して、戻せるようにする

書き換え前の設定は、Windowsの「ドキュメント」フォルダー内の TerminalFontBackups に残す方針にした。ここには9月2日の変更時に取った2つのREGファイルがある。

ただしこの日、9月5日ぶんのバックアップは作成されていなかった。 上の2ファイル以外にフォルダーは無く、Windows Terminalの settings.json の控えも残っていない。9月7日の作業で改めて取り直している（末尾の追記を参照）。

9月2日のREGへ戻すと、従来PowerShellはUDEV Gothic NF・高さ11、またはその前のLucida Consoleに戻る。元に戻す場合は必要なREGファイルを取り込む。設定ファイル全体を復元すると、その後に変えた色やショートカットも一緒に戻ってしまうので、font の値だけを見て設定画面で直すほうが安全だ。

変更後に読み直したのは、Windows Terminalの設定3か所と、従来コンソールのレジストリ2か所。フォントが「インストール済みとしてWindowsに認識されているか」は、このとき確認していない。 指定値が入っていることと、その指定が解決できることは別で、今回はここを分けて見ていなかった。

今回は記事に書体名だけでなく、変更理由、サイズ、設定箇所、戻し方を残した。次に違和感が出たら、そこから比較を始められる。

追記（2026-09-07）: 登録が抜けていて、2日後にアラートになった

9月7日の朝、Windows Terminalの起動時に「フォントが見つからない」というアラートが出た。調べると、HackGen Console NF はWindowsに登録されていなかった。

つまり9月5日は「コピー」だけで終わっていて、「登録」が実行されていなかった。設定側だけがHackGenを指し、実体が解決できない状態が2日続いていた。

従来のコンソールは元のフォントへ戻っていた

さらに、従来コンソール（タブのない黒いウィンドウ）の FaceName は Lucida Console に戻っていた。FontSize の値も消えていた。

9月2日 朝    Lucida Console      日本語グリフを持たない。SSH中に「線」に見えた状態
9月2日 9:14  UDEV Gothic NF      ここで直した
9月5日       HackGen Console NF  設定を変更（ただしフォントは未登録）
9月7日 朝    Lucida Console      戻っていた

指定したフォントを解決できないと、コンソールは代替フォントで描画し、その値を終了時に書き戻す。9月2日に直したはずの状態が、登録漏れによって元へ戻っていたことになる。GrokBotの接続作業で黒いウィンドウからSSHしていれば、同じ症状が再発していた。

やり直した手順

1. 変更前を Documents\TerminalFontBackups\20260907-065440-before-hackgen-register\ に保存（console-before.reg / windows-terminal-before.json / hkcu-fonts-before.txt の3ファイル）
2. HKCUへ2値を登録し、AddFontResource と WM_FONTCHANGE で起動中のウィンドウにも反映

$dst = Join-Path $env:LOCALAPPDATA 'Microsoft\Windows\Fonts'
$key = 'HKCU:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts'
$map = @{
  'HackGenConsoleNF-Regular.ttf' = 'HackGen Console NF (TrueType)'
  'HackGenConsoleNF-Bold.ttf'    = 'HackGen Console NF Bold (TrueType)'
}
foreach ($f in $map.Keys) {
  New-ItemProperty -Path $key -Name $map[$f] `
    -Value (Join-Path $dst $f) -PropertyType String -Force | Out-Null
}

3. 従来コンソールの FaceName を x64・x86 の両方で HackGen Console NF に戻し、FontFamily=0x36、FontSize=0x000B0000（高さ11）、FontWeight=400 を明示

今回は「解決できること」まで確認した

前回の反省を踏まえ、設定値ではなく描画結果まで見た。

• InstalledFontCollection に HackGen Console NF が現れることを確認
• 従来コンソールを実際に起動し、日本語・かな・罫線・英数字を表示して撮影。FaceName の実測値も画面に出した
• Windows Terminalを新しいウィンドウで開き、アラートが出ないことと日本語の表示を確認
• 全角と半角の幅比も、あいうえお と ABCDEFGHIJ の行末がそろうことで確認

設定を書いたかどうかと、それが解決できるかどうかは別物だった。フォントを替えたときは、指定値の読み直しではなくフォント一覧に出るかと実際の描画を見る。

補足: PowerShellスクリプトの文字コード

作業中、BOMなしUTF-8で書いた .ps1 に日本語コメントを入れたところ、Windows PowerShell 5.1がANSI（cp932）として読み、変数がnullになって落ちた。Windows PowerShell 5.1に渡すスクリプトは、日本語を含むならUTF-8 BOM付きで保存する。 含まないならBOMなしでも動く。