自治体向け税務システムの発注は、業務範囲を整理し、標準仕様と照合してから、同じ条件で提案を比べると、長期運用しやすい委託先を選べます。
発注形態から委託先の選定まで、この順に考えると進めやすくなります。全体像は、自治体向け税務システム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・自治体向け税務システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
自治体向け税務システムの全体像と発注前の確認
自治体向け税務システムは、住民や事業者への賦課、収納、滞納管理を扱う基幹業務システムです。また、証明・通知、申告・照会も扱います。対象範囲を先に定めておくと、各社の見積条件をそろえやすくなります。
税目・機能・外部連携の範囲整理
発注する業務の範囲は、賦課、収納、滞納、帳票、証明、統計のどこまでかを決めておきます。税目は、個人・法人住民税、固定資産税、軽自動車税が中心です。収納管理、滞納管理、地方税共通も、基本の範囲に入ります。
- 追加対象：国民健康保険税、税務窓口、申告支援、GIS連携
- 税務機能：名寄せ、課税資料取込、税額計算、更正・決定、土地・家屋・償却資産の評価、納税通知書・督促状、消込・還付・充当、滞納者・財産・折衝・差押の管理
- 接続先：住民基本台帳、eLTAX、国税、金融機関、口座振替、地方税お支払サイト、eL-QR、印刷事業者、GIS
対象の範囲を決めないまま見積を取ると、会社ごとに前提が変わり、金額を比べられなくなります。
2026年の標準仕様と独自要件の切り分け
標準仕様と独自要件は、適合版数と個別対応の要否を分けて整理しておきます。
- 標準仕様の対象：個人住民税、法人住民税、固定資産税、軽自動車税、収納管理、滞納管理、地方税共通
- 標準仕様の版数：2026年2月27日付の第10.0版が掲載されています（出典：デジタル庁「データ要件・連携要件の標準仕様」、2026年）。
- RFPの記載：提案システムの適合版数と、将来の改版に追随する契約範囲の明記
- 独自要件：独自帳票や条例に基づく運用と、標準機能との差分の記録
差分は、「制度上必須」「自治体固有の運用」「これまで続けてきた慣行」の三つに分けると、優先順位を決めやすくなります。
標準化できる業務を個別に開発すると、改版のたびに費用とテストが生じます。一方で、条例や住民サービスに直結する差分は、理由と代替案を残して判断します。
発注形態の選び方
発注形態には、標準準拠パッケージ、共同利用型クラウド、段階刷新、スクラッチ開発があります。
標準仕様に合わせられる業務が多いほど、パッケージや共同利用が候補になります。一方で、地域固有の業務が多いほど、個別開発の比重が高まります。
最初から一つの方式に決めつけず、税目ごとに比べます。また、標準機能を基本にし、差分を設定・API・小規模改修で補う構成は、将来の改版にも対応しやすい考え方です。
標準準拠パッケージの発注
標準準拠パッケージは、基本機能や制度改正、帳票を一定の型で導入できます。権限や操作ログも、同じ型に含まれます。
業務を標準機能に寄せられれば、要件定義と開発を短くでき、保守の見通しも立てやすくなります。
適合状況は、税目ごとの対応版数、標準外機能、帳票差分を確かめます。連携方式と移行実績も、合わせて見ます。また、デモでは実際の業務を再現し、パッケージ名だけで判断しないようにします。
共同利用型クラウドの発注
共同利用型クラウドは、共通化の効果と自団体に必要な条件を確かめたうえで選びます。次に、他自治体と共通化できる業務と、自団体だけに必要な差分を分けます。
- 共同利用の効果：複数自治体が基盤やアプリを共用し、運用や制度改正対応の負担を分け合う仕組みです。
- 公開事例：NECの豊橋市・岡崎市の共同利用型クラウド
- 利用料の範囲：法改正、帳票変更、ユーザー追加、データ抽出、障害復旧、設定変更が料金に含まれるかの確認
- 安全性と解約：データ保管場所、権限、監査ログ、バックアップ、返却条件の扱い
NECは岡崎市について、単独利用と比べると、税総合システムの開発費と運用保守費を5年間で約5.5億円、45％削減できると見込みました（出典：NECプレスリリース、2013年）。
この例は、共同利用の効果を考える参考事例で、全自治体に当てはまる相場ではありません。ガバメントクラウドやLGWAN-ASPも、安全性の評価とあわせて、データ保管場所や返却条件を確かめます。
段階刷新・スクラッチ開発の発注
収納や証明など切り出しやすい領域から段階刷新すると、移行リスクと職員の学習負荷を分散できます。一方で、旧システムとの並行稼働、二重入力、連携仕様の調整が必要になります。
スクラッチ開発は、独自業務を柔軟に実現できます。ただし、標準仕様の改版、税制改正、担当者交代後の保守要員、障害復旧を、自治体と開発会社が長く担うことになります。
判断では、人口規模だけでなく税目数とデータ品質を見ます。加えて、運用体制、標準化期限、独自運用の重要性も確認します。
RFPと要件整理の進め方
RFPは機能一覧だけでなく、背景・目的、対象税目、現行業務をそろえる文書です。連携先や移行対象、保守期間などの条件も、同じ形式で示します。
発注者側が目的と制約を整理したうえで、委託先に実現方式、リスク、必要な体制を示してもらうと、価格だけに偏らず比べられます。
現行業務・データ・繁忙期の棚卸し
業務とデータの棚卸しでは、関係者と処理の流れを洗い出します。移行リスクや繁忙期の制約も、あわせて確認しておきます。
- 関係者：税務課、収納・滞納担当、窓口、情報政策課、財政担当、印刷・委託先
- 業務の流れ：課税資料取込、異動、税額計算、更正、通知書、納付取込、消込、還付、滞納整理、証明書発行
- 記録項目：担当者、処理時期、帳票、連携ファイル、手作業
- 移行リスク：外字、旧住所、宛名統合、欠損値、重複データ、保存年限
- 繁忙期の要件：停止可能日時、同時利用者数、バッチ完了時刻、帳票出力数
繁忙期は月別に整理し、処理が集中する時期を特定します。たとえば、住民税の賦課・通知・申告・年度更新や、固定資産評価の時期が該当します。
デジタル庁の標準は、基幹業務の停止可能な日時や時間帯が限られる点を示しています。並行稼働については、移行リスクを下げる一方で、費用負担が増える可能性も示されています（出典：デジタル庁「地方公共団体情報システム非機能要件の標準」、2025年）。
RFPに記す標準仕様・移行・責任分界
RFPでは、標準仕様への適合、接続条件、移行・保守の責任分界を具体的に示します。
- 適合・接続：標準仕様の対象業務・版数、利用基盤、eLTAX、国税、金融機関、GIS、帳票、印刷との接続条件
- 移行の分担：現行ベンダーの抽出、新ベンダーの変換、自治体の件数・税額・帳票確認
- 保守と障害対応：制度改正、標準改版、帳票変更、リリース時期、問い合わせ、一次切り分け、復旧目標、災害時の代替運用
- 情報保護：最小権限、多要素認証、暗号化、操作ログ、バックアップ、脆弱性対応、委託先監査、再委託管理、契約終了時の返却・消去
「データ移行一式」とまとめると、外字、過年度データ、滞納案件、電子帳票が見積から漏れやすくなります。個人番号を扱うため、情報保護の実施状況も、提案内容と契約の両方で確かめます。
同じ業務シナリオとサンプルデータによる提案比較
候補を2〜3社に絞り、同じサンプルデータと業務シナリオで、デモやPoCを依頼します。
- 個人住民税：課税資料取込、異動反映、通知書出力、納付消込、還付まで再現
- 業務別の確認：固定資産税の土地・家屋・償却資産、滞納管理の折衝記録・差押、外部連携のエラー再送・照合
- PoCの確認範囲：標準機能、データ欠損、職員の入力負担、帳票差分、ピーク時処理
- 提案書：費用、期間、成果物、本番で再利用できる設定、発見課題の扱い
- 評価基準：確認者と判定基準を先に決め、営業デモの印象だけで選ばない
業務の流れを再現すると、機能一覧では見えない操作の負担がわかります。PoCの目的は、完成品を先に作ることではなく、実業務への適合性を確かめることです。
契約形態の使い分け
要件整理・調達支援、パッケージやクラウドの利用、個別開発、運用保守は、それぞれ別の契約になる場合があります。
要件が固まらない工程は準委任、完成条件を定義できる開発は請負に分けると、整理しやすくなります。同じように、継続して使う機能はサービス利用、稼働後の支援は保守契約として扱えます。
契約名で決めるより先に、誰が何をいつまでに実施するかを確かめます。
準委任契約による要件整理・調査・設計
準委任契約は、調査、設計、助言、開発支援といった役務に対して対価を支払う契約です。
現行調査や標準仕様との差分整理、RFP作成支援など、進めながら論点が具体化する工程に向きます。移行検証やPoC、部署間の合意形成も、進めながら論点が固まる工程です。
成果物を設ける場合は、完成を約束するのか、作業と報告を約束するのかを、契約書と作業計画で分けて書きます。
請負契約の完成条件と検収
請負契約は、合意した成果物を完成させ、検査・検収する工程に適しています。成果物は、画面、帳票、API、バッチなどに分けて挙げ、受入条件を具体化します。移行ツール、マニュアル、テスト結果も、受入の対象に挙げておきます。
通知書なら、対象税目、印字項目、文字、件数を試験項目にし、再出力、エラー処理、処理時間も確かめます。特に、標準機能と追加開発の境界が曖昧なまま契約すると、変更のたびに追加費用や納期延長が生じるおそれがあります。
データ・変更・保守の責任分界と契約書の記載
契約書では、データの所有権と利用範囲、個人情報・個人番号の扱いを定めます。再委託や知的財産権の取り決めも、あわせて書いておきます。ソースや設計書の引き渡し、障害対応、損害賠償も、同じ契約書で扱います。
秘密保持、監査、契約終了時の返却・消去も、契約書に残します。複数のベンダーが関わる移行では、抽出や変換、照合などの担当を工程表に示します。
保守では、法改正や標準改版を基本料金に含む範囲と、自治体固有の追加改修を分けて考えます。問い合わせ時間や繁忙期の延長対応、障害の重要度別の一次応答と復旧目標も決めておきます。月額だけでなく、制度改正や帳票変更を含めた複数年の総額で比べます。
自治体向け税務システムの費用相場
全国一律の公開市場統計は少ないため、ここに挙げる費用レンジは、2026年時点で公開調達例と類似システムの相場から整理した目安です。
金額は、人口や税目の数、標準仕様への対応、連携や移行の範囲によって変わります。帳票、並行稼働、クラウド、保守期間によっても変わります。レンジは予算検討の出発点とし、特定の金額で発注額を決めつけないようにします。
単一税目の改修・制度対応の目安（500万円〜6,000万円）
単一税目の改修は、公開契約の幅と制度対応の条件をあわせて見積もります。
- 参考レンジ：既存パッケージの単一税目改修・制度対応は500万円〜6,000万円程度
- 北九州市：令和6年度は個人市民税改修538万7,800円、不足額給付対応1,466万4,100円（出典：北九州市「随意契約結果一覧表」、2024〜2025年）
- 費用の変動要因：法改正、対象税目、帳票、連携、テスト、職員確認、リリース時期
北九州市の金額は、特定の自治体の個別業務と既存パッケージに関する契約額で、全体の平均を示すものではありません。
現行パッケージのライセンス提供元しか改修できない場合、仕様を理解する事業者への継続委託が合理的なこともあります。その場合でも、将来の移行に備えて、データ抽出の条件と設計書の開示、追加改修の単価を確かめます。
部分刷新・連携・移行の目安（2,000万円〜1.5億円）
部分刷新では、連携や移行を含む初期費用と、継続費用を分けて見積もります。
- 参考レンジ：税目追加、連携、帳票刷新、部分クラウド移行、データ整備は2,000万円〜1.5億円程度
- 移行・連携：住民情報、eLTAX、金融機関、印刷、滞納管理との接続や総合テストを確認
- 初期費用：要件定義、現状分析、標準との差分、設計・設定、開発、連携、変換、移行、帳票、研修、稼働立会い
- 継続費用：クラウド、機器、ライセンス、保守、法改正対応の年額と契約期間
対象税目が少なくても、安くなるとは限りません。そのため、見積は接続先と過年度データを基準に読みます。
見積に「一式」が多い場合は、作業量や前提条件を質問します。対象外の範囲や追加単価も、あわせて尋ねます。
複数税目の刷新・長期保守の公開事例（3億円〜70億円超）
大規模刷新の公開額は、自治体の規模や契約範囲が異なるため、相場と混同しないようにします。
- 市区町村の刷新：標準対応、移行、並行稼働、研修、長期保守を含め3億円〜15億円程度
- 大規模案件：大都市・都道府県では10億円〜70億円超の公開事例
- J-LISの落札額：税務情報基盤の機器・ソフトウェア賃貸借・保守は、2025年に1億1,327万4,480円（出典：地方公共団体情報システム機構、2025年）
- 福岡市の契約：税システム構築・保守の複数年度契約は約69億9,505万円（出典：福岡市「税システム構築・保守業務委託」入札結果、2025年）
いずれも、対象範囲・規模・期間を含んだ個別の金額で、自治体全体の相場ではありません。判断の際は、費用を項目ごとに分けます。対象は、初期構築と保守、機器やクラウド、移行、制度改正です。5年から10年程度の総保有コストで見ます。
委託先の選定と見積比較のポイント
委託先は、知名度や機能数だけでなく、自治体税務の経験と標準仕様への対応で選びます。移行力や制度改正後の支援体制も、あわせて見ます。
提案と見積の評価を分けすぎると、安くても移行体制の弱い委託先を選ぶおそれがあります。
必須要件を満たすことを前提に、価格と技術適合性、運用体制を同じ評価表で比べます。リスクや自治体側の負担も、同じ表で扱います。
自治体税務・標準化・移行の実績
実績を確かめるときは、規模や対象範囲をそろえ、導入後の体制まで見ます。
- 導入条件：人口規模、税目、共同・単独利用、標準仕様の版数、移行対象、保守年数
- 実績の内容：個人住民税の改修か、固定資産税・収納・滞納を含む刷新かを区別
- 移行経験：現行ベンダーからの移行、外字・名寄せ、並行稼働、繁忙期の障害対応
- 担当体制：提案責任者、税務業務、移行・基盤・セキュリティ、稼働後の自治体専門SE
自治体名を含む公開事例や、説明できる実績を求めます。導入後に窓口が変わる場合は、引き継ぎを契約に含めておきます。
再委託がある場合は、作業範囲、情報へのアクセス権、監督方法を明示し、障害時の連絡経路も示してもらいます。
初期費用・保守・自治体負担の見積比較
各社の見積は、費目と契約条件をそろえて比べます。総額と評価軸も、同じ条件で並べます。
- 費目：要件定義、設計・設定、開発、連携、データ整備・移行、テスト、研修、立会い、機器、ライセンス、保守、法改正
- 契約条件：税込・税別、期間、作業場所、旅費、印刷・抽出費、問い合わせ時間
- 総額と単価：5年または契約期間の総額、年間固定費、改版追加費、返却費、障害対応費、ユーザー・帳票の追加単価
- 評価軸：標準適合、移行、性能、セキュリティ、体制、自治体作業量、契約終了時の選択肢
同じサンプルデータと条件を各社へ渡し、対象外の項目を明記してもらいます。条件がそろっていないと、安く見えた見積が後から膨らむことがあります。
ベンダーロックインと移行失敗のリスク
ロックインと移行の懸念は、契約終了後の選択肢、データの可搬性、移行検証の方法に分けて確かめます。
- 将来の選択肢：特定提供元しか改修できない、独自形式の抽出に費用がかかる、設計書が渡らない、APIが非公開などの条件
- データの可搬性：共同利用・クラウドも含め、所有権、標準形式での抽出、移行支援、仕様書、他社切替費、解約後の返却・別環境での復元
- 移行検証：複数回の模擬移行で件数、税額、宛名、過年度、滞納案件、帳票を照合
- 並行稼働：二重管理の期限、差異時の正データ、最終確認者の決定
ただし、継続利用が合理的な場合もあります。価格差が小さければ、移行・保守・復旧・返却条件が明確な提案を選ぶことで、稼働後の予期せぬ負担を抑えられます。
よくある質問（FAQ）
発注の際には、現行ベンダーとの関係や時期、費用の分け方などの質問が多く寄せられます。パッケージとスクラッチのどちらを選ぶかも、よく尋ねられます。調達の前に判断しやすいよう、質問ごとに答えます。
自治体向け税務システムはパッケージとスクラッチのどちらがよいですか？
標準仕様に合わせられる業務が多く、法改正や保守を安定させたい場合は、標準準拠パッケージや共同利用型クラウドが有力です。
条例や地域の運用が住民サービスに直結していて、標準機能では対応できない場合は、個別開発を検討します。
判断では、独自部分を限定したうえで、移行・改版・保守費用まで含めて見ます。
現行ベンダーに継続して発注する場合も比較は必要ですか？
継続発注には、現行の仕様やデータ形式を理解していること、制度改正をすばやく反映できること、既存ライセンスを使える利点があります。一方で、単価と作業範囲、標準仕様への適合、将来の返却や他社移行は、別に確かめる必要があります。
改修内容や工数を、テスト、保守、追加単価に分けます。そのうえで、過去の契約や他社の参考提案と照合すると、説明責任を果たしやすくなります。
予算が決まっていない段階でもRFPを作れますか？
予算が決まっていなくても、RFPは作れます。対象税目と現行システム、連携先や移行対象を整理し、希望時期と必須要件を示します。そのうえで、概算見積の前提条件を明らかにします。
予算は一つの上限額にせず、単一税目改修、部分刷新、全体刷新の複数案で依頼すると、費用と機能を比べやすくなります。
また、要件定義だけを先に委託し、その成果物をもとに本開発の見積を更新する方法もあります。
税務システムの発注はいつから準備すればよいですか？
稼働の希望時期から逆算し、現状調査とRFP、提案評価と契約を経て、要件定義から並行稼働までの工程を計画します。
年度更新や納税通知の直前に切り替えると、障害が起きた際の影響が大きくなります。そのため、十分なリハーサルと復旧手順を確保しておきます。
大規模な複数税目の刷新では、複数年度の計画が必要です。標準仕様の版数や予算要求、調達、データ移行も、その計画に含めます。
まとめ
発注前には、対象税目と賦課・収納・滞納の範囲、連携先を整理します。繁忙期や過年度データ、標準仕様との差分も、あわせて押さえておきます。自治体の運用体制と改版対応に合わせて、発注形態を選びます。
RFPと契約での比較条件
RFPには、標準仕様の版数と機能・帳票を記載します。eLTAX、国税、金融機関、GISとの接続も、同じ書面に記載します。移行、非機能、セキュリティ、保守、データ返却、責任分界も、あわせて書いておきます。
上流工程は準委任、完成条件を定義できる開発は請負など、工程に合わせて契約を分けます。そのうえで、変更管理と検収条件を明確にします。
長期の総額と移行品質による選定
費用は対象範囲と期間をそろえて総額で比べ、公開調達額は個別事例として扱います。
- 単一税目改修：数百万円規模
- 部分刷新：数千万円〜1億円台
- 複数税目刷新：数億円規模
- 大規模調達：数十億円規模
- 比較項目：初期構築、移行、連携、テスト、クラウド・機器、保守、制度改正を分け、5年から10年程度の総額で比較
つまり、同じサンプルデータで提案を確かめ、標準化後も職員が運用を続けられる体制を持つ委託先を選ぶことが、発注の成功につながります。
▼全体ガイドの記事
・自治体向け税務システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。