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

電子申請システム開発は、申請フォームをWeb上に置くだけでは完了しません。住民や事業者が手続きを探して入力し、本人確認や電子署名を行い、添付書類を提出し、行政側が受付・審査・決裁・通知・交付まで処理できる業務基盤として設計する必要があります。申請者側の便利さだけを先に追うと、職員が紙へ転記する作業や差し戻しの対応が残り、期待した効果が出ないことがあります。

自治体のDX担当者、情報政策担当者、各課の業務担当者、行政手続きをオンライン化したい企業の担当者が開発を進めるときは、対象手続、本人確認の水準、既存システムとの連携、LGWAN接続系や個人番号利用事務系との分離、法改正時の保守まで整理することが大切です。この記事では、電子申請システムの全体像、開発の進め方、2026年時点の費用相場、見積もりで確認すべき項目、FAQを順番に解説します。

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

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

電子申請システムとは、住民・事業者が窓口へ行かずに行政手続を申請し、行政側がオンラインで受付から処理完了までを管理する仕組みです。対象になるのは、各種届出、証明書の請求、給付申請、施設予約、講座やイベントの申込、事業者向けの許認可申請などです。申請の入口がオンラインになるだけでなく、受付後の審査、差し戻し、決裁、手数料の納付、通知書の交付までつながって初めて業務全体のデジタル化になります。

申請者向けと職員向けの機能を一体で考えます

申請者向けには、手続の検索、スマートフォン対応のフォーム、入力内容のチェック、途中保存、添付ファイルの提出、申請状況の照会、補正依頼への対応、修正後の再提出、メールやLINEによる通知などが必要です。住所や氏名を何度も入力させない設計、入力例の表示、エラー箇所の分かりやすい案内も、申請完了率を左右します。本人確認が必要な手続では、マイナンバーカードを使う公的個人認証サービス（JPKI）、法人向けのGビズID、手続に応じたその他の認証方法を使い分けます。

職員向けには、受付内容の確認、添付書類の閲覧、審査、差し戻し、職権訂正、担当者間の引き継ぎ、決裁、通知書の作成、電子交付、一括処理、権限設定、操作履歴の確認が必要です。申請者が入力した情報を職員が別の基幹システムへ再入力する構成では、入力ミスと二重作業が残ります。住民記録、税、収納、福祉、文書管理、決裁、口座、施設予約など、対象手続に必要なシステムとの連携範囲を早い段階で洗い出します。

ネットワーク分離・認証・監査ログを開発範囲に含めます

自治体向けの電子申請システムでは、インターネット接続系、LGWAN接続系、個人番号利用事務系をどのように分離し、どのデータをどの経路で連携するかが重要です。個人情報を扱う処理を単純にインターネット側へ置くのではなく、認証、認可、通信の暗号化、保存データの暗号化、権限分離、操作ログ、バックアップ、障害時の復旧を含めて設計します。ログは取得するだけでなく、誰がいつどの申請を閲覧・変更・承認したかを後から追跡できる形式にします。

クラウドサービスを採用する場合は、ISMAPまたはISMAP-LIUへの登録状況を確認します。ISMAPは、政府が求めるセキュリティ要求を満たすクラウドサービスを事前に評価・登録し、調達時のセキュリティ水準を確保する制度です。ただし、登録されていることだけで自自治体の要件を満たすとは限りません。データの保管場所、再委託先、脆弱性対応、インシデント通知、バックアップ、復旧目標、契約終了時のデータ返却まで仕様書と契約書で確認します。

導入効果はオンライン化率だけで判断しません

開発前に、申請完了率、不備率、差し戻し件数、審査にかかる時間、問い合わせ件数、職員の処理時間、オンライン完結率をKPIとして決めます。利用件数が増えても不備率が高ければ、職員の確認作業が増えることがあります。逆に、入力案内を改善して不備を減らせば、既存の電子申請基盤を大きく改修しなくても効果を出せる場合があります。

川崎市の事例では、既存の汎用電子申請システムに操作ガイドを追加し、申請者が迷いやすい項目を画面上で案内した結果、手続によって不備率が最大81.7％改善し、年間約105時間の業務削減につながったと紹介されています。この事例からも、システムを導入して終わりにせず、申請データと問い合わせ内容を分析してフォームを継続的に改善する運用が重要だと分かります。

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

電子申請システムの開発は、現状分析、対象手続の選定、要件定義、方式比較、認証・連携・セキュリティ設計、PoCまたは先行導入、開発・設定、テスト、研修・切替、運用改善の順に進めます。実際には、データ移行や連携調査で新しい課題が見つかるため、工程を一方向に進めるのではなく、確認結果を要件と計画へ戻しながら確度を高めます。

