自治体向け税務システム開発の発注/外注/依頼/委託方法について

自治体向け税務システムの発注では、標準仕様への適合、課税・収納・滞納データの移行、法改正後の保守までを一体で定義し、価格だけでなく長期運用の実現性で委託先を選ぶことが重要です。税目を一つだけ改修する場合と複数税目を刷新する場合では、必要な契約、体制、費用、移行リスクが大きく異なります。

この記事では、自治体の税務課・情報政策課・財政担当者が、自治体向け税務システムを発注・外注・依頼・委託する際の進め方を解説します。発注形態の選び方、RFPと要件整理、準委任・請負などの契約形態、2026年時点で参考にできる費用レンジ、委託先選定と見積比較のポイントまで、調達前に確認したい論点を順番に整理します。

▼全体ガイドの記事
・自治体向け税務システム開発の完全ガイド

自治体向け税務システムとは？発注前に全体像を確認します

自治体向け税務システムは、住民や事業者に対する税の賦課、収納、滞納管理、証明・通知、申告・照会を扱う基幹業務システムです。発注範囲には、個人住民税、法人住民税、固定資産税、軽自動車税、収納管理、滞納管理、地方税共通に加え、自治体によって国民健康保険税、税務窓口、申告支援、GIS連携などが含まれます。対象業務を曖昧にしたまま見積を取ると、会社ごとに範囲が変わり、金額の比較ができなくなります。

まず、賦課、収納、滞納、帳票、証明、統計のどこまでを対象にするかを決めます。機能面では、宛名・住民情報との名寄せ、課税資料の取込、税額計算、更正・決定、土地・家屋・償却資産の評価、納税通知書と督促状の作成、消込・還付・充当、滞納者・財産・折衝・差押の管理までを確認します。さらに、住民基本台帳、eLTAX、国税連携、金融機関、口座振替、地方税お支払サイトやeL-QR、印刷事業者、GISとの接続を洗い出します。

標準化対象の税務業務では、国の標準仕様を確認してから独自要件を整理します。デジタル庁のデータ要件・連携要件の標準仕様では、個人住民税、法人住民税、固定資産税、軽自動車税、収納管理、滞納管理、地方税共通が2026年2月27日付の第10.0版として掲載されています（出典：デジタル庁「データ要件・連携要件の標準仕様」、2026年）。RFPには、提案システムがどの版数に適合するか、将来の改版をどの契約範囲で追随するかを明記します。

独自帳票や条例に基づく地域運用は、標準機能との差分として記録します。その際、「制度上必須」「自治体固有の運用」「これまで続けてきた慣行」の三つに分けると、カスタマイズの優先順位を決めやすくなります。標準仕様に寄せられる業務を無理に個別開発すると、改版のたびに追加費用とテストが発生します。一方で、条例や住民サービスに直結する差分まで削ると現場が使えないため、差分の理由と代替案を残すことが重要です。

発注形態はどれを選ぶとよいですか？

発注形態は、標準準拠パッケージを導入する方法、複数自治体で共同利用するクラウドを使う方法、既存システムを段階的に刷新する方法、独自要件をスクラッチ開発する方法に分けて考えます。標準仕様に合わせられる範囲が広いほどパッケージや共同利用が有力になり、地域固有の帳票や複雑な業務を残すほど個別開発の比重が高くなります。最初から一方式に決めず、税目ごとに最適な方式を比較することが安全です。

標準準拠パッケージは、税務業務の基本機能、制度改正、帳票、権限、操作ログを一定の型で導入しやすい方式です。自治体側が業務を標準機能へ寄せられる場合は、要件定義と開発を短くし、保守の見通しを立てやすくなります。ただし、パッケージ名だけでは適合状況を判断できません。税目ごとの対応版数、標準外機能、帳票差分、他システムとの連携方式、データ移行の実績を確認し、デモで実際の業務を再現します。

共同利用型クラウドは、複数自治体が共通の基盤やアプリケーションを利用し、運用・制度改正対応の負担を分ける方式です。NECは豊橋市と岡崎市の税総合システムを共同利用型クラウドで提供し、岡崎市について単独利用と比べてシステム開発費と運用保守費を5年間で約5.5億円、45％削減可能と見込んだ事例を公表しています（出典：NECプレスリリース、2013年）。これは現在の全自治体に当てはまる相場ではありませんが、共同利用の効果を検討する際の公開事例です。

