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

自治体向け電子申請システムの発注は、フォームを作るだけでなく、住民の申請から職員の審査、基幹システムへの登録、通知・交付までを一つの業務として再設計し、必要な範囲をSaaS利用・パッケージ導入・個別開発から選ぶことが重要です。

発注形態の選び方、RFPに入れる要件、請負と準委任の使い分け、費用相場、委託先の比較方法までを順に整理します。公開契約例や2026年時点の制度・APIの動向も踏まえ、調達担当者と情報政策担当者が、見積書の金額だけでなく導入後の運用まで比較できるように解説します。

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

自治体向け電子申請システムは何を発注するものですか？

自治体向け電子申請システムで発注する対象は、住民が使う申請画面だけではありません。受付後の審査、差し戻し、承認、手数料決済、電子文書交付、帳票出力、基幹システム連携、操作ログ、保守運用までを含む業務基盤として考える必要があります。

住民側には、手続き検索、スマートフォン対応フォーム、入力補助、条件分岐、添付ファイル、申請状況の照会、受付・差し戻し通知などが必要です。手続きの性質によっては、メール認証、マイナンバーカードを使った公的個人認証、電子署名、代理申請も検討します。職員側には、LGWANからの受付確認、担当課への振り分け、審査・承認、差し戻し、期限管理、権限設定、監査ログ、CSVまたはAPIによる連携が必要です。

電子化の成否は、申請データを受け取った後に職員が何回転記するかで大きく変わります。発注前に「申請受付→本人確認→審査→差し戻し→基幹登録→通知・交付→保管」の流れを可視化し、どの工程を自動化するか決めます。デジタル庁も、住民と行政職員双方の負担軽減を目的に、手続きのオンライン化と業務効率化を進めています（出典：デジタル庁「行政手続のオンライン化」、2026年6月更新）。

発注形態はSaaS・パッケージ・個別開発から選びます

発注形態は、自治体固有の業務がどれだけあるか、既存システムとどこまで連携するか、導入を急ぐかによって決まります。機能の多さだけでなく、制度改正への追随、職員がフォームを追加できるか、契約終了時にデータを返却できるかまで比較することが大切です。

SaaS・ASPは、提供会社がクラウド基盤、機能更新、脆弱性対応を担うため、自治体がサーバーを個別に構築する負担を抑えやすい方式です。申請フォームや予約、アンケート、集計などの標準機能を使い、複数課へ短期間で展開したい場合に適しています。一方で、独自の審査順序や複雑な基幹連携が標準機能に収まらない場合は、追加開発費や外部連携の可否を確認します。

パッケージを導入し、自治体固有の審査や基幹システム連携だけを追加する方式は、標準機能を活用しながら差別化要件にも対応できます。マイナポータルのぴったりサービスや自治体公式サイト、住民ポータル、LINEなどを組み合わせる場合は、データの受け渡し方式、認証の責任分界、障害時の連絡経路を先に整理します。2026年6月に公開された電子申請等APIにより、自治体のWebサイトやアプリからぴったりサービスの検索・申請機能を連携する選択肢も明確になっています（出典：デジタル庁開発者サイト「電子申請等API」、2026年7月更新）。

スクラッチ開発は、独自の審査、複数の基幹システム、特殊な帳票、厳格な可用性などを自由に設計できる反面、初期費用と開発期間が大きくなりやすい方式です。制度改正やOS・ブラウザ更新、脆弱性対応、担当者交代時の引き継ぎまで自治体側の運用責任が重くなるため、「既製サービスでは対応できない要件」を明確にしてから選びます。独自画面を作ること自体を目的にせず、業務改善効果と5年間の総保有コストで判断します。

発注から導入までの進め方を5段階で整理します

いきなり製品名や開発会社を決めると、導入後に紙との二重運用や追加費用が発生しやすくなります。最初に対象手続きと業務フローを整理し、次に方式と要件を定め、RFPで提案を募り、契約後は段階的に検証する流れが安全です。

手続きごとに、年間件数、繁忙期、来庁の必要性、入力項目、添付書類、本人確認、手数料、審査担当、処理日数、基幹登録の有無を一覧にします。件数が多く、住民の来庁負担と職員の転記負担が大きい手続きから始めると、導入効果を測りやすいです。デジタル庁が示すオンライン化対象の手続きだけでなく、自治体独自の粗大ごみ受付、施設予約、給付申請なども候補に含めます。

業務フローの現状と目標を並べ、オンラインで完結させる範囲、職員が確認する範囲、紙を残す例外を定めます。そのうえで、機能要件、連携要件、非機能要件、導入支援、研修、保守、費用の提示方法をRFPに記載します。提案依頼前に複数社へヒアリングを行う場合も、特定製品の機能に引っ張られすぎず、自治体が達成したい業務成果を軸に質問します。

