プロジェクトCDE

youtube／プロジェクトCDE：5層のブループリント

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

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

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-1　CDEの決裁フロー（WIP → Shared → Published / Archived）

1.3 管理対象業務フェーズ

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

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

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

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

• 調査（現況・支障物件・既存施設・他事業/計画調査）
  • 目的: 現況把握、支障物件の洗い出しと影響評価、既存施設・権利関係の確認、他事業との整合性確認。
  • 主な成果物: 調査報告書（PDF）、支障物件台帳（CSV/GeoJSON）、既存施設図面（PDF/DWG）、ジオタグ写真・撮影ログ（JPEG/MP4）、調査位置リスト（CSV/GeoJSON）。
  • 空間データ形式: GeoJSON, GeoPackage, Shapefile, CSV（座標付き）、写真はEXIF/GPSを付与。
  • メタデータ（必須）: 調査日、担当者、手法、信頼度（精度）、参照元、関連事業ID、ssot_id。
  • 調査方法の留意点: 現地踏査＋既存図面照合を基本とし、支障箇所は位置・所有者・使用状況・移設可否・概算費用を記載する。既存施設は構造・材質・更新履歴を確認する。
  • 運用: 原本はCDEで保管し、支障物件・既存施設はGISレイヤとして登録。ssot_idで他データ（設計・測量・施工）と連携してトレーサビリティを確保する。
  • 検証ポイント: 既存図面との差分リスト、優先度（緊急/高/中/低）、行政手続きや補償の要否、施策案の推奨。
  • 台帳例（支障物件）: id,title,epsg,lon,lat,owner,status,impact_level,remediation_estimate,file_url
• 測量（基準測量・詳細測量・観測）
  • 制御点・基準点座標：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は5層構造で成立する。下位3層（第1〜3層）はデータの蓄積・統合・高度化を担う技術基盤であり、上位2層（第4〜5層）はそのデータを活用して事業をマネジメントし、関係者と共有・公開するガバナンス層である。技術基盤だけでは「データを保管しているだけ」になり、ガバナンス層だけでは根拠となるデータが整備されない。この5層が一体となって初めてプロジェクトCDEは機能する。

第1層：蓄積・保管層

蓄積・保管層（業務データ基盤）

目的: SSOT（原本）を確実に保持し、業務データの取り込み・長期保管・ETL・メタデータ管理・高速API提供を行う基盤。RAG用のインデクシングや埋め込み生成を組み込み、AI支援機能へのデータ供給を想定する。

• 主な機能: ファイル原本管理、バージョン管理、メタデータカタログ、バックアップ、監査ログ、データライフサイクル管理、大容量ファイルの効率的保存（IFC/LAS/GeoTIFF 等）。
• RAG対応: 埋め込みパイプライン、ベクトルDB＋メタデータストア、再インデックス化ポリシー、応答品質評価と出典トレーサビリティ。

蓄積・保管層（アクセス制御とデータ共有）

概要: 認証・認可・共有ポリシー・監査ログは蓄積層の核となる機能であり、誰がどのデータをどの条件で閲覧・取得・操作できるかを厳密に定義・実施する。Exchange/WIP/Shared/Published の各ステータスに応じた共有ルール、共有方法の種類（限定共有／公開共有）、有効期限・ダウンロード制御・匿名化ポリシーなどをここで管理する。

• 主な機能: ID管理（OIDC/OAuth2）、アクセス制御リスト／ロール、共有方法管理（限定共有／公開共有の有効期限・パスワード・ダウンロード可否）、監査ログ・操作記録、データマスキングとPII対策。
• 運用要点: 権限分離（最小権限）、承認ワークフロー連携（WIP→Shared→Published）、定期監査、国内DCやガバメントクラウド方針対応。

第2層：統合・可視化層（GIS基盤）

目的: 空間データ（ベクタ・ラスタ・点群・BIM）の統合・変換・配信・可視化を担う。

• 主な機能: 空間DB(PostGIS)・OGC配信(WMS/WFS/3DTILES/MVT)、2D/3Dタイル化、タイルキャッシュ、ビューア連携（Cesium, Leaflet 等）。
• 運用要点: 派生物はSSOT起点でCI化して生成、GetFeatureInfo等で文書と紐付けて即時参照可能にする。

第3層：デジタルツイン活用層

目的: BIM/点群/センサを統合し、現場の同期・シミュレーション・検証を行う層。

• 主な機能: モデル統合・時間同期・シミュレーション・解析（出来形・安全性・影響評価）、VR/AR 表示。
• 運用要点: 時系列管理とリアルタイムデータパイプライン、モデル整合ルールの明文化。

第4層：事業監理層（AI支援）

目的: 第1〜3層のデータを活用し、事業監理の意思決定支援（概算・予測・要約・検索）を提供する層。

• 主な機能: 予測分析、概算算出支援、要約・レポート生成、インテリジェント検索（RAG）、異常検知、ワークフロー自動化。
• 推奨構成: 埋め込み → ベクトルDB → レトリーバ → LLM（出典付きプロンプト）＋出力トレーサビリティ。
• 運用ポイント: 事業監理が前提・精度目標・最終承認を担い、AI支援はデータ準備・自動算出・レポート作成を実行。概算は「意思決定資料」として入札用積算と明確に区別する。

第5層：公開・ガバナンス層（SSOT共有・公開）

目的: 承認済みデータの配信と公開ポリシー適用。Published のデータのみ公開し、派生物の整合性を保証する。

• 主な機能: 公開用派生物管理、アクセス制御・ライセンス表示、公開版のライフサイクル管理、公開監査ログ。
• 運用要点: SSOT起点の派生生成を必須とし、公開データの出所・ライセンス・更新履歴を明示する。

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

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

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

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

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

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

2. 蓄積・保管層（業務データ基盤）

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

2.1 選定要件

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

必須条件（KO条件）

表2-1　必須条件（KO条件）一覧

評価要件（重みづけ）

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

表2-2　評価要件（重みづけ）一覧

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

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

表2-3　ストレージ候補の比較・総合評価

※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登録状況

表2-4　ISMAP登録状況（2026年4月時点）

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

2.4 推奨　

表2-5　推奨ストレージ一覧

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

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

フォルダ階層の設計方針：ステータス（Exchange / TaskTeam / WIP / Shared / Published / Archived）を最上位に置き、業務フォルダは下位にまとめる。これにより権限付与はステータス単位で済み、設定ミスやメンテナンスコストを低減できる。

要点（短く）

• ステータスを最上位にする（検索・権限制御の一貫性）
• 協議（外部向け）は 03_.../Published まで到達させる
• 内部会議記録は横断フォルダ 00_会議・議事録 に集約する
• 実データ（正本）は 06_External_SSOT に置き、CDE には必ずマニフェストを置く

会議・協議の使い分け（簡潔表）

補足：00_会議・議事録 は横断的に参照できるようにして、内部会議の検索性を担保する。

推奨フォルダ構成（詳細ツリー）