共同利用では、他自治体と共通化できる業務と、自団体だけに必要な差分を分けます。利用料に含まれる法改正対応、帳票変更、ユーザー追加、データ抽出、障害時の復旧、自治体ごとの設定変更を契約前に確認します。ガバメントクラウドやLGWAN-ASPを利用する場合も、クラウドの安全性だけで判断せず、データ保管場所、アクセス権限、監査ログ、バックアップ、解約時のデータ返却条件まで確認します。

現行システムをすべて一度に置き換えるのではなく、収納や証明など比較的切り出しやすい領域から段階的に刷新する方法もあります。段階刷新は、移行リスクと職員の学習負荷を分散しやすい一方、旧システムとの並行稼働、二重入力、連携仕様の調整が必要です。スクラッチ開発は、独自業務を柔軟に実現できる反面、標準仕様の改版、税制改正、担当者交代後の保守要員、障害復旧までを自治体側と開発会社が長く担うことになります。

選択の判断では、人口規模だけでなく、税目数、現行データの品質、職員が維持できる運用体制、標準化の期限、独自運用の重要性を見ます。標準機能で対応できる業務はパッケージや共同利用で揃え、差分だけを設定・API・小規模改修で補う構成が、将来の改版にも対応しやすい考え方です。

RFPと要件整理はどのように進めますか？

RFPは、開発会社に機能一覧を渡すだけの文書ではありません。背景と目的、対象税目、現行業務、連携先、移行対象、非機能要件、導入時期、保守期間、提案・見積の様式をそろえ、各社が同じ前提で提案できるようにする文書です。発注者側が目的と制約を整理し、委託先には実現方式とリスク、必要な体制を示してもらう形にすると、価格だけに偏らない比較ができます。

最初に税務課、収納担当、滞納担当、窓口、情報政策課、財政担当、印刷・委託先を集め、業務とデータの流れを描きます。課税資料の取込元、異動処理、税額計算、更正、通知書印刷、納付情報の取込、消込、還付、滞納整理、証明書発行について、担当者、入力時期、出力帳票、連携ファイル、手作業を確認します。台帳の項目名だけでなく、外字、旧住所、宛名統合、欠損値、重複データ、保存年限も移行リスクとして記録します。

繁忙期の性能と停止制約も重要です。住民税の賦課、納税通知、申告、年度更新、固定資産評価など、処理が集中する時期を月別に整理し、許容できる停止日時、同時利用者数、バッチ完了時刻、帳票出力数を要件にします。デジタル庁の非機能要件の標準では、基幹業務の停止可能日や時間帯が限られること、並行稼働は移行リスクを下げる一方でコスト負担が増える可能性が示されています（出典：デジタル庁「地方公共団体情報システム非機能要件の標準」、2025年）。

RFPには、標準仕様の対象業務と適合版数、ガバメントクラウドまたは利用予定基盤への対応、eLTAX・国税連携・金融機関・GIS・帳票・印刷との接続条件を記載します。加えて、現行ベンダーからのデータ抽出、新ベンダーによる変換、自治体による件数・税額・帳票の確認という移行の責任分界を明示します。「データ移行一式」とだけ書くと、外字変換や過年度データ、滞納案件、電子帳票の扱いが見積から漏れやすくなります。

保守については、税制改正、標準仕様の改版、帳票の変更、制度対応のリリース時期、問い合わせ窓口、障害時の一次切り分け、復旧目標、災害時の代替運用を質問します。個人番号を含む情報を扱うため、最小権限、多要素認証、暗号化、操作ログ、バックアップ、脆弱性対応、委託先監査、再委託管理、契約終了時のデータ返却・消去もRFPの評価項目に含めます。

