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

電子申請システム開発は、対象手続の洗い出し、本人確認と連携の設計、段階的な導入の順に進めると、申請から審査、交付までの業務をデジタル化できます。

全体像、開発の工程、費用相場、見積もりの確認点の順に取り上げます。全体像は電子申請システム開発の完全ガイドもご覧ください。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

電子申請システム開発の全体像

電子申請システムは、住民や事業者が窓口へ行かずに行政手続きを申請し、行政側が受付から処理完了までを管理する仕組みです。対象には、届出、証明書請求、給付申請があります。施設予約、講座やイベントの申込、事業者向け許認可申請なども対象です。

申請の入口だけで終わらせず、審査、差し戻し、決裁、手数料納付、通知書交付までつなげると、業務全体をデジタル化できます。

申請者向けと職員向けの機能の一体的な検討

発注側と開発会社は、申請から職員の処理までに必要な機能を、利用者ごとに整理しておきます。

• 申請者向け：手続検索、スマートフォン対応フォーム、入力チェック、途中保存
• 申請の継続：添付、状況照会、補正・再提出、メールやLINE通知
• 本人確認：手続に応じて公的個人認証サービス（JPKI）や法人向けGビズIDを使い分ける
• 職員の処理：受付確認、添付閲覧、審査、差し戻し、職権訂正、担当引き継ぎ、決裁
• 職員の管理：通知書作成、電子交付、一括処理、権限設定、操作履歴確認

住所や氏名の再入力を減らし、入力例やエラー箇所を画面で示す設計は、申請完了率に影響します。一方で、申請内容を別の基幹システムへ再入力する構成では、入力ミスと二重作業が残ります。

対象手続に必要な連携先は、早期に洗い出しておきます。候補には、住民記録、税、収納があります。このほか、福祉や文書管理、決裁、口座、施設予約などもあります。

ネットワーク分離・認証・監査ログの開発範囲

自治体向けでは、個人情報を扱う処理をインターネット側へ置かないよう、分離するネットワークとデータ経路を決めておく必要があります。認証や復旧の設計も、この開発範囲に含めます。

• ネットワーク：インターネット接続系、LGWAN接続系、個人番号利用事務系の分離と連携経路
• 情報保護：認証、認可、通信・保存データの暗号化、権限分離
• 運用継続：追跡可能な操作ログ、バックアップ、障害復旧、復旧目標
• クラウドの登録：ISMAPまたはISMAP-LIUへの登録状況
• クラウドの契約：保管場所、再委託先、脆弱性対応、事故通知、終了時の返却

ISMAPは、政府のセキュリティ要求を満たすクラウドを評価・登録する制度です。登録済みであっても、自治体の要件を満たすとは限りません。そのため、条件は仕様書や契約書で確認します。

操作ログには、誰がいつ申請を閲覧、変更、承認したかを残し、追跡できるようにします。

オンライン化率だけで判断しない導入効果の指標

オンライン化率に加えて、申請者と職員の負担や処理の質を測るKPIを、開発前に決めておきます。

• 申請状況：申請完了率、オンライン完結率
• 処理状況：不備率、差し戻し件数、審査時間、職員の処理時間
• 利用者対応：問い合わせ件数

利用件数が増えても、不備率が高いままだと、職員の確認作業が増えることがあります。

たとえば、川崎市では既存の汎用電子申請システムに操作ガイドを加え、迷いやすい項目を画面で案内しました。手続によって不備率が最大81.7％改善し、年間約105時間の業務削減につながったと紹介されています。

入力案内の改善は、大規模な改修をしなくても効果が出る場合があります。そのため、運用側は申請データや問い合わせを分析し、フォームを継続して改善します。

電子申請システム開発の進め方・工程

開発は、現状分析から運用改善まで次の順に進みます。途中の調査で課題が見つかった場合は、要件と計画に戻して確度を高めます。

1. 現状分析と対象手続の選定
2. 要件定義と方式比較
3. 認証・連携・セキュリティ設計
4. PoCまたは先行導入
5. 開発・設定、テスト
6. 研修・切替と運用改善

1. 現行業務と対象手続の洗い出し

発注側は、手続ごとに現況を記録し、申請から保管までを一続きの業務フローにまとめます。

• 手続情報：名称、担当課、年間件数、繁忙期、申請者、添付書類
• 審査・管理：本人確認、手数料、審査、決裁者、通知方法、保存年限
• 業務負荷：現在の処理時間、窓口確認、郵便物開封、台帳転記、補正連絡、保管

