電子申請システム開発の発注/外注/依頼/委託方法について

電子申請システムの発注・外注は、申請フォームだけでなく、受付から審査・決裁・通知までの業務と連携を整理し、5年間の総額と運用責任をRFPで比較することが成功の近道です。

電子申請システムは、住民や事業者がスマートフォンやパソコンから申請し、行政側が受付、本人確認、添付書類の確認、審査、差し戻し、決裁、交付までを電子的に処理する仕組みです。単なるWebフォームを外注するだけでは、紙の審査や手入力が残って期待した効果が出ません。本記事では、発注形態の選び方、RFP・要件整理、請負と準委任の使い分け、費用相場、委託先の選定、見積比較、契約後の受入までを順番に解説します。

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

電子申請システムの発注・外注で押さえる全体像

発注時に最初に決めるべきことは、どの会社へ依頼するかではなく、どこまでを電子化の対象にするかです。申請者向けの入力画面、認証、添付ファイル、決済、職員の審査ワークフロー、既存システム連携、通知、監査ログを一つの業務として整理すると、必要な外注範囲と見積もりの前提が見えてきます。

電子申請システムは、住民・事業者が利用するフロントエンドと、職員が申請を処理するバックオフィスを組み合わせた業務システムです。フロント側には手続検索、入力チェック、途中保存、本人確認、電子署名、添付、申請状況の照会、差し戻し後の修正・再提出が必要になります。事業者向け手続では、法人認証のGビズIDを使うか、メール認証や独自アカウントを使うかによって、画面と連携の設計が変わります。

バックオフィス側では、受付、担当課への振り分け、審査、補正依頼、職権訂正、決裁、電子交付、帳票出力、問い合わせ履歴、操作ログを扱います。マイナポータル経由の申請を受け取る場合は、電子申請等情報受取等APIを通じてLGWAN接続系や個人番号利用事務系へデータを連携する構成もあります。したがって、発注の対象は画面の制作費だけではなく、業務フロー、ネットワーク、データ、運用を含むシステム全体です。

電子申請を導入したかどうかだけでは、発注の成果を正しく評価できません。申請完了率、不備率、差し戻し件数、審査にかかる時間、問い合わせ件数、オンラインで最後まで完結した割合をKPIに設定します。例えば申請件数が増えても、不備と電話問い合わせが増えて職員の負担が大きくなれば、利用者と行政の双方にとって改善とは言いにくいためです。

川崎市の公開事例では、汎用電子申請システムに操作ガイドを追加し、学校給食申込書の不備率を81.7％、国保資格喪失届の不備率を56.6％改善し、後者では年間約105時間の業務削減につなげています（出典: テックタッチ「川崎市の電子申請の不備率改善」、2025年公開）。この事例が示すように、開発会社に初期構築だけを任せるのではなく、稼働後のデータ分析と画面改善まで委託範囲に含めることが重要です。

電子申請システムの発注形態はどれを選ぶべきですか？

発注形態は、SaaS・パッケージ、自治体向けクラウド、ローコード、スクラッチ開発を、費用だけでなく導入速度、柔軟性、法改正対応、データ移行、解約時の出口で比較して決めます。標準的な手続を短期間で増やすならSaaS型が候補になり、独自の審査や交付、複雑な既存連携が中心なら追加開発やスクラッチが必要になります。

標準SaaSやパッケージ型は、手続フォーム、受付、審査、通知、権限管理などの共通機能が整っており、早く始めやすい方式です。職員が手続を追加できるサービスを選べば、毎回の小さな改修を外注せずに運用でき、複数課への横展開もしやすくなります。2026年時点で、デジタル庁は2025年4月から先行実証参加自治体による次期オンライン申請サービスの受付を始め、2026年6月16日時点の対象自治体・手続を公開しています（出典: デジタル庁「行政手続のオンライン化」、2026年）。国の共通サービスやマイナポータルとの連携可能性を確認しながら、独自開発を最小限にすることが発注のポイントです。

