行政手続きオンライン化システム開発の進め方/やり方/流れや方法/手法/工程/手順

行政手続きオンライン化システムは、申請フォームを置くだけではなく、本人確認、受付、審査、補正、決裁、通知、保管までを一つの業務フローとしてつなげる仕組みです。成功のポイントは、最初に対象手続きと現行業務を棚卸しし、利用者と職員の両方が無理なく使える範囲から段階的に導入することです。

本記事では、行政手続きオンライン化システムの開発を、要件整理、サービス・開発会社の選定、設計開発、テスト、稼働、定着の6フェーズに分けて解説します。費用相場や見積書の確認項目、本人確認・LGWAN・既存システム連携で迷いやすい判断基準も、実務で使えるチェックリストとして整理します。

▼全体ガイドの記事
・行政手続きオンライン化システム開発の完全ガイド

行政手続きオンライン化システムの全体像とは？

行政手続きオンライン化システムとは、住民や事業者がパソコン・スマートフォンから申請し、行政側が受付から処理完了までを電子的に管理する業務システムです。デジタル庁も、スマートフォンなどで手続きが完結する状態を目指し、マイナンバーカードの利用を含むオンライン化を進めています（出典: デジタル庁「行政手続のオンライン化」、2026年6月更新）。

最低限必要になるのは、手続き検索、条件分岐のある入力フォーム、添付ファイル、下書き保存、申請状況の照会、補正依頼、メールやSMSによる通知です。行政側には、受付一覧、担当者への振り分け、審査・差し戻し・承認のワークフロー、電子決裁、交付文書の作成、操作履歴、監査ログが必要になります。フォームだけをオンラインにして、受付後に印刷して紙で回覧すると、住民の入力負担は減っても職員の転記や保管作業は残ります。したがって、申請の入口から処分通知・交付・保管までを一つの業務フローとして図にすることが重要です。

全体構成は、申請者向けの画面、認証・本人確認、申請管理・ワークフロー、職員ポータル、データベースとファイル保管、通知・決済、既存システム連携、監視・バックアップに分けて整理できます。たとえば子育ての申請なら、申請者の情報を入力フォームに反映し、受付後に担当課へ振り分け、審査結果を通知し、必要に応じて住民情報や福祉システムへ連携します。最初の要件表には「誰が」「どの情報を」「いつ」「どのシステムへ渡すか」を記載し、API連携かファイル連携か、リアルタイムか日次かも決めておくと、後工程の追加費用を抑えやすくなります。

行政手続きオンライン化システムの進め方

開発は、いきなり製品やベンダーを決めるのではなく、現行業務の整理から始めます。特に行政手続きは、法令、様式、本人確認、添付書類、審査者、決裁者、交付方法が手続きごとに異なるため、全庁共通の機能と個別対応の境界を先に見極めます。以下の6フェーズをゲートとして使い、各段階で「次へ進める条件」を合意すると、導入後に想定外の業務が残りにくくなります。

最初に、対象手続きごとに年間件数、繁忙期、申請者、手数料、添付書類、本人確認の方法、審査・決裁ルート、交付物、保存年限、現行の処理時間を一覧化します。次に、住民の来庁回数を減らせるか、郵送・転記を削減できるか、処理件数が多いか、制度変更が少ないかを評価し、先行対象を決めます。チェック項目は「オンライン申請だけで完結できるか」「添付書類をデータ連携で省略できるか」「窓口・郵送を残す場合の切り替え条件は何か」「障害時の代替手段はあるか」です。ここでMUSTとWANTを分け、先行稼働は1〜2手続きに絞ると、複雑な全庁展開による遅延を防ぎやすくなります。

選定では、導入自治体数だけでなく、対象手続きと同じ本人確認レベル、審査・補正・決裁・交付までの対応範囲を確認します。SaaS・パッケージ、ローコード、既存基盤への追加開発、フルスクラッチを同じ要件表で比較し、実際の職員と住民がデモを操作します。RFPには、LGWANやガバメントクラウドとの接続、API・ファイル連携、データの所有権と持ち出し、ログ保存、脆弱性対応、障害時の責任分界、フォーム追加単価、制度改正対応費、他社へ移行する場合の条件を明記します。画面の見た目が優れていても、審査後の業務を別システムへ手入力するサービスなら、導入目的を満たせないためです。

