行政手続きオンライン化システムは、申請の受付から本人確認・審査、通知・保管、既存システムとの連携までを一つの流れにつなぐ業務システムです。住民と職員の双方の業務効率化に役立ちます。
対象手続きの選び方、機能と費用、導入の進め方は、各テーマの関連記事もあわせてご覧ください。
▼関連記事一覧
・行政手続きオンライン化システム開発の進め方/やり方/流れや方法/手法/工程/手順
・行政手続きオンライン化システム開発でおすすめの開発会社/ベンダー6選と選び方
・行政手続きオンライン化システム開発の見積相場や費用/コスト/値段について
・行政手続きオンライン化システム開発の発注/外注/依頼/委託方法について
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
行政手続きオンライン化システムの定義
行政手続きオンライン化システムは、住民や事業者がパソコンやスマートフォンから申請し、行政が手続きの完了まで管理する業務システムです。
申請画面だけでなく、職員向けの管理機能や既存システムとの連携も含みます。
本人確認、決済、証跡管理も構成要素に含まれます。単なる入力フォームと違い、受付後の業務まで扱う点が特徴です。
Webフォーム化にとどまらない業務範囲
紙の申請書を同じ内容のWebフォームにするだけでは、職員による印刷や手入力、別システムへの転記が残ります。その場合、住民の負担が一部減るにとどまります。
オンライン化では、受付後の業務もあわせてつなぎます。
- 申請データの受付：構造化したまま受付一覧へ取り込みます。
- 担当課への振り分け：受け付けた申請を所管の部署へ自動で回します。
- 審査から通知まで：審査状況、補正依頼、決裁、交付文書の通知を一続きにします。
検討の単位は、フォーム画面ではなく、手続きが完了するまでの業務フローになります。ただし、窓口、郵送、電話などを残す場合でも、オンライン申請と同じ台帳で進捗を管理できる設計が望ましいです。
申請者・職員・既存システムの三層構成
申請者、職員、既存システムの流れは、一枚の業務フローに描いておくと全体を見渡せます。申請者画面だけを評価すると、職員の審査やデータ連携に手作業が残るためです。
基本構成は、申請者、職員、既存システムの三層で整理します。層ごとに主な機能を確認すると、画面や連携の漏れに気づきやすくなります。
- 申請者向け：公開画面と、認証・本人確認の仕組みを用意します。
- 職員向け：申請管理、ワークフロー、職員ポータルを備えます。
- 管理・連携向け：データベース、ファイル保管、通知・決済、既存連携、監視・バックアップを含みます。
必要な本人確認の強度や保存すべき証跡は、対象手続きによって異なります。
デジタル庁のガイドラインは、電子署名や主体認証のほか、アクセスログや通知などのプロセス記録を活用する考え方を示しています（出典: デジタル庁「行政手続におけるオンラインによる本人確認の手法に関するガイドライン」）。
オンライン化できる行政手続きの種類と対象範囲
手続きの難しさは、本人確認、添付書類、手数料、審査、交付方法によって変わります。
利用頻度や業務効果、法令上の制約、連携の難しさから、手続きごとに優先順位を決めます。全庁分を一つの仕様にまとめず、この順で段階的に広げます。
先行しやすい申込・予約・届出型の手続き
先行導入の候補は、手続きの特徴と候補例を照らし合わせて選びます。
- 先行しやすい条件：入力項目と添付書類が少なく、本人確認や審査が複雑でない手続きです。既存機能やローコードで始めやすくなります。
- 候補となる手続き：施設予約、講座・イベント申込、アンケート、簡易な届出、証明書の請求受付が該当します。
簡単な手続きでも、受付完了メールや状況照会、キャンセルの扱いは決めておく必要があります。定員管理や個人情報の保存期間も、あらかじめ定めます。
先行案件で得た利用率や問い合わせの傾向は、次の設計に反映します。それによって、全体展開が安定します。
本人確認・審査・決済を伴う手続きの別設計
給付、福祉、税、子育て、介護、許認可の手続きでは、本人確認や代理申請、添付書類、審査ルート、手数料、交付文書が関わります。そのため、受付だけでなく、補正依頼、差戻し、決裁、通知、支給・交付後の記録まで要件に含めます。
住民記録、税務、福祉などの基幹システムへ同じ情報を再入力すると、オンライン化の効果が損なわれます。連携できない場合は、CSV出力とエラー一覧を用意します。取り込みの確認と再処理の履歴も残せるようにします。
優先順位の付け方（住民効果と職員効果）
候補ごとの効果と導入時の難しさを、次の観点で見比べます。
- 住民・職員への効果：双方の効果と審査の複雑さを評価します。
- 評価に使う情報：年間申請件数や窓口混雑、郵送費などを一覧にします。入力不備や処理時間、制度改正頻度、データ連携の難しさも対象です。
- 件数が多く審査が複雑：職員判断が必要なら段階導入が向く場合があります。
- 件数が少なくても住民効果が大きい：遠方からの来庁や、子育て・介護など時間制約のある利用者に着目します。
- 導入候補の分類：短期導入、高い効果、連携要件の先行検証に分けると、ロードマップを組み立てやすくなります。
主な機能と導入メリット・注意点
機能は申請者向け、職員向け、管理・連携向けに分けて確認します。機能数の多さだけで比べず、対象手続きの業務フローを短くする機能がそろっているかを評価します。
申請者向けの迷わず完了できる導線
申請者向けの機能は、手続きの検索から完了後の状況確認までをつなぐものです。利用者の範囲に応じて、スマートフォン入力や読み上げ、多言語表示の要否を検討します。
- 入力前後の案内：対象者を絞り込む案内、条件分岐フォーム、入力例を用意します。
- 申請データの入力：添付ファイルの提出と下書きの保存に対応します。
- 申請後の確認：状況照会、補正対応、メールやSMS通知を備えます。
- 利用環境への配慮：文字サイズ変更、やさしい日本語、多言語表示などを検討します。
必要書類を事前に知らせ、入力時にエラーを伝えると、申請の不備を減らせます。さらに、完了後に受付番号と次の流れ、問い合わせ先を示せば、電話での進捗確認も抑えられます。
職員向けの受付後処理の標準化
職員向けの管理機能は、受付後の処理と、案件状況の把握に分けて整えます。
- 受付・審査：受付一覧と自動振り分けを使い、審査状況を管理します。差戻しや補正依頼も扱います。
- 決裁・交付：承認・決裁と、交付文書の作成を行います。
- 記録・集計：操作履歴と監査ログを残し、統計画面も備えます。
- 案件状況の共有：担当者と管理者が、滞留案件や期限、差戻し理由を把握できます。
- 後続業務での再利用：入力データを、後続処理で使える形式に整えます。
転記や目視確認は減らせる一方で、最終判断を自動化しすぎると、制度解釈や例外処理が難しくなります。そのため、AIや自動判定は入力補助や分類、要約などから始め、決裁者が確認できる証跡を残します。
導入効果の測定と業務改革の視点
効果測定では、来庁回数、郵送量、窓口待ち時間の三つを主に使います。転記時間や不備率、完了日数、オンライン申請率などの指標も、必要に応じて加えます。
特に、審査や決裁が紙のままだと、申請率が上がっても職員の負担は減りません。
導入前に現状値を測り、手続きごとに目標を設定します。そのうえで、住民と職員の双方について、1件当たりの転記時間や補正回数、決裁までの日数の変化をKPIとして追います。
行政手続きオンライン化システムの費用相場
費用は、手続き数や申請件数、認証強度によって大きく変わります。決済や既存システム連携は費用を左右する要素で、データ移行と運用範囲も見積もりに影響します。
ここに示す金額は定価ではありません。業務システム一般の工数目安と、自治体の公表契約を参考にした予算検討用のレンジです。
費目の詳しい相場は、行政手続きオンライン化システム開発の見積相場や費用/コスト/値段についてをご覧ください。
初期費用の幅（300万円から8,000万円超）
数手続きのフォーム、通知、簡易な受付管理を既存SaaSで始める場合、初期費用は300万〜1,500万円程度が目安です。
複数部署で審査・補正・決裁・文書交付を管理し、既存システム連携を含む中規模導入では、1,500万〜4,000万円程度を想定します。
全庁型では、住民情報や税、福祉をまたいで開発します。窓口、認証、決済を含む場合は、3,000万〜8,000万円超になる可能性があります。特に、スクラッチ開発や大規模移行では、複数年度の計画と運用費も含めて判断します。
公表契約に見る機能ごとの予算配分
費用は、オンライン申請本体だけでなく、機能ごとに分けて比べます。たとえば、決済、窓口、基幹連携は別々の費目として見ます。案内、フォーム、クラウドについても、同じ考え方で分けます。
熊本市の2025年度公表契約にある金額は、機能ごとの予算例です。
- 手続きガイド：クラウド利用料は171万6,000円です。
- 関連オプション・決済：電子文書交付などは26万4,000円、決済は143万8,000円の発注見込額。
- 窓口支援：導入・運用保守の金額は4,735万3,350円です。
- 福祉系システム連携：対応費は2,691万1,280円です（出典: 熊本市「令和7年（2025年）5月 随意契約」）。
これらはオンライン申請単体の市場価格ではありません。受付機能と窓口・基幹連携を同じ費目に混ぜると、見積もりを比較できなくなることを示す例です。
ランニングコストの内訳（利用料・保守・制度改正）
継続費には、SaaS利用料や件数・利用者課金、クラウド・LGWAN接続が含まれます。監視やバックアップ、脆弱性対応に加えて、問い合わせ対応や制度改正対応、操作研修も費目に入ります。
小規模導入では年100万〜500万円程度、中規模以上では年500万〜1,500万円以上を見込む場合があります。ただし、契約条件によって差が大きい推定値です。
見積書では、初期費用と年額費用に加え、手続きの追加や移行、制度改正の単価と条件を確認します。本人確認・決済や障害対応、他社移行の条件も、見積書に明記してもらいます。特に、追加や改修のたびに費用が発生すると、数年後の総額が膨らみます。
パッケージ・SaaS・ローコード・スクラッチの違い
提供形態は、短期導入と独自業務・基幹連携のどちらを優先するかで選びます。
初期費用だけでなく運用の面も確認します。法改正への追随や、職員が自分で変更できる範囲、データの持ち出しに加え、障害時の対応や他サービスへの移行条件も見ます。
SaaS・パッケージが向く場合：標準機能を早く使いたいケース
SaaSやパッケージは、申請フォームや受付管理、通知、集計などを活用する方式です。導入期間と初期費用を抑えやすくなります。
制度改正やセキュリティ更新を提供側が担う場合は、自治体の保守負担も軽くなります。
一方で、独自の承認ルートや特殊な添付書類、複雑な連携には対応できない場合があります。そのため、デモだけでなく実際の手続きで、補正、差戻し、交付、取消しまで操作し、適合度を確かめます。
ローコードの特徴：手続き追加のスピード
ローコードでは、職員や管理者が部品を組み合わせて、フォームやワークフローを作れます。そのため、手続きの追加や軽微な様式変更を自ら行え、制度改正への対応を早められます。
自由度が高いほど、項目名や権限、ログ、個人情報、連携方式を統一するルールが必要です。フォームが乱立したり、担当者の異動後に保守が難しくなったりするのを避けるため、テンプレートとレビュー手順を整えます。
スクラッチ開発の検討場面：複雑な業務と連携の一体化
スクラッチ開発は、既存業務に合わせた設計や、複数の基幹システムとの連携を実現しやすい方式です。独自の審査や決裁、データ変換、権限管理を一つの業務基盤に統合する場合に適します。
一方で、要件定義から移行までに時間と費用がかかり、担当者が代わった後の保守も課題です。API、データモデル、ソースコードや設計書の帰属、障害時の責任、改修単価は、契約前に確認します。
行政手続きオンライン化システムの進め方
導入は、システムを選ぶより先に、手続きと業務の棚卸しから始めます。期間の目安は、標準導入で1〜3か月、複数部署展開で3〜6か月、基幹連携や独自開発を含む場合で6〜12か月以上です。
調達や庁内調整、テスト期間も含めて計画を立てます。工程の詳細は行政手続きオンライン化システム開発の進め方/やり方/流れや方法/手法/工程/手順をご覧ください。
手続きと現行業務の棚卸し
手続きごとに、年間件数や申請者、申請方法、入力項目を一覧にします。添付書類や本人確認、手数料も含めます。審査者や決裁者、処理日数、保存年限、現行システム、担当課も、同じ一覧に書き出します。
紙を電子化する前に、重複項目や不要な添付、同じ情報の再提出、承認者が不明確な工程を洗い出します。そのうえで、「必ずオンライン化する手続き」と「将来拡張する手続き」を分け、住民と職員それぞれの効果をKPIにします。
業務を見直さずに紙の運用をそのまま移すと、入力画面だけが増え、処理時間や確認作業は減りません。棚卸しを先に行うのは、このためです。
要件定義で先に決める認証・連携・例外処理
要件定義では、通常の申請に加えて、例外となるケースも書き出します。代理申請や差戻し、補正のほか、取消しや期限切れ、添付失敗なども対象です。決済エラーや二重申請、障害時の窓口対応も洗い出します。
本人確認やログ保存、権限分離は、要件定義の段階で決めます。通知方法や連携頻度、エラー時の再処理も同じ段階で決めておきます。これらは後から追加すると費用と納期が膨らみやすいため、早めに決めます。
画面設計では、申請者のスマートフォン画面と職員画面を、同じ業務フローの中で確認します。また、デモやモックアップで受付から補正、決裁、交付まで試すと、仕様書だけでは見つけにくい問題を早い段階で見つけられます。
小さな先行稼働から本番展開への広げ方
最初から全庁に展開せず、1〜2手続きでPoCまたは先行稼働を行います。そのうえで、申請完了率や入力途中の離脱、補正率を測ります。処理時間や問い合わせ数、職員の操作時間、障害件数も記録します。
利用者と職員の声をもとに、フォームやワークフローを修正します。本番後は、手続き追加の窓口や制度改正の確認、脆弱性対応を運用に組み込みます。監査ログ点検、バックアップ復旧訓練、異動時研修も、運用の一部として扱います。
納品後も利用率と処理品質を定期的に見直す体制が必要です。
本人確認・セキュリティ・標準化対応の要点
利便性を高めるほど、なりすましや情報漏えい、申請内容の改ざん、権限の誤設定への備えが必要になります。一方で、すべてに最も強い認証を適用すると、負担と費用が増えます。そのため、リスクに応じて段階を設計します。
手続きのリスクに応じた本人確認の使い分け
本人確認の方法は、手続きのリスクや確認目的に合わせて選びます。すべてに強い認証を求めるのではなく、利用者の負担も踏まえて決めます。
- 低リスクの手続き：施設予約や簡易な申込では、メール認証やワンタイムパスワードで足りる場合があります。
- 重要な手続き：給付、税、福祉、重要な証明、法的効果のある届出では、公的個人認証、電子署名、多要素認証を候補にします。
手続きごとに、なりすましや否認を防ぐ要件を整理します。なお、公的個人認証サービスは、マイナンバーカードのICチップにある電子証明書で本人を認証し、電子文書の改ざんを確認する仕組みです。
デジタル庁によると、2026年6月30日時点で同サービスを利用する民間事業者は1,284社です（出典: デジタル庁「公的個人認証サービス（JPKI）」、2026年7月更新）。
カード読み取りや証明書の有効性、失効時の扱いを確認します。スマートフォン利用と代替窓口も、確認の対象です。
通信・権限・ログ・復旧の要件化
通信暗号化や脆弱性診断、WAFなどの防御を要件に含めます。管理者権限の分離や操作・申請ログ、保存期間も、要件として定めます。暗号化バックアップや監視、アラート、復旧目標、委託先管理も、要件に加えます。
添付ファイルのウイルス対策や職員端末の制御、ログの改ざん防止、退職や異動時のアカウント無効化も確認します。障害時には、連絡や紙・窓口への切り替えを決めます。復旧後は二重登録を防ぎ、未処理案件を再開する手順も定めます。
セキュリティは製品機能だけでなく、日常の運用と訓練で維持します。
標準化・ガバメントクラウドとの境界の確認
地方公共団体の基幹業務では、住民基本台帳、税、福祉、介護、国民健康保険など現時点で20の事務が標準化対象です。
デジタル庁は、標準準拠システムへの移行、デジタル3原則、データ要件・連携要件の標準化を進めています（出典: デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2026年確認）。
オンライン申請と基幹業務の接続では、次の条件を初期の要件定義で確認します。
- 対象業務：標準仕様の対象と対象外を分けます。
- データ形式：文字・コードとデータ所有権も確認します。
- 接続方法：API、ファイル連携、ガバメントクラウド、LGWANの条件を確認します。
申請側が独自の項目名や形式を使うと、基幹連携の際に変換費用が発生します。
開発会社・ベンダーの選び方
導入自治体数や知名度だけでなく、対象手続きの複雑さと連携範囲に合うかを見極めます。SaaS、ノーコードの段階展開、住民情報連携、全庁SIでは、必要な体制が異なります。
同じ評価軸で比べたうえで、案件に合う提案かを確認します。
同じ規模・認証・連携の実績
自治体向けの導入実績に加え、同程度の案件で本人確認や決済の事例があるかを確認します。実績は、手続きの機能と接続・連携の二つに分けて見ます。
- 手続きの機能：添付、審査・決裁の事例
- 接続・連携：LGWANやクラウド接続、住民情報・税・福祉連携の事例
可能であれば、自治体に担当範囲や導入期間、稼働後の問い合わせ、制度改正対応、データ移行方法を聞きます。提案担当者と開発・運用チームが同じかどうか、障害時の判断者は誰かも、契約前に明確にします。
見積書とRFPの費目・責任範囲の比較
RFPや要件表には、対象手続きや年間件数、利用者、認証、添付を記載します。同じ書面には、決済や審査・決裁も入れます。受付後の処理と基幹との接続も、費目と責任範囲を分けて書いてもらいます。
- 受付後の処理：通知、保管
- 基幹との接続：既存連携、移行
テストや研修、保守、制度改正対応の範囲も、記載の対象です。
提案内容は、機能の実現方法と費目を分けて比べます。
- 標準機能：標準機能で対応できる範囲です。
- 追加開発：追加開発が必要になる範囲を書き分けます。
- 運用対応：運用で対応する機能を明記します。
見積額は、工程ごとに分けて示してもらいます。要件定義や設計、開発、テストの費用と、移行や研修、保守の費用を、分けて比べます。
業務システム一般では、要件定義が全体の約10％、設計が10〜20％、開発が40〜60％、テストが10〜20％となることがあります。連携や移行の比率は、案件によって異なります。
人月単価は80万〜120万円程度を参考にし、人数と期間、成果物を明示して比べます。
導入後の運用と将来の移行条件
契約時には、導入後の運用条件とデータの扱い、将来の移行条件を確認します。
- 運用条件：追加単価やフォーム変更、制度改正、脆弱性対応などを定めます。障害受付や復旧目標、研修、利用状況レポートも含めます。
- データ管理：所有権や保存場所、ログ出力、バックアップ、再委託、個人情報の削除条件を契約に含めます。
- 移行への備え：標準形式の出力、API仕様書、画面・帳票定義、設定情報、操作履歴の保管方法を確認します。
短期の費用だけでなく、5年程度の総保有コストで比べます。担当者が代わっても運用できるかも、評価の対象です。
▶ 詳細はこちら：行政手続きオンライン化システム開発でおすすめの開発会社/ベンダー6選と選び方
▶ 詳細はこちら：行政手続きオンライン化システム開発の発注/外注/依頼/委託方法について
よくある質問
導入前によく寄せられる費用、本人確認、窓口運用の質問に回答します。法令や条例、既存システムの制約があるため、個別の要件は現行業務と照らし合わせてください。
行政手続きオンライン化システムは最低いくらから導入できますか？
数手続きのフォームと簡易な受付管理なら、初期300万〜1,500万円程度が予算検討の目安です。本人確認、決済、審査・決裁、既存連携、移行を含めると、1,500万〜4,000万円程度になります。
全庁型では、8,000万円を超える可能性もあります。
すべての行政手続きでマイナンバーカードの本人確認が必要ですか？
手続きごとに、本人確認が必要かどうかを判断します。その際は、リスクや本人確認の理由、電子署名の要否、利用者負担、代替手段を整理します。
低リスクの申込は簡易認証、高リスクの給付や重要な届出は公的個人認証や多要素認証などを検討します。
窓口や郵送をなくしてオンラインだけにできますか？
利用者や手続きの性質によっては、窓口・郵送・電話などを残す設計が現実的です。たとえば、オンラインを使えない人への支援や代理申請、障害時の受付、本人確認書類を持参するケースが想定されます。
すべてのチャネルを同じ申請管理に集めると、二重管理を防げます。
導入にはどのくらいの期間がかかりますか？
標準機能のSaaS導入は1〜3か月、手続きの棚卸しと複数部署展開を含む場合は3〜6か月が目安です。基幹連携や独自開発では、6〜12か月以上かかる場合があります。
調達、庁内合意、本人確認・決済の審査、データ移行、並行運用テストを含め、稼働日から逆算して計画します。
まとめ
導入判断で外せない三つの視点
行政手続きオンライン化は、受付や審査、決裁、通知を一つの業務フローとして見直す取り組みです。本人確認や補正、保管、既存連携も、その流れに含めて考えます。
判断では、対象手続きの業務効果、認証・セキュリティの妥当性、既存システムとの連携と運用継続性を確認します。
最初の一歩：手続き一覧と見積項目の整理
導入を判断するときは、対象手続き、費用、接続・移行条件を順に整理します。
- 手続きを棚卸しし、住民・職員双方への効果が大きく、先行しやすいものから始めます。
- フォームや認証、決済などの費目を分け、数年単位の総保有コストで比べます。移行や保守、制度改正対応も、その中に含めます。
- 部分導入は300万〜1,500万円程度、中規模連携は1,500万〜4,000万円程度、全庁型は3,000万〜8,000万円超まで幅があります。
- 標準化、ガバメントクラウド、LGWANとの境界、データ所有権、移行条件を確認して選定します。
▼関連記事一覧
・行政手続きオンライン化システム開発の進め方/やり方/流れや方法/手法/工程/手順
・行政手続きオンライン化システム開発でおすすめの開発会社/ベンダー6選と選び方
・行政手続きオンライン化システム開発の見積相場や費用/コスト/値段について
・行政手続きオンライン化システム開発の発注/外注/依頼/委託方法について
▼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を創業。