--- type: other title: 第３章 機能・帳票要件 source: 自治体システム等標準化検討会 profile: mrlgss-doc/0.1 business_code: "026" version: "1.5" spec_date: 2026-01-01 --- # 第３章 機能・帳票要件 本章の構成は、以下のとおりである。 表3-1 機能・帳票要件の構成

構成

内容
１．機能・帳票要件

機能・帳票要件における考え方及び事業ごとに必要となる機能要件・帳票要件を定義する。

※帳票要件は出力対象帳票のみ定義
２．帳票詳細要件

機能・帳票要件で示した帳票について、システム印字項目等を定義する。

また、帳票詳細要件で定義した帳票のレイアウトを示す。
## １．機能・帳票要件 機能・帳票要件の具体的な要件は以下の事業について「（別紙２）機能・帳票要件」でまとめている。 ０．共通 １．資格異動 ２．免除 ３．付加 ４．給付 ５．日本年金機構への報告・日本年金機構からの情報登録 ６．情報提供・その他 ７．統計・報告 各事業の機能・帳票要件における考え方や留意事項は以下のとおりである。 1. 管理項目について 2. 「～等」の表記について 3. 一覧出力機能について 4. EUC機能の要件について 5. 基幹系他システム連携機能について 6. 外部帳票と内部帳票について 7. エラー・アラート（チェック条件）の考え方について 8. 操作権限管理について 9. アクセスログ管理について （10）一括処理時の自動化について 1. 管理項目について 該当する機能で管理すべき項目として「管理項目」をまとめている。「管理」とはデータの設定・保持・修正ができることをいい、参照又は表示のみを目的とした項目は管理項目として定めないこととしている。そのため、参照・表示のみを目的とした項目については、参照要件又は表示要件として記載している。 図3-1 管理項目の該当例と非該当例 ![](./assets/image10.png) なお、住民税情報等の他システムからの連携で取得した情報のうち、国民年金システム側で保持・修正を行う場合は管理項目と定めている。 例）免除・納付猶予申請書の確認にて扶養親族数の確認に必要な扶養情報を他システムから取得するが、取得した情報を国民年金システム内で保持して適宜修正等を行うこともあるため、免除における管理項目となる。 2. 「～等」の表記について 機能・帳票要件の記載で「～等」と表現しているものがある。「～等」は性質別に考え方を次のとおり整理している。 表3-2 「～等」の表記と考え方

分類

記載箇所（例）

考え方
管理項目に記載しているもの

![](./assets/image11.png)

管理項目における「等」が無い場合、地方自治体毎の運用差異等に起因し自治体独自項目を標準オプションとして列挙する整理しかできない状況であるため、現段階では「等」と記載をしている。

今後、データ要件の検討に合わせて精緻化する予定である。なお、コード項目及びコード内容の明確化もデータ要件の検討に合わせて行う予定である。
事務運用例として記載しているもの

![](./assets/image12.png)

左記事例では種別変更に関する資格異動情報を登録する事務運用の例として記載している。登録対象となる種別変更は３号から１号への変更が主たるケースとなるが、実際には複数のパターンがあり、全て列挙することも現実的ではない。一方、主に発生する事務運用例を記載することは具体的イメージの補助となるため、「等」をつけて記載をしている。
あえて全て列挙しなくても法令等により要件に齟齬が生じないもの

![](./assets/image13.png)

左記事例では前年の収入金額に含める対象となる収入は法令・通知等で決まっているため、あえて全てを列挙せずとも要件に齟齬が生じないため、冗長とならないように「等」をつけて記載をしている。
要件を実現するための手段を参考として記載しているもの

![](./assets/image14.png)

左記事例では、大量帳票の印刷を外部業者に委託する場合に電子データを作成する要件であるが、委託先によって作成する電子データの形式は異なるため、実現手段の事例として

「CSV形式のファイルやPDFファイ

ル」を出しているだけで、実現方法は任意となる。（「等」を除くと記載したファイル形式以外のものが実装不可となるため、「等」をつけている。）
3. 一覧出力機能について 機能・帳票要件における一覧出力に関する機能要件について、機能の考え方及び記載方針を次のとおり整理している。 表3-3 一覧出力に係る機能の考え方と記載方針

