自治体向け電子申請システム開発の進め方/やり方/流れや方法/手法/工程/手順

自治体向け電子申請システム開発は、紙の申請書をWebフォームに置き換えるだけではなく、受付から審査、基幹システムへの登録、通知・交付までの業務を一つの流れとして再設計する取り組みです。

本記事では、自治体向け電子申請システムの進め方を、要件整理、ベンダー選定、設計・開発、テスト、稼働、定着の6フェーズに分けて解説します。2026年時点の公開契約例を踏まえた費用レンジ、RFPや見積書で確認したい項目、導入後に成果を測る指標まで、担当者が庁内で説明しやすい形に整理します。

▼全体ガイドの記事
・自治体向け電子申請システム開発の完全ガイド

自治体向け電子申請システムとは何ですか？全体像をつかむ

自治体向け電子申請システムとは、住民や事業者がスマートフォンなどから申請・届出・予約を行い、職員が受付、審査、差し戻し、承認、交付、集計までをオンラインで処理する仕組みです。申請者向けの画面だけでなく、職員向けの審査画面、認証、決済、電子交付、LGWAN接続、既存システム連携まで含めて設計する必要があります。

フォームに入力されたデータが担当課の共有フォルダーに届くだけでは、職員が印刷、転記、担当振り分けを行うため、住民の入力負担が減っても庁内の負担は残ります。自治体向け電子申請システムでは、「手続き検索→入力→本人確認→添付→受付→審査→差し戻し→承認→基幹登録→通知・交付→保管」という一連の状態を定義し、どの段階を自動化するかを決めます。

特に重要なのは、オンライン化率だけを目標にしないことです。窓口来庁数、職員の転記時間、処理日数、差し戻し率、オンライン完結率、問い合わせ件数を手続き別に測定すると、導入効果を予算要求や次年度の拡張計画に結び付けやすくなります。

方式は大きく、マイナポータルの「ぴったりサービス」を活用する方法、電子申請SaaSやASPを導入する方法、標準パッケージに連携開発を加える方法、独自にスクラッチ開発する方法に分かれます。手続きの種類、本人確認の厳格さ、既存基幹システムへの登録要件、独自の審査ルールを基準に選ぶことが大切です。

デジタル庁が2026年6月に公開した電子申請等APIでは、自治体のWebサイトやアプリからぴったりサービスの手続き検索・申請機能を呼び出す選択肢が示されています。認証、手続き検索、申請データ送信、電子署名データ送信、処理状況照会などのAPIが用意されていますが、利用申請からサービス開始までの参考期間は約半年から1年です（出典: デジタル庁「電子申請等API」、2026年6月公開・7月更新）。短期導入を優先する場合は、既存SaaSや標準機能との比較を行います。

住民側では、手続きの検索、スマートフォン対応、入力補助、条件分岐、添付ファイル、申請状況の照会、受付・補正依頼の通知、電子文書の受け取りが基本機能です。高齢者、障害のある方、外国人、スマートフォン操作に不慣れな方も利用できるよう、やさしい日本語、十分な文字サイズ、キーボード操作、エラー内容の分かりやすさを確認します。

職員側では、LGWANからの受付確認、担当課への振り分け、審査・承認、差し戻し、期限管理、帳票出力、CSVやAPIによる連携、権限管理、操作ログ、バックアップが重要です。本人確認も全手続きでマイナンバーカードを必須にするのではなく、申請リスクに応じてメール認証、属性確認、公的個人認証、電子署名を使い分けます。

自治体向け電子申請システムの進め方｜6フェーズで整理する

進め方は、システムを先に選ぶのではなく、対象手続きと業務フローを整理してから方式を比較する順番が基本です。6フェーズを一気に進めるのではなく、各フェーズの完了条件を文書化し、次に進んでよいかを庁内で確認すると、後からの追加費用や責任分界の曖昧さを抑えられます。

