自治体向け電子申請システム開発の進め方/やり方/流れや方法/手法/工程/手順

自治体向け電子申請システムの開発は、手続きと業務の整理、方式とベンダーの選定、設計から定着までの6段階で進めます。住民と職員の負担を減らすことが、この流れの目的です。

全体像、6フェーズの内容、費用と見積もりの確認事項の順に説明します。全体像は、下の完全ガイドもご覧ください。

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

自治体向け電子申請システムの全体像

電子申請システムを中心に、住民向け機能、職員向け機能、本人確認、LGWAN接続を示す図解。
住民の申請と職員の受付後の処理を、同じ仕組みの中で支えます。

自治体向け電子申請システムは、住民や事業者がスマートフォンなどから申請、届出、予約を行う仕組みです。

職員は、受付から集計までを、審査や差し戻し、承認も含めてオンラインで処理します。

開発では、住民向けの申請画面と職員向けの審査画面を設計し、認証や決済、電子交付などを組み込みます。

LGWAN接続や既存システム連携も、同じ仕組みの中で設計します。

業務基盤としての位置づけ

申請データが共有フォルダーに届いても、印刷や転記、担当の振り分けが残るため、庁内の負担は減りません。

自治体と開発会社は、入力から保管までの各状態を定義し、審査、承認、基幹登録など、どの段階から自動化するかを決めます。

効果は、オンライン化率だけでなく、手続きごとの来庁数、転記時間、処理日数で測ります。さらに、差し戻し率、オンライン完結率、問い合わせ件数も追えば、予算要求や拡張計画と結び付けて示せます。

ぴったりサービス・SaaS・個別開発の使い分け

方式は、本人確認の厳格さと基幹登録の要件を基準に選びます。手続きの内容や独自審査ルールも、方式を選ぶ際の判断材料になります。

  • ぴったりサービス:国の手続きやAPI連携を生かせる場合の候補
  • SaaS・ASP:短期導入を優先する場合の比較対象
  • 標準パッケージ:連携開発の範囲が問われる方式
  • スクラッチ開発:独自要件との適合が問われる方式

デジタル庁が2026年6月に公開した電子申請等APIは、自治体サイトやアプリからぴったりサービスの検索・申請機能を呼び出す選択肢です。

また、APIでは認証や手続き検索、申請データの送信などを扱えます。ただし、ぴったりサービスの電子申請等APIを新規に使う場合、利用申請から開始までは約半年から1年が参考期間です(出典:デジタル庁「電子申請等API」、2026年6月公開・7月更新)。

住民と職員の両方に使いやすい機能

住民と職員それぞれの利用場面に合わせて、機能と配慮を用意します。

  • 住民向け機能:検索、スマートフォン対応、入力補助、条件分岐、添付、状況照会、受付・補正依頼の通知、電子文書の受け取り。
  • 利用しやすさ:やさしい日本語、文字サイズ、キーボード操作、分かりやすいエラー表示。
  • 職員向け機能:LGWAN受付確認、振り分け、審査・承認、差し戻し、期限管理、帳票、CSV・API連携、権限、ログ、バックアップ。
  • 本人確認:申請のリスクに応じた、メール認証、属性確認、公的個人認証、電子署名の使い分け。

高齢者や障害のある方、外国人などが使えるように設計します。

すべての手続きで、マイナンバーカードを必須にする必要はありません。

自治体向け電子申請システムの進め方|6フェーズの流れ

対象手続きと業務フロー、方式とベンダー、住民画面と庁内処理、例外処理と繁忙期を4枚のパネルで整理した図解。
前提整理、方式選定、設計、検証の論点が順につながります。

まず対象手続きと業務フローを整理し、そのあとに方式を比べる順で進めます。各段階の完了条件を文書にして庁内で確認すると、追加費用や、どこまでを誰が受け持つかの曖昧さを抑えられます。

フェーズ1:要件整理|対象手続きとTo-Be業務の決定

まず全庁の手続きを一覧にし、件数や繁忙期、来庁の負担を洗い出します。その際は、添付や本人確認の要否、審査担当、基幹登録の有無なども書き出します。

