固定資産税システム開発の発注/外注/依頼/委託方法について

固定資産税システムの発注は、現行業務を洗い出し、RFPで要件をそろえ、提案を比べ、移行テストまで順に進めると、税額と運用の確実性を高められます。

発注形態の選び方や要件の整理と契約、費用の見方、委託先の比較は、どれも税額の正確さと稼働後の運用に関わります。

▼全体ガイドの記事
・固定資産税システム開発の完全ガイド

固定資産税システムの発注で最初に整理すべき全体像

固定資産税システムを税務の中核機能、周辺機能、連携先の3層で示した図解
調達範囲は中核・周辺・連携先に分けて整理できます。

発注範囲は、税務の中核機能と、評価・地図・調査を支える周辺機能に分けて考えます。最初から一つにまとめず、標準仕様、自治体固有の業務、連携先をそれぞれ別の行にして一覧にします。

税務の中核機能の範囲(課税台帳から証明書まで)

税務の中核では、資産の記録から税額計算、根拠の説明、証明書発行までを一続きで扱います。

  • 台帳と異動:土地・家屋・償却資産、納税義務者、共有者の情報の管理。
  • 評価と税額:所有権移転などの異動の反映から、評価額・課税標準額・税額の計算まで。
  • 履歴と出力:軽減・特例・非課税・減免・更正・過誤納の履歴、通知書・証明書・名寄帳の出力。

担当者が税額の根拠を住民に説明できるよう、各種履歴も残しておきます。納税通知書や評価証明、公課証明、名寄帳を正しく出力できるかは、住民対応の品質に直結します。

連携先には住民情報、収納・滞納管理、eLTAXがあります。さらに、宛名・番号管理や登記情報、税務署、庁内の財務や申請管理とも連携します。

デジタル庁の標準仕様では、固定資産税の第10.0版が2026年2月27日に公開されています(出典:デジタル庁「データ要件・連携要件の標準仕様」、2026年)。標準仕様は改定があるため、RFPには準拠する版数と、改定時に保守で対応する範囲を明記します。

評価・GIS・所有者調査の標準機能との切り分け

周辺機能は、標準仕様に含まれるものと含まれないものを分け、調達方法も別に決めます。

  • 評価・現地調査:土地・家屋評価と現地調査の支援。
  • 地図・資料:地番図・家屋図・地籍図のGIS、航空写真、登記履歴。
  • 所有者調査:所有者不明土地や空き家の相続人を調べる支援。

標準仕様に含まれない機能も、業務で必要であれば省けません。税務本体と別に調達するか、連携する周辺システムとするかを決めます。

京都市は、地図と課税台帳を融合した課税支援システムを導入し、3年ごとの評価替えや制度改正への対応、複雑化したスクラッチツールの保守負担を見直しています(出典:両備システムズ「京都市 固定資産税課税支援システム導入事例」、確認日2026年)。また、千葉県流山市の事例では、家屋評価の手順を一つにまとめ、評価計算や訪問日程の管理を支援しています(出典:NTT-ATエムタック「千葉県流山市 事例」)。

こうした事例を参考に、自団体の課題を基準として、中核機能と周辺機能の境界を決めます。

固定資産税システムの発注形態の選択肢

発注形態は、標準準拠パッケージとクラウド・SaaSのほか、ハイブリッドとフルスクラッチに分けて比べます。制度改正や評価替えが続くため、各形態は自由度だけでなく、法令対応、データ移行、他社への移行のしやすさでも評価します。

標準準拠パッケージが向く自治体(制度対応と移行実績を重視)

標準準拠パッケージを選ぶなら、制度対応と移行後の支援体制を合わせて確かめておきます。

  • 標準機能:全国共通の税務処理、帳票、データ連携を土台にできる。
  • 制度対応:制度改正や標準仕様の改定に追随する負担を抑えやすい方式。
  • 導入・運用実績:稼働実績、移行テンプレート、並行稼働の方法、問い合わせ窓口。

