社内で完結するシステムを設計してきたエンジニアが、外部の複数組織とつなぐ案件に触れると、勝手の違いに戸惑うことがあります。相手が1社や2社であれば、個別に調整して仕組みを合わせることもできますが、相手の数が数百、数千に及ぶ場合はその前提が崩れます。内閣府が公表した新総合防災情報システムの資料は、多数の組織とつなぐ仕組みが実際に何を先に決めているかを見せてくれます。この記事では、その中身を、自分が関わる連携案件にそのまま当てはめられる形で整理します。

1. 相手が1,920あると設計が変わる

内閣府が公表した新総合防災情報システム（SOBO-WEB）は、災害情報を地理空間情報として共有する仕組みです¹。国、地方公共団体、指定公共機関を合わせて1,920機関が利用できる規模で運用されています⁴。

個別対応という前提が最初から崩れる

相手が数社であれば、担当者どうしで仕様をすり合わせ、個別に連携を組むやり方も十分に成り立ちます。仕様書を1本ずつ読み合わせ、相手の事情に合わせて手直ししていくやり方です。

しかし相手の数が1,920に達すると、この進め方は工数の面で最初から成立しません。1機関ごとに個別対応していては、いつまで経っても全体をつなぎ終わらないためです。多機関連携の案件に入るエンジニアがまず捉えたいのは、この規模の感覚です。

個別対応の設計よりも、共通の型を先に決めておく設計のほうが、相手の数が増えるほど効いてきます。1社ごとに仕様をすり合わせる手間を、1,920回積み重ねることは現実的ではないためです。多機関連携の案件に途中から加わるエンジニアも、まず相手の数を確認し、個別対応が成り立つ規模かどうかを見極めるところから始めます。

規模の見極めは、契約や要件定義の初期段階で済ませておきたい作業です。後になって相手の数の多さに気づくと、設計をやり直す羽目になります。

数を基準に設計を組み立てる考え方

この仕組みは、災害対応機関が被災状況等を早期に把握・推計し、災害情報を俯瞰的に捉えて全体像の把握を支援することを目的としています²。目的が全体像の把握である以上、参加する組織の数が増えるほど価値が増す設計になっています。

さらにシステム同士のデータ連携によって、災害情報の流通が可能になっています⁵。人が都度入力して回るのではなく、システムどうしが連携する前提が最初から組み込まれているということです。

相手の数を基準に設計を組み立てる考え方は、自社内のシステムを設計するときの感覚とは異なります。社内であれば、部署ごとの事情を個別に聞いて回る余地もありますが、外部の1,920機関にはその余地がありません。数を先に把握することが、設計の入り口になります。

図1は、1,920機関という規模を、中心の仕組みと周囲の区分として表したものです。相手の数を先に数え、個別対応ではなく共通の型で受け止める。それが多機関連携の設計の起点になります。

出典：内閣府「新総合防災情報システム（SOBO-WEB）について」（2025年11月）をもとに作成

2. 重ねて初めて意味が出る

多機関連携の仕組みは、ただ情報を集めるだけでは価値を持ちません。集めた情報を、どの軸で重ねるかによって意味が変わります。

単独のデータは判断材料になりにくい

1つの機関が持つ被災状況の情報だけでは、次にどこへ人や物を動かすか、その優先順位までは見えてきません。位置という軸を持たない情報どうしを並べても、比較のしようがないためです。

多機関連携の設計では、集めた情報をどの軸で並べるかを先に決めておく必要があります。この仕組みが選んだ軸は、地図の上の位置です。

情報を集める仕組みと、情報を重ねる仕組みでは、必要になる設計が別物です。集める仕組みは各機関からの窓口を用意すれば足りますが、重ねる仕組みは共通の座標軸を持たない限り機能しません。地図という座標軸を選んだことが、この仕組みの土台になっています。

座標軸を先に決める発想は、多機関連携以外の仕組みにも応用できます。時間軸で並べるのか、組織の階層で並べるのか、共通の軸を早い段階で固めておくことが、後工程の手戻りを減らします。

異なる情報を重ねて優先順位が見える

例えば、浸水被害の情報と、医療・福祉施設の情報を地図上で重ね合わせて表示すると、救助・支援活動の優先順位づけ等の検討に活用できます³。それぞれの情報を単独で見ているだけでは気づけない組み合わせです。