📁 [事業名]-プロジェクトCDE
│
├── 📁 00_Exchange【やり取り】   ← 【例外措置】CDE外からの受領ファイルを一時保管する場所
│   │              ※業務分類は行わず、年月等で管理。重要なものは後でShared等に移す。
│   │              ※送信控えはここではなく送信時にShared/Publishedで管理すること
│   ├── 📁 202604_〇〇省から受領
│   └── 📁 202604_ライフライン事業者から受領
│
├── 📁 01_TaskTeam【タスクチーム】   ← CDE上の各チーム作業フォルダ（当該チームのみアクセス可）
│   └── 📁 [業務名]
│       ├── 📁 00_会議・議事録        ← 【横断】事業調整会議・定例会議・設計レビュー等の議事録
│       ├── 📁 01_事業全体計画の整理
│       ├── 📁 02_測量・調査・設計業務等の指導・調整等
│       ├── 📁 03_地元及び関係行政機関等との協議   ← 協議（外部機関との正式な折衝）の成果物
│       ├── 📁 04_事業管理
│       ├── 📁 05_施工管理
│       ├── 📁 06_BIM-CIM（統合モデル）活用支援
│       └── 📁 07_その他（維持管理・電子納品等）
│
├── 📁 02_WIP【作業中】        ← 当該タスクチームのみ書込可・正式CDE管理の入口
│   └── 📁 [業務名]
│       ├── 📁 00_会議・議事録        ← 【横断】事業調整会議・定例会議・設計レビュー等の議事録
│       ├── 📁 01_事業全体計画の整理
│       ├── 📁 02_測量・調査・設計業務等の指導・調整等
│       ├── 📁 03_地元及び関係行政機関等との協議
│       ├── 📁 04_事業管理
│       ├── 📁 05_施工管理
│       ├── 📁 06_BIM-CIM（統合モデル）活用支援
│       └── 📁 07_その他（維持管理・電子納品等）
│
├── 📁 03_Shared【共有】     ← 承認済み・プロジェクト関係者全員閲覧可
│   ├── 📁 00_会議・議事録        ← 【横断】承認済み議事録（事業調整会議・定例会議等はここが最終到達点）
│   ├── 📁 01_事業全体計画の整理
│   ├── 📁 02_測量・調査・設計業務等の指導・調整等
│   ├── 📁 03_地元及び関係行政機関等との協議
│   ├── 📁 04_事業管理
│   ├── 📁 05_施工管理
│   ├── 📁 06_BIM-CIM（統合モデル）活用支援
│   └── 📁 07_その他（維持管理・電子納品等）
│
├── 📁 04_Published【活用】  ← 承認済み現行版（関係機関等での活用）
│   │                       ※ 00_会議・議事録は通常ここに昇格しない（内部文書のため）
│   ├── 📁 01_事業全体計画の整理
│   ├── 📁 02_測量・調査・設計業務等の指導・調整等
│   ├── 📁 03_地元及び関係行政機関等との協議   ← 協議議事録・配布資料はPublishedまで通す
│   ├── 📁 04_事業管理
│   ├── 📁 05_施工管理
│   ├── 📁 06_BIM-CIM（統合モデル）活用支援
│   └── 📁 07_その他（維持管理・電子納品等）
│
├── 📁 05_Archived【アーカイブ】   ← 変更不可。業務・工事完了時の成果物・納品物を保管
│   ├── 📁 01_土木設計業務等   ← 設計・測量・調査・事業管理等の業務完了時の報告書・成果品
│   └── 📁 02_工事完成図書     ← 工事完了時の完成図・施工記録・出来形・品質管理書類等
│
└── 📁 06_External_SSOT【外部SSOT】   ← 実データはS3等に配置。Box には必ずマニフェストを置く
    ├── 📁 01_CAD・BIM-CIM　　　　　　　← ACC/FORMA等の外部CAD・BIMプラットフォームへのマニフェスト
    ├── 📁 02_GIS【地理空間データ】     ← ラスタ（高解像度）、ベクタ、タイル、点群、タイル配信設定
    ├── 📁 03_DT【デジタルツイン】     ← 3Dタイル、BIM同期データ、時系列センサデータ
    └── 📁 04_RAG【検索／RAG用埋め込み】← 埋め込みベクトル、ベクタDB参照、原文テキストの索引

ガイドラインとの関係：業務分類 01〜07 は事業監理業務の標準分類（国土技術政策総合研究所等の提案に基づく）に準拠している。00_会議・議事録 は業務横断的な性質を考慮した実務上の追加であり、01〜07 の分類体系を変更するものではない。

06_External_SSOT の具体構成

• 01_CAD・BIM-CIM/ — ACC/FORMA 等の外部CAD・BIMプラットフォームに格納された Published IFC/DWG へのマニフェスト（実ファイルは外部プラットフォーム上）
• 02_GIS/ — GeoTIFF 等ラスタ、タイル、ベクトル、点群バックエンド（CRS/解像度等のメタを含む）
• 03_DT/ — 3Dタイル、BIM 同期データ、時系列センサデータ（バージョン管理・同期ログ）
• 04_RAG/ — 前処理テキストの索引用マニフェスト／埋め込み参照情報（埋め込み本体は専用ベクタDBへ）

（注）元文書の受領・前処理は内部DMS等で行い、公開用正本が必要な場合に限り 06_External_SSOT に配置して Box のマニフェストで紐付ける運用としてください。

マニフェスト（CDE 側） — 最低限の必須項目

• ssot_id — 正本の一意識別子
• consumer — CAD/GIS/DT/RAG 等のカテゴリ
• s3_path / db_uri — 正本の実体参照
• checksum — 整合性確認用
• version — バージョン
• published_at — 公開日時
• owner — 所有部署／担当者
• access_policy — アクセス制御情報（署名付きURL TTL 等）

運用フロー（簡潔）

1. 協議で外部提供合意成立 → 担当が実データを External SSOT に登録
2. マニフェスト（published_manifest_<案件>.yaml）を 03/.../Published に配置して承認メタを残す
3. 承認後、署名付き URL や API を発行・通知（Webhook による通知を推奨）

注意点（要点のみ）

• マニフェストは検索性と監査の鍵。ssot_id と consumer を必須にすること
• マニフェスト索引（横断索引）はプロジェクト要件に応じて別途運用（必要時に設置）してください
• 実データは配信性能や保存要件に応じて S3/PostGIS/専用DB を使い分ける

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へ提出する。

2.7 External_SSOT【外部SSOT】の運用ルール（例外措置）

目的: 06_External_SSOT 配下を子フォルダ単位で整理し、各フォルダで扱うデータ、保存先、最小運用要件を明確にする（06_External_SSOTでの利用として）。

注: 06_External_SSOT は、01〜05 の業務分類で管理される原本（CDE側の一次ソース）を置き換えるものではありません。CDE（01–05）がメタデータ・承認・一次管理を担う一方で、外部システム連携や配信要件に応じて外部ストレージに正本の複写を作成・整理し、配信／参照を行うための運用領域として位置づけます。 以下は 06_External_SSOT/ の子フォルダ別の簡潔な説明と運用要件（CAD・BIM-CIM/GIS/DT/RAG に集約）。

01_CAD・BIM-CIM — CAD・BIM/CIM

• 役割: ACC / FORMA 等の外部CAD・BIMプラットフォームに格納された Published IFC/DWG ファイルへのマニフェスト管理。実ファイルは外部プラットフォーム上に存在し、Box にはマニフェストのみを置く。
• 保存先（実データ）: Autodesk Construction Cloud（ACC）/ FORMA / 専用BIMストレージ
• 要件: プラットフォームURL・ファイルID・バージョン・承認日を含むマニフェストを必置。常に変化する作業中CADは対象外（TaskTeam管理）。Published 相当のファイルのみを対象とする。

02_GIS — 地理空間データ

• 役割: ラスタ（GeoTIFF等）、タイル、ベクトル、点群の正本管理。
• 保存先: S3（ラスタ/タイル）、PostGIS（ベクトル）、点群タイルストア
• 要件: CRS・解像度等のジオメタデータを含め、タイル化・配信要件を明示する。

03_DT — デジタルツイン

• 役割: 3Dタイル、BIM 同期データ、時系列センサデータの正本管理。
• 保存先: S3 / 専用BIMストレージ / 時系列DB
• 要件: バージョン管理・同期ログ・時間解像度メタを保持する。

04_RAG — 検索／RAG用埋め込み

• 役割: 前処理テキスト、索引用メタ、埋め込み参照情報（埋め込み本体は専用ベクタDBで管理）
• 保存先: 前処理テキストは Box（レビュー用）／埋め込みは専用ベクタDB
• 要件: 前処理手順・モデルID等の再現性メタを保持し、個人情報は除去または匿名化する。

共通の必須運用要件（要点）

• マニフェストは Box に置き、ssot_id / consumer（CAD-BIM/GIS/DT/RAG 等） / s3_pathまたはdb_uri / version / owner / access_policy を明記すること。
• 実データは External SSOT に正本を置き、Box はメタデータ・承認証跡・サムネイル等の参照用に用いる。
• 元文書の前処理は内部DMS等で行い、公開用正本は 06_External_SSOT に保管して Box のマニフェストで紐付ける。

3. 蓄積・保管層（アクセス制御とデータ共有）

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

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

意思決定フロー

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

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

表3-1　アクセス制御・データ共有の三層（概要）

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

共有方法

