Claudeのdata-context-extractorで社内データ分析スキルを作る
dataプラグインのdata-context-extractorは、アナリストの暗黙知を聞き出して会社固有のSQL分析スキルを生成します。質問の中身、生成物の構成、置き場所と育て方をまとめます。
data-context-extractorは、Anthropicのknowledge-work-pluginsにあるdataプラグインのスキルです。普通の分析スキルと違い、SQLを書く前にアナリストへ質問を重ね、その会社のテーブル構造・指標の定義・除外条件を聞き出して、会社専用のデータ分析スキルを生成します。Claudeに社内のウェアハウスを触らせるとき、最初に詰まる「userって何のこと?」を先に片づけるための道具です。
data-context-extractorは何を作るスキルか
SKILL.mdは自分自身を「メタスキル」と説明しています。つまり、このスキルが答えるのはデータの質問ではありません。データの質問に答えるスキルを作ります。
動作モードは2つです。
2つのモードの違い
Bootstrap Mode
ウェアハウスの種類を聞き、スキーマを調べ、質問に答えてもらい、[company]-data-analystという名前のスキルを一式生成します。
Iteration Mode
既存スキルを読み込み、足りない領域だけを質問して、references/にファイルを足し、SKILL.mdの案内表を更新します。
起動の言い回しも定義されています。新規作成なら「Create a data context skill」「Set up data analysis for our warehouse」、改善なら「Add context about [domain]」「The skill needs more info about [topic]」のような依頼がきっかけになります。日本語で頼んでも、descriptionの意味に沿って呼ばれる可能性はあります。確実に呼びたいときは、上の英語の言い回しをそのまま添えるのが無難です。
対象読者は、データアナリストや分析基盤の担当者です。想定する場面は、BigQuery・Snowflake・PostgreSQL/Redshift・Databricksのいずれかを使い、社内用語や指標の定義が人の頭の中にしかない状態です。
使う前に整えるもの:プラグインとウェアハウス接続
スキル単体ではなくdataプラグインの一部なので、先にプラグインを入れます。READMEの手順は次の2行です。
claude plugin marketplace add anthropics/knowledge-work-plugins
claude plugin install data@knowledge-work-pluginsマーケットプレイスの追加とインストールの一般的な流れはClaude Codeプラグイン完全ガイドにあります。
READMEはこのプラグインを「主にCowork向けに設計され、Claude Codeでも動く」と位置づけています。Coworkのディレクトリからの探し方はCoworkのディレクトリでスキル・コネクタ・プラグインを探すが詳しいです。
次に効くのがウェアハウス接続です。SKILL.mdのPhase 1は、~~data warehouseと書かれたクエリ・スキーマ用のツールで接続するよう指示します。~~data warehouseはCONNECTORS.mdにある置き換え用の記法で、実際に接続したMCPサーバーを指します。プラグインの.mcp.jsonには次のサーバーが入っています。
| 区分 | サーバー | URLの扱い |
|---|---|---|
| ウェアハウス | サーバーBigQuery、Definite | URLの扱い設定済み |
| ウェアハウス | サーバーSnowflake、Databricks | URLの扱いURLが空欄(自分で設定) |
| ノートブック | サーバーHex | URLの扱い設定済み |
| プロダクト分析 | サーバーAmplitude(米国・EU) | URLの扱い設定済み |
| プロジェクト管理 | サーバーAtlassian | URLの扱い設定済み |
SnowflakeとDatabricksのurlは空文字です。CONNECTORS.mdも両者に「MCP URL not yet configured」の注記を付けています。この2つを使う会社は、自社のMCPサーバーのURLを入れてから始める必要があります。
上の4製品以外でも使えます。SKILL.mdが例に挙げるウェアハウスは4種類ですが、CONNECTORS.mdの「Other options」はRedshift・PostgreSQL・MySQLなども挙げ、READMEもSQL方言を限定していません。sql-dialects.mdにはMySQLの方言メモもあります。
データ分析プラグイン全体としては、接続が無くても使えます。READMEによれば、SQLの結果を貼り付けるか、CSVやExcelをアップロードして分析を進められます。ただしdata-context-extractorのPhase 1は、~~data warehouseのスキーマツールで探索する手順です。接続なしで回すときの手順はSKILL.mdに書かれていないため、テーブル定義を会話に貼って補う形になります。
Bootstrap Modeの流れ:質問に答えるだけで何ができるか
Bootstrap Modeの4フェーズ
- 1
Phase 1:接続とスキーマ探索
ウェアハウスの種類を尋ね、データセットとスキーマを列挙します。「アナリストが最もよく叩くテーブルを3〜5個」を聞き、その詳細を引きます。
- 2
Phase 2:核心の質問
次節の5分野を、一度にではなく会話の中で順に聞きます。
- 3
Phase 3:スキル生成
SKILL.mdとreferences/以下のファイルを作ります。テンプレートはreferences/にある3種類です。 - 4
Phase 4:パッケージと提示
ファイルを作り、zipにまとめ、何を取り込んだかの要約と一緒に渡します。
Phase 1のスキーマ探索には、SKILL.mdにサンプルSQLが載っています。BigQueryならINFORMATION_SCHEMA.SCHEMATAでデータセットを、project.dataset.INFORMATION_SCHEMA.TABLESでテーブルを引きます。SnowflakeならSHOW SCHEMAS IN DATABASEとSHOW TABLES IN SCHEMAです。
聞かれる5つの質問と、答える側の準備
Phase 2の質問は5分野あります。Claudeが何を聞いてくるかを知っておくと、答えを事前に用意できます。聞かれてから思い出すより、先に文書にしておくほうが精度が上がります。
| 分野 | 聞かれること | 用意しておく答えの例 |
|---|---|---|
| エンティティの曖昧さ | 聞かれること「user」「customer」は何を指すか。種類はあるか | 用意しておく答えの例アカウント、組織、請求先の区別と、結ぶIDカラム |
| 主識別子 | 聞かれること主な識別子は何か。同じ実体に複数のIDがあるか | 用意しておく答えの例主キーと業務キー、UUIDと整数ID、旧システムのID |
| 主要指標 | 聞かれることよく聞かれる2〜3個の指標と計算式 | 用意しておく答えの例正確な式、参照するテーブルとカラム、期間の慣習(直近7日か暦月か) |
| データ衛生 | 聞かれること常に除外すべきものは何か | 用意しておく答えの例テスト・社内・不正のフラグ列、status = 'deleted'のような値 |
| よくある落とし穴 | 聞かれること新人アナリストが間違えやすい点は何か | 用意しておく答えの例紛らわしい列名、タイムゾーン、NULLの扱い、履歴テーブルと現況テーブル |
SKILL.mdはエンティティの曖昧さを「Critical」と明記しています。5分野のうち最優先という扱いです。指標の例にもARR = monthly_revenue × 12のような式が挙がっており、「だいたいの定義」ではなく、列名まで書いた式を求める作りです。
答えを散文で返すのが不安なら、あらかじめ次のような下書きを用意しておくと会話が早く進みます。これは書き方の一例で、スキルが要求する形式ではありません。
# 用語と指標の下書き(例)
- 「ユーザー」= accounts.account_id。組織は orgs.org_id(1組織:多アカウント)
- 常に除外: is_test = TRUE、is_internal = TRUE、status = 'deleted'
- 月次売上 = subscriptions.monthly_amount の当月末時点の合計(解約月は含めない)
- 注意: events.created_at は UTC。日次集計はJSTに直してから
- 注意: orders は注文時点のスナップショット。現在の状態は orders_current数字や列名は仮のものです。自社の実物に置き換えて使います。
落とし穴
口頭の「だいたい」はスキルにそのまま焼き付く
質問への答えは、そのまま生成物の定義になります。「月次売上は売上テーブルの合計」のような曖昧な答えは、曖昧なままmetrics.mdに入ります。式、対象カラム、期間の切り方まで言い切って答えるほうが、後から直す手間が減ります。
生成されるもの:ディレクトリ構成とSKILL.mdの中身
Phase 3の完成形は次の構成です。
[company]-data-analyst/
├── SKILL.md
└── references/
├── entities.md # エンティティの定義と関係
├── metrics.md # KPIの計算
├── tables/ # ドメインごとに1ファイル
│ ├── [domain1].md
│ └── [domain2].md
└── dashboards.json # 任意:既存ダッシュボードの一覧SKILL.mdのテンプレートは、name: [company]-data-analystのフロントマターで始まり、descriptionに「ウェアハウスの種類」「想定する主な用途を3つ」「会社固有の文脈が必要な質問」を入れる形です。本文は次の見出しで組まれます。
- SQL Dialect(使うウェアハウスの方言メモ)
- Entity Disambiguation(用語がどのエンティティを指すかの整理)
- Business Terminology(用語表)
- Standard Filters(常に適用する除外条件)
- Key Metrics(定義・式・参照元・粒度・注意点)
- Data Freshness(更新頻度と遅延、
MAX(日付列)での確認クエリ) - Knowledge Base Navigation(
references/への案内表) - Common Query Patterns(よく使うクエリ)
- Troubleshooting(典型的な間違い、権限エラー、パフォーマンス)
references/sql-dialects.mdには、BigQuery・Snowflake・PostgreSQL/Redshift・Databricks/Spark SQL・MySQLの5つの方言メモと、4製品の共通操作の対応表があります。たとえばBigQueryはSAFE_DIVIDEでゼロ除算を避け、SnowflakeはDIV0を使い、列の除外は前者がEXCEPT、後者がEXCLUDEです。方言を取り違えたSQLを書かせないための節で、使うウェアハウスの分だけがSKILL.mdに埋め込まれます。
ドメイン別のファイルには、クイックリファレンス(業務上の文脈、曖昧語の整理、標準フィルタ)、主要テーブルの定義(場所・主キー・更新頻度・パーティション・列表・結合関係)、指標、サンプルクエリ、よくある落とし穴、関連ダッシュボードが入ります。テンプレートは、収録を勧める領域として、revenue.md・users.md・product.md・growth.md・sales.md・marketing.md・support.mdを挙げています。
納品前の品質チェックリストは、7項目です。
- フロントマター(name・description)が揃っている
- エンティティの曖昧さの節が明確
- 主要な用語が定義されている
- 標準フィルタ・除外条件が書かれている
- ドメインごとにサンプルクエリが2〜3個ある
- 方言に合った構文でSQLが書かれている
- 参照ファイルがSKILL.mdの案内表からリンクされている
テンプレートには「プレースホルダーを残さない」「使わない節は削る」「実在のテーブル名・列名でサンプルを書く」という注意もあります。生成後に[PLACEHOLDER]が残っていないかを探すのが、最初の検収になります。
生成したスキルをどこに置くか
Phase 4は「zipにする」と書いています。Claude Codeのスキルはディレクトリ単位で置く仕組みなので、Claude Codeで使うなら、zipを展開してディレクトリとして置きます。
置き場所は、Claude Codeのスキル一般の規則に従います。
| 置き場所 | 効く範囲 |
|---|---|
~/.claude/skills/<スキル名>/SKILL.md | 効く範囲自分の全プロジェクト(Coworkやクラウドセッションでは読まれない) |
.claude/skills/<スキル名>/SKILL.md | 効く範囲そのリポジトリ。コミットすればチームに共有される |
分析基盤を管理するリポジトリが別にあるなら、そこの.claude/skills/に置いてコミットするのが、チームで使い回すいちばん素直な形です。スキルの配置と探索順の詳細はClaude Code Skillsのfrontmatter全フィールドとSKILL.mdの書き方にまとめています。
Coworkやクラウドセッションでは、手元の~/.claude/skills/は読まれません。Coworkでは、claude.aiのアカウントで有効にしたスキルが読み込まれます。個人用の場所に置いたスキルが、クラウドのスケジュール実行で「見つからない」と言われるのはこの仕様のためです。
プラグインとして配る手もあります。スキルのフォルダに.claude-plugin/plugin.jsonを置くと、プラグインとして読み込めます。詳しい手順はClaude Code skills-directoryでプラグインをそのまま動かす手順にあります。
Iteration Modeで育てる:クエリが外れたときの直し方
最初の生成で全部が揃うことは、まずありません。このスキルの設計は、運用しながら足していく前提です。Iteration Modeの手順は4段階です。
- 既存スキルを読み込む(セッション内にあればそれを使い、無ければzipやフォルダをアップロード)
- 足りない領域を特定する(「どの領域の文脈が足りないか。どのクエリが失敗したか、誤った結果を返したか」を聞かれる)
- その領域のテーブルを探索し、領域別の質問をして
references/[domain].mdを作る - SKILL.mdの「Knowledge Base Navigation」に新しい領域を足して、再パッケージする
きっかけにしやすいのは、実際に間違った集計が出た場面です。「先月のアクティブ顧客が実数の倍になった」と気づいたら、原因のテーブル結合やフラグの除外漏れをその場でIteration Modeに渡し、規則として残します。同じ間違いを2回しないための記録としてreferences/が育ちます。
間違いを規則に変える
スキルに記載なし
テストアカウントの除外条件が分からず、is_testを見ずに集計してしまう。
Standard Filtersに追記済み
WHERE is_test = FALSE AND is_internal = FALSEを既定で付け、例外が必要なときだけ理由を添えて外す。
生成したスキルは、書いた時点の知識の固定です。ウェアハウスのスキーマが変われば、スキルの記述は古くなります。Data Freshnessの表に更新頻度を書く欄はあっても、テーブル定義の変更を自動で追う仕組みはSKILL.mdには書かれていません。スキーマ変更のあとにIteration Modeを回す運用を決めておくと、陳腐化を抑えられます。ラボ機器の出力を標準形式にそろえる別系統のスキルは、instrument-data-to-allotropeの解説で扱っています。
使うときの注意点
- 機密情報の取り扱い: 生成物はテーブル名・列名・指標の式・ダッシュボードのURLを含みます。これらがスキルに入る以上、共有範囲は個人用か、リポジトリか、組織全体かを決めてから置きます。PIIを含む列の扱いは、テンプレートの「Access Issues」の節に代替の手段を書く欄があります。
- descriptionの長さ: Claude Codeはスキル一覧で
descriptionとwhen_to_useを合わせて1,536文字で切ります。生成されたdescriptionに用途を詰め込みすぎると、後半が一覧から落ちます。肝心の用途は前半に書く形が向いています。 - 生成物は実行して確かめる: 聞き出した内容をもとにClaudeが書くので、列の型や結合キーの記述が実テーブルと食い違うことがあります。サンプルクエリは必ず実行し、結果が合うかを人が確かめます。
- 隣のスキルとの分担: 可視化は別のスキルの領分です。チャートと配色はClaude Code datavizスキルが担当し、
dataプラグインにもdata-visualizationが入っています。データ文脈を作るのはこのスキル、見せ方は別のスキルという分け方です。