デジタル庁は、利便性と業務効率の効果が高い手続きを整理したうえで、56手続を優先的にオンライン化する考え方を示しています(出典:デジタル庁「行政手続のオンライン化」、2026年6月更新)。

  • 優先順位:国の対象に加えて、自治体の処理件数と職員の作業時間で判断
  • 申請項目:紙様式をそのまま画面にせず、入力項目、確認情報、省略できる添付を分けた設計
  • 受付後の業務:審査担当、差し戻し条件、再申請、通知、保存年限、基幹登録者の決定
  • 完了確認:対象一覧、現行・To-Beフロー、利用者区分、本人確認、連携先、KPI、初回範囲の7点について、自治体側の承認
  • 試行:1〜3手続きで試したうえでの拡張

自治体は、各社から同じ前提で見積もりを取れるよう、要件を具体化します。

フェーズ2:選定|方式とベンダーの比較

各方式は、初期費用だけでなく5年間の総保有コストで比べます。

  • SaaS:導入が早く、制度改正や脆弱性対応を任せやすい一方、独自審査やデータ構造に制約が出ることがあります。
  • スクラッチ:業務に合わせやすい一方、更新費や担当者交代、ベンダーロックイン、終了時の移行負担を見ておく必要があります。
  • RFP・デモ:要件の仕様書への明記と、例外処理のデモでの確認
  • 導入実績:自治体や同規模の案件での実績、同じ基幹製品との連携経験、制度改正への対応方法、職員が追加できるフォームの範囲
  • 運用:問い合わせ窓口と出力形式。追加のたびに開発依頼が必要だと、全庁展開の費用が膨らみます。

仕様書には、接続方式、基幹連携、認証を明記します。決済や電子交付、アクセシビリティ、ログ、バックアップも、同じ仕様書に含めます。細かな項目は、後段の「RFP・仕様書に必ず書く項目」にそろえて整理します。

契約では、障害時の連絡時間や再委託、データ返却・削除の方法も定めます。さらに、例外処理をデモで確かめます。

フェーズ3:設計・開発|住民画面と庁内処理の一体設計

住民画面と庁内処理を分けて整理したうえで、必要なデータだけを連携する構成を検討します。

  • システム構成:住民・職員画面、連携サーバ、ログ・権限管理、通知、決済、電子交付の整理
  • ネットワーク:インターネット、LGWAN、個人番号利用事務系・基幹領域の分離と、API等で必要なデータだけの受け渡し
  • フォーム:条件分岐で不要項目を隠す設計、住所・氏名の重複入力の削減、添付の容量・形式とウイルスチェック、受付番号と控えの保存方法
  • 電子署名:必要な手続きでの署名対象、検証、失敗時の再申請の設計
  • 契約・受入:標準機能・設定・個別開発の区別、画面から改善までの成果物と受入条件、変更要求の扱いの合意

作業項目を一括にすると見積もりを比べにくいため、機能ごとに区分してもらいます。

フェーズ4:テスト|例外処理と繁忙期の検証

正常系だけでなく、例外処理と繁忙期を想定したシナリオを用意します。

検証は、住民役や窓口担当など、役割ごとに行います。

  • 申請例外:入力エラー、添付漏れ、本人確認・決済失敗、差し戻し後の再提出、担当課変更、期限超過。
  • 連携・通知:通知不達、基幹連携の重複送信、同時申請の検証
  • 非機能:繁忙期の同時アクセス、データ量、復旧、切り戻し、ログ検索、権限変更、脆弱性診断の確認
  • 利用者評価:高齢者や障害のある方の操作性、スマートフォンでの文字切れ、やさしい日本語の評価
  • 合格・変更条件:重大障害ゼロ、未解決課題、連携照合、マニュアル、連絡網、判定者の明記と、仕様変更の費用区分の契約時の決定

自治体は、利用者に近い人にも評価に加わってもらい、役割ごとの操作シナリオで受け入れの可否を確かめます。