地図という共通のレイヤーに載せることで、別々の機関が持っていた情報が、初めて1つの判断材料になります。単独では意味を持たないデータが、重なって初めて価値を持つ。これが多機関連携の仕組みが目指す方向です。

個別に集めるだけの仕組みよりも、共通の座標軸で重ねる仕組みのほうが、参加する機関が増えるほど価値が増します。多機関連携の設計に関わるときは、情報をどの軸に載せるかを、早い段階で確認しておきたいところです。

重ねる情報と見えてくることの整理

地図の上で何と何を重ねると、どんな判断材料になるのか。ここまでの内容を整理すると、次のような対応関係になります。設計を任されるときは、この組み合わせを自分の案件に当てはめて考えると、重ねる軸が見えやすくなります。

重ねる対象	何をするか	見えてくること・設計の要点
浸水被害の情報／医療・福祉施設の情報	地図上で重ね合わせて表示する	救助・支援活動の優先順位づけ等の検討に活用できる3
各機関が個別に持つ位置情報	共通の地図基盤に統合する	単独では判断材料にならなかった情報が意味を持つ
更新頻度が異なる複数のレイヤー	同じ地図上で同期して表示する	レイヤーごとの更新タイミングをそろえる設計が要る

3. 入口を絞らない

相手が1,920あるとき、こちらの都合で相手の環境をそろえてもらうことはできません。だから入口の設計が変わります。

相手の環境を揃えられない前提に立つ

自社内のシステムであれば、使う端末や回線をある程度そろえることもできます。しかし相手が国や地方公共団体、指定公共機関にまで及ぶと、相手ごとの環境は最初からばらばらです。

相手の環境をこちらで指定できないという前提は、社内システムを設計するときの感覚とは逆になります。この逆転を早い段階で意識できるかどうかが、入口の設計の質を左右します。

この仕組みは専用端末不要で、PC、タブレット、スマートフォンから利用できます⁶。特定の端末を前提にすると、その端末を持たない相手を最初から締め出すことになります。

専用端末を用意する設計よりも、手元にある端末をそのまま使える設計のほうが、相手の負担を増やしません。相手に新しい機器の準備を求めた時点で、参加できる機関の数は狭まってしまいます。

共通の入口を用意するという設計

入口を絞らないという決め事は、機能を減らすという意味ではありません。むしろ、どの環境からでも同じ入口にたどり着けるように、共通の窓口を先に用意しておくという設計です。

この考え方は、社内向けのシステムでは意識しにくいものです。利用者を自社のメンバーだけに絞れる環境では、端末をそろえるほうが管理しやすく感じられます。相手が外部の1,920機関に及ぶ多機関連携では、この感覚を切り替える必要があります。

システム同士のデータ連携によって情報の流通が可能になっている以上⁵、入口は人が使う画面だけでなく、システムからの接続も受け止める形になっています。多機関連携の案件では、この二重の入口を意識して設計に加わることが求められます。

入口を広く取る設計は、確認する項目を減らすという意味でもありません。むしろ、どの環境から接続されても同じ形で受け止められるように、入口の手前で形式をそろえる仕組みを用意しておく必要があります。

図2は、複数の環境から同じ入口にたどり着く仕組みを表したものです。入口を1つの端末に絞らないことが、1,920機関という規模を受け止める最初の条件になっています。

出典：内閣府「新総合防災情報システム（SOBO-WEB）について」（2025年11月）をもとに作成

4. 共有する項目を先に決める

入口を広く取っても、何を共有するかが決まっていなければ、届いた情報はそれぞれの機関でばらばらの形のままです。

共有する情報を先に決めた第1版

令和6年4月より運用が始まったこの仕組みでは、国や地方自治体、指定公共機関等の災害対応機関が共有する特に重要な情報を、災害対応基本共有情報として令和5年度に第1版が策定・公表されました⁸。

項目を先に決めておくことで、機関ごとに形式の違う情報を受け取ってから調整するのではなく、最初から同じ形で届く仕組みにできます。多機関連携の設計では、この順番が要になります。

共有する項目を決める作業は、地味に見えて設計の骨格を作る工程です。ここで決めた項目の粒度が粗ければ、後から機関ごとに解釈が分かれ、結局は個別対応に逆戻りしてしまいます。

項目の粒度を決める作業には、実務側と技術側の両方の視点が要ります。技術側だけで決めると、現場で使われない項目ばかりが並びかねません。

