ISO 19650 Part 1徹底解説：CDE（共通データ環境）の4つの状態と情報マネジメントの基本概念

連載第2回となる今回は、ISO 19650の土台となる「Part 1：概念と原則」にスポットを当てます。
第1回で紹介した全体像を踏まえ、ISO 19650の心臓部である「CDE（共通データ環境）」の仕組み、関係者の役割、一意の識別規則やメタデータ管理、そして実務において混同しやすい重要概念まで徹底的に解説します。
この記事を読めば、ISO 19650の原文が意図する「情報マネジメントの真髄」がすべてクリアに理解できます。

ISO 19650 Part 1の役割と基本思想

ISO 19650-1（Part 1）は、規格全体の「辞書」であり「憲法」にあたる存在です。
プロジェクトに参加する発注者、設計者、施工者、維持管理事業者が、ライフサイクル全体を通じて共通の言語と原則で対話できるようにするための概念的枠組みを提示しています。

まず、Part 1の基本思想を支える極めて重要な3つの概念を整理しましょう。

① 情報プロバイダー（Information Provider）と情報レシーバー（Information Receiver）

ISO 19650の情報管理は、常に「情報の送り手（Provider）」と「情報の受け手（Receiver）」の双方向関係として定義されます。

情報プロバイダー
情報を生産し、提供する側（例：設計を納品する設計者、竣工図書を提出する施工者）。

情報レシーバー
情報を要求し、受領する側（例：設計成果物をチェックする発注者、下請けのデータを統合する元請け）。

実務では、この役割は固定されません。例えば、元請けは、発注者に対しては「プロバイダー」ですが、協力会社に対しては「レシーバー」となります。この双方向の責任を明確にすることが、情報管理の第一歩です。

② プロジェクトの「情報基準」と「情報生産方法および手順」

発注者（Appointing Party）は、実際のプロジェクト作業が始まる前に、以下の2つのルールブックをあらかじめ規定し、プロジェクト全体に提示しなければなりません。

プロジェクト情報基準（Project's Information Standard）
ファイル命名規則、コード体系、データフォーマットなどの「成果物の共通ルール」を定めたもの。

プロジェクト情報生産方法および手順（Project's Information Production Methods and Procedures）
BIMソフトの使い方、干渉チェックの手順、データの承認フローなど「作業のプロセス」を規定したもの。

これらは単なるガイドラインではなく、すべての情報コンテナ（ファイル）の品質を決定する大前提となります。

③ 情報プロトコル（Information Protocol）

どれほど優れた基準を整備しても、法的強制力がなければ実務では形骸化してしまいます。そこで、ISO 19650では「情報プロトコル」と呼ばれる合意文書を、プロジェクトに関わるすべての契約（Appointment：任命）に組み込むことを義務付けています。
これにより、情報管理基準（EIRなど）への準拠が「契約上の義務」となり、実務面および法律・商務面で裏付けられた情報管理体制が実現します。

ISO 19650の心臓部「CDE（共通データ環境）」の真実

ISO 19650において、最も頻繁に登場し、最も重要な仕組みがCDE（Common Data Environment：共通データ環境）です。

CDE＝単一のクラウドプラットフォームではない

実務で最も多い誤解は「CDE＝1つのクラウドストレージを全員で使うこと」という思い込みです。 規格におけるCDEは、プロジェクトの情報を一元管理する「技術的ソリューション（CDE Solution）」と「プロセスのルール（CDE Workflow）」の組み合わせを指します。

現実のプロジェクトでは、全員が同じ1つのクラウド（例：発注者が用意したシステム）の内部だけで全作業を行うことは不可能です。下請けや元請けは、自社内の機密事項や未成熟なデータを他社に見られずに編集する「自分たちの領域」を必要とするからです。

そのため、ISO 19650では複数のCDEが連動する「CDEエコシステム（分散型CDE）」の構築が一般的です。