• アカウント（認証付き）: 組織アカウントでのアクセス。SSO/MFA・RBAC・監査ログにより高忠実度データの安全共有に適する。プロビジョニング（SCIM）とライフサイクル管理を組み合わせ、外部ユーザには短期トークンでのアクセスを推奨する。
• 限定共有（署名付き短期URL／ID＋パスワード）: 外部委託先や関係機関向けの限定共有。有効期限・ダウンロード制御・パスワードで安全性を高める。可能なら署名付き短期URL（HMAC/JWTベースの署名・TTL・ワンタイム）を優先する。
• 公開共有（パブリック）: アカウント不要の一般公開リンク。公開対象は匿名化・軽量化した派生物のみに限定し、CDN/WAF/レート制限で配信する。

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

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

• 共有方法: 公開共有（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-2　役割別：工事関係者の可視化層割当（例）

3.8 関係機関との情報共有

主な関係機関と共有内容

表3-3　主な関係機関と共有内容

情報共有の設計方針

表3-4　情報共有の設計方針

4. 蓄積・保管層（タスクチーム作業環境）

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

4.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〕と同構成）も可"]

表4-1　タスクチーム作業環境の分類（前提条件）

4.2 評価要件（T1〜T5）

表4-2　タスクチーム作業環境の評価要件（T1〜T5）

4.3 候補・総合評価

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

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

表4-3　〔B〕NAS＋CDE同期型 候補・総合評価

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

表4-4　〔A-BIM〕BIM/CIM同時並行編集 候補・総合評価

〔C〕自社VPN型

表4-5　〔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へエクスポート提出するワークフローが基本。

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

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

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

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

5. 統合・可視化層（GIS基盤）

GISとデジタルツインの整理

概念	役割	主目的	本書での位置づけ
GIS基盤（本章）	地理空間データの管理・配信・2D/3D可視化	空間的意思決定支援・台帳管理・データ配信	空間データ統合の基盤（手段）
デジタルツイン活用層（第5章）	GIS/BIM/IoTを統合し現実をデジタルで再現・同期	状態監視・シミュレーション・AR/VR活用	GIS基盤を活用する上位層（目指す姿）

本章はGIS基盤（空間データの管理・配信・可視化）を扱う。デジタルツイン的な活用（リアルタイム同期・シミュレーション・XR）は第5章で整理する。

5.1 全体構成と役割

GIS基盤・空間データ可視化基盤は、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 等）]

表5-1　空間データ可視化基盤の構成要素

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

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

表5-2　データ処理パイプライン（ETL処理内容）

共通ETL要件

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

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

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

表5-3　GIS基盤（空間統合・属性管理）の機能一覧

LIZMAP を動作させるための VM 候補

以下は QGIS Server + Lizmap Web Client を用いた可視化ポータルを想定した VM 構成候補です。実運用ではトラフィック量・同時接続数・タイル生成負荷・タイルキャッシュ有無に応じて調整してください。

• 開発 / 評価（小規模テスト）
  • CPU: 2 vCPU
  • メモリ: 4 GB
  • ディスク: 50 GB SSD
  • OS: Ubuntu LTS（例: 22.04以降）
  • 備考: 単一ノードで動作確認。低負荷・少人数の検証用。
• 小規模本番（少数ユーザ）
  • CPU: 4 vCPU
  • メモリ: 8–16 GB
  • ディスク: 100–150 GB SSD（IOPS に余裕を）
  • 備考: PostGIS を同一 VM に置けるが、データ量が増える場合は分離を検討。
• 中規模本番（複数同時ユーザ・タイル生成あり）
  • CPU: 8 vCPU
  • メモリ: 32 GB
  • ディスク: 250 GB SSD（高速IO推奨）
  • 備考: PostGIS を別ノード／マネージド DB に分離。タイルキャッシュ（MapProxy/TileCache）や Redis を併用。
• 高可用 / スケーラブル構成（推奨：本番大型）
  • 構成例: Web層（複数の Lizmap Web Client コンテナ） + QGIS Server ノード群（LB配下） + PostGIS（主従構成またはマネージド） + 分散キャッシュ/オブジェクトストレージ（S3互換）
  • 各 Web ノード: 4–8 vCPU / 16–32 GB
  • QGIS Server ノード: 8 vCPU / 32 GB（負荷に応じて水平スケール）
  • 備考: Kubernetes 等でコンテナ化し、水平スケール＋LBで対応するパターンが運用性に優れる。

運用上の注意（短く）

• OS: Ubuntu LTS 系を推奨。セキュリティ更新は自動化する。
• QGIS Server: LTR（長期サポート）バージョンを利用し、Lizmap の対応バージョンを確認する。
• PostGIS: データ量が多い場合は I/O とメモリを重視。VACUUM / autovacuum 設定を適切に調整する。
• キャッシュ: タイル・OGCレスポンスのキャッシュ（Varnish/Redis/MapProxy）を導入するとレスポンスが大幅改善する。
• バックアップ: PostGIS とタイルストアのスナップショット/バックアップ運用を必須とする。
• TLS/認証: 公開・関係者共有に応じて OIDC/SSO を導入し、Lizmap の権限管理と連携する。

（参考）クラウド/オンプレ候補

• AWS: EC2（汎用・汎用メモリ最適化）、RDS / Aurora（PostGIS 対応）、S3（タイル・オブジェクト）
• Azure: Virtual Machines、Azure Database for PostgreSQL、Blob Storage
• GCP: Compute Engine、Cloud SQL（Postgres）、Cloud Storage
• オンプレ: VMware 仮想マシン（vCPU/メモリを上記目安に割当）、ストレージは高速 SSD を推奨

上記は目安です。負荷試験（同時接続・タイル生成）を実施して実運用構成を確定してください。

ISMAP 登録（主要クラウド）

以下は主要クラウド事業者の ISMAP 登録状況（主要公開情報に基づく）。

• AWS (Amazon Web Services): 登録済み（サービス単位で対象範囲が異なるため、該当サービス行の 登録番号 を ISMAP ポータルで確認してください） — 参照: https://www.ismap.go.jp/csm?id=cloud_service_list 、https://aws.amazon.com/jp/compliance/ismap/
• Microsoft (Office 365 / Azure): 登録済み — 登録番号: C21-0013-2 — 参照: https://www.ismap.go.jp/csm?id=cloud_service_list
• Google Workspace: 登録済み — 登録番号: C21-0005-2 — 参照: https://www.ismap.go.jp/csm?id=cloud_service_list
• Box: 登録済み — 登録番号: C21-0017-2 — 参照: https://www.ismap.go.jp/csm?id=cloud_service_list
• Dropbox Business: 登録済み — 登録番号: C24-0075-2 — 参照: https://www.ismap.go.jp/csm?id=cloud_service_list
• さくらのクラウド（さくらインターネット）: 登録済み — サービス単位の登録番号は ISMAPポータル 側の該当行を確認してください — 参照: https://manual.sakura.ad.jp/cloud/ismap/index.html
• IIJ（IIJ GIO 等）: 登録済み — サービス単位で登録番号あり、該当サービスの ISMAP エントリを参照してください — 参照: https://www.iij.ad.jp/（IIJ GIO 案内）および ISMAP ポータル
• NTT（NTTデータ等の該当サービス）: 登録済み（例: NTTデータ OpenCanvas 等） — 登録番号はサービスごとに異なるため ISMAP ポータルを参照してください

各社の ISMAP ポータル検索（例）

• AWS: https://www.ismap.go.jp/csm?sysparm_query=Amazon%20Web%20Services
• Microsoft: https://www.ismap.go.jp/csm?sysparm_query=Microsoft%20Office%20365
• Google: https://www.ismap.go.jp/csm?sysparm_query=Google%20Workspace
• Box: https://www.ismap.go.jp/csm?sysparm_query=Box
• Dropbox: https://www.ismap.go.jp/csm?sysparm_query=Dropbox%20Business
• さくら: https://www.ismap.go.jp/csm?sysparm_query=%E3%81%95%E3%81%8F%E3%82%89%E3%81%AE%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89
• IIJ: https://www.ismap.go.jp/csm?sysparm_query=IIJ%20GIO
• NTT: https://www.ismap.go.jp/csm?sysparm_query=NTT%20Data