観点

考え方

記載方針
一覧の抽出条件 地方自治体により抽出したい条件が様々である（例参照）ため、標準仕様書として全ての条件を網羅するとした場合、抽出条件は地方自治体の実態を勘案すると大半の抽出条件が標準オプションとして定義することが考えられる。また、運用する中で必要と考えられる抽出条件が状況により変化することが考えられる。例）２０歳到達予定者一覧では、「到達日 or 個人番号で検索」

EUC機能で「プログラムの操作を行うことなく、抽出条件は各事務にて対象とする一覧に関する管理項目を対象とし、任意のデータ抽出が主管課職員でも容易にできること」と定義することで、一覧管理機能として抽出条件を詳細に定義しないこととしている。
一覧の表示項目

必要な表示項目は地方自治体により様々であり、更に該当機能を使用する場面により変化する（例参照）ため、全てを網羅するとした場合、一覧に関する要件に膨大な項目を列挙することとなる。

例）報告を必要としない異動に係る情報の一覧で、資格異動種別の情報だけではく、関連する住民記録情報が必要となる場合や、所得情報等が必要となる場合等、様々な項目が考えられる。

EUC機能で「表示（出力）項目は各事務にて対象となる一覧に関する管理項目、および住民記録情報等の関連する項目を対象とし、任意に指定できること」と定義することで、一覧管理機能として表示項目を詳細に定義しないこととしている。
一覧の実装方法 一覧機能の実現方法としては、一覧画面での表示や一覧帳票・CSV等のデータでの出力等様々考えられるが、運用に応じた適切な方法により一覧形式での確認ができれば運用に大きな支障は発生しないと思われる。また、「一定の件数以下であれば画面表示、それを超えればCSV等出力」といった実装方法の明確な線引きは、業務や対象機能、自治体規模等により様々と考えられる。

一覧管理機能に関する要件は、全て「一覧で確認できること」という記載とし、実装方法は問わないこととしている。
ただし、事務運用上、明記をしないと支障が出ると認められるものは明記する。 また、上記３つの観点を踏まえて、「（４）EUC機能の要件について」で、一覧管理機能とEUC機能の関連性を整理している。 4. EUC機能の要件について 一覧管理機能とEUC機能は一部機能が重複する部分があるが、運用上最低限必要となる業務固有の一覧確認要件は「○○を一覧で確認できること」と明記した上で一覧出力機能での 対応とすることとし、その他の要件については、EUC機能での対応という形で整理している。 図3-2 機能・帳票要件におけるEUC機能の記載例 ![](./assets/image15.png) 5. 基幹系他システム連携機能について 基幹系業務との他システム連携機能において、国民年金用宛名情報／税務情報等の情報については、最新情報を保持する住民記録システムや個人住民税システムを都度参照する仕様を原則とする（下記パターン①）。ただし、処理速度やシステム負荷の観点、あるいは、各市区町村における移行完了までの過渡期の運用を考慮し、必要に応じ、パターン②やパターン③の採用も可能である仕様とする。 図3-3 基幹系他システムとの連携イメージ ![](./assets/image16.png) 6. 外部帳票と内部帳票について 帳票要件として定義する帳票は外部帳票とする。担当主管課内の決裁用等の内部帳票は機能要件におけるEUC機能等を活用することとする。なお、外部帳票と内部帳票の定義は次のとおりである。 表3-4 外部帳票と内部帳票の考え方
帳票種類

帳票種類の考え方
外部帳票

住民や年金機構等の外部機関に向けた帳票をいう。

標準仕様としてはシステムから出力すべき帳票として定義し、システムからの印字項目等を定める。
内部帳票

事務運用に併せて必要となる担当主管課内で使用する確認用リスト等の帳票をいう。

