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

構成	内容
１．機能・帳票要件	機能・帳票要件における考え方及び事務ごとに必要となる機能要件・帳票要件を定義する。 ※帳票要件は出力対象帳票のみ定義
２．帳票一覧	法令・通知等で示している帳票または統一指針が必要な帳票を対象に一覧化。
３．帳票詳細要件	機能・帳票要件で示した帳票について、システムからの印字項目（以下「システム印字項目」という。）等及びレイアウトを定義する。

## １．機能・帳票要件機能・帳票要件は以下の通り、別紙に示す。 | 生活保護の機能・帳票要件 | 別紙2-Aのとおり | |------------------------------|-----------------| | レセプト管理の機能・帳票要件 | 別紙2-Bのとおり | 各事務の機能・帳票要件における考え方や留意事項は以下のとおりである。 1. 管理項目について 2. 「～等」の表記について 3. 一覧管理機能について 4. EUC機能の要件について 5. 基幹系他システム連携機能について 6. 外部帳票と内部帳票について 7. エラー・アラートのチェック条件について 8. 操作権限管理について 9. アクセスログ管理について（10）一括処理時の自動化について 1. 管理項目について該当する機能で管理すべき項目として「管理項目」をまとめている。「管理」とはデータの設定・保持・修正ができることをいい、参照又は表示のみを目的とした項目は管理項目として定めないこととしている。そのため、参照・表示のみを目的とした項目については、参照要件又は表示要件として記載している。図３-１管理項目の該当例と非該当例 ![](./assets/image3.png) なお、障害者福祉等の他システムからの連携で取得した情報のうち、生活保護システム側で保持・修正を行う場合は管理項目と定めている。例）他法活用点検に必要な他法情報を他システムから取得するが、取得した情報を生活保護システム内で保持して適宜修正等を行うこともあるため、他法情報管理・確認結果の登録の管理項目となる。 2. 「～等」の表記について機能・帳票要件の記載で「～等」と表現しているものがある。「～等」は性質別に考え方を次のとおり整理している。表３-２「～等」の表記と考え方

分類	記載箇所（例）	考え方
事務運用例として記載しているもの	![](./assets/image4.png)	左記事例では収入認定額から必要経費を控除する際に用いる控除額について、事務運用の例として記載している。控除種類は主に社会保険料・交通費となるが、実際には様々な費用があり、全て列挙することは現実的ではない。一方、主に発生する事務運用例を記載することは具体的イメージの補助となるため、「等」をつけて記載をしている。
あえて全て列挙しなくても法令等により要件に齟齬が生じないもの	![](./assets/image5.png)	左記事例では限度額の判定に必要な情報は法令・通知等で決まっているため、あえて全てを列挙せずとも要件に齟齬が生じないため、冗長とならないように「等」をつけて記載をしている。
要件を実現するための手段を参考として記載しているもの	![](./assets/image6.png)	左記事例では、帳票印字項目における印字編集条件を示しているが、実現手段の事例として、「パラメタ」をあげているだけで、実現方法は任意となる。（「等」を除くと記載したパラメタ以外のものが実装不可となるため、「等」をつけている）

3. 一覧管理機能について機能・帳票要件における一覧管理機能について、機能の考え方及び記載方針を次のとおり整理している。表３-３一覧管理機能の考え方と記載方針

観点	考え方	記載方針
一覧の抽出条件	地方自治体により抽出したい条件が様々である（例参照）ため、標準仕様書として全ての条件を網羅するとした場合、抽出条件は地方自治体の実態を勘案すると大半の場合標準オプションとして定義されることが考えられる。また、運用する中で必要と考えられる抽出条件が状況により変化することが考えられる。例）要否意見書に係る一覧では、「回収・未回収」や「医療機関コード」で検索」	EUC機能で「抽出条件は各事務にて定義している管理項目を対象とし、任意に指定できること」と定義することで、一覧管理機能として抽出条件を詳細に定義しないこととしている。
一覧の表示項目	必要な表示項目は地方自治体により様々であり、更に該当機能を使用する場面により変化する（例参照）ため、全てを網羅するとした場合、一覧に関する要件に膨大な項目を列挙することとなる。例）要否意見書に係る一覧で、発行情報だけでなく、他法情報や、ケース記録の情報等を併せて出力することが考えられる。	EUC機能で「表示（出力）項目は各事務にて対象となる一覧に関する管理項目、及び住民記録情報の関連する項目を対象とし、任意に指定できること」と定義することで、一覧管理機能として表示項目を詳細に定義しないこととしている。
一覧の実装方法	一覧機能の実現方法としては、一覧画面での表示や一覧帳票・CSV等のデータでの出力等様々考えられるが、運用に応じた適切な方法により一覧形式での確認ができれば運用に大きな支障は発生しないと思われる。また、「一定の件数以下であれば画面表示、それを超えればCSV等出力」といった実装方法の明確な線引きは、事務や対象機能、地方自治体規模等により様々と考えられる。	一覧管理機能に関する要件は、全て「一覧で確認できること」という記載とし、実装方法は問わないこととしている。