一方で、標準機能にない独自の審査順序、特殊な帳票、複雑な代理申請、基幹システムとのリアルタイム連携は、オプションや個別開発が必要になる場合があります。見積依頼では「標準」「設定」「追加開発」「対象外」の4区分で回答してもらい、標準料金だけを見て安いと判断しないようにします。

スクラッチ開発は、独自の審査ルールや交付処理、既存基幹システムとの連携を細かく設計できる点が強みです。ただし、本人確認、添付ファイル、アクセスログ、脆弱性対応、バックアップ、制度改正、ブラウザやスマートフォンの更新までを継続的に管理する必要があります。自由度が高い分、初期開発費だけでなく、法改正やセキュリティ更新を含む保守体制を契約前に確保します。

スクラッチを選ぶ前に、標準機能への業務変更、設定による対応、限定的なAPI連携で解決できないかを確認します。独自仕様が住民サービスや法令上不可欠なのか、従来の慣行を残したいだけなのかを分けると、過剰な開発を避けられます。提案書には、将来の手続追加を職員が行える範囲と、毎回開発会社へ依頼する範囲を明記してもらいます。

一括発注は、現状分析、設計、開発、移行、テスト、研修、切替、保守までを一つの事業者にまとめやすく、発注者の調整負担を抑えられます。責任の所在を一つにしやすい反面、提案内容や価格の妥当性を比較しにくくなり、委託先への依存が強まる可能性があります。一括で依頼する場合でも、工程別の成果物、費用、受入条件を見積書で分けてもらいます。

分離発注は、現状調査・PMO、申請基盤、クラウド・ネットワーク、データ移行、第三者検証、運用保守などを分ける方式です。専門性の高い会社を選びやすく、相見積もりの透明性も高まりますが、障害発生時の原因切り分けと責任分界が複雑になります。分離する場合は、全体統合責任者、API仕様の管理者、受入テストの責任者、切替判断者を契約と体制図で定めます。

RFPと要件整理はどの順番で進めますか？

RFPは、機能一覧だけを配布する資料ではありません。各社が同じ条件で提案と見積もりを作れるように、現行業務、対象手続、利用者数、申請件数、既存システム、ネットワーク、データ、非機能、移行、運用、契約条件を一つの前提としてまとめる資料です。作成順序は、現状棚卸し、対象手続の優先順位付け、将来業務の決定、RFP作成、質問回答、提案比較とします。

最初に、手続名、申請者、年間件数、繁忙期、提出期限、添付書類、本人確認、手数料、審査担当、決裁者、通知方法、保存年限を一覧にします。現状の業務フローには、紙の申請書を受け取ってからスキャンする作業、表計算ソフトへの転記、電話での不備確認、紙の決裁、郵送での交付など、システム画面に現れない工程も含めます。これらを拾わないと、導入後も手作業だけが残ります。

成果物は、手続一覧、業務フロー、画面遷移、帳票一覧、権限表、データ項目一覧、外部連携一覧、課題一覧の8種類に分けると、RFPの別紙として使いやすくなります。特に例外処理を確認することが重要です。代理申請、差し戻し後の再提出、添付不足、手数料の返金、申請期限の超過、通信障害、紙申請との併存を、担当課と一緒に洗い出します。

機能要件には、手続検索、入力補助、途中保存、本人確認、電子署名、添付、決済、受付番号、状況照会、補正依頼、審査、決裁、電子交付、通知、帳票、検索、データ出力を記載します。マイナンバーカードを使う場合は、JPKIの署名用電子証明書を使うのか、券面事項入力補助を使うのか、スマートフォンで完結させるのかを手続ごとに区別します。法人手続ではGビズIDの対象範囲と、代表者・担当者・代理人の権限も要件になります。

