拠点が増えるたびに、また一からネットワークを引き、また一から端末を選んでいないか。増えた分だけ管理する対象が増え、それを見る人は増えていない。
デジタル庁は2026年8月14日、「防災庁のガバメントソリューションサービスへの移行に係るネットワーク環境構築及び保守」について公募公告を出した。応募要領に書かれている目的と概要は、制度や規模の違いを差し引いても、民間企業の拠点展開を考えるうえで参考になる内容である。
要点を原文に沿って整理する。
- ガバメントソリューションサービス（GSS）は、政府共通の標準的な業務実施環境（業務用PCやネットワーク環境）を提供するサービスである
- 高度化する脅威に対応したゼロトラストアーキテクチャに基づき、利便性とセキュリティ両面を確保したネットワークへの統合に向けて、まずデジタル庁がGSSを導入した
- その後、人事院および農林水産省を始めとして、各府省庁は令和4年度（2022年度）以降のネットワーク更改等を契機に、この環境へ移行することを原則とされた
- 新たに設置が決定した防災庁においても、職員の業務実施環境としてGSSを提供する
新しい組織ができたときに、その組織の環境を政府共通の標準環境の上に構築する。この順序が置かれている点が、本稿で取り上げたいところである。
誤解のないように書いておくと、これは「何も作らなくてよい」という話ではない。今回の公募件名そのものが「ネットワーク環境構築及び保守」であり、調達仕様書の範囲には防災庁のGSS環境の設計・構築と防災庁に設置する機器等の借入および当該機器等の保守が入っている。共通基盤を使っても、その組織に固有の設計・構築・移行の作業は発生する。変わるのは、基盤の設計から始めるか、既にある基盤の上に載せるところから始めるか、という出発点である。
この記事を読むべき人
- 拠点や子会社が増えており、そのたびにネットワークと端末を個別に手配している会社
- 買収や統合で、環境の異なる組織を抱えることになった会社
- 情報システムの担当が増えないまま、管理対象だけが増えている会社
- 拠点ごとに保守の委託先が違い、全体像を把握している人がいない会社
- ネットワーク機器の更改時期が近く、同じ構成で入れ替えるつもりでいる会社
RESTAURANT DX
店長の経験と勘を、仕組みで再現できる店舗にしませんか？
発注／シフト／予約／FLコストを標準化する多店舗飲食特化のDX。食材ロス削減・インバウンド対応まで概算費用をその場で示します。
「更改を契機に移行する」という順序
応募要領の記述で実務的に効くのは、「ネットワーク更改等を契機に、この環境へ移行することを原則とされた」という部分である。
一斉に切り替えるのではなく、更改の機会をとらえて順次統合していく、という進め方である。なお、応募要領が述べているのはここまでで、何をもって更改の機会とするかは示されていない。
これを民間企業に当てはめると、機器の保守期限や回線の契約更新が、その機会にあたる。以下は、この読み替えを前提としたGXOの整理である。
なぜこの順序が検討しやすいかというと、更改が「放っておいても発生する支出」だからである。同じ構成で入れ替える前提の予算は、すでに議論の俎上にある。その場に「標準環境に寄せる案」を並べれば、比較の土俵に乗せやすい。
ただし、寄せる側には更改費用に収まらない支出が出ることがある。移行そのものの作業費、既存回線の解約に伴う費用、認証やアカウントの統合、切り替え時の停止リスクへの備えなどである。「更改予算の枠内で済む」と決めてかかると、途中で追加の決裁が必要になる。先に見積もっておきたい。
それでも、更改は費用・停止・契約の見直しを一度にまとめられる有力な機会である。更改以外の時期に移行できないわけではないが、その場合は移行費用を単独で計上し、契約の残期間も処理する必要が出る。次の更改がいつ来るかは、機器の保守期限と回線の契約期間によるため、自社の資産台帳と契約書で確認したい。
今、自社のネットワーク機器やPCの更改時期が近い拠点があるなら、そこが検討のタイミングである。「今回は同じもので」と決める前に、標準化の対象にできないかを一度並べて比較したい。
何を「標準」と呼ぶのかを決めておく
調達仕様書には、GSSのネットワークの考え方として次の記載がある。仮想化技術を用いた統合ネットワークを実現することにより、組織やシステム毎に異なるネットワーク要件に対応する。このネットワークは、マルチテナンシー、サービスチェイニングによるコストの高効率化、個別のニーズに柔軟に対応できる仮想化、広帯域、低遅延の要素を備えることとする、とされている。
ここで注目したいのは、「標準環境に寄せる」ことと「全部同じにする」ことが同義ではない点である。
組織やシステムごとに要件が違うことを前提にしたうえで、共通の基盤の上でその違いを吸収するという設計になっている。
中堅企業が拠点の標準化を検討するときに失敗しやすいのが、ここである。「標準化」を「全拠点まったく同じ構成」と定義してしまうと、事情の違う拠点が必ず出てきて、例外が積み上がり、結局標準が形骸化する。
先に決めるべきは、何を共通にして、何を拠点ごとに変えてよいかの線引きである。
実務的には、次の3層に分けて考えると整理しやすい。
- 共通で固定するもの（認証の仕組み、端末の管理方式、通信の経路とセキュリティの考え方）
- 選択肢の中から選ばせるもの（回線の種類や帯域、拠点内の機器構成）
- 拠点の裁量に任せるもの（座席レイアウトに伴う配線、什器）
この線引きを文書にしていない会社では、拠点ごとの判断が全部「相談」になる。相談が増えれば、情報システムの担当がボトルネックになる。
運用の引き継ぎを、最初の契約に書いておく
調達仕様書の調達範囲には、設計・構築や機器の借入・保守と並んで、次の項目が挙げられている。
GSS運用事業者へ引継ぎ（令和9年5月末までに実施すること。なお、令和12年9月末までにGSS運用事業者に変更があった場合、その都度、対応を行うこと。）
この一文が持つ意味は大きい。
構築を担当する事業者と、その後の運用を担当する事業者が別であることを前提に、引き継ぎの期限と、運用事業者が交代した場合の再対応まで、最初の契約の範囲に含めている。
中堅企業の発注では、ここが抜けることが多い。構築したベンダーがそのまま運用を続ける前提で契約し、何年か後に運用を別の会社に移そうとした時点で、引き継ぎの費用と期間の交渉が始まる。このとき交渉力を持っているのは、構成を把握している側である。
構築を発注する時点で、次の3点を契約に書けるかを確認したい。
- 運用を別の事業者に移す場合、どこまでの資料と情報を、いつまでに引き渡すのか
- その作業は当初の契約範囲に含まれるのか、別途費用が発生するのか
- 運用の担当が交代した場合、そのたびに対応する義務があるのか
3番目まで書いてある契約に、GXOが発注支援で立ち会った範囲ではあまり出会わない。民間全体での頻度を示すデータを持っているわけではないが、自社の契約に書かれているかを確認する価値はある。
契約直後の10業務日で握るもの
調達仕様書には、プロジェクト実施計画に関する要件として次の記載がある。受注者は契約締結後10業務日以内に、プロジェクトの実施方針、体制表、マスタスケジュール、作業分解構成図（WBS）等を含むプロジェクト実施計画書及びプロジェクト管理要領を当庁へ提出し、承認を得ること。
さらに、体制表には、作業責任者、個人情報取扱責任者及び作業担当者の氏名及び所属、担当作業、指揮命令系統、情報セキュリティ対策に係る管理・連絡体制並びに連絡先を記載することとされている。加えて情報取扱者名簿および情報管理体制図を提出するものとされ、受注者に提供する情報の受注者による目的外利用の禁止、受注者及び再委託先における情報セキュリティ教育等の対策の実施内容及び管理体制を含む情報セキュリティ対策を実施することが求められている。
中堅企業の発注に持ち込める部分は、ここに集中している。
期限を切って計画書を出させる。「契約締結後10業務日以内」という具体的な日数が入っている。期限がなければ、計画書は最初の打ち合わせ資料に置き換わって出てこない。
体制表に、誰が何を担当するかまで書かせる。会社名と部署名だけの体制図では、実際に手を動かす人が誰かが分からない。指揮命令系統まで書かせておくと、問題が起きたときに誰に言えばよいかで迷わない。
再委託先まで含めた情報セキュリティの取り扱いを最初に確認する。実際の作業が委託先で行われる場合、自社の情報がどこまで渡るのかは、契約時にしか決められない。
スケジュールを「提案させる」という設計
調達仕様書の作業スケジュールの節には、応札者は提案書において、本調達で必要となる作業を整理し、適切な作業スケジュールを提案することとされ、受注者は契約後、担当職員と協議の上、本調達の具体的なスケジュールについて計画、決定することと書かれている。
発注側が想定スケジュールを示したうえで、確定は提案と協議に委ねる、という構造である。
この形は、中堅企業の発注でも有効である。発注側が期日を一方的に固定すると、無理のある計画がそのまま契約に入り、後から遅延の責任論になる。逆に完全にベンダー任せにすると、比較ができない。
「こちらの想定はこれ。実現可能な計画を提案してほしい」という出し方であれば、提案の中身で比較できる。そして提案されたスケジュールに無理があるかどうかは、その計画を実行する体制表と突き合わせれば、ある程度は判断できる。
よくある質問
Q. この公募は民間企業に関係があるのか。 A. 直接の関係はない。公的機関の調達であり、参加資格も行政向けのものである。本稿は、新設組織のIT環境をどう設計するかの考え方を学ぶ材料として扱っている。
Q. 拠点が3つ程度でも、標準化を考える意味はあるか。 A. ある。むしろ、拠点数が少ないうちに線引きを決めておくほうが安い。5拠点、10拠点と増えてから統一しようとすると、既存拠点の作り替えが発生する。
Q. 標準環境に寄せると、拠点の事情に対応できなくなるのではないか。 A. 「全部同じにする」設計であればそうなる。共通で固定する部分と、選択肢の中から選ばせる部分を分けておけば、拠点ごとの事情は選択肢の側で吸収できる。
Q. ゼロトラストの考え方を取り入れるべきか。 A. 拠点間を専用線で結び、社内なら信頼するという前提が崩れている会社では検討する価値がある。ただし、製品を入れることではなく、誰が何にアクセスしてよいかを定義し直すことが本体である。定義がないまま製品を入れても、運用が回らない。
Q. 更改の時期が来ている拠点がある。何から確認すればよいか。 A. 現在の機器の保守期限、回線の契約期間、そしてその拠点で動いている業務システムが何に依存しているかの3点である。この3点が分かれば、同じ構成で入れ替えるか、標準環境に寄せるかを比較できる。
Q. 引き継ぎ条項を契約に入れたいと言うと、ベンダーは嫌がらないか。 A. 嫌がる会社もある。その反応自体が判断材料になる。引き継ぎを想定した作り方をしている会社は、資料が整っているため、この条項を大きな負担とは受け止めない。
拠点や組織が増えるたびに個別に作っている状態を変えたいとき
拠点ごとに違う環境は、作った時点では最適でも、増えた瞬間から管理の負債になる。そして負担がかかるのは、人数が増えない情報システムの担当である。
現在の拠点構成と、どこから標準化できるかを整理したい場合はDX・システム開発で対応している。業務側の棚卸しから着手したい場合はDX推進トータルサポート、自社の現在地を確認したい場合はDX成熟度診断が使える。拠点間の通信とアクセス制御の設計を見直したい場合はセキュリティ診断、既にベンダーから構築の提案を受けているなら、引き継ぎ条項と体制表が実行可能な内容になっているかを契約条件を相談するから見直せる。
増えたSaaSの管理面をどう設計するかは公共SaaSのコントロールプレーンから読む管理設計、拠点とリモートを含めたネットワークの作り替えはゼロトラスト移行と拠点・リモートの再設計で扱っている。本稿は、新しい組織や拠点の環境を標準へ寄せる判断に絞っている。
参照した情報
- デジタル庁「公募公告：防災庁のガバメントソリューションサービスへの移行に係るネットワーク環境構築及び保守」（令和8年8月14日）: https://www.digital.go.jp/procurement/a6ef7176-6cb9-42fe-bf1a-a70322f49800
公募件名、公告日（令和8年8月14日）、公募期間（令和8年8月14日から令和8年8月24日12時）、契約形態（請負契約）、および契約期間（契約締結日から令和12年9月30日）は、上記ページで公開されている応募要領を取得して確認した。GSSが政府共通の標準的な業務実施環境（業務用PCやネットワーク環境）を提供するサービスである旨、ゼロトラストアーキテクチャに基づくネットワークへの統合に向けてまずデジタル庁がGSSを導入した旨、各府省庁が令和4年度以降のネットワーク更改等を契機に移行することを原則とされた旨、令和8年度以降も防災庁を含む複数の省庁で統合を実施する予定である旨、および新たに設置が決定した防災庁にGSSを提供する旨も、同応募要領の記載である。
GSSネットワークの考え方（仮想化技術を用いた統合ネットワーク、マルチテナンシー、サービスチェイニングによるコストの高効率化、個別のニーズに柔軟に対応できる仮想化、広帯域、低遅延）、調達範囲に含まれるGSS運用事業者への引継ぎとその期限（令和9年5月末まで、令和12年9月末までに運用事業者の変更があった場合はその都度対応）、作業スケジュールに関する記載（応札者が提案書で適切なスケジュールを提案し、受注者が契約後に担当職員と協議のうえ決定する）、契約締結後10業務日以内のプロジェクト実施計画書およびプロジェクト管理要領の提出と承認、体制表の記載事項、情報取扱者名簿および情報管理体制図の提出、目的外利用の禁止、ならびに受注者および再委託先における情報セキュリティ教育等の対策は、同ページで公開されている調達仕様書を取得して確認した。
調達の予定価格、応札事業者、および調達仕様書に含まれる技術要件の詳細は、本稿では扱っていない。公募という調達方式の制度上の位置づけについても、公告文に説明がないため本稿では触れていない。契約期間の始期は「契約締結日」であり公告時点では未確定であるため、本稿は契約期間の長さを断定していない。
標準を3層に分ける線引き、更改を検討の契機として使えるという読み方、移行に伴って更改予算の枠外の費用が発生し得るという指摘、引き継ぎ条項として確認すべき3点、契約直後に握るべき事項、およびスケジュールを提案させるという設計の評価は、拠点展開と発注の支援を通じてGXOが整理したものであり、デジタル庁が民間企業向けに示した基準や推奨ではない。行政の調達手続きと民間企業の発注は制度上の前提が異なるため、本稿の内容を公的機関への応札の手引きとして用いることはできない。