特に、人口規模が大きく、既存データや複数税目との連携が多い自治体では、移行実績と支援体制を確かめておきます。

標準準拠であっても、家屋・土地評価やGIS、登記履歴、所有者調査まで含むとは限りません。そのため、提案書では適合状況と標準外機能を分け、追加開発と将来の保守費も別々に回答してもらいます。

デジタル庁は、固定資産税を含む20事務を標準化対象とし、原則2025年度までの移行を目指す方針を示しています。詳しくは、「地方公共団体の基幹業務システムの統一・標準化」で確認できます(出典:デジタル庁、2026年7月更新)。

クラウド・SaaSの運用負担と責任分界

クラウド・SaaSでは、どこまでを委託し、どこから先を自治体側が担うかを切り分けておきます。

  • 委託できる運用:サーバー更改、バックアップ、監視、障害対応の一部。
  • 利用環境:複数拠点からの参照や、ハードウェアを持たない運用。
  • 自治体側の条件:ネットワーク分離、LGWAN、個人情報、ログ、障害時の代替運用。

RFPでは、保管場所と暗号化、権限を指定します。さらに、バックアップ頻度と、復旧目標時間と復旧時点も定めます。停止時の連絡手順や契約終了時のデータ返却形式も、確認すべき項目です。

月額料金が低くても、初期設定や連携、帳票変更、利用者追加が従量課金なら、5年間の総額は変わります。さらに、制度改正や地図更新、データ出力の料金も、見積条件に含めます。

ハイブリッドの組み合わせと特殊業務の個別対応

自治体固有の評価ルールや業務ノウハウがある場合は、標準パッケージに評価やGIS、調査の機能を組み合わせる方法が現実的です。そのため、機能ごとに得意な委託先を分けられます。

  • 税額計算・共通宛名:標準パッケージに任せる範囲。
  • 家屋評価・地図業務:専門製品との組み合わせ。
  • 独自分析・住民向け画面:必要な範囲での追加開発。

フルスクラッチを検討するのは、特殊な評価業務や既存資産との密接な連携があり、業務を変えられない場合に限られます。自由度がある一方で、担当者が異動すると仕様が分からなくなるリスクもあります。

制度改正のたびに追加開発が必要となり、再調達時のデータ移行も難しくなり得ます。そのため、個別開発では、設計書やデータ辞書に加えて、テスト仕様書と運用手順書も納品物にします。

ポイント

発注形態は、制度改正への追随を任せたいか、業務を作り込む必要があるかで絞ると比べやすくなります。標準で足りない部分をどう補うかは、比較の前に決めておきます。

固定資産税システムの発注・外注の進め方

現行業務とデータの棚卸しからRFP作成、提案・見積比較、データ移行・受入テストへ進む図解
比較の前に現状と条件を揃える順序が分かります。

発注は、現行業務の洗い出しから始めます。そのうえで、標準仕様とのFit & Gapを確かめ、RFPを作って提案と見積を比べ、契約へ進みます。

契約後は、要件定義と開発・設定を経て、データ移行と受入テストに進みます。最後に、並行稼働を経て本番切替を行います。

ベンダーを呼ぶ前に、自団体の現状を整理しておく必要があります。課題や範囲が曖昧なままだと、各社の前提がずれ、金額や機能を比べられません。

現行業務とデータの担当課別の洗い出し

通常処理と例外処理を含む業務フローを作り、関係課と一緒にデータの品質も確かめます。対象には、償却資産申告、現地調査、地図更新も含まれます。

  • 業務フロー:登録から課税、納税通知、証明書発行までの書き出し。
  • 例外処理:評価替え、所有権移転、納税義務者の変更、共有、相続、非課税、減免、更正の洗い出し。
  • 関係者:資産税、情報政策、収納・滞納、住民情報、財政、地図・家屋評価の各担当者。

データは件数だけでなく、品質も確かめます。外字や旧字体、地番・家屋番号の揺れといった表記の問題を、サンプルで調べます。さらに、共有者や過年度情報、重複、欠損の有無も見ます。

