選択的夫婦別氏制度（４）

選択的夫婦別氏制度（３）からの続き

前回，ChatGPTは日本の選択的夫婦別姓制度への反対論の中の「感情論や伝統論」ではない「合理的反対論」とおぼしきものを提示してきた。さらに「“実装可能な最適解”の設計図まで具体化できます。」とのことなのでさっそくお願いする。

Ｑ（koshix）：

実装可能な最適解の設計図を下さい。

Ａ（ChatGPT-5.1）：

ここで言う「最適解」は、

・人権（氏名・アイデンティティの自由）を最大限尊重しつつ

・行政コストと現場の混乱を最小化し

・子どもや弱者へのしわ寄せを抑える

という意味での「現実的にベストに近い案」というイメージで書きます。

０．全体コンセプト

三つの役割を分離する、というのが軸です。

(1) ID（個人識別キー）

・主役：マイナンバー

・補助：生年月日等

(2) 系譜・親族関係の台帳

・主役：戸籍

・氏はここでは「ラベル」に格下げ

(3) 社会生活上の表示名（氏名）

・主役：複数の「氏」候補（旧姓・婚姻姓など）＋名

・用途ごとに「どの表示名を使うか」を選択可能

要するに、

> 「氏をIDのキーから外して、“表示属性”にしていく」

という方向にじわじわ移行する設計図です。

１．法制度改正パッケージ（最小限で効く組み合わせ）

(1) 民法（夫婦の氏に関する規定）の改正

現行：「夫婦は婚姻の際に同じ氏を定める」

→ 改正案：

a. 夫婦は

・どちらかの氏

・各自が婚姻前の氏

を選択できる（いわゆる「選択的別姓」）。

b. 子の氏については

・出生時に父母がどちらか一方の氏を原則として選択（兄弟姉妹で統一が原則）

・特別な事情がある場合のみ、家庭裁判所の許可で兄弟間異なる氏も可

ここで「子どもの氏の原則統一」を入れておくと、学校・医療・行政がだいぶ楽になります。

(2) 戸籍法（戸籍の構造）の改正

a 戸籍の基本単位を

・「一戸籍＝一氏」から

・「一戸籍＝一親族ユニット（家族ID）」に変更

b 新たに**「戸籍家族ID」**を導入

・例：F-2025-000123 のような固定ID

・同じ家族IDの戸籍構成員は、氏が違っても「同一戸籍家族」と判定できる。

c 戸籍上の各人に

・「現在の氏」

・「婚姻前の氏」

・「過去に用いた氏（履歴）」

のフィールドを持たせる（履歴管理）。

→ これで、「氏が違っても家族である」ことを戸籍上きちんと表現できます。

(3) 住民基本台帳法・マイナンバー関係の整合

a 住民票の「氏」は

・「現在使用している主たる氏（標準表示名）」を表示

・ただし裏側のデータベースには複数の氏フィールドを保持

b マイナンバーは

・氏に関係なく**不変の個人ID**

・すべての行政システムは「まずマイナンバーで紐づけ、氏は表示の問題」にする方向へ。

２．システム設計の“中身”のイメージ

(1) 行政コアDBのスキーマ（ざっくり）

1レコード（1人）につき、主要フィールドはこんな感じにします：

・person_id（＝マイナンバー）

・family_id（＝戸籍家族ID）

・given_name（名）

・legal_surname_primary（主たる氏）

・legal_surname_secondary（副氏：旧姓など）

・surname_history[]（過去の氏の配列）

・display_name_profiles[]

例：

・プロファイル1：公的文書用（legal_surname_primary + given_name）

・プロファイル2：旧姓職業用（legal_surname_secondary + given_name）

各サブシステム（税・年金・保険・教育など）は：

・内部では person_id で一意に管理

・画面・帳票出力のときだけ「どの display_name_profile を標準にするか」をポリシーで決める

という構造にしておくと、氏が変わってもIDは揺れないので事故が減ります。

３．段階的導入シナリオ（10〜15年スパン）

(1) フェーズ1（〜3年）：法改正＋新規婚姻からの先行導入

a 民法・戸籍法・住基法の改正成立。

b 新規に婚姻するカップルから

