プロジェクトCDE

本資料はプロジェクトCDEのアジャイルな検討を目的とした草案（ドラフト）です。内容は整理途中であり、本資料にはAI支援ツールを用いて整理・作成した情報が含まれます。AIの出力は参考情報であり、事実関係や技術的妥当性の最終判断・承認は人が行ってください。実務で使用したり外部へ提示する前に、必ず関係者による確認・検証・正式な承認を行ってください。

参考資料：2025.3.7_プロジェクトCDEを中心としたデータマネジメントの取組案について（国土技術政策総合研究所）

目次

1. プロジェクトCDEの定義と全体構造
2. 業務データ基盤（ストレージ選定）
3. アクセス制御とデータ共有
4. 空間データ可視化基盤
5. 承認フロー（ワークフロー）
6. タスクチーム作業環境
7. 付録

1. プロジェクトCDEの定義と全体構造

1.1 定義と目的

• 定義: プロジェクトCDEとは、事業の計画・設計・施工・維持管理にわたる業務そのものをCDE（Common Data Environment）によって管理・統制する仕組みであり、単なるデータ保管庫ではない。各業務フェーズで生まれるデータをSSOT（唯一の正本）として管理しながら、可視化・共有を通じて事業関係者全体の意思決定を支える。
• 目的: 各フェーズで生成されるデータをSSOT（Single Source of Truth）として保持し、可視化・共有を通じて関係者の意思決定を支援する。公開用の派生物も必ずSSOTから生成・配信して整合性を担保する。
• 管理対象: 文書・図面・BIM/IFC・点群・台帳系属性など、事業管理・設計・施工管理・維持管理に関わるすべての成果データ。

1.2 運用ワークフロー（ISO 19650準拠）

ISO 19650準拠のステータス管理により、権威あるマスター（SSOT）を確立する。タスクチームの作業はCDE外で準備され、WIPへの提出をもって正式なCDE管理が開始される。

1.3 管理対象業務フェーズ

プロジェクトCDEは以下の業務フェーズを包括的に管理する。

graph TD
    subgraph CDE["プロジェクトCDE（＝SSOT管理基盤）"]
        EM["事業管理<br/>工程・コスト・関係者調整"]

        subgraph 実施層["事業管理が統括する実施層"]
            P["計画"] --> Ch["調査（現況・支障物件・既存施設・他事業/計画調査）"] --> S["測量（現況取得）"] --> D["設計（基本設計・実施設計）"] --> C["施工管理"] --> M["維持管理"]
        end

        EM -.統括.-> 実施層
    end

分割の趣旨:

• 調査（現況・支障物件・既存施設・他事業/計画調査）: 既存施設（道路・水路・河川等）の実態確認、支障物件（既存構造物・埋設物）、および他事業・計画（進行中／予定）の確認、地質・土質調査等の非座標調査・台帳を含む調査全般を指す。調査報告書・支障物件台帳および他事業計画の参照情報は設計・施工判断に不可欠な基礎情報であり、CDEでの原本管理とメタデータ（位置参照・調査日・担当・信頼度・参照先）を必須化する。
• 測量（現況取得）: 点群（LAS/LAZ）・写真・GNSS観測データなど、空間座標情報としての現況データを取得・処理するフェーズ。測量精度・座標系・メタデータ（取得日時・機器・処理方法）を明記し、設計・出来形管理で利用可能な形でCDEに保管する。
• 設計（基本設計・実施設計）: 調査・測量データを基に図面・モデル・仕様書を作成するフェーズ。設計成果物のステータス管理（WIP→Shared→Published）と設計変更のトレーサビリティをCDEで担保する。

この分割により、成果物・責任範囲・CDE運用ルール（ファイル命名・メタデータ・承認ゲート）がより明確になり、実務での運用負荷が低減します。

プロジェクトCDEとは、実施層（計画・設計・施工管理・維持管理）を事業管理が統括しながら、すべての成果データをSSOTとして管理する基盤そのものである。

1.3.1 調査・測量・設計で作成される主なデータと代表フォーマット

調査・測量・設計の各工程で生まれるデータ類と、CDE上での保存・可視化に向けた代表的なフォーマットを整理します。

• 調査（予備調査・現地調査）
  • 現地調査報告書：PDF, Word（PDF/A 推奨）
  • 写真・画像：JPEG/PNG（高解像度はTIFF/GeoTIFF）
  • 空撮・衛星画像：GeoTIFF, JPEG2000
  • 調査台帳・アンケート：Excel (.xlsx), CSV
  • 既存図面・資料：PDF, DWG/DXF, スキャン(TIFF)
  • 参照GISデータ：Shapefile, GeoPackage, GeoJSON, GML, PostGIS
• 測量（基準測量・詳細測量・観測）
  • 制御点・基準点座標：CSV/TXT（EPSG 明記）, GeoJSON, Shapefile, GPX
  • GNSS観測データ：RINEX, NMEA
  • トータルステーション出力：機器固有形式（.dat 等）/CSV
  • 点群データ（LiDAR/TLS）：LAS/LAZ, E57, XYZ/TXT
  • オルソモザイク・DSM/DTM：GeoTIFF, ASCII GRID
  • 等高線・地形ベクトル：Shapefile, GeoPackage, DXF
  • ジオタグ写真／動画：JPEG(+EXIF/GPS), MP4
• 設計（基本設計・実施設計・BIM）
  • 設計図面：DWG, DXF, PDF
  • BIM／3Dモデル：IFC, Revit (.rvt), OBJ, FBX
  • 土木設計データ（縦断・横断・線形）：LandXML, CSV/TXT（チェーンエイジ/標高）
  • 土量・切盛土モデル：TIN/メッシュ（OBJ/PLY）, LandXML, GeoTIFF DEM
  • 数量・積算：Excel (.xlsx), CSV, XML
  • 仕様書・技術報告書：PDF, Word
  • 施工用ステークアウトデータ：CSV（座標リスト）, DXF, LandXML