地図座標や納税義務者コード、評価根拠の記録も、同じように見ておきます。移行できないデータを後から補うと、予定外の費用や切替の延期につながります。そのため、RFPの前に現行データのサンプルを抽出しておきます。

RFPで求める機能・データ・連携・非機能

RFPは、調達条件を機能・連携・非機能・移行後の責任に分け、各社へ同じ形で回答を求めます。

  • 前提・機能:背景、課題、対象業務・資産、利用者、ピーク処理量、時期、予算、必要機能の記載。
  • 外部連携:連携先、データ項目、方向、頻度、方式、エラー時の再送方法の指定。
  • 非機能:稼働時間、応答性能、同時利用者数、バックアップ・復旧、暗号化、脆弱性対応、ログ、権限、障害通知、保守時間の条件。
  • 移行・契約条件:標準仕様、周辺機能、移行計画、データ返却、再委託、制度改正費用の回答項目。

機能要件は、課税台帳と評価・税額計算、異動、申告に分けます。さらに、証明書や帳票、検索に加え、権限と監査ログも機能要件に含めます。

連携先は、住民情報や宛名、収納・滞納などです。さらに、eLTAXや登記、GIS、税務署も連携先になります。特定移行支援システムに該当する場合は、その移行計画も求めます。

移行リハーサルと税額突合(切替前)

切替前に代表資産を選び、現行と新システムの税額を突き合わせます。移行、研修、切戻しの条件も、そのときに固めておく必要があります。

  • 税額突合:土地・家屋・償却資産の評価額、課税標準額、軽減、都市計画税を含む税額の比較。
  • 例外の差分:共有、相続、所有者変更、非課税、減免、更正、評価替え、償却資産申告の各ケース。
  • 移行リハーサル:サンプル移行、全件移行、照合、再移行、切替判定を、複数回重ねる。

本番稼働の準備では、画面が動くかどうかだけでなく、業務が回るかを見ます。研修では、異動してきた職員が評価根拠を確認できるか、管理職が処理状況を把握できるかも試します。

年度当初の課税や評価替えの時期から逆算して、並行稼働の期間と障害時の手作業を決めます。バックアップからの復旧と切戻しの条件は、契約前に定めておきます。

ポイント

発注の前に現行業務とデータを洗い出し、RFPで条件をそろえておくと、各社の金額を同じ前提で比べられます。切替は、税額突合を切替前から繰り返した結果で判断します。

RFPの要件整理と契約形態

RFPの要件を標準要件、自治体固有要件、運用要件に分けた図解
3種類に分けると、標準仕様と独自業務、稼働後の条件を見渡せます。

RFPでは、画面の一覧だけでなく、業務の判断とデータの責任、稼働後の変更方法を明らかにします。制度改正や評価替えがあるため、初期構築と保守で、どこまでを誰が受け持つかを発注前に決めておきます。

標準要件・自治体固有要件・運用要件の三分類

要件を三つに分けると、標準準拠の範囲、自治体独自の業務、稼働後の運用条件を見分けられます。

  • 標準要件:標準仕様に従い、独自画面や計算方式の変更を抑えて、保守と再調達に備える。
  • 自治体固有要件:家屋評価、GIS、現地調査、所有者調査を、別製品との連携も含めて定義。
  • 運用要件:登録・承認・訂正・出力の権限、履歴閲覧者、帳票変更の申請方法。

RFPの回答欄は、「標準機能」「設定で対応」「追加開発」「別製品」「対応不可」から選べる形にします。そのため、各社が同じ尺度で回答でき、口頭説明への依存も減らせます。

要件定義の準委任と開発の請負

契約形態は、仕様がどこまで確定しているかに応じて、工程ごとに選びます。

  • 準委任:仕様が変わりやすい工程(要件定義、業務整理、現行調査など)。
  • 請負:成果物と完成条件が明確な設計、開発、移行作業。

すべてを請負にすると、曖昧な要件が変更要求として積み上がるおそれがあります。一方で、すべてを準委任にすると、納品物や完成条件が曖昧になるおそれがあります。

