固定資産税システム開発の完全ガイド

固定資産税システムは、税務本体と評価・GISなどの周辺機能に分けて整理し、標準仕様と自治体固有の要件も分けて考えると、必要な機能と導入方法を判断しやすくなります。

機能と種類、開発の進め方、費用相場、選定・発注、運用の注意点を節ごとに扱います。詳細は関連記事で読めます。

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

固定資産税システムの概要

周辺機能を独立させる構成も選べます。

固定資産税システムは、資産を把握し、根拠を確認できる状態で税額を計算する、自治体向けの税務基盤です。さらに、住民向けの通知や証明書の作成にもつなげます。

業務範囲は自治体によって異なるため、税務本体と評価・地図・登記などの周辺機能を分けて考えると、要件を整理しやすくなります。

税務本体が担う業務

税務本体は、土地・家屋・償却資産の課税台帳と、納税義務者、共有者、所有権の異動を管理します。評価額と課税標準額も対象で、軽減・特例や都市計画税も扱います。

例外履歴：納税義務者の変更、非課税、減免、更正、過誤納の経緯を追えるようにします。
説明根拠：評価根拠、処理日時、承認者を監査ログに残します。
帳票・連携：証明書や通知書の出力と、収納・滞納、宛名、住民情報、電子申告との連携。

帳票の例は、課税台帳、評価証明、公課証明などです。このほか、名寄帳や納税通知書も挙げられます。本体に含める範囲は調達方針で変わるため、データの発生元と利用先を一覧にして決めます。

評価・GIS・登記などの周辺機能

周辺機能には、家屋と土地の評価、地図の確認、登記履歴との連携があります。自治体の業務によっては、本体と別のシステムやサービスに分けて持つことになります。

家屋評価：現地調査、評価資料、家屋番号、用途、構造、床面積を扱います。
土地評価・GIS：地番図、航空写真、地籍図、路線価を参照し、地図上で課税対象や未反映資産を確認します。
登記連携：登記情報や履歴を使い、所有権移転や相続に伴う更新漏れを減らします。

千葉市の標準化計画では、家屋評価や固定資産業務支援GIS・登記履歴を、税務システム本体と別に整理しています。登記・課税データ連携と概要調書も、税務システム本体とは別に整理しています。

この区分は、標準仕様と自治体固有業務をどう組み合わせるかを考える際の参考になります（出典：千葉市「自治体情報システムの標準化に関する全体計画書」）。

固定資産税システムの種類と選び方

選択肢には、標準準拠パッケージとクラウド型、オンプレミス型、スクラッチ開発があり、本体と支援システムを組み合わせる構成もあります。同じ観点をそろえて比べると、方式の違いが見えてきます。

標準仕様への適合：対象版や、更新が保守契約に含まれるかを確認します。
自治体固有の評価業務：家屋評価、地図、登記履歴、所有者調査、独自帳票をどう扱うかを見ます。
移行難易度：既存データの品質と移行対象の違い。
制度改正への追随：制度改正に伴う改修の範囲と費用。

標準準拠パッケージを中心にする方式

標準準拠パッケージの特徴と、周辺機能で確かめるべき点を先に見ておきます。

標準仕様への適合：国の機能・データ・連携要件に沿った製品です。
更新と導入知見：制度改正や仕様更新に追随しやすく、他自治体の知見や移行テンプレートも活用できます。
周辺機能：家屋評価、地図、登記履歴、所有者調査、独自帳票は、必ずしも自動では解決しません。
構成の確認：周辺サービスとして追加するか、別システムと連携するかは、構成図と費用内訳で確かめます。

固定資産税のデータ要件・連携要件は、デジタル庁が公開しており、2026年2月27日に第10.0版として公開されています（出典：デジタル庁「データ要件・連携要件の標準仕様」）。

クラウド・オンプレミス・スクラッチの違い

方式によって運用の負担や対応できる要件が違うので、特徴と確認事項を分けて比べます。

