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

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

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

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

また、帳票詳細要件で定義した帳票のレイアウトを示す。
## １．機能・帳票要件 機能・帳票要件の具体的な要件は以下の事業について「（別紙２）機能・帳票要件」でまとめている。 １．介護保険共通 ２．被保険者資格 ３．保険料賦課 ４．保険料収納 ５．滞納管理 ６．受給者管理 ７．認定管理 ８．給付管理 ９．統計・報告等 10．総合事業 各事業の機能・帳票要件における考え方や留意事項は以下のとおりである。 （１）管理項目について （２）「～等」の表記について （３）一覧管理機能について （４）EUC機能の要件について （５）基幹系他システム連携機能について （６）外部帳票と内部帳票について （７）エラー・アラート（チェック条件）の考え方について （８）操作権限管理について （９）アクセスログ管理について （10）バッチ処理について （１）管理項目について　　　　　　　　　　　　　　　　　　 該当する機能で管理すべき項目として「管理項目」をまとめている。「管理」とはデータの設定・保持・修正ができることをいい、参照又は表示のみを目的とした項目は管理項目として定めないこととしている。そのため、参照・表示のみを目的とした項目については、参照要件又は表示要件として記載している。 図3-1　管理項目の該当例と非該当例 ![](./assets/image9.png) ![](./assets/image10.png) なお、住民税情報等の他システムからの連携で取得した情報のうち、介護保険システム側で保持・修正を行う場合は管理項目を定めている。同一のパッケージにより参照のみでも可能としている連携項目の場合は、管理項目を定めず、デジタル庁が整理する連携要件に連携できる項目を定めている。 例）負担限度額認定にて利用者負担段階の判定に必要な非課税年金情報を他システムから取得するが、取得した情報を介護保険システム内で保持して適宜修正等を行うこともあるため、受給者管理（負担限度額情報）の管理項目となる。 管理項目のうちコード管理（選択入力）を行う場合は、管理項目名に「コード」を付加している。具体的なコード管理内容は、機能・帳票要件に定めず、デジタル庁が整理するデータ要件（コード一覧）に定めている。 例）資格異動事由に関する管理項目は、「資格異動事由コード」となる。 管理項目のデータ型（全角文字、半角文字等）、桁数、データ入力出力条件等は、機能・帳票要件に定めず、デジタル庁が整理するデータ要件に定めているため、管理項目の入力条件（必須・条件付き必須・任意）やデータ移行時のデータ抽出条件はデータ要件を確認すること。 （２）「～等」の表記について　　　　　　　　　　　　　　　 機能・帳票要件の記載で「～等」と表現しているものがある。「～等」は性質別に考え方を次のとおり整理している。 表3-2　「～等」の表記と考え方 | 分類 | 記載箇所（例） | 考え方 | |:--:|----|----| | 事務運用例として記載しているもの | ![](./assets/image120.png) | 左記事例では過去の認定情報を参照する事務運用の例として記載している。認定申請に対する処分は主に認定（新規・更新・区分変更）となるが、実際には認定以外の様々なケースがあり、全て列挙することも現実的ではない。一方、主に発生する事務運用例を記載することは具体的イメージの補助となるため、「等」をつけて記載をしている。 | | あえて全て列挙しなくても法令等により要件に齟齬が生じないもの | ![](./assets/image14.png) | 左記事例では負担割合の判定に必要な情報は法令・通知等で決まっているため、あえて全てを列挙せずとも要件に齟齬が生じないため、冗長とならないように「等」をつけて記載をしている。 | | 要件を実現するための手段を参考として記載しているもの | ![](./assets/image16.png) | 左記事例では、大量帳票の印刷を外部業者に委託する場合に電子データを作成する要件であるが、委託先によって作成する電子データの形式は異なるため、実現手段の事例として「CSV形式のファイルやPDFファイル」を出しているだけで、実現方法は任意となる。（「等」を除くと記載したファイル形式以外のものが実装不可となるため、「等」をつけている。） | （３）一覧管理機能について　　　　　　　　　　　　　　　　 機能・帳票要件における一覧管理機能について、機能の考え方及び記載方針を次のとおり整理している。 表3-3　一覧管理機能の考え方と記載方針
観点 考え方 記載方針
一覧の抽出条件

