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

自治体向け電子申請システムとは、住民の申請をオンラインで受け付け、職員の審査・登録・通知・交付までを一つの業務フローとしてつなぐ行政DXの基盤です。

導入を検討するときは、フォームを作ることだけを目的にせず、どの手続きを、どの認証レベルで、どの既存システムへ連携し、職員の作業をどこまで減らすかを決めることが大切です。この記事では、自治体向け電子申請システムの全体像、機能、種類、進め方、費用相場、開発会社やサービスの選び方、導入後のKPI、よくある質問までを、2026年時点の制度・公開契約例を交えて解説します。

自治体向け電子申請システムの全体像

自治体向け電子申請システムは、住民・事業者がスマートフォンやパソコンから手続きを行い、自治体職員が受付から審査、承認、交付、保管までを管理する仕組みです。単なる入力フォームではなく、申請者側の画面と庁内の処理を一続きに設計する点に特徴があります。対象業務の範囲と個人情報の種類によって、必要な認証・ネットワーク・連携方式が変わります。

Webフォームではなく業務全体を扱う仕組みです

一般的なWebフォームは、入力された内容をメールや一覧で受け取るところまでが中心です。一方、自治体向け電子申請システムでは、手続きの検索、入力補助、添付ファイル、本人確認、受付番号の発行、担当課への振り分け、審査、差し戻し、承認、手数料の決済、電子文書の交付、操作ログの保存までを管理します。受付後に職員が紙へ転記したり、別の基幹システムへ手入力したりする場合は、住民の利便性が上がっても庁内の負担が残ります。そのため、最初に「申請受付→審査→基幹登録→通知・交付→保管」の流れを可視化する必要があります。

対象になる手続きは申請・届出・予約・支払いです

対象になりやすいのは、子育て・介護・福祉の申請、転出届や住所に関する届出、各種証明書の請求、施設予約、粗大ごみの収集申込、イベント参加、事業者向けの許認可申請、アンケート、手数料を伴う申請などです。まずは申請件数が多く、来庁や郵送の負担が大きく、審査手順が比較的標準化されている手続きを選ぶと効果を確認しやすいです。本人確認や原本提出が必要な手続きでも、事前入力、予約、添付書類の案内までをオンライン化するだけで、窓口滞在時間を短縮できます。

住民の利便性と職員の処理効率を同時に見ます

住民にとっての価値は、窓口へ行かずに申請できることだけではありません。スマートフォンで入力しやすいこと、途中保存できること、必要書類が事前に分かること、受付や差し戻しの状況を確認できることが重要です。高齢者、障害のある人、日本語を読むことに不慣れな人も利用できるよう、文字サイズ、色のコントラスト、キーボード操作、やさしい日本語、窓口での入力支援を組み合わせます。職員側では、転記時間、担当課への振り分け、差し戻し通知、期限管理、集計作業を減らせるかを確認します。

主要機能と自治体向けのシステム構成

主要機能は、申請者向け、職員向け、連携・運用向けの三つに分けて整理すると要件を漏らしにくいです。特に自治体では、インターネット側の申請画面、LGWANから利用する職員画面、個人番号利用事務系や基幹システムを適切に分離し、必要なデータだけを連携させる設計が求められます。

申請者向けには迷わず完了できる画面を用意します

申請者向けの基本機能は、手続き検索、スマートフォン対応フォーム、条件分岐、入力チェック、添付ファイル、途中保存、メール認証、申請状況照会、受付・差し戻し通知です。手数料がある場合は、金額計算、オンライン決済、領収情報の案内を追加します。証明書や通知書を電子交付する場合は、交付後の閲覧期限、再発行の扱い、本人以外への誤送付を防ぐ仕組みも要件に入れます。入力項目を紙の申請書からそのまま移すのではなく、住民がすでに持っている情報を再入力させないことが、離脱率を下げるポイントです。

職員向けには審査と引き継ぎを標準化します

職員向けには、LGWANからの受付確認、担当課や担当者への振り分け、審査、差し戻し、承認、期限管理、帳票出力、CSVやAPIによるデータ連携、操作ログ、権限管理が必要です。担当者が異動しても同じ品質で処理できるよう、審査基準、差し戻し理由、処理期限、通知文面をシステム上で標準化します。繁忙期に申請が集中する手続きでは、同時アクセス数、添付ファイル容量、通知の遅延、再送処理、障害時の受付継続方法を負荷試験で確かめます。