クラウド・SaaS：サーバー更改、バックアップ、監視を自前で抱えにくく、複数拠点で使いやすい方式です。
オンプレミス：庁内ネットワークや運用ルールを活かしやすい方式です。
スクラッチ：特殊な評価ロジックや既存資産との密接な連携がある場合に検討します。

クラウドでは、障害時の業務継続やデータの保管場所を、契約と仕様書に明記します。ログの保存期間、契約終了時の返却、再委託先のアクセスも、明記しておく項目です。利用料は月額または年額なので、比べるときは5年程度の総保有コストで見ます。

オンプレミスでは、機器の更新や災害対策、バックアップ設備、職員の運用負担を見込みます。スクラッチの場合は、制度改正のたびに改修が必要になりやすく、異動後に保守が属人化するリスクもあります。

方式を決める前に、特殊要件が差別化につながるのか、標準機能と周辺連携で代えられるのかを検証しておきます。

ポイント

方式を選ぶときは、制度改正への追随と、自治体固有の評価業務を標準品でどこまで賄えるかを先に確かめると、候補を絞りやすくなります。

固定資産税システム開発の進め方

切替日は年度当初課税から逆算します。

開発は、要件定義、方式選定、移行設計の順で進めます。その後、構築・連携、テスト、研修を経て、並行稼働と切替に至ります。切替日は年度当初課税から逆算して決めるとともに、評価替えや償却資産申告、決算、議会、予算要求の時期も見ておきます。

要件定義とFit & Gap分析

要件定義では、業務フローに沿って、対象の業務とデータの流れを洗い出します。

土地・家屋・償却資産の業務と、納税義務者、共有、評価替え、異動、減免の扱いを洗い出します。
証明書や帳票、GISに加え、登記、電子申告、収納、権限、監査ログも対象に含めます。
データごとに、更新時期、担当者、根拠、出力先の帳票を確かめます。
標準仕様の範囲内か、標準化の対象外の周辺機能か、自治体固有の要件かに分けます。
標準に合わせる機能と、残す差分を決めたうえで、理由、代替案、将来の保守費を記録します。

業務部門と情報政策部門の認識がそろわないまま進むと、後工程で追加開発が膨らみやすくなります。

データ移行と外部連携の設計

移行と連携は、対象データの品質を確かめる段階と、接続後に業務を確かめる段階を分けて進めます。

課税台帳に加えて、過年度の評価額、異動履歴、納税義務者、共有者も移行対象に入れます。
地番・家屋番号、外字、地図座標、評価根拠は、移行の前に確かめておきます。
空欄、重複、桁ずれ、独自コード、判読困難な外字は、変換できない場合があります。
早い段階でサンプル移行を行い、件数や代表ケースの画面、帳票を照合します。
住民情報や宛名、収納・滞納との連携に加え、登記済通知、電子申告、GIS、帳票とも連携します。
連携方式、更新頻度、エラー時の再送、障害時の手作業に加え、どこまでを誰が受け持つかを決めます。

実データに近い条件での確認も欠かせません。本体と家屋評価・GISを別システムにする例もあるため、連携の仕様を明確にしておきます。

税額突合・受入テスト・切替

受入テストから切替までの間に、税額が一致しているかと、本番時の役割や手順を確かめます。

通常の土地・家屋・償却資産に加え、評価替え、所有権移転、相続、共有のケースも試します。
非課税や減免、更正、過誤納、償却資産申告、納税義務者の変更のケースも用意します。
評価額、課税標準額、税額、通知書について、現行と新システムの結果を突き合わせます。
差異が制度上のものか、移行や計算ロジックの不備によるものかを説明できるようにします。
本番前に、全件移行や復旧、権限、連絡網、暫定の手作業、職員研修をリハーサルします。
並行稼働の時期は、確定処理を行うシステムと、差異を判定する担当者を決めておきます。
年度当初課税に必要な準備期間から、切替日を逆算します。

▶ 詳細はこちら：固定資産税システム開発の進め方

ポイント

進め方を判断するときは、移行とテストの期間を年度当初課税に間に合う範囲へ収められるかを最初に見ておくと、無理のない計画を立てやすくなります。

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

導入範囲の拡大に応じて費用幅も広がります。