設計では、画面仕様より先に業務フローを確定します。申請者が入力を始めてから、受付完了、担当振り分け、審査、補正依頼、再申請、決裁、手数料確定、交付、保管までの状態を定義し、各状態で誰が何を操作できるかを権限表にします。入力項目は必須・任意だけでなく、条件分岐、入力形式、エラーメッセージ、添付ファイルの容量、保存期間まで決めます。マイナンバーカード、公的個人認証、ID・パスワード、多要素認証などは、手続きのなりすましリスクや法的要件に応じて選びます。低リスクの申込まで一律に強い認証にすると離脱が増え、高リスクの申請を簡易認証にすると審査や監査の負担が増えるため、リスク評価を基準にすることが大切です。

テストは、正常に申請できるかだけでは不十分です。入力途中で通信が切れた場合、添付ファイルが大きすぎる場合、同じ申請を二重送信した場合、補正期限を過ぎた場合、決済だけ失敗した場合、担当者が交代した場合、交付後に訂正が必要になった場合まで確認します。住民向けにはスマートフォンの複数機種、文字サイズ変更、キーボード操作、読み上げ、やさしい表現を確認し、職員向けには検索・一覧・一括処理・権限分離・監査ログを確認します。受入テストの合格条件は、申請完了率、エラー時の復旧、処理時間、通知到達、帳票の内容などを数値または判定文で定め、担当課が自分で再現できるようにします。

本番稼働では、いきなり紙の窓口をなくすのではなく、先行手続きを限定してオンラインと従来チャネルを並行させます。開始前には、担当者、問い合わせ窓口、障害連絡先、個人情報の誤送信時の対応、紙に戻す判断基準を決めます。初週は、申請件数、途中離脱、補正率、問い合わせ内容、審査にかかった時間、オンライン比率を日次で確認します。利用率が低いときに「住民がデジタルに慣れていない」と決めつけず、必要な手続きにたどり着けない、本人確認が難しい、添付書類が準備できない、完了メールが届かないなど、導線ごとの原因を分けて改善します。

定着フェーズでは、稼働をゴールにせず、月次または四半期ごとにKPIを見直します。代表的な指標はオンライン申請率、申請完了率、補正率、処理時間、来庁・郵送件数、問い合わせ件数、職員の転記時間、住民満足度です。フォームを追加する担当者には、命名規則、本人確認の選び方、個人情報の扱い、アクセシビリティ、テスト手順を標準化した運用ガイドを渡します。制度改正時の改修費、脆弱性対応、バックアップ復元訓練、監査ログの確認、ベンダー交代時のデータ出力も契約と運用計画に含めます。トラストバンクの公表事例では、松阪市がLoGoフォームを約1,500フォームまで広げ、フォーム導入をきっかけに業務そのものを見直す動きにつながったとされています（出典: 株式会社トラストバンク、2023年）。

行政手続きオンライン化システムの費用相場とコストの内訳

費用は、手続き数だけでなく、認証の強度、審査・決裁の複雑さ、既存の住民情報・税務・福祉システムとの連携、LGWANやガバメントクラウド対応、データ移行、研修、保守の範囲で変わります。以下は公表された自治体契約と業務システム一般の工数目安を組み合わせた推定レンジであり、行政手続きオンライン化システム全体の一律の定価ではありません。見積もりを取るときは、初期費用と年額費用を分け、どこまで含む数字かを確認します。

数手続きのフォーム、通知、簡易的な受付管理を既存SaaSで始める場合は、初期300万〜1,500万円程度が一つの目安になります。ここには、手続きの棚卸し、フォーム設計、権限設定、初期設定、操作研修などが含まれることがありますが、本人確認、決済、独自の帳票、既存システム連携、手続き追加は別料金になりやすいです。小規模導入でも、受付後に担当課が手作業で転記するなら、追加のワークフローやCSV出力が必要になります。価格だけで決めず、先行する手続きの処理時間をどこまで削減できるかで判断します。