ネットワーク分離と連携境界を先に決めます

自治体向けの構成では、住民がアクセスするインターネット側と職員が審査するLGWAN接続系を分け、連携サーバやAPIゲートウェイを介して申請データを受け渡す方式が基本候補です。個人番号利用事務系や住民情報系の基幹システムへは、必要な項目・タイミング・エラー時の戻し方を定義してから接続します。個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（行政機関等編）」、2026年確認のガイドラインでは、アクセス権限を業務上必要な最小限に限定すること、委託先・再委託先の選定や監査に関する条項を契約へ盛り込むことが示されています。

マイナポータルと独自フォームはどちらを選ぶべきですか？

結論から言うと、どちらか一方に統一するのではなく、手続きの標準性、本人確認の厳格さ、基幹システム連携、住民の導線で使い分けます。国の標準的な手続きやマイナンバーカードを使った本人確認が重要な申請はマイナポータルとの連携を検討し、自治体独自の予約・アンケート・施設利用・イベント申込などは独自フォームや汎用SaaSが適しています。

マイナポータル連携は標準手続きと本人確認に向いています

マイナポータルのぴったりサービスは、子育てや引っ越しをはじめとする自治体手続きの検索・申請に利用できます。デジタル庁「電子申請等API」、2026年6月16日公開・7月24日更新の資料では、自治体のWebサイトやアプリから手続き検索、認証、申請、処理状況照会などを組み込む選択肢が明確になったと説明されています。住民が普段使う自治体サイトから申請へ誘導しつつ、既存の受付・申請データ処理機能を活用できる点が利点です。ただし、API利用申請から利用開始までの参考期間は約半年から1年と示されているため、実装や審査の期間を調達計画に含めます。

独自フォームは自治体固有の業務と短期展開に向いています

独自フォームは、自治体独自の設問、予約枠、抽選、添付資料、複数課の承認などを柔軟に設計しやすい方式です。職員が新しい手続きを追加できるノーコード型や、標準機能を組み合わせるSaaS・ASP型であれば、数手続きの試行を短期間で始めやすいです。一方、独自フォームを増やしすぎると、住民が手続きごとに別の画面やアカウントを使うことになります。入口の統一、検索性、認証の共通化、データの保存先を設計してから導入します。

選定時は手続き単位で連携方式を比較します

連携方式を選ぶときは、手続きを四つの軸で分類すると判断しやすいです。第一に、本人確認がメール認証で足りるか、公的個人認証や電子署名が必要かを整理します。第二に、審査後のデータを基幹システムへ登録する必要があるかを確認します。第三に、申請者へ電子文書を交付するか、来庁や郵送を残すかを決めます。第四に、件数の季節変動、制度改正の頻度、職員がフォームを追加する頻度を見積もります。この整理をすると、マイナポータル、独自フォーム、パッケージ連携、個別開発を混在させても、重複投資を抑えられます。

自治体向け電子申請システムの進め方

導入は、製品を選んでから手続きを合わせるのではなく、現状業務を棚卸ししてから方式と予算を決めます。企画、要件定義、調達、設計・開発、テスト、パイロット、全庁展開、運用改善の順に区切り、各段階で成果物と判断基準を明確にします。

▶ 詳細はこちら：自治体向け電子申請システム開発の進め方/やり方/流れや方法/手法/工程/手順

企画段階で手続きと業務フローを棚卸しします

最初に、手続きごとの年間件数、繁忙期、来庁回数、郵送の有無、添付書類、本人確認、手数料、担当課、審査日数、基幹システムへの登録先を一覧化します。住民へのヒアリングだけでなく、窓口職員がどの入力を転記し、どの不備で差し戻し、どの帳票を作成しているかを確認します。候補を一度に全庁へ広げるのではなく、件数が多く、処理手順が安定し、効果を数字で測りやすい1〜3手続きから始めると、投資判断を説明しやすいです。

要件定義と調達では機能以外を仕様化します

要件定義では、画面機能だけでなく、可用性、バックアップ、復旧目標、暗号化、アクセス制御、監査ログ、脆弱性診断、負荷試験、障害連絡、再委託、データ返却・削除、仕様書の引き渡しを仕様書へ記載します。調達担当者は、SaaS利用料、初期設定、フォーム作成、連携開発、研修、保守、制度改正対応を分けて見積もるよう求めます。契約期間、更新時の価格改定、データの所有権、サービス終了時のエクスポート形式まで確認すると、乗り換え時の予想外の費用を減らせます。

