LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

業務システムで氏名のカナは、長らく「補助的な項目」として扱われてきました。五十音で並べるため、電話口で聞き取った読みを残すため、振込データに載せるため——用途はいろいろですが、正しさを公に確かめる手段はありませんでした。

その位置づけが変わりました。戸籍法の改正により、令和7年5月26日から戸籍に氏名のフリガナが記載されることになりました*1。フリガナが戸籍の記載事項になったということは、公に証明できるカナが存在する状態になったということです。

本記事では、氏名を扱う業務システムの担当者と、その改修を受託する立場に向けて、制度の流れ、システム側で点検すべき箇所、移行の進め方を整理します。制度の解釈が要る部分は最新の公式資料で確かめながら進めてください。

制度の流れ——通知、届出、そして順次記載

すでに戸籍に記載されている人については、市区町村長からの通知を起点に手続が進みます。法務省の資料では、次の流れが示されています*1。

まず、改正法の施行日である令和7年5月26日から順次、住民票の住所に「戸籍に記載予定の氏名のフリガナ」の通知が送付されます*1。

通知の内容が正しければ、届出は不要です。令和8年5月26日以降、通知されたフリガナが順次戸籍に記載されます。早く記載してほしい場合は、届出をすることもできます*1。

通知の内容が誤っていれば、届出が必要です。届出の期限は施行日から1年以内、つまり令和8年5月25日までとされています*1。

期限までに届出をしなかった場合は、通知されたフリガナが記載されます。ただし、その場合は1回に限り、家庭裁判所の許可を得ることなく届出のみで変更できるという取扱いが用意されています*2。届出をして記載された後に変更したい場合は、氏については「やむを得ない事由」、名については「正当な事由」があるとして家庭裁判所の許可が必要になります*2。

もう一点、届出人の範囲にも違いがあります。名のフリガナは各人が届出できますが、氏のフリガナは原則として戸籍の筆頭者が届出することとされています*2。家族単位で氏のフリガナが決まる構造です。

読み方の基準——「一般に認められている」という枠

戸籍に記載できるフリガナには基準があります。氏名として用いられる文字の読み方として、一般に認められているものでなければならないとされています*2。

認められない例として、漢字の意味と関係のない読み方、別の単語を付け加える読み方、反対の意味になる読み方が挙げられています*2。読み方の自由度に一定の枠がかかっているということです。

ただし、すでに戸籍に記載されている人については例外の道が用意されています。通知と異なる読み方が通用している場合、それを証する書面——パスポート、預貯金通帳、健康保険証といったものを提出して届出できるとされています*2。

ここは業務システムの担当者にとって示唆があります。自社が管理しているカナが、その人の「通用している読み方を証する書面」の一つになりうるという点です。金融機関の通帳、保険証、契約書。こうした書類に記載されたカナが、届出の根拠として使われる場面がありえます。

つまり、自社システムのカナが正確であることの意味が、これまでより重くなります。入力時のチェックが甘く、誤ったカナが登録されたままになっていると、それが本人の届出の妨げになる、あるいは誤った読みを裏づける材料になってしまう。データ品質の話が、単なる社内の都合を超えてきます。

システム側で点検する四つの箇所

制度の内容を踏まえて、業務システム側で見直すべき箇所を整理します。

カナ項目の定義です。古い設計では、半角カタカナで15桁といった制約が残っていることがあります。金融機関向けの形式に合わせた名残です。姓と名を一つの項目に詰め込んでいる場合、分割が必要になるかもしれません。

文字コードの扱いも確かめておきたい部分です。半角と全角が混在している、濁点が分離した形で入っている、環境によって表示が崩れる——こうした状態は、カナを突き合わせる処理で誤判定を生みます。文字コードと文字化けの整理で扱うような観点で、まず現状を把握します。

入力チェックです。漢字を入力するとカナが自動で埋まる仕組みは便利ですが、変換候補の読みがそのまま登録され、本人の読みと違うまま使われていることがあります。自動補完は初期値として提示するにとどめ、本人に確認する導線を入れる。この見直しは、制度とは別に品質の話として意味があります。

変更への追随です。ここが今回の制度でいちばん効いてくる部分です。令和8年5月26日以降、フリガナが戸籍に記載され、その後1回に限り届出だけで変更できる人が出てきます*2。つまり、カナが変わる人が一定数現れます。

カナを上書きで更新している設計だと、いつ何から何へ変わったのかが残りません。適用日つきで履歴を持つ形にしておくと、過去の帳票や取引の照合ができます。マスタデータ管理で扱うような、変更を前提とした持ち方が求められます。

突合・名寄せです。カナを一致判定の材料に使っている処理があるなら、洗い出しておく必要があります。同姓同名の区別、重複登録の検出、外部データとの照合。カナが変わると、これらの結果が変わる可能性があります。データ品質の監視で扱うような仕組みがあれば、変化を早く捉えられます。

帳票・外部連携です。自社で桁数を広げても、連携先が受け取れなければ意味がありません。送り先の項目定義を確かめ、切り詰めが起きる場合の扱いを決めておきます。

業種による影響の重さ

影響の大きさは、氏名をどう使っているかで変わります。整理しておきます。

本人確認を伴う業務です。金融、保険、通信、不動産。公的書類の記載と自社のデータを突き合わせる場面があるため、カナの正しさが手続の通り方に直結します。本人確認の仕組みを持っている場合、オンラインでの本人確認で扱うような照合のロジックに、カナの変更が影響しうることを見ておきます。