標準仕様としてはシステムから出力すべき帳票の種類及びシステムから印字する項目は定めず、EUC機能での対応を原則として定義する。
7. エラー・アラート（チェック条件）の考え方 機能・帳票要件に定める各機能において、不正な状態で情報が管理されると事務運用に影響が発生するため、適宜データの矛盾をチェックする必要がある。主な矛盾の分類としては次のとおりである。 表3-5 矛盾の分類
分類 内容
物理的矛盾 項目の属性（英字、数字、日本語等）や項目長（桁数、バイト数）等で定義されている内容と合致しないもの
論理的矛盾 存在しない日付（4/31等）や数値等項目間の大小関係が逆転している等、一般的に矛盾していると言えるもの

法制度等により規定されている条件を満たしていないものや業

務プロセスが成立しない状態（※）となっているもの

※ 入力した新規の基礎年金情報が、既に登録されている基礎年金番号だった場合 等
これらの矛盾に対してチェックを行い、エラー又はアラートとして処理することにより、不正なデータの登録を抑止することや操作者（入力者）への注意喚起を行う必要がある。エラー・アラートのチェック観点は、次のとおりである。 表3-6 エラー・アラートのチェック観点
チェック

チェック観点

 チェックの事例と理由
エラー

物理的矛盾や論理的矛盾のいずれにもエラーとしてチェックする場合があり、システムからのアウトプットである帳票や集計、データ等の出力を正しく行うために業務システムにてチェックを行い、不正なデータが作成されないように抑止する。

免除・納付猶予申請書において、免除区分（種別）が設定されていない。

⇒免除区分が判別できず、国民年金保険料免除・納付猶予申請（市町村確認書）出力等が正しく行えない可能性があるため、未設定の場合はエラーとする必要がある。
アラート

物理的矛盾では空白や未設定を許容する場合であったり、論理的矛盾では法制度や当該制度の運用上、通常は入力されるべき項目が入力されていない場合や、やむを得ない事情等による例外規定がある場合であったり、操作者

（入力者）に本来あるべき状態でない

ことを気付かせるために注意喚起する。

免除・納付猶予申請書受理・審査において、扶養親族数に免除基準に満たない人数が設定されている。

⇒扶養親族数が正しく計算されていない、あるいは入力ミスの可能性もあることから、アラートで注意喚起を促す必要がある。
本仕様書におけるエラー・アラート（チェック条件）において主に留意すべき事項は、次のとおりである。 1. エラーチェックは「不正データを作成しない」という観点からデータ入力時にチェックすることを基本とするが、必要な情報を用いて帳票やデータ等を出力するまでに整備されれば影響がないケースも考えられるため、必ずしも入力時にチェックすることを求めるものではないこととする。 2. エラーチェックの内容は必ずしもメッセージによる表示に限定するものではなく、データの入力内容が一定条件を満たすまでデータ保存を不可にする、といった方法等でも問題ないこととする。 3. 文字列／数値といったデータの属性やデータの項目長に対するチェックは、データ要件で定められるデータ形式に準拠することとし、矛盾するものはエラーチェックとする。 4. 検索条件未入力のチェックや入出力ファイルの格納先（フォルダ）パスの存在確認チェック、画面終了時のデータ未保存チェック等は、画面要件に含まれるものであるため、本仕様書におけるエラー・アラートの要件としては定めないこととする。 5. 制度改正等により、従前までエラー・アラートとしていたチェックが不要となる場合や地方自治体の運用により必要とするチェックの設定が異なる等も想定されることから、チェック内容に対するエラー・アラートの設定は切り替え可能（エラー・アラートを表示しない設定も含む）とするべきかを考慮して実装する必要がある。 （８）操作権限管理について 操作権限設定・管理は、すべての基幹業務システムにおいて必要であり、シングル・サイン・オンを実現するため、実装すべき機能として、以下のとおり定める。 表3-7　操作権限管理

機能一覧

実装必須・オプション

発注者のシステム操作権限ポリシーに基づき、システムの利用者及び管理者に対して、個人単位でID及び パスワード、利用者名称、所属部署名称、操作権限（異動処理や表示・閲覧等の権限）、利用範囲及び期間が管理できること。

必須

職員のシステム利用権限管理ができ、利用者とパスワードを登録し利用権限レベルが設定できること。

必須

