防災情報システム開発の発注/外注/依頼/委託方法について

防災情報システムの発注・外注は、機能一覧と価格だけで決めず、災害時に誰が何を何分以内に行うかを整理してから、標準機能・連携・運用支援を一体で比較することが成功の近道です。

本記事では、自治体や防災関係機関の担当者に向けて、防災情報システムを依頼・委託する方法を解説します。発注形態の選び方、RFI・RFPと要件整理、請負・準委任などの契約形態、2026年時点の費用相場、委託先の選定、見積比較、導入後の訓練まで、発注前に確認したい実務を順番に整理します。

▼全体ガイドの記事
・防災情報システム開発の完全ガイド

防災情報システムを発注・外注する前に知っておきたい全体像

防災情報システムは、災害情報を集めて表示するだけのポータルではありません。現場や住民からの情報収集、災害対策本部での判断、避難所や被災者の状況管理、住民・関係機関への情報発信、復旧・復興の記録までをつなぐ業務基盤です。発注では、画面の見た目よりも情報の流れと責任分担を先に定義する必要があります。

主な対象業務は、災害情報の収集、GISによる地図表示、災害対策本部のクロノロジーや指示管理、避難所の開設・混雑・物資管理、被災者台帳や罹災証明、メール・Web・SNSなどへの一斉発信です。気象庁防災情報XML、河川情報、Lアラート、防災行政無線、既存の庁内システムなどとの連携も含まれます。個人情報を扱う被災者支援領域と、住民向けの公開情報領域を同じ権限で運用しない設計も重要です。

発注書に「防災情報を一元管理するシステム」とだけ書くと、各社が異なる範囲を想定して比較できなくなります。地震、洪水、土砂災害、高潮など地域の優先シナリオを一つ選び、「情報を受け取る人」「判断する人」「承認する人」「発信する人」「記録を確認する人」を具体化すると、必要な機能と不要な機能を切り分けやすくなります。

住民向けの避難情報や通行規制は広く届ける必要がありますが、要配慮者情報、被災者台帳、職員の連絡先、未確認の被害報告は厳格に管理する必要があります。そのため、公開ポータル、職員・関係機関向け画面、個人情報を扱う業務画面を、認証・権限・ネットワーク・データ分類の面で分離します。発注時には、誰がどの情報を閲覧・登録・承認・出力できるかを権限表として添付します。

内閣府のSOBO-WEBは2024年4月に運用を開始し、2026年時点で各省庁や地方自治体など約1,900機関が利用しています。EEIに基づく情報を地理空間情報として共有し、災害対応機関が被害状況を俯瞰する仕組みです（出典: 内閣府「新総合防災情報システム（SOBO-WEB）について」、2026年確認）。自組織のシステムをSOBO-WEBやEEIとどう接続するかは、今後のRFPにおける重要な確認事項です。

防災情報システムの発注形態はどれを選ぶべきですか？

発注形態は、標準機能を使うSaaS・パッケージ、クラウド上の個別構築、スクラッチ開発、複数サービスを組み合わせるハイブリッドに分けて考えると整理しやすくなります。自治体固有の業務をすべて作り込む前に、災害時の中核業務と周辺業務を分け、標準化できる範囲を見極めます。

短期間で導入したい、標準的な情報収集・地図表示・一斉発信から始めたい、保守や機能更新を自組織だけで抱えたくない場合は、SaaSやパッケージが候補になります。初期開発を抑えやすく、複数自治体で共通化された機能を利用できる一方、独自の承認経路や帳票がそのまま再現できるとは限りません。災害時のアクセス急増に対するSLA、データの所在、解約時のエクスポート、API公開範囲を確認します。

デジタル庁は、自治体が防災アプリ・サービスを探して調達しやすくするため、防災DXサービスマップ・カタログ、モデル仕様書、デジタルマーケットプレイスの活用を進めています（出典: デジタル庁「自治体における防災アプリ・サービス調達の迅速化・円滑化」、2026年確認）。候補サービスを探す際は、カタログ掲載の有無だけで決めず、自組織の業務シナリオと連携要件を満たすかを提案依頼で確認します。