最初に、全庁の手続きを件数、繁忙期、来庁負担、添付書類、本人確認、手数料、審査担当、基幹登録の有無で棚卸しします。デジタル庁は、子育てや介護など住民の利便性と業務効率化の効果が高い手続きを整理し、56手続を優先的にオンライン化する考え方を示しています（出典: デジタル庁「行政手続のオンライン化」、2026年6月更新）。優先順位は国の対象手続きだけで決めず、自自治体での処理件数と職員の作業時間を掛け合わせて決めます。

要件整理では、現行の紙様式をそのまま画面にするのではなく、申請者が入力する項目、自治体が確認できる情報、添付を省略できる情報を分けます。申請受付後の審査担当、差し戻しの条件、再申請の扱い、通知方法、保存年限、基幹システムへの登録者まで決めると、開発会社から同じ前提で見積もりを取れます。

完了チェックとして、対象手続き一覧、現行業務フロー、To-Be業務フロー、利用者区分、本人確認レベル、連携先、KPI、初回リリース範囲の7点を承認します。最初から全庁の全手続きを対象にせず、1〜3手続きでパイロットを行い、結果を見て拡張する設計が現実的です。

方式選定では、SaaS・ASP、パッケージ、ぴったりサービス連携、個別開発を、初期費用だけでなく5年間の総保有コストで比較します。SaaSは標準機能を早く使い始めやすく、制度改正や脆弱性対応をサービス側に任せやすい一方、独自の審査やデータ構造に制約が出る場合があります。スクラッチは業務に合わせやすい一方、更新費用、担当者交代、ベンダーロックイン、終了時の移行負担を見込む必要があります。

RFPには、機能一覧だけでなく、LGWANとインターネットの接続方式、基幹システムとのデータ連携、認証・電子署名、決済、電子交付、アクセシビリティ、監査ログ、バックアップ、障害時の連絡時間、再委託、データ返却、契約終了後の削除方法を記載します。提案評価では、デモ画面の見栄えより、差し戻しや例外処理を含む実際の業務シナリオを操作してもらいます。

候補会社には、自治体の導入実績だけでなく、同規模・同じ基幹製品との連携経験、制度改正への対応方法、職員がフォームを追加できる範囲、問い合わせ窓口、データエクスポート形式を確認します。価格が安くても、手続き追加のたびに開発会社へ依頼する契約であれば、全庁展開のコストが膨らむためです。

設計では、住民向け画面、職員向け審査画面、連携サーバ、ログ管理、権限管理、通知、決済、電子交付を分けて整理します。ネットワークも、インターネット側で申請を受け付ける領域、LGWAN接続系で職員が審査する領域、個人番号利用事務系や基幹システムの領域を分離し、必要なデータだけをAPIや連携サーバで受け渡す構成が基本候補です。

フォーム設計では、質問を一画面に詰め込まず、条件分岐で不要な項目を表示しないようにします。住所や氏名などの重複入力を減らし、添付ファイルの容量、ファイル形式、ウイルスチェック、受付番号、控えの保存方法も決めます。電子署名が必要な手続きでは、署名対象のデータ、署名検証、失敗時の再申請まで設計に含めます。

開発契約では、標準機能で対応する部分、設定で対応する部分、個別開発する部分を区別します。画面、帳票、API、データ移行、テスト、研修、マニュアル、稼働後の改善を同じ作業項目にまとめると、見積もりが比較しにくくなります。成果物と受け入れ条件を機能ごとに分け、変更要求が出た場合の扱いも合意します。

テストは、正常に申請できるかだけでは不十分です。入力エラー、添付漏れ、本人確認失敗、決済失敗、差し戻し後の再提出、担当課変更、同時申請、期限超過、通知メール不達、基幹連携の重複送信まで、実際に起こり得る状態を試します。住民役、窓口担当、審査担当、管理者の役割ごとに操作シナリオを用意します。