候補を2〜3社に絞ったら、同じサンプルデータと業務シナリオでデモやPoCを依頼します。個人住民税の課税資料を取り込み、異動を反映し、通知書を出力し、納付データを消し込んで還付へ進む一連の流れを再現すると、機能一覧では見えない操作負担がわかります。固定資産税では土地・家屋・償却資産、滞納管理では折衝記録や差押、外部連携ではエラー時の再送や照合まで確認します。

PoCの目的は完成品を先に作ることではなく、標準機能で対応できる範囲、移行データの欠損、職員の入力負担、帳票の差分、ピーク時の処理を確かめることです。PoCの費用、期間、成果物、本番導入時に再利用できる設定、PoCで見つかった課題の扱いを提案書に書かせます。自治体側の確認者と判定基準を先に決めておくと、営業デモの印象だけで選ぶことを避けられます。

契約形態はどのように使い分けますか？

自治体向け税務システムでは、要件整理・調達支援、パッケージやクラウドの利用、個別開発、運用保守が一つの契約にまとまるとは限りません。要件が固まっていない工程を準委任、完成条件を定義できる開発工程を請負、継続的な機能提供をサービス利用契約、稼働後の問い合わせや改修を保守契約として分けると、責任と費用を整理しやすくなります。契約名よりも、何をいつまでに誰が実施するかを確認することが大切です。

準委任契約は、専門家としての調査、設計、助言、開発支援などの役務に対して対価を支払う契約です。現行システムの調査、標準仕様との差分整理、データ移行方式の検証、RFP作成支援、PoC、関係部署との合意形成など、進めながら論点が具体化する工程に向いています。成果物を置く場合も、成果物の完成だけを約束するのか、作業と報告を約束するのかを契約書と作業計画で分けます。

請負契約は、合意した成果物を完成させ、検査・検収する工程に向いています。画面、帳票、API、バッチ、データ移行ツール、マニュアル、テスト結果などを成果物として列挙し、受入条件を具体化します。例えば「通知書を出力できる」だけでなく、対象税目、印字項目、文字、件数、再出力、エラー処理、処理時間を試験項目にします。標準機能と追加開発の境界が曖昧なまま請負にすると、変更のたびに追加費用や納期延長が起こりやすくなります。

契約書や仕様書では、データの所有権と利用範囲、個人情報・個人番号の取扱い、再委託の条件、知的財産権、ソースや設計書の引き渡し、障害時の連絡と復旧、損害賠償、秘密保持、監査への協力、契約終了時の返却・消去を確認します。既存ベンダーと新ベンダーの双方が関わる移行では、抽出、変換、取込、照合、誤りの修正を誰が担うかを工程表に落とします。

保守契約では、法改正や標準仕様の改版を基本料金に含める範囲と、自治体固有の追加改修として別見積になる範囲を分けます。平日日中だけの問い合わせ対応で足りるのか、賦課や通知の繁忙期に延長対応が必要なのか、障害の重要度ごとの一次応答と復旧目標を決めます。安い月額だけで契約すると、制度改正や帳票変更のたびに予算確保が必要になるため、複数年の総額で比較します。

自治体向け税務システムの費用相場はどのくらいですか？

自治体税務システムだけを対象にした全国一律の公開市場統計は少ないため、以下は公開調達の実例とリサーチノートの類似システム相場から整理した目安です。人口、税目数、標準仕様対応、連携先、移行データ、帳票、並行稼働、クラウド利用、保守期間によって大きく変わります。したがって、レンジは予算検討の起点として使い、発注額を特定の金額で断定しないことが重要です。

既存パッケージの単一税目改修や制度対応では、500万円〜6,000万円程度が一つの参考レンジです。北九州市の公開契約では、令和6年度の個人市民税システム改修が538万7,800円、同年度の不足額給付対応が1,466万4,100円でした（出典：北九州市「随意契約結果一覧表」、2024〜2025年）。これは特定の自治体・業務・既存パッケージに関する契約額であり、自治体税務システム全体の平均ではありません。

制度対応の費用は、法改正の内容、影響する税目、帳票変更、外部連携、テスト、職員確認、リリース時期で変わります。現行パッケージのライセンス提供元しか改修できない場合は、北九州市の契約理由のように、既存仕様を理解する事業者へ継続委託する合理性が生じます。その場合も、将来の移行可否、データ抽出条件、設計書の開示、追加改修の単価を確認し、ロックインの影響を把握します。

