辞書、系統、分類
ほかに 28 言語で読めます
English · Español · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
モジュール3／6：Data Architectコース第5章「データの品質とガバナンス」。各モジュールは単独でも読めます。 前へ：悪いデータを入れない · 次へ：プライバシー法が設計を形づくる
このモジュールが答える問い： データが何を意味し、どこから来て、どれくらい機密なのかを、どう記録するのか？
ある組織を引き継いだとします。取引先には900個の項目があり、その中にCustomer_Type__c、Customer_Class__c、Customer_Category__c、Customer_Status__c、ERP_Status__c、Account_Status__cがあります。誰かが実際に顧客なのかを教えてくれるのはどれでしょう？ 説明を開いてみます。3つは空欄。一つには「Customer Type」と書いてある。ありがとう。一つはERPから来たと書いてあり、もう一つはとうにいなくなった誰かが6年前に作ったものです。今度は、あなたがアーキテクトではなく、連携やレポートのチーム、あるいはエージェントだと想像してください。組織にはデータがたくさんあります。だからといって、そのデータが何を意味するかを知っているわけではありません。
そこでメタデータがアーキテクチャになります。関連しているけれど同じではない、3つの問いを通じてです。
- 辞書： このデータは何を意味するのか？
- 系統： どこから来たのか？
- 分類： どう扱われなければならないのか？
2種類のメタデータ
Section titled “2種類のメタデータ ”メタデータには2種類あり、その両方が必要です。ビジネスメタデータは、そのデータがビジネスにとって何を意味するかです。定義、オーナー、使い方のルール、どれくらい機密か。技術メタデータは、それがどう作られ、どう動くかです。オブジェクトと項目、型と長さ、API参照名、スキーマ、あるシステムから別のシステムへのマッピング、ソースからターゲットまでの系統（リネージ）。項目のAPI参照名と型は、開発者にそれをどう使うかを教え、定義とオーナーは、ほかのすべての人にそれを使うべきかどうかを教えます。この2つが食い違うとき、あるいは片方が欠けているとき、そこで連携やレポートがおかしくなるのです。
試験に出やすい知識。 ビジネスメタデータ（意味、定義、オーナー、ルール、機密度：ビジネス辞書と分類）と技術メタデータ（オブジェクト、項目、型、API参照名、スキーマ、マッピング、系統）を区別できるようにしておきましょう。
意味から始める
Section titled “意味から始める ”第3章でルールを決めました。すべての項目に説明を付ける。Customer Statusという項目に「Customer Status」ではなく、たとえば*「パートナーとSteve Truckingの現在の商取引上の関係。有効化の後にERPから設定される。見込み客の評価には使わないこと。」*のように。これで、それが何を意味し、どこから来て、何に使ってはいけないかがわかります。それがビジネス辞書の始まりです。重要なデータについての共通の定義です。顧客とは何か？ 有効な顧客とは？ 配送済みとは何を意味するか？ 何をもって時間通りとするか？ 当たり前に聞こえますが、5つの部門を一つの部屋に集めるまでのことです。財務には一つの定義があり、営業には別の定義があり、オペレーションには3つ目、ウェアハウスには4つ目があり、誰かが5つ目の上にダッシュボードを作っています。問題は誰も言葉が通じないことではありません。企業が意味について合意していないことです。
辞書はスプレッドシートやドキュメントツールに置いてもかまいませんが、その重要な定義は、人がデータを使う場所の近くになければなりません。プラットフォームでは、項目の説明、ヘルプテキスト、分類のメタデータです。分析ではさらに重要になります。「売上」が経営層のダッシュボードとアナリストのクエリで違うものを意味してはいけません。それがセマンティックレイヤーの目的であり、Data 360のセマンティックモデルは、指標、ディメンション、リレーションといった統制された定義を物理データの上に保持します（Create a Semantic Model in Data 360 (opens in a new tab)、英語）。テクノロジーは変わりますが、要件は変わりません。重要なデータには合意された意味が必要です。
そして、テクノロジーではなく意味から始めましょう。オブジェクト、項目、データ型、API参照名から始まる辞書は、実装を記録しています。ビジネスの用語から始まる辞書は、企業を記録しています。
| ビジネス用語 | 意味 | 表現されている場所 |
|---|---|---|
| 小売パートナー | Steve Truckingが契約のもとで配送を請け負っている小売業者 | Salesforceの取引先、財務ERPの顧客 |
| 配送 | 一人の受取人への、一つの住所への、一日の、一つの配送 | 現在はRouteDesk。配送がSalesforceに移れば作業指示 |
| 受取人 | 配送を受け取る人 | 配送の上の受取人の詳細 |
| 配送済み | 合意された業務上の定義に従って完了したこと | 配送ステータス |
| 時間通りの配送 | 合意された配送の時間帯の中で完了したこと | 導出された指標 |
一つの意味、多くの技術的な表現。
次に、どこから来たのかを問う
Section titled “次に、どこから来たのかを問う ”値が何を意味するかがわかったら、どこから来たのかを知りたくなります。それが系統（リネージ）です。Salesforceにあるパートナーの正式名称。営業担当者が入力したのか、ERPが送ってきたのか、連携が変換したのか、Data 360が統合したのか、計算されたのか、AIが生成したのか？ それによって、どれくらい信頼するか、それで何をしてよいかが変わります。モジュール2の仮のレコードを思い出してください。2つの取引先がどちらも「Keystone」と書いてあっても、一方は昨日営業担当者が作ったもの、もう一方は権威ある識別子とともにERPから来たものかもしれません。同じ文字列、違う系統、違う扱いです。
系統は、データエンジニアが描く1,000個のテーブルの図だけではありません。重要なデータについては、実践的な問いに答えられるようにしたいのです。どこで始まったのか、どのシステムが権威を持つのか、何がそれを変換したのか、どのシステムがコピーを受け取ったのか、最後に何がそれを変えたのか、そして導出された値をその源までたどれるか？ 第4章の全体像は、システムがつながっていることを示します。系統は、その途中でデータに何が起きたかを示します。
一部の系統はただで手に入ります。取引先上のERPのID、作成者と最終更新者、連携のログ、対応表のドキュメント。Data 360は、そのデータオブジェクトに、レコードごとのデータソースとソースオブジェクトを記録する系統の項目を追加します（Data Lineage Fields (opens in a new tab)、英語）。しかし、システムが連携しているからといって系統が現れると思い込まないでください。最も役に立つ系統が、一つの項目であることもあります。ソースシステム = Keystone。 そして、そのソースがガバナンスにとって重要なら、人が入力するのではなく連携が設定するようにして、機械的に信頼できるものにしましょう。
導出されたデータこそ、何よりも系統を必要とします。Steve Truckingが、トラックの位置、配送の時間帯、ルートの履歴から配送遅延のリスクを計算し、配車がそれを優先順位付けに使っているとします。「高」はどこから来たのでしょう？ さらに受取人に「配送が遅れています」と伝えるエージェントが加われば、何がその根拠で、それがどれくらい新しかったのかを知る必要があります。保存された値から、計算された値、統合された値、予測された値、生成された値へと離れるほど、系統は重要になります。
分類は別の問いに答える
Section titled “分類は別の問いに答える ”次の問いです。どう扱われるべきか？ 受取人の名前、配送先の住所、電話番号、配送メモ、配送ステータス、トラック番号、物流センター、小売パートナー、写真。どれも同じくらい機密なわけではありません。「配送中」は電話番号ではありませんし、物流センターのコードは人の家の中を写した写真ではありません。Salesforceでは、標準項目でもカスタム項目でも、各項目にこれを記録できます。データ所有者、項目の使用状況、データ機密度、コンプライアンス分類です（Data Classification Metadata Fields (opens in a new tab)、英語）。第3章ではこれを分類項目と呼び、なぜ重要なのかを説明しました。項目にPIIやGDPRの印を付ければ、マスキングツールから、印の付いた値が大規模言語モデルに届かないようにできるSalesforceのAIトラストレイヤーまで、さまざまなプロセスがそれを見つけられます。第3章からの注意を一つ。Salesforceは現在、エージェントについてはそのLLMマスキングを無効にしています。エージェントが必要とするコンテキストまで取り除いてしまうことがあるからです（大切なものを分類する：分類項目）。ですから、分類はやはりほかの管理策を動かさなければなりません。
ここでの私の立場は意図的なものです。すべての項目ではなく、機密の項目を分類する。 誰かが「100%分類済み」と報告するためだけに、何千もの項目の分類に3か月を費やし、誰もそれを使わない、ということにはしたくありません。受取人の電話番号：はい。自宅の住所：はい。門の暗証番号や「庭に犬がいる」が書かれているかもしれない配送メモ：はい。人や家が写っているかもしれない写真：もちろんです。社内の表示ラベル？ ガバナンスの労力を注ぐべきところではありません。だからといって、説明のない項目が許されるわけではありません。2つの別々の仕事です。説明は広く、分類は意図的に。 それが分類を意味のあるものに保ちます。
人が使える分類体系
Section titled “人が使える分類体系 ”分類には語彙、つまり分類体系（タクソノミー）が必要です。Salesforceのデフォルトは、Public、Internal、Confidential、Restricted、MissionCriticalです。組織によっては独自のラベルを使いたいかもしれません。私はそれを決めつけません。わかりやすくしておきましょう。カテゴリーが47個あって、プライバシーチームの外の誰もカテゴリー31と32を区別できないなら、役に立っていません。よい分類体系は、ラベルを振る舞いに結びつけます。ある項目が機密の個人データなら、誰が見られるのか、サンドボックスに入れてよいのか、地域の外に出てよいのか、分析に現れてよいのか、どれくらいの期間保持するのか、エージェントが使ってよいのか？ こうして分類が仕事をするようになります。
強制のない分類は飾りである
Section titled “強制のない分類は飾りである ”受取人の電話番号を機密とマークして、ほかに何も変えなければ、ドキュメントを書いただけです。役に立ちますが、ガバナンスはその先まで進みます。分類は、権限、マスキング、暗号化、保持、同意、データの移動、サンドボックスでの利用、監査、AIのアクセスを動かすべきです。その一部はアーキテクトの設計上の判断であり、一部のプラットフォームは今やタグと分類を直接ポリシーに適用します。Data 360のガバナンスがそうです（Data Governance in Data 360 (opens in a new tab)、英語）。そして、項目をRestrictedとマークしても、誰かがそれを読むのは止まりません。分類は項目がどう扱われるべきかを示し、セキュリティがそれを実現します。順序はこうです。データを特定し、理解し、重要なものを分類し、そしてその分類が求める管理策を適用する。
データについての3つの問い。そして3つ目は何かを動かさなければならない。
参照データにもメタデータが必要
Section titled “参照データにもメタデータが必要 ”国コード、配送ステータス、物流センターのコード、パートナーの識別子、キャンセルの理由。シンプルに見えます。2つのシステムが食い違うまでは。一つはCANCELLED、別のものはCANCELED、3つ目はCNCL、4つ目は9。参照データには、定義、所有者、源、値が変わる場合のライフサイクル、そしてシステムによって表し方が違う場合の対応表が必要です。小さな値が、とても大きなプロセスを動かすことがあります。第6章でさらに掘り下げます。
3つを合わせる
Section titled “3つを合わせる ”受取人の電話番号を例にとりましょう。辞書：特定の配送を受け取る人に連絡するための番号。系統：小売パートナーの積荷目録から。分類：個人データ。これでアーキテクチャの問いが立てられます。クルーはそれを見てよいのか、どれくらいの期間か（概要資料では、自分の停車地について、その日だけ）。サンドボックスに入れてよいのか。Snowflakeはそれを必要とするのか。エージェントは使ってよいのか。配送が終わったら何が起きるのか？
次は配送ステータスです。辞書：配送の現在の業務上の状態。系統：Steve Truckingの配送プロセスが設定し、それぞれのパートナーへ独自の連携を通じて送り返される。分類：業務データで、機密ではない。違うデータ、違う扱い。それが要点です。
私はメタデータを、本当のアーキテクチャが終わった後に作るドキュメントとして扱いません。項目が何を意味するかを言えないなら、データモデルを理解していません。値がどこから来たかを知らないなら、連携を理解していません。それが機密かどうかを知らないなら、セキュリティを理解していません。メタデータはアーキテクチャを記述し、ときにはそれを動かすのです。
試験の先へ：AIが変えること。 分類は、エージェントが何を取得し、何を繰り返してよいかを決めるスイッチになりつつあり、系統はエージェントの答えや行動にまで届かなければなりません。エージェントが受取人に配送が遅れていると伝えるなら、アーキテクチャは、何がその根拠で、それがどこから来て、エージェントがそれを使ってよかったのかを言えるべきです。「Salesforceのどこか」は系統ではありませんし、「顧客データ」は分類ではありません。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- システムやチームが一つの言葉に違う意味を与えないように、どのビジネス用語に統制された定義が必要か。
- 重要な値が、その源、権威、変換を示すのに十分な系統をどう保つか。
- どの項目が機密やコンプライアンス上の意味を持ち、そのため明示的な分類を受けるか。
- 組織がどの分類体系を使い、人がそれを一貫して当てはめられるか。
- 分類が使われずに眠っているのではなく、本物の管理策をどう動かすか。
データを統制する前に、何を持っているかを知りましょう。それが何を意味し、どこから来て、どう扱われなければならないか。説明は広く、分類は意図的に、系統は重要なところで保つ。そうでなければ、データを統制しているのではありません。ただ持っているだけです。
さらに学ぶ
Section titled “さらに学ぶ ”- Salesforceヘルプ、Data Classification Metadata Fields (opens in a new tab)（英語）、2026-10-14確認。
- Salesforceヘルプ、Data 360：Data Lineage Fields (opens in a new tab)、Data Governance in Data 360 (opens in a new tab)、Create a Semantic Model in Data 360 (opens in a new tab)（英語）、2026-10-14確認。