Claude Media
Claude CodeのData Agent KitプラグインでdbtとGoogle Cloudのパイプラインを組む
Claude CodeClaude連携チュートリアル

Claude CodeのData Agent KitプラグインでdbtとGoogle Cloudのパイプラインを組む

Google LLCのData Agent Kitプラグイン(dak)の入れ方、dak-setupの設定、dbt-bigqueryなどのスキル、11個のMCPサーバー、権限とテレメトリの扱いを順に説明します。

読了目安 約11分

Claude CodeでGoogle Cloudのデータ基盤を触るなら、Google LLCが公開しているData Agent Kitプラグインが入口になります。プラグイン名は dak、スキル群とMCPサーバー群を1回の導入でまとめて入れられます。BigQueryのSQL、dbtのモデル、Sparkノートブック、Airflowのオーケストレーションを、自然文の指示から進める作りです。

マーケットプレイスのページ名は data-agent-kit-starter-pack ですが、claude plugin install で指定する名前は dak@dak-marketplace です。この名前の違いが最初のつまずきどころになります。この記事では導入から初回設定、dbtまわりのスキルの動き、同梱MCPの中身、権限の絞り方までを順に追います。

入れる前に揃える前提

要件は3つです。

  • Claude Code(READMEは他にAntigravity CLI、Codex CLIも対象と書いています)
  • Node.js(最新のLTS推奨)
  • 認証済みのGoogle Cloud CLI(gcloud)

認証は2段階で、ユーザー認証とApplication Default Credentials(ADC)の両方が要ります。MCPサーバーはADCを使ってGoogle CloudのAPIに接続するため、片方だけでは動きません。

gcloud auth login
gcloud auth application-default login

IDEで使う場合は、プラグインではなく「Data Agent Kit」拡張を入れるよう案内されています。VS Codeならマーケットプレイスの拡張、Antigravity IDEやCursorなどVS Codeベースの環境なら拡張機能パネルで検索します。このプラグインはCLI型のコーディングエージェント向けです。

Claude Codeへの導入と初回設定

導入はマーケットプレイスの登録とインストールの2コマンドです。

claude plugin marketplace add \
  https://github.com/GoogleCloudPlatform/data-agent-kit-plugin
claude plugin install dak@dak-marketplace

リポジトリの .claude-plugin/marketplace.json を見ると、マーケットプレイス名は dak-marketplace、中身のプラグインは dak の1本だけです。

dak-setupで設定を済ませる

導入直後は設定が空です。READMEによると、エージェントに何か指示を出せば設定の案内が始まります。手動で呼ぶなら次のスキルです。

/dak:dak-setup

dak-setup のSKILL.mdは、次の順で進めるよう書かれています。前のステップが終わらないと次へ進みません。

手順

dak-setupの進み方

  1. 1

    gcloudの存在確認

    gcloud --version を実行します。無ければそこで止まり、インストール案内だけを出します。自動で入れ直すことはしません。

  2. 2

    ADCの確認

    アクセストークンを出力せずに有無だけ確かめます。無ければブラウザのサインインを開く gcloud auth application-default login に進みます。ヘッドレス環境では --no-launch-browser を使う指示です。

  3. 3

    プロジェクトIDの確認

    gcloud config get-value project で既定値を拾い、確認を取ります。表示名ではなくプロジェクトIDかどうかも見ます。

  4. 4

    リージョンとサービスの選択

    使うGoogle Cloudサービスとリージョンを決め、同梱のセットアップスクリプトを実行します。

  5. 5

    エージェントの再起動

    READMEは、促されたらエージェントを再起動して設定を反映させるよう求めています。

セッション開始時には dak-setup.js sync を呼ぶSessionStartフック(startup|resume)も入ります。設定が欠けていればこのフックが検知し、dak-setup スキルの出番になります。

認証エラー(could not find default credentials など)が出たら、READMEの手順は「エージェントを終了し、gcloud auth login と gcloud auth application-default login を順に実行してから再起動」です。

入口はgcp-data-pipelinesスキル

skills ディレクトリには37個のスキルが並びます。名前から見ると、BigQuery系、dbtとDataform、Dataflow、Spark、Airflow(Composer)系、Cloud Storage系、ノートブックとML系、セキュリティ系に分かれます。