設計・開発・テストは実業務で段階確認します

設計では、住民の画面と職員の審査画面を別々に作らず、申請が届いてから完了するまでの状態遷移を定義します。開発後は、正常な申請だけでなく、添付漏れ、重複申請、差し戻し、代理申請、決済失敗、基幹連携エラー、担当課変更、通知の再送をテストします。パイロットでは実際の職員と住民に近い利用者が操作し、入力時間、問い合わせ、差し戻し理由、処理日数を計測します。デジタル庁「行政手続のオンライン化」、2026年6月更新の方針によると、2026年時点で国の行政手続オンライン化はスマートフォン等で手続きを完結させる方向で進んでいます。そのため、パソコン前提の画面を後付けでスマートフォン対応にする計画は避けます。

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

費用は、自治体の人口や手続き数だけでなく、本人確認、決済、電子交付、既存基幹システムとの連携、LGWAN接続、データ移行、職員研修、保守の範囲で大きく変わります。以下は標準的な機能を使うケースから個別開発までを含めた概算の目安です。公開された一律料金ではないため、予算要求の初期仮説として使い、要件を固めた段階で複数の見積もりへ置き換えます。

▶ 詳細はこちら：自治体向け電子申請システム開発の見積相場や費用/コスト/値段について

導入方式別の初期費用と期間の目安です

小規模自治体がフォーム数を絞ってSaaSを導入し、基幹連携を行わない場合は、初期費用0〜300万円、年間の利用・運用費100〜500万円、導入期間1〜3か月が一つの目安です。複数課で決済・電子交付・研修まで行う標準導入では、初期費用300〜1,500万円、年間費用300〜1,500万円、期間3〜6か月程度を見込みます。大規模自治体でシングルサインオン、API、複数の基幹システム連携を含む場合は、初期費用1,000万円〜1億円、年間費用1,000万〜3,000万円、期間6〜12か月程度となる場合があります。独自審査、複数基幹、データ移行、高可用性を含むスクラッチ開発では、5,000万円〜3億円以上、期間9〜24か月を想定することもあります。

公開契約例は金額の内訳を分けて読みます

実際の公開契約を見ると、伊東市の2024年度資料には汎用電子申請システムのサービス使用契約が年間107万8,440円と記載されています。また、伊東市「令和6年度分随意契約調査表」および熊本市「令和7年5月契約状況」、2024・2025年度契約の資料には、手続き案内のクラウド利用料が年間171万6,000円、電子文書交付の追加が1,000通/月あたり11,000円、汎用メールの追加も1,000通/月あたり11,000円、オンライン決済の指定納付受託業務が納付額の3.5%と記載されています。これらはサービス利用やオプションの金額であり、全庁連携の開発費や庁内の運用人件費を含む総額ではありません。

大規模案件はサービス費と開発費を一つにしません

名古屋市「名古屋市電子申請システムサービス提供及びシングルサインオン開発業務委託」落札公示、2026年の公開契約には、電子申請システムのサービス提供とシングルサインオン開発を合わせた業務が1億296万円と記載されています。この金額は、単純なフォーム利用料の相場ではなく、大都市向けのサービス提供と認証基盤の開発を含む契約例です。見積もりを比較するときは、初期構築、月額・年額利用、申請件数や通知数に応じた従量課金、決済手数料、基幹連携、保守、制度改正、職員研修を分けて確認します。5年分の総保有コストで比べると、初期費用が安い方式でも、従量課金や追加開発が大きい場合に順位が変わります。

SaaS・パッケージ・スクラッチ開発の違い

方式選定では、短期導入、柔軟性、連携範囲、制度改正への追随、運用負担、データ移行のしやすさを比較します。住民向けの画面だけでなく、職員が手続きを追加・修正できるか、障害時にどこまで自庁で確認できるか、契約終了時にデータを取り出せるかまで確認すると、導入後の差が見えます。

SaaS・ASP型は早く始めて改善したい自治体向けです

SaaS・ASP型は、サービス提供側の基盤やセキュリティ更新を利用し、自治体側のサーバー設置や保守を抑えやすい方式です。フォーム作成、申請状況管理、通知、集計などを標準機能で使える場合は、1〜3手続きのパイロットを始めやすいです。制度改正や脆弱性対応がサービス側の更新に含まれるか、データの保存場所、バックアップ、障害時の復旧目標、LGWANからの利用可否、再委託先、サービス終了時のデータ返却を契約前に確認します。独自の審査や複雑な基幹連携を標準機能だけで無理に実現すると、運用での手作業が増えるため注意が必要です。

