固定資産税システム開発の進め方/やり方/流れや方法/手法/工程/手順

固定資産税システムの開発は、現行業務と要件を整理し、データ移行と税額突合を経て切り替える順に進めます。

初回課税を安全に迎えるには、年度当初課税や納税通知書の発送時期から工程を逆算して、計画を立てることが大切です。

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

固定資産税システム開発の全体像

固定資産税システムを中心に、賦課や評価替えなど5つの業務を配置した図。
年度ごとの処理と日々の異動が同じ基盤につながります。

固定資産税システムは、資産情報を登録して税額を出す単機能のソフトウェアではなく、税務の基幹システムとして業務全体を支えます。

毎年の賦課や3年ごとの評価替えを支え、日々の異動処理も扱います。さらに、償却資産申告や証明書発行も担い、収納・滞納管理との連携も、止めずに回す必要があります。

開発や更改では、機能一覧を先に作るより、業務とデータのつながりを整理することが大切です。担当部署や処理時期も、そのつながりの中で捉えます。

税務本体が担う機能とデータ

税額計算の説明責任を果たすために、税務本体が扱う情報の範囲を決めておく必要があります。

  • 資産・課税情報:土地・家屋・償却資産の台帳と、納税義務者、共有者、所有権異動の管理を担い、評価額と課税標準額を計算します。
  • 特例・履歴:住宅用地の特例、非課税、減免、都市計画税、更正、過誤納などの記録を残します。
  • 帳票・証明書:納税通知書、課税台帳、評価証明、公課証明、名寄帳などを出力します。
  • 外部連携:宛名番号、住民情報、収納・滞納管理、eLTAXなどとデータをやり取りします。

例外処理には、共有持分の変更や相続による納税義務者の変更があります。さらに、登記済通知書との不一致や過年度更正も、例外処理に含まれます。

評価根拠の確認も含めて、例外処理への対応と説明可能性が求められます。例外に対応できるかは、通常処理のデモでは見えにくいため、例外のケースを実際に動かして確かめます。

税額がなぜその金額になったのか、職員が追跡できることも欠かせません。そのため、監査ログには根拠データや処理日時を残す設計が必要です。担当者と変更前後の値も、同じログで追えるようにします。

標準準拠の税務本体と周辺システムの区分

更改では、税務本体と周辺機能の境界を先に決めます。境界があいまいだと、標準準拠の範囲と別システムにする機能が混ざってしまいます。

家屋評価などの周辺機能は、税務本体とは別の関連システムとして切り分けられる場合があります。

  • 税務本体:標準仕様に準拠する機能が対象で、製品の適合状況と改定への追随方法を見ます。
  • 周辺機能:家屋評価、固定資産業務支援GIS、登記履歴、登記・課税データ連携、概要調書、所有者調査など。

固定資産税の標準仕様は、デジタル庁のデータ要件・連携要件に掲載されており、2026年2月27日公開の第10.0版です(出典:デジタル庁「データ要件・連携要件の標準仕様」、2026年)。

たとえば、千葉市の標準化計画でも、税務システムと家屋評価システム、固定資産業務支援GIS・登記履歴システムなどを区分しています(出典:千葉市「自治体情報システムの標準化に関する全体計画」、2024年)。

周辺機能を本体へ詰め込まず、データ連携や、どこまでを誰が受け持つか、障害時に業務をどう続けるかまで含めて分けておくと、将来の変更に強い構成になります。

ポイント

税務本体の範囲を決め、周辺機能との境界を引いたうえで、例外処理まで業務の流れに含められるかが判断の目安です。機能一覧より先に、業務とデータのつながりを押さえてください。

固定資産税システムの進め方・流れ

初回課税に向けた準備から切替までを4つの番号付きパネルで示した図。
切替前に移行データと税額を段階的に確かめます。