操作者IDとパスワードにより認証ができ、パスワードは利用者による変更、システム管理者による初期化ができること。認証に当たっては、シングル・サイン・オンが使用できること。

必須

アクセス権限の付与は、利用者単位で設定できること。

必須

アクセス権限の設定はシステム管理者により設定できること。

必須

アクセス権限の付与も含めたユーザー情報の登録・変更・削除はスケジューラ―に設定し、事前に準備ができること。

必須

事務分掌による利用者ごとの表示・閲覧項目及び実施処理の制御ができること。

必須

他の職員が住民情報の入力・異動作業をしている間は、同一住民の情報について、閲覧以外の作業ができないよう、排他制御ができること。

必須

操作権限管理については、操作権限一覧表での管理及びそれらに基づく利用者別の各種制御ができること。

必須

操作権限はバッチ処理で一括メンテナンスできること。ID パスワードによる認証に加え、ICカードや静脈認証等の生体認証を用いた二要素認証に対応すること。

必須

複数回のアクセスの失敗に対して、アクセス禁止状態にできること。

必須

組織・職務・職位等での操作権限を設定できること。

オプション
（９）アクセスログ管理について アクセスログ管理は、すべての基幹業務システムにおいて必要であり、実装すべき機能として、以下のとおり定める。 表3-8　アクセスログ管理
機能一覧 実装必須・オプション

個人情報や機密情報の漏えいを防ぐために、システムの利用者及び管理者に対して、以下のログを取得すること。

① 操作ログ

ア．取得対象：

(a)照会、(b)帳票発行、(c)異動入力（履歴追加）、(d)異動入力（履歴修正）、(e)異動入力（履歴削除）、(f)バッチ処理（帳票作成）、 (g)バッチ処理（データ更新）、(h)画面ハードコピー、(i)データ抽出（EUC）

※(c)から(e) まで については、仮登録及び本登録両方の操作ログを取得できること。

イ.記録対象：

操作者 ID 、日時、ファイル名、端末名、オンラインの場合は対象となったレコード（処理対象者等）・機能名・画面名、バッチについては処理名、処理・交付場所、個人番号へのアクセス有無

② 認証ログ

ログイン及びログインのエラー回数等

③ イベントログ

住民記録システム内で起こった特定の現象・動作の記録。異常イベントやデータベースへのアクセス等のセキュリティに関わる情報

④ 通信ログ

Webサーバや Web アプリケーションサーバ、データベースサーバ等との通信エラー等

⑤ 印刷ログ

印刷者ID、印刷日時、対象ファイル名、印刷プリンタ（又は印刷端末名 、タイトル、枚数、公印出力の有無、個人番号の出力の有無、出力形式（プレビュー、印刷、ファイル出力等）、証明書の場合には発行番号等の情報

⑥ 設定変更ログ

管理者による設定変更時の情報・エラーログ

管理者による設定変更時の情報取得したログは、市区町村が定める期間保管するとともに 、オンラインでの検索・抽出・照会、EUC機能を用いた後日分析が簡単にできること。

なお、システム利用者や第三者によるログの改ざんがされないよう、書き込み禁止等の改ざん防止措置がされること。

必須

システムの利用者及び管理者のログについては、分析・ファイル出力が作成できること。

必須
（10）一括処理時の自動化について　　　　　　　　　　　　　 一括処理の実行方法は、手動による実行の他に設定による自動実行があるが、実装すべき機能として、以下のとおり定める。 表3-9　一括処理

機能一覧

実装必須・オプション

実行（起動）方法として、直接実行ができること。

必須

実行（起動）方法として、年月日及び時分、毎日、毎週ＸＸ曜日、毎月ＸＸ日、毎月末等を指定した方法（スケジュール管理による起動）で実行できること。

必須

他システム間連携等のイベント発生による実行（実行の契機となる前処理の完了後に起動）ができること。

必須

前回処理時に設定したパラメタを用いて、実行できること。パラメタは修正でき、再利用できること。

必須

一括処理を行う場合でも単件等の処理に影響が出ないこと。

必須

