データCADとフレームワークの対応表
データCADの属性・ビュー・出力は、データマネジメントの知識体系（DAMA-DMBOK2）、エンタープライズアーキテクチャ（TOGAF・ArchiMate）とイベント駆動アーキテクチャ、情報セキュリティ（ISO/IEC 27001・NIST CSF 2.0・SCS評価制度）、プライバシー（個人情報保護法・GDPR・CCPA/CPRA）、AIガバナンス（EU AI法・NIST AI RMF）、事業継続（ISO 22301）と移行計画（TOGAF Phase E/F）、そしてW3Cのメタデータ・オントロジー標準に対応しています。ワークショップで描いた図面が、そのまま各フレームワークの成果物になります。
DAMA-DMBOK2（11の知識領域）
データガバナンスを中心とした11領域。診断ビューでは各領域の成熟度（0〜5）を現状・目標で入力し、レーダーで差を確認できます。
| 知識領域 | データCADでできること |
|---|---|
| データガバナンス | データオーナー（責任部門）・スチュワード・カストディアンの3役割。「責任部門がない」「マスタにスチュワードがいない」を自動検知 |
| データアーキテクチャ | 業務×部門×システムの3軸でデータの所在を構造化。TOGAFのデータ・マトリクスを自動生成 |
| データモデリングとデザイン | 業務用語集（概念レベルの定義・同義語・上位概念）と、データ種別（マスタ／参照／トランザクション／分析／文書／メタデータ） |
| データストレージとオペレーション | システム種類（SaaS・クラウド・オンプレ・端末・AI・紙・人）、保管国、保存期間・廃棄ルール |
| データセキュリティ | 4段階の分類、C/I/A評価、物理分離、生成AIでの利用可否。部門×システムの機微データ集中マップ |
| データ統合と相互運用性 | 所在ごとのCRUD。作成点のないデータ（出所不明）や、複数システムでの作成（二重入力）を検知 |
| ドキュメントとコンテンツ管理 | 紙・人の記憶も「システム」として描ける。属人化・紙だけのデータを検知 |
| 参照データとマスターデータ | マスタ・参照データを識別し、Single Source of Truth が崩れている所を検知 |
| データウェアハウジングとBI | 分析データとデータプロダクト（データメッシュ）を区別して記録 |
| メタデータ管理 | 図面そのものがビジネス・技術メタデータ。DCAT・SKOS準拠で出力し、台帳の記入率を測定 |
| データ品質 | 完全性・正確性・一貫性・適時性・妥当性・一意性の6次元を1〜5で評価。低評価を所見に |
TOGAF（ADM とアーキテクチャ成果物）
業務・データ・アプリケーションの3つのアーキテクチャ領域と、ベースライン→ターゲットの移行計画を1枚の図面で扱います。
| TOGAF | データCADでの表現 |
|---|---|
| Phase B ビジネスアーキテクチャ | 業務プロセス軸（業務機能＝ケイパビリティでグループ化）と部門軸 |
| Phase C データアーキテクチャ | Data Entity / Business Function マトリクス（CRUD）、データ×部門マトリクス |
| Phase C アプリケーションアーキテクチャ | システム軸と Application / Data マトリクス、システム間連携（Application Interaction）マトリクス |
| Phase D テクノロジーアーキテクチャ | 技術基盤（クラウド・SaaS・データセンター・ネットワーク・ブローカー）を3Dの土台として描き、Application / Technology マトリクスを生成 |
| BDAT の4層ビュー（EAビュー） | ビジネス・データ・アプリケーション・テクノロジーを層で並べ、要素を選ぶと層をまたいでつながる要素をたどる（影響範囲の分析） |
| ArchiMate 3.1 | The Open Group の Model Exchange 形式で出力。Archi などで BDAT ビューが開く（業務プロセス・アクター・データオブジェクト・アプリケーション・ノード・イベント） |
| Data Security Diagram | 分類・物理分離・AI利用可否と、部門×システムの機微データ集中マップ |
| ベースライン／ターゲット | 期間（As-Is → 移行期 → To-Be）を時系列ダイヤルで切り替え |
| ギャップ分析 | 比較モードと、追加・廃止されるシステム、移るデータの一覧（Excel・Markdownにも出力） |
| Phase E/F 移行計画 | 移行先のないデータ（移行漏れ）を自動検知。ワークパッケージ・更改・保守期限は「時間軸と依存関係」へ |
ISMS（ISO/IEC 27001）と個人情報保護法
Excel出力の「情報資産台帳」シートは、そのまま情報資産の目録として使えます。診断は次の規定を根拠に所見を出します。
| 根拠 | データCADでの扱い |
|---|---|
| ISO/IEC 27001 A.5.9 情報資産の目録 | 1行1データの情報資産台帳（オーナー・C/I/A・保管場所・保存期間） |
| ISO/IEC 27001 A.5.12 情報の分類 | 公開／社内／機密／極秘。個人情報を「公開」にしていないかを検知 |
| 個人情報保護法 第2条3項（要配慮個人情報） | 法令タグと分類の整合を確認 |
| 個人情報保護法 第18条（利用目的） | 個人情報がAIシステムで扱われている所を検知 |
| 個人情報保護法 第22条（不要時の消去） | 保存期間が決まっていない個人情報を検知 |
| 個人情報保護法 第28条（外国にある第三者への提供） | 国外のシステムにある個人情報を検知 |
| 番号法・電子帳簿保存法・J-SOX・営業秘密・輸出管理 | 法令タグとして記録し、AI利用可否の自動判定に反映 |
イベント駆動アーキテクチャ（EDA）
システム間の連携を「イベント（非同期の発行・購読）」「API」「バッチ」「ファイル」「手作業」で描きます。3Dでは光の粒が流れ、ブローカー経由のイベントは建物の上のイベントバスを通ります。
| 観点 | データCADでの扱い |
|---|---|
| プロデューサー／コンシューマー | 発行元と受け手のシステム（業務も指定可）。受け手に所在が描かれていないデータを検知し、ワンクリックで所在を追加 |
| イベントブローカー | Kafka・EventBridge・Pub/Sub などを技術基盤（ブローカー）として描き、経由する連携をまとめて表示 |
| イベントの種類 | ドメインイベント・統合イベント・通知・変更データ取得（CDC）・コマンド、配信保証（最大1回／少なくとも1回／正確に1回） |
| AsyncAPI 3.0 | イベントの連携をチャネル（トピック）・発行／購読の操作・メッセージとして出力。ペイロードは運ぶデータの中身のモデルから |
| CloudEvents | メッセージに type（トピック）と source（発行元）を付与 |
| データコントラクト | スキーマのないイベントを検知（ODCS・スキーマレジストリでの管理を促す） |
| 越境・AIの判定 | 連携で渡る先も所在とみなして、個人情報の国外移転・AIへの投入を点検 |
時間軸と依存関係（TOGAF Phase E/F・ArchiMate 実装と移行）
期間に年月を付け、システムの更改・保守期限・移行のワークパッケージ・業務の前提を記録すると、時間軸ビューで依存関係と矛盾が見え、診断・出力に反映されます。
| 観点 | データCADでの表現 |
|---|---|
| Plateau（期間） | As-Is → 移行期 → To-Be の各期間に開始・終了の年月。時間軸ビューの目盛り、保守期限・日程の突き合わせに使う（OWL-Time の time:hasBeginning / hasEnd で出力） |
| Work Package（ワークパッケージ） | 導入・更改・廃止・データ移行・統合・業務改革の計画。日程・状況・責任部門・到達する期間・対象（システム・業務・データ・拠点・技術基盤） |
| 先行関係（finish-to-start） | 「先に終わっている必要がある」ワークパッケージ。先行より先に始まる計画を矛盾として指摘。循環は自動で断つ |
| 更改（置き換え元） | 新システムが引き継ぐ旧システム。新旧の空白（サービス断）・長い並行稼働・置き換え先に載っていないデータ・後継のない廃止を点検 |
| 保守期限（EOL） | システム・技術基盤の保守期限。期限を過ぎて使う計画、期限切れのまま稼働中を指摘（NIST CSF ID.AM-08・PR.PS-02、SCS「攻撃等の防御」） |
| 業務の前提（依存関係） | 業務 → 業務の前提。その時点で前提の業務がなくなる矛盾を検知。依存のトレースで上流（依存している先）・下流（影響する先）をたどる |
| 連携の存在期間 | 連携の相手が導入前・廃止後になっている期間を検知（ID.AM-03 データの流れ） |
| 変更の集中 | 期間の切り替わりで、ひとつの業務が使うシステムが3つ以上入れ替わる時期を指摘（ITIL 変更管理・段階的な切り替え） |
| ArchiMate の Implementation & Migration | Plateau・Work Package・Deliverable と Triggering（先行）・Realization（到達）・Aggregation（期間に存在するシステム）で出力 |
拠点・地域と事業継続（W3C ORG Site・ISO 22301）
本社・工場・データセンター・クラウドのリージョン・自宅などを拠点として描き、部門・システム・技術基盤を割り当てると、データの物理的な所在が地図に出て、1拠点への集中や閉鎖の影響を点検できます。
| 観点 | データCADでの表現 |
|---|---|
| 拠点（org:Site） | 種類（本社・事業所・工場・倉庫・店舗・データセンター・クラウドのリージョン・施設・自宅）、国、地域名、座標（市区町村程度の粗さ。W3C Basic Geo の geo:lat / geo:long で出力）、開設・閉鎖の期間 |
| 物理的な所在の決め方 | システムの拠点 → 技術基盤の拠点 → 紙・人・端末・自社サーバは部門の拠点。保管国（越境の判定）も拠点の国から補う |
| 地図ビュー | 拠点ごとのデータ量・分類の内訳・個人情報・極秘・止まると困るデータ、拠点をまたぐ連携、個人情報の越境（赤い破線）。期間を再生して移転を見る |
| ISO 22301 8.4・NIST CSF RC.RP・SCS「復旧」 | 可用性3またはマスタのデータが1拠点にしかない、バックアップ・代替拠点が本体と同じ拠点、を所見に |
| 拠点の閉鎖・開設 | 閉鎖した（開設前の）拠点にシステム・部門・技術基盤が残っている時期を検知 |
| 医療・自治体の要求 | 医療情報システムの安全管理に関するガイドライン（非常時の事業継続）、地方公共団体の ICT-BCP を準拠ビューの適用判定に表示 |
| ArchiMate の Location | 拠点を Location として出力し、部門・システム・技術基盤を Aggregation で結ぶ。バックアップ拠点は Association |
| プライバシーへの配慮 | 番地・建物は持たない（座標は約100mに丸めて保存）。家庭では市区町村より細かい場所を書かない |
予算策定と投資対効果（TCO・NPV・ROI・TBM）
システム・技術基盤の年間の運用費と、ワークパッケージの一時費用・効果を入れると、時間軸（As-Is → To-Be）に沿って年度別の予算と、「何もしない場合」と比べた投資対効果を計算します。
| 考え方 | データCADでは |
|---|---|
| TCO（総保有コスト） | ライセンス・基盤・保守運用・社内工数（人月×単価）を年額で。期間の年月に沿って、システムが動いている月だけ計上（物価上昇率を反映） |
| Run / Change（TBM・IT予算の区分） | 運用（システム・技術基盤）と変革（ワークパッケージ）を分けた予算表。会計年度の開始月を選べ、Excel に貼れる形でコピー |
| 何もしない場合（ベースライン） | As-Is のシステムを使い続けた場合。保守期限（EOL）の後は延長保守の割増を上乗せ。計画との差が運用費の削減 |
| 支出ベースと損益ベース | 資産計上する開発・導入費は、稼働の翌月から償却年数（既定5年：自社利用ソフトウェア）で定額償却した損益ベースでも表示 |
| NPV・IRR・回収期間 | 年度ごとの正味（効果 − 投資）を割引率で現在価値に。累積がプラスに戻る月を回収とし、ワークパッケージ別にも計算 |
| 効果の確度 | 業務効率化（時間×単価）・コスト削減・収益・リスク低減を、確度（高・中・低）とシナリオ（保守的・標準・楽観的）で割り引く |
| リスク低減（ALE） | 診断の所見1件あたりの年間期待損失を決めると、As-Is から所見が減った分をリスク低減の効果として数える |
| シナリオと感度分析 | 計画の遅れ（旧システムが長く動き、効果も遅れる）・投資の上振れ・為替（外貨建ての割合）・物価・割引率を動かし、NPV が動く幅をトルネード図で比較 |
| データの保有コスト（DMBOK のデータの価値） | 運用費を所在に配賦し、データ・ドメインごとに「持つのにいくらかかっているか」を As-Is と To-Be で比較 |
| 出力 | Excel に「予算（年度別）」「投資対効果」シート、Markdown（AI用）に予算と投資対効果の節。API：/api/models/<slug>/finance |
文書からの自動作図（AI）
業務マニュアル・業務フロー・情報資産台帳・システム一覧・CRUD 表・設計書（CREATE TABLE）をまとめて入れると、業務 × 部門 × システム × データの図面を起こします。すべての候補に根拠（ファイル・場所・引用）が付き、採否を選んでから反映します。
| 考え方 | データCADでは |
|---|---|
| 決まった形はルールで | 台帳・一覧は見出しの言い換えを自動で判別（見出し行が1行目でなくても可）。1セルに複数の部門・システムがあれば分ける。CRUD マトリクス・CREATE TABLE・基盤メタデータもルールで読む（確度：高） |
| 自由な文章は AI で | マニュアル・業務フローの本文と形の分からない表は Claude が読み、業務・部門・システム（紙・人の記憶も）・データ・所在（CRUD）・連携・用語・確認したい点を、原文の引用つきで返す。AI を使わない場合は語の形と動詞で拾う（確度：低） |
| 名寄せと照合 | 「〜システム」「〜部」の有無・括弧書きを同じとみなし、AI で略称・別名（SFA と Salesforce など）をまとめる。今の図面に同じ名前があれば照合し、空いている項目だけを埋める |
| 未確認の明示 | 業務・部門・保管場所が文書から分からないデータは「未確認」の項目に置く。3D で穴が見え、診断にも「所在を特定できなかった」と出る |
| 確認したい点（ヒアリング項目） | 文書間の食い違い（責任部門・分類）、手作業の転記、どこにも書かれていない作成元などをまとめ、Markdown で保存できる |
| トレーサビリティ（DMBOK メタデータ） | 反映した項目は根拠と確度を持ち、右パネルで確認済みにできる。Excel に「自動作図の根拠」シート、診断に「根拠が弱い（要確認）」 |
| 個人情報の扱い | 文書は保存しない。AI に送る前にメール・電話番号・12桁の番号・郵便番号を伏せ、名簿・顧客一覧のような表は見出しだけを送る |
攻撃シミュレーション（MITRE ATT&CK・ATLAS）
描いた部門・システム・技術基盤・連携・委託先と、記入した対策から攻撃グラフを組み、7つの典型的な攻撃が侵入口からどこまで広がり、どのデータが持ち出され（暗号化され）、どの業務が止まり、どこで検知できるかを3Dで再生します。
| 考え方 | データCADでは |
|---|---|
| 攻撃グラフ | 部門（人と認証情報）・システム・技術基盤・委託先をノード、ログイン・端末の乗っ取り・連携・基盤の共有を辺にし、辺ごとの通りやすさを対策で下げる（例：多要素認証があれば盗んだパスワードでのログインは 0.15 倍）。複数の経路は「どれか1つでも通る」確率にまとめる |
| 7つのシナリオ | ランサムウェア・標的型メール・取引先経由・内部不正・端末の紛失・クラウドの設定ミス・生成AIへのプロンプトインジェクション。侵入口は指定しなければ被害が最も大きいものを自動で選ぶ |
| MITRE ATT&CK（Enterprise） | 経路の一歩ごとに戦術（初期アクセス・認証情報・横展開・収集・持ち出し・影響）と技術の ID（T1566・T1078・T1021・T1486 など）を表示 |
| MITRE ATLAS（AI） | AIへの攻撃は AML.T0051（プロンプトインジェクション）・AML.T0057（LLM からのデータ漏えい）。AIに渡る連携のデータも漏えいの対象 |
| 検知と封じ込め | EDR（1時間）・ログ監視（6時間）のあるシステムに届いた時点で検知し、その8時間後より先への広がりを抑える。どこにも無ければ「検知できない」 |
| 復旧と業務の停止 | 暗号化されたシステムで作成・更新している業務が止まる。代替（DR）拠点・バックアップ・「バックアップも狙われる」（同じ基盤が乗っ取られる）・バックアップなしで復旧の目安を分ける |
| 物理分離の効果 | 紙・金庫・人の記憶だけにある物理分離のデータには、内部不正以外の攻撃は届かない（3Dで盾を表示） |
| 対策の効果（NIST CSF 2.0） | 多要素認証 PR.AA-03・暗号化 PR.DS-01・バックアップ PR.DS-11・ログ PR.PS-04・EDR DE.CM-09・パッチ PR.PS-02・アクセス権の棚卸し PR.AA-05・DLP を、仮に全システムへ入れた場合の被害の減りで順位づけ |
| 出力 | Excel に「攻撃シミュレーション」（全シナリオの比較と経路）、Markdown（AI用）に想定被害の表。API：/api/models/<slug>/attack（scenario=all で比較） |
NIST CSF 2.0 と SCS評価制度（★3・★4）
システムごとの対策（多要素認証・暗号化・バックアップ・ログ・EDR・パッチ・アクセス権の棚卸し・DLP・委託契約）を記録すると、機微なデータのあるシステムで足りない対策を所見にします。所見は NIST CSF 2.0 の機能と、経済産業省の SCS評価制度の7領域に対応づけます。
| NIST CSF 2.0 ／ SCS評価制度 | データCADでの扱い |
|---|---|
| GV 統治 ／ ガバナンスの整備 | データオーナー・ドメインオーナーの不在を検知。自己評価（ティア1〜4）を現状・目標で入力 |
| GV.SC サプライチェーン ／ 取引先管理 | システムの提供事業者・委託先を記録。個人情報を預けているのに委託契約（DPA）がない所を検知 |
| ID 識別 ／ リスクの特定 | 情報資産台帳・C/I/A・技術基盤の未設定・対策の未記入を検知 |
| PR 防御 ／ 攻撃等の防御 | 多要素認証・暗号化・脆弱性対応の不足、物理分離すべきデータの共有基盤への配置 |
| DE 検知 ／ 攻撃等の検知 | ログ・監視、端末のEDRの不足 |
| RC 復旧 ／ インシデントからの復旧 | 正を持つシステムのバックアップの不足、人の記憶にしかないデータ |
| SCS評価制度の段階 | ★3（自己評価＋確認、有効1年）・★4（第三者評価、有効3年）の目標を設定。2026年8月に基本規程が施行、申請受付は2026年度末頃の予定 |
個人情報保護法・GDPR・CCPA/CPRA・NIST Privacy Framework
データごとに本人のいる国・地域、利用目的、適法根拠、販売・共有、子どもの情報、影響評価の実施を記録し、処理活動の記録（RoPA）を自動で作ります。
| 根拠 | データCADでの扱い |
|---|---|
| 個人情報保護法 第17条・第18条 | 利用目的の未記入、個人情報のAIでの取り扱いを検知 |
| 個人情報保護法 第25条・第28条 | 委託先の監督（委託契約）、外国にある第三者への提供（保管国・連携先で判定） |
| GDPR 第6条・第30条・第35条 | EUの本人のデータの適法根拠、処理活動の記録、DPIA が必要そうな処理（特別な種類・子ども・AI） |
| GDPR 第44〜49条 | 十分性認定のない国（米国は DPF 認証の確認）にあるEUの個人データを検知 |
| CCPA/CPRA・CPPA 規則 | 販売・共有のオプトアウト、センシティブ個人情報の利用制限、リスク評価（2026年1月から） |
| NIST Privacy Framework | 所見を Identify-P／Govern-P／Control-P／Communicate-P／Protect-P に対応づけ |
AIガバナンス（EU AI法・NIST AI RMF・AI推進法）
AIシステムごとに用途・リスク区分・役割・人による監視・告知・影響評価を記録し、AIシステム台帳と主な義務・期日を出します。
| 根拠 | データCADでの扱い |
|---|---|
| EU AI法 リスク区分 | 用途（採用・与信・教育・公共サービスなど附属書IIIの領域）から高リスクを推定。禁止・限定（透明性）・最小も選べる |
| EU AI法 第14条・第26条・第27条 | 高リスクAIの人による監視・導入者の義務・基本権影響評価。附属書IIIは Digital Omnibus により2027年12月から |
| EU AI法 第50条 | 人と対話する・コンテンツを生成するAIの告知と表示（2026年8月から） |
| CCPA ADMT（CPPA 規則） | 重要な決定（雇用・金融・教育・医療）の自動化。事前通知・オプトアウト・リスク評価（2027年1月から） |
| NIST AI RMF 1.0 | GOVERN／MAP／MEASURE／MANAGE の自己評価と、所見の対応づけ |
| AI推進法・AI事業者ガイドライン | AIを活用する事業者としての指針。AI利用禁止のデータがAIに渡る経路（所在・連携）を検知 |
メタデータ・オントロジー標準（W3C ほか）
AI用の出力は独自形式に閉じず、標準語彙に接続しています。社内のデータカタログやナレッジグラフに、そのまま取り込めます。
| 標準 | 使い方 |
|---|---|
| DCAT 3 | データ資産は dcat:Dataset の下位クラス。業務用語は dcat:theme で結ぶ |
| W3C Organization Ontology | 部門は org:OrganizationalUnit、組織は org:Organization の下位クラス |
| SKOS | 業務用語集を skos:ConceptScheme / skos:Concept（定義・同義語・上位概念）で出力 |
| OWL-Time | 期間は time:ProperInterval。各要素に有効期間（validFrom / validTo） |
| DPV（Data Privacy Vocabulary） | 個人情報フラグを dpv:PersonalData に関連付け |
| CSVW | 中身のモデルのエンティティ・項目は csvw:Table / csvw:Column を参照（dcad:Entity / dcad:Attribute） |
| SHACL / SHACL-SPARQL | 物理分離・AI禁止・個人情報の公開禁止・越境移転などのガードレールを機械検証できるシェイプとして出力 |
| JSON-LD・RDF Turtle・OWL | ナレッジグラフ・RAGのメタデータ・トリプルストアに投入 |
| プロパティグラフ（Cypher） | Neo4j などに投入し、GraphRAG の土台に。MERGE なので何度でも流せる |
これからのデータマネジメント
生成AI時代のデータ管理で求められる考え方を、図面の属性として持っています。
| 考え方 | データCADでの表現 |
|---|---|
| AIガバナンス（AI事業者ガイドライン） | データごとの生成AI利用可否（利用可／マスキングして可／禁止）を、分類・法令から自動判定し、AI用出力のガードレールに反映 |
| 人間中心のデータ管理 | 共有基盤・AIから切り離して紙・金庫・人で守るデータを「物理分離」として明示 |
| データメッシュ（ドメインオーナーシップ） | データドメインを3Dのバブルで描き、ドメインオーナー・種別（ソース整列／集約／利用者整列）を記録。責任部門が品質を保証して公開する「データプロダクト」も印を付けられる |
| ドメイン駆動設計（DDD） | 境界づけられたコンテキストとしてのドメイン。コア／支援／汎用のサブドメイン区分と入れ子（バブルの中のバブル） |
| データコントラクト（ODCS v3） | 中身のモデル（スキーマ）・分類・AI利用可否・責任部門から Open Data Contract Standard の YAML を自動生成 |
| アクティブメタデータ | 保存済みの図面はURLで常に最新の診断・出力を取得でき、AIエージェントから直接参照できる |
データモデリングと基盤メタデータ
データ（キューブ）の中に、エンティティ・項目・キー・つながりのモデルを持てます。3Dで拡大すると中が見え、データ辞書（Excel）・Turtle・Cypher・データコントラクトにそのまま出力されます。
| 考え方・基盤 | データCADでできること |
|---|---|
| 概念・論理・物理モデル（DMBOK 5） | モデルごとに抽象度を記録。物理名と論理名（日英）、型、主キー・外部キー・業務キー、必須、個人情報の印 |
| リレーショナル（ER） | 外部キーからつながりを自動で引き、キューブの中で関係のばねモデルとして配置 |
| ディメンショナル（Kimball のスター） | ファクトを中央、ディメンションを周りに置いて表示。会計・販売分析のデータマートに |
| Data Vault 2.0 | ハブ・リンク・サテライトを定石どおりに配置。監査可能な統合層の設計に |
| ドキュメント・イベント | FHIR リソースや JSON、ログ・IoT のイベントモデル（病院テンプレートは FHIR R4 の主要リソース） |
| Microsoft Fabric / Power BI | TMDL（PBIP・Fabric の Git 連携）、model.bim（TMSL）、管理 API（Scanner）からテーブル・列・メジャー・リレーションを取り込み（Pro） |
| AWS・Google Cloud | AWS Glue Data Catalog（get-tables）、Amazon Redshift、BigQuery（テーブル JSON・INFORMATION_SCHEMA）から取り込み（Pro） |
| Snowflake・Databricks・dbt | INFORMATION_SCHEMA.COLUMNS・GET_DDL・Unity Catalog、dbt の manifest.json（説明・テスト・制約）から取り込み（Pro） |
| 個人情報の自動検出 | 列名・コメントから個人情報・要配慮個人情報・マイナンバーらしき項目を見つけ、データの印・AI利用可否・診断に反映 |