対象は件数だけで決めず、住民の移動負担、不備と職員工数、効果の測りやすさ、制度上の適性から選びます。

紙申請を残す場合は、同じ申請が二重に登録されないよう、併存期間の受付方法、データの正本、職員の手順を決めておきます。

2. 共通機能と手続固有の要件の切り分け

複数の手続で使う機能と、手続ごとに異なる機能を分けて整理します。

• 共通機能：アカウント、本人確認、入力チェック、添付、通知、決済、権限、監査ログ、バックアップ、申請状況照会
• 手続固有の機能：独自審査、資格判定、計算、代理申請、複数人同意、現地確認、電子交付条件

切り分けずに手続ごとに画面を作ると、認証や通知が重複します。その結果、変更があるたびに複数の箇所を直すことになります。

機能ごとの対応先を一覧にします。対応先は、共通基盤や標準SaaSの設定、周辺システム、個別開発のいずれかです。

各社の提案を同じ前提で比べられるよう、この一覧を共通の基準にします。

3. SaaS・ローコード・スクラッチの要件別比較

方式ごとに得意分野と制約が異なるため、要件に合う方式を選びます。

• 標準SaaS・パッケージ：標準業務に合えば導入を早めやすく、保守を任せやすい
• ノーコード・ローコード：職員が作成・修正でき、テンプレートも再利用できる
• スクラッチ開発：独自業務に合わせやすい一方、継続保守が必要

標準SaaSは、セキュリティ更新や法改正対応も含めて、認証や通知、申請管理を任せやすい方式です。

手続数が少なく標準フォームで足りる場合は、費用と期間を抑えやすくなります。

標準SaaSの場合、独自審査や特殊な画面制御、深い基幹連携には、制約が出る場合があります。

ローコードでは、複雑な業務ルールや厳格な権限分離があると、追加開発が必要になる場合があります。大規模な処理や双方向の連携も、追加で開発が必要になることがあります。

スクラッチは要件定義が長引きやすく、制度改正や脆弱性対応の費用も継続してかかります。

比べるときは、初期費用だけでなく、導入期間と5年間の総額も含めます。

手続を追加する際の単価や、内製スキルも確認します。

法改正の対応を誰が担うか、契約終了時のデータ返却、ベンダーロックインの有無も比べます。

代表的な手続でPoCを行い、申請完了率や不備率を確かめてから、ほかの手続へ広げる進め方もあります。

4. 本人確認・決済・ネットワーク連携の設計

本人確認の水準や支払い、連携の条件は、手続ごとに決めておきます。そのうえで、例外が起きたときの処理も、あわせて設計します。

• 本人確認：なりすましの影響、手続の重要性、署名、代理申請、証跡を基準にする
• 決済：電子納付、返金、決済失敗時の再申請、領収情報の保管
• 電子署名：検証結果、署名時刻、証明書の状態、対象データを記録する
• ネットワーク連携：連携項目、送信頻度、再送、重複防止、停止時の手作業

JPKIは本人確認や電子署名に使えますが、端末環境や暗証番号の入力への配慮も必要です。

事業者向けではGビズIDが適する場合もあり、申請の導線と本人確認の負担は分けて考えます。

手数料がある場合は、カード等のオンライン決済も設計します。

連携先には、LGWANや個人番号利用事務系も含まれます。

5. テスト・研修・本番切替・KPI改善

本番前のテストと研修では、申請の開始から処理の完了、障害対応までを通して確認します。

• 試験：単体、連携、業務シナリオ、受入、セキュリティ、負荷、移行リハーサル
• 業務確認：入力、本人確認、添付、受付、審査、差し戻し、再提出、決裁
• 完了確認：決済、通知、交付、保存まで通して試す
• 例外・障害確認：添付漏れ、期限切れ、決済失敗、二重送信、権限外閲覧、連携停止、通知不達
• 研修：差し戻し、代理処理、誤登録訂正、問い合わせ、障害時の受付継続

受入基準は画面の表示だけにせず、申請データが正しいシステムへ届くことや、処理期限、ログ、帳票出力、障害時の手作業への切替も含めます。

2025年4月から、先行実証に参加する自治体で次期オンライン申請サービスの受付が始まっています。さらに、2026年9月以降は本格運用も予定されています。