• 共通の運用ポイント（CDE連携）
  • 座標系（EPSG コード）とメタデータ（作成者・作成日・精度・処理履歴）を必須化（ISO 19115 推奨）。
  • 納品・保管はオープンフォーマット優先（GeoPackage, GeoJSON, GeoTIFF, LAS/LAZ, IFC 等）。
  • 可視化はCDEと連携：2DはGeoServer/QGIS Server＋Lizmap/Leaflet、3DはCesium/3DTiles、点群はEntwine/Potree、BIMはIFC.js/BIMserver 等を想定。
  • CAD⇄GIS、BIM⇄IFC、点群⇄メッシュの変換ルール、命名規則、バージョン管理を事前に合意し手順を文書化する。
  • 納品パッケージ例：図面(PDF/DWG) + 座標CSV + GISレイヤ(GeoPackage) + 点群(LAS) + 仕様書(PDF) + メタデータ(JSON)

  #### 空間データ可視化基盤への連携 調査・測量・設計で生成されたデータはCDEでの原本管理と並行して、空間データ可視化基盤で統合・加工・配信されます。代表的な連携フローは次の通りです。

  • ベクタ（Shapefile/GeoJSON/GeoPackage） → PostGIS 等の空間 DB に格納 → GeoServer/QGIS Server 経由で OGC（WMS/WFS）やベクタタイル配信 → Lizmap/Leaflet 等で2D可視化
  • ラスタ（GeoTIFF / DSM / DTM） → タイル化（GeoServer/TMS）→ 地図・解析ビューで配信
  • 点群（LAS/LAZ/E57） → PDAL/Entwine による処理・タイル化 → Potree / 3DTiles 等でブラウザ表示
  • BIM/3Dモデル（IFC/Revit/OBJ） → IFC→3DTILES/glTF 変換（IFC.js, BIMserver 等）→ Cesium/3D ビューアで閲覧
  • 文書・図面（PDF/DWG/Excel） → CDEで原本管理、可視化基盤はサムネ・メタデータ・リンクを参照して関連情報を表示

  運用要点：

  • 全データに座標系（EPSG）とメタデータ（作成者・作成日・精度・処理履歴）を付与し、可視化基盤はこれを参照して整合性を担保する。
  • ETL（GDAL/OGR、PDAL、変換パイプライン）は自動化し、SSOT（CDE）→ 派生物（可視化用タイル/モデル）生成をCI化する。

  • アクセス制御はCDE側で原本を管理し、可視化基盤は派生ビューに対して公開レイヤ（認証／共有リンク／公開）を適用する。

  • 文書・図面は単なるリンク参照に留めず、GIS属性（SSOT ID／文書種別／承認ステータス／作成日／関連地物ID 等）として取り込み、地物の属性クエリや GetFeatureInfo で即時参照・ダウンロードできるようにする。これにより位置情報と文書が一体化し、事業全体の統合的参照・意思決定が可能になる。

    ##### 文書・図面の属性スキーマ（例） 下は GIS の属性テーブルやメタデータカタログに保存する想定の最小スキーマ例です。プロジェクト要件に応じて拡張してください。

    • ssot_id (string, 必須): SSOT 一意 ID（例: UUID）
    • doc_id (string, 必須): 文書/図面の識別子（例: DOC-2026-001）
    • title (string): 文書タイトル
    • doc_type (string): 種別（例: 調査報告書／設計図／写真／点群）
    • related_feature_id (string, 任意): 関連する地物／要素の ID（地物側の主キーと整合）
    • related_feature_type (string, 任意): 地物種別（例: road, bridge, manhole）
    • epsg (integer, 推奨): 座標系 EPSG コード（該当する場合）
    • created_at (datetime): 作成日時
    • creator (string): 作成者（担当者名／組織）
    • accuracy (string/float, 任意): 精度・信頼度（例: 0.05m）
    • approval_status (string): 承認ステータス（WIP/Shared/Published）
    • file_url (string, 必須): CDE 上の原本ダウンロード／参照 URL
    • thumbnail_url (string, 任意): サムネ画像 URL
    • metadata_json (jsonb, 任意): 拡張メタデータ（元ファイルの処理履歴・センサー情報等）

    例：メタデータ JSON（GeoJSON の properties に埋める想定）

    { “ssot_id”: “b6f9d8e2-4c2a-4f1a-9e2b-0a1b2c3d4e5f”, “doc_id”: “DOC-2026-001”, “title”: “現況写真_道路A_20260501”, “doc_type”: “photo”, “related_feature_id”: “FT-000123”, “related_feature_type”: “manhole”, “epsg”: 6669, “created_at”: “2026-05-01T10:23:00+09:00”, “creator”: “測量チームA”, “accuracy”: null, “approval_status”: “WIP”, “file_url”: “https://box.example.com/s/abcd1234”, “thumbnail_url”: “https://box.example.com/s/thumb_abcd1234.jpg”, “metadata_json”: {“camera_model”:”CannonXYZ”,”exif_gps”:true} }

    ##### 実装チェックリスト（導入時）

    • CDE に原本保管：ファイルとメタデータの分離（ファイルは Box 等、メタデータは PostGIS/Elasticsearch）
    • 一意 ID 運用：ssot_id を全システムでキーにする（UUID を推奨）
    • GIS 属性追加：地物テーブルに doc_links または doc_count 等の列を追加し GetFeatureInfo で参照可能にする
    • メタデータ格納：PostGIS の JSONB カラムか専用メタデータテーブルで管理し全文検索を有効化する
    • API/Viewer 統合：GeoServer の GetFeatureInfo / feature attributes で file_url を返すよう設定
    • 権限連携：CDE のアクセス権と可視化基盤の表示制御を紐付ける（SSO / token 検証）
    • ETL 自動化：ファイル登録時にメタデータを自動抽出・インジェストするパイプラインを構築（例: Lambda/Cloud Function / CI）
    • テスト：代表的な文書（PDF）、図面（DWG）、写真（ジオタグ付）で GetFeatureInfo→ファイル参照→ダウンロードまでの実行検証

    上記を実行すれば、GIS 上で地物をクリックすると該当する文書・図面が即参照でき、位置情報と文書が一体化した運用が実現します。

  「4. 空間データ可視化基盤」は、上の流れを前提に具体的な構成・技術選定・運用を記載します。

1.4 機能構成（全体像）

プロジェクトCDEの本質はSSOTによる共有・公開であり、以下の構造で機能群が成立する。

【目的】SSOTによる共有・公開
    ↑ SSOTを活用
【事業監理業務】進捗管理・資料整理・可視化・報告
    ↑ SSOTを構成
【データ基盤】空間データ可視化基盤 + 業務データ基盤（ストレージ）

業務データ基盤（ストレージ）

データ取り込み（バッチ／ストリーム）、ETL/ELT、スキーマ・メタデータ管理、アクセス制御・監査、バックアップ、API公開、データガバナンス等を担い、SSOT（属性・履歴・トランザクション）を保持する。

空間データ可視化基盤

CAD／BIM／CIM／GISの可視化・解析・配信（3DTILES/glTF、ベクタタイル、OGC/Web API、タイル化・キャッシュ等）を担い、閲覧・解析・住民向け公開を実現する。

1.5 業務フォルダとデータの使い分け方針

CDEで扱うデータは性質が異なるため、以下のように使い分けることが現実的である。

【文書・図面系】設計書・報告書・会議録・CAD図面・写真
    → ファイルストレージ（Box を標準推奨 / NAS は暫定）で管理

【GIS・BIM系】空間データ・IFC・点群・3Dモデル
    → GIS/BIMプラットフォームと連携（別途選定）
    ただし元ファイルの保管先はファイルストレージと統一が望ましい

調査・測量・設計・監理の役割分担（事業管理視点）

• ID連携: BIM要素・点群領域・GIS地物に一意IDを付し、トレーサビリティを担保する。
• ソース規定: どのシステム上のどのステータスが権威（SSOT）かを明文化する（例: 設計は Published のIFC、監理は Published のGIS属性テーブル）。
• 派生物ワークフロー: IFC/点群からは公開用の3DTILES/glTF/タイル点群を自動生成し、監理・公開用に配備する。

2. 業務データ基盤（ストレージ選定）

ストレージが決まらなければ、GIS基盤も業務データ連携も成立しない。まずデータを保存・管理できるストレージの選定を行う。

2.1 選定要件

要件は「必須条件（KO条件）」と「評価要件（重みづけ）」の2段階で設定する。KO条件を満たさない候補はその時点で不適合となる。

必須条件（KO条件）

評価要件（重みづけ）

評価点：◎＝3点 ／ ○＝2点 ／ △＝1点　　R8（コスト）は低いほど高得点（低〜中＝3、中＝2、初期高＝1）

2.2 ストレージ候補の比較・総合評価

KO判定が⚠️・❌の候補の総合点は参考値（KO要件の解消を前提とした場合の機能評価）。

※1 Dropbox Business・Google WorkspaceはISMAP登録済みだが、データセンター所在国の扱いは発注者のセキュリティポリシー確認が必要なため「要確認」とする。
※2 NASは外部組織との共有にVPN設定が必要で認証付き外部共有手段がなく、KO-A不適合とする。
※3 Google Workspace・Dropbox BusinessのKO-Aは○。外部共有に相手方アカウントが必要で、アカウントを持たない場合は成立しない。KO判定が⚠️なのはKO-B（国内DC）が満たせていないため。
※4 SharePointのKO-Aは○：Azure AD B2Bゲスト招待は相手方Microsoftアカウントまたは相手方組織のゲスト許可が前提。許認可機関・行政機関では制限されるケースが多く、M365非保持者への代替手段（ゲストリンク・パスワード付きURL）はKO-Aが定義する「パスワード付きURLのみ＝不適合」に該当するため、公共事業では実質的にKO-A不適合となるケースが大半。CDE用途には推奨しない。
※R4評価：Box◎＝容量無制限（Business以上）／SharePoint○＝1TBベース＋ライセンス加算・1ファイル上限250GB／Dropbox○＝プランにより上限あり／Google○＝共有プール制／NAS◎＝増設で無制限だが初期コスト大

2.3 ISMAP登録状況

出典：ISMAPクラウドサービスリスト（2026年4月時点）

2.4 推奨

SharePoint (Microsoft 365) はISMAP登録済みだが、M365非保持者への代替手段（ゲストリンク・パスワード付きURL）がKO-Aの「パスワード付きURLのみ＝不適合」に該当する。公共事業では許認可機関・行政機関側でゲスト招待を制限しているケースが多く、CDEとしての採用要件を満たさないため推奨から除外した。

2.5 推奨フォルダ構成例（Box）

フォルダ階層の設計方針：ステータス（Exchange / TaskTeam / WIP / Shared / Published / Archived）を最上位に置く。業務フォルダを最上位にするとフォルダ数 × ステータス数の権限設定が必要になり設定漏れ・メンテナンスコストが増大する。ステータスを最上位にすれば各ステータスフォルダへの権限付与が各1回で全業務フォルダに継承される。

📁 [事業名]-プロジェクトCDE
│
├── 📁 Exchange【やり取り】   ← 【例外措置】CDE外でやり取りされたファイルを一時保管する場所
│   │              ※業務分類は行わず、年月等で管理。重要なものは後でShared等に移す。
│   ├── 📁 202604_〇〇省から受領
│   └── 📁 202604_地元説明会資料_送信控え
│
├── 📁 TaskTeam【タスクチーム】   ← CDE上の各チーム作業フォルダ（当該チームのみアクセス可）
│   └── 📁 [業務名]
│       ├── 📁 01_事業全体計画の整理
│       ├── 📁 02_測量・調査・設計業務等の指導・調整等
│       ├── 📁 03_地元及び関係行政機関等との協議
│       ├── 📁 04_事業管理
│       ├── 📁 05_施工管理
│       ├── 📁 06_BIM-CIM（統合モデル）活用支援
│       └── 📁 07_その他（維持管理・電子納品等）
│
├── 📁 WIP【作業中】        ← 当該タスクチームのみ書込可・正式CDE管理の入口
│   └── 📁 [業務名]
│       ├── 📁 01_事業全体計画の整理
│       ├── 📁 02_測量・調査・設計業務等の指導・調整等
│       ├── 📁 03_地元及び関係行政機関等との協議
│       ├── 📁 04_事業管理
│       ├── 📁 05_施工管理
│       ├── 📁 06_BIM-CIM（統合モデル）活用支援
│       └── 📁 07_その他（維持管理・電子納品等）
│
├── 📁 Shared【共有】     ← 承認済み・プロジェクト関係者全員閲覧可
│   ├── 📁 01_事業全体計画の整理
│   ├── 📁 02_測量・調査・設計業務等の指導・調整等
│   ├── 📁 03_地元及び関係行政機関等との協議
│   ├── 📁 04_事業管理
│   ├── 📁 05_施工管理
│   ├── 📁 06_BIM-CIM（統合モデル）活用支援
│   └── 📁 07_その他（維持管理・電子納品等）
│
├── 📁 Published【公開】  ← 関係機関等への公開版
│   ├── 📁 01_事業全体計画の整理
│   ├── 📁 02_測量・調査・設計業務等の指導・調整等
│   ├── 📁 03_地元及び関係行政機関等との協議
│   ├── 📁 04_事業管理
│   ├── 📁 05_施工管理
│   ├── 📁 06_BIM-CIM（統合モデル）活用支援
│   └── 📁 07_その他（維持管理・電子納品等）
│
└── 📁 Archived【アーカイブ】   ← 変更不可。業務・工事完了時の成果物・納品物を保管
    ├── 📁 01_土木設計業務等   ← 設計・測量・調査・事業管理等の業務完了時の報告書・成果品
    └── 📁 02_工事完成図書     ← 工事完了時の完成図・施工記録・出来形・品質管理書類等

2.6 Exchange【やり取り】の運用ルール（例外措置）

CDEの理想は「全関係者が同じシステム上で完結すること」だが、実務上はメール添付やチャット等でCDE外にファイルが流れる。Exchange フォルダはやり取りの一時バッファとして許容するが、正本（SSOT）と同列扱いにしてはいけない。

位置づけ（一次受領）

• 正式受領はアカウント（コラボレータ）共有（認証付き）で行う。Exchange はコラボレータ外からの例外的な受領や緊急時の一時バッファとしてのみ使用する。
• Exchange で受領したファイルは速やかに検査・分類し、重要なものはTaskTeamで整理した上でWIPに提出し、承認プロセスを経てShared/Published等の正式フォルダへ移行する。

受信方針

• 外部正式受領はBoxの File Request を使用する。
• 組織内のメール添付は Box for Outlook でBoxに保存し、共有リンクを利用して添付の重複と追跡不備を防ぐ。

送信方針

• 送信はアカウント（コラボレータ）共有（認証付き）を基本とする。共有リンクは、受信者がBoxアカウントを持たない等の例外的な場合に限定する。
• デフォルトの共有設定はview-only。必要に応じて有効期限・パスワード・ダウンロード可否を設定する。

アクセス制御

• Exchange は一次受領用バッファとし、WIP/Shared/Published 等の正式フォルダはコラボレータ限定で厳格に管理する。
• 移行期限: Exchange 内の重要ファイルは原則72時間以内に分類・WIPへ提出する。

3. アクセス制御とデータ共有

3.1 アクセス制御・データ共有の三層（概要）

プロジェクトCDEでは、データの共有方法とアクセス制御を「三つの共有レベル（層）」で定義します。各層ごとに許容されるデータ粒度・認証レベル・配信手段が異なり、適切な共有方法を選ぶことが設計上の重要課題です。

意思決定フロー

1. データ分類（機密度・個人情報の有無）
2. 層の決定（共有レベル：層1（設計編集） / 層2（関係者共有） / 層3（公開））
3. 必要なセキュリティ対策（認証・匿名化・ネットワーク制御・監査）
4. アプリ／配信方式の選定（例: Revit/Navisworks/KOLC+ は層1、Cesium は層2、Re:Earth/Lizmap は層1〜層3対応）
5. 公開タイミング（Published 承認後、派生物を配信）

ここでの「層」は、主に「共有方法（アカウント認証／共有リンクタイプA／共有リンクタイプB）」と「アクセス制御レベル」を指します。以下の表や説明は、この対応を前提としています。

※ 層2の「または」は相手に応じた使い分けを意味し、両方の方法を同時に提供できる状態にすることが必須。アカウント共有のみに限定すると、許認可機関・ライフライン事業者・下請け等の共有先に有料アカウントの取得を強いることになり、ほとんどのニーズに対応できない。

共有方法

• アカウント（認証付き）: 組織アカウントでのアクセス。SSO/MFA・RBAC・監査ログにより高忠実度データの安全共有に適する。
• 共有リンク（タイプA: ID＋パスワード／短期署名）: 外部委託先や関係機関向けの限定共有。有効期限・ダウンロード制御・パスワードで安全性を高める。
• 共有リンク（タイプB: 公開）: アカウント不要の一般公開リンク。公開対象は匿名化・軽量化した派生物に限定する。

3.2 層1 — 設計編集（高保護・編集可）

• 共有方法: CDE内のShared領域またはAPI経由の署名付き配布パイプライン。手動配布／メール添付は禁止。
• 認証: SSO（OIDC/SAML）＋厳格MFA（ハードトークン/OTP）、短いセッション有効期限（例: 30分）。
• 認可: RBAC＋細粒度ACL（オブジェクト／属性レベル）。最小権限で編集ロールを付与。
• 配布: APIゲートウェイ経由、署名・ハッシュ付き派生物、バージョン管理。VPN/ゼロトラスト・IP制限を要求。
• 監査: 変更ログを完全記録しSIEMへ集約。差分ロールバック対応。
• 運用: 編集は承認ワークフロー必須（WIP→Shared）。エクスポート時の自動DLPチェックを実施。

3.3 層2 — 関係者共有（制御付き参照）

• 共有方法: アカウントベース（SSO/MFA）と タイプA共有リンク（ID＋パスワード・有効期限・ダウンロード制御）の両方を併用する。プロジェクト内チームや主要パートナー等アカウントを取得できる相手にはアカウント共有、許認可機関・ライフライン事業者・下請け等アカウント取得が困難な相手にはタイプA共有リンクを使用する。アカウントのみに限定すると共有先に有料アカウント購入を強いる事態となり現実的でない。
• 認証: SSO＋MFA推奨。外部ユーザはSCIM等でプロビジョニングし短期トークンを発行。
• 認可: ロールベースに加え時間・用途ベース制御（スコープ・有効期限）。原本の直接ダウンロードは原則制限。
• 配布: 必要最小属性で派生物を生成、署名・ハッシュで整合性を担保。
• 監査: アクセス／ダウンロードログを保持し定期レビュー。承認メタデータ（承認者・日時・派生物ID）を必須化。
• 運用: 共有リンクは申請→承認→発行履歴を残す。期限切れ後は自動無効化。

3.4 層3 — 公開（低リスク・広報向け）

• 共有方法: タイプB公開リンク（CDN配信）で公開。公開前に完全匿名化・マスキング・解像度低減した派生物のみを公開し、公開期限と監視を設定する。
• 認証: 閲覧は基本不要。公開設定変更は管理者のSSO権限（MFA）で保護。
• 認可: 公開はPublishedを通過した派生物のみ許可。
• 配布: CDN＋WAF＋RateLimitで配信。公開派生物は署名・バージョン・元SSOT IDを持つ。
• 監査: アクセス統計・監視ログで追跡。個人情報を含む公開は厳禁。
• 運用: 公開前にSSOTと照合し、公開後は定期チェックと期限管理。削除・訂正要求の対応フローを整備。

3.5 共通要件（全層）

• 認証基盤: OIDC/SAML IdP、SCIMによるプロビジョニング。MFAを原則。
• 認可基盤: RBAC／ABACの実装、APIゲートウェイでスコープ管理。
• 通信: TLS 1.2/1.3による暗号化。
• ログ/監査: 全アクセス・操作ログをSIEMへ集約し最低90日保持。
• データ所在: 公共案件は国内DC／ISMAP等を確認。バックアップの所在を明示。
• 自動化: 変換・バージョン・配信は自動パイプライン化し、配布前に承認チェックを必須化。手動配布は禁止。

3.6 事業管理の運用原則

• フェーズ毎に承認ゲート（WIP→Shared→Published）を設定し、承認済み派生物のみ上位層へ流通させる。
• 編集権限は最小権限で付与し、外部委託には期限付き・用途限定の編集ロールを発行する。
• 事業管理はアクセスレビューと定期監査を主導し、ポリシー適合性を担保する。
• フェーズ毎のアクセスポリシーと承認責任者を明記し、承認メタデータを必須化する。

3.7 役割別：工事関係者の可視化層割当（例）

3.8 関係機関との情報共有

主な関係機関と共有内容

情報共有の設計方針

4. 空間データ可視化基盤

4.1 全体構成と役割

空間データ可視化基盤は、CDEで管理されるSSOTデータを位置情報（座標系）という共通軸で統合・加工・配信し、関係者が地図・3D・グラフで直感的に状況を把握できるようにする。CDE本体（ストレージ・権限管理）とは分離するが、データの流れは一方向ではない。

• CDE → GIS（派生物生成）: SSOTの変更を起点に、ETLで自動変換した派生物をPostGIS・タイルストアに格納して配信する。
• GIS固有属性の管理（GIS主導）: 現地調査・台帳補正・新規地物追加など、GIS層が正本となる属性はPostGISに直接書き込み（OGC API - Features / WFS-T / QGISなど、層1のみ）、変更履歴を保持したうえでCDEへバックシンクしてSSOTとの整合性を維持する。

[SSOT（CDE / Box等）] ←── バックシンク（GeoPackage/GeoJSON・CDE WIPワークフロー経由）
    ↓ ETLパイプライン（GDAL / PDAL / IFC変換 等）
[空間DB（PostGIS）・タイルストア（MBTiles / 3DTILES）]
    ↑ GIS属性編集・補正・新規追加（OGC API - Features / WFS-T / QGIS等、層1のみ）
    ↓ OGC API / 3DTILES配信
[配信サーバ（GeoServer / TileServer GL / Cesium Server）]
    ↓ 認証・CDN
[クライアント（Cesium / MapLibre GL / Lizmap 等）]

4.2 データ処理パイプライン（ETL自動化）

調査・測量・設計で生成された各データ（1.3.1 記載）はCDEで原本を保管した上で、ファイル登録イベントをトリガーに可視化用の「派生物」を自動生成する。

共通ETL要件

• 全データに座標系（EPSG）整合・投影変換を実施
• ssot_id・作成日・作成者・精度・処理履歴をメタデータとして付与（PostGIS JSONB / GeoJSON properties）
• パイプラインはCI化し、SSOT更新→派生物再生成を自動実行（インクリメンタル差分更新対応）
• 公開層（層3）向けには属性削減・個人情報匿名化を施した別派生物を生成

4.3 GIS基盤（空間統合・属性管理）

すべての業務データを位置情報という共通軸で統合する中核。PostGISを主DBとして採用し、地物・属性・メタデータ・文書リンクを一元管理する。

ID連携原則

• ssot_id（UUID）を全システム共通キーとして使用し、BIM要素・点群領域・GIS地物・文書間のトレーサビリティを担保する
• GIS地物テーブルに doc_links（ssot_id 配列）または doc_count カラムを追加し、GetFeatureInfoで関連文書を参照可能にする

4.4 3D可視化（3DTILES統一）

3Dモデル配信は 3DTILES を中間フォーマットの標準とし、取り込み→タイル化→配信→表示を一貫して自動化する。

主要フロー

1. 取り込み: IFC/RVT/DWG・LAS/LAZ・写真測量モデル等を受け入れ
2. 前処理: 座標（EPSG/ECEF）整合、階層・セマンティクス抽出、マテリアル統合
3. タイル化: メッシュ簡略化・LOD生成・Draco/KTX2圧縮 → 3DTILES 生成
4. デプロイ: 3DサーバまたはS3+CDNへデプロイしストリーミング配信
5. 表示: Cesium/Three.js等がビュー依存でタイルを逐次取得してレンダリング
6. インタラクション: 断面・距離・属性クエリ・ハイライト等の3D操作を提供

BIM/CIM固有の考慮事項

• 元IFC/DWGはCDEにSSOTとして保管し、公開用は軽量化した3DTILES/glTFを Published として配信
• IFC→3DTILES変換ツール: IFC.js / ifcConvert / xeokit-metadata-convert 等
• SaaS（Autodesk Forma, Trimble Connect等）はセキュリティ・国内保管要件を確認の上PoC評価を推奨
• ARクライアント非対応の場合、サーバ側でglTF/GLBへ自動変換して配信

設計上の留意点

• 3D固有メタデータ（階層ID・素材・耐荷重等のセマンティクス）をタイルメタに保持し、クライアントからの3Dクエリで利用可能にする
• ジオリファレンス（ECEF→ローカル変換）と高さ基準（地表面 vs ジオイド）を明示
• パフォーマンスはタイル粒度・LOD・圧縮・プリフェッチで制御。巨大モデルは領域分割とメタタイル設計が必要
• ファイル登録→変換→検証→デプロイのパイプラインをCI化し、差分更新（インクリメンタル）対応を実装

4.5 2D配信（OGC準拠）

2Dの地図・属性データ配信はOGC標準に準拠して相互運用性を確保しながら、3D表示（3DTILES）と整合した座標系・メタデータを保持する。

推奨OGCプロトコル / フォーマット（優先順）

3D連携

• 背景ラスタ（XYZ/WMTS）・DEMはCesiumの地形ドレープに使用可能であることを要件とする
• 同一タイル座標系（EPSG:3857 / WebMercator）を採用し、タイル格子・ズームレベルの整合を保つ

• DEM/高さ基準はメタデータで明示（height_reference: geoid

  ellipsoid）

• ベクタ（MVT）と3D（3DTILES）は ssot_id を共通キーとして双方向参照可能にする

パフォーマンス対策

• ラスタ: WMTS/XYZで事前タイル化（ズームレベル 0〜18）、CDN + Cache-Controlでエッジキャッシュ最大化
• ベクタ: MVT（Tippecanoe生成）で表示に最小限の属性のみ（ssot_id, type, label, status）。詳細属性は別APIで遅延取得
• DEM: 粗解像度は遠景用・詳細はローカル領域用に分割
• ベクタクエリはPostGIS側で処理しクライアント負荷を軽減
• クライアント側はWebGL（Cesium/MapLibre GL/deck.gl）でGPU描画し、CPU作業はワーカで分離

推奨スタック

• バックエンドDB: PostGIS（ジオメトリ・属性・バージョン管理を一元化）
• OGCサーバ: GeoServer / QGIS Server(Lizmap)（WMS/WMTS/WFS/OGC API）
• タイル生成: tippecanoe（ベクタ）・gdal2tiles/gdalwarp（ラスタ）
• ベクタタイル配信: tegola / TileServer GL / S3+CloudFront
• クライアント: MapLibre GL（2D）+ Cesium（3D）を組合せ、用途に応じて Leaflet/deck.gl を追加

メタデータ（必須項目）
ssot_id, title, created_at, creator, epsg, bbox, accuracy, license, file_url, processing_history。
カタログ登録時はISO 19115準拠フィールドを含め、OGC API - Records / CSWで検索可能にする。

PoC/導入時チェック

• WMS/WMTS/OGC API - Features のレスポンス互換性とGetFeatureInfoの整合性
• MVT（PBF）タイルの生成・ズーム整合性・スタイル適用テスト
• GeoPackageの作成・読み戻しおよびオフライン利用検証
• OGC API - Records / CSWでの検索・メタデータ表示確認
• 2D/3D間のID連携（ssot_idによる双方向参照）

4.6 事業監理機能（SSOT活用層）

SSOTとして管理されたデータを活用し、事業管理が実施層を横断的に統括するための業務機能を可視化基盤から提供する。

4.7 アクセス制御・配信設計

可視化基盤のアクセス制御は「3. アクセス制御とデータ共有」の三層モデルに準拠する。

共通要件

• OGC/3DTILESエンドポイントはリバースプロキシ（Nginx/Caddy）で保護し、APIはOAuth2トークン/APIキーで制御
• 公開用（層3）はCDEのPublishedステータスを通過した派生物のみ配信を許可
• 全アクセス・操作ログをSIEMへ集約し最低90日保持

4.8 課題・PoC・ロードマップ

優先PoC項目（高）

• 大規模データ表示性能（複数IFC + 点群）での応答性と同時閲覧性能検証
• IFC→3DTILES/glTF、点群→タイル点群の自動生成パイプラインと処理時間評価
• CDEと可視化サービス間の認証・権限連携（SSO・ユーザ同期・ロールマッピング）
• 元データの完全エクスポート（可搬性）とリストア検証
• GIS属性編集ワークフローの検証（QGIS / OGC API - Features 経由の書き込み・audit_log 記録・CDE WIPへのバックシンク手順）

運用ガバナンス（中）

• SSOTの責任分界（どのデータが公式か・更新は誰が承認するか）の明文化
• GIS固有属性の責任分界（PostGISが正本となる属性の範囲・編集承認手順・CDE反映タイミング）の文書化
• 公開層の匿名化基準（写真・点群の個人情報除去ルール）とチェック手順
• ログ保管期間・監査プロセスの策定

技術改善・コスト（低〜中）

• 自前ホスティング vs SaaS のTCO比較と冗長化設計
• レンダリング最適化（LOD戦略・キャッシュ/タイル刷新の方針）
• 出来形差分検出の自動化とアラート連携

体制・教育（継続課題）

• 運用ハンドブックの作成（権限・承認・公開手順）
• 運用担当（CDEオーナー）とデータ管理担当の役割定義
• 関係者向けトレーニング計画とPoCフィードバックループ

まずはPoC設計書（試験データ・評価指標・スケジュール）を作成し、実行→評価→運用ルール反映のサイクルを回すことを推奨する。

4.9 データ利用方式の分岐

空間データの「使い方」は、誰が・どの目的で使うかによって大きく2方式に分かれる。「3. アクセス制御とデータ共有」の三層モデル（層1〜3）と対応させると、方式・共有方法・具体的アプリの選択が明確になる。

全体対応表（層・方式・共有方法・アプリ）

層2では方式AとBを並行して提供することで、専門ソフト利用者（設計者・施工管理者）と非専門者（関係機関・下請け）のどちらにも対応できる。

方式A — 原本ネイティブ運用（層1中心・設計・精度重視）

ひとことで言うと

「いつも使っている専門ソフトで、ファイルをそのまま開いて使う方法」
変換なしに原本を直接保管・編集・共有する。現場の進捗変化にもリアルタイムで追従できる。

わかりやすい説明

• 設計者が DWG（CAD図面）や IFC（BIMモデル）を毎日更新するとき、そのまま保存・上書きするだけで最新状態を維持できる。
• 出来形計測のたびに点群（LAS）を取り直しても、ファイルを差し替えるだけで対応できる。
• 変換作業が不要なので、専門担当者は普段どおりのツール・手順で継続作業できる。

技術的根拠

• 精度・セマンティクス保持: DWG/DXF・LAS/LAZ・IFC・LandXML 等のネイティブ形式は座標精度と属性・階層構造を完全保持する。変換時の精度劣化・属性欠損を回避できる。
• 随時更新への対応: 設計変更・出来形計測・施工進捗の頻繁な反映には、ファイル差分上書きが最もコストが低くトレーサビリティも高い。バージョン管理（タイムスタンプ＋ssot_id）と組み合わせると変更履歴も確保できる。
• ツール親和性: KOLC+・ArcGIS Pro・Revit・Navisworks・QGIS・AutoCAD Civil 3D・Leica Cyclone 等の専門ツールがネイティブ読み込みに対応しており、高度な解析・設計・点群処理がそのまま可能。
• アクセス制御: 層1（認証付きアカウント・SSO/MFA）で厳格に保護。ファイルロック（排他制御）と CDE の WIP→Shared ワークフローを組み合わせる。
• 運用上の推奨: CDE（SSOT）への登録は差分アップロード＋更新イベントで方式B の派生物自動再生成をトリガーとするパイプラインを構築すると安定する。

注: 一般的な運用の目安として、KOLC+・ArcGIS Pro の場合は方式B等への変換で共有を賄えるケースが多い。一方で Revit、Navisworks、QGIS、AutoCAD Civil 3D を原本のままネイティブで高速に共有・参照させる用途では、機能・性能確保のために有償の FORMA 等の専用ソリューションが必要になる場合がある（予算と要件に応じ要検討）。

方式B — タイル配信統合（層2〜3・公開・AR向け、2D: XYZ/WMTS/MVT / 3D: 3DTILES）

ひとことで言うと

「データを地図タイルや3Dタイルに変換して、ブラウザやスマホでだれでも見られるようにする方法」
原本は保管しつつ、公開・共有・AR表示に適した軽量な「配信用ファイル」を自動生成して使う。
方式Bの層2〜層3〜AR/VR/WebARを単一プラットフォームで一気通貫カバーできるツールとして torinome（HoloLab） が挙げられる。

わかりやすい説明

• 住民説明会で工事範囲をスマートフォンの地図で見せるとき、専門ソフト不要で地図タイルとして配信できる。
• 3D モデルを現地でスマートフォン AR に重ねて見せるとき、3DTILES をストリーミング取得してそのまま表示できる。
• データ量が大きくても「今見ている範囲の分だけ読み込む」仕組み（タイル分割）なのでサクサク動く。
• 発注者・関係機関向けには認証付きURL（タイプA）、住民・広報向けには公開URL（タイプB）を使い分けられる。

技術的根拠

• 推奨中間フォーマット:
  • 2D ラスタ（航空写真・オルソモザイク）: XYZ / WMTS（OGC標準）— CDNキャッシュ可能、ズームレベル 0〜18 の高速配信。
  • 2D ベクタ（道路・施設・境界）: Vector tiles (MVT/PBF) — クライアント側描画・スタイリング・属性連携が可能。
  • 3D（BIM/点群/都市モデル）: 3DTILES（OGC標準） — LOD 付きストリーミング配信。軽量個別モデルは glTF/GLB を併用。
• 配信性能の根拠: タイル形式はサーバ側で事前生成し CDN に乗せることで大人数同時閲覧・住民公開に対応できる。動的生成（WMS等）比でレスポンスが大幅に高速。
• 相互運用性: WMTS/XYZ は MapLibre GL・Leaflet・QGIS・ArcGIS・CesiumJS 等が標準対応。3DTILES は OGC標準で Cesium・Google Maps Platform・ArcGIS Pro 等が対応済み。
• アクセス制御との対応:
  • 層2（関係者）: タイルエンドポイントに OAuth2/タイプA 短期署名URLを付与して認証。
  • 層3（公開）: CDN + WAF + RateLimit で公開配信。公開は匿名化・解像度低減した派生物のみ許可。
• AR連携: 3DTILES は ECEF 座標系と LOD が組み込まれており、Cesium for Unity/Cesium for Unreal ・スマートフォン AR（ARCore/ARKit + CesiumJS）に直接利用できる。モバイル AR 向けは glTF + Draco 圧縮で軽量化。日本製の torinome AR（iPad/iPhone）・torinome WebAR（スマートフォン・ブラウザのみ）も 3DTILES・LAS・glTF・PLATEAU に対応しており、専用アプリ不要の住民向け AR 体験を届けられる点が特徴。
• 変換・維持コスト: ETL 自動化（GDAL/PDAL/Tippecanoe/Entwine/py3dtiles 等）と CI 化で軽減できる。

推奨方針（ハイブリッド）

原本（方式A）は CDE で SSOT として保管・管理し、共有・公開・AR 用には方式B の派生物を自動生成する。

[CDE: 原本保管（SSOT）— 方式A]
    │  層1: アカウント認証で専門ソフトから直接利用
    ↓ 更新イベントをトリガーに自動ETL（方式B 生成）
[PostGIS + タイルストア]
    ├── 2D: XYZ/WMTS/MVT タイル  ← 層2（認証）/ 層3（公開）
    └── 3D: 3DTILES / glTF        ← 層2（認証）/ 層3（公開）/ AR
    ↓
[配信サーバ + CDN]
    ├── 層2（アカウント認証 ＋ タイプA共有リンク）: Lizmap / CesiumJS / torinome Base（認証付き）
    ├── 層3（タイプB公開）: Re:Earth / Lizmap / PLATEAU VIEW / CesiumJS / torinome Base（公開）
    └── AR: torinome AR / torinome WebAR / Cesium for Unity・Unreal（3DTILES/glTF ストリーミング）

• 自動 ETL（GDAL/PDAL/Tippecanoe/Entwine/py3dtiles 等）で変換を CI 化する。
• 座標系（EPSG）・精度・メタデータ（ssot_id・作成者・作成日・処理履歴）を各派生物に保持する。
• 公開層（層3）向けは属性削減・個人情報匿名化を施した専用派生物を生成し、Published ステータスを通過したものだけ配信を許可する。

4.10 方式A 代表事例: KOLC+（国内SaaS型・建設CIM/BIM向け）

国内事例として KOLC+（運営: KOLG Inc. / サービスページ: https://kolcx.com/）が挙げられる。BIM/CIM・点群・CADのネイティブ形式を CDE に保管したまま、設計者・施工管理者が普段どおりのツールで直接参照・編集できる方式A の典型例。3D タイル化によるブラウザ表示も備え、方式A/B の橋渡し役も担う。

注: KOLC+ 等のベンダー提供 API や Webhook を利用して、承認済みの最終成果を自動的に CDE の Archived に登録できるかを事前に検証することを推奨します（認証・メタデータ渡し・冪等性を PoC で確認）。

• クラウドでのモデル統合: BIM/CIM・点群・2D/3D CAD・地形・オルソ画像等を座標系で統合し、3D タイル化してブラウザ高速表示を実現。
• 運用機能群: 4D（工程）共有・編集、土量計算、断面 DXF 出力、360 度写真管理、GNSS/現場カメラや計測データのリアルタイム連携、Navisworks クラウド共有、指摘・バージョン管理、ワークフロー（ASP）等を提供。
• セキュリティ・ホスティング: 国内データセンター稼働、ISO27001（ISMS）等の認証取得、ISMAP 登録。
• 料金感（公表値の例）: 月額数万円〜のプラン（例: 3D プラン 3 万円/月、デジタルツイン向け 5 万円/月、DX プラン 24 万円/月、官公庁プラン 6 万円/月など。詳細は見積・問合せが必要）。

評価と留意点

• ISMAP 登録・国内 DC・官公庁プランがある点は公共事業での採用を容易にする。
• SaaS 導入は長期契約・データポータビリティ・コストが課題になり得るため、「元データの管理場所」「派生公開データの生成ルール」「API 連携・エクスポート可否」を事前に確認すること。
• 実務導入は PoC（大規模 IFC/点群での表示性能、API による CDE 連携、権限／保管場所の確認、コスト試算）を必須とする。

4.11 方式B 代表事例: torinome（XRデジタルツインPF・HoloLab）

ホロラボ（HoloLab Inc.）が開発・運営する XR デジタルツインプラットフォーム（サービスページ: https://hololab.co.jp/services/packages/torinome/）。方式B（タイル配信）の層2〜3・AR/VR/WebAR を単一プラットフォームで一気通貫カバーできる点が最大の特徴。

アプリケーション構成（7種）

対応データ形式

glTF/GLB（メッシュ）、LAS（点群）、3D Tiles（Gaussian Splatting・GIS データ・都市モデル）、GeoJSON、CZML、KML/KMZ、iPhone スキャンデータ（LiDAR）、テキスト・URL・動画・画像、PLATEAU / Photorealistic 3D Tiles（Google）

セキュリティ・アクセス制御

• Admin 機能: ユーザー・グループ管理、アクセス制御（層2相当）、コンテンツの一括管理が可能。
• 外部 API 連携: 既存 DB や CMS との API 連携に対応。CDE（Box 等）からのデータ取り込みパイプラインを構築可能。
• 国内 DC/ISMAP: 日本事業者（HoloLab Inc.）。詳細は要確認（公共案件では事前に契約書面で確認すること）。

プランと料金感

料金は非公開（要問い合わせ）。カスタマイズ開発・外部システム連携（API）のオプションあり。

評価と留意点

• 強み: 方式B の Web GIS（Base）→ 関係者共有（Admin 認証）→ AR/VR/WebAR を単一プラットフォームで提供できるのは現時点で torinome のみ。専用アプリ不要の WebAR は住民説明会・広報での即時展開に有効。
• 確認事項: 層2（タイプA共有リンク: パスワード付き・有効期限・ダウンロード制御）への正式対応可否は要確認。公共案件では国内 DC の書面確認を取得すること。
• 留意点: 方式A（DWG/IFC 等の原本ネイティブ編集）には非対応。設計・計画フェーズは方式A（KOLC+ 等）と併用するハイブリッド構成を推奨。
• 実務導入: PoC（大規模点群・3DTILES の Base 表示性能、Admin による URL 共有の挙動、CDE 連携 API、コスト試算）を実施してから本採用を判断すること。

5. 承認フロー（ワークフロー）

5.1 CDEの決済フロー（WIP → Shared → Published / Archived）

ISO 19650のステータス遷移は単なるデータ管理の便宜ではなく、正式な決済（承認）プロセスを表す。

flowchart TD
    TT["TaskTeam【タスクチーム】<br/>作成・修正（CDE外）"]
    EX["Exchange【やり取り】<br/>CDE外からの受領・一時保管（バッファ）"]
    WIP["WIP【作業中】<br/>共有依頼前の確認（受注者）"]
    SH["Shared【共有】<br/>審査・承認待ち（発注者）"]
    PB["Published【公開】<br/>承認済み現行版（関係機関等に公開）"]
    AR["Archived【アーカイブ】<br/>業務・フェーズ完了単位の<br/>報告書・納品物保管（公開と別枠）"]
    ASP["主に「調査・測量・設計」<br/>KOLC＋ / Basepage 等<br/>受発注者間のASP承認ワークフロー"]

    TT -->|"やり取り"| EX
    TT -->|"TaskTeamで作成・WIPへ提出"| WIP
    EX -->|"整理"| TT
    WIP -->|"指摘あり → タスクで修正・再提出（繰り返し）"| TT
    WIP -->|"チーム内確認・共有依頼（受注者）"| SH
    SH -->|"審査・承認（発注者）"| PB
    ASP -->|"承認完了（最終版）→ Archived へ"| AR
    SH -->|"業務・フェーズ完了時に保管（別枠）"| AR

最優先確認事項: 発注者（国・自治体）の情報セキュリティポリシーおよびガバメントクラウド方針によりクラウド利用可否・使用可能サービスが限定される場合がある。ストレージ選定は事業開始前に発注者と合意が必要。

5.2 承認フロー推奨パターン

KO-U（承認UI/UX）: 発注者担当者が直接操作する正式承認フロー（Shared→Published）でUI品質が低いと運用そのものが破綻する。P5〜P7の汎用UIは本フローへの適用不可。

5.3 得点順（承認パターン比較表）

評価基準（重み）: 監査性(40) / セキュリティ/コンプライアンス(30) / Usability(20) / インフラ・保守運用(7) / 導入コスト(3)

推奨（事業監理観点）: 本番運用ではP1ハイブリッドを目標に据え、まずP2単体でPoCを実施し、承認UIの課題が顕在化した段階でP3のフルスタック承認画面を追加するロードマップが最も現実的。P4〜P7は受注者内部フロー（TaskTeam/WIP系）に限定する。

5.4 Webhook起点での実装方式（比較）

非機能要件（実装言語・フレームワーク名より重要）

• Webhook署名検証と再送時の冪等性
• キューによる非同期化（大容量処理・再試行）
• task_id等による監査トレーサビリティ
• シークレット分離と最小権限実行

5.5 承認対象ごとの推奨実装

6. タスクチーム作業環境

タスクチームの作業環境はCDEの外側・各チーム裁量であり、CDE（SSOT）ストレージとは目的・要件が根本的に異なる。CDE選定で課したKO-A（認証付き外部共有）・KO-B（国内DC）は基本的に不要。代わりに、チーム内共有・ツール統合・CDEへの搬入しやすさが重要な評価軸となる。

6.1 作業環境の分類（前提条件）

候補を評価する前に、チームがどのネット環境で作業するかを先に確認する。

重要: 建設・インフラプロジェクトの大多数のチームは「事務所＋現場の両方で作業する」。オフライン同期の主体は個人PCではなくNAS（チーム共有ストレージ）である。個人PCのOneDrive/Box Driveキャッシュは各自に分散するため、チームで同じファイルに同時アクセスすると同期競合が発生する。NASをチームの共有作業ベースに置き、ネット復帰時にNAS→CDEへ定期同期する構成が現実的な標準パターン。

flowchart TD
    Q0{"社内ポリシーで<br/>外部クラウドへの<br/>直接接続が禁止？"}
    Q0 -->|はい| C["〔C〕自社VPN型<br/>大手ゼネコン・設計事務所等"]
    Q0 -->|いいえ| Q1

    Q1{"作業拠点の回線は<br/>光1Gbps以上か？<br/>（事務所・現場ともに）"}
    Q1 -->|はい| Q2
    Q1 -->|いいえ| B["〔B〕NAS＋CDE同期型（大多数）<br/>設計者・施工者・測量・コンサル等<br/>NASで作業 → ネット接続時にCDE WIPへ同期"]

    Q2{"BIM/CIMファイルを<br/>複数人が同時並行で<br/>編集する作業があるか？"}
    Q2 -->|いいえ| A["〔A〕高速常時接続型（少数）<br/>発注者窓口・自治体担当等<br/>クラウド直接アクセス可・NAS不要"]
    Q2 -->|はい| ABIM["〔A-BIM〕BIM/CIM同時並行編集<br/>① ACC（クラウド共同編集）<br/>② NAS＋CDE同期（〔B〕と同構成）も可"]

6.2 評価要件（T1〜T5）

6.3 候補・総合評価

各チームがすでに持っている環境を使うのが現実的。強制統一はコスト・運用負荷が高く不要。

〔B〕NAS＋CDE同期型（大多数のチームが該当）

〔A-BIM〕BIM/CIM同時並行編集

〔C〕自社VPN型

※a NASをCDEと同一サービスの同期対象に設定することで、NAS上の更新ファイルがWIPに自動または半自動で反映できる。
※b 手動アップロードの場合は「提出ルール（ファイル命名・提出連絡）」の徹底が提出漏れ防止の鍵
※c 提出時はNAS→CDEへのコピーまたはエクスポート操作が必要。提出ミス・タイムラグが生じやすい
※f ACCはAutodesk専用プラットフォームであり、Box等の汎用クラウドストレージとは別物。BIM/CIM作業ファイルを汎用クラウドストレージに直接保存・同期することは非推奨または動作保証外。CDEをBoxとする場合、BIM/CIMチームの作業ファイルはACC内に留まり、完成成果物（IFC・PDF・点群等）をCDE（Box）のWIPへエクスポート提出するワークフローが基本。

6.4 CDEとの接続ルール（重要）

タスクチーム作業環境が何であれ、WIPへの提出ルールを統一することが最重要。環境を強制統一するより、提出プロセスを標準化する方が現実的。

提出ルール（例）
① 成果物がチーム内でレビュー・合意済みであること
② ファイル命名規則に従っていること（[事業コード]_[図面番号]_[版数]_[日付]）
③ CDEのWIPフォルダの所定の場所にアップロード
④ 提出連絡（チャット・メール等）で発注者担当に通知
→ 以降はCDE管理（Shared→Published）へ移行

統合パターン（理想）: CDEをBoxとした場合、同一サービスの別フォルダをタスクチーム作業環境として使うことで、提出操作がフォルダ間の移動・コピーで完結する。ただしタスクチームフォルダのアクセス権限をCDE（WIP以降）と明確に分離することが必要。

7. 付録

7.1 可視化アプリ対応表

主要可視化アプリ・プラットフォームについて「主に対応する可視化層」「主な機能」「認証・連携」を整理する。実際の導入可否は各製品の最新仕様・契約条件で確認すること。

「可視化層」欄の凡例: 記載なし＝確認済み / （調査中）＝タイプA共有リンク対応・認証方式等の詳細が未確認。導入前に要確認。

注意: 各アプリの「認証方式（SAML/OAuth/独自）」「APIの有無」「データ所在（国内DC要件）」は導入前に必ず確認する。層2として使用する場合は、アカウント共有とタイプA共有リンク（パスワード付き・有効期限・ダウンロード制御）の両方に対応していることを事前に確認すること。 アカウント共有のみしか対応していないツールは、アカウントを持たない関係機関・下請け等への共有ができず、層2要件を単独では満たせない。

KOLC+（方式A 代表事例）

詳細は 4.10 方式A 代表事例: KOLC+ を参照。

torinome（方式B 代表事例）

詳細は 4.11 方式B 代表事例: torinome を参照。

7.2 認証・API・国内DC 暫定まとめ

下表は公開情報を基にした暫定評価。公共案件でのKO判定（国内DC必須等）を想定する場合、各ベンダーの官公庁向けプラン／ガバメントクラウド対応／契約書面での所在地明記を必ず取得すること。

7.3 NETIS と類似サービスの確認

• NETIS: 国土交通省が公開する新技術の情報データベース。技術の採用検討時はNETIS掲載や評価情報を確認することを推奨する — https://www.netis.mlit.go.jp/

推奨手順: NETISで該当技術・事例の有無をまず確認し、関係者向けPoC（大規模データでの表示性能試験、API/ワークフロー連携、データ保管・エクスポート可否、総所有コスト比較）を実施したうえで採用を決定する。