はじめに
以前から話題になっていたMCP（Model Context Protocol）ですが、Anthropicの独自規格の範囲に留まらず、OpenAIが公式に採用を発表した事で一気に火がつき、最近は至るところでMCPという単語が躍るようになりました。
今回はMCPを利用したデータベースとの対話+資料化までのデモを1つのユースケースとして残しておきたいと思います。
■構成
クライアント：Claude Desktop
データベース：BigQuery
データベースとの対話+資料化デモ
BigQueryのMCPサーバーについては以下2つが公開されています。
機能的にはほぼ一緒なのですが、後者はデータセット名までパラメータで渡せるので、こちらを使っていきます。
Claude Desktopの構成で以下の設定をするだけで、すぐに使えます。
"mcpServers": {
"bigquery": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/LucasHild/mcp-server-bigquery.git@main",
"mcp-server-bigquery",
"--project",
"{{GCP_PROJECT_ID}}",
"--location",
"{{GCP_LOCATION}}",
"--dataset",
"{{DATASET}}",
"--key-file",
"{{KEY_FILE_PATH}}"
],
}
今回、BigQueryのサンプルデータとして以下のダミーの売上データを使います。
1000件のデータで、店舗別、商品別の売上情報を持っています。
このデータについては何も教えずに(MCPを繋いだだけの状態で)、Claudeからリクエストを投げてみます。
「店舗別、月別売上を時系列で表示して」とリクエストすると、データセット内のテーブルとデータ構造を確認し、必要なSQLクエリを自分で組み立てて実行します。更に、その結果を元にリアルタイムでグラフ生成まで行ってくれています。
要するに、データベースさえ繋いでしまえば、ユーザーの要望とデータ構造を元に必要なSQLを自分で作成・実行する能力を持ち、Reactのコードがはけるのでグラフ生成まで自在にできるという事です。
当然、以下のような円グラフ、棒グラフなどもお手のものです。
当然、裏側でコードを持っているので、「この色を変えて」「プルダウン選択を追加して」「グラフの縦軸を伸ばして」と言った指示も即座に対応してくれます。
TextToSQLの時は、テーブル構造やCSVのみ、Code Interpreterの時は画像のみといった感じであと一歩感がありましたが、MCP+アーティファクトにより、ノーコードでここまで来れるとなると、少し潮目が変わってきた感覚があります。
BIも業務で構築する立場としては、標準的なBIレポートとこのように非定型な分析がリアルタイムでできるアプリとのバランスを考えていく必要があるなと感じました。
ここまで来るとレポートも出して欲しいなと思ってたので、「HTMLで資料化して」と指示してみると、HTML形式での資料化までその場でやってくれます。
↓ 生成された資料
実際のHTMLも貼っておきますので、興味ある方は自分で触ってみて下さい(メモ帳に張り付けて、拡張子htmlで保存してブラウザで開けばグラフが触れます)。
店舗別・商品別売上分析レポート
概要
このレポートでは、全店舗の売上データを分析し、店舗別および商品別の売上傾向を可視化しています。
2024年2月の詳細分析と2024年1月から2025年4月までの時系列での売上推移を確認できます。
主な分析結果:
- 2024年2月の総売上額は389,500円
- 店舗別売上では、店舗Bが最も高く92,700円（約24%）
- 商品別売上では、商品Jが最も高く104,000円
- 上位3商品（J, I, H）で全体の約60%の売上を占める
- 店舗間の売上差は比較的小さいが、商品間の売上差は大きい
2024年2月: 店舗別・商品別売上分析
店舗別売上（円グラフ）
店舗
売上額
構成比
店舗B
92,700円
23.8%
店舗A
87,700円
22.5%
店舗D
70,500円
18.1%
店舗C
70,000円
18.0%
店舗E
68,600円
17.6%
合計
389,500円
100.0%
商品別売上（棒グラフ）
商品
売上額
構成比
商品J
104,000円
26.7%
商品I
67,500円
17.3%
商品H
61,600円
15.8%
商品G
49,000円
12.6%
商品F
35,400円
9.1%
商品E
32,000円
8.2%
商品D
23,600円
6.1%
商品C
6,300円
1.6%
商品B
5,400円
1.4%
商品A
4,700円
1.2%
合計
389,500円
100.0%
分析と考察:
2024年2月の売上分析では、店舗別の売上はほぼ均等に分布していますが、商品別では大きな偏りが見られます。
特に商品Jは全体の4分の1以上の売上を占めており、売上への貢献度が高い主力商品となっています。
一方で商品A、B、Cの売上は非常に低く、これらの商品の販売戦略の見直しや、
あるいは商品ラインナップからの削除を検討する必要があるかもしれません。
店舗別月別売上推移 (2024年1月〜2025年4月)
トレンド分析:
時系列データからは、各店舗の売上に季節変動が見られます。特に注目すべき点として、
2025年3月に店舗BとAで大幅な売上増加が見られます。これは季節要因や特別なプロモーション、
あるいは特定商品の需要増加などが影響している可能性があります。
一方で、店舗Cは2025年3月と4月に売上が大きく落ち込んでおり、原因調査が必要かもしれません。
結論と推奨事項
-
商品ポートフォリオの最適化:
売上貢献度が低い商品A、B、Cの販売戦略を見直し、主力商品へのリソース集中を検討する。
-
店舗間の知見共有:
売上が好調な店舗の販売手法や顧客対応を他店舗と共有し、グループ全体の売上向上を図る。
-
季節変動への対応:
売上が落ち込む時期に向けた販促キャンペーンの計画や、繁忙期に向けた在庫・人員配置の最適化を行う。
-
データ分析の継続:
月次での売上分析を継続し、トレンドの変化に素早く対応できる体制を整える。
個人的な感想
業務的なインパクト
こちらについてはもはやMCPとは関係ないのですが、DX・BPRをずっとやってきた立場としては、AIによって以下3つが高精度かつシームレスに繋がるようになった事の破壊力がとてつもないなと思っています。
① TextToSQL
② 動的グラフ生成
③ HTML出力
TextToSQLによって、ユーザー側のSQLの知識が実質不要になり、データベースと自然言語で会話できるようになりました。
もはや誰もがSQLに長けたデータサイエンスのスペシャリストとペアで仕事ができる状態になるので、データ利活用の民主化によるデータドリブンが一気に進む可能性を秘めています。
そもそもデータサイエンティストでさえ、複雑なクエリを自分で作りたいと思う人はいないはずなので(ソフトウェアエンジニアとコーディングの関係)、データサイエンティストの仕事も捗るでしょう。
一方、TextToSQL単体だと、あくまでCSVやテーブルを返すだけなので片手落ち感があったのですが、分析用のグラフをその場で生成してインタラクティブな操作もできるとなると、更に裾野も広くなるのではないかと思います。
Code Interpreterが最初出てきた時も衝撃でしたが、Claude DesktopのArtifactのレベルだと「実務で使いたい！」とおそらくほとんどの人が思うのではないでしょうか。
私自身、Code Interpreterの時のデモと今回のデモを実施した際のユーザーのリアクションが明らかに異なる事を感じており、業務ユーザーでの利用普及におけるUXの壁を越えてきたという感覚があります。
このレベルであれば、今後は管理職や役員のようなクラスでも「このデータ出しておいて」と部下に指示するより、自分でやったほうが早いとなるケースも増えてくるのではないでしょうか。
そして、以前コンサルファームに所属していた事もあり「資料＝パワポ」という意識に引っ張られていたのですが、そもそもAIはパワポよりHTMLのほうが作成も編集も圧倒的に得意なので、HTMLを資料としてそのまま使っても良いかもしれません。
MS Copilotの非常に簡素なパワポ資料に比べ、GensparkがHTMLでかなり良い資料を生成している事からもこれは明らかで、今後は社内資料がパワポベースからHTMLベースになるという企業もどんどん増えてくるのではないでしょうか。
綺麗なパワポが作れるツールもまたおそらく出てくるようになるとは思いますが、そもそもパワポにこだわる必要もないので、HTML+PDF出力が主体になっていくような気もします。
そしてこれらの機能が今まで個別だったものの、「データ取得」→「グラフ化+分析」→「資料化」がインタラクティブかつシームレスに繋がるUXになってきた上に、これを推論モデルでやる事で更に拡張できるようになります。
いわゆる自動化というより、自動化拡張のような形で、おそらく個人レベルでは出しえない様々な角度でのクエリや分析、レポーティングなどを考えてくれるので、単なる自動化・効率化に留まらない威力を持ちます。
むしろ中途半端に細かい指示を出すとAIの分析スコープが狭くなるおそれがあるので、抽象度高めに依頼するほうが推論モデルの実力が発揮されやすいかもしれません (優秀な部下をマイクロマネジするとむしろ生産性が下がるイメージ)。
また今回はBigQueryだけですが、MCPで様々なツールと容易に連携できるようになると、各種公開情報やトレンドデータなどの社外情報も組み合わせた包括的な分析・レポーティングができるようになるでしょう。
もはや自動化タスクとして、日次/週次/月次分析レポートの資料化までAIに任せてしまって、それをベースに社内でディスカッションとなる未来がそう遠くない気がします。
ここで1つ注意が必要なのは、今後はおそらく「AIを使いこなせるか」というより「データがAIの手が届く範囲にあるか(データ基盤が整っているか)」というイシューのほうが大きくなってくるという点です。
AIがコモディティ化し、推論モデルがあれこれやってくれる世界線においては、「非常に優秀なAIエンジニア×データが散在している組織」と「そこそこのAIエンジニア×データが整備された組織」であれば、圧倒的に後者が強くなります。
AIで最近は話題がもちきりですが、実際のところ、本当に投資すべきはAI以上にデータ基盤の整備・構築になるでしょう。
生成AIの登場によってDXのフェーズが明らかに変わった感があるものの、実際のところ、これまでDXを真面目にやってきた企業が更に加速できるという状態になっています。
少なくとも、優秀なAIエンジニアだけ採用すれば何とかなるという話ではないので注意が必要です。
技術的な話
おそらく非エンジニアの人達のほとんどがまだ勘違いしていると思いますが、MCPで機能的にできる事が特に増えたわけではなく、FunctionCallingを含めこれまでもそもそもできていた事が標準化された、つまり、やりやすくなっただけといえばそれだけという形になります。
元々AIエージェントの構築周りをやっていた人は、「これ何が嬉しいの？(何でこんなに騒がれてるの？？)」と感じた人も少なくなかったのではないかと思います。
私も元々BigQueryとTextToSQLで会話するAIエージェントをFunctionCallingで作っていたので、BigQueryのMCPを最初見た時「え、これだけ？」と驚きました。
最初「MCPはUSB-C」というアナロジーが今一つ腑に落ちなかったのですが、USB-Cに標準化される前もそれぞれの規格で充電はできていたものの、USB-Cで充電が楽になったのは確かなので、ある種上手い表現なのかもしれません。
個別アプリの作り込みという観点で言えば、標準的なMCPを使った場合のレスポンスの処理はアプリ側で書く必要があるので、それならばMCPサーバーを自分で立てようという話に結局なりそうな上に、そもそも自分しか使わないならMCP化する意味もあまりないので、そのまま書く方が良いのでは？という形になる気がします。
利用できるものはなるべく活用していきたく、今後のエコシステム化の恩恵と進化は楽しみですが、特化型のケースで言えば、何が何でもMCPかというと、ラッパー処理を書くコストがむしろ高くつく上にレスポンスが遅くなるというケースが少なくない気もするので、今の所はあくまで標準化+公開観点の用途という意識は持っておく必要がありそうです。
既に社内で構築・リリース済みのAIアプリケーションに対して「これもMCP化しよう！」と言うのは明らかに間違いで、とりあえずMCP化すると何かパワーアップするという訳ではありません。
一つありそうだなと思ったのは、社内DWH構築の際にMCPサーバーも構築側がセットで用意してあげるという形です。
毎回AIエージェントがデータベースの一覧取得やスキーマ検索をやるのも遅い上に、データの意味的な情報や社内用語などの情報はどうしても落ちるので、その辺りの情報やナレッジをMCPサーバー側に上手く組み込んで公開すれば(抽象化してツールとして公開すれば)、DWHを利用したAIエージェントの構築と利用効率がかなり上がるような気がします。
こうなるとBIレポートもコードベースのものから、AIへの指示プロンプトとして管理・修正される形になっていくかもしれません(業務ユーザー側で即時修正できるようになる)。
まとめ
いかがだったでしょうか。
MCPに関しては使える所では利便性が非常に高いものの、魔法のツールというわけではないので、適材適所で使いどころを見極めていくべきだと思います。
また、今回はアプリケーションとしての可能性の視点でしたが、まだまだ未成熟な領域であり、原理上のセキュリティリスクについても様々な指摘があるため、サンドボックス環境でまずは試すのが良いでしょう。
ただMCPを使うとモデルやライブラリのスイッチは非常に楽になる上、各AIエージェントからの利用が多い社内システムやデータベースについては、ナレッジも含めMCP化しておくと、各所でのAI利活用促進に大きく寄与するかもしれません。
これまでの個別タスクの自動化が、MCPの登場も含め、どんどんE2E(End-to-End)の方向に向かっていくのが楽しみです。
Views: 0