非機能テストでは、繁忙期の同時アクセス、データ量、バックアップからの復旧、障害時の切り戻し、監査ログの検索、権限変更、脆弱性診断を確認します。高齢者や障害のある方が操作しやすいか、スマートフォンの画面で文字が切れないか、やさしい日本語になっているかも、担当課だけでなく実際の利用者に近い人を交えて評価します。

受け入れテストの合格条件には、重大障害ゼロ、未解決課題の一覧、データ連携の照合結果、操作マニュアル、障害連絡網、稼働判定者を明記します。テストで発見した仕様変更を無償修正と追加費用に分けるルールも、稼働直前ではなく契約時点で決めておくと安心です。

稼働前には、対象手続き、開始日、受付時間、メンテナンス時間、問い合わせ先、紙申請との併用期間を住民と職員に告知します。オンライン申請を開始しても、窓口で同じ内容を紙に書いてもらい、職員が再入力する運用が残れば効果が出ません。紙で受け付ける場合の登録方法や、オンライン申請を支援する窓口の役割もあらかじめ決めます。

初日の運用では、開発会社、情報政策担当、業務課、ヘルプデスクの連絡先を一本化し、申請が止まった場合の優先順位を決めます。本人確認、決済、電子交付、基幹登録のどこで止まっているかを追跡できるよう、受付番号とログの見方を職員に説明します。大きな制度改正や給付開始の前には、実データに近い件数でリハーサルを行います。

稼働後1か月は、オンライン申請数だけでなく、未完了率、差し戻し理由、問い合わせ内容、処理時間、職員が手作業で補正した件数を毎週確認します。利用が少ない場合も、システムの失敗と決め付けず、手続きページの見つけやすさ、広報、入力項目、本人確認の負担を分解して改善します。

定着フェーズでは、職員が手続きの追加や文言の修正を行える範囲を明確にします。すべてを開発会社への依頼にすると、制度改正や繁忙期に対応できず、フォームが古いまま残ります。逆に、権限を広げすぎると個人情報や審査ルールの設定を誤るため、作成、承認、公開、停止の権限を分けます。

月次では、手続き別の申請数、完了率、差し戻し率、平均処理日数、問い合わせ件数、窓口削減時間、障害件数を確認します。四半期ごとには、利用されていないフォーム、添付書類が多いフォーム、特定の端末で離脱が多いフォームを洗い出します。評価指標を見ながら、入力項目の削減や審査ルールの見直しを行うことが、電子化を定着させる近道です。

契約更新時には、制度改正対応の範囲、サポート時間、価格改定、API仕様の変更、ログ保存、バックアップ、データ返却、他社サービスへの移行条件を確認します。5年後に別のサービスへ移行する可能性を前提に、データ形式、項目定義、ファイル添付、申請履歴を自治体が利用できる状態にしておくと、将来の調達で選択肢を失いにくくなります。

自治体向け電子申請システムの費用相場と内訳

自治体向け電子申請システムの費用は、人口や手続き数、認証レベル、決済・電子交付、基幹連携、データ移行、研修の有無で大きく変わります。したがって、単一の相場を断定するのではなく、導入方式別のレンジと、見積もりに含まれる作業を分けて見ることが必要です。

リサーチノートと自治体の公開契約例を組み合わせると、目安は次のように整理できます。小規模自治体がフォーム数を絞ってSaaSを導入し、基幹連携を行わない場合は、初期費用0〜300万円、年間100〜500万円程度、期間1〜3か月が一つの目安です。複数課で決済、電子交付、研修まで行う標準導入では、初期300〜1,500万円、年間300〜1,500万円程度、期間3〜6か月が目安になります。

大規模自治体でSSO、API、複数の基幹システム連携を含める場合は、初期1,000万〜1億円、年間1,000万〜3,000万円程度、期間6〜12か月が目安です。独自審査、複数基幹、移行、高可用性まで含むスクラッチ開発では、初期5,000万〜3億円以上、期間9〜24か月となるケースもあります。これらは案件条件に基づくレンジであり、特定自治体の契約額をそのまま自自治体の予算とみなすものではない点に注意が必要です。