顧客情報を長期に保つ業務です。会員制のサービス、保守契約、定期購入。過去の記録とのつながりを保つ必要があるため、カナが変わったときに履歴が追えるかが問われます。顧客データの統合で扱うような基盤を持っている場合、統合キーの見直しが必要になるかもしれません。

公的な手続を代行する業務です。社会保険の手続、税の申告、各種の届出。提出先が求める様式にカナ項目があるなら、その定義に合わせる必要があります。制度の施行に合わせて様式が変わることもあるため、様式を設定として持てる形が望ましいでしょう。

影響が小さい業務です。社内向けのシステムで、カナを並び順にだけ使っている場合。この場合は急いで手を入れる必要はありません。ただし、人事系のシステムで公的手続に連携している部分があれば、そこだけは確かめておきます。

自社がどこに当たるかを見極めるには、「カナがどの処理で使われているか」を洗い出すのが早道です。表示、並び順、検索、突合、外部連携。この五つのどこに使われているかで、影響の重さが決まります。

移行と是正の進め方

実際に手を入れるとして、どう進めるか。順序を整理します。

第一に、現状のデータを測ることです。カナ項目に何が入っているかを集計します。半角と全角の比率、桁数の分布、記号や空白の混入、空欄の件数。この測定なしに改修範囲を決めると、後から想定外の値が出てきます。

第二に、項目定義を決めることです。文字種、桁数、姓名の分割。将来の連携も見据えて決めます。ここで広めに取っておくと、後の変更が減ります。

第三に、履歴を持てる形に変えることです。カナの値を適用日つきで保持し、変更の理由も記録できるようにします。今回の制度による変更なのか、誤りの訂正なのか、婚姻等による変更なのか——区別できると運用が楽になります。

第四に、既存データの移行です。半角から全角へ、一体項目から分割へ。変換の規則を決め、変換できない値を洗い出して個別に対応します。データ移行で扱うような、変換規則の設計と検証の進め方がそのまま当てはまります。

第五に、運用の手順を作ることです。顧客からカナの変更を申し出られたとき、誰がどう更新するのか。証明書類の確認は要るのか。窓口の担当者が判断できる手順にしておかないと、現場で止まります。

なお、全件を一度に直す必要はありません。カナが実際に使われている処理から順に、必要な範囲を直していく進め方が現実的です。制度上、記載が進むのは令和8年5月26日以降ですから、影響が表面化する時期を見据えて段取りを組めます。

受託・委託で進めるときの要点

この種の是正を外部と進める場合の要点を挙げます。

第一に、影響調査を独立した工程にすることです。カナがどこで使われているかの洗い出しは、それ自体に工数がかかります。調査の結果によって改修範囲が変わるため、調査と実装を分けて発注する形が合理的です。

第二に、現行データの提供方法を決めることです。個人情報を含むため、そのまま渡せません。統計値だけを取る、仮名化したデータで検証する、社内で調査ツールを動かす——いずれの形にするかを最初に決めます。

第三に、連携先の確認を誰が担うかです。外部システムや提出先の項目定義を確かめる作業は、相手方との窓口が必要です。社内で担うのか、委託先に任せるのか。曖昧にすると、この確認が抜け落ちます。

第四に、テストデータの用意です。長い名前、記号を含む名前、外字を含む名前。境界にあたるパターンを作る作業を工程に入れておきます。実在の氏名を使わずに検証できる形を用意しておくのが望ましいでしょう。

第五に、制度解釈の担い手を決めることです。届出の要否や書類の扱いは、法務や総務の領域です。開発側は決まった運用を実装する役割に集中し、解釈の窓口を明確にしておきます。

体制としては、既存システムのデータ構造を読み解ける要員が入れるかが分かれ目になります。古いシステムでは、カナ項目が思わぬ場所で使われていることがあります。設計書だけでなくコードとデータの両方を見られる体制を作れるかを、委託先を選ぶ観点に入れておくとよいでしょう。

まとめ：戸籍のフリガナ記載への対応で押さえる3つの視点

戸籍法の改正により、令和7年5月26日から戸籍に氏名のフリガナが記載されることになりました。押さえたい視点は三つです。第一に、通知を受けて内容が誤っていれば令和8年5月25日までに届出、届出がなければ令和8年5月26日以降に通知のフリガナが順次記載され、その場合は1回に限り届出のみで変更できるという流れを理解しておくこと。第二に、業務システムの側では「カナは変わらない」という暗黙の前提が崩れるため、カナ項目の文字種と桁数、適用日つきの変更履歴、名寄せや突合でカナに依存している処理——この三点を先に点検する必要があること。第三に、自社が保持するカナが本人の届出を裏づける書類になりうるため、入力時のチェックとデータ品質の意味がこれまでより重くなることです。まずはカナ項目に何が入っているかを集計し、カナがどの処理で使われているかを洗い出すところから着手するのが堅実でしょう。

よくある質問

出典

1. *1　参考：法務省「フリガナが記載されるまで」（https://www.moj.go.jp/MINJI/furigana/flow.html）。施行日、通知の送付、届出の期限、届出がない場合の順次記載という流れの一次情報として（2026年8月確認）
2. *2　参考：法務省「戸籍にフリガナが記載されます よくあるご質問」（https://www.moj.go.jp/MINJI/furigana/faq.html）。読み方の基準と認められない例、通用している読み方を証する書面、届出人の範囲、記載後の変更手続の確認として（2026年8月確認）

Tweet