観点

考え方

記載方針

一覧の抽出条件

地方自治体により抽出したい条件が様々である（例参照）ため、標準仕様書として全ての条件を網羅するとした場合、抽出条件は地方自治体の実態を勘案すると大半の場合標準オプションとして定義されることが考えられる。また、運用する中で必要と考えられる抽出条件が状況により変化することが考えられる。例）要否意見書に係る一覧では、「回収・未回収」や「医療機関コード」で検索」

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

一覧の表示項目

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

例）要否意見書に係る一覧で、発行情報だけでなく、他法情報や、ケース記録の情報等を併せて出力することが考えられる。

EUC機能で「表示（出力）項目は各事務にて対象となる一覧に関する管理項目、及び住民記録情報の関連する項目を対象とし、任意に指定できること」と定義することで、一覧管理機能として表示項目を詳細に定義しないこととしている。

一覧の実装方法

一覧機能の実現方法としては、一覧画面での表示や一覧帳票・CSV等のデータでの出力等様々考えられるが、運用に応じた適切な方法により一覧形式での確認ができれば運用に大きな支障は発生しないと思われる。また、「一定の件数以下であれば画面表示、それを超えればCSV等出力」といった実装方法の明確な線引きは、事務や対象機能、地方自治体規模等により様々と考えられる。

一覧管理機能に関する要件は、全て「一覧で確認できること」という記載とし、実装方法は問わないこととしている。

ただし、事務運用上、明記をしないと支障が出ると認められるものは明記する。また、上記３つの観点を踏まえて、「（４）EUC機能の要件について」で、一覧管理機能とEUC機能の関連性を整理している。 4. EUC機能の要件について一覧管理機能とEUC機能は一部機能が重複する部分があるが、運用上最低限必要となる業務固有の一覧確認要件は「○○について一覧で確認できること」と明記した上で一覧管理機能での対応とすることとし、その他の要件については、EUC機能での対応という形で整理している。なお、業務固有の一覧確認要件については、一覧画面での表示、一覧帳票の出力、EUC機能実装等、実装方法は問わない。図３-２機能・帳票要件におけるEUC機能の記載例 ![](./assets/image7.png) 5. 基幹系他システム連携機能について基幹系業務との他システム連携機能において、生活保護用宛名情報／他法活用に係る障害者情報等の情報については、生活保護システム内での保持・不保持のいずれであっても機能上の影響はないと考えられるため、いずれの方式（主に下図パターン）での実装も可能として定義している。図３-３基幹系他システムとの連携イメージ ![](./assets/image8.png) 6. 外部帳票と内部帳票について帳票要件として定義する帳票は外部帳票を基本とする。担当主管課内の決裁用等の内部帳票は機能要件におけるEUC機能等を活用することとする。なお、外部帳票と内部帳票の定義は次のとおりである。表３-４外部帳票と内部帳票の考え方

帳票種類	帳票種類の考え方
外部帳票	住民や事業者等の外部に向けた帳票をいう。システムから出力すべき帳票として定義し、システムからの印字項目等を定める。
内部帳票	地方自治体の内部事務で使用する確認用リストや決裁用等の帳票をいう。システムから出力すべき帳票の種類及びシステムから印字する項目は定めず、EUC機能での対応を原則として定義する。

7. エラー・アラートのチェック条件について機能・帳票要件に定める各機能において、不正な状態で情報が管理されると事務運用に影響が発生するため、適宜データの矛盾をチェックする必要がある。主な矛盾の分類としては次のとおりである。表３-５矛盾の分類