パッケージ＋連携開発は標準機能と固有業務を両立します

パッケージを基盤にして、自治体固有の審査、帳票、認証、基幹連携だけを追加する方式は、標準化と柔軟性のバランスを取りやすいです。すべてを個別に作るより初期費用や保守の範囲を抑えやすく、標準機能のアップデートも利用できます。ただし、標準機能に合わせて業務を変える範囲と、個別機能として残す範囲を決めないと、追加開発が積み上がります。連携仕様、エラー処理、マスタの責任部署、制度改正時の改修費を要件定義の段階で文書化します。

スクラッチ開発は独自性より長期運用を重視します

スクラッチ開発は、独自の審査、複数の基幹システム、特殊なデータ連携、高い可用性など、標準サービスで対応しにくい要件に向いています。一方、制度改正、OSやミドルウェアの更新、脆弱性対応、職員異動、仕様書の不足、担当ベンダーへの依存が長期的な負担になります。開発費だけで判断せず、5年間の保守費、改修費、監視費、テスト費、データ移行費、終了時の引き継ぎ費まで含めて検討します。独自開発を選ぶ場合でも、共通的な認証、通知、ログ、申請状態管理は再利用可能な部品として設計すると、将来の手続き追加を進めやすいです。

自治体向け電子申請システムの開発会社・ベンダーの選び方

発注先は、知名度や機能一覧だけでなく、自治体の業務を整理し、調達から運用まで責任を持って伴走できるかで選びます。既製サービスを提供する事業者と、基幹連携や個別開発を担う開発会社では役割が異なるため、必要な範囲を明確にしてから比較します。提案書の機能数より、実際の業務フローと5年運用の見通しが説明されているかを重視します。

自治体実績は件数ではなく業務範囲を確認します

実績を聞くときは、「自治体への導入数」だけで終わらせません。人口規模、対象手続き数、LGWAN接続、マイナポータル連携、基幹システム連携、決済、電子交付、職員が自らフォームを追加できる範囲、導入後の問い合わせ・研修体制を同じ条件で質問します。可能であれば、同規模の自治体で、オンライン完結率や処理時間がどう変わったかを確認します。導入事例の数字が想定値なのか、稼働後の実測値なのかも区別します。

セキュリティと契約条件は提案段階で確認します

確認項目には、保存場所、暗号化、認証、権限分離、監査ログ、バックアップ、復旧時間、脆弱性診断、インシデント報告、再委託先、国外での取扱い、データ返却・削除を含めます。個人情報を扱う委託では、委託先の選定基準、アクセスを認める情報とシステムの範囲、監査方法を契約へ落とし込めるかが重要です。障害時に自治体が受付状況や申請データを確認できるか、復旧までの代替受付をどうするかも、平常時のデモだけでは分からないため、提案書とSLAで確認します。

見積もりは同じ前提と5年総額で比較します

相見積もりでは、対象手続き、想定申請件数、利用者数、添付容量、連携先、認証方式、研修回数、保守時間、制度改正の回数をそろえます。提案ごとに前提が違うまま金額だけを比べると、安い提案に見えても、後から連携開発や追加フォーム作成が発生します。見積書は、初期費用、月額・年額、従量課金、連携、移行、テスト、研修、保守、追加改修、終了時のデータ出力に分け、5年間の費用と自治体側の作業時間を並べて評価します。

▶ 詳細はこちら：自治体向け電子申請システム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：自治体向け電子申請システム開発の発注/外注/依頼/委託方法について

導入後に失敗しない運用とKPI

電子申請は稼働開始がゴールではなく、手続きの追加、制度改正、職員異動、問い合わせ対応、障害対応、監査、データ移行を含めて初めて定着します。申請件数だけを見ると、便利になったのに職員の作業が減っていない状態を見落とします。住民と職員の両方の行動を測り、改善を続ける運用体制を作ります。

紙とオンラインの二重運用を減らします

よくある失敗は、オンラインで受け付けた申請を職員が印刷し、紙の申請と同じ手順で転記・回覧することです。移行期に紙を残す場合でも、オンライン申請のデータを審査画面で確認し、基幹システムへ連携する流れを先に整えます。紙でしか受け付けられない人への窓口支援を用意しながら、オンライン申請の処理を別ルートにしないことが重要です。手続きごとに、オンライン申請を受けた後に発生する作業を一つずつ廃止・統合できないか見直します。

