--- type: other title: 機能・帳票要件 source: 自治体システム等標準化検討会 profile: mrlgss-doc/0.1 business_code: "024" version: "1.6" spec_date: 2026-01-30 --- # 機能・帳票要件 機能・帳票要件の具体的な要件は、以下の業務について「（別紙２）機能・帳票要件」でまとめている。 〇 共通 〇 資格管理 〇 賦課管理 〇 給付管理 〇 収納管理 〇 滞納管理 ※　統計・報告業務については、各業務の機能・帳票要件にそれぞれ記載している。 各業務の機能・帳票要件における考え方や留意事項について、以降に示す。 （１）記載方針について （２）管理項目について （３）一覧機能及びEUC機能について （４）基幹系他システム連携機能について （５）料／税の取扱いについて （６）外部帳票と内部帳票について （７）エラー・アラート（チェック条件）の考え方について （８）実装方法について （９）画面要件について （１０）和暦元号の対応について （１１）標準準拠システムの共通要件について （１２）多様な収納方法への対応について （１３）特定健診等の取扱いについて （１４）政令指定都市向け機能要件について （１５）実装必須機能（経過措置対象）について （１６）適合基準日の考え方について ## 記載方針について 【標準仕様書の考え】 機能・帳票要件については、デジタル庁より示された標準仕様書間の横並び調整方針の別添１「標準仕様書機能要件様式例」に従い記載している。 【検討の経緯】 本仕様書【第1.2版】以降、デジタル庁より示された様式例に従った記載としている。 ## 管理項目について 【標準仕様書の考え】 機能・帳票要件に示された要件を満たすため、機能I/F（入力した値を帳票出力で利用する等、他機能で利用する項目）として最低限必要と想定される項目を「管理項目」とする。 また、具体的なコードは、機能・帳票要件に定めず、デジタル庁が整理するデータ要件・連携要件標準仕様書の基本データリスト（コード一覧）に定められているものに準ずるものとする。 管理項目のデータ型（全角文字、半角文字等）、桁数、データ入力出力条件等は、機能・帳票要件に定めず、デジタル庁が整理するデータ要件・連携要件標準仕様書に定めているため、管理項目の入力条件（必須・条件付き必須・任意）やデータ移行時のデータ抽出条件はデータ要件・連携要件標準仕様書を確認すること。 【検討の経緯】 標準仕様書としては管理項目を明確にすべきであると考えるため、機能・帳票要件に示す要件を満たすための項目は管理項目として明確に示すこととした。 また、コードやデータ型等については、データ要件・連携要件標準仕様書に従うため、上記の通りとした。 ## 一覧機能及びEUC機能について 【標準仕様書の考え】 一覧機能とは、各業務の機能・帳票要件に「一覧で確認できること」「一覧を出力できること」「リストを出力できること」と表記された、運用上必要となる業務固有の要件を実現する機能のことを指す。 EUC機能とは、共通機能標準仕様書に規定するデータの抽出・分析・加工・出力を行う機能のことを指す。 一覧機能の実現方法としては、一覧画面での表示や一覧帳票、CSV等のデータでの出力等様々考えられるが、一覧形式での確認・出力ができれば各市区町村における運用に大きな支障は生じないものと考えるため、実装方法は明記しないこととし、要件を満たす場合はEUC機能による対応も可能とする。 一覧機能及びEUC機能の考え方は[表 ３‑２](#_Ref101693405)のとおりとする。

表 ‑ 一覧機能及びEUC機能の考え方
観点 一覧機能の考え方 EUC機能の考え方
抽出条件 市区町村によって抽出に用いる項目や条件は様々であり、運用する中でも必要と考えられる抽出条件は状況により変化することが考えられるため、全てを網羅して示すことは行わないこととする。 共通機能標準仕様書の規定に従う。
表示・出力項目

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

