DifyでLooker MCPを使ってAgent AI作ってみた（感想）
最近話題のMCP（Model Context Protocol）ですが、皆さんはもう試されましたか？
僕はというとDifyでLooker MCPを組み込んでAgent AIを作ってみました。結論から言うと「確かに便利だけど実務で使うにはまだ早いかも」という感じです。
この記事では、Dify + Looker MCPでの実装から、Slack連携、そして「結局古典的な方法が一番じゃん」という気づきまでを書いていきます。
Difyとは
DifyはOSSのLLMアプリケーション開発プラットフォームです。僕の環境ではセルフホストで運用しています。
主な特徴としては：
- ノーコード/ローコードでLLMアプリケーションを構築可能
- RAG、Agent、Chatbot、Workflowなど様々なアプリケーションタイプに対応
- 各種LLMプロバイダーとの統合が容易
- OSSなので自社環境にホスト可能
特に実務で使う場合、データガバナンスの観点からセルフホストできるのは大きなメリットです。OpenAIのAPIに直接データを投げるよりは、自社管理下でコントロールできますから。
Looker MCPとは
MCPはAnthropicが提唱したプロトコルで、LLMと外部ツールを標準化された方法で接続するための仕組みです。
Looker MCPは、このMCPを使ってLooker（Google Cloud）のデータを探索できるようにしたものです。
理論上は：
- LookMLで定義されたモデルをAIが理解
- 自然言語でのクエリをLookerのAPIに変換
- データを取得して回答を生成
という流れで、「昨日の売上を教えて」といった質問に答えてくれるはずです。
LookMLの整備 vs 探索的AI利用
ここからが本題です。
Looker MCPを使うと、AIがLookMLを読み取って探索的にデータを取得してくれます。
しかし、これは本当に正しいアプローチなのか？ という疑問が湧いてきました。
なんでもAIに探索させるのは危険
実務でデータ分析をしていると分かりますが、データというのは文脈（コンテキスト）が非常に重要です。
例えば：
- 「売上」といっても、キャンセル分を含むのか含まないのか
- 「ユーザー数」といっても、アクティブユーザーなのか登録ユーザーなのか
- 「昨日」といっても、システム日付なのかユーザーのタイムゾーンなのか
これらの定義は、LookMLで明確に定義されているべきです。つまり、Semantic Layerとしてきちんと整備されたLookMLがあれば、そもそもAIに探索させる必要がないわけです。
Semantic Layerの重要性
Semantic Layerとは、データの意味を定義する層のことです。
LookMLでいえば：
measure: total_revenue {
type: sum
sql: ${TABLE}.revenue ;;
description: "キャンセルを除いた純粋な売上金額"
value_format_name: jpy
}
measure: active_users {
type: count_distinct
sql: ${user_id} ;;
filters: [last_active_date: "30 days"]
description: "過去30日以内にアクティビティがあったユーザー数"
}
このように明確に定義されていれば、誰が見ても、どのツールを使っても、同じ結果が得られます。
データは嘘をつかないがデータを扱う人は嘘をつく、という言葉があります。
AIも同じで、AIは与えられた情報の中からそれらしい答えを返しますが、それが正しいとは限りません。
だからこそ、人間が責任を持ってSemantic Layerを整備する必要があります。
これは最近でいうAI-readyなデータセットという観点ですね。
Slack連携の実装
とはいえ、MCPを試してみたかったので、CloudFlareを経由してSlackと連携してみました。
アーキテクチャ
Slack ←→ CloudFlare Workers ←→ Dify Agent ←→ Looker MCP
CloudFlare Workersを使った理由は：
- サーバーレスで運用が楽
- 自社サーバーに建てたOSSなのでセキュリティ的に穴開けないといけない（ほぼこれ）
- レスポンスが速い
- Slack側のタイムアウト（3秒）対策
実装のポイント
Slackからのリクエストは3秒以内に応答しないとタイムアウトしてしまいます。
そのため、CloudFlare Workers側で：
- Slackからのリクエストを受け取る
- すぐに200 OKを返す
- 非同期でDify Agent APIにリクエスト
- 結果をSlackにポスト
という流れにしました。
結果は成功してます。
ユーザーはSlackで「昨日の売上教えて」と聞けば、数秒後に回答が返ってくる、というわけです。
実際に使ってみた結果
ここからが重要なのですが、実際に運用してみて分かったことがあります。
トークンをめちゃくちゃ消費する
結局looker-queryなどでLook MLを回してPDTされているデータを取ってくるわけですが、これってつまり表データをtokenに変換して必要な情報を取得してくるので、かなりのトークンを消費する。場合によっては数万から十数万トークンをただのシンプルな回答に浪費する。
これは結構致命的でした。
回答が安定しない
同じ質問をしても、微妙に違う結果が返ってくることがあります。
これはLLMの性質上仕方ない部分もありますが、実務で使うには致命的です。
例えば：
- 1回目：「昨日の売上は1,234,567円です」
- 2回目：「昨日の売上は123,456円です」(たぶん別のLook MLから取得しちゃってる)
- 3回目：「昨日(2025-10-13)は未来の日付のため売上データが見つかりませんでした」
これでは信頼できません。
Lookerを綺麗に整備していたら使う機会がない
そしてもっと本質的な問題として、LookMLがきちんと整備されていれば、そもそもMCPを使う必要がないということです。
Lookerでダッシュボードを作っておけば：
- 誰でも同じ定義でデータを見られる
- 結果は常に一貫している
- 可視化も綺麗
- パフォーマンスも安定
わざわざAIを経由する理由がないわけです。
つまりきちんと整備されていれば不安定な答えを取得するより、正しいダッシュボードを参照するコストの方はるかに安いということです。
リテラシーの問題
さらに、MCPを使いこなすには、ある程度のデータリテラシーが必要です。
- どういう質問をすればいいのか
- 返ってきた結果が正しいのかを判断できるか
- エラーが出たときに対処できるか
これらを全員に要求するのは現実的ではありません。
結局、古典的な方法が一番では？
Looker MCPを実装してみて、改めて思ったことがあります。
正しいことを正しくやるほうが、組織としては健全なのでは？
具体的には：
- LookMLをSemantic Layerとしてきちんと整備する
- 必要なメトリクスを明確に定義する
- ダッシュボードやExploreで正しいデータへのアクセスを誘導する
- データを管理する人が見せるデータを制御する
これらの「古典的」なアプローチのほうが、結果的には：
- データの一貫性が保たれる
- 誰でも同じ結果を得られる
- 説明責任を果たせる
- メンテナンスコストが低い
LLMは確かに便利ですが、不安定要素が絶対に付きまといます。そのコントロールに時間を費やすより、正しいものを整備して周知したほうがいいんじゃないか、というのが僕の結論です。
まとめ
Looker MCPを試してみた結果：
- 技術的には非常に面白い
- 個人的な探索には便利
- しかし組織全体で使うにはまだ早い
- 結局、基本に忠実にデータ基盤を整備するほうが重要
データ分析の世界では、新しい技術が次々と出てきます。しかし、本質的に重要なのは：
- データの定義を明確にすること
- 誰でも同じ結果を得られる仕組みを作ること
- 説明責任を果たせる状態を維持すること
これらの「古典的」な原則は、AIの時代になっても変わらないのではないでしょうか。
Looker MCPは確かにめちゃくちゃ便利です。でも、実際に必要レベルかと言われると、やはりある程度のリテラシーを要求されるので、組織全員に利用してもらうようなケースはまだ現実的じゃないな、というのが今回の検証での学びでした。
もちろん技術の進化は見守り続けますし、実用レベルになったらまた試してみたいと思います。それまでは、地道にLookMLを整備していくことにします。
というわけで、今回はDify + Looker MCPの実装と、そこから得られた気づきについて書いてみました。
皆さんの環境ではどうでしょうか？もし試された方がいれば、ぜひコメントで教えてください。
Discussion