固定資産税システムの開発は、次の7つの工程で進みます。年度業務に合わせて、切替後の初回課税を安全に迎える計画を立てることが欠かせません。

  1. 要件定義
  2. 設計・設定
  3. データ移行
  4. テスト
  5. 研修
  6. 並行稼働
  7. 切替

納品日から逆算するだけでは、年度の業務日程とずれて危険です。工程は、年度当初課税と納税通知書の発送を起点に調整し、償却資産申告と評価替えの時期も組み込みます。

1. 現行業務の棚卸しと要件定義

要件定義では、関係部署と現行の運用を確認して、標準仕様との違いを整理します。必要な成果物も、このときにそろえておきます。

  • 関係部署:資産税課、情報政策課、収納、戸籍・住民情報、窓口、GISの担当者に参加してもらいます。
  • 業務フロー:土地・家屋・償却資産の登録、登記済通知書の取込、現地調査、評価計算の流れ。
  • 関連業務:納税義務者変更、申告書審査、証明書発行、収納連携まで、フローに含めます。
  • 現行資料:担当者への聞き取りに加え、帳票、Excel、紙台帳、バッチ処理、手作業の補正表を見ます。
  • 要件・成果物:必須機能、独自業務、廃止運用を分け、業務・データ・連携・帳票・権限・例外・移行年度・非機能要件を整理します。

現行運用は、「現在使っているから必要」とせず、法令上の必要性や説明責任、旧システムの制約から確かめます。さらに、仕様書にない運用も把握しておくと、後工程での追加費用を抑えやすくなります。

2. Fit & Gap分析とデータ移行設計

製品候補の適合性を確かめながら、データ移行の調査と照合を要件定義と並行して進めます。

  1. 標準機能、設定変更、追加開発、業務見直しに分けて、Fit & Gap分析を行います。
  2. 評価要領、軽減・特例、帳票の位置、外字、共有者の持分、地番・家屋番号の表記を確かめ、実データに近いサンプルで、職員が通常手順で処理できるか試します。
  3. 台帳項目、コード体系、過去年度の保管、外字、重複、欠損、地図座標、所有者履歴を調べたうえで、移行年度と保存年度を決めます。
  4. サンプル移行で変換ルールを決めたうえで、全件移行と件数・金額照合、代表ケースの画面照合を複数回繰り返します。
  5. 移行対象外のデータは、参照の方法と保存の責任を契約書に明記します。

3. 税額突合、受入テスト、並行稼働

税額の突合から切替後の検証まで、次の順に進めると、稼働後の混乱を抑えられます。

  1. 画面表示だけでなく、現行と新システムの税額が一致するかを見ます。
  2. 土地の評価替え、家屋の新築・増築、償却資産申告、住宅用地の特例、非課税、減免、更正、相続、共有、所有権異動、納税義務者変更を試します。
  3. 差があれば比較表を作り、税率、評価額、課税標準額、端数処理、軽減条件、適用年度のどこで差が生じたかを説明できる状態にします。
  4. 受入テスト、帳票印刷、外部連携、性能、バックアップ・復旧を確かめ、切替直前には本番手順でリハーサルを行います。
  5. 処理時間、担当者、判定基準、問題時の戻し方を確かめ、最低でも繁忙期を避けた切替日と、障害時の手作業切替を決めます。
  6. 問い合わせ窓口と、初回課税後の検証期間を決めておきます。

ポイント

年度当初課税や納税通知書の発送時期から逆算しても工程が組めないときは、計画を見直すのが目安です。切替前に税額突合と並行稼働を挟めるかも、判断の材料になります。

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

5つの導入構成について、初期費用の推定レンジを横棒で比較した図。
統合範囲が広い構成ほど、見積もりの上限も大きくなります。

固定資産税システム単体の全国統一の価格表は、公開されていません。そのため、ここで示す金額は、自治体向けパッケージの範囲や公開調達額、移行・GIS・評価業務の複雑さから組み立てた推定レンジです。

