行政手続きオンライン化システムの発注は、対象手続きを洗い出して要件を整理し、提案を比べてから段階的に導入する流れで進めます。この順序を守ると、追加費用や二重運用を抑えやすくなります。
発注準備から導入後までを、RFPや費用、委託先の選定を中心に順に見ていきます。
▼全体ガイドの記事
・行政手続きオンライン化システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
行政手続きオンライン化システムの全体像
行政手続きオンライン化システムは、住民や事業者がパソコン・スマートフォンから申請し、行政側が受付から処理完了までをデジタルでつなぐ業務システムです。
発注する側は、電子申請の入口だけでなく、業務の後工程まで発注範囲に含めて決めます。
申請画面と職員側処理の一体的な検討
申請者向けには、手続き検索、条件分岐フォーム、添付の機能が要ります。下書き保存と状況照会、補正対応、メールやSMS通知が、申請の途中と申請後の連絡を支えます。
職員側では、申請を受け付けて担当者へ振り分け、審査や差し戻し、承認までを扱える必要があります。さらに、電子決裁や交付文書の作成、操作履歴の確認も欠かせません。
入口だけを外注し、受付後にPDFを印刷して手入力する運用が残ると、住民の利便性は上がっても職員の負担は十分に減りません。
本人確認と既存システム連携の費用への影響
本人確認と既存システム連携は、手続きのリスクや接続先に応じて、発注側が条件を整理しておく必要があります。
- 本人確認：ID・パスワード、ワンタイムパスワード、多要素認証、マイナンバーカードの公的個人認証、GビズIDを、手続きごとに使い分けます。
- 既存連携：税、福祉、住民情報、施設予約、文書管理、決済ごとに、APIかファイル連携か、連携の頻度、エラー時の再送方法を確認します。
LGWANやガバメントクラウドへの接続条件も、早い段階で確認しておきます。また、デジタル庁は、補正連絡や通知書のオンライン送付まで含めたオンライン完結を目指しています。
次期オンライン申請サービスは、2026年9月以降の本格運用が予定されています（出典: デジタル庁「行政手続のオンライン化」, 2026年）。
行政手続きオンライン化システムの発注・外注の始め方
発注は、対象手続きを洗い出し、現状の業務を一覧にするところから始めます。この一覧があると、ベンダーに同じ条件で相談できます。製品名や開発会社の候補を探すのは、そのあとです。
対象手続きの洗い出しと優先順位付け
同じ条件でベンダーへ相談できるよう、手続きごとに現在の件数や手間、着手の順番、効果の出やすさを記録して、現状と優先度を整理します。
- 業務の現状：年間件数、繁忙期、窓口滞在時間、郵送の有無、添付書類の種類、手数料、審査・決裁、保管先。
- 着手順：利用頻度と職員の削減効果をもとに、MUST（必須）と将来拡張するWANTに分けて決めます。
- 効果と例外：定型で件数の多い手続きは効果を測りやすい一方、法令解釈や現地確認が多い手続きでは、紙の代替も設計します。
発注側は、処理時間や法的根拠、現在の課題も、相談の前に整理しておきます。
SaaS・ローコード・スクラッチの同じ条件での比較
発注側は、業務の規模や独自の要件に応じて、製品方式と発注方式を選びます。
- 小規模・短期：数手続きから始めるなら、行政向けSaaSやパッケージが候補になります。
- 職員による追加：職員がフォームを自分で追加しやすいことを優先するなら、ローコードを検討します。
- 深いシステム統合：住民情報や複数の業務システムを深く統合するなら、既存基盤への追加開発やスクラッチ開発も選択肢に入ります。
- 発注方法：標準機能はサービス調達、独自要件は開発委託、複数提案の比較はRFPで募集します。
製品デモでは、申請画面を見るだけでなく、補正から交付、エラー処理、ログ確認まで実際に操作して確かめます。
RFPと要件整理に入れるべき項目
RFPは、開発会社に自由な提案を求める資料であり、発注者が比較条件をそろえる基準です。発注側は、現行業務と目標、非機能要件をRFPで指定します。
さらに、データ連携、導入後の運用、見積書の分け方まで書き込みます。こうして条件をそろえておくと、安くても必要な作業が抜けた見積もりを見抜きやすくなります。
業務フロー単位での機能要件の書き方
申請者側の機能要件は、入力から申請完了までに必要な機能を、流れに沿って書き出します。
- 申請準備：手続き検索、入力補助、条件分岐、本人確認、電子署名。
- 申請と連絡：添付、下書き、状況確認、補正、通知、オンライン決済。
- 利用しやすさ：多言語対応とアクセシビリティ。
- 職員処理：受付、担当者への振り分け、審査、差し戻し、承認、電子決裁。
- 記録と出力：交付、検索、帳票出力、監査ログ。
各機能は、「必須」「代替可」「将来対応」のいずれかに分けておきます。
画面数で数えるより、一件の申請が完了するまでの流れで書くと、提案内容の差が見えてきます。
非機能要件とセキュリティの責任分界の確定
RFPでは、サービスの品質水準と、障害時の責任分担を具体的に書き込みます。
- 稼働と復旧：可用性、応答時間、同時接続数、バックアップ、障害復旧を定めます。
- セキュリティ：脆弱性診断、監視、ログ保存期間、権限分離、暗号化、個人情報、再委託管理を記載します。
- 障害対応：本人確認、クラウド、決済、通知で障害が起きたとき、誰が調査し、住民へどう案内するかを決めます。
本人確認は、すべて同じ強さにはせず、手続きのリスクと利用者の負担を評価して決めます。また、デジタル庁の本人確認ガイドラインも、脅威やなりすましの影響を踏まえて手法を選ぶ考え方を示しています。
データ移行と導入後の運用を含む初期要件
移行と導入後の運用の要件も、RFPに具体的に書き込んでおきます。
- 移行対象：申請データ、利用者情報、様式、添付ファイルの対象期間、形式、欠損・重複の扱いを決めます。
- 移行確認：移行リハーサルを行い、検証担当を決めます。
- 導入後の運用：制度改正時のフォーム修正、フォーム追加、職員研修、問い合わせ対応、操作マニュアル、データ出力を含めます。
- 契約終了時：データの返却・消去を要件に入れます。
2026年時点では、紙の様式をもとにAIでフォームを作るサービスもあります。ただし、生成結果を法令、様式、アクセシビリティの観点で人が確認する工程は省けません。
業務の不確実性に合わせた契約形態の選択
要件が固まっている範囲と、検証しながら決める範囲を分けて契約するのが現実的です。
すべてを一括で任せる場合も、要件定義、設計・開発、テスト、移行、保守を工程と成果物ごとに分けておきます。そうすると、変更があったときに判断しやすくなります。
請負契約での成果物と変更条件の明確化
請負契約は、合意した仕様どおりにシステムを完成させる契約です。画面、API、帳票、テスト仕様書、移行結果、マニュアルなどの成果物と検収条件を明記できる場合に向いています。
制度改正や庁内調整で変更が多い場合は、変更管理や追加見積もりの単位、納期への影響、発注者の確認期限を定めておきます。条件が曖昧なままだと、費用や責任をめぐる争いになりがちです。
伴走支援や要件定義に向く準委任契約
準委任契約は、専門家の知識や作業時間を提供してもらう契約です。
- 向く業務：成果物だけで品質を測りにくい現状分析、BPR、RFP作成支援、プロジェクト管理、職員とのワークショップ、運用改善。
- 作業と役割：作業の中身がはっきりしないままだと、会議への参加だけで費用が積み上がる可能性があります。
- 納品と意思決定：月次の作業報告、成果物、課題一覧、次月計画を納品対象にし、発注者側も意思決定を遅らせないようにします。
SaaS利用契約での料金単位とデータ出口の確認
SaaSやパッケージでは、課金の単位と契約終了時の条件を確かめておきます。
- 基本料金：初期設定費、月額・年額利用料、ユーザー数、申請件数、手続き数、ストレージの各費目。
- 従量料金：本人確認、決済、通知、サポートのうち、どれが課金単位になるかを見ます。
- 追加費用：フォーム追加のたびに費用が発生するか、制度改正の修正が利用料に含まれるかを確認します。
- データ出口：申請データをCSVなどで出せるか、添付ファイルも返却されるか、削除証明を出せるか決めます。
返却や削除の条件を決めておくと、将来のベンダー変更に備えられます。
行政手続きオンライン化システムの費用相場と内訳
費用は、手続き数や認証の強度、審査・決裁の複雑さによって大きく変わります。さらに、既存システムとの連携やデータ移行、運用支援も費用を左右します。
ここで示す金額は、業務システム一般の工数感と自治体が公表した契約を組み合わせた目安です。すべての案件に当てはまる定価ではありません。
規模別の費用レンジの予算検討への活用
予算を検討するときは、規模ごとの推定レンジと、対象とする業務を対応させて見ます。
- 部分導入：数手続きのフォーム、通知、簡易受付に絞る場合、初期300万〜1,500万円程度が検討レンジです。
- 中規模導入：複数部署で審査、補正、決裁、文書交付を行い、既存連携もする場合、1,500万〜4,000万円程度が中心です。
- 全庁型：住民情報、税、福祉、窓口、認証、決済をまたぐ場合、3,000万〜8,000万円超になる可能性があります。
各金額は個別案件の推定レンジで、機能数に加えて、連携方式や導入支援の範囲によって上下します。
公表契約を使った機能別の予算分解
熊本市が公表した2025年度契約では、くらしの手続きガイドクラウドサービス利用料が171万6,000円でした（出典: 熊本市「令和7年（2025年）5月 随意契約」, 2025年）。
LoGoフォーム関連オプションの発注見込額は26万4,000円でした（出典: 熊本市「令和7年（2025年）5月 随意契約」, 2025年）。さらに、オンライン決済の発注見込額は143万8,000円でした（出典: 熊本市「令和7年（2025年）5月 随意契約」, 2025年）。
同じ契約でも、費目ごとに金額は大きく異なります。
- 標準仕様対応：共通基盤の申請管理システムに関する業務は973万5,000円でした（出典: 熊本市「令和7年（2025年）5月 随意契約」, 2025年）。
- 住民情報系の運用：住民情報系システムの運用管理は1億4,190万円でした（出典: 熊本市「令和7年（2025年）5月 随意契約」, 2025年）。
- 共通基盤の運用：共通基盤システムの運用管理は4億6,332万円でした（出典: 熊本市「令和7年（2025年）5月 随意契約」, 2025年）。
これらは同じ種類の開発費ではありません。案内やフォーム、決済のほか、標準仕様対応や基幹運用の費目も含まれるため、一括の金額では比べられません。
ランニングコストと追加費用の切り分け
継続費と追加作業を分けて見積もり、年額の負担を確かめます。
- 継続費：SaaS利用料、クラウド・LGWAN接続費、利用者や申請件数に応じた従量料金、保守、監視、脆弱性対応、ヘルプデスク、研修。
- 追加費用：フォーム追加、制度改正対応などを見積もります。
- 年額の目安：小規模は100万〜500万円程度、中規模以上は500万〜1,500万円以上という推定もあります。
一般的な業務システムでは、保守運用費を初期開発費の年5〜15％程度と見ることがあります。
行政向けサービスは、利用料やセキュリティ監視の契約方式が異なります。そのため、この比率をそのまま当てはめず、年額の見積もりを別に取ります。
小規模・中規模以上の年額レンジは推定であり、公表価格の一律相場ではありません。
委託先の選定と見積比較の着眼点
委託先は、自治体数や知名度だけでなく、同程度の手続きの実績、既存連携、導入後の運用体制で比べます。
RFPへの回答が出たら、価格だけでなく、要件の解釈と前提条件を確認します。さらに、標準機能と追加開発の線引き、発注者側に残る作業も見ておきます。
発注範囲に合う委託先の得意領域
委託先は、発注範囲と得意領域が合っているかで比べます。
- 住民向け申請：短期間で導線を整える場合は、スマートフォン、本人確認、決済、テンプレート対応の行政向けSaaSが候補になります。
- 基幹系との連携：自治体向けSIや基幹ベンダーに、接続の体制があるかを確認します。
- パッケージ活用：申請者から職員まで扱う製品は、標準機能と個別開発を切り分けて見ます。
トラストバンクのLoGoフォームは、自治体専用のノーコード電子申請システムです。公式発表では、導入数が500自治体を突破しています（出典: 株式会社トラストバンク「LoGoフォーム」, 公表時点）。
たとえば、株式会社NTTデータ関西の申請管理システムのように、申請者から自治体職員までの処理を対象とするパッケージもあります。
見積書の費目と前提条件をそろえた比較
費目と前提条件をそろえると、提案価格に含まれる範囲を比べられます。
- 作業費：要件定義、UX・画面設計、開発、連携、認証、決済、移行、テスト、研修、リリース、保守。
- 料金条件：初期・継続費、標準・オプション、手続き数、追加単価、問い合わせ時間、制度改正。
提案価格が低くても、連携テストや移行リハーサル、アクセシビリティ確認、職員研修が発注者側の作業になっていることがあります。そのため、金額の大小より先に、抜けている作業と前提条件を確認します。
提案説明での責任分界と将来の変更に関する質問
提案説明では、障害時の責任分界と将来の変更条件、導入実績を聞いておきます。
- 障害・安全管理：一次窓口、復旧目標、セキュリティインシデントの報告時間、再委託先、データの保管場所、ログの保存期間を確認します。
- 契約終了・変更：データ返却、手続きの追加や制度改正にかかる営業日数、担当課が自分で修正できる範囲を聞きます。
- 実績と引き継ぎ：自治体名の数だけで見ずに、本人確認レベル、審査・交付の自動化、既存連携、利用率、削減効果、ベンダー交代時の資料の受け渡しを確認します。
発注後の導入を成功させる進め方
契約後は、発注者側の業務担当と情報政策担当、委託先のプロジェクト責任者が定例会を開き、課題と決定事項を一つにまとめて管理します。
最初から全庁展開を目指すより、まず1〜2手続きでPoCや先行稼働を行います。そのうえで、申請完了率や差し戻し率、処理時間、問い合わせ数を確認してから広げると、現場の改善点を見つけやすくなります。
利用者・職員・連携先の三方向によるテスト
テストでは、利用者・職員・連携先のそれぞれの視点から、正常系と異常系を確かめます。
- 入力と認証：入力エラー、添付ファイル、本人確認・決済の失敗を確認します。
- 処理の流れ：補正、差し戻し、承認、通知、交付、取消、再申請の正常系・異常系を確認します。
- 申請者：スマートフォンで迷わず申請を完了できるか検証します。
- 職員・連携先：職員が一覧から処理状況を把握できるか、連携先で文字化けや重複が起きないかを別々に検証します。
- 移行・障害対応：リリース前に本番相当のデータで移行リハーサルを行い、障害時に窓口・郵送へ切り替える手順も訓練します。
公開後の利用率と職員の処理時間の改善
公開後は、利用状況と職員の処理状況を追い、改善につなげます。利用率が低いときは、必ずしもシステムの問題とは限りません。手続きの探しにくさや認証の負担、スマートフォンでの操作性が原因になっていることもあります。
- 申請指標：オンライン申請率、途中離脱率、入力不備率、補正回数を追います。
- 処理指標：平均処理時間、問い合わせ件数、電子交付率、窓口への切り替え件数を見ます。
- 利用率が低い場合：必要書類の説明不足など、システム以外の原因も含めて確かめます。
- 改善方法：案内と研修を改善し、一定期間ごとにフォームや業務フローを見直せる契約にすると、導入効果を維持できます。
よくある質問（FAQ）
発注では、費用だけでなく、対象手続き、本人確認、既存システム連携、契約後の運用を同時に確かめる必要があります。特に、発注前によく質問される内容を取り上げます。
行政手続きオンライン化システムの発注費用はいくらですか？
初期費用は導入範囲によって異なります。ここで示す金額は、案件条件から算出したレンジです。
- 部分導入：数手続きなら初期300万〜1,500万円程度が目安です。
- 中規模導入：審査・決裁・連携を含む場合は1,500万〜4,000万円程度が目安です。
- 全庁型・基幹連携：3,000万〜8,000万円超になる可能性があります。
年額利用料や保守は別に見積もります。連携、認証、決済、移行、研修も、それぞれ分けて考えます。
本人確認はマイナンバーカード必須ですか？
マイナンバーカードは必須とは限りません。
- 選定条件：手続きのリスク、なりすまし時の影響、申請者の負担、電子署名の必要性を評価します。
- 認証方法：簡易認証、多要素認証、マイナンバーカード、公的個人認証などを使い分けます。
- 利用者への影響：認証を強くすると安全性が上がる一方、利用できる人が減り、問い合わせや運用費が増えることがあります。窓口・郵送の代替手段も設計します。
SaaSとスクラッチ開発はどちらを選ぶべきですか？
短期間で標準的な手続きを増やすならSaaSやパッケージが向き、独自の審査・決裁や基幹連携が中核になるなら、追加開発やスクラッチが候補になります。
共通要件はRFPにまとめ、SaaSで対応できる範囲、設定で対応する範囲、開発が必要な範囲を分けて整理します。こうすると、過剰なスクラッチ化を避けながら、不足する機能も把握できます。
相見積もりは何社から取ればよいですか？
同じRFPで比べられる提案を、2〜4社程度から集めるのが実務的です。SaaS、行政向けパッケージ、基幹連携に強いSIなど、異なるタイプの会社を含めます。
各社には同じデータと条件を渡し、初期費用と5年間の継続費、追加手続きの単価を比べます。さらに、発注者作業、移行、終了条件も見ます。
まとめ
対象手続きと現状の業務を洗い出し、申請から審査、決裁、通知、保管までの流れを定めます。
RFPには、機能と非機能の要件、本人確認、連携を含めます。移行や保守、データ返却も、前の節で挙げた項目どおりに書き込みます。そのうえで、SaaS、パッケージ、ローコード、スクラッチを同じ条件で比べます。
発注前の予算と契約の境界の決定
部分導入は初期300万〜1,500万円程度、中規模導入は1,500万〜4,000万円程度が推定レンジです。全庁型や基幹連携では、3,000万〜8,000万円超という推定を参考にできます。
手続き数や認証、連携、移行、運用の範囲によって、金額は変わります。年額利用料や保守、フォーム追加、制度改正への対応を確認します。決済や研修、終了時の返却も、確認が必要です。
導入後まで伴走できる委託先の選定
委託先は、自治体数だけでなく、本人確認やLGWAN・クラウド接続、基幹連携を確認します。さらに、障害対応や研修、制度改正への対応、移行と引き継ぎも見ておきます。
まず、1〜2手続きで効果を測り、住民の利用率と職員の処理時間を見ながら広げていくと、業務基盤として育てやすくなります。
▼全体ガイドの記事
・行政手続きオンライン化システム開発の完全ガイド
▼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を創業。