宋本廣韻の音韻データをHDICやDHSJRにつなぐ方法(3)

宋本廣韻の音韻データをHDICやDHSJRにつなぐ方法(3)

June 28, 2026
デジタル人文学, 日本古辞書
廣韻, 音韻学, 漢字データベース, Python, 宋本廣韻, HDIC, DHSJR, KRM, データ統合, 異体字

はじめに #

前回の 宋本廣韻の音韻データをHDICやDHSJRにつなぐ方法(2)では、 gy_dhsjr_link.py--itaiji--itaiji-jsonオプションを使い、NIHU異体字対応表やKRM由来の異体字リストによって未収録字を減らす方法を解説しました。

(1)・(2)では廣韻.csvだけを音韻データのソースとしてきましたが、廣韻.csvと同じ宋本廣韻を収録した別データにsbgy.xmlがあります。sbgy.xmlの見出し漢字には、廣韻.csvにはない異体字情報(本字と書き換え字のペア)が含まれています。

本稿(3)では、廣韻.csvsbgy.xmlの見出し漢字を比較することで異体字ペアを抽出し、--itaiji-jsonオプション用のJSONファイルとして整備する方法を解説します。

廣韻.csvsbgy.xmlを比較する #

廣韻.csvsbgy.xmlは、どちらも宋本廣韻(澤存堂本)を収録したデータですが、データの作られ方が異なるため、同じ字であるはずの箇所で文字のコードポイントが食い違っている場合があります。たとえば「衆」と「眾」、「衛」と「衞」のような新字体・旧字体の違いや、同字を表す異なる字形の使い分けです。

両ファイルの字頭(見出し漢字)は、それぞれ韻の出現順・韻内の字の出現順に従って並んでいるので、出現位置を1対1で対応付けることで、コードポイントの異なる箇所をすべて抽出できます。これを行うスクリプトがcompare_guangyun_sbgy.pyです。

python3 compare_guangyun_sbgy.py

実行すると、次の2つのTSVファイルが出力されます。

  • mismatched_count_report.tsv — 韻ごとの字数が一致しない場合の一覧
  • char_mismatch_report.tsv — 字数が一致する韻の中で、同じ位置の文字が異なる場合の一覧

字数が一致しない韻があった #

最初の実行では、mismatched_count_report.tsvに蒸韻・勘韻の2件が出力されました。

韻目原貌廣韻_字数sbgy_字数
9897
5453

調べてみると、廣韻.csv側にだけ、[嬹][帎]という角括弧書きの字が1件ずつ余分に含まれていました。これらは小韻字號(小韻内の字の番号)が1a1のような特殊な形式になっている補字で、sbgy.xml側には対応するエントリがありません。

compare_guangyun_sbgy.pyでは、この小韻字號のパターンを検出して読み込み時にスキップするようにし、両ファイルの字数を一致させました。

_SUPPL_JIGO_PAT = re.compile(r'^\d+a\d+$')  # 補字の小韻字號パターン (例: 1a1)

これによりmismatched_count_report.tsvは0件となり、206の韻すべてで字数が一致した状態で、文字単位の比較に進めるようになりました。

文字の不一致を分類する #

字数が一致した状態で改めて比較すると、char_mismatch_report.tsvに951件の不一致が出力されました。これを3種類に分類しています。

分類件数内容
単純な字体差699コードポイントが異なる同字(新字体/旧字体など)
表記法の違いのみ243廣韻.csvの「本字〈異体字〉」併記表記によるもの
本字部分も不一致9本字同士も一致しない、要確認のケース

「表記法の違いのみ」というのは、廣韻.csvの字頭に本字〈異体字〉という形式(例:砅〈砯〉)で書かれているケースです。本字部分がsbgy.xml側の字と一致していれば、実質的には同じ字を指していると判断できます。

「本字部分も不一致」の9件は、本字部分すら一致しないため、機械的な判断では同字と確定できず、目視での確認が必要なケースです。

--itaiji-json用のJSONを生成する #

char_mismatch_report.tsvから、gy_dhsjr_link.py--itaiji-jsonオプションに渡せる形式のペアリストを作るスクリプトがmake_itaiji_from_compare_gy.pyです。

python3 make_itaiji_from_compare_gy.py

このスクリプトは、分類ごとに次のルールでペアを採用します。

  • 単純な字体差廣韻.csvの字頭とsbgy.xmlの字頭をそのままペアにする
  • 表記法の違いのみsbgy.xml側の本字と書き換え字(rewrite_word)をペアにする
  • 本字部分も不一致:デフォルトでは採用しない(--include-uncertainで含められる)

実行結果は次のとおりです。

出力: itaiji_gy_compare.json  (870 ペア)
  単純な字体差         : 690 ペア
  表記法の違いのみ      : 180 ペア
  本字部分も不一致      : 0 ペア
  スキップ             : 81 行