非機能要件には、同時利用者数、画面応答、稼働時間、障害時の受付継続、バックアップ、復旧時間、ログ保存期間、監視、脆弱性対応、暗号化、アクセス権限、データ保管場所、再委託管理を含めます。行政手続では、インターネット接続系、LGWAN接続系、個人番号利用事務系の間で、どのデータをどの経路で渡すかが重要です。申請情報を受け取るAPI、連携サーバ、基幹システムへの取込、エラー時の再送方法までRFPに書くと、会社ごとの前提差を抑えられます。

申請履歴、添付ファイル、利用者アカウント、審査状態、交付記録を既存システムから引き継ぐなら、移行要件を後回しにしてはいけません。対象期間、項目、コード体系、文字、欠損、重複、添付資料の保存方法、移行後の照会方法、旧システムをいつまで参照できるかを決めます。移行件数だけではなく、申請番号の連続性、ステータスの整合性、添付ファイルの開封、個人情報のマスキングも確認します。

受入条件は「画面が表示される」では不十分です。代表手続を使った正常系・不備・差し戻し・代理申請・決済失敗・API通信断・権限違反・大量アクセスのテストを定義し、合格基準と証跡を決めます。テスト仕様書、結果報告書、操作マニュアル、運用設計書、設定一覧、脆弱性診断結果、移行結果を納品物に含め、検収の期限と不具合修正の扱いを契約に連動させます。

電子申請システムの契約形態と責任分界

電子申請システムの契約は、要件の確定度に合わせて工程ごとに設計します。成果物と受入条件を定義できる開発工程は請負契約、現状調査やPMO、技術支援のように作業内容が変わりやすい工程は準委任契約が候補になります。SaaS利用料、クラウド費用、保守、法改正対応、追加フォーム作成は、開発契約と別の継続費用として管理すると、5年間の支出を見通しやすくなります。

請負契約では、合意した成果物を完成させ、発注者が検査・受入する流れを明確にします。要件定義書、基本設計書、詳細設計書、画面・帳票定義、プログラムまたは設定、テスト結果、移行結果、マニュアルを成果物一覧にし、瑕疵が見つかった場合の修補、再検収、追加費用の条件を決めます。受入基準が曖昧なまま契約すると、動作はするものの例外処理や帳票、性能、ログが不足していたという問題が起きやすくなります。

準委任契約では、受託者が専門的な作業を行い、発注者が意思決定と成果確認を担います。現状分析、RFP支援、PMO、データクレンジング、運用設計、職員研修など、前提条件が変わりやすい作業に向いています。稼働時間だけで評価せず、課題管理表、会議体、レビュー記録、判断事項、次回までの作業を毎月確認し、何をもって支援が完了したかを残します。

電子申請システムでは、元請けのほかに、クラウド事業者、決済代行会社、認証サービス、データ移行会社、コールセンター、帳票・郵送会社が関わることがあります。再委託の範囲、事前承認、再委託先の安全管理、事故時の報告、監査への協力、個人情報の保存場所、アクセスできる担当者を契約書と個人情報取扱特記事項で確認します。再委託先が変わるときの通知と承認手続も定めておくと安心です。

契約終了時のデータ返却は、発注前に確認する重要な項目です。申請データ、添付ファイル、利用者情報、審査履歴、設定、帳票定義、ログをどの形式で返却できるか、返却費用はいくらか、返却後にバックアップをいつ消去するか、別ベンダーへの引継ぎに協力するかを明記します。データを返せても、独自形式や画像だけで再利用できない場合があるため、サンプルデータで実際に読み込めるかを確認します。

クラウドを採用する場合は、ISMAPまたはISMAP-LIUの登録状況だけで判断せず、対象サービスと構成を確認します。ISMAPは、政府が求めるセキュリティ要求を満たすクラウドサービスをあらかじめ評価・登録し、政府調達のセキュリティ水準を確保する制度です（出典: ISMAPポータル「ISMAP概要」、2026年確認）。登録の有無に加えて、暗号化、権限管理、脆弱性パッチ、ログ、バックアップ、データの保管場所、インシデント通知、監査証跡をRFPの回答様式でそろえます。

SLAには、稼働率、計画停止の通知期限、障害の重要度、一次回答時間、復旧目標、問い合わせ受付時間、制度改正への対応期限、月次報告、違反時の扱いを記載します。例えば、申請受付停止、個人情報の誤表示、決済失敗、基幹連携停止、通知書の誤交付は、同じ障害でも影響が異なります。重大度ごとに誰へ何分以内に連絡し、どの代替手段で受付を継続するかまで決めておくことが大切です。

電子申請システムの費用相場と5年TCO

電子申請システムの費用は、人口、年間申請件数、対象手続数、認証・電子署名、決済、添付容量、連携数、LGWAN構成、職員数、移行対象、保守範囲で大きく変わります。全国共通の公式価格表は少ないため、ここで示す金額は市場全体の統計ではなく、NotebookLMで整理した価格情報、2025年公開の行政向け近接SaaS料金、一般的な公共系Webシステムの工程感をもとにした発注前の目安です。予算要求や契約金額を決めるときは、同一要件で複数社から見積もりを取得します。

小規模なノーコード・SaaS導入で、対象手続が少なく標準フォーム中心なら、初期費用0万〜150万円、月額3万〜30万円、導入期間1〜2週間から2か月程度が一つの目安です。認証、決済、複数課の審査、既存システム連携まで含める標準SaaSでは、初期100万〜500万円、月額10万〜50万円、導入期間2〜6か月程度を見込みます。連携や移行が増えると、初期300万〜1,500万円、月額20万〜100万円、4〜9か月程度になる場合があります。

独自の審査・交付や複数システムとの連携をスクラッチで構築する場合は、3,000万円から1億円超、導入期間12〜24か月程度になることがあります。これらはあくまで概算レンジであり、特定の会社や案件の価格を保証するものではありません。見積書では、要件定義、設計、フォーム作成、認証、決済、API、LGWAN接続、データ移行、テスト、研修、保守、法改正対応、追加手続単価を分けて確認します。

電子申請システムのTCOは、初期構築費に、SaaS利用料、クラウド・通信費、決済手数料、認証費、保守、監視、問い合わせ対応、職員研修、追加フォーム作成、法改正対応、脆弱性診断、データ移行、契約終了時の返却費用を加えて算出します。例えば、初期120万円、月額18万円、5年間のTCO約1,200万円というSaaS型の目安がありますが、これは一つの価格例であり、申請件数や連携数によって変動します。

近接する行政向けサービスの公開料金として、デジタル庁の給付支援サービス利用説明資料（2025年12月）には、導入料金458,400円、人口規模に応じる基本料金1,000,000円以上、月額30,000円、金融機関連携556,800円という費用構造が示されています。これは電子申請システムそのものの相場ではありませんが、行政SaaSでは「初期設定＋規模別基本料＋月額＋オプション」という分かれ方があることを確認できます。電子申請の見積もりも同様に、無料に見える標準機能の外側を確認します。

費用を抑えるには、最初から全手続を個別開発しないことが有効です。申請件数が多く、不備や問い合わせが多い手続、住民が窓口へ行く負担が大きい手続、添付・決済・本人確認をオンラインで完結しやすい手続から代表例を選びます。小さなPoCで申請完了率と不備率を測り、効果が確認できた機能だけを横展開すると、使われない画面への投資を避けられます。

連携も、すべてをリアルタイムにする必要があるかを確認します。まずCSV連携や日次バッチで足りる業務、API連携が必要な業務、職員の確認を残す業務に分けると、開発費と障害リスクを抑えられます。ただし、個人番号を含む情報、決済結果、受付番号、審査状態など、誤りが住民の権利や金銭に影響するデータは、責任分界と再送・訂正手順を明確にしたうえで連携方式を決めます。