発注者CDE（Client-CDE）
発注者が所有・運用し、公式成果物を受け取るための最終プラットフォーム。

受託者CDE（Contractor-CDE / Distributed CDE）
元請けや施工者が、日々の社内作業やサブサプライチェーン内での共同作業のために自ら管理・運用するプラットフォーム。

これら複数のCDE間で、情報が規格に準拠したルール（メタデータマッピングや統合プロセス）に沿ってスムーズに受け渡される状態こそが、真のCDEエコシステムです。

CDEにおける「4つの情報状態」と厳密なデータ遷移

ISO 19650-1では、CDE内のすべての情報コンテナ（3Dモデルファイル、2D図面PDF、計算書Excel、仕様書Wordなど）を以下の4つの状態（状態コンテナ）に明確に区分して管理します。

 [作業中 (WIP)]
       │
       ▼ (QAチェック & 技術レビュー)
 [共 有 (Shared)] ────────┐
       │                 ▼ (承認・配信プロセス)
       │           [公 開 (Published)]
       │                 │
       └───────► [記録/保存 (Archived)] ◄──────┘
               (すべての状態遷移を継続的にアーカイブ)

① 作業中（WIP：Work in Progress）

• 概要
  • 各担当チーム（意匠、構造、設備など）が内部で作成・編集している未完成・検討段階の情報。
• ルール
  • 唯一編集（書き込み・修正）が可能な状態です。 他のタスクチームや発注者からは完全に隠蔽・アクセス制限され、自チーム内だけで管理されます。未承認の「ブレスト段階のモデル」が現場に誤流出するのを防ぎます。

② 共有（Shared）

• 概要
  • チーム内での品質確認を経て、他チームとの共同作業（干渉チェックや意匠調整など）や、発注者へのプレビューのために公開された情報。
• ルール
  • 他チームはこれを参照（閲覧、リンク、フェデレーション）できますが、直接書き換えることはできません（読み取り専用）。 修正が必要な場合は、必ず一度WIP状態に戻し、原著作者が修正を行ってから再度「共有」に昇格させます。

③ 公開（Published）

• 概要
  • 発注者やプロジェクト責任者の最終的な技術・商務レビューをクリアし、契約上の公式成果物として承認された情報。
• ルール
  • 確認申請、調達、現場での施工、維持管理で正式に使用される「信頼性100%」の決定版データです。当然、読み取り専用で保護されます。

④ 記録/保存（Archived）

• 概要
  • 過去の全開発履歴、承認履歴、および確定した最終成果物の取引履歴（トランザクション）を記録したブラックボックス。
• ルール
  • 意思決定の履歴をすべて追跡（トレーサビリティの確保）できるようにし、紛争防止や将来の修繕時の監査ログに役立てます。CDEの運用中、各状態間の遷移（いつ・誰がチェックし承認したかなど）は常に自動的かつ継続的にアーカイブされます。

実務で混乱を極める「2つの超重要ルール」：命名規則とメタデータ

BIM実務者がCDEを構築・運用する際、最も多く挫折するのが「命名規則（一意のID）」と「メタデータ属性」の混同、および「バージョン」と「リビジョン」の誤用です。ここを規格の定義に従って厳密に整理します。

ルール1：「一意のID」と「メタデータ」の完全な分離

実務でよくある最悪の失敗は、以下のようにファイル名の中に遷移する情報（ステータスや修正回数）を盛り込んでしまうことです。

• ❌ NG例: 図面A_リビジョン02_共有S1.pdf

これを行うと、ステータスが変わるたびにファイル名が変わり、CDE内で重複ファイルや無効リンクが大量発生します。 ISO 19650では、以下のルールを貫きます。

一意のID（Unique ID）は不変
ファイル名（命名規則）は、プロジェクトを通じて完全に不変な「一意の識別子」とします。

• 例: [プロジェクトコード]-[作成者]-[ゾーン]-[レベル]-[種別]-[役割]-[連番]