既存の防災行政無線、県のシステム、河川テレメータ、消防・福祉・住民情報などと深く連携し、地域固有の災害対応フローを実装する場合は、個別構築が必要になることがあります。ただし、全面的なスクラッチ開発は要件が膨らみやすく、制度や外部APIの変更のたびに改修費が発生します。標準基盤を使い、独自性が高い承認・帳票・データ連携だけを追加開発する方式が、費用と柔軟性のバランスを取りやすいです。

ハイブリッド方式では、SaaSの防災ポータル、既存の庁内システム、GIS、独自API、通知基盤などを組み合わせます。自由度が高い反面、障害が起きたときにどの会社が一次窓口になるか、ID連携・データモデル・バックアップを誰が管理するかが曖昧になりがちです。主契約者と再委託先を含む責任分界を、提案書と契約書の両方に記載してもらいます。

発注前の要件整理はどの順番で進めますか？

防災情報システムの発注では、いきなり製品名や画面要件を並べるのではなく、現状業務、災害シナリオ、データ、連携先、運用体制の順に整理します。担当者だけで作ると、災害対策本部や現場、広報、福祉、情報政策、消防の実態が抜けるため、部門横断のワークショップを実施します。

まず、地域の優先リスクを一つか二つに絞ります。例えば洪水なら、気象情報や河川水位を受信し、危険度を地図で確認し、避難所の開設状況を更新し、避難情報を承認して発信する流れを一つのシナリオにします。各工程について「入力者」「確認者」「判断者」「発信者」「記録の保存先」「目標時間」を決めると、必要なワークフローが見えてきます。

平時の訓練では、仮想の被害報告を入力してから本部で集約し、地図表示、承認、一斉配信、クロノロジー記録までを実際に操作します。入力の重複、同じ情報の電話・Excel・システムへの三重登録、未承認情報の誤配信が見つかれば、それを要件に反映します。機能の数ではなく、初動の遅れと二重入力をどれだけ減らせるかを評価軸にします。

連携一覧には、システム名だけでなく、データ項目、送受信方向、更新頻度、形式、認証方式、障害時の代替手段、データの所有者、テスト環境の有無を記載します。対象は気象庁防災情報XML、河川情報、Lアラート、県や国の防災基盤、防災行政無線、メール、SNS、Web、消防・福祉・住民情報などです。連携先の仕様書を入手できない場合は、RFPで前提条件と追加費用の見積方法を回答させます。

2026年5月29日から、気象庁は警戒レベルと対応しやすい新たな防災気象情報の運用を開始しました。大雨や土砂災害、高潮などの情報体系が変わり、機械判読用のXMLについても新しい資料・サンプルが公開されています（出典: 気象庁「新たな防災気象情報について」、2026年確認）。既存システムのXML取り込みをそのまま前提にせず、仕様変更時の改修費、試験期間、切替手順を契約範囲に含めます。

個人情報を扱う場合は、認証、多要素認証、役割別権限、通信・保存時の暗号化、操作ログ、脆弱性対応、バックアップ、委託先管理、再委託の承認を要件化します。自治体の情報セキュリティポリシーやLGWAN接続、候補クラウドのISMAP登録状況も確認します。ただし、登録状況だけで安全性を判断せず、対象サービス、運用責任、ログの保管期間、インシデント時の報告手順を合わせて見ます。

災害時は庁舎の被災、停電、通信断、アクセス急増を想定します。RTOはいつまでに復旧するか、RPOはどの時点までのデータを復元できるかを明記し、複数拠点のバックアップ、代替回線、手作業への切替、障害時の連絡先、現地支援の到着条件を確認します。平時の稼働率だけでなく、訓練で実際に復旧・切替できるかを受入条件にします。

RFI・RFPで発注条件を伝える方法

RFIは市場にどのようなサービスや技術があるかを把握するための情報提供依頼で、RFPは具体的な提案と見積を求める提案依頼です。最初から一社の製品仕様に合わせず、RFIで選択肢と制約を把握してから、同じ条件でRFPを配布すると、比較可能な提案が集まりやすくなります。

RFIでは、組織の規模、対象部署、想定災害、既存システム、連携先、導入希望時期、予算検討の前提、運用できる職員数を示します。製品の機能一覧だけでなく、標準機能で対応できる範囲、追加開発が必要な範囲、APIの公開条件、データ移行方法、災害時サポート、導入事例の提示を求めます。価格を聞く場合は、初期費用、月額・年額、連携費、移行費、訓練費、保守費を分けて回答してもらいます。