複数部署への展開、審査・補正・決裁・電子交付、認証・決済、住民情報や福祉などとの連携を含む場合は、1,500万〜4,000万円程度のレンジで見積もられることがあります。一般的な業務システムの工数配分では、要件定義が全体の約10％、設計が約10〜20％、開発が約40〜60％、テストが約10〜20％という考え方が使われますが、行政案件では調達支援、セキュリティ審査、移行、研修、並行運用も加わります。熊本市の2025年度公表契約でも、くらしの手続きガイドのクラウド利用料は171万6,000円、書かないワンストップ窓口支援システムの導入・運用保守は4,735万3,350円、福祉系システムとの連携対応は2,691万1,280円でした（出典: 熊本市「令和7年（2025年）5月随意契約」）。これらは同一システムの開発費ではありませんが、案内、受付、窓口、基幹連携を別契約・別費目で予算化する実例として参考になります。

全庁型、独自の複雑な審査、住民情報・税・福祉・窓口をまたぐ連携、標準化対応、複数年の移行を含む案件では、3,000万〜8,000万円超になることもあります。熊本市の同じ公表契約には、ガバメントクラウド利用権5,325万5,000円など、オンライン申請そのものとは別の基盤費も記載されています。基盤費や既存システム運用費まで同じ「開発費」として比較すると、サービスの優劣を誤って判断しやすくなります。なお、保守運用は初期開発費の年5〜15％程度という一般的な置き方もありますが、SaaSの利用料、申請件数課金、セキュリティ監視、フォーム追加、制度改正対応を合算した実額は契約条件で変わるため、幅を持って予算化します。

年額費用には、サービス利用料、クラウド・ネットワーク費、監視・バックアップ、ヘルプデスク、定期的な脆弱性対応、フォーム追加、制度改正対応、本人確認や決済の従量課金が含まれます。熊本市の公表契約では、LoGoフォームの電子文書交付追加と汎用メール追加がそれぞれ1,000通あたり月額11,000円、オンライン決済の発注見込額は納付額の3.5％とされていました（出典: 熊本市、2025年）。このように、固定費だけでなく申請件数や交付数に連動する費用があります。見積書には、年間の想定件数を3パターン程度で置き、利用が増えた場合の5年総額も確認します。

行政手続きオンライン化システムの見積もりを取る際のポイント

行政案件の見積もりは、合計金額だけを比べると判断を誤ります。ベンダーによって「初期設定」「開発」「導入支援」「保守」「連携」の含め方が異なり、安い提案ほど後から追加費用が発生する場合があるためです。発注前に、対象手続き、利用者数、年間申請件数、データ連携、セキュリティ、移行、研修、運用の責任範囲を同じ条件で提示し、金額と前提条件を一対一で比較します。

見積もり依頼書には、手続き一覧だけでなく、各手続きの年間件数、ピーク時の同時利用、申請者の属性、本人確認の必要性、添付書類、決済、審査者・決裁者、通知・交付方法、保存年限を記載します。既存システムは名称だけでなく、連携方式、データ項目、文字コード、接続可能な時間帯、テスト環境の有無、連携先の改修負担まで確認します。さらに、アクセシビリティ、LGWAN接続、ガバメントクラウド、バックアップ、ログ、脆弱性診断、災害時の復旧目標、個人情報の委託先管理も要求事項に入れます。曖昧な「必要に応じて対応」ではなく、「何を、誰が、いつまでに、何件まで行うか」に変換することがポイントです。

比較先は、行政向けSaaS、ノーコード・ローコード製品、自治体基幹に強いSI、独自開発会社など、異なるタイプを含めます。評価時には同じ手続きのシナリオを渡し、住民がスマートフォンで申請し、本人確認を行い、添付して送信し、職員が審査・補正・決裁し、通知と交付まで進める様子を見ます。チェックするのは、職員がフォームを追加できるか、入力ミスを防げるか、補正の履歴が残るか、連携失敗を検知できるか、ログを監査に使えるか、データを取り出せるかです。ベンダーから「標準機能で可能」と回答された項目は、画面デモまたは仕様書で確認し、将来開発の予定だけで評価しないようにします。