パイプラインを組むときの入口は gcp-data-pipelines です。説明文には、dbt、Dataflow(Apache Beam)、Dataform、Spark(Dataproc Serverless)、BigQuery Data Transfer Service、Cloud Composerによるオーケストレーションのどれが適切かへ導き、曖昧な要件を整理するスキルとあります。「何で組むか」が決まっていない段階の指示は、まずここが受けます。

dbtを使うと決まれば dbt-bigquery スキルが、Airflow DAGを書くなら gcp-managed-airflow-dag-authoring が、失敗の調査なら gcp-composer-troubleshooting や gcp-spark-troubleshooting が担当します。

dbt-bigqueryスキルが決めている作業の流れ

dbtの記事として最も参考になるのが dbt-bigquery のSKILL.mdです。「dbtモデルやプロジェクトを作る・変える・直す」ときに使うとされ、手順が細かく書かれています。要点を拾います。

動作

dbt-bigqueryの動作ルール

  • 環境を先に確認する

    dbt --version と bq version を実行します。dbtが無ければPython仮想環境の作成と dbt-bigquery の導入を案内します。プロジェクトIDの指定が無ければ gcloud config get-value project の値を使います。

  • 既存のDAGを把握する

    dbt_project.yml を探し、dbt compile で既存のDAGを把握します。コンパイル結果を既存アセットの正とします。

  • データを見てから書く

    bq ls、bq show --schema、bq head で元テーブルと出力先のスキーマとサンプルを確認します。IDが不明なら discovering-gcp-data-assets スキルで探します。

  • 新規プロジェクトはdbt/に作る

    プロジェクトが無いときは、ルート直下ではなく dbt/ のような専用サブディレクトリに生成します。dbt init --skip-profile-setup で雛形を作り、profiles.yml も同じ場所に必ず置きます。

注目は、dbt run の扱いです。SKILL.mdは「ユーザーの明示的な確認なしに dbt run を実行しない」と書いています。通常の反復では dbt compile で構文と依存関係を確かめ、必要に応じて dbt test を回し、実際のテーブル作成はユーザーに委ねる設計です。本番のBigQueryにコストと副作用が出る操作を、人の確認の後ろに置いています。

指示しなくても入る自動処理

同じSKILL.mdには、頼んでいなくても適用する処理も書かれています。

  • データクレンジング: data-autocleaning スキルの手順に従い、応答に「Automatic Cleaning Summary」の節を付ける
  • SQL最適化: bigquery-sql スキルの手順に従い、適用した内容を「Optimization Summary」にまとめる

最適化の中でも、IN (SELECT ...) を EXISTS に書き換えるものは必須の書き換えです。UNION から UNION ALL、COUNT(DISTINCT) から APPROX_COUNT_DISTINCT は、結果が変わりうるため確認を取ってから適用します。既存のモデルを触らせるときは、差分にこの自動処理が混ざることを前提に、レビューの対象に含めてください。

新しいdbtモデルには必ず config ブロックを付ける決まりもあります。

{{
    config(
        materialized = "table",
    )
}}

参照は {{ ref('model_name') }} と {{ source('source_name', 'table_name') }} を使い、テーブル名の直書きを避けます。

profiles.ymlの欠落が最頻の失敗原因

SKILL.mdは profiles.yml の欠落を「パイプライン失敗の主因」と位置づけています。リモートのDAG実行で Could not find profile named 'X' が出たら、バンドルやバケットに profiles.yml があるかを確認し、BigQueryのプロジェクト・データセット・ロケーションを対応づけた設定を示す、という手順です。ローカルで動いたdbtがComposer上で動かないとき、最初に疑う場所として覚えておけます。

dbtの実行結果の絞り込みはClaude Codeでdbt build --selectを回すに、dbt自体のMCPサーバーを使う方法はdbt MCPサーバーの使い方にまとめています。dakはGoogle Cloud側の知識をスキルで補うもので、dbt MCPとは役割が違います。

同梱の11個のMCPサーバー

mcp.json には11個のMCPサーバーが定義されています。

サーバー接続先用途の目安
dak-bigquery接続先bigquery.googleapis.com/mcp用途の目安BigQuery
dak-cloudsql接続先sqladmin.googleapis.com/mcp用途の目安Cloud SQL
dak-alloydb接続先alloydb.googleapis.com/mcp用途の目安AlloyDB
dak-spanner接続先spanner.googleapis.com/mcp用途の目安Spanner
dak-bigtable / dak-bigtable-data接続先bigtableadmin / bigtable.googleapis.com/mcp用途の目安Bigtableの管理とデータ
dak-gcs接続先storage.googleapis.com/storage/mcp用途の目安Cloud Storage
dak-kc接続先dataplex.googleapis.com/mcp用途の目安Knowledge Catalog
dak-spark接続先dataproc-$GCP_REGION.googleapis.com/mcp用途の目安Spark
dak-notebook / dak-viz接続先ローカルのNodeプロセス用途の目安ノートブックと可視化

