![]()
三色○○のCDE
~建物ライフサイクルマネジメントの情報基盤
2026.08.06
パラメトリック・ボイス NTTファシリティーズ 松岡辰郎
長期間にわたる建物ライフサイクルマネジメントでは建物に関する様々な情報が参照・利用さ
れる。必要とされる建物情報は建物の種類や利用目的、運営方針に左右される。当然ながら新
築から竣工を経て撤去に至る長い時間の中で常に同じ建物情報が求められるわけではなく、建
物の状態、事業方針、改修や用途変更といった各種のイベントや建物のあるべき姿を求める社
会的環境の変化によっても変わり続ける。
建物ライフサイクルマネジメントの始点が新たに建物を建てる場合、一般的には竣工というイ
ベントの前後で必要とされる建物情報も、それらを共有するステークホルダーも大きく変化す
る。とはいえ竣工後に建設プロセスでの建物情報が不要になるわけではなく、維持管理やファ
シリティマネジメントを含む建物運営に関する情報が追加されるということになる。一方、既
存の建物を対象とした建物ライフサイクルマネジメントを導入する場合は、その時点での建物
の状態と新築時からの時系列的な点検・診断や改修をはじめとする様々な履歴を情報として可
能な限り収集し、現状把握や課題抽出から建物の運営方針が策定される。
建物ライフサイクルマネジメントで建物情報を利用する目的は、建物を様々な視点からデータ
化し現状把握や課題抽出、意思決定と意思伝達、施策策定と将来予測をより高精度かつ容易に
実現することにある。建物情報の種類や形態は様々であり、それらのシームレスな連携と参照
が求められる。同時に情報としての信頼性と整合性の確保も必須となる。このような情報の整
合性確保と情報収集・参照コストを低減する手段の一つとして、形状情報と属性情報を連携さ
せるBIMが注目されてきたことはご存じのとおりである。
BIMモデルをはじめとする建物情報を関係者で共有する手段として、CDE(Common Data
Environment)の利用が有効であることはよく知られているところだろう。最近はMCP(Model
Context Protocol)サーバを介したAIとの連携も急速に進んでいる。改めて建物ライフサイク
ルマネジメントにおける今後のCDEの姿について考える時期に来ているのではないかと思って
いる。
建設プロジェクトでのCDEは、設計・監理・施工といった建築生産者と発注者の間で建物情報
を共有する基盤、と捉えることができる。建物情報は意匠・構造・設備等の異なる技術領域間
で共有され、建物総体としての最適化や刻々と変化する状況への対応、適正な意思伝達と迅速
な意思決定、発注者や関係者間での合意形成を実現する、脈動するダイナミックな情報活用の
場としての姿を思い浮かべることができる。
一方、建物ライフサイクルマネジメントのCDEは建設のそれとは少々異なる世界観を持つ必要
があるように思う。まず対象とする建物の数があげられる。一概にはいえないが建物は事業や
アクティビティのツールであり、企業や組織の資産や経営資源でもある。所有または使用する
建物が複数であれば、それらを網羅的に運営し管理をする必要がある。そのためには複数建物
を群として集約し横断的な評価・分析と整備計画策定を可能とする、広い情報空間が必要とな
る。また、既存建物が管理対象となることから、建物の現状を表す情報が必要となる。これを
デジタルツインと表現しても良いが、複数の建物情報を横断的に管理することから、ここでは
データベースの視点でマスタデータと呼ぶことにする。敷地や建物の基本スペックを表す概要
情報、個々の建物の姿を表す現況BIMと現況図、各部位・機器の性能諸元情報、写真や画像等
の非言語情報、各種ドキュメント等を集約したものが建物ライフサイクルマネジメントにおけ
るマスタデータと位置付けられる。マスタデータは基準となる建物情報として、建物ライフサ
イクルマネジメントの全ての関係者が参照・利用できるよう共有される。
長期間にわたる建物の運営期間では、建物は点検・診断の対象となるだけでなく、それらに基
づく修繕や事業方針の変更による改修、増減築やリノベーションといったイベントによって変
更が加えられる。既存建物を改修する場合も建設プロジェクトと同様に、建築生産に関する建
物情報をプロジェクト関係者や発注者で共有し、適正な意思伝達と意思決定を実現する。ダイ
ナミックに変化する複数建物のプロジェクト情報をステークホルダーで共有し協働する場は、
大量のデータ管理の視点ではデータレイクであると言える。
建物の状況を評価・分析することによる現状把握と課題抽出とそれに基づく改修や修繕を検討
する場合、建物がこれまでどのように作られ、使われ、手を加えられてきたか、という履歴情
報は重要な手掛かりとなる。履歴情報には建物が建てられた際の設計図書や各種の届出、工事
の情報といったものから、竣工後の点検や維持管理の実績、これまで実施された改修工事や修
繕、建物がどのように運用・利用されてきたかといった過去のイベントや光熱水コスト等の記
録まで広範囲なものが含まれる。時系列的な情報を含んでいるため、マスタデータとは別の視
点で建物を評価・分析することができるとともに、傾向分析や将来予測の素材としても活用が
期待できる。履歴情報は時間と共に追加・蓄積されるが、マスタデータやデータレイクのよう
に継続的な変更は加えられないので、データウェアハウスと見ることができる。
建物ライフサイクルマネジメントにおいて、既存建物に対する点検や診断、改修や修繕、さら
には経営や事業の方針に基づく運営計画の変更を策定する場合、マスタデータの現況情報を用
いて現状把握を行い、データウェアハウスの履歴情報から課題やあるべき姿を設定し、マスタ
データから派生させた建物情報をデータレイクで設計・施工情報として活用する。工事が完了
したら建物の変更箇所をマスタデータに反映させ現況情報を現行化すると共に、プロジェクト
の記録を履歴情報としてデータウェアハウスに追加・蓄積する。
このように建物ライフサイクルマネジメントのためのCDEは、多数の建物情報を群として扱う
ことができる情報空間に、マスタデータ、データレイク、データウェアハウスがそれぞれ明確
な役割を分担して共存し、建物情報がそれらを横断的に流通する情報基盤の姿となる。
今回、建物ライフサイクルマネジメントのCDEの概念を簡単に表現する方法をあれこれ考えて
いる時、某生成AIに相談をしてみた。その結果「3色○○」で表現してみてはどうか?という
提案を受けることとなった。どれも秀逸で感心したので、蛇足だがいくつかの案を載せてみる
ことにする。他にも色々な視点でイメージを描いてみると考えやすいかもしれない。
1.三色団子(3つの独立したデータ環境が、CDEという一本の串で貫かれることで、連携し
ているイメージ)
・マスタデータ 「白(プレーン)」:すべての基準であり混じり気のない正統なデータ。
味の土台となる中心的な存在
・データレイク 「緑(よもぎ)」:自然そのまま素材そのものの状態(生データ)を表現。
雑多でエネルギーに満ちたデータの溜まり場
・データウェアハウス 「ピンク(桜)」:きれいに着色・加工され見た目も華やかで、すぐ
に「消費(分析・利用)」できる状態に整えられたデータ
2.三色ゼリー・ムース(下から上へとデータが洗練されていく「データパイプライン」の美
しさを、グラスの断面(レイヤ)で視覚的に説明するイメージ)
・下層:データレイク 「あずき・濃い色の層」: 一番底にどっしりと溜まっている手つかず
の生データ。あらゆる素材がそのまま沈殿しているイメージ
・中層:マスタデータ 「ミルク・白の層」: 上下のデータを結びつけ、全体の一貫性を保つ
ための「基準」となるクリアな層。
・上層:データウェアハウス 「抹茶やフルーツ・鮮やかな層」: 洗練され、すくい取ってす
ぐに美味しく食べられる(意思決定に使える)最上層のデータ
3.三色丼(そぼろ丼)(CDEという1つの器の中で、それぞれが異なるアプローチで全体を
支えている「適材適所」を表現)
・マスタデータ 「さやえんどう(緑)」: 量は多くないものの形が決まっており、全体の
「軸・基準」として見栄えを引き締める役割
・データレイク 「鶏そぼろ(茶)」: 細かくて大量にあり、形も不揃いなデータがぎっしり
と詰まっているイメージ(テキスト、画像、3Dモデルなどの雑多さ)
・データウェアハウス 「炒り卵(黄)」: 手を加えてフワフワに扱いやすくし、誰もが喜ぶ
形に加工された栄養(インサイト)の宝庫




