特に確認したいのは、制度改正でフォームや審査ロジックを変更する費用、手続き追加の単価、申請・添付・通知の従量課金、決済手数料、本人確認の利用料、連携先の改修費、データ移行費、職員研修の追加回数です。障害時には、どの会社が一次受付をするのか、復旧目標時間、データ欠損の確認、再送・再審査の手順を合意します。契約終了時のデータ返却形式、保存期間、削除証明、他社へ移行する際の支援条件も、導入前に確認する必要があります。デジタル庁が進める次期オンライン申請サービスでは、情報の再入力削減、補正連絡、オンラインでの通知・完結が重視されているため、将来の連携余地を閉じない設計にすることも重要です（出典: デジタル庁「行政手続のオンライン化」、2026年6月更新）。

よくある質問（FAQ）

行政手続きオンライン化システムでは、費用だけでなく、どこまでオンラインで完結するか、本人確認をどう設計するか、既存チャネルをどう残すかがよく問われます。ここでは、導入前に担当者が判断しやすいよう、代表的な質問へ直接回答します。

最初に、全手続きの一覧を作り、年間件数、処理時間、本人確認、添付書類、審査・決裁、交付方法を棚卸しします。そのうえで、住民効果と職員の削減効果が高く、例外処理が比較的少ない1〜2手続きを選び、先行導入のKPIと成功条件を決めます。

すべての手続きを同じ強度にする必要はありません。申込内容の影響、なりすまし時の被害、法令上の要件、利用者の負担を評価し、低リスクの問い合わせや予約は簡易認証、高リスクの給付・証明・届出はマイナンバーカードの電子署名や多要素認証などを検討します。認証できない住民のために、窓口や郵送などの代替手段と問い合わせ対応も残します。

短期間で複数手続きを始めたい、制度改正への対応をサービス側に任せたい場合はSaaSやパッケージが向きます。独自の審査、複雑な基幹連携、全庁の業務を一体で変える必要がある場合は追加開発やスクラッチを検討しますが、初期費用だけでなく保守、改修、ベンダー依存、移行費を含む5年総額で比較します。実際には、標準機能をSaaSで使い、差別化が必要な連携部分だけを追加開発する構成も現実的です。

標準機能を使ったSaaS導入は1〜3か月、手続き棚卸しと複数部署への展開を含む導入は3〜6か月、基幹連携や独自開発を含む案件は6〜12か月以上が目安です。本人確認、決済、大量のデータ移行、並行運用、調達手続きがあると期間は延びるため、稼働希望日から逆算して要件整理、受入テスト、職員研修の期間を先に確保します。

まとめ

発注前には、要件整理で対象手続きとKPIが決まっているか、選定で同じシナリオを比較したか、設計開発で認証・権限・連携・ログが定義されているか、テストで異常系を確認できるか、稼働で代替チャネルと障害対応が決まっているか、定着で追加改修と運用担当が決まっているかを確認します。どれか一つでも未確定なら、見積もりの前提条件として残し、決定時期と担当者を記録します。

最初から全庁のすべてを一度に変えるより、効果が測りやすい手続きで成功パターンを作り、職員が自らフォームを改善できる運用を整えてから対象を広げる方が、定着しやすくなります。申請完了率や処理時間だけでなく、補正率、問い合わせ、窓口・郵送の残存件数を定期的に確認し、システムと業務の両方を更新します。

行政手続きオンライン化システムの進め方は、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズに分けると、判断すべきことが見えやすくなります。特に重要なのは、申請フォームの導入を目的にせず、受付後の審査、補正、決裁、通知、交付、保管までを業務フローとして設計することです。

費用は、部分導入で300万〜1,500万円程度、複数部署・基幹連携を含む導入で1,500万〜4,000万円程度、全庁型やスクラッチ開発で3,000万〜8,000万円超という推定レンジがあります。ただし、これは公表契約や一般的な業務システムの相場をもとにした目安であり、認証、決済、データ連携、運用保守、制度改正対応を含む範囲で変わります。相見積もりでは、初期費用とランニングコスト、固定費と従量課金、標準機能と追加開発を分けて比較してください。

まずは手続きの棚卸しから始め、住民の利便性と職員の処理負担を同時に改善できる手続きを選びます。先行稼働で申請完了率や補正率を確認し、利用者の声と職員の実績をもとにフォームと業務を継続的に改善することが、行政手続きオンライン化を定着させる近道です。

▼全体ガイドの記事
・行政手続きオンライン化システム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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