1. 現行業務と対象手続を棚卸しします

最初に、オンライン化したい手続を一覧化します。手続名、担当課、年間申請件数、繁忙期、申請者、添付書類、本人確認の方法、手数料、審査の有無、決裁者、通知方法、保存年限、現在の処理時間を記録します。申請書の画面だけではなく、窓口での確認、郵送物の開封、台帳への転記、審査、補正連絡、決裁、通知、保管までを一つの業務フローにします。

対象手続は、申請件数が多いものだけで決めません。住民の移動負担が大きいもの、不備が多く職員の確認工数が大きいもの、オンライン化による効果が測りやすいもの、制度上オンライン処理に適しているものを優先します。紙申請をすぐに廃止できない場合は、紙とオンラインが併存する期間の受付方法、二重登録の防止、データの正本、職員の処理手順も決めます。

2. 共通機能と手続固有の要件を分けます

次に、複数の手続で使い回せる共通機能と、手続ごとに異なる機能を分けます。共通機能には、アカウント、本人確認、入力チェック、添付、通知、決済、権限、監査ログ、バックアップ、申請状況照会などがあります。手続固有の機能には、独自の審査項目、資格判定、計算、代理申請、複数人の同意、現地確認、電子交付の条件などがあります。

この切り分けを行わずに手続ごとに画面を作ると、同じ認証や通知の仕組みが重複し、仕様変更のたびに複数箇所を改修することになります。共通基盤に載せる範囲、標準SaaSの設定で対応する範囲、周辺システムで補う範囲、個別開発する範囲を一覧にして、各社の提案が同じ前提で比較できる状態を作ります。

3. SaaS・ローコード・スクラッチを要件で比較します

標準SaaSやパッケージは、認証、通知、申請管理、セキュリティ更新、法改正対応をサービス側に任せやすく、導入を早めやすい方式です。手続数が少なく、標準フォームと標準ワークフローで対応できる場合は、費用と期間を抑えやすくなります。一方で、独自の審査や特殊な画面制御、既存基幹システムとの深い連携には制約がある場合があります。

ノーコードやローコード型は、職員がフォームを作成・修正しやすく、自治体内でテンプレートを再利用できることが強みです。ただし、複雑な業務ルール、厳格な権限分離、大規模な一括処理、基幹システムとの双方向連携は、追加開発や別基盤が必要になることがあります。スクラッチ開発は独自業務へ合わせやすい反面、要件定義が長期化し、制度改正や脆弱性対応の費用を継続的に負担することになります。

方式を決めるときは、初期費用だけでなく、導入までの期間、5年間の総額、手続追加時の単価、管理者の内製スキル、法改正への対応主体、契約終了時のデータ返却、ベンダーロックインのリスクを比較します。最初から全手続を一つの方式に固定せず、代表的な手続でPoCを行い、申請完了率や不備率を確認してから横展開する方法も有効です。

4. 本人確認・決済・ネットワーク連携を設計します

本人確認は、すべての手続で同じ方法にする必要はありません。申請者のなりすましによる影響、手続の重要性、署名の要否、代理申請の有無、保存すべき証跡を手続ごとに整理します。マイナンバーカードのJPKIは本人確認や電子署名に利用できますが、利用者側の端末環境や暗証番号入力も考慮します。事業者向け手続ではGビズIDが適する場合があり、申請導線と本人確認の負担を分けて考えることが大切です。

手数料が発生する場合は、クレジットカード等のオンライン決済、電子納付、返金、決済失敗時の再申請、領収情報の保管まで設計します。電子署名が必要な申請では、署名の検証結果、署名時刻、証明書の状態、署名対象データを記録します。LGWANや個人番号利用事務系と連携する場合は、データを単に送受信するだけでなく、連携項目、送信頻度、エラー時の再送、重複登録の防止、停止時の手作業を定義します。

5. テスト・研修・本番切替・KPI改善を行います

テストは、単体テスト、連携テスト、業務シナリオテスト、受入テスト、セキュリティテスト、負荷テスト、移行リハーサルに分けます。代表的な申請を最初から最後まで通し、入力、本人確認、添付、受付、審査、差し戻し、再提出、決裁、決済、通知、交付、保存までを確認します。正常系だけでなく、添付漏れ、期限切れ、決済失敗、同じ申請の二重送信、権限外の閲覧、連携停止、通知不達も試験します。

