metamesh

モデルストーミング（DV / Dimensional）で生まれるビジネスメタデータを W3C 標準 (SKOS / OWL / JSON-LD) で 1 箇所に保存し、 MCP 経由で Claude が直接読み書き することで、 dbt / Semantic Layer / AI/LLM すべてに同じ意味を届けるフレームワーク。

metamesh はドメイン非依存の OSS。実装例は別リポジトリで管理する。 現在の参照実装: vtuber-analytics (VTuber 配信メタデータをこのフレームワークで構造化したもの)。

立ち位置を一文で: 業務担当者と AI が同じ「業務概念の SSoT」を共有するための、 モデルストーミング駆動のワークフロー OSS。隣接する semantic layer / catalog / GraphRAG エコシステムとは 競合ではなく上流補完 の関係。詳細は POSITIONING.md。

解こうとしている問題

データ基盤の下流に行くほど ビジネスメタデータ（人間の頭の中の知識）が削られていく。

モデルストーミング成果物 (情報量 100%)
  → DV/Mart 実装        (情報量 30%: 定義が削れる)
    → Semantic Layer    (情報量 15%: ビジネス定義が消える)
      → Data Catalog    (情報量 10%)
        → AI / LLM      (情報量  5%: 構造は分かるが意味が分からない)

「得意先別売上」と「顧客別売上」が同じクエリにならない、配信者と チャンネルとサブチャンネルの関係が AI に伝わらない、といった現象は、 5 つの断絶点 で同義語・階層・関係性の意味・実装の対応がそれぞれ 失われることが原因。

詳細: docs/PROJECT_CONTEXT.md（フレームワーク 全体）。

metamesh の設計思想

構成要素

