gsi33: Unicode補助面の地名表記に関するWeb地図基盤の検証

[hfu]

以下、Copilot による生成です。

GSI Plane 2漢字テストセット：Unicode補助面の地名表記に関するWeb地図基盤の検証

概要

国土地理院は、令和8年（2026年）10月30日以降、地名情報で取り扱う日本語文字集合の範囲を一部変更し、これまで代替文字で表現していた一部の漢字を、本来の文字で表現する方針を公表している。

この変更は、単なる「珍しい漢字の追加」ではない。対象33文字の大半は Unicode の基本多言語面（BMP）外、すなわち補助漢字面（SIP: Supplementary Ideographic Plane）に属する文字であり、Web地図基盤、ベクトルタイル、MapLibre GL JS、PDF、検索、コピー＆ペースト等の処理系が、Unicode補助面の地名文字を損失なく扱えるかを試す実践的なテストケースになる。

本 issue では、国土地理院が公表した33文字を、UN Smart Maps / DWG7 関連ツールチェーンにおける回帰試験セットとして扱うことを提案する。

情報源

• 国土地理院「【予告】地名情報で取り扱う漢字の仕様を一部変更します。」
  https://www.gsi.go.jp/kihonjohochousa/kihonjohochousa41222.html

• 国土地理院「仕様の一部変更に伴い追加する漢字（33文字）」
  https://www.gsi.go.jp/common/000279182.pdf

• MapLibre Style Specification: Glyphs
  https://maplibre.org/maplibre-style-spec/glyphs/

背景

国土地理院の予告では、令和8年10月30日以降、日本語文字集合の範囲を一部変更し、以下の漢字を代替文字ではなく本来の文字で表現するとしている。

• 別表に掲げる漢字
• JIS X 0221 の追加面で表現される漢字

これは、地名情報の文字表記が、従来の代替字運用から、より正確なUnicode本字運用へ移行することを意味する。

これまで多くのWeb地図システムは、暗黙のうちに以下の前提に依存していた可能性がある。

• 日本語地名は概ねBMP内の漢字で表現される
• 稀な漢字は上流側で代替文字に置き換えられる
• 表示できない文字はフォントの問題として扱えばよい

しかし、国土地理院が公式な地名情報にUnicode補助面の漢字を投入することにより、問題はフォント表示だけではなくなる。

本質的には、次の問いになる。

地名情報の原データからWeb地図表示、検索、帳票、PDF、コピー＆ペーストに至るまで、Unicode補助面の文字を同一コードポイントとして保持できるか。

なぜWeb地図基盤にとって重要か

MapLibre GL JS を含むWeb地図表示では、文字描画に複数の経路があり得る。

glyph PBF を使う経路

MapLibre Style では、glyphs に以下のような URL テンプレートを指定できる。

{
  "glyphs": "https://example.org/fonts/{fontstack}/{range}.pbf"
}

この場合、ラベル表示は、指定されたフォントスタックと glyph PBF サーバに依存する。

重要な検証点は以下である。

• U+20000 以上の範囲に対する glyph PBF が生成できるか
• 使用フォントが対象文字のグリフを持つか
• glyph生成ツールがCJK統合漢字拡張B/Dを扱えるか
• MapLibre側が必要な範囲を正しく要求するか

glyphs を指定しない経路

近年のMapLibre GL JSでは、glyphs を省略した場合にローカル環境のフォントを用いる挙動がある。

この場合、SDF glyph 配信に依存しないため、CJK文字、とくに補助面漢字については、OSやブラウザのフォントフォールバックを利用できる可能性がある。

一方で、この経路では表示結果が以下に依存する。

• OS
• ブラウザ
• インストール済みフォント
• フォントフォールバックの実装
• IPAmj明朝、Noto CJK、游ゴシック、ヒラギノ等の有無

したがって、「MapLibreで表示できるか」という問いは、より正確には次の問いに分解すべきである。

どのレンダリング経路で、どの段階で文字が失われる、または表示不能になるのか。

問題意識

今回の国土地理院の変更は、「地図上に珍しい漢字が出るか」という狭い問題ではない。

むしろ、以下のような日本のWeb地図基盤全体の成熟度を試す出来事である。

• Unicode補助面の文字をデータとして保持できるか
• UTF-16サロゲートペアを含む文字列を壊さず処理できるか
• MVT/PBF にエンコード・デコードできるか
• MapLibre GL JS で表示できるか
• PDFや帳票に出力できるか
• PDFからのコピーで元のコードポイントが維持されるか
• 検索・ソート・正規化で意図しない変換が起きないか
• 「文字化け」と「フォント欠落」を区別して診断できるか