受入基準は、画面が表示されることだけにしません。申請データが正しいシステムへ届くこと、職員が処理期限を確認できること、ログが残ること、帳票や通知文書が正しく出力されること、障害時に手作業へ切り替えられることを基準にします。職員研修では操作説明だけでなく、差し戻し、代理処理、誤登録の訂正、問い合わせ対応、障害時の受付継続を演習します。

2025年4月から、先行実証に参加する自治体で次期オンライン申請サービスを使った手続の受付が始まっています。2026年9月以降の本格運用も予定されているため、今後は住所などの再入力削減、自治体が保有する情報の転記、補正連絡、通知書のオンライン化など、申請前後を含めた一連の体験が重視されます。国のサービスと自治体独自の電子申請システムがどこで連携するかを確認し、将来の重複投資を避けることが大切です。

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

電子申請システムの費用は、人口、年間申請件数、手続数、職員数、本人確認、電子署名、決済、通知、基幹システム連携、LGWAN構成、データ移行、運用保守の範囲で大きく変わります。全国共通の公定価格や市場全体の平均額があるわけではないため、以下は公開料金例と一般的な公共系システムの工程感をもとにした、予算検討用の目安です。正式な予算は同一要件で複数社から見積もりを取得します。

小規模なSaaS導入では、初期設定やフォーム作成を含めて100万円前後から始められるケースがあります。リサーチで確認した行政向けSaaSの整理では、初期約120万円、月額約18万円、5年間のTCO約1,200万円という例があり、標準機能を使いつつ複数課で運用する場合の考え方として参考になります。ただし、これは電子申請市場全体の平均や特定自治体の確定価格ではなく、申請件数や連携範囲を含めて再計算する必要があります。

近接する行政SaaSの公開資料には、導入料金458,400円、人口規模に応じた基本料金、月額30,000円、金融機関連携556,800円という構成もあります。電子申請システムそのものの価格ではありませんが、行政向けサービスでは、初期設定、規模別の基本料金、月額利用料、連携オプションが分かれて請求されることを示す例です。見積もりでは、初期費用の安さだけでなく、利用者数や申請件数が増えたときの従量課金も確認します。

費用は開発費・連携費・運用費に分けて比較します

初期費用には、企画支援、現状分析、要件定義、フォーム作成、画面・ワークフロー設定、認証・電子署名、決済、通知、既存システムとのAPI連携、LGWAN接続、データ移行、テスト、研修、本番切替が含まれます。標準SaaSの利用料だけを見て予算を作ると、連携、帳票、移行、職員研修が別費用になった際に予算超過しやすくなります。

運用費には、サービス利用料、クラウド基盤、監視、バックアップ、ヘルプデスク、障害対応、セキュリティ更新、法改正対応、フォーム追加、データ抽出、定期的な改善が含まれます。契約期間は1年だけでなく、3年または5年の総額で比較します。利用料が毎年変わる条件、申請件数の増加による従量課金、追加フォームの単価、解約時のデータ返却費用もTCOに加えます。

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

電子申請システムの見積もりは、同じ要件書を複数社へ渡し、初期費用、年間費用、追加費用、保守範囲を同じ単位で比較することが基本です。提案書に「標準機能」「設定変更」「追加開発」「対象外」を明記してもらうと、安い見積もりが重要機能を対象外にしていないか確認しやすくなります。RFIで市場の選択肢を把握し、RFPで要求水準と評価方法をそろえる進め方が有効です。

対象範囲と前提条件を明確にします

見積依頼書には、対象手続数、年間申請件数、繁忙期の件数、利用部署、職員数、同時利用者数、添付ファイルの容量、保存年限、通知件数、帳票数、決済件数、本人確認の方式を記載します。手続数だけではなく、1手続あたりの分岐数、審査ステップ、申請者と職員の権限、代理申請、再提出、電子交付の有無も条件に含めます。

既存システム連携では、住民記録、宛名、税・収納、福祉、文書管理、電子決裁、口座、マイナポータル、LINEなどの接続先、APIの有無、連携項目、送受信頻度、エラー時の再処理、テスト環境を一覧化します。データを一方向に渡すだけか、審査結果や通知情報を戻すのかで費用は変わります。連携先の改修費用を発注者と受託者のどちらが負担するかも明記します。

非機能要件・セキュリティ・受入条件を数値化します

非機能要件には、稼働時間、可用性、応答時間、同時利用者数、バックアップ頻度、復旧時間目標、復旧時点目標、ログ保存期間、暗号化、脆弱性診断、アクセス制御、監視、障害時の連絡時間を含めます。LGWAN接続系や個人番号利用事務系との連携がある場合は、ネットワーク構成、接続方式、認証方式、データの持ち出し制御、監査方法を図で示してもらいます。

