8月14日、xbillが「Looker's Native MCP Server with Claude Code」と題した記事を公開した。この記事では、LookerのネイティブMCPサーバーにClaude Codeを接続し、Looker CLIと組み合わせて使う実践的な手順と、その設計上の分業について詳しく紹介されている。
BIツールとAIエージェントの統合は、データ分析の自動化において有力なアプローチとして注目されているが、これまでは開発者が各自の端末に重量級のバイナリをインストール・管理し続ける必要があり、導入・運用のコストが壁になっていた。今回の変更により、その摩擦が大幅に解消される。また、MCP（Model Context Protocol）はAnthropicが策定したオープンなプロトコルで、AIエージェントが外部ツールやデータソースと標準化されたインターフェースで対話するための仕様だ。LookerはGoogle Cloud傘下のBIプラットフォームであり、今回の対応はGoogle Cloud上のAIエージェント基盤との親和性をさらに高める動きといえる。
292MBのバイナリが不要になった
従来、エージェントをLookerに接続するにはMCP Toolboxというローカルバイナリが必要だった。292MBをダウンロードし、API認証情報を設定し、stdioサブプロセスとして起動し、アップデートを管理し続ける——これを開発者が各自の端末で行う運用だった。
Lookerはこれをサービスとしてホストするようにした。現在、Looker（Google Cloud core）とLooker（original）のすべてのインスタンスが、自身のベースURL上でMCPエンドポイントを公開している。
https://780eb09e-7dab-4076-9ec1-ecf9d8414630.looker.app/mcp
これが「インストール」の全てだ。サーバーの実体は"name":"Toolbox"——従来と同じソフトウェアをGoogleが自分たちのインフラで動かすようにしただけで、運用負担だけが消えた形だ。
接続設定：4ステップ
1. 前提条件
- 管理者による有効化が必要。
Admin → Platform → Model Context Protocolでサーバーをオンにし、エージェントが呼び出せるツールのAllowlistを設定する。 - API3認証情報（Base URL、Client ID、Client Secret）を用意する。Looker管理画面の
Users → (自ユーザー) → Edit Keysから取得できる。 - プレビュー版の制限を把握しておく。 カスタマーホスト型インスタンスは非対応。ツールアクセス制御はグローバルなAllowlistのみで、ユーザー・グループ単位の制御はない。
2. Claude Codeへの登録
設定ファイルは4行で完結し、シークレットを一切含まない。
{
"mcpServers": {
"looker-managed": {
"type": "http",
"url": "${LOOKER_MCP_URL}",
"headersHelper": "${CLAUDE_PROJECT_DIR:-.}/lk headers"
}
}
}
旧来の設定は、.envをsourceするbashラッパーで292MBのバイナリを--stdioで起動し、startup_timeout_secでハンドシェイクを待つ構成だった。エンドポイントが既に動いているため、起動待ちが消えた。
headersHelperの動作が重要だ。 これは静的な値ではなくコマンド名を指定する。Claude Codeは接続のたびにこのコマンドを実行し、401や403を受け取った場合は自動的に再実行してリトライする。LookerのアクセストークンはHTTPヘッダーとして渡される方式で、有効期限は1時間だが、期限切れは自動でリカバリーされる。
${LOOKER_MCP_URL}の展開はClaude Code自身が行う点も見落としやすい。シェルではなくClaude Codeが展開するため、この変数はclaudeを起動するプロセスの環境変数として存在していなければならない。設定スクリプトをsourceせずexecuteしてしまうと、ツールが認識されないトラブルに直結する。
3. 動作確認
Claude Codeを起動して/mcpを実行すると、looker-managedが40ツールで接続されていることが確認できる。tools/listは認証なしで応答するため、クライアントはサインイン前にサーバーを検出できる。データへのアクセスには必ずトークンが必要で、匿名でのデータ取得はできない。
MCPとCLIの分業が本質
記事の核心はここにある。「何を問うかはMCP、何を実行するかはCLI」 という分業だ。
実例：質問からCSVファイルへ
Which product categories drive the most revenue?
Claude Codeはこの問いに対してLookerのセマンティックモデルを辿る。get_modelsでインスタンスのモデル一覧を取得し、get_exploresで対象のExploreを絞り込み、get_measuresで実際に存在する集計フィールド（order_items.total_sale_priceなど）を確認してからqueryを実行する。カラム名を推測する必要がなく、ダッシュボードと同じガバナンス済み定義を読んでいる。
クエリ結果は：
Outerwear & Coats: $971,454 / 6,711件 / 平均$144.76
Jeans: $924,765 / 9,428件 / 平均 $98.09
Sweaters: $630,197 / 8,476件 / 平均 $74.35
「アウターウェアは販売件数がジーンズより33%少ないのに売上トップ。平均単価が48%高いから」という読み筋をエージェントが導く。クエリの形が固まったら、それをCLIに引き渡してCSVとして保存する：
./lk query runquery --file q.json --format csv --output category-revenue.csv
同じ数字が、コンテキストではなくディスクに着地する。
二つのインターフェースの違い
Native MCP（looker-managed） |
CLI（./lk） |
|
|---|---|---|
| カバレッジ | 40ツール（クエリ、コンテンツ、LookML開発、ヘルス） | API全体（git、ユーザー、ロール、スケジュール等） |
| 結果の行先 | モデルのコンテキスト | ディスク |
| 向いている用途 | 探索・判断・コンテンツ生成 | 大量データ、ファイル、反復実行 |
| 苦手な用途 | 大量出力、管理操作 | 何を問うかを判断すること |
40,000行をエージェントのコンテキストに流すのは現実的でない。形が決まればCSVジョブをエージェントなしで回せる。
MCPでできないこと
ギャップは設計上のもので、ランダムではない。MCPサーバーは「セマンティックモデルとしてのLooker」をカバーし、「管理システムとしてのLooker」の手前で止まる。
Git操作が全滅。
list_git_branches、create_git_branch、switch_git_branchなどはローカルバイナリにはあったが、マネージドサーバーには一つも存在しない。LookMLファイルの編集とdev_modeは使えるので、「書けるがブランチに乗れない」状態になる。ここはCLIで補う。コミット操作はAPIそのものに存在しない。 これはMCPの問題ではなくLooker APIの問題だ。「ブランチ作成→編集→バリデーション→コミット→デプロイ」のループは、コミットのステップだけが詰まる。コミットはLooker IDEのブラウザ操作が必要だ。
get_field_value_suggestionsが廃止。 フィルタ値の候補取得は、フィールドのsuggest_exploreとsuggest_dimension属性を使って直接クエリする方法で代替できる。管理操作は全てCLI経由。 ユーザー、グループ、ロール、スケジュール、接続設定など管理系の操作にMCPツールは存在しない。
ローカルバイナリとの比較
| MCP Toolbox（ローカル） | Native（Lookerホスト） | |
|---|---|---|
| インストール | 292MBダウンロード、開発者ごと | URLのみ |
| トランスポート | stdioサブプロセス | Streamable HTTP |
| バージョン | 自分で管理（現在v1.8.0） | Googleが管理（現在v1.4.0） |
| ツール数 | 46 | 40 |
| ガバナンス | クライアントサイド、助言的 | 管理パネル、インスタンス全体に強制 |
バージョンが本質的なトレードオフだ。 ホスト版はv1.4.0で、ダウンロード版はv1.8.0に進んでいる。v1.4.0以降に追加された機能に依存している場合は、移行を急ぐべきでない。
ガバナンスが本質的なメリットだ。 管理パネルでツールをオフにすれば、それは全クライアントに対して存在しなくなる。開発者ごとに設定を強制するのではなく、一か所で統制できる。
詳細はLooker's Native MCP Server with Claude Codeを参照していただきたい。