契約後は、まず1〜3手続きでフォーム、審査、通知、権限、ログ、連携を検証します。住民向けの操作テストだけでなく、職員が差し戻しや代理申請を処理できるか、繁忙期の大量申請に耐えられるか、障害時に紙へ切り替えられるかも確認します。オンライン完結率、処理時間、差し戻し率、問い合わせ件数を計測し、改善してから対象課と手続きを広げます。

RFPと要件整理で発注前に決めるべきこと

RFPは、開発会社へ希望を伝える文書であると同時に、提案内容と見積を同じ条件で比較するための基準です。「使いやすいシステム」のような抽象表現だけではなく、誰が、どの画面で、何分以内に、どのデータを処理するかまで具体化します。

手続き検索、入力補助、条件分岐、添付、本人確認、電子署名、代理申請、受付通知、審査、差し戻し、承認、決済、電子交付、帳票、検索、集計、権限、監査ログを機能一覧にします。各機能には「必須」「できれば」「対象外」を付け、標準機能か追加開発か、職員が設定変更できるかを提案書で回答してもらいます。特に差し戻し後の再提出、申請の取り下げ、二重申請、添付ファイルの不足など、例外処理を忘れないことが重要です。

可用性、バックアップ、復旧目標、同時接続数、応答時間、暗号化、アクセス制御、脆弱性診断、負荷試験、監査ログの保存期間、障害連絡、保守時間帯をRFPに入れます。インターネット側、LGWAN接続系、個人番号利用事務系・基幹システムを分離する構成では、連携サーバーやAPIゲートウェイの責任分界も明記します。個人情報を扱うため、委託先・再委託先への監督、監査、事故報告、データ返却・削除を契約条件に含めます（出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（行政機関等編）」）。

導入後に自治体職員がフォームを追加・変更できるか、制度改正時に誰が修正するか、問い合わせの一次窓口は誰かを確認します。職員異動を考慮した研修資料、操作マニュアル、管理者権限の引き継ぎも成果物に含めます。さらに、契約終了時のデータ形式、エクスポート費用、移行支援、バックアップの削除証明まで提示してもらうと、ベンダーロックインのリスクを抑えやすいです。

契約形態は請負・準委任・利用契約を組み合わせます

契約形態は、仕様が固まっている部分と、導入しながら改善する部分を分けて考えます。SaaSの利用契約、初期設定や連携開発の請負、業務整理や伴走支援の準委任を組み合わせると、責任範囲と変更のしやすさを整理できます。具体的な契約方式は、自治体の調達規程や法務担当の確認を受けて決めます。

請負契約では、何をいつまでに納品し、どの基準で検収するかを具体化します。画面一覧、連携仕様、テスト結果、操作マニュアル、研修、移行データ、セキュリティ診断報告書などを成果物として定義し、仕様変更の手続きと追加費用の算定方法も定めます。完成の判断が曖昧なまま契約すると、検収時に認識の違いが表面化しやすいです。

準委任は、業務分析、要件整理、プロジェクト管理、運用改善など、作業の遂行を委託する場面に向きます。制度や現場の要望を確認しながら進める段階では、月次の作業範囲、体制、報告内容、意思決定者を定めると管理しやすいです。開発成果物の完成責任まで曖昧にしないよう、要件定義・設計・開発・保守のどこを請負とし、どこを準委任とするかを分けて記載します。

SaaS利用料や保守費は、月額・年額の固定料金だけでなく、フォーム数、申請件数、保存容量、メール通数、決済額、追加ユーザー数で変わる場合があります。契約更新時の価格改定、最低利用期間、解約予告、障害時のサービスレベル、データ保存期間を確認します。初年度だけ安い提案ではなく、導入、拡張、制度改正、移行、終了までを含む5年間の支出で比較することが大切です。

自治体向け電子申請システムの費用相場と内訳

自治体向け電子申請システムの費用は、人口、手続き数、本人確認の強さ、既存システム連携、決済・電子交付、契約年数で大きく変わります。公開料金が少ないため、以下はリサーチノートに整理した一般的な業務システム相場と、2025〜2026年の自治体公開契約例を組み合わせた目安です。個別案件の確定金額ではなく、見積の桁と内訳を確認するためのレンジとして利用します。

小規模自治体がフォーム数を絞り、基幹連携なしでSaaSを導入する場合は、初期費用0〜300万円、年間の利用・運用費100〜500万円程度が一つの目安です。複数課への標準導入に決済、電子交付、研修を加える場合は、初期300万〜1,500万円、年間300万〜1,500万円程度を見込みます。SSO、API、複数基幹との連携を含む大規模案件では、初期1,000万〜1億円、年間1,000万〜3,000万円程度まで広がります。独自審査や高可用性を含むスクラッチ開発は、5,000万〜3億円以上、期間9〜24か月となるケースもありますが、要件により変動します。

