「地方公共団体情報システム共通機能標準仕様書」に関するFAQ
原本: デジタル庁 「地方公共団体情報システム共通機能標準仕様書」に関するFAQ（2026年5月29日更新）。Excel、PDF、掲載ページ。Excel の先頭シート「2026.5.29更新」を質問ごとの見出しに組み替えた（全 113 問）。値はセルの文字列のまま。掲載日は日付として保存されたセルは ISO 日付に、文字列のセル（更新日を併記したもの）は原文のまま。同梱の「見え消し版」シートは文字列が同一で書式（見え消し）だけが違うため載せていない。
全般
Q1. 共通機能は国が構築・提供するのですか。
回答: 共通機能は本仕様書に従って、原則として事業者が構築し、地方公共団体がそれを利用することを想定しています。
掲載日: 2022-08-25
Q2. 共通機能は、ガバメントクラウド上への構築が必須ですか。
回答: 共通機能の機能配置は、他の標準準拠システムと同様にガバメントクラウドの利用を第一に検討いただく必要があります。一方で、標準準拠システム以外のシステム（外部システムを除く。）も含めた連携等も踏まえて検討するべきものであり、ガバメントクラウド上の構築を必須とするものではありません。
なお、申請管理システム（総務省仕様準拠）については、先にオンプレミス等での整備が進められた事例等を鑑み、機能配置する環境は適切にご判断いただければと思います。
掲載日: 2022/8/25
2022/10/28更新
2023/6/30更新
2025/10/31更新
Q3. 「(2)統合運用管理機能群や(3)インフラ機能群については、ガバメントクラウドのマネージドサービス等を活用することが考えられることから、本仕様書の対象外とする。」とありますが、これらの機能群についてはガバメントクラウドが提供するツールを積極的に取り込んだ形でシステムを構築するということでしょうか。
回答: ご認識のとおりです。
掲載日: 2023-06-30
Q4. 共通機能の標準仕様として規定された機能以外の機能を追加することは可能ですか。
回答: 本仕様書が規定する共通機能に新たに機能を追加することや、本仕様書が対象とする共通機能と疎結合の形で新たに機能を作ることは可能です。
各標準準拠システムの標準仕様書で実装不可機能とされた機能を実装することはできません。
掲載日: 2022/8/25
2023/6/30更新
Q5. 共通機能を地方公共団体ごとに構築、機能追加を許容すると、改修を原則認めないとする標準化の趣旨に反しませんか。
回答: 各業務の標準準拠システムに改修を発生させないために必要となる最低限の要件を本仕様書に規定しています。共通機能に任意で実装される機能はあくまで追加的な機能であり、標準準拠システムに改修を発生させるものではないと考えます。
また、機能の追加を可能としているのは、あくまで事業者において共通機能として提供することが適切と判断される機能を提供することを想定したものであり、個別自治体の要求に応じたカスタマイズを許容するものではありません。
掲載日: 2022/8/25
2023/3/30更新
Q6. 既に実装し運用している申請管理機能や団体内統合宛名機能などについても、今回の標準仕様に合わせた改修が必須となるのでしょうか。
回答: 申請管理システム（総務省仕様準拠）を継続利用することは可能ですが、その他の共通機能については本仕様書に準拠する必要があります。
掲載日: 2023-06-30
Q7. ひとつの地方公共団体において、複数事業者が提供する別々の共通機能システムを利用することは可能ですか。
回答: 可能ですが、両システムとも本仕様書に準拠する必要があります。
掲載日: 2022-08-25
Q8. 同一の共通機能を別システムとして構築することは可能ですか（例えば、ガバメントクラウド上のシステム用の団体内統合宛名機能を有するシステムと、オンプレミス環境用の団体内統合宛名機能を有するシステムをそれぞれ構築するなど）。
回答: 実装方式は本仕様書で規定対象外となるため、地方公共団体の判断で実装、構築ください。
掲載日: 2022-08-25
Q9. 共通機能の開発や構築に関する費用はデジタル基盤改革支援補助金の対象となりますか。
回答: 開発費用や利用料は対象となりません。
共通機能標準仕様書における標準化対象範囲となっている共通機能については、標準化対象事務に係る機能であると解されるため、当該機能の標準準拠システムへの移行経費（補助対象経費Ａ～Ｆ）は補助対象となります。
また、現在、共通機能標準仕様書の標準化対象範囲となっている共通機能を有するシステムについて、標準化対象範囲外の部分についても標準化対応に伴い経費が発生することも考えられるところ、その場合については、標準準拠システムと業務データのAPI連携等を行う場合に限って、補助対象経費E（関連システムとの円滑な連携に要する経費）は補助対象となります。
庁内データ連携機能で使用するオブジェクトストレージについては、アプリケーションがデータ連携を行う際に利用する機能であるため、その構築費用はアプリケーション開発に含まれるとして、補助金対象外経費Aに該当します。
掲載日: 2022/10/28
2023/3/30更新
2023/4/11更新
Q10. 「３類型に分類されていない機能（本仕様書に規定していない機能）と同様に実装は任意である」という記載について、「任意の実装」は、ガバメントクラウド上に実装可能でしょうか。
回答: 基幹業務システムの標準仕様書において実装不可機能と規定されている機能を除き、実装可能ですが、構築する基盤は、ガバメントクラウドも含め自治体において任意に選択可能です。
掲載日: 2022/10/28
2023/6/30更新
Q11. 標準準拠システムに段階的に移行する場合、共通機能をいつまでに実装（利用開始）すべきかについて規定や考え方はありますか。
回答: 地方公共団体において各標準準拠システムの移行時期を踏まえて共通機能の利用開始時期をご検討ください。
掲載日: 2022-10-28
Q12. 個人番号を一意の番号と整理し、各標準準拠システムに住基CS照会機能付与したうえで4情報から個人番号を検索できるようにすることで団体内統合宛名機能を不要にすることはできませんか。
回答: 現時点においては、住民記録システム以外のシステムが住基CSと連携することは認められておりません。
掲載日: 2022/10/28
2025/10/31更新
Q13. 本仕様書の対象範囲の共通機能を利用しない場合も、全ての共通機能を実装する必要がありますか。
回答: 本仕様書の対象範囲としている共通機能を利用していない場合は、当該機能を利用する必要はありません。
掲載日: 2023-03-30
Q14. 「本仕様書の対象外とした機能については、本仕様書の対象となった共通機能や各標準準拠システムと疎結合の形で実装することや、本仕様書の対象とされた共通機能と疎結合の形で構築することが可能である。」 と記載がありますが、同一サーバ内で共通機能と対象外機能を分離して実装すれば疎結合であるといえますか。
回答: 同一サーバであっても、分離して実装されていれば疎結合であるといえます。この場合、地方公共団体情報システムデータ要件・連携要件標準仕様書で示す「独自施策システム等連携仕様」に従ってシステム間が連携している必要があります。
掲載日: 2023/3/30
2023/4/11更新
Q15. すでに本仕様書の対象である共通機能を導入している場合、既存システムを引き続き利用することは認められますか。
回答: 標準仕様書に記載の各種規定に準拠した上でシステムを利用ください。
掲載日: 2023/3/30
2023/4/11更新
2025/10/31更新
Q16. 独自施策システム等IDについては、誰が・どのように付番するのでしょうか。
回答: 独自施策システム等IDは自治体内で一意に付番、管理していただきます。
掲載日: 2023-03-30
Q17. 独自施策システムを管理するためのIDを付番することの目的及び具体的なユースケースについて教えてください。
回答: 本仕様書において「地方公共団体において標準準拠システムと連携する独自施策システム等を一意に特定し、管理するためにID を付番することとする。」としております。また、ファイル連携に関する詳細技術仕様書においては、バケットや連携フォルダ命名規則などについて規定していますのでご参照ください。
掲載日: 2023-06-30
Q18. 「本仕様書が対象とする共通機能を、一又は複数の標準準拠システムと一体のパッケージとして提供する場合については、機能配置等の実装方式は本仕様書に適合する必要はなく、パッケージベンダの責任において提供することとしてもよい。」とありますが、実装方式等は事業者の判断に委ねて良いということでしょうか。また、これは経過措置になるのでしょうか。
回答: 本仕様書が対象とする共通機能と標準準拠システムを一体のパッケージで導入する場合は、機能配置や実装方法、連携仕様はベンダの責任で自由に設定できます。ただし、一体的なパッケージ導入ではない場合、連携仕様は共通機能の標準仕様書への準拠が必要です。
なお、当内容については、地方公共団体情報システムデータ要件・連携要件標準仕様書に記載のある、標準準拠システムと連携対象システム間の連携をパッケージ提供事業者の責任において経過措置として可能とすることとは異なり、経過措置ではありません。
掲載日: 2023-06-30
Q19. 団体内統合宛名機能と住登外者宛名番号管理機能を統合して実装することは問題ないでしょうか。
回答: ご認識のとおりであり、「地方公共団体情報システム共通機能標準仕様書」に関するリファレンスにおいてシステムの構築パターンを示しています。
掲載日: 2023/6/30
2024/6/28更新
Q20. 二要素認証については標準準拠システムの機能要件として必須とされていますが、実装はどのように行うのが適切でしょうか。
回答: 標準準拠システムにおいては、横並び調整方針「８操作権限・管理に関すること」で定めているとおり、「情報システムの正規の利用者かどうか判断し（認証）、権限がない利用者による不正利用を防止（認可）すること」が求められております。
実装方法については以下の4つの方式のいずれかを採用してください。
1、端末で二要素認証を実施し、アプリケーションで再度認証、認可を行う。（アプリケーションにおける認証はID/PASS等の一要素でよい）
2、端末で二要素認証を実施し、ログイン情報を認証基盤を通して権限設定されたアプリケーションに連携（SSO）し、認可を行う。
3、認証基盤で二要素認証を実施し、認証情報を適切なアクセス権限が設定された各アプリケーションに連携し、認可を行う。
4、アプリケーションで二要素認証を実施し、認証と認可を同時に行う。
掲載日: 2024-09-30
申請管理
Q21. 総務省仕様に準拠していない申請管理システムは、標準準拠システムとの連携は認められませんか。
回答: ご認識のとおりです。
掲載日: 2023-06-30
Q22. マイナポータル以外の電子申請システムと申請管理機能の連携機能を任意で実装することは認められますか。
回答: 申請管理機能は、マイナポータルと標準準拠システムの間を連携する機能として共通機能標準仕様書で規定していますが、本仕様書では、最低限の機能について標準仕様を作成しており、共通機能に新たに連携機能を追加することを妨げません。
他方、 総務省が示す「地方公共団体における情報セキュリティポリシーに関するガイドライン」上は、「国等の公的機関が構築したシステム等、十分に安全性が確保された外部接続先」として、eLTAX、マイナポータル、自治体情報セキュリティ向上プラットフォームを想定しているところですが、各自治体の判断でマイナポータル以外の電子申請システムとの特定通信を行うことを否定するものではなく、十分にセキュリティ対策を検討の上、採否を御判断ください。
掲載日: 2023/3/30
2024/6/28更新
Q23. マイナポータルからのデータ連携は、地方公共団体ではなく国でシステムを構築する認識で良いでしょうか。
回答: マイナポータルと申請管理との連携については、「マイナポータル申請管理外部接続インターフェース仕様書」によることとしており、連携インターフェースの仕様については国から提供されておりますが、地方公共団体はその仕様に準拠して申請管理の連携要件を構築することとなります。
掲載日: 2023-06-30
Q24. マイナポータルで取り扱う手続きを追加・変更した場合、各地方公共団体の取り扱う手続き及びその設定データ等を申請管理機能ではどのように把握する想定でしょうか。
回答: 「地方公共団体情報システム共通機能標準仕様書」に関するリファレンス及び「別紙1_ 申請管理機能に関する業務フロー」において、手続マスタ管理に係る業務フローを示していますのでこちらをご参照ください。業務フローは特定の手続ではなく、一般的な手続を想定しています。
掲載日: 2023-06-30
Q25. 機能要件（機能ID0290004）において「申請管理機能で保持している番号紐付情報により、申請データのシリアル番号を住民宛名番号に変換できること」とありますが、住民宛名番号情報は転出した住民についても紐づけが可能でしょうか。
回答: 申請管理機能で保持する番号紐付情報については、転出があった以後、申請管理機能側で番号紐付情報を消去しない限りは紐付け可能です。
掲載日: 2023-06-30
Q26. 紙による申請についても、共通機能の申請管理機能を利用できますか。
回答: 現時点においては、紙による申請は、申請管理機能を用いず直接基幹業務システムに登録することを想定しています。
掲載日: 2023-03-30
Q27. 標準準拠システムと申請管理機能のインターフェースについて、過渡的な対応が認められる期間は具体的にありますか。
回答: 具体的な期限は示していません。
掲載日: 2023-06-30
Q28. 機能要件（機能ID0290007）における申請内容照会・登録において、宛名番号とは、「住民宛名番号」を指すのでしょうか。
回答: ご認識のとおりです。申請者が住所地特例など住登外者である場合、住民宛名番号を手動で入力することを想定しています。
掲載日: 2023-06-30
Q29. 申請管理機能で申請データを保管する必要はあるのでしょうか。基幹業務システムに申請データを連携する場合は、基幹業務システムで申請データを保管することになり、二重に保管することになのではないでしょうか。
回答: 基幹システムへの連携に係る処理を効率的に⾏うため、機能要件（機能ID0290003）において「申請データをデータベースもしくはサーバに格納できること」としています。
なお、申請管理機能を一又は複数の標準準拠システムと一体的なパッケージとして提供する場合の扱い（機能配置等の実装方式は、パッケージベンダの責任において提供することとしてもよい）を妨げるものではありません。
掲載日: 2023-06-30
Q30. 共通機能機能要件の申請データ取込（機能ID0290001）で備考に記載のある「マイナポータル申請管理外部接続インターフェース仕様書」の入手方法を教えてください。
回答: ①地方公共団体向け：マイナポータル申請管理にログインし「各種ダウンロード」より取得が可能です。
②事業者向け：マイナポータルAPI仕様公開サイト（https://myna.go.jp/html/api/receiveinfo/index.html）の電子申請等情報受取等APIから仕様書申請が可能です。\ なお、仕様書取得だけであれば、地方公共団体から①で入手した仕様書を事業者に提供してもらう方法も可能ですが、APIを使用した検証等を行う場合は、上記サイトから仕様書申請および利用申請が必要になります。
掲載日: 2023-08-10
庁内データ連携機能
Q31. 庁内データ連携機能の実装方式は、「RESTによる公開用API連携」、「ファイル連携」の両方が実装必須ですか。また、「公開用VIEW連携」等の他の連携方式を採用することはできますか。
回答: 標準準拠システム間の連携及び標準準拠システムと標準準拠システム以外のシステム（外部システムを除く。）の連携は、「RESTによる公開用API連携」と「ファイルによる連携」の2つの連携方式であり、「公開用VIEW連携」等のその他の連携方式は認められません。
なお、連携するデータごとの連携方式は、「地方公共団体情報システムデータ要件・連携要件標準仕様書」をご参照ください。
掲載日: 2022/8/25
2022/10/28更新
Q32. APPLICの地域情報プラットフォームガイドラインで示されている統合DB機能による連携方式は利用することは可能ですか。
回答: 「統合DB」による庁内データ連携機能の実装は、全ての地方公共団体において必要とされているものではないことから、標準仕様の規定対象外としています。一方で、本仕様書で規定しない共通機能についても、地方公共団体の事情を踏まえて必要なものは、本仕様書が規定する共通機能、標準準拠システムと疎結合の形で構築することを妨げません。
「統合DB」は、標準準拠システム間の連携を仲介するものと理解しており、連携の際に統合DBがあたかも連携先または連携元の標準準拠システムのように振る舞うことで、標準準拠システムに改修を発生させずに連携の仲介を実現するのであれば、問題ありません。
掲載日: 2022/8/25
2023/6/30更新
Q33. CSV形式以外のファイル形式（固定長ファイル、XML、ZIP、TSV等）での連携は、今後認められない認識で良いですか。また、認められない理由を教えてください。
回答: 標準準拠システム間の連携及び標準準拠システムと標準準拠システム以外のシステム（外部システムを除く。）のファイル連携においては、CSVファイル以外は認められません。これは、標準準拠システム（共通機能を含む）のインターフェース部分のカスタマイズを発生させないようにし、別の標準準拠システムへの移行時の改修を不要とするためのものです。
なお、本仕様書が対象とする共通機能におけるマイナポータルや中間サーバー等の外部システムとのインターフェースについては、外部システムのインターフェース仕様に従います。
掲載日: 2022/8/25
2022/10/28更新
2023/4/11更新
Q34. 申請管理機能でマイナポータルからダウンロードした申請ZIPについて基幹業務システムとデータ連携することはできますか。
回答: 機能要件（機能ID0290009）において、基幹業務システムに申請データ（申請ZIP）を送信できることとしています。
また、ファイル連携に関する詳細技術仕様書において、「申請ZIP別フォルダの」作成や、申請機能に関して個別の規定がない仕様については他の標準準拠システムと同様の仕様を適用する旨を記載しています。
一方、ファイル連携に関する詳細技術仕様書に記載のある格納完了通知ファイル形式について、そのファイルの3行目に「連携ファイルのヘッダ情報を含まない実データの行数」の情報を含めることとしていますが、申請ZIPについては3行目の情報は不要となります。
掲載日: 2023-09-29
Q35. ファイル連携の実装方式や環境、実装を行う主体についての規定はありますか。
回答: クラウドで提供されるオブジェクトストレージを利用することを原則とし、対応が困難な場合においてはファイルサーバを構築し、連携することも可能です。
「ファイル連携に関する詳細技術仕様書」で規定しています。
掲載日: 2022/8/25
2023/3/30更新
Q36. 2.0版においてオブジェクトストレージを利用する方式となった理由は何故ですか。
回答: オンプレミスを前提としたFTP等のファイルサーバと比較し、構築費用、コストパフォーマンス、信頼性や可用性について優れていること、また、ファイル操作に伴う通知や他サービスとの連携を簡易に実現できることから、オブジェクトストレージを利用する方式としています。
掲載日: 2023/3/30
2025/10/31更新
Q37. 外部システムとファイル連携を行う際、庁内データ連携で用いるオブジェクトストレージを利用することは可能ですか。
回答: 外部システムが対応可能であれば、利用を妨げるものではありません。
外部システムとの連携に利用するあたっては、総務省が示す「地方公共団体における情報セキュリティポリシーに関するガイドライン」及びデジタル庁が示す「地方公共団体情報システム非機能要件の標準」に準拠したセキュリティ対策を施してください。
掲載日: 2023-03-30
Q38. 機能要件（機能ID0300005）において「ログ出力するフォルダは実装時には必ず取り決めすること」とありますが、ファイル連携で利用するオブジェクトストレージの利用推奨と解釈してよいですか。
回答: ログの保存場所は任意であり、オブジェクトストレージにログを置くことを妨げません。
掲載日: 2023-06-30
Q39. ガバメントクラウド上でファイル連携する機能が必要と思われますが、マネージドサービスにより実現されるのでしょうか。
回答: バケットやアクセス権、格納先（フォルダ）等を設定する必要がありますが、ガバメントクラウドの各CSPが提供するマネージドサービスの活用により実現することが可能です。
掲載日: 2023-06-30
Q40. ファイル連携に関する詳細技術仕様書ではバケットの命名規則について以下のとおり記載されています。 {都道府県コード及び市区町村コード }-{システム区分＋業務ID又は独自施策システム等ID}-{システム区分＋業務ID又は独自施策システム等ID} 他方、2.4.権限管理では、「バケット単位でアクセス権限付与を行うこと。」とされており、同一の業務ID又は独自施策システム等IDで複数の事業者がシステムを構築する場合や、本番とテスト環境等において、バケット単位でどのようにアクセス権限を制御するのでしょうか。
回答: ファイル連携に関する詳細技術仕様書 2.1.2.バケット命名規則において、「バケット名はグローバルで一意である必要があることから、（略）仮に、バケット名が一意とならない場合は、自治体の裁量で文字列を付与するなどして、バケットの命名規則に一部変更することも妨げない。」と記載しており、バケット名を一意にした上でアクセス権限を付与する運用を想定しています。
掲載日: 2024-03-18
Q41. ファイル連携に関する詳細技術仕様書では、標準準拠システム間の連携に関するバケットや連携フォルダ作成の際の命名規則が規定されており、いずれの命名規則においても「地方公共団体の基幹業務システムの統一・標準化における各種IDの管理方針」に記載の業務IDを含んだ命名の方法が規定されています。一方で、サブユニット単位での調達が認められている一部の基幹業務システムにおいては、サブユニット毎で業務IDが分かれていないものがありますが、このようなサブユニットが連携する場合のバケットの作成や連携フォルダの作成における命名規則を教えてください。
回答: ファイル連携に関する詳細技術仕様書 2.1.2.バケット命名規則において、「バケット名はグローバルで一意である必要があることから、（略）仮に、バケット名が一意とならない場合は、自治体の裁量で文字列を付与するなどして、バケットの命名規則に一部変更することも妨げない。」と記載しており、文字列を付与するなどにより、本体業務とサブユニット業務を区別できるものと想定しています。また、2.2.2.連携フォルダ命名規則においては、「一つの業務IDに対して、複数の事業者のシステムにて構築する場合は、業務IDの後ろに01から始まる連番2桁を付与し、計6桁とすることでシステムを区別すること。」と記載しており、本体業務及びサブユニット毎の連携フォルダを区別することを可能としています。
掲載日: 2024/3/18
2024/6/28更新
Q42. 標準仕様書の機能の一部を当該業務の標準準拠システムではなく別の業務の標準準拠システムの機能として切り出して調達する場合があります。（例えば、地方自治体により障害者福祉システムの機能にある精神障害者保健福祉手帳と自立支援医療（精神通院医療）は健康管理システムの一部、特別児童扶養手当と自立支援医療（育成医療）は児童福祉システムの一部のように調達する場合がある。）このとき、切り出された機能を実装する標準準拠システムから当該機能のデータを他業務の標準準拠システムへ連携する際のバケットや連携フォルダの構成について教えてください。
回答: 連携する際のバケットと連携フォルダの命名規則は、「ファイル連携に関する詳細技術仕様書」においてそれぞれ以下のように規定されております。
＜バケットの命名規則＞
{都道府県コード及び市区町村コード2}-{システム区分＋業務ID又は独自施策システム等ID}-{システム区分＋業務ID又は独自施策システム等ID}
＜連携フォルダの命名規則＞
システム区分（0:標準準拠システム、1:独自施策システム等）に利用側業務システムの業務IDを合わせた4桁
業務IDの考え方としては、地方自治体が、機能の一部を別の業務の標準準拠システムの機能として切り出して調達した場合に限っては、切り出した元の業務IDを利用しても、切り出した先の業務IDを利用してもどちらでも差し支えありません。
どちらの構成で連携を実装するかにつきましては適切な権限設定を行うことを含めて、自治体及び事業者間の調整の上決めることを想定しております。
例）障害者福祉システムの機能にある精神障害者保健福祉手帳機能を健康管理システムの一部で調達し、個人住民税システムと連携する場合
【パターン①】
○障害者福祉システムと個人住民税システムの連携で利用するバケットやフォルダ構成で連携を行うパターン
精神障害者保健福祉手帳に係る障害者福祉システムのバケット名やフォルダ名と通常の障害者福祉シスSテムのバケット名やフォルダ名を区別して連携を行えるよう、権限管理を含めて事業者間で調整をした上で当該連携を行っていただく想定です。
【パターン②】
○健康管理システムと個人住民税システムの連携で利用するバケットやフォルダ構成で連携を行うパターン
健康管理システムの健康管理機能の連携ファイルと精神障害者保健福祉手帳機能の連携ファイルで取り込み誤りが起きないようにするなど事業者間での調整をした上で当該連携を行っていただく想定です。
掲載日: 2024/6/28
2024/9/30更新
Q43. 「ファイル連携に関する詳細技術仕様書」の「2.3.1 連携ファイル命名規則」の⑤に、独自施策システム等連携仕様による、基本データリストを用いた連携における連携ファイルの命名規則が記載されています。当該規定では命名規則として、基本データリストのグループIDを用いることとなっていますが、共通機能の場合は項目定義書のグループIDを用いて同様の規則で命名することは可能でしょうか。
回答: 共通機能が独自施策システム等と連携する場合、項目定義書のグループIDを用いて、「ファイル連携に関する詳細技術仕様書」の「2.3.1 連携ファイル命名規則」の⑤の規則と同様に命名してください。
掲載日: 2024-06-28
Q44. 「データ要件・連携要件標準仕様書（総論）」の「3.3 独自施策システム等連携仕様」に、独自施策システムとのファイル連携においては基本データリストに規定されたグループ単位のファイルでも対応可能と記載されています。 その際、「ファイル連携に関する詳細技術仕様書」に記載の格納完了通知ファイルも提供側が作成する必要はありますでしょうか。
回答: ご認識の通り、「データ要件・連携要件標準仕様書（総論）」において、独自施策システムとの連携の際、基本データリスト項目以外のデータが必要な場合においてはグループ単位のファイル連携で対応すると規定しております。独自施策システムと標準準拠システムの連携においても、「ファイル連携に関する詳細技術仕様書」の記述に従う必要があるため、提供側による格納完了通知ファイルの作成が必要となります。
掲載日: 2026-03-25
Q45. 成人保健、母子保健にある「○○_独自施策情報（グループID：019036, 019037, 019069, 019070）」は、規定の健診（検診）以外の情報を取り扱う想定ですが、基本データリストのグループ構成表には「同一レイアウトで複数作成することも可能（最大30グループとする）」とあります。これらのグループで該当する検診・健診情報が複数作成される場合、現行の命名規則では、ファイルを受け取るシステムにおいてファイル名からファイルの内容を判別出来ないかと思いますが、このような繰り返しが生じるグループについて、どのように命名するのかご提示ください。
回答: 連携フォルダの命名規則は、「ファイル連携に関する詳細技術仕様書」において以下のように定義しており、{9}の部分で対応いたします。
{システム区分＋グループID}_kihon_YYYYMMDDhhmmssfff_{9}.csv
{9}について、原則、「連番」の規定でございますが、最大30の繰り返しが生じるグループ（健康管理業務におけるグループID：019036等）においては「連番+任意の2桁以上の数値（固定値も可）」を許容しておりますので、市町村を含めた事業者間調整の上、連番＋固定値での運用をご検討ください。
掲載日: 2024/6/28
2024/9/30更新
2025/5/30更新
Q46. 住民の異動情報など更新頻度が高いものについては、リアルタイムのデータ連携のために、提供側の基幹業務システムからのPUSH型での提供が必要ではないですか。
回答: 基幹業務システム間のデータ連携は、ファイル連携で行います。「機能別連携仕様」で随時連携と規定されている連携は、即時での連携が可能です。
掲載日: 2022/8/25
2023/3/30更新
Q47. 移行過渡期において、標準準拠システムから標準準拠未対応システムや標準準拠システム以外のシステムへのデータ連携・文字コードの変換等はどのように対応すればよいですか。統合DB等を設けてインターフェースの差異を吸収してもよいですか。
回答: 標準準拠システムは「地方公共団体情報システムデータ要件・連携要件標準仕様書」及び本仕様書における庁内データ連携機能に規定された連携方式によってのみ連携が可能です。そのため、段階的に基幹業務システムの標準化対応を行う場合には移行期間や連携先システムの改修コスト等の実情を踏まえて対応方針を検討いただく必要があります。
統合DB等を実装して、対応することも妨げません。
掲載日: 2022-08-25
Q48. API連携における認証方式をOAuth2.0としたのはなぜですか。
回答: 相互運用性を確保するため、認証方式を規定しました。
RFCで規定された方式が望ましく、OAuth2.0の中でも、一定レベルのセキュリティ強度が確保されている「FAPI Part1:baseline」を満たすことから、「OAuth2.0（トークンタイプ：Bearer、認証方式：client_secret_jwt）」を採用しました。
掲載日: 2023-03-30
Q49. OAuth2.0アクセストークン情報取得API仕様書では、要求先システムにおいてAPI連携によりアクセストークン情報取得を行うこととなりますが、リクエストパラメータとなるトークンやクライアントアサーションはどのように要求先へ提供されることになるのでしょうか。
回答: APIシーケンス（OAuth2.0）の「②-1リソースを要求」において、要求元システムから要求先システムへアクセストークンを提示する運用を想定しております。
また、クライアントアサーションの元となるクライアントIDとクライアントシークレットは、認証認可サーバで作成され、要求元システムと要求先システムに対して事前に配布される運用を想定しております。
なお、要求先システムが利用するクライアントアサーションJWTは、要求先システムにおいてクライアントIDとクライアントシークレットから作成されるものであり、要求元システムがクライアントアサーションJWTを要求先システムへ提供することはありません。
掲載日: 2023-09-29
Q50. 移行過渡期に限り標準準拠システムに既存の連携機能を有してもよいでしょうか。
回答: 地方公共団体情報システム標準化基本方針 4.1.2連携要件の標準にて規定しています。
掲載日: 2022/10/28
2023/6/30更新
Q51. 広域連合や一部事務組合が複数の地方公共団体から事務を移管され当該事務の標準準拠システムを利用している場合、移管元の地方公共団体の他の標準準拠システムとのデータ連携はどの様になりますか。
回答: 標準準拠システム同士のデータ連携は、「地方公共団体情報システムデータ要件・連携要件標準仕様書」により定められた連携が必要となります。
広域連合や一部事務組合で利用されている標準準拠システムにおいても例外ではなく、「地方公共団体情報システムデータ要件・連携要件標準仕様書」にて定められている連携が必要になります。
掲載日: 2022/10/28
2023/3/30更新
2023/4/11更新
2025/10/31更新
Q52. データ連携元との整合性を確認する機能について、規定する予定はありますか。
回答: 標準仕様として規定する予定はありませんが、任意で機能を追加することは妨げません。
また、標準仕様で示す範囲においても、ファイル連携により、各基幹業務システムでデータを保持することも考えられ、全件連携を行うこと等で整合性確認が可能になると考えられます。
掲載日: 2023-03-30
Q53. 本仕様書で示されている庁内データ連携機能の節で示す内容の対象範囲に、外部システムとの連携は含まれますか。
回答: 外部システムとの連携については本仕様書の対象外です。
掲載日: 2023-03-30
Q54. 退避・移動したファイルの保存期間について「日次処理30日分・月次処理3か月分・年次処理13か月間を最低限保存すること。」とありますが、より長い期間を保存期間とすることは可能ですか。
回答: 当該要件より長い期間を保存期間とすることは可能です。
掲載日: 2023-03-30
Q55. 住登外者宛名番号管理から項目定義書のデータをファイル出力することはできますか。
回答: 各基幹業務システムとの連携における出力については機能別連携仕様にて規定しておりますが、その他における出力については追加の機能において整備することは妨げません。
掲載日: 2023-06-30
Q56. ｢・提供側業務システムが、連携ファイルをCSV形式以外でデータを作成すること。｣が実装不可機能として記載されていますが、他の箇所の記載からはCSV形式以外での連携が許容されるケースもあるように読めます。
回答: 当該実装不可機能は、データ要件・連携要件に規定された連携を想定しています。
外部システムとの連携や別途規定する過渡期における連携等については対象になりません。
掲載日: 2023-03-30
Q57. 「標準オプション機能については、３類型に分類されていない機能（本仕様書に規定していない機能）と同様に実装は任意であるが、標準準拠システムと連携が必要な機能について規定する。」と規定されていますが、機能要件に記載のない機能については、 ①標準準拠システムとの連携は不可。 ②その他独自施策システム等との連携を妨げるものではない。 という認識で相違はないでしょうか。
回答: ①標準オプション機能として機能要件に記載のない機能についても標準準拠システムとの連携は可能ですが、実装する場合、地方公共団体情報システムデータ要件・連携要件標準仕様書に規定する機能別連携仕様に従うこととなります。
②ご認識のとおりであり、独自施策システム等が標準準拠システムとデータ連携する場合は、地方公共団体情報システムデータ要件・連携要件標準仕様書の独自施策システム等連携仕様に従うこととなります。
掲載日: 2023-06-30
Q58. 連携ファイルにおける画像データのフォーマット形式は何が適切でしょうか。 また、画像データが複数ページある場合、データ要件にある繰り返しの定義に従うことになるのでしょうか。
回答: イメージファイルをBASE64にエンコードした文字列としてください。
データ要件の繰り返し定義によらず複数ページのイメージファイルをオブジェクトストレージに格納して、データ連携することができます。
掲載日: 2023-06-30
Q59. データ要件・連携要件標準仕様書や共通機能標準仕様書におけるファイル連携に関する詳細技術仕様書の規定を満たすことで、標準準拠システム間の相互運用性は確保されますか。
回答: データ要件・連携要件標準仕様書は、標準準拠システムから出力するデータの形式や標準準拠システム間の連携項目等について規定しており、各基幹業務システムがこれに適合することで、事業者間のデータ連携に係る調整を容易にすることが可能です。
また、共通機能標準仕様書の庁内データ連携機能は、庁内データの連携方式等をお示しするものであり、事業者のご意見を踏まえ、令和4年度末にファイル連携を原則として、オブジェクトストレージやファイルサーバを活用する場合の仕様について規定することで共通機能部分の相互運用性確保を目指したものです。
データ要件・連携要件、共通機能標準仕様書のいずれも相互運用性の確保のために必要な要件を定めたものではありますが、データ要件・連携要件における履歴の考え方等、各事業者の実装に依存する領域があることから、業務間のデータ連携に係る相互運用性を確保するためには、事業者間の一定の調整が必要となる点には留意が必要です。
掲載日: 2024-09-30
Q60. 連携ファイルの命名規則について、1.1版の場合はどのように版数を表現すればよいですか。
回答: マイナーバージョンアップが同一のメジャーバージョンアップの中で10回以上行われるケースを考慮し、1.1版の場合、vの右が「0101」となります。
例）003o00100v0101_20220126155422111_1.csv
掲載日: 2025-01-31
Q61. マイナンバー利用事務系ネットワークとLGWAN接続系ネットワークに配置された標準準拠システム同士が連携する場合、留意すべき事項はありますか。
回答: 三層分離間のデータ連携については、総務省が示す「地方公共団体における情報セキュリティポリシーに関するガイドライン」及び各地方公共団体における情報セキュリティポリシー等によるところと考えていることから、各地方公共団体等の責任において適切にデータ連携いただくようお願いいたします。
掲載日: 2025-05-30
Q62. 連携データが0件の場合にも格納完了通知ファイルを出力する必要はありますか。
回答: ファイル連携に関する詳細技術仕様書において、「データが0件の場合も格納完了通知ファイルを出力すること。」としており、データが0件であることを明示的に示すことを想定しております。ただし、随時連携等の連携ファイルを作成する条件によっては、0件データの連携ファイルの作成が不要となることも想定されますので、当該機能の実装については事業者間調整の上、自治体での判断としてください。
掲載日: 2026-03-25
住登外者宛名番号管理機能
Q63. 住登外者の基本4情報等が揃わない場合であっても、取得できている情報のみで住登外者宛名番号の付番依頼を行うことは可能ですか。
回答: 可能です。
掲載日: 2022/8/25
2024/9/30更新
Q64. 複数の業務で1つの住登外者宛名番号を使用している場合、業務IDごとにレコードを分けるのではなく、1レコード内に業務IDを複数持つという考えで良いですか。 また、データ抽出時のAPIレスポンスも、複数業務IDがある場合、業務IDの項目だけ複数分返ってくるという考えで良いですか。
回答: 住登外者宛名番号と業務IDについては、ご認識のとおりです。
APIについても、複数の業務IDが１レコードに格納されます。
掲載日: 2022-08-25
Q65. 項目定義書の業務IDと独自施策システム等IDとの組み合わせで参照可能業務を管理すると推察しますが、住民基本台帳ネットワークシステム利用可能業務間では参照可、税業務間では参照可などのセット方法は可能でしょうか。
回答: 業務ID、独自施策システム等IDについてはご認識のとおりです。また、住民基本台帳ネットワークシステムから取得した情報の閲覧を制御することを目的として他業務参照不可フラグを設定しており、これらのデータ項目を活用した運用をご検討ください。
掲載日: 2023-06-30
Q66. 他業務参照不可フラグが設定された場合、同一人物に対して他の基幹業務システムはどのように住登外者宛名番号を登録することになるのでしょうか。
回答: 共通機能標準仕様書に記載する住登外者宛名番号管理の業務フローに示すとおり、届出書等の提出を受けて基本4情報等で住登外者の候補者を照会することになりますが、他業務参照不可フラグが設定されていた場合、当該人物の情報は検索対象とならないため、新規付番の手続をすることとなります。
掲載日: 2023/9/29
2024/9/30更新
Q67. 住登外者の基本4情報を変更した場合、各標準準拠システムへはどのように変更通知が送られるのですか。
回答: 住登外者宛名番号管理機能は、住登外者宛名番号を付番するための機能であり、基本４情報の正本は各標準準拠システムで管理するため、住登外者宛名番号管理機能から変更通知は送信しません。
掲載日: 2022-08-25
Q68. 住登外者宛名基本情報に関する登録、結果の送信機能をバッチ処理で実装することは可能ですか。
回答: バッチ処理は標準準拠システムで実装する機能であり、本仕様書の規定対象外であるため、標準準拠システムの標準仕様書にバッチ処理の機能が規定されていれば実装可能であると認識しています。
掲載日: 2022-08-25
Q69. 基本4情報を取得できず名寄せができないことも想定されますが、住登外者宛名番号管理機能への登録対象は、地方公共団体が任意で選定することも可能ですか。
回答: 標準準拠システムにおいて住登外者宛名番号を付番する場合には、住登外者宛名番号機能を利用いただく必要があります。
掲載日: 2022-08-25
Q70. 現在、パッケージシステムに含まれる宛名管理機能により全庁的に宛名（番号・宛名情報・付随情報）の一元管理を行っており、住登外者宛名番号の発行機能もこれに含まれます。現行と同様の宛名管理システムを独自に構築して運用することは可能でしょうか。
回答: 標準仕様書間の横並び調整方針において「宛名番号の付番をするためのシステムについては、住民について住民記録システムが付番し他システムに連携することとし、住登外者については住登外者宛名番号管理機能が付番することと整理する。」としており、「宛名情報を一元的に管理したい自治体は、宛名管理システムを、独自施策システムとして構築する。」としています。また、本仕様書において「共通機能に新たに機能を追加することや、本仕様書が対象とする共通機能と疎結合の形で新たに機能を作ることを妨げない」としていることから、独自施策システムとして標準準拠システムとは疎結合する形で構築することや、住登外者宛名番号管理機能に追加することを妨げるものではありません。
掲載日: 2023-06-30
Q71. 標準準拠システムが住登外者削除情報を送信した後に、他の標準準拠システムが同一人の住登外者登録をした場合、住登外者宛名番号管理機能はどのような処理を行うのですか。
回答: 同一人の住登外者登録を行う際の住登外者宛名基本情報検索機能により、住登外者の削除履歴を含めて検索し、候補者を抽出します。その上で、当該宛名と同一人と判断し、宛名番号を再度利用するか、同一人と判断せず新規に付番するかを選択することが可能です。
掲載日: 2022/8/25
2023/3/30更新
Q72. 同一の住登外者に対して宛名番号の異なる宛名を作成してしまったケースにおいて、団体内統合宛名機能にて個人番号を利用することで各宛名が同一人であることが確認できた場合、住登外者宛名番号管理機能における名寄せに利用するために、団体内統合宛名機能での同定結果を住登外者宛名番号管理機能へ連携することは出来ますか。
回答: 住登外者宛名番号管理機能は住登外者宛名番号の付番・管理に特化した機能であり、名寄せの処理自体は標準準拠システム側で行われることを想定しており、住登外者宛名番号管理機能は標準準拠システムから連携される名寄せ情報に基づいて、住登外者宛名番号の名寄せを実施します。
したがって、ご質問のケースのような団体内統合宛名機能と住登外者宛名番号管理機能の連携については標準仕様として規定していません。
掲載日: 2022/8/25
2023/3/30更新
Q73. 住登外者宛名番号管理機能にてDV情報の管理が必要ではないですか。例えば、介護でDV支援措置対象となっている方を税で住登外者登録する際、税側でも介護同様に管理上の考慮が発生するためです。
回答: 本機能が保持する情報は付番のための情報であり、業務間で連携することを目的とした情報ではないため、DV支援措置の情報は不要と判断しています。
掲載日: 2022-08-25
Q74. 住登外者宛名管理機能でDV情報を管理する際に、旧氏使用、通称名の使用有無等により、対象の宛名情報が抽出できない可能性があります。宛名履歴や通称名を管理することは可能ですか。
回答: 本仕様書では住登外者宛名番号の付番及び管理のために必要となる最低限の機能要件を規定しており、地方公共団体が必要と判断する機能を住登外者宛名番号管理機能に任意で追加することは妨げません。
掲載日: 2022/8/25
2023/4/11更新
Q75. 住登外者の個人情報は、住民基本台帳法に基づき住民基本台帳に掲載された情報とは異なると考えていますが、位置づけはどのように捉えればよいですか。
回答: 住登外者の個人情報の取り扱いについては、個人情報の保護に関する法律についてのガイドライン（行政機関等編）では、「利用目的の範囲内で取り扱わなければならない。」とされており、地方公共団体において必要な利用目的を特定する必要があります。
また、「例外的に利用目的以外の目的のための利用及び提供が認められる場合」について、以下の場合に認めることとされています。
行政機関等が法令の定める事務又は業務の遂行に必要な限度で保有個人情報を内部で利用する場合であって、当該保有個人情報を利用することについて相当の理由があるとき（同項第2号）
掲載日: 2022-08-25
Q76. 法人宛名番号は住登外宛名と同様に20業務のほとんどで利用する情報ですが、住登外者宛名番号管理機能の対象に法人宛名管理は含まれないのですか。その場合、法人宛名番号はどのように管理すればよいですか。
回答: 法人宛名番号については住民・住登外者と比較し、所持する項目が大きく異なること、また法人の性質も様々であることから、本仕様書の対象外と判断しました。したがって、法人宛名番号の管理に関する機能は、各基幹業務システムの標準仕様書に規定のある場合を除き、標準準拠システムとは疎結合の形で実装いただく必要があると考えます。
掲載日: 2022-08-25
Q77. 住登外者宛名番号管理機能の利用開始にあたっては、名寄せの完了が条件となりますか。
回答: 初期データ移行の名寄せは必須としません。ただし、初期データ移行に際し住登外者宛名番号が重複する場合は重複番号に対する対応が必要となります。
掲載日: 2022-08-25
Q78. 標準準拠システム以外のシステムで管理されている住登外者の情報も初期セットアップとして名寄せの対象となりますか。
回答: 標準準拠システム以外のシステム（外部システムを除く。）が住登外者宛名番号管理機能を利用することは任意ですので、名寄せの要否についても各地方公共団体にてご判断ください。
掲載日: 2022/8/25
2022/10/28更新
Q79. ある業務システムが住登外者宛名番号管理機能に登録した住登外者宛名情報を、他の業務システムが更新・削除して問題ないでしょうか。
回答: 住登外者宛名番号管理機能における基本4情報はあくまで付番のための情報であるため、更新することは問題ないものと考えます。
また、住登外者宛名番号の削除については、当該業務の業務IDのみが削除されるため、他の業務が利用する住登外者宛名番号が削除されることはありません。
掲載日: 2023-03-30
Q80. 住登外者宛名番号管理機能の追加機能として個人番号に関する機能を実装することは、標準仕様書上問題ないとの理解でよいですか。
回答: 共通機能標準仕様書に記載しておりますとおり、自治体において、新たに機能を追加することは妨げられておりません。
ただし、機能の追加に伴い、以下の事務又は庁内連携が発生する場合には、番号利用法第9条第2項に基づく条例の定めが必要となりますのでご留意下さい。
①個人番号の独自利用を行う事務
②個人番号の独自利用を行う事務の処理のための庁内連携
③番号利用法に定められた個人番号利用事務の処理のための庁内連携
掲載日: 2023/3/30
2024/9/30更新
Q81. 住登外者として当該市に最初に登録された人が、その後転入してきた場合は、新規に住民宛名番号を付番されますか。
回答: 現時点において、住民記録システムでの転入において、住登外者宛名番号管理機能に対して基本４情報で突合し、住登外者宛名番号を利用することはできません。
掲載日: 2023-03-30
Q82. 住登外宛名番号管理機能において、標準仕様書に規定されたAPI連携を使用せず、宛名情報等をファイル連携することは許容されないのでしょうか。
回答: 地方公共団体情報システム共通機能標準仕様書に規定している住登外者宛名番号管理機能を実装する場合においては、API連携を用いて連携いただく必要がございます。
他方で、宛名情報を一元的に付番・管理するためのシステム（宛名管理システム等）は、独自施策システムとして整理しており、その場合において、同標準仕様書に規定しているAPI連携を使用した住登外者宛名番号管理機能を実装せずに、データ要件・連携要件標準仕様書3.3独自施策システム等連携仕様によりファイル連携を行うことを妨げません。
掲載日: 2025-02-28
Q83. 住登外者宛名番号にアルファベットを使用することはできますか。
回答: 新規付番については数値のみを使用してください。項目定義書において住登外者宛名番号のデータ型は文字列型となっておりますが、こちらは標準化移行前における過去データにおいて、アルファベットを使用している場合を考慮したものです。したがって、既に文字列型で設定された宛名番号を継続して利用いただくことは問題ありません。
掲載日: 2026-05-29
団体内統合宛名機能
Q84. 標準仕様書に規定された団体内統合宛名機能を経由せずに、中間サーバーには連携することは可能ですか。
回答: 標準化後においては、標準準拠システムは団体内統合宛名機能を経由して中間サーバーと連携することとなります。
掲載日: 2022/8/25
2023/4/11更新
Q85. 各標準準拠システムは団体内統合宛名番号を保持しないのですか。
回答: 各標準準拠システムおいては団体内統合宛名番号を保持しない方針としています。また、この方針に沿って基幹業務システムの標準仕様書を策定しました。
掲載日: 2022/8/25
2023/3/30更新
Q86. 現在利用中の団体内統合宛名管理システムも、申請管理システム（総務省仕様準拠）と同様に継続利用することは可能ですか。
回答: 既存の団体内統合宛名システムにおいては、標準化対応として、本仕様書で規定する団体内統合宛名機能の機能要件に準拠する必要があります。
掲載日: 2022-08-25
Q87. 項目定義書では業務IDと独自施策システム等IDのいずれもが主キーになっていて、どちらか片方がnullになるという認識で良いでしょうか。
回答: 項目定義書の項目説明に記載していますとおり、対象のIDがない場合にはデフォルト値を「000」とすることとしています。
掲載日: 2023-06-30
Q88. 基幹業務システムや独自施策システムから団体内統合宛名機能を経由して自治体中間サーバーと連携する場合、各システムから団体内統合宛名機能への連携においてファイル連携は許容されないのでしょうか。 また、当該連携において、命名規則等はどのようになるのでしょうか。
回答: 団体内統合宛名機能の機能別連携仕様では、基幹業務システムとの連携インターフェースについて「「地方公共団体 情報連携中間サーバーシステム・ソフトウェア」外部インターフェイス仕様書」及び「【別冊】外部インターフェイス仕様書（情報提供等記録開示システム連携）」によることと記載しています。加えて、共通機能標準仕様書において、団体内統合宛名機能に実装される各システムとのインターフェイスは、中間サーバーの外部インターフェイスを準用する仕様としています。
また、独自施策システムについては、同標準仕様書に記載のとおり、団体内統合宛名機能を利用する際は、団体内統合宛名機能のインターフェイスにアクセスすることで利用可能となります。
そのため、基幹業務システムや独自施策システムと団体内統合宛名機能との連携は、当該外部インターフェイス仕様書等に基づく通信仕様となり、SOAP通信でのデータ連携（XML形式）となります。
この場合、ファイル連携に関する詳細技術仕様書で規定する連携ファイル命名規則等に従うことはありません。
掲載日: 2023/9/29
2024/3/18更新
2025/1/31更新
2025/5/30更新
Q89. 基幹業務システムや独自施策システムから団体内統合宛名機能を経由して自治体中間サーバーと連携する場合、「共通機能標準仕様書」における外部インターフェイス一覧に記載されている全ての連携インターフェイスを実装する必要がありますか。
回答: 「2.4.2.団体内統合宛名機能の位置付け」に記載のとおり、団体内統合宛名機能における標準準拠システム・住民記録システム等・中間サーバとのインターフェイスのいずれについても、各地方公共団体において必要となるインターフェイスを選択し実装してください。
掲載日: 2026-05-29
Q90. 団体内統合宛名機能は、地方公共団体の首長部局と教育委員会で共通の実装になるのでしょうか。
回答: 団体内統合宛名機能を首長部局と教育委員会でそれぞれ実装するのか、又は共通で実装するのかは、各地方公共団体の運用に合わせてご判断ください。
掲載日: 2023-12-28
Q91. 地方公共団体の首長部局と教育委員会で共通の団体内統合宛名機能を実装する場合、就学事務システム（就学援助）から団体内統合宛名機能へ特定個人情報を提供するにあたり、機関が異なるため、番号法第19条第１項第11号の規定に基づく条例の制定は必要でしょうか。
回答: 地方公共団体内の異なる機関で共通の団体内統合宛名機能を利用する場合、団体内統合宛名機能への特定個人情報の提供に関しては、番号法第19条第１項第８号による情報提供の要求を受けた際に特定個人情報を提供するために必要な機能であるため、別途条例制定は不要です。
掲載日: 2023-12-28
Q92. 広域連合や一部事務組合の構成団体で同一の宛名番号が複数存在した場合、基幹業務システムと団体内統合宛名機能との連携において、宛名番号から団体内統合宛名番号をどのように特定して変換するのでしょうか。
回答: 共通機能標準仕様書では、「共通機能に新たに機能を追加することや、本仕様書が対象とする共通機能と疎結合の形で新たに機能を作ることを妨げない」としており、団体内統合宛名機能において、宛名番号の他に構成団体や個人を特定する情報を基にして団体内統合宛名番号を特定し、宛名番号から団体内統合宛名番号へ変換する機能を搭載して対応することが想定されます。
掲載日: 2023-12-28
Q93. 送信元システム識別子と送信先システム識別子は、中間サーバーとの連携において必要な項目であるため、基幹業務システムと団体内統合宛名機能との連携においても必要でしょうか。
回答: 共通機能標準仕様書2.4.1.において、「標準準拠システムが「「地方公共団体 情報連携中間サーバーシステム・ソフトウェア」外部インターフェイス仕様書」及び「【別冊】外部インターフェイス仕様書（情報提供等記録開示システム連携）」（以下「外部インターフェイス仕様書等」という。）に規定されているインターフェイスを利用して中間サーバーと連携する際は、団体内統合宛名機能を経由し、利用する。」と記載しているとおり、基幹業務システムと団体内統合宛名機能間の連携において送信元システム識別子と送信先システム識別子は必要な項目です。
掲載日: 2023/12/28
2025/5/30更新
Q94. 団体内統合宛名機能は業務IDや独自施策システム等ID毎にデータを管理する一方、住登外者宛名番号管理機能では住登外者宛名番号毎にデータを管理する構成となっており、両機能で異なる理由を教えてください。
回答: 団体内統合宛名機能は、基幹業務システムや独自施策システム等からの付番依頼情報に基づき、団体内統合宛名DBに合致する個人番号が存在しない場合、団体内統合宛名番号を付番して宛名基本情報を保存します。また、更新依頼情報に基づき複数の宛名基本情報を保持する場合、団体内統合宛名として有効な宛名基本情報を指定するために統合宛名フラグを設定することとしています。
一方、住登外者宛名番号管理機能は、住登外者宛名番号を付番・管理するための機能として、住登外者宛名番号の付番にあたり住所情報や氏名等の履歴を含めた住登外者宛名基本情報を検索するため、住登外者宛名番号に基づいて履歴を管理するデータ構成としています。
掲載日: 2024-03-18
Q95. 独自施策システムである宛名管理システムに団体内統合宛名機能を実装する際に、現行システムの機能が共通機能仕様書の規定に準拠している、もしくは改修で準拠する場合、現行システムを継続利用することは可能でしょうか。この場合、団体内統合宛名機能は、各システムとどのように連携するのでしょうか。
回答: 宛名管理システムが 「地方公共団体情報システムデータ要件・連携要件標準仕様書」の機能別連携仕様で規定するインターフェースに準拠していれば、現行システムを継続利用していただいて問題ございません。また、宛名管理システムを標準準拠システムと一体のパッケージとして提供する場合を除き、標準準拠システムとの連携は、機能別連携仕様で規定する連携インターフェースを利用することを原則としておりますが、「地方公共団体情報システム共通機能標準仕様書」に関するリファレンス 6.5.宛名管理システムのデータ連携に記載のとおり、当該インターフェースで連携できない項目がある場合においては、データ要件・連携要件標準仕様書の独自施策システム等連携仕様に基づいて連携を行うことも想定されます。
掲載日: 2024/9/30
2025/1/31更新
EUC
Q96. 共通機能の標準仕様として規定された機能以外の機能を追加することは可能ですか。
回答: 本仕様書が規定する共通機能に新たに機能を追加することや、本仕様書が対象とする共通機能と疎結合の形で新たに機能を作ることを妨げません。
一方、各標準準拠システムの標準仕様書で実装不可機能とされた機能を実装することはできません。
掲載日: 2022/10/28
2023/6/30更新
Q97. 「EUC 機能で利用するデータソースは当該機能専用のデータソースとして整備すること」とありますが、各標準準拠システムのデータベースとは別にデータソースを整備するという認識でよいですか。
回答: 2.0版において、「EUC機能で利用するデータソースは当該機能専用のデータソースとして整備すること」という記載を削除しました。
従って、各標準準拠システムのデータベースを利用することも、標準準拠システムから基本データリストを連携し、EUC機能専用のデータソースとして利用することも可能です。
掲載日: 2022/10/28
2023/3/30更新
Q98. 「一又は複数の標準準拠システムと一体のパッケージとしてEUC 機能を提供する場合については、基本データリストを利用できることを前提に、基本データリスト外のデータ項目の利用も可能とする。」とはどのようなことでしょうか。
回答: 「機能別連携仕様にて他業務から取得しているデータ項目については、基本データリストにないデータ項目であっても、データソースの対象とし、データの型、桁数等は連携元である他業務の基本データリストの定義に従うこと。」を指しています。
掲載日: 2023-06-30
Q99. 個別の標準準拠システムでEUC機能を実装すれば、共通機能標準仕様書に記載された各業務横断的に利用できるEUC機能は実装する必要はない、という理解でよいですか。
回答: 個別の標準準拠システムで実装される場合は、業務横断的に利用できるEUC機能を実装する必要はありません。
掲載日: 2023-03-30
統合収滞納管理機能
Q100. 統合収納管理機能・統合滞納管理機能を実装する場合には、標準化仕様に準拠する必要がありますか。
回答: 機能要件及び機能別連携仕様について準拠する必要があります。業務固有の要件については、要件の考え方・理由に記載しており、利用しない業務の要件を満たす必要はありません。
掲載日: 2023-06-30
Q101. 統合収滞納管理機能の実装は必須でしょうか。任意の場合、統合収納管理機能か統合滞納管理機能のいずれか一方のみを実装してもよいのでしょうか。
回答: 共通機能の実装は各地方自治体の任意です。必ずしも共通機能としての統合収納管理・統合滞納管理を利用しなければならないということではなく、いずれか一方のみでも構わないほか、業務個別の収納管理機能・滞納管理機能のみを利用することも可能です。
掲載日: 2023-03-30
Q102. 本仕様書において統合収納管理機能・統合滞納管理機能について、任意に実装することができるといった記載がありますが、当該機能を実装する場合、その対応時期は各標準準拠システムと同様に令和７年度末までに整備することを目標とするということでしょうか。
回答: ご認識のとおりです。
掲載日: 2023-06-30
Q103. 各賦課業務に規定されない標準準拠システムにおいても、統合収滞納管理機能を利用することは可能でしょうか。
回答: 各賦課業務に規定されない標準準拠システムも、統合収滞納管理機能を利用することが可能です。また、標準化対象外事務についても、利用することが可能です。
掲載日: 2023-03-30
Q104. 共通機能として統合収納管理機能・統合滞納管理機能を導入する場合、業務単位で利用有無を任意に選択してよいでしょうか。 例）国民健康保険、介護保険、後期高齢者医療は共通機能を利用するが、税業務や子ども・子育て支援は利用せず業務個別の機能を利用する 等
回答: 差し支えありません。
掲載日: 2023-06-30
Q105. 標準準拠システム以外のシステムとのデータ連携について、統合収滞納管理システムがオブジェクトストレージ経由で標準準拠システム以外のシステムとデータ連携することは許容されますか。
回答: 統合収滞納管理システムがオブジェクトストレージ経由で標準準拠システム以外のシステムとデータ連携することは、許容されます。
掲載日: 2023-03-30
Q106. 各賦課業務のうち、A業務とB業務が第1統合収滞納管理機能を運用し、C業務とD業務が第2統合収滞納管理機能を運用するような、地方公共団体内で複数の統合収滞納管理機能を運用することは可能でしょうか。 また、A業務とB業務が第1統合収納管理機能を運用し、C業務とD業務が第2統合収納管理機能を運用し、統合滞納管理機能は自治体で単一のものとする運用は可能でしょうか。
回答: いずれの運用についても標準化法上の制約はありません。
掲載日: 2024-03-18
Q107. 統合収納管理_項目定義書におけるコードID002（業務詳細（科目）コード）では標準化対象業務以外の科目（住宅使用料・学童保育料・奨学金・学校給食費等）が想定されていませんが、それらは各事業者の自由定義ということでしょうか。 その場合、データ連携で読み替えや対比表が必要と思われますが、予め考慮しておかないのでしょうか。
回答: 各賦課業務（税務、介護保険、国民健康保険、後期高齢者医療、子ども・子育て支援）以外の収滞納情報を統合収滞納管理機能で管理いただく場合は、統合収納管理コードID002備考記載の自治体独自コードにより管理いただく想定です。
対象範囲や管理パターンが膨大となるため、現時点では、対比表等の作成は予定していません。各事業者において変換等の対応をすることとなります。
掲載日: 2024-03-18
Q108. 国民健康保険システムの標準仕様において標準オプション機能となった機能が削除されています。削除された機能は、実装不可機能と読み取られるため、削除ではなく、実装区分を標準オプションに変更した方がよいのではないでしょうか。
回答: 統合収滞納管理機能は、各賦課業務の実装必須機能と実装不可機能を集約したものを機能要件として定めています。そのため、各賦課業務標準仕様書において標準オプション機能に修正となった機能については、原則統合収滞納管理機能要件としては規定せず、機能要件からは削除となります。
なお、統合収滞納管理機能は共通機能であるため、各賦課業務と異なり、機能要件にない機能は実装不可機能とはなりません。事業者において共通機能として提供することが適切と判断される機能を追加し、提供することが可能です。
掲載日: 2024-03-18
Q109. 統合収滞納管理機能を導入する場合、個別のシステムでも収滞納機能を開発すると、二重に開発を行うこととなり、無駄が生じます。個別業務での開発も必要でしょうか。
回答: 各賦課業務（税務、介護保険、国民健康保険、後期高齢者医療、子ども・子育て支援）においては、「共通機能標準仕様書」2.6.2に規定されているとおり、共通機能として統合収滞納管理機能を実装する場合には、個別収滞納管理機能を実装せず、当該統合収滞納管理機能をもって個別収滞納管理機能とみなすことができます。そのため、統合収滞納管理機能を実装する場合には、個別賦課業務システムにおいて収滞納管理機能を実装する必要はございません。
なお、税務以外の各賦課業務の基本データリストにおいて、統合収滞納管理機能を採用した場合に出力が不要となるグループについて、グループ構成表シートにてお示ししています。
掲載日: 2024-06-28
Q110. 機能要件（機能ID0360414:口座振替済通知書（圧着はがき））について、圧着機を導入していない場合等への対応のためフリーレイアウトが基準帳票として存在しないのですが、システムとして実装することは可能でしょうか。
回答: 統合収滞納管理機能の帳票要件につきましては、「共通機能標準仕様書」2.6.3.に記載のとおり、各賦課業務横断的に利用される住民向けの帳票・様式について、統一的な帳票・様式を採用する場合の基準（基準帳票）を規定しています。基準帳票を採用しない場合においては、各賦課業務標準仕様書の帳票要件に準拠していただく必要があります。
ただし、共通機能である統合収滞納管理機能では、事業者において共通機能として提供することが適切と判断される場合は、標準仕様として規定された機能以外の機能を追加することが可能です。当該機能追加として、事業者が適切と判断する帳票の出力機能を追加をしていただくことは差支えございません（「地方公共団体情報システム共通機能標準仕様書」に関するFAQ#5に記載のとおり、個別自治体の要求に応じたカスタマイズを許容するものではない点ご留意ください。）。
掲載日: 2024-06-28
Q111. 各賦課業務の標準仕様書において、課税年度、賦課年度、調定年度、相当年度等の用語の揺らぎが生じていますが、住民並びに職員の混乱を招かないよう統一したいです。 共通機能標準仕様書における統合収納管理機能及び統合滞納管理機能の用語に合わせる形で、各賦課システムの画面要件や帳票の見出し等を変更しても差し支えないでしょうか。具体的には、賦課年度及び相当年度に統一するものとなります。
回答: 統合収納管理もしくは統合滞納管理を採用のうえ、業務間で統一が必要な場合かつ事業者において各自治体毎にカスタマイズを行うことなく、パラメータ設定等にて対応が可能である場合において、統合収納管理もしくは統合滞納管理の用語に合わせることは差し支えありません。
掲載日: 2025-10-31
その他
Q112. 項目定義書のカラム説明はどこに示されているのでしょうか。
回答: 項目定義書のカラム説明は基本データリストと同様です。「地方公共団体情報システムデータ要件・連携要件標準仕様書 第2章 2.2基本データリスト （2）各カラムの説明」をご参照ください。
掲載日: 2026-03-25
Q113. 今回標準仕様が示された機能以外について、今後、標準仕様を示す予定はありますか。
回答: 本仕様書で規定した機能については、現行の業務システムにおける共通的な機能としての整備の状況や個別の基幹業務システムに依存しない形での機能の定義の容易性の観点から、対象範囲を定めているものであり、今後、各標準仕様書の改定等にあわせて対象範囲を見直すことはあり得ます。
掲載日: 2022/8/25
2023/3/30更新