金額は、人口や土地・家屋・償却資産の件数によって大きく違います。さらに、連携数や既存データの品質、標準化の範囲でも変わります。

推定レンジは予算要求の第一仮説として使い、同じ条件を示して複数社から見積もりを取ります。

構成別の初期費用の目安(1,000万円から8億円超)

初期費用と期間は、導入範囲や開発方式によって次のように変わります。いずれも、機能範囲と工程からの推定です。

  • 支援SaaS・パッケージ追加:評価・GIS・所有者調査などを追加する場合、1,000万〜5,000万円、3〜9か月が目安です。
  • 標準準拠パッケージ更改:固定資産税パッケージへの更改なら、5,000万〜2億円、9〜18か月が第一仮説です。
  • 税務基幹の一体更改:住民税、法人住民税、軽自動車税、収納・滞納管理も含む場合、2億〜6億円、18〜30か月程度になりやすいです。
  • 大規模自治体の統合:GIS、家屋評価、登記履歴、複数拠点、大量移行まで一体で扱う場合、3億〜8億円超、24〜36か月程度を見込むことがあります。
  • フルスクラッチ:独自の評価ロジックや帳票を開発し、3億〜10億円超、24〜48か月となる可能性があります。

スクラッチ開発を比べるときは、初期費用に加えて、10年程度の保守負担も見ます。制度改正や評価替えへの対応のほか、担当者交代や障害対応も、保守の負担に含めて考えます。

見積に含めるべき初期費用とランニング費用

更改費用の比較では、初期構築の範囲と毎年発生する運用費を切り分けます。

  • 初期導入:要件定義、環境構築、設定・追加開発、帳票、外部連携、テスト、研修、並行稼働、管理。
  • データ移行:抽出、変換、クレンジング、サンプル・全件移行、照合、リハーサル、GISレイヤー変換。
  • 個別対応:地番・家屋図の更新、外字対応、過去年度データの参照環境。
  • 運用・保守:保守、制度改正、クラウド利用、バックアップ、監視、ヘルプデスク。
  • 継続更新:地図更新、帳票改定、職員研修。

データ移行は、どの工程まで見積もりに含まれるのかを確かめておきます。

GISレイヤー変換や地番・家屋図の更新は、別費用として扱われることがあるため、見積もりで別建てになっているかを確認します。

運用費の目安は、支援SaaSが年500万〜2,000万円、固定資産税パッケージが年1,000万〜5,000万円です。一方で、税務基幹一体型や大規模クラウドは年3,000万〜1億円程度です。

これらは類似の自治体システムから組み立てた目安で、公開価格ではありません。なお、制度改正を標準保守に含むか、追加見積もりにするかも確認します。

港区の調書(出典:港区「令和07年度入札(見積)経過調書」、2025年)には、令和7年度対応分の標準準拠パッケージ導入委託が3億8,019万9,600円で落札されたと記載されています。

これは税務システム全体の導入サービスの金額で、固定資産税単体の価格ではありません。ただし、標準準拠対応や複数税目などを含む自治体案件の公開ベンチマークとして参考になります。

ポイント

予算を組むときは、構成ごとの推定レンジを第一仮説とし、初期費用と毎年の運用費を分けて見ることが目安です。推定レンジは公開価格ではないため、同じ条件の個別見積もりで検証することが大切です。

固定資産税システムの見積もりを取る際のポイント

見積もりの精度は、ベンダーの営業力よりも、発注側が同じ条件を提示できるかで決まります。

機能名だけを並べたRFPでは、各社が異なる前提で価格を出すため、どの提案が妥当か比べられません。

標準仕様の版数や対象税目、資産件数を、数値でそろえます。

移行年度と連携先、帳票数は、数字で書いておくと比べやすくなります。研修回数や稼働時期、保守範囲も、できるだけ数値で示します。

RFP・仕様書に入れる項目

