共通データ環境（CDE）覚え書き
2026.08.04
パラメトリック・ボイス 芝浦工業大学 志手一哉
はじめに
ここのところ、共通データ環境（CDE：Common Data Environment）について考えること
があり、その中で「なるほど、そうか」と腹に落ちたことがいくつかある。ここで提示する内
容が絶対唯一の正解というわけではないかもしれないが、これから述べる考え方に違和感がな
ければ、日本の建設業界の商習慣や実務に適したアプローチとして文章化しておくことには
十分な意義があると考えている。それは、現状の日本のやり方に合わせてCDEを解釈しようと
いう話ではない。むしろ「CDEというフレームワークをこのように捉えれば、我々の日々の実
務にスムーズに応用できるのではないか」という視点からの整理である。そのような意図を込
めて、あえてタイトルを「覚え書き」とした。
ISO 19650におけるCDEの基本構造
BIMをはじめとする建物情報マネジメントの国際規格である「ISO 19650シリーズ」に関心の
ある方々には釈迦に説法となるが、CDEとは本来、クラウド環境でのデータ連携を前提とした
建設プロセスにおける情報管理の基礎的な概念・仕組みである。このワークフローでは、情報
やファイルが置かれている状態（ステータス）を以下の4つに分類している。保管（ARCHIVE）
を除く3つのステータス間には、「検問作業（ゲート）」が配置されている。この関所での
チェックを通過し、「承認」や「正式な許可」を得ない限り、ファイルを次のステータスへと
昇格させることはできない。
● 作業中（WIP：WORK IN PROGRESS）：各担当チームが日常的な作業・作成を行ってい
る段階。
● 共有（SHARED）：他チームとの調整や各種チェックのために情報を開示した段階。
● 発行（PUBLISHED）：正本として正式に許可され、公式な参照・利用が可能となった段階。
● 保管（ARCHIVE）：過去の記録や履歴として参照用に保持される段階。
生産設計の現場に当てはめて考えてみる
このCDEのワークフローは、施工段階における生産設計（施工図・製作図作成）のシチュエー
ションに当てはめてみると、具体的にイメージしやすい。現場の作業所に設置された施工図室
をはじめ、設備・電気などの各サブコン、鉄骨やPCなどのファブリケーター、サッシや建具等
のメーカー各社は、それぞれ独立した「タスクチーム」として作業を進める。各チームは、自
らのタスクに最も適したソフトウェアを選定して作業を行うが、この状態が「作業中（WIP）」
に該当する。
施工図や製作図を起こすにあたり、全チームが共通して参照すべきベースとなるのは、発注者
とゼネコンが工事請負契約を結んだ根拠である「契約用設計図書」である。この設計図書の所
有権は発注者にあり、すでに完成版として発注者承認を経たものであるため、CDE上では「発
行（PUBLISHED）」に格納されている。PUBLISHEDにあるデータは、A工事・B工事・C工事
といった担当範囲や立場の違いを問わず、建設工事に関わるすべての関係者がいつでも公式に
閲覧・入手できる状態になっていなければならない。
各タスクチームが作成した施工図や製作図は、チーム内での社内チェックや一次レビュー、社
内承認を経て、ゼネコンへ提出される。ゼネコン側は、提出された施工図、製作図、躯体図を
相互に重ね合わせ、意匠・構造・設備の納まりや干渉、施工性を総合的に確認する。この相互
確認や整合性チェックを行う場が「共有（SHARED）」である。SHAREDにおけるフォルダ構
成はプロジェクトの特性に応じて柔軟でよく、工事別（チーム別）に設けるケースもあれば、
建物の部位や階数別に設けるパターンも考えられる。チェックの結果、干渉や修正点が見つ
かったファイルはWIPに戻されて再作業となる。一方でチェックを通過したファイルあるいは
ファイル群は、設計者の確認および発注者（またはその代行者）の承認を経て、公式な
PUBLISHEDへと移行する。PUBLISHEDに移動したデータは承認済みの完成版として扱われ
るが、もしその後に設計変更が生じた場合は、再びWIPに戻されて改訂作業のサイクルを回す
ことになる。
運用を支えるルール作り
SHAREDの領域で共有・交わされるフォルダやファイルの数は、工事が本格化するにつれて膨
大な量に膨れ上がる。そのため、誰がいつ見てもファイル名やフォルダ名を見るだけで「それ
が何のデータか」「最新バージョンなのかどうか」を判別できるよう、命名規則（ネーミング
ルール）を事前に確立して守ることが不可欠である。
さらに、保管するファイルフォーマットに関するルール設定も重要な鍵となる。
SHARED用の形式：干渉チェックや納まり調整、重ね合わせレビューがスムーズに行える
フォーマットであること。
PUBLISHED用の形式：そのデータを必要とする発注者・設計者・現場担当者・職方・直営
工事など、幅広い関係者が閲覧・利用できるフォーマットであること。
目的やステータスに応じた適切なフォーマット定義がなされていると、CDEは滑らかに機能
する。
フェーズに応じたサイクルと「中間領域」の工夫
こうしたCDEのワークフローは、一度回して終わりではない。設計・施工プロセスの各段階で
サイクルが繰り返し回される。たとえば設計段階においては、基本設計や実施設計、あるいは
それらを分割したステージのマイルストーンとして実施されるDR（デザインレビュー）が完
了することによってCDEワークフローのサイクルが1回まわる。ただし実務上、DRを通過した
時点のデータがすぐに最終確定版（PUBLISHED）にならないケースも多い。そのため、
SHAREDとPUBLISHEDの間に「チェック完了済み」といった中間ステータス（一時保管領域）
を設けると便利である。
また施工フェーズにおける躯体図、施工図、製作図の作成に関しても、建物全体を一括で回す
のではなく、実質的にはフロア単位や製品単位でこのサイクルを回していく。このように整理
されたデータ共有環境を構築し、全員が共通ルールを遵守して、適切なアクセス権で運用して
いれば、「過去の古い図面を参照して作業してしまう」「改訂前の旧図面でファブリケーター
が製作に着手してしまう」といった、建設現場で最も避けたい間違いや手戻りを無くすことが
できる。
WIPの自由度とマルチツールの受容
一方で、最も上流にあたる「作業中（WIP）」の領域に目を向けると、ここは各タスクチーム
の専門性が発揮される場である。したがって、WIP内では各チームが自らの業務効率を最大化
できるソフトウェアを自由に選定し、そのネイティブフォーマットのままチーム内で管理する
のが最も合理的である。そうしないと、解析、積算、制作に各者の設計データを上手く使えな
い。一方、同じソフトウェアを使うタスクチーム同士では、データを相互にリンクしたり
1ファイルで協業したりするケースもあろう。
ここで強調したいのは、WIP、SHARED、PUBLISHEDという各エリアを具現化するにあたり、
それらを単一のシステムやクラウドツールに統一する必要はないという点だ。各CDEツールの
設置者や管理プラットフォームが別々であっても構わない。また、CDEとしての運用の作法や
アクセスルールが徹底されていれば、データがBIMモデルであれ、従来の2D CAD図面であれ、
それらが混在したハイブリッドな環境であっても理に適った形で十分に成立する。
CDEの本質とは
CDEと聞くと、何か非常に高価な統合ITシステムを導入しなければならないような錯覚に陥り
がちだが、決してそうではない。結局のところ、CDEの本質は「関係者が古い情報や誤った
バージョンで作業を進めてしまわないための、確実な仕組みと運用ルールを構築すること」に
他ならない。複雑に思えるISO 19650の考え方も、我々の日々の現場実務や生産設計のプロセ
スに引き寄せて整理してみれば、きわめて合理的で自然な「整理整頓の作法」であることが見
えてくる。この「覚え書き」が、日本の建設現場における情報マネジメントの普及の一助とな
れば幸いである。