・選択的別姓を利用可能に

・旧姓の職業利用を全面的に「法定通称」として明文化。

c 行政の基幹システム（戸籍・住基）のスキーマだけ先に拡張し、

・実際のUIはまだ「従来通り」でもよい（裏側からじわじわ多氏対応に）。

・この段階では既存夫婦は原則そのまま。

「新規から始めて、世代交代とともに徐々に別姓世帯が増える」設計にすると、移行ショックが小さいです。

(2) フェーズ2（〜8年）：行政システム全体の刷新

a 国税・年金・健康保険・学校・警察・裁判所の各システムで

・person_id（マイナンバー）を主キーにするリファクタリングを実施。

・氏をキーにしている古いロジックを順次撤去。

b 災害対応・避難所名簿・医療現場の本人確認について

・「マイナンバー＋顔写真＋家族ID」を組み合わせた運用ガイドラインを整備。

c 学校について

・名簿上は「氏名＋家族IDマーク」

・兄弟姉妹は原則同じ氏、例外は学校の配慮義務を明文化。

ここで 行政内部はほぼ“個人ID国家”に近い状態になります。

(3) フェーズ3（〜15年）：民間システムの移行完了

a 銀行・証券・保険・クレジットカードなどに対し

・氏変更＋別姓対応のガイドラインと移行期限を提示。

・中小企業向けにクラウド人事・給与ソフトの標準パッケージを無償〜低額提供。

b パスポート・運転免許証などの公的IDカードで

・「主たる氏」＋「旧姓（括弧書き）」併記を標準に。

c 15年程度かけて、「氏変更に伴う実務トラブル」が徐々に減っていく状態を目指す。

４．子ども・弱者への配慮設計

・子どもの氏は原則「兄弟姉妹で統一」。

・例外（虐待・DV・離婚など）の場合には

　家裁・児相の判断で、子ども側の安全を最優先に変更可。

学校・医療現場では

・氏名だけで家族関係を判断せず

・「家族ID・保護者情報」ベースで管理する運用に切り替え。

これにより、

・「親子別姓＝いじめ」という単純構図ではなく

・「どんな氏でも、学校・医療・福祉がちゃんと対応できる体制」

を制度と運用で保証します。

５．コストと混乱を抑える工夫

(1) ビッグバン方式はやらない。

・「YYYY年X月から一斉に全システム切り替え」は地獄なので避ける。

(2) すでに老朽化している基幹システムの更新タイミングに合わせて

・「どうせ作り直すなら、多氏対応スキーマで」という方針で順次更新。

(3) 民間向けには

・中小企業向けの標準クラウドソフトを国主導で整備し、

・そこに載りさえすれば別姓対応できるようにしておく。

要は、

> 「別姓対応のためだけに何兆円もドカンと新規投資する」のではなく、

> 「どうせ必要な更新のついでに“個人ID前提＋多氏対応”に寄せていく」

という発想にすると、費用対効果が良くなります。

６．この設計案のポイント（メリット・デメリット）

(1) メリット

・氏をIDキーから外すので、

・以後の氏変更トラブルが激減

・別姓導入後も運用事故を最小限にできる

・子どもの氏は原則統一＋例外は家裁判断で、

　現場の混乱と子どもへのしわ寄せを防ぎやすい

・導入は新規婚姻から始めるので、

　「一夜で社会が変わる」ショックがない

(2) 正直に言う部分

・マイナンバー前提社会をかなり推し進めることになる（プライバシー懸念はセットで議論が必要）

・完了まで10〜15年スパンの長期プロジェクトになる

・「戸籍の意味」を、これまでの感覚からかなり組み替えることになる（政治的には重い）

７．まとめ

この設計図は、ざっくり言えば：

> 1. 氏を「家族のキー」から「個人の表示属性」に降格させる

> 2. 本当のキーはマイナンバー＋家族IDにする

> 3. 新規婚姻から静かに始め、15年くらいかけて日本社会を“個人ID前提”にシフトさせる

という筋道です。

（以下略）

なるほどね。しかし，どうみても10〜15年は長すぎだと思う。行政機関も国会議員もこのくらいのリサーチはしているはずだろうけれど・・・。