焦点は、住所の再入力と保有情報の転記です。補正連絡と通知のオンライン化も、対象に挙がっています。そのため、国のサービスとの連携箇所を確認しておくと、将来の重複投資を避けられます。

電子申請システムの費用相場

電子申請システムの初期費用は、方式と連携範囲によって、0〜150万円から3,000万円〜1億円超まで幅があります。費用は、規模と機能の両方で変わります。

規模では、人口、申請件数、手続数、職員数が関わります。機能では、本人確認、署名、決済、通知、連携が関わります。さらに、LGWAN構成、移行、保守も費用に影響します。

公定価格や市場全体の平均額はありません。以下の例は、公開されている料金例と公共系の工程感をもとにした予算検討の目安です。正式な予算を立てる段階では、同じ要件で複数社から見積もりを取ります。

方式別では、小規模SaaSが初期0〜150万円、自治体向け標準SaaSが100〜500万円、SaaS＋基幹・決裁・LGWAN連携が300〜1,500万円です。個別開発・スクラッチは3,000万円〜1億円超です。

小規模SaaSでは、初期設定とフォーム作成を含めて100万円前後から始められる例があります。

行政向けSaaSの調査例では、初期が約120万円、月額が約18万円、5年間のTCOが約1,200万円です。

ここまでの例は、標準機能を複数課で使う場合の参考値です。市場平均でも、特定の自治体の確定価格でもありません。申請件数や連携範囲を含めて、発注側の条件で再計算します。

近接する行政SaaSの公開例では、導入458,400円、人口別の基本料金、月額30,000円、金融機関連携556,800円という構成になっています。ただし、これは電子申請そのものの価格ではありません。

行政向けの料金は、初期設定、規模別の基本料、月額利用料、連携オプションに分かれる例です。

利用者や申請件数が増えた場合に、従量課金がかかるかも確認します。

費用の内訳（開発費・連携費・運用費）の比較

標準SaaSの利用料だけで予算を組むと、連携、帳票、移行、職員研修が別費用になり、予算が足りなくなる場合があります。そのため、初期費用を分けて確認します。

• 導入準備：企画支援、現状分析、要件定義、フォーム作成
• 構築・接続：画面、ワークフロー、認証、署名、決済、通知、API、LGWAN
• 稼働準備：データ移行、テスト、研修、本番切替

運用費には、サービス料やクラウド基盤に加えて、監視、バックアップ、ヘルプデスク、障害対応が入ります。セキュリティ更新や法改正対応、フォーム追加、データ抽出、定期改善が、どこまで含まれるかも確認します。

1年分だけでなく、3年または5年の総額で比べます。利用料の改定条件や、申請が増えたときの従量課金も含めます。

追加フォームの単価や、解約時のデータ返却費用も、TCOに加えます。

電子申請システムの見積もりで確認すべきポイント

同じ要件書を複数社に渡し、初期費用、年間費用、追加費用、保守範囲をそろえて比べます。

提案書には、標準機能、設定変更、追加開発、対象外を明記してもらいます。

見積もりの金額が安く見えても、重要な機能が対象外になっていないかを確かめます。

まずRFIで選択肢を調べ、そのうえでRFPで要求水準と評価方法をそろえる進め方が有効です。

対象範囲と前提条件の明確化

各社の金額を比べられるように、見積依頼書の対象範囲と前提をそろえます。

• 利用規模：手続数、年間・繁忙期の件数、部署、職員数、同時利用者数
• 申請条件：添付容量、保存年限、通知・帳票・決済件数、本人確認方式
• 業務条件：手続の分岐、審査段階、権限、代理申請、再提出、電子交付
• 連携条件：接続先、API、連携項目・頻度、再処理、テスト環境

接続先には、住民記録、宛名、税・収納、福祉があります。さらに、文書管理、電子決裁、口座、マイナポータル、LINEなども含まれます。

連携が片方向か、審査結果や通知も戻すかで、費用が変わります。

連携先の改修費用を発注者と受託者のどちらが負担するかも、見積もりに明記します。

非機能要件・セキュリティ・受入条件の数値化

非機能の条件は測れる形にしておき、受入試験と必要な納品物も見積もりに含めます。

• 性能・復旧：稼働時間、可用性、応答時間、同時利用者数、バックアップ頻度、復旧時間・時点目標
• 保護・監視：ログ期間、暗号化、脆弱性診断、アクセス制御、監視、障害連絡時間
• 接続・監査：LGWAN等との構成、接続・認証方式、持ち出し制御、監査方法を図で示してもらう
• 受入条件：業務完了、連携一致、再提出、通知、操作ログ、代替運用
• 納品・運用資料：要件書、画面一覧、業務フロー、権限表、API一覧、テスト仕様、操作・運用手順書、データ返却手順