標準仕様としてはシステムから出力すべき帳票の種類及びシステム印字項目は示さず、EUC機能等での対応を原則とする。
出力形式 紙、PDF、CSV、その他様々な形式が想定されるが、他業務システムと統一してPDF（紙）及びCSV形式での出力とする。
ただし、事務運用上、明記をしないと支障が出ると判断したものは各機能・帳票要件において明記することとする。 また、外部委託用のファイル出力については、個々の機能に対して外部委託用ファイル出力機能は示さず、一覧機能又はEUC機能を用いて対応するものとするが、個々の機能において対応することを妨げるものではない。 【検討の経緯】 出力形式については、紙、PDF、CSV等の具体的なものに限定しない記載とすべきとのご意見や、一方で具体的な出力形式を示すべきとのご意見を検討会委員よりいただいたため、他業務システムと統一してPDF（紙）又はCSV形式に限定する記載とした。しかしながら、PDF（紙）又はCSV形式とした場合、PDF（紙）のみの対応でも許容してしまうこと、また、全国意見照会において、どちらか一方ではなくPDF（紙）とCSVの両方の形式としてほしいといったご意見を複数いただいたことから、「PDF（紙）及びCSV形式」とすることとした。 また、外部委託用のファイル出力については、個々の機能に対してCSVファイル出力機能の追加や項目追加に関するご意見を検討会委員よりいただいたものの、外部委託を行うかどうかは市区町村の運用によって変わるものであるため、外部委託用としての機能は示さず、一覧機能、又はEUC機能から出力するものを用いて対応していただく前提としたが、個々の機能において対応することを妨げるものではない。 なお、EUC機能の要件については、共通機能標準仕様書に規定されることから、上記のとおりとした。 ## 基幹系他システムとの連携パターンについて 【標準仕様書の考え】 基幹系業務との他システム連携機能において、国民健康保険用宛名情報、税務情報等の情報については、国民健康保険システム内での保持・不保持のいずれであっても機能上の影響はないと考えられるため、いずれの方式（主に[図 ３‑１](#_Ref211332429)のパターン）での実装も可能として示すこととする。 ![](./assets/image6.png) 図 ‑ 基幹系他システムとの連携パターン 【検討の経緯】 宛名情報、税務情報等の情報については、国民健康保険システムでも他業務システムにおける扱いと同様の考えに整理できるため、上記のとおりとした。 ## 料／税の取扱いについて 【標準仕様書の考え】 「料」と「税」の表記は「料」「税」「料（税）」が存在するが、本仕様書においては、「料」と「税」を区別することなく表現できるものについて「料（税）」の表記で統一することとし、いずれか一方のみ表現する場合は、「料」又は「税」と明確に区別して表現を行うこととする。 なお、本仕様書において「課税標準額」のような「税」を前提とした項目名となっているため、「料」を採用している市区町村においては、これらの項目について適宜「料」へ読み替えの上対応することとする。 【検討の経緯】 「料」「税」「料（税）」の表記が混在しているため統一すべき、とのご意見を検討会委員よりいただき、帳票毎に表記の内容を整理した上で、本仕様書に示すこととした。 ## 外部帳票と内部帳票について 【標準仕様書の考え】 帳票要件として示す帳票は外部帳票とする。担当主管課内の決裁用等の内部帳票は機能要件におけるEUC機能等を活用することとする。 なお、外部帳票と内部帳票の考え方は[表 ３‑３](#_Ref101281152)のとおりである。

表 ‑ 外部帳票と内部帳票の考え方
帳票種類 帳票種類の考え方
外部帳票 住民や他市区町村、事業者(※)等の外部機関に向けた帳票をいう。標準仕様としてはシステムから出力すべき帳票として示し、システム印字項目等を示す。
内部帳票

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