変化する情報は「メタデータ（属性タグ）」としてCDEで管理
「状態（State）」「ステータス（Status：適合性コード）」「リビジョン（Revision）」などの動的なパラメータは、ファイル名ではなく、CDEのシステム上で「メタデータ（属性）」として付与します。

CDE内でのステータスの昇格（例：SharedからPublishedへ）は、「ファイル名は一切変えず、属性タグだけを書き換える」ことによって行うのがISO 19650の絶対原則です。

ルール2：「バージョン（Version）」と「リビジョン（Revision）」の厳密な使い分け

BIMマネージャーとして知っておくべき、進行履歴の2段階管理です。英国ナショナルアネックス（BS EN ISO 19650-2）に代表されるベストプラクティスに基づきます。

• バージョン（WIP内管理、小数点以下）: 自タスクチーム内（WIP状態）での編集中の履歴。P01.01、P01.02 のように小数点以下でトラッキングします。これは自チームの編集者だけに見え、作業ミス時のロールバック用としてCDEが自動記録します。
• リビジョン（外部共有用、整数）: 他チームへ「共有（Shared）」または「公開（Published）」する際に確定する、外部向けの正式な版管理。
  • preliminary（暫定版）
    • 契約合意前のデータ（Sharedなど）は、プレフィックス P に整数2桁で示します（例：P01、P02）。
  • contractual（契約確定版）
    • 発注者に承認され「公開（Published）」されたデータは、プレフィックス C に整数2桁で示します（例：C01、C02）。

このように、P01.05（WIPで5回目の修正）から、他チームに見せるために共有する瞬間に小数点以下を切り落として P01（正式な共有初版）へと変換します。

CDEのワークフローを動かす「ステータス（適合性）コード」

CDEにアップロードされたファイルに「Shared」属性を付与するだけでは、他チームは「この図面を何に使ってよいのか」判断できません。そこで、情報の「許可された用途」を明示する「ステータスコード（適合性コード）」をメタデータとして割り当てます。

これにより、CDE内で「意匠用フォルダ」「構造用フォルダ」のように物理的にフォルダを分けなくても、メタデータだけで厳密なアクセス制御と誤利用の防止が可能になります。

代表的な標準ステータスコード一覧（BS EN ISO 19650-2に基づく例）

WIPからSharedへの昇格時に必ず通る「2つのゲート」

情報コンテナをWIPからSharedへ移行させる際、担当チームは1つのチェックではなく、必ず以下の「2つの独立した検証段階」を踏む必要があります。

QAチェック（品質保証：ラッパーの検証）
ファイル命名規則（一意のID）が合っているか、適切なメタデータ属性が正しく選択されているかなど、情報コンテナの「外郭（ wrapper）」を検証するステップ。システムによる自動検証が可能です。

技術レビュー（内容検証）
図面の表現が合っているか、設計基準を満たしているか、不整合がないかなど、情報コンテナの「中身（設計品質）」を人間（BIMマネージャーなど）が専門的に検証するステップ。

押さえておきたい基本用語：情報要求の階層（OIR/AIR/PIR/EIR）

ISO 19650では、発注者が受注者に対して「何の情報が欲しいか」を論理的かつ段階的に定義するルールがあります。これを「情報要求（Information Requirements）」と呼びます。

【実例ストーリー】OIR / PIR / AIR が EIR（発注仕様書）になるまでの実際の流れ

これら4つの要求が、どのようにブレークダウンされて実際の契約書（EIR）に落とし込まれるのかを、商業ビルの建設を例にストーリーで見てみましょう。

1. 【OIR（経営目標）の提示】
   • ビルオーナー（発注者）の経営トップが「わが社は2030年までに、ポートフォリオ全体のビルのエネルギー消費量を30%削減する（カーボンニュートラル達成）」という経営目標（OIR）を決定します。