将来費用と契約終了時の条件の確認

初期費用だけでなく、制度改正や手続の追加、契約終了後までの条件も確認します。

• 保守・更新：法改正が保守料に含まれるか、別見積もりか
• 追加改修：文言変更・フォーム追加の単価、更新後の検証責任
• データ返却：申請、添付、審査、決裁、通知、操作履歴の返却形式
• 移行条件：返却費用・期間、削除証明、他社移行支援
• 契約条件：価格改定、再委託、障害時の損害対応、終了時の事前通知

契約条件を明確にしておくと、将来のベンダーロックインを抑えられます。

電子申請システム開発のFAQ

電子申請システムはスクラッチ開発が必要ですか？

要件によっては、スクラッチ開発を選ばなくても済みます。標準フォームや本人確認、通知、審査、決済が中心なら、SaaSやパッケージが導入しやすい方式です。

法改正やセキュリティ更新の負担も抑えやすくなります。一方で、独自審査や複雑な交付、特殊な連携が欠かせない場合は、追加開発やスクラッチを検討します。

開発期間はどのくらいかかりますか？

導入までの期間は、必要な準備や連携の範囲によって、次のように異なります。

• 小規模SaaS：標準フォーム中心なら1〜2か月程度で開始できる
• 複数課で利用：本人確認、決済、審査、通知を使う場合は2〜6か月程度
• 連携・移行あり：基幹・LGWAN連携、移行、研修を含む場合は4〜9か月程度
• 独自開発：大規模連携を含む場合は12〜24か月以上となることがある

期間を左右するのは、画面数よりも、業務調整、連携調査、受入テスト、調達手続です。

マイナンバーカード対応は必須ですか？

手続によって異なります。なりすましを防ぎたい場合や電子署名が必要な場合は、JPKIが有効です。

すべての手続で同じ確認を求めると、申請者の負担が増えます。そのため、確認は不要とするか、メール認証かカード認証にするかを、手続ごとに分けて決めます。

確認方法では、手続ごとに次の3点を比べておきます。

• 本人確認：必要なレベルと証跡
• 事業者向け：GビズID
• 代理申請：委任確認の仕組み

導入後はどのKPIを見ればよいですか？

申請する側の進みやすさと、職員の処理の負担は、完了率や不備率、職員の処理時間などの指標で比べられます。

• 申請の状況：完了率、途中離脱率、不備率、オンライン完結率
• 処理の状況：差し戻し件数、審査時間、職員の処理時間
• 利用者対応：問い合わせ件数

導入前に基準値を取っておき、導入後も同じ期間で比べます。

件数だけでなく、不備が多い項目や離脱が起きている画面も調べます。そのうえで、説明や入力順、エラー表示、添付方法を改善します。

紙申請を残したままでも導入できますか？

導入はできますが、紙と電子を併用する期間の運用設計が必要です。紙の申請を職員が登録するか、別台帳で管理するかを決めます。

申請番号の統一方法と二重登録の防止を定めます。窓口での支援や代理入力も考慮に入れます。

経路が異なっても、同じ審査、決裁、通知につながるようにします。

電子申請システム開発のまとめ

開発前には、申請受付から審査、決裁、通知、交付までの業務フローを整理します。

申請者向けの機能に加えて、職員の審査、差し戻し、職権訂正、権限、ログ、既存連携も、同じ範囲で考えます。

方式は、初期費用や導入期間、5年間のTCOで比べます。さらに、法改正の対応、追加フォームの単価、データ返却の条件も比べます。

目安は、小規模SaaSが初期0〜150万円、自治体向け標準SaaSが100〜500万円、SaaS＋基幹・決裁・LGWAN連携が300〜1,500万円です。

スクラッチは3,000万円〜1億円超ですが、件数、連携、認証、決済、移行、セキュリティで変わります。

発注前には、要件をそろえたRFPを作ります。そのうえで、標準、設定、追加開発、対象外を分けた見積もりを取ります。

導入後は、完了率や不備率、差し戻し、審査時間、問い合わせを継続して計測します。最後に、小さく導入して改善を続けながら、住民と職員が使いやすい業務基盤へ育てていきます。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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