フェーズ5:稼働|窓口とオンラインの混乱防止

稼働前に周知と窓口の運用を準備し、オンラインと紙の二重入力を防ぎます。

  • 事前周知:対象、開始日、受付・メンテナンス時間、問い合わせ先、紙との併用期間の案内
  • 窓口対応:紙受付の登録方法と、オンライン申請支援窓口の役割の決定
  • 初日運用:開発会社、情報政策、業務課、ヘルプデスクの連絡の一本化と、停止時の優先順位の決定
  • 停止追跡:受付番号とログの見方の共有と、本人確認、決済、電子交付、基幹登録の停止箇所の特定
  • 稼働後の改善:稼働後1か月の、主要指標の毎週の確認

稼働後は、未完了率や差し戻し理由、問い合わせなどを確認します。利用が少ない場合も、すぐに失敗と決めつけず、まずはページの見つけやすさや広報を見直します。入力項目と本人確認の負担も点検します。

大きな制度改正や給付の前には、実データに近い件数でリハーサルします。

フェーズ6:定着|自治体内に残すフォーム追加と改善

フォーム追加や改善を自治体内に残し、制度改正や繁忙期にも対応できる体制を作ります。

  • 権限設計:職員が行う追加・修正の範囲の決定と、作成、承認、公開、停止の分離
  • 月次確認:手続き別申請数、完了率、差し戻し率、平均処理日数、問い合わせ、窓口削減時間、障害件数。
  • 四半期改善:未利用、添付過多、特定端末で離脱が多いフォームの調査と、入力項目や審査ルールの見直し
  • 契約更新:制度改正、サポート時間、価格改定、API変更、ログ、バックアップ、データ返却、他社移行条件の確認
  • 将来移行:5年後を想定したデータ形式、項目定義、添付、申請履歴を、自治体が使える状態で保つこと

すべてを開発会社に任せると、フォームが古くなります。一方で、権限を広げすぎると設定誤りにつながるため、役割を分けることが必要です。

ポイント

判断に迷ったら、対象手続きの一覧と業務フローに自治体側の承認があるかを先に確かめます。承認がないまま方式を比べると、各社の見積もりの前提がそろいません。

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

小規模SaaS、標準導入、大規模連携、スクラッチの4段階を初期費用のレンジとともに示す図解。
大規模連携やスクラッチでは、初期費用の上限も大きくなります。

費用は、人口や手続き数で変わるうえ、認証、決済・電子交付、基幹連携、移行・研修の範囲によっても変わります。そこで、方式別のレンジと、見積もりに含まれる作業を分けて確認します。

方式別の初期費用・年間費用・期間の目安

導入方式と規模ごとの目安は、次のように分かれます。

  • 小規模SaaS:小規模自治体でフォームを絞り、基幹連携なしの場合。初期0〜300万円、年間100〜500万円、1〜3か月。
  • 標準導入:複数課で決済、電子交付、研修を含む場合。初期300〜1,500万円、年間300〜1,500万円、3〜6か月。
  • 大規模連携:大規模自治体でSSO、API、複数基幹連携を含む場合。初期1,000万〜1億円、年間1,000万〜3,000万円、6〜12か月。
  • スクラッチ:独自審査、複数基幹、移行、高可用性まで含むケースもあります。初期5,000万〜3億円以上、期間9〜24か月。

各レンジは案件条件に基づく目安です。特定の自治体の契約額を、そのまま予算の目安とみなすものではありません。

公開されている契約例を見ると、伊東市の2024年度「汎用電子申請システムサービス使用契約」は年107万8,440円です(出典:伊東市「令和6年度分随意契約調査表」、2025年公開)。

熊本市の2025年度「くらしの手続きガイドクラウドサービス利用料」は171万6,000円です(出典:熊本市「令和7年5月契約状況」、2025年公開)。

熊本市のLoGoフォームでは、電子文書交付追加と汎用メール追加が各1,000通/月あたり11,000円です(出典:熊本市「令和7年5月契約状況」、2025年公開)。

