自治体向け電子申請システムの発注は、業務の棚卸し、要件整理、方式選定、契約・試験の順に進めると、住民と職員の双方の負担軽減につながります。全体像は、自治体向け電子申請システム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・自治体向け電子申請システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
自治体向け電子申請システムの発注範囲
発注の対象は、住民が使う申請画面に限りません。審査、差し戻し、承認、手数料決済、電子文書交付も含みます。さらに、帳票出力、基幹システム連携、操作ログ、保守運用まで含めた業務基盤として捉えます。
住民側と職員側の機能の一体設計
住民の申請画面と職員の処理画面は、同じ申請を前後から支える関係にあります。そのため、住民側と職員側に必要な機能を整理し、一体として設計します。
- 住民向けフォーム：手続き検索、スマートフォン対応、入力補助、条件分岐、添付、申請状況の照会
- 住民への通知：受付・差し戻し通知
- 認証・申請方法：メール認証、マイナンバーカードによる公的個人認証、電子署名、代理申請
- 職員向け機能：LGWANからの受付確認、担当課への振り分け、審査・承認、差し戻し、期限管理
- 管理・連携：権限設定、監査ログ、CSVまたはAPIによる連携
本人確認や代理申請の方法は、手続きの性質によって検討することになります。
申請受付から登録・通知までの範囲
電子化の効果は、申請データを受け取った後の転記回数で変わります。そのため、発注前に業務の流れを一覧にして、自動化する工程を決めておきます。
- 申請受付と本人確認
- 審査と差し戻し
- 基幹登録と通知・交付
- 記録の保管
デジタル庁は、住民と行政職員双方の負担軽減を目的に、手続きのオンライン化と業務効率化を進めています（出典：デジタル庁「行政手続のオンライン化」、2026年6月更新）。
発注形態（SaaS・パッケージ・個別開発）の選び方
発注形態は、自治体固有の業務、既存システムとの連携範囲、導入時期を踏まえて決めます。あわせて、制度改正への追随、職員によるフォーム追加、契約終了時のデータ返却も確かめます。
SaaS・ASPが向く、短期間で標準手続きを広げる場面
SaaS・ASPは、提供会社がクラウド基盤、機能更新、脆弱性対応を担い、自治体のサーバー構築負担を抑えやすい方式です。
申請フォーム、予約、アンケート、集計などの標準機能を使い、複数課へ短期間で展開したい場合に適しています。
独自の審査順序や複雑な基幹連携が標準機能に収まらない場合は、追加開発費と外部連携の可否を確かめます。
標準化と個別要件を両立するパッケージと連携開発
連携方式を決める際は、追加する機能と接続先を先に確かめておきます。
- 個別要件：自治体固有の審査や基幹連携を追加し、標準機能と両立
- 連携先：ぴったりサービス、自治体公式サイト、住民ポータル、LINEなど
- 接続時の確認：データ受け渡し、認証の責任分界、障害時の連絡経路
- 電子申請等API：2026年6月公開。自治体のWebサイトやアプリから、ぴったりサービスの検索・申請機能を連携できます。
デジタル庁開発者サイトの「電子申請等API」は、2026年7月に更新されています。
スクラッチ開発の検討条件
スクラッチ開発なら、独自審査、複数の基幹システム、特殊帳票、厳格な可用性を自由に設計できます。一方で、初期費用と開発期間は大きくなりやすい方式です。
制度改正、OS・ブラウザ更新、脆弱性対応、担当者交代時の引き継ぎも、自治体側の運用責任になります。こうした運用負担も含めて、既製サービスで対応できない要件を明確にしてから選びます。
独自の画面を作ること自体を目的にせず、業務改善の効果と5年間の総保有コストで判断します。
発注から導入までの5段階の進め方
製品や開発会社を先に決めると、紙との二重運用や追加費用が生じる場合があります。そこで、対象の手続きから整理し、要件を定めてから提案を募る流れにします。
第1段階：手続きと業務フローの洗い出し
手続きごとに、年間件数、繁忙期、来庁の必要性を把握します。そのうえで、入力項目、添付書類、本人確認の方法、手数料を整理します。さらに、審査担当、処理日数、基幹登録の有無も記録しておきます。
件数が多く、住民の来庁負担と職員の転記負担が大きい手続きから始めると、導入の効果を測りやすくなります。
候補には、デジタル庁が示す対象に加えて、自治体独自の粗大ごみ受付、施設予約、給付申請も含めます。
第2・3段階：要件の整理とRFPの配布
まず、業務フローの現状と目標を並べ、オンライン完結、職員の確認、紙を残す例外の範囲を定めます。次に、その要件をまとめ、提案依頼書（RFP）に記載します。
- 機能・連携：必要な機能と既存システムとの接続範囲
- 非機能・運用：性能、セキュリティ、導入支援、研修、保守
- 費用：提案時に提示する費用の内訳と条件
RFPを出す前に複数社へヒアリングする場合も、特定製品の機能に引っ張られないよう、自治体が達成したい業務成果を軸に質問します。
第4・5段階：契約、試験、段階的な展開
契約後は、1〜3手続きを対象に、フォーム、審査、通知、権限、ログ、連携を検証します。住民向けの動きだけでなく、職員の差し戻しや代理申請も試しておきます。
繁忙期の大量申請に耐えられるか、障害時に紙へ切り替えられるかも確かめます。あわせて、オンライン完結率、処理時間、差し戻し率、問い合わせ件数を測ります。
試験の結果をもとに改善したうえで、対象の課と手続きを広げていきます。
RFPと要件整理で発注前に決める項目
RFPは、希望を伝える文書であるとともに、提案と見積を同じ条件で比べるための基準です。「使いやすい」といった表現だけでは比べにくいため、誰がどの画面で何分以内に何を処理するかまで具体化します。
手続きごとの機能要件
まず、手続き検索、入力補助、条件分岐、添付、本人確認を機能一覧に入れます。電子署名、代理申請、通知、審査、決済、電子交付も、同じ一覧で扱います。そのうえで、帳票、検索、集計、権限、監査ログも書き出します。
各機能には「必須」「できれば」「対象外」のいずれかを付けます。さらに、標準機能か追加開発か、職員が設定変更できるかを、提案書で回答してもらいます。
差し戻し後の再提出、取り下げ、二重申請、添付不足といった例外の扱いも、あらかじめ確認しておきます。
数値と手順で定める非機能要件とセキュリティ
RFPには、次の非機能要件とセキュリティ要件を、数値や手順で定めて書き込みます。
- 可用性・性能：可用性、バックアップ、復旧目標、同時接続数、応答時間
- 安全対策：暗号化、アクセス制御、脆弱性診断、負荷試験
- 運用条件：監査ログの保存期間、障害連絡、保守時間帯
- 委託先管理：委託先・再委託先の監督、監査、事故報告、データ返却・削除の契約条件
インターネット側、LGWAN接続系、個人番号利用事務系・基幹システムを分ける構成の場合は、連携サーバーやAPIゲートウェイの責任分界も明記します。
委託先管理の考え方は、個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（行政機関等編）」が出典です。
運用体制と契約終了時の条件
職員がフォームを追加・変更できるかどうかに加えて、制度改正時の修正担当と問い合わせ窓口を決めておきます。研修資料、操作マニュアル、管理者権限の引き継ぎも、成果物に含めます。
契約終了時のデータ形式、エクスポート費用、移行支援を提示してもらい、バックアップ削除の証明も求めると、ベンダーロックインのリスクを抑えやすくなります。
契約形態（請負・準委任・利用契約）の組み合わせ
仕様が固まっている部分と、導入しながら改善していく部分を分けて考えます。たとえば、SaaSの利用契約、初期設定や連携開発の請負、業務整理や伴走支援の準委任を組み合わせます。こう分けると、責任範囲と変更のしやすさを整理できます。
具体的な契約方式は、自治体の調達規程や法務担当の確認を受けて決めます。
請負の成果物と検収条件
請負契約では、納品物と期限、検収基準を具体化します。納品物には、画面一覧、連携仕様、テスト結果を含めます。さらに、操作マニュアル、研修、移行データ、セキュリティ診断報告書なども定義します。
あわせて、仕様変更の手続きと追加費用の算定方法も定めておきます。完成の判断が曖昧だと、検収の場面で認識の違いが表面化しやすくなります。
業務整理や段階的な改善に使いやすい準委任
準委任は、作業の遂行を委託する場面に向きます。たとえば、業務分析・要件整理、プロジェクト管理、運用改善などです。また、制度や現場の要望を確かめながら進める段階でも使えます。
月次の作業範囲と体制、報告内容、意思決定者を決めておきます。
成果物の完成責任が曖昧にならないよう、要件定義・設計・開発・保守のうち、請負と準委任の範囲を分けておきます。
利用契約・保守契約の5年間の条件
SaaS利用料や保守費は、月額・年額の固定料金のほか、フォーム数、申請件数、保存容量によって変わる場合があります。メール通数、決済額、追加ユーザー数によって変わる場合もあります。そのため、固定料金と従量料金を分けて確認します。
価格改定と最低利用期間、解約予告を確認します。さらに、障害時のサービスレベルとデータ保存期間も見ておきます。そのうえで、導入から移行・終了までを含む5年間の支出で比べます。
自治体向け電子申請システムの費用相場と内訳
費用は、人口、手続き数、本人確認の強さで変わります。さらに、既存システム連携、決済・電子交付、契約年数によっても変わります。ここで示す金額は、一般的な業務システムの相場と、2025〜2026年の自治体の公開契約例を組み合わせた目安です。
金額は、見積の桁と内訳を確かめるための幅として使うもので、個別案件の確定額ではありません。
方式別の初期費用と年間費用の目安
費用は導入規模と連携範囲によって幅が変わります。次の条件別のレンジを、見積比較の起点として使います。
- 小規模SaaS：初期0〜300万円、年間利用・運用費100〜500万円
- 複数課への標準導入：初期300万〜1,500万円、年間300万〜1,500万円
- 大規模連携案件：初期1,000万〜1億円、年間1,000万〜3,000万円
- スクラッチ開発：5,000万〜3億円以上、期間9〜24か月のケース
小規模SaaSは、フォーム数を絞り、基幹連携なしで導入する想定です。標準導入には、決済、電子交付、研修が含まれます。大規模案件では、SSO、API、複数基幹との連携が含まれます。
スクラッチ開発の金額と期間は、要件によって変動します。
公開契約例の金額の読み方
公開契約例を読むときは、契約内容と金額を合わせて確認します。
- 伊東市：2024年度随意契約調査表の汎用電子申請システムサービス使用契約、1,078,440円
- 熊本市：2025年度のGraffer「くらしの手続きガイド」クラウド利用料、1,716,000円
- 名古屋市：2026年度の電子申請システムサービス提供・シングルサインオン開発業務、102,960,000円
名古屋市の案件は、フォームの利用料にとどまらず、大都市向けのサービス提供と開発を含みます。
（出典：各自治体の公開契約資料、2025〜2026年）
見積に含まれにくい費用
見積では、初期設定・開発に加えて、データ移行、帳票調整、LGWAN接続を確認します。さらに、SSO・API連携と決済手数料、電子文書交付、メール従量課金も確かめます。
アクセシビリティ対応、脆弱性診断、負荷試験も見積の対象です。さらに、職員研修やマニュアル、ヘルプデスク、制度改正対応も含まれます。保守費は、初期開発費の5〜15％程度が一般的な目安です。ただし、SaaS利用料とは性質が異なります。
見積は、固定費と従量費を分けてもらいます。そのうえで、初年度だけの費用と毎年発生する費用、オプション費も区別してもらいます。
委託先の選定と見積比較の確認点
委託先は、知名度や機能数だけでなく、自治体の業務を要件に落とし込めるかで選びます。提案と見積、デモ、実績、質疑は、同じ評価表で比べます。
RFPへの回答が抽象的な会社は、契約後に追加費用や役割分担の問題が生じる可能性があります。そのため、価格の理由も確かめておきます。
自治体実績の業務範囲
導入した自治体数だけでなく、フォーム提供、審査、決済、電子交付、基幹連携のどこまで支援したかを確かめます。
人口規模、手続き数、LGWAN環境が近い事例を紹介してもらいます。加えて、マイナポータル連携、既存基幹製品、導入期間が近い事例も挙げてもらいます。
導入後に職員が自分たちで運用を回せるよう、フォーム作成支援、研修、制度改正時の相談、障害対応の体制も確かめます。
同じ前提にそろえた見積比較
まず比較表に作業項目を並べ、各社の見積範囲をそろえます。
- 導入作業：要件定義、画面・フォーム、ワークフロー
- 機能・連携：認証、添付、通知、決済、電子交付、連携
- 運用準備：移行、テスト、研修、保守
金額が「一式」なら、作業時間と担当人数、単価を質問します。あわせて、前提と対象外の作業も確かめます。さらに、追加開発単価、仕様変更の承認、納期遅延、再委託の範囲も比べます。
住民の使いやすさと継続運用の確認
デモでは、住民がスマートフォンで手続きを検索し、入力、添付、送信するところまで試してもらいます。高齢者、障害者、外国人、代理申請者といった利用者も想定します。
住民側では、文字サイズや入力エラーの伝わり方、やさしい日本語、キーボード操作、問い合わせ導線を確かめます。
一方で、職員側では、繁忙期の受付、差し戻し、担当課の変更、権限異動、監査ログ検索を試します。現場で毎日使えるかを評価します。
よくある質問（FAQ）
費用や方式には唯一の正解がありません。対象手続き、本人確認、連携範囲、導入後の運用を前提に判断します。
SaaSとスクラッチ開発はどちらを選ぶべきですか？
標準的な申請を早く広げるならSaaS、独自審査や複数基幹との深い連携が不可欠ならパッケージと連携開発、またはスクラッチが候補です。
標準機能で実現できる範囲と追加開発の範囲を分けたうえで、5年間の費用と制度改正への対応力を比べます。
RFPにはどこまで細かく要件を書くべきですか？
対象手続き、利用者、業務フロー、必須機能を記載します。連携先、セキュリティ、性能、運用体制も書き込みます。さらに、成果物と費用の提示方法まで含めます。
製品の画面仕様は指定せず、業務の成果と制約条件を示します。標準機能・設定・追加開発のどれに当たるかを提案者に回答してもらうと、比較しやすくなります。
費用を抑えるにはどの工程を見直せばよいですか？
最初から全庁の全手続きを個別に開発せず、件数と効果の大きい手続きから試験導入します。また、標準機能を活用することも有効です。
決済、電子交付、基幹連携は、効果とリスクを見て段階化します。一方で、セキュリティ、バックアップ、監査ログ、アクセシビリティは、将来の手戻りが大きいため、削りすぎないことが重要です。
契約終了時のデータ返却はなぜ確認が必要ですか？
申請データは、監査、問い合わせ、再申請、保存年限への対応に必要になります。そのため、CSVや添付ファイルの返却形式、費用、移行中の閲覧可否、バックアップ削除時期を契約書に記載しておきます。
データ所有権に加え、メタデータや操作ログの扱いも確認します。
まとめ
まずは製品や開発会社を決める前に、対象の手続きと業務フローを整理します。住民の申請から職員の審査・登録・通知までを、発注範囲に含めます。
SaaS・ASP、パッケージ、スクラッチのそれぞれで、標準機能と追加開発を分けて考えます。ここまで整理すると、費用と納期の見通しを立てやすくなります。
RFPには、機能、連携、セキュリティ、性能を記載します。さらに、運用、再委託、データ返却、契約終了条件も書き込みます。
見積は、初期費用と年額利用料、従量課金を分けて比べます。連携開発や保守も、別々に比べます。
小さく導入して効果を測り、オンライン完結率、処理時間、差し戻し率、問い合わせ件数を確かめます。職員の作業時間も継続して改善していくと、発注は一度きりのシステム導入では終わりません。
▼全体ガイドの記事
・自治体向け電子申請システム開発の完全ガイド
▼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を創業。