地方自治体により抽出したい条件が様々である（例参照）ため、標準仕様書として全ての条件を網羅するとした場合、抽出条件は地方自治体の実態を勘案すると大半の抽出条件が標準オプションとして定義することが考えられる。また、運用する中で必要と考えられる抽出条件が状況により変化することが考えられる。

例）要介護認定者一覧では、「認定申請日 or 認定日で検索」

 EUC機能で「抽出条件は各事業の管理項目を任意に指定できること」と定義することで、一覧管理機能として抽出条件を詳細に定義しないこととしている。
一覧の表示項目

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

例）要介護認定の認定者一覧で、認定情報だけではく、関連する住民記録情報が必要となる場合や、介護保険の給付実績情報が必要となる場合等、様々と考えられる。

 EUC機能で「各事業の管理項目の内容を全て表示すること」及び「設定した抽出条件、表示項目を保存でき、抽出時に再度呼び出せること」と定義することで、一覧管理機能として表示項目を詳細に定義しないこととしている。
一覧の実装方法 一覧機能の実現方法としては、一覧画面での表示や一覧帳票・CSV等のデータでの出力等様々考えられるが、運用に応じた適切な方法により一覧形式での確認ができれば運用に大きな支障は発生しないと思われる。また、「一定の件数以下であれば画面表示、それを超えればCSV等出力」といった実装方法の明確な線引きは、業務や対象機能、自治体規模等により様々と考えられる。 一覧管理機能に関する要件は、全て「一覧で確認できること」という記載とし、実装方法は問わないこととしている。
ただし、事務運用上、明記をしないと支障が出ると認められるものは明記する。 また、上記３つの観点を踏まえて、「（４）EUC機能の要件について」で、一覧管理機能とEUC機能の関連性を整理している。 （４）EUC機能の要件について　　　　　　　　　　　　　　　 一覧管理機能とEUC機能は一部機能が重複する部分があるが、運用上最低限必要となる業務固有の一覧確認要件は「○○を一覧で確認できること」と明記した上で一覧管理機能での対応とすることとし、その他の要件については、EUC機能での対応という形で整理している。 図3-2　機能・帳票要件におけるEUC機能の記載例 ![](./assets/image15.png) （５）基幹系他システム連携機能について　　　　　　　　　　 基幹系業務との他システム連携機能において、介護保険用宛名情報／税務情報等の情報については、介護保険システム内での保持・不保持のいずれであっても機能上の影響はないと考えられるため、いずれの方式（主に下図パタン）での実装も可能として定義している。 図3-3　基幹系他システムとの連携イメージ ![](./assets/image17.png) （６）外部帳票と内部帳票について　　　　　　　　　　　　　 帳票要件として定義する帳票は外部帳票を基本とする。担当主管課内の決裁用等の内部帳票は機能要件におけるEUC機能等を活用することとする。なお、外部帳票と内部帳票の定義は次のとおりである。 表3-4　外部帳票と内部帳票の考え方
帳票種類 帳票種類の考え方
外部帳票

住民や事業者等の外部に向けた帳票をいう。

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

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

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

法制度等により規定されている条件を満たしていないものや業務プロセスが成立しない状態（※）となっているもの

※ 決定日が申請日より前の日付となっているような日付の前後関係が不整合な状態や支払データ作成時に必要な口座情報が存在しない等
これらの矛盾に対して、エラー又はアラートのチェックを行い、不正なデータの登録を抑止することや操作者（入力者）への注意喚起を行う必要がある。エラー・アラートのチェック観点は、次のとおりである。 表3-6　エラー・アラートのチェック観点
チェック チェック観点 チェックの事例と理由
エラー 物理的矛盾や論理的矛盾のいずれにもエラーとしてチェックする場合があり、システムからのアウトプットである帳票や集計、データ等の出力を正しく行うために業務システムにてチェックを行い、不正なデータが作成されないように抑止する。

認定管理において、認定情報登録時に要介護度が設定されていない。

⇒要介護度が設定されていないと被保険者証への印字や、国保連合会へ連携する受給者台帳への出力等が正しく行えないため、未設定の場合はエラーとする必要がある。
アラート 物理的矛盾では空白や未設定を許容する場合であったり、論理的矛盾では法制度や当該制度の運用上、通常は入力されるべき項目が入力されていない場合や、やむを得ない事情等による例外規定がある場合であったり、操作者（入力者）に本来あるべき状態でないことを気付かせるために注意喚起する。