契約には、作業範囲や成果物、検収基準、支払条件を記載します。さらに、変更管理や知的財産権、再委託も盛り込みます。

秘密保持と個人情報の扱い、障害対応とSLAに加えて、損害賠償も契約に入れます。データ返却と契約終了時の移行支援は、制度改正や標準仕様改定への対応が保守に含まれるか、追加費用になるかを確かめておきます。業務を止める修正については、承認者を決めておく必要があります。

個人情報・監査ログ・データ返却の調達条件

個人情報の扱いやクラウド運用、移行のそれぞれで、保護とデータ返却の条件を調達要件に含めます。

  • アクセス管理:最小権限、重要操作の認証、通信・保存時の暗号化、操作・税額変更・出力ログの定め。
  • 委託先管理:再委託先のアクセス、権限の付与と削除、端末管理、脆弱性の報告期限。
  • クラウド・移行:障害時の復旧、バックアップ世代数、ログ保存期間、終了時のデータ返却と消去証明。

このため、移行では、変換プログラムや照合結果、エラー一覧を納品対象にします。修正履歴も対象に含めます。取込の可否だけでなく、現行との税額・件数・帳票の一致で成否を判定します。

ポイント

迷ったときは、要件を標準・自治体固有・運用の三つに分け、各社が同じ尺度で回答できるかで確かめます。契約は工程ごとに準委任と請負を使い分け、データ返却の条件も含めます。

固定資産税システムの費用相場と見積の内訳

費用は、自治体の人口や資産件数、データの品質で変わるほか、税務基幹の更改範囲やGIS・家屋評価・所有者調査の有無にも左右されます。

固定資産税単体の全国統一価格は公開されていません。ここで示すのは、公開された調達額と導入範囲から組み立てた、2026年時点の企画用の推定です。正式な予算や契約金額ではなく、RFPで比べる目安として使います。

初期費用の幅(支援システムの1,000万円台から大規模統合の8億円超)

固定資産税システムの費用と導入期間は、対象とする業務の範囲によって変わります。

  • 評価・GIS・所有者調査の支援SaaS等:初期1,000万〜5,000万円、3〜9か月程度。
  • 固定資産税の標準準拠パッケージ更改:5,000万〜2億円、9〜18か月程度。
  • 税務基幹の一体更改:住民税・法人住民税・軽自動車税・収納・滞納管理などを含み、2億〜6億円、18〜30か月程度。
  • 大規模な統合:GIS等を含め3億〜8億円超、24〜36か月程度。

データ移行や帳票、外部連携を含めるほど、同じ製品でも費用は上がります。研修や並行稼働についても、範囲が広がるほど費用は増えます。大規模自治体で、GIS、家屋評価、登記履歴まで統合すると、上記の範囲になることがあります。

港区の税務システム標準準拠パッケージ導入サービス委託は、令和7年度対応分の落札額が3億8,019万9,600円でした(出典:港区「税務システムにおける標準準拠パッケージの導入サービス委託」、2025年)。ただし、これは税務システム全体の金額で、固定資産税単体の相場ではありません。

要件定義・移行・連携・保守を開発費と分けた見積の内訳

初期費用とランニング費用を項目ごとに分けて、見積の前提をそろえます。

  • 導入・移行:要件定義、業務設計、開発、帳票、API・ファイル・GIS・登記連携、データ整備、移行の区分。
  • 稼働準備:テスト、研修、並行稼働、切替支援の項目化。
  • 継続運用:クラウド、ライセンス、保守、監視、バックアップ、制度改正、問い合わせ等の別。

一式で示された見積の場合は、想定人月と対象データ件数を確認します。さらに、連携本数やテストケース数、現地作業回数も見ます。

ランニング費用には、地図更新や帳票変更、脆弱性対応なども含まれます。推定のレンジは、支援SaaSが年500万〜2,000万円、固定資産税パッケージが年1,000万〜5,000万円です。