公開契約例では、伊東市の2024年度「汎用電子申請システムサービス使用契約」が年107万8,440円、熊本市の2025年度「くらしの手続きガイドクラウドサービス利用料」が171万6,000円です。一方、熊本市ではLoGoフォームの電子文書交付追加と汎用メール追加が各1,000通/月あたり11,000円、オンライン決済の指定納付受託業務が納付額の3.5%という従量項目も公開されています。これは（出典: 伊東市「令和6年度分随意契約調査表」、熊本市「令和7年5月契約状況」、いずれも2025年公開）に記載された情報です。

さらに、名古屋市の2026年度「電子申請システムのサービス提供及びシングルサインオン開発業務委託」は1億296万円でした。これは大都市向けのサービス提供とSSO開発を含む契約であり、年額のSaaS利用料と同じ種類の費用ではありません（出典: 名古屋市「落札者等の公示」、2026年5月）。公開金額を比較するときは、利用料、構築、連携、運用保守、従量課金のどれが含まれるかを必ず分解します。

費用は、要件整理・調達支援、初期設定・フォーム作成、個別開発・API連携、テスト・移行・研修、月額または年額の利用料、保守・改善の6つに分けます。決済手数料、SMSやメールの通数、電子文書交付、ストレージ、本人確認、電子署名、アクセス超過などの従量課金が別にある場合は、繁忙期の利用量を入れて試算します。

運用費は、初期開発費の5〜15%程度を保守費の目安とする一般的な考え方がありますが、自治体向けでは制度改正、脆弱性対応、監査、24時間障害対応、フォーム追加、職員研修が含まれるかで変わります。安価な保守費だけを選ぶのではなく、何時間までの問い合わせや改修が含まれるか、休日や夜間の障害連絡が可能かを確認します。

予算計画は、初年度、2年目以降、5年間の総額を分けると説明しやすくなります。初年度には構築・移行・研修が集中し、2年目以降には利用料、保守、制度改正、手続き追加が発生します。契約終了時のデータ抽出や移行支援を別料金にする事業者もあるため、更新しない場合の費用まで見積もりに含めます。

見積もりを取る際のポイントとチェックリスト

見積もりの精度は、発注側がどれだけ業務と前提条件を明らかにできるかで決まります。機能名を並べた一覧だけを渡すと、各社が異なる前提で見積もるため、価格差の理由が分かりません。対象手続き、想定件数、ピーク時の同時利用、連携先、データ保存年限、職員数、研修対象を同じ様式で提示します。

仕様書には、対象手続きと利用者、業務フロー、画面・帳票、認証、電子署名、添付、決済、電子交付、通知、検索、権限、ログ、バックアップ、連携、移行、研修、保守を記載します。特に「既存システムと連携すること」だけで済ませず、連携項目、データ形式、送信頻度、エラー時の再送、重複防止、責任分界を示します。

セキュリティ面では、通信・保存時の暗号化、アクセス制御、管理者権限、脆弱性診断、ログの保存期間、インシデント報告、再委託先の管理、データセンターの所在地、バックアップと復旧目標を確認します。行政機関等の個人情報を扱うため、個人情報保護委員会の行政機関等向けガイドラインを踏まえ、委託先の監督・監査・事故報告を契約条項に落とし込みます。これは（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（行政機関等編）」）に基づく確認です。

相見積もりでは、初期費用、年間利用料、連携開発、保守、従量課金、オプション、移行、研修、契約終了時の費用を同じ列に並べます。会社ごとに「標準機能」「設定」「個別開発」「対象外」を表示してもらうと、最安値に見える提案が必要な作業を別料金にしていないか判断できます。