全国共通の公開価格表はないため、ここに示す金額は、自治体向けパッケージの範囲と公開調達額、移行・GIS・評価業務の複雑さをもとにした推定です。

費用は、人口、土地・家屋・償却資産の件数、税目の範囲によって変わります。さらに、データ品質、連携数、標準化の状況も費用を左右します。そのため、予算要求では初期の仮説として扱い、同じ条件で見積を比べます。

導入パターン別の初期費用と期間

初期費用と期間は、導入する機能や対象範囲によって変わります。まず、パターンごとの目安を見ておきます。

支援システム追加：評価・GIS・所有者調査などを追加する場合は、1,000万〜5,000万円、3〜9か月が目安です。
固定資産税パッケージ更改：標準準拠パッケージの更改なら、5,000万〜2億円、9〜18か月程度です。
複数税目の一体更改：住民税、法人住民税、軽自動車税、収納・滞納管理まで含めると、2億〜6億円です。
大規模な周辺機能統合：GIS、家屋評価、登記履歴を大規模に統合すると、3億〜8億円超になることがあります。

東京都港区の「税務システムにおける標準準拠パッケージの導入サービス委託（令和7年度対応分）」では、落札金額が3億8,019万9,600円でした。この金額は税務システム全体の導入サービスに対するもので、固定資産税単体の価格としては扱えません。複数税目を含む標準化案件の規模感をつかむための数字です（出典：港区「令和7年度入札・見積経過調書」）。

見積に含めるべき費用項目

見積は、初期費用、移行費、運用費に分けて、対象範囲と金額の前提を確認します。

初期費用：企画・要件定義、Fit & Gap、環境構築、設定・追加開発、帳票、連携、テスト、研修、並行稼働、切替支援。
移行費：抽出、変換、クレンジング、サンプル・全件移行、照合、リハーサル。対象年度や件数、外字、地図、過去履歴も、見積に明記します。
運用費：保守、制度改正、クラウド、監視、バックアップ、問い合わせ、地図更新、帳票改定、評価替え、脆弱性対応。

年額で見ると、支援SaaSは500万〜2,000万円、固定資産税パッケージは1,000万〜5,000万円が推定レンジです。

税務基幹一体型や大規模クラウドは年3,000万〜1億円程度です。そのうえで、5年分の利用・保守費と、契約終了時のデータ返却費も比べます。

▶ 詳細はこちら：固定資産税システム開発の見積相場・費用

ポイント

費用は初期費用だけでなく、移行、保守、制度改正、クラウド利用料まで含めた総額で比べます。条件をそろえずに金額を並べても、比較にはなりません。

固定資産税システムの開発会社・サービスの選び方

導入件数に加えて、税務本体や家屋・土地評価、GIS、所有者調査など、どの領域が得意かを確かめます。RFPの回答様式をそろえると、機能、移行、連携、保守、費用、体制を同じ条件で比べられます。

比較すべき五つの観点

候補ごとの得意分野と契約後の対応力は、同じ観点をそろえて見極めます。

実務経験：土地・家屋・償却資産、評価替え、減免、更正、共有、相続、償却資産申告、証明書の実績。
標準化対応：標準仕様の版、適合状況、標準外機能の扱い。
移行・連携：データ診断、外字・地図変換、過去履歴、登記・電子申告・住民情報との連携。
保守体制：制度改正、評価替え、帳票改定、脆弱性対応、障害時の復旧目標。
データの出口：契約終了時の標準形式での返却と、他システムへの移行。

実績は業務単位で確かめ、移行や連携については、担当者と作業回数まで説明できるかを見ます。保守の条件とデータ返却の条件も、契約に落とし込めるかを確かめます。

提案書とデモで確認する方法

提案とデモの場では、実際の業務シナリオ、担当体制、費用条件を一緒に確かめます。