特に重要なのは、 と □ の違いである。

が表示される場合

は U+FFFD REPLACEMENT CHARACTER である。

これはフォントの問題ではなく、元の文字がデコード、変換、抽出、コピー等の過程ですでに失われていることを意味する。

この状態になった後では、IPAmj明朝などのフォントを追加しても元の文字は復元できない。

□ が表示される場合

□、いわゆる豆腐が表示される場合は、Unicode文字そのものは届いているが、現在のフォントまたはglyph配信経路に対応する字形がない可能性が高い。

この場合は、フォント、glyphサーバ、フォントフォールバック設定によって改善できる余地がある。

PDFで見えるがコピーで壊れる場合

PDFでは、画面表示とテキスト抽出が別の仕組みで動作する。

そのため、Acrobat等で画面上は正しく表示されていても、コピー＆ペースト時にUnicodeへの対応付けが失敗し、 や別文字になる場合がある。

これは、今回のようなMJ文字・補助面漢字を含む地名情報では特に注意すべきである。

提案：GSI Plane 2 Kanji Test Set

国土地理院が公表した33文字を、GSI Plane 2 Kanji Test Set として扱い、Unicode補助面地名文字の実装試験、回帰試験、表示試験、コピー＆ペースト試験に利用する。

このテストセットは以下の点で有用である。

• 国土地理院が公表した公式な文字セットである
• 実際の地名情報に必要な文字である
• 33文字と小さく、試験セットとして扱いやすい
• BMP文字とSIP文字が混在している
• CJK統合漢字拡張B/Dを含む
• MapLibre、MVT、PDF、Word等の実装差を露出しやすい

対象33文字

列の意味は以下のとおり。

• No.: 本issue内の通し番号
• 文字: 対象漢字
• コードポイント: Unicodeコードポイント
• ブロック: Unicodeブロック
• 面: BMPまたはSIP
• UTF-16サロゲートペア: UTF-16でサロゲートペアが必要か
• JIS X 0213: 国土地理院公表資料に記載された値
• MJ番号: 文字情報基盤のMJ番号
• IVS: 国土地理院公表資料では未指定

No.	文字	コードポイント	ブロック	面	UTF-16サロゲートペア	JIS X 0213	MJ番号	IVS
1	坉	U+5749	CJK Unified Ideographs	BMP	不要	-----	MJ008938	未指定
2	弰	U+5F30	CJK Unified Ideographs	BMP	不要	-----	MJ011189	未指定
3	椧	U+6927	CJK Unified Ideographs	BMP	不要	-----	MJ014145	未指定
4	蔻	U+853B	CJK Unified Ideographs	BMP	不要	-----	MJ058504	未指定
5	𦭲	U+26B72	CJK Unified Ideographs Extension B	SIP	必要	-----	MJ046358	未指定
6	𫞈	U+2B788	CJK Unified Ideographs Extension D	SIP	必要	-----	MJ057710	未指定
7	𫟰	U+2B7F0	CJK Unified Ideographs Extension D	SIP	必要	-----	MJ058910	未指定
8	𫞋	U+2B78B	CJK Unified Ideographs Extension D	SIP	必要	-----	MJ014410	未指定
9	𣖾	U+235BE	CJK Unified Ideographs Extension B	SIP	必要	-----	MJ038168	未指定
10	𠏹	U+203F9	CJK Unified Ideographs Extension B	SIP	必要	2-03-02	MJ030848	未指定
11	𡈽	U+2123D	CJK Unified Ideographs Extension B	SIP	必要	1-15-34	MJ032932	未指定
12	𡋽	U+212FD	CJK Unified Ideographs Extension B	SIP	必要	2-04-82	MJ033033	未指定
13	𡶒	U+21D92	CJK Unified Ideographs Extension B	SIP	必要	2-08-37	MJ034538	未指定
14	𡸴	U+21E34	CJK Unified Ideographs Extension B	SIP	必要	1-47-78	MJ034640	未指定
15	𣇃	U+231C3	CJK Unified Ideographs Extension B	SIP	必要	2-13-93	MJ037700	未指定
16	𣕚	U+2355A	CJK Unified Ideographs Extension B	SIP	必要	2-14-88	MJ038132	未指定
17	𣘹	U+23639	CJK Unified Ideographs Extension B	SIP	必要	2-15-31	MJ038224	未指定
18	𣜿	U+2373F	CJK Unified Ideographs Extension B	SIP	必要	1-86-09	MJ038332	未指定
19	𣷓	U+23DD3	CJK Unified Ideographs Extension B	SIP	必要	2-78-64	MJ039381	未指定
20	𥔎	U+2550E	CJK Unified Ideographs Extension B	SIP	必要	1-89-09	MJ042849	未指定
21	𥧄	U+259C4	CJK Unified Ideographs Extension B	SIP	必要	1-89-52	MJ043488	未指定
22	𥹖	U+25E56	CJK Unified Ideographs Extension B	SIP	必要	2-83-84	MJ044210	未指定
23	𦙾	U+2667E	CJK Unified Ideographs Extension B	SIP	必要	2-85-21	MJ045521	未指定
24	𦫿	U+26AFF	CJK Unified Ideographs Extension B	SIP	必要	1-90-61	MJ046282	未指定
25	𧃄	U+270F4	CJK Unified Ideographs Extension B	SIP	必要	1-91-41	MJ047259	未指定
26	𧦅	U+27985	CJK Unified Ideographs Extension B	SIP	必要	2-88-54	MJ048837	未指定
27	𩗏	U+295CF	CJK Unified Ideographs Extension B	SIP	必要	2-92-34	MJ053729	未指定
28	𩸕	U+29E15	CJK Unified Ideographs Extension B	SIP	必要	2-93-57	MJ055201	未指定
29	𪀕	U+2A02F	CJK Unified Ideographs Extension B	SIP	必要	2-94-09	MJ055513	未指定
30	𩹉	U+29E49	CJK Unified Ideographs Extension B	SIP	必要	2-93-61	MJ055230	未指定
31	𨺉	U+28E89	CJK Unified Ideographs Extension B	SIP	必要	2-91-69	MJ052363	未指定
32	𨸶	U+28E36	CJK Unified Ideographs Extension B	SIP	必要	2-91-65	MJ052313	未指定
33	𡵅	U+21D45	CJK Unified Ideographs Extension B	SIP	必要	2-08-24	MJ034487	未指定

