前置き
データメッシュについての続きです。
分散した各データプロダクトが、内部にデータ品質をチェックする適応度関数を保有している ことこそが、データメッシュアーキテクチャの最も革新的で、最も重要な心臓部です。
これは、データ品質保証の責任を、
中央のデータチームから、データを最もよく知るドメインチーム（データプロダクトの提供者）へと移譲
する「Data as a Product（プロダクトとしてのデータ）」原則の根幹をなします。
🛒 アナロジー：スーパーマーケットの食品
従来のデータ基盤は、中央の大きなタンク（モノリシックなDWH）にすべてのジュースを混ぜて、後から中央の品質管理部門が「これは飲めるか？」と検査するようなものでした。
データメッシュは、スーパーマーケットの棚に並ぶパッケージ商品に似ています。
データ
商品そのもの（例：オレンジジュース）
適応度関数/品質
商品パッケージに記載された「栄養成分表示」「賞味期限」「原材料」。
その他の機能
「バーコード（発見・アクセス）」「密封されたパッケージ（セキュリティ）」
消費者は、中央の検査官を信用するのではなく、各商品（データプロダクト）が自ら保証する品質表示を見て購入を決定します。
データ品質を保証する「適応度関数」
データプロダクトは品質（Trustworthiness）を自己保証します。
これは、データパイプラインの内部に、以下のような「適応度関数」が組み込まれていることを意味します。具体的には以下の項目。
完全性
NULLやNOT NULLの制約チェック。
鮮度
データが最後に更新されたのはいつか（SLAの監視）。
正確性
値が期待される範囲内か（例：年齢が0〜120の間）。
一意性
主キーが重複していないか。
妥当性
スキーマ定義（例：YYYY-MM-DD形式）に準拠しているか。
これらのチェックが失敗した場合、データプロダクトは下流へのデータ提供を停止したり、品質スコアを公開したりする責任を持ちます。
データプロダクトが他に保有する機能
データが「プロダクト」であるためには、品質以外にも、自律したコンポーネントとして
以下の機能（インターフェイス）を保有している必要があります。
🌐 ディスカバラビリティ - 発見可能性
機能
自分が何者であるかを説明するメタデータ。
具体例
中央のデータカタログに自動で登録される情報です。
・データプロダクトの オーナー（ドメインチーム） は誰か。
・データの**意味（セマンティクス）**は何か。
・データのスキーマ定義。
・上記でチェックされたデータ品質（鮮度、正確性 など）の現在のスコア。
🔑 アドレサビリティと相互運用性 - アクセス性
機能
データにアクセスするための、標準化されたAPIやエンドポイント（Output Port）。
具体例
・https://api.datamesh.example/products/customer-profile のようなREST API。
・BigQueryやSnowflakeの特定のテーブル/ビューへの参照。
・Kafkaの特定のトピック。
・これらは標準化された形式（例：JSON, Avro, Parquet）でデータを提供します。
🔒 セキュリティとガバナンス - 安全性
機能
データへのアクセス制御（ACL）と監査ログ。
具体例
・データプロダクト自体が「どのユーザー/ロールが、どの列にアクセスできるか」というポリシーを管理します（あるいは中央のポリシーと連携します）。
・「誰がいつ、どのデータにアクセスしたか」というログを自動で出力します。
⚙️ 自律性 - 自己完結性
機能
データプロダクトを生成・提供するために必要な、独自のインフラ（コンテナ、Pod、ストレージ）。
具体例
・データをETL/ELTするための独自のデータパイプライン（例：dbt, Airflow）。
・データを格納するための独自のストレージ（例：S3バケット, BigQueryテーブル）。
・これらはすべて、ドメインチームが管理するData Product Quantum（データプロダクト量子）と呼ばれる独立したデプロイ単位としてパッケージ化されます。