オンライン決済の指定納付受託業務は、納付額の3.5%です(出典:熊本市「令和7年5月契約状況」、2025年公開)。

名古屋市の2026年度「電子申請システムのサービス提供及びシングルサインオン開発業務委託」は1億296万円でした。ただし、大都市向けサービスとSSO開発を含み、年額SaaS利用料とは異なります(出典:名古屋市「落札者等の公示」、2026年5月)。

公開額は、利用料や構築費、従量課金など、何が含まれるかを分けて比べます。

見積書で分けて確認する5つのコスト

見積もりでは、初期・導入、継続費用などの主な構成を分けて確認します。

  • 要件整理:要件整理・調達支援を含む費用。
  • 初期設定・フォーム作成:初期設定とフォーム作成の費用。
  • 個別開発・API連携:個別開発とAPI連携の費用。
  • 導入作業:テスト、移行、研修の費用。
  • 利用・運用費:月額または年額の利用料と、保守・改善の費用。

決済や電子交付、本人確認の従量課金は、繁忙期の利用量で試算します。SMS・メールやストレージの従量課金も、同じ利用量の想定で見込みます。電子署名とアクセス超過の従量課金は、繁忙期の利用量を基に見込んでおきます。

保守費は、初期開発費の5〜15%程度とする一般的な目安があります。ただし、実額は、制度改正や脆弱性対応、監査、24時間障害対応などの範囲で変わります。

問い合わせや改修の対応時間、休日・夜間の障害連絡を確認します。そのうえで、保守は安さだけで選ばないようにします。

予算は、初年度と2年目以降、5年間の総額に分けて捉えます。初年度は構築や移行、研修が集中します。一方で、その後は利用料や保守、制度改正などが続きます。

契約終了時のデータ抽出や移行支援が別料金になる場合もあります。そのため、更新しない場合の費用も見積もりに含めます。

ポイント

方式と規模で費用は大きく変わるため、同じ金額でも何が含まれるかを確かめてから比べます。初年度の構築費だけで判断せず、5年間の総額で見ることが大切です。

見積もりを取る際のポイントとチェックリスト

見積もりの精度は、業務と前提条件の明確さで決まります。機能名だけを示すと、各社の前提が異なり、価格差の理由が分からなくなります。

対象手続きや想定件数、ピーク時の同時利用を、同じ様式で各社に示します。さらに、連携先や保存年限、職員数などの項目も含めます。

RFP・仕様書に必ず書く項目

仕様書には、機能、データ連携、セキュリティの要件を具体的に記します。

  • 機能・業務:対象手続き・利用者、業務フロー、画面・帳票、認証、電子署名、添付、決済、電子交付、通知、検索、権限、ログ、バックアップ、連携、移行、研修、保守
  • 連携仕様:連携項目・形式・頻度、エラー時の再送、重複防止、どこまでを誰が受け持つか
  • 安全管理:通信・保存時の暗号化、アクセス制御、管理者権限、脆弱性診断、ログ保存期間、事故報告、再委託先、データセンター所在地、バックアップと復旧目標

個人情報保護委員会の「個人情報の保護に関する法律についてのガイドライン(行政機関等編)」(出典:個人情報保護委員会)を踏まえます。

個人情報を扱う委託先の監督、監査、事故報告は、契約に定めておきます。

複数社の同条件での比較

相見積もりでは、費用項目を同じ列に並べ、各社に対応区分を示してもらいます。

  • 費用:初期、年間利用、保守、従量課金、オプション。
  • 導入範囲:連携開発、移行、研修、契約終了時の費用。
  • 対応区分:「標準機能」「設定」「個別開発」「対象外」。

同じ条件で比べると、最も安く見える提案が、必要な作業を別料金にしていないかを判断できます。

評価の観点には、自治体の実績、基幹連携、LGWANを含めます。さらに、APIや制度改正への対応、内製運用も見ます。アクセシビリティや障害対応、データ返却も、評価の対象に入れます。ベンダーの継続性も、同じ観点で確かめます。