870件のペアが生成されました。スキップされた81行は、漢字1文字同士の対応関係にならないもの(後述)です。

スキップされる行について #

951件の不一致のうち870件がペア化される一方、81件はスキップされます。内訳は次の2パターンです。

  1. sbgy.xml側に書き換え字がない場合廣韻.csv側だけが「本字〈異体字〉」の情報を持っていて、sbgy.xml側にはそもそも対応する異体字情報がないケースです。ペアを作る材料がないため、スキップは妥当です。
  2. 書き換え字がIDS(部首合成記述)の場合⿱鼓釜のように、Unicodeの単一コードポイントとして存在しない字を部首の組み合わせで表現したものです。1文字対1文字の正規化マップという枠組みには収まらないため、スキップしています。

いずれも、無理にペア化すると正規化ロジックを壊しかねないケースであり、除外は意図した挙動です。

gy_dhsjr_link.pyに適用する #

生成したitaiji_gy_compare.jsonを、(2)で使ったKRM由来の異体字リストと同様に--itaiji-jsonオプションに指定して使います。

python3 gy_dhsjr_link.py \
  --dhsjr updated_30-048-02_RMK.tsv \
  --gy 廣韻.csv \
  --itaiji-json itaiji_gy_compare.json \
  --outdir ./linked_out

(2)で使用したNIHU異体字対応表・KRM由来の異体字リスト2種と合わせて、複数の--itaiji-jsonをカンマ区切りで同時に指定することもできます。

python3 gy_dhsjr_link.py \
  --dhsjr updated_30-048-02_RMK.tsv \
  --gy 廣韻.csv \
  --itaiji 異体漢字対応テーブル111220版_TSV221111.txt \
  --itaiji-json itaiji_krm_unverified_20260626.json,itaiji_krm_gy_attested.json,itaiji_gy_compare.json \
  --outdir ./linked_out

実行結果は次のとおりです。

廣韻インデックスを構築中…
  廣韻 ユニーク字数: 19585
異体字マップを構築中…
  [itaiji] NIHUテーブル読み込み: 異体漢字対応テーブル111220版_TSV221111.txt
  [itaiji] JSON読み込み: itaiji_krm_unverified_20260626.json
  [itaiji] JSON読み込み: itaiji_krm_gy_attested.json
  [itaiji] JSON読み込み: itaiji_gy_compare.json
  異体字マップ件数: 4014
処理中: 30-048-02_RMK.tsv
  → linked_out/30-048-02_RMK_gy_linked.tsv (27985 行)
  → linked_out/dhsjr_gy_unmatched.tsv (3646 行)
  → linked_out/dhsjr_gy_multi.tsv (7191 行)
完了。

sbgy.xml由来のペアは、KRM由来の異体字リストとは独立した観点(廣韻.csvとsbgy.xmlという、同じ宋本廣韻の異なる電子化データ同士の字体差)から作られているため、既存の異体字マップと重複しつつも一部は補完関係になります。実際にどれだけ未収録字が減るかは、対象とする資料の字種によって変わるため、手元のデータで件数を確認することをお勧めします。

おわりに #

本稿(3)では、廣韻.csvsbgy.xmlという、同じ宋本廣韻を収録した2つのデータソースを比較することで、--itaiji-jsonオプション用の異体字ペアリストを生成する方法を解説しました。

ポイントは次の3点です。

  • 両ファイルの字頭は出現順で1対1に対応付けられるため、位置を揃えて比較すれば不一致を網羅的に抽出できる
  • 比較の前提として、両ファイルの字数を一致させる必要がある(廣韻.csv側の補字行の扱いに注意)
  • 抽出した不一致は「単純な字体差」「表記法の違いのみ」「要確認」に分類し、機械的に判断できるものだけをペア化する

(1)(2)で扱ってきた廣韻.csv単体の照合に加えて、sbgy.xmlという別ソースを組み合わせることで、未収録字をさらに減らせる見通しが立ちました。

スクリプトは sbgy-data-tools リポジトリから入手できます。

(1)の結果は次のとおりでした。

状況行数比率
一意15,82856.6%
複数音6,52223.3%
未収録5,62820.1%

(2)の結果は次のとおりでした。

状況行数比率
一意17,02560.8%
複数音7,09225.3%
未収録3,86813.8%

(3)の結果は次のとおりでした。

状況行数比率
一意17,14861.3%
複数音7,19125.7%
未収録3,64613.0%

未収録は(1)の20.1%から、(2)では13.8%に減少、さらに(3)では13.0%まで減少させることができました。

次回(4)予告 #

近刊の加藤大鶴・石山裕慈・佐々木勇編『日本語と漢字音・漢語音 データベースが切り開く新しい世界』(アジア遊学320、勉誠社、2026年7月)では、DHSJRを活用した事例が数多く紹介されています。次回はその内容を紹介しながら、必要に応じて(1)(2)(3)に述べた内容を再検討してみましょう。