※この記事は2026年2月時点でのn8nに基づいて作成されています。
n8nで「自然言語 → SQL → DB検索」を作ろうとして
AI Agent → MCP → MySQL の構成を試したら
思った以上にドツボったので記録を残しておきます。
やりたかったこと
n8nで AI Agent → MCP → MySQL を接続し、以下のような DB検索AIエージェント を構築すること。
ユーザーからの自然言語の質問
↓
AIがスキーマを解釈してSQL生成
↓
MCP経由でDB検索を実行
↓
結果をユーザーに返す
しかし、いざ作ってみると数々の壁にぶち当たることになります……。
遭遇した4つの罠
困ったこと①：AIが存在しないテーブルやカラムを捏造する
AIはスキーマ情報を与えても完全には従わない
っていうか、普通に
- 存在しないカラム
- 存在しないテーブル
を作る。
AIあるある。
対策
テーブル定義書をJSON形式に整形し、システムプロンプト（またはコンテキスト）としてAIに直接注入。これで打率はかなりマシになりました。
困ったこと②：SQLを生成するだけで、満足して終了する
なんとか正しいSQLを作ることには成功したものの、今度はMCPツールを実行してくれない現象が発生。
AI「SQLできました！ `SELECT * FROM users...` です！（ドヤ」
（ここでプロセス終了。DBへは投げない）
AIエージェントは 「手元にツールがあっても、必ず呼び出すとは限らない」 という盲点がありました。
対策
プロンプトに 「SQL生成後は、必ず Execute a SQL query in MySQL ツールを呼び出して実行結果を取得すること」 と、行動を強く縛る明示的な指示を追加。
困ったこと③：地味にめんどくさい「MCP Server Trigger」の仕様
n8nでMCP Serverを構築（または接続）する際、挙動確認のために毎回手動で 「Execute workflow」 を押して待機状態にする必要がある。
テスト用のWebhook URLなども1回呼び出すと無効になるため、開発のデバッグループが非常に回しづらいのが地味にストレス。
困ったこと④（最大の難関）：「MCP Client Tool」が1回しか動かない
n8n の MCP Client Tool は、1トランザクション型ツール。
つまり、「1回目のSQLを実行した結果、データが足りないからもう1回別のSQLを投げたい（Self-Correction）」と思っても、同じセッション内で再度MCPツールを呼び出すことがシステム的にできません。AIの思考の試行錯誤（ループ）と相性が悪かったのです。
試しにMCPをやめてみた。
「これ、べつにMCP挟まなくてもよくない…？」と思って、構成を
AI Agent → MySQL Tool（n8n標準） に変更。
結果、快適 of 快適！！
- 待機不要：Workflowを常に動かしておける
- SOP（縛り指示）不要：プロンプトの引き延ばしや無理な強制が不要に
- 構成簡単：シンプル is ベスト
- レスポンスが速い：余計なオーバーヘッドがない
なんや、MCPって必須やなかったんか。
結論：MCPは必須ではなかった。
今回のSQL検索AIではMCPは不要でした。
ただし「AI Agentを作るならMCPが必要」と言われることも多いです。
MCP自体は非常に優れた規格なので、今回の経験から、MCPを使うべきか直結でいいかの境界線を整理しました。
MCPを導入すべきケース（複雑な構成）
- 複数ツールを横断して連携する
- n8nに標準ツールがない、独自の内部APIをAIに連携させる必要がある
- 外部サービス側の認証情報（APIキーなど）をMCPサーバー側で一元管理してセキュリティを高めたい
直接ツール接続でOKなケース（シンプルな構成）
- 特定の1つのツール（例：MySQL、Slack）しか扱わない
- AIが複雑な思考（ループや自己修正）を必要としない、単純なタスク
- 速度と開発体験（DX）を最優先したい
n8nでの実装には現時点でまだセッション管理などの制約があるため、作ろうとしているセッションの複雑さを勘案して選択するといいでしょう。
おまけ
最近、n8nを外部AIから操作する「n8n MCP Server」側は自己修復ループに対応するアップデートが入りましたが、今回の構成である「n8nの内部からMCPを呼び出す（MCP Client Tool）」側の1トランザクション制限は依然として健在です。
そのため、「シンプルなDB操作なら標準ツール直結が正解」という結論は、現時点でも変わりません。