Google Cloudの各サービスへ向かうサーバーは、プラグイン同梱の mcp_proxy_bundle.cjs を経由して各サービスのリモートMCPエンドポイントにつなぎます。dak-spark だけは $GCP_REGION が接続先に入るため、dak-setup でリージョンを決めておく必要があります。

READMEは、BigQuery、Cloud Storage、Spanner、AlloyDB、Managed Service for Apache Spark、Knowledge Catalogなど15以上のGoogle Data Cloudサービスに接続するプラグインだと説明しています。ここで挙げた11個のサーバーはその接続口です。

単体のBigQuery MCPだけで足りる場合はClaude BigQuery連携の手順のほうが軽く済みます。Cloud SQLだけならCloud SQL for PostgreSQLプラグインがあります。dakは1回でまとめて入る代わりに、使わないサービスのサーバーも定義されます。

実際の指示の出し方

READMEの例示プロンプトは、パイプライン一式を頼む形です。たとえば次のような指示が載っています。

  • BigQueryのテーブルを使い、PySparkノートブックで分散Random Forestを学習する
  • Knowledge Catalogで顧客注文のデータセットを探し、リネージを表示する
  • 重複排除ノートブック、dbtパイプライン、モデル学習を毎週月曜に回すAirflow DAGを作る
  • 直近に失敗したDataflowジョブの原因をログから探し、修正案を出す

dbtとデータパイプラインに絞るなら、次のように段階を分けて頼むのが安全です。公式の例ではなく、スキルの動作ルールに合わせた分け方の一例です。

BigQueryのraw.ordersを元に、日次の売上集計モデルをdbt/配下に作って。
dbt compileまで通して、dbt runは私が確認してから実行する。

dbt run の確認待ちがスキル側にあるため、この指示と矛盾しません。コンパイルまでで止まったら、生成されたSQLと profiles.yml の中身を読み、問題なければ自分で dbt run を実行します。その先のスケジューリングはAirflow DAG作成のスキルに別の指示で渡します。

権限の絞り方とテレメトリ

エージェントがツールやコマンドを実行できる以上、権限は最小限に絞る、というのがREADMEのセキュリティ節の趣旨です。具体策は3つ挙げられています。

  1. エンドユーザーの認証情報ではなく、サービスアカウントの権限借用(impersonation)を使う
  2. サービスアカウントには必要なロールだけを付与する
  3. Principal Access Boundaryポリシーで、エージェントのサービスアカウントが触れるプロジェクトを限定する

READMEにはGoogle CloudのMCPに対するプロンプトインジェクションの緩和策への案内も付いています。ADCに自分の高権限アカウントをそのまま使うと、エージェントが本番プロジェクトを触れてしまうため、検証用のプロジェクトとサービスアカウントで始めるのが無難です。

落とし穴

使用統計が既定で送られる

プラグインはスキルやMCPツールが使われた時点などの使用統計を収集します。ユーザーのコード、ファイルの中身、アプリケーションのデータ値は収集しないとREADMEは書いています。フックの PreToolUse が全ツール(matcher: "*")で呼ばれる構成です。止めるなら環境変数 DO_NOT_TRACK=1 を設定するか、~/.data_agent_kit/config.json に {"enableTelemetry": false} を書きます。

導入判断の目安

マーケットプレイスのページは提供元をGoogle LLCと表示しています。リポジトリのプラグイン定義のバージョンは1.1.0で、GitHubのReleasesには1.1.0(2026年10月13日)、1.0.0(同9月29日)、0.11.0(同9月11日)が並びます。数週間で複数回更新されるため、スキル名や挙動はリポジトリのCHANGELOGで確かめてから使ってください。

向いているのは、BigQueryを中心にdbtとAirflowを使うGoogle Cloud上のデータ基盤です。スキルの中身はBigQueryやComposerなどGoogle Cloudのサービス名で書かれているため、他社クラウドのデータ基盤には向きません。Airflowだけを深掘りするなら、AstronomerプラグインのほうがDAGの作成と修復に特化しています。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →