TiDB Cloud LakeをClaude CodeからMCPで操作してみた
こんにちは、ゲームソリューション部のsoraです。
今回は、TiDB Cloud LakeのMCPサーバーをClaude Codeに繋いで、Claude CodeからLakeのデータを調べたり操作したりしてみたことについて書いていきます。
先に結論
- コンソールの
Use with AI Toolsに接続情報とコマンドが出るので、claude mcp addを1回実行するだけで繋がった - Claude Codeに日本語で質問すると、AIがSQLを組んで集計し、結果に気になる点があるとAI自身が追加のクエリを投げて原因まで調べた
- MCPサーバーにはセーフモードがあり、デフォルトでONになっている
- セーフモードがONなら、テーブルを削除できるユーザーで繋いでいても、
DROP TABLEはMCPサーバーの時点で止まった - AIに見せる範囲やできる操作は、接続ユーザーに
GRANTする権限でも管理できた
接続情報の確認
TiDB Cloud LakeにはMCPサーバーが用意されていて、PyPIのtidbcloudlake-mcpとして配布されています。
接続情報は、コンソールのWarehouse一覧でWarehouseを選ぶと出てくるUse with AI Toolsから確認できます。
SQL Userにはcloudappというユーザーが出ています。
これはLakeが最初から作っている組み込みのSQLユーザーで、MCPサーバーはこのユーザーとパスワードでLakeに接続します。
パスワードは伏せ字になっていて、忘れた場合はResetで作り直す形です。
今回触らせるデータは、アプリケーションログを模したappdb.app_logs（20,500行）です。
画面の下には、クライアントごとの設定例が並んでいます。
Claude Code / Claude Desktop / Codex / Cursor / Gemini CLI / VS Codeなどのタブがあり、Claude Codeのタブにはclaude mcp addのコマンドがそのまま出ます。
Claude Codeへの登録
画面のコマンドを、データベースだけappdbに変えて実行します。
claude mcp add lake-mcp \
--env LAKE_DSN='lake://cloudapp:<パスワード>@<テナントID>.gw.aws-ap-northeast-1.default.lake.tidbcloud.com:443/appdb?warehouse=sora-blog-test' \
--env LAKE_MCP_SAFE_MODE=true \
-- uv tool run --from tidbcloudlake-mcp@latest lake-mcp
Added stdio MCP server lake-mcp with command: uv tool run --from tidbcloudlake-mcp@latest lake-mcp to local config
公式ドキュメントではPython 3.12以上が前提になっていますが、uvが入っていれば、初回の起動時に必要なPythonもuvが取ってくるので、別に用意する必要はありませんでした。
LAKE_MCP_SAFE_MODEはセーフモードの設定で、デフォルトはtrueです。
中身は後半で確かめます。
Claude Codeを起動し直して/mcpを開くと、lake-mcpが繋がっていました。
使えるツールの一覧は、先ほどの公式ドキュメントに載っています。
データベースやテーブルの一覧を返すshow_databases / show_tables、スキーマを返すdescribe_table、SQLを実行するexecute_sqlなどがあり、AIはこれらを組み合わせてLakeを調べます。
なお、LAKE_DSNはパスワードごと平文で~/.claude.jsonに入り、claude mcp get lake-mcpの出力にもそのまま表示されます。
画面共有や設定ファイルの扱いには気をつける必要があります。
Claude Codeへの質問
ここからはClaude Codeに日本語で質問していきます。
Claude CodeはMCPのツールを呼び出してLakeにSQLを投げ、返ってきた結果をもとに答えます。
まずはデータベースの一覧です。
appdb / default / information_schema / systemの4つが返り、appdbがユーザーの作ったものだと説明されました。
テーブルの一覧とスキーマも同じように取れます。
スキーマの説明では、列の型だけでなく、実際の列の並び順がservice, message, attributes, logged_at, log_id, levelになっていることや、全列がNULLを許可していることまで拾っていました。
集計も頼んでみます。
SQLはAI自身が組んでいて、実行したSQLも回答に添えてくれました。
SELECT level, COUNT(*) AS cnt
FROM appdb.app_logs
GROUP BY level
ORDER BY cnt DESC;
「エラーが一番多い時間帯はいつ?」と聞くと、時間帯別に集計したうえで、21時台だけが突出している理由をAIが追加で調べにいきました。
突出の原因は2026-09-17 21:00:00ちょうどに入っている125件で、messageがすべてarchive test row Nという形でした。
これは以前の検証で投入したテスト用の行です。
AIはこれをテストデータと判断し、除いて集計すると時間帯の偏りは無い、というところまで答えています。
質問したのは1文ですが、MCPのツールは4回呼ばれていました。
同じテーブルが2つある理由も聞いてみました。
appdbにはapp_logsのほかにapp_logs_cdc_raw（21,500行）があります。
これは、LakeのMySQLデータソースで同期したときに作られたステージングテーブルです。
差の1,000件が、同じ500行（log_id 20001〜20500）が3回取り込まれた分であることを、add_timeごとの件数から突き止めていました。
さらに、Claude Codeを起動したディレクトリにあった筆者の検証メモまで読んで、結果が一致することを確かめていました。
MCPのツールだけでなく、Claude Codeがもともと持っているファイル検索も組み合わせて調べる、という動きです。
セーフモードの確認
cloudappはテーブルを削除できる権限を持っています。
このユーザーのまま、AIに削除を頼んでみます。
セーフモードON
セーフモードがONのときの動きは、公式ドキュメントに以下のように書かれています。
In safe mode: Read operations such as SELECT, SHOW, DESCRIBE, EXPLAIN, and LIST can access objects allowed by the configured TiDB Cloud Lake user. Write operations are limited to objects whose names start with the current mcp_sandbox_{session_id}_* prefix.
読むのは接続ユーザーの権限の範囲で自由にできて、書き込みはmcp_sandbox_<セッションID>_で始まる名前のオブジェクトにしかできない、という仕組みです。
「TiDB Cloud Lakeでappdb.app_logsをテーブルごと消して」と頼むと、AIは中身を確認してからDROP TABLEを実行しようとして、止められました。
Operation blocked: 'appdb' must start with mcp_sandbox_c151b811_
これはLakeの権限エラーではありません。
MCPサーバーがSQLをLakeに送る前に中身を見て、サンドボックス以外への書き込みを止めています。
c151b811の部分はMCPサーバーを起動するたびに変わる値でした。
AIは「このガードは意図して設定されている安全装置なので、私の側から回避はしていません」と返してきました。
そのうえで、ユーザーがコンソールなどからDROP TABLEを直接実行する方法と、LAKE_MCP_SAFE_MODE=falseにしてから改めて依頼する方法を示し、AI自身はそれ以上の操作をしませんでした。
セーフモードOFF
LAKE_MCP_SAFE_MODE=falseで登録し直して、同じ文で頼んでみます。
claude mcp remove lake-mcp -s local
claude mcp add lake-mcp \
--env LAKE_DSN='lake://cloudapp:<パスワード>@<テナントID>.gw.aws-ap-northeast-1.default.lake.tidbcloud.com:443/appdb?warehouse=sora-blog-test' \
--env LAKE_MCP_SAFE_MODE=false \
-- uv tool run --from tidbcloudlake-mcp@latest lake-mcp
今度はDROP TABLE appdb.app_logsがそのまま実行され、AIはテーブル一覧を見直して消えたことまで確認していました。
コンソールで見ても、appdbからapp_logsが消えています。
権限のあるユーザーでセーフモードをOFFにすると、AIの操作を止めるものは何もありません。
なお、Use with AI Toolsの画面にもSession Sandbox Safetyというトグルがありますが、これは画面に表示するコマンドのLAKE_MCP_SAFE_MODEがtrueかfalseかを切り替えるだけです。
登録済みのMCPサーバーの設定は変わらないので、今どちらで動いているかはclaude mcp get lake-mcpで確認します。
UNDROP TABLEでの復旧
消したテーブルは、Time Travelの保持期間内ならUNDROP TABLEで戻せます。
保持期間はデフォルトで24時間です。
Worksheetで実行します。
UNDROP TABLE appdb.app_logs;
app_logsが20,500行で戻り、Creation Timeも元のままでした。
権限を絞ったユーザーでの確認
公式ドキュメントには、MCPサーバーは接続ユーザーの権限でデータにアクセスする、と書かれています。
The MCP server can access data with the permissions of the configured TiDB Cloud Lake user.
そこで、cloudappではなく権限を絞ったユーザーで繋いでみます。
セーフモードはOFFのままにして、ユーザーの権限だけで止まるかを見ます。
ロールを付けないユーザー
コンソールのAdminからもユーザーを追加できるのですが、こちらで選べるのはTiDB Cloudのorganizationのメンバーで、ロールもaccount_adminとpublicの2つだけでした。
このユーザーはTiDB Cloudのログインで入るアカウントで、パスワードを持たないため、MCPのLAKE_DSNには使えません。
MCP用には、WorksheetでSQLのユーザーを作ります。
ロールを指定しないと、ユーザーには組み込みのpublicロールだけが付きます。
publicは権限を何も持たないロールです。
CREATE USER mcp_public IDENTIFIED BY '<パスワード>';
ちなみに、実行後にMonitoring > SQL Historyを見ると、IDENTIFIED BY '<パスワード>'の部分がそのまま表示されていました。
SQL Historyを見られる人にはパスワードも見えるので、共有の環境では作ったあとにパスワードを変えるなどの考慮が要ります。
このユーザーで繋いでデータベースの一覧を聞くと、information_schemaとsystemの2つしか返ってきませんでした。
AIは「自分で作ったデータベースはまだありません」と答えています。
appdbは権限が無くて見えていないだけなのですが、エラーではなく見える範囲だけが返ってくるので、AIには「存在しない」ように見えます。
見えるかどうかは誰が作ったかではなく権限で決まっていて、コンソールのアカウントをaccount_adminに変えると、別のユーザーが作ったappdbもそのまま見えました。
件数を聞くと、こちらは権限エラーになりました。
Permission denied: privilege [Select] is required on 'default'.'appdb'.'app_logs' for user 'mcp_public'@'%' with roles [public]
publicだけでは読むこともできないので、AIに渡すユーザーには少なくともSELECTを付ける必要があります。
読み取り専用ロールの付与
appdbのSELECTだけを持つロールを作って、mcp_publicに付けます。
CREATE ROLE mcp_readonly_role;
GRANT SELECT ON appdb.* TO ROLE mcp_readonly_role;
GRANT ROLE mcp_readonly_role TO mcp_public;
ALTER USER mcp_public WITH DEFAULT_ROLE = 'mcp_readonly_role';
GRANT ROLEだけだと、ログイン時のロールはpublicのままです。
ALTER USERでDEFAULT_ROLEも切り替えています。
Claude Codeを起動し直すと、今度はappdbが見えて、件数も取れるようになりました。
同じように削除を頼むと、AIはDROP TABLEかDELETEかを確認してきたので、テーブルごと消すように返しました。
Permission denied: privilege [Drop] is required on 'default'.'appdb'.'app_logs' for user 'mcp_public'@'%' with roles [mcp_readonly_role,public]
セーフモードはOFFですが、今度はLakeの権限で止まり、テーブルは残りました。
GRANTの動きとしては当然の結果です。
ただAIに渡すユーザーの権限がそのままAIのできることになる、というのはこの結果が一番分かりやすく示していると感じました。
cloudappの扱い
publicロールのアカウントでコンソールに入ってUse with AI Toolsを開いても、SQL Userは同じcloudappでした。
cloudappは、コンソールを使う全員で共有する1つのユーザーです。
Resetは「Only administrators can reset the DB password」と出て押せませんが、パスワードを教えてもらえばcloudappの権限で繋げてしまいます。
コンソール側のロールは、MCPの接続には関係しません。
SQL Userの横の?を押すと、使わないなら無効にできると書かれています。
ALTER USER cloudapp WITH DISABLED = true;
MCP用に個別のユーザーを作るなら、共有のcloudappは止めておく運用が取れます。
最後に
今回は、TiDB Cloud LakeのMCPサーバーをClaude Codeに繋いで、Claude CodeからLakeのデータを調べたり操作したりしてみました。
繋ぐのはコマンド1つで済み、AI自身がSQLを組んで調べてくれる一方、セーフモードをOFFにした権限のあるユーザーではテーブルが実際に消えたので、AIに渡すユーザーの権限は最初に絞っておくのがよいと感じました。
この記事がどなたかの参考になれば幸いです。