比較の評価軸は、価格だけでなく、自治体実績、既存基幹との連携、LGWAN対応、API公開、制度改正への対応、職員の内製運用、アクセシビリティ、障害対応、データ返却、ベンダーの継続性を含めます。提案会社には、実際の手続きシナリオでデモを依頼し、申請者、受付担当、審査担当、管理者それぞれの操作を確認します。

よくある失敗は、紙様式をそのままフォーム化して入力項目が多くなること、申請受付後の審査や基幹登録を設計しないこと、紙とオンラインの二重運用が続くこと、制度改正の費用負担が曖昧なことです。対策として、対象手続きごとに現行とTo-Beの業務フローを作り、処理時間と作業者を比較します。

もう一つのリスクは、サービス終了時にデータを取り出せないことです。契約前に、申請データ、添付ファイル、申請履歴、監査ログ、マスターデータをどの形式で、何営業日以内に、どの費用で返却できるかを質問します。再委託先、障害時の責任、個人情報の削除証明、価格改定の通知期間も、調達担当と情報政策担当で確認します。

よくある質問（FAQ）

ここでは、導入前に自治体担当者から寄せられやすい質問に回答します。費用や期間は案件条件によって変わるため、公開契約例と一般的なレンジを分けて考えることが重要です。

フォーム数が少なく基幹連携を行わないSaaS導入では、初期0〜300万円、年間100〜500万円程度が一つの目安です。複数課、決済、電子交付、研修を含む標準導入では初期300〜1,500万円程度、大規模なSSO・API・基幹連携では初期1,000万〜1億円程度のレンジもあります。対象範囲と従量課金をそろえて比較し、自自治体の条件で個別見積もりを取得します。

標準的なSaaS導入で対象手続きが少なければ1〜3か月、複数課の設定、決済、電子交付、研修まで行う場合は3〜6か月程度が目安です。基幹システム連携や独自審査を含むと6〜12か月以上、スクラッチ開発では9〜24か月となる場合があります。ぴったりサービスの電子申請等APIを新たに利用する場合、デジタル庁は利用申請からサービス開始まで約半年〜1年を参考期間として案内しています。

国の標準的な手続きやマイナンバーカードを使った本人確認を重視する場合は、ぴったりサービスの活用を優先して検討します。独自の予約、アンケート、施設利用、細かな審査フロー、自治体独自の通知・決済を重視する場合は、SaaSや独自フォームが適することがあります。手続きごとに、認証レベル、入力体験、職員処理、基幹連携の4点を比較し、全てを一つの方式に統一しないことが現実的です。

通信・保存時の暗号化、本人確認、権限分離、監査ログ、脆弱性診断、バックアップ、復旧目標、障害時の報告、再委託先の管理、データ削除を確認します。インターネット、LGWAN接続系、個人番号利用事務系・基幹系を適切に分離し、連携データを必要最小限にすることも重要です。仕様書と契約書に責任分界と監査方法まで記載し、導入後も定期的に点検します。

まとめ｜自治体向け電子申請システムは業務全体から進める

自治体向け電子申請システムを成功させるには、システムの機能比較より先に、どの手続きを、誰のどの負担を、どこまで減らすかを決めます。そのうえで、要件整理、選定、設計・開発、テスト、稼働、定着の6フェーズを順に進め、各段階の完了条件を確認します。

費用は、年額利用料だけのSaaS導入から、SSO・基幹連携を含む大型開発まで幅があります。初期費用、利用料、個別開発、従量課金、保守、データ移行、研修、契約終了時の費用を分け、5年間の総額で比較します。住民の使いやすさと職員の業務削減を同時に評価し、まず少数手続きで成果を測ってから全庁展開につなげることが、無理のない進め方です。

稼働をゴールにせず、フォーム追加、制度改正、職員異動、監査、障害、データ返却までを含めて運用計画を作ります。導入後はオンライン完結率、処理時間、差し戻し率、問い合わせ件数を定期的に確認し、住民と職員の双方にとって使いやすい手続きへ改善を続けます。

▼全体ガイドの記事
・自治体向け電子申請システム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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