税目追加、申告・収納連携、帳票刷新、部分的なクラウド移行、データクレンジングを含む場合は、2,000万円〜1.5億円程度のレンジを見込みます。複数税目のうち一部を刷新する案件でも、住民情報やeLTAX、金融機関、印刷、滞納管理と接続するなら、画面開発より移行・連携・総合テストの比重が大きくなります。対象税目が少ないから安いとは限らず、接続先と過年度データを基準に見積を読みます。

初期費用は、要件定義・現状分析、標準仕様との差分整理、設計・設定、追加開発、外部連携、データ変換、移行リハーサル、帳票・印刷、職員研修、稼働立会いに分解します。クラウド・機器・ライセンス・保守・法改正対応は初期費用と分け、年額と契約期間を示してもらいます。見積書の「一式」が多い場合は、作業量、前提条件、対象外、追加単価を質問します。

市区町村の複数税目刷新で、標準仕様対応、移行、並行稼働、研修、長期保守まで含める場合は、3億円〜15億円程度を予算検討の目安とします。大都市や都道府県の大規模案件では、10億円〜70億円超になる公開事例もあります。J-LISの税務情報基盤では、2025年のストレージ機器・ソフトウェアの賃貸借・保守の落札金額が1億1,327万4,480円でした（出典：地方公共団体情報システム機構、2025年）。

また、福岡市の税システム構築・保守業務委託は、複数年度の構築・保守を含む大規模な公開調達として、約69億9,505万円の契約規模が示されています（出典：福岡市「税システム構築・保守業務委託」入札結果、2025年）。J-LISや福岡市の金額は、自治体全体の相場ではなく、対象範囲・利用規模・期間を含む個別の調達額です。初期構築と保守、機器・クラウド、移行、制度改正を別々に比較し、5年から10年程度の総保有コストで判断します。

委託先の選定と見積比較で確認すべきポイントは何ですか？

委託先は、知名度や機能数だけでなく、自治体税務の経験、標準仕様への対応、移行を完了させる力、制度改正後の支援体制で選びます。提案書と見積書の評価を分けすぎると、安いが移行体制の弱い提案を選ぶおそれがあります。必須要件を満たしていることを前提に、価格、技術適合性、運用体制、リスク、自治体側の負担を同じ評価表で比較します。

実績を確認するときは、単に「自治体向けの導入実績がある」と聞くのではなく、人口規模、税目の範囲、共同利用か単独利用か、標準仕様の版数、移行対象データ、稼働後の保守年数を確認します。個人住民税だけの改修経験と、固定資産税・収納・滞納を含む税務全体の刷新経験は別物です。現行ベンダーからの移行、外字・名寄せ、並行稼働、繁忙期の障害対応について、自治体名を含む公開事例や説明可能な実績を求めます。

提案責任者、税務業務に詳しい業務担当、移行担当、インフラ・セキュリティ担当、稼働後の自治体専門SEが誰かも確認します。提案時の責任者と導入後の窓口が変わる場合は、引き継ぎ方法と体制を契約に含めます。再委託がある場合は、作業範囲、情報へのアクセス権、監督方法、障害時の連絡経路を明示してもらいます。

見積比較では、初期構築費だけでなく、要件定義、設計、設定、追加開発、連携、データクレンジング、移行リハーサル、本番移行、テスト、研修、稼働立会い、クラウド・機器、ライセンス、保守、法改正対応を同じ項目にそろえます。税込・税別、契約期間、作業場所、旅費、印刷費、データ抽出費、問い合わせ対応時間をそろえないと、安く見える見積が後から膨らみます。

特に比較しやすいのは、5年または契約予定期間の総額、年間の固定費、制度改正・標準仕様改版の追加費、データ抽出・返却費、障害対応費、ユーザーや帳票の追加単価です。各社に同じサンプルデータと同じ前提条件を渡し、対象外項目を記載させます。評価表では価格だけでなく、標準適合、移行方法、性能、セキュリティ、体制、自治体側の作業量、契約終了時の選択肢に点数を配分します。