注: ISMAP は多くの事業者で「サービス単位」かつ「リージョン／機能範囲」ごとに登録が行われます。正式な調達・利用判断では、上記の簡易表に加え ISMAP クラウドサービスリスト の該当行で登録番号・登録日・対象範囲（サービス名／リージョン）を必ず確認してください。

もし私の方で 登録番号（ISMAP ポータル上の「登録番号」列）を各社ごとに1つずつ取得して本文に明記してよろしければ、続けて各該当ページを掘り登録番号と登録日・参照 URL を追記します。

概算価格比較（目安・月額）

前提（見積条件の例）: 東京リージョン相当、OS: Ubuntu、ストレージ: 250 GB SSD、帯域: 小〜中程度、オンデマンド課金（割引/リザーブ未考慮）。実運用ではマネージド DB・バックアップ・サポート費用・データ転送量が別途必要。

• AWS / Azure / GCP（パブリック大手）
  • 小規模（4 vCPU / 8–16 GB）: 約 ¥15,000〜¥35,000
  • 中規模（8 vCPU / 32 GB）: 約 ¥60,000〜¥140,000
  • 高可用（マルチノード + マネージドDB + オブジェクトストレージ）: 約 ¥200,000〜¥600,000
• さくらのクラウド（国産 IaaS）
  • 小規模: 約 ¥10,000〜¥30,000
  • 中規模: 約 ¥50,000〜¥110,000
  • 高可用: 約 ¥150,000〜¥450,000
• IIJ / NTT（エンタープライズ / 法人向け）
  • 小規模: 約 ¥20,000〜¥40,000
  • 中規模: 約 ¥80,000〜¥160,000
  • 高可用: 約 ¥250,000〜¥700,000
• SaaS 型（Box / Dropbox 等）
  • 比較対象が異なるため IaaS と直接比較不可（例: Dropbox Business ユーザ課金 約 ¥1,000〜¥2,500/ユーザ/月、Box も同程度）。

注意: 上記は概算レンジです。実際の見積りは「想定同時接続数」「タイル生成頻度」「バックアップ保持期間」「ネットワーク egress」「サポートレベル（SLA）」で大きく変動します。公共案件では ISMAP 適合確認と同時に、各社から正式な見積（構成＋サポート）を取得してください。

（参考）国内クラウド / ホスティング候補

• さくらのクラウド（さくらインターネット）: 国内データセンタで稼働する IaaS。VM の柔軟な構成が可能で国内拠点要件を満たしやすい。ブロックストレージやオブジェクトストレージとの組合せでタイル保管やバックアップ運用が容易。

• IIJ GIO / IIJ のクラウドサービス: 法人向けの高信頼クラウド・マネージド DB 提供があり、国内拠点・運用サポートを重視する案件に適する。PostGIS 運用のマネージドサービスが利用可能な場合は運用負荷軽減につながる。

• NTT Communications / NTT グループのクラウド: 国内データセンタと高いネットワーク品質を提供。エンタープライズ向けの SLA・セキュリティ要件が重要な公共案件に向く。

• さくらのVPS / 国内専用ホスティング: 小規模・試験的な導入やコスト最優先のケースで検討可能。ただし I/O 性能やスケール性に注意。

注: 上記国内サービスは「国内データセンタ要件」に対応しやすい候補ですが、ISMAP 登録状況・契約条件・運用サポート内容は随時確認が必要です。公共案件では必ず ISMAP 等の適合確認を行ってください。

ID連携原則

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

5.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化し、差分更新（インクリメンタル）対応を実装

5.5 2D配信（OGC準拠）

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

表5-4　推奨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による双方向参照）

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

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

表5-5　事業監理機能一覧（SSOT活用層）

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

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

表5-6　可視化基盤のアクセス制御・配信設計

共通要件

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

5.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設計書（試験データ・評価指標・スケジュール）を作成し、実行→評価→運用ルール反映のサイクルを回すことを推奨する。

5.9 データ利用方式の分岐

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

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

表5-7　データ利用方式の全体対応表（層・方式・共有方法・アプリ）

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

ネイティブ方式（原本ネイティブ運用）

概要

ネイティブ方式は、設計・測量・BIM 等の原本ファイル（DWG/IFC/LAS/ LandXML 等）を変換せずそのまま SSOT として管理し、専門ツールで直接開いて利用する運用モデルです。精度・セマンティクスを損なわず随時更新を反映できる点が最大の特徴で、層1（設計編集）を主目的に想定されます。

主なメリット

• 精度保持: 元ファイルの座標精度や階層・属性をそのまま維持できるため、設計・解析での誤差を最小化できる。
• 既存ワークフローの継続: 専門担当者は普段使っているツールを変えずに作業でき、学習コストが低い。
• 即時反映: 差分アップロードで最新状態に追従でき、出来形計測など頻繁更新に適する。
• 出典性: SSOT として原本を保管することで、トレーサビリティが明確になる。

適用場面

• 層1（設計編集）: 詳細設計、BIMモデリング、点群処理など専門ツールで直接編集・解析する場面。
• 層2の専門担当向け: Trimble Connect や専用ビューア経由で共有し、関係者（施工管理者・監理者）が原本を精査する場合。
• 出来形チェック・品質管理: 高精度な比較や差分解析が必要な工程。

フォーマット別の使い分け（ネイティブ前提）

• CAD: DWG/DXF（詳細図・線形）— 精密図面・寸法管理に最適。
• BIM: IFC/RVT — 階層・属性・部材情報を保持し設計連携に有効。
• 点群: LAS/LAZ — 高精度出来形・計測解析に必須。Entwine 等でタイル化する前の原本保持が重要。
• 土木データ: LandXML/CSV — 断面・縦横断・土量計算の原点として管理。

簡易アーキテクチャ

SSOT（CDE: 原本保管）→ 専門ツールアクセス（直接ダウンロード or マウント）→ 編集 → CDEへ差分アップロード（WIP→Shared→Published ワークフロー）

差分アップロードをトリガーに、必要に応じて派生タイル（XYZ/MVT/3DTILES）を生成する ETL を動かすのが望ましい。

PoC（最小手順）

1. 代表的な原本ファイル（IFC/DWG/LAS）を CDE に登録する。
2. 専門ツールで原本を開き、小規模編集（注記・修正）を実施して差分を CDE にアップロードする。
3. 差分イベントで ETL を起動し、派生タイルの再生成が行えることを検証する。
4. バージョン管理（ssot_id + version）とアクセスログが残ることを確認する。

検証ポイント

• 精度とセマンティクス: 変換やエクスポートを行った場合の座標ズレ・属性欠落の有無を原本と比較する。
• 反映フロー: 差分アップロード→派生物再生成（インクリメンタル）が期待どおり動くか。
• 認可・排他制御: ファイルロックやWIPフローで同時編集による競合が防げるか。
• 運用コスト: 大容量ファイルの転送・保管コストと、変換を伴う運用の工数を見積もる。

運用上の推奨

• ハイブリッド運用: ネイティブ原本は SSOT として保管し、公開・共有用には自動的にタイル派生物を生成するハイブリッド運用を推奨する。
• 差分トリガーの自動化: CDE のイベント（ファイル更新）をトリガに ETL をCI化し、派生物の整合性を常に担保する。
• 権限管理: 層1向けの厳格な認証（SSO/MFA）と排他制御（チェックアウト/チェックイン）を導入する。
• テスト基準: 大規模モデルでレンダリング・転送性能を予め PoC で検証し、容量・帯域に応じた運用ポリシーを定める。

表5-8　ネイティブ方式 評価サマリ

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

タイル配信方式（XYZ/MVT/3DTILES）

概要

タイル配信方式とは、原本を CDE に保管しつつ、表示・公開用途に最適化した派生データ（2D/3Dタイル）を生成して配信する手法です。ブラウザ／モバイル／AR クライアントでの軽快な表示と大規模同時配信を目的とします。

主なメリット

• 広域かつ高速配信（事前生成タイル＋CDN）
• 表示中の範囲のみ取得するため帯域・描画負荷が低い（タイル分割／LOD）
• モバイル／AR に適した軽量ストリーミング（3DTILES/glTF + 圧縮）
• 公開／限定共有の使い分けが容易（署名付きURL／OAuth／CDN制御）