給付管理（住宅改修）において、改修費用に支給限度基準額以上の金額が設定されている。

⇒支給限度基準額のリセットにより実際は超過していない場合であったり、入力ミスの可能性もあったりするため、アラートで注意喚起を促す必要がある。
本仕様書におけるエラー・アラート（チェック条件）において主に留意すべき事項は、次のとおりである。 ① エラー・アラートは機能・帳票要件に定める。 ② エラーチェックは「不正データを作成しない」という観点からデータ入力時にチェックすることを基本とするが、必要な情報を用いて帳票やデータ等を出力するまでに整備されれば影響がないケースも考えられるため、必ずしも入力時にチェックすることを求めるものではないこととする。 ③ エラーチェックの内容は必ずしもメッセージによる表示に限定するものではなく、データの入力内容が一定条件を満たすまでデータ保存を不可にする、といった方法等でも問題ないこととする。 ④ 文字列／数値といったデータの属性やデータの項目長に対するチェックは、データ要件で定められるデータ形式に準拠することとし、矛盾するものはエラーチェックとする。 ⑤ 検索条件未入力のチェックや入出力ファイルの格納先（フォルダ）パスの存在確認チェック等は、画面要件に含まれるものであるため、本仕様書におけるエラー・アラートの要件としては定めないこととする。 ⑥ アラートについては、制度改正等により従前まで必要とされていたチェックが不要となる場合や、地方自治体の運用により必要とするチェックの設定が異なる等も想定されることから、アラートの設定は切り替え可能（アラートを表示しない設定も含む）とすることを考慮する必要がある。 ⑦ エラーについては、システム内部管理項目や帳票への印字項目・集計項目などのアウトプットとして必要となる項目を除き、エラーの設定は切り替え可能（エラーを表示しない設定も含む）とすることを考慮する必要がある。 （８）操作権限管理について　　　　　　　　　　　　　　　　 操作権限管理は地方自治体で利用する事務処理システムとして共通した要件とすることが基本であることから、デジタル庁が整理した要件を基本とする。加えて、介護保険システムに必要とされたものは固有の要件として追加する必要がある。これらの考え方を踏まえて、以下のとおり定める。 表3-7　操作権限管理（実装必須機能）
実装必須機能
システムの利用者及び管理者に対して、個人単位でID及びパスワード、利用者名称、所属部署名称、操作権限（異動処理や表示・閲覧等の権限）、利用範囲及び期間が管理できること。
職員のシステム利用権限管理ができ、利用者とパスワードを登録し利用権限レベルが設定できること。
操作者IDとパスワードにより認証ができ、パスワードは利用者による変更、システム管理者による初期化ができること。

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

＜介護保険システム固有の要件＞

　所属部署（課・係等）単位でも設定できること。

＜介護保険システム固有の要件＞

利用者又は所属部署（課・係等）単位に、利用できる操作（登録・修正・削除・参照・印刷・ファイル出力）を設定できること。
IDパスワードによる認証に加え、ICカードや静脈認証等の生体認証を用いた二要素認証に対応すること。
複数回の認証の失敗に対して、アカウントロック状態にできること。
他の職員が異動処理を行っている間は、同一住民の情報について閲覧以外の作業ができないよう、排他制御ができること。
アクセス権限の設定は、システム管理者により設定できること。
アクセス権限の付与も含めたユーザ情報の登録・変更・削除はスケジューラ―に設定する等、事前に準備ができること。
また、事務分掌による利用者ごとの表示・閲覧項目及び実施処理の制御ができること。
なお、操作権限管理については、個別及び一括での各種制御やメンテナンスができること。
認証に係る機能については、標準準拠システムで実装するか、認証基盤等で実装するかを問わない。 表3-8　操作権限管理（標準オプション機能）
標準オプション機能

＜介護保険システム固有の要件＞

管理が本庁と他に分かれる場合は、本庁部署・利用者と他部署・利用者で更新・参照の権限を設定できること。（例：指定都市における本庁と区役所、広域連合・一部事務組合における広域連合（本部・支部等）と構成市町村等。）

＜介護保険システム固有の要件＞