┌──────────────────────────────────────────────────┐
│  ユーザー (データエンジニア / 研究者)               │
│       ↕ 自然言語                                   │
│  Claude Desktop / Code                            │
│  ├─ Skills (.claude/skills/)                       │
│  │  ├─ cbc-modeling-interview         (DV)         │
│  │  ├─ nbr-identification             (DV)         │
│  │  ├─ dv-implementation-design       (DV)         │
│  │  ├─ beam-modeling-interview        (Kimball)    │
│  │  ├─ dimension-fact-identification  (Kimball)    │
│  │  ├─ star-schema-design             (Kimball)    │
│  │  ├─ ontology-visualize             (汎用)       │
│  │  └─ ontology-review                (汎用)       │
│       ↕ MCP                                        │
│  metamesh server  (薄い primitive)                 │
│  ├─ Write : add_concept, add_relationship          │
│  └─ Read  : query_concept (SPARQL: SELECT/         │
│              CONSTRUCT/DESCRIBE/ASK)               │
│       ↕ METAMESH_ONTOLOGY_ROOT                     │
│  ontology/ (ユーザー自身が用意するディレクトリ)      │
│    ├── concepts/*.jsonld                          │
│    └── relationships/*.jsonld                     │
└──────────────────────────────────────────────────┘

クイックスタート

1. 依存インストール

git clone https://github.com/Islanders-Treasure0969/metamesh.git
cd metamesh
uv sync --extra dev
uv run pytest          # 動作確認 (69 tests)

2. オントロジーディレクトリを用意する

metamesh 自身はドメインデータを持たない。自分のオントロジーディレクトリを 作る (空でも OK、最初の add_concept で生成される):

mkdir -p ~/my-ontology/{concepts,relationships}
export METAMESH_ONTOLOGY_ROOT=~/my-ontology

または既存の例を借りる:

git clone https://github.com/Islanders-Treasure0969/vtuber-analytics
export METAMESH_ONTOLOGY_ROOT=$PWD/vtuber-analytics/ontology

3. Claude Desktop に登録

~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "metamesh": {
      "command": "/path/to/uv",
      "args": [
        "--directory", "/path/to/metamesh",
        "run", "python", "-m", "metamesh.server"
      ],
      "env": {
        "METAMESH_ONTOLOGY_ROOT": "/path/to/your/ontology"
      }
    }
  }
}

uv のフルパスは which uv で取得 (PATH を継承しない環境があるため絶対パス推奨)。

4. 最初の概念を作る

Claude にこう話しかけるだけ:

「Streamer って概念を metamesh に追加して」

cbc-modeling-interview Skill が起動して、Claude が CBC Form 相当の 質問を順番に投げてくれる。回答すれば自動的に <METAMESH_ONTOLOGY_ROOT>/concepts/Streamer.jsonld が生成される。

MCP ツール一覧

Core (3)

書き込みと検索の最小セット。通常はこれだけで完結する。

Optional bulk exporters (3)

CI で一括書き出しする等の用途には便利。通常運用では query_concept で 都度引いて Claude が必要な形に変換すれば足りるので、必須ではない。

実出力サンプルは vtuber-analytics の output/ を参照。

SPARQL 実例集

query_concept(sparql=...) で叩ける。CONSTRUCT / DESCRIBE は subgraph を triples で返すので、Claude が即座に Mermaid やテーブルに変換可能。

全 Hub と business_key を一覧

PREFIX dv: <https://metamesh.dev/ext/dv/>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
SELECT ?label ?hub ?bk WHERE {
    ?c dv:hub ?hub ;
       dv:business_key ?bk ;
       skos:prefLabel ?label .
    FILTER(LANG(?label) = "ja")
}
ORDER BY ?hub

特定概念の近傍 subgraph (CONSTRUCT)

PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
CONSTRUCT { ?s ?p ?o }
WHERE {
    { <https://metamesh.dev/ontology/Streamer> ?p ?o . BIND(<https://metamesh.dev/ontology/Streamer> AS ?s) }
    UNION
    { ?s ?p <https://metamesh.dev/ontology/Streamer> . BIND(<https://metamesh.dev/ontology/Streamer> AS ?o) }
}

→ Claude が triples を Mermaid に変換して即時可視化。

N:M 関係性だけ抽出

PREFIX dv: <https://metamesh.dev/ext/dv/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT ?rel ?domain ?range WHERE {
    ?rel dv:cardinality "N:M" ;
         rdfs:domain ?domain ;
         rdfs:range ?range .
}

可視化について

metamesh は組み込みの可視化コマンドを持たない。理由:

1. SPARQL (CONSTRUCT) で subgraph を取れば、Claude が文脈に応じた最適な 形式 (Mermaid / Graphviz / 表 / Cytoscape JSON) で都度レンダリングできる
2. オントロジー編集の標準ツール (Protégé / WebVOWL) は metamesh の 出力する JSON-LD を直接食える。深い分析はそちらに任せた方が劣化しない

この設計の具体実装が ontology-visualize Skill。「Mermaid で見せて」「N:M 関係だけ図示して」「Streamer 周辺だけ」等の自然言語要求を SPARQL CONSTRUCT に変換 → triples を Mermaid に変換 → チャットに直貼り、を 1 プロンプトで 完結する。.claude/skills/ontology-visualize/SKILL.md 参照。

オントロジー直接編集 (advanced)

オントロジーは生 JSON-LD ファイルなので、好きなツールで開いて手で書ける:

• Protégé で <METAMESH_ONTOLOGY_ROOT>/concepts/*.jsonld を順次 import
• WebVOWL に JSON-LD をアップロードして可視化
• 任意のテキストエディタ + git diff レビュー

add_concept / add_relationship は rdflib で round-trip 検証してから 保存するので、これらツール経由で書いた場合は別途整合性確認を推奨 (uv run pytest で構造テスト)。

参照実装: vtuber-analytics

Islanders-Treasure0969/vtuber-analytics は metamesh のフレームワークを VTuber 分析に適用したリポジトリ。

• 7 概念 + 6 関係性のオントロジー (Streamer / Channel / Stream / Org / Collaboration / Clip / Topic)
• metamesh が生成した dbt / MetricFlow / LLM context のサンプル
• Holodex API でオントロジーの dv:business_key を実データ検証するスクリプト

「metamesh をどう使うか」の具体例として、また自身の VTuber 分析プロジェクト として、独立したリポジトリで運用される。

開発

uv sync --extra dev    # ruff / pytest / pytest-asyncio
uv run pytest -v       # 69 tests
uv run ruff check .

ロードマップ (フレームワーク本体)

関連資料

• POSITIONING.md — metamesh の立ち位置 / 隣接 OSS との関係 / 非ゴール
• docs/PROJECT_CONTEXT.md — フレームワーク全体の設計根拠
• docs/references/ — Data Vault / SKOS / OWL の参考資料
• vtuber-analytics — 参照実装

License

Apache-2.0