自治体の公開資料では、伊東市の2024年度随意契約調査表に汎用電子申請システムサービス使用契約1,078,440円の例があります。熊本市の2025年度契約状況では、Grafferの「くらしの手続きガイド」クラウド利用料が1,716,000円と示されています。一方、名古屋市の2026年度の電子申請システムサービス提供・シングルサインオン開発業務は102,960,000円で、単純なフォーム利用料ではなく、大都市向けのサービス提供と開発を含む案件です（出典：各自治体の公開契約資料、2025〜2026年）。

初期設定や開発費のほか、データ移行、帳票調整、LGWAN接続、SSO、API連携、決済手数料、電子文書交付、メール従量課金、アクセシビリティ対応、脆弱性診断、負荷試験、職員研修、マニュアル作成、ヘルプデスク、制度改正対応を確認します。保守費は初期開発費の5〜15％程度が一般的な目安として挙げられますが、SaaSの利用料とは性質が異なります。見積書では、固定費、従量費、初年度だけの費用、毎年発生する費用、オプション費を分けてもらいます。

委託先選定と見積比較で確認するポイント

委託先は、知名度や機能数だけでなく、自治体の業務を理解して要件へ落とし込めるかで選びます。提案書、見積書、デモ、導入実績、担当者との質疑を同じ評価表で比較し、価格が安い理由と高い理由を確認します。RFPへの回答が抽象的な会社は、契約後に追加費用や役割分担の問題が生じる可能性があります。

導入自治体数が多くても、フォーム提供だけなのか、審査・決済・電子交付・基幹連携まで支援したのかで意味が変わります。人口規模、手続き数、LGWAN環境、マイナポータル連携、既存基幹の製品、導入期間が近い事例を紹介してもらいます。導入後に職員が自走できるよう、フォーム作成支援、研修、制度改正時の相談、障害対応の体制も確認します。

比較表には、要件定義、画面・フォーム、ワークフロー、認証、添付、通知、決済、電子交付、連携、移行、テスト、研修、保守を行ごとに並べます。各社の金額が「一式」になっている場合は、作業時間、担当人数、単価、前提条件、含まれない作業を質問します。追加開発の単価、仕様変更の承認方法、納期遅延時の扱い、再委託の範囲まで比べると、見積の安さだけで判断しにくくなります。

デモでは、住民がスマートフォンで手続きを検索し、入力し、添付し、送信するまでを試します。高齢者、障害者、外国人、代理申請者も想定し、文字サイズ、入力エラーの伝わり方、やさしい日本語、キーボード操作、問い合わせ導線を確認します。職員側では、繁忙期の受付、差し戻し、担当課変更、権限異動、監査ログの検索を試し、現場職員が毎日使えるかを評価します。

よくある質問（FAQ）

最後に、自治体向け電子申請システムを発注する際に多い疑問へ回答します。費用や方式に唯一の正解はないため、対象手続き、本人確認、連携範囲、導入後の運用を前提に判断します。

標準的な申請を早く広げたい場合はSaaS、独自審査や複数基幹との深い連携が不可欠な場合はパッケージ＋連携開発またはスクラッチが候補です。まず標準機能で実現できる範囲と、追加開発が必要な範囲を分け、5年間の費用と制度改正への対応力を比較します。

対象手続き、利用者、業務フロー、必須機能、連携先、セキュリティ、性能、運用体制、成果物、費用の提示方法まで書きます。製品の画面仕様を決めつけるのではなく、達成したい業務成果と制約条件を示し、標準機能・設定・追加開発の別を提案者に回答してもらう形式が比較しやすいです。

最初から全庁の全手続きを個別開発せず、件数と効果の大きい手続きでパイロットを行い、標準機能を活用することが有効です。決済や電子交付、基幹連携も同時に導入するのではなく、業務効果とリスクを見ながら段階化します。ただし、セキュリティ、バックアップ、監査ログ、アクセシビリティなど将来の手戻りが大きい要件を削りすぎないことが重要です。

申請データは、監査、問い合わせ、再申請、保存年限への対応に必要になるためです。契約終了時にCSVや添付ファイルをどの形式で返却するか、費用はいくらか、移行期間中に閲覧できるか、提供会社側のバックアップをいつ削除するかを契約書へ記載します。データ所有権だけでなく、メタデータや操作ログの扱いまで確認します。

まとめ

自治体向け電子申請システムの発注では、製品や開発会社を先に決めるのではなく、対象手続きと業務フローを整理し、住民側の申請から職員側の審査・登録・通知までを発注範囲に含めます。SaaS・ASP、パッケージ、スクラッチの特徴を比べ、標準機能と追加開発を切り分けることが、費用と納期の見通しを立てる第一歩です。

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を創業。