適用場面（簡潔）

• 層2（関係者共有）: 認証付きタイルで関係者に高速共有
• 層3（公開）: CDN 経由で住民向け広報・地図公開
• AR/現場: 3DTILES/glTF を現地表示や WebAR に利用

フォーマット別の使い分け

• ラスタ（航空写真／オルソ）: XYZ / WMTS（背景タイル）
• ベクタ: MVT(PBF)（検索・スタイル可変な地物）
• 3D: 3DTILES / glTF（BIM・点群・都市モデル）

簡易アーキテクチャ（概略）

CDE（原本） → ETL/変換ワーカー → タイルストア（MBTiles / オブジェクトストレージ） → CDN → クライアント

（認証領域はプロキシ／署名付きURL／OAuth で制御）

PoC（最小手順）

• ラスタ（GeoTIFF → XYZ）: gdal2tiles.py -z 0-18 input.tif tiles/
• ベクタ（GeoJSON → mbtiles）: tippecanoe -o data.mbtiles -zg input.geojson
• 3D（LAZ → Entwine EPT → 3DTILES）: entwine build -i /path/laz -o /path/ept → py3dtiles 等で 3DTILES 生成

各出力を S3 等に置き CDN に配信し、MapLibre/CesiumJS で簡易確認する。

検証ポイント

• 変換による座標ズレ／属性欠落の有無（原本との差分比較）
• ズーム別レスポンスと CDN キャッシュ効率
• 更新サイクル（差分再生成の所要時間）
• 公開用の匿名化・解像度調整の妥当性

運用上の推奨

• 原本は SSOT として CDE に保持し、差分登録をトリガーに CI 化した ETL で派生タイルを再生成する。
• 公開用は属性削減・匿名化版のみ配信し、認証領域は署名付きURLやプロキシで保護する。
• PoC ではラスタ／ベクタ／3D のうち一つをまず検証し、次にハイブリッド運用を確認する。

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

原本（ネイティブ方式（原本ネイティブ運用））は CDE で SSOT として保管・管理し、共有・公開・AR 用にはタイル配信方式（XYZ/MVT/3DTILES）の派生物を自動生成する。

[CDE: 原本保管（SSOT）— ネイティブ方式]
    │  層1: アカウント認証で専門ソフトから直接利用
    ↓ 更新イベントをトリガーに自動ETL（タイル配信生成）
[PostGIS + タイルストア]
    ├── 2D: XYZ/WMTS/MVT タイル  ← 層2（認証）/ 層3（公開）
    └── 3D: 3DTILES / glTF        ← 層2（認証）/ 層3（公開）/ AR
    ↓
[配信サーバ + CDN]
    ├── 層2（アカウント認証 ＋ 限定共有）: Lizmap / CesiumJS / torinome Base（認証付き）
    ├── 層3（公開共有）: 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 ステータスを通過したものだけ配信を許可する。

6. デジタルツイン活用層

本章の位置づけ
デジタルツイン活用層は、「GIS基盤（第4章）が提供する空間データ」を活用して、現実の物理対象（構造物・インフラ・都市）をデジタル空間上に再現・同期する。GISが「手段」であるのに対し、デジタルツインは「目指す姿・活用層」である。本章では代表的なDTプラットフォームとして 建設BIM/CIM DT（KOLC+: 5.5）・スマートシティ都市DT（Re:Earth: 5.6）・XRデジタルツイン（torinome: 5.4） を取り上げる。

6.1 GIS基盤とデジタルツインの関係

GIS基盤（第4章）= データインフラ
  │
  ├── データ保管・処理
  │       ・ PostGIS（空間DB）/ GeoServer（OGC配信）/ TileServer GL
  │       ・ ETLパイプライン（GDAL/PDAL/py3dtiles）→タイル生成
  │
  ├──▼タイル配信エンドポイント：ここが接続界面▼───
  │       【■ 2Dタイル】 XYZ・WMTS（ラスタ）/ MVT/PBF（ベクタ）
  │       【■ 3Dタイル】 3D Tiles（OGC標準）/ glTF/GLB
  │       → このエンドポイントを読み取る側が「DT活用層」
  │
  └── 活用層（デジタルツイン）= アプリケーションプラットフォーム
          ・ 建設BIM/CIM DT: KOLC+（4D工程・出来形・現場リアルタイム同期）
          ・ 都市DT: Re:Earth / PLATEAU VIEW（スマートシティ・住民説明会）
          ・ XR DT: torinome（CesiumJS基盤・広域表示＋AR/VR/WebAR）
          ・ IoTリアルタイム同期・シミュレーション・将来予測

タイルが接続界面: GIS基盤とDT活用層の連携はタイル形式を通じたエンドポイントで行われる。GIS基盤は2D（XYZ/WMTS/MVT）・3D（3D Tiles）のタイルを生成・配信する「タイルプロバイダ」であり、DTプラットフォームはそのタイルを取得・レンダリング・ XR展開する「タイルコンシューマ」である。この分業が高速性・大視点共有・XR連携を同時成立させる根拠である。

表6-1　GISとデジタルツインの役割の違い

6.2 デジタルツインの構成要素

表6-2　デジタルツイン構成要素

6.3 デジタルツイン・ロードマップ

プロジェクトCDEにおけるデジタルツインの展開は段階的に進めることを推奨する。

ステップ1（入口）: GIS基盤でBIM/IFC・点群・都市モデルの3D可視化を実現する。
ステップ2（展開）: IoTセンサー・現場データとのリアルタイム連携を追加する。
ステップ3（成熟）: シミュレーション・AR/VR活用まで拡張し、事業全体の意思決定・住民説明・維持管理を支援する。

デジタルツインプラットフォーム代表事例: 建設BIM/CIM DT「KOLC+」は本章 5.4 に、スマートシティ都市DT「Re:Earth」は本章 5.5 に、XRデジタルツイン「torinome」は本章 5.6 に記載する。

表6-3　DTプラットフォーム比較（KOLC+ / Re:Earth / torinome）

使い分けの目安: 工事現場スケールの進捗・出来形・リアルタイム同期 → KOLC+。都市・地域スケールの広域可視化・ノーコード・PLATEAU・公共実績重視 → Re:Earth。広域 CesiumJS 表示 ＋ AR/VR/WebARのXR体験まで一気通貫 → torinome。

6.4 KOLC+（建設BIM/CIMデジタルツインプラットフォーム）

BIM/CIM・点群・設計データを統合し、現場と設計・監理の状態をリアルタイムで同期する建設向けデジタルツインプラットフォーム。KOLC+（運営: KOLG Inc. / サービスページ: https://kolcx.com/）は、GIS基盤（第4章）が提供する3DTILES・点群・2D地図等を取り込み、工事進捗・出来形・4D工程をデジタル空間上で再現・管理する。GIS基盤が「データを供給する基盤」であるのに対し、KOLC+は「建設プロジェクトの状態をデジタルで再現・監理するプラットフォーム」である。

注: 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万円/月など。詳細は見積・問合せが必要）。

評価と留意点

• 得意な用途: 工事現場〜路線スケールのBIM/CIM詳細管理・出来形・4D工程・現場センサーとのリアルタイム同期。設計→施工→維持管理を一気通貫でカバーする建設特化のDT。
• 広域表示の限界: 都市・地域スケールの広域高速表示・PLATEAU連携・住民説明向け公開可視化は Re:Earth（5.5）が適している。KOLC+ は工事現場〜路線スケールに特化しており、広域地図的な用途は本来の守備範囲外。
• ISMAP 登録・国内 DC・官公庁プランがある点は公共事業での採用を容易にする。
• SaaS 導入は長期契約・データポータビリティ・コストが課題になり得るため、「元データの管理場所」「派生公開データの生成ルール」「API 連携・エクスポート可否」を事前に確認すること。
• 実務導入は PoC（大規模 IFC/点群での表示性能、API による CDE 連携、権限／保管場所の確認、コスト試算）を必須とする。
• ネイティブ方式によるネイティブ編集（DWG/IFC原本操作）とタイル配信（3Dタイル配信・ブラウザ表示）を橋渡しするハイブリッドな位置づけ。GIS基盤のOGC配信と組み合わせて、設計から施工・維持管理までの一気通貫デジタルツインを構成できる。