RFIの回答を比較するときは、できる・できないの二択ではなく、「標準設定」「追加設定」「個別開発」「外部サービスが必要」の四つに分類します。災害時の現地支援や職員向け研修を提供できるかも確認します。回答を受けた後、要件を変更した場合は、変更内容と見積への影響を記録しておくと、RFP後の認識違いを抑えられます。

必須要件には、災害情報の登録・承認・履歴管理、必要な外部連携、権限管理、ログ、バックアップ、可用性、アクセシビリティなど、導入しなければ業務が成立しない条件を置きます。加点要件には、多言語・やさしい日本語、AIによる情報整理、スマートフォン入力、オフライン時の代替入力、訓練シナリオ機能などを置きます。将来要件には、被災者支援、センサー追加、他自治体との広域連携、分析機能などを置き、初回の開発範囲と混同しないようにします。

RFPでは、同じ洪水や地震のシナリオを使ったデモを求めます。候補会社には「情報受信から地図表示」「現場報告の登録」「本部での集約と指示」「承認後の一斉発信」「対応履歴の出力」までを実演してもらいます。録画された説明や機能表ではなく、実際の操作で二重入力、承認漏れ、通信断、誤配信防止、データ出力のしやすさを比べることが大切です。

価格だけで決めると、連携や訓練を別発注することになり、結果的に高くなる場合があります。評価項目は、業務適合性、連携・データ移行、災害時の可用性とセキュリティ、運用・訓練支援、導入体制、拡張性、費用のように分けます。例えば、価格を全体の30％以下に抑え、必須要件を満たさない提案は価格にかかわらず失格とするなど、調達方式に沿った評価基準を設定します。

また、提案書の実績欄では、単なる導入件数ではなく、同規模の自治体での稼働年数、実災害や訓練での利用、障害対応、職員研修の実施回数、再委託先の担当範囲を確認します。候補会社が得意とする災害種別や機能と、自組織の課題が一致しているかを見ます。知名度や機能数よりも、災害対応フローを平時から変えられるかを重視します。

契約形態と委託範囲はどう決めますか？

防災情報システムでは、要件定義、設計・開発、データ移行、テスト、研修、運用保守、災害時支援が一つの契約に見えても、成果物と責任は異なります。契約形態を業務の性質に合わせ、要件が固まっている部分と、調査・伴走が必要な部分を分けると、変更時のトラブルを減らせます。

請負契約は、合意した成果物を完成させ、検査・受入を行う開発工程に向いています。画面、API、帳票、テスト結果、操作マニュアル、移行結果などを成果物として明確にし、受入条件と不具合対応を定めます。要件が曖昧なまま請負にすると、追加要望が変更契約になり、納期と費用の調整が難しくなります。

準委任契約は、現状調査、業務整理、要件定義支援、技術調査、運用改善のように、専門家が善管注意義務をもって業務を支援する場面に向いています。作業時間や体制だけでなく、会議体、レビュー、成果物、意思決定の記録を契約に含めます。要件定義を準委任で行い、要件確定後の開発を請負にする二段階方式も選択肢になります。

SLAには、サービスの稼働率だけでなく、障害の検知・一次回答・復旧目標・経過報告・再発防止報告を定めます。災害発生時に通常の窓口が混雑することを想定し、緊急連絡先、24時間対応の有無、休日・夜間の扱い、現地支援の条件、通信断時の連絡手段も確認します。大規模災害の対象地域が広がった場合の優先順位も、事前に協議しておきます。

委託先が再委託する場合は、再委託先の社名、担当工程、アクセスするデータ、セキュリティ審査、事故時の責任を把握します。契約終了時のデータ返却・消去、バックアップの引き渡し、API仕様書やソースコードの扱い、移行支援の期間も重要です。自組織が将来別会社へ移行できるよう、データを標準形式で出力できることを明記します。

防災情報システムの費用相場と見積の内訳

防災情報システムに全国共通の定価はありません。情報収集・GIS・一斉発信だけか、無線・センサー・住民アプリ・避難所・被災者支援まで含むかで、費用の桁が変わります。以下の金額は公開価格ではなく、公開Q&A、自治体予算、類似公共システムの情報から整理した発注前の目安です。最終的には、対象機能と連携範囲をそろえた個別見積が必要です。