税務基幹一体型や大規模クラウドは、年3,000万〜1億円程度です。公開されている価格ではないため、ユーザー数や資産件数、保守時間、制度改正の扱いを揃えたうえで、正式な見積を取ります。

初期費用と5年間の総保有コスト

初期費用だけでなく、運用中の追加費用や品質要件も比べます。たとえば、地図更新や追加帳票、研修、障害復旧に加えて、脆弱性診断と再移行支援も対象に含めます。

  • 5年間の総額:保守、クラウド、制度改正、評価替え、データ修正などを含めた合計。
  • 追加単価:利用者追加や帳票変更の費用。
  • 品質確保:移行や税額突合、監査ログのほか、権限・バックアップ・訓練・受入テストの費用も削らない。

初期費用が低くても、利用者追加や帳票変更の単価が高いと、運用期間が長いほど差が広がります。そのため、費用を抑えたい場合は、通常業務と特殊業務を分け、信頼性に直結しない機能から段階導入を検討します。

予算要求では、初期構築費と移行・切替費を分け、年間運用費や制度改正対応費も別に示します。こうすると、費用の理由が関係者に伝わります。

ポイント

初期費用だけでなく、利用者追加や帳票変更の単価まで含めた5年間の総額で比べると、差の理由が分かりやすくなります。費用は対象業務の範囲で大きく変わるため、同じ前提で揃えて比べます。

委託先の選定と見積比較で確認するポイント

委託先は、導入件数よりも、固定資産税のどの業務に強いかで見極めます。税務中核と評価・GISでは必要な専門性が違い、家屋評価や所有者調査、移行・運用支援でも、求められる力は変わります。

営業資料だけでなく、設計・移行・保守を担う責任者から、類似団体での課題と対応方法を聞きます。

導入実績の確認範囲(業務範囲と成果)

自治体名や製品名だけでなく、導入の範囲と実作業の成果を確かめます。

  • 導入規模と範囲:稼働団体数、人口・資産件数、標準仕様の版数、対象業務。
  • 移行・稼働:データ量、並行稼働の期間、外字や過年度履歴の移行方法。
  • 運用成果:評価替えへの対応、障害時の復旧時間、稼働後の保守体制。

項目ごとに実例を確かめれば、広告的な実績と実務能力を見分けられます。

千葉県市原市では、所有者不明土地などの相続人調査をデジタル化し、部署間連携を進める事例が2026年6月に公表されています(出典:ビービーシー「2in1Win所有者調査管理システム導入事例」、2026年)。また、税務本体だけでなく、評価・GIS・所有者調査の専門会社も含めて、委託範囲を比べます。

提案評価と見積比較の配点

価格だけでなく、業務への適合性や標準仕様、移行計画を評価します。連携やセキュリティ、体制、保守も見たうえで、将来費用まで評価に含めます。そのうえで、評価の配点を事前に決めておきます。

  • 業務理解・機能適合:25点
  • 移行・テスト:20点
  • 連携・非機能、体制、保守・制度改正:各15点
  • 初期費用と5年間の総額:10点

価格の配点を上げすぎると、移行や保守が弱い提案が有利になります。そのため、各社に同じ見積書式を渡し、初期費用と追加開発、移行、テストを分けてもらいます。

研修や切替、年間保守も同じ書式で分けてもらいます。さらに、クラウドや制度改正、障害対応も、項目ごとに示してもらいます。

前提条件や対象外、上限件数を明示してもらいます。さらに、利用者数や現地作業回数、外部サービス料も示してもらいます。金額差が出た場合は、単価よりも作業範囲の違いを比べます。

ベンダーロックインと責任分界

データを取り出せない事態、追加開発の単価が不明な事態、標準外機能の保守担当や障害時の窓口が分かれる事態を、選定の段階で防ぎます。

  • データと費用:データ項目と出力形式、追加開発単価、終了時の返却・移行支援の取り決め。
  • 責任分界:標準外機能の保守担当と、障害時の一次窓口。
  • 再委託:会社名、担当範囲、アクセス権、障害時の連絡経路の把握。