電子申請システムの委託先選定と見積比較のポイント

委託先は、知名度や初期価格だけでなく、行政手続の業務理解、本人確認・決済、職員向け審査、LGWANを含むネットワーク、既存システム連携、移行、稼働後の改善を一つの体制で確認します。比較候補を集める段階では、標準SaaS型、職員がフォームを作るノーコード型、本人確認や審査・基幹連携を重視するSI型に分けると、自組織に合う会社を見つけやすくなります。

実績確認では、「自治体に何件導入したか」だけでなく、自組織と似た人口規模、手続数、申請件数、認証方式、既存基幹システム、ネットワーク分離の案件を聞きます。稼働中の自治体で、申請者の不備率、審査時間、問い合わせ件数、オンライン完結率がどう変わったか、導入後にどのような改修をしたかまで確認します。導入担当者だけでなく、実際に審査する職員へのヒアリング機会を求めると、提案書では分からない運用負担を見極められます。

候補会社の例として、NTTデータ関西のe-TUMO APPLYは、電子署名、キャッシュレス決済、マイナポータル連携、受付・審査・文書交付などを掲げています。同社は行政総合サービスモールで829団体導入、最短3か月でのクラウド導入を案内していますが、これは同社が公開する実績・導入目安です（出典: 株式会社NTTデータ関西「行政総合サービスモール」、2026年確認）。トラストバンクのLoGoフォーム、グラファーのGrafferスマート申請、ポケットサインの電子申請、電通総研やプレイネクストラボの本人確認・窓口DX関連サービスも比較候補になります。ランキングではなく、対象業務と方式の適合性で評価します。

評価表には、業務適合性、住民向けUI、職員向け審査、本人確認・電子署名、決済、既存システム連携、セキュリティ、移行、運用体制、導入スケジュール、法改正対応、データ返却、費用の12項目を入れます。例えば、業務適合性25点、技術・セキュリティ20点、導入・移行15点、運用・保守15点、実績10点、提案の分かりやすさ5点、費用10点のように、価格を全体の一部にします。配点は組織の方針に合わせますが、安さだけで逆転しない設計が重要です。

提案評価では、画面デモと実データに近いシナリオを使います。「申請者がスマートフォンで本人確認し、添付を追加し、決済し、差し戻し後に再提出する」「職員が担当課へ振り分け、軽微な不備を訂正し、決裁して電子交付する」といった一連の流れを実演してもらいます。できない機能は、標準外、追加開発、運用回避、将来対応のどれかを示してもらい、提案価格と納期への影響を記録します。

見積比較では、合計金額を横に並べるだけでは不十分です。各社に同じ見積様式を渡し、要件定義、設計、設定・開発、フォーム作成、認証、決済、API連携、ネットワーク、移行、テスト、研修、運用開始支援、保守、法改正、追加手続、解約・データ返却の金額を分けてもらいます。初期費用、月額、年額、従量課金、ユーザー数課金、申請件数課金、決済手数料を同じ期間に換算します。

必ず確認するのが、見積書の前提条件と除外項目です。対象手続数、想定申請件数、添付容量、同時利用者数、既存システムのAPI有無、データ移行件数、職員の作業分担、現地作業、テスト環境、問い合わせ対応時間が、価格に含まれているかを確認します。特に「連携は別途」「カスタマイズは別途」「法改正は別途」という記載は、5年間のTCOを大きく左右します。別途費用の単価と見積もり条件まで提案書に書いてもらいます。

契約前には、最安値の会社へすぐ決めるのではなく、上位候補に同じ質問を返して再見積もりを取ります。価格差が大きい場合は、機能が不足しているのか、作業範囲が狭いのか、保守や移行が含まれていないのかを分解します。安い導入費用の代わりに追加フォームやデータ返却の単価が高いケースもあるため、5年総額と契約終了時の費用を見て判断します。