標準クラウドやパッケージを小・中規模で導入する場合、初期費用は50万〜300万円、年額は30万〜100万円、5年間の総保有コストはおおむね200万〜800万円が一つの目安です。ただし、これは標準機能中心で、連携、データ移行、研修、個別帳票、災害時の現地支援を追加すると上振れします。SaaSの利用料だけを見て、APIや運用設計を別費用にしないよう注意します。

県規模の公開予算例では、鳥取県の令和7年度資料に、防災情報ポータルの機能追加13,744千円、令和8年度の債務負担行為15,495千円、既存ポータルの保守・回線接続費12,043千円が記載されています。河川情報・高所カメラ・地図表示・気象庁XML仕様変更への対応を含む事例であり、全国一律の価格ではありません（出典: 鳥取県「令和7年2月定例会 議案説明資料・令和7年度当初予算説明書」、2025年）。県・政令市など既存システムが多い組織では、連携と保守が大きな費用要因になります。

見積は、要件定義・業務設計、ライセンスやSaaS利用料、画面・ワークフロー設定、GIS・地図データ整備、API・既存システム連携、インフラ・冗長化・バックアップ、データ移行、テスト、訓練、本番移行、保守・監視、災害時の現地支援に分けます。さらに、初年度だけ発生する費用と、毎年発生する費用、利用量に応じて増える費用を分けると、5年TCOを計算できます。

国のクラウド型被災者支援システムでは、ソフトウェアの開発費を内閣府が負担し、自治体はクラウド環境や通信環境などのインフラ使用料を負担する整理が示されています。一方、既存の住民情報システムからのデータ出力や連携改修は、住基ベンダーへの個別確認が必要です（出典: 内閣府・J-LIS「クラウド型被災者支援システムに関する主な質問と回答」、2025年）。公的な支援制度や特別交付税、起債の対象可否も、予算要求前に所管部署へ確認します。

標準機能中心なら1〜5か月、要件定義から本稼働までの一般的な導入は6か月〜1年、複数の既存システムと連携する県・政令市やスクラッチ開発では9〜24か月を見込むと安全です。短期導入を目指す場合は、最初の3か月で扱う災害種別・部署・避難所を限定し、後続フェーズの範囲を明示します。対象を広げる時期と追加予算が決まっていない短納期計画は、終盤の要望追加で破綻しやすいです。

5年TCOは、初期費用に5年分の利用料・保守費・回線費・クラウド従量費・訓練費・データ更新費・制度変更対応費を加えて計算します。例えば初期構築が1,000万円でも、年額の保守・利用料が300万円なら、5年TCOは2,500万円です。逆に初期費用が安くても、連携を別会社に毎年依頼するなら総額は上がります。見積比較では、同じ期間、同じ連携、同じ訓練回数で比較します。

委託先の選定と見積比較で失敗しないポイント

防災情報システムの委託先は、総合SI、通信・運用、GIS・空間情報、気象・予測、被災者支援など、得意領域が異なります。大手か中小かだけで絞らず、必要な業務を主契約者が担えるか、専門会社との連携を管理できるか、導入後も訓練と改善を支援できるかを見ます。

確認するのは、導入件数だけではありません。自組織と同規模の自治体で、災害対策本部、現場入力、避難所、広報、被災者支援のどこまでを稼働させたか、既存の気象・河川・無線・GISと接続したか、訓練や実災害で使われたかを確認します。可能であれば、発注者への照会、実際の操作画面、障害対応の報告書、導入後の改善履歴を見せてもらいます。

公開情報では、NEC、NTT東日本、NTTデータ、富士通、日立、パスコなどが、防災情報、自治体、GIS、予測分析、通信・運用の領域で実績を公開しています。ただし、掲載企業の知名度や紹介ページだけで順位をつけるのではなく、RFPに同じ災害シナリオと評価表を渡し、標準機能・追加開発・連携・災害時支援を同じ条件で比べます。

まず、見積書の項目を共通テンプレートにそろえます。要件定義、基本設計、設定・開発、連携、移行、試験、研修、本番切替、保守、クラウド・回線、災害時支援を行に分け、数量、単価、期間、前提条件、除外事項、追加時の単価を記載してもらいます。「一式」だけの項目は、作業内容と完了条件を質問します。