全ての一括処理の実行結果（処理内容や処理結果、処理時間、処理端末名称、正常又は異常の旨、異常終了した際はOSやミドルウェア等から出力されるエラーコード等）が確認できること。

必須

異常終了した場合の警告を国民年金システム内、または自治体が別途利用する他の通報システムに連携できること。

必須
## ２．帳票詳細要件 帳票詳細要件では、原則として「１（６）外部帳票と内部帳票について」にて示した外部帳票を対象とし、機能・帳票要件で定義した帳票におけるシステムからの印字項目等を 「（別紙３）帳票詳細要件」でまとめている。また、帳票詳細要件として定義した帳票の様式（レイアウト）を「（別紙４）帳票レイアウト」でまとめている。なお、システムからの印字項目（以下「システム印字項目」という。）とは、業務システムにて対象情報により編集し印字する項目のことをいい、固定文言等の帳票レイアウトに直接設定されている項目は含まない。 帳票詳細要件及び帳票レイアウトの考え方や留意事項は以下のとおりである。 1. 帳票詳細要件には、機能・帳票要件にて定義した帳票（主に外部帳票）のシステム印字項目等をまとめている。内部帳票は基本的にEUC機能等を活用し作成することとするため、帳票詳細要件及び帳票レイアウトは定めない。 2. 帳票詳細要件に定義されたシステム印字項目は項目単位の類型に従うこととし、編集条件等は定義すべき内容のみを記載している。 3. 帳票における「第１章３（１）標準準拠の基準」（実装類型）の取扱いは次のとおりである。 ・帳票自体の出力における実装類型は、「１．機能・帳票要件」のとおりである。 ・帳票詳細要件のシステム印字項目で項目単位における類型の取扱いは次のとおりである。 表3-10 帳票詳細要件における類型の取扱い
システム印字項目の類型

項目の取扱い
実装必須

システムからの印字ができるように実装する必要がある。
標準オプション

システムからの印字は実装してもしなくてもよいが、実装しない場合は帳票レイアウト上の項目も必要に応じて設けないこととする。
実装不可

システムからの印字は実装不可とし、帳票レイアウト上の項目も原則設けないこととする。
4. システム印字項目の編集方法は、次のとおりである。なお、項目固有に編集方法を定義する場合は、帳票詳細要件の「備考（印字編集条件など）」に示す。 表3-11 システム印字項目の編集方法
システム印字項目の種類

編集条件など

への記載内容

表記の例

 補足

記載あり

 日付 和暦表記
/西暦表記

＜和暦表記＞

令和3年4月1日

＜西暦表記＞

2021年4月1日

＜短縮表記＞

R3.4.1

「令和3年4月1日から令和4年3月31日まで」等の期間を印字する場合は日付のみ印字

原則和暦表記とする。ただし、外国人の生年月日は西暦表記とする。帳票要件で定義する一覧帳票等で用途に応じて短縮表記とする。

また、例えば“から”、

”まで”等の日付以外の関連する文字は、帳票レイアウト側での埋め込み（プログラムから印字しないこと）として編集条件等には未記載としている。
カナ項目

全角表記

/半角表記

口座名義人カナのみ半角表記とし他は全角表記としている。
住所（宛名）

住所＋改行＋

方書

〇〇市△△町

□□□マンション

住民記録システム標準仕様書に宛名部分の住所は住所と方書の間は改行としている。なお、一部帳票では郵便番号を住所に付加して表示する場合は帳票詳細要件の「編集条件など」にその旨を記載している。

住所

（宛名以外)

住所＋全角ス

ペース＋方書

〇〇市△△町　□□□マンション
届出の有無等の選択肢

打ち出し形式

  1. 有、

  2. 無

有・無

該・非

選択肢のいずれかの文字を印字する。〇を印字する仕様は、手書きの延長の考え方であることと、印刷時の印字ずれ等を考慮し、原則不可としている。しかし、必要に応じ利便性などを考慮し、個別で○を印字することを否定するものではない。

記載なし

 金額 記載なし

1,000

1,000円

  1. ０００円

金1,000円

月額１，０００円

帳票の種類や表示位置に応じて表記を使い分ける必要があるため、金額の印字フォーマットは定めない。