結論：自治体向け電子申請システムの費用相場は、標準的なSaaS導入なら初期費用0〜1,500万円、
年間100万〜1,500万円程度、基幹システム連携や全庁展開を含む開発なら1,000万円〜1億円超まで広がります。
ただし、自治体向け電子申請システムは、住民が入力するフォームだけを作るサービスではありません。
認証、添付ファイル、審査・差し戻し、LGWAN接続、決済、電子交付、既存の住民情報や福祉・税システムとの連携まで含めて見積もる必要があります。
本記事では、公開契約例をもとに費用の内訳、価格帯、開発期間、金額が変わる要因、コストを抑える進め方を解説します。
▼全体ガイドの記事
・自治体向け電子申請システム開発の完全ガイド
自治体向け電子申請システムの費用相場はいくらですか？
結論から言うと、数個の手続きを短期間でオンライン化するだけなら年間数百万円以内に収まる場合があります。
一方で、複数の業務課が利用し、マイナンバーカード認証、電子署名、オンライン決済、
電子交付、基幹連携、シングルサインオンまで含めると、初期開発費は数千万円から1億円規模になることがあります。
小規模なSaaS導入は初期0〜300万円が目安です
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
フォーム数が少なく、既存の基幹システムへデータを自動登録せず、標準的な受付・通知・集計だけを使う場合は、SaaSやASPの導入が候補になります。
初期設定、フォーム作成支援、権限設定、職員向け研修を含めた初期費用は0〜300万円程度、年間の利用・運用費は100万〜500万円程度が一つの目安です。
実際の金額は、自治体の人口、利用課数、フォーム作成数、問い合わせ対応の範囲、契約年数によって変わります。
全庁展開や個別連携を含むと1,000万円〜1億円超です
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
複数課で利用し、申請データを審査後に基幹システムへ渡す場合は、初期費用300万〜1,500万円程度が標準導入の目安になります。
大規模自治体でSSO、複数の基幹システム、データ移行、可用性対策、監査ログまで組み込む場合は、初期費用1,000万〜1億円程度に広がります。
名古屋市の2026年度の公示では、電子申請システムのサービス提供とシングルサインオン開発を合わせた契約金額が約1.03億円でした（出典：名古屋市公報。2026年）。
ただし、この金額は特定自治体の契約条件に基づく事例であり、すべての自治体に適用できる定価ではありません。
自治体向け電子申請システムの費用内訳は何ですか？
見積書は「システム一式」という一行で出してもらわず、初期設定、画面・フォーム、認証、
審査機能、連携、移行、テスト、研修、保守に分けてもらうことが重要です。費用の大半は機能そのものよりも、
自治体固有の業務フローをどこまで標準機能に合わせるか、どのデータをどのネットワーク間で連携するかによって決まります。
企画・要件定義は業務整理と調達準備の費用です
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
企画・要件定義では、対象手続きの件数、申請者、本人確認の強さ、添付書類、審査担当、差し戻し条件、通知方法、保存期間を整理します。
さらに、インターネット側で受け付けた申請をLGWAN側で確認するのか、基幹システムへ自動連携するのかを決めます。
この工程を省くと、後から「この課だけ独自の承認が必要」「紙の原本を残す必要がある」と判明し、追加開発費と納期延長が発生しやすくなります。
フォーム・審査・認証・通知の開発費です
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
住民向けフォームは、入力補助、条件分岐、添付ファイル、スマートフォン表示、申請状況照会などの数が増えるほど工数が増えます。
職員側には、担当課への自動振り分け、審査、差し戻し、期限管理、帳票出力、操作ログ、権限設定が必要です。
マイナンバーカードの公的個人認証や電子署名を使う場合は、認証方式の設計、失敗時の案内、証明書の有効性確認、問い合わせ対応まで含めて見積もります。
基幹連携・データ移行・セキュリティ対策の費用です
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
申請データをCSVで出力して職員が登録するだけなら、API連携は不要な場合があります。
しかし、住民情報、税、福祉、施設予約などへ自動登録する場合は、連携先ごとに項目変換、エラー処理、再送、権限確認を設計します。
既存システムが古い、APIが公開されていない、ネットワーク分離が複雑である、といった条件では連携費用が上がります。
脆弱性診断、負荷試験、バックアップ、災害復旧、監査ログ、データ返却・削除の設計も初期費用と保守費用の双方に影響します。
SaaS・パッケージ・スクラッチで価格はどう変わりますか？
費用だけを比べると、SaaSが最も安く、スクラッチ開発が最も高く見えます。しかし、
実際には5年間の運用費、制度改正への対応、職員がフォームを追加できるか、データを他のシステムへ移せるかまで確認しなければ、
適切な比較になりません。自治体の規模よりも、標準化できる業務か、独自の審査や連携が多い業務かが方式選定の分かれ目です。
SaaS・ASPは初期費用を抑えやすい方式です
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
SaaS・ASPは、サーバー調達や基本的なセキュリティ更新をサービス側に任せやすく、1〜3か月程度で始められることがあります。
職員がノーコードでフォームを増やせるサービスなら、手続き追加のたびに開発会社へ発注する費用も抑えられます。
ただし、利用者数、フォーム数、ファイル容量、電子交付通数、メール通数、決済金額などの従量課金が設定されることがあるため。繁忙期の利用量を前提に年間費用を計算することが必要です。
パッケージ＋連携開発は標準機能と独自要件を両立します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
パッケージを使いながら自治体独自の審査、帳票、基幹連携だけを追加する方法は、SaaSとスクラッチの中間に位置します。
標準機能を活用できれば、初期費用を全面的な個別開発より抑えつつ、現場の業務にも合わせられます。
ただし、標準機能から外れる要件が増えるほど、バージョンアップ時の検証、個別改修の保守、ベンダー依存が増えます。
見積書では標準設定と追加開発を分け、将来の制度改正時にどちらが費用を負担するかを確認します。
スクラッチ開発は自由度と引き換えに保守負担が増えます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
独自の業務フロー、複数の基幹システム、特殊な認証、地域ポータルとの一体化を重視する場合は、スクラッチ開発が候補になります。
一般的な業務システムの開発では、SE単価を月80万〜120万円程度として工数を積み上げることがあり、自治体向けではここに調達支援、セキュリティ。LGWAN対応、アクセシビリティ、研修が加わります。
初期開発費は5,000万〜3億円以上、保守費は初期費用の5〜15％程度が目安とされますが、機能範囲と可用性要件によって大きく変動します。
費用を左右する主な変動要因は何ですか？
同じ自治体向け電子申請システムでも、人口や申請件数だけで価格は決まりません。本人確認の強さ、
手続きの種類、連携先の数、職員の運用体制、契約期間、障害時の対応時間が組み合わさって見積金額になります。
安い提案を選ぶ前に、含まれていない作業を確認することが大切です。
本人確認・電子署名・決済の有無で変わります
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
メール認証だけでよい申請と、公的個人認証や電子署名が必要な申請では、必要な設計と問い合わせ対応が異なります。
手数料のオンライン決済を加える場合は、決済サービスの初期設定、売上消込、返金、領収書、手数料率を確認します。
熊本市の2025年度契約状況では、LoGoフォームのオンライン決済に係る指定納付受託業務が納付額の3.5％。発注見込額約144万円とされています（出典：熊本市「令和7年5月契約状況」、2025年）。
決済額が増える自治体ほど、固定費だけでなく従量費を5年分試算する必要があります。
手続き数・申請件数・利用課数で変わります
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
フォームを5本だけ作る場合と、全庁で数百種類の手続きを管理する場合では、初期設定だけでなく権限設計、更新作業、問い合わせ窓口の負荷が異なります。
申請件数が多い場合は、ピーク時のアクセスを想定した負荷試験、ファイル保存容量、通知メールの上限、審査期限の管理が必要です。
利用課数が増えると、全庁共通の管理者と各課の担当者を分けるための権限設計や研修費も増えます。
ネットワーク・可用性・運用支援の条件で変わります
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
インターネット側の受付とLGWAN側の審査を分ける構成、個人番号利用事務系との連携、シングルサインオン、冗長化、バックアップ。災害時の復旧目標を求めるほど費用は上がります。
また、導入後に職員がフォームを作るのか、ベンダーへ毎回依頼するのかで年間の支援費も変わります。
北海道のHARP新運営では、電子申請とクラウド連携基盤の運用費を人口割を基本とした処理費逓減方式で算出しています。
人口に単純比例させず、利用規模が大きいほど単位当たりの負担を下げる考え方は、共同利用を検討する際の参考になります。
開発期間はどのくらいで費用とどう関係しますか？
開発期間を短くすることだけを目標にすると、要件漏れやテスト不足によって後から追加費用が発生します。
費用を適正化するには、最初からすべての手続きを作るのではなく、対象を絞って段階導入し、
利用状況を見ながら広げる進め方が有効です。目安として、小規模なSaaS導入は1〜3か月、
標準導入は3〜6か月、大規模連携は6〜12か月、スクラッチ開発は9〜24か月程度を見込みます。
要件定義では対象手続きと業務フローを絞ります
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
最初に全庁の手続きを一度に対象にするのではなく、申請件数が多く、住民の来庁負担と職員の転記作業を減らしやすい手続きから選びます。
申請者が誰か、どの情報を再入力しているか、添付書類を省略できるか、審査後にどこへ登録するかを可視化します。
デジタル庁は、住民の利便性と行政運営の効率化を目的に行政手続のオンライン化を進めているため、単なる電子フォーム化ではなく、業務フロー全体を見直すことが重要です。
パイロット導入でリスクと追加費用を見つけます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
最初の1〜3手続きで、住民がスマートフォンから申請できるか、添付ファイルを扱えるか、職員が差し戻しや承認を迷わず操作できるかを確認します。
オンライン完結率、処理時間、差し戻し率、問い合わせ件数、窓口来庁数を計測すると、追加投資の優先順位を決めやすくなります。
パイロットで判明した課題を本番全体へ反映すれば、全庁展開後の大規模な作り直しを避けやすくなります。
2026年以降はAPI活用も費用比較に含めます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
デジタル庁は2026年6月に「電子申請等API」を公開し、自治体のWebサイトやアプリから。ぴったりサービスの手続き検索・申請・申請状況照会などを利用できる仕組みを示しています。
APIを利用すれば独自の受付システムをすべて構築せずに済む可能性がありますが、利用申請、仕様確認、画面開発、認証、エラー処理、自治体側の審査運用は必要です。
API連携による削減効果と、独自画面・中間サーバー・保守の費用を分けて比較することが大切です。
自治体向け電子申請システムのコストを最適化する方法は何ですか？
コスト最適化は、機能を削ることではなく、住民と職員に効果がある機能へ予算を集中することです。
導入時の安さだけでなく、フォーム追加、制度改正、問い合わせ、障害対応、データ返却まで含めた5年間の総保有コストで比較します。
次の観点をRFPや見積依頼書へ反映すると、提案会社ごとの前提条件をそろえやすくなります。
標準機能を優先し独自開発を必要最小限にします
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
既存の紙様式をそのままオンラインフォームへ移すと、入力項目や添付書類が多いまま残ります。まず不要な項目を削り、類似手続きを共通化し、標準の審査・通知機能を使えるよう業務を整理します。
独自開発は、法令や自治体固有の要件で標準化できない部分に限定します。標準機能を受け入れる範囲を広げるほど、初期費用だけでなくバージョンアップ時の検証費も抑えやすくなります。
共同利用と段階導入で固定費を分散します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
単独で全機能を作る前に、都道府県や近隣自治体との共同利用、既存の汎用電子申請サービス、マイナポータルの活用を比較します。
北海道HARPのように、人口割を基本としつつ処理量に応じて単位費用を逓減させる運用モデルは、共同調達の検討材料になります。
小さく始めて効果を確認し、決済、電子交付、基幹連携の順に追加すれば、初年度の予算と現場の受け入れ負荷を分けられます。
5年分の利用料と終了時の費用を確認します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
熊本市の2025年度契約状況では、くらしの手続きガイドのクラウド利用料が年間約172万円でした。
また、LoGoフォームの電子文書交付追加と汎用メール追加は。それぞれ1,000通／月あたり約1.1万円の単価契約です（出典：熊本市「令和7年5月契約状況」、2025年）。
これらは公開された一自治体の契約例であり、サービス全体の標準価格ではありませんが、年額固定費と従量費を別々に見積もる必要性を示しています。
契約更新時の価格改定、データエクスポート、移行支援、解約後の保存・削除、再委託先の変更条件も5年総額へ含めます。
見積もりを依頼するときの確認ポイントは何ですか？
相見積もりでは、金額の合計だけでなく、前提条件と対象範囲をそろえることが重要です。
自治体側が準備するデータ、ベンダーが担当するフォーム作成、テスト、研修、運用支援を明確にしなければ、
安い見積もりが単に作業を含んでいないだけということがあります。
見積依頼書に機能と非機能の条件を明記します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
対象手続き数、想定申請件数、同時利用者数、添付ファイル容量、利用課数、認証方式、決済・電子交付の有無、連携先、保存期間、稼働時間。復旧目標を見積依頼書へ書きます。
可用性、暗号化、脆弱性診断、ログ保存、バックアップ、障害連絡、再委託、データ返却・削除も機能とは別の非機能要件として示します。
要件が未確定の場合は、必須要件と将来拡張に分け、提案会社へ複数案を求めます。
複数社を同じ5年総額と運用条件で比較します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
比較項目は初期費用、月額・年額利用料、フォーム追加費、ストレージ費、通知・電子交付通数、決済手数料、連携開発費、保守費、研修費、制度改正対応費です。
さらに、職員が自分でフォームを追加できるか、問い合わせの受付時間、障害時の復旧目標、データの所有権、APIの公開範囲、契約終了時のエクスポート方法を確認します。
自治体向けの導入実績だけでなく、同じネットワーク構成と認証条件で運用した実績を聞くことが重要です。
追加費用と契約終了時のリスクを確認します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
「フォームを追加するたびに個別見積もりになるか」「制度改正による項目変更は保守に含まれるか」「連携先の仕様変更費用は誰が負担するか」を契約前に確認します。
障害対応が平日昼間だけなのか、休日や繁忙期も含むのかによって保守費は変わります。
個人情報を扱うため、再委託先の管理、監査への協力、インシデント発生時の報告、契約終了後のデータ削除証明まで、価格と責任分界をセットで確認することが必要です。
自治体向け電子申請システムのよくある質問
自治体の担当者からは、SaaSと個別開発の選び方、年間費用に含まれる範囲、マイナポータルとの違いについて質問が多く寄せられます。
ここでは、予算要求やRFP作成の前に確認したい代表的な疑問へ回答します。
自治体向け電子申請システムは数百万円で導入できますか？
標準フォームを少数作り、基幹連携や高度な認証を使わないSaaS導入であれば、初期費用数百万円以内、
年間費用100万〜500万円程度に収まる可能性があります。ただし、フォーム作成支援、
研修、電子交付、決済、繁忙期の従量費を含むかで変わるため、初期費用だけで判断してはいけません。
年間の運用費は初期開発費の何％ですか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
一般的な業務システムでは、保守費を初期開発費の5〜15％程度とする目安があります。
ただし、自治体向け電子申請システムでは、SaaSの年額利用料、ストレージや通知の従量費、決済手数料、フォーム追加、制度改正、ヘルプデスク。セキュリティ監査などが別建てになる場合があります。
契約書と料金表で、保守率に含まれる作業と含まれない作業を確認してください。
ぴったりサービスを使えば独自システムは不要ですか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
すべての独自システムが不要になるとは限りません。
デジタル庁の電子申請等APIを使うと、自治体のWebサイトやアプリからぴったりサービスの検索・申請機能を呼び出せますが、利用申請、画面設計、認証。
自治体職員の審査、基幹システムへの登録、問い合わせ対応は必要です。
対象手続きと連携範囲を整理し、独自受付を作る場合とAPIを活用する場合の5年総額を比較してください。
費用を抑えても住民の使いやすさを保てますか？
可能です。費用を抑える対象は、住民が使う入力補助やスマートフォン対応ではなく、重複する独自機能、
不要な個別帳票、利用実績のない連携から優先して見直します。高齢者、障害者、外国人も利用するため、
やさしい日本語、キーボード操作、文字サイズ、窓口支援との併用を要件に残し、機能の優先順位を業務効果と利用者負担で決めることが重要です。
まとめ
自治体向け電子申請システムの費用は、SaaSの小規模導入で初期0〜300万円・年間100万〜500万円程度、
標準導入で初期300万〜1,500万円・年間300万〜1,500万円程度、大規模な基幹連携やSSOで初期1,000万〜1億円程度、
スクラッチ開発で5,000万〜3億円以上という幅があります。これは公開契約例と一般的な業務システムの工数目安を組み合わせた参考レンジであり、
人口、手続き数、認証、連携、可用性、運用支援によって変動します。
金額ではなく5年総額と業務効果で判断します
見積もりを取るときは、初期費用だけでなく、年額利用料、従量課金、決済手数料、連携開発、
保守、制度改正、研修、データ移行、契約終了時の費用を分けて確認します。オンライン完結率、
処理日数、差し戻し率、窓口来庁数、職員の転記時間をKPIに設定し、導入費用に見合う効果を検証できる状態にしておくことが大切です。
まずは対象手続きと必要な連携を整理します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
最初から大規模な独自開発を決めるのではなく、対象手続きを棚卸しし、標準SaaS、共同利用、ぴったりサービスの電子申請等API、パッケージ＋連携開発。スクラッチの順に適合性を比較します。
自治体の業務と住民の利用環境を理解する開発会社へ、同じ要件で複数の見積もりを依頼すると、価格の差が機能差なのか、作業範囲の差なのかを判断しやすくなります。
▼全体ガイドの記事
・自治体向け電子申請システム開発の完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。