分類	内容
物理的矛盾	項目の属性（英字、数字、日本語等）や項目長（桁数、バイト数）等で定義されている内容と合致しないもの。
論理的矛盾	存在しない日付（４月31日等）や数値等項目間の大小関係が逆転している等、一般的に矛盾していると言えるもの。
法制度等により規定されている条件を満たしていないものや業務プロセスが成立しない状態（※）となっているもの。 ※ 決定日が申請日より前の日付となっているような日付の前後関係が不整合な状態や支払データ作成時に必要な口座情報が存在しない等

分類

内容

物理的矛盾

項目の属性（英字、数字、日本語等）や項目長（桁数、バイト数）等で定義されている内容と合致しないもの。

論理的矛盾

存在しない日付（４月31日等）や数値等項目間の大小関係が逆転している等、一般的に矛盾していると言えるもの。

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

※ 決定日が申請日より前の日付となっているような日付の前後関係が不整合な状態や支払データ作成時に必要な口座情報が存在しない等

これらの矛盾に対して、エラー又はアラートのチェックを行い、不正なデータの登録を抑止することや操作者（入力者）への注意喚起を行う必要がある。エラー・アラートのチェック観点は、次のとおりである。表３-６エラー・アラートのチェック観点

チェック	チェック観点	チェックの事例と理由
エラー	物理的矛盾や論理的矛盾のいずれにもエラーとしてチェックする場合があり、システムからのアウトプットである帳票や集計、データ等の出力を正しく行うために業務システムにてチェックを行い、不正なデータが作成されないように抑止する。	エラーとなった国民健康保険団体連合会請求情報の修正処理ができること。 ⇒国民健康保険団体連合会から受領した請求情報と生活保護システムから出力した介護券の情報に差異がある場合はエラーとする必要がある。
アラート	物理的矛盾では空白や未設定を許容する場合であったり、論理的矛盾では法制度や当該制度の運用上、通常は入力されるべき項目が入力されていない場合や、やむを得ない事情等による例外規定がある場合であったり、操作者（入力者）に本来あるべき状態でないことを気付かせるために注意喚起する。	医療券・調剤券作成時に他法情報が入力されている場合は注意喚起のためアラート出力が行えるように制御できること。 ⇒医療扶助に優先して活用されるべき他法他施策による給付の有無を確認するため、アラートで注意喚起を促す必要がある。

チェック

チェック観点

チェックの事例と理由

エラー

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

エラーとなった国民健康保険団体連合会請求情報の修正処理ができること。

⇒国民健康保険団体連合会から受領した請求情報と生活保護システムから出力した介護券の情報に差異がある場合はエラーとする必要がある。

アラート

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

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

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

医療券・調剤券作成時に他法情報が入力されている場合は注意喚起のためアラート出力が行えるように制御できること。

⇒医療扶助に優先して活用されるべき他法他施策による給付の有無を確認するため、アラートで注意喚起を促す必要がある。

本仕様書におけるエラー・アラートのチェック条件において主に留意すべき事項は、次のとおりである。 1. エラー・アラートは機能・帳票要件に定める。 2. エラーチェックは「不正データを作成しない」という観点からデータ入力時にチェックすることを基本とするが、必要な情報を用いて帳票やデータ等を出力するまでに整備されれば影響がないケースも考えられるため、必ずしも入力時にチェックすることを求めるものではないこととする。 3. エラーチェックの内容は必ずしもメッセージによる表示に限定するものではなく、データの入力内容が一定条件を満たすまでデータ保存を不可にする、といった方法等でも問題ないこととする。 4. 文字列／数値といったデータの属性やデータの項目長に対するチェックは、データ要件で定められるデータ形式に準拠することとし、矛盾するものはエラーチェックとする。 5. 検索条件未入力のチェックや入出力ファイルの格納先（フォルダ）パスの存在確認チェック等は、画面要件に含まれるものであるため、本仕様書におけるエラー・アラートの要件としては定めないこととする。 6. 制度改正等により、従前までエラー・アラートとしていたチェックが不要となる場合や地方自治体の運用により必要とするチェックの設定が異なる等も想定されることから、エラー・アラートの設定は切り替え可能（エラー・アラートを表示しない設定も含む）とするべきかを考慮して実装する必要がある。 7. エラーについては、システム内部管理項目や帳票への印字項目・集計項目などのアウトプットとして必要となる項目を除き、エラーの設定は切り替え可能（エラーを表示しない設定も含む）とすることを考慮する必要がある。 8. 操作権限管理について操作権限管理は地方自治体で利用する事務処理システムとして共通した要件とすることが基本であることから、住民記録システム標準仕様書の「10.3 操作権限管理」に準拠することを基本とする。加えて、住民記録システム標準仕様書において住民記録システム固有の機能や表現が記載されている部分については、生活保護システムに固有の要件として置き換える必要がある。これらの考え方を踏まえて、以下のとおり定める。表３-７　操作権限管理（実装必須機能）

