Claude CodeのDataHubプラグインでカタログ検索とコネクタ開発を回す
datahub-skillsプラグインの入れ方、カタログ操作の5スキル、コネクタ開発の3スキルを整理し、書き込み前の承認フローと接続設定のつまずきどころまで扱います。
DataHubのカタログを検索し、説明文やタグを付け、リネージを追い、さらに自前のコネクタを開発する。この一連の作業をClaude Codeから呼び出せるようにするのが、DataHub Projectが公開しているプラグイン「datahub-skills」です。
導入は1行で済みます。難しいのは、DataHubへの接続設定と、書き込み系のスキルをどこまで任せるかの線引きです。
claude plugin install datahub-skillsdatahub-skillsプラグインとは何か
datahub-skillsは、DataHub向けのエージェントスキル集です。マーケットプレイスのページには「カタログ検索・メタデータ付与・リネージ追跡・データ品質管理・接続設定に加え、コネクタの計画とPRレビューまで含む開発・操作ツールキット」と説明されています。提供元はDataHubで、マーケットプレイス上の導入数は569です。
リポジトリのライセンスはApache 2.0で、plugin.json のバージョンは1.4.1です。Claude Code以外にCursor、Codex、Copilot、Gemini CLI、Windsurfなどでも使えますが、機能に差があります。差分は後半の表にまとめます。
中身は大きく2系統に分かれます。
プラグインの2系統
カタログ操作（5スキル）
datahub-search、datahub-enrich、datahub-lineage、datahub-quality、datahub-setup。DataHubに登録済みのメタデータを読み書きします。
コネクタ開発（3スキル）
datahub-connector-planning、datahub-connector-pr-review、load-standards。取り込み元を増やすコネクタ自体を作る側の作業です。
このほかに、セッション開始時に注入されるルーティング用スキル using-datahub と、CLI・MCP・エンティティモデルの共有リファレンス shared-references が同梱されています。using-datahub は「検索ならsearch、タグ付けならenrich」のように、依頼の言い回しを5つのカタログ操作スキルへ振り分ける表です。直接呼ぶものではありません。
導入手順とスキルCLI経由の違い
Claude Codeへの入れ方は2通りあります。
# A: プラグインとして入れる(フック・スラッシュコマンド・マルチエージェント付き)
claude plugin install datahub-skills
# B: Skills CLI でプロジェクト単位に入れる(.claude/skills/ に配置)
npx skills add datahub-project/datahub-skills -a claude-code選び方は単純です。スラッシュコマンドとSessionStartフック、並列レビューを使うならA。スキルだけをリポジトリに置いてチームで共有するならBです。READMEの対応表では、スラッシュコマンドとSessionStartフックはClaude Codeのプラグイン経由でだけ使えると書かれています。
コネクタのレビューで並列実行を使いたい場合は、pr-review-toolkit も入れます。
claude plugin install pr-review-toolkit@claude-plugins-officialClaude Codeとほかのエージェントで何が違うか
| 機能 | Claude Code | Cursor / Copilot / Codex / Gemini CLI / Windsurf |
|---|---|---|
| カタログ検索・メタデータ付与・リネージ・品質・接続設定 | Claude Code使える | Cursor / Copilot / Codex / Gemini CLI / Windsurf使える |
| コネクタの計画・レビュー・標準の読み込み | Claude Code使える | Cursor / Copilot / Codex / Gemini CLI / Windsurf使える |
| レビューの並列実行(5サブエージェント) | Claude Code使える | Cursor / Copilot / Codex / Gemini CLI / Windsurf不可(順番に実行) |
| 調査エージェントへの委任 | Claude Code専用エージェント | Cursor / Copilot / Codex / Gemini CLI / Windsurfインラインで代替 |
| スラッシュコマンド | Claude Code使える | Cursor / Copilot / Codex / Gemini CLI / Windsurf不可(自然文で依頼) |
| SessionStartフック | Claude Codeプラグイン経由で使える | Cursor / Copilot / Codex / Gemini CLI / Windsurf不可 |
カタログ操作そのものは、どのエージェントでも同じ結果になります。Claude Codeで増えるのは、並列レビューとコマンド、セッション開始時のルーティング注入です。
最初にやること — DataHubへの接続設定
プラグインを入れただけではカタログに触れません。接続先の設定を済ませるのが datahub-setup スキルで、「DataHubに接続したい」と頼めば環境の点検から始まります。
点検の対象はPython、仮想環境、DataHub CLI、GMSのURL、トークン、MCPサーバーの6項目です。結果は表で返り、トークンの値は表示されません。
認証の方法は3つあります。
~/.datahubenvにGMSのURLとトークンを書く(推奨。chmod 600を勧められる)- 環境変数
DATAHUB_GMS_URLとDATAHUB_GMS_TOKENを設定する(設定ファイルより優先される) - DataHubのMCPサーバーを設定する
設定ファイルの形は次のとおりです。
gms:
server: "<GMS_URL>"
token: "<PERSONAL_ACCESS_TOKEN>"GMSのURLは環境ごとに形が違います。ローカルのDockerなら http://localhost:8080、Acryl Cloudなら https://<INSTANCE>.acryl.io/gms、Kubernetesなら http://datahub-gms.<NAMESPACE>:8080 が例として挙がっています。
DataHubのMCPツール(search、get_entities、get_lineage など)が既に使える環境では、スキルはCLIの導入と認証を飛ばし、search(query="*", count=1) で疎通だけを確かめます。MCPで繋いでいるなら、CLIは任意です。
CLIを使う場合は、仮想環境に入れる決まりになっています。
python3 -m venv .venv && source .venv/bin/activate
pip install acryl-datahub
datahub version疎通確認は次の3コマンドを順に実行し、最初の失敗で止まります。
datahub get --urn "urn:li:corpuser:datahub"
datahub search "*" --limit 1
datahub check server-config接続でつまずいたときの切り分け
datahubコマンドが通らないとき
- QConnection refusedが出ていますか?答えが次へ答えがはい
URLの誤りかGMSの未起動です。URLとサーバーの状態を見直します。
- Q401 Unauthorizedが出ていますか?答えが次へ答えがはい
トークンが無効か期限切れです。DataHubの画面でトークンを作り直します。
- Q403 Forbiddenが出ていますか?答えが次へ答えがはい
トークンの権限が足りません。スコープを確認します。
検索結果が空だけの場合
メタデータをまだ取り込んでいない新規インスタンスなら正常な状態です。
自己署名証明書のエラーには --disable-ssl-verification が必要になることがある、とも書かれています。付ける前に、社内の証明書を信頼する設定で済まないかを先に当たるほうが安全です。
さらに、検索の既定値を決めたいときは .datahub-agent-config.yml というプロファイルを作れます。設定できるのは、対象プラットフォーム、ドメイン、エンティティの種類、環境(PROD / DEV)、1回の取得件数(既定10)、非推奨の除外などです。チームごとの設定は .datahub-agent-config.<name>.yml として複数持てます。保存前に内容を見せ、同意を取る流れです。
カタログを操作する5つのスキル
Claude Codeでは、依頼を自然文で書いても、スラッシュ付きで呼んでも動きます。
Find revenue tables in Snowflake
/datahub-search datasets tagged PII
/datahub-enrich set owner of revenue_daily to @jdoe
/datahub-lineage trace the customer pipeline
/datahub-quality raise an incident on the customer pipeline
/datahub-setup focus on Snowflake in the Finance domain| スキル | できること | 向く依頼 |
|---|---|---|
| search | できることキーワード検索、絞り込み、カラム名検索、構造化プロパティの照会、複数ステップの質問応答 | 向く依頼「注文テーブルの持ち主は誰か」 |
| enrich | できること説明・タグ・用語集・オーナー・非推奨の付与と更新 | 向く依頼「このカラムにPIIタグを付けたい」 |
| lineage | できること上流・下流の追跡、影響範囲の分析、プラットフォームをまたぐデータフロー | 向く依頼「テーブルを変えたら何が壊れるか」 |
| quality | できることアサーションの作成と実行、インシデントの起票と解消、通知の購読 | 向く依頼「鮮度のアサーションを作りたい」 |
| setup | できることCLI導入、認証、疎通確認、既定スコープとプロファイル | 向く依頼「接続をセットアップしたい」 |
qualityには棲み分けがあります。READMEによると、Open Source版では診断が中心で、フルの管理機能はCloud版の側にあります。自分のDataHubがOSSかCloudかで、頼める範囲が変わります。
メタデータの書き込みは必ず承認を挟む
enrichは書き込み系なので、動きが慎重に作られています。SKILL.md の流れは「対象の特定 → 計画 → 承認 → 実行 → 検証」です。
- 書き込みの承認は必須で、単一エンティティの更新でも省略しない
- 変更前後の差分を計画として見せ、了承を得てから実行する
- 一括更新では、該当エンティティを最大20件まで表示し、総数を伝えて範囲を確認する
- 対象が50件を超えるときは、件数の明示的な確認を求める
- 10件ごとに進捗を報告し、エラーが出たらその場で止めて成功分と失敗分を報告する
- 書き込み後に再読み込みして、変更が反映されたかを確かめる
読み取り中心のsearchと違い、enrichは検索用のサブエージェント metadata-searcher に委任しません。変更の文脈と承認フローを持たないエージェントに任せないための設計だと、SKILL.md に書かれています。
実運用では、まず「説明が空のテーブルに説明文を提案させる」ような小さな範囲で回し、承認画面の見え方を確かめてから一括に進める使い方が合います。
落とし穴
一括更新を『まとめて承認』で流さない
50件を超える更新は件数の確認が入ります。それでも、サンプルとして見せられるのは最大20件です。残りの30件以上は中身を見ないまま承認することになるので、先に検索で対象を絞り、タグやオーナーの条件を細かく指定してから頼むのが無難です。
コネクタ開発の3スキルと4つのエージェント
DataHubに新しいデータソースを取り込むコネクタを作る側の作業にも、スキルが用意されています。
datahub-connector-planning— 取り込み元の種類を分類し、調査し、エンティティの対応づけと設計を書いた_PLANNING.mdを作り、承認を得るまでコードを書かない4段階datahub-connector-pr-review— コネクタのコードを22の標準に照らして検査する。Claude Codeでは、サイレント失敗・テストカバレッジ・型設計・単純化・コメント対応の5エージェントが並列で走るload-standards— 22の標準を最初に文脈へ読み込み、コネクタ作業の前提を揃える
22の標準は、コアが11、ソース種別が11です。コアはmain、api、sql、code_style、containers、lineage、patterns、performance、platform_registration、registration、testing。ソース種別はbi_tools、data_lakes、data_warehouses、identity_platforms、ml_platforms、nosql_databases、orchestration_tools、product_analytics、query_engines、sql_databases、streaming_platformsです。
/connector-planning duckdb
/connector-review postgres
/load-standards計画の段階では、connector-researcher エージェントが取り込み元のシステムを調べます。レビューでは connector-validator が検証スクリプトを走らせて結果を報告し、comment-resolution-checker がPRレビューの指摘が実際に直されたかを確かめます。カタログ側の検索を高速に処理する metadata-searcher と合わせ、同梱エージェントは4つです。
計画から実装へ進む順番
新しいコネクタを作る流れ
- 1
標準を読み込む
/load-standardsで22の標準を文脈に入れます。 - 2
計画を作って承認する
/connector-planning <取り込み元>で_PLANNING.mdを作らせ、エンティティの対応と設計に了承を出します。 - 3
実装する
承認後に、通常のClaude Codeの作業としてコードとテストを書きます。
- 4
レビューにかける
/connector-review <コネクタ名>か、PR番号を渡して並列レビューを回します。
標準を最初に読み込ませる理由は、READMEに「エージェントが何に照らして検査しているかを実際に知った状態にする」ためと書かれています。計画とレビューの両方に標準が付属しているので、片方のスキルだけを入れても標準は一緒に届きます。
つまずきやすい点
コマンド名が2種類ある。READMEのコマンド表には /catalog-search、/catalog-enrich、/catalog-lineage、/catalog-quality、/catalog-setup が載っています。一方、各スキルの説明やルーティング表では /datahub-search などの名前が使われています。リポジトリには commands/catalog-*.md と skills/datahub-* の両方があるため、どちらも存在する名前です。補完候補にどちらが出るかは、/ を入力して確かめるのが確実です。
evalsには別途の準備が要る。READMEのEvalsは、保存済みの評価を新しいエージェントで実行する機能です。使うにはDataHub CloudのCLI(pip install 'acryl-datahub-cloud[datahub-evals]')と、回答するエージェント側のDataHub MCPサーバーが必要です。
プラグインにMCPサーバーは同梱されていない。接続方法の選択肢にはMCPが含まれますが、MCPサーバーの設定は別途行う前提です。リポジトリのルートに .mcp.json は置かれていません。
トークンを会話に出さない。setupスキルはトークンの値を表示せず、<REDACTED> で伏せる決まりです。それでも、トークンを会話に貼り付けて渡すのは避け、~/.datahubenv か環境変数で渡します。
OAuthでClaudeとDataHubを繋ぐ方法は、ClaudeとDataHubを連携する方法で扱っています。そちらはClaude側からカタログを操作する経路で、このプラグインはClaude Codeにスキルとコマンドを足す経路です。
ほかのプラグイン記事との比べ方
プラグインの入れ方そのものは、どの記事でも変わりません。Claude Codeのfeature-devプラグインやAikidoプラグインと同様に、claude plugin install で入れ、スラッシュコマンドとスキルを呼びます。
違いは、datahub-skillsが「外部サービスの操作」と「そのサービス自体の開発」の両方を1つに束ねている点です。カタログを使う人とコネクタを書く人は、同じデータ基盤チームでも別の担当になりがちです。入れるときは、使う側のスキルだけをSkills CLIで個別に入れる選択もあります。各スキルのディレクトリは自己完結していて、標準もシンボリックリンクで一緒に届くためです。
プラグインの仕組みそのものはClaude.aiのプラグイン機能とはに整理があります。
まとめ
datahub-skillsは、導入そのものより接続設定と書き込みの扱いに手間がかかるプラグインです。OSSのDataHubならqualityの管理機能は限られ、Cloud版ではevalsのような追加の準備も要ります。まずはsearchとlineageのような読み取り系から使い、承認の流れを確かめてからenrichに進むと、事故を避けながら範囲を広げられます。コネクタを作る側は、/load-standards と /connector-planning の順に進め、計画の承認を実装の前に置くのが基本線です。