2. 【AIR（運用要求）とPIR（プロジェクト要求）への展開】
   • AIR（運用のためのデータ要求）: OIRを達成するために、FM（ファシリティマネジメント）担当者は「すべてのビルの空調設備、BEMSシステムの型番、定格消費電力、メンテナンス履歴をデジタルデータで管理し、FMシステムと連携できるようにしなければならない」と定義します。
   • PIR（意思決定のための要求）: 計画立案担当者は「基本設計の終了時（ステージ2）に、建物の年間消費エネルギーのシミュレーションレポートを提示させ、経営陣がGo/No-Goを判断する」と決定します。
3. 【EIR（具体的な注文書）への合意・統合】
   • 発注者のBIMマネージャーは、上記AIRとPIRをすべて満たすために、設計施工会社（受注者）に対する具体的な発注仕様書（EIR）を作成します。
   • 「空調設備のBIM属性データには、必ずパラメータ [BMS_ID] [Rated_Power] [Manufacturer] を付与し、基本設計時には簡易シミュレーション結果（LOIN）、竣工時にはFM連携用のCOBie形式（またはIFCフォーマット）で提出すること。」

このように、経営上のニーズ（OIR）が、運用のニーズ（AIR）とプロジェクト意思決定のニーズ（PIR）に分解され、最終的に受託者への「具体的な契約条件（EIR）」となって結晶化するのです。

情報の成果物モデル：PIMとAIM

プロジェクトの進捗に伴って構築されていくBIMデータ（情報モデル）は、フェーズに応じて2つに呼び分けられます。

PIM（Project Information Model：プロジェクト情報モデル）
設計・施工フェーズ（資産のデリバリー段階）で作成・更新される情報モデル。工事完了に向けてタスクチーム間で常に更新・調整され、マイルストーンごとにCDEを通じて発注者に承認（Published）されながら成長していく「生きているデータ」です。

AIM（Asset Information Model：資産情報モデル）
建物が完成して引き渡された後（運用・維持管理フェーズ）で使われる情報モデル。PIMから運用に必要な機微・アセットデータを抽出し、AIMへと移行させます。ビルオーナーやFM担当者が、日々のメンテナンス、エネルギー分析、将来の改修計画などに長期間活用します。

【完全理解】Part 1を支えるその他の最重要概念・ルール

ISO 19650 Part 1が「情報マネジメントの憲法」と呼ばれるのは、用語集にとどまらず、データ作成や組織の体制に関する本質的な原則を細かく定めているからです。

① LOIN（Level of Information Need：情報の必要レベル）

従来のBIMで曖昧に使われていた「LOD（Level of Detail）」に代わり、ISO 19650が導入した、より本質的で柔軟な定義方法です。「情報の作り込みすぎ（無駄なコスト）」と「情報不足（手戻り）」の双方を防ぐため、以下の3つの側面から「必要な情報の粒度」を定義します。

幾何情報（Geometric Information）
3Dモデルの形状詳細度（どこまで立体的に細部を表現するか）。

属性情報（Alphanumeric Information）
型番、スペック、価格、設置日などのテキストデータ・数値データの詳細度。

ドキュメント（Documentation）:
取扱説明書、保証書、各種試験成績書など、情報コンテナに添付する補足書類。

「いつ、だれが、どの目的（例：干渉チェック、積算、維持管理）のために、どの程度のLOINで情報コンテナを提供するのか」をあらかじめ定義します。

② 情報配信計画（Information Delivery Planning）

実際のモデリングや製図に取り掛かる前に、受注者側は「いつ、誰が、どの情報コンテナを、どのLOINで、誰に向けて提出するのか」を事前に緻密に計画・コミットしなければなりません。これが「情報配信計画」の原則です。実務では以下の計画書に展開されます。

TIDP（タスク情報配信計画）
各タスクチームが、自らの担当する成果物（ファイル）の提出スケジュールをコンテナレベルで一覧化した計画書。

MIDP（マスター情報配信計画）
元請けのリード受託者が、すべてのTIDPを取りまとめ、プロジェクト全体のマイルストーンに整合させたマスター計画書。