実装必須機能	住民記録システム標準仕様書での記載有無
発注者のシステム操作権限ポリシーに基づき、システムの利用者及び管理者に対して、個人単位でID及びパスワード、利用者名称、所属部署名称、操作権限、利用範囲及び期間が管理できること。	あり
職員のシステム利用権限管理ができ、利用者とパスワードを登録し利用権限レベルが設定できること。	あり
操作者IDとパスワードにより認証ができ、パスワードは利用者による変更、システム管理者による初期化ができること。	あり
利用者又は所属部署（課・係等）単位に、アクセス権限（利用できる機能・メニュー）を設定できること。	あり（一部変更）
利用者又は所属部署（課・係等）単位に、利用できる操作（登録・修正・削除・参照・印刷・ファイル出力）を設定できること。	なし
利用者及びアクセス権限の設定（登録・修正・削除・参照）は個別にできること。	なし
IDパスワードによる認証に加え、ICカードや静脈認証等の生体認証を用いた二要素認証に対応すること。（操作端末へのログイン時に対応している場合も含む） ※レセプト管理システムにおいては標準オプション機能として整理している	あり
複数回のアクセス失敗に対して、アクセス禁止状態にできること。	あり
同時に処理することによってデータの不整合が発生する可能性がある機能については、他の利用者が入力作業をしている間は、同一住民の情報について閲覧以外の作業ができないよう、排他制御ができること。 ※レセプト管理システムにおいては標準オプション機能として整理している	あり
利用者及び権限の設定（登録・修正・削除・参照）は一括でできること（人事異動時の負荷軽減を考慮し、例えばCSVファイルを取込み一括更新できる等）。	あり（一部変更）
アクセス権限の設定は、システム管理者により設定できること。	あり

表３-８　操作権限管理（標準オプション機能） | 標準オプション機能 | 住民記録システム標準仕様書での記載有無 | |:---|:--:| | 管理が本庁と他に分かれる場合は、本庁部署・利用者と他部署・利用者で更新・参照の権限を設定できること。（例：政令指定都市における本庁と区役所、複数福祉事務所のある自治体の本庁と福祉事務所等。） | なし | | 本庁以外の部署・利用者のアクセス権限については、自治体の執行体制に応じて、住民がどこでも手続きが行えるように管理場所（所管）以外でも更新できるようにするほか、管理場所（所管）は更新できるが他部署（他の管轄や区役所、福祉事務所等）は参照のみ・更新不可に設定できるようにもすること。政令指定都市における区役所の配下にある支所・出張所等も同様に権限設定が選択できるようにすること。 | なし | | 認証に当たっては、シングル・サイン・オンが使用できること。 | あり | 9. アクセスログ管理についてアクセスログ管理は地方自治体で利用する事務処理システムとして共通した要件とすることが基本であることから、住民記録システム標準仕様書の「10.2 アクセスログ管理」に準拠することを基本とする。加えて、住民記録システム標準仕様書において住民記録システム固有の機能や表現が記載されている部分については、生活保護システムに固有の要件として置き換える必要がある。これらの考え方を踏まえて、以下のとおり定める。表３-９　アクセスログ管理（実装必須機能）

実装必須機能	住民記録システム標準仕様書での記載有無
個人情報や機密情報の漏えいを防ぐために、システムの利用者及び管理者に対してログを管理（取得・検索・抽出・参照・ファイル出力を指す、以下、表3-10において同様）できること（IaaS事業者がログについての責任を負っている場合等、パッケージベンダ自体がログを提供できない場合は、IaaS事業者と協議する等により、何らかの形で本機能が地方自治体に提供されるようにすること）。	あり（一部変更）
ログイン認証ログを管理できること。	あり（一部変更）
操作ログを管理できること。	あり（一部変更）
イベントログ、通信ログ、印刷ログ、エラーログを管理できること（生活保護システムが動作するOS、運用管理ツール、DB等におけるログでよい）。	あり（一部変更）
他システム連携により取得した住民記録情報、住民税情報、国民健康保険情報、障害者福祉情報、児童福祉情報、介護保険情報に対する参照ログを管理できること。	なし
取得した各種ログは、地方自治体が定める期間保管でき、書き込み禁止等の改ざん防止措置をとること。例）保管期間は、イベントログは直近１年間、操作ログは５年間とする等	あり