相続による義務者の変更、共有物件の一部異動、評価替えを示してもらいます。
減免から更正、地図検索、証明書出力まで、一連の流れとして確かめます。
簡単な検索だけを見ると、例外処理や説明のしやすさの不足を見落としやすくなります。
導入責任者や業務設計、移行、連携、保守の担当者が、本番までどこに関わるのかを確かめます。
再委託の範囲と管理方法を確かめます。あわせて、障害時に何分以内に受け付け、何時間以内に復旧方針を示すかを質問します。
移行や制度改正の別料金を含めて、価格の前提と除外項目を比較表に残します。

▶ 詳細はこちら：固定資産税システム開発でおすすめの開発会社6選と選び方

ポイント

開発会社は導入件数よりも、自治体の業務単位での実績と、移行や保守まで説明できるかで比べると、判断の差が出やすくなります。

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

要件が曖昧なまま価格だけを競わせると、提案の後に追加費用や想定外の運用変更が生じやすくなります。そのため、発注の前に、現行業務、標準仕様、移行対象、連携先、非機能、保守条件をRFPにまとめておきます。

RFPに記載する項目

提案の条件をそろえて比べられるように、RFPでは要件を区分ごとに具体化します。

機能：台帳、評価・課税、異動、軽減・特例、申告、証明書、帳票、権限、監査ログ。
データ：現行項目、コード、件数、保持年度、外字、地図、欠損・重複。
連携：住民情報、宛名、収納・滞納、登記、GIS、電子申告、通知書の方向・頻度・エラー処理。
非機能：性能、同時利用者数、稼働時間、バックアップ、復旧目標、災害対策、ログ、暗号化、脆弱性対応、保守窓口。
委託・契約管理：要件と契約条件を明記します。

委託先と再委託先については、入退室、アカウント、端末、持ち出し、作業記録の扱いも示してもらいます。加えて、標準仕様の版や標準外機能、データ返却、制度改正の追加費用は、必ず回答してもらう項目にします。

契約後の役割分担と変更管理

契約後は、責任と記録の方法をそろえ、変更や委託の管理、検収の条件を明確にしておきます。

自治体側では業務責任者、情報政策、調達を、開発会社側ではプロジェクト、業務、移行の担当を決めます。
変更は、理由、影響機能、費用、納期、テスト範囲を記録し、承認したうえで受け付けます。
制度改正や評価替えによる変更は、通常の追加要望とは分けて扱います。
再委託先が触れるデータや作業場所、ログの確認者、事故時の報告期限（何時間以内か）を確かめます。
検収には、税額突合、移行件数、帳票、連携、権限、復旧、研修資料の完成を含めます。
引き渡すものの形式と検収基準を契約書や仕様書に残し、引き渡し時の認識の差を抑えます。

▶ 詳細はこちら：固定資産税システム開発の発注・外注・委託方法

ポイント

発注前にRFPで要件を具体化しておくと、提案の条件がそろい、追加費用の発生を契約の段階で抑えやすくなります。価格だけで比べる前に、この作業を済ませておくことが大切です。

導入後の運用・セキュリティと失敗を防ぐポイント

毎年の課税処理に加えて、税制改正や評価替え、帳票の改定、登記情報や電子申告の仕様変更にも対応していく必要があります。

表計算や個別ファイルで補正を重ねると、どれが正本か分からなくなります。そのため、稼働の時点で運用責任と記録方法を決めておきます。

個人情報と税額情報を守る要件

保護策、自治体の適用要件、クラウド運用時の管理項目は、分けて確かめます。

基本対策：ネットワーク分離、最小権限、二要素認証、暗号化、操作・税額変更・データ出力ログ、バックアップ、復旧訓練、脆弱性対応。
適用要件：マイナンバー利用事務系に関わる画面転送方式を確かめます。
無線LAN：LGWAN接続系とマイナンバー利用事務系での利用要件。
クラウド管理：データ所在地、障害時の切替、ログ保存、バックアップ世代数、復旧目標の扱い。
権限と終了時：返却・消去証明、再委託先の監査権限、職員権限の無効化、緊急操作の記録を決めます。

地方公共団体における情報セキュリティポリシーに関するガイドラインは、2025年3月に改定されたものです（出典：国家サイバー統括室「地方公共団体における情報セキュリティポリシーに関するガイドラインの改定資料」）。