既存パッケージのライセンス提供元しか改修できない、独自データ形式で抽出に費用がかかる、設計書が引き渡されない、APIが公開されていないという条件は、将来の選択肢を狭めます。継続利用が合理的な場合でも、データの所有権、標準形式での抽出、移行支援、仕様書の提供、他社切替時の費用をあらかじめ確認します。便利な共同利用やクラウドも、解約時にデータを戻せるか、別環境で復元できるかを確認して初めて比較できます。

移行リスクを下げるには、模擬移行を複数回行い、件数、税額、宛名、過年度、滞納案件、帳票の照合結果を記録します。新旧システムの並行稼働をする場合は、いつまで二重管理するか、差異が出た場合にどちらを正とするか、最終確認者は誰かを決めます。価格差が小さい場合は、移行・保守・復旧・データ返却の具体性が高い提案を優先すると、稼働後の予期せぬ負担を抑えやすくなります。

よくある質問（FAQ）

自治体向け税務システムの発注では、現行ベンダーとの関係、発注時期、費用の分け方、パッケージとスクラッチの判断について質問が多く寄せられます。ここでは、調達前に判断しやすいよう、直接的に回答します。

標準仕様に合わせられる業務が多く、法改正や保守を安定させたい場合は、標準準拠パッケージや共同利用型クラウドが有力です。条例や地域固有の運用が住民サービスに直結し、標準機能では対応できない場合は個別開発を検討しますが、独自部分を限定し、移行・改版・保守の費用まで含めて判断することが大切です。

継続発注には、現行仕様やデータ形式を理解している、制度改正を短期間で反映できる、既存ライセンスを利用できるという利点があります。一方で、単価や作業範囲が妥当か、標準仕様への適合が進んでいるか、将来のデータ返却や他社移行が可能かは別に確認します。少なくとも改修内容、工数、テスト、保守、追加単価を分解し、過去の契約や他社の参考提案と照合すると説明責任を果たしやすくなります。

作れます。まずは対象税目、現行システム、連携先、移行対象、希望時期、必須要件を整理し、概算見積の前提条件を提示します。予算を一つの上限額だけで伝えるのではなく、単一税目の改修、部分刷新、全体刷新の複数シナリオで提案を依頼すると、費用と機能の関係を比較しやすくなります。要件定義を先行して委託し、その成果物をもとに本開発の見積を更新する進め方もあります。

稼働希望時期から逆算し、現状調査、RFP、提案評価、契約、要件定義、開発・設定、移行、テスト、研修、並行稼働を並べます。年度更新や納税通知などの繁忙期直前に切り替えると、障害時の影響が大きくなるため、十分なリハーサルと復旧手順を確保します。大規模な複数税目刷新では、標準仕様の版数、予算要求、調達手続き、データ移行を含めて複数年度の計画にする必要があります。

まとめ

自治体向け税務システムの発注では、最初に対象税目、賦課・収納・滞納の業務範囲、外部連携、繁忙期、過年度データ、標準仕様との差分を整理します。そのうえで、標準準拠パッケージ、共同利用型クラウド、段階刷新、スクラッチ開発を比較し、自治体の運用体制と将来の改版対応に合う発注形態を選びます。

RFPには、標準仕様の対応版数、機能と帳票、eLTAX・国税連携・金融機関・GIS、移行方式、非機能要件、セキュリティ、保守、データ返却、自治体と委託先の責任分界を記載します。要件が変化する上流工程は準委任、完成条件を定義できる開発は請負など、工程に合わせて契約を分け、変更管理と検収条件を明確にします。

費用は、単一税目改修の数百万円規模から、部分刷新の数千万円〜1億円台、複数税目の刷新・長期保守の数億円、大規模調達の数十億円まで幅があります。公開調達額は個別事例として参照し、初期構築、移行、連携、テスト、クラウド・機器、保守、制度改正対応を分けて5年から10年程度の総額で比較します。最後に、同じサンプルデータで提案を検証し、標準化後も自治体職員が運用を続けられる体制を持つ委託先を選ぶことが、発注成功につながります。

▼全体ガイドの記事
・自治体向け税務システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。