標準仕様としてはシステムから出力すべき帳票の種類及びシステム印字項目は示さず、EUC機能等での対応を原則とする。ただし、ペーパーレスを前提としてEUC機能を原則として考えるものの、既にベンダが提供しているシステムにおいて実装済みの内部帳票の出力機能を利用することを妨げるものではない。
※　行政機関、金融機関等。 【検討の経緯】 デジタル庁が示す「帳票要件の標準」に則り、住民等に送付する外部帳票については、標準仕様として統一した様式や印字項目を定めることとした。 一方、確認用リスト等の内部帳票については、「EUC機能等を利用して画面で確認する等のデジタル化を原則とし、真に必要なものに限定して、標準を定める」ことが示されているが、必要とする項目が確認できれば特に様式を指定する必要はなく、また、印字すべき項目や様式が市区町村によって様々であり、一律の様式を標準仕様書に規定することは難しいため、本仕様書としては様式や印字項目は定めないこととした。 なお、既にベンダが提供しているシステムに実装済みの機能を廃止する工数などを考慮して、既に実装されている場合においては、引き続き利用することを妨げないこととした。 ## エラー・アラート（チェック条件）の考え方について 【標準仕様書の考え】 機能・帳票要件に定める各機能において、不正な状態で情報が管理されると事務運用に影響が発生することから、適宜データの矛盾をチェックする必要があるため、本仕様書において考え方を示す。ただし、業務固有のデータのチェック仕様については、各ベンダの方針に従うものとし、本仕様書の対象外とすることを原則とするが、チェックすべき処理の概要については必要に応じて機能・帳票要件に示すこととする。 主な矛盾の分類としては[表 ３‑４](#_Ref101281176)のとおりである。