初期観察

33文字の内訳は以下のとおりである。

• BMP内の文字: 4文字
• SIP内の文字: 29文字
• CJK統合漢字拡張B: 26文字
• CJK統合漢字拡張D: 3文字
• UTF-16でサロゲートペアが必要な文字: 29文字
• MJ番号が付与されている文字: 33文字
• IVSが国土地理院公表資料で明示されている文字: 0文字

したがって、今回の追加対象の約88%はBMP外の文字である。

これは「日本語フォントのカバレッジ」の問題であると同時に、「Unicode補助面の地名文字を地理空間情報処理の全経路で扱えるか」という問題である。

推奨する試験シナリオ

A. データ保持試験

以下の経路で、各文字が U+FFFD にならず、同一コードポイントとして維持されることを確認する。

UTF-8原データ
→ JSON / GeoJSON
→ データベース
→ ベクトルタイル生成
→ MVT / PBF
→ クライアント側デコード
→ MapLibre text-field

期待結果:

• 元のUnicodeコードポイントが維持される
• U+FFFD に置換されない
• 代替漢字に変換されない
• 文字が脱落しない

B. MapLibre表示試験：ローカルフォント経路

glyphs を指定しないスタイルで、ローカルフォントによる表示を試験する。

例:

{
  "version": 8,
  "sources": {
    "test": {
      "type": "geojson",
      "data": {
        "type": "FeatureCollection",
        "features": []
      }
    }
  },
  "layers": [
    {
      "id": "gsi-plane2-labels",
      "type": "symbol",
      "source": "test",
      "layout": {
        "text-field": ["get", "name"],
        "text-size": 16
      }
    }
  ]
}

確認事項:

• glyphs 省略時に全33文字を表示できるか
• OS別・ブラウザ別に差があるか
• 標準フォントのみで表示できるか
• IPAmj明朝等を追加した場合に改善するか
• 表示不能時に □ になるか、空白になるか、 になるか

C. MapLibre表示試験：glyph PBF経路

glyphs を明示的に指定したスタイルで試験する。

確認事項:

• glyphサーバが U+FFFF を超える範囲のPBFを生成できるか
• glyph生成ツールがCJK統合漢字拡張B/Dに対応しているか
• 使用フォントが対象文字のグリフを持っているか
• MapLibreが必要な {range} を正しく要求するか
• 欠落時の表示が □、空白、 のどれになるか