本庁以外の部署・利用者のアクセス権限について、自治体の執行体制に応じて、住民がどこでも手続きが行えるように管理場所（所管）以外でも更新できるようにするほか、管理場所（所管）は更新できるが他部署（他の管轄や区役所等）は参照のみ・更新不可に設定できるようにもすること。指定都市における区役所の配下にある支所・出張所や広域連合・一部事務組合における広域連合（本部）の配下にある支部・出張所等も同様に権限設定が選択できるようにすること。
シングル・サイン・オンが使用できること。
（９）アクセスログ管理について　　　　　　　　　　　　　　 アクセスログ管理は地方自治体で利用する事務処理システムとして共通した要件とすることが基本であることから、住民記録システム標準仕様書の「10.2 アクセスログ管理」に準拠することを基本とする。加えて、住民記録システム標準仕様書において住民記録システム固有の機能や表現が記載されている部分については、介護保険システムに固有の要件として置き換える必要がある。これらの考え方を踏まえて、以下のとおり定める。 表3-9　アクセスログ管理（実装必須機能）
実装必須機能 住民記録システム標準仕様書での記載有無
個人情報や機密情報の漏えいを防ぐために、システムの利用者及び管理者に対してログを管理（取得・検索・抽出・参照・ファイル出力を指す、以下、表3-9において同様）できること（IaaS事業者がログについての責任を負っている場合等、パッケージベンダ自体がログを提供できない場合は、IaaS事業者と協議する等により、何らかの形で本機能が地方自治体に提供されるようにすること）。 あり（一部変更）
ログイン認証ログを管理できること。 あり（一部変更）
操作ログを管理できること。 あり（一部変更）
イベントログ、通信ログ、印刷ログ、エラーログを管理できること（介護保険システムが動作するOS、運用管理ツール、DB等におけるログでよい）。 あり（一部変更）
他システム連携により取得した住民記録情報、住民税情報、国民健康保険情報、後期高齢者医療情報に対する参照ログを管理できること。参照ログには参照した日時、職員、端末、宛名（対象者や保護者等を識別できる宛名番号等の情報）を含むこととし、分析できるように画面上で操作、又は表計算ソフト等へ取り込めるようにすること。 なし

取得した各種ログは、地方自治体が定める期間保管でき、書き込み禁止等の改ざん防止措置をとること。

例）保管期間は、イベントログは直近１年間、操作ログは５年間とする等

 あり
表3-10　アクセスログ管理（標準オプション機能） | 標準オプション機能 | 住民記録システム標準仕様書での記載有無 | |:--:|----| | 他システム連携により取得した生活保護受給者情報及び中国残留邦人情報、障害者福祉情報に対する参照ログを管理できること。参照ログには参照した日時、職員、端末、宛名（対象者や保護者等を識別できる宛名番号等の情報）を含むこととし、分析できるように画面上で操作、又は表計算ソフト等へ取り込めるようにすること。 | なし | （10）バッチ処理について　　　　　　　　　　　　　　　　　 バッチ処理の実行方法は、手動による実行の他に設定による自動実行があるが、地方自治体で利用する事務処理システムとして共通した要件とすることが基本であることから、デジタル庁が整理した要件を基本とする。加えて、介護保険システムに必要と整理されたものは固有の要件として追加する必要がある。これらの考え方を踏まえて、以下のとおり定める。 表3-11　バッチ処理（標準オプション機能）
標準オプション機能
バッチ処理の実行（起動）方法として、直接起動だけでなく、年月日及び時分、毎日、毎週○曜日、毎月ＸＸ日、毎月末を指定した方法（スケジュール管理による起動）が提供されること。

また、バッチ処理の実行時は、前回処理時に設定したパラメタが参照されること。

前回設定のパラメタは、一部修正ができること。