共有する項目を先に決めておく設計よりも、届いてから調整する設計のほうが手間がかからないように見えます。しかし機関の数が増えるほど、その場しのぎの調整は積み重なって破綻します。先に決めておく手間のほうが、結果として小さく済みます。

決め事は更新され続ける第1.1版

共有する項目は、一度決めたら終わりではありません。共有するデータの具体的な内容として、データ属性を追加した第1.1版が令和7年6月に公表されています⁹。

決め事を作った後も、実際に運用してみて粒度を見直し、項目を育てていく。多機関連携の仕組みに加わるエンジニアの仕事は、この更新の作業にも及びます。

版を重ねるという発想は、最初から完璧な項目一覧を用意することを求めていません。むしろ、運用しながら育てていくことを前提にした設計です。多機関連携の仕事に関わるエンジニアには、この継続的な見直しに付き合う役割も期待されます。

共有項目が版を重ねてきた変遷

運用開始から第1.1版までの流れを整理すると、次のようになります。共有する項目は一度で完成させるものではなく、版を重ねて育てていくものだと分かります。

版	策定・公表時期	内容
運用開始	令和6年4月	新総合防災情報システムの運用が始まる8
第1版	令和5年度に策定・公表	災害対応機関が共有する特に重要な情報を災害対応基本共有情報として整理
第1.1版	令和7年6月公表	共有するデータの具体的な内容としてデータ属性を追加9

5. 使えないときに残す範囲を決める

多機関連携の仕組みは、平常時だけでなく、使えなくなったときの設計も持っています。

全部を守るという設計にしない

災害対応に使う仕組みだからといって、あらゆる場面で全機能を保とうとすると、その分だけ仕組み自体が複雑になり、かえって壊れやすくなります。

この仕組みは、クラウドが使用不可となった場合、オンプレミスで官庁向け機能のみ縮退運転を実施します⁷。全部を守るのではなく、残す範囲をあらかじめ狭めてあるという考え方です。

全機能を保とうとする設計よりも、残す範囲を先に絞っておく設計のほうが、実際に使えなくなった場面で迷いが少なくなります。判断する材料が少ない状況ほど、事前に決めてある範囲がそのまま頼りになります。

官庁向け機能だけを残すという線引き

縮退運転の設計で大事なのは、何を諦めるかではなく、何を最後まで残すかを先に決めておくことです。残す範囲が決まっていれば、実際に使えなくなった場面でも、迷わずその範囲に切り替えられます。

縮退運転という言葉だけを聞くと後ろ向きな印象を持つかもしれませんが、中身は前向きな設計判断です。守る範囲を早い段階で決めておくことで、緊急時に議論する時間そのものを減らせます。

縮退時に残す機能を絞り込む判断は、平常時の設計を担当するエンジニアが下すことになります。縮退運転の範囲を決める作業も、多機関連携の設計に含まれる仕事の一部です。

多機関連携の案件に入るエンジニアが持ち込みたいのも、この視点です。相手が1,920あるからこそ、平常時の設計と同じくらい、縮退時に何を残すかの設計にも目を配る必要があります。

縮退運転の範囲を官庁向け機能に絞っている点も見落とせません。相手が1,920機関にのぼる仕組みだからこそ、緊急時に維持する範囲を広く取りすぎないことが、かえって仕組み全体の頼りやすさにつながります。

図3は、通常時と縮退時とで、残る範囲がどう変わるかを表したものです。全部を守る設計ではなく、残す範囲を先に決めておく設計だと分かります。

出典：内閣府「新総合防災情報システム（SOBO-WEB）について」（2025年11月）をもとに作成

6. まとめ｜つなぐ側の設計

ここまで見てきた3つの決め事は、入口を絞らないこと、共有する項目を先に決めること、使えないときに残す範囲を決めることです。相手が1,920あるという規模から逆算すると、この3つを最初に立てておくことが欠かせません。

この3つは、防災の仕組みに限った話ではありません。多機関連携が絡む案件であれば、業種を問わず同じ3つの問いが立ちます。相手の数を数え、共有する項目を決め、使えないときに残す範囲を決める。この型を知っているかどうかが、案件に入ってからの動き方を左右します。

3つの決め事を表で確認する

自分が関わる連携案件でも、この3つをそのまま当てはめて確認できます。次の表に、それぞれの決め事と、確認しておきたいことを整理しました。