想定されるリスク:

• glyphサーバや生成ツールがBMP中心にしか検証されていない
• フォントには字形があっても、glyph PBF生成経路で落ちる
• 文字列データは維持されているが表示のみ失敗する

D. コピー＆ペースト試験

各文字について、以下の経路を試験する。

MapLibreラベル
→ ブラウザ上でのコピー、またはDOM/HTML経由のコピー
→ クリップボード
→ テキストエディタ
→ コードポイント確認

確認事項:

• コピー後の文字が元のコードポイントと一致するか
• U+FFFD にならないか
• 視覚的に似た代替文字に変換されないか
• 私用領域文字に変換されないか
• 文字が脱落しないか

E. PDF試験

以下の経路を試験する。

HTML / Web地図出力
→ PDF
→ 画面表示確認
→ PDFからコピー
→ コードポイント確認

注意点:

• PDF上で見えることと、PDFからUnicodeとして正しく抽出できることは別問題である
• PDFで表示できても、コピー時に U+FFFD になる可能性がある
• この挙動は、公式資料、帳票、地図PDF等の再利用性に影響する

F. 検索・正規化試験

各文字について、以下を試験する。

データベース登録
→ 完全一致検索
→ 前方一致検索
→ 全文検索
→ ソート
→ エクスポート

確認事項:

• 完全一致検索が成立するか
• 正規化処理で別文字に変換されないか
• 代替文字検索をサポートする必要があるか
• MJ番号を補助キーとして保持すべきか
• 検索用の異体字・代替字テーブルが必要か

合格基準案

このテストセットに対する合格基準として、以下を提案する。

• 全33文字をUTF-8として保存できる
• 全33文字をJSON/GeoJSONとしてシリアライズできる
• 全33文字をMVT/PBFにエンコード・デコードできる
• 少なくとも1つの明示された表示環境で全33文字を表示できる
• データ処理経路で U+FFFD に置換されない
• 欠字・豆腐表示とデータ損失を区別して診断できる
• コピー可能な出力では、コピー後もコードポイントが維持される
• PDF出力をサポートする場合、表示とテキスト抽出の可否を別々に記録する
• 試験結果にはOS、ブラウザ、MapLibreバージョン、フォント経路、利用フォントを記録する

提案する成果物

1. テストデータ

1文字1点の小さな GeoJSON を作成する。

属性例:

{
  "no": 1,
  "char": "坉",
  "codepoint": "U+5749",
  "block": "CJK Unified Ideographs",
  "plane": "BMP",
  "surrogate_pair": false,
  "jis_x_0213": null,
  "mj": "MJ008938",
  "ivs": null
}

2. 表示試験ページ

MapLibre GL JS を用いた最小試験ページを作成する。

モード:

• glyphs を指定しないローカルフォントモード
• glyphs を指定するglyph PBFモード

ページ上に表示する情報:

• 文字
• コードポイント
• MJ番号
• 表示結果
• OS / ブラウザ
• フォント経路

3. パイプライン試験

以下の一致を確認するスクリプトまたはワークフローを作成する。

source JSONのコードポイント
= decoded vector tile attribute
= rendered label input
= copied output, where applicable

4. 結果マトリクス

環境ごとの試験結果を以下のように記録する。

環境	ローカルフォント経路	glyph PBF経路	PDF表示	PDFコピー	備考
Windows 11 / Edge	TBD	TBD	TBD	TBD
macOS / Safari	TBD	TBD	TBD	TBD
Ubuntu / Firefox	TBD	TBD	TBD	TBD
Android / Chrome	TBD	TBD	TBD	TBD
iOS / Safari	TBD	TBD	TBD	TBD

論点

1. CJKが多い地図では、glyphs を省略してローカルフォントを使う方針を推奨できるか。

2. 日本語補助面地名文字に対する既知の良好なフォントスタックを維持すべきか。

3. GSI Plane 2 Kanji Test Set を、多言語ラベル試験セットの一部にできるか。

4. 日本語地名を扱う際、MJ番号を任意メタデータとして保持すべきか。

5. 障害分類として、以下を明確に区別すべきか。

   • データ損失
   • glyph欠落
   • フォントフォールバック失敗
   • PDFテキスト抽出失敗
   • 検索・正規化失敗

6. 代替文字から本来のUnicode文字へ移行する各国地名データに対して、一般化可能なパターンとして文書化できるか。

位置づけ