③ フェデレート情報モデル（Federated Information Model）

実務では「BIMソフトで各設備・意匠ファイルを重ね合わせて干渉をチェックした3Dモデル」と狭く解釈されがちですが、ISO 19650-1 Section 4における定義はより高次元です。
フェデレート情報モデルとは、「手動および自動の情報管理プロセス（CDEワークフローなど）を介してタスクチームから納品された、3Dモデルだけでなく、2D図面、計算書、仕様書、各種報告書を含む『すべての情報コンテナが整合し、連動・統合された全体』」を指します。
単なる3D空間の重ね合わせではなく、プロジェクトの「情報そのもののシームレスな統合状態」を表す重要な用語です。

④ 能力およびキャパシティの評価（Capability and Capacity Assessment）

発注者が受託者を選ぶ（または元請が協力会社を選ぶ）際、単に「見積価格」や「設計デザイン」だけで決めるのではなく、事前に「ISO 19650に沿ったデジタル情報管理を遂行するスキル（Capability：技術・能力）」と「リソース・人員・IT環境（Capacity：容量・体制）」を十分に備えているかを厳格にテスト・評価するプロセスが原則化されています。

⑤ 情報マネジメント機能（Information Management Function）

ISO 19650では、「BIMマネージャー」という特定の職位や役職を設定するのではなく、「情報マネジメントを行うにあたって必要な『責任とタスク（機能）』」に着目します。
「CDEの構築・サポート」「情報要求の作成」「データの検証・承認」などの各種マネジメント機能を、プロジェクトの誰（発注者側、元請側、あるいは外部コンサルタントなど）が分担し、実行（アサイン）するのかを契約時に明確化します。

⑥ セキュリティマインド・アプローチ（ISO 19650-5に基づくセキュリティ視点）

BIMデータは、重要インフラや機微アセット（防犯設備、配管経路、避難経路など）の極めてデリケートな情報を含みます。
そのため、Part 1の基本原則として「セキュリティへの配慮（Security-minded approach）」がビルトインされています。 CDEにおけるアクセス権限の設定は、単に作業を円滑にするためだけでなく、情報コンテナ単位、状態コンテナ単位で「誰が閲覧してよく、誰をシャットアウトすべきか」を厳格に制御するための安全保障の観点が必須です。

まとめ：Part 1がもたらす実務の変革

ISO 19650 Part 1の根底にあるのは、「データの信頼性と透明性の確保」です。

1. CDEをエコシステムとして捉え、自社と発注者のシステムをシームレスにデータ連携させる。
2. ファイル名（一意のID）は不変とし、ステータス、リビジョンなどのメタデータをCDE上でタグ管理することで、ファイル重複のないクリーンな環境を作る。
3. WIPからSharedへの昇格時にQAチェック（ラッパー）と技術レビュー（中身）の2つの独立したゲートを通し、データ品質を担保する。
4. ステータス（適合性）コードを駆使し、フォルダ制限に依存しない論理的なアクセス制御を行う。
5. バージョン（小数点以下）とリビジョン（整数）を厳密に区別し、作業中の履歴と対外的な共有履歴を混同しないようにする。
6. フェデレート情報モデルをすべての情報コンテナの連動体として捉え、計画的に情報を組み上げる。

これらの原則と正確な国際専門用語をマスターしておくことで、次回解説する「Part 2：設計・施工フェーズの実務ルール（EIR・BEPの作成と活用）」の実務プロセスが、驚くほど直感的に、かつ深く理解できるようになります。

次回は、実際のプロジェクト現場で、どのように「BIM実行計画書（BEP）」を共同で作成し、CDEを実稼働させるのか、その具体的なステップに踏み込みます。お楽しみに！

※本記事は、一般に公開されている情報をもとに、ISOについて学べる内容を整理したものです。正式な仕様や要件については、ISO規格本文をご確認ください。