各社の提案を同じ条件で比べられるよう、RFP・仕様書には次の項目をそろえます。

  • 仕様適合:標準仕様の対象版、必須機能への適合、標準化対象外の機能、自治体独自要件。
  • 外部連携:宛名、住民情報、収納・滞納、eLTAX、登記、GIS、国税との受け渡しの方式、頻度、再送、担当範囲。
  • 帳票:出力条件、印字項目、外字、電子交付、改定時の費用。
  • 性能・安全:処理時間(通常時・年度当初課税時)、同時利用者数、バックアップ頻度、復旧目標、ログ保存期間、暗号化、二要素認証、権限分離、脆弱性対応、障害報告期限
  • クラウド・契約:データ保管場所、委託先・再委託先、返却、消去証明、停止時の代替手順。

開発会社の得意領域と移行体制

自治体の重点課題に応じて、開発会社の実績を見る領域を整理します。

  • 税務中核:自治体税務・基幹業務の導入実績。
  • 評価・GIS:地図と課税台帳の統合や、評価計算の実績。
  • 家屋評価:登録、日程調整、評価計算などの支援範囲。
  • 所有者調査:相続人調査などの案件管理の経験。
  • 移行・運用:複数税目、共通宛名、収納、帳票、クラウド移行の体制を比べます。

京都市は地図と課税台帳を統合しました。両備システムズの導入事例では、評価額・課税標準額の計算まで扱うクラウド型パッケージを導入しています(出典:両備システムズ「京都市 固定資産税課税支援システム導入事例」、2026年確認)。

京都市は人口約140万人の政令指定都市で、11行政区の業務集約も行っています。大規模自治体で業務の統一やGIS連携を重視する場合、参考になる事例です。

税務・自治体基幹に実績を持つ企業として、ジーシーシー、富士通、TKCなどが候補になります。

固定資産税単体だけでなく、共通宛名や収納との関係を比べます。あわせて、帳票の扱いやガバメントクラウドへの移行方針も確認します。

NTT-ATエムタックの流山市の事例では、家屋評価事務の流れを一つにまとめています。具体的には、家屋データの登録や台帳入力を支えます。訪問日程の調整と評価計算も、支援の範囲に入ります。

家屋評価を別サービスで強化したい自治体は、税務本体との導入範囲を確かめる必要があります。

先ほどの企業も、この比較の対象に含めて検討できます。

所有者不明土地や空き家対策を重視する自治体は、所有者調査管理の導入経験も確かめておくとよいです。

ビービーシーの事例では、市原市が相続人調査の書類と案件情報をまとめて管理しました(出典:株式会社ビービーシー「2in1Win所有者調査管理システム導入事例」、2026年)。

同事例では、職員1人当たりの年間時間外勤務が2021年度の約500時間から2024年度の約60時間へ、約88%削減したと紹介されています。

ビービーシーは2026年6月時点で、同システムが全国90超の自治体に導入されたと公表しています。

データ移行と制度改正のリスク管理(契約での取り決め)

移行後に税額や履歴の不備が表に出ないよう、検証と制度改正時の責任を契約で固めておきます。

  • 移行品質:外字、地番と地図、共有者持分、過年度の評価根拠、減免・更正履歴の確認。
  • 移行条件:リハーサル回数、照合方法、未移行データの扱いを契約に記載する。
  • 制度改正:改正の検知、影響調査、改修、帳票変更、テスト、リリース、職員周知までの保守範囲。
  • セキュリティ・復旧:ネットワーク分離、最小権限、二要素認証、監査ログ、バックアップ、復旧訓練の運用と責任分担。

起こりやすい失敗には、稼働日に起動しない問題のほか、一部データや例外計算の不備に気づくのが遅れることもあります。こうした不備は、問い合わせや税額の確認で発覚することがあります。

制度改正対応に追加費用がかかるかは、契約前に明らかにしておきます。あわせて、自治体情報セキュリティポリシーに沿った実施範囲も確かめます。