固定資産税の構成にマイナンバー利用事務系のデータが含まれるかどうかは、自治体ごとに確かめる必要があります。

よくある失敗と予防策

導入後の手戻りや運用負担を防ぐために、起こりやすい失敗と、その対応を確かめておきます。

周辺業務の整理漏れ：税務本体だけが稼働して、現地調査や地図確認が別ファイルに残ると、二重入力が続きます。
移行の後回し：古いコードや外字、欠損、過去年度の扱いを早めに調べ、要件定義と並行してサンプル移行を進めます。
通常ケースだけの受入：相続、共有、減免、更正、非課税、所有者不明、償却資産申告といった例外も、テストの対象に入れます。
保守とデータ出口の未確認：制度改正の費用、他社へ移すときの形式、契約終了時の返却条件を、あらかじめ定めておきます。

固定資産税システムに関するよくある質問

答えは自治体の規模や既存システムによって変わるため、一般的な目安と、個別に確かめるべき条件を分けて説明します。

固定資産税システムの開発費用はいくらですか？

支援システム追加は1,000万〜5,000万円、標準準拠パッケージ更改は5,000万〜2億円、複数税目の税務基幹更改は2億〜6億円程度が推定レンジです。

GIS、家屋評価、大規模な移行を含めると、さらに高くなる場合があります。正式な金額を判断するには、資産件数や連携数、移行対象年度、標準外機能、保守範囲をそろえて見積もる必要があります。

標準準拠パッケージなら自治体独自の機能は不要ですか？

自治体独自の機能が必要になる場合もあります。税務本体の標準仕様と、家屋・土地評価、GIS、登記履歴、所有者調査、独自帳票などの周辺業務は、別のシステムやサービスに分かれる場合があります。

どこまでを標準機能、連携、運用で対応するかは、Fit & Gap分析で決めます。

データ移行で特に注意すべき項目は何ですか？

課税台帳の件数に加えて、過去年度の評価額や所有権異動、納税義務者、共有者を確かめます。あわせて、地番・家屋番号、外字、地図座標、評価根拠も注意が必要です。

コード変換、欠損・重複、移行後の税額計算、帳票は、サンプルと全件の両方で照合します。そのうえで、本番の前に複数回リハーサルします。移行対象外のデータを残す場合は、参照方法と保存期間も決めておきます。

導入にはどのくらいの期間がかかりますか？

支援システム追加は3〜9か月、標準準拠パッケージ更改は9〜18か月、複数税目の税務基幹更改は18〜30か月程度が目安です。

期間は、業務要件の差分や移行、外部連携、職員数、並行稼働、年度当初課税の切替時期によって変わります。そのため、評価替えと繁忙期を含む年間カレンダーを要件定義の時点で作っておくと、無理な切替日を避けやすくなります。

まとめ

固定資産税システムは、土地・家屋・償却資産の評価や異動、税額計算を支える税務基盤です。証明書や、登記・GIS・電子申告との連携、履歴と監査証跡も担います。

2026年時点では、標準仕様への適合を確かめ、税務本体と評価・GISなどの周辺機能を分けて設計すると、要件と費用を明確にできます。

最初に行う作業

現行業務とデータを洗い出し、標準仕様、自治体固有の要件、周辺機能、移行対象、連携先を構成図にまとめます。

代表的な税額計算と例外ケースを押さえ、移行・テスト・切替のカレンダーを作ります。機能、費用、体制、保守、データ返却を同じ条件で比べると、追加費用や運用負担の増加を抑えやすくなります。

更改判断で外せない視点

更改では、方式、費用の範囲、運用後に求める条件を合わせて判断します。

構成：標準準拠の税務本体、評価・GISなどの周辺サービス、クラウド基盤、自治体の運用を組み合わせて考えます。
費用：初期構築、移行、連携、研修、並行稼働、制度改正、評価替え、保守、クラウド利用料を含めて見積もります。
運用の条件：正確な税額、説明できる履歴、安全な運用、将来のデータ移行のしやすさを同時に求めます。

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
 ・スクラッチシステム開発の完全ガイドブック
 ・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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