受入条件は、機能が動くことだけでなく、業務シナリオを最後まで処理できること、申請データと連携先のデータが一致すること、差し戻し後の再提出ができること、通知が送られること、職員の操作ログが残ること、障害時に代替運用へ切り替えられることを含めます。納品物として、要件定義書、画面一覧、業務フロー、権限表、API一覧、テスト仕様書、操作マニュアル、運用手順書、データ返却手順を求めます。

将来費用と契約終了時の条件を確認します

電子申請は制度改正や手続追加が続くため、初期開発が終わった後の費用が重要です。法改正への対応を保守料に含むのか、改修ごとに別見積もりになるのか、軽微な文言変更やフォーム追加の単価はいくらかを確認します。サービスのバージョンアップで既存フォームや連携が動かなくなった場合の検証責任も、契約前に決めておきます。

また、契約終了時に、申請データ、添付ファイル、審査履歴、決裁記録、通知履歴、操作ログをどの形式で返却できるかを確認します。返却費用、返却期間、データ削除の証明、別ベンダーへ移行する際の支援範囲も見積条件に含めます。契約期間中の価格改定、再委託、障害時の損害対応、サービス終了時の事前通知を確認すると、将来のベンダーロックインを抑えられます。

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

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

必ずしもスクラッチ開発は必要ではありません。標準的な申請フォーム、本人確認、通知、審査、決済を使う場合は、SaaSやパッケージの方が短期間で導入しやすく、法改正やセキュリティ更新の負担も抑えやすいです。独自の審査ルール、複雑な交付、特殊な基幹連携、自治体固有のデータ管理が業務上不可欠な場合に、追加開発やスクラッチを検討します。

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

標準フォーム中心の小規模なSaaS導入なら、要件整理から1〜2か月程度で始められる場合があります。複数課で使い、本人確認、決済、審査、通知を設定する場合は2〜6か月程度、基幹システムやLGWANとの連携、データ移行、職員研修まで含める場合は4〜9か月程度が目安です。独自開発や複数の大規模連携がある場合は12〜24か月以上になることがあります。期間は画面数よりも、業務調整、連携調査、受入テスト、調達手続の長さに左右されます。

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

手続の性質によって異なります。なりすまし防止や電子署名が必要な手続ではJPKIの導入が有効ですが、すべての手続に同じ本人確認を求めると申請者の負担が増えます。本人確認が不要な手続、メール認証で足りる手続、カード認証が必要な手続を分け、手続ごとに必要な本人確認レベルと保存する証跡を定義します。事業者向けではGビズID、代理申請では委任関係を確認できる仕組みも比較します。

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

申請完了率、入力途中の離脱率、不備率、差し戻し件数、審査時間、問い合わせ件数、オンライン完結率、職員の処理時間を確認します。手続ごとに導入前の基準値を計測し、導入後の同じ期間と比べます。件数だけでは効果を判断せず、不備の多い入力項目や離脱する画面を見つけ、フォームの説明、入力順序、エラー表示、添付方法を改善します。

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

導入できますが、紙とオンラインの両方を受け付ける期間の運用設計が必要です。紙申請を職員が電子申請システムへ登録するのか、紙は別の台帳で管理するのか、申請番号をどのように統一するのか、二重登録をどう防ぐのかを決めます。オンライン利用が難しい人への窓口支援や代理入力も含め、申請経路が違っても同じ審査・決裁・通知へつながる仕組みにします。

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

電子申請システム開発を成功させるポイントは、フォームの見た目から始めず、申請受付から審査・決裁・通知・交付までの業務フローを先に整理することです。申請者向けの入力や本人確認だけでなく、職員向けの審査、差し戻し、職権訂正、権限、操作ログ、既存システムとの連携を同じ開発範囲で考えます。

方式は、標準SaaS、ノーコード・ローコード、個別開発を、初期費用だけでなく導入期間、5年間のTCO、法改正対応、追加フォーム単価、データ返却条件で比較します。費用の目安は、小規模SaaSが初期0〜150万円、標準SaaSが100〜500万円、連携込みが300〜1,500万円、スクラッチが3,000万円〜1億円超ですが、申請件数、連携数、認証、決済、移行、セキュリティ要件によって変わります。

発注前には、対象手続と前提条件をそろえたRFPを作成し、標準機能・設定・追加開発・対象外を分けた見積もりを取得します。導入後は、オンライン化率だけでなく、完了率、不備率、差し戻し、審査時間、問い合わせ件数を継続的に計測します。小さく導入して利用状況を改善し、住民と職員の双方が使いやすい業務基盤へ育てることが、電子申請システムの開発で最も重要です。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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