表３-10　アクセスログ管理（標準オプション機能）

標準オプション機能	住民記録システム標準仕様書での記載有無
他システム連携により取得した健康管理情報に対する参照ログを管理できること。	なし

（10）一括処理時の自動化について一括処理の実行方法は、手動による実行の他に設定による自動実行があるが、地方自治体で利用する事務処理システムとして共通した要件とすることが基本であることから、住民記録システム標準仕様書の「9.1 バッチ処理」に準拠することを基本とする。加えて、住民記録システム標準仕様書において住民記録システム固有の機能や表現が記載されている部分については、生活保護システムに固有の要件として置き換える必要がある。これらの考え方を踏まえて、以下のとおり定める。表３-11　一括処理（標準オプション機能）

標準オプション機能	住民記録システム標準仕様書での記載有無
実行（起動）方法として、直接実行ができること。	あり
実行（起動）方法として、年月日及び時分、毎日、毎週ＸＸ曜日、毎月ＸＸ日、毎月末等を指定した方法（スケジュール管理による起動）で実行できること。	あり（一部変更）
他システム間連携等のイベント発生による実行（実行の契機となる前処理の完了後に起動）ができること。	なし
前回処理時に設定したパラメタを用いて、実行できること。パラメタは修正でき、再利用できること。	あり（一部変更）
一括処理を行う場合でも単件等の処理に影響が出ないこと。	あり（一部変更）
全ての一括処理の実行結果（処理内容や処理結果、処理時間、処理端末名称、正常又は異常の旨、異常終了した際はOSやミドルウェア等から出力されるエラーコード等）が確認できること。	あり
異常終了した場合の警告を生活保護システム内、または自治体が別途利用する他の通報システムに連携できること。	あり

## ２．帳票詳細要件帳票詳細要件では、機能・帳票要件にて、実装必須又は標準オプションとした帳票について、印字項目等を定義し「（別紙4-A及び4-B）帳票詳細要件」でまとめている。なお、可能な限り印字編集条件を記載するようにしている。また、帳票詳細要件として定義した帳票の様式（レイアウト）を「（別紙5-A及び5-B）帳票レイアウト」でまとめている。なお、システム印字項目とは、業務システムにて対象情報により編集し印字する項目のことをいい、固定文言等の帳票レイアウトに直接設定されている項目は含まない。帳票詳細要件及び帳票レイアウトの考え方や留意事項は以下のとおりである。 1. 「XX一覧表」といった内部管理・確認用の各種一覧の帳票については、機能要件として「XX情報を一覧で確認できること。」としEUC機能等を活用し作成することとするため、帳票詳細要件及び帳票レイアウトは定めない。 2. 帳票詳細要件に定義されたシステム印字項目は項目単位の類型に従うこととし、編集条件等は定義が必要な内容のみを記載している。 3. 帳票レイアウトは、法令・通知等で示されている様式を基に定義している。この帳票レイアウトをもとにシステム印字項目・帳票詳細要件で定めた項目の確実、かつ、効率的な実装を行うものであるが、各項目間の位置関係など、帳票レイアウトと大幅な差異がなければ、幅等の完全準拠を要求するものではない。その例として、項目の追加や順番の変更はできないが、項目の表示・非表示の制御（システム印字項目・帳票詳細要件で項目の表示・非表示を定義している項目に限る。）や長さ・太さ・色の変更、プレプリントの設定、項目の表示・非表示に伴うレイアウトにおける行数の変更、印字枠・表示枠の大きさ設定を可能とする。 4. 帳票における「第１章４（１）標準化範囲内の類型」（実装類型）の取扱いは次のとおりである。・帳票自体の出力における実装類型は、「１．機能・帳票要件」のとおりである。・帳票詳細要件のシステム印字項目で項目単位における類型の取扱いは次のとおりである。表３-12　帳票詳細要件における類型の取扱い

システム印字項目の類型	位置づけ（対ベンダ）	地方自治体への影響
実装必須印字項目	実装必須。	すべての項目が印字される。
標準オプション印字項目	システムからの印字は実装してもしなくてもよい。	ベンダが実装している場合は、印字される。

5. システム印字項目の編集方法は、帳票詳細要件の「印字編集条件など」で示す。また、各システム印字項目の印字編集条件に、制度改正に伴う該当区分の追加または変更がある場合は追加・変更を行うことを可能とする。二次元コードの規格を指定する場合は、「ISO（ISO/IEC18004」又は「JIS（JIS X 0510）」に限ることとする。主な「印字編集条件など」の類型は次のとおりである。なお、システム印字項目について、帳票レイアウトや出力状況に応じて短縮して表記することも可能である。（例：「生年月日」等について、元号をアルファベットで表記する「R○.○.○」のように短縮して表記することも可能である。）表３-13 「印字編集条件など」の類型

印字編集条件などの類型		記載例	類型の定義
記載なし		－	システムで保持しているデータをそのまま出力する。
定型	年月日	・和暦で表記する。・元号　年　月　日文言のみ印字する。・和暦表記、外国籍の場合は西暦表記する。・帳票要件で定義する一覧帳票等で用途に応じて、「R〇.〇.〇」のような短縮表記も可能とする。＜表記例＞・和暦表記　令和6年4月1日・西暦表記　2024年4月1日・短縮表記　R6.4.1	複数の帳票で定義されている項目は、同様の編集条件を定義する。
	カナ氏名	・全角カナで印字する。
	性別	・該当区分を印字する。
	住所	・住所出力が選択された場合のみ、印字する。・郵便番号、住所、方書を設定する。
	自治体名称	・福祉事務所名または地方自治体名を記載する。
	文書番号	・マスタ管理、もしくはフリー入力した文書番号を設定する。・文書番号を設定しない場合は、ブランクも可能である。
	敬称	・パラメタ等により初期設定が行える。
	教示文	・教示文ありを選択した場合のみ、文言を印字する。
	（控）の文言	・「控」を出力する場合、帳票タイトルに「（控）」の文言を印字する。
	再発行区分	・帳票を再発行する場合、左上部分に「再発行」の文言を印字する。
	担当者	・パラメタ等により初期設定が行える。
	職名	・パラメタ等により初期設定が行える。
	二次元コード・バーコード	・二次元コードまたはバーコードを印字する。
個別		【保護決定通知書における保護の種類の印字編集条件の例】・保護の種類を左詰めで印字する。・「生活扶助」、「住宅扶助」、「教育扶助」は固定とし４つ目以降に「介護扶助」、「医療扶助」、「生業扶助」の順に印字する。・「介護扶助」、「医療扶助」、「生業扶助」すべてがある場合、５つ目は「その他」とする。等	印字項目ごとに異なる編集条件を定義する。

6. 窓空宛名部分の場所や大きさ、窓空宛名を含む帳票に対応した封筒レイアウトは、全庁的に統一したほうがよいため、住民記録システム標準仕様書に準拠する。 7. 帳票に印字する文字フォントは、データ要件・連携要件標準仕様書（総論）に準拠する。 8. システムから印字する各項目の文字数は、デジタル庁で定めるデータ要件のデータ項目の桁数が最大となる。機能・帳票要件に個別に定める場合を除き、印字枠に収まらない文字数の場合は、印字枠に収まるように文字サイズを縮小や改行をして印字すること。 9. 帳票へ印字する文字のサイズ及び文字数については、市区町村毎に外国人の氏名等の表記方法や取扱いに差異があることから、特段の定めはしないこととするが、いずれにしても文字溢れ（文字切れ）が生じるケースがあることから、文字溢れ（文字切れ）が生じた場合の挙動を統一することを目的に、本仕様書にて以下のとおり示すこととする。 - 帳票出力時に、文字数が多くやむを得ず文字溢れ（文字切れ）が生じる場合や、未登録外字が含まれる場合はアラートを表示して注意喚起するとともに、「文字溢れ（文字切れ）エラーリスト」を出力して、文字溢れ（文字切れ）や未登録外字の情報を確認できるようにする。 - 文字溢れ（文字切れ）した項目は、印字可能な文字数まで印字、若しくは空欄出力とすることをパラメータ設定で選択可能とする。 10. 帳票レイアウト上で表記している青文字・青線のオブジェクト（システム印字項目ではないもの）は、標準オプション項目を示している。