表 ‑ 矛盾の分類
分類 内容
物理的矛盾 項目の属性（英字、数字、日本語等）や項目長（桁数、バイト数）等で示されている内容と合致しないもの
論理的矛盾 存在しない日付（4/31等）や数値等項目間の大小関係が逆転している等、一般的に矛盾しているといえるもの
法制度等により規定されている条件を満たしていないものや業務プロセスが成立しない状態（※）となっているもの
※　決定日が申請日より前の日付となっている等の日付の前後関係が不整合な状態や支払データ作成時に必要な口座情報が存在しない等。 これらの矛盾に対して、エラー又はアラートのチェックを行い、不正なデータの登録を抑止することや操作者（入力者）への注意喚起を行う必要がある。エラー・アラートのチェック観点は、[表 ３‑５](#_Ref101281195)のとおりである。

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

システム上、必須項目とされている項目が入力されていない状態で登録を行おうとしている。

⇒該当項目がその後の処理で使用される、又はデータベースのキー情報となる等、後続の処理が正しく行えなくなるもののため、未設定の場合はエラーとする必要がある。
アラート 物理的矛盾では空白や未設定を許容する場合であったり、論理的矛盾では法制度や当該制度の運用上、通常は入力されるべき項目が入力されていない場合や、やむを得ない事情等による例外規定がある場合であったり、操作者（入力者）に本来あるべき状態でないことを気付かせるために注意喚起する。

高額療養費等の支給申請を登録する際に対象者の登録口座が入力されていない。

⇒最終的な支払い時に必要となり、登録がない場合、振込処理ができない。ただし、後から入力する可能性もあるため、エラーとはしないが、アラートで注意喚起を促す必要がある。
本仕様書におけるエラー・アラート（チェック条件）において主に留意すべき事項は、以下のとおりである。 1. エラーチェックは「不正データを作成しない」という観点からデータ入力時にチェックすることを基本とするが、帳票やデータの出力等に影響がない場合においては、入力時にチェックすることを必須とするものではないこととする。 2. 検索条件未入力のチェックや入出力ファイルの格納先（フォルダ）パスの存在確認チェック、画面終了時のデータ未保存チェック等は、画面要件に含まれるものであるため、本仕様書におけるエラー・アラートの要件としては定めないこととする。 3. 制度改正等により、従前までエラー・アラートとしていたチェックが不要となる場合や、市区町村の運用により必要とするチェックの設定が異なる等も想定されることから、エラー・アラートの設定は切り替え可能（エラー・アラートを表示しない設定も含む。）とするべきかを考慮して実装する必要がある。 【検討の経緯】 実装面を考慮し、エラー・アラートの細かすぎる定義は避けるべきとご意見をいただいた一方で、定義の詳細化が必要とのご意見を検討会委員よりいただいたことから、共通的なチェック条件の考え方を示し、機能毎にチェックすべき処理の概要を示すべきと判断したものについては、機能・帳票要件に示すこととした。 また、データの完全性確保のため入力時のエラーチェックを必須とすべきとのご意見をいただいたものの、不正データが帳票やEUCによるデータ出力等に影響がない場合に限り、入力時チェックを必須としないこととした。 ## 実装方法について 【標準仕様書の考え】 本仕様書については、あくまで標準的な要件を定めるものであり、本仕様書を基に具体的に機能をどのように実装するかについてはベンダに委ねられることから、オンライン処理及びバッチ処理のどちらで実装するか等の実装方法を指定するような粒度の記載は行わないこととする。 また、業務運用上、一括での処理が前提となる機能については、「一括処理」や「一括更新」等、「一括」と表現することで明確に判断可能となるように記載するが、上記と同様に、どのように実装するかについての記載は行わないこととする。 なお、機能・帳票要件において、「一括」として示した処理については、特定の情報を一度に登録・更新・削除・出力する機能を指すものとし、バッチ処理を想定した仕様書の記載としているが、実装必須機能及び標準オプション機能のいずれにおいても、必ずしもバッチ処理による実装を強制するものではない。 【検討の経緯】 機能要件として必要な記載が不足している箇所については、検討会委員のご意見を受けて記載の見直しを行った上で本仕様書を示しているが、実装方法に係る記載については他業務システムにも倣い上記の方針とした。 ただし、収納管理及び滞納管理機能については、税務システムと同等の機能要件となるものは乖離が生じないよう税務システムの標準仕様書と合わせた記載としているものの、機能・帳票要件や帳票レイアウトの一部については、国保独自の検討過程を経て策定しており、今後もそれぞれ独自の仕様書で定めることとする。 ## 画面要件について 【標準仕様書の考え】 検索条件やソート機能、レイアウト等を含む画面要件については、現状カスタマイズ頻度が低く、第１章「３．（３）対象項目」に示したとおり、標準化範囲外としていることから、原則言及しないこととする。 ただし、本仕様書の議論・検討の過程でいただいた意見により、事務処理上明らかに必要な機能であり明記が望ましいと判断したものについては記載を行っている。 【検討の経緯】 他業務システムの考えに倣い画面要件について原則言及しないこととするものの、必要と判断したものについては記載を行うこととした。 ## 和暦元号の対応について 【標準仕様書の考え】 改元時の対応について、現在の元号のように西暦日付から和暦に用いる元号が設定可能な場合は、以下の方針とする。 1. 同一日付で元号が選択可能である場合は、住民記録システムで選択した元号が採用されること。 2. 将来、新たな元号変更が予測される場合に、西暦日付から設定可能となるよう考慮されていること。 3. 原則としては、アプリケーション改修なしで改元対応が可能となるよう考慮されていること。例外的にアプリケーション改修が発生する場合においては、影響箇所を局所化する等の配慮がされていること。 また、市区町村内の各システムにおいて元号変更の対応タイミングを揃える観点から、どの業務にも属さない共通的な管理を行うシステム等での制御を行うことも可能とする。 なお、改元の際の帳票における年度の表記については一律で方針を示すことはしない。 【検討の経緯】 改元の際の年度の表記については、新元号の発表時期や開始時期等を基に市区町村にて適切な対応をとることを目的に、都度通知等で案内が発出されるものと考えているため、一律で方針を示すことは行わないこととした。 ## 標準準拠システムの共通要件について 【標準仕様書の考え】 運用主任者の管理等、市区町村内の各システムにおいて共通的な機能については、全業務システム共通の仕様を整理する必要があると考えるが、現時点では国民健康保険システムにて必要な機能として本仕様書に機能を示すこととする。 【検討の経緯】 国民健康保険システムの標準仕様としてこれまでに議論を重ねてきた内容を踏まえ、上記のとおりに規定した。 ## 多様な収納方法への対応について 【標準仕様書の考え】 保険料（税）の納付方法には、口座振替のみならず、コンビニ収納や、クレジットカード払い、請求書払いといわれるスマートフォンのアプリケーションを使用して支払う方法など、複数の方法が存在している。現状、これらの収納消込データは、「収納代行業者」毎に連携されるインタフェースの仕様が異なっており、統一が図られていない状況にある。 ペイジーを利用する場合は、共同利用センターで、決済毎の消込データを統合するサービスがあるが、これもあくまでマルチペイメントネットワークサービスを活用することが前提となる。 これを踏まえ、eLTAX以外の収納機関から連携される各種収納データを収納消込が可能となる形に成型する処理については、収納機関ごとの統一標準がないことから「標準化の対象外」とする。利用するシステムにおいて活用する収納代行業者との連携インタフェースに改変が必要な場合、その改変を適宜実施いただくことは可能と考えている。
![](./assets/image7.png)

図 ‑ 多様な収納方法を利用する場合の標準化範囲のイメージ

【検討の経緯】 全国意見照会において、市民サービス・収納率の向上を目的として、電子決済サービス等の収納方法の拡大を進めているため、収納方法への対応については標準化の対象外として明記してほしいとのご意見をいただいたことから、他業務システムの考え方に合わせて上記のとおりとした。 ## 特定健診等の取扱いについて 【標準仕様書の考え】 特定健康診査及び特定保健指導（以下「特定健診等」という。）に係る機能要件については、以下の条件において標準仕様書（※）の記載有無に関わらず、現行の国民健康保険システムで実装されている機能を標準準拠システムに継続して保持すること及び市区町村が利用することを許容するものとする。 なお、国民健康保険システム以外のシステムで特定健診等業務を行っている市区町村に対しては、当該システムの継続利用を妨げるものではない。 ※　国民健康保険システムと健康管理システムの標準仕様書 〇期間： 特定健診等について、特定健診等システム標準仕様書に沿っていずれかの標準準拠システムに実装されるまでの間 〇対象の業務： 健康増進法、国民健康保険法及び高齢者の医療の確保に関する法律等に規定される業務及び健康管理システムにおいて市区町村拡張事業として規定されている業務 〇条件： 現行の国民健康保険システム等で既に業務を実現するための要件が実装されている場合 【検討の経緯】 特定健診等業務に係る機能要件については、令和6年8月に特定健診等システム標準仕様書【第1.0版】が公開されたところ。当該仕様書の適合基準日は令和11年4月1日とされており、これ以降、特定健診等業務に係るシステムは当該仕様書に準拠する必要があるが、国民健康保険システムについては令和8年4月1日以降、本仕様書に示した機能要件以外は実装不可となることから、既に国民健康保険システムに特定健診等に係る業務機能を実装している場合、準拠版の特定健診等システムを開発中の期間は、国民健康保険システムから当該機能を削除する等の対応が必要となる等の影響が生じることとなるため、後期高齢支援システムの考え方と合わせて上記のとおりとした。 ## 政令指定都市向け機能要件について 【標準仕様書の考え】 政令指定都市向けの機能要件については機能・帳票要件に規定し、政令指定都市用の実装区分欄に「◎：実装必須機能」「〇：標準オプション機能」等の実装類型を示している。 政令指定都市向けの機能要件として規定した機能が、一般市区町村においても必要と想定されるものについては、一般市区町村用の実装区分欄に実装類型を示している。 政令指定都市に製品提供するベンダにおいては、政令指定都市用の実装区分が「◎：実装必須機能」の機能要件に対応することが前提であり、一般市区町村向けに製品提供するベンダに対して、当該機能の実装を必須とするものではない。 また、行政区管理の実施有無に応じてその取扱いが大きく異なる機能においては、機能要件欄に［行政区管理を行っている指定都市向けの要件］等のように［］で記載している。これは、ベンダが開発規模を鑑みて開発対象団体が必要とする機能を取捨選択し、開発検討を行えるよう設けている（行政区管理を行わない団体のみを対象に製品開発を行う、あるいは行政区管理を行う団体のうち賦課区の切り替えを行わない団体のみを対象に製品開発を行う等。）。\[\]に該当する政令指定都市へ製品を提供する場合に限り、該当機能の政令指定都市用の実装区分が有効になるため、\[\]に該当する政令指定都市へ製品を提供しない場合は、政令指定都市用の実装区分が実装必須機能であっても、必ずしも開発を求めるものではない。
![](./assets/image8.png)

図 ‑ 政令指定都市要件の機能要件と実装区分の記載方法

なお、行政区の定義や帳票に印字する行政区情報と出力単位とそれらの検討過程の資料を本紙（別添１）～（別添４）に示す。 【検討の経緯】 政令指定都市向け機能要件については、「政令指定都市と一般市区町村では必要な項目や機能が異なる」「政令指定都市の機能要件を個別に示してほしい」といったご意見を多くいただいたことを受け、政令指定都市が必要とする機能要件や運用の異なる政令指定都市の要望の再検討を行い、上記のとおりとした。 ## 実装必須機能（経過措置対象）について 【標準仕様書の考え】 国民健康保険の制度運営に直結しない実装必須機能について、本仕様書に示す機能要件のとおり国民健康保険システムに実装されていない場合でも、システム外での対応や現行機能の継続利用等による代替運用が可能であり、市区町村の事務に支障がないと考えられる機能については時限を設けた標準オプション機能とする方針とし、機能・帳票要件に以下のとおり示している。
![](./assets/image9.png)

図 ‑ 実装必須機能（経過措置対象）機能の記載方法

【検討の経緯】 国民健康保険においては、令和7年度末の標準化期限までに準拠する必要がある本仕様書【第1.1版】の公開後、大型の制度改正が示されており、標準仕様書への準拠対応に加えて、これら制度改正に係るシステム改修についても優先的に対応を行う必要が生じている。本仕様書に示している全ての実装必須機能を標準化期限の令和7年度末までに実装することが困難な状況であることから、上記のとおりとした。 機能・帳票要件に示した実装必須機能（経過措置対象）以外の実装必須機能について経過措置対象とする必要がある場合は、令和7年2月にデジタル庁より示された「移行後の経過措置（一部機能の移行後の実装等）について」の「３．経過措置適用のフロー」に従い手続きを行う必要がある。機能・帳票要件に示す実装必須機能（経過措置対象）と上記のフローとの取り扱いについては、参考資料「国民健康保険システムにおける実装必須機能（経過措置対象）の申請について」に記載を行っている。 ## 適合基準日の考え方について 【標準仕様書の考え】 実装必須機能の適合基準日については、標準化期限又は「その機能に関連する制度の施行日」のいずれか遅い方の日付を定めることとしており、標準化期限以降に制度施行を迎える実装必須機能については、制度施行日を設定する方針としている。 ![](./assets/image10.png)一方、制度施行日と、各市区町村における機能の適用日（システムのバージョンアップ等を行い、制度改正対応で必要となる実装必須機能を国保システムへ追加する日）が異なるケースが想定されることから、市区町村における事務に支障が生じないことを前提に、制度施行日後の適用も許容するため、必要に応じて[図 ３‑５](#_Ref219481170)のような記載イメージで適合基準日欄に示すこととする。 図 ‑ 適合基準日欄の記載イメージ 【検討の経緯】 ベンダ各社において制度施行日までに実装必須機能の開発を完了した場合でも、各市区町村における機能の適用日（利用開始時期）は、機能の事前検証等の都合により制度施行日以降となることも想定され、この場合において、制度施行日を適合基準日とした場合では標準仕様書に未適合の期間が生じ、経過措置申請等の対応が必要となることが懸念される。このため、市区町村における事務に支障が生じないことを前提に、上記のとおりとした。