修正パラメタ個所については、修正した旨が判別し易くなっていること。
全てのバッチ処理の実行結果（処理内容や処理結果、処理時間、処理端末名称、正常又は異常の旨、異常終了した際はOSやミドルウェア等から出力されるエラーコード等）が出力されること。
バッチの実行結果から一連の作業で最終的な提出物をXLSX形式等で作成する場合等には、自動実行する仕組みを用意すること。
## ２．帳票詳細要件 帳票詳細要件では、原則として「１（６）外部帳票と内部帳票について」にて示した外部帳票を対象とし、機能・帳票要件で定義した帳票におけるシステムからの印字項目等を「（別紙３）帳票詳細要件」でまとめている。また、帳票詳細要件として定義した帳票の様式（レイアウト）を「（別紙４）帳票レイアウト」でまとめている。なお、システムからの印字項目（以下「システム印字項目」という。）とは、業務システムにて対象情報により編集し印字する項目のことをいい、固定文言等の帳票レイアウトに直接設定されている項目は含まない。 帳票詳細要件及び帳票レイアウトの考え方や留意事項は以下のとおりである。 ① 帳票詳細要件には、機能・帳票要件にて定義した帳票（主に外部帳票）のシステム印字項目等をまとめている。内部帳票は基本的にEUC機能等を活用し作成することとするため、帳票詳細要件及び帳票レイアウトは定めない。 ② 帳票詳細要件に定義されたシステム印字項目は項目単位の類型に従うこととし、編集条件等は定義すべき内容のみを記載している。 ③ 帳票における「第１章 ３（１）標準化範囲内の類型」（実装類型）の取扱いは次のとおりである。 ・帳票自体の出力における実装類型は、「１．機能・帳票要件」のとおりである。 ・帳票詳細要件のシステム印字項目で項目単位における類型の取扱いは次のとおりである。 表3-12　帳票詳細要件における類型の取扱い | システム印字項目の類型 | 項目の取扱い | |:--:|----| | 実装必須 | システムからの印字ができるように実装する必要がある。 | | 標準オプション | システムからの印字は実装してもしなくてもよい。 | | 実装不可 | システムからの印字は実装不可とし、帳票レイアウト上の項目も原則設けないこととする。 | ④ システム印字項目の編集方法は、次のとおりである。なお、項目固有に編集方法を定義する場合は、帳票詳細要件の「印字編集条件など」で示す。 表3-13　システム印字項目の編集方法

システム印字

項目の種類

編集条件など

への記載内容

 表記の例 補足
日付

和暦表記

/西暦表記

＜和暦表記＞

令和3年4月1日

＜西暦表記＞

2021年4月1日

＜短縮表記＞

R3.4.1

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

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

和暦表記時は「(元号)1年」ではなく「(元号)元年」とする。

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

全角表記

/半角表記

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

○○市△△町

□□□マンション

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

住所

（宛名以外）

 住所＋全角スペース＋方書 ○○市△△町　□□□マンション
届出の有無等の選択肢 打ち出し形式

有・無

該・非

 選択肢のいずれかの文字を印字する。○を印字する仕様は、手書きの延長の考え方であることと、印刷時の印字ずれ等を考慮し、原則不可としている。

固定文言

（教示文等）

 文言マスタにて設定された文言を印字 文言マスタで印字有無が「有」となっている場合、設定された文言を印字する。
編集 文言マスタにて設定された文言を印字

＜設定例＞

印字有無：有

印字する管理項目：申請受付場所

前付加文言：「受付場所：」

後付加文言：（空白）

＜印字例＞

受付場所：○○支所

 文言マスタにて印字有無、印字する管理項目、前付加文言、後付加文言をパラメタで複数設定でき、印字有無が「有」となっている場合、設定された文言を印字する。
自由記載 利用者が自由に利用できる「自由記載」領域とする

帳票詳細要件及び帳票レイアウトに当項目がある場合、自治体ごとに自由記載欄を設定できる。

なお、文言マスタで設定された固定文言、管理項目及び付加文言のシステムからの印字も可能であり、帳票レイアウトの変更とならず、ベンダが実装する範囲で、設定により表の挿入や削除も可能とする。

又、バーコードや二次元コードの印字に関する要件は機能・帳票要件の介護保険共通に記載している。
⑤ 窓空宛名部分の場所や大きさ、窓空宛名を含む帳票に対応した封筒レイアウトは、全庁的に統一したほうがよいため、住民記録システム標準仕様書に準拠する。 ⑥ 帳票に印字する文字フォントは、データ要件・連携要件標準仕様書（総論）に準拠する。 ⑦ 帳票に印字する文字サイズは、帳票タイトルを14ポイント、他の項目は10.5ポイントを基本とすること。帳票によっては所定枚数に収める必要がある等の理由により教示文等の項目の文字サイズの縮小が必要な個所は7ポイントを最小とする。 ⑧ システムから印字する各項目の文字数は、デジタル庁で定めるデータ要件のデータ項目の桁数が最大となる。機能・帳票要件に個別に定める場合を除き、⑦に定める文字サイズでは印字枠に収まらない文字数の場合は、印字枠に収まるように文字サイズを縮小や改行をして印字すること。