よくある質問

電子申請システムの発注では、SaaSとスクラッチの選択、認証、ネットワーク、費用、運用体制について同じ疑問が出やすくなります。ここでは、発注前に判断しやすいように、よくある質問へ直接回答します。

標準的な手続を早く増やし、法改正やセキュリティ更新の負担を抑えたいなら、SaaSやパッケージ型が第一候補です。独自の審査、交付、データ連携が業務上不可欠で、標準機能や設定では対応できない場合に、限定的な追加開発やスクラッチを検討します。実際の代表手続を使ったFit & Gapと5年TCOを比較して決めることが大切です。

必ずしもすべての手続で同じ認証を使う必要はありません。本人確認の強さ、電子署名の要否、代理申請の有無、個人向けか法人向けか、申請者が利用しやすいかを手続ごとに整理します。デジタル庁の2025年活動報告では、GビズIDは2025年3月末時点で累計発行アカウント124万件、接続サービス数217とされています（出典: デジタル庁「2025年デジタル庁活動報告」、2025年）。法人手続で利用者が多い場合は候補になりますが、認証連携費、アカウント管理、代理権限、認証失敗時の代替手段も見積もりに含めます。

標準フォーム中心の小規模SaaS導入なら1〜2週間から2か月、認証・決済・複数課の審査や連携を含む場合は2〜9か月、個別開発や大規模移行を含む場合は12〜24か月程度が目安です。NTTデータ関西は、クラウド型の行政総合サービスモールについて最短3か月での導入を案内していますが、実際の期間は対象手続、ネットワーク、データ移行、庁内の意思決定で変わります。RFPでは、要件確定、設計、設定・開発、テスト、研修、先行稼働、本番切替の工程を分けます。

フォーム作成を内製化できる場合でも、業務フローの整理、認証・決済、既存システム連携、LGWAN構成、個人情報保護、データ移行、アクセシビリティ、受入テスト、障害対応は外部支援が役立ちます。職員が手続の追加を担当し、専門会社が共通基盤とセキュリティ、連携、運用設計を担当する分担も可能です。誰が何を設定し、誰が障害時に判断し、誰が法改正を反映するのかを体制図とSLAで明確にします。

初期費用だけでなく、月額・年額、申請件数や利用者数に応じた従量費、認証・決済手数料、保守、法改正、追加フォーム、データ移行、研修、問い合わせ、解約時のデータ返却を5年間で合算します。各社に同じ要件と見積様式を渡し、標準機能、追加開発、別途費用、対象外を分けて回答してもらいます。最安値を選ぶのではなく、必要な業務が含まれた5年総額と、将来の変更しやすさを合わせて判断します。

まとめ

電子申請システムの発注・外注では、最初に会社や製品を決めず、対象手続の業務フローを分解します。申請者の入力、本人確認、添付、決済、受付、審査、差し戻し、決裁、通知、基幹システム連携、ログ、紙申請との併存を一覧化し、オンライン化した後に職員の仕事がどう変わるかを明確にします。

RFPには、機能要件だけでなく、現行業務、ネットワーク分離、認証・決済、API、移行、バックアップ、監査ログ、SLA、再委託、法改正、データ返却を記載します。請負と準委任を工程ごとに使い分け、成果物と受入条件を契約に落とし込みます。委託先の実績は導入社数だけでなく、類似する手続・利用者・連携・運用の事例で確認し、実際の申請から交付までをデモで評価します。

費用は、初期構築費だけでなく、利用料、連携、移行、保守、法改正、追加手続、問い合わせ、障害対応、データ返却を含む5年間の総額で比較します。導入後は、申請完了率、不備率、差し戻し件数、審査時間、問い合わせ件数、オンライン完結率を見ながら、フォームや案内を改善します。電子申請システムを「作って終わり」にせず、行政サービスと職員業務を継続的に良くする運用まで含めて発注することが、長期的な成果につながります。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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