水曜日, 4月 30, 2025
ホームニューステックニュースMCPでのデータベースとの対話+資料化 #Python - Qiita

MCPでのデータベースとの対話+資料化 #Python – Qiita



MCPでのデータベースとの対話+資料化 #Python - Qiita

はじめに

以前から話題になっていた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件のデータで、店舗別、商品別の売上情報を持っています。

image.png

このデータについては何も教えずに(MCPを繋いだだけの状態で)、Claudeからリクエストを投げてみます。

「店舗別、月別売上を時系列で表示して」とリクエストすると、データセット内のテーブルとデータ構造を確認し、必要なSQLクエリを自分で組み立てて実行します。更に、その結果を元にリアルタイムでグラフ生成まで行ってくれています。

image.png

要するに、データベースさえ繋いでしまえば、ユーザーの要望とデータ構造を元に必要なSQLを自分で作成・実行する能力を持ち、Reactのコードがはけるのでグラフ生成まで自在にできるという事です。

当然、以下のような円グラフ、棒グラフなどもお手のものです。

image.png

当然、裏側でコードを持っているので、「この色を変えて」「プルダウン選択を追加して」「グラフの縦軸を伸ばして」と言った指示も即座に対応してくれます。

TextToSQLの時は、テーブル構造やCSVのみ、Code Interpreterの時は画像のみといった感じであと一歩感がありましたが、MCP+アーティファクトにより、ノーコードでここまで来れるとなると、少し潮目が変わってきた感覚があります。

BIも業務で構築する立場としては、標準的なBIレポートとこのように非定型な分析がリアルタイムでできるアプリとのバランスを考えていく必要があるなと感じました。

ここまで来るとレポートも出して欲しいなと思ってたので、「HTMLで資料化して」と指示してみると、HTML形式での資料化までその場でやってくれます。

image.png

↓ 生成された資料

C__Users_wabud_Box_005_RPA%EF%BC%88DX%E3%80%81MJK%E3%80%81ABeam%EF%BC%89_BI_90_CoE%E6%A4%9C%E8%A8%8E_%E5%8F%82%E8%80%83_MCP-%E5%88%86%E6%9E%90%E3%83%AC%E3%83%9D%E3%83%BC%E3%83%88%E3%83%87%E3%83%A2.html (1).png

実際のHTMLも貼っておきますので、興味ある方は自分で触ってみて下さい(メモ帳に張り付けて、拡張子htmlで保存してブラウザで開けばグラフが触れます)。




  
  
  店舗別・商品別売上分析レポート
  
  

  
  


個人的な感想

業務的なインパクト

こちらについてはもはや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)の方向に向かっていくのが楽しみです。



フラッグシティパートナーズ海外不動産投資セミナー 【DMM FX】入金

Source link

Views: 0

RELATED ARTICLES

返事を書く

あなたのコメントを入力してください。
ここにあなたの名前を入力してください

- Advertisment -

Most Popular