APIやファイル連携の仕様書も、納品物に含めます。「標準機能」と説明された機能が実は追加開発だった、という認識違いを防ぐには、デモで実業務のシナリオを使って確かめるのが有効です。

デモでは、台帳検索や共有、相続、評価替えを実演してもらいます。さらに、減免や更正、証明書発行、地図連携も場面に含めます。

エラー訂正と監査ログも、同じ場で見てもらいます。匿名化した実データに近いサンプルを使い、担当職員が業務の抜けや追加費用の条件を確かめます。

ポイント

導入実績は業務範囲と移行・運用の成果まで確かめ、見積は各社に同じ書式で出させて比べます。評価では業務適合と移行の配点を厚くし、総額は前提を揃えてから判断します。

固定資産税システムの発注でよくある質問

発注で特によく問われるのは、システムの範囲と、標準化後に残す独自業務、費用と期間です。

固定資産税システムはパッケージとスクラッチのどちらがよいですか?

標準準拠パッケージを軸にし、自治体固有の評価・GIS・調査業務を設定や追加開発、別製品で補う形が、比べやすい方式です。

スクラッチは、業務上の必要性と、制度改正・保守・再移行費用を説明できる場合に検討します。

固定資産税システムの発注費用はいくらで導入期間はどれくらいですか?

支援システム追加は初期1,000万〜5,000万円、パッケージ更改は5,000万〜2億円、税務基幹一体更改は2億〜6億円程度が企画用の推定レンジです。

期間は支援システムで3〜9か月、固定資産税単体で9〜18か月、複数税目の一体更改で18〜30か月程度です。データ移行や評価替えの時期によって変わります。

RFPには固定資産税システムの何を書けばよいですか?

RFPには、背景と課題、対象業務、資産件数を書きます。さらに、利用者数や現行システム、データ移行の条件を入れ、帳票と外部連携も記載します。

標準仕様の版数や非機能、セキュリティ、テストを明記します。研修や保守、再委託は、データ返却と合わせて書きます。

各社には、「標準機能」「設定で対応」「追加開発」「別製品」「対応不可」の区分を同じ様式で回答してもらいます。見積の前提条件と対象外も明示してもらいます。

固定資産税システムの委託先は何社に相談すべきですか?

複数社へ同じRFPを渡し、税務中核、評価・GIS、所有者調査などの範囲を揃えて比較します。会社数よりも、実作業者や類似自治体での移行経験を確かめられるかどうかが重要です。

制度改正や評価替えへの対応、5年間の費用に加えて、障害時にどこまでを誰が受け持つかも確かめます。

固定資産税システムの発注・外注・依頼方法まとめ

標準準拠パッケージを出発点にし、評価やGIS、家屋評価、所有者調査は周辺機能として整理します。現行業務とデータを洗い出し、RFPで要件と前提をそろえます。

準委任と請負を工程に応じて使い分け、移行・テスト・保守を含む5年間の総額で委託先を比較します。

発注前に決める対象範囲と評価基準

税務中核や評価・GIS、家屋評価、所有者調査のどこまでを調達に含めるかを、発注前に決めます。連携や住民向け証明書を含めるかも、同じ段階で決めておきます。

評価項目には、標準仕様への適合や移行、業務適合を入れます。さらに、セキュリティや保守、データ返却も加えます。

価格だけでなく、評価基準を先に揃えておくと、提案会社ごとに前提の違う金額だけで競う状態を避けられます。

最初の一歩:現行データのサンプルと業務フローの作成

製品デモを頼む前に、業務フローや資産件数、連携先を一枚にまとめます。帳票や例外処理、データ課題も、同じ資料に書き加えます。

その資料をもとにRFPを作り、提案と見積、体制、契約条件を、同じ尺度で比べます。

固定資産税は住民への説明責任と年度当初の正確な課税を支える基幹業務です。安さだけでなく、移行後も制度と現場に対応できる委託先を選びます。

▼全体ガイドの記事
・固定資産税システム開発の完全ガイド

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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