Windows 11 24H2（ビルド 10.0.26100.4946）で AppLocker の発行元（Publisher）条件ルールを追加した際、ルール一覧の一部の行だけフォントが変わって「にじむ／太さが違う／字形が違う」ように見える場合があります。本記事では、この現象の原因と設計意図、そして運用での実践的な対処策を、再現手順・検証ポイント・PowerShell スクリプト例まで含めて詳しく解説します。
現象の要点（発生条件と見え方）
- 対象環境：Windows 11 24H2（ビルド 10.0.26100.4946）。AppLocker の Publisher 条件を使ったルールを GPO などから作成。
- ルール一覧で、参照したバイナリの「ファイルの説明」（FileDescription）や「会社名」「製品名」等のメタデータに、漢字・絵文字・その他の Unicode 文字（拡張漢字、異体字、記号など）が含まれる。
- このとき該当行がシステム既定フォント（いわゆるユニバーサル フォント）で描画され、同じ行の「条件タイプ」列（Publisher 等）までフォントが切り替わって見える。
- 結果として、一覧の中で一部行だけ字幅やウェイトが違うように見え、「異常」や「文字化け」のように感じられる。
結論（先に回答）
仕様どおりの挙動です。Windows のテキスト描画は、表示すべき文字に対してグリフを持たないフォントが指定された場合でも文字欠落（□や?の表示）を避けるため、フォント フォールバック（代替フォントへの切り替え）を行います。AppLocker の一覧グリッドは列の途中だけ別フォントが混ざって読みづらくなるのを避けるため、該当行全体を同一フォントで統一して描画します。そのため、「条件タイプ」列までフォントが切り替わったように見えます。視覚的な差はありますが、ルールの評価や適用（許可／拒否）には一切影響しません。
なぜフォントが混在して見えるのか（仕組みの理解）
Windows の UI は、DirectWrite 等の描画スタックを通じてテキストをレンダリングします。アプリ側（ここでは AppLocker 管理コンソール）は、複数列からなる一覧（グリッド）を描画しつつ、各セルの文字集合を総合的に評価して「行」単位で適切なフォントを選びます。行内に絵文字や BMP（基本多言語面）外の文字、異体字セレクタなどが存在し、既定 UI フォントにグリフがない場合、Windows は欠落を回避するためにユニバーサル フォントへ切り替えます。この切り替えは視覚的な統一性を優先し、同一行の他列（「条件タイプ」や「アクション」など）も同じフォントで描き直されます。
| 文字の種類 | 代表例 | 描画時の挙動 | 見え方 |
|---|---|---|---|
| ASCII / 基本的なカナ・常用漢字 | A–Z, 0–9, ひらがな, カタカナ, 一般的な漢字 | 既定 UI フォントで描画 | 他行と同じ字幅・ウェイトで均一 |
| 拡張漢字・異体字・CJK 拡張面 | （つちよし）等、CJK 拡張 B 以降 | ユニバーサル フォントへフォールバック | 該当行全体の字形・字幅がわずかに変化 |
| 絵文字・記号 | など | カラー絵文字または対応フォントに切替 | 行全体が別フォントに見え、太さや高さが変わる |
セキュリティ影響の有無
- 影響なし：表示フォントの切替は UI レベルの挙動であり、ポリシー評価エンジン（AppLocker による許可／拒否判定やイベント ログ出力）には関与しません。
- 適用結果（Audit/Enforce）やイベント ログの成否、ハッシュ／発行元検証ロジックは通常どおりに機能します。
発生環境と前提
- OS：Windows 11 24H2（ビルド 10.0.26100.4946）
- 構成：GPO から AppLocker の Publisher 条件ルールを新規追加または編集
- 端末差：システムフォントや言語パック、フォントの有無が端末ごとに異なるため、別端末では再現しないことがあります。
再現手順（確認したい場合）
- GPO 管理エディターで「コンピューターの構成 → Windows の設定 → セキュリティの設定 → アプリケーション制御ポリシー → AppLocker」を開く。
- 「実行可能ファイルの規則」など対象コレクションで「新しい規則の作成」。
- 条件に「発行元」を選び、ファイルの説明に Unicode や絵文字を含む EXE/DLLを参照してルールを作る。
- 作成後、ルール一覧を開くと、該当行の「名前」や「条件タイプ」までフォントが切り替わって見える。
「異常」ではなく設計上の仕様
見た目として「列の見出し（条件タイプ）まで変わるのはおかしい」と感じやすいですが、行内でフォントが混在するほうが読みづらいケースが多く、行単位でフォントを統一するのは UI の可読性を保つための設計的判断です。このため、GPO 設定やレジストリで AppLocker コンソールのフォントだけを固定化する手段はありません（コンソール自体のフォント設定項目は提供されていません）。
統一フォントで見たいときの対策（運用でできること）
対策 1：バイナリのメタデータを統一する
- 自社配布バイナリ（社内ツール・配布 EXE/DLL）の「ファイルの説明」「会社名」「製品名」に絵文字／拡張漢字／異体字等を含めない。
- 表記は ASCII もしくは JIS 基本漢字＋全角カナ程度に抑える。省略や別表記（例：「」→「吉」）を運用ルールに従い統一。
- 署名済みファイルは、文字列を修正した上で再ビルド＋再署名が必要。
対策 2：一覧の閲覧経路を変える（CSV/外部ツール）
- AppLocker コンソールの見た目は変更できません。PowerShell でルールを CSV 出力して、Excel などで任意フォント（メイリオ、游ゴシック UI 等）に統一して閲覧する方法が現実的です。
- 資産管理ツールで AppLocker ルール取得→レポート化できる機能があれば、そちらで表示フォントを固定するのも有効です。
対策 3：配布パッケージのガバナンス
- CI/CD や署名パイプラインに、埋め込みリソースの文字種検査（FileDescription/CompanyName/ProductName の Unicode チェック）を追加。
- 開発ガイドラインに「UI での互換性重視の文字種」を明記し、レビューのチェック項目に含める。
実務に役立つ比較表
| 選択肢 | 効果 | コスト | セキュリティ影響 | 向いている場面 |
|---|---|---|---|---|
| メタデータ修正（再ビルド） | 一覧のフォント切替を根本抑止 | 中〜高（ビルド/署名の手間） | なし | 自社開発や配布物を制御できる |
| CSV による閲覧 | 表示側のフォント統一 | 低（スクリプト整備のみ） | なし | 他社製品も混在する環境 |
| 外部レポート／資産管理 | ダッシュボード化・検索性向上 | 中（ツール導入・保守） | なし | 組織全体で可視化したい |
PowerShell サンプル（CSV で安全に可読化）
サンプル A：AppLocker ルールをコレクション横断で CSV 出力
Publisher 条件・パス条件・ハッシュ条件を横断してまとめます。Excel で開きフォントを固定すれば、視覚差を最小化できます。
# 管理者 PowerShell
[xml]$xml = Get-AppLockerPolicy -Effective -Xml
$rows = @()
foreach ($rc in $xml.AppLockerPolicy.RuleCollection) {
$collectionType = $rc.Type
# Publisher ルール
foreach ($r in $rc.FilePublisherRule) {
$cond = $r.Conditions.FilePublisherCondition
$exc = $r.Exceptions.FilePublisherCondition
$rows += [pscustomobject]@{
Collection = $collectionType
RuleId = $r.Id
Name = $r.Name
Action = $r.Action
Sid = $r.UserOrGroupSid
Type = 'Publisher'
Publisher = $cond.PublisherName
Product = $cond.ProductName
Binary = $cond.BinaryName
VerLow = $cond.BinaryVersionRange.LowSection
VerHigh = $cond.BinaryVersionRange.HighSection
Path = ''
Hash = ''
Exception = if ($exc) { $exc.PublisherName } else { '' }
}
}
# パス ルール
foreach ($r in $rc.FilePathRule) {
$cond = $r.Conditions.FilePathCondition
$rows += [pscustomobject]@{
Collection = $collectionType
RuleId = $r.Id
Name = $r.Name
Action = $r.Action
Sid = $r.UserOrGroupSid
Type = 'Path'
Publisher = ''
Product = ''
Binary = ''
VerLow = ''
VerHigh = ''
Path = $cond.Path
Hash = ''
Exception = ''
}
}
# ハッシュ ルール
foreach ($r in $rc.FileHashRule) {
$cond = $r.Conditions.FileHashCondition
$hashItem = $cond.FileHash
$rows += [pscustomobject]@{
Collection = $collectionType
RuleId = $r.Id
Name = $r.Name
Action = $r.Action
Sid = $r.UserOrGroupSid
Type = 'Hash'
Publisher = ''
Product = ''
Binary = ''
VerLow = ''
VerHigh = ''
Path = $hashItem.SourceFileName
Hash = $hashItem.Hash
Exception = ''
}
}
}
$dest = Join-Path $env:USERPROFILE 'Desktop\AppLockerRules.csv'
$rows | Export-Csv -Path $dest -NoTypeInformation -Encoding UTF8
Write-Host "Exported to: $dest" サンプル B：ファイルの説明などを「見やすく」抽出（絵文字等の置換）
拡張漢字・絵文字が Excel 上でも崩れにくいよう、表示用にだけ置換して CSV に出します（バイナリ本体は変更しません）。
function Remove-NonStandardChars {
param([string]$Text)
if ([string]::IsNullOrEmpty($Text)) { return $Text }
$sb = New-Object System.Text.StringBuilder
foreach ($ch in $Text.ToCharArray()) {
$cp = [int][char]$ch
if (
($cp -ge 0x20 -and $cp -le 0x7E) -or # ASCII 可視
($cp -ge 0x3040 -and $cp -le 0x30FF) -or # ひらがな・カタカナ
($cp -ge 0x4E00 -and $cp -le 0x9FFF) -or # CJK 基本
($cp -ge 0xFF00 -and $cp -le 0xFFEF) # 全角英数・記号
) {
[void]$sb.Append($ch)
} else {
[void]$sb.Append('?') # 見やすさ重視の代替
}
}
$sb.ToString()
}
$targets = @(
'C:\Program Files',
'C:\Program Files (x86)'
)
$files = Get-ChildItem -Path $targets -Recurse -Include *.exe,*.dll -ErrorAction SilentlyContinue
$rows = foreach ($f in $files) {
try {
$vi = [System.Diagnostics.FileVersionInfo]::GetVersionInfo($f.FullName)
[pscustomobject]@{
Path = $f.FullName
CompanyName = Remove-NonStandardChars $vi.CompanyName
ProductName = Remove-NonStandardChars $vi.ProductName
FileDescription = Remove-NonStandardChars $vi.FileDescription
FileVersion = $vi.FileVersion
}
} catch {
# 読み取り不可はスキップ
}
}
$dest = Join-Path $env:USERPROFILE 'Desktop\FileDescriptions_Sanitized.csv'
$rows | Export-Csv -Path $dest -NoTypeInformation -Encoding UTF8
Write-Host "Exported to: $dest" 注意：サンプル B はあくまで見やすくするための置換です。実際のメタデータを書き換えるわけではありません。正規化したい場合は、ソースコード／リソースを修正して再ビルド・再署名してください。
現場で役立つ検証チェックリスト
- 当該行のバイナリの FileDescription/CompanyName/ProductName に拡張文字や絵文字が含まれるか。
- 別端末（言語パック・フォント構成が違う端末）で再現するか。
- AppLocker のイベント ログ（「許可」「ブロック」）に異常がないか。
- 同一ベンダーの別バージョン（メタデータが違う）で見え方が変わるか。
- CSV 出力・Excel 強制フォント表示で可読性が改善するか。
よくある誤解と回答
- Q：フォントが行ごとに違う＝ルールが壊れている？
A：いいえ。UI 表示のみの問題で、評価ロジックは通常どおり動作します。 - Q：GPO で AppLocker コンソールのフォントを固定にできる？
A：できません。コンソール表示用のフォントを直接指定する設定は提供されていません。 - Q：ハッシュ条件やパス条件でも起きる？
A：列に表示されるテキストに拡張文字が含まれれば同様の見え方が起こり得ますが、典型的には Publisher 条件で参照したメタデータに由来します。 - Q：将来の更新で変わる可能性は？
A：UI の描画方針はバージョンにより調整される可能性はありますが、現象自体はフォント フォールバックという一般的な仕組みに基づくため、完全に無くすにはメタデータ側の統一が確実です。
運用ベストプラクティス（社内開発・配布物がある場合）
- 命名規則の策定：FileDescription/CompanyName は ASCII＋一般的な日本語に限定し、絵文字・異体字の使用を禁止。
- CI での自動チェック：ビルド成果物からバージョン リソースを抽出し、許容範囲外の文字を検出したらビルド失敗。
- レビュー観点：署名前に「発行元名」「製品名」などの UI 露出文字列を必ず確認。
- ドキュメント整備：ベンダーへ配布する命名方針のガイドラインを用意し、調達時に要求。
トラブルシューティング詳説（表示のぶれを読み解く）
行ごとのフォント切替は、行内で最も広い文字集合をカバーするフォントを選択した結果として生じます。よって、同じベンダーでも製品名に 1 文字だけ拡張漢字が含まれるバージョンと、含まれないバージョンが混在すると、一覧の中でも一見ランダムに行の見え方が変化します。こうした「ぶれ」は、列幅の自動調整やアイコンのレンダリング順序とも相互作用し、微妙な改行・折り返し位置に差を生みます。視覚差が運用上のストレスになる場合は、CSV 出力→Excel 固定フォントの閲覧フローへ切り替えるだけでも大きく改善します。
実例で学ぶ：Publisher ルールの強みと文字列の罠
Publisher 条件は、署名情報（発行元名）や製品名、バイナリ名、バージョン範囲に基づいて包括的に許可範囲を表現できる強力な方式です。一方で、作成時に参照した実ファイルのメタデータが UI に露出する設計のため、文字集合が広すぎるとフォント フォールバックが誘発されます。セキュアな運用そのものには影響しませんが、一覧レビューや監査用のスクリーンショットにおいて「見た目の揺らぎ」が気になる場合は、表示経路を切り替える（スクリプトや外部レポート）ことが最短の解決策です。
監査・ログとの関係
AppLocker の監査ログ（例：EXE and DLL、MSI and Script 等のチャネル）は、実行時の許可／拒否をイベントとして記録します。UI のフォント切替はこれらのログ出力に影響せず、統制上の証跡は維持されます。監査重視の現場では一覧の見た目に依存せず、CSV やイベント ログを一次情報として扱うことを推奨します。
端末差と再現性（なぜ別マシンで再現しないのか）
- プリインストール フォントの差（例：言語パック有無、企業イメージのフォント削減）。
- レンダリングの微差（DPI 設定、テキスト拡大率、ClearType 設定）。
- 表示領域の差（管理コンソールの列幅、モニター解像度）。
このため、「現場 A では混在に見えるが、現場 B では問題ない」といった乖離は珍しくありません。根本対策はメタデータ統一、暫定的には CSV での閲覧統一を採用しましょう。
運用フロー例（実践テンプレート）
- 新規アプリ登録時：Unicode 文字検査（社内ルールで許容された文字種に限定）。
- 配布前レビュー：FileDescription/CompanyName をレビュー表に貼り付け、承認プロセスで確認。
- ルール作成：Publisher 条件で登録、CSV エクスポートも同時に実施。
- 監査・点検：CSV（固定フォント）を一次閲覧、必要に応じてスクリーンショットは CSV ベースで作成。
見た目の統一にこだわるなら（補足テクニック）
- Excel 側での整形：列幅を固定、改行を無効化、フォントを「游ゴシック UI」や「メイリオ」に統一。
- CSV の正規化：サンプル B のように、レポート用にだけ「?」へ置換。（本番バイナリは決して書き換えない）
- 命名規則の自動チェック：PowerShell で CI に組み込み、エラー時はビルド失敗にする。
まとめ
Windows 11 24H2 の AppLocker ルール一覧で発生する「行単位のフォント切替」は、文字欠落を避けるためのフォント フォールバックに基づくもので、設計どおりの挙動です。見た目の統一を優先したい場合の最短解は、表示経路の切替（CSV/外部ツール）と、メタデータ側の統一を並行して進めること。セキュリティ評価やポリシー適用には影響がないため、落ち着いて原因を理解し、運用でスマートにコントロールしましょう。
実装メモ（短期・中期・長期のロードマップ）
| 期間 | 施策 | ねらい | 成果物 |
|---|---|---|---|
| 短期（今すぐ） | CSV 出力＋Excel フォント固定でレビュー | 見た目のばらつき解消 | AppLockerRules.csv、レビューテンプレート |
| 中期（1〜2 四半期） | CI にメタデータ文字種検査を組み込み | 将来のぶれ防止 | 検査スクリプト、ガイドライン更新 |
| 長期 | 社内配布物の命名規則を徹底・教育 | 持続的な可読性と監査性 | 開発標準、レビュー項目、教育資料 |
最後に（重要ポイントの再掲）
- これは障害ではなく仕様。ルール適用・監査には影響なし。
- 見た目を揃えるなら、メタデータ統一と表示経路の切替が最短。
- 端末差で再現しない場合がある（フォント・言語パック・DPI）。
コメント