実際の手続きシナリオでデモを依頼し、申請者や受付、審査など、役割ごとの操作を確認します。

失敗しやすいリスクと事前対策

主な失敗要因と、契約前に確認したい対策を整理します。

  • 業務設計不足:紙様式のフォーム化による項目過多、審査・基幹登録の未設計、紙との二重運用、制度改正費用の不明確さ。
  • 業務フロー確認:手続きごとの現行・To-Beフローの作成と、処理時間や作業者の比較による対策
  • データ返却:申請データや添付、履歴などを、どの形式で、何営業日以内に、どの費用で返すかの契約前の確認
  • 契約条件:再委託先、障害時の責任、個人情報の削除証明、価格改定の通知期間の確認

ポイント

見積もりを比べる前に、各社へ渡す前提が同じかを確かめます。前提がそろっていれば、価格差が機能の違いによるのか、別料金の作業によるのかを見分けられます。

よくある質問(FAQ)

導入前に自治体の担当者から寄せられる質問に答えます。費用や期間は案件の条件で変わるため、公開契約例と一般的なレンジは分けて考えます。

自治体向け電子申請システムの導入費用はいくらですか?

基幹連携なしでフォーム数が少ないSaaSは、初期0〜300万円、年100〜500万円程度が目安です。

複数課での利用や決済、電子交付などを含む標準導入は、初期300〜1,500万円程度です。さらに、大規模なSSOやAPI、基幹連携を含む場合は、初期1,000万〜1億円程度の幅があります。

発注側は、範囲と従量課金をそろえて比べ、自治体の条件で見積もりを取り寄せます。

開発から稼働までどのくらいかかりますか?

対象手続きが少ないSaaSでは、1〜3か月が目安です。複数課の設定や決済などを含む場合は、3〜6か月が目安です。

基幹連携や独自審査を含むと6〜12か月以上、スクラッチ開発では9〜24か月になる場合があります。

ぴったりサービスの電子申請等APIを新規利用する場合は、利用申請から開始まで約半年〜1年が参考期間です。

ぴったりサービスと独自の電子申請フォームはどう使い分けますか?

国の標準手続きやカードによる本人確認を重視する場合は、ぴったりサービスを優先して検討します。

独自予約や施設利用、細かな審査などを重視する場合は、SaaSや独自フォームが適することがあります。

手続きごとに認証の水準や入力のしやすさ、職員の処理などを比べ、方式を一つに統一しない方法も現実的です。

住民の個人情報を安全に扱うには何を確認しますか?

暗号化、本人確認、権限分離などを確認します。さらに、監査ログや脆弱性診断、バックアップも見ておきます。

ネットワークは、インターネット、LGWAN接続系、個人番号利用事務系・基幹系を分離し、連携データを必要最小限にします。

責任の分け方と監査の方法は、仕様書や契約書に記載し、導入後も定期的に点検します。

ポイント

費用と期間は、自治体の規模と基幹連携の範囲で大きく変わります。まず規模と連携の範囲を決めてから、一般的な目安を当てはめるようにします。

まとめ|自治体向け電子申請システムを業務全体から進める考え方

成功させるには、機能の比較より先に、対象手続きと減らしたい負担を決めます。そのうえで、6段階を順に進め、各段階の完了条件を確かめます。

6フェーズごとの完了条件の管理

費用は、年額SaaSからSSO・基幹連携を含む大型開発まで幅があります。そのため、初期費用や利用料、個別開発を分けて見ます。従量課金や保守、移行、研修、終了時費用も別の項目として分け、5年間の総額で比べます。

住民の使いやすさと職員の業務削減を、どちらも評価します。少数の手続きで成果を測ってから全庁へ広げると、無理のない進め方になります。

5年間の費用と定着までの比較

運用計画は、稼働をゴールにせず、稼働後の先まで見通して作ります。フォーム追加や制度改正、人事異動、監査、障害、データ返却まで含めます。

導入後は、オンライン完結率や処理時間、差し戻し率などを定期的に確認します。さらに、住民と職員の双方に使いやすい手続きへ改善します。

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

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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