水道情報活用システム
リファレンスアーキテクチャ仕様書（要件定義書）2019 年 4 月

国立研究開発法人新エネルギー・産業技術総合開発機構
株式会社 エヌ・ティ・ティ・データ

本書は、国立研究開発法人 新エネルギー・産業技術総合開発機構「IoT を活用した新産業モデル創出基盤整備事業」における「水道 IoT の社会実装推進に向けた検討」、及び「高度なデータ活用を可能とする社会インフラ運営システムの開発」事業により作成しました。

国立研究開発法人新エネルギー・産業技術総合開発機構(以下「当機構」という)は、以下の条件のもとで本ドキュメント(本使用許諾条件に添付されて提供されるドキュメントをいい、以下同じ)を使用、複製および頒布することを無償で許諾します。本ドキュメントを使用、複製または頒布した場合には、以下の条件に同意したものとします。
１．本ドキュメントの中に含まれる著作権表示および本使用許諾条件を、本ドキュメントの全部または一部を複製したものに表示してください。
２．本ドキュメントを使用したサービスの提供を含め営利目的に本ドキュメントを使用することができますが、本ドキュメントのみを単独で販売することはできません。
３．第４項に定める場合を除き、本ドキュメントを使用したサービスの提供に際して、事前の書面による当機構の許可なく、それらの宣伝、広告活動に当機構の名称を使用することはできません。
４．本ドキュメントを使用して得られた結果を、形態を問わず、出版、発表において公表する場合には、本ドキュメントと当機構の名称を引用等において明示してください。
５．本ドキュメントは現状有姿で提供されるものであり、当機構は、本ドキュメントに関して、商品性および特定目的への適合性、エラー・バグ等の不具合のないこと、第三者の特許権、実用新案権、意匠権、商標権、著作権その他の知的財産権を侵害するものではないことを含め、明示たると黙示たるとを問わず、一切の保証を行わないものとします。また、当機構は、本ドキュメントの誤りの修正その他いかなる保守についても義務を負うものではありません。
６．当機構は、本ドキュメントの使用または使用不能、複製、頒布、その他本ドキュメントまたは本使用許諾条件の規定に関連して生じたいかなる損害(特別損害、間接損害、逸失利益を含みます
が、これに限りません)または第三者からのいかなる請求についても、法律上の根拠を問わず一切責任を負いません。当機構がかかる損害または請求の可能性について知らされていた場合も同様とします。
７．本ドキュメントは、一般事務用、家庭用、通常の産業用等の一般的用途を想定して作成されているものであり、原子力施設における核反応制御、航空機自動飛行制御、航空交通管制、大量輸送システムにおける運行制御、生命維持のための医療用機器、兵器システムにおけるミサイル発射制御など、極めて高度な安全性が要求され、仮に当該安全性が確保されない場合、直接生命・身体に対する重大な危険性を伴う用途(以下「ハイセイフティ用途」という)を想定して作成されたものではなく、当該ハイセイフティ用途に要する安全性を確保する措置を施すことなく、本ドキ
ユメントを使用しないものとします。また、ハイセイフティ用途に本ドキュメントを使用したことにより発生する、いかなる請求または損害賠償に対しても当機構は一切の責任を負わないもの
とします。

目次
第 1 章

概要 .................................................................................. 11.1.

本仕様書の位置づけ............................................................................................................................................ 11.2.

本仕様書の構成 .................................................................................................................................................. 2

1.3.

水道情報活用システムの導入背景と概要 ............................................................................................................. 3

1.3.1.

水道事業体の課題 ...................................................................................................................................... 3

1.3.2.

水道情報活用システムに期待される効果 ..................................................................................................... 4

1.3.3.

水道情報活用システムの全体像 .................................................................................................................. 9

1.4.

説明の前提........................................................................................................................................................ 10

1.4.1.

水道情報活用システムの基本構成 ............................................................................................................. 10

1.4.2.

対象読者と役割 ......................................................................................................................................... 11

第 2 章

コンセプト編 ..................................................................... 12

2.1.
2.1.1.

アーキテクチャ設計への要求事項....................................................................................................................... 13＜観点Ａ＞ クラウド活用のメリットが発揮できること .................................................................................... 13
要求事項Ａ－① テナントによる影響分離 ........................................................................................... 15
要求事項Ａ－② 処理負荷の増減に対する性能安定確保................................................................... 16
要求事項Ａ－③－１ デプロイの容易化による導入・運用負荷の軽減 .................................................. 17
要求事項Ａ－③－２ 長期・大量データの蓄積 .................................................................................... 18
要求事項Ａ－④ クラウド標準サービスの活用による運用負荷削減..................................................... 18

2.1.2.

＜観点Ｂ＞ 従来型システムの課題が解決されていること ........................................................................... 19
従来型システムの主な課題と要求事項の整理 .................................................................................... 19
要求事項Ｂ－① サービス型への転換（マイクロサービス化） ............................................................... 21
要求事項Ｂ－② 機能およびサービスの共通化・集約化...................................................................... 22
要求事項Ｂ－③ オープンな仕様・技術の採用（データアクセス、データ蓄積） ....................................... 22

2.1.3.

＜観点Ｃ＞ 従来型システムでできることが継承されていること.................................................................... 24
要求事項Ｃ－① 可用性： 事業体毎に異なる要求レベルへの対応 .................................................... 25
要求事項Ｃ－② 運用・保守性： 不具合の特定と対処の情報集約 ..................................................... 26
要求事項Ｃ－④ 性能・拡張性： 上り監視および下り制御の応答安定 ................................................ 27
要求事項Ｃ－⑤ セキュリティ： プラットフォーム型システムにおけるセキュリティ確保 .......................... 29

2.1.4.
2.2.

要求事項のまとめ ...................................................................................................................................... 30
アーキテクチャ設計のコンセプト .......................................................................................................................... 32

2.2.1.

水道標準プラットフォームの構成概要 ......................................................................................................... 32

2.2.2.

共通テナントの構成 ................................................................................................................................... 33

2.2.1.

事業体テナントの構成 ................................................................................................................................ 34

2.2.2.

アーキテクチャの全体像............................................................................................................................. 36

2.2.3.

コンテナの活用について............................................................................................................................. 37
コンテナ技術のメリットとデメリット ....................................................................................................... 37
プラットフォーム提供機能に対するコンテナ技術の利用について .......................................................... 39
ベンダーアプリケーションでのコンテナ技術の利用について ................................................................. 41

2.2.4.

システム標準仕様書との関連について ....................................................................................................... 42

第 3 章

カタログ編 ....................................................................... 44

3.1.

プラットフォームサービスの概要（構成） ............................................................................................................... 45

3.2.

プラットフォーム内のサービス概要とカタログ ....................................................................................................... 47

3.2.1.

共通テナント .............................................................................................................................................. 47

3.2.2.

事業体テナント .......................................................................................................................................... 49

3.2.3.

ベンダーテナント ........................................................................................................................................ 51

3.2.4.

試験テナント .............................................................................................................................................. 52

3.2.5.

セキュリティパーツ ..................................................................................................................................... 55

3.2.6.

その他支援サービス .................................................................................................................................. 58

3.2.7.

テナント共通項目： 冗長化構成 ................................................................................................................. 59
バックアップ構成................................................................................................................................ 59
ホットスタンバイ構成 .......................................................................................................................... 59
デュアル構成 .................................................................................................................................... 60
ディザスターリカバリー構成................................................................................................................ 60

3.3.

想定するアプリケーションイメージ ....................................................................................................................... 62

3.3.1.

浄水場・遠隔監視制御業務アプリケーション（例１） ...................................................................................... 62

3.3.2.

浄水場・遠隔監視制御業務アプリケーション（例２） ...................................................................................... 63

3.3.3.

水運用需要予測業務アプリケーション ......................................................................................................... 63

3.3.4.

アセットマネジメント（施設統廃合）アプリケーション ...................................................................................... 64

3.3.5.

施設台帳アプリケーション .......................................................................................................................... 65

第 4 章

プロセス編 ....................................................................... 67

4.1.

プラットフォームの提供の仕方 ............................................................................................................................ 68

4.2.

想定するプロセスについて.................................................................................................................................. 68

4.3.

各プロセスの概要 .............................................................................................................................................. 69

4.3.1.

計画プロセス ............................................................................................................................................. 69

4.3.2.

導入プロセス ............................................................................................................................................. 71

4.3.3.

運用保守プロセス ...................................................................................................................................... 72

第1章

概要

1.1. 本仕様書の位置づけ
水道情報活用システムの標準仕様に関わるドキュメント体系を図 1.1-1 に示す。リファレンスアーキテクチャ仕様書（以下、本仕様書）は、「調達仕様書案」にて調達対象となる水道標準プラットフォームの内容を具体化するために、水道標準プラットフォー
ムの設計コンセプト、サービスメニュー、導入・保守プロセスを記載したドキュメントである。

導入の手引き案

水道事業体の職員が水道情報活用システムの意義を適切に理解し導入を検討できるよう、システムの概要、コスト削減などの効果、業務の変革イメージ、移行方法などを説明

調達仕様書案

水道事業体の職員が水道情報活用システムを調達する際の仕様書のひな形として提供

本仕様書
リファレンスアーキテクチャ
仕様書案

システム標準仕様書

サンプル設計書
サンプルソースコード

水道事業体の職員やベンダーに向けて、水道標準プラット
フォームの設計コンセプト、提供するサービス、および、導入・保守のプロセスを説明

水道標準プラットフォームの社会実装に向け、データ流通の要点である標準インターフェースを中心に各種の通信仕様を規定

システム標準仕様書に従ってデータ流通の処理を実装できることを示すため、データ送受信に関連する一部機能について、サンプルの設計書およびソースコードを提供。

図 1.1-1 水道情報活用システムの標準仕様に関わるドキュメント体系

1 / 72

1.2. 本仕様書の構成
本仕様書は以下の３編から構成される。

（１）コンセプト編
水道標準プラットフォームのアーキテクチャ設計に対する要求事項、および、設計のコンセプトを説明（２）カタログ編
水道標準プラットフォームが提供するサービスメニューを説明（３）プロセス編
水道情報活用システム整備に関する計画から導入、保守に至るプロセスを説明

2 / 72

1.3. 水道情報活用システムの導入背景と概要
1.3.1. 水道事業体の課題
我が国の水道事業は、｢施設･設備の老朽化｣、｢人口減少に伴う需要減｣、｢職員の高齢化に伴う技術継承｣など、複数の経営課題に直面しており、国民生活を支える基本サービスとしての抜本的な取り組みが求められている。この状況に対し、2018 年の水道法改正においては、都道府県や複数事業体との ｢広域連携｣、水道施設台帳の整備やアセットマネジ
メントの導入による｢適切な資産管理｣、PFI やコンセッション方式等による ｢官民連携｣などを推進することとなっており、現状の「改善」ではなく、事業経営の在り方を大きく見直す「変革」によって現状を打開することが、水道事業が目指すべき将来的な方向性として示されている（図 1.3-1）。

図 1.3-1 水道事業における現状の課題と取り組みの方向性

このように、少子高齢化や設備の老朽化が進み、特に小規模事業体における事業運営が困難になりつつあるなかで、現状の打開策として広域化を進める必要があり、プラットフォームの活用がその促進力になる。具体的には、情報通信分野では、センサ技術やビッグデータ･AI 技術、クラウドサービス、高速通信網の拡大など、目覚ましい発展や進化を遂げており、現実社会で新たな価値を生み出す ｢サイバーフィジカルシステム(CPS)｣ や ｢インターネットオブシングス(IoT)｣ によるイノベーションが加速し、近年さまざまな業種･業界において、技術基盤や新しいサービス提供等、急速に進化を遂げている。そして、このようなテクノロジーを活用し、ビジネスプロセスを再構築する「トランスフォーメーション(DX)」により、事業経営の「変革」を図る動きが世界的な動向となっている（図 1.3-2）。

3 / 72

社会動向

水道事業が抱える課題

・少子高齢化・人口減少
・インフラ設備老朽化

取り組みの方向性

広域連携・職員数の減少＆ノベテラン職員の高齢化
・給水収入の減少＆設備の最適化
・老朽化設備の維持保守コスト増加

少ない職員で高いサービス水準を維持した運営
統合・再配置による設備のダウンサイジング

CPS/IoTプラットフォーム活用により水道事業のスマート化を図ることで広域化を促進【現状】
・管理方法や運用方法は事業体、浄水場ごとに様々
・現場職員によって高水準サービスが維持されている
浄水場
職員 ベテラン 現場
職員 作業者

（管理
者）

給水収入

【CPS/IoTによるプラットフォーム活用の将来イメージ】・給水人口規模に応じた最適な設備更新、業務効率化を実現
広域管理
職員

浄水場

・・・

設備老朽化

職員 ベテラン 現場
職員 作業者（管理者）（統合管理者）

フィードバック（計画、サービス）

ベテラン
職員

情報・データ

資産とデータを
総動員して
最適化

浄水場
現場作業者

職員減・高齢化

アセット
マネジメントCPS/IoT

浄水場

・・・

直営

現場作業者

民間委託

フィードバック（現場支援、制御）

ノウハウ蓄積故障予知

CBM型保守

出所：第１回 水道CPS/IoT検討委員会 平成28年度実証内容を編集

図 1.3-2 水道分野における CPS/IoT プラットフォームの活用

上記の状況を受けて、経済産業省及び NEDO（国立研究開発法人新エネルギー・産業技術総合開発機構）において「IoT を活用した新産業モデル創出基盤事業／水道 IoT の社会実装推進に向けた検討」事業（2017 年度～2018 年度）
等により、水道事業における各種情報活用の効率化等を目的として、「水道情報活用システム」、および、その情報流通基盤となる「水道標準プラットフォーム」の検討が進められている。
現在の水道事業の運用業務は、各水道事業体および各浄水場等の施設ごとに様々であり、各現場の高スキルな職員のノウハウおよび電話等による人的連携により高水準サービスが維持されている状況である。このような状況に対し、水道情報活用システムを利用することで、現場の情報を収集して統合管理し、全体最適な計画立案を早いサイクルで可能となり、これらの情報を現場にフィードバックすることで業務運用の効率化が期待される。さらに、水道標準プラット
フォームを継続的に活用して情報やデータを蓄積することにより、アセットマネジメントや予防型保守などの取り組み
が可能となり、施設統廃合によるダウンサイジングや水道事業体の広域化を実現して、水道事業体経営の「変革」を図ることが期待されている。

1.3.2. 水道情報活用システムに期待される効果
水道情報活用システムに期待される効果として以下の点が挙げられる。

■ポイント１：

共同利用・割り勘で低コストへ



システムの共有による割り勘効果



ベンダーロックインから外れることで、コスト低減の可能性

アプリケーションにも競争が生まれ、選択権が水道事業者側に

4 / 72

■ポイント２：

サービスやシステムを選択

必要な機能やセキュリティやコスト、必要期間を考慮し、最適な機能やサービスが選べる

各種アプリケーションや機能は、競争環境にあり、最適な価格で購入できる■ポイント３：

システム投資（資本的支出）でなく、毎年の利用料負担（費用計上）に初期投資ではなく、サービス利用の形により費用負担を平均化。

水道標準プラットフォームを導入し、共通のシステムを使うことにより、事業体内や広域化連携でのメリットを最大化することが期待される。
広域化を実施し、水道標準プラットフォームを導入した場合に期待される各効果について、以下で具体的に説明する。

■ポイント１：

共同利用・割り勘で低コストへ

水道標準プラットフォームを利用することで、システムの共有化が行われ、遠隔監視および中央の広域センターで集中監視することで、事業体内もしくは事業体同士の施設の共同利用の加速、つまり、システムのダウンサイジングにより負担が軽減される。また、管理の一体化の加速、つまり、事業体内、事業体同士の連携による管理業務の一体化などが進むことが期待できる。具体的には以下のような効果が得られると考えられる（図 1.3-3）。

効果１：システムの集約化により、人員配置が最適化
効果２：システムの集約化により、業務の包括委託（監視業務やデータ入力業務）が促進
効果３：広域化における中核事業体による小規模事業体への支援が可能に

広域化前