バックアップと復旧訓練は、機能の有無だけでなく、運用手順と責任分担まで決めておくことが大切です。

ポイント

見積もりを比べる前に、版数や資産件数、移行年度、連携先の条件を発注側がそろえて示せるかが目安です。条件がそろっていない提案は、価格だけでは比べられません。

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

固定資産税システムでは、制度、データ、現場の運用が密接に結びついています。そこで、予算化やベンダー選定の場面で確認される質問と、判断基準をまとめます。

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

標準準拠パッケージへの更改では、初期費用5,000万〜2億円程度を第一仮説として考えます。

GISや家屋評価、登記履歴を含めると、費用は大きく上がります。大規模なデータ移行や複数税目との一体更改も加わると、2億〜8億円超になることがあります。

これは公開価格ではなく、推定のレンジです。資産件数や連携数、移行年度は、そろえておくと比べやすくなります。帳票数と保守期間も含めて、個別の見積もりを確認してください。

パッケージとスクラッチ開発はどちらが適していますか?

標準仕様への追随や制度改正への対応を重視する自治体では、標準準拠パッケージが第一候補です。導入実績や移行テンプレートも、比べる材料になります。

自治体固有の評価計算が既存の資産と強く結びつき、業務を変えられない場合に限って、スクラッチを検討します。

スクラッチ部分が増えるほど、将来の改修費や担当者の属人化、他社への移行の難しさが上がります。そのため、差分は金額と保守体制で示して比べます。

既存の課税台帳や地図データは安全に移行できますか?

移行は可能ですが、安全に進められるかどうかは、現行データの品質と移行設計で決まります。

  • 移行検証:サンプル移行と全件移行、件数・金額照合、画面照合を、複数回のリハーサルで行います。
  • 確認データ:外字、地番、家屋番号、共有、過去年度、評価根拠を、事前に確かめます。
  • 対象外データ:紙資料や旧システムを、誰がどの方法で参照するかを決めます。

ポイント

予算化やベンダー選定で迷ったときは、標準準拠への追随と将来の保守負担を基準に考えると、判断の方向が定まりやすいです。費用は推定レンジとして扱い、個別見積もりで確かめてください。

まとめ

成功の要点は、税務本体と評価・GISなどの周辺機能を分けることです。そのうえで、年度業務に沿って、要件から切替までの流れを設計します。

標準仕様への準拠を目的にするだけでなく、税額計算の説明可能性を重視します。さらに、職員の評価業務と、住民への証明書発行、所有者調査を一つの業務の流れとして整理します。

まず確認する三つの項目

最初に現行業務とデータを洗い出し、標準準拠の範囲と自治体固有の差分を確定します。

資産件数と移行年度を明らかにし、外部連携やGIS・家屋評価の有無も確かめます。そのうえで、初期費用とランニング費用を分けた見積もりを取ります。

評価替えと年度当初課税から逆算して、税額突合と移行リハーサルを計画します。並行稼働や障害時の代替手順も、同じ計画に入れます。

見積もり前の関係部署での合意

部署ごとに必要な機能や保持するデータが違うため、発注条件を関係部署で合意してから、各社に示します。

関係部署で優先順位と、どこまでを誰が受け持つかを決めたうえで、RFPを作成します。

  • 関係部署:資産税課に加え、情報政策、収納、住民情報、窓口、GIS、空き家対策。
  • 共通条件:版数、適合性、移行回数、制度改正、復旧目標、データ返却条件を、同じ様式で各社に尋ねる。
  • 資料の整理:課税台帳、評価・地図データ、帳票、連携一覧を一つにまとめる。

固定資産税システムは、資産税課だけでなく複数部署のデータをつなぐ基盤です。業務とデータの全体像が見えると、パッケージとクラウドに加え、周辺SaaSや追加開発も比べやすくなります。

選定では、価格だけでなく、稼働後の安定性も含めて判断します。

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

会社紹介

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

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

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

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

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

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