https://www.soumu.go.jp/main_sosiki/kenkyu/jichitaishisutemu_hyojunka/02gyosei04_04000127_00014.html
資料２
戸籍附票システム標準仕様書（案）
【第1.０版】
令和４年（2022年）XX月XX日
自治体システム等標準化検討会
（住民記録システム等標準化検討会）
凡例
実務上は、住民・職員への分かりやすさ等の観点から、法令用語でない用語が用いられることがあるが、本仕様書の機能要件の記載上は、原則として法令用語を用いている。
なお、機能要件の構成は、必ずしも本仕様書のとおりとしなければならないことを意味するものではなく、本仕様書に従う限り、実務上の使い勝手を考慮してメニューを再構成することも可能である。
住民基本台帳法（昭和42年法律第81号）····························法
住民基本台帳法施行令（昭和42年政令第292号）··················令
住民基本台帳法施行規則（平成11年自治省令第35号）············規則
戸籍法（昭和22年法律第224号）·····························戸籍法
情報通信技術の活用による行政手続等に係る関係者の利便性の向上並びに行政運営の簡素化及び効率化を図るための行政手続等における情報通信の技術の利用に関する法律等の一部を改正する法律（令和元年法律第16号）······················································デジタル手続法
地方公共団体情報システムの標準化に関する法律 （令和3年法律第40号）···········標準化法
住民基本台帳事務処理要領（昭和42年10月４日自治振第150号等自治省行政局長等から各都道府県知事あて通知）······················事務処理要領
住民基本台帳ネットワークシステム····················住基ネット
コミュニケーションサーバー··································CS
住民基本台帳ネットワークシステムシステム構築手引書戸籍附票システム改造仕様書（第0.5版）（令和3 年5 月）·········戸籍附票システム改造仕様書
目次
第１章本仕様書について……………………..8
背景…………………..9
２．目的………………………11
３．対象……………….15
４．本仕様書の内容……………..17
第２章標準化の対象範囲………………..21
標準化の対象範囲………………………22
第３章機能要件…………………..23
1管理項目…………………………..24
1.1戸籍の附票データ…………………25
1.2異動履歴データ………………………..39
1.3その他の管理項目…………………42
2検索・照会・操作………………..45
2.1検索……………………….46
2.2照会…………………………….49
2.3操作………………………..51
3抑止設定…………………………….52
4異動……………………………………56
4.1職権……………………………..60
4.2異動の取消し…………………..63
5証明…………………………64
6統計69
7連携………………………………………71
7.1CS連携………………………..72
7.2 庁内他業務連携……………………….74
8実装してもしなくても良い機能 ……………………….76
8.1 本人通知…………………………………..77
9 バッチ…………………………79
10 共通………………………82
11 エラー・アラート項目……………….91
第４章様式・帳票要件………………104
20.1 戸籍の附票の写し等……………………..113
20.2 その他………………………….136
20.3 住民基本台帳関係年報の調査様式………………….142
第５章データ要件……………….143
第６章非機能要件……………………..145
第７章用語…………………….147
別紙１業務フロー
別紙２ツリー図4 / 161
目次（詳細）
凡例…………………………1
第１章本仕様書について…………………………8
１．背景…………………………..9
２．目的…………………………11
（１）目指す姿…………………………..11
（２）本仕様書の目的…………………………12
３．対象………………………….15
（１）対象自治体…………………………15
（２）対象分野……………………………..15
（３）対象項目…………………15
デジタル社会を見据えた対応………………….16
４．本仕様書の内容……………………..17
（１）本仕様書の構成……………………….17
（２）標準準拠の基準………………………17
（３）想定する利用方法…………………..18
（４）本仕様書の改定……………………..18
各自治体の調達仕様書の範囲との関係…………..19
第２章標準化の対象範囲……………………..21
標準化の対象範囲………………………22
第３章機能要件………………………….23
1管理項目……………………………24
1.1戸籍の附票データ……………………25
1.1.1戸籍の附票データの管理………………………………..25
1.1.2改製………………………………………………..27
1.1.3戸籍の附票の除票の管理………………………………..28
1.1.4改製不適合戸籍の附票の管理…………………………….29
1.1.5空欄………………………………………………..30
1.1.6年月日の管理…………………………………………31
1.1.7年月日の表示…………………………………………32
1.1.8在外選挙人名簿及び在外投票人名簿登録市区町村名…………..32
1.1.9本籍・筆頭者…………………………………………33
1.1.10戸籍附票宛名番号、附票番号……………………………33
1.1.11備考……………………………………………….34
1.1.12メモ……………………………………………….35
1.1.13支援対象者管理………………………………………35
1.1.14郵便番号……………………………………………38
1.1.15フリガナ……………………………………………38
1.2異動履歴データ…………………….39
1.2.1異動履歴の管理……………………………………….39
1.2.2異動事由…………………………………………….39
1.3その他の管理項目…………………….42
1.3.1入力場所・入力端末……………………………………42
1.3.2住所辞書管理…………………………………………42
1.3.3和暦・西暦管理……………………………………….43
1.3.4公印管理…………………………………………….43
1.3.5交付履歴の管理……………………………………….43
1.3.6認証者………………………………………………44
2検索・照会・操作…………………….45
2.1検索…………………………………46
2.1.1検索機能…………………………………………….46
2.1.2検索文字入力…………………………………………46
2.1.3基本検索…………………………………………….47
2.2照会……………………….49
2.2.1異動履歴照会…………………………………………49
2.2.2交付履歴照会…………………………………………49
2.2.3文字コード照会等……………………………………..49
2.2.4支援対象者照会……………………………………….50
2.3操作………………………………51
2.3.1キーボードのみの画面操作………………………………51
3抑止設定……………………………..52
3.1異動・発行・照会抑止……………………………………53
3.2支援措置………………………………………………53
異動………………………..56
4.0.1異動者………………………………………………57
4.0.2異動日・処理日……………………………………….57
4.0.3審査・決裁…………………………………………..58
4.0.4入力確認・修正……………………………………….59
4.0.5一括入力…………………………………………….59
4.1職権………………………..60
4.1.1戸籍届出等に基づく戸籍の附票の職権記載等………………..60
4.1.2在外選挙人名簿及び在外投票人名簿登録市区町村の異動……….60
4.1.3CSから受信した戸籍の附票記載事項通知及び本籍転属通知の取込..61
4.1.4 誤記修正 …………………………………………….62
4.2異動の取消し………………………..63
4.2.1異動の取消し……………………….63
5証明…………………………………………….64
5.1証明書記載事項…………………………………………65
5.2同一の戸籍の附票の者の並び順…………………………….66
5.3方書の記載…………………………………………….66
5.4発行番号………………………………………………67
5.5公印・職名の印字……………………………………….67
5.6公用表示………………………………………………68
5.7文字溢れ対応………………………………………….69
6.1統計………………………………………………….70
7連携…………………………71
7.1CS連携…………………………72
7.1.1CSへの自動送信……………………………………….72
7.1.2附票本人確認情報との整合性確認…………………………73
7.2 庁内他業務連携…………………………74
7.2.1住民記録システムとの連携……………………74
7.2.2個人番号カードによる証明書等の交付……………………..74
8実装してもしなくても良い機能 …………….76
8.1 本人通知……………………………………77
8.1.1登録管理…………………………………………….77
8.1.2画面表示…………………………………………….77
8.1.3通知書出力…………………………………………..77
9 バッチ………………………………….79
9.1バッチ処理………………………………..80
9.2抑止対象者…………………………………………….81
共通…………………………………………82
10.1EUC機能ほか…………………………………………..83
10.2アクセスログ管理………………………………………85
10.3操作権限管理………………………………………….87
10.4操作権限設定………………………………………….88
10.5ヘルプ機能……………………………………….88
10.6中間標準レイアウト仕様での出力………………………….89
10.7印刷…………………………………………………89
10.8CSV形式のデータの取込(P)……………………………….90
11 エラー・アラート項目………………………..91
11.1エラー・アラート項目………………………….92
第４章様式・帳票要件…………………………104
20.0.1様式・帳票全般……………………………………..105
20.0.2各項目の記載……………………………………….106
20.0.3備考欄（異動履歴）の記載…………………………….107
20.0.4備考欄（異動履歴）の記載の修正……………………….110
20.0.5備考欄（編製年月日等）の記載…………………………111
20.0.6備考欄（その他）の記載………………………………111
20.1 戸籍の附票の写し等………………………..113
20.1.1戸籍の附票の写し…………………….113
20.1.2戸籍の附票の除票の写し……………………125
20.2 その他………………………….136
20.2.1支援措置期間終了通知………………………………..136
20.2.2在外選挙人名簿及び在外投票人名簿登録者の戸籍又は戸籍の附票の変更通知書137
20.3 住民基本台帳関係年報の調査様式………………142
20.3.1住民基本台帳関係年報の調査様式第４表及び第５表…………142
第５章データ要件…………………………………..143
30.1データ構造…………………………….144
30.2文字(P)……………………………….144
第６章非機能要件…………………………145
第７章用語……………………………………..147
別紙１業務フロー
別紙２ツリー図
第１章本仕様書について
１．背景
自治体の情報システムは、これまで各自治体が独自に構築・発展させてきた結果、その発注・維持管理や制度改正対応などについて各自治体が個別に対応しており、人的・財政的負担が生じている。特に人口規模が一定以上の自治体を中心に、同一ベンダのシステムを利用する自治体間でもシステムの内容が異なることが多く、クラウド上のサービスを利用する方式への移行の妨げとなっている。さらに、自治体ごとに様式・帳票が異なる ことが、それを作成・利用する住民・企業・自治体等の負担に繋がっている。
また、中長期的な人口構造の変化に対応した自治体行政に変革していくためにも、自治体の情報システムに係る重複投資をなくして標準化・共同化を推進し、自治体行政のデジタル化に向けた基盤を整備していく必要がある。
そうした問題意識から、自治体行政のデジタル化に向け、自治体の情報システムや様式・帳票の標準化等について、自治体、ベンダ及び国が協力して具体的な検討を行う場として、令和元年（2019年）８月から、総務省において、自治体システム等標準化検討会（座長：庄司昌彦武蔵大学社会学部教授）が開催され、更に詳細な議論を行う場として分科会（分科会長：後藤省二株式会社地域情報化研究所代表取締役社長）が開催されている。
令和２年９月11日に住民記録システム標準仕様書【第1.0版】が公表されて以降、デジタル・ガバメント閣僚会議の下で開催された「マイナンバー制度及び国と地方のデジタル基盤抜本改善ワーキンググループ」における議論も踏まえ、令和２年12月25日の「デジタル・ガバメント実行計画」では、地方公共団体の主要な17業務について、システムの標準仕様を作成すること、地方公共団体の情報システムの標準化・共通化を実効的に推進するための法律案を令和３年通常国会に提出すること、標準化の目標時期を令和７年度とすることなどが閣議決定された。このことを受けて、第204回通常国会では、標準化法が可決成立 した。
また、令和３年12月24日に閣議決定された「デジタル社会の実現に向けた重点計画」では、基幹業務システムを利用する原則全ての地方公共団体が、目標時期である令和７年度（2025年度）までに、ガバメントクラウド上に構築された標準化基準に適合した基幹業務システムへ移行する統一・標準化を目指す こととされた。標準化対象事務は、標準化法の趣旨を踏まえ、情報システムによる処理の内容が地方公共団体において共通しているかという観点等から、累次の閣議決定において示されてきた17業務に、印鑑登録及び戸籍、戸籍の附票事務の3業務を加えることとされた。また、戸籍の附票は、住民票と戸籍の情報をつなぎ合わせ、もって住民票の記載の正確性を担保する機能を果たす とともに、在外選挙人名簿への登録等の選挙事務に伴う公証事項のほか、デジタル手続法による改正後の法では、住民票コードなどが戸籍の附票の記載事項に追加され、国外転出者の本人確認情報の公証を担う こととなり、市区町村間の情報連携手法がデジタル化されることから、このことを前提とした機能の整備を進める必要がある。こうしたことを踏まえ、戸籍附票システム標準仕様書（以下「本仕様書」という。）は、戸籍の附票を規定する法及び事務処理要領を基礎にしつつ、「住民記録システム標準仕様書（第2.0版）」を参考に、策定されたものである。
２．目的
（１）目指す姿
本仕様書が目指す姿は、「複数のベンダがガバメントクラウド上でシステムのアプリケーションサービスを提供し、各自治体は、原則としてカスタマイズせずに利用し、ほとんど発注・維持管理や制度改正対応の負担なく、業務を行える姿」
とする。
〔各主体にとってのシステム標準化のメリット〕
〇住民・企業等のサービス利用者
自治体に対して異なる手続で実施していた申請等が統一的に実施可能となり、手続の簡素化や合理化を実現する。
○自治体
限られた人材や専門的な知識・ノウハウを共有することで、自治体のシステム調達や法令改正対応等の業務及び調整に係るコストが減少 し、本来自治体職員が行うべき業務に人材を充当できるようになる。また、財政面においては、カスタマイズの抑制、システムの共同化による割り勘効果を生むことで、導入・維持管理の費用や法令改正時の費用を削減 する。
○ベンダ
個別のカスタマイズ要望が減ることにより、個別自治体との調整やカスタマイズのためのプログラミングの負担が減少し、人口減少下で稀少化するシステムエンジニアの人員をAI・RPA等の攻めの分野に投入し、創意工夫により競争することが可能となる。
さらに、各主体のメリットのみならず、国・国民全体として、事務の迅速化・正確性の向上や、データ利活用の促進等のメリットがある。
（２）本仕様書の目的
我が国の自治体が中長期的な人口構造の変化に直面する中にあっても、住民サービスを維持・向上させ続けるためには、クラウド化等を通じた自治体の職員負担の削減、ベンダの負担の削減やベンダ間での円滑なシステム更改等を通じた自治体の財政負担の削減を進める必要がある。また、デジタル社会において実現・普及する技術を取り入れることで、自治体は、デジタル社会に対応した住民サービスを提供することが求められる。
それを実現する手段として、システムの標準化を進めることとし、その基礎となる標準仕様書の作成を通じて、以下の３つの目的を実現する。
（目的１）カスタマイズを原則不要 にする
今あるカスタマイズの中で、普遍的に有用性が認められるものは標準的に実装すべき機能として標準仕様書に盛り込み、そうでないものは実装しない機能とすることで、「人口規模が大きな団体でも、標準準拠パッケージであればカスタマイズなしで支障なく業務が行える」ようにして、カスタマイズを原則不要にする。
（目的２）ベンダ間での円滑なシステム更改 を可能にする
ベンダ間共通の標準装備すべき機能やデータの標準等を定めることで、ベンダ移行時の円滑なシステム更改を可能にする。
（目的３）自治体行政のデジタル化に向けた基盤整備 を行う
デジタル社会に必要な機能のうち現段階で普遍的に有用性が認められるものを搭載することで、自治体行政のデジタル化に向けた基盤整備を行う。
具体的には、目的１（カスタマイズを原則不要にする）に関して、現時点で実装されているカスタマイズのうち、標準的に実装すべき機能と実装しない機能の仕分けを行うことにより、
・カスタマイズについての自治体内、自治体間、自治体・ベンダ間の調整コストの削減、導入・維持管理や制度改正時の負担（重複投資）の削減
・自治体間の調整コストの削減による、自治体間のシステム共同化の円滑化
・カスタマイズについてのシステムエンジニアのプログラミングの負担の削減
を、目的２（ベンダ間での円滑なシステム更改を可能にする）に関して、異なるベンダ間において、データの標準や、標準装備すべき機能を定めることにより、
・ベンダが異なる自治体間も含めたクラウド化
・ベンダロックインの防止による健全な競争の促進
を、目的３（自治体行政のデジタル化に向けた基盤整備を行う）に関して、デジタル社会に必要な機能を搭載することにより、
・住民の利便性向上
・自治体のデータ入力の負担の削減
を目指している。
今あるカスタマイズのうち標準仕様書に盛り込む機能と盛り込まない機能を仕分け異なるベンダ間において、データ移行における移行ファイルの標準や、標準装備すべき機能を設定
カスタマイズについての自治体内、自治体間、自治体・ベンダ間の調整コストの削減
調達時、制度改正時の負担（重複投資）を削減
自治体間の調整コストを削減し、自治体間のシステム共同化が容易に
カスタマイズについてのSEのプログラミングの負担の削減
自治体・ベンダ間の調整コストの削減
ベンダロックインを防ぎ、健全な競争を促進
サーバの構築・維持管理負担の削減
調達時、制度改正時の負担（重複投資）を削減
自治体・ベンダ間の調整コストの削減
ベンダから見たシステムの原価を削減
時間外勤務等の削減
マイナンバーカードの活用やデータ利活用等の、デジタル社会に必要な機能を搭載
紙媒体の申請書をシステムに入力する作業が不要に
各自治体がデジタル社会に必要な機能について個別にベンダと協議することが不要に
住民サービスの向上のために人材を集中
住民サービスの向上のために財源を集中
住民の利便性向上
スケールメリットを生かしたハードウェアの導入・維持費用の削減
現在、ベンダが異なる自治体間でも共同クラウド化
目的２ベンダ間での円滑なシステム更改
ベンダの負担の削減
自治体の財政負担の削減
人口減少社会・デジタル社会における住民サービスの維持・向上
目的１カスタマイズを原則不要に
自治体の職員負担の削減
標準仕様書の作 成
クラウド化
目的３自治体行政のデジタル化に向けた基盤整備
３．対象
（１）対象自治体
本仕様書の対象自治体は、全ての市区町村 とする。
なお、本仕様書における「市区町村」の区とは、特別区のことであるが、法令で指定都市の区及び総合区が市と、区長及び総合区長が市長とみなされる場合は、法令と同様の扱いとする。ただし、本文中の各項目に記載のとおり、以下の区分に応じて異なる要件としているものもある。
・指定都市
・一般市区町村
また、指定都市においては、第３章機能要件の中で示す５（証明）については区を越えた処理を可能とする。
（２）対象分野
本仕様書が規定する対象分野は、地域情報プラットフォーム標準仕様における戸籍ユニットのうち戸籍附票に関連する箇所 とする。
・自治体業務アプリケーションユニット標準仕様V3.5
https://www.applic.or.jp/jigyo/jigyo-2/ict-platform/standard-2020/
なお、概ね住民基本台帳制度上の戸籍の附票事務と対応しているが、一部については本仕様書において規定していない。例えば、法第19条第１項に基づく通知のうち住基ネット回線を通じて実施する部分については、別途「戸籍附票システム改造仕様書」に基づく仕様があることから本仕様書の対象外 とする。
（３）対象項目
本仕様書では、以下の項目について規定する。
・標準化の対象範囲（第２章）
・機能要件（第３章）
・様式・帳票要件（第４章）
・データ要件（第５章）（※）
・非機能要件（第６章）
以下の項目については原則として規定しない。ただし、カスタマイズの発生源になっている場合等についてはこの限りでない。
・画面要件
・ヘルプやガイドの具体的内容等、業務遂行に必須ではなく専ら操作性に関する機能
このうち、機能要件、様式・帳票要件及び連携要件（ ※）は、カスタマイズの発生源になっている部分であるため、「２（２）本仕様書の目的」に示した目的１（カスタマイズを原則不要にする）から本仕様書の対象とすることとした。また、機能要件、データ要件及び連携要件（※）は、ベンダ間での円滑なシステム更改を阻害している部分であるため、目的２（ベンダ間での円滑なシステム更改を可能にする）から本仕様書の対象とすることとした。さらに、目的３（自治体行政のデジタル化に向けた基盤整備を行う）から、デジタル社会に必要な機能については、これらの要件の中に反映した。
※データ要件及び連携要件については、「地方自治体の業務プロセス・情報システムの標準化の作業方針の見直しについて」（旧内閣官房情報通信技術（IT）総合戦略室（以下「IT総合戦略室」という。現デジタル庁）に基づき、デジタル庁を中心に検討が行われており、その検討を踏まえ、本仕様書における記載ぶりについても見直しを行うこととする。
なお、様式・帳票要件では、戸籍附票システムを標準化するという観点から、多くの自治体において戸籍附票システムから出力する様式・帳票（例：戸籍の附票の写し）について規定することとし、多くの自治体において戸籍附票システムから出力するとは限らない様式・帳票（例：戸籍の附票の写しの請求書）については規定しないこととした。
また、非機能要件では、自治体を通じて共通して規定すべきもの（例：セキュリティ）については規定し、共通して規定すべきでないもの（例：研修）については規定しないこととした。したがって、各自治体の情報システムの調達において、本仕様書に規定されていない非機能要件を設けることを妨げるものではない。
デジタル社会を見据えた対応
本仕様書は、これからのデジタル社会においてあるべき姿（電子化・ペーパーレス化）を視野に標準を設定するとしつつも、これからのデジタル社会においてあるべき姿にそのまま即したものには必ずしもなっていない。例えば、本仕様書において、紙の証明書について規定しているが、バックヤードでのデータ連携が進めば、今後、必要性が低下していく ものと考えられる。また、データ構造や文字についても、直ちにあるべき姿に移行するとせずに、経過措置を設けている。
また、これからのデジタル社会を見据えれば、実務やシステムの前提となる制度自体を見直すべきという考え方もあり得る。しかし、そうした制度自体の検討については、一朝一夕にできるものではなく、あまりにも現在の実務から遊離した仕様書となれば、実効性が失われる。
そこで、本仕様書としては、電子化・ペーパーレス化も含め、これからのデジタル社会においてあるべき姿を視野に入れつつ、現行制度の下で、多くの自治体が支障なく対応できるものについて、できる限り盛り込むこととした。
他方、デジタル社会を見据え、様々な社会環境の変化に対応するためには、本仕様書の作成後、実務やシステムの前提となる制度を随時見直していくことが重要であり、制度の見直しとともに本仕様書を改定していくことが求められる。
４．本仕様書の内容
（１）本仕様書の構成
第１章では、本仕様書の背景、目的、対象及び内容について記載している。
第２章では、標準化の対象範囲を記載している。
第３章、第４章、第５章及び第６章では、それぞれ、戸籍附票システムが備えるべき機能要件、様式・帳票要件、データ要件及び非機能要件 について記載している。「（２）標準準拠の基準」にあるように、これらの章は、パッケージシステムが本仕様書に準拠するための判断基準となるものであり、言わば本仕様書の本体部分である。
第７章では、本仕様書において用いている用語について、解釈の紛れがないよう、定義している。
また、別紙に業務フロー及びツリー図を記載している。業務フローは、第３章で規定する機能要件が業務上どのように位置づけられ、有効に機能するのかについて自治体及び事業者の共通理解を促すため、それらに対応したモデル的な業務フローを示している。ここで示した業務フローは、実際の各自治体における業務フローを拘束するものではないが、現在の業務フローでは、本仕様書における機能要件どおりの機能で業務を行うことが難しいと考える自治体は、現在の業務フローを本仕様書に示す業務フローに寄せる（BPR）ことで、本仕様書における機能要件どおりの機能で業務を行うことが期待される。ツリー図は、戸籍の附票に係る業務における機能要件の一覧性を高め、標準化の対象となる業務を明確化するため、業務フローに紐づいた形式 で記載している。
（２）標準準拠の基準
本仕様書の対象は地域情報プラットフォーム標準仕様における戸籍ユニット のうちの戸籍附票に関連する箇所の定義を基本としており、この対象範囲において定義すべき機能について、【実装すべき機能】【実装しない機能】【実装してもしなくても良い機能】の３類型に分類した。可能な限り３類型のいずれに該当するか分類をした上で、定義すべき機能の範囲内で分類されていない機能は、カスタマイズ抑制、ベンダ間移行の円滑化の観点から、実装しない機能と同様のものとして位置付ける。
パッケージシステムが本仕様書に準拠するためには、第３章、第４章及び第５章に規定する【実装すべき機能】をいずれも実装し、【実装しない機能】及び分類されていない機能をいずれも実装しないことが必要である。ただし、分類されていない機能のうち、自治体やベンダの創意工夫により新たな機能をシステムに試行的に実装させて機能改善の提案を行う場合は、当該試行についてあらかじめ公表し、当該試行を本仕様書に盛り込む提案となることを条件にして実装することを可能とする。【実装してもしなくても良い機能】は、実装しても、実装しなくても、実装した上で自治体が利用を選択できることとしても、いずれも差し支えない。
また、本仕様書に準拠しているかどうかは、「３（１）対象自治体」で示した指定都市及び一般市区町村の類型ごとに判断される。特に明記しない限り、2類型全てに当てはまる要件として記載しており、必要に応じて、「指定都市においては、～～」、「（一般市区町村においては、実装してもしなくても良い。）」のように記載している。
なお、実装すべき機能のうち、法令上必ず使用しなければならない機能と必ずしも使用しなくてもよい機能があり、個別に判断する必要がある。
（３）想定する利用方法
標準化法第８条第１項では、「地方公共団体情報システムは、標準化基準に適合するものでなければならない。」とされており、本仕様書を基礎として、各所管大臣は、標準化法 第6条に基づき標準化基準を策定することが想定される。したがって、本仕様書については、
・今後、整備予定の「ガバメントクラウド」上において、各ベンダが、本仕様書に準拠しているシステムを提供する
・各自治体は、本仕様書に準拠しているパッケージシステムをカスタマイズすることなく利用することを想定している。
自治体においては、人口減少による労働力の供給制約の中、システムについて十分な知見がなくても、負担なくシステムを調達し、利用できることが望ましい。自治体としては、標準化後にシステム更改を行う際は改めて本仕様書に示した個別の要件を一々提示してRFI (request for information)やRFP (request for proposal)、更にはFit & Gap分析を行って調達するのではなく、単に、本仕様書に準拠しているパッケージシステムであることを要件に付するだけで、調達を行うことができ、カスタマイズをすることなく利用できることを想定している。本仕様書は、本仕様書における機能さえあればカスタマイズなしで支障なく業務が行えるようになるよう、実装すべき機能と実装しない機能をその理由とともに整理 したものである。そのため、自治体内での検討や自治体・ベンダ間の協議の際に、仮に本仕様書における機能と異なる機能が必要ではないかという議論があった場合、限られた人員、財源の中で、果たして当該自治体だけ特別に必要な機能なのか、本仕様書が想定する業務フローを参照し、効率的な業務運用への見直しが必要ではないか、という観点から、本仕様書における必要／不要の整理を知るための資料として参照することも想定している。
（４）本仕様書の改定
本仕様書については、制度改正時のほか、戸籍情報システムの標準仕様書（法務省所管）に変更が生じた場合、自治体やベンダからの創意工夫によるシステムの機能改善等の提案がある場合や新たな技術が開発されるなどデジタル化の進展等がみられる場合にも、関係者の関与の下で改定することを想定している。とりわけ、制度改正により本仕様書を改正する必要がある場合は、制度の施行時期を勘案して改定する。改定後の本仕様書に基づいて、ベンダがクラウド上で一括してシステムを改修することにより、制度改正等のたびごとに個々の自治体が個別にベンダと協議して改修を行う必要がなくなると想定 される。
各自治体の調達仕様書の範囲との関係
本仕様書を用いることにより、戸籍の附票事務を運用することは可能 であり、本仕様書の対象範囲については本仕様書に記載された内容で調達する必要がある。
しかしながら、各自治体においては、本仕様書の対象範囲外の機能や戸籍情報システムなどと併せて調達すること、また本仕様書に規定されていない非機能要件を設けること等も想定され、各自治体の調達仕様書の範囲と標準仕様書の範囲は必ずしも一致しないと考えられる。この場合であっても、各自治体の情報システムの調達において、本仕様書の範囲の業務について本仕様書に記載された内容で調達する限りにおいては、このような対応も許容される。
また、戸籍附票システムについては、戸籍情報システムに同梱されたパッケージを調達することが主流 となっているため、戸籍情報システムとアプリケーションモジュールやデータベースなどを共有するシステム構成とすることも考えられるが、戸籍の附票事務の独立性が確保される限り、 このようなシステム構成についても許容される。例えば、審査・決裁機能について同じアプリケーションモジュールを活用し、同時に処理を実施することは許容するが、戸籍情報システムの審査・決裁機能を以て戸籍附票システムの審査・決裁機能とすることは許容しない。また、データベースについても、戸籍情報システムで管理する情報を参照する場合は共通項目としても問題ないが、戸籍附票システムにて独自に管理・更新が必要な項目については個別に実装する必要がある。
【戸籍情報システムとシステム構成を共有することを許容する項目】
第４章機能要件
1.1.5空欄
1.1.6年月日管理
1.1.7年月日の表示
1.1.9本籍・筆頭者
1.1.15フリガナ
1.3.1入力場所・入力端末
1.3.2住所辞書管理
1.3.3和暦・西暦管理
1.3.4公印管理
1.3.5交付履歴の管理
1.3.6認証者
2.1.1検索機能
2.1.2検索文字入力
2.2.1異動履歴照会
2.2.2交付履歴照会
2.2.3文字コード照会等
2.3.1キーボードのみの画面操作
3.1異動・発行・照会抑止
4.0.3審査・決裁
5.5公印・職名の印字
5.6公用表示
5.7文字溢れ対応
10.2アクセスログ管理
10.3操作権限管理
10.4操作権限設定
10.5ヘルプ機能
10.7印刷
30.2文字
第6章非機能要件
第２章標準化の対象範囲
標準化の対象範囲
戸籍附票システムの標準化の対象となる範囲は、本仕様書において、実装すべき機能及び実装してもしなくても良い機能として規定している機能要件や、非機能要件、データ要件・連携要件等の共通要件とする。
本仕様書に準拠する戸籍附票システムにより処理する事務は、概ね住民基本台帳制度上の戸籍の附票事務と対応しているが、必ずしも１対１で対応しているわけではない。
本仕様書は、地域情報プラットフォーム標準仕様における戸籍ユニットのうちの戸籍附票に関連する箇所を基本として、今あるカスタマイズの中で、普遍的に有効性が認められるものは標準機能として標準仕様書に盛り込み、そうでないものは盛り込まないことで実装しない機能として整理し、策定した。
第３章機能要件
1 管理項目
1.1 戸籍の附票データ
1.1.1 戸籍の附票データの管理
【実装すべき機能】
戸籍の附票に記載されている者（消除となった者も含む）について、以下の項目を管理すること。
また、以下の項目の一部（戸籍の表示（本籍・筆頭者）、氏名、生年月日、性別等）については、戸籍情報システム等の戸籍附票システム以外のシステムでのデータベースの構築も可能とするが、その場合でも、30.1（データ構造）に規定する最新データの保持と、戸籍附票システムの端末画面上でデータベースを確認できる機能を有する こと。
【戸籍の附票記載事項に当たる項目（法第17条各号及び第17条の２第１項関係）】
・戸籍の表示（本籍・筆頭者）
・氏名
・生年月日（和暦で管理すること。）
・性別
・住所（方書を含む。）
・住所を定めた年月日
・住民票コード
・国外転出者である旨（国名等）、転出予定年月日
・在外選挙人名簿登録市区町村名
・在外投票人名簿登録市区町村名
【戸籍の附票の除票固有の記載事項に当たる項目（法第21条の２関係）】
・消除事由（消除、改製）
・事由の生じた年月日
【戸籍の附票のその他の項目】
・戸籍附票宛名番号
・附票番号
・同一の戸籍の附票の者の並び順（5.2参照）
・異動履歴として管理する各項目（1.2.1参照）
・住所（方書を含む。）の履歴
・住所を定めた年月日の履歴
・証明書の交付履歴（1.3.5参照）
・抑止フラグ
・備考（1.1.11参照）
・メモ（1.1.12参照）
・氏名のフリガナ（1.1.15参照）
・住所コード
・住所の郵便番号
・編製年月日
・改製記載年月日（改製記載の場合）
・再製記載年月日（再製記載の場合）
・個人番号未付番者についてCSとの連携のために設定される符号
・利用者証明用電子証明書シリアル番号
【戸籍の附票の除票固有 のその他の項目】
・改製消除年月日（改製消除の場合）
【実装しない機能】
消除となった者における項目の記載・消除・修正ができること。
【考え方・理由】
戸籍の表示（本籍・筆頭者）は、戸籍情報システムで管理されている内容と同一 の内容を管理すること。
氏名は、該当する戸籍に記載されている氏名と同一の字形 で記載ができること。
また、生年月日は該当する戸籍に記載されている生年月日と同じ内容とし、住民記録システムに準じ和暦 で管理すること。ただし、データベースに保持する形式として西暦も許容するが、入出力 において和暦に変換する機能を有すること。
性別について、戸籍情報システムに記録されている実父母（又は養父母）との続柄や夫又は妻の情報等から変換された性別とすること。
戸籍附票宛名番号 は、戸籍附票システム内で採番された個人を特定できる一意な番号を指す。附票番号 とは、戸籍の附票単位で振られた番号を指す。
同一の戸籍の附票の者の並び順は、該当する戸籍に記載されている者と一致すること。
個人番号未付番者については、戸籍の附票に住民票コードが記載されないところ（デジタル手続法附則第４条第３項）、CSとの連携のため、住民票コードに代わる符号を設定し、記載 すること。
世帯主氏名は、分科会における議論の結果、使用実態及び今後のニーズが確認できなかったことから、不要 と判断した。
消除となった者又は戸籍の附票の除票について本人からの申出等による誤記修正を行った場合又は戸籍の訂正があった場合は、記載事項を修正せず、誤記等である旨又は誤記等の修正後の記載について備考欄に記載されることとし、記載・消除・修正は実装しない機能とした。
なお、消除となった後に消除となった者と同一戸籍の氏変更があった場合等においても、消除となった者については消除となった際の情報を保持 すること。ただし、消除となった者が当該戸籍の筆頭者である場合、身分事項としての氏の変更は許容しないが、戸籍届出等による修正により戸籍の表示としての筆頭者氏名欄の氏（戸籍の附票のインデックスとしての氏）の変更を認める。
再製については滅失された戸籍の附票に対して行われるものであることから、再製消除年月日については記録できる戸籍の附票の除票が存在しないため、管理項目としていない。
1.1.2 改製
【実装すべき機能】
戸籍の附票は、欄の大きさの上限（履歴を保持できる上限回数のこと。）を設けず、満欄による自動改製は行わない こと。
戸籍の附票は、任意のタイミングで手動改製ができる こと。
改製を行った年月日を管理できること。
また、戸籍法第11条の２に基づき戸籍が再製された場合においては、戸籍の附票を改製 すること。
【考え方・理由】
法においては、市区町村長の判断 により改製が可能であることから、任意改製の機能を設けることとする。
戸籍情報システムに同梱して構築された場合においても、戸籍の附票単独で改製が必要となることが想定されるため、戸籍附票システム単独で改製を実施できる機能を想定している。
戸籍附票システムにおいては、戸籍情報システムにおける訂正に係る事項の記載のない戸籍の附票の再製という概念が存在しないことから、戸籍法第11条の２に基づき、戸籍において虚偽の届出等、錯誤による届出等又は市町村長の過誤の訂正に係る事項の記載のない戸籍の再製の申出があり、戸籍の再製が行われた際には、改製することとする。戸籍の全部又は一部が滅失等した場合の戸籍法第11条に基づく戸籍の再製が行われた際には、戸籍附票システムにおいても再製で対応 することを想定している。
また、「市町村長は、戸籍の附票を改製する場合には、当該戸籍の附票の消除前又は修正前の記載（法第16条第２項の規定により磁気ディスクをもって調製する戸籍の附票にあっては、記録）の移記を省略することができる」（令第21条第２項の規定により読み替えて準用する令第13条の２）とされていることから、改製する場合においても最新の履歴以外を移行することは許容 されている。
1.1.3 戸籍の附票の除票の管理
【実装すべき機能】
戸籍の附票に記載された者全員を消除したとき、又は戸籍の附票を改製したときは、戸籍の附票の除票とすること。
消除又は改製を実施した日（消除の事由が生じた年月日又は改製消除年月日）より150年間 保存を行うこと。
保存期間を経過した戸籍の附票の除票の廃棄を行えること。
法第21条の２に規定する戸籍の附票の除票の記載事項及び備考欄に誤記があることが判明した場合、備考欄に誤記である旨及び正しい記載を入力すること。
テキストデータ化が実施できていない戸籍の附票の除票に関してはイメージデータで管理できること。イメージデータの解像度は400dpiとするが、標準準拠システム移行前に当該解像度以外で読み取ったイメージデータについては、そのままの解像度で差し支えない取扱い とする。
読み取った戸籍の附票の除票はBMP形式又はBMP形式に可逆変換できること（例：TIFF）。
読み取った戸籍の附票の除票に対してイメージ処理が行えること（例：文字追加、線描画など）。
スキャナでの戸籍の附票の除票読み込み時に濃度が調整できること。
スキャナで読み込んだ戸籍の附票の除票を回転させ、体裁を整えることができること。
スキャナの読み取り位置を設定できること。
戸籍の附票の除票のイメージデータに変更が発生した場合、システム上で誤記修正・保存処理を実施できること。
デジタル手続法第10号施行日以前の戸籍の附票の除票については、イメージデータを検索するための項目として、氏名・生年月日・戸籍の表示（本籍・筆頭者）・住所・消除事由（職権消除、改製等）・事由の生じた年月日を登録できること。また、その項目を基に検索が実施 できること。
【考え方・理由】
令34条に基づき、戸籍の附票の除票は150年保存が可能な形式とする。
デジタル手続法による改正後の法により、住民票の除票と同様、戸籍の附票の除票が公証基盤として法令上明確に位置づけられた。これにより、戸籍の附票の除票となった時点の情報を確実に記録しておくことが必要であることから、戸籍の附票の除票の記載事項は修正しないこととされた。よって、万が一、誤記が判明した場合は、戸籍の附票の除票の記載事項を直接修正せず、戸籍の附票の除票の備考欄に誤記である旨及び正しい記載等を入力することとする。
また、戸籍の附票の除票の記載事項でない事項に誤記があることが判明した場合も、備考欄に誤記である旨及び正しい記載等を入力できること。
戸籍情報システム電算化前の戸籍の附票の除票は紙での管理、イメージデータでのシステム管理の２つの管理形態が存在しており、様式については規定されていないため様々な様式が存在している。
また、ペーパーレス化の観点や、デジタル手続法第９号施行日以降、本籍・筆頭者等の省略に対応するための手処理運用の煩雑さを考慮すると、紙運用よりもシステムで運用できることが望ましいため、テキストデータ化ができない戸籍の附票の除票についてはイメージデータのシステム管理ができる機能を定義している。イメージデータ管理の機能は、システム移行時も考慮し、解像度やデータ形式なども定義している。また、データ形式の変換及びイメージデータの回転は、イメージデータに変更を加えないまま実施することを想定しており、改ざんに当たらない。濃度調整についても、元の戸籍の附票の除票の内容を損なうような調整にならないものを指している。
1.1.4 改製不適合戸籍の附票の管理
【実装すべき機能】
電子データ（テキスト）及びイメージデータとして管理すること。
イメージデータの解像度は400dpiとするが、標準準拠システム移行前に当該解像度以外で読み取ったイメージデータについては、そのままの解像度で差し支えない取扱いとする。
読み取った改製不適合戸籍の附票はBMP形式又はBMP形式に可逆変換できること（例：TIFF）。
読み取った改製不適合戸籍の附票に対してイメージ処理が行えること（例：文字追加、線描画など）。
スキャナでの改製不適合戸籍の附票の読み込み時に濃度が調整できること。
スキャナで読み込んだ改製不適合戸籍の附票を回転させ、体裁を整えることができること。
スキャナの読み取り位置を設定できること。
改製不適合戸籍の附票のイメージデータに変更が発生した場合、システム上で職権記載、職権消除及び職権修正・保存処理を実施できること。編集機能として、文字情報の追加・消除、編集内容の確認画面と承認機能を有すること。
電子データ（テキスト）としては、1.1.1（戸籍の附票データの管理）に規定する項目を管理すること。また、規定した項目を基に検索ができること。
【考え方・理由】
改製不適合戸籍の附票とは戸籍情報システムの電算化において、「誤字 を使用することができず、本人が文字の変更を認めない場合や確認が取れない場合」等に戸籍がテキストデータ化されないことに伴い戸籍の附票においてもテキストデータにされずに紙やイメージデータのまま管理がされている戸籍の附票を指す。
現在も改製不適合戸籍の附票を管理している団体が存在しており、紙又はイメージデータによるシステム管理の２つの管理形態が存在する。
戸籍については、平成26年７月４日付け法務省民一第740号民事局第一課長回答にて、「電子情報処理組織の取り扱いに適合しない戸籍の画像情報処理方式による磁気ディスク化について、差支えないとされた事例」とあり、必ずしもシステムで管理を行うべきという回答ではないため、紙での管理も残っている状況であり、戸籍の附票も戸籍に準じ紙での管理が残っている。デジタル化３原則やデジタル手続法第10号施行日以降の運用を見据えると、原則標準準拠システム移行時には改製不適合戸籍の附票についても附票本人確認情報の通知等が必須となるためテキスト化すべきと考えるが、本人の同意を得られない、連絡が取れない等様々な理由によりテキスト化が困難で、現行の運用を継続せざるを得ない状況も考えられることに加え、戸籍情報システムにおいてイメージデータの管理を継続し、情報連携等に必要な情報のみテキストデータ化する方向であることを踏まえ、戸籍附票システムにおいても電子データ（テキスト）での管理とイメージデータの管理機能を併用 する。
イメージデータ管理の機能は、システム移行時も考慮し、解像度やデータ形式なども定義している。また、データ形式の変換及びイメージデータの回転は、イメージデータに変更を加えないまま実施することを想定しており、改ざんに当たらない。濃度調整についても、元の改製不適合戸籍の附票の内容を損なうような調整にならないものを指している。
1.1.5 空欄
【実装すべき機能】
1.1.1（戸籍の附票データの管理）に規定する項目のうち、以下の項目は、空欄を許容しない こと。その他の項目は、空欄を許容すること。
【空欄を許容しない項目】
・ 戸籍の表示（本籍・筆頭者）
・ 生年月日（デジタル手続法第９号施行日以前に消除となった者を除く。）
【考え方・理由】
氏名については、出生届において氏名が未定であり、空欄となる場合があることから、空欄が許容される。
また、出生届は14日以内に届け出る必要があり、性別が空欄の戸籍ができることがある。戸籍の記載において性別が空欄となっている場合は、原則としては、戸籍の取扱いに準ずることとなるため、戸籍届出上許容されている場合は、確定し次第、職権で修正する。また、デジタル手続法第９号施行日前に消除となった者についても、消除となった時点で記載項目とされていないため、空欄が許容される。
住所については、住所不明者についてのみ 空欄を許容するが、住基ネットの本人確認情報の検索等の手段を用いても住所を特定できない場合に住所不明者とすることが適切である。（例えば、最終住所地市区町村で調査の結果職権消除となった者で、どこの市区町村にも転入又は職権記載がされていなかった場合は住所不明者となる。）
住民票コードについては、住基ネット稼働後に一度も住民基本台帳に記録されたことがない者等は未付番者となるため、空欄が許容される。また、デジタル手続法第10号施行日前に消除となった者についても、消除となった時点で記載項目とされていないため、空欄が許容される。
生年月日については、出生届提出時に確定している項目であり、基本的には空欄が許容されない。ただし、性別同様、デジタル手続法第９号施行日前に消除となった者については、空欄となり得るため、その場合においては空欄が許容される。
1.1.6 年月日の管理
【実装すべき機能】
年月日は、暦上日で管理すること。ただし、1.1.1（戸籍の附票データの管理）に規定する項目のうち生年月日、住所を定めた年月日及び1.2.2（異動事由）に規定する項目のうち戸籍届出等による記載又は戸籍届出等による消除に係る異動日については、暦上日以外の年月日（例：うるう年でない年における２月29日）も許容するとともに、以下に規定する不詳日を許容すること。また、1.1.1（戸籍の附票データの管理）に規定する編製年月日、改製記載年月日、改製消除年月日又は再製記載年月日についても以下の不詳日を許容すること。戸籍附票システム内部の年月日の入力や管理については、1.1.1（戸籍の附票データの管理）の生年月日を除き、和暦・西暦どちらを用いても差し支えない。
【不詳日入力一覧】
・「令和○○年頃 」
・「令和○○年○月頃」
・「令和○○年〇月〇日頃」
・「推定 令和○○年○月○日」
・「推定令和○○年○月」
・「令和○○年春 」
・「令和○○年○月上旬」
・「令和○○年○月中旬頃」
・「年月日不詳」
・「令和○○年月日不詳」
・「令和○○年○○月日不詳」
・「令和○○年○○月○日から○○月○日頃までの間」
・「令和○○年○○月推定○日から○日までの間」
・「令和○○年○○月○日頃から○日頃までの間」
暦上日以外の年月日（例：うるう年でない年における２月29日）、明治45年７月30日及び大正15年12月25日の設定も許容する。
【実装しない機能】
みなし生年月日等を作成できること。
【考え方・理由】
住所を定めた年月日等住民記録システムから反映されるデータについての不詳日は、住民記録システムに準ずる。生年月日についても、戸籍において不詳日となっている者も存在することから、不詳日の設定を許容することとした。
また、編製年月日、改製記載年月日、改製消除年月日及び再製記載年月日について原則不詳日は認められないが、古くから記録されている戸籍の附票において不詳となっている場合が考えられるため、不詳日の設定を許容することとした。
1.1.7 年月日の表示
【実装すべき機能】
年月日は、戸籍の附票の写し等の証明書及び画面表示において、和暦で記載・表示すること。上記の記載・表示のため1.3.3（和暦・西暦管理）による適切な変換機能を有していること。
【考え方・理由】
市区町村によって和暦と西暦が異なると、システムが複雑になる上、QRコード化やOCR読込みに支障が出る ため、全て和暦で表示することとする。
なお、これは証明書等で表示する際のルールであり、入力やデータの持ち方としては、和暦と西暦のどちらを用いても、記載・表示する際や他システム連携の際に適切に変換できれば差し支えない。
1.1.8 在外選挙人名簿及び在外投票人名簿登録市区町村名
【実装すべき機能】
在外選挙人名簿及び在外投票人名簿登録市区町村名を戸籍の附票へ記載できること。
必要に応じ、戸籍情報システムに対して、在外選挙人名簿及び在外投票人名簿登録者の戸籍又は戸籍の附票の変更通知書を作成する際に必要な情報（在外選挙人名簿及び在外投票人名簿登録者氏名、在外選挙人名簿及び在外投票人名簿登録市区町村名等）を連携できること。
【考え方・理由】
在外選挙人名簿登録市区町村名、在外投票人名簿登録市区町村名については、都道府県名についても省略せずに管理すること。ただし、市区町村名（指定都市にあっては、市名及び区名又は総合区名）までの管理でよい。
戸籍情報システムで在外選挙人名簿及び在外投票人名簿登録者の戸籍又は戸籍の附票の変更通知書を作成する場合に、在外選挙人名簿及び在外投票人名簿登録者氏名や当該帳票の送付先市区町村名を提示・連携できる機能を備えた。
1.1.9 本籍・筆頭者
【実装しない機能】
本籍・筆頭者欄は、「なし」又は「不明」と記載できること。
【考え方・理由】
法第16条で「市町村長は、その市町村の区域内に本籍を有する者につき、その戸籍を単位として、戸籍の附票を作成しなければならない。」としていることから、本籍・筆頭者は必ず存在するため、いずれの項目においても「なし」又は「不明」の取り扱いにはなり得ない。
1.1.10 戸籍附票宛名番号、附票番号
【実装すべき機能】
戸籍附票宛名番号、附票番号は、自動付番 できること。
戸籍附票宛名番号と附票番号は、それぞれ戸籍情報システムで管理されている戸籍個人番号、戸籍番号と紐づけて管理することができること。
同一自治体内で番号が重複しない ようにすること。
指定都市においては、行政区ごとに番号を管理し、区間転籍の際には新規付番できること。
【考え方・理由】
戸籍附票宛名番号は個人を特定できる一意な番号を指し、個人を単位で付番される番号を指す。附票番号は戸籍の附票を特定できる一意な番号であり、戸籍の附票単位で付番される番号を指す。
なお、本仕様書としては、戸籍附票システムにおいて自動付番する分野別番号とするものの、戸籍情報システムにおいては、戸籍を構成する個人単位で付番される戸籍個人番号、戸籍単位で付番される戸籍番号が存在していることから、それらの番号と同一番号で管理することを妨げるものではない。
指定都市においては、行政区ごとに戸籍を管理しており、区間転籍の際には新たに付番していることから、同機能を実装することとした。
1.1.11 備考
【実装すべき機能】
備考に異動履歴を入力できること。
異動履歴については、20.0.3（備考欄（異動履歴）の記載）により自動で作成 され、備考欄に記載すること。
また、備考に個人を単位として、自由入力できる備考欄（その他）（20.0.6参照）を設けること。備考欄（その他）（20.0.6参照）の削除・修正について履歴管理されること。
備考に入力されたものについては、必要に応じ戸籍の附票の写し等の証明書に出力することができること。
消除となった者の記載事項及び備考欄に誤記があることが判明した場合、備考欄に誤記である旨及び正しい記載等を入力し、証明書に出力すること。ただし、特別の請求又は必要である旨の申出に基づき表示する項目に関する誤記である旨及び正しい記載等については、デフォルトでは省略とし、市区町村長の判断で当該項目を表示して交付する場合にのみ出力すること。
【考え方・理由】
戸籍の附票の写し等の証明書には本人等及び国又は地方公共団体の機関による特別の請求又は第三者及び特定事務受任者による必要である旨の申出があった場合に、異動履歴の記載等を行っている市区町村があること、また、消除となった者に誤記があることが判明した場合に誤記である旨及び正しい記載等を記載する必要があること（1.1.3戸籍の附票の除票参照）から、それらを記録する機能も必要であると想定されるため、当該機能を設けた。
消除となった者又は戸籍の附票の除票について本人からの申出等による誤記修正を行った場合又は戸籍の訂正があった場合は、記載事項を修正せず、誤記等である旨及び誤記等の修正後の記載について備考欄に記載されるものとする。
証明書における備考欄は、特別の請求又は必要である旨の申出を受けてプライバシー保護の観点等から市区町村長の判断により記載するかしないかを選択し、記載を選択した場合、当該項目を表示して交付する。ただし、消除となった者又は戸籍の附票の除票について本人からの申出等による誤記修正を行った場合又は戸籍の訂正があった場合、その誤記等である旨及び正しい記載等について表示されないことで、第三者による悪用等のリスクも想定されるため、当該内容については必ず備考欄に記載することとした（20.0.5及び20.0.6参照）。ただし、特別の請求又は必要である旨の申出に基づき表示する項目に関する誤記である旨及び正しい記載等については、デフォルトでは省略とし、市区町村長の判断で当該項目自体を表示して交付する場合にのみ記載すること。
また、戸籍届出等による修正により戸籍の表示としての筆頭者氏名欄の氏の変更を許容するが、構成員としての筆頭者の欄（「附票に記載されている者」の欄）は消除されて以降の変更を許容しないことから、当該戸籍の表示の筆頭者氏名欄と構成員欄の消除された筆頭者が同一人物であることを担保するため、特別の請求又は必要である旨の申出を受けて、市区町村長の判断により記載するかしないかを選択し、戸籍の表示が表示された場合に、備考欄に戸籍の表示における筆頭者氏名欄の氏変更の異動履歴を必ず記載 することとする（20.0.3参照）。
編製年月日、改製記載年月日又は再製記載年月日については、戸籍の附票の連続性を確かめる必要性がある戸籍の附票の写し等の交付を求める者の便宜を図る観点より、必ず備考欄に記載することとする（20.0.5参照）。
1.1.12 メモ
【実装すべき機能】
個人を単位とし、記載事項を限定しないメモ入力が可能であること。
メモを入力した者の操作者ID及び日時が記録 されること。
メモの削除・修正について履歴管理されること。
メモ入力されたものについては、戸籍の附票の写し等の証明書に出力されない こと。
【考え方・理由】
メモ機能については、証明書に出力しない事項について、限定せずに記載できる機能とした。
なお、個人情報保護の観点にも十分留意の上で記載することが重要である。
1.1.13 支援対象者管理
【実装すべき機能】
支援措置の実施に当たっては、支援対象者の戸籍の附票及び戸籍の附票の除票に支援対象者である旨の表示ができるとともに、戸籍附票システム内に以下に掲げる項目のデータベースを構築し、戸籍の附票及び戸籍の附票の除票の上記表示から画面遷移し、支援措置責任者の了承を得て又は支援措置責任者のみが端末画面上でデータベースを確認できること。
＜データベース上の項目＞
○支援対象者に関する項目
①現本籍地市区町村の場合
・氏名及びフリガナ
・戸籍附票宛名番号
・附票番号
・生年月日
・性別
・住所
・前住所等
・本籍
・前本籍等
・連絡先（電話番号、携帯電話番号、メールアドレス等）
・その他（任意の文言を登録できること。）
②前本籍地市区町村等の場合
・氏名及びフリガナ
・戸籍附票宛名番号
・附票番号
・生年月日
・性別
・住所
・前住所等
・連絡先（電話番号、携帯電話番号、メールアドレス等）
・その他（任意の文言を登録できること。）
○併せて支援措置を求める者に関する項目
・氏名及びフリガナ
・戸籍附票宛名番号
・附票番号
・生年月日
・性別
・住所
・前住所等
・本籍
・前本籍等
・支援対象者との関係
・その他（任意の文言を登録できること。）
○加害者に関する項目
・氏名及びフリガナ
・戸籍附票宛名番号（同一市区町村の場合に限る。）
・附票番号（同一市区町村の場合に限る。）
・生年月日
・性別
・住所
・その他（任意の文言を登録できること。）
○支援対象者より支援を求められている事務
・戸籍の附票の写し等の交付（本籍、前本籍等）
・住民基本台帳の閲覧（現住所）
・住民票の写し等の交付（現住所、前住所）
○転送情報
①当初受付市区町村が対応するもの
・転送先市区町村
・転送年月日
②当初受付市区町村から転送を受けた他の市区町村（以下「転送受付市区町村」という。）が対応するもの
・転送された支援措置申出書の受付年月日
・支援の必要性がないことを確認したときの申出者への連絡年月日
○支援措置の期間
・支援措置の開始年月日
・支援措置の終了年月日
○仮支援措置
・仮支援措置の有無
・仮支援措置の開始年月日
・当初受付市区町村（転送受付市区町村の場合に限る。）
なお、支援対象者の氏名及び戸籍附票宛名番号並びに併せて支援措置を求める者の氏名及び戸籍附票宛名番号、支援を求められている事務並びに支援措置の期間以外の項目については、戸籍附票システム以外のシステムでのデータベースの構築も可能とするが、その場合でも戸籍の附票の支援対象者である旨の表示から画面遷移し、端末画面上でデータベースを確認できる機能を有すること。
【考え方・理由】
総務省通知（平成16年５月31日総行市第218号）で「住民基本台帳事務における支援措置申出書」の様式例を示し（平成18年10月4日総行市第136号及び平成24年9月26日総行市第89号様式変更）、申出書に記載する事項を例示しており、上記の項目を抜粋した。
戸籍の附票及び戸籍の附票の除票においては、最新住所を含む住所の履歴に現住所が表示される可能性があり、データベース上で確認できる必要がある。
支援措置においては、申出がなされてから、支援措置の必要性を確認し、実際に支援措置を開始するまでの間も、被害者保護のために、仮支援措置が必要となる場合があり得、仮支援措置の有無についてもデータベース上確認できる必要がある。
10.3（操作権限管理）において、利用者ごとの表示・閲覧項目及び実施処理の制御ができることとしており、各市区町村の支援措置に係る事務の実情に合わせて、データベースの閲覧権限や閲覧項目、閲覧を実施する際の処理などについて、管理できるものである。
本籍地について、住所の変更がない場合であっても本籍地が複数回変更することがあり得ることから、現住所が記載されている戸籍の附票又は戸籍の附票の除票の写しを保存している全ての市区町村で支援措置を講ずる必要がある。
なお、支援対象者及び併せて支援措置を求める者の氏名及び戸籍附票宛名番号、戸籍附票システム上のデータベースのほか支援を求められている事務並びに支援措置の期間以外の項目については、住民記録システムに準じて、戸籍附票システム以外のシステムでのデータベース構築を可能とした。
1.1.14 郵便番号
【実装すべき機能】
住所の郵便番号を管理 すること。
【考え方・理由】
郵送のニーズが一定以上あると想定されるため、便宜的に管理項目とする。実装方法として、住民記録システムと戸籍附票システム共通で持つことは問題ないと考える。
1.1.15 フリガナ
【実装すべき機能】
氏名については、フリガナを管理すること。
【考え方・理由】
住民記録システムに準じて管理を行う。
また、現在、法務省において、戸籍における「氏名の読み仮名」の法制化について検討が進められている。その検討を踏まえ、法における「氏名の読み仮名」の取扱い及び戸籍附票システムにおける取扱いを決めていくこととなるので、フリガナに係る本仕様書の記載については、関係法令が制定される際に修正を行う予定である。
1.2 異動履歴データ
1.2.1 異動履歴の管理
【実装すべき機能】
1.1.1（戸籍の附票データの管理）に規定する異動履歴は、以下の項目を管理すること。
・異動者（4.0.1参照）
・異動事由として管理する項目（1.2.2参照）
・異動日（4.0.2参照）
・処理日（4.0.2参照）
・入力場所（1.3.1参照）
・入力端末（1.3.1参照）
また、別途管理している操作者ID及び操作日時（10.2参照）については、異動履歴と紐づけることができること。
また、異動したデータ自体については、以下のとおり、時点ごとに全項目の履歴データを持つ方式により管理すること。
・戸籍の附票に記載する各項目を１列 とし、全項目を１行 で保持する。
・データキーは、戸籍附票宛名番号と履歴番号 でユニークとする。履歴番号は1からの単純連番 とする。
・履歴は、データキーの履歴番号をカウントアップ し、項目内容の変更有無に係わらず、全項目の内容を保持する。
・履歴番号が最大のデータを１件セレクトすることで、その個人の直近データの全項目を取得 する。
【考え方・理由】
異動履歴の管理項目は基本的に住民記録システムに準ずる。ただし、届出日や申出日等、戸籍附票システムにおいて必要のない項目については削除した。
1.2.2 異動事由
【実装すべき機能】
システムが管理する異動事由コード及び付随する区分により、以下の区分が行えること。また、以下の区分からシステムが管理する異動事由コード及び付随する区分にマッピングができること。
異動事由は、以下のとおり区分すること。
〇記載の事由
・戸籍届出等による記載
・改製 （戸籍法第11条の２に基づく戸籍の再製に伴う改製を指す）
・改製 （その他の戸籍の附票における改製を指す）・再製 （戸籍の附票における再製を指す）
・異動の取消し（増）
〇消除の事由
・戸籍届出等による消除
・改製（戸籍法第11条の２に基づく戸籍の再製に伴う改製を指す）
・改製（その他の戸籍の附票における改製を指す）
・再製（戸籍の附票における再製を指す）
・異動の取消し（減）
〇修正の事由
・戸籍届出等による修正
・転入等
・転出
・転居
・職権修正等（住民票における職権記載・消除・修正等を指す）
・誤記修正
・その他職権修正
・異動の取消し（修正）
【考え方・理由】
データ連携を前提として、改造仕様書に定義されている異動事由を基に項目を設けた。
前提として、本仕様書において異動事由”コード”というデータベースの物理的な異動事由コードのラインナップは定義されていない。本仕様書の「区分すること。」は、各社のパッケージの異動事由コード及び付随する区分が、本仕様書の論理的な区分にマッピングできることと考える。
また、修正の事由の「職権修正等」については、住基ネット回線を通じて連携される住民記録システムにおける住民票に対する「職権記載等」、「職権消除等」及び「職権修正等」がマッピングされる異動事由を指す。戸籍附票システムにおける職権修正は「その他職権修正」とし、在外選挙人名簿及び在外投票人名簿登録市区町村名の変更等に伴う職権修正は「その他職権修正」に含まれる。
戸籍において虚偽の届出等、錯誤による届出等又は市町村長の過誤によって記載が行われ、戸籍法第11条の２に基づき、その記載について訂正がされた場合には、戸籍附票システムにおいては戸籍届出等による記載、消除又は修正の異動事由で対応するものとする。また、戸籍法第11条の２に基づき、当該訂正に係る事項の記載のない戸籍の再製の申出があり、戸籍の再製が行われた際には、戸籍附票システムにおいては改製を行い、異動事由は「改製（戸籍法第11条の２に基づく戸籍の再製に伴う改製を指す）」で対応するものとする。
1.3 その他の管理項目
1.3.1 入力場所・入力端末
【実装すべき機能】
システムログや証明書発行管理に使用するため、戸籍附票システムを使用する場所として、本庁、支所、出張所、戸籍附票システム利用課等の入力場所及び入力端末等の登録管理ができること。
指定都市においては、行政区を管理できること。
【考え方・理由】
システムログや証明書発行管理に使用するための戸籍附票システムを使用する場所（本庁・支所・出張所・戸籍附票システム利用課等の入力場所）及び入力端末等を管理する機能が必要。
1.3.2 住所辞書管理
【実装すべき機能】
必要に応じ速やかに、最新の住所情報に更新すること。国名については、毎年、最新の情報に更新すること。ただし、住所等の（旧）町名等が入力 できること。
住所情報は、職員でも容易に修正できること。
住所辞書については全国的に提供されるものを使用し、住所コードは全国地方公共団体コードを使用した11桁の値とすること。構成は、都道府県（２桁）＋市区町村（３桁）＋大字（３桁）＋小字（３桁） とすること。
なお、都道府県コードはJIS X 0401に、市区町村コードについてはJIS X 0402に準拠すること。大字、小字は規定しない。
住所カナ入力（例えば、東京都日野市神明の場合であれば、「トヒシ」のように、住所の頭の数文字を入力することをいう。）をすることで、郵便番号及び住所が自動で入力されること。また、郵便番号を入力することで、住所が自動で入力 されること。
住所及び本籍について都道府県名→市区町村名→大字→小字 の順に一覧表より順番に選択していくことで住所辞書からの引用ができること。
【考え方・理由】
住民記録システムに準ずる。
1.3.3 和暦・西暦管理
【実装すべき機能】
和暦と西暦の対応及び変換のためのマスタ情報が管理できること。
また、元号が改正された場合、パラメータ設定による元号変更対応が可能であること。
【考え方・理由】
住民記録システムに準ずる。
1.3.4 公印管理
【実装すべき機能】
市区町村長及び職務代理者の公印が管理できること。
【考え方・理由】
住民記録システムに準ずる。
また、指定都市の場合は他区長及びその職務代理者の公印を管理できることも含む。
1.3.5 交付履歴の管理
【実装すべき機能】
1.1.1（戸籍の附票データの管理）に規定する証明書の交付履歴(20.1.1.（戸籍の附票の写し）、20.1.2.（戸籍の附票の除票の写し））は、市区町村が定める期間、以下の項目を管理すること。
・交付年月日時
・交付場所
・交付対象者
・証明書の種別
・交付区分（本人等請求、公用請求、第三者請求）
・記載事項
・枚数
・発行番号
・端末名、操作者ID
・処分情報（誤って発行した証明書を処分した場合にはその旨の記録。）
また、上記交付履歴の項目について、コンビニで交付された場合も同様に管理すること。
【実装しない機能】
市区町村が定める期間内に、交付履歴データを削除できること。
【考え方・理由】
住民記録システムに準ずる。
1.3.6 認証者
【実装すべき機能】
証明書等の認証者は、市区町村長と職務代理者の２件について、職名・氏名の管理ができる こと。
また、期間等事前に登録した条件によって、自動的に切り替わることができるよう職務代理者期間の管理ができること。
指定都市においては、他区長及びその職務代理者の職名・氏名を管理できることも含む。
【実装しない機能】
証明書等の認証者を「○○長公印」のように氏名空欄とできること。
【考え方・理由】
住民記録システムに準ずる。
2 検索・照会・操作
2.1 検索
2.1.1 検索機能
【実装すべき機能】
システム利用者（ID単位）ごとに、一度検索ダイアログ等で設定した値（検索履歴）については、自動的にその設定値が、一定の件数保存されること。
また、それら検索履歴を選択することにより、同じ条件による再検索及び検索履歴を活用した新たな検索にも対応できること。
【考え方・理由】
住民記録システムに準ずる。
2.1.2 検索文字入力
【実装すべき機能】
フリガナを登録している場合は、カタカナで入力及び検索できること。
以下のあいまい検索 ができること。
・清音、濁音、半濁音による違いを無視できること。
例「ヂ」と「ジ」、「ズ」と「ヅ」、「ワ」と「ハ」、「ヴァ」と「バ」、「ヴィ」と「ビ」、「ヴ」と「ブ」、「オ」と「ヲ」、「ヒ」と「ピ」
・拗音、促音の小文字と大文字による違いを無視できること。
例「ッ」と「ツ」、「ャ」と「ヤ」、「ュ」と「ユ」、「ョ」と「ヨ」
・氏名（カナ）等で文字列一致検索（完全一致・部分一致）ができること。
・氏名（漢字）等で一部の文字を「＊」 で代替した検索ができること。
・名（氏名の名）のみの検索ができること。
・氏と名との間のスペースを無視 した検索ができること。
・氏名フリガナ検索について、２文字目以降が「ウ」の場合で、その直前の文字が「オ段」の場合、「ウ」を「オ」に変換して検索 できること。
・長音の有無を無視 できること。
・入力ゆらぎ対応として、「ー(全角長音)」と「―(全角ダッシュ)」と「－(全角マイナス)」と「‐(全角ハイフン)」、「ｰ(半角長音)」と「-(半角ハイフン、マイナス)」、「全角スペース」と「半角スペース」を区別せず 検索条件として指定でき両方が該当として処理されること。
・検索文字から、異体字や正字も包含した検索 ができること。
例：検索文字の例
「辺」で検索時は「邊」、「边」、「邉」、「𨘢」等、
「浜」で検索時は「濱」、「頻」、「濵」、「滨」等、
「藤」で検索時は「 䕨 」、「籘」、「籐」等が検索対象文字となる。
・外字を登録する際に、異体字を合わせて登録した場合は、それも包含して検索できること。
なお、一般市区町村においては、あいまい検索の機能として異体字検索は、実装してもしなくても良い機能とする。
【実装しない機能】
（株）や（有）等の記号を入力及び検索できること。
【考え方・理由】
住民記録システムに準ずる。
2.1.3 基本検索
【実装すべき機能】
氏名・氏名のフリガナ・生年月日（西暦・和暦）・性別・本籍・筆頭者・住所・住所コード・住民票コードから検索できること。また、消除となった者の備考欄に含まれる、誤記があることが判明した場合の記録のうち、正しい記載である氏名・氏名のフリガナ・生年月日について検索できること。
指定都市においては、区からも検索できることとし、操作者の所属により管轄区を自動判定し、検索画面上の区を既定値として検索できること。なお、他区の選択も可能とすること。
年月日を指定して複数条件検索、項目内部分検索ができること。
異動履歴の検索においては、氏名及び住所、住民票コードについては過去履歴を含めて検索し、対象者を特定できること。
上記項目に関し、データ未入力項目を含めて検索できること。
外字検索、検索文字選択のためのサポート機能が提供されていること。 具体的には外字を選択するための手書き入力、手書き入力による文字選択等が想定されるが、具体的な実装方法は規定しない。
また、西暦と和暦はそれぞれ対応する年に置き換えられ検索がされること。
氏名及び住所の検索は、過去のものも横断的に検索できること。
※「検索」 は、対象者を選択するため、画面から検索用項目を画面入力して、マッチするものを探す操作をいう。「照会」 は、既に特定した対象者の詳細な情報について、データベースに問い合わせる操作をいう。
【実装してもしなくても良い機能】
対象者を検索、選択後、該当者の1.1.1（戸籍の附票データの管理）のデータをCSV形式で出力する機能を有すること。
【実装しない機能】
異動者一覧を表示している状態で、検索条件を加えての再検索（絞込み）ができること。
【考え方・理由】
住民記録システムに準ずる。
2.2 照会
2.2.1 異動履歴照会
【実装すべき機能】
個人や同一の戸籍の附票の者を特定した後に、1.2.1（異動履歴の管理）に規定する異動履歴を照会できること。
1.2.1（異動履歴の管理）に規定する項目を用いて対象者の異動履歴を照会できること。
【実装しない機能】
複数の戸籍の附票にまたがる同一個人を単位として履歴が照会できること。
【考え方・理由】
新しい戸籍を作った者について、元の戸籍に基づく戸籍の附票を照会する等といった、複数の戸籍の附票にまたがる同一個人を単位とした履歴の照会までは不要と考え、実装しない機能とした。
2.2.2 交付履歴照会
【実装すべき機能】
個人を特定した後に、1.3.5（交付履歴の管理）に規定する証明書の交付履歴(20.1.1.（戸籍の附票の写し）、20.1.2.（戸籍の附票の除票の写し）について、照会できること。
なお、照会に当たっては、1.3.5（交付履歴の管理）に規定する項目から行えること。
また、コンビニで交付された場合も同様に照会できること。
【考え方・理由】
住民記録システムに準ずる。
2.2.3 文字コード照会等
【実装すべき機能】
漢字文字の入力・照会については、拡大して入力・照会ができるとともに、文字コードの照会 ができること。
【考え方・理由】
住民記録システムに準ずる。
2.2.4 支援対象者照会
【実装すべき機能】
照会した支援対象者（併せて支援を求める者を含む。）の戸籍の附票データを確認する場合において、支援措置期間中又は仮支援措置期間中である旨が明示的に確認でき、1.1.13（支援対象者管理）の支援措置のデータベースに連携して、当該データベースの支援対象者の詳細情報が確認できること。
【考え方・理由】
住民記録システムに準ずる。
2.3 操作
2.3.1 キーボードのみの画面操作
【実装すべき機能】
端末のセキュリティを確保しながら、キーボードのみでも画面操作が可能であること。
【考え方・理由】
住民記録システムに準ずる。
3 抑止設定
3.1 異動・発行・照会抑止
【実装すべき機能】
支援対象者に対する抑止、排他制御（10.3参照）、その他の抑止を管理できること。
各抑止機能について、異動入力、証明書発行、照会などの処理ごとに、個人及び同一の戸籍の附票単位で、抑止（エラー、アラートは表示されるが、処理可又は処理可（抑止なし））の開始日及び終了日設定が可能であること。抑止が終了していない者について、抑止の一時解除ができること。また、抑止の一時解除については、庁内各システムで誤って本解除として扱われないように、コンビニ交付システムを含む庁内各システムへのデータ連携は不要とすること。
一時解除後、必要な処理が完了したら手動で 一時解除を元に戻し、失念していた場合は一定時間経過後に自動で抑止状態に戻ること。
抑止状態に戻るまでの時間を設定できること。
抑止・解除、又は一時解除できる権限は個別に設定できること。
なお、抑止の終了日を経過しても、抑止は自動的に終了しないこと。
戸籍情報システムから情報を連携させている場合は、戸籍情報システムにおいて戸籍届出による記載や修正等の処理を実施している際、異動中であるといった情報が連携され、抑止が実施されること。
検索結果の表示の際、抑止対象であることが明らかとなること。
抑止事由（支援措置、外字作成中、戸籍異動中等）を選択できること。
抑止については複数設定することができ、設定ごとに、抑止する処理・抑止レベル（エラー・アラート）の設定ができること。
証明書発行の抑止設定及び解除情報については、コンビニ交付に対しても自動連携されること。
【考え方・理由】
支援措置（3.2参照）の他、戸籍情報システムにおいて異動処理を実施している（戸籍異動中）等の事由の際、戸籍附票システムにおいても対となる戸籍の附票への抑止機能が必要となることから、個別に書き込むのではなく、まとめて整理した。
抑止設定及び解除については、個人単位又は同一の戸籍の附票単位いずれにも対応できることとし、市区町村が 選べるようにすることとした。
3.2 支援措置
【実装すべき機能】
支援対象者（併せて支援を求める者を含む。以下同じ。）が含まれる戸籍の附票の写し等の交付を実施しようとする際に、エラーとすることができること。また、支援措置責任者は、1.1.13（支援対象者管理）の支援措置のデータベースに連携して、当該データベースの支援対象者の詳細情報が確認できること。審査の結果、戸籍の附票の写し等の交付を行う場合には、エラーを解除できること。
戸籍附票システムとして支援措置に関する情報を得た場合には、戸籍附票システムから戸籍情報システムへ支援措置情報を連携できること。
また、戸籍の附票事務として支援措置の申出を受けた際、住所地と本籍地が同一市区町村である場合は、戸籍附票システムから住民記録システムへ連携できること。
支援措置の期間設定は、１年とし、支援措置の開始年月日を入力すると、支援措置の終了年月日が自動的に設定及び表示され、必要に応じて修正できること。
例）開始年月日が令和２年４月１日の場合、終了年月日が令和３年３月31日に自動的に設定される。
支援措置の延長については、支援措置の期間終了日の１か月前から、支援措置期間の延長処理を行えることとするともに、延長後の支援措置の期間は、延長前の支援措置の期間の終了日の翌日から起算して１年間設定できること。
なお、それに先立ち20.2.1.の支援措置期間終了通知を出力できること。また、支援措置の期間終了日の１か月前から、支援対象者の戸籍の附票を参照する際には、１か月以内に支援措置の期間が終了する旨のアラートを表示できること。
支援措置の期間が終了しても延長されないときは、支援対象者の戸籍の附票を表示する端末画面において、支援措置の期間が終了している旨のアラートを表示できること。
支援対象者から支援の終了を求める旨の申出を受けたとき、支援措置の期間を経過し、又は延長がされなかったときその他市区町村長が支援の必要性がなくなったと認めるときは、支援措置を終了できること。
申出がなされてから、支援措置の必要性を確認し、実際に支援措置を開始するまでの期間も、被害者保護のために、仮支援措置として支援対象者が含まれる戸籍の附票の写し等の交付を実施しようとする際に、エラーとすることができること。
また、仮支援措置については、自動的に解除されるものではないが、仮支援措置の状態のまま自治体の指定した日数を超過した対象者が存在する場合には、常時又は戸籍附票システム終了前にその旨を表示できること。
【実装してもしなくても良い機能】
支援の必要性について確認後、申出者に支援措置を開始する旨の通知を出力できること。
【考え方・理由】
支援対象者に係る戸籍の附票の写し等の交付は、慎重に行われる必要があるため、エラーを基本とし、 必要な審査を実施した上で、エラーを解除できることとする。要領第５-10-キで、支援措置の期間終了の１か月前から、支援措置の延長の申出を受ける旨規定されており、延長漏れを防止するため、延長受付期間にアラートを表示する機能を設けることとする。
また、3.1（異動・発行・照会抑止）にあるように、抑止の終了日を経過しても、抑止は自動的に終了しないこととしている。
なお、10.3（操作権限管理）において、利用者ごとの表示・閲覧項目及び実施処理の制御ができることとしており、各市区町村の支援措置に係る事務の実情に合わせて、利用者ごとに端末画面上での住所非表示とすることも妨げられていない。
また、要領５-10-ウの、申出者へ支援の必要性の確認の結果の連絡については、市区町村における支援措置の方針や処理件数により取るべき手段が異なることから、実装してもしなくても良い機能とした。
戸籍情報システムとの支援措置情報の連携については、住民記録システムから支援対象者管理データが連携された場合も含め、戸籍の附票で抑止措置がかかっている者であることを戸籍情報システムに連携することで、戸籍事務における証明書の発行の際の注意喚起につなげるため、連携できることを機能に盛り込んだ。
また、実態として、支援措置の申出の多くが住民記録事務として受理されると想定されるが、住所地と本籍地が異なる市区町村である場合には、戸籍の附票事務として受理するケースが想定される。さらに、住所地と本籍地が同一の市区町村の場合であっても戸籍の附票事務として受理する可能性があり、その場合には戸籍附票システムから住民記録システムへ支援措置情報を連携する必要があることから、住民記録システムに連携する機能を設けた。なお、住民記録システムから戸籍附票システム等への「住民記録データ（支援対象者管理データを含む）」の連携については、住民記録システム標準仕様書に規定されている。
4 異動
4.0.1 異動者
【実装すべき機能】
戸籍の附票の異動処理においては、当該異動処理の対象者の戸籍の附票が既に存在する場合については、対象者を戸籍の附票データから選択できること。その際、基本検索により個人又は戸籍の附票単位で検索できるものとし、戸籍の附票を検索し対象者を選択する場合は、戸籍の附票の全部（当該戸籍の附票の全員を異動者とすることをいう。）又は一部（当該戸籍の附票の一部を異動者とすることをいう。）を選択できること（対象者の選択から全部又は一部を自動判断することを含む。）。一部を選択する場合には、一人又は複数人の対象者を選択できること。
戸籍の附票の異動処理において、当該異動処理の対象者の戸籍の附票が存在しない場合については、異動者の情報を入力できること。
指定都市においては、異動者を操作者の属する行政区に戸籍の附票を置く者に限定することができること。
【考え方・理由】
戸籍の附票の異動については個人が単位であることから、個人単位で異動者を選択できること。また、戸籍の附票の全部や一部についても選択できることも必要である。
新規に戸籍の附票を作成する場合など、対象者の戸籍の附票が存在しない場合については、戸籍情報システムにおける戸籍の情報を確認しながら異動者の情報入力等を実施することを想定している。
4.0.2 異動日・処理日
【実装すべき機能】
異動処理においては、異動日及び処理日を入力できること。
異動日は、初期表示としては空欄とすること。
異動日は、転出を除き処理当日以前の日のみを入力できること。
処理日は、処理当日が自動入力されること。
【実装しない機能】
処理当日以外を処理日として入力できること。
【考え方・理由】
異動日・処理日の考え方は住民記録システムと同様であるため、住民記録システムに準ずる。
4.0.3 審査・決裁
【実装すべき機能】
異動処理の仮登録及び本登録を行えること。
異動入力した内容は仮登録状態として、審査（決裁）により本登録 とする。
仮登録状態の情報では、取消・修正等ができ、異動処理・証明発行・住基ネット回線を通じた連携については、抑止されること。
仮登録一覧は、画面に表示され、異動者が選択できること。また、常時又は戸籍附票システム終了前に仮登録状態の者が存在することを表示できること。
また、仮登録一覧は、全部、一部（選択異動者及び入力支所等を単位とした一部）ごとに表示・本登録できること。ただし、全部本登録については、件数に上限を掛けることができることとする。
【仮登録状態】
・ 異動情報がシステムに入力され、その内容がいったんシステム上に保存されているが、未審査又は審査中のため本登録状態に至っておらず、法上、戸籍の附票にまだ記載されていない状態
・ 異動処理が確定されておらず、異動履歴とならない状態
・ 戸籍の附票の写し発行時には、戸籍附票システムや他業務システム、又は、証明書のコンビニ交付において、仮登録中のデータに基づく証明書は発行できないようにする。
【本登録状態】
・ 異動情報がシステムに入力され、審査（決裁）を経てその内容がシステム上に保存されており、法上、戸籍の附票に記載されている状態
・ 異動処理が確定され、異動履歴となる状態
・ 確定情報となるため、証明書、住基ネット回線を通じた連携等に反映される。
【考え方・理由】
住民記録システムと同様、仮登録状態の情報については取消・修正が可能である。
ただし、仮登録状態の情報は取消・修正できることとしているが、戸籍情報システムにおいては取消事由（例：重婚や不適齢婚等）が含まれる届出を誤って受理した場合には当該届出の情報を取り消すことができないとされているため、戸籍情報システムとシステム構成を共有している場合において、戸籍情報システムにて取り消すことができない場合には戸籍附票システムにおいても同様の扱いとする。
住民票の写し等と比べ、記載事項が限られることや証明書の発行数が相対的に少ないことから、誤記のおそれが少ないため、審査（決裁）機能を設けなくともよいとの意見もいただいたが、責任者の審査（決裁）がないまま登録することは自治体による公証制度である以上想定されず、一定のプロセスや組織としての意思決定が必要であることから、審査（決裁）機能は実装すべき機能とする。
なお、審査（決裁）を実施する方法について本仕様書では規定しないが、仮登録の内容が妥当であるか責任者が確認するプロセスを経ること、また記録することで、「職員が単独で登録を完了する」ことが発生しない運用とすることが肝要である。審査（決裁）の実施者についても、不在時や繁忙期時等を想定し、システム上での処理は代決者が行うことも許容する。
4.0.4 入力確認・修正
【実装すべき機能】
更新前（仮登録状態）には、20.0.1（様式・帳票全般）に定める確認用帳票を画面確認又は印刷でき、入力内容を修正できること。
【考え方・理由】
住民記録システムと同様、審査・決裁機能を設けたことに伴い、当該機能を設ける。
また、「デジタル化に向けた基盤整備を行う」という本仕様書の目的（第１章２（２）参照）を踏まえ、入力内容の確認はペーパーレスで行うことを原則 とする。ただし、繁忙期や非常時等、紙での照合が必要となる場面もあることを想定し、基本はペーパーレス対応を推奨するが、紙での出力機能も実装することとした。
4.0.5 一括入力
【実装すべき機能】
同一のシステム利用者が、同一の戸籍の附票に記録されている複数人に同一の内容を入力する場合、対象を選択後、一括で入力できること。
異動日と異動履歴は自動的に適用されること。
本機能は、一般市区町村においては、実装してもしなくても良い。
【考え方・理由】
同一の戸籍の附票に記録されている複数人に同一の内容を入力する場合、一括入力することができることにより、入力作業を省力化する。
なお、権限及び情報セキュリティ等の観点から、履歴は、システム利用者（ID単位）ごとに保持することとする。（2.1 （検索機能）参照）
4.1 職権
法第18条に規定する職権による戸籍の附票の記載等に関する機能について記載する。
4.1.1 戸籍届出等に基づく戸籍の附票の職権記載等
【実装すべき機能】
戸籍届出等に基づき、戸籍届出等による記載、消除又は修正として、職権記載、職権消除及び職権修正の処理が行えること。
なお、戸籍法第24条第２項、第113条、第114条又は第116条の規定によって戸籍の記載が訂正された場合も、同様に職権記載、職権消除及び職権修正の処理が行えること。
【考え方・理由】
戸籍の附票の記載、消除又は記載の修正は、職権で行うものとする（法第18条）。
戸籍の附票は戸籍を単位に作成されているため、戸籍の異動に伴い戸籍の附票についても職権で記載、消除及び修正を行うことが考えられるため。
戸籍の附票においては消除となった者（戸籍の附票の除票を含む。）に関しての修正は許容しないため、戸籍情報システムにおいて除籍者について訂正がなされた場合は備考のその他欄に戸籍において訂正がなされた旨を記載すること（記載方法については20.0.6を参照のこと。）。
また、戸籍の附票においては戸籍における訂正概念が存在しないため、戸籍法第24条第２項、第113条、第114条又は第116条の規定によって戸籍の記載が訂正された場合には、職権記載、職権消除及び職権修正の処理が行えるものとしている。
4.1.2 在外選挙人名簿及び在外投票人名簿登録市区町村の異動
【実装すべき機能】
市区町村の選挙管理委員会からの法第17条の２第２項の通知や本籍地市区町村からの通知に基づき、在外選挙人名簿登録情報及び在外投票人名簿登録情報について職権記載等できること。
また、戸籍の附票への国内住所地の追加等に伴い、在外選挙人名簿登録情報又は在外投票人名簿登録情報の変更があった場合には、その旨を在外選挙人名簿登録市区町村又は在外投票人名簿登録市区町村に通知するための在外選挙人名簿及び在外投票人名簿登録者の戸籍又は戸籍の附票の変更通知書（20.2.2参照）を出力できること。
国民投票日の翌日に、当該国民投票のために登録された在外投票人名簿情報を戸籍の附票から削除することができること。
【実装してもしなくても良い機能】
在外選挙人名簿及び在外投票人名簿に登録されている者の一覧について出力できること。
【考え方・理由】
在外選挙人名簿又は在外投票人名簿への登録、移転、抹消等が発生した場合には、登録情報についての記載等が必要である。また、公職選挙法第30条の13第1項及び日本国憲法の改正手続に関する法律第43条第１項に基づき、在外選挙人名簿登録市区町村又は在外投票人名簿登録市区町村に通知するための通知書を作成する機能も必要である。なお、戸籍附票システムから出力する通知書については、国内住所地の追加等の戸籍の附票に起因する異動が発生した場合を想定している。
法第17条の２第１項の規定に基づく通知を受けて、戸籍の附票には、在外投票人名簿に登録された旨を記載しなければならない こととされている。しかし、国民投票の終了後、戸籍の附票において在外投票人である旨等の記載を保持し続ける必要性は乏しいことから、投票日翌日に各市町村で職権消除 することが適当であると判断した。なお、本取扱いについては、国民投票が実際に行われることとなった場合に、総務省から各市区町村長宛てにその趣旨を通知することとする。
在外選挙人名簿及び在外投票人名簿に登録されている者の一覧は、国内に住所を戻した際の通知の発行管理等に使用する市区町村も存在することから、実装してもしなくても良い機能とした。
4.1.3 CSから受信した戸籍の附票記載事項通知及び本籍転属通知の取込
【実装すべき機能】
CSから戸籍の附票記載事項通知（法第19条第１項）及び本籍転属通知（法第19条第３項）を受信した場合、職員の手を介することなく自動で通知を取り込むことができること。その際、通知の内容や自動で処理されない文字化け、オーバーフロー等の対応を職員が確認し、修正できること。
また、受信した通知に対する戸籍の附票記載事項通知取込エラー一覧表及び本籍転属通知取込エラー一覧表を作成・出力できること。
CSから受信した戸籍の附票記載事項通知及び本籍転属通知に外字が設定されていた場合、外字の字形や文字情報を出力できること。出力先は、戸籍の附票記載事項通知取込一覧表や本籍転属通知取込一覧表への出力、画面への出力など方法は指定しないが、職員の手を介することなくシステムで出力できること。
なお、受信し、反映されたデータの修正が必要な場合には、適宜修正を行えること。
【考え方・理由】
戸籍の附票記載事項通知に加え、デジタル手続法の施行に伴い戸籍照合通知（法第19条第２項）及び本籍転属通知についても電文としてCSから連携されるため、取込機能は必須。
職員の手を介することなく自動で取り込めるとは、CSから戸籍の附票記載事項通知又は本籍転属通知を受信した後、取込処理ボタン等を押すことにより、通知を1件ずつ処理するのではなく、取り込んだ通知の情報を一括して仮登録する機能を想定している。
4.1.4 誤記修正
【実装すべき機能】
誤記があった場合、職権修正として、修正ができること。
異動事由は、「誤記修正」とすること。
誤記があった異動の異動履歴は上書き修正せず、誤記修正の異動履歴とともに、異動履歴データとして保持すること。
【実装しない機能】
異動履歴を残さない上書き修正ができること。
【考え方・理由】
住民記録システムに準ずる。
4.2 異動の取消し
4.2.1 異動の取消し
【実装すべき機能】
4.1.3に規定する異動処理の取消しができること。そのため、取消しの対象となる異動処理を異動履歴データから選択できること。その際、4.0.1の例により、全部又は一部の区分により、対象者を選択できること。
異動の取消し機能は、最新履歴を削除する機能ではなく、履歴を上積みして、元の状態に復元できる機能とすること。復元した後、データ項目を追加する必要がある場合にあっては、その他職権修正により対応する。
具体的には、住民記録システムからCSを通じて連携される、戸籍に記載されている者の増減を伴わない記載事項の修正を実施する機能（異動の取消し（修正））を有すること。
取消処理については、それ自体を１つの異動処理として取り扱うこととし、「４異動」を適用するほか、取り消された異動処理及び取消処理を、ともに異動履歴データとして保持すること。
【考え方・理由】
住民記録システムからCSを通じて連携される異動の取消し（増・減・修正）については、戸籍附票システムにおいてはすべて異動の取消し（修正）に集約することができることから、異動の取消し（修正）の機能を設けることとした。
なお、4.1.1（戸籍届出等に基づく戸籍の附票の職権記載等）のとおり、戸籍法第24条第２項、第113条、第114条又は第116条の規定によって戸籍の記載が訂正された場合には、異動の取消しを行うのではなく、職権記載、職権消除及び職権修正の処理が行えるものとしている。
5 証明
5.1 証明書記載事項
【実装すべき機能】
証明書（戸籍の附票の写し及び戸籍の附票の除票の写し）を発行する際は、同一の戸籍の附票の全員分又は一部の者について選択できること。
また、本籍・筆頭者、住民票コード、在外選挙人名簿登録市区町村名、在外投票人名簿登録市区町村名等はデフォルトで省略とすること。
支援措置対象者に係る住所（必要な手続を経て抑止の一時解除をし、支援対象者を含む戸籍の附票の写し等を出力する場合）等の省略ができること。イメージデータにて管理している場合においても、本籍・筆頭者、在外選挙人名簿登録市区町村名、支援措置対象者に係る住所（必要な手続を経て抑止の一時解除をし、支援対象者を含む戸籍の附票の写し等を出力する場合）等を省略（マスキング）ができること。
特別の請求又は必要である旨の申出がある場合には記載の選択ができること。（特別の請求又は必要である旨の申出を受けて、市区町村長の判断により記載するかしないかを選択し、記載を選択した場合の記載方法については、20.0.3（備考欄（異動履歴）の記載）を参照すること。）
消除となった者の記載事項及び備考欄に誤記があることが判明した場合、備考欄に誤記である旨及び正しい記載等を入力し、証明書に出力すること。ただし、特別の請求又は必要である旨の申出に基づき市区町村長の判断で表示する項目に関する誤記である旨及び正しい記載等については、デフォルトでは省略とし、市区町村長の判断で当該項目自体を表示する場合にのみ出力すること。また、消除となった者が筆頭者であり、当該者が消除された後に戸籍届出等による修正により戸籍の表示としての筆頭者氏名欄の氏に変更が生じた場合、特別の請求又は必要である旨の申出に基づき市区町村長の判断で戸籍の表示（本籍・筆頭者）について表示する際には、備考欄に戸籍の表示における筆頭者氏名欄の氏変更の異動履歴を必ず記載すること（記載方法については、20.0.3(備考欄（異動履歴の記載）を参照すること。)）。
証明書には、認証文（第４章に記載のもの）、電子公印及び発行番号を出力すること。
証明書の様式については、第４章に定める様式とすること。
証明書が複葉にわたる場合は、最終ページのみに認証文が印字されること。
また、生年月日は和暦で出力すること。住所を定めた年月日について、証明書出力時は和暦で出力すること。
なお、デジタル手続法第９号施行日前に消除となった者において、戸籍の附票の写し等に性別及び生年月日を記載しないこと。また、デジタル手続法第10号施行日前に消除となった者について、戸籍の附票の写し等に住民票コードを記載しないこと。
【考え方・理由】
認証文の位置については、「当該戸籍の附票の写しの末尾に原本と相違ない旨を記載しなければならない」（令第21条第２項の規定により読み替えて準用する令第15条）と明記されているため、最終ページのみに印字されることとしている。
5.2 同一の戸籍の附票の者の並び順
【実装すべき機能】
戸籍の附票の写しにおいて、同一の戸籍の附票の者の記載順序は、戸籍に記載されている順序と同一となること。
戸籍の記載順序については、戸籍法第14条にて定められたとおり。
第十四条氏名を記載するには、左の順序による。
第一夫婦が、夫の氏を称するときは夫、妻の氏を称するときは妻
第二配偶者
第三子
②子の間では、出生の前後による。
③戸籍を編製した後にその戸籍に入るべき原因が生じた者については、戸籍の末尾にこれを記載する。
【実装しない機能】
同一の戸籍の附票の者の記載順序を変更可能とすること。
【考え方・理由】
戸籍の附票の写しの記載順序については、従来より戸籍と同時に管理されていたことから、戸籍と同じ並び順となるため、戸籍の記載順序と同一となることとしている。
5.3 方書の記載
【実装すべき機能】
住所に方書が含まれる場合は、省略せず、証明書に記載すること。
【考え方・理由】
住民記録システムにおいて方書を含めて証明書に記載していることから、戸籍の附票の写しにおいても同様とする。
5.4 発行番号
【実装すべき機能】
枚葉（まいよう、全部のページの意味）に発行年月日、市区町村名、発行端末番号、発行された順に付された番号、ページ番号及び総ページ数を証明書に記載できること。
【実装しない機能】
発行場所を証明書に記載できること。
【考え方・理由】
数葉にわたる証明書の加除を防止するための必要な措置として、総務省質疑応答（平成18年１月24日総行市第12号）にて、戸籍の附票の枚葉に発行年月日、市町村名、発行端末番号、発行番号、ページ番号及び総ページ数を印刷することとして差し支えないとされた。
なお、発行場所を証明書に記載する機能については、市区町村名と発行端末番号により発行場所が分かるため不要とする。
5.5 公印・職名の印字
【実装すべき機能】
システムから出力される公印印字に対応する証明書等には、証明書ごとに、市区町村長又は職務代理者の職名・氏名、公印印字の有無及び公印の種類（市区町村長又は職務代理者の印）が選択できること。また、市区町村長又は職務代理者の職名を印字する場合は、指定都市・特別区の場合も含め、都道府県名を印字すること。
なお、公印は電子公印に対応し、種類（市区町村長又は職務代理者の印、証明書専用の印、カード券面用の印）が選択できること。また、「公印省略」「この印は黒色です」等の任意の固定文言が印字できること。
【考え方・理由】
各市区町村では文書管理規程等により、公文書には公印を押印することが定められており、戸籍の附票の写しは公文書に当たるため、公印が必要。磁気ディスクをもって調製された戸籍の附票の写しには電子印の使用が認められているので、戸籍の附票の写しに押印する電子印の管理機能が必要 となる。
また、公印の種類は２種類以上管理できることとした方が良い（証明書専用印など有り）。
5.6 公用表示
【実装すべき機能】
証明書に「公用」の表示（印字）ができること。
【実装しない機能】
証明書に「規定により免除」と表示できること。
【考え方・理由】
証明書に「公用」と表示（印字）することは、本人等の請求や第三者からの申出による証明書等の交付と区別する上で必要といえるため実装すべき機能とした。
5.7 文字溢れ対応
【実装すべき機能】
システムから出力される証明書等の出力項目に文字溢れが発生した場合は、文字の大きさを調整するなどして、文字超過とならないようすること。
なお、文字数が多くやむをえず文字溢れが生じる場合や、未登録外字が含まれる場合は、アラートを表示して注意喚起するとともに、文字超過リストを出力して、文字溢れした情報を確認できるようにすること。ただし、証明書については、出力時に文字溢れしている旨のアラートを表示し、パラメータ設定によって、該当項目を限界まで出力させるか空白で出力するか選択できる こと。
【考え方・理由】
証明書のみ中間標準レイアウトに準拠した文字超過表記とする旨とした。
証明書に正しく印字されない文字溢れや未登録外字については、職員に注意喚起し、手動で修正や確認等、個別に対応する必要がある ため。
6 統計
6.1 統計
【実装すべき機能】
毎年、総務省通知（平成26年12月25日付け総行住第136号）に基づき総務省が実施している「住民基本台帳関係年報」の調査項目である、戸籍の附票事務処理状況及び戸籍の附票の写し（戸籍の附票の除票の写しを含む）の通数の算出やその検証のための統計機能を有していること。
システム移行においては、標準準拠システム稼働月以降の集計ができること（標準準拠システム稼働月以前の集計は、従来のシステムで行うこと。）。
【考え方・理由】
住民記録システムに準じ、総務省の実施する「住民基本台帳関係年報」の調査に対応するための統計機能を実装すべき機能とした。
7 連携
7.1CS連携
7.1.1 CSへの自動送信
【実装すべき機能】
職権による記載等の異動時等に、「戸籍附票システム改造仕様書」の電文仕様に基づき、各電文がCSに自動送信 されること（4.1.3（CSから受信した戸籍の附票記載事項通知及び本籍転属通知の取込等）参照）。
なお、送信方法（回線や媒体）や送信のタイミングは定めないが、異動の時系列は担保されること。
住基ネット共同利用に対応し、住基ネットCSサーバ（附票AP）で受信した電文を、構成自治体に振り分ける機能を有すること。
その他、以下について実行できること。
・CSに対する符号の生成要求の自動送受信ができること
・送信した附票本人確認情報、住民票コード照会情報、戸籍照合通知（法第19条第２項）情報、本籍転属通知（法第19条第３項）情報の照会及び一覧表への印字ができること （指定都市においては、一覧表は行政区単位で分割できること）
・送信した附票本人確認情報、住民票コード照会情報、戸籍照合通知情報、本籍転属通知情報の再送信、再送信の際は異動事由を変更して送信できること
・CSとの疎通状況を確認できること
・送信データを手入力でも補完でき、送信できること
・一時的に手動連携に切り替えることができること
・住民基本台帳ネットワークシステム統一文字 （以下「住基ネット統一文字」という。）との変換が管理できること
・CSへ連携できなかった場合のエラー表示ができること・その他、戸籍附票システム改造仕様書最新版に記載されている機能を実行できること
【考え方・理由】
CSへの連携方式として、自動連携方式と手動連携方式があるが、標準仕様書では自動連携方式を想定する。
指定都市においては、作業の効率化の観点から、一覧表について行政区単位で分割できることとする。
CSとの接続構成は、J-LISより示されている接続構成パターンに準じた形を想定する。
7.1.2 附票本人確認情報との整合性確認
【実装すべき機能】
CS側の附票本人確認情報との整合性を、定期的に確認できること。
【考え方・理由】
戸籍附票システム改造仕様書において「戸籍附票システムが送信した附票本人確認情報登録通知電文及び附票本人確認情報更新要求電文の送信件数と、附票APで左記電文を受信し附票本人確認情報を更新した処理件数を比較チェック する」こととされているため、機能を規定した。
7.2庁内他業務連携
7.2.1 住民記録システムとの連携
【実装しない機能】
本籍地と住所地が同一の市区町村の者管内住所人の異動時において、住所情報や住民票コードの情報を住民記録システムから直接受信できること。
【考え方・理由】
住民記録システムが戸籍附票システムと直接連携している市区町村と、CSを介して戸籍附票システムと連携している市区町村があるが、デジタル手続法第10号施行日以降は、戸籍附票システムはCSからデータを受信することができる機能（4.1.3、7.1.1参照）があれば十分なので、住所情報及び住民票コードが住民記録システムから直接戸籍附票システムに連携されることのできる機能は実装しないこととする。
なお、本籍地と住所地が同一の市区町村の者について、戸籍の附票の記載事項と住民票の記載事項の整合性を確認する方法としては、戸籍附票システムと住民記録システムそれぞれのEUC機能 （戸籍附票システムのEUC機能は10.1(EUC機能ほか)参照）を用いて、本籍地と住所地が同一の市区町村の者の情報を抽出し、突合することを想定している。また、住民記録システムから本籍地が同一の市区町村の者の最新の情報を戸籍附票記載事項通知の形でCSを通じて送信し、それをCSから戸籍附票システムでデータを受信しデータベースと突合することにより行うことも想定される。
7.2.2 個人番号カードによる証明書等の交付
【実装すべき機能】
広域交付システムインタフェース仕様書に基づく端末における証明書交付に対応していること。当該端末における証明書交付履歴を管理できること。
公的個人認証サービスを用いた証明書等の電子申請に対応していること。
【考え方・理由】
コンビニ交付をはじめとする個人番号カードによる証明書等の交付に対応するため、戸籍附票システムから電子申請受付システムにデータ連携を行う機能又は戸籍附票システム側で広域交付システムインタフェース仕様書に基づいた電文、証明書PDFを出力する機能を有することとする。
また、コンビニ交付以外のオンラインによる証明書等の申請に対応するため、公的個人認証サービスを用いた電子申請に対応できる機能を有することとする。なお、当該機能を有するシステムを別途、構築している場合には、当該システムと必要な情報を連携できる機能を有することとする。
8 実装してもしなくても良い機能
8.1本人通知
8.1.1 登録管理
【実装してもしなくても良い機能】
「本人通知」の申出内容について、登録・管理できること。
また、登録期間が満了する者について、本人通知期間満了のお知らせが出力できること。
対象の証明書は、窓口で交付した「戸籍の附票の写し」及び「戸籍の附票の除票の写し」とし、証明書を発行する際に、交付記録として発行日・交付請求者区分（本人、代理人、第三者）・証明書種別・枚数の記録（登録）ができること。また、証明書発行後に修正（交付請求者の選択誤りを修正）ができること。
【考え方・理由】
住民記録システムに準ずる。
8.1.2 画面表示
【実装してもしなくても良い機能】
「本人通知」の事前登録者の戸籍の附票の写し等が交付される際、画面確認できること。
【考え方・理由】
住民記録システムに準ずる。
8.1.3 通知書出力
【実装してもしなくても良い機能】
証明書発行履歴を基に本人あて又は申請者あての戸籍の附票の写し等の交付通知書（発行日・請求者区分・証明書種別・枚数）が出力できること。
なお、出力条件として、「本人通知の事前登録者への交付」、「本人通知の事前登録者への交付（申請者が本人の交付記録は除く）」、「事前登録に関わらず申請者情報（第三者への交付や委任状による交付）による判定」が選択可能 であること。
【考え方・理由】
住民記録システムに準ずる。
9 バッチ
9.1 バッチ処理
【実装すべき機能】
バッチ処理の実行（起動）方法 として、直接起動だけでなく、年月日及び時分、毎日、毎週○曜日、毎月ＸＸ日、毎月末を指定した方法（スケジュール管理による起動）が提供されること。スケジュール管理にソフトウェア製品を利用する場合は名称、メーカー、バージョンなどについて、発注者からの要求があった場合、提示すること。
また、バッチ処理の実行時は、前回処理時に設定したパラメータが参照 されること。
なお、前回設定のパラメータは、一部修正ができること。修正パラメータ個所については、修正した旨が判別し易くなっていること。
大量処理を行う場合でもオンライン処理に影響が出ないこと。
全てのバッチ処理の実行結果（処理内容や処理結果、処理時間、処理端末名称、正常又は異常の旨、異常終了した際はOSやミドルウェア等から出力されるエラーコード等）が出力 されること。また、異常終了した場合の警告を戸籍附票システム内又は自治体が別途利用する他の通報システムに連携できること。
また、例えば6.1で記載した統計についてバッチの実行結果から一連の作業で最終的な提出物をXLSX形式等で作成する場合等には、自動実行する仕組み を用意すること。
【考え方・理由】
バッチ処理の実行方法には、直接起動方法のほか、ジョブスケジューラーから実行される「同期実行」、イベント駆動型である「非同期実行」がある。
戸籍附票システムにおいては、他システム間連携等のイベント発生による実行（非同期実行）は一般的に用いられないことから、全てのバッチ処理が「同期実行」できることが必要となる。
また、バッチ処理で異常が発生した場合はリカバリが必要となることから、リカバリを効率化するための実行結果の出力は必須である。
製品によっては、システムによりExcel形式で作成可能なものや、CSVだけ作成し、あとはオペレーションで行うものもあるため、機能要件を合わせるために記載。
なお、ベンダは、構築環境等によらず提供製品についての情報を顧客である市区町村に開示、説明する義務があり、市区町村側もミドルウェアの情報に限らず把握しておく必要がある。
修正パラメータ個所は判別しやすい必要があるが、アクセシビリティの観点から、色での識別等の方法は規定しない。
9.2 抑止対象者
【実装すべき機能】
抑止対象者一覧を作成できること。
【考え方・理由】
住民記録システムに準ずる。
10 共通
10.1 EUC機能ほか
【実装すべき機能】
EUC専用のデータソースが整備されていること。データソースは、戸籍の附票の異動履歴や除票データを含む戸籍附票システムで取り扱う全てのデータを対象とすること。
これらの機能等によって、データの抽出・分析・加工及びそれらの出力等について、以下のとおり提供されること。
【データソース】
「中間標準レイアウト仕様（戸籍）」の「データ項目一覧表」に記載のあるデータ項目のうち、戸籍附票システムで取り扱うものに限って、データソースとして参照できること。
各データ項目については、「データ項目一覧表」における「データ項目名称」として参照できること。
また、各データ項目の「データ型」、「桁数」、「外字使用（外字使用の有無）」、「コード」の仕様については、「データ項目一覧表」の記載内容（各データ項目の仕様）に従うこと。
「中間標準レイアウト仕様（戸籍）」 の「データ項目一覧表」に記載のないデータ項目であっても、１（管理項目）において管理し、又は２（検索・照会・操作）において検索・照会・操作できることとしている項目（例：異動履歴、証明書の交付履歴）については、データソースとして参照できること。
これらのデータソースは、物理的なEUC専用のデータソース又は仮想的なデータソース等として提供すること。
【データ抽出・分析・加工】
データソースに対しては、検索条件が指定できるとともに、当該条件によるデータの抽出ができること。また、その検索条件を履歴として残すことができ、一部の条件を変更して再利用ができること。さらに、一般的な演算子（+,=,>,!=,&,++,–他、各種演算を表わす記号・シンボル）及び一般的に流通している表計算ソフトウェアやデータベースソフトウェアで用いられる一般的な関数を用いたデータの抽出・分析・加工等ができること。また、大量抽出等した場合であっても、オンライン処理に影響が出ないこと。
なお、一般的な演算子や関数を用いる方式については、演算子等を直接記述・指定するもののほか、特別の知識のない職員であってもデータの抽出・分析・加工等ができるよう（設定項目を提示して選択や入力を促し）、対話的に処理を進める操作方式（ウィザード）も提供すること。
抽出については、指定した条件に該当する者の情報（氏名、本籍等）、該当者数、該当する戸籍の附票数いずれも対応可能であること。
【データ出力】
抽出・分析・加工したデータに対して、XML形式やCSV形式として、データの出力ができること。
また、リスト形式及び宛名形式でのディスプレイや紙等への出力（ディスプレイ表示、プリンターでの印刷等）及びPDF形式でのファイル保存もできること。
これらのデータ並びにリスト形式及び宛名形式での出力については、大量処理の場合であっても、オンライン処理に影響が出ないこと。
そして、特別の知識のない職員であってもデータ並びにリスト形式及び宛名形式での出力に関わる操作ができるよう（設定項目を提示して選択や入力を促し）、対話的に処理を進める操作方式（ウィザード）も提供すること。
なお、データ項目を出力する際は、30.2（文字）に規定する要件に従うこと。
【考え方・理由】
戸籍附票システムをノンカスタマイズ前提に標準化するためには、全ての市区町村で求められる機能を実装することが理想である。一方で、自治事務である戸籍の附票事務においては（団体ごとの多様性があることから）、全国の市区町村が求める機能の全てを網羅することは、コスト等の観点から現実的ではない。
そこで、EUC機能によって、非定型業務（戸籍附票システム標準仕様で当該機能が提供されていない業務）、市区町村ごとの独自業務及び各都道府県で実施する独自の統計調査や整合性確認等に対して、ノンカスタマイズで対応できるようにすることは、以下標準仕様の目的（自治体システム等の標準化を推進する目的）にも資する。
（目的１）カスタマイズを原則不要にする。
⇒非定型業務及び独自業務等によるシステムのカスタマイズが抑制できる。
（目的２）ベンダ間での円滑なシステム更改を可能にする。
⇒システム移行に関わる元データの確認・検査等のコストが縮減できる。
（目的３）自治体行政のデジタル化に向けた基盤整備を行う。
⇒オープンデータ等に対応するコストが縮減できる。
なお、デジタル庁を中心に検討中の「データ要件・連携要件」の検討次第で本規定については見直しを行う。
戸籍附票システム自体に実装を求めるものはないが、操作方式については、操作説明書（オペレーションマニュアルの類）によって別途提供されることが必要である。その際、以下の帳票を作成することを操作例として含めるよう留意すること。
・支援対象者の一覧
・選択した個人の証明書発行履歴の一覧
○技術的基準
第８戸籍の附票システムの安全な管理等
３戸籍の附票システムの管理
(2)ファイルの不当な使用の防止等
ファイルの使用者の資格を明確に定めることとし、資格を持たない者による使用を制限すること等、ファイルの使用の管理及び不当な使用の検知について必要な措置を講ずること。
(3)データ等の取扱い及び管理に際してのエラー及び不正行為の防止
データ、プログラム及びドキュメントについては、特定の者が管理すること、定められた場所に保管すること、受渡し及び保管に関し必要な事項を記録すること、使用、複写、消去及び廃棄は責任者の承認を得て行うとともにその記録を作成すること等その取扱い及び管理の方法を明確にすること。
○技術的基準
第８戸籍の附票システムの安全な管理等
４端末機操作の管理
(2)端末機の操作者の確認
ア戸籍の附票システムの運用に際しては、パスワード、識別カード又はこれらと同等以上のものと認められる方法により資格の確認を行うこと。
イ（略）
(3)ファイルに対する利用制限
端末機の操作者ごとに利用可能なファイルを設定する等、ファイルの利用を制限する方法を定めること。
(4)（略）
(5)強制的に終了する機能
端末機には、複数回のアクセスの失敗に対して、強制的に終了する機能を設けること。
10.2 アクセスログ管理
【実装すべき機能】
＜ログの取得＞
個人情報や機密情報の漏えいを防ぐために、システムの利用者及び管理者に対して、以下のログを取得すること（IaaS事業者がログについての責任を負っている場合等、パッケージベンダ自体がログを提供できない場合は、IaaS事業者と協議する等により、何らかの形で本機能が市区町村に提供されるようにすること）。
・ 操作ログ
取得対象：①照会、②帳票発行、③異動入力（履歴追加）、④異動入力（履歴修正）、⑤異動入力（履歴削除）、⑥バッチ処理（帳票作成）、⑦バッチ処理（データ更新）、⑧画面ハードコピー、⑨データ抽出（EUC）
※③から⑤までについては、仮登録及び本登録両方の操作ログを取得できること。
記録対象：操作者ID、日時、ファイル名、端末名、オンラインの場合は対象となったレコード（処理対象者等）・機能名・画面名、バッチについては処理名、処理・交付場所
・ 認証ログ
ログイン及びログインのエラー回数等
・ イベントログ
戸籍附票システム内で起こった特定の現象・動作の記録。異常イベントやデータベースへのアクセス等のセキュリティに関わる情報
・ 通信ログ
WebサーバやWebアプリケーションサーバ、データベースサーバ等との通信エラー等
・ 印刷ログ
印刷者ID、印刷日時、対象ファイル名、印刷プリンタ（又は印刷端末名）、タイトル、枚数、公印出力の有無、出力形式（プレビュー、印刷、ファイル出力等）、証明書の場合には発行番号等の情報
・ 設定変更ログ
管理者による設定変更時の情報
・ エラーログ
戸籍附票システム上でエラーが発生した際の記録。管理者による設定変更時の情報
取得したログは、市区町村が定める期間保管するとともに、オンラインでの検索・抽出・照会が簡単にできること。
なお、システム利用者や第三者によるログの改ざんがされないよう、書き込み禁止等の改ざん防止措置がされること。
＜ログの分析＞
システムの利用者及び管理者のログについては、以下の分析例の観点等から分析・ファイル出力が作成できること（IaaS事業者がログについての責任を負っている場合等、パッケージベンダ自体がログを提供できない場合は、IaaS事業者と協議する等により、何らかの形で本機能が市区町村に提供されるようにすること）。
[分析例]
・深夜・休業日におけるアクセス一覧
・ログイン失敗一覧
・ID別ログイン数一覧
・大量検索実行一覧
・戸籍附票宛名番号等から該当者の検索実行一覧
【考え方・理由】
ログの保管期間は、各市区町村の開示請求の対応期間と同じであることが望ましい。ログの容量は大きくなるため、期間が長いほどディスク容量を占めることになる。
保管期間を指定する理由を明示することによって、クラウド環境下等において長期的にログを残したい自治体に対する追加課金等の理由も明確になる。
なお、印刷ログについては、プリンタ名では印刷場所の特定が困難な場合があるため、その場合は省略することも、印刷端末名をもって代えることも可とすることとした。
10.3 操作権限管理
【実装すべき機能】
発注者のシステム操作権限ポリシーに基づき、システムの利用者及び管理者に対して、個人単位でID及びパスワード、利用者名称、所属部署名称、操作権限（異動処理や表示・閲覧等の権限）、利用範囲及び期間が管理できること。
職員のシステム利用権限管理ができ、利用者とパスワードを登録し利用権限レベルが設定できること。
操作者IDとパスワードにより認証ができ、パスワードは利用者による変更、システム管理者による初期化ができること。認証に当たっては、シングル・サイン・オンが使用できること。
アクセス権限の付与は、組織単位、利用者単位で設定できること。
アクセス権限の設定はシステム管理者により設定できること。
アクセス権限の付与も含めたユーザ情報の登録・変更・削除はスケジューラ―に設定し、事前に準備ができること。
また、事務分掌による利用者ごとの表示・閲覧項目及び実施処理の制御ができること。
他の職員が戸籍附票情報の入力・異動作業をしている間は、同一個人の情報について、閲覧以外の作業ができないよう、排他制御ができること。
なお、操作権限管理については、操作権限一覧表での管理及びそれらに基づく利用者別の各種制御ができること。
例：1.1.13（支援対象者管理）、2.2.4（支援対象者照会）、9.1（バッチ処理）、
10.1 （EUC機能他）、10.2（アクセスログ管理）10.3（操作権限管理）、10.4（操作権限設定）の操作権限は、それぞれ独立して制御 ができること。
操作権限はバッチ処理で一括メンテナンスできること。
IDパスワードによる認証に加え、ICカードや静脈認証等の生体認証を用いた二要素認証 に対応すること。
複数回のアクセスの失敗に対して、アクセス禁止状態にできること。
【実装しない機能】
職位・職権単位でアクセス権限を設定できること。
【考え方・理由】
個人情報や機微情報を取り扱う戸籍附票システムでは、システムの利用者及び管理者の個人単位での操作権限の管理が必要であるとともに、なりすまし利用を防止するため二要素認証を利用可能とする（グループ利用や非常勤職員等が同一IDを共用することは禁止）。
操作権限は、個々のシステムの利用者及び管理者を特定することが必要となるため、必ず、利用者個人を単位としたID及びパスワードを付与する。なお、全ての操作権限は、個々のIDに紐づくことになる。
アクセス権限を利用者単位で設定できれば、職位・職権単位でも設定できるため、独自の機能として職位・職権単位で設定できる機能は不要。
なお、人事異動の際のメンテナンスの負荷軽減を考慮し、操作権限はバッチ処理で一括メンテナンスできることとする（テキストデータを元にシステムで一括更新可能など）。
操作権限管理（認証等含む）は戸籍情報システムの一部として戸籍の附票が管理されている場合は、戸籍附票システム独自の機能として実装することが難しく、戸籍情報システムの機能を利用する想定としている。
10.4 操作権限設定
【実装すべき機能】
システムの利用者及び管理者に対する個人単位での操作権限においては、異動・証明を含む全ての画面にて、「戸籍の表示（本籍・筆頭者）」、「住民票コード」の項目を表示又は非表示に設定できること。（支援対象者の権限設定については10.3（操作権限設定）を参照）
【考え方・理由】
戸籍の附票の記載事項には住民票コード、戸籍に関する情報が含まれているが、これらの項目については、処理担当者によっては必ずしも必要な情報ではないため、照会画面において、これらを利用することができるシステムの利用者及び管理者といった権限者に応じて、個人単位で一定の操作権限設定を行えることとする。
10.5 ヘルプ機能
【実装すべき機能】
システムの操作方法や運用方法等について、マニュアルを有していること。
また、ヘルプ機能として、操作画面上から、当該画面の機能説明・操作方法等が確認できるオンラインマニュアル（画面上に表示されるマニュアル類）が提供されること。
【実装しない機能】
システムの操作方法や運用方法等について、冊子のマニュアルを有していること。
【考え方・理由】
市区町村によっては冊子のマニュアルが使用されているが、オンラインマニュアルで代替できるため、不要とする。
オンラインマニュアルは、システムの操作中に、キーワード検索などによって、知りたい情報に容易にアクセスできる。
オンラインマニュアルの一部として、Ｑ＆Ａ（よくある質問＆回答）集が提供されることが望ましい。
10.6 中間標準レイアウト仕様での出力
【実装すべき機能】
「中間標準レイアウト仕様（戸籍）」で定義された表形式（移行ファイル構成表、移行ファイル関連図、データ項目一覧表、コード構成表、コード一覧）、XML形式又はCSV形式（レイアウト仕様） に準拠したデータ抽出機能が提供されること。また、中間標準レイアウト仕様以外で保有するデータがある場合は、同様に提供されること。
なお、システム契約期間の終了時には、その時点での「中間標準レイアウト仕様（戸籍の最新バージョン）」で定義された表形式、XML形式又はCSV形式でデータ提供ができること。なお、中間標準レイアウトにおいて法改正等に対して未反映部分が存在する場合は、未反映部分を補い、データ提供ができること。
【考え方・理由】
住民記録システムに準ずる。
戸籍の附票は中間標準レイアウトの戸籍ユニットに含まれるものの、戸籍の附票単独でデータ移行することは考えづらいため、戸籍の移行と合わせて中間標準レイアウト仕様でデータを抽出することを想定している。なお、デジタル庁を中心に検討中の「データ要件・連携要件」の検討次第で本規定については見直しを行う。
10.7 印刷
【実装すべき機能】
証明書を発行する際にプリンタやトレー（ホッパ） の指定ができること。
出力部数を設定できること。
帳票発行時にプレビュー機能を保有すること。
帳票発行時にPDFか紙出力が指定でき、プリンタが指定できること。なお、デフォルトでPDFか紙出力かを設定できることとしても可能とする。
戸籍附票システム内部でアクセスログの取得が可能な形で、表示画面のハードコピー機能及びハードコピーの印刷機能を有すること。
氏名や住所等の印刷域桁数を超過したものについては、帳票発行時に超過内容を記載したリストを出力できること。
【実装しない機能】
アクセスログが取得できないOS独自の印刷ができること。
【考え方・理由】
住民記録システムに準ずる。
10.8 CSV形式のデータの取込(P)
【実装すべき機能】
証明書の発行処理を行う際、CSV形式で提供された以下のデータを取り込めること。その際、任意の方法でCSV形式になったデータを取り込むことができればよい。
・戸籍の附票の写し等の証明書の交付申請書に記載されたデータ
【考え方・理由】
今後、マイナポータルからのオンライン申請が戸籍の附票の写しにも拡充されていった場合等における、申請情報の取込機能を想定している。
11 エラー・アラート項目
11.1 エラー・アラート項目
【実装すべき機能】
論理的に成立し得ない入力その他の抑止すべき入力等（少なくとも「エラー項目一覧」に記載のもの）は、エラー（※）として抑止すること。エラーは、当該内容で本登録することを抑止することが目的であり、その実装方法として、エラーメッセージを表示し、次の画面に進めないようにすることも、エラーメッセージの表示によらず、そもそも入力不可とすることで対応することも差し支えない。また、仮登録段階でエラーメッセージを表示して抑止することも、本登録段階でエラーメッセージを表示して抑止することも、いずれもエラーの実装方法として許容される。
論理的には成立するが特に注意を要する入力等（少なくとも「アラート項目一覧」に記載のもの）は、アラート（※）として注意喚起すること。
※エラー：論理的に成立し得ない入力その他の抑止すべき入力等について、抑止すべき原因が解消されるまで、当該入力等を確定（本登録）できないもの
※アラート：論理的には成立するが特に注意を要する入力等について、注意喚起の表示を経た上で、当該入力等を確定できるもの
エラー・アラートとする場合は、原因となったエラー・アラート項目と理由・対応方法を入力者に適切に伝えること。
戸籍情報システムのエラー・アラート機能のうち、戸籍附票システムにおいても該当する項目についてはそれに準拠すること。
【考え方・理由】
標準化に当たっては、論理的に成立し得ない入力その他の抑止すべき入力等を抑止するためのものをエラー、論理的には成立するが特に注意を要する入力等に注意喚起するものをアラートとし、その両方について、抑止・注意喚起すべき場面を整理して、標準仕様書に盛り込む。ただし、具体的なエラーメッセージの文言やそれを表示する場面等、エラー・アラートをシステム入力者等に伝える方法については、画面遷移の体系や入力確認の方法等によっても異なるため、標準仕様として規定しない。
戸籍附票システムでは戸籍情報システムと同様のデータ項目や機能を扱っている部分があり、エラーやアラートについても同様のものが必要であるため、それらのデータ項目や機能で戸籍附票システムにおいても該当する項目については戸籍情報システムで定義されているエラー・アラート項目に準拠することとした。
○エラー項目一覧エラー番号 エラー項目 （参考）表示メッセージ例 ※本仕様書では規定しないが参考までに一例を示す 関係する 機能要件 番号 1 戸籍附票システム内のデータにおいて、住民票コードが一致する者がいた場合 住民票コードが既に登録されています。住民票コードの入力ミス又は二重戸籍等特殊な状況にある可能性があります。確認してください。 1.1.1 2 消除となった者について内容の変更をする場合 消除となった者については情報の変更ができません。誤記等が判明した場合は備考欄に追記してください。 1.1.1 3 住民票コードのチェックデジットが不正の場合 住民票コードのチェックデジットが違います。 1.1.1 4 異動入力において、必須項目を入力せずに確定する場合 ○○が入力されていません。 1.1.5 5 異動事由が消除の事由又は修正の事由で対象者が存在しない場合 異動対象者が存在しません。異動内容を確認してください。 1.2.2 6 他の文字を入力せずに「＊」（ワイルドカード）のみ入力して検索を実行した場合 「＊」のみで検索はできません。他の文字を入力したうえで実行してください。 2.1.1 7 抑止対象者を選択した場合 抑止対象者です。選択できません。 3.1 8 抑止対象者を特定する検索をした場合 取扱注意者、又はその同一戸籍の者の情報ですので表示できません。 抑止対象者であり、証明書等発行する場合は戸籍担当まで連絡してください。また発行後は再度連絡をお願いします。 3.1