広域化後
広域
アプリケーション・監視・水質モニタ■事業体毎のシステム整備活用
A事業体(中核都市）
a中央監視室広域センターCPSプラットホーム
水道標準プラットフォーム

B事業体
（中規模）

（小規模事業体）

b中央監視室c中央監視室 d中央監視室

C事業体

広域
台帳関係ｼｽﾃﾑ

D事業体（小規模事業体）

A事業体(中核都市）

B事業体（中規模）

a中央監視室b中央監視室

C事業体（小規模事業体）

D事業体（小規模事業体）

c中央監視室 d中央監視室(人で監視)
・水質/運転監視・配水制御・水質モニタ・運転監視S

自前

委託

a庁舎

b庁舎

・台帳ｼｽﾃﾑ・台帳ｼｽﾃﾑ

・配水制御

・監視ｼｽﾃﾑ

委託
c庁舎

・配水制御

監視業務包括委託

自前
a庁舎

d庁舎

b庁舎

c庁舎

台帳データ入力の共同包括委託

図 1.3-3 水道標準プラットフォームによる共有化でのコスト低減

5 / 72d庁舎

■ポイント２：

サービスやシステムを選択

現状では、施設ごとに個別に業務内容を定め、システムも個別構築であるため、一度決めた方式からの変更は、個別に、改造や仕様検討が必要となり時間・手間がかかり、既存のベンダーしか対応できない。一方、プラットフォー
ムの活用をすることで、必要な機能やセキュリティやコスト、必要期間を考慮し、最適な機能やサービスが選べるよ
うになることが期待される。それにより、各種アプリケーションや機能は、競争環境に、最適な価格で購入できるよ
うになるとともに、必要となる機能が必要な分だけサービスとして購入可能となる。（図 1.3-4）

現状（個別構築）

将来（水道標準プラットフォーム利用）

重要な施設

通常の施設

見ていなかっ
た施設

Ａ社構築

Ｂ社構築

×：なし

高セキュリティ

高セキュリティ

高機能・
高完全性

重要な施設

通常の施設

見ていなかった施設

水道標準プラットフォーム

高セキュリ
ティ・機能・完
全性

高機能・
高完全性

中程度のセ
キュリティ・機能・完全性

最低限のセキュリティ
・機能・完全性

図 1.3-4 サービスやシステムの選択による効果■ポイント３：

システム投資（資本的支出）でなく、毎年の利用料負担（費用計上）に

従来システムの導入（オンプレ型）においては、償却期間（15 年間）の利用が大前提であり、広域化プロセスにおいて、「短期間だけ使いたい」「設備統廃合で監視箇所が少なくなる」「監視内容・点数が変わるのに」といった事
情に対応した、システム導入の選択は困難な状況である。
一方、水道標準プラットフォームはクラウドサービス上で構築される。そのためサービス形式での利用も可能となるため需要（事業規模、期間）に応じた柔軟な利用が可能になる。また、ゲートウェイも設定を変更すれば、再利用可能である。よって、広域化の進展による監視箇所増にも対応可能となる。（図 1.3-5）

6 / 72

現状（個別構築）
導入

監視システム(センサ100台分)

償却期間 １５年
更新

将来（水道標準プラットフォーム利用）契約

監視システム
(最初はセンサ100台分、
その後段階縮小)

施設の統廃合等、ダウンサイジングの進展に応じて、システム経費の削減が可能

変更

変更
解約

図 1.3-5 システム投資からサービス利用への移行

プラットフォームの導入にあたり、現状では、ベンダー各社で接続仕様が異なるため、アプリケーションを利用する
場合は、ベンダー毎の接続仕様を意識した作りこみが必要である。プラットフォームの実現にあたっては、アプリケー
ションと現場機器が疎結合となるよう、「データ流通のルール」を定める。このルールに則してデータのやり取りを行うことで変更に容易に対応できる、ベンダーに依存しない、オープンで公平性のある社会を目指す（図 1.3-6）。

図 1.3-6 標準仕様でのルール化

7 / 72

標準仕様の策定により、標準インターフェイスによる各種ベンダー間の接続コストが低減され、また、CPS や AI のコ
ンセプトを実現可能なデータ流通および蓄積が可能となることが期待される。
また、ベンダーの変更については、データ移行も課題となっている。そのため、プラットフォームには、各種事業体のデータが保持され蓄積される構造とする。プラットフォームには標準インターフェイスがあり、アプリケーション（ベンダー）を変更する場合の移行作業や移行コストが軽減される（図 1.3-7）。

従来型

プラットフォーム型

Ａ社

Ｂ社

Ｃ社

台帳アプリ

台帳アプリ

台帳アプリ

A事業体の
台帳データ

B事業体の
台帳データ

Ｃ事業体の
台帳データ

Ａ社

Ｂ社

Ｃ社

台帳アプリ

台帳アプリ

台帳アプリ
台帳アプリ

C事業体の
台帳データ

B事業体の
台帳データ

A事業体の
台帳データ

プラットフォーム

広域連携

広域連携

Ａ社
台帳アプリ

Ａ社

データ形式の変換
移管・移行コストが発生

標準IFにて接続！
移行・変換コスト発
生せず

台帳アプリ

A事業体の
台帳データ
Ｂ事業体の
台帳データ

B事業体の
台帳データ

A事業体の
台帳データ

Ｃ事業体の
台帳データ

C事業体の
台帳データ

プラットフォーム

図 1.3-7 広域連携に向けたプラットフォーム内でのデータ保持方針について事業体にアプリケーションの選択権をより強く実施できる環境に移行するべく、従来型の業務個別での多くの機能の塊としてシステム提供を受けていた形態から、事業体のニーズに合わせた「フラクタルなアプリケーション」をする形態を目指し、様々なベンダーから必要な分だけ商品入手が可能な環境とする。

データの扱いと共に、事業体がアプリケーションをプラットフォームで選択して利用できる点も重要である。事業体にアプリケーションの選択権をより強く実施できる環境に移行するべく、従来型の業務個別での多くの機能の塊としてシステム提供を受けていた形態から、事業体のニーズに合わせた「フラクタルなアプリケーション」をする形態を目指し、様々なベンダーから必要な分だけ商品入手が可能な環境とする。（図 1.3-8）

8 / 72

従来

これから

ユーザー
個別でシステムへアクセス

AP領域

監視
制御

水質

水
運用

固定
資産
管理

会計

×

点検
記録

ワンストップで各システムへアクセス

プラット
フォーム

漏水
管理

データ
ベース

×

標
準
IF

標
準
IF

独自
IF

独自
IF

データ
ベース

漏水
管理

管網
GIS

アセッ
ト

不要

必要な機能を必要なだけ提供可能×

個別で多数の機能を一元定期に提供
独自
IF

水質
漏水
予測

監視
制御

管網
GIS

給水
台帳

データ
ベース

×

標
準
IF

標
準
IF

標
準
IF

事業体データベース
一元化！漏れなくダブりなし

システム個別でデータベースを保持

図 1.3-8 アプリケーションの選択利用のイメージ

1.3.3. 水道情報活用システムの全体像
以上を踏まえ、水道情報活用システムの全体像を図 1.3-9 に示す。水道標準プラットフォームは標準仕様に従ったインターフェイスを備え、各事業体へのデータへのアクセス機能を、各社のアプリケーションやゲートウェイに提供する。このような構成により、事業体の利用者はアプリケーションをサービスとして選択し、必要なものを必要な期間だけ利用することが可能となる。（図 1.3-9）
Ａ社
アプリケーション

業務委託業者

広域
事業体

庁舎
浄水場

台帳
会計
監視
制御

場外業務

監視制御 需要予測
ＡＰ
ＡＰ

利用
許可

単独
事業体

Ｂ社
アプリケーション

台帳
ＡＰ

会計
ＡＰ

アクセス

水質監視 需要予測
ＡＰ
ＡＰ

台帳
ＡＰ

会計
ＡＰ

監視制御 需要予測
ＡＰ
ＡＰ

台帳
ＡＰ

会計
ＡＰ

事業体の許可で必要なデータは
自由に連携

標準API
A事業体 B事業体
B事業体
データ
データ
データ

水道標準プラットフォーム

広域事業体
広域事業体
広域事業体
データ
データ
データ

各社コンテンツ
アクセス制御

監視
制御

標準IF

ＧＷ
設置
既存
設備
改造

プラット
ホーム
に集約
する機能

データセキュリティ

ログイン
ID認証

データ
セキュリティ

Ｃ社
アプリケーション

IoT
GW

IoT
GW

既存SCADA既存SCADA

データセキュリティ

Ｂ事業体
監視システム

システム
GW

システム
GW

新SCADA

Ｃ事業体
監視システム

料金
データ

Ａ事業体
事務系システム

台帳
データ

料金
データ

Ｂ事業体
事務系システム

図 1.3-9 水道情報活用システムの全体像

9 / 72

データを保持し、誰にどのデータが流通しているのかの
管理機能

課金管理
使っている内容

台帳
データ

Ａ事業体
監視システムコールセンターシステム障害時の問合せ対応

必要な機能が動くためのサーバ，ＯＳ
等の資源

セキュリティの機能

1.4. 説明の前提
1.4.1. 水道情報活用システムの基本構成
本節では、説明の前提情報として、水道情報活用システムを構成する各基本要素について説明を行う。水道情報活用システムシステムは下図の通り 3 層より構成される。

アプリケーション

プラットフォーム

ゲートウェイ

図 1.4-1 水道情報活用システムの構成■アプリケーション
アプリケーションは、水道標準プラットフォームの利用者に各種業務サービスを提供する。プラットフォームが提供するデータと機能を利用し、付加価値の高いサービスを事業体に提供する。提供サービスとして、以下のようなアプリ
ケーションを想定している。

 運転監視アプリケーション
 運転制御アプリケーション
 需要予測アプリケーション
 台帳管理アプリケーション
 アセットマネジメントアプリケーション
 その他 AI などの技術を活用したアプリケーション■プラットフォーム
プラットフォームは、標準インターフェイスに則してデバイス/システムのデータを流通させ、蓄積をする。また共通的な機能を配置し、水道情報活用システムにおけるサービスプラットフォームの役割を担う。

10 / 72

■ゲートウェイ
ゲートウェイは、デバイス/システムのデータを水道標準プラットフォームに送信するための中継機能を担うサブシス
テムである。ゲートウェイには以下の 2 種類があり、それぞれの役割を以下に示す。

(1) IoT ゲートウェイ
IoT ゲートウェイは、現地施設や現地設備に繋がっているデバイス(PLC、SCADA 等)のデータを水道標準プラットフ
ォームにデータ通信するための中継する役割を担う。デバイスなど現場のデータを収集し、水道標準プラットフォームとデータを送受信する。なお一定時間データを蓄積する機能を想定する。

(2) システムゲートウェイ
システムゲートウェイは、水道事業における既存システム(台帳、料金システム、会計システム 等)のデータを水道
標準プラットフォームにデータ送信するための役割を担う。既存システムのデータを定期的に収集し、水道標準プ
ラットフォームにデータを送信する。

1.4.2. 対象読者と役割
本書の対象読者と役割を以下に示す。

① 水道事業体
水道情報活用システム上のアプリケーションやゲートウェイを利用して水道業務に関連したデータ処理・データ活用のサービスを享受するもの。

② アプリケーションベンダー
水道情報活用システム上のアプリケーションを開発もしくは提供し、水道事業体が実施する水道業務のデータを活用に関したサービスを事業体に提供するもの。

③ ゲートウェイベンダー
水道情報活用システムに接続するIoTゲートウェイ、もしくは、システムゲートウェイを開発もしくは提供し、水道事業に関する現場設備等のデータを水道標準プラットフォームへ流通する機器を提供するもの。

④ プラットフォーマー
水道情報活用システム上の水道標準プラットフォームを構築提供し、上記②，③のベンダーの様々なソリューション・アプリケーションを実装して、情報システムサービスとして提供・運営するもの。

11 / 72

第2章

コンセプト編

本編では、水道標準プラットフォームのアーキテクチャ設計に対する要求事項、および、設計のコンセプトを説明する

リファレンスアーキテクチャ仕様書
コンセプト編
水道標準プラットフォームのアーキテクチャ設計に対する要求事項、および、設計のコンセプトを説明

カタログ編

プロセス編

水道標準プラットフォームが提供するサービスメニューを説明

水道情報活用システム整備に関する計画から導入、保守に至るプロセスを説明

12 / 72

2.1. アーキテクチャ設計への要求事項
水道情報活用システムを実現するにあたり、本項では、水道標準プラットフォームのアーキテクチャ設計に要求すべき事項を、以下の３つの観点で洗い出し、アーキテクチャ設計の前提情報とする。（図 2.1-1）＜観点Ａ＞ クラウド活用のメリットが発揮できること。
＜観点Ｂ＞ 従来型システムの課題が解決されていること。
＜観点Ｃ＞ 従来型システムでできることが継承されていること。

従来型
監視制御系
監視制御
監視制御
アプリケーション
監視制御
アプリケーション
アプリケーション
データベース
データベース
データベース

業務系（台帳）
台帳
台帳
台帳
アプリケーション
アプリケーション
アプリケーション

解決型
観点Ａ
クラウド活用のメリット発揮

監視制御
監視制御
アプリケー
監視制御
アプリケー
ション
アプリケー
ション
ション

台帳
台帳
アプリケー
台帳
アプリケー
ション
アプリケー
ション
ション

料金
料金
アプリケー
料金
アプリケー
ション
アプリケー
ション
ション

標準API-IoT
標準API

データベース
データベース
データベース

データ蓄積-IoT
ﾃﾞｰﾀ蓄積DCS
DCS（テレメータ
DCS（テレメータテレコントロー（テレメータテレコントロール）
テレコントロー
ル）
ル）

PLC
PLC
PLC
浄水場
浄水場
浄水場

業務系（料金）観点Ｂ
従来型の課題解決

標準API-IoT
標準API

料金
料金
料金
アプリケーション
アプリケーション
アプリケーション

GW
IoTGW
GW

IoTGW
IoTGW
GW

データベース
データベース
データベース

PLC
PLC
PLC

既存システム既存システム既存システム

観点Ｃ
従来型でできることの継承

浄水場
浄水場
浄水場

図 2.1-1 水道標準プラットフォームへの要求事項の洗い出し観点

2.1.1. ＜観点Ａ＞ クラウド活用のメリットが発揮できること
近年、社会的な情報サービスがクラウド型へ移行しており、最新の便利なＩＣＴ技術などは、クラウド上で提供されることが予想され、水道情報活用システムの実現においては、クラウドサービスの利用が大きな検討要素となる。具体的には、クラウドサービスを利用することにより、それら最新のＩＣＴ技術を逐次取り入れ、かつ、業務量の増減に対応しながらサービスを継続できるようになると期待される。しかしながら、計算機リソースを提供するだけのサービスとしてクラウドを利用した場合、従来型の情報システム(オンプレ型)と大きな変化が無く、性能やコストのメリットが発揮されない場合があるため、注意が必要である。本節では、クラウド化の課題のパターンを分析することで、クラウ
ド活用のメリットを発揮できるようなシステムアーキテクチャへの要求事項を洗い出す。

13 / 72

従来型システムをクラウド化したことによる課題のパターンを表 2.1-1 に示す。

表 2.1-1 従来型システムのクラウド化の課題パターン

項番

観点

内容
回線を複数顧客（ここでは事業体をさす）で共同利用しているＡ－①のが原因で、ある顧客の大量アクセスが、他顧客のシステム応
答速度遅延を発生させてしまう。
性能が出ない従来型のままの条件でシステムをそのままクラウドに構築してＡ－②いるため、不特定多数の利用者がアクセスすると、応答速度遅延が発生してしまう。
「クラウド上の技術」を前提に構築せず、従来型と同じシステ

Ａ－③

ム構成のままクラウド環境（仮想サーバー上）に構築するため、結果安くならない。
安くならないクラウドで標準サービスとして持っているような共通的な機能（人的なもの（監視業務など）含む）を、従来型からそのまま

Ａ－④の形でシステム毎にクラウドに持ってくるため、維持コストが安くならない。
これまで完全に閉じたネットワーク内でのシステム環境をそのＡ－⑤

安全にならない

ままクラウド環境に乗せ換えたため、必要なセキュリティ対策がされておらず、情報漏洩やデータ改ざんが発生。

これらの課題のパターンに対しては、クラウドサービスの特徴を活かしたシステム構築を実施することで解決可能であり、さらに、従来型システムよりも性能面やコスト面でメリットが得られることも多い。上記の課題のパターンに対する具体的な対応策として、システムアーキテクチャへの要求事項を表 2.1-2 に示す。

14 / 72

表 2.1-2 クラウド化の課題パターンへの対応策

項番

Ａ－①

システムアーキテクチャ
内容への要求事項
テナントによる
影響分離

水道事業体毎にテナントを区切る（グループ化する）ことで、水道事業体ごとの利用回線やサーバーリソースを分け、他へのアクセス量の影響を受けないようにすることが可能
スケールが容易というクラウドのメリットを活かし、利用者がＡ－②

スケールアウト対応

増えてもリソースのスケールが可能な仕組みで設計・構築することで対処可能。

Ａ－③－１

デプロイの容易化

コンテナ技術の活用により、デプロイの容易化や瞬時のサービス起動などでリソース効率が上がり、コスト削減が可能。
全データをそのままデータベースに乗せるのではなく、すぐにＡ－③

安価な大容量ストレージ

必要としない過去データは安価なオブジェクトストレージ（蓄

－２

の提供

積用の安い価格のストレージ）に乗せかえる、など、従来のデータ管理方法を見直すことでコスト削減が可能。

Ａ－④

クラウド標準サービスのクラウドが標準サービスとして持っている DNS、DBMS、システム活用による運用負荷削減

監視サービスなどを活用することで運用負荷軽減が可能。

以下、それぞれの対応策について、具体的に説明を行う。

要求事項Ａ－①

テナントによる影響分離

水道標準プラットフォームでは、多数の水道事業体のシステムを同時に稼働させる必要があるが、特定の事業体における通信負荷や処理負荷が、他事業体の業務に影響を発生することは避けなければならず、その対策は、運用ではなくアーキテクチャとして検討を実施しておく必要がある。
その実現手段としては、クラウドサービスとしてある一定の処理リソースを一つの区画として扱う「テナント」という仕組みがあり、事業体のシステムを各テナントに分けて、回線リソースやサーバーリソースを配置し、お互いの影響を分離することが、クラウドのアーキテクチャを利用した解決策となる。また、水道事業体のデータも各テナントに分けて置くことで、データアクセス権の管理が明確になり、セキュリティリスクの低減も可能となる。上記の解決案を具体的に図 2.1-2 に示す。

15 / 72

失敗例

解決策例

顧客Aの大量使用で、共同利用している顧客Ｂの応答速度低下

顧客毎にテナントを区切り、顧客固有の機能のみ、サーバリ
ソースを顧客ごとに分け、他顧客の使用量の影響を受けないようにする。

顧客A

顧客B

回線

顧客Aの大量使用で、共同利用している顧客Ｂの使用可能なリ
ソース量が減り、応答速度低
下顧客A

回線

顧客Aの使用量の影響を受けず、必要な
リソース量を確保でき、応答速度を担保

顧客B

回線

クラウド環境

クラウド
環境

仮想マシン

仮想マシン

仮想マシン

データ蓄積

データ蓄積

データ蓄積

ゲストＯＳ

ゲストＯＳ

ゲストＯＳ

ハイパーバイザー
ホストOS
ハードウェアハイパーバイザー
ホストOS
ハードウェアハイパーバイザー
ホストOS
ハードウェアベンダーテナント

顧客Ａテナント

顧客Ｂテナント

図 2.1-2 テナントによる影響分離

要求事項Ａ－②

処理負荷の増減に対する性能安定確保

次に個別の事業体において、通信処理負荷が増減した場合の対策について説明する。監視制御アプリケーションであれば、通常は一定の監視情報が通信されており、処理負荷の増減は少ない。しかしながら、災害時や回線障害の復旧時
及び機器の異常発生時には、アラームが突発的に発生する場合がある。また、システム系のアプリケーションでは、業
務上の理由により、毎月もしくは毎年の特定の時期にだけ、データ通信やデータ処理が集中して増加することが想定される。このような処理負荷の増減に対し、従来型のシステムではサーバーなどの必要なハードウェアリソースの最大値を見積もり、そのリソースを最大値に合わせた固定で準備していたが、リソースの余剰を多く抱えることとなり、無駄な投資が発生していた。
このような課題に対し、クラウドでは、仮想化技術によってサーバーなどハードウェアリソースの増減が簡単に可能な技術で、スケールが容易に変更できるというクラウドのメリットを活かし、利用者が増えてもリソースのスケールが可能な仕組みで設計・構築することで対処可能となる。具体的にはサーバーの前段にロードバランサーを配置し、必要な分だけサーバー増減を行ってそれらに負荷分散を行うことで応答を担保しつつ、必要十分なリソースのみの利用に抑制することで性能とコストのバランスを取ることができる。

16 / 72

失敗例

解決策例

不特定多数からのアクセスにより応答速度が出なくなるケー
スが発生容易に可能なサーバのスケールアウトとロードバランサーによる負荷分散により応答速度を担保

不特定多数が参加

従来利用者

従来利用者

不特定多数が参加

・・・

・・・

回線

回線
クラウド環境従来型利用者
数で開発しているため利用者が増えた場合に応答
遅延が発生

・・・
Web/AP
サーバ

顧
客
Ａ
シ
ス
テ
ム

クラウド環境ロードバランサー

・・・
Web/AP
サーバ

顧
客
Ａ
シ
ス
テ
ム

・・・

Web/AP
サーバ

必要な分だけ必要な分だけサーバ追加とサーバ追加と
負荷分散で
負荷分散で
応答速度を
応答速度を
担保
担保

・・・
・・・

ロードバランサー

・・・

DBサーバ

・・・

DBサーバ

DBサーバ

顧客Ａテナント

顧客Ａテナント

図 2.1-3 スケールアウト対応

要求事項Ａ－③－１

デプロイの容易化による導入・運用負荷の軽減

前項で述べたようにクラウド環境では、サーバーの増減や新規機能のサーバーの追加が容易であるため、その特性を活かしたシステム構築、運用が期待される。一方で、作業コストを低減するためにはそうしたサーバーの立ち上げ作業（デプロイ）を省力化しておく必要がある。
その解決策として、コンテナ技術を活用し、各種 OS 上での動作が保障されている「コンテナ」により、動作試験を含めたサーバーのデプロイ作業を省力化することが必要となる。また「コンテナ」は仮想マシンとは異なり、ゲスト OS が不要となるため、起動時間の短縮や処理リソースの低減が可能となる。これらはクラウド IaaS サービス（ハードウェア
や OS の費用）の課金を削減することにつながり、省力化とは別のコストメリットが期待できる。

仮想マシンのデメリット
デプロイ作業について仮想サーバ環境上でもAPのインストールとAPの環境
情報設定作業が必要なため従来と変
わらない

ゲストOSが含まれるため、サービス起
動時、ゲストOSの起動も含まれるた
め時間がかかる

コンテナ技術のメリット

仮想マシンのリ
ソース量が大きい

仮想マ
シン

仮想マ
シン

仮想マ
シン

仮想マ
シン

AP

AP

AP

AP

AP環境
情報
ゲスト
ＯＳ

AP環境
情報
ゲスト
ＯＳ

AP環境
情報
ゲスト
ＯＳ

AP環境
情報
ゲスト
ＯＳ

・・・

コンテナがAPとAP
環境情報をセットに記憶できるため、コンテナを立ち上げだ
けでデプロイが終了⇓より少ない作業工数（人件費）

コンテナ

ゲストOSが不要なためサービス起動時間が非常に速い⇓
より短いリソース課
金時間

コンテナ

コンテナ

AP

AP

AP環境
情報

AP環境
情報

コンテナのリソース量が仮想マシンより小さい⇓
より少ないリソース
量での課金

・・・

AP

AP

AP環境
情報

AP環境
情報

コンテナエンジン
ホストOS
ハードウェアハイパーバイザー
ホストOS
ハードウェア

図 2.1-4 コンテナ技術によるデプロイの容易化

17 / 72コンテナ

要求事項Ａ－③－２

長期・大量データの蓄積

水道業務に利用するシステムでは、一般的に１０年以上の長期に渡ってシステムを継続利用することが期待され、その間に保存されるデータも大量となる。このデータを活用するために、従来環境を単にそのままクラウドに蓄積システ
ムを構築してしまうことで、ストレージが大量に必要となり、また、データのライフサイクルを考えた運用保守作業も必要となるため、システム維持コストがさがらないという課題が発生する。
この問題に対し、蓄積システムを２つに分け、「すぐに必要としないデータ（過去データなど）」は安価なオブジェ
クトに乗せかえることでコストを削減することが考えられる。具体的には、日々の業務に使うデータについてはデータ
ベースに載せて常時アクセスが可能な状態とするが、業務上、アクセスがほとんど発生しない過去のデータについて
は、クラウドサービスとして提供されていることが多い、アクセス速度は劣るが大容量で安価なオブジェクトストレー
ジを活用する。それにより、過去のデータをデータベースからオブジェクトストレージに退避し、データベースのスト
レージ容量を抑制することで、業務継続とコストのバランスを取ることができる。

失敗例

解決策例

従来と同様の速度でデータ操作が可能

従来と同様の速度でデータ操作が可能

全データ

最新
データ

（最新データ+過去データ）

定期データ退避

データ取り出しに時間がかかるが非常に安価

過去データ

データベース

データベース

オブジェクトストレージ

データベース価格（月額）500円/GB

データベース価格（月額）500円/GB

ストレージ価格（月額）10円/GB

全データ量
50,000GB

最新データ量5,000GB

過去データ量45,000GB価格（月額）
2,500,000円

価格（月額）
450,000円

価格合計（月額）2,950,000円（ー22,050,000円の削減）

価格合計（月額）
25,000,000円

図 2.1-5 オブジェクトストレージによるコスト削減（※金額は某社のサービス価格を活用した事例）

要求事項Ａ－④

クラウド標準サービスの活用による運用負荷削減

クラウドの利用を IaaS（ハードウェアや OS などの部分）の提供と限定してしまった場合、従来型のシステム構築において、共通的な機能（人的なもの（監視業務など）も含む）を従来型からそのまま持ってくるため、維持コストが安くならない場合がある。
クラウドサービスでは、様々なシステムをできるだけ容易に構築・運用を可能とするために、様々な標準サービスが準備されており、これらを活用することで、構築・運用の負荷を低減することができる。具体的には、DNS や NTP など
一般的に使われるサービスや、データベース管理システム（DBMS）や DB サーバーの提供サービス、あるいは、運用負荷の低減につながるシステムの監視サービスが利用可能である。
選定したクラウドサービスの内容を事前に調査し、これらのサービス活用することを前提として、システムや運用の設計を行うことでトータルとしてコストメリットの大きなサービスの提供が可能となる。

18 / 72

クラウドの IaaSだけを利用する場合

クラウドの様々なサービスを活用する場合

クラウド標準サービス活用で運用の負担軽減
顧客A

システムベンダ
従来同様
独自のシ
ステム監
視体制を
整備

独自監視

独自に
DNSを
構築・設
定・保守

構築/保守

独自に
DBMSを構築・保守

Web/AP
サーバ

構築/保守

集約監視
システム
監視サービス

回
線
DNS
顧
客
Ａ
シ
ス
テ
ム

Oracle

DBサーバ

ベンダーが
サービスを
DNS
活用を前提
にしていな
い。

簡単構築

保守作業は
サービスを
利用

postgre
SQL
・・・

クラウド
環境

回
線

設定

DNS

監
視
シ
ス
テ
ム

DBMS
サービス
Oracleクラウド標準サービス例

顧客A

システムベンダなし

システム
監視サービス

クラウド
環境

監
視
シ
ス
テ
ム

クラウド標準サービス例

設定

顧客Ａテナント

Web/AP
サーバ

Oracle

サービス
活用

顧
客
Ａ
シ
ス
テ
ム
サービス

DBサーバ

活用

DNS

DBMS
サービス
OraclepostgreSQL・・・

顧客Ａテナント

図 2.1-6 クラウド標準サービスの活用による運用負荷削減

2.1.2. ＜観点Ｂ＞ 従来型システムの課題が解決されていること
従来型システムの主な課題と要求事項の整理
水道情報活用システムのアーキテクチャ要求事項を洗い出すにあたり、従来型のシステムが持つ課題を明らかにし、その解決策として、要求事項を洗い出すことも一つの有用な方法である。そうして得られた要求事項を踏まえて設計することにより、従来型システムのデメリットを解消し、各種のメリットを得られると期待できる。
従来型のシステムでは、各施設に専用のハードウェアにより個別にシステムが構築されており、主に以下の表 2.1-3
ような課題がある。

19 / 72

表 2.1-3 従来型システムの主な課題

項番

課題

内容
・15 年スパンで来る巨額な投資でダウンサイジング対応が難しい

Ｂ－①

更新スパンが長い(投資が無駄になる）
・広域化に対するシステム更新変更(統廃合）が難しい

Ｂ－②

事業体職員の負担が高い

・多くの IT システム維持管理稼働やベンダー対応が発生・システム投資の高止まり
Ｂ－③

ベンダーロックインの弊害

・ベンダースイッチ時の多大な労力・広域化に対するシステム更新変更(統廃合）が難しい

Ｂ－④

AI 等の活用や分析が難しい

・長期蓄積されたデータがない

これらの課題により、従来型の情報システムが、人口減少によるシステムのダウンサイジング、広域化によるシステム
統合、などに向けた障害となっている。以上に示したような課題の解決イメージを図 2.1 7 に、および、具体的に洗い出されたシステムアーキテクチャへの要求事項を表 2.1 4 に、それぞれ示す。

業務
検討

経営
視点

注力すべき内容に
注力
システムが
多数

更新スパンがながい

競争性のある入
札が難しい

AI等のための蓄積データない

監
視
制
御
Ａ
Ｐ

認
証

マ
ッ
ピ
ン
グ
Ａ
Ｐ

Ｉ
Ｄ
管
理

監視制御
DB

ハ
ー
ド物
ウ理
ェ
ア

標準仕様
書
マッピ
ング
AP

標準
API

コンテナ

マッピングDB

ヒストリ
カルデー
タ

標準
IF

事業体テナント
マ
Ｉ
ス
認
Ｄ
タ
証
管
管
理
コンテナ
理
事業体テナント
共通テナント
監視
制御
AP

Ｉ
Ｄ
管
理

認
証

一元的に
管理

仕様がオープンでベンダが選べる

標準
標準
API
IF
監視制御
DB

水道情報活用システム

クラウド基盤

マッピン
グDB

ハ
ー
ド物
ウ理
ェ
ア

PLC/DCS

技術の刷新・
追加が高額

GW

GW

GW

PLC/DCS

AI
新AP

GW

既存システ
ム

新AP

部分的な技術の刷新・追加

AI

図 2.1-7 水道情報活用システムによる従来型システムの課題解決

20 / 72

表 2.1-4 水道情報活用システムによる従来型システムの課題解決

項番

観点

システムアーキテクチャへの要求事項
クラウドサービス活用により必要な機能のみ提供

Ｂ－①

サービス型への転換（マイクロサービス化）
仮想化技術活用により計算処理リソースの利用を最適化

Ｂ－②

機能・サービスの共通化

共通化できる機能やサービス（運用保守 SE と OP）を集約して、コストを削減水道標準プラットフォーム上でデータ流通を行うためのオープ
ン仕様のインターフェイスを提供

Ｂ－③

オープンな仕様・技術の採用

オープンな技術およびＯＳＳの採用
データ共有の仕組みを提供（データ項目の標準化／共有化、共有データ出力機能）

Ｂ－④

安価な大容量ストレージ

標準的なフォーマットにより安価で長期継続的に蓄積可能なスの提供

トレージサービスの提供（要求事項Ａ－③－２と同じ）

以下、各要求事項の具体的内容を説明する。

要求事項Ｂ－① サービス型への転換（マイクロサービス化）
水道標準プラットフォームにより、各施設に個別に作りこまれた情報システムは、一つのシステムに統合され、かつ、水道情報活用システムのサービスとしてシステムの各種機能を選択して利用できるようになることが望ましい。つ
まり「サービス型への転換」であり、従来型システムという「モノ」の購入・所有・管理から脱却し、利用したい機能だけを利用したいときにだけ利用できるようになる。この「サービス型への転換」を実現することにより、課題Ｂ－①
は根本的に解決される。これを実現するためには、システムの各機能をモジュール化して租結合とし、個別に分離して利用可能とすることが必要である（マイクロサービス化）。また、計算機ハードウェアの仮想化技術を利用し、計算処
理リソースの追加・削除を容易にすることが必要となる（図 2.1-8）。

21 / 72従来型の課題～初期投資型～

解決策～サービス型～

15年という長期スパンでの更新

短期スパンでの必要な部位の更新が可能

・技術やハードウェアの老朽化が進む。
・新技術に追従できず、維持費も高騰したまま。
・データも容易に取り出せず、分析や新技術検討も進まな
い。

AP

認
証

Ｉ
Ｄ
管
理

AP 認
証

Ｉ
Ｄ
管
理

DB

DB

PLC/DCS

PLC/DCS・新しい技術に追従した最適なシステムを維持
・必要最低限のサービスの利用で、維持コストも抑制

AP AI

DB
コンテナ

AP AI

暗
号
化

DB

コンテナ
テナント1

認
証
マ
ス
タ
管
理

Ｉ
Ｄ
管
理

テナント2

クラウド基盤
PLC/DCS

AI
AP

AP

AP

AP

AI

認
証

Ｉ
Ｄ
管
理

AP

認
証

Ｉ
Ｄ
管
理

DB

DB

PLC/DCS

PLC/DCS

AI

AP

AI

・仕様のブラックボックス化
で、技術の刷新・追加が高額に。
・データ出力にも高額な費用
が発生。

AP
DB
コンテナ
AP

IT

暗
号
化

DB

コンテナ
テナント1

テナント2

クラウド基盤OT

PLC/DCS

認
証
マ
ス
タ
管
理

Ｉ
Ｄ
管
理

・IT化（クラウドサービスの活用＋マイクロサービス化）により、短いスパンで新しい仕組みが導入可・ラダーによる機器制御など、
OTにしかできないことはOTで実現

図 2.1-8 初期投資型からサービス型への移行

要求事項Ｂ－② 機能およびサービスの共通化・集約化
各種システムが一つのプラットフォーム上に統合されることで、問合せ窓口の一本化など、システムの維持管理作業も集約・削減され、水道情報活用システムの維持管理についても「サービス型への転換」が図られる。事業体職員やベンダーはこの維持管理サービスを利用することで、維持管理作業の負担削減が期待できる（課題Ｂ－②の解決）。

要求事項Ｂ－③ オープンな仕様・技術の採用（データアクセス、データ蓄積）
従来型システムを水道標準プラットフォーム上に統合する際に、各社の仕様にてシステムが作り込みされており、シ
ステムの統合や、ベンダーの変更が難しいという課題がある。具体的には、アプリケーションと現場の機器が独自の通信仕様で密結合となっており、１対１の関係を持ったシステムが複数併存する形となっている（図 2.1-9 の左側）。こ
の課題に対し、各システムの業務情報を、オープンな標準仕様でデータ流通する仕組みとすることで、その後のシステムの変更や切り替えが容易となる（図 2.1-9 の右側）。

22 / 72

ベンダーロックインの弊害

ア
プ
リ
ケ
ー
シ
ョ
ン

１

Ａ社仕様の世界

Ｂ社仕様の世界

C社仕様の世界

監視制御
アプリケーション
A社製

監視制御
アプリケーション
B社製

監視制御
アプリケーション
C社製

Ａ
社
物
理
接
続
仕
様

B
社
物
理
接
続
仕
様

C
社
物
理
接
続
仕
様

：

浄水施設

現
場
機
器

１

オープンな標準仕様による業界運用

A社製

制御
機器

浄水施設

PLC

B社製

制御
機器

センサ

事業体①

オープンな標準仕様の世界
ア
プ
リ
ケ
ー
シ
ョ
ン

N

センサ

事業体②

C社製

制御
機器

浄水施設

現
場
機
器

PLC

センサ

事業体③

M

A社製

制御
機器

浄水施設

PLC

センサ

事業体①

a.システム投資の高止まり

監視制御
アプリケーション
B社製

監視制御
アプリケーション
C社製

施設統廃合
アプリケーション
D社製

水道標準プラットフォーム(オープンな標準仕様によるデータ流通)

：

浄水施設

PLC

監視制御
アプリケーション
A社製

B社製

浄水施設

PLC

制御
機器

センサ

システム

・天候情報サイト
・カレンダ情報サイト

等

制御
機器

事業体②

外部サービス

PLC

C社製

センサ

事業体③

業界に対しての標準仕様策定と、その仕様を具備した
水道標準プラットフォーム開発提供により、ベンダー
ロックイン解除により左記a,b,c課題を解決

b.ベンダースイッチ時の多大な労力・コスト
c.広域化の施設統廃合に合わせたシステム変更が難しい

図 2.1-9 オープンな標準仕様によるデータ流通の実現

水道標準プラットフォームでは、オープンな標準仕様に従ったインターフェイスを通じて、プラットフォームのデー
タベースにアクセスすることを「システム利用時のルール」として定めることで、アプリケーションをデータベースと租結合とし、自由なデータ流通を実現する。
その際に、データへのアクセス方式だけでなく、データベースに保存されたデータ項目についても、標準的な項目を定め、データ項目を共有する必要がある。そのため、プラットフォームはデータベースのデータ項目（マスタ情報）を登録して共有可能とし、ベンダーにはデータベースのデータ項目を共有することを「システム利用時のルール」として定めることとする。ただし、システム系のアプリケーションでは性能を確保するためにデータベースの構造自体に作り込みが発生することが多い。その場合には、データ項目の共有だけでは不十分なため、共有（および移行）用のデータを別途出力することを「システム利用時のルール」として定める必要がある（図 2.1-10）。
アプリケーション（IoT系）

アプリケーション（システム系）

他社
アプリケーション

標準IF

標準IF

標準IF

標準ＩＦ
マスタ機能

ＮｏＳＱＬ

監視制御ＡＰはデータ構造は時系列で比較的簡易。
→ マスタに項目を登録して共有

マスタのデータ項目でデータアクセス可能

標準データ項目を
簡易な表形式で出力

ＲＤＢ

標準
データ
項目

共有用のデータから
データアクセス可能共有（移行）用のデータ

システム系ＡＰは、RDBにDB構造を各社で独自にチューニン
グが多い。
→ 共有（移行）用に別途データ出力

23 / 72

標準データ
項目

図 2.1-10 複数ベンダーでのデータ共有の仕組み

これにより、水道事業体はコストや技術のメリットに応じて各ベンダーの提供する機能を選択することが比較的容易になる。加えてベンダー間では適正な競争環境が生み出され、サービス改善や技術発展に資することが期待される。
なお、システムの技術要素としてはオープンソースソフトウェアを利用したオープンな技術を積極的に活用すること
で、特定ベンダーへの製品依存を回避できる。

「要求事項Ｂ－④ 安価な大容量ストレージの提供」

については、要求事項Ａ－③－２ と同じであるため、説明を省略する。

2.1.3. ＜観点Ｃ＞ 従来型システムでできることが継承されていること
前項では従来型システムの課題解決の観点で、水道情報活用システムに求められる要求事項の洗い出しを行ったが、併せて、従来型システムのサービスレベルと同等のサービスが、水道情報活用システムにおいても提供されることも、また重要な観点である。
従来型のシステムでは、個別の施設に専用のハードウェアを用意しているために、システム相互に性能の悪影響を及ぼすことや、そもそもセキュリティ的な侵入のリスクが比較的低いと考えられる。一方で、水道標準プラットフォームには多くの様々なシステムが統合され、様々なユーザーが同時利用するため、従来型システムのサービスレベル（非機能要件）が満たされないリスクがある。よって、そのリスクを洗い出し、対応方針をシステムアーキテクチャへの要求事項としてまとめておくことは重要である。
従来型システムで提供している各項目のサービスレベルに対し、水道情報活用システムでの継承が懸念される点、およびその対応方針としてシステムアーキテクチャへの要求事項を表 2.1-5 に示す。なお、非機能要件の項目としては、IPA の「非機能要求グレード 2018」から抽出している。

24 / 72

表 2.1-5 従来型システムからの継承懸念点とシステムアーキテクチャへの要求事項

項番

Ｃ－①

非機能要件
継承懸念点
項目

可用性

システムアーキテクチャへの要求事項

事業体毎に可用性要件が異なることへの対応

運用・保守性ため、サービス毎にサーバーが独立して稼働するため、不具合発生時の発生箇所が追跡しづらくなる。

Ｃ－③

移行性

性能・拡張性

従来の AP/GW/PF の監視機能に加え、データ項目単位でのトラフィック（流通）を監視することで、不具合発生個所を追跡可能とする。
―（観点Ｂでベンダーロックイン解消を議論済）

監視制御において、１秒周期の高速

インメモリ型の KVS（Key-Value Store）による速で求められる監視（上り）を、い応答。

AP/DB/GW が分割された構成での実現

MQTT プロトコルによる軽量データでのやり取り

監視制御において、監視（上り）をＣ－④件（冗長構成や負荷分散など）を個別に提供可能とする。
従来型から AP/DB/GW が分離される

Ｃ－②

事業体毎にテナントとして区切ることで、各種要実施しながら、制御（下り）もリア
ルタイムに行う必要がある

制御用通信と、監視用通信の処理リソースを分離
し、並列に動作させることで実現
複数の AP が同じ DB にアクセスする

インメモリ型の KVS（Key-Value Store）による速中、従来と同様の応答性をどう確保

い応答。

するか

DB のスケールアウトと負荷分散

複数の AP が同じ DB にアクセスする

Ｃ－⑤

セキュリティ

ため、従来型では意識していなかっトークンと証明書による AP の認証認可

た AP 自体の認証認可が必要

上記で挙げられたシステムアーキテクチャへの各要求事項について、以下に説明する。

要求事項Ｃ－①

可用性：

事業体毎に異なる要求レベルへの対応

施設や水道事業体毎に可用性の要件が異なるため、プラットフォームでは、それぞれに対応した冗長構成等を提供
し、それぞれの構成は別々のシステムとして稼働させる必要がある。これを実現するために、観点 A の対策Ａ－①

顧

客別テナントによる影響分離で述べたように、クラウドサービスとしてある一定の処理リソースを一つの区画として扱う「テナント」という仕組みを使って、事業体毎の個別の設定に対応できる。

25 / 72

要求事項Ｃ－②

運用・保守性：

不具合の特定と対処の情報集約

従来型のシステムに対して、プラットフォーム型のシステムでは、アプリケーション、データベース、ゲートウェイが分離され、さらに、複数のベンダーのデータが流通する。そのため、サービス毎にサーバーが独立して稼働し、不具合発生時の発生箇所が追跡しづらくなるという課題がある。
この問題に対し、プラットフォームの各要素（アプリケーションやゲートウェイ）および、そこに流通するデータ項
目に対して ID を割り振り、データの流通をプラットフォームで統一的に監視することで不具合の発生個所を発見できるようにする。例えば、アプリケーションなどの各機能がマイクロサービスとして租結合な状態でシステムが構成されれ
ば、マイクロサービス間のリクエスト・レスポンスの応答結果を残すことが出来るため、不具合発生個所やタイミングを具体的にとらえることが可能となる。
データ流通や機器状態の監視は、プラットフォーム内のサーバーだけに限定するものではなく、ゲートウェイベンダ
ー／通信回線事業者／アプリケーションベンダー／クラウド事業者など、水道情報活用システムの運用保守に関係する各事業者と連携して、ゲートウェイ、通信回線、アプリケーション、IaaS 基盤などから、システム動作状況のログなどを常時収集する。この機能により、プラットフォームとしてシステム動作監視側で一括集約して提供し、プラットフォーム・ベンダーに共有するなどが可能となり、運用作業の集約化、故障発生時の円滑な対応を実現する（図 2.1-11）。

水道事業体
利用者

データが
表示されない回線の一時不通です

復旧しました

円滑な復旧対応

アプリケーションネットワークプラットフォーム

障害発生
通信回線

ゲートウェイ

処理
ログ

通信
ログ

プラットフォーム
受付窓口

動作状態を
すべて集約・共有
水道事業体
回線復旧を
利用者
依頼済です

処理
ログ

プラットフォーム
運用保守ＳＥ

回線
状況

障害発生
動作
ログ

アプリケーションベンダー
運用保守ＳＥ

PLC
ゲートウェイベンダー
運用保守ＳＥ

図 2.1-11 監視情報の集約による運用作業の円滑な対応の実現（１）

水道標準プラットフォームは、複数の水道事業者や複数のベンダーが同時に利用し、保守運用に関係してくることから、複数の異常が同時並行的に発生している状況であっても、異常が発生している箇所を取り違えることなく、確実に関係者に共有し、連携して対応作業を進められる仕組みが必要となる。そのためには、まずシステム全体の動作監視、異常の一覧、各異常の内容について、保守運用の関係者全員が同一の画面で共有し、対応結果を各自で登録できること

26 / 72

が求められる。さらに、各ベンダーのアプリケーション画面に統一した画面番号を割り振り、常時表示させるルールを作ることで、故障発見時に画面番号を登録し、その番号に基づいて状況確認や対応作業を実施することで、実施対象を取り違えることなく、復旧作業を連携して進めることができる（図 2.1-12）。
＜運用保守ＳＥ＞
画面番号

不具合
発生

333

水道事業体
利用者

プラットフォーム
受付窓口

333

333

不具合
発生

不具合
発生

プラットフォーム

アプリケーション
ベンダー

ゲートウェイベンダー

状況確認・対応結果登録

ＡＰ

ＮＷ

ＰＦ

画面番号

333

障害発生

通信
回線

画面番号

333

障害発生

通信
回線

対応完了

障害発生

障害発生

システム動作監視

通信回線

異常一覧

異常内容

＜共有画面＞GW
PLC

図 2.1-12 監視情報の集約による運用作業の円滑な対応の実現（２）要求事項Ｃ－④

性能・拡張性：上り監視および下り制御の応答安定

プラットフォーム型のシステムでは、監視制御において、従来型と同等の性能（１秒周期）で監視（上り）を実施
し、突発的な送信データの増加にも対応して安定的な処理を継続できる必要がある。システム標準仕様書では、大量の処理リソースを消費せずに、IoT ゲートウェイからの受信応答性能を確保するために MQTT プロトコルによる軽量通信を採用している。
まず、「MQTT」とは、ＩｏＴ向けのプロトコルで、軽量なデータサイズで通信が可能なものであり、ＩｏＴのデファ
クトスタンダードとなっている。このプロトコルにより、広域回線の通信負荷を増大させることなく、多数の IoT ゲー
トウェイからのデータ送信処理を実施することができる。
次に、「インメモリ」とは、データをハードディスクなどには書き込まずメモリ上で管理するしくみのことで、非常に高速にデータの読み書きが可能である。また、「KVS」（Key-Value Store）とは、Key と Value を組み合わせる単純な構造からなるデータストアで、シンプルな構成のため高速なデータの読み書きが可能である。「インメモリ KVS」
は、上記を組み合わせた技術であり、受信時のパケットロスを発生させずに、高速なデータ蓄積が可能となる。
これらの技術を組み合わせて、IoT ゲートウェイからデータ蓄積までのデータ送信処理を高速に実現している（図2.1-13）。

27 / 72SCADA画面
アプリケーション

標準API

データ蓄積

イ ン メ モ リK V S

インメモリ型KVS

これら技術を組み合わせて高速な応答を実現

標準IF

MQTT
ゲートウェイ

PLC

図 2.1-13 IoT ゲートウェイからのデータ受信処理の高速化

上記の処理と合わせ、観点 A で示したロードバランサーを使ったスケールアウトの技術を使うことで、監視データの受信処理におけるプラットフォーム型システムの性能・拡張要件を確保している。
監視データの受信処理に並行して、下り通信としての制御処理も同時かつ突発的に発生するが、これらの影響を分離
し、それぞれのレスポンスを確保する必要がある。そのため、それぞれの処理リソースを分離し、制御用通信と監視用
通信を独立させ、並列に動作させることで、監視の大量トラフィックの影響を受けない仕組みとする。

SCADA画面
アプリケーション

標準API（制御用）

標準API（監視用）
水
道
標
準
プ
ラ
ッ
ト
フ
ォ
ー
ム

データ蓄積

標準IF（制御用）

標準IF（監視用）

データ送受信暗号化など

ゲートウェイ

制御用通信と監視用通信を独立させ並列に動作↓
監視の大量トラフィックの影響を受けない仕組みとする

データ送受信暗号化など

PLC

図 2.1-14 監視用処理と制御用処理の分離によるレスポンス確保

28 / 72

要求事項Ｃ－⑤

セキュリティ：プラットフォーム型システムにおけるセキュリティ確保

従来型のシステムでは、個別の施設もしくは個別の水道事業体に向けて、個別のベンダーがシステムを構築していたため、利用者や利用するアプリケーションは限定的であった。しかし、プラットフォーム型のシステムでは、複数のア
プリケーションを複数のユーザーが利用するため、従来型では意識していなかったユーザーだけでなく、アプリケーシ
ョンについても認証認可が必要となる。それにより、ユーザーが利用権限を持つアプリケーションだけにアクセスさせることが可能となる。ユーザーとアプリケーションの認証について、仕組みを図 2.1-15 に示す。

【認証】（最初の１回のみ）【認可】（通信毎）③アプリケーション操作
ユーザー
トークン

アプリケーション①ログイン(システム動作)

APの認証

人の認証

①ログイン
②トークン発行
ユーザー
トークン

ユーザーはログイン
して、トークンを受領後、利用可能なＡ
Ｐ一覧から利用する
ＡＰを選択

通信実行

②トークン
発行
ＡＰ
トークン

ユーザー
トークン
ＡＰ
トークン

認証認可

標準API
データ蓄積

水
道
標
準
プ
ラ
ッ
ト
フ
ォ
ー
ム

ＡＰとＰＦとの通信時に、要求されているデータを操作する権限があるかチェック・・・

図 2.1-15 トークンと証明書による認証認可

それぞれの仕組みは基本的に同じであり、最初のアクセス時に認証を受け、認証の結果である「トークン」の発行を受けて、その後通信ではユーザーのトークンとアプリケーションのトークンで要求されているデータを操作する権限があるかチェックする。
その他、従来型と同様のセキュリティレベルを確保するため、水道事業体のセキュリティポリシーに応じて以下の対策を選択可能とする。

①

閉域網回線の利用②

ファイヤウォールによるアクセス制限③

通信経路の暗号化（HTTPS）④

不正アクセス検知（IPS/IDS）⑤

データの暗号化⑥

認証認可（ユーザー、アプリケーション、ゲートウェイ）⑦

アクセスログの保持⑧

不正アクセス検知・監視（24h365d）

29 / 72これらの対策を踏まえてプラットフォームのセキュリティ対策の全体像を図 2.1-16 に示す。

アプリケーション④不正アクセス検知（IPS/IDS）③通信経路暗号化（HTTP(S))②ファイアウォール
標準API⑧不正アクセス
検知監視
24h365d⑤データ暗号化
⑥認証認可
データ蓄積

⑦アクセス
ログ保持

標準ＩＦ

事
業
体
テ
ナ
ン
ト

⑤データ暗号化②ファイアウォール④不正アクセス検知（IPS/IDS）①閉域網回線

ゲート
ウェイ

ク
ラ
ウ
ド
環
境

③通信経路暗号化（HTTP(S))③データ暗号化

PLC/既存システム 等

図 2.1-16 プラットフォームのセキュリティ対策の全体像

2.1.4. 要求事項のまとめ
前節で洗い出したアーキテクチャ設計への要求事項を、①システム全体構成に関わるもの、②システムの各構成要素に関わるもの、③システムの導入・運用に関わるもの、に分類し、その実現手段についてまとめたものを表 2.1-6 に示す。

30 / 72

表 2.1-6 アーキテクチャ設計への要求事項

種別

内容

#

実現手段

・テナントによる影響分離

①

a

システム
全体構成
に関わる

b
c

要求事項
d

・事業体毎に異なる要求レベルへの対応
サービス型への転換

機能のモジュール化と租結合による（マイクロサービス化）

システム構成機能およびサービスの共通化・集約化

共通化できる機能を集約

オープンな仕様・技術の採用

オープン仕様の標準インターフェイス（標準仕様、データ共有）

および、標準項目でのデータ共有

長期・大量データの蓄積
大容量安価なオブジェクトストレージa
サービス型への転換b②（必要な計算処理リソースだけを利用）c

オープンな仕様・技術の採用（技術面）

d

処理負荷の増減に対する性能安定確保

システムの
各構成要素

プラットフォーム型システムにおけるセキ

Ｂ－①
Ｂ－②
Ｂ－③
Ａ－③－２
Ｂ－④
Ｂ―①

オープンな技術・ＯＳＳの採用

Ｂ－③

サーバー、ＤＢのスケールアウト

Ａ－②（暗号化、閉域化）

インメモリ型の KVS（Key-Value Store）
上り監視および下り制御の応答安定

b

用に関わる

（軽量データでのやり取り）

Ｃ－④

し、並列に動作
デプロイの容易化による導入・運用負荷③

MQTT プロトコル

制御と監視の処理リソースを分離
i

a

Ｃ－⑤

ユーザー、ＡＰ、ＧＷの認証認可

f

h

要求事項

Ｃ－①

処理サーバーの仮想化技術

ュリティ確保g

システム導入・運

Ａ－①

通信、データの秘匿化
e

に関わる
要求事項

テナントによるデータ流通範囲分割

対応項目

の軽減

コンテナ技術クラウド標準サービスの活用による

DNS、システム監視、セキュリティ等

運用負荷の軽減のサービス

c機能およびサービスの共通化・集約化

d

不具合の特定と対処の情報集約

31 / 72

Ａ－③－１

Ａ－④

共通化できる作業の集約（問い合わせ窓口等）
サービス間のトラフィック監視と対応情報の共有の仕組み

B－②

Ｃ－②

2.2. アーキテクチャ設計のコンセプト
本節では、前節で洗い出された水道標準プラットフォームのアーキテクチャへの要求事項を踏まえて、システムのアーキテクチ
ャが備えるべき構成を整理し、アーキテクチャ設計のコンセプトを示す。

2.2.1. 水道標準プラットフォームの構成概要
前節の整理において得られた、「①システム全体構成に関わる要求事項」 から、システムの各機能をモジュール化し、HTTP
REST 通信等により租結合とすること（マイクロサービス化）が求められる。マイクロサービス化を実現することにより、各機能モジ
ュールの配置を比較的自由に変更できるので、「共通化機能の集約」 や 「テナントによる分割」 が可能となる。
共通機能の内容は後術するが、共通的に必要な機能モジュールを共通テナントに集約し、他の事業体固有のデータ蓄積モジ
ュールは、各事業体のテナントに分けて格納することで、「事業体間の影響分離」や「機能集約による維持管理負荷やコストの低減」が可能となる。
各事業体に格納されたデータは、「オープン仕様の標準インターフェイス」によりベンダーテナント（事業体テナント内の事業体
専用のアプリケーション領域も含む）からアクセスする構成とすることで、「ベンダーロックインの解除」を実現する。
上記を踏まえ、水道標準プラットフォームの構成の概要を、図 2.2-1 に示す。

【凡例】

IoT系
アプリ
ケーション

①c 機能およびサービスの共通化・集約化

・・・

システム系
アプリ
ケーション

システム系
アプリ
ケーション

・・・

標準インターフェース

共
通
テ
ナ
ン
ト

共通的
機能群

①a テナント
による
影響分離

事
業
体
テ
ナ
ン
ト

データ蓄積

…

水
道
標
準
プ
ラ
ッ
ト
フ
ォ
ー
ム

IoT系
アプリ
ケーション

【項番】要求事項①d オープンな仕様・技術の採用（標準仕様）

標準インターフェース

共通機能（暗号化、ID管理等）
IaaS基盤、OS、ネットワーク

ゲートウェイゲートウェイゲートウェイゲートウェイゲートウェイゲートウェイ…

…

図 2.2-1 「①システム全体構成に関わる要求項目」 に基づくプラットフォームの構成概要

32 / 72

2.2.2. 共通テナントの構成
前項の構成に対し、本項では、「②システムの各構成要素に関わる要求事項」 および 「③システム導入・運用に関わる要求事項」 を踏まえて、システムアーキテクチャを具体化する。
まず、②と③の要求事項から共通テナントに求められる必要な機能を具体化した結果を図 2.2-2 に示す。

【凡例】
【項番】要求事項

事業体利用者②f セキュリティ
確保（認証認可）②e セキュリティ
確保（暗号化）

ユーザー
インターフェース
暗号化

認証
認可

マスタ
管理

動作
監視

…

②jオープンな仕様・技術の採用（データ共有）

共
通
テ
ナ
ン
ト

オブジェクトストレージ③d 不具合の特定と対処の情報集約③c 機能およびサービスの共通化・集約化③a 長期・大量データの蓄積図 2.2-2 共通テナントに求められる機能構成

図 2.2-2 における「マスタ管理」とは、システムで扱うデータのＩＤを管理する機能であり、データを一意に特定することで、データを共有する際や、サービス間のトラフィックを「動作監視」で監視する際に必要となる。

33 / 72

2.2.1. 事業体テナントの構成
次に、アーキテクチャへの要求事項から事業体テナントに求められる機能構成について、図 2.2-3 に示す。

アプリ
ケーション

アプリ
ケーション

②b 必要の計算処理リソースだけを
利用可能

事
業
体
テ
ナ
ン
ト

アプリ
ケーション

【凡例】 【項番】要求事項

負荷分散装置
監視用
ＩＦ

監視用
ＩＦ

…

制御用
ＩＦ

負荷に応じて追加②d 処理負荷の増減に対する性能安定確保（スケールアウト）② i 上り監視および下り制御
の応答安定

…

NoSQL DB
負荷に応じて追加

インメモリ KVS

負荷に応じて追加

監視用
ＩＦ

監視用
ＩＦ

…

制御用
ＩＦ

②g 上り監視および下り制
御の応答安定(KVS, MQTT)

負荷分散装置②e セキュリティ確保（閉域化、暗号化）
ゲートウェイゲートウェイゲートウェイ…

…

図 2.2-3 事業体テナントに求められる機能構成

事業体テナントでは、アラームの発生等によりデータ量が増加する可能性があり、その処理負荷に応じて、「インターフェイスおよびＤＢのスケールアウト」 により安定したデータ流通が可能となる。併せて、「インメモリ型ＫＶＳ」 や 「ＭＱＴＴ」 等の技術により、高いトラフィック処理性能を確保することができる。また、監視と制御の処理を行うサーバーを分離し、それぞれの応答性を確保する構成としている。
上記の構成では、データベースのスケールアウトを実現するために NoSQL を採用しているが、高いトランザクション性能要件を求められるシステム系のアプリケーションではデータベースとして RDB を利用しており、データベーススキーマは対象のアプリ
ケーション向けにカスタマイズおよびチューニングがされていることが多い。この場合、他のベンダーからは蓄積データにアクセスできずベンダースイッチが阻害される。また、ベンダーの現状のアプリケーション構成では、上記構成に合わせて対応することが難しいことも想定され、その場合、データ移行やデータ流通が阻害されることが想定される。
このような場合に対応し、暫定的に、移行用に共有ファイルを準備することで他社アプリケーションでのデータアクセスを確保しつつ、独自インターフェイスでＤＢアクセスをする構成とする（図 2.2-4）。そして、将来的には、システム系のアプリケーションにお34 / 72

いても標準のインターフェイスに DB アクセスを統一する（図 2.2-5）

【凡例】

台帳AP

マッピングAP

背景
地図

GIS
エンジン

その他ＡＰ

その他ＡＰ

標準IF

標準IF

・・・

標準IF

独自ＩＦ

①d オープンな仕様・技術の採用（標準仕様、データ共有）

マスタ機能
GIS
エンジン

RDB
(台帳情報)【項番】要求事項

空間DB(地図情報)

標準
データ
項目

標準
データ
項目

共有（移行）用のデータ
ShapeFile

標準
データ
項目

CSV

出力

出力

図 2.2-4 事業体テナントに求められる機能構成（水道 GIS 台帳システムを事例したもの／暫定的にＲＤＢへの独自インターフェイスを利用）

【凡例】

台帳AP

マッピングAP

背景地図

GIS
エンジン

標準IF

【項番】要求事項

その他ＡＰ

その他ＡＰ

標準IF

標準IF

・座標系
・投影法

標準IF

標準ＩＦ
データ共有／移行

マスタ機能

RDB
(台帳情報)

標準
データ
項目

空間DB
(地図情報)※DＢとＩＦの機能構成は別途検討①d オープンな仕様・技術の採用（標準仕様、データ共有）

・座標系
・投影法
標準
データ
項目

標準
データ
項目

共有（移行）用のデータ

図 2.2-5 事業体テナントに求められる機能構成（将来的に標準インターフェイスに統一）

35 / 72

2.2.2. アーキテクチャの全体像
以上の機能構成を踏まえて、水道標準プラットフォームのアーキテクチャの全体像は図 2.2-6 のように具体化される。

事業体利用者

水
道
標
準
プ
ラ
ッ
ト
フ
ォ
ー
ム

IoT系
アプリ
ケーション

IoT系
アプリ
ケーション

・・・ システム系
アプリ
ケーション

標準インターフェース
監視

ユーザー
インターフェース

共
通
テ
ナ
ン
ト

認証
認可
マスタ
管理

暗号化
動作
監視

事
業
体
テ
ナ
ン
ト

オブジェクト
ストレージ

監視

…

システム系
アプリ
ケーション

制御

…

ファイル

…

データベースNoSQL DB
共有用
ファイル

標準インターフェース
監視

監視

・・・

RDB

インメモリ KVS

・・・

…

制御

…

ファイル

…

共通機能（暗号化、ID管理等）
IaaS基盤、OS、ネットワーク

ゲートウェイゲートウェイ
IoT
ゲートウェイ…

…
図 2.2-6 システムアーキテクチャ全体像

ゲートウェイゲートウェイシステム
ゲートウェイ（共通テナント、事業体テナント具体化後）

36 / 72

アーキテクチャへの要求事項を、システムスタックとして整理した結果を図 2.2-7 に示す。

【凡例】

アプリケーション③a デプロイの容易化による
導入・運用負荷の軽減

コンテナ
回
線

共通
サービス

【項番】要求事項③b クラウド標準サービスの活用

ＯＳ／ミドルウェア②c オープンな仕様・技術の採用（技術面）

テナント①a テナントによる影響分離

IaaS基盤②bサービス型への転換（必要な計算処理
リソースだけを利用③d 不具合の特定と対処の情報集約図 2.2-7 システムアーキテクチャ全体像（システムスタック）

本システムはクラウドサービスをベースとし、仮想化技術に基づく IaaS 基盤を利用することで、事業体テナントで発生するイン
ターフェイスサーバーやデータベースのスケールアウトを迅速に実施可能となる。また、水道標準プラットフォームにベンダーがア
プリケーションを導入する場合には、ホストＯＳ上にコンテナエンジンを用意しておくことで、ベンダーが実施するＡＰのデプロイ作
業を省力化することが可能となる。また、共通サービスについては、セキュリティやシステム動作監視に関する機能についてはク
ラウドで標準サービスとして準備されていることも多いため、これらの機能サービスを利用することで、導入・運用の手間を削減することが期待できる。また、共通サービスについては、セキュリティやシステム動作監視に関する機能についてはクラウドで標準サービスとして準備されていることも多いため、これらの機能サービスを利用することで、導入・運用の手間を削減することが期待できる。

2.2.3. コンテナの活用について
コンテナ技術は従来の仮想マシン技術と比較し、多くのメリットがあり、昨今急速に普及している技術であるが、クラウドが持つコンテナサービスは、仮想マシンと比較し費用が高いケースが多いことと、商用システムとしての実績がまだ少ないこと等が懸念点である。ここでは、費用、実績については一旦考慮せず、技術としての比較からメリット・デメリットを整理し、その結果各機能がコンテナ技術と仮想マシン技術とどちらを採用すべきか、について示すものとする。実際の運営上の採用においては、クラウドのコンテナサービスの費用面と実績面を考慮した上で採用を検討する必要があると考えている。

コンテナ技術のメリットとデメリット
コンテナは昨今急速に普及している仮想化技術の１つで、サービスとその実行環境をパッケージ化できるため、ソフトウェア開発者にとっては、煩わしいデプロイ作業から解放される（開発工数を削減できる）といったメリットがある。さらに運用面でも、実環

37 / 72

境への素早い展開、かつ仮想マシンよりも使用リソース量が少ないため、素早いサービス起動も可能となり、サービス継続性を高める、というメリットもある。（図 2.2-8）

仮想マシンのデメリット
デプロイ作業について仮想サーバ環境上でもAPのインストールとAPの環境
情報設定作業が必要なため従来と変
わらない

ゲストOSが含まれるため、サービス起
動時、ゲストOSの起動も含まれるた
め時間がかかる

コンテナ技術のメリット

仮想マシンのリ
ソース量が大きい

仮想マ
シン

仮想マ
シン

仮想マ
シン

仮想マ
シン

AP

AP

AP

AP

AP環境
情報
ゲスト
ＯＳ

AP環境
情報
ゲスト
ＯＳ

AP環境
情報
ゲスト
ＯＳ

AP環境
情報
ゲスト
ＯＳ

・・・

コンテナがAPとAP
環境情報をセットに記憶できるため、コンテナを立ち上げだ
けでデプロイが終了⇓より少ない作業工数（人件費）

コンテナ

ゲストOSが不要なためサービス起動時間が非常に速い⇓
より短いリソース課
金時間

コンテナ

コンテナ

AP

AP

AP環境
情報

AP環境
情報

コンテナのリソース量が仮想マシンより小さい⇓
より少ないリソース
量での課金

・・・

コンテナ

AP

AP

AP環境
情報

AP環境
情報

コンテナエンジン
ホストOS
ハードウェアハイパーバイザー
ホストOS
ハードウェア

図 2.2-8 仮想マシンと比較した場合のコンテナ技術のメリット

仮想マシンとコンテナはどちらも仮想化技術であるが、それぞれメリット・デメリットがあり、それらを踏まえ、各機能の採用技術（仮想マシンもしくはコンテナ）を以下表 2.2-1 に整理する。仮想マシンとコンテナを比較した際の、「コンテナ」のメリット・デメリット
は大きくは以下の通りである。

表 2.2-1 仮想マシンとコンテナを比較した際の「コンテナ」のメリット・デメリット

区分
メリット

デメリット

概要
①

ゲスト OS が不要なため、サービス起動時間が早い。

②

仮想マシンより必要リソース量が少なく、リソース集約率がよい。

③

サービスとその実行環境をパッケージ化できるため、デプロイ作業が容易かつ迅速に可能となる。

①

OS と異なるシステムをコンテナで起動させることはできない②

コンテナ単体でデータの永続性がなく（コンテナの停止時にデータは消失する）、データを保持するサービスには不向き。（外部のボリュームとの連携により技術的には可能だが、仮想マシンに比べ運用作業が増える）以下、コンテナ技術の利用について、プラットフォームが提供する機能への採否と、アプリケーションベンダーへの環境提供の２点に分けて説明する。

38 / 72

プラットフォーム提供機能に対するコンテナ技術の利用について
前節で示したコンテナのデメリットに対し、水道標準プラットフォームのサービスは、オープンな仕様かつ低コストでの仕組みとすることから、全てＯＳＳの「CentOS」で動作することにより、デメリットの①について対処できるものとした。デメリットの②については、ホストＯＳ上にデータベース用のボリュームを作成してマウントすることで解決することが考えられる。このような運用が可能かどうかはケースバイケースであり、本節では両方の構成について示す。

■ ケース１． データを保持するサービスにはコンテナを利用しない場合
各サービスの特徴から、各機能にコンテナの採否は表 2.2-2 に整理される。

表 2.2-2 各構成要素とコンテナ技術の採否

#

配置される

機能

採用技術

理由

テナント
１

共通テナント

認証認可

コンテナ

デメリットを考慮する必要がなく、メリットを享受できる

２

共通テナント

データセキュリティ

コンテナ

３

共通テナント

ユーザーＩＦコンテナ

４

共通テナント

動作監視

仮想マシン

動作監視データをＤＢとして保持するため、デメリット②をもたらす。プラットフォームの思想として、データの消失は厳禁であるため、データ永続性を担保する仮想マシンを採用する。

５

共通テナント

マスタ管理

仮想マシン

認証情報やマスタ情報をＤＢとして保持するため、デメリット②をもたらす。プラットフォームの思想としてデータの消失は厳禁であるため、データ永続性を担保する仮想マシンを
採用する。

６

共通テナントオブジェクト

仮想マシン

ストレージ

ゲートウェイから収集したデータや、アプリケーションが利用する過去データをＤＢとして保持するため、デメリット②をもたらす。プラットフォームの思想としてデータの消失は厳禁であるため、データ永続性を担保する仮想マシンを採用する。

７

事業体テナント

アプリケーション

コンテナ

デメリットを考慮する必要がなく、メリットを享受できるため。

仮想マシン

ゲートウェイから収集したデータや、アプリケーションが利用向け標準ＡＰＩ
８

事業体テナント

データ蓄積

するデータをＤＢとして保持するため、デメリット②をもたらす。プラットフォームの思想としてデータの消失は厳禁であるため、データ永続性を担保する仮想マシンを採用する。
９

事業体テナント

ゲートウェイ向け

コンテナ

デメリットを考慮する必要がなく、メリットを享受できるため。

標準ＩＦ39 / 72この場合のシステムアーキテクチャ全体像は図 2.2-9 のようになる。

仮想マシン

仮想マシン

仮想マシン

動作監視

マスタ管理

データ蓄積

ゲストOS

ゲストOS

ゲストOS

ＶＭ

ＶＭ

コンテナ

コンテナ

コンテナ

コンテナ

コンテナ

認証
認可

暗号化

ユーザ
IF

AP向け
標準
API

GW向け
標準
IF

コンテナエンジン

コンテナエンジン

共通テナント

事業体テナントA

・・・

事業体テ
ナントB

ホストOS(CentOS）

オブジェクトストレージ

ハードウェア

図 2.2-9 システムアーキテクチャ全体像（ケース１．データを保持するサービスにはコンテナを利用しない場合）■ ケース２． すべてのサービスにコンテナを利用する場合
コンテナは、ステートフルなサービス向けであることから、データの永続性を持たない（コンテナの停止時にデータが消失する）
ため、データベースをもつサービス（マスタ管理など）については、ホストＯＳ上にデータベース用のボリュームを作成してマウントすることで解決することとする。仮想マシンに比べ運用作業が増える可能性があるが、システム全体でコンテナを利用するメリットが上回ると判断できれば、採用を検討すべきである。この場合のシステムアーキテクチャ全体像は図 2.2-10 のようになる。

コンテナ

コンテナ

認証
認可

暗号化

コンテナ

コンテナ

コンテナ

ユーザ
IF

AP向け
標準
API

GW向け
標準
IF

コンテナ

コンテナ

コンテナ

動作監視

マスタ管理

データ蓄積

DB

・・・

コンテナエンジン

コンテナエンジン

共通テナント

事業体テナントADB

オブジェクトスト
レージ

DB

事業体
テナントB
ホストOS(CentOS）

ハードウェア
永続化が必要なDB・ストレージはホストOS上に作成・マウント

図 2.2-10 システムアーキテクチャ全体像（ケース２.すべてのサービスにコンテナを利用する場合）

40 / 72

水道標準プラットフォームにベンダーがアプリケーションを導入する場合には、ホストＯＳ上にコンテナエンジンを用意しておくことで、ベンダーが実施するＡＰに関して、上述したコンテナのメリットを享受できるため、ベンダーテナントへもコンテナを提供するのが望ましいと考える（ベンダーの採用は必須ではない）。ベンダーテナントへのコンテナ提供については以下(3)で示す。
上述したシステムアーキテクチャで水道標準プラットフォームが構築されることで、期待される効果を最大限に発揮できると考えられる。今後は、上記が実現可能なクラウドサービスの選定や、コンテナの費用面を考慮した採用技術の確定、実構築による動作検証を進めていき、実運用での稼働に耐えうるプラットフォームとしていく必要がある。

ベンダーアプリケーションでのコンテナ技術の利用について
前項では、プラットフォームで提供する各機能について、コンテナ技術の利用を検討した。一方、ベンダーが導入するアプリケーションについては、データ保存の有無や、利用するＯＳ、ハード性能などが個別に異なるため、コンテナ技術のメリット・デメリット
を個別に検討して選択することとなる。そのため、プラットフォームでは、アプリケーションベンダーの要望に応じて、仮想マシンとコンテナのいずれのケースでも IaaS 環境を提供できるようにする。
ただし、アプリケーションが動作保障されたＯＳやミドルウェアは各社のアプリケーションより異なるため、動作環境を個別にプラットフォーム側で提供すると、様々な動作環境を構築、検証することとなり、作業負荷やコストの増大が懸念される。一方、ベンダー側が動作検証済アプリケーションの動作環境全体を、コンテナイメージとしてプラットフォームに持ち込むことで、プラットフォー
ム側は、コンテナエンジンだけを準備しておけば良く、両者で構築作業や検証範囲を削減できる。具体的には、ベンダーアプリケ
ーションの導入について、コンテナを利用することで以下のようなメリットがあり、コンテナの利用が推奨される。

（Ａ） 環境移行の負荷低減
プラットフォームへのアプリケーション導入においては、複数回の導入作業が想定されるため、その作業をできるだけ簡易にしておくことが望ましい。例えば、アプリケーション導入における環境移行のステップとして以下が想定される。

① ベンダーの社内試験環境→ ② プラットフォームとの接続検証用の試験環境→ ③ 水道事業体の既設装置や実データを模擬した試験環境→ ④ 本番環境

これらの移行において、毎回、仮想マシンを立ててゲストＯＳの設定やミドルウェアを含めた環境を構築することは作業負担が大きい。また、検証の異常発生時に、環境要因であるかを常に疑う必要があり、原因の切り分けについて時間がかかる。一方、コンテナでＯＳやアプリケーションの設定情報を含めて環境移行ができれば、構築および動作検証の作業全体の負担が削減できると想定される。

（Ｂ） 運用時のバージョンアップや環境変更の容易性
アプリケーションのバージョンアップは各社の判断により、顧客ニーズへの対応や新規技術への追従のために実施される。これらの対応後に、再度、前項で述べたような試験プロセス（の一部）を経て、アプリケーションを本番環境に反映する場
合、各ステップでの環境の変更や動作検証を個別に行っていく必要がある。
従前よりコンテナを利用していれば、導入作業が容易になるだけでなく、ＯＳとの動作検証が完了した状態で導入できるため、動作検証範囲や試験ステップの削減も期待できる。

41 / 72

（Ｃ） プラットフォーム機能の試験提供
前項で検討した通り、プラットフォーム側で提供する機能については、コンテナでプラットフォームへ導入することを想定している。そのため、ベンダー側で事前の検証のために共通機能を利用したい場合、プラットフォーム側はコンテナとして試験用サーバーを提供することが可能であり、（ベンダー側もしくはプラットフォーム側の）試験環境にコンテナエンジンがあれば、希望する共通機能の連携試験の環境を素早く構築できる。そして、ベンダー側での連携検証が終わった場合に、その設定状態をそのままコンテナイメージとしてプラットフォーム側に提供できるため、環境移行が容易で、不具合の発生も低減できる。

上記を踏まえ、アプリケーションの開発から導入までのコンテナ利用のメリットを図 2.2-11 に示す。

プラットフォーム側の環境

ベンダー側の環境
開発環境

アプリケーション

試験環境

試験環境

本番環境

コンテナ

コンテナ

コンテナ

アプリケーション
AP環境情報・AP機能変更
・対応OS変更
・AP環境変更〇 プラットフォーム機能を、試験用にコンテナイメージで提供が可能。

検証済
イメージ
コピー

アプリケーション
AP環境情報

検証済
イメージ
コピー

アプリケーション
AP環境情報コンテナエンジン

コンテナエンジン

コンテナエンジン

ホストOS

ホストOS

ホストOS

〇 導入、起動、停止、削除が容易。
〇 環境要因の検証削減。

アプリケーション

ゲストOS
＋環境設定

■仮想サーバの場合✕ ゲストＯＳ設定、動作環境の設定も必要。
✕ 環境要因の動作検証が必要。

ハイパーバイザー
図 2.2-11 ベンダーアプリケーションでのコンテナ利用のメリット

2.2.4. システム標準仕様書との関連について
システム標準仕様書は、先のシステムアーキテクチャにおけるデータ流通の部分に対して、社会実装を推進するため、具体的な通信仕様を定めたものである。これを標準仕様として公開することにより、ベンダーや事業体におけるプラットフォームの利用推進が期待される。
システムアーキテクチャとシステム標準仕様書の対応関係を図 2.2-12 に示す。

42 / 72

【凡例】

CPS/IoT
セキュリティ仕様書
アプリ
ケーション

共
通
テ
ナ
ン
ト

事
業
体
テ
ナ
ン
ト

ユーザー
インターフェース
暗号化

認証
認可

マスタ
管理

動作
監視

…

水
道
標
準
プ
ラ
ッ
ト
フ
ォ
ー
ム

アプリ
ケーション

インターフェース

データ
蓄積

インターフェース

オブジェクト
ストレージ

システム標準仕様書…

事業体ユーザアプリベンダー向け標準インターフェイス仕様書

水道標準プラットフォーム外部仕様書
機器ベンダー向け標準インターフェイス(デバイス)仕様書
機器ベンダー向け標準インターフェイス(システム)仕様書

共通機能（暗号化、ID管理等）
IaaS基盤、OS、ネットワーク

ゲートウェイゲートウェイゲートウェイ

初期情報設定シート※初期値設定方法

IoTゲートウェイ外部仕様書…

システムゲートウェイ外部仕様書■その他の仕様書
基本仕様書

システム標準仕様書の全体概要

水道CPSデータプロファイル仕様書

通信データのXMLフォーマット

図 2.2-12

システムアーキテクチャとシステム標準仕様書の対応関係

43 / 72

第3章

カタログ編

本編では、水道標準プラットフォームが提供するサービスメニューを説明する。

リファレンスアーキテクチャ仕様書
コンセプト編
水道標準プラットフォームのアーキテクチャ設計に対する要求事項、および、設計のコンセプトを説明

カタログ編

プロセス編

水道標準プラットフォームが提供するサービスメニューを説明

水道情報活用システム整備に関する計画から導入、保守に至るプロセスを説明

44 / 72

3.1. プラットフォームサービスの概要（構成）プラットフォームの活用をすることで、必要な機能やセキュリティやコスト、必要期間を考慮し、最適な機能やサービスが選べるようになることが期待される。それにより、各種アプリケーションや機能は、競争環境に、最適な価格で購入できるようになるとともに、必要となる機能が必要な分だけサービスとして購入可能となる。
そのため、プラットフォームサービスは「カタログ」のように選択し、それを必要な期間だけ利用できるようになっていることが望ましい。本章では、プラットフォームサービスの項目をテナント毎に示し、利用時の選定内容を示す。
プラットフォームサービスの概要は以下の３点であり、その全体構成を図 3.1-1 に示す。

◆プラットフォームは、４つのテナントに加え、「セキュリティパーツ」 と 「その他サービス」 の６つで構成する◆共通テナントの共通サービスは（A,B,C）は、すべてのテナントに提供する◆事業体及び試験テナントについては、個別機能サービスなどを更に提供する

プラットフォーム
⑤
セ
キ
ュ
リ
テ
ィ
ー
パ
ー
ツ

①
共通テナント②
事業体テナント

Ｃ．共通人的サポートサービス（問合せ窓口
一次切り分けなど）③
ベンダーテナント④
試験テナントD．専用AP
領域提供サービス

Ｅ．試験AP
領域提供サービス

Ｂ‘．個別機能サービス

Ｂ‘．個別機能サービス

共通人的サポートサービス（運用保守）
B．共通機能サービス（ID登録、事業体マスタ、認証、認可、暗号、基盤監視、動作監視）
A．共通基盤サービス（ＯＳ、ミドルウェア、ストレージ、冗長化構成）⑥その他支援サービス

事業体

GWベンダー
浄水場

配水場・管路APベンダー

図 3.1-1 プラットフォームサービスの全体構成

図 3.1-1 に示したプラットフォームサービスの各構成要素の内容は以下の通り。

45 / 72

① 共通テナント
プラットフォームをシステムとして利用する際に共通的な機能を集約したテナントである。図 X に示すように、共通テナントの各
サービスは、すべての事業体・ベンダーが共通的に活用する機能の集合されたサービスであり、他のテナントで利用可能である。
具体的には、プラットフォーム内の IT 基盤などの提供、ユーザー登録/ログイン、多要素認証、データ暗号化、PF 内の各種サービス・機能・データへのアクセス認可、データ流通を実現する機能、運用保守を容易に実施する機能及びヘルプデスク等人的なサポート、SE によるシステム全体の運用保守等、共通的に利用可能なサービス。

② 事業体テナント
システムアーキテクチャの全体像で示した通り、事業体のデータをデータベースに保管しているため、前項で示した共通的なサービスに加えて、データ保管に必要な個別機能変更のサービスを提供する。また事業体データ項目の雛形も用意しデータ整備を支援するとともに、事業体同士の共同利用も可能とする。
本サービス内には、事業体データのアクセスするための各種標準インターフェイス（AP-IF、GW-IF）も配置し、データ流通を実現している。事業体専用のアプリケーションを本サービス内に配置することも可能であり、専用 AP 領域を構築支援するサービスを提供している。

③ ベンダーテナント
ベンダーに提供するベンダーのアプリケーションを配置するサービス。ここにあるアプリケーションは事業体向けテナントのデータ
を標準 IF などで取得しアプリケーションサービス（AI 機能等も含む）としてユーザーに提供する。本サービス内のアプリケーション
は、複数事業体にも提供できるアプリケーションや、事業体専用のアプリケーションを配置することができる。

④ 試験テナント
試験テナントでは、アプリケーションベンダーやゲートウェイベンダーが、プラットフォームの本番環境に接続する前に、自社の製品について試験を実施し、機能面、非機能面について検証を実施するための環境を提供する。そのため、事業体テナントのサー
ビスとほぼ同等のサービスを受けることができる設定としている。
このテナントでは、ベンダーや事業体が、新たなアプリケーションなどの試験開発をするために必要な環境の提供する試験用のデータとして事業体の許可を前提に、このテナント内に事業体データを配置し、導入に向けた本格的な試験として利用することができる。

⑤ セキュリティパーツ
プラットフォームを利用するにあたって、セキュリティのポリシーは各事業体で異なるため、セキュリティに必要なシステムの機能や通信回線もそれぞれ異なることが想定される。そのため、セキュリティパーツとして、様々な機能選択を可能としている。

⑥ その他支援サービス
導入設計フェーズから PF 利用開始まで、各種支援サービスを想定し、提供するサービスである。

46 / 72

3.2. プラットフォーム内のサービス概要とカタログ
本節では、６つの各構成要素について、それぞれが提供するサービス概要と選択可能なサービス項目（カタログ）を説明する。

3.2.1. 共通テナント
共通テナントは、プラットフォームをシステムとして利用する際に共通的な機能を集約したテナントである。図 3.2-1 に示すように、共通テナントの各サービス A～C は、すべての事業体・ベンダーが共通的に活用する機能の集合されたサービスであり、他のテナントで利用可能である。

プラットフォーム

①
共通テナント

②
事
業
体
テ
ナ
ン
ト

Ｃ．共通人的サポートサービス

③
ベ
ン
ダ
ー
テ
ナ
ン
ト

④
試
験
テ
ナ
ン
ト

問合せ窓口
一次切り分けB．共通機能サービス
A．共通基盤サービス

図 3.2-1

共通テナントのサービス提供範囲

共通テナントで提供する各サービスの内容を以下に説明する。

Ａ．共通基盤サービス
本サービスは、すべてのテナントに必要な環境（HW、OS、仮想技術、コンテナ技術、ミドルウェア、IT 製品（データベースなど）、ストレージ）を提供する。

B．共通機能サービス
本サービスはプラットフォームの各テナント共通的に利用する機能を提供する。
提供する機能として、ユーザー及びベンダーの ID 登録、セキュリティ認証、事業体マスタ（事業体の諸元データ）、プラットフォーム内の各テナントやデータへのアクセス等の認証や認可、データの暗号化、プラットフォームとしてのすべてのテナントの動作
監視機能、ベンダーが提供する GW 及びアプリケーションなどの動作監視や運用保守作業に関する機能とする。

47 / 72

Ｃ．共通人的サポートサービス
本サービスはプラットフォームの各テナントで共通的に利用する人的サービスを提供する。
•

全体の問合せ窓口を設置し、事業体やベンダーからの問い合わせをサポート•

運用作業においては、プラットフォームが適切に動くための運用業務を実施（共通サービス及び事業体向けテナントは PF が実施。例えばベンダーテナントなどの運用については、このサービスを活用するか、自らベンダーが実施するかは選択可能）。

•

保守作業においては、運用と同様プラットフォームが適切に動くための保守業務を実施（例えばベンダーテナントの保守については、このサービスを活用するか、自らベンダーが実施するかは選択可能）。

•

システム障害時においては、事業体とプラットフォーム及びベンダーとの保守契約を前提に共通窓口としてプラットフォームにて一次受付・一次切り分けを行い、別途定める保守連絡先として登録されている各ベンダーへの二次問合せを実施することでサポートを受けることができる。

これらのサービスを利用する場合に、利用者が選択できるサービス項目（カタログ）を表 3.2-1 に示す。これらの項目を選択していくことにより、利用者が希望するサービスのみを受けられるようになる。

表 3.2-1 共通テナントのサービスカタログ

No.

提供サービス内容

A 共通基盤サービス（選択必須）
1 基盤提供サービス

全テナントに必要な環境（HW、OS、仮想技術、コンテ
ナ技術、ミドルウェア、IT製品（データベース等）、ストレージ）を提供

B 共通機能サービス（選択必須）
1 事業体のマスタ登録サービス

事業体がPFを利用するための必要なプロフィール(マスタ）を登録するサービス

2 ユーザー登録／認証認可サービス

利用するユーザやベンダーのID登録やPF内の利用範囲について認証認可の設定するサービス

3 AP・GW登録／データ流通に関する認証認可サービス

PFに接続するAP情報・GW情報を登録し、データ流通
先への認証認可の設定するサービス。

4 暗号化サービス（オプション）

GW-PF間、PF-ユーザ間などの通信データの暗号化やセキュリティ認証などを提供するサービス。

5 動作監視情報提供サービス（オプションあり）

各AP・PF・ＧＷの動作監視情報および運用保守状況の情報を提供するサービス。
AP/GWでの動作監視項目はベンダーにて設定

C 共通人的サポートサービス（選択必須・一部オプション）
１ 運用サービス(一部オプション可能）

OP/SEによりシステムの運用・移行などの作業を実施する
サービス（共通テナントは必須、各テナントやGWなども本サービスでの実施を前提）

2 保守サービス(一部オプション可能）

OP/SEによりサービス基盤や機能やアプリケーションなどの維持管理を適切に行うサービス（共通テナントは必須、各テナントやGWなども実施を前提）。障害発生時には事前に登録した対応内容で、PFが1次受けと成り障害対応を行う（必須）

３ データ抽出サービス(オプション）

事業体のデータを任意に抽出して提供するサービス

48 / 72

3.2.2. 事業体テナント
事業体テナントでは、システムアーキテクチャの全体像で示した通り、事業体のデータをデータベースに保管しているため、前項で示した共通的なサービス A～C に加えて、「B’.個別機能サービス」を提供し、また、各事業体に専用の AP を事業体テナント上に稼働する場合を考慮して、「D.専用 AP 領域サービス」を提供している。

プラットフォーム

②
事業体テナント
①
共
通
テ
ナ
ン
ト

D．専用AP
領域サービス

③
ベ
ン
ダ
ー
テ
ナ
ン
ト

④
試
験
テ
ナ
ン
ト

Ｂ‘．個別機能サービス
Ｃ．共通人的サポートサービス
Ｂ．共通機能サービス
Ａ．共通基盤サービス

図 3.2-2

事業体テナントのサービス提供範囲

事業体テナントで提供する各サービスの内容を以下に説明する。

Ａ．共通基盤サービス
本テナントに必要な環境（HW、OS、ミドルウェア、IT 製品（データベースなど）、ストレージ）を活用してサービスを構築

B．共通機能サービス
本テナントに関する共通的に利用する機能を活用してサービスを利用

Ｃ．共通人的サポートサービス
PF の全体の問合せ窓口と連携し、事業体やベンダーからの問い合わせをサポートする。具体的には以下の通り。
•

本テナントが適切に動くための運用業務を実施します。また本テナントの保守作業においては、運用と同様に適切に動くための保守業務を実施•

システム障害時においては、事業体とプラットフォーム及びベンダーとの保守契約を前提に共通窓口としてプラットフォームにて一次受付・一次切り分けを行い、別途定める保守連絡先として登録されている各ベンダーへの二次問合せを

49 / 72

実施することでサポートを受けることができる。

B‘．個別機能サービス
事業体データの保持・蓄積及びデータ流通に必要となる「アプリケーション向け標準インターフェイス（AP-IF）」、「ゲートウェ
イ向け標準インターフェイス（GW-IF）」、「データベース」及び「データ移行ツール」の各機能を提供する。プラットフォームのSE が実施する。
•「AP-IF」によりベンダーはアプリケーションに必要なデータを取得可能。必要な IF 数を提供•

「GW-IF」により GW から必要なデータ通信制御を実施。必要な IF 数を提供•

「データベース」としては、各種データベースを用意する。そのデータ項目（スキーマ）、データ保持期間などを設定する機能を提供する。具体なデータの設計作業や実際の登録作業はベンダーで実施することを予定している。

•「データ移行サービス」として、必要なデータ移行ツールや標準的なデータ形式などを予定

D．専用 AP 領域提供サービス
アプリケーションベンダーが事業体専用にアプリケーション提供する場合を想定し、事業体テナント内に専用アプリケーションを動作する領域を提供する。なおアプリケーションからのデータへのアクセス等は AP-IF、GW-IF などを活用してデータにアクセスすることになる。

これらのサービスを利用する場合に、利用者が選択できるサービス項目（カタログ）を表 3.2-2 に示す。これらの項目を選択していくことにより、利用者が希望するサービスのみを受けられるようになる。（Ａ.共通基盤サービス／Ｂ.共通機能サービス／Ｃ．共通人的サポートサービスは、「共通テナント」と同様になるため記載を割愛）

表 3.2-2 事業体テナントのサービスカタログ

No.

B‘

D

提供サービス

内容

個別機能サービス（選択必須・一部オプション）
1 事業体データに接続するAP-IF・
ＧＷ-IFの提供サービス

AP・ＧＷが事業体のデータと通信するためのIFを必要数設置し、データ通信を可能とするサービス。

2 事業体データを保有・蓄積サービス（オプションあり）

事業体やベンダーの設計により指定された「データベース機能（蓄積粒度・期間等も選択可能）」を設定する。なおPFからは「データの雛形」を提供することデータ設計を支援することも可能。

３ 事業体データ移行サービス（オプションあり）

データ移行・統合に必要なツールやデータ形式等を提供する。データ移行の実施をすることも可能。

試験AP領域提供サービス（選択任意）
1 事業体専用のアプリケーション領域を提供するサービス

事業体テナント内に事業体専用のアプリケーションを配置するための領域を提供するサービス。

Ａ.共通基盤サービス／Ｂ.共通機能サービス／Ｃ．共通人的サポート
サービスは、「共通テナント」と同様になるため記載を割愛します。

50 / 72

3.2.3. ベンダーテナント
ベンダーテナントは、ベンダーが複数の事業体に横断的にアプリケーションを提供する場合を想定して、ベンダーアプリケーショ
ン専用の環境を提供するものである。

プラットフォーム

①
共
通
テ
ナ
ン
ト

②
事
業
体
テ
ナ
ン
ト

③
ベンダーテナント

④
試
験
テ
ナ
ン
ト

Ｃ．共通人的サポートサービス
Ｂ．共通機能サービス
Ａ．共通基盤サービス

図 3.2-3 ベンダーテナントのサービス提供範囲

ベンダーテナントで提供する各サービスの内容を以下に説明する。

Ａ．共通基盤サービス
本テナントに必要な環境（HW、OS、ミドルウェア、IT 製品（データベースなど）、ストレージ）を活用してサービスを構築

B．共通機能サービス
本テナントに関する共通的に利用する機能を活用してサービスを構築

Ｃ．共通人的サポートサービス
PF の全体の問合せ窓口と連携し、事業体やベンダーからの問い合わせをサポートする。具体的には下記の通り。
•

本テナントが適切に動くための運用業務を実施。また本テナントの保守作業においては、運用と同様に適切に動くための保守業務を実施。

•

システム障害時においては、事業体とプラットフォーム及びベンダーとの保守契約を前提に共通窓口としてプラットフォームにて一次受付・一次切り分けを行い、別途定める保守連絡先として登録されている各ベンダーへの二次問合せを実施することでサポートを受けることができる。

51 / 72これらのサービスを利用する場合に、利用者が選択できるサービス項目（カタログ）を表 3.2-3 に示す。これらの項目を選択していくことにより、利用者が希望するサービスのみを受けられるようになる。

表 3.2-3 ベンダーテナントのサービスカタログ

No.

提供サービス内容

A 共通基盤サービス（選択必須）
1 基盤提供サービス

ベンダーテナントに必要な環境（HW、OS、仮想技術、
コンテナ技術、ミドルウェア、IT製品（データベース等）、
ストレージ）を提供

B 共通機能サービス（選択必須）
1 データ流通に関する認証認可
サービス

データ流通先への認証認可の設定するサービス。

2 暗号化サービス（オプション）

GW-PF間、PF-ユーザ間などの通信データの暗号化やセキュリティ認証などを提供するサービス。

3 動作監視情報提供サービス（オプションあり）

ベンダーテナントの動作監視情報および運用保守状況の情報を提供するサービス。
APでの動作監視項目はベンダーにて設定

C 共通人的サポートサービス（選択必須・一部オプション）
１ 運用サービス(一部オプション可能）

OP/SEによりシステムの運用・移行などの作業を実施する
サービス（ベンダーテナントに関すること及びGWなども本サービスでの実施を前提）

2 保守サービス(一部オプション可能）

OP/SEによりサービス基盤や機能やアプリケーションなどの維持管理を適切に行うサービス（ベンダーテナントに関すること及びGWなども本サービスでの実施を前提）。
障害発生時には事前に登録した対応内容で、PFが1次受けと成り障害対応を行う（必須）3.2.4. 試験テナント
試験テナントでは、アプリケーションベンダーやゲートウェイベンダーが、プラットフォームの本番環境に接続する前に、自社の製品について試験を実施し、機能面、非機能面について検証を実施するための環境を提供する。そのため、事業体テナントのサー
ビスとほぼ同等のサービスを受けることができる設定としている。

52 / 72

プラットフォーム

①
共
通
テ
ナ
ン
ト

④
試験テナント

③
ベ
ン
ダ
ー
テ
ナ
ン
ト

②
事
業
体
テ
ナ
ン
ト

E．試験AP
領域提供サービス
Ｂ‘．個別機能サービス

Ｃ．共通人的サポートサービス
Ｂ．共通機能サービス
Ａ．共通基盤サービス

図 3.2-4

試験テナントのサービス提供範囲

試験テナントで提供する各サービスの内容を以下に説明する。

Ａ．共通基盤サービス
本テナントに必要な環境（HW、OS、ミドルウェア、IT 製品（データベースなど）、ストレージ）を活用してサービスを構築

B．共通機能サービス
本テナントに関する共通的に利用する機能を活用してサービスを利用

Ｃ．共通人的サポートサービス
PF の全体の問合せ窓口と連携し、事業体やベンダーからの試験中の問い合わせをサポートする。
•

本テナントが適切に動くための運用業務を実施します。また本テナントの保守作業においては、運用と同様に適切に動くための保守業務を実施•

システム障害時においては、事業体とプラットフォーム及びベンダーとの保守契約を前提に共通窓口としてプラットフォームにて一次受付・一次切り分けを行い、別途定める保守連絡先として登録されている各ベンダーへの二次問合せを実施することでサポートを受けることができる。

B‘．個別機能サービス
事業体データの保持・蓄積及びデータ流通に必要となる「アプリケーション向け標準インターフェイス（AP-IF）」、「ゲートウェ
イ向け標準インターフェイス（GW-IF）」、「データベース」及び「データ移行ツール」の各機能を提供する。プラットフォームのSE が実施する。

53 / 72•「AP-IF」によりベンダーはアプリケーションに必要なデータを取得可能。必要な IF 数を提供•

「GW-IF」により GW から必要なデータ通信制御を実施。必要な IF 数を提供•

「データベース」としては、各種データベースを用意する。そのデータ項目（スキーマ）、データ保持期間などを設定する機能を提供する。具体なデータの設計作業や実際の登録作業はベンダーで実施することを予定している。

•「データ移行サービス」として、必要なデータ移行ツールや標準的なデータ形式などを予定

D．専用 AP 領域提供サービス
アプリケーションベンダーが事業体専用にアプリケーション提供する場合を想定し、事業体テナント内に専用アプリケーションを動作する領域を提供する。なおアプリケーションからのデータへのアクセス等は AP-IF、GW-IF などを活用してデータにアクセスすることになる。

これらのサービスを利用する場合に、利用者が選択できるサービス項目（カタログ）を表 3.2-4 に示す。これらの項目を選択していくことにより、利用者が希望するサービスのみを受けられるようになる。（Ａ.共通基盤サービス／Ｂ.共通機能サービス／Ｃ．共通人的サポートサービスは、「共通テナント」と同様になるため記載を割愛）

表 3.2-4 試験テナントのサービスカタログ

No.

B‘

Ｅ

提供サービス

内容

個別機能サービス（選択必須・一部オプション）
1 事業体データに接続するAP-IF・
ＧＷ-IFの提供サービス

AP・ＧＷが事業体のデータと通信するためのIFを必要数設置し、データ通信を可能とするサービス。

2 事業体データを提供サービス（オプションあり）

試験用のデータを提供する。事業体やベンダーの設計により指定された「データベース機能（蓄積粒度・期間等も選択可能）」を設定する。なおPFからは「データの雛形」を提供すること試験データ設計を支援することも可能。

３ 事業体データ移行サービス（オプションあり）

データ移行・統合に必要なツールやデータ形式等を提供する。データ移行の実施をすることも可能。

４ 事業体データの抽出サービス（オプション）

GW-PF間、PF-ユーザ間などのデータ通信の暗号化を設定して利用できるサービス。

試験AP領域提供サービス（選択任意）
1 試験用のアプリケーション領域を提供するサービス

試験テナント内に試験用のアプリケーションを配置する
ための領域を提供するサービス。

54 / 72

3.2.5. セキュリティパーツ
プラットフォームを利用するにあたって、セキュリティのポリシーは各事業体で異なるため、セキュリティに必要なシステムの機能もそれぞれ異なることが想定される。そのため、セキュリティパーツとして、様々な機能選択を可能としている。そして、プラットフ
ォームの①から④テナントでは、以下のセキュリティパーツを「データ毎のセキュリティの必要性・重要度」から選択ができるようにしている（）。

プラットフォーム

⑤
セ
キ
ュ
リ
テ
ィ
ー
パ
ー
ツ

②
事
業
体
テ
ナ
ン
ト

①
共
通
テ
ナ
ン
ト

③
ベ
ン
ダ
ー
テ
ナ
ン
ト

④
試
験
テ
ナ
ン
ト

⑥その他支援サービス

事業体

浄水場

配水場・管路

GWベンダー
APベンダー

図 3.2-5 セキュリティパーツのサービス提供範囲

具体的に選択可能なセキュリティパーツの内容を表 3.2-5 に示す。

55 / 72

表 3.2-5 セキュリティパーツのサービスカタログ
No.

内容

セキュリティー選択パーツ

1 データ通信系セキュリティパーツ(選択必須）
1 回線事業者の閉域網サービス提供

閉域網前提のプラットフォームでの各テナントでは、閉域網での接続のみ許容し、インターネットを経由しない
安全なデータ通信を提供します。

2 ファイアウォール、IDS、IPS・プラットフォーム内の各テナントで、ファイアウォールのサービスにより不正侵入を防御します。
・IDS(不正侵入検知)、IPS(不正侵入防止)による不正アクセス対策を提供します。

2 暗号認証系セキュリティパーツ（選択必須・一部オプション）
1 通信経路を暗号化したデータ通信サービスを提供（オプションあり）

通信経路において、HTTP(S) 及び MQTT(S)のプロ
トコル、公開鍵方式の採用により、「盗聴防止」や「改ざん」を防ぐデータ通信を提供します。

2 セキュリティ認証（多要素認証による認証）サービスを提供（オプション）

・利用者ユーザの認証・認可では、OpenIDConnect
や証明書による相互認証、ユーザアクセス制御により、「乗っ取り」や「なりすまし」を防止します。
・利用者のアクセスログを保持することにより、「事後否認」を防止します。

3 人的セキュリティパーツ（選択任意）
1 セキュリティー監視サービスを提供（オプション）

IDS/IPSサービスのアラート監視をSEにより24時間
365日を実施します。

これらのセキュリティパーツのメニューについて、活用する技術を表 3.2-6 に示す。また、総合行政ネットワーク（LGWAN）の対策内容との対比により、同等レベルの対策が選択可能であることが分かる。

表 3.2-6 セキュリティパーツのセキュリティレベル補足
選択
パーツ
番号

1

水道標準プラットフォームのセキュリティーパーツのメニュー○

活用する技術など

閉域網での接続のみ許容し、インターネット
回線事業者の閉域網サービス
を経由しない安全なデータ通信を行う。

サービス分類

総合行政NW・LGWAN対策内容

接続セキュリティ系

総合行政ネットワークとは物理的に切り離し、イASP
ンターネットから完全に遮ガイドライン
断することで、不正アクセ

行政専用の閉じたネット
ワークを用いインターネット

ス等の脅威を防止する。

2○ ファイアウォールにより不正侵入を防御する。 クラウド内のサービスを利用

3○

通信経路を暗号化した状態にてデータ通信
HTTP(S) 及び MQTT(S)を行い、盗聴防止対策とする。

IDS(不正侵入検知)、IPS(不正侵入防止)による不正アクセス対策を実施する。

4

○

５

・通信データの暗号化により、情報の「盗聴」、「改ざん」を防止する。
○ ・多要素認証を行い「なりすまし」を防止する。OpenIDConnectなどの技術・利用者のアクセスログを保持することにより、「事後否認」を防止する。

６○

IDS/IPSのアラートを24時間365日監視対応を実施する。

クラウド内のサービスを利用

クラウド内のサービスを利用し、SE
配置

56 / 72

接続セキュリティ系

LGWANの各種サーバ群
をファイアウォールによって侵入の脅威から防御する。

暗号認証系

通信経路を暗号化し、盗聴防止策とする。

接続セキュリティ系

地方公共団体間、都道
府県ノード間での直接通信を制限し、全ての通信を侵入検知機能
総合行政（IDS）で監視すること
ネットワークLGWAN で、不正アクセスの検知を
の概要
行う。

暗号認証系

認証技術による情報の「盗聴」「改ざん」「なりすまし」「事後否認」を防止する。

人的サポート系専門家による24時間
365日のセキュリティ監視を行う。

また、閉域網の選定ではレベルの異なる閉域性の回線があるため、その選択可能なパーツ（回線）の内容を表 3.2-7 に示す。各改正の具体的な説明を表 3.2-8 に補足する。

表 3.2-7 セキュリティパーツ閉域網のサービスカタログ

No.

利用回線の
選択パーツ

説明

閉域性

1 閉域網の種類
1 専用線◎

通信事業者が顧客の拠点間接続などのために貸与す
る、専用の通信回線および回線網。

回線独占利用2 広域イーサネット

2

・地理的に離れたLAN間などをイーサネットインター
フェースで接続する技術。
・イーサネット（レイヤ2）通信が提供されており、利用するプロトコルがIPに依存しないため、LANと同じ感覚で利用可能。

3 IP-VPN

・拠点間の接続に、プロバイダなどの通信事業者の閉域IPネットワーク網を使った通信技術。
・通信業者と契約した人のみが利用できる閉域NW。

4 エントリーVPN

ブロードバンド回線をアクセス回線として用い、通信事
業者の閉域IP網上でVPNを提供するサービス。

○
主に通信業者の閉域IP網を利用

インターネット（今回の閉域網に関するプラットフォームには適用しない）
1 インターネット
VPN

拠点間の経路にインターネットを含むVPNのこと。
IPsecやSSL（Secure Sockets Layer）といったVPN技術でIPパケットを暗号化し、インターネット上でVPNを構築。

△
インターネット利用。
VPN技術でのみ通信を分離

表 3.2-8 セキュリティパーツ閉域網のサービスに関する特徴
回線
パーツ
番号
1

2

3

4

名称

説明

閉域性

月額費用 帯域（拠点毎） 保障

通信事業者が顧客の拠点間接続などの◎数百万ために貸与する、専用の通信回線および回線（距離変動）
回線網
独占利用
地理的に離れたLAN間などをイーサネッ
トインターフェースで接続する技術。イーサ
広域
ネット（レイヤ2）通信が提供されており、
有イーサネット
利用するプロトコルがIPに依存しないため、数十万〇
LANと同じ感覚で利用可能～
数百万
拠点間の接続に、プロバイダなどの通信
主に通信業事業者の閉域IPネットワーク網を使った
IP-VPN者の閉域IP通信技術。通信業者と契約した人のみ網を利用が利用できる閉域NW
ブロードバンド回線をアクセス回線としてエントリー
用い、通信事業者の閉域IP網上で数万
無VPN
VPNを提供するサービス

回線
品質

専用線

57 / 72

高通信
可能 適用用途
備考
レイヤ
1以上
PF-事業体 （利用は減
～
PF-GW
少）
3以上
・網構成柔
PF-事業体 軟
2以上
PF-GW ・提供地域
が狭い
PF-事業体
PF-GW

一般的に
利用

3以上

低

PF-事業体利用が拡大
PF-GW

3.2.6. その他支援サービス
導入や設計からサービス利用に至るまでの各種支援サービスを提供する（図 3.2-6）。

プラットフォーム

⑤
セ
キ
ュ
リ
テ
ィ
ー
パ
ー
ツ

①
共
通
テ
ナ
ン
ト

③
ベ
ン
ダ
ー
テ
ナ
ン
ト

②
事
業
体
テ
ナ
ン
ト

④
試
験
テ
ナ
ン
ト

⑥その他支援サービス
図 3.2-6

その他支援サービス提供範囲

支援を受けることが可能なサービスの項目を表 3.2-9 に示す。

表 3.2-9 その他支援サービスのカタログ
No.

その他支援サービス内容

１ 導入設計支援サービス（すべてオプション）
1 PF導入設計支援

・APやGWのシステムの具体的な要求を伺い、PFを活用したシステ
ム設計の詳細レベルまでの支援します。実績に関する資料やアプリ
ケーションやGWに関する内容は随時情報収集して関係資料としてご提供することも可能。

2 GW機器の提供

GW機器の提供と行い動作確認など支援します

２ AP・GWなど試験支援サービス
1 AP・GWの受け入れ(必須）・ベンダーが試験テナントで実施するAP・GWの受入試験の状況を確認し、試験完了基準を判定します。
・受入試験を完了した試験環境を本番環境へ移行します。

2 既存オンプレシステムからのデータ移行支援(オプション）

既存システムからのデータを移行するために、PFが定義するマスタ・ス
キーマのデータ形式に変換するデータ移行ツールを提供します。

３ 回線敷設支援サービス（オプション）
1 回線敷設サービス

・プラットフォームとデータを送受信するための回線敷設を行います。
・回線種別の選択（事業体⇔PF間、ベンダ⇔PF間、GW⇔PF間）
・閉域網
・無線（携帯回線）/有線（光回線）
・回線の共有/占有

４ PF利用開始準備支援（オプション）
研修・教育

PF利活用のための説明会を事業体やベンダー向けに実施します。

PF接続端末の提供

PFの動作監視サービスが利用可能な端末を提供します。

58 / 72

3.2.7. テナント共通項目： 冗長化構成
本節ではプラットフォーム内の各テナントに対して、可用性の向上を目的として、冗長化構成を希望する場合に、どのような選択が可能かを示す。

バックアップ構成
バックアップ構成は、シングル構成、ホットスタンバイ構成、デュアル構成などすべての構成において提供が可能となっており、すべてのテナントのバックアップ環境を、本番環境とは別のリージョン内のデータセンター内で提供する（図 3.2-7）。
なお、バックアップは、サービス提供環境を保管する「システムバックアップ」とデータの複製を保管する「データバックアップ」を提供する。バックアップのサービスを利用することにより、提供するテナントが不具合や故障により、サービス提供ができなくなった場合でも、速やかにバックアップ環境からテナントの復旧が可能となる。

バックアップ構成
リージョン内で全テナントをバックアップ
共通テナント

サーバ
サーバ

事業体向け
事業体向け
事業体
テナント
テナント
テナント
サービス
サービス

ベンダー向けベンダー向け
ベンダー
テナント
テナント
テナント
サービス
サービス

試験テナント
試験テナント
試験テナント
サービス
サービス

サーバ
サーバ

サーバ
サーバ

サーバ
サーバ

図 3.2-7 バックアップ構成

ホットスタンバイ構成
ホットスタンバイの構成は、同じリージョン内で構成する場合と、違うリージョン同士で構成をとる場合の二つから選択可能とする。各テナントを提供するサーバーのうち、アプリケーションやデータを保存するサーバーについては、ホットスタンバイ（稼働系/待機系）の構成で提供する。そして、待機系サーバーは、稼働系サーバーを監視し、サービスの不具合や故障を検知した場合には、速やかに待機系のサーバーへ自動的に切替し、サービス提供を継続する（図 3.2-8）。

59 / 72

ホットスタンバイ構成

APPF

稼働系サーバ【ACTIVE】

監視

待機系サーバ【STANDBY】

切替
稼働系サーバ【ACTIVE】

監視

待機系サーバ【STANDBY】

切替
図 3.2-8 ホットスタンバイ構成

デュアル構成デュアル構成は、複数のサーバーを同時に稼働させ、負荷分散装置によって処理を振り分ける構成であり、サーバーがダウンした場合には、振り分け先が少なくなるだけで、性能面の余裕があれば継続的に業務を継続できる（図 3.2-9）。
アプリケーションサーバーについては、同じリージョン内で構成する場合と、違うリージョン同士で構成をとる場合の二つが選択できる。各テナントを提供するサーバーのうち、アプリケーションやデータを保存するサーバーについては、デュアル（稼働系/稼働系）の構成を提供する。データ―ベース機能については、選定するデータセンターのサービス機能によりデュアル構成を提供することは出来ない（ホットスタンバイ構成のみ）可能性がある。

デュアル構成負荷分散装置サーバ

サーバ

図 3.2-9 デュアル構成

ディザスターリカバリー構成
リージョン間ディザスターリカバリー構成では、地域性が異なるデータセンターで、全テナントのバックアップ環境を提供する。これにより、データセンターが災害等の被害を受け、利用不能となった場合でも、速やかに異なるリージョンのバックアップ環境からサービスの復旧が可能。選定するデータセンターによっては、リージョン内のディザスターリカバリーを提供するものもある。

60 / 72

ディザスターリカバリー(DR)構成

リージョンＡ

リージョン内DR
全テナントをバックアップ
共通テナント

サーバサーバ

事業体向け
事業体向け
事業体
テナント
テナント
テナント
サービス
サービス

ベンダー向けベンダー向け
ベンダー
テナント
テナント
テナント
サービス
サービス

サーバサーバ

サーバサーバ

試験テナント
試験テナント
試験テナントサービス
サービス

共通テナント

事業体
テナント

ベンダー
テナント

試験テナント

サーバサーババックアップ
連携サービス

遠隔データセンター接続
共通テナントリージョン間DR

事業体
テナント

ベンダー
テナント

試験テナント

全テナントをバックアップ
共通テナント

サーバサーバ

事業体向け
事業体向け
事業体
テナント
テナント
テナント
サービス
サービス

ベンダー向けベンダー向け
ベンダー
テナント
テナント
テナント
サービス
サービス

サーバサーバ

サーバサーバ

試験テナント
試験テナント
試験テナントサービス
サービス

リアルタイムにデータレプリカを作成

リージョンＢ

サーバサーバ

図 3.2-10 ディザスターリカバリー構成

61 / 72

3.3. 想定するアプリケーションイメージ
プラットフォームで稼働するアプリケーションについては、アプリケーションベンダーの競争領域であり、一般的にはプラットフォームで標準的に提供するものではないが、プラットフォームの利用内容を具体的にイメージできるように、いくつか代表的なアプリ
ケーションの例を示す。

3.3.1. 浄水場・遠隔監視制御業務アプリケーション（例１）
特定の施設に向けて作成された浄水場・遠隔監視制御業務アプリケーションが、浄水場内に閉じて監視制御のシステムが構築されている場合、浄水場（現地）に行き、システムの画面を見ないと状況がわからない。しかし、水道標準プラットフォームによりデータが流通し、浄水場・遠隔監視制御業務アプリケーションが活用できることで、以下の効果が期待できる。

◆広域センター（拠点集約）で効率化しやすい。
・システム機能を集約して業務効率化
・既存メーカに関係のないデータ集約による事業体職員への情報提供◆モバイル端末等、場所を選ばない環境を提供できる。
・災害時など緊急時に、現場職員以外も状況確認可能（応援体制構築）

上記の例として複数の施設のデータを横断的に監視するアプリケーションのイメージを図 3.3-1 に示す。

図 3.3-1 浄水場・遠隔監視制御業務アプリケーション（例１）62 / 72

3.3.2. 浄水場・遠隔監視制御業務アプリケーション（例２）
事業体の集約・連携に伴い、複数施設の一元管理ニーズが高まった場合、監視対象浄水場の状況（運転、水運用、機械の状
況）の一括監視が期待される。このような状況に対し、本節の例は、複数の事業体の情報を一つのアプリケーションで、全体俯瞰
して確認できる画面の例である（図 3.3-2）。また、本アプリケーションの特徴を以下に挙げる。

◆監視対象の施設を全体俯瞰できる。
◆浄水場の運転状態が直感的に確認でき、異常個所を容易に特定できる。
◆水質情報など水運用の情報（配水量）及び機械の動作状況が一元監視・管理できる。
◆小規模事業体も含めて水質状況も一元的に監視し、水質維持業務に関する連携ができる。
◆クラウドにアクセスすれば、どこからでも確認可能に。
◆特に災害時には有効。

図 3.3-2 浄水場・遠隔監視制御業務アプリケーション（例２）3.3.3. 水運用需要予測業務アプリケーション
需要予測においては、曜日、祝日、天気、気温、降水量等の外部情報を考慮する必要があり、ベテラン職員の技術に寄るところが大きい。そのため、ベテラン職員退職による、業務継続性への懸念がある。
よって、水道情報活用システムを導入することで、ベテラン職員の技術をデータとして蓄積し、知見の共有や現場の支援に活用
し、少子高齢化に伴う人手不足への対応、ベテラン職員の知見共有に貢献が期待される。
このような背景を踏まえ、需要予測のアプリケーションの活用が考えれ、その画面例を図 3.3-3 に示す。また、本アプリケーションの特徴を以下に挙げる。

63 / 72

◆施設・設備の状況に加え、天候等の外部情報を収集、地図上に表示。
◆ベテラン職員のノウハウを抽出し、AI により需要量の予測値を算出 等。
◆従来の監視機能に、需要予測のみの機能追加としても可能なイメージ。

図 3.3-3 水運用需要予測業務アプリケーション

3.3.4. アセットマネジメント（施設統廃合）アプリケーション
施設のダウンサイジングは水道事業の改善に大きな効果をもたらす。しかし、施設統廃合計画の策定に必要なデータがバラバラに存在し、また様式が異なるため、データ集約・整理に手間がかかり、なかなか検討が進まないことがある。
システムの導入により、以下の効果が期待される。

◆施設統廃合計画の策定に必要なデータを一元的に把握することで、施設統廃合計画を作成する時間を短縮する。
◆これにより、広域化を視野に入れた施設の統廃合を加速し、将来投資の削減に貢献。

このようなニーズに対するセットマネジメント（施設統廃合）アプリケーション画面の例として図 3.3-4 を示す。

図 3.3-4 アセットマネジメント（施設統廃合）アプリケーション

64 / 72

3.3.5. 施設台帳アプリケーション
施設台帳は水道法改正により、義務化されたように、以下のような水道事業の改善には欠かせない基盤的な情報となる。

◆小規模事業体への支援◆維持管理基準の見直し・統一◆長寿命化計画の立案促進◆更新計画の立案促進

こうした情報は事業体間で共有することにより、以下のようなメリットがある（図 3.3-5）。

◆台帳システムが同じため、中核事業体のノウハウをベースに他事業体を支援しやすくなる。
◆小規模事業体は支援が受けられ、事業体全体の台帳整備が進む。
◆広域事業体全体の台帳データが統一的に整備され更新計画立案が進む。

広域事業体全体でシェアリング
CPSプラットホーム

水道施設台帳システム（共同利用型）
A事業体(中核都市）

B事業体
（中規模）

a浄水場

b浄水場

C事業体

D事業体

（小規模事業体）（小規模事業体）

c浄水場

d浄水場
データ項目
検討支援

データ
入力支援

入力業務
包括委託

作業

作業

作業

作業

図 3.3-5 施設台帳アプリケーション

また、データ項目の検討やデータ入力に当たり、維持管理上のノウハウが求められるが、事業体同士が連携することにより、効
果的・効率的に台帳整備を進めることが可能と考えられる。

65 / 72

施設台帳データの一例
N
o

施設名

設置年

法定耐
用年数

耐用年数
満了年

補助

維持修繕
限度年

・・・

1

浄水監視
システム

2001年

15年

2016年

01

2021年

・・・

2

GISシステ
ム

2001年

10年

2011年

02

2016年

・・・

3

第１ポン
プ

2001年

30年

2031年

03

2051年

・・・

4

・・・・

-

-

-

-

-

・・・

維持管理費

更新
費用
算定
へ

2011年 2012年 ・・・ 2016年
維持管理費

5

設備更新数

0
2011年 2012年 ・・・ 2016年
更新設備数

設備償還がいくつあるか確認

図 3.3-6 施設台帳データの一例

66 / 72

第4章

プロセス編

本編では、水道情報活用システム整備に関する計画から導入、保守に至るプロセスを説明する。

リファレンスアーキテクチャ仕様書
コンセプト編
水道標準プラットフォームのアーキテクチャ設計に対する要求事項、および、設計のコンセプトを説明

カタログ編

プロセス編

水道標準プラットフォームが提供するサービスメニューを説明

水道情報活用システム整備に関する計画から導入、保守に至るプロセスを説明

67 / 72

4.1. プラットフォームの提供の仕方
プラットフォームサービスの提供の仕方としては以下の２通りが想定される。しかし、費用の 「割り勘効果」 を最大化するためには、共同利用を比較的大きな規模で実施することが望ましいため、共同利用型での提供を主体とする。

A. 共同利用型
様々な事業体が共同でプラットフォームの各テナントを活用して、ベンダーのシステムの提供を受けたり、自身に必要なシステムを配置することができるものであり、ベンダーは、このプラットフォームにおいて、事業体向けの各種システムを提供し、プラットフォームと連携して維持される。

B. プライベート利用型
標準仕様書に準拠して開発したプラットフォームの部品や各テナントを、当該事業体のためにプライベート型のプラットフォームとして個別に整備するものであり、ベンダーは、この整備されたプットフォームに事業体の要望する各種システ
ムを提供することができる。

4.2. 想定するプロセスについて
プラットフォームのサービス提供は、以下の３段階に分けることができる。

１．計画プロセス
更新・新設するシステム対象について、以下項目の検討を実施し、予算化するプロセス。

◆更新・新設するシステム概要◆導入スケジュール◆既存設備の改修内容◆導入・ランニング(運用保守）費用

２．導入プロセス
導入（運用保守含む）に関する調達仕様を提示し入札をして、当該システムを提供するベンダーを確定させ、プラットフォーム上にシステム導入を進めるプロセスであり、必要な既存改造などは別調達で実施する。

◆導入に関する調達仕様書◆保守に関する調達仕様書◆既存の改修仕様書

68 / 72

３．運用保守プロセス
導入(運用保守含む）に関する段取りにおいて、入札でベンダーを決定された事を踏まえ、運用保守の内容を承認し、運用保守に関する契約をして運用保守をスタートするプロセスであり、プラットフォームとベンダーとの契約を前提に、事業体はプラットフォームと保守契約を実施しサービスを受ける。

各プロセスにおける実施主体としては、計画及び導入についてはベンダーが主体で事業体に対する対応を進める。一方で、運用保守ではプラットフォームが窓口となりベンダーと連携して進める。それぞれのプロセスにおける関係者の役割を図 4.2-1 に示す。

１．計画プロセスにおける関係者図

２．導入プロセスにおける関係者図

３．運用保守プロセスにおける関係者図 事業体の要求に対して、ベンダー各社が事業体に対して行う（導入マニュアル等を活用）。
 プラットフォームは、各ベンダーへPFの情報（サービス内容や価格）を提示し、ベンダーの導入・ランニングに関する提案活動を支援する。

 入札で契約したベンダーが、事業体とシステム導入検討を進める。（導入仕様と保守仕様は確定され、契約ベンダーが具体な仕様調整する）
 プラットフォームは、ベンダーを支援・フォローし構築の試験をして、運用保守の準備をする。

■契約ベンダーと運用保守内容について詳細な提案を受け承認をした上で以下のとおり、プラットフォームが事業体との運用保守窓口を行う。
■プラットフォームとベンダーは個別に運用保守契約を行う。

事業体

事業体

事業体

導入契約・導入業務実施
平行して運用保守の仕様調整実施

運用保守契約 サービス提供実施

提案

提案

提案

Aベンダー Bベンダー Cベンダー

プラットフォーム
契約ベンダーの窓口
該当分の運用保守契約

PFの情報を提供

構築

導入契約

プラットフォーム

ベンダーの開発・工場・
工事部門

プラットフォーム
サービス支援契約ベンダーの窓口
契約ベンダーの開発・工場・
工事部門

契約該当分の運用保守
サービス

図 4.2-1 各プロセスにおける関係者の役割

4.3. 各プロセスの概要
4.3.1. 計画プロセス
本プロセスは、導入するシステム(アプリケーションやＧＷ及びその他）の要件を検討し、必要な予算・導入スケジュールを確定することを想定したプロセスであり、以下の３ステップから構成される（図 4.3-1）。

69 / 72

１．更新（新整備）するシステムの概要を決める
プラットフォームが提供する導入マニュアル・調達仕様書(雛型)等を元に、システムの要求事項・導入スケジュールなどのシステムについての要件を取り纏める。

２．システムの概要を元にベンダーからの提案を受ける取り纏めたシステムの要件を元に、ベンダーからの仕様などの提案・概算見積回答(導入・ランニング）を受ける。

◆プラットフォームの調達仕様書（案）を元に具体な内容の提案を受ける。
◆ベンダーはプラットフォームに必要な問い合わせや提案を実施し仕様・費用を提示する。

なお上記検討業務を、コンサルタントなどに委託して実施することも想定する。

３．予算・計画を決める
ベンダーからの提案などを元に以下をまとめる。

◆更新・新設するシステム概要仕様◆導入スケジュール◆既存設備の改修内容◆導入・ランニング(運用保守）費用

上記を定め、計画プロセスを終了する。

更新（新整備）するシステムの概要を決める

左記の概要を元にベンダーからの提案を受ける

 導入したいシステムの概要を決める。
→プラットフォームが提供する導入マニュアル・調達仕様書(雛型)等を元に、システムの要求事項・導入スケジュールなどのシステムについての要件を取り纏める。

 左記で取り纏めたシステムの要件を元に、ベンダーからの仕様などの提案・概算見
積回答(導入・ランニング）を受ける。
→プラットフォームの調達仕様書（案）を元に具体な内容の提案を受ける。
→ベンダーはプラットフォームに必要な問い合わせを提案を実施し仕様・費用を提示する

図 4.3-1 計画プロセスの内容

70 / 72

予算・計画を決める
 ベンダーからの提案などを元に以下をまとめる。
「更新・新設するシステム概要仕様」「導入スケジュール」「既存設備の改修内容」「導入・ランニング(運用保守）費用」

を定め計画プロセスを終了する

4.3.2. 導入プロセス
本プロセスは、導入及び保守も含めた調達仕様書を作成し、入札を行い、業者を選定し、導入を進めることを想定したプロセスであり、以下の３ステップから構成される（図 4.3-2）。

１．入札に向けた調達仕様書を作成する
入札のための調達仕様書や予算を確定する。なおライフサイクルコストとして、導入及びランニングに関する費用の提示を求めることを前提とする。
◆計画プロセスで入手した調達仕様に関するベンダーからの意見・情報元に、調達仕様書や契約内容を定める。
◆調達仕様書については導入・運用保守の内容も含む。

２．入札・ベンダーを決める
取り纏めた調達仕様書や予算情報を用いて、入札を行い、業者の提案内容・見積(導入・ランニング）の評価をして、業者を選定する。

３．導入をする
落札ベンダーと契約し、調達仕様書を元にプラットフォームにシステム・アプリケーションの導入を進める。
既存設備の改造の発注もあわせて行う。本ステップでは、導入打合せと平行して、運用保守に関する具体的な事項を決定して、運用保守の契約を実施することを想定している。

入札に向けた
調達仕様書を作成する
 入札のための調達仕様書や予算を確定する。
→計画プロセスで入手した調達仕様に関するベンダーからの意見・情報元に、調達仕様書や契約内容を定める。
→なお調達仕様書については導入・運用保守の内容も含む

入札・ベンダーを決める

導入をする 左記の調達仕様書や予算情報を用いて、入札を行い、業者の提案内容・見積(導入・ランニング）の評
価をして、業者を選定する。

 落札ベンダーと契約し、調達仕様書を元にプラット
フォームにシステム・アプリ
ケーションの導入を進める。
 既存設備の改造の発注もあわせて行う。
＜注＞導入打合せと平行して、運用保守に関する具体的な事項を決定して、運用保守の契約を実施することを想定(次頁以降へ）入札箱

図 4.3-2 導入プロセスの内容

71 / 72

4.3.3. 運用保守プロセス
導入プロセスの入札での契約ベンダー確定のプロセスと連携して、運用保守をスタートするためのプロセスを想定した。
プロセスとしては、以下の２ステップから構成される（図 4.3-3）。

１．運用保守の仕様打合わせを実施
入札での運用保守作業仕様や提示された金額を元に、ベンダーからの具体な運用保守内容の提案を受け、承認する。プラット
フォームに関する仕様決定についてはベンダーとプラットフォームが連携して実施する。

２．運用保守に関する PF とベンダーで契約を実施
プラットフォームとベンダーと分担を決定した運用保守仕様を元に契約を結ぶ。
上記を踏まえて運用保守仕様が決定した後、プラットフォームと事業体の契約を結ぶ。

以上のステップにより、運用保守契約をスタートし、プラットフォームを窓口にした運用保守を開始する。

（導入プロセス中）運用保守を仕様打合わせを実施する（導入プロセス中）運用保守に関するPFとベンダーで契約を実施する

 入札での運用保守作業仕様や提示された金額を元に、ベンダーからの具体な運用保守内容の提案を受け、承認する。
→プラットフォームに関する仕様決定についてはベンダーとプラッ
トフォームが連携して実施する プラットフォームとベンダーと分担を決定した運用保守仕様を元に契約を結ぶ
 上記を踏まえて運用保守仕様が決定した後、プラットフォームと事業体の契約を結ぶ

図 4.3-3 運用保守プロセスの内容

72 / 72

運用保守契約をスタート プラットフォームを窓口にした運用保守を開始する。