決め事	何を先に決めているか	自分の案件で確認したいこと
入口を絞らない	専用端末を要求せず、PC・タブレット・スマートフォンから利用できる設計6	相手側の環境を限定せず受け止められる入口になっているか
共有する項目を先に決める	災害対応基本共有情報として、共有する情報をあらかじめ整理8	どの項目を、どの粒度で共有するかが最初に合意されているか
使えないときに残す範囲を決める	クラウドが使用不可の場合、官庁向け機能のみの縮退運転を用意7	障害時にどこまで機能を残すかが、事前に決まっているか

図4は、この3つの決め事を1つの図にまとめたものです。相手の数から逆算して、入口・共有項目・縮退時の範囲という順に設計を積み上げていく流れを表しています。

図の作成：Remogu編集部。本文で取り上げた3つの決め事を整理したもので、統計データではありません

多機関連携のような案件は、自社内で完結する開発とは、関わる相手の数も、必要になる調整の視点も変わります。こうした経験は、社内向けの開発だけを続けていては積みにくいものです。Remoguが扱う案件は、90%以上がフルリモートで参画できます¹⁰。場所に縛られず、こうした設計の経験を積みたいエンジニアには、条件を見比べてみる価値があります。組織をまたぐ視点を持って設計に関わった経験は、次の案件でも強みとして生かせます。

7. よくある質問

多機関連携の案件では、何から手をつければよいですか

まず相手の数を数えることから始めます。相手が数社なのか、数百、数千に及ぶのかで、個別対応が成り立つかどうかが変わります。相手の数が多いと分かった時点で、入口を絞らないこと、共有する項目を先に決めること、使えないときに残す範囲を決めることの3つを検討します。

相手の数が多い案件と、少ない案件では、設計の考え方はどう変わりますか

相手が少なければ、相手ごとの事情に合わせて個別に調整する余地があります。相手が多いと、その余地がなくなり、共通の型を先に決めて、相手にはその型に合わせてもらう向きに変わります。1,920機関という規模は、その転換点を分かりやすく示す例です⁴。

縮退運転の設計は、可用性を高める設計と同じものですか

近い部分はありますが、狙いが少し違います。可用性を高める設計は壊れにくくすることに重心があり、縮退運転の設計は壊れた後に何を残すかに重心があります。多機関連携の仕組みでは、官庁向け機能のみを残すという範囲があらかじめ決まっています⁷。

こうした案件に参画するには、どんな経験が生きますか

特定の技術1つの経験よりも、複数の関係者の事情を1つの仕組みに落とし込んだ経験のほうが評価されやすい領域です。社内向けの開発だけでなく、外部の組織と情報をやり取りする設計に関わったことがあれば、それは十分に生かせる経験です。まずは組織をまたぐデータ連携に関わるリモート案件が、どのような条件で並んでいるのかを見比べるところから確かめられます。

多機関連携の案件は、どのように見つけられますか

組織をまたぐデータ連携に関わる案件は、案件情報の技術要件や参画条件を確認しながら探すことになります。Remoguでも、こうした条件のリモート案件を掲載しています。まずは条件を見比べて、自分の経験がどこで生きるかを確かめるところから始められます。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 内閣府「新総合防災情報システム（SOBO-WEB）について」令和7年11月 内閣府政策統括官（防災担当）（2025年11月）
＊2 内閣府「新総合防災情報システム（SOBO-WEB）について」令和7年11月 内閣府政策統括官（防災担当）（2025年11月）
＊3 内閣府「新総合防災情報システム（SOBO-WEB）について」令和7年11月 内閣府政策統括官（防災担当）（2025年11月）
＊4 内閣府「新総合防災情報システム（SOBO-WEB）について」令和7年11月 内閣府政策統括官（防災担当）（2025年11月）
＊5 内閣府「新総合防災情報システム（SOBO-WEB）について」令和7年11月 内閣府政策統括官（防災担当）（2025年11月）
＊6 内閣府「新総合防災情報システム（SOBO-WEB）について」令和7年11月 内閣府政策統括官（防災担当）（2025年11月）
＊7 内閣府「新総合防災情報システム（SOBO-WEB）について」令和7年11月 内閣府政策統括官（防災担当）（2025年11月）
＊8 内閣府「新総合防災情報システム（SOBO-WEB）について」令和7年11月 内閣府政策統括官（防災担当）（2025年11月）
＊9 内閣府「新総合防災情報システム（SOBO-WEB）について」令和7年11月 内閣府政策統括官（防災担当）（2025年11月）
＊10 Remoguサイト公開情報（フルリモート可能案件の割合）