次に、機能の対応度とリスクを評価します。標準機能で対応できる項目、設定変更で対応する項目、個別開発する項目、別途契約になる項目を色分けすると、価格差の原因が分かります。さらに、データの所有権、API仕様書の提供、解約時の移行、責任分界、サポート時間、制度・XML変更への対応方法を比較します。最安値ではなく、5年TCOと災害時の継続性を含めた総合評価にします。

導入直後に全機能を使いこなすことは難しいため、数部署・数避難所・一つの災害種別から始め、訓練で入力から発信までを確認して段階的に広げます。人事異動で担当者が変わる自治体では、動画や手順書だけでなく、異動時研修、出水期前の訓練、夜間・休日を想定した訓練を契約に含めます。訓練後は、入力遅延、誤配信、二重入力、未確認情報の滞留、復旧時間を記録します。

運用開始後は、年1回の訓練だけで終わらせず、災害対応マニュアルの改定、制度変更、外部APIの更新、組織改編に合わせて要件を見直します。委託先には、月次または四半期の運用報告、障害・脆弱性の報告、利用ログの分析、改善提案を求めます。システムを納品して終わりではなく、平時の訓練で運用を改善する契約にすることが、実災害での利用率を高めます。

よくある質問（FAQ）

防災情報システムの発注では、費用、開発期間、既存システムとの連携、運用体制について質問が多く寄せられます。ここでは、発注前に判断しやすいように、よくある疑問へ直接回答します。

標準機能中心の小・中規模クラウドやパッケージなら、初期50万〜300万円、年額30万〜100万円程度が目安になります。ただし、これは標準機能を前提にした目安で、GIS、API連携、データ移行、個別帳票、研修、災害時支援を含めると増額します。必要な機能と5年分の運用費をそろえた見積で判断してください。

現状業務と災害シナリオを整理できる担当者がいれば、基本的なRFPは作成できます。ただし、API、ネットワーク、可用性、セキュリティ、データ移行、契約責任まで抜けなく記載するには、情報政策部門や外部の専門家にレビューを依頼すると安心です。RFIで市場の対応範囲を把握し、必須・加点・将来要件を分けてからRFPに落とし込む方法が現実的です。

短期間・標準業務中心ならSaaSやパッケージ、地域固有の業務や複雑な既存連携が中核なら個別構築が向いています。ただし、全面スクラッチではなく、標準基盤に独自の承認・帳票・連携だけを追加する方式も有力です。自組織の災害シナリオを候補サービスで実演し、標準機能で足りない部分の費用と将来の改修負担を比べて決めます。

保証できる範囲は契約で定められます。稼働率だけでなく、障害の一次回答、復旧目標、経過報告、緊急連絡先、夜間・休日対応、現地支援の条件、代替運用、再発防止報告をSLAや運用仕様書に記載します。実際に訓練で連絡網と復旧手順を試し、契約どおりに支援できるかを確認することも必要です。

まとめ

防災情報システムの発注・外注・委託では、最初に地域の災害シナリオと業務の流れを整理し、標準機能と独自開発の境界を決めます。そのうえでRFIとRFPを使い、同じシナリオ、同じ連携条件、同じ5年TCOで候補会社を比較します。費用相場は導入範囲によって大きく変わるため、初期構築費だけでなく、連携、移行、保守、訓練、災害時支援まで見積に含めることが重要です。

第一に、機能数ではなく「入力・判断・承認・発信・記録・訓練」の一連の流れで評価します。第二に、API、データ所有権、バックアップ、SLA、再委託、解約時の移行を契約条件にします。第三に、導入後の訓練と利用ログの改善までを委託範囲に含めます。2026年の新たな防災気象情報やXML仕様の変更にも追随できる体制を確認しておくと、導入後の追加費用と手戻りを抑えられます。

まず、関係部署を集めて一つの災害シナリオを選び、現状の情報経路と二重入力を洗い出します。次に、既存システム・データ・連携仕様・セキュリティ・災害時の代替運用を一覧化し、RFIで候補サービスの対応範囲を確認します。最後に、必須・加点・将来要件と共通の見積様式を用意してRFPを配布し、実演と5年TCOを含めて委託先を選定します。

防災情報システムは、導入して終わる設備ではなく、平時の訓練と有事の意思決定を支える業務基盤です。自組織の災害対応を理解し、開発・連携・運用を一緒に改善できるパートナーを選ぶことが、発注の最も重要なポイントです。

▼全体ガイドの記事
・防災情報システム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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