6.5 Re:Earth（スマートシティ・都市デジタルツインプラットフォーム）

Re:Earth（運営: Eukarya Inc. / サービス: https://reearth.io）は、CesiumJSを基盤としたノーコード型スマートシティ・都市デジタルツインプラットフォーム。国土交通省のPLATEAUプロジェクトにおけるWeb可視化環境としても採用実績があり、都市・インフラのデジタルツイン可視化（住民説明・広報・スマートシティ）に広く用いられる。

主な特徴

• ノーコード操作: プラグイン・ウィジェット方式でコーディング不要のDT可視化環境を構築できる。GeoJSON・3DTILES・CZML・WMS/WMTS等を直接読み込んでWebブラウザで公開・共有。
• PLATEAU連携: 国土交通省Project PLATEAUの都市モデル（CityGML/3DTILES）をそのまま読み込み、住民説明・都市計画・インフラ管理の可視化に活用。
• オープンソース + SaaS: コアエンジンはOSS（Apache 2.0）。クラウド版（SaaS）と自ホスト版の選択が可能。
• 公共・住民向け公開（層3）に強み: 公開共有で住民・広報向けのデジタルツインビューアとして展開できる。
• GIS基盤との連携: 第4章のGIS基盤（GeoServer・PostGIS・OGC API）が配信するタイル・フィーチャーを直接接続して活用できる。

主な対応データ形式

GeoJSON、3DTILES（PLATEAU都市モデル対応）、CZML、KML/KMZ、WMS/WMTS（OGC準拠）、MVT

評価と留意点

• 得意な用途: 都市・地域スケールの広域高速表示。CesiumJS + CDNタイル配信による大量オブジェクトの高速レンダリングが強み。PLATEAU都市モデル・住民説明・広報公開・スマートシティ可視化に最適。
• BIM/CIM詳細管理の限界: 工事現場スケールのBIM/CIM詳細管理・出来形・4D工程・リアルタイム同期は KOLC+（5.4）が適している。Re:Earth は「広く見せる」可視化層であり、「深く管理する」施工管理DTとは用途が異なる。
• 強み: PLATEAU対応・ノーコード・住民説明会・広報公開に最適。行政・公共事業での実績多数。
• 確認事項: 国内DCホスティング・ISMAPへの登録状況は要確認。公共案件の本番採用前に発注者と合意が必要。
• 留意点: 可視化・共有・住民説明に特化した活用が適している。設計変更・精度管理・承認ワークフローには向かない。

6.6 torinome（XRデジタルツインPF・HoloLab）

ホロラボ（HoloLab Inc.）が開発・運営する XR デジタルツインプラットフォーム（サービスページ: https://hololab.co.jp/services/packages/torinome/）。torinome Base は CesiumJS を基盤とした 3D 地球儀ベースの Web GIS であり、Re:Earth と同等の広域・都市スケール 3D 表示能力を持つ。これに加えて AR/VR/WebAR の XR 層を一気通貫で提供できる点が最大の特徴。PLATEAU / Google Photorealistic 3D Tiles・CZML（CesiumJS 専用フォーマット）への対応も CesiumJS 基盤の証左である。タイル配信方式の層2〜3・AR/VR/WebAR を単一プラットフォームでカバーできる。

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

表6-4　torinome アプリケーション構成（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.）。詳細は要確認（公共案件では事前に契約書面で確認すること）。

プランと料金感

表6-5　torinome プランと料金感

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

評価と留意点

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

7. 事業監理層（AI支援）

7.1 設計原理と処理パイプライン

目的:

• 事業監理における意思決定支援を中心に据え、データの一次性（SSOT）を根拠として説明可能な推論・要約・予測を提供する。

設計原理（原理的要件）:

• 単一責任の分離: データ保管（BOX, SSOT）・知識化（埋め込み/ベクトルDB）・生成（LLM）・公開（公開層）の役割を明確に分離する。
• 出典性（Provenance）: すべての推論は参照元（box_file_id, version, segment）に遡れること。
• 説明可能性（Explainability）: LLM応答は要約に加え、参照箇所と信頼度スコアを提示する。
• モジュール性と再現性: ETL→埋め込み→検索→生成の各段階は独立してテスト・再現可能であること。

データモデルと知識表現:

• ドキュメントセグメント: 法令・要領は逐条・逐項で分割し、各セグメントを最小単位の埋め込み対象とする。
• メタデータ正規化: document_type, jurisdiction, effective_date, version, segment_id, legal_citation 等をキーにしてフィルタと出典マッピングを行う。
• オントロジー: 道路・河川ドメインの基本語彙（用語辞書）と簡易オントロジーを定義し、同義語・単位変換・階層関係を埋め込み前に正規化する。

処理パイプライン（理論的構成）:

1. インジェスト層: BOX(SSOT)から文書を取得し、段落・条項単位にセグメント化。
2. 正規化層: OCR補正・単位標準化・用語正規化・座標系/時間形式統一を適用。
3. 構造化化層: 表・仕様・箇所参照を抽出し、メタ情報として付与。
4. 知識化層: セグメント単位で埋め込みを作成し、ベクトルDBへ格納（メタを強く付与）。
5. 推論層: レトリーバ（RAG）で関連セグメントを取得し、引用付きコンテキストをLLMへ与えて応答生成。
6. 検証層: 応答の出典一貫性・信頼度を評価し、必要なら再検索やヒューマンレビューへエスカレーション。

RAG設計上の注意点（理論）:

• ソース分離: 法令・要領等の一次資料は専用のRAGインデックス（高信頼インデックス）に分離し、回答時に高優先で選択する。
• 出典重み付け: 埋め込み段階でソース信頼度スコアをバイアスとして保持し、検索時に重みとして反映する。
• 応答の保守性: 法令改定時は該当セグメントのみ再処理し、古い応答が残らないようにversion管理を徹底する。

評価指標（KPI）:

• 出典提示率（%）: 応答で出典を提示した割合（目標100%）
• 出典一貫性率: 応答と参照文書の一致率（目標95%）
• 意思決定適合率: AI推奨が人間の判断と合致した割合（サンプルレビュー）
• レイテンシ: 応答生成までの時間（オンライン要件）

セキュリティ・プライバシー原則:

• 最小権限: BOXアクセスは短期トークン＋サービスアカウントで実行
• 機密分離: 個人情報／機密は埋め込み対象外、または匿名化ルールを適用
• 監査可能性: イベント→処理→応答のトレースログを保持

展開パターン:

• バッチ主導: 大量更新や定期再埋め込みを夜間バッチで行い、安定性を担保
• イベント駆動: BOXMCP 等のイベントでリアルタイム近くに差分更新を行う（公開層とは明確に分離）

運用的結論:

• 事業管理（監理）用途では「一次資料に基づく出典トレース」と「ヒューマンレビューの組み込み」が最重要であり、システム設計はこれを最優先に据える。
• BOXMCP / BOX を中心としたイベント駆動と、高信頼のRAGインデックス（法令専用）の分離が実務的に有効である。
• 次ステップ: 本理論を元に PoC 設計（データセット、評価指標、レビュー体制）を作成する。

7.2 RAG向け SSOT（法律・要領・マニュアル等）の設置案

AI（RAG）で信頼できる応答を得るためには、一次情報を整備した専用のSSOTコレクションを用意することが効果的です。ここでは道路・河川に関する法令、要項、要領、運用マニュアル、保守手順書、設計基準等をBOX上に体系的に収集・管理するための設計案を示します。

• 目的: RAG の根拠ソースとして利用できる一次資料群を SSOT として BOX に格納し、出典トレースとレビュー体制を通じて応答の信頼性を担保する。
• 範囲例（道路・河川）:
  • 法令（道路法、河川法、関連政令・省令）
  • 国土交通省要項・告示（道路橋示方書、河川管理要領 等）
  • 地方自治体の運用マニュアル・設計要領
  • 維持管理マニュアル、検査手順、点検チェックリスト
  • 仕様書、設計要件、承認決裁文書（公開可の範囲）
