--- type: standard-spec title: 地方税（共通）システム標準仕様書（機能要件） source: 総務省 profile: mrlgss-doc/0.1 business_code: "016" version: "5.1" notice_id: tax_soumu_016 norm_layer: L4 view: payload-table --- # 地方税（共通）システム標準仕様書（機能要件） 総務省「税務システム標準仕様書【第5.1版】」の機能要件（地方税（共通））を機械可読化したもの。 機能ID×機能名称×機能要件原文×実装区分×適合基準日を gov-notice payload として型付き正本にする。 - 全 132 機能（実装必須 64 / 標準オプション 61）。 - 各行の `source` は機能要件概念の URN（`urn:jp:gov:std:016:func:` + 7桁機能ID）。 - `legal_fields.機能要件` は仕様書原文（byte 保持）。`実装区分` は required/optional に正規化。 - 原本: 総務省「税務システム標準仕様書」一式（`009008_4_機能要件_税務共通.xlsx`）。 - 帳票要件は [帳票要件一覧](./forms.md)、データ要件・連携要件は [地方税（共通）（業務016）](../index.md) を参照。 > **抽出の性質**: 機能要件 xlsx のセルから機械的に構造化している。機能ID・実装区分・機能要件原文は > 確実に取れる。適合基準日は版で新規導入された機能のみ記載され（多くは空）、空欄は標準の適用日に従う。 ## 機能要件一覧 payload ```yaml notice_id: tax_soumu_016 tables: - table_no: 機能要件 kind: functional rows: - source: urn:jp:gov:std:016:func:0160001 legal_fields: 機能名称: 宛名管理 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: |- 税務システムにて宛名基本情報を保持できること、または住民記録システム（宛名管理システム等を経由する場合も含む）と連携し、宛名基本情報の取込ができること（ただし、住民記録システム等の外部データベースと連携し、税務システムでは宛名基本情報を保持せず、照会する形式での実装も可とする）。 宛名基本情報の変更履歴を保持できること。 住民記録システムとの連携時のエラーを把握できること。ただし、氏名・住所・生年月日・性別などの住民の基本情報についての住民記録システムからの連携項目は宛名管理機能側では更新できない。また、住民記録システムの過去履歴修正は反映されない。 実装区分: required 要件の考え方・理由: |- 一般的な住民情報システムの統合パッケージでは、税務システムとは別に宛名管理システム等を実装していることが多いが、税務システムとして業務上必要な機能を明確にする必要があるため、本項目を定義している。宛名管理システム等で実装している場合は読み替えることとする。当該機能については、宛名管理システムにて実装することも可とする。また、税務システムにおいて必要な宛名管理システム等として、本書に定義した以外の機能を実装することを妨げるものではない。 住民記録システムからの連携項目については、税務システム側での更新は実施しない運用を想定し、宛名管理機能側での更新は実施しないことを定義している。 - source: urn:jp:gov:std:016:func:0160002 legal_fields: 機能名称: 宛名管理 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: |- 住民、住民登録外者の宛名基本情報として以下を管理（参照、登録、修正）できること。 ＜住民、住民登録外者の基本情報＞ ・宛名番号 ・世帯番号 ・行政区（地区管理） ・管内管外の区分 ・住民区分（住民、住民登録外者、法人の別） ・住民種別（日本人・外国人の別） ・国籍/在留資格情報 ・住民状態（死亡・転出等） ・氏名 ・氏名振り仮名 ※外国人住民の場合はフリガナ ・氏名（通称） ・氏名（通称）フリガナ ・氏名（漢字、アルファベット）※外国人住民の場合のみ ・旧氏 ・旧氏フリガナ ・世帯主 ・続柄 ・生年月日 ・死亡年月日 ・非住民日 ・性別 ・郵便番号 ・住所コード ・住所（方書含む。） ・登録税目コード ・連絡先区分(自宅/勤務先/携帯) ・電話番号（複数管理も可能） ・eLTAX納税者ID 実装区分: required 適合基準日: 2026-04-01 要件の考え方・理由: |- 宛名番号の付番をするためのシステムについては、住民について住民記録システムが付番し他システムに連携することとし、住登外者については住登外者宛名番号等管理機能（デジタル庁が策定する「地方公共団体の基幹業務システムの共通機能に関する標準仕様書」において規定する住登外者宛名番号等管理機能をいう。以下同じ。）が付番することと整理する。 住登外者宛名番号管理機能のうち付番機能を税務システムに個別に実装する場合、以下のとおりとする。 ・税務システムと住登外者宛名番号管理機能のうち付番機能との間の連携については提供事業者の責任において対応することとし、必ずしもデータ連携機能の要件に定めるとおり、データ連携機能を実装する必要はない。 ・宛名番号を用いて住登外者に関する情報を他の基幹業務システムと連携することが想定されることから、税務システムと他の基幹業務システム間において、別人に同一の住登外者宛名番号を付番しないことを原則とするが、自治体の判断等にて住登外者に関する情報を他の基幹業務システムと連携しない運用を行う場合は、自治体の責任によって、基幹業務システムごとに住登外者に宛名番号を付番することを許容する。 - source: urn:jp:gov:std:016:func:0160003 legal_fields: 機能名称: 宛名管理 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: |- ＜住民、住民登録外者の基本情報（枝番2の続き）＞ ・市内転居日 ・転出先住所（転出の場合のみ） ・転出先住所（転出の場合のみ）の住所コード及びその郵便番号 ・転出予定日 ・前住所（転入前・転居前住所） ・前住所（転入前・転居前住所）の住所コード及びその郵便番号 ・個人番号（マイナンバー） ・異動事由 ・異動年月日 ・処理年月日 ・住所を定めた日、定めた事由 ・住民になった日、事由 ・異動に関する届出日 ・登録部署（情報を登録した課・係など） 転出先住所は転入通知受理後に確定住所で上書きされる。 住登外者宛名番号の付番・管理に関して、以下の処理ができること。 ・住登外者宛名番号管理機能（「地方公共団体情報システム共通機能標準仕様書」に規定する住登外者宛名番号管理機能をいう。）に対して対象者を照会し、照会結果を表示できること。 ・住登外者宛名番号の付番に際し、住登外者宛名番号管理機能より受領した照会結果に対象者が含まれる場合は、該当する住登外者宛名番号を当該対象者の宛名番号として管理し、その選択結果を住登外者宛名番号管理機能に対して連携できること。照会結果に対象者が含まれていない場合は、住登外者宛名番号管理機能に対して住登外者宛名番号の付番依頼ができること。 ・登録、更新した住民登録外者の宛名情報を住登外者宛名番号管理機能に対して連携できること。 実装区分: required 要件の考え方・理由: 枝番2のとおり - source: urn:jp:gov:std:016:func:0160004 legal_fields: 機能名称: 宛名管理 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: 個人番号（マイナンバー）の表示制御ができること。 実装区分: required 要件の考え方・理由: 枝番1のとおり - source: urn:jp:gov:std:016:func:0160005 legal_fields: 機能名称: 宛名管理 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: |- 法人の宛名基本情報として以下を管理（参照、登録、修正）できること。 ＜法人の基本情報＞ ・宛名番号 ・行政区（地区管理） ・管内管外の区分 ・組織区分 ・名称 ・名称カナ ・代表者名 ・本支店区分（本店、支店の別、不明） ・前後区分（法人格と名称の位置関係（前後）の別） ・設立年月日 ・閉鎖等年月日 ・郵便番号 ・所在地（方書含む。本店、支店ごとに管理） ・所在地の住所コード（本店、支店ごとに管理） ・電話番号 ・法人番号 ・法人番号公表の同意 ・法人種別（特徴事業者等） ・法人の異動事由 ・屋号 ・法人の連絡先区分（法人代表者/経理等） ・法人の担当部署 ・登録部署（情報を登録した課・係など） ・異動年月日、処理年月日 ・住民区分（住民、住民登録外者、法人の別） ・eLTAX納税者ID 実装区分: required 要件の考え方・理由: 枝番1のとおり - source: urn:jp:gov:std:016:func:0160006 legal_fields: 機能名称: 宛名管理 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: |- 住民、住民登録外者、法人の送付先・連絡先情報として以下を管理（参照、登録、修正）できること。 ＜住民、住民登録外者、法人の送付先・連絡先情報＞ ・宛名番号 ・行政区（地区管理） ・管内管外の区分 ・名称 ・名称カナ ・送付先（送付先の住所（方書を含む。）又は所在地（方書を含む。本店/支店）、送付先の郵便番号） ・連絡先区分（自宅/勤務先/携帯） ・電話番号 ・メモ ・登録日 ・利用廃止日 実装区分: required 要件の考え方・理由: 枝番1のとおり - source: urn:jp:gov:std:016:func:0160007 legal_fields: 機能名称: 宛名管理 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: 有効期間（開始年月日・終了年月日）を指定して、期限付きの送付先を管理（参照、登録、修正）できること。 実装区分: optional 要件の考え方・理由: 納税義務者が特定の期間転出するなど送付先が変更される期間が判明している場合の送付先管理方法として有用な面がある。一方で、税務システム等標準化検討会の構成員によって当該機能の要否が異なることから「標準オプション機能」とする。 - source: urn:jp:gov:std:016:func:0160008 legal_fields: 機能名称: 宛名管理 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: 氏名優先区分（例：外国人住民について、郵便物の送付先・各種証明書・各種通知書の氏名の記載として通称のみを希望するか、本名のみを希望するか。）を管理できること。 実装区分: optional 要件の考え方・理由: |- 住民記録システム標準仕様書に準じる。 住民記録システムにおいても「標準オプション機能」であるため、氏名優先区分については、税務として独立して管理する項目として定義しているが、住民記録システムや宛名管理システム等との共通的な管理は可とする。 - source: urn:jp:gov:std:016:func:0160119 legal_fields: 機能名称: 宛名管理 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: 氏名優先区分を税目ごとに管理できること。 実装区分: optional - source: urn:jp:gov:std:016:func:0160120 legal_fields: 機能名称: 宛名管理 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: 氏名優先区分について、本名と通称又は旧氏の併記の記載も選択できること。 実装区分: optional - source: urn:jp:gov:std:016:func:0160009 legal_fields: 機能名称: 宛名管理 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: 氏名優先区分を住民記録システムから連携できること。 実装区分: optional 要件の考え方・理由: 住民記録システムからの連携についても併せて、「標準オプション機能」とする。 - source: urn:jp:gov:std:016:func:0160135 legal_fields: 機能名称: 宛名管理 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: |- 住民、住民登録外者、法人の代理人等情報として以下を管理（参照、登録、修正）できること。 ＜住民、住民登録外者、法人の代理人等情報＞ ・宛名番号 ・世帯番号 ・行政区（地区管理） ・管内管外の区分 ・肩書（相続人代表者、相続財産清算人、清算人、管財人、納税承継人、破産管財人、相続人・包括受遺者、納税管理人、法定代理人、成年後見人、保佐人、補助人、その他） ・氏名、名称 ・名称カナ ・郵便番号 ・住所コード ・住所（方書含む。） ・死亡年月日（閉鎖等年月日） ・送付先（送付先の住所・方書、送付先の郵便番号） ・電話番号 ・メモ ・代理人等の有効期間（開始年月日、終了年月日） 実装区分: required 適合基準日: 2026-04-01 要件の考え方・理由: 世帯番号、行政区（地区管理）、管内管外の区分、氏名、名称、名称カナ、郵便番号、住所コード、住所（方書き含む。）、死亡年月日（閉鎖年月日）、送付先、電話番号、メモについては、宛名番号にて住民、住登外者、法人と代理人等を紐づけることで、代理人等の宛名マスタを参照する方法も可とする。 - source: urn:jp:gov:std:016:func:0160011 legal_fields: 機能名称: 宛名管理 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: 上記宛名基本情報のうち送付先・連絡先情報及び代理人等情報については、宛名・税目単位に管理できること。加えて、送付先・連絡先・代理人情報については、税目共通・収滞納の項目を管理できること。 実装区分: required 要件の考え方・理由: |- 税務では、住登外者も納税義務者になり得るため、住登外者の宛名情報を管理する必要があるが、当該納税義務者が転入や再転出をした場合、宛名情報の同一性の維持が必要となる。よって、同一人の紐づけ機能や、同一人の可能性がある対象の出力機能を定義することで、業務運用の効率化が図られると考え、「実装必須機能」として定義している。 送付先情報等は、各団体の規模や体制によって、税目横断で共通で利用する場合と、税目ごとに利用する場合がある。よって、宛名単位で管理する共通の送付先情報等とは別に、税目単位で管理する送付先情報等を保有する構成とし、各税目の送付先情報等の登録が無い場合は共通の送付先情報等を利用して業務を実施することを想定している。 なお、宛名登録の運用としては、まず必要となった税目で宛名（税目共通の宛名）を作成し、他の税目（又は地方税以外での業務）でもそのまま利用できる場合はそのまま利用し、送付先などが異なる場合は当該税目用に個別の送付先設定をすることを想定しているため、必要に応じて税目単位への複写する機能の実装でも問題ない。 - source: urn:jp:gov:std:016:func:0160012 legal_fields: 機能名称: 宛名管理 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: 同一人で複数の宛名が存在する場合に、宛名番号の関連付けを行い、関連付けした宛名の中で、代表して使用する宛名を管理（設定・解除）できること。 実装区分: required 適合基準日: 2026-04-01 - source: urn:jp:gov:std:016:func:0160013 legal_fields: 機能名称: 宛名管理 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: |- 同一人の可能性のある者について、任意のタイミングで出力できること。 任意の登録・更新日を期間指定し、住民登録者若しくは同一人の可能性のある住民登録外者の宛名情報を出力できること。 実装区分: optional - source: urn:jp:gov:std:016:func:0160122 legal_fields: 機能名称: 宛名管理 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: 不要な宛名情報を抽出できること。また、一括して削除することができること。 実装区分: optional 要件の考え方・理由: 過去5年間どの税目でも利用がない宛名を削除する運用を想定しているもの。抽出条件は事業者の実装に委ねることとする。 - source: urn:jp:gov:std:016:func:0160014 legal_fields: 機能名称: 宛名管理 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: 宛名情報を使用している業務（税目）の照会ができること。 実装区分: optional - source: urn:jp:gov:std:016:func:0160015 legal_fields: 機能名称: 宛名管理 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: 任意の付番ルールに基づき付番管理ができること。また、宛名番号及び世帯番号について任意の番号による付番管理ができること。 実装区分: optional 要件の考え方・理由: 宛名番号及び世帯番号については、各団体にて多様な採番ルールを採用しているため、機能として網羅的に定義しないこととした。一方で、現行の採番ルールを活かし、各団体にて効率的な業務運用ができるよう、各パッケージ製品に標準的に実装されている自動採番機能については、事業者の実装に委ねるため「標準オプション機能」として定義している。 - source: urn:jp:gov:std:016:func:0160016 legal_fields: 機能名称: 宛名管理 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: 市町村合併時の転出先住所の一括更新ができること。 実装区分: optional - source: urn:jp:gov:std:016:func:0160017 legal_fields: 機能名称: 宛名管理 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: 国税庁の法人マスターデータの取込ができること。 実装区分: optional - source: urn:jp:gov:std:016:func:0160018 legal_fields: 機能名称: 宛名管理 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: 法人番号情報提供サイトからダウンロードできる法人情報を取込み、名称や住所等で一致した宛名に対し、法人番号を一括で反映できること。 実装区分: optional - source: urn:jp:gov:std:016:func:0160145 legal_fields: 機能名称: 宛名管理 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: ソート機能のため、番地・枝番・部屋番号等を数値によりコード管理できること。なお、番地・枝番・部屋番号等が文字列の場合も数値に変換した上で管理すること。 実装区分: optional 要件の考え方・理由: 各種帳票類のソートを円滑に行いたいとの地方団体の意見を受け、「標準オプション機能」として定義している。 - source: urn:jp:gov:std:016:func:0160019 legal_fields: 機能名称: メモ 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: |- 個人・法人・課税客体等を単位とし、入力者及び登録日時ごとに記載事項を限定しないメモの入力が可能であること。 個人・法人・課税客体等を単位に複数件のメモの登録が可能であること。 宛名システム等の画面上で業務共通のメモを管理でき、業務間で情報共有できること。 また、メモを登録した税目が画面上で容易に確認できること。 メモは入力権限及び閲覧権限を設定できること。 メモの期限管理を設定できること。 1件当たり2,000文字管理できること。 実装区分: required 要件の考え方・理由: |- 税務共通要件で定義しているメモ機能は、原則として各税目のシステムに共通的に実装されるべきメモ機能を定義している。ただし、宛名管理システムで宛名基本情報を管理し、税務システムで参照するシステム構成の製品の場合は、宛名管理システム（宛名基本情報画面等）にも同等の機能を求めることとする。 各税目固有に求められるメモに関する機能は、各税目の機能要件で個別に定義することとした。例えば、個人住民税では年度ごとにメモを管理したいといった意見を受けて、当該要件を個別に定義している。 税務システムは、個人・法人・課税客体ごとに台帳管理されるため、メモもそれらの単位ごとの管理を定義している。 管理文字数については、データ移行の阻害要因となり得るため、文字数の上限を定義している。 メモ機能の性質上、運用の中で堆積してしまう傾向があるといった意見を受けて、期限管理を定義している。期限の到達によりメモを自動削除し、不要なメモの堆積を予防することを想定している。 特定の情報管理画面等へ展開せずとも、メモの登録有無を把握できることが大きく業務効率化に寄与するといった意見を受け、個人画面でメモが登録されていることの気付き機能を定義した。なお、メモアイコンの点灯やポップアップ等実現方法は問わないこととしている。 メモへの登録内容を定型文としてテンプレート化したいといった意見があったが、メモの汎用性が損なわれるため、定義しない。 特定の文言を対象者のメモに一括登録したいといった意見があったが、RPA等を活用した業務効率化が可能な領域であるため、定義しない。 備考: 課税客体は税務システムの課税対象となる軽自動車、土地、家屋、償却資産を指す。 - source: urn:jp:gov:std:016:func:0160020 legal_fields: 機能名称: メモ 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: 世帯を単位とし、記載事項を限定しないメモの入力が可能であること。 実装区分: optional 要件の考え方・理由: |- メモ内容の補足情報として、画像ファイルを登録したいといった意見があったが、少数意見であり効果も限定的であるため、標準オプション機能として定義している。 メモで管理している文字列を対象にキーワード検索できる機能について要望があったが、少数意見であり効果も限定的であるため、「標準オプション機能」として定義している。 - source: urn:jp:gov:std:016:func:0160021 legal_fields: 機能名称: メモ 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: 世帯を単位に複数件のメモの登録が可能であること。 実装区分: optional 要件の考え方・理由: 同上 - source: urn:jp:gov:std:016:func:0160022 legal_fields: 機能名称: メモ 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: メモのタイトルを管理できること。 実装区分: optional 要件の考え方・理由: 同上 - source: urn:jp:gov:std:016:func:0160023 legal_fields: 機能名称: メモ 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: 宛名個人画面でメモが登録されていることの気付き機能（メモアイコンの点灯やポップアップ等）を管理できること。 実装区分: optional 要件の考え方・理由: 同上 - source: urn:jp:gov:std:016:func:0160024 legal_fields: 機能名称: メモ 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: メモ内文字列について、キーワード検索ができること。 実装区分: optional 要件の考え方・理由: 同上 - source: urn:jp:gov:std:016:func:0160025 legal_fields: 機能名称: メモ 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: メモに画像ファイルを登録できること。 実装区分: optional 要件の考え方・理由: 同上 - source: urn:jp:gov:std:016:func:0160026 legal_fields: 機能名称: 入力場所・入力端末 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: |- システムログや各種証明書発行管理に使用するため、システムを使用する場所として、本庁、支所、出張所、システム利用課等の入力場所及び入力端末等の登録管理ができること。 指定都市においては、行政区（総合区を設置している場合は総合区。以下同じ。）（区役所）を管理できること。 実装区分: required 要件の考え方・理由: 住民記録システム標準仕様書に準じる。 - source: urn:jp:gov:std:016:func:0160027 legal_fields: 機能名称: 住所マスタ 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: |- 住民の住所については住民記録システムから取得すること。 当該システムにおいて、住所登録が必要な場合は、住所マスタを保持すること。 実装区分: required 要件の考え方・理由: デジタル庁による全標準化対象20業務への修正指示に基づき、業務横断的な整合性を取る形で記載した。 - source: urn:jp:gov:std:016:func:0160028 legal_fields: 機能名称: 役場マスタ 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: |- 全国の役場マスタ（役場名、住所等）を管理すること。 一括でデータ等を取込、役場マスタを一括更新できること。 ただし、宛名管理システム等の外部データベースと連携し、税務システムでは情報を保持せず、照会する形式での実装も可とする。 実装区分: required - source: urn:jp:gov:std:016:func:0160029 legal_fields: 機能名称: 金融機関マスタ 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: |- 金融機関マスタデータ（金融機関コード、金融機関名、金融機関名かな、支店コード、支店名、支店名かな）を管理できること。 ただし、収納や口座システム等の外部データベースと連携し、税務システムでは情報を保持せず、照会する形式での実装も可とする。 金融機関マスタデータを修正する権限（修正の可否・範囲）を特定ユーザーに限定できること。 各地方団体の収納代理金融機関以外の振替依頼申請をエラーとして設定できること。 実装区分: required 要件の考え方・理由: |- 不正防止のため、金融機関マスタの修正範囲・権限を特定ユーザーに限定する権限制御機能を定義している。 業務効率化と精度向上のため、各地方団体の収納代理金融機関以外の振替依頼申請をエラーとする機能を定義している。 - source: urn:jp:gov:std:016:func:0160030 legal_fields: 機能名称: 金融機関マスタ 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: 全国銀行協会フォーマットの様式を基に、金融機関マスタデータの一括更新が可能であること。 実装区分: optional 要件の考え方・理由: デジタル庁による全標準化対象20業務への修正指示に基づき、業務横断的な整合性を取る形で記載した。 - source: urn:jp:gov:std:016:func:0160031 legal_fields: 機能名称: 金融機関マスタ 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: 金融機関マスタデータ（金融機関有効開始日、金融機関有効終了日、指定金融区分コード、電子納付対応有無コード、店舗有効開始日、店舗有効終了日、本店支店区分、手形交換所番号、店舗郵便番号、店舗住所、店舗電話番号、利用開始日、利用終了日）を管理できること。 実装区分: optional 要件の考え方・理由: |- デジタル庁による全標準化対象20業務への修正指示に基づき、業務横断的な整合性を取る形で記載した。 また、枝番1は全国銀行協会フォーマットを想定したものであるが、当該フォーマット以外では利用開始日、利用修正日を取り込むケースがあること踏まえ左記の項目を「標準オプション機能」とした。 - source: urn:jp:gov:std:016:func:0160130 legal_fields: 機能名称: 公印管理 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: |- 発行者及び職務代理者の公印が管理できること。また、発行者及び職務代理者毎に複数種類の公印が管理でき、帳票ごとに公印の種類を設定できること。 職務代理者の指定期間を設定できること。 システムから出力される公印印字に対応する各種証明書・各種通知書には、帳票ごとに、発行者又は職務代理者の職名・氏名、公印、発行年月日等印字の有無及び公印の種類（発行者又は職務代理者の印）が選択できること。また、発行者又は職務代理者の職名を印字する場合は、都道府県名を印字すること。ただし、指定都市においては都道府県名を省略することも可能とする。 なお、公印は電子公印に対応し、種類（発行者又は職務代理者の印、証明書専用の印）が選択できること。また、「公印省略」「この印は黒色です」等の任意の固定文言が印字できること。 なお、本庁・支所ごとの登録管理は不要とする。 実装区分: required 適合基準日: 2026-04-01 要件の考え方・理由: |- 電子公印のサイズは、住民記録システム標準仕様書に準じる。 市区長村長印と職務代理者印の切替え時のミスを防止するため、職務代理者の指定期間を設定する機能を定義している。 複数の公印を保有し、帳票の印字余白の大きさなどによって使い分けている地方団体が多いため、市区町村長及び職務代理者のそれぞれ複数の公印を管理する要件を定義している。 備考: 税務システム標準仕様書　本編30ページ【標準様式・帳票・共通項目】　項番７　自治体名型について説明するもの。 - source: urn:jp:gov:std:016:func:0160131 legal_fields: 機能名称: 公印管理 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: 支所・出張所の専用公印を持つこと。 実装区分: prohibited 適合基準日: 2026-04-01 要件の考え方・理由: |- 住民記録システム標準仕様書に準じる。 同一帳票につき、事務を所管する課が異なることを理由に異なる公印を持つことについても同様であると想定している。 備考: 税務システム標準仕様書　本編30ページ【標準様式・帳票・共通項目】　項番７　自治体名型について説明するもの。 - source: urn:jp:gov:std:016:func:0160034 legal_fields: 機能名称: 発行者 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: |- 各種証明書・各種通知書の発行者は、市区町村長、市区町村長に代わって市区町村長から事務の委任を受けた者及び職務代理者の３件について、職名・氏名を管理できること。 また、期間等事前に登録した条件によって、自動的に切り替わることができるよう職務代理者期間の管理ができること。 指定都市においては、市長、市長に代わって市長から事務の委任を受けた者、市長の職務代理者、区長、区長に代わって区長から事務の委任を受けた者及び区長の職務代理者を管理ができること。 実装区分: required 要件の考え方・理由: 住民記録システム標準仕様書に準じるとともに、地方税法第３条の２に基づき定義している。 - source: urn:jp:gov:std:016:func:0160035 legal_fields: 機能名称: 発行者 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: 各種証明書・各種通知書の発行者を「○○長　公印」のように氏名空欄とできること。 実装区分: optional 要件の考え方・理由: 税務では、選挙期間中においても事前に各種通知書の大量印刷を実施することが想定されることから、首長などの氏名をあえて印字しないことで、各種通知書の差替えを防止する運用も見込まれるため、首長などの氏名を空欄とする機能を「標準オプション機能」として定義している。 - source: urn:jp:gov:std:016:func:0160036 legal_fields: 機能名称: 改元 大分類: 1. 共通機能 中項目: 1.1. 管理項目 機能要件: |- パラメータ設定等にて、アプリケーションへの変更なしで改元に対応できること。 また、年度途中でも事前に登録した改元施行日に、新元号に自動的に切り替わること。 実装区分: required 要件の考え方・理由: 令和の改元作業での課題も踏まえ、プログラム改修なしに改元対応できる要件を追加している。 - source: urn:jp:gov:std:016:func:0160037 legal_fields: 機能名称: 検索機能 大分類: 1. 共通機能 中項目: 1.2. 検索・照会 機能要件: |- 必要な条件を設定して、検索が可能であること。 システム利用者（ID単位）ごとに、一度検索ダイアログ等で設定した値（検索履歴）については、自動的にその設定値が、一定の件数保存されること。 また、それら検索履歴を選択することによって、同じ条件による再検索及び検索履歴を活用することによる新たな検索にも対応できること。 複数検索キーによる検索ができること。 実装区分: required 要件の考え方・理由: |- 窓口や電話の問合せ対応による検索事務において、処理の中断と再開を繰り返して進行するため、直近の検索履歴を活用した検索事務の実現は、業務効率化に寄与する有益な機能となる。 検索キー等の必要な条件については各税目の機能要件において、代表的なものがあれば記載を行っている。 ただし、どのような検索キーを実装すべきかについては、問い合わせ対応の際などに最小限の画面遷移で個人や法人、課税客体等を絞り込み、対象画面を表示する手順として考える必要があり、実際には各システムベンダの創意工夫の範囲である。 上記の意図から、各社のシステムにおいて、操作性を向上させる目的で各税目で定義されている検索キーの省略や追加を行うことは差し支えない。 - source: urn:jp:gov:std:016:func:0160038 legal_fields: 機能名称: 検索機能 大分類: 1. 共通機能 中項目: 1.2. 検索・照会 機能要件: 照会を行った宛名番号の履歴を保持し、再検索の条件に活用できること。 実装区分: optional 要件の考え方・理由: 操作性に係る機能ではあるが、全ての地方団体にとって有用な機能であると考えられるため、宛名番号の履歴からの再検索機能について、「標準オプション機能」として定義している。 - source: urn:jp:gov:std:016:func:0160039 legal_fields: 機能名称: 検索関連機能 大分類: 1. 共通機能 中項目: 1.2. 検索・照会 機能要件: 検索後の同個人名一覧・同法人画面一覧等に課税ある税目を表示することができること。 実装区分: optional 要件の考え方・理由: |- 検索対象の正確な絞り込みを行う必要性から、複数検索キーによる検索機能を定義した。 検索結果から即時に検索対象を特定できるよう、検索後の同個人名一覧・同法人画面一覧等に課税のある税目を表示する機能を、「標準オプション機能」として定義している。 - source: urn:jp:gov:std:016:func:0160040 legal_fields: 機能名称: 検索関連機能 大分類: 1. 共通機能 中項目: 1.2. 検索・照会 機能要件: 旧氏による検索ができること。 実装区分: optional 要件の考え方・理由: 旧氏併記の法改正により旧氏で検索するケースが増えることに鑑み、旧氏検索を「標準オプション機能」として定義している。 - source: urn:jp:gov:std:016:func:0160041 legal_fields: 機能名称: 検索文字入力 大分類: 1. 共通機能 中項目: 1.2. 検索・照会 機能要件: 氏名に関する検索は、住民記録システム標準仕様書に準拠した「あいまい検索」（異体字や正字も包含した検索を除く。）ができること。 実装区分: required 要件の考え方・理由: デジタル庁による全標準化対象20業務への修正指示に基づき、業務横断的な整合性を取る形で記載した。 - source: urn:jp:gov:std:016:func:0160042 legal_fields: 機能名称: 検索文字入力 大分類: 1. 共通機能 中項目: 1.2. 検索・照会 機能要件: |- 以下のあいまい検索ができること。 　・検索文字から、異体字や正字も包含した検索ができること。 例：検索文字の例 「辺」で検索時は 　「邊」、「边」、「邉」、「𨘢」等、 「浜」で検索時は 　「濱」、「頻」、「濵」、「滨」等、 「藤」で検索時は 　「䕨」、「籘」、「籐」等が検索対象文字となる。 実装区分: optional - source: urn:jp:gov:std:016:func:0160043 legal_fields: 機能名称: 支援措置対象者照会 大分類: 1. 共通機能 中項目: 1.2. 検索・照会 機能要件: |- 照会した支援措置対象者（併せて支援を求める者などを含む。）に該当する個人の情報を確認する場合（検索結果画面等も含む）において、常に支援措置期間中又は仮支援措置期間中である旨が明示的に確認できること。 検索結果・照会画面等に支援措置対象者が含まれる場合、表示時に該当者の住所が直ちに表示されないこと。 なお、支援措置対象者が所属する世帯、固定資産の共有者を閲覧する場合も同様とし、対象者が明示されることとする。 実装区分: required 要件の考え方・理由: 住民記録システムの標準仕様書の内容を基に、業務フローや操作が多岐にわたる税務の特性に応じて、機能を具体化している。中でも、検索や各種処理にて不要な個人情報の表示を避けるための機能へのニーズが高いと判断し、「実装必須機能」として定義している。 - source: urn:jp:gov:std:016:func:0160044 legal_fields: 機能名称: 支援措置対象者照会 大分類: 1. 共通機能 中項目: 1.2. 検索・照会 機能要件: 支援措置対象者の住所を画面に表示する場合、閲覧理由を入力できること。また、入力した閲覧理由は、閲覧者・日時と合わせて履歴管理できること。 実装区分: optional - source: urn:jp:gov:std:016:func:0160045 legal_fields: 機能名称: 支援措置対象者照会 大分類: 1. 共通機能 中項目: 1.2. 検索・照会 機能要件: 支援措置終了後であっても、支援開始日及び支援終了日が確認できること。 実装区分: optional - source: urn:jp:gov:std:016:func:0160124 legal_fields: 機能名称: 支援措置対象者照会 大分類: 1. 共通機能 中項目: 1.2. 検索・照会 機能要件: 宛名番号の関連付けを行っている場合、関連付けした宛名全てに支援措置対象者情報が連携されること。 実装区分: optional 要件の考え方・理由: 宛名の関連付けを行っている場合、支援措置対象者の情報の連携漏れが発生するリスクがあるため要件化したもの。 - source: urn:jp:gov:std:016:func:0160046 legal_fields: 機能名称: 処理注意者照会 大分類: 1. 共通機能 中項目: 1.2. 検索・照会 機能要件: |- 照会した処理注意者に該当する個人の情報を確認する場合（検索結果画面等も含む）において、処理注意者である旨が明示的に確認できること。 検索結果・照会画面等に処理注意者が含まれる場合、該当者が「他団体における支援措置対象者」であるなど、表示時に支援措置対象者と同等の対応が必要な該当者については、住所が直ちに表示されないこと。 なお、処理注意者が所属する世帯、固定資産の共有者を閲覧する場合も同様とし、対象者が明示されることとする。 実装区分: required 要件の考え方・理由: 処理注意者においても、検索や各種処理にて不要な個人情報の表示を避けるための機能へのニーズが高いと判断し、「実装必須機能」として定義している。 - source: urn:jp:gov:std:016:func:0160047 legal_fields: 機能名称: 処理注意者照会 大分類: 1. 共通機能 中項目: 1.2. 検索・照会 機能要件: 処理注意者の住所を画面に表示する場合、閲覧理由を入力できること。また、入力した閲覧理由は、閲覧者・日時と合わせて履歴管理できること。 実装区分: optional - source: urn:jp:gov:std:016:func:0160048 legal_fields: 機能名称: 処理注意者照会 大分類: 1. 共通機能 中項目: 1.2. 検索・照会 機能要件: 終了後であっても、開始日及び終了日が確認できること。 実装区分: optional - source: urn:jp:gov:std:016:func:0160125 legal_fields: 機能名称: 処理注意者照会 大分類: 1. 共通機能 中項目: 1.2. 検索・照会 機能要件: 宛名番号の関連付けを行っている場合、関連付けした宛名全てに処理注意者情報が連携されること。 実装区分: optional 要件の考え方・理由: 宛名の関連付けを行っている場合、処理注意者の情報の連携漏れが発生するリスクがあるため要件化したもの。 - source: urn:jp:gov:std:016:func:0160144 legal_fields: 機能名称: 支援措置対象者への発行抑止 大分類: 1. 共通機能 中項目: 1.3. 抑止設定 機能要件: |- 支援措置対象者（併せて支援を求める者を含む。）が含まれる外部帳票（各種証明書、各種通知書）の発行を実施しようとする際に、エラーとすることができること。審査の結果、各種証明書・各種通知書の発行を行う場合には、エラーを解除できること。なお、発行抑止を一時的に解除した場合、一定時間経過後又は一定回数証明書を発行した後に自動的に発行抑止が再設定されること。 さらに、支援措置期間及び仮支援措置期間の設定は、住民記録システム等と同期することを想定しているが、支援措置期間及び仮支援措置期間中に転出したものについては、ただちに支援措置対象外とせず、継続して支援措置対象者と同等の管理を実施できる機能を備えること（終期は手動更新とすることや処理注意者としての管理に切り替わること等の機能を想定している）。 発行抑止の対象となる帳票について、支援措置対象者本人以外からの請求があった場合は、住所欄を「記載省略」等として発行できること。 発行抑止の解除機能について、権限設定が可能であること。 実装区分: required 要件の考え方・理由: |- 住民記録システム標準仕様書の記載を基にしているが、支援措置対象者の情報は住民記録システム等から連携し、税務システムでは情報を設定・修正しない運用を想定しているため、支援措置期間の延長等に関する機能は定義していない。ただし、税務では住登外者への各種証明書・各種通知書の発行を実施するため、支援措置期間中に転出者した場合などにシステム上ただちに支援措置対象外とする実装とした場合、本来発行を抑止すべき状況の方への各種証明書・各種通知書の発行がなされるリスクがある。このため、支援措置期間中の転出者について、支援措置対象者と同等の管理を実施できる機能を「実装必須機能」として定義している。 また、行政からの支援措置対象者の情報の漏洩はあってはならないと考えるため、再設定や情報の表示・印刷における漏洩防止のための機能を定義している。 備考: なお、法人の所在地については公開情報であることから、発行抑止の対象外とする。 - source: urn:jp:gov:std:016:func:0160050 legal_fields: 機能名称: 処理注意者への発行抑止 大分類: 1. 共通機能 中項目: 1.3. 抑止設定 機能要件: |- 住民登録外者等の個人対象者に対し、税務システム固有の処理注意情報を管理（参照、登録、修正、削除）することで、支援措置対象者と同様の発行抑止ができること。なお、同一人として関連付けられた宛名すべてに対して、発行抑止が有効となること。なお、処理注意者に該当する個人の情報を確認する場合（検索結果画面等も含む）において、常に処理注意者である旨が明示的に確認できること。 ＜処理注意情報＞ ・処理注意区分（処理注意となる事由の分類） ・メモ ・開始日及び終了日 実装区分: required 要件の考え方・理由: |- 支援措置対象者の情報とは別に、税務個別での処理注意者情報の管理が必要であることから、処理注意者情報の管理と外部帳票の発行抑止機能を定義している。 なお、住民への住民票の発行を主とする住民記録業務とは異なり、住登外者への課税や証明書発行なども必要となるため、同一人とする宛名についても、継続的に処理注意者情報を管理できる機能を定義している。 - source: urn:jp:gov:std:016:func:0160051 legal_fields: 機能名称: 処理注意者への発行抑止 大分類: 1. 共通機能 中項目: 1.3. 抑止設定 機能要件: 処理注意者については、処理注意区分に応じて、支援措置対象者と同様の発行抑止と、発行時のアラート表示が選択できること。 実装区分: required - source: urn:jp:gov:std:016:func:0160052 legal_fields: 機能名称: 他システム連携 大分類: 1. 共通機能 中項目: 1.3. 抑止設定 機能要件: |- 抑止対象者設定及び解除について、住民記録システムからのデータを取込もしくは必要に応じた照会ができること（宛名管理システム等を経由しても可）。 支援措置対象者に異動があった場合、異動を検知できる仕組みがあること。 実装区分: required 要件の考え方・理由: 住民記録システムから支援措置情報が連携され手動で抑止設定が必要な場合 及び 転出などにより処理注意者としての設定が必要な場合などを想定し、異動リストなどの異動を検知できる仕組みを機能として定義した。 備考: 税務システムでは、住民記録システム（もしくは宛名管理システム等）から連携された支援措置対象者の情報を用い、発行抑止を実施することを想定している。 - source: urn:jp:gov:std:016:func:0160053 legal_fields: 機能名称: 端数処理・税額計算方針 大分類: 1. 共通機能 中項目: 1.4.端数処理・税額計算 機能要件: 過年度更正における税額等の計算について、対象年度に実施した計算方式を再現できること。 実装区分: prohibited 要件の考え方・理由: |- 本取り組みでは、税務システムにおけるカスタマイズ要因の排除を目的に、端数処理方式の標準化を定義している。端数処理の標準化を実施するには、過年度更正における端数処理についても同様に標準化する必要があるため、"過年度分の端数処理の再現"は「実装不可機能」として定義している。ただし、過年度更正における税額等の計算・算出をシステム外で行うことについてまで規定しているものではない。 本機能は端数計算についてを記載している為、制度的な算出方法の変更があった場合に、当時の課税年度における税額計算を行うことを否定するものではない - source: urn:jp:gov:std:016:func:0160126 legal_fields: 機能名称: 送付先の記載 大分類: 1. 共通機能 中項目: 1.5. 証明・通知 機能要件: |- 各種通知書の送付について、宛名管理及び住所マスタを参照して、住民、住民登録外者又は法人の基本情報に記録された住所・所在地（本店/支店）及び氏名・名称を設定すること。 ただし、設定に際しては、①税目個別の代理人等情報、②税目共通の代理人等情報、③税目個別の送付先・連絡先情報、④税目共通の送付先・連絡先情報、⑤基本情報の優先順位で設定できること。 なお、各項目において税目共通と税目個別の両方の設定がある場合は、税目個別の設定を優先させる。 方書については、省略せず、全ての各種通知書に必ず記載すること。 各種証明書については、住所の記載省略を選択して印刷できること（本人以外への発行の場合）。 実装区分: required 適合基準日: 2026-04-01 要件の考え方・理由: |- 納税通知書などを郵送する際、納税義務者本人の住所以外への送付が想定される。このため、相続人などの代理人等が設定されている場合は代理人への送付を優先する。また、代理人等が設定されていない場合でも、本人が希望する送付先住所が設定されている場合は、送付先住所を優先する。 なお、代理人等や送付先については、税目（収納・滞納含む）で一つ設定できることに加え、税目共通でも設定できるようにする。 各種証明書の住所省略は、本人以外への交付時を想定している。 - source: urn:jp:gov:std:016:func:0160055 legal_fields: 機能名称: 発行番号 大分類: 1. 共通機能 中項目: 1.5. 証明・通知 機能要件: |- 各種証明書の発行単位ごとに発行番号を記載できること。 複数部数を発行する場合は、一部ずつ異なる発行番号とすること。 実装区分: optional 要件の考え方・理由: |- 住民記録システム標準仕様書を基に作成している。 発行番号から、発行履歴や発行ログをシステム画面等により確認することで印刷日時やプリンタが特定できると考えられるため、発行番号の採番ルールとして、発行年月日や発行端末名、プリンタ番号などは表示しないこととする。ただし、製品によって発行番号から発行年月日や発行場所が特定できる実装とすることを妨げるものではない。 - source: urn:jp:gov:std:016:func:0160056 legal_fields: 機能名称: 発行番号 大分類: 1. 共通機能 中項目: 1.5. 証明・通知 機能要件: |- 発行場所を各種証明書に記載できること。 発行連番の表示・非表示の選択や番号の編集が可能であること。 実装区分: prohibited 要件の考え方・理由: 発行連番の表示・非表示や編集機能について、意見照会において要望があったが、発行内容が追跡できなくなるため、「実装不可機能」に追加することとした。 - source: urn:jp:gov:std:016:func:0160057 legal_fields: 機能名称: 公用表示 大分類: 1. 共通機能 中項目: 1.5. 証明・通知 機能要件: 各種証明書に「公用」の表示（印字）ができること。 実装区分: required 要件の考え方・理由: 庁内合議や外部の公的機関に提出する各種証明書を想定し、「公用」を表示（印字）する機能を定義している。 - source: urn:jp:gov:std:016:func:0160058 legal_fields: 機能名称: 文字溢れ対応等 大分類: 1. 共通機能 中項目: 1.5. 証明・通知 機能要件: 各種証明書・各種通知書の出力帳票については、文字数が多くやむをえず文字溢れが生じる場合や未登録外字が含まれる場合は、アラートを表示して注意喚起するとともに、文字超過リスト及び未登録外字リストを出力して、文字溢れした情報や未登録外字の情報を確認できるようにすること。また、文字溢れや未登録外字が含まれる場合は、出力帳票の印字縮小若しくは該当項目の空欄出力が可能であること。 実装区分: required 要件の考え方・理由: |- 各種証明書・各種通知書に正しく印字されない文字溢れや未登録外字については、職員に注意喚起し、手動で修正や確認等、個別に対応する必要があるため。 また、文字溢れや未登録外字の印字仕様（縮小印字、空欄出力　等）は限定しないこととした。 - source: urn:jp:gov:std:016:func:0160059 legal_fields: 機能名称: カスタマーバーコード 大分類: 1. 共通機能 中項目: 1.5. 証明・通知 機能要件: |- カスタマーバーコード情報を印字できること。カスタマーバーコードの印刷に際しては、郵便局が示す印字領域内に印字できること。 カスタマーバーコードが生成できない場合は、印刷時に注意喚起が行われること。 実装区分: required 要件の考え方・理由: |- 原則として外部帳票は全てカスタマーバーコードが必要と想定されるが、帳票ごとの制約を考慮する必要があるため、カスタマーバーコードが必要な帳票は各税目の印字項目で定義している。 出力件数に応じてカスタマーバーコード印字要否が異なることが想定されるため、帳票ごとにカスタマーバーコード印字を制御する機能を定義している。 - source: urn:jp:gov:std:016:func:0160060 legal_fields: 機能名称: カスタマーバーコード 大分類: 1. 共通機能 中項目: 1.5. 証明・通知 機能要件: カスタマーバーコードの出力制御ができること。 実装区分: optional - source: urn:jp:gov:std:016:func:0160061 legal_fields: 機能名称: 窓あき封筒に対応した送付先の印字出力 大分類: 1. 共通機能 中項目: 1.5. 証明・通知 機能要件: 検索結果や処理結果の対象者に対して、窓あき封筒に封入した際に窓から見える状態で印字できること。 実装区分: required 要件の考え方・理由: |- 住民記録システム標準仕様書を基に作成している。 封入・封緘時の作業誤りのリスクが少ない窓あき封筒を、住民への各種通知書を発送する際の標準的な運用として位置付ける。 - source: urn:jp:gov:std:016:func:0160127 legal_fields: 機能名称: 窓あき封筒に対応した問合せ先の印字出力 大分類: 1. 共通機能 中項目: 1.5. 証明・通知 機能要件: 帳票の連絡先（問合せ先）について、窓あき封筒に封入した際に各項目（住所、部署名、電話番号等）が窓から見える状態で印字できる帳票を出力できること。また、対象者の住所などによって問合せ先の印字を変更できること。 実装区分: optional 要件の考え方・理由: 指定都市などの大規模自治体では、納税通知書や督促状などの送付物に関する問合せ先についても区や市税事務所ごとなどで分けている場合があるため、本機能を「標準オプション機能」として定義する。 - source: urn:jp:gov:std:016:func:0160128 legal_fields: 機能名称: 窓あき封筒に対応した問合せ先の印字出力 大分類: 1. 共通機能 中項目: 1.5. 証明・通知 機能要件: 検索結果や処理結果の対象者に対して、窓あき封筒の窓に対応した送付先及び連絡先（問合せ先）のみを印字した帳票を出力できること。 実装区分: optional 要件の考え方・理由: 機能ID 0160123にて該当帳票レイアウトの変更が難しい場合については、窓あき封筒の窓に対応した送付先及び連絡先（問合せ先）のみを印字した帳票が同封できるよう、本機能を「標準オプション機能」として定義する。 - source: urn:jp:gov:std:016:func:0160062 legal_fields: 機能名称: 宛名シール 大分類: 1. 共通機能 中項目: 1.5. 証明・通知 機能要件: |- ・1.1.1.宛名管理で定義する送付先から任意に宛名シールを作成できること。 ・検索結果や処理結果の対象者に対して、宛名管理及び住所マスタより、郵便番号・送付先の住所、氏名・名称、カスタマーバーコードを記載した宛名シールを一括出力できること。 ・INPUTファイルによる出力ができること。 実装区分: required 要件の考え方・理由: 運用の中で任意の対象者に対する宛名シールを作成するシーンが想定されることから、1.1.1.で定義する送付先に対して、任意に宛名シールを作成する機能、対象者のINPUTファイルによる出力機能を定義している。ただし、具体的な実現方法は限定していない。 - source: urn:jp:gov:std:016:func:0160129 legal_fields: 機能名称: 文書番号 大分類: 1. 共通機能 中項目: 1.5. 証明・通知 機能要件: |- 各種証明書・各種通知書に文書番号を出力できること。地方団体が指定する漢字・記号・数字を組み合わせた番号体系に採番できること。 （例：（記号）△第＋任意の番号＋号） 帳票ごとに文書番号の表示/非表示を制御できること。 実装区分: required 適合基準日: 2026-04-01 要件の考え方・理由: |- 税務では各種証明書・各種通知書に文書番号を印字するケースがあるため、文書番号の印字機能を定義している。 特に文書番号の印字の必要性が高いといった意見の多かった帳票について、印字項目にて文書番号を定義している。 その中でも、用途に応じて表示/非表示を出し分けていることから、当該機能についても定義している。 - source: urn:jp:gov:std:016:func:0160064 legal_fields: 機能名称: 返戻者情報管理 大分類: 1. 共通機能 中項目: 1.6.返戻・公示送達 機能要件: |- 各種通知書の返戻者情報の管理（参照、登録、保持、修正）ができること。 ＜返戻者情報＞ ・税目 ・課税年度 ・登録日 ・返戻日 ・返戻事由 ・通知書番号 ・返戻物の種別 ・納税義務者（氏名、住所） ・再発送日 ・公示送達日 実装区分: required 要件の考え方・理由: |- 税務では、納税義務者への通知書の送付など、郵送を利用する工程が非常に多く存在するため、郵送物の返戻においてもシステムでの情報管理が必要と考え、本要件を「実装必須機能」として定義する。 なお、納税義務者（氏名、住所）については、宛名番号にて紐づけ、宛名マスタ（納税義務者マスタ）での管理（照会）でも可とする。 備考: ※特別徴収の場合は、納税義務者の項目については特別徴収義務者の名称、所在地と読み替える。 - source: urn:jp:gov:std:016:func:0160065 legal_fields: 機能名称: 返戻者情報管理 大分類: 1. 共通機能 中項目: 1.6.返戻・公示送達 機能要件: 返戻者情報に追加で、調査・返戻処理段階の区分（未調査、調査中、再送付、公示送達など）、調査記録（調査日時、担当者、調査方法、調査内容/結果など）が管理（参照、登録、保持、修正）ができること。 実装区分: required 要件の考え方・理由: 返戻件数が少ない地方団体においては、調査・返戻処理段階の区分、調査記録の項目を実装しない場合でも、メモ欄での管理が可能であると想定されるが、必要とする地方団体も多いことから備考欄に※の記載を追加した。 備考: ※本要件については、団体の人口規模や組織体制に応じて機能の実装状況にかなりの差異があること等を勘案し、当分の間、【標準オプション機能】へと緩和して位置付ける。ただし、当該取扱いは、あくまで標準準拠システムへの移行期における過渡的なものと整理しており、今後、標準準拠システムの開発・導入状況や地方団体の意見等を踏まえながら、解消を図っていく予定である。 - source: urn:jp:gov:std:016:func:0160066 legal_fields: 機能名称: 返戻者情報管理 大分類: 1. 共通機能 中項目: 1.6.返戻・公示送達 機能要件: 返戻者情報に追加で、再送理由、公示送達事由が管理（参照、登録、保持、修正）ができること。 実装区分: optional 要件の考え方・理由: 運用上、納税義務者のメモや調査記録にて状況は判断できると想定されることから「標準オプション機能」とした。 - source: urn:jp:gov:std:016:func:0160067 legal_fields: 機能名称: 返戻者情報管理 大分類: 1. 共通機能 中項目: 1.6.返戻・公示送達 機能要件: 返戻者情報に追加で、更新者、担当者が管理（参照、登録、保持、修正）ができること。 実装区分: optional - source: urn:jp:gov:std:016:func:0160068 legal_fields: 機能名称: 返戻者情報管理 大分類: 1. 共通機能 中項目: 1.6.返戻・公示送達 機能要件: 任意の期間で返戻者の一覧が出力できること。 実装区分: optional - source: urn:jp:gov:std:016:func:0160069 legal_fields: 機能名称: 返戻者情報のバーコード登録 大分類: 1. 共通機能 中項目: 1.6.返戻・公示送達 機能要件: 送付物にバーコードを印字することで、返戻となった場合、バーコード読み取りによる返戻者情報の登録が可能であること。バーコード読み取りの際、登録日・返戻日などのバーコードから読み取りができないデータ項目については、画面から一括登録ができること。 実装区分: optional 要件の考え方・理由: 大規模な団体においては、返戻となる各種通知書の件数が大量となることから、バーコードによる取込による地方団体の業務の効率化を期待し、本機能を「標準オプション機能」として定義する。 - source: urn:jp:gov:std:016:func:0160070 legal_fields: 機能名称: 返戻者情報の一括取込 大分類: 1. 共通機能 中項目: 1.6.返戻・公示送達 機能要件: 送付対象者の一覧などから加工したCSVデータなどを取り込むことで、返戻者情報の一括取込が可能であること。一括取込で登録できないデータ項目については、画面から一括登録ができること。 実装区分: optional 要件の考え方・理由: 帳票によってはバーコードの印字がない場合などにおいては、EUCなどで出力した送付対象者の一覧データなどから、返戻者分のみを適宜抽出し、税務システムへの一括取込を実施することで、業務の効率化を期待できる。よって、本機能を「標準オプション機能」として定義する。 - source: urn:jp:gov:std:016:func:0160071 legal_fields: 機能名称: 処理保留 大分類: 1. 共通機能 中項目: 1.6.返戻・公示送達 機能要件: 必要に応じて、納税義務者又は物件への課税や更正等の処理保留の設定ができること。 実装区分: required 要件の考え方・理由: 返戻となった場合、該当納税義務者への課税等の通知が実施できず、課税を前提とした更正などの処理についても処理を保留する必要があるため、本機能を「実装必須機能」として定義する。 備考: |- なお、本機能は返戻処理と連動している必要はない。 ※特別徴収の場合は、納税義務者の項目については特別徴収義務者と読み替える。 - source: urn:jp:gov:std:016:func:0160072 legal_fields: 機能名称: 再発行 大分類: 1. 共通機能 中項目: 1.6.返戻・公示送達 機能要件: 調査結果より住所が判明した納税義務者に対し、納期限及び送付先を再設定の上、返戻となった帳票を再発行できること。 実装区分: required 適合基準日: 2027-04-01 要件の考え方・理由: 調査により納税義務者の住所が判明した場合は、納期限を変更の上、正しい送付先へ送付する必要があるため、本機能を「実装必須機能」として定義する。 備考: |- ※特別徴収の場合は、納税義務者の項目については特別徴収義務者と読み替える。 一括で出力することも妨げない。 - source: urn:jp:gov:std:016:func:0160073 legal_fields: 機能名称: 返戻時住所管理 大分類: 1. 共通機能 中項目: 1.6.返戻・公示送達 機能要件: 返戻時の住所についても、履歴を管理できること。 実装区分: optional 要件の考え方・理由: 調査により納税義務者の住所が判明した場合でも、返戻時点の住所を保持することで、再返戻時の照会や他税目との情報共有が可能となるため、一部団体から一定のニーズがあると判断し、本機能を「標準オプション機能」として定義する。 - source: urn:jp:gov:std:016:func:0160074 legal_fields: 機能名称: 公示送達登録 大分類: 1. 共通機能 中項目: 1.6.返戻・公示送達 機能要件: 個別に納期限の登録・修正ができること。 実装区分: required 要件の考え方・理由: 調査により納税義務者の住所が判明しなかった場合は、公示送達の実施を以て通知したものとみなす。その際、公示送達日より法定納期限を設定する必要があり、また、必要に応じて納期限を変更する場合も考慮し、本機能を「実装必須機能」として定義する。 - source: urn:jp:gov:std:016:func:0160075 legal_fields: 機能名称: 公示送達登録 大分類: 1. 共通機能 中項目: 1.6.返戻・公示送達 機能要件: 返戻者情報への公示送達日の登録に連動し、パラメータ設定に基づき自動で対象者の納期限が変更されること。 実装区分: optional - source: urn:jp:gov:std:016:func:0160076 legal_fields: 機能名称: 公示送達登録 大分類: 1. 共通機能 中項目: 1.6.返戻・公示送達 機能要件: 対象者を設定し、一括で納期限の登録・修正ができること。 実装区分: optional - source: urn:jp:gov:std:016:func:0160077 legal_fields: 機能名称: 公示送達対象の出力 大分類: 1. 共通機能 中項目: 1.6.返戻・公示送達 機能要件: |- 公示送達日登録を行った対象者又は指定納期設定（納期変更）の対象者を抽出し、リストの出力を紙及びＣＳＶで出力できること。 また、指定納期設定（納期変更）については、変更前／変更後の情報をリスト出力できること。 ＜出力項目＞ ・通知書番号 ・納税義務者（宛名番号、氏名、住所） ・公示送達日　※公示送達日登録の場合 ・納期限（変更前／変更後）　※指定納期設定の場合 実装区分: required 要件の考え方・理由: 公示送達の登録を行った対象者等を出力し、公示送達文書の作成を実施する必要があるため、本機能を「実装必須機能」として定義する。なお、記載の項目を網羅し、公示送達対象者及びその内容を把握できればデザインやレイアウトは問わないが、どの団体でも取り扱える汎用的な形式として紙及びCSVと定義した。 備考: ※特別徴収の場合は、納税義務者の項目については特別徴収義務者と読み替える。 - source: urn:jp:gov:std:016:func:0160078 legal_fields: 機能名称: 公示送達対象の異動の確認 大分類: 1. 共通機能 中項目: 1.6.返戻・公示送達 機能要件: 公示期間中に住所や送付先の異動があったものを出力できること。 実装区分: required 要件の考え方・理由: 公示送達中に異動があった場合、新たに住所などが判明し各種通知書を直接送付できる可能性がある。よって、システム上、公示送達中の異動を把握できる仕組みが具備されている必要があると考え、本機能を「実装必須機能」として定義する。 - source: urn:jp:gov:std:016:func:0160079 legal_fields: 機能名称: 公示送達対象の照会 大分類: 1. 共通機能 中項目: 1.6.返戻・公示送達 機能要件: |- 公示送達対象者が来庁した場合、納税義務者や課税台帳等の画面にて、公示送達対象者であることが容易に特定できること。 ＜想定する機能の例＞ ・納税義務者の検索結果（一覧画面等）に公示対象であることが表示される。 ・対象者の基本情報を参照した際に、公示対象であることが表示される。 実装区分: optional 要件の考え方・理由: 公示送達対象者が来庁した場合、即座に適切な対応が可能となるよう、公示送達対象者であることを迅速かつ確実に把握したいというニーズがある一方で、公示送達対象者が来庁するケースは稀と考えられるため、「標準オプション機能」として定義する。 備考: ※特別徴収の場合は、納税義務者の項目については特別徴収義務者と読み替える。 - source: urn:jp:gov:std:016:func:0160080 legal_fields: 機能名称: 公示送達文書の出力 大分類: 1. 共通機能 中項目: 1.6.返戻・公示送達 機能要件: 科目、年度、期別毎に公示送達文書を出力できること。 実装区分: optional 要件の考え方・理由: 公示送達文書については手作業で作成している団体がほとんどであるが、システムから直接出力したいという要望もあるため、公示送達文書の出力機能を「標準オプション機能」として定義する。 - source: urn:jp:gov:std:016:func:0160081 legal_fields: 機能名称: 団体内統合宛名番号の付番依頼及び中間サーバーへの副本情報登録機能 大分類: 1. 共通機能 中項目: 1.7. 連携 機能要件: |- 団体内統合宛名機能（「地方公共団体情報システム共通機能標準仕様書」に規定する団体内統合宛名機能をいう。以下同じ。）における団体内統合宛名番号の付番や宛名情報の更新のために、登録、更新した宛名情報及び個人番号を団体内統合宛名機能へ連携できること。 団体内統合宛名機能を経由して、副本情報の登録等、中間サーバーとの連携ができること。なお、中間サーバーとの連携のうち、中間サーバーから取得したURLを元にHTTPダウンロードする場合は、団体内統合宛名機能を経由せず連携すること。 実装区分: required 要件の考え方・理由: デジタル庁による全標準化対象20業務への修正指示に基づき、業務横断的な整合性を取る形で記載した。 - source: urn:jp:gov:std:016:func:0160082 legal_fields: 機能名称: 団体内統合宛名番号の付番依頼及び中間サーバーへの副本情報登録機能 大分類: 1. 共通機能 中項目: 1.7. 連携 機能要件: 情報照会の結果、「不開示」で提供された情報について、対象者の課税台帳等の照会画面において注意喚起が行われること。 実装区分: optional - source: urn:jp:gov:std:016:func:0160084 legal_fields: 機能名称: 他の標準準拠システムへの連携 大分類: 1. 共通機能 中項目: 1.7. 連携 機能要件: |- 庁内データ連携機能（デジタル庁が策定する「地方公共団体情報システム共通機能標準仕様書」に規定する庁内データ連携機能をいう。以下同じ。）に従うこと。 税務システムから他の標準準拠システムへの情報連携、または他の標準準拠システムから税務システムへの情報連携については、デジタル庁が策定する「地方公共団体情報システム データ要件・連携要件標準仕様書」に従うこととする。 実装区分: required 備考: 統合収納管理機能・統合滞納管理機能との連携は、デジタル庁が策定する「地方公共団体の基幹業務システムの共通機能に関する標準仕様書」に規定する統合収納管理機能・統合滞納管理機能に従うこととする。 - source: urn:jp:gov:std:016:func:0160085 legal_fields: 機能名称: 独自施策システム等への連携 大分類: 1. 共通機能 中項目: 1.7. 連携 機能要件: |- 標準準拠システム以外のシステム（独自施策システム等）のうち、当該標準準拠システムを利用する地方公共団体が標準準拠システムとのデータ連携を認めるものとのデータ連携については、デジタル庁が策定する「地方公共団体情報システム データ要件・連携要件標準仕様書」に基づく連携要件の標準に従うこと。 共用アプリケーション等の外部システムとのデータ連携についても、デジタル庁が策定する「地方公共団体情報システム データ要件・連携要件標準仕様書」に基づく連携要件の標準に従い、外部システムに係る接続仕様書によることとする。 実装区分: optional 要件の考え方・理由: 税務システムから独自施策システム等の標準準拠システム以外のシステムへの情報連携については、デジタル庁が策定する「地方公共団体情報システム データ要件・連携要件標準仕様書」の独自施策システム等連携仕様に従うこととする。 - source: urn:jp:gov:std:016:func:0160142 legal_fields: 機能名称: eLTAXからの情報の取込 大分類: 1. 共通機能 中項目: 1.7. 連携 機能要件: |- eLTAXからの利用届出情報の連携ファイルを取り込み、税務システム上の納税義務者情報又は法人基本情報における氏名（法人名）・住所などとの突合を実施し、候補となる納税義務者を出力できること。候補として出力した納税義務者に対し、紐づけ処理を実施することで、納税義務者に納税者IDを登録できること。 候補となる納税義務者が存在しないなど、業務上、調査・確認が必要なデータ項目がある場合、エラー及びアラートとして通知できること。なお、エラー及びアラートとなった場合でも、検索などにより納税義務者を特定することで、紐づけ処理が実行できること。 実装区分: required 備考: eLTAXに関して、利用届出情報以外の情報連携については、各税目において定義している。 - source: urn:jp:gov:std:016:func:0160143 legal_fields: 機能名称: eLTAXからの情報の取込 大分類: 1. 共通機能 中項目: 1.7. 連携 機能要件: |- eLTAXからの連携方式について、各地方団体のセキュリティポリシー等に応じて以下の２方式から選択できること。 ・外部電子媒体を経由しての電子ファイル一括取込ができる ・外部電子媒体を経由することなく（システムに直接）自動で連携できる 実装区分: required 要件の考え方・理由: 今後のオンラインによる行政手続きの拡大に鑑み、eLTAXとの情報連携は、税務システムとして実装必須機能と定義している。実現方式としては、各団体内のセキュリティポリシーやネットワーク構成等により、外部電子媒体の経由の有無を選択できることとした。 - source: urn:jp:gov:std:016:func:0160136 legal_fields: 機能名称: eLTAXからの情報の取込 大分類: 1. 共通機能 中項目: 1.7. 連携 機能要件: eLTAXから納税管理人申告（申請）書の情報を取り込み、住民、住民登録外者、法人の代理人等情報として登録、更新できること。 実装区分: optional 要件の考え方・理由: |- eLTAXから納税管理人申告（申請）書の申請が可能であるため、取り込みに必要な機能を追加した。 なお、多く団体は税務システム側に手入力で登録していることから「標準オプション機能」として定義した。 - source: urn:jp:gov:std:016:func:0160087 legal_fields: 機能名称: eLTAXからの情報との紐づけ 大分類: 1. 共通機能 中項目: 1.7. 連携 機能要件: |- eLTAXからの情報取込において、税務システム内であらかじめ登録したeLTAX納税者ID、法人番号又は個人番号を用い、eLTAXからの情報と税務システム内の情報の紐づけができること。 ただし、宛名管理等の外部データベースと連携し、税務システムでは情報を保持せず、照会する形式での実装も可とする。 実装区分: required 要件の考え方・理由: eLTAXから取り込んだ情報と、税務システム内の情報の突合については、予め登録した、納税者ID、個人番号、法人番号を基に実施する運用を想定している。 - source: urn:jp:gov:std:016:func:0160088 legal_fields: 機能名称: eLTAXからの情報との紐づけ 大分類: 1. 共通機能 中項目: 1.7. 連携 機能要件: eLTAXからの情報取込において、税務システム内であらかじめ登録した氏名・住所を用い、eLTAXからの情報と税務システム内の情報について紐付けされること。また、紐づけについて複数の候補がある場合は、該当情報を通知し、システム画面にてどの情報と紐づけするか選択できること。 実装区分: optional 要件の考え方・理由: 氏名、住所を用いた紐づけについては、対象者の特定誤りの可能性などから当該機能の利用について慎重な市区町村もある一方で、多くの団体にとって効率的であると考えられることから、「標準オプション機能」として定義した。 - source: urn:jp:gov:std:016:func:0160089 legal_fields: 機能名称: eLTAXへの情報送信 大分類: 1. 共通機能 中項目: 1.7. 連携 機能要件: eLTAXへの送信データについては、eLTAXの取込仕様に合せ、1,000件を超える場合は1,000件ごとのファイルに分割する機能を持つこと。 実装区分: required 要件の考え方・理由: 業務の省力化のため、eLTAXの取込仕様に合わせ、ファイルを分割する機能を定義している。 - source: urn:jp:gov:std:016:func:0160137 legal_fields: 機能名称: eLTAXを通じての照会・回答 大分類: 1. 共通機能 中項目: 1.7. 連携 機能要件: eLTAXを通じて照会先団体宛ての照会データを登録できること。 実装区分: optional 要件の考え方・理由: |- eLTAX5期更改にて、地方税外部連携システムの団体間照会・ファイル送信機能が追加されたことに伴い、地方団体間の照会・回答に関して必要な情報をやり取りするための要件として定義している。 また、本機能を用いての照会・回答業務は税目が限定されていないことから、税務共通に定義している。 地方税共同機構より公表された「eLTAX５期更改における見積参考資料」を以て、必要な機能を示すこととする。 なお、本機能がないと業務上支障があるというものではないため、「標準オプション機能」として定義した。 備考: 照会元団体での業務を想定している。 - source: urn:jp:gov:std:016:func:0160138 legal_fields: 機能名称: eLTAXを通じての照会・回答 大分類: 1. 共通機能 中項目: 1.7. 連携 機能要件: eLTAXを通じて照会データをダウンロードできること。 実装区分: optional 要件の考え方・理由: |- eLTAX5期更改にて、地方税外部連携システムの団体間照会・ファイル送信機能が追加されたことに伴い、地方団体間の照会・回答に関して必要な情報をやり取りするための要件として定義している。 また、本機能を用いての照会・回答業務は税目が限定されていないことから、税務共通に定義している。 地方税共同機構より公表された「eLTAX５期更改における見積参考資料」を以て、必要な機能を示すこととする。 なお、本機能がないと業務上支障があるというものではないため、「標準オプション機能」として定義した。 備考: 照会先団体での業務を想定している。 - source: urn:jp:gov:std:016:func:0160139 legal_fields: 機能名称: eLTAXを通じての照会・回答 大分類: 1. 共通機能 中項目: 1.7. 連携 機能要件: eLTAXを通じて照会元団体宛ての回答データを登録できること。 実装区分: optional 要件の考え方・理由: |- eLTAX5期更改にて、地方税外部連携システムの団体間照会・ファイル送信機能が追加されたことに伴い、地方団体間の照会・回答に関して必要な情報をやり取りするための要件として定義している。 また、本機能を用いての照会・回答業務は税目が限定されていないことから、税務共通に定義している。 地方税共同機構より公表された「eLTAX５期更改における見積参考資料」を以て、必要な機能を示すこととする。 なお、本機能がないと業務上支障があるというものではないため、「標準オプション機能」として定義した。 備考: 照会先団体での業務を想定している。 - source: urn:jp:gov:std:016:func:0160140 legal_fields: 機能名称: eLTAXを通じての照会・回答 大分類: 1. 共通機能 中項目: 1.7. 連携 機能要件: eLTAXを通じて回答データをダウンロードできること。 実装区分: optional 要件の考え方・理由: |- eLTAX5期更改にて、地方税外部連携システムの団体間照会・ファイル送信機能が追加されたことに伴い、地方団体間の照会・回答に関して必要な情報をやり取りするための要件として定義している。 また、本機能を用いての照会・回答業務は税目が限定されていないことから、税務共通に定義している。 地方税共同機構より公表された「eLTAX５期更改における見積参考資料」を以て、必要な機能を示すこととする。 なお、本機能がないと業務上支障があるというものではないため、「標準オプション機能」として定義した。 備考: 照会元団体での業務を想定している。 - source: urn:jp:gov:std:016:func:0160132 legal_fields: 機能名称: 個人番号カードによる各種証明書の交付 大分類: 1. 共通機能 中項目: 1.7. 連携 機能要件: |- 証明発行サーバや自治体基盤クラウドシステム等を通じて、広域交付システムインタフェース仕様書に基づくコンビニエンスストア等の端末における下記証明書交付に対応していること。 公的個人認証サービスを用いた各種証明書の電子申請に対応していること。 ＜対象証明書＞ ・所得証明書 ・（非）課税証明書 実装区分: required 適合基準日: 2027-04-01 要件の考え方・理由: |- 住民記録システム標準仕様書に準じる。 税証明書のコンビニ交付については、地方団体によって対象としている帳票が大きく異なるため、多数の地方団体が共通して交付している証明書を実装必須機能、その他証明書を実装必須機能※として整理している。 備考: |- 今後のコンビニ交付の利用拡大に鑑み、コンビニ交付における連携対応は必須とする。 ただし、コンビニ交付サービスを提供するかは、市区町村の状況に鑑み、選択できることとする。 - source: urn:jp:gov:std:016:func:0160133 legal_fields: 機能名称: 個人番号カードによる各種証明書の交付 大分類: 1. 共通機能 中項目: 1.7. 連携 機能要件: |- 証明発行サーバや自治体基盤クラウドシステム等を通じて、広域交付システムインタフェース仕様書に基づくコンビニエンスストア等の端末における下記証明書交付に対応していること。 公的個人認証サービスを用いた各種証明書の電子申請に対応していること。 ・その他証明書 実装区分: required 要件の考え方・理由: |- 税証明書のコンビニ交付については、地方団体によって対象としている帳票が大きく異なるため、多数の地方団体が共通して交付している証明書を実装必須機能、その他証明書を実装必須機能（※）として整理している。 その他証明書については、すべての証明書がコンビニ交付できることを求めるものではないが、導入先の地方団体が現在コンビニ交付を行っており、かつ、移行後も継続交付を希望する証明書については地方団体と協議の上実装する必要がある。 備考: |- ※本要件については、団体の人口規模や組織体制に応じて機能の実装状況にかなりの差異があること等を勘案し、当分の間、【標準オプション機能】へと緩和して位置付ける。ただし、当該取扱いは、あくまで標準準拠システムへの移行期における過渡的なものと整理しており、今後、標準準拠システムの開発・導入状況や地方団体の意見等を踏まえながら、解消を図っていく予定である。 左記証明書のうち、導入先の地方団体にて現在コンビニ交付を行っており、移行後も継続運用を希望する証明書については、地方団体と協議の上実装すること。 - source: urn:jp:gov:std:016:func:0160091 legal_fields: 機能名称: EUC機能 大分類: 1. 共通機能 中項目: 1.8. 共通管理 機能要件: |- ＥＵＣ機能（デジタル庁が策定する「地方公共団体情報システム共通機能標準仕様書」に規定するＥＵＣ機能をいう。）を利用して、データの抽出・分析・加工・出力ができること。 ＥＵＣ機能へ連携するデータ項目は「地方公共団体情報システムデータ要件・連携要件標準仕様書」の「基本データリスト」の規定に従うこと。（税務システムとＥＵＣ機能を一体のパッケージとして構築する場合については、基本データリストに定義されたデータ項目を利用できることを前提に、基本データリスト外のデータ項目の利用も可能とする。） なお、機能別連携仕様にて他業務から取得しているデータ項目については、基本データリストにないデータ項目であっても、データソースの対象とし、データの型、桁数等は連携元である他業務の基本データリストの定義に従う必要がある。 実装区分: required 要件の考え方・理由: デジタル庁による全標準化対象20業務への修正指示に基づき、業務横断的な整合性を取る形で記載した。 - source: urn:jp:gov:std:016:func:0160092 legal_fields: 機能名称: アクセスログ管理 大分類: 1. 共通機能 中項目: 1.8. 共通管理 機能要件: |- ＜ログの取得＞ 個人情報や機密情報の漏えいを防ぐために、システムの利用者及び管理者に対して、以下のログを取得すること（IaaS 事業者がログについての責任を負っている場合等、パッケージベンダ自体がログを提供できない場合は、IaaS 事業者と協議する等により、何らかの形で本機能が市区町村に提供されるようにすること）。 ●操作ログ 取得対象：①照会、②帳票発行、③異動入力（履歴追加）、④異動入力（履歴修正）、⑤異動入力（履歴削除）、⑥バッチ処理（帳票出力）、⑦バッチ処理（データ更新）、⑧画面ハードコピー、⑨データ出力（EUC） ※③から⑤までについては、仮登録及び本登録両方の操作ログを取得できること。 記録対象：操作者 ID、日時、ファイル名、端末名、オンラインの場合は対象となったレコード（処理対象者等）・機能名・画面名、バッチについては処理名、処理・交付場所、個人番号へのアクセス有無 ●認証ログ ログイン及びログインのエラー回数等 ●イベントログ 税務システム内で起こった特定の現象・動作の記録。異常イベントやデータベースへのアクセス等のセキュリティに関わる情報 ●通信ログ Web サーバや Web アプリケーションサーバ、データベースサーバ等との通信エラー等 ●印刷ログ 印刷者 ID、印刷日時、対象ファイル名、印刷プリンタ（又は印刷端末名）、タイトル、枚数、公印出力の有無、個人番号の出力の有無、出力形式（プレビュー、印刷、ファイル出力等）、各種証明書の場合には発行番号等の情報、各種通知書等の場合には文書番号情報 実装区分: required 要件の考え方・理由: |- 住民記録システム標準仕様書を基に作成している。 ログの保管期間は、各市区町村の開示請求の対応期間と同じであることが望ましい。ログの容量は大きくなるため、期間が長いほどディスク容量を占めることになる。 保管期間を指定する理由を明示することによって、クラウド環境下等において長期的にログを残したい地方団体に対する追加課金等の理由も明確になる。特に、特定個人情報に関わるログに関しては、内部監査及び外部監査人（情報保護委員会による監査等を含む。）にも対応できるよう、監査証跡としての役割も満たせることが必要である。（特定個人情報へのアクセスログについては、安全管理措置でログの取得と定期的な分析・確認が義務づけられており、ログ取得機能を提供できないシステムは番号法違反となり、導入できない。） なお、印刷ログについては、プリンタ名では印刷場所の特定が困難な場合があるため、その場合は省略することも、印刷端末名をもって代えることも可とすることとした。 - source: urn:jp:gov:std:016:func:0160093 legal_fields: 機能名称: アクセスログ管理 大分類: 1. 共通機能 中項目: 1.8. 共通管理 機能要件: |- ＜ログの取得（枝番1の続き）＞ ●設定変更ログ 管理者による設定変更時の情報 ●エラーログ 税務システム上でエラーが発生した際の記録。管理者による設定変更時の情報 取得したログは、市区町村が定める期間保管するとともに、オンラインでの検索・出力・照会、EUC 機能を用いた後日分析が簡単にできること。なお、システム利用者や第三者によるログの改ざんがされないよう、書き込み禁止等の改ざん防止措置がされること。 実装区分: required 要件の考え方・理由: 同上 - source: urn:jp:gov:std:016:func:0160094 legal_fields: 機能名称: アクセスログ管理 大分類: 1. 共通機能 中項目: 1.8. 共通管理 機能要件: |- ＜ログの分析＞ システムの利用者及び管理者のログについては、以下の分析例の観点等から分析・ファイル出力ができること（IaaS 事業者がログについての責任を負っている場合等、パッケージベンダ自体がログを提供できない場合は、IaaS 事業者と協議する等により、何らかの形で本機能が市区町村に提供されるようにすること）。 [分析例] ・深夜・休業日におけるアクセス一覧 ・ログイン失敗一覧 ・ID 別ログイン数一覧 ・大量検索実行一覧 ・宛名番号等から該当者の検索実行一覧 実装区分: required 要件の考え方・理由: 同上 - source: urn:jp:gov:std:016:func:0160095 legal_fields: 機能名称: 保存年限 大分類: 1. 共通機能 中項目: 1.8. 共通管理 機能要件: |- 法令年限及び業務上必要な期間（保存期間）を経過した情報について、標準準拠システムから物理削除できること。 個人番号利用事務においては、保存期間を経過した場合には、個人番号及び関連情報を標準準拠システムから削除できること。 保存期間は、各地方公共団体が任意で指定できること。 実装区分: required 要件の考え方・理由: デジタル庁による全標準化対象20業務への修正指示に基づき、業務横断的な整合性を取る形で記載した。 - source: urn:jp:gov:std:016:func:0160096 legal_fields: 機能名称: 操作権限管理 大分類: 1. 共通機能 中項目: 1.8. 共通管理 機能要件: |- システムの利用者及び管理者に対して、個人単位で I D 及び パスワード、利用者名称、所属部署名称、操作権限（異動処理や表示・閲覧等の権限）、利用範囲及び期間が管理できること。 職員のシステム利用権限管理ができ、利用者とパスワードを登録し利用権限レベルが設定できること。 操作者IDとパスワードにより認証ができ、パスワードは利用者による変更、システム管理者による初期化ができること。 アクセス権限の付与は、利用者単位で設定できること。 アクセス権限の設定はシステム管理者により設定できること。 アクセス権限の付与も含めたユーザ情報の登録・変更・削除はスケジューラ―に設定する等、事前に準備ができること。 また、事務分掌による利用者ごとの表示・閲覧項目及び実施処理の制御ができること。 他の職員が異動処理を行っている間は、同一住民の情報について、閲覧以外の作業ができないよう、排他制御ができること。 なお、操作権限管理については、個別及び一括での各種制御やメンテナンスができること。 実装区分: required 要件の考え方・理由: |- デジタル庁による全標準化対象20業務への修正指示に基づき、業務横断的な整合性を取る形で記載した。 認証に係る機能については、標準準拠システムで実装するか、認証基盤等で実装するかを問わない。 - source: urn:jp:gov:std:016:func:0160097 legal_fields: 機能名称: 操作権限管理 大分類: 1. 共通機能 中項目: 1.8. 共通管理 機能要件: |- パスワードによる認証に加え、ICカードや静脈認証等の生体認証を用いた二要素認証に対応すること。 複数回の認証の失敗に対して、アカウントロック状態にできること。 実装区分: required 要件の考え方・理由: 同上 - source: urn:jp:gov:std:016:func:0160098 legal_fields: 機能名称: 操作権限管理 大分類: 1. 共通機能 中項目: 1.8. 共通管理 機能要件: |- 組織・職務・職位等での操作権限を設定できること。 操作権限一覧表で操作権限が設定できること。 実装区分: optional 要件の考え方・理由: 同上 - source: urn:jp:gov:std:016:func:0160099 legal_fields: 機能名称: 操作権限管理 大分類: 1. 共通機能 中項目: 1.8. 共通管理 機能要件: 認証に当たっては、シングル・サイン・オンが使用できること。 実装区分: optional 要件の考え方・理由: 同上 - source: urn:jp:gov:std:016:func:0160100 legal_fields: 機能名称: ヘルプ機能 大分類: 1. 共通機能 中項目: 1.8. 共通管理 機能要件: |- システムの操作方法や運用方法等について、オンラインマニュアルを有していること。 また、ヘルプ機能として、操作画面上から、当該画面の機能説明・操作方法等が確認できるオンラインマニュアル（画面上に表示されるマニュアル類）が提供されること。 実装区分: required 要件の考え方・理由: |- 住民記録システム標準仕様書を基に作成している。 オンラインマニュアルは、システムの操作中に、キーワード検索などによって、知りたい情報に容易にアクセスできる。 オンラインマニュアルの一部として、Ｑ＆Ａ（よくある質問＆回答）集が提供されることが望ましい。 - source: urn:jp:gov:std:016:func:0160101 legal_fields: 機能名称: ヘルプ機能 大分類: 1. 共通機能 中項目: 1.8. 共通管理 機能要件: システムの操作方法や運用方法等について、冊子のマニュアルを有していること。 実装区分: optional 要件の考え方・理由: 市区町村によっては冊子のマニュアルが使用されているが、オンラインマニュアルで代替できるため、不要とする。 - source: urn:jp:gov:std:016:func:0160102 legal_fields: 機能名称: 「地方公共団体情報システム データ要件・連携要件標準仕様書」に基づく出力 大分類: 1. 共通機能 中項目: 1.8. 共通管理 機能要件: |- デジタル庁が策定する「地方公共団体情報システム データ要件・連携要件標準仕様書」で定義された表形式（移行ファイル構成表、移行ファイル関連図、データ項目一覧表、コード構成表、コード一覧）、XML形式又はCSV形式（レイアウト仕様）に準拠したデータ出力機能が提供されること。また、デジタル庁が策定する「地方公共団体情報システム データ要件・連携要件標準仕様書」以外で保有するデータがある場合は、同様に提供されること。 なお、システム契約期間の終了時には、その時点でのデジタル庁が策定する「地方公共団体情報システム データ要件・連携要件標準仕様書」で定義された表形式、XML形式又はCSV形式でデータ提供ができること。 実装区分: required 要件の考え方・理由: 標準化対象業務である税務システムにおいて、デジタル庁が策定する「地方公共団体情報システム データ要件・連携要件標準仕様書」に基づくデータ出力は必須となる。 - source: urn:jp:gov:std:016:func:0160103 legal_fields: 機能名称: バッチ処理 大分類: 1. 共通機能 中項目: 1.8. 共通管理 機能要件: |- バッチ処理の実行（起動）方法として、直接起動だけでなく、年月日及び時分、毎日、毎週○曜日、毎月ＸＸ日、毎月末を指定した方法（スケジュール管理による起動）が提供されること。 また、バッチ処理の実行時は、前回処理時に設定したパラメータが参照されること。 前回設定のパラメータは、一部修正ができること。 修正パラメータ個所については、修正した旨が判別し易くなっていること。 全てのバッチ処理の実行結果（処理内容や処理結果、処理時間、処理端末名称、正常又は異常の旨、異常終了した際はOSやミドルウェア等から出力されるエラーコード等）が出力されること。 バッチの実行結果から一連の作業で最終的な提出物をXLSX形式等で作成する場合等には、自動実行する仕組みを用意すること。 実装区分: required 要件の考え方・理由: |- デジタル庁による全標準化対象20業務への修正指示に基づき、業務横断的な整合性を取る形で記載した。 税務では,作業工程が多岐にわたるためバッチ処理は必須であると判断し、「実装必須機能」とした。 - source: urn:jp:gov:std:016:func:0160104 legal_fields: 機能名称: エラー・アラート項目 大分類: 1. 共通機能 中項目: 1.9. エラー・アラート項目 機能要件: |- 論理的に成立し得ない入力その他の抑止すべき入力等（少なくとも各業務で規定したエラー・アラート項目に記載したもの）は、エラー（※）として抑止すること。エラーは、当該内容で本登録することを抑止することが目的であり、その実装方法としては、エラーメッセージを表示し、次の画面に進めないようにすることも、エラーメッセージの表示によらず、そもそも入力不可とすることで対応することも差し支えない。また、本登録段階でエラーメッセージを表示して抑止することも、いずれもエラーの実装方法として許容される。 論理的には成立するが特に注意を要する入力等（少なくとも各業務の仕様書に記載のもの）は、アラート（※）として注意喚起すること。 ※エラー：論理的に成立し得ない入力その他の抑止すべき入力等について、抑止すべき原因が解消されるまで、 　　　　　当該入力等を確定（本登録）できないもの。 ※アラート：論理的には成立するが特に注意を要する入力等について、注意喚起の表示を経た上で、 　　　　　　当該入力等を確定できるもの。 エラー・アラートとする場合は、原因となったエラー・アラート項目と理由・対応方法を入力者に適切に伝えること。 実装区分: required 要件の考え方・理由: |- エラー、アラート機能については、各税目にて業務上必要な機能が異なるため、税目ごとの定義することとしている。一方で、各パッケージ製品を正常稼働させる上必要なエラー、アラート（データベース仕様上、数字項目以外の入力は不可 など）についても定義する必要があることから、共通要件として全般的な定義を実施している。 また、各税目におけるエラー、アラート発出の詳細な条件については、各団体の規模や体制、製品の仕様に応じて多様であるため、業務上必須と考えられるエラー、アラートの大まかな条件や機能についてのみ標準仕様書に定義し、詳細な条件の網羅的な定義は実施せず、一例を参考資料として標準仕様書の別紙として整理している。各団体は当該参考資料を活用し、各パッケージ製品の実装状況を確認することで、自団体に適したパッケージ製品を選定することを想定している。 - source: urn:jp:gov:std:016:func:0160105 legal_fields: 機能名称: 一括処理などにおけるエラー・アラート 大分類: 1. 共通機能 中項目: 1.9. エラー・アラート項目 機能要件: 一括処理などにおいて、業務上確認・調査が必要な項目がある場合は、エラー及びアラートとして通知されること。また、エラー及びアラートとなったデータ項目の修正や修正後の再処理などが可能であること。 実装区分: required 要件の考え方・理由: 本書では、所謂バッチ処理とオンライン処理の別については、実装方式によるものとして、明確な定義を実施していない。一方で、実運用においては、バッチ処理などの一括処理においてエラー及びアラートが発生した場合はこれを検知し、速やかに処理を再開させる必要がある。このため、一括処理などにおけるエラー及びアラートの検知とその後の修正、処理の再開について、「実装必須機能」として定義する。 - source: urn:jp:gov:std:016:func:0160106 legal_fields: 機能名称: エラー・アラート項目の選択 大分類: 1. 共通機能 中項目: 1.9. エラー・アラート項目 機能要件: |- 各地方団体の組織体制・業務状況等に応じて、各パッケージ製品に実装しているエラー及びアラート項目の発出有無を選択できること。 また、エラー（処理不可）とするか、アラート（処理可）とするかを切り替えできること。 ただし、システムの構造上、必須となるエラー及び業務上必須と考えられるエラー・アラートについては、この限りではない。 実装区分: required 要件の考え方・理由: エラー及びアラート項目の中には、各地方団体の組織体制や業務状況によって、登録時に随時で検知・修正したい場合や後続の処理時でまとめて検知・修正したい場合、該当件数が多いため、エラー及びアラートを検知をさせないようにしたい場合などがある。こうした各地方団体の状況に合せて、効率的な業務運用の設計が可能となるよう、発出の有無等を選択的に実装できる機能を「実装必須機能」として定義する。 備考: ※本要件については、団体の人口規模や組織体制に応じて機能の実装状況にかなりの差異があること等を勘案し、当分の間、【標準オプション機能】へと緩和して位置付ける。ただし、当該取扱いは、あくまで標準準拠システムへの移行期における過渡的なものと整理しており、今後、標準準拠システムの開発・導入状況や地方団体の意見等を踏まえながら、解消を図っていく予定である。 - source: urn:jp:gov:std:016:func:0160141 legal_fields: 機能名称: データ出力 大分類: 1. 共通機能 中項目: 1.10. 様式・帳票出力 機能要件: |- 各種通知書について、印刷の外部委託を実施するためCSV形式のテキストファイルを作成し、出力できること。 氏名等の文字フォントについては、IPAmj明朝フォントで出力すること。 また、氏名等以外の文字フォントについては任意とする。 二次元コード（カスタマーバーコードを含む。）については、二次元コードの値をファイルに格納すること。 一覧形式の内部帳票については、CSV等の汎用的かつ加工可能な形式で出力できること。 実装区分: required 適合基準日: 2027-04-01 要件の考え方・理由: 税務では、税額通知書などの外部帳票を一括で印刷する必要があるため、負担軽減策として印刷業務のアウトソーシングが一般的である。どの外部帳票をアウトソーシングの対象とするかについては、各団体の体制や費用対効果に依るため、画一的に定めることは困難である。一方で、税務システムが未対応であることによって、各団体の体制に応じた業務の最適化が阻害されることは避けるべきであるとの観点により、一括での印刷が必要と考えられる「各種通知書」については、標準化対象業務横断で記載内容を統一し、印刷テキストファイルでの出力を「実装必須機能」として定義している。 備考: 氏名等の文字フォントに関して、行政事務標準文字のうち初期整備の対象となる、IPAmj明朝フォントに実装されていない文字については、デジタル庁が作成した行政事務標準文字図形を参考とする。 - source: urn:jp:gov:std:016:func:0160134 legal_fields: 機能名称: データ出力 大分類: 1. 共通機能 中項目: 1.10. 様式・帳票出力 機能要件: 帳票等の印刷のため、当該帳票等のデータについて印刷イメージファイル（PDF形式等）を作成し、出力できること。 実装区分: optional 要件の考え方・理由: デジタル庁による全標準化対象20業務への修正指示に基づき、印刷イメージファイルでの出力は「標準オプション機能」としている。 - source: urn:jp:gov:std:016:func:0160109 legal_fields: 機能名称: データ出力 大分類: 1. 共通機能 中項目: 1.10. 様式・帳票出力 機能要件: 印刷データの出力においては、帳票印刷作業の都合に合わせて、当該帳票の出力項目を用いて山分け条件やソート順を設定できること。 実装区分: required 要件の考え方・理由: 取り扱い件数の少ない地方団体においては、山分け条件やソート順の任意設定についてのニーズがあまりないが、必要とする地方団体も多いことから備考欄に※の記載を追加した。 備考: ※本要件については、団体の人口規模や組織体制に応じて機能の実装状況にかなりの差異があること等を勘案し、当分の間、【標準オプション機能】へと緩和して位置付ける。ただし、当該取扱いは、あくまで標準準拠システムへの移行期における過渡的なものと整理しており、今後、標準準拠システムの開発・導入状況や地方団体の意見等を踏まえながら、解消を図っていく予定である。 - source: urn:jp:gov:std:016:func:0160110 legal_fields: 機能名称: データ出力 大分類: 1. 共通機能 中項目: 1.10. 様式・帳票出力 機能要件: 当該帳票の出力項目以外のデータ項目を用いて、山分け条件やソート順を設定できること。 実装区分: optional 要件の考え方・理由: 税務では、山分けや引き抜き、同封物の封緘などの印刷後の下流工程があり、当該作業の効率化の為、各種通知書等のソート順を指定する必要がある。ソート順については各団体の体制などに依るため画一的な仕様を定めることが困難と考え、印字項目でのソート順の指定を「実装必須機能」として定義する。各団体は、標準準拠システム導入時に事業者と協議の上、ソート順を指定することを想定している。また、印字項目以外の項目（住所地のグループ化をした地区コード等）でのソート順指定については、各パッケージ製品の実装によるものとし、「標準オプション機能」として定義している。なお、山分けやソートについては、地区や郵便局の集配局、重量などで行われることができるようにすることが考えられる。 - source: urn:jp:gov:std:016:func:0160111 legal_fields: 機能名称: データ出力 大分類: 1. 共通機能 中項目: 1.10. 様式・帳票出力 機能要件: |- 各種通知書については、各票の内容を1レコードとし、一覧形式で出力できること。 なお、当該データの出力においてはCSV等の汎用的的かつ加工可能な形式で出力できること。 実装区分: optional 要件の考え方・理由: 同上 - source: urn:jp:gov:std:016:func:0160112 legal_fields: 機能名称: データ出力 大分類: 1. 共通機能 中項目: 1.10. 様式・帳票出力 機能要件: 帳票の連絡先（問合せ先）について、各項目（連絡先、部署名、氏名等）を任意に設定・修正できること。 実装区分: optional 要件の考え方・理由: 同上 - source: urn:jp:gov:std:016:func:0160113 legal_fields: 機能名称: 印刷 大分類: 1. 共通機能 中項目: 1.10. 様式・帳票出力 機能要件: |- 出力部数を設定できること。 帳票発行時にプレビュー機能を保有すること。 帳票発行時にPDFか紙出力が指定でき、プリンタが指定できること。 税務システム内部でアクセスログの取得が可能な形で、表示画面のハードコピー機能及びハードコピーの印刷機能を有すること。 印刷した帳票の印刷履歴が保持・照会できること。 一括出力、個別出力、再発行に対応すること。 一括出力：特定の条件などの指定により複数の対象に対して一括で帳票を出力する方式 個別出力：特定の対象を指定し1件ずつ帳票を出力する方式 再発行：過去に出力した帳票と同一の帳票を出力する方式 第三者に対して各種証明書・納付書等を発行する場合、住所欄を「記載省略」等として印字できること。 実装区分: required 要件の考え方・理由: 税務では、課税資産の共有者等の第三者に対して各種証明書・納付書等を発行するケースがある。個人情報保護のため、第三者に対して各種証明書・納付書等を発行する場合、住所欄を隠匿する機能を定義している。 - source: urn:jp:gov:std:016:func:0160114 legal_fields: 機能名称: 印刷 大分類: 1. 共通機能 中項目: 1.10. 様式・帳票出力 機能要件: アクセスログが取得できないOS独自の印刷ができること。 実装区分: prohibited - source: urn:jp:gov:std:016:func:0160115 legal_fields: 機能名称: 交付履歴 大分類: 1. 共通機能 中項目: 1.10. 様式・帳票出力 機能要件: |- 税務システムにて発行する各種証明書については、市区町村が定める期間、以下の項目を管理すること。 ・交付年月日時 ・交付場所 ・交付対象者 ・各種証明書の種別 ・交付区分（本人等請求、公用請求、第三者請求、広域交付） ・記載事項 ・枚数 ・発行番号 ・端末名、操作者ID ・処分情報（誤って発行した証明書を処分した場合にはその旨の記録。） また、上記交付履歴の項目について、コンビニエンスストアで交付・広域交付された場合も同様に管理すること。 実装区分: required 要件の考え方・理由: 住民記録システム標準仕様書に準じる。 備考: 1.8.2.アクセスログ管理と同等項目については、そちらでの管理でも問題ない。 - source: urn:jp:gov:std:016:func:0160116 legal_fields: 機能名称: データ構造 大分類: 1. 共通機能 中項目: 1.11. データ要件 機能要件: データ構造については、デジタル庁が策定する「地方公共団体情報システム データ要件・連携要件標準仕様書」の規定に準ずる。 実装区分: "" 要件の考え方・理由: デジタル庁が策定する「地方公共団体情報システム データ要件・連携要件標準仕様書」において、データに関する要件等が定められている。 - source: urn:jp:gov:std:016:func:0160117 legal_fields: 機能名称: 文字 大分類: 1. 共通機能 中項目: 1.11. データ要件 機能要件: 文字要件については、デジタル庁が策定する「地方公共団体情報システム データ要件・連携要件標準仕様書」の規定に準ずる。 実装区分: "" 要件の考え方・理由: デジタル庁が策定する「地方公共団体情報システム データ要件・連携要件標準仕様書」において、文字に関する要件等が定められている。 - source: urn:jp:gov:std:016:func:0160118 legal_fields: 機能名称: 非機能要件 大分類: 2. 非機能要件 中項目: 2.1. 機能要件: － 実装区分: "" 要件の考え方・理由: 運用・保守性、セキュリティなどの非機能要件については、デジタル庁及び総務省が策定する「地方公共団体情報システム非機能要件の標準」によるものとする。 ```