これは日本の稀用漢字だけの問題ではない。

より一般化すれば、次の問題である。

国家地図作成機関等が提供する権威ある地名データは、今後ますますUnicode全域を前提とする。一方、多くのWeb地図基盤は、暗黙のうちにBMP時代の文字集合を前提に設計・試験されてきた可能性がある。

国土地理院の33文字リストは、この問題を検証するための非常に良い試験セットである。

理由は以下のとおり。

• 公式な情報源に基づく
• 実際の地名表記に必要である
• 小さく扱いやすい
• 合成的なテスト文字ではない
• BMP、拡張B、拡張Dを含む
• フォント、エンコーディング、MVT、MapLibre、PDF、コピー＆ペーストの問題を横断的に露出させる

DWG7 / UN Smart Maps にとって、このテストセットは、権威ある多言語地名データを扱うツールチェーンがUnicode補助面に対応できているかを確認する、コンパクトで実践的な回帰試験として有用である。

[hfu]

実装方針: GSI Plane 2 Kanji Test Set (#956)

スコープ

本テストセットは MapLibre GL JS を対象とした検証に限定する。issue原文が挙げた試験シナリオのうち、以下の理由により対象を絞った。

• 表示試験（B/C）: 目視確認が前提となり自動化・再現性の担保が難しいため対象外とする。フォント側の網羅性の問題として別途切り出す。
• コピペ試験（D）: MapLibreはテキストをCanvas上にラスタライズして描画するため、DOM上に選択可能なテキストが存在せず、そもそも試験として成立しない。
• PDF試験（E）: MapLibreはWebGL/Canvasレンダリングであり、PDF出力経路（印刷ライブラリ、PDF埋め込みフォント）は別スタックの話でありスコープ外。

対象とするのは以下の2つ。いずれも目視・手動操作を要さず、CIで完全に自動化できる。

• データ保持試験（A）: GeoJSON → MVT変換の往復でコードポイントが壊れないことの検証
• 検索・正規化試験（F）: NFC/NFD、異体字セレクタ有無、MJ文字番号対応などの文字列レベルでの正規化検証

フェーズと成果物

Phase 1: データ保持試験（A）

• data/gsi33.geojson — 33文字分の地物、issue記載の属性スキーマに準拠
• pipeline/encode_decode_test.js — GeoJSON → Martin/tippecanoeでMVT生成 → デコードしてコードポイント往復比較
• GitHub Actionsで自動実行し、pass/failをPRステータスに反映

Phase 2: 検索・正規化試験（F）

• 33文字に対する正規化パターン（NFC/NFD、異体字セレクタ有無、MJ文字番号との対応）を文字列レベルで比較するスクリプト
• 表示を要しない純粋な文字列処理のため完全にCIに載せられる
• pipeline/normalization_test.js

Phase 3: スコープ文書化

• SCOPE.md に対象外とした試験（B/C/D/E）とその理由を明記し、後日の再説明を不要にする

リポジトリ構成

gsi33-testset/
  data/gsi33.geojson
  pipeline/
    encode_decode_test.js
    normalization_test.js
  SCOPE.md
  .github/workflows/pipeline-test.yml

進め方

Phase 1・Phase 2・SCOPE.md を1本のPRにまとめる。CIが全て自動で通る単位としてマージでき、レビュー側の手動確認を要さない。

[hfu]

gsi33 実装計画（案）

Issue #956「GSI Plane 2 Kanji Test Set」の実装計画。**Phase 1・Phase 2・SCOPE.md を1本の PR にまとめ、CI がすべて自動で通る単位としてマージする（レビュー側の手動確認を要さない）**方針に基づく。

PR の構成

gsi33/
├── SCOPE.md                  # 本PRの範囲と除外範囲の宣言
├── data/
│   ├── gsi33.json            # 33文字マスタ（コードポイント・MJ番号等）
│   └── gsi33.geojson         # 1文字1点のテストGeoJSON
├── test/
│   ├── phase1-retention.test.mjs   # データ保持試験（シナリオA）
│   └── phase2-glyphs.test.mjs      # glyph経路試験（シナリオCの自動化可能部分）
├── expected-failures.json    # 既知の失敗を明示するxfailテーブル
└── .github/workflows/ci.yml  # GitHub Actions

Phase 1: データ保持試験（シナリオA）— 全自動

マスタ gsi33.json を単一の真実源とし、以下をコードポイント単位でアサートする。

1. UTF-8 ラウンドトリップ: ファイル read/write 後に codePointAt ベースで全33文字が一致。U+FFFD の混入をパイプライン全段で検出したら fail。
2. JSON / GeoJSON ラウンドトリップ: JSON.parse(JSON.stringify(...)) および GeoJSON バリデーション後の属性値一致。
3. MVT エンコード・デコード: @mapbox/vt-pbf + @mapbox/vector-tile で GeoJSON → MVT → デコードし、name 属性のコードポイント列が元データと完全一致。tippecanoe が CI 環境で利用可能なら同経路も追加（apt/brew 依存のためオプショナル job とし、失敗しても required check にしない）。
4. 正規化安定性: NFC / NFKC / NFD 適用後もコードポイントが不変であることを確認（シナリオFの前哨。33文字は互換分解を持たない想定であり、これ自体が回帰テストになる）。
5. サロゲートペア処理: str.length（UTF-16 code unit 数）と [...str].length(コードポイント数) の期待値をマスタに持たせ、意図しない分割・切断を検出。

実装は Node.js（node --test、依存最小）。座標は実在地名との対応付けを後続 issue に回し、本PRではダミーグリッド座標とする（SCOPE.md に明記）。

Phase 2: glyph 経路試験（シナリオC の CI 自動化可能部分）

ブラウザ表示そのものは手動確認を要するため本PRから除外し、「フォント → glyph PBF 生成 → PBF デコード」までを機械検証する。

1. フォントカバレッジ検査: IPAmj明朝（IPAフォントライセンスで再配布可、MJ 文字を網羅）を CI 内で取得し、fontTools（Python）で cmap に全33コードポイントのグリフが存在することをアサート。
2. glyph PBF 生成: SIP を扱える生成系（例: pbf_font_tools / build_pbf_glyphs。node-fontnik は U+FFFF 以下限定という既知の制約があり、それ自体を検証対象とする）で U+20000 以降のレンジ PBF を生成。
3. PBF デコード検証: 生成された {range}.pbf をデコードし、33文字それぞれの glyph id と SDF ビットマップが非空であることをアサート。
4. 既知の失敗の取り扱い: ツール側の制約で通らない項目は expected-failures.json に「ツール名・対象コードポイント・理由・追跡issue」を記録して xfail 扱いとする。これにより CI は常にグリーンでマージ可能でありつつ、失敗が暗黙に隠れない。

SCOPE.md の内容

• 本PRで扱う: シナリオA全体、シナリオCのうちヘッドレスで機械検証可能な範囲、正規化安定性（Fの一部）。
• 本PRで扱わない（後続 issue に分割）: B（OS/ブラウザ別ローカルフォント表示マトリクス）、C のブラウザ実表示、D（コピー&ペースト）、E（PDF）、F（DB検索）。いずれも人間またはブラウザ実機の確認を要するため。
• 合格基準案（issue 記載）との対応表: 「UTF-8保存」「JSON/GeoJSONシリアライズ」「MVTエンコード・デコード」「U+FFFD 非置換」は本PRのCIで担保、残りは後続。
• 試験結果に記録すべき環境情報（OS・ツールバージョン・フォント）を CI が results/report.json として自動出力する仕様。

CI 設計

GitHub Actions 1 ワークフロー。ubuntu-latest 上で Node（Phase 1）と Python + フォント取得（Phase 2）を実行し、report.json / report.md を artifact 化。required check は Phase 1 + Phase 2 の deterministic なテストのみとし、tippecanoe 等の環境依存 job は informational とする。マージ条件は「CI グリーン」のみ。

リスクと対策

• node-fontnik の BMP 制約: 検証対象そのものとして扱い、結果を expected-failures に記録（issue の論点5「障害分類」に対応する最初の実データになる）。
• フォント取得の不安定性: IPAmj明朝の URL 断絶に備え、SHA-256 検証付きダウンロード + キャッシュ。
• 正規化での意図しない変換: テスト4で常時監視。失敗時は Unicode バージョン差異を疑う診断メッセージを出す。

後続フェーズ（本PR外・参考）

Phase 3: MapLibre 実表示ページ + OS/ブラウザ結果マトリクス（手動記録）。Phase 4: コピー&ペースト / PDF 抽出試験。Phase 5: 検索・正規化の DB 試験と、代替字→本字移行パターンの一般化文書。

[hfu]

リポジトリを作りました。
https://github.com/dwg7/gsi33

[hfu]

gsi33 で一通りやるべきことはやったように思うので、クローズします。