オンライン化率以外のKPIも設定します

基本KPIは、オンライン申請率、オンライン完結率、申請完了までの時間、窓口来庁回数、職員の転記時間、審査の処理日数、差し戻し率、問い合わせ件数です。手続きの特性に応じて、添付書類の削減数、決済完了率、電子交付率、スマートフォンでの完了率、アクセシビリティに関する問い合わせ、住民満足度も加えます。導入前の直近1〜3か月を基準値とし、パイロット後、全庁展開後、制度改正後に同じ指標を比較します。

5年運用の担当者と改善費を確保します

フォームの追加や修正を誰が行うか、制度改正の要件を誰が整理するか、障害時に誰が住民へ告知するかを、情報政策部門と業務課の役割として決めます。職員異動のたびに操作方法が分からなくならないよう、手順書、研修、権限申請、問い合わせ窓口を整備します。導入初年度だけでなく、毎年の制度改正、アクセシビリティ改善、脆弱性対応、APIや基幹システムの変更に使う予算を確保します。サービス終了や乗り換えに備え、データ形式、保存期間、エクスポート手順を定期的に確認することも大切です。

自治体向け電子申請システムのよくある質問

自治体向け電子申請システムでは、費用、マイナンバーカードの要否、既存システムとの連携について多くの質問があります。導入前に確認しておきたいポイントを、実際の調達・運用で判断しやすい形に整理します。

自治体向け電子申請システムの導入費用はいくらですか？

小規模なSaaS導入なら初期0〜300万円、年間100〜500万円程度が一つの目安ですが、連携や認証を含めると数百万円から1億円超まで幅があります。公開契約例も、年間100万円台のサービス利用から、シングルサインオン開発を含む1億296万円まで差があるため、利用料・従量課金・連携開発・保守を分けて比較します。

マイナンバーカードを持っていない住民も申請できますか？

手続きのリスクに応じて、メール認証、属性確認、公的個人認証などを使い分ければ、マイナンバーカードを必須にしない受付も設計できます。ただし、厳格な本人確認や電子署名が必要な手続きでは、カードや別の確認方法が必要です。対象手続きごとに認証レベルを決め、カードを使えない人への窓口支援や代替手段も案内します。

既存の住民情報システムや基幹システムと連携できますか？

連携できますが、すべての手続きでリアルタイム連携が必要とは限りません。申請後に職員が確認してCSVで取り込む方式、APIで自動登録する方式、基幹側へ結果だけ返す方式などを、処理量・個人情報・エラー時の対応で選びます。要件定義では、連携項目、文字コード、重複判定、エラー時の再送、責任分界、監査ログを具体化します。

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

基幹連携のない小規模なSaaS導入なら1〜3か月、複数課・決済・電子交付を含む標準導入なら3〜6か月、SSOや複数基幹との連携を含む大規模案件なら6〜12か月が目安です。APIの利用申請やセキュリティ審査、調達手続き、住民向け周知、職員研修が加わると長くなります。稼働日から逆算せず、業務棚卸しと調達仕様書の作成に必要な期間を先に確保します。

まとめ

まとめとして、自治体向け電子申請システムを選ぶときに押さえるべき判断軸を整理します。手続き、費用、運用、効果測定を一体で考えることが、導入後の定着につながります。

導入判断で押さえる三つの要点です

第一に、システム選定より先に、対象手続きと業務フローを決めます。第二に、初期費用ではなく、認証・連携・保守・従量課金を含む5年総額で比較します。第三に、住民の使いやすさと職員の処理時間をKPIで測り、導入後も改善できる体制を確保します。

最初の一歩は対象手続きの選定です

まずは申請件数、来庁負担、処理時間、差し戻しの多さを基準に候補を絞り、1〜3手続きの現状業務を図にします。そのうえで、マイナポータル、独自フォーム、標準サービス、個別連携のどれを組み合わせるかを決め、同じ前提で複数の見積もりを比較します。

費用は年間100万円台のサービス利用から、認証・全庁連携を含む1億円規模まで幅があります。初期費用だけでなく、5年間の利用料、従量課金、連携、保守、制度改正、データ返却を比較し、オンライン完結率、処理日数、転記時間、差し戻し率、問い合わせ件数で効果を測定します。住民の使いやすさ、職員の運用、個人情報保護、障害時の責任分界を同じ要件表で確認することが、持続的な行政DXにつながります。