• 推奨メタデータ設計（BOX上のファイルメタ）:
  • document_type（法令/要項/手順書）
  • jurisdiction（国/都道府県/市町村）
  • effective_date / revision_date
  • version（SSOT版）
  • legal_citation（条文参照）
  • review_owner（管理部門/担当者）
  • sensitivity（公開/内部/機密）
• 運用フロー（簡易）:
  1. 法令・要領等を収集し、担当部署が BOX の SSOT/RAG フォルダへ配置してメタデータを付与。
  2. 法令の改正や要領改訂が発生したら、担当レビュー担当が revision_date を更新し、新版を version として登録。旧版はアーカイブとして残す。
  3. ETL は SSOT/RAG フォルダだけを定期巡回して埋め込みを更新。変更検出は version または revision_date をキーに差分処理。
  4. RAG 応答では必ず legal_citation と box_file_id を表示し、利用者が元文書へ遡れるようにする。

• ガバナンス: 法令類は法務・技術レビュー担当の二重チェック体制を設け、改定時の承認プロセス（レビュー→承認→公開）を定義する。公開・非公開の切替は BOX の共有設定で管理。

• 品質管理指標:
  • 出典一貫性率（LLM応答が参照した一次文書と一致する割合）
  • レビュー未解決指摘数（ヒューマンレビューで検出された誤り数）
  • 応答の出典提示率（応答で出典を提示した割合、目標100%）
• 実践上の留意点:
  • 法令は逐条で構造化しておくと検索性が向上する（条番号・項目をメタ化）。
  • 地方要領やマニュアルは地域差があるため jurisdiction によるフィルタリングを実装する。
  • 機密あるいは個人情報を含む文書は SSOT に含めず、別の保護レイヤで扱うか、埋め込み前にマスキングする。
    • 法令は逐条で構造化しておくと検索性が向上する（条番号・項目をメタ化）。
    • 地方要領やマニュアルは地域差があるため jurisdiction によるフィルタリングを実装する。
    • 機密あるいは個人情報を含む文書は SSOT に含めず、別の保護レイヤで扱うか、埋め込み前にマスキングする。

優先度付き収集リスト（道路・河川分野の例）

以下は優先順位（高→中→低）を付けて整備する推奨リストです。まずは「高」からBOXに集め、PoCで品質検証を行ってから中→低へ広げてください。

• 高（最優先）:
  • 現行の法令本文（道路法、河川法および関連政令・省令）
  • 国土交通省の告示・要領（道路橋示方書、河川管理要領等）の最新版
  • 維持管理マニュアルと検査手順（点検チェックリストを含む）
  • 施行令・施行規則、技術基準の抜粋（解釈上重要な条項）
• 中（次に整備）:
  • 地方自治体の設計要領・運用マニュアル（主要自治体サンプル）
  • 事業固有の仕様書・設計要件・承認決裁文書（公開可能範囲）
  • 過去の判例・解釈資料、技術懇談会の資料（参照頻度が高いもの）
• 低（補助資料）:
  • 研究報告書・技術論文、参考資料（学術的背景の補助情報）
  • ベンダー提供の製品マニュアル（必要部分のみ抜粋）
  • 過去の稼働記録・運用日誌（匿名化して参照する場合）

7.2.1 ガイドライン／基準書の具体例（詳細）

RAG 用 SSOT に優先的に含めるべきガイドラインや基準書の具体例とその役割を示します。

• 法令・施行令・政令: 法的根拠としての条文（道路法、河川法、施行令等） — 合法性・許認可判断の根拠。
• 国（中央省庁）発行の要領・告示: 国土交通省の要領、道路橋示方書、河川管理要領等 — 設計・維持管理の標準手順と技術基準。
• 地方自治体の運用要領・設計指針: 地域固有要件や運用手順（都道府県、市区町村単位の実務ガイド）。
• 維持管理・検査マニュアル: 点検頻度・手順・閾値・計測方法など、現場運用時の判断基準。
• 技術標準・仕様書: 橋梁・舗装・河川構造物に関する材料・施工・試験基準。
• 事業計画・承認文書: 設計条件・合意事項・承認履歴（公開可能範囲） — 意思決定トレーサビリティ。
• 保守記録・検査レポート（匿名化可）: 過去の点検結果や補修履歴、故障事例の学習素材。
• 関連ガイドライン: 危機管理、災害対応、交通管理、環境配慮に関する運用ガイド。

7.2.2 整備指針（収集・正規化・メタ付与の具体手順）

RAG 信頼性を高めるための実務的な整備手順とルールの例です。

1. 収集ルール設計
   • 収集対象を『法令／要領／マニュアル／データ（検査）』等のカテゴリで定義。優先度タグ（high/medium/low）を必須にする。
   • 収集元を明記（官報／省庁サイト／自治体公式／ベンダー）し、ソースの信頼度を評価する。
2. 文書化とメタデータ付与
   • 上で示したメタ（document_type, jurisdiction, effective_date, version, legal_citation, review_owner, sensitivity）を必須化。
   • 逐条・逐項の分割（条番号、節番号）をファイル内のセグメントとして保持し、埋め込みはセグメント単位で行う。
3. 正規化ルール
   • 単位統一（m, km, kgf→N 等）、座標系標準化（EPSG コードの明記）、日付フォーマット統一を実施。
   • OCR 出力は必ず正規化パイプラインを通し、誤字訂正辞書（用語集）で補正する。
4. 出典マッピング
   • 各埋め込みベクトルには source_type, box_file_id, version, segment_id, jurisdiction を含める。
   • LLM 応答テンプレートは「引用表示（条文/要領名/版）」→「要約」→「参考箇所へのリンク」の順で出力する。
5. 品質管理とレビュー
   • 法務／技術レビュー担当を明確化し、改定時はレビュー→承認→更新のフローを実行。
   • 定期的なヒューマンレビュー（サンプル検証）と自動指標（出典一貫性率）を組み合わせて品質を監視。
6. 運用制約とリスク管理
   • 地方差・言語差の管理（自治体ごとの要領は jurisdiction で分離）
   • 機密データ、個人情報は埋め込み対象外または匿名化・マスキングを義務化。
7. 用語辞書と専門語彙管理
   • ドメイン辞書（法令用語、技術用語、略語）を作成し、OCR 正規化・検索シソーラス・LLM プロンプトの補助に利用する。

7.3 実装例（BOXMCP 等）

以下は BOXMCP（Box のイベント／コネクタ機能）を用いた実装例です。理論節で示した設計原理に基づき、実運用でのイベント駆動・差分処理・出典トレースをどのように実装するかを示します。

• 主なイベント: FILE.UPLOADED, FILE.VERSIONED, FILE.PREVIEWED, SHARE.CREATED, COLLAB.USER_ADDED。
• フロー概要:
  1. BOXMCP がイベントを受け取り、イベントペイロード（file_id, version, actor, timestamp）を受信。
  2. イベントをキュー（例: Pub/Sub, Service Bus）へ投入し、処理用ワーカーへ流す。
  3. ワーカーは最小権限のサービスアカウントで BOX API からファイルを取得し、認可チェックを実施。
  4. ETL（PDF/OCR、IFC→属性抽出、CSVパース等）を行い、差分が検出された場合のみ埋め込みを更新してベクトルDBへ反映。
  5. 埋め込みや検索結果には必ず box_file_id と version、該当スニペット位置をメタとして添付し、LLM 応答に出典を表示。
  6. 全イベント処理の監査ログ（event_id、処理ステータス、エラー、参照box_file_id）を保存。
• 実装上の留意点:
  • 冪等性: 同一イベントの重複処理を避けるため event_id を保存し、重複は無視する。
  • 差分処理: 大容量ファイル（点群・BIM）では差分抽出と差分のみの再埋め込みを採用してコスト削減。
  • セキュリティ: BOX トークンは短期発行・最小権限で運用し、アクセスはすべて監査ログに記録。
  • フォールバック: Box 側障害時はイベントを S3 互換ストアに二重送信するなどの代替経路を用意。
• PoC チェックリスト（短期）:
  1. 代表ファイルを BOX にアップロードして FILE.UPLOADED が発生することを確認
  2. BOXMCP イベントがキューへ入ることを確認
  3. ワーカーが BOX から最小権限で取得し、テキスト抽出→埋め込みを実行することを確認
  4. RAG 応答に box_file_id と version が含まれることを確認
  5. ファイルのバージョン更新で差分のみが再処理されることを確認
• BOXの国内DC要件（公共案件向け）を満たしているか確認。必要に応じてオンプレ/国内クラウドの代替を検討。

• 機密データは埋め込み・LLM送信前にマスキングまたはオンプレ処理で匿名化する。

• 実装パターン（短期〜中期）:
  1. PoC（短期）: 代表的なプロジェクトデータ（図面PDF・台帳CSV・簡易BIMエクスポート）をBOXに集約し、簡易ETL→埋め込み→RAG照会で要約精度を検証。出典トレースと運用UXを重点評価。
  2. スケール化（中期）: ベクトルDBのシャーディング、インクリメンタル更新、差分検出、運用ダッシュボード（応答品質・使用状況）を導入。
• 例: BOXを起点としたワークフロー
  1. 設計担当が設計図をBOXにアップロード（メタデータで project-id と status: WIP を付与）
  2. ETL が定期的にBOXを巡回して新規ファイルを検出、テキスト抽出と埋め込みを実行
  3. 管理者が「公開」フラグをBOX上で切り替えると、公開用差分が生成されて公開層へ流れる（公開は別プロセス）
  4. ユーザーがAIチャットで問い合わせ→RAGがBOX由来の根拠を提示して回答（出典付き）

8. 事業監理層（概算事業費）（AI支援）

8.1 RAGベースの早期概算（目的・ワークフロー・PoC）

目的:

• 過去の積算実績を埋め込み化してRAG（Retrieval-Augmented Generation）で参照し、事業監理が早期に意思決定できる「初期概算」と検討材料を短時間で作成する。出典トレースと前提メタを必須化し、結果はヒューマンレビューで確定する。

必須インプット:

• SSOT の過去積算データ（CSV/表形式）、設計図・台帳のテキスト化データ、地域単価表、事業前提（範囲・仕様・精度目標）

代表ワークフロー:

1. 事業監理が前提（対象範囲・単価版・精度目標）を定義する。
2. データ準備: SSOT から過去積算・台帳・単価表を抽出し、セグメント化・正規化（単位・用語・日付）を実施する。
3. 埋め込み生成: セグメント単位で埋め込みを作成し、ベクトルDBに格納する。
4. 初期概算生成: レトリーバで関連セグメントを取得し、LLMに出典付きコンテキストを与えて初期概算と乖離要因候補を生成する。
5. フラグ付け: LLM応答で「図面要確認」や「データ欠落」の箇所にフラグを立てる。
6. レビュー・迭代: 事業監理がレビューし、必要箇所を精査（GAIA等で数量抽出）または係数で補正する。

RAG と Gaia 等の使い分け（要旨）:

• RAG: 早期概算、出典トレース、乖離要因の洗い出し（高速・低コスト）
• Gaia 等: 点群/3D・複雑形状・PDF/OCR由来の精緻数量抽出（高精度・再現性）

成果物（出力）:

• 概算サマリ（総額・工種別内訳・想定誤差）
• 機械可読内訳（CSV/Excel）と前提メタ（YAML/JSON）
• 出典トレース（box_file_id, version, segment_id）とRAGスニペット

8.2 Gaia Cloud等の選定根拠と利用ルール（概要）

前提: 本節は Gaia Cloud 等がネットワーク／サイトライセンス（同時起動/concurrent）を提供し、組織横断での導入が可能であることを想定して記述している。実際の契約形態・価格はベンダー見積りで確認すること。

選定根拠（要点）:

• 全自動積算と設計書解析（PDF/OCR）の実装により、手入力削減と高速な初期数量算出が期待できる点。
• 国土交通省等の中央省庁および全国自治体の積算基準に対応するデータベースを持ち、地域差に対する運用負荷を低減できる点。
• クラウド基盤（AWS等）採用による自動バックアップ・常時最新版提供と、リモートでのチーム共有・運用が可能な点。
• 充実したメーカーサポート（全国拠点・リモート支援）があり、導入時の定着支援と運用相談が得られる点。

期待できる効果:

• RAGベースの初期概算からの精査対象を迅速に確定でき、工数削減と意思決定の短縮化に寄与する。
• 複雑形状・点群ベースの数量算出が必要なケースで、人的作業を機械化して精度と再現性を高める。

想定適用範囲（運用上の区分）:

• 日常的な概算支援: RAGで算出した初期概算のレビューと簡易突合（主に事業監理担当）。
• 精緻な数量抽出: RAGでフラグ付けされた箇所、点群/3Dモデルが関係する土量・体積・延長の算出に Gaia Cloud等 を投入。

導入チェックリスト（選定・PoCで確認すべき項目）:

1. 精度検証: 過去案件での出力（数量・金額）と実績値の乖離分布を確認する（目標例: RAG＋Gaiaで概算誤差を主要指標以下に収束）。
2. データ連携: SSOT（Box等）からのデータ取り込み／出力（CSV/Excel/JSON）・API連携が可能かを確認する。
3. 運用コストとSLA: 利用料金、処理コスト、サポート体制（オンサイト/リモート）を評価する。
4. セキュリティ／準拠性: データ所在（国内DC可否）・ISMAP/組織ポリシー適合の有無を確認する。
5. ワークフロー適合性: RAGワークフローとの突合（出典トレース保持・補正履歴の記録）が運用で可能かを確認する。

簡潔な運用ルール（サンプル）:

1. 投入閾値: RAG初期概算と既存実績の相対乖離 > 20%、または図面解釈に高い不確実性が検出された場合に限定して Gaia Cloud等 を適用する。
2. データ準備: Gaia Cloud等に渡すデータは「数量抽出に必要な座標系・スケール・属性（メタ）」を満たしていること（前処理チェックリストで合格後に実行）。
3. 出力管理: Gaia Cloud等の出力は原資料（box_file_id 等）およびRAG由来の文脈と突合し、最終値は事業監理が承認する。出力差分・補正履歴を必ず保存する。
4. 最小実行単位: 実行はプロジェクト単位／区間単位で行い、コストとメリットを比較して投入を決定する。

リスクと留意点:

• Gaia Cloud等はクラウドサービスのためネットワーク要件（推奨帯域）や運用コストが発生する。処理の自動化には入力データの前処理が重要。
• 公共案件ではデータ所在・契約条項（国内DC/データ保護）とベンダー契約の確認が必須。
• ベンダーのマニュアルに従う運用を原則とし、本書で技術的内部仕様の詳細は記載しない。

推奨PoC設計（短期）:

• 1) 過去案件2件を選定し、RAGのみ → RAG＋Gaia Cloud等の順で概算を算出、金額・数量の乖離と作業工数を比較する。
• 2) データ連携（SSOT→Gaia Cloud等→出力）を通じてエクスポート形式・APIの確認を行う。
• 3) サポート評価：ベンダーと共同で導入手順・トレーニングを実行し、定着までのサポート品質を検証する。

※ 本節の Gaia Cloud等に関する記述は製品ページおよび公開情報の要点を整理したもので、詳細はベンダー資料・マニュアルで確認してください。

9. 公開・ガバナンス層（SSOT共有・公開）

この層は、SSOTから公開物を派生・生成して配信する「公開プロセス」と、公開を制御する「ガバナンス（承認・監査・ポリシー）」を合わせて扱います。承認フロー（ワークフロー）は公開プロセスの一部として位置づけられ、WIP→Shared→Published といった状態遷移のトリガー、公開メタデータの付与、公開物の差分管理、通知・ログ保管、公開権限の検査を担います。つまりワークフローは独立した手続きではなく、公開・ガバナンス層の運用機能として実装されるべきものです。

9.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

表8-1　CDEの決済フロー 遷移アクションと実行者

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

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

表8-2　承認フロー推奨パターン一覧

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

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

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

表8-3　承認パターン比較（得点順）

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

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

表8-4　Webhook起点での実装方式の比較

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

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

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

表8-5　承認対象ごとの推奨実装

10. 付録

10.1 可視化アプリ対応表

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

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

表9-1　主要可視化アプリ対応表

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

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

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

表9-2　認証・API・国内DC 暫定まとめ

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

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

表9-3　NETISと類似サービス一覧

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