もともと私の手元には、自分のサーバー上のデータベースにPythonで接続するモジュールがありました、ただこれが古いライブラリ前提で作られていて、最新の環境に上げようとすると動かない、という状態でずっと固まっていたんです
どうせ作り直すなら、ただの接続モジュールに戻すのはもったいない、せっかくなら Claudeから直接データベースを覗ける道具にしてしまえば便利なのでは? と思いついたのがきっかけでした
その「道具」がMCPサーバーと呼ばれるものになります、この記事では Claude Codeに伴走してもらいながら、自分専用のMCPサーバーを設計から公開まで作った体験を、コードの深い話は抜きにして広めに書いていきます
先に結論を言うと、プログラムをゴリゴリ書ける人でなくても、自分専用の道具は作れます、Claudeに設計から相談して、実装もレビューも任せて、最後に自分が確認するだけで形になりました
ジャベ雄「自作」って聞くと身構えちゃうけど、やってることの大半は日本語の相談なんですよね
Claude Codeの拡張機構の全体像はClaude Codeの拡張機構入門の記事、AI周辺の用語はAI用語集でまとめているので、言葉でつまずいたらそちらも合わせてどうぞ
そもそもMCPって何 Claudeに道具を持たせる仕組み
まず言葉の整理から、MCP(エムシーピー)はClaudeに「外部の道具」を持たせるための拡張の仕組みの1つです
Claudeはそのままだと、賢く文章を考えたり相談に乗ったりはできても、「私のサーバーにあるデータベースを読んできて」みたいな手元の操作はできません、本体に手足が付いていないイメージです
そこで 道具(=MCPサーバー)を外付けしてあげると、Claudeが単体ではできない操作を、その道具を介してできるようになります、今回私が作ったのは「自分のサーバーのデータベースを読む道具」です
これをClaudeに登録しておくと、あとは日本語で 「このテーブルから昨日のデータを出して」と頼むだけで、Claudeが裏でデータベースへの問い合わせ(SQLという命令文)を組み立てて、結果を返してくれます



SQLを自分で書かなくていいの、ここが地味にうれしいんですよ
MCPはClaude Codeの拡張機構(Skills・Agents・MCP・Hooks)の中の1つです、4つの違いや全体像は別記事にまとめているので、ざっくり地図がほしい方は拡張機構入門から読むと迷いません
なぜ既製品でなく自作だったのか
ここで疑問が出ると思います、データベース用のMCPなんて世の中にすでにあるのに、なぜわざわざ自分で作ったのか? という話です
結論から言うと、既製品が私のサーバー環境にそのままでは繋がらなかったからです、この接続の壁が今回いちばんの分かれ道でした
実は最初、私は「わざわざ作らなくても、既にあるものを入れれば一発でしょ」と軽く考えていました、ところがいざ繋ごうとすると、データベースの接続情報を正しく入れているのに、どうやっても弾かれてしまう、ここで「あれ、これ普通のやり方では届かないやつだ」と気づいたわけです
Xserverは「二段構え」でつなぐ必要がある
私が使っているレンタルサーバー(Xserver)は、データベースに直接つなぐのではなく、いったん別のサーバーに安全な経路でログインしてから、その先のデータベースへ繋ぐという二段構えが前提になっています
この「安全な経路を一本通してから、その中を通ってつなぐ」やり方を SSHトンネルと呼びます、外から直接データベースを叩けないようにする、セキュリティ上ありがたい仕組みなんですが、繋ぐ側からするとひと手間多いわけです
玄関(別のサーバー)で本人確認をしてから、建物の中の鍵付き通路を通って奥の部屋(データベース)に入るイメージです、玄関を通らずに奥へは入れない作りなので、外部からの直アクセスを防げます
一般的なデータベース用のMCPは、この SSHトンネルの機能を持っていません、だからXserverのような二段構えのサーバーには、既製品をそのまま当ててもつながらないんです
既製品は「参考にはするけど、そのままでは私の用途を満たさない」、これが自作に踏み切った理由になります、自分の環境にぴったり合う道具がないなら、作ってしまえばいいという発想です
Claude Codeに全工程を伴走させた流れ
ここからが記事の本題です、私は今回 「バイブコーディング」的に、ほぼ全工程をClaude Codeに伴走させて作りました、ノリと相談で進めていく感じの作り方ですね
AIでアプリを作る体験そのものについてはAIでアプリ開発に挑戦した体験記でも書いているので、雰囲気が気になる方はそちらも、ここでは「道具(MCP)を作るときの流れ」に絞ります
大きく分けると、壁打ち → 設計 → タスクごとに実装 → 最終レビュー → 公開という5ステップで進みました
いきなり書かせるのではなく、まずClaudeとブレスト(壁打ち)して方針を詰めました、出てきた答えは「ただの接続モジュールでなくMCPサーバーにする」「読み取り専用を基本にする」「古いライブラリをやめて、今も保守されているものを使う」の3つです
方針が固まったら、Claudeが設計の仕様と実装の段取り(やることリスト)を文書に起こしてくれました、私がやったのは中身を読んで「これでいきましょう」とOKを出すことだけです
機能を1つずつに分けて、実装する役のAIとチェックする役のAIを別々に立てて進めました、しかも先にテスト(動作確認の仕掛け)を書いてから本体を作る進め方で、1機能ごとにお互いレビューさせています
全機能ができたあと、仕上げにもう一度だけ全体を厳しめにレビューさせました、ここで思わぬ抜け穴が見つかるんですが、その話は次の章でじっくり書きます
完成したものは自分専用のリポジトリ(コードの保管場所、私は非公開で用意しました)にまとめて、Claudeに道具として登録、これで実際に使える状態になりました
「先にテストを書く」ってどういうこと
STEP3で「先にテストを書いてから本体を作る」と書きました、これは TDD(テスト駆動開発)という作り方で、ざっくり言うと「合格ラインを先に決めてから中身を作る」やり方です
料理で言えば、完成形の味見の基準を先に決めておいて、その基準を満たすように作る感じですね、こうすると 作ったものが意図どおり動いているかを毎回その場で確認できるので、後からのやり直しが減ります
大事なのは、この段取り自体もClaudeが提案して進めてくれた点です、私が「TDDでやって」と細かく仕切ったわけではなく、相談する中で自然とこの形に落ち着きました



「実装する人」と「チェックする人」を分ける、これ人間のチーム開発と同じ発想なんですよね
最終レビューで「自分のバグ」が見つかった話
この章の話が今回いちばん学びになりました、各タスクのレビューはちゃんと通していたのに、最後の全体レビューで実際のバグが1つ見つかりました
中身を平たく言うと、読み取り専用のはずなのに、ある特殊な書き方をすると書き込み命令が通ってしまう抜け穴でした、「読むだけ」を守らせていたつもりが、すり抜ける経路が残っていたんです
怖いのは、これが 各機能ごとの個別レビューを全部すり抜けていた点です、1つひとつの機能を見ているときには気づけず、全体を改めて厳しい目で見直したときに初めて浮かび上がってきました
AIに作らせるときも「作る人」と「チェックする人」を分けると質が上がります、1人(1つのAI)で書いてそのまま完結させず、別の視点でレビューを挟む、ここが今回いちばんの収穫でした
見つかったあとの流れはシンプルで、指摘 → 修正 → 再レビューでその抜け穴を塞ぎました、ここでもやっているのは「Claudeに直してもらって、もう一度別の目で確認する」という同じ進め方です
AIは賢いんですが、万能で無謬というわけではありません、だからこそ 作る工程とチェックする工程を分けて、最後に全体を見直す、この一手間が安心につながると実感しました
AIにデータベースを触らせるときの安全設計
今のバグの話とつながりますが、AIにデータベースを触らせるなら、安全側に倒した設計が要ります、ここは自作する人だけでなく、既製のMCPを使う人にも役立つ考え方なので少し丁寧に書きます
基本は「読み取り専用」にしておく
私が決めたのは 既定で「読むだけ」にするという方針でした、AIにデータベースを任せるとき、いちばん怖いのはうっかりデータを書き換えられたり消されたりすることです
だから道具の側で「ふだんは読むだけ、書き込みは明示的にスイッチを入れたときだけ許可する」という作りにしました、自分でも「今は書き込みOKにしているぞ」と意識しないと書けない、という ブレーキです
本当の安全弁はデータベース側にある
ただ、ここで大事な考え方があります、道具(アプリ)側のチェックは第一の防御線にすぎません
さっきのバグのように、アプリ側の「読むだけ」設定はすり抜ける経路が残っていることがあります、だから 本当の安全弁は、データベース側に「読み取りしかできない利用者」を用意することです
つまり、そもそも書き込み権限を持たないアカウントで繋いでおけば、仮にアプリ側のチェックを抜けても、データベースが「あなたには書き込み権限がありません」と弾いてくれます、二重のブレーキです
考え方としてはこうです、データベースには、つなぐための利用者(アカウント)を何種類か作れます、ふだんアプリやサーバーの管理に使うのは強い権限を持った利用者ですが、AIに渡すのは「読むことしかできない利用者」を別に1つ用意して、そちらだけを使わせるのが安心です
こうしておくと、構造はとてもシンプルになります、アプリ側の「読むだけ」設定が 第一の防御線、その奥でデータベース側の読み取り専用の利用者が 最後の安全弁として控える、という形です、手前のチェックがうっかり抜けても、いちばん奥で物理的に書き込めない、この奥行きが効いてきます
手順の細かい話は環境ごとに変わるので踏み込みませんが、方針として覚えておきたいのは 「アプリで頑張る」より「権限を持たせない」ほうが強いという一点です、できないように作ってあれば、そもそも事故が起きようがありません、ここは私自身が今回のバグで痛感したところでもあります
「アプリ側でチェックしているから大丈夫」と思い込まないことです、権限はできるだけ大本(データベースやサーバー)の側で絞っておくのが安全の基本になります、これはAIに限らずどんな自動化でも効く考え方です
使った道具は「最新の保守されたもの」だけ
技術の中身には深入りしませんが、1点だけ、今回 古い(メンテが止まった)接続方式をやめて、今も保守されている方式に乗り換えられたのは大きな前進でした
使ったのは3つで、安全な経路(SSH)を扱う asyncssh、データベースとやり取りする aiomysql、Claudeと話す土台になる FastMCP、それぞれ「SSHを扱う道具」「データベースを扱う道具」「MCPを作る土台」くらいの理解で十分です
名前を覚える必要はありません、ポイントは 今も更新が続いているライブラリだけで動くようにできたこと、古いものに縛られて身動きが取れなかった状態から解放されたのが、地味にいちばん嬉しかったところです
実際に使ってみたらこうなった
道具が完成して、Claudeに登録したあと、さっそく試してみました、頼み方はいたってシンプルで、日本語で「このテーブルから昨日ぶんのデータを抽出して」とお願いするだけです
するとClaudeが裏で問い合わせ(SQL)を自分で組み立てて、結果を返してくれました、私はSQLを1行も書いていません、それでも自分がためているデータがちゃんと取れて、試したときは千件を超える実データが返ってきました



自分のデータに話しかけて答えが返ってくる感じ、ちょっと未来っぽくて楽しいんですよ
これで 自分専用の「自分のサーバーのデータベースをClaudeから覗く道具」が手に入りました、欲しかったのはまさにこれです、既製品では届かなかった一歩を、自作で埋められたという達成感もありました
使ってみて地味に効いたのが、データの中身を確認するためにいちいち管理画面を開かなくてよくなったことです、これまでだと「あのデータどうなってたっけ」と思うたびにブラウザでログインして画面をたどっていました、それが今は、Claudeに一言聞けば返ってくる、この距離の近さが思った以上に快適でした
しかも返ってきた結果について「この中で件数が多い順に並べて」とか「先週ぶんと比べてどう?」みたいに、そのまま会話で深掘りできます、データを取り出す道具と、それを読み解く相手が同じ場所にいる、この一体感がふつうのデータベース管理ツールとはひと味違う使い心地でした
もう少し具体の流れを書いておくと、たとえば あるテーブルに対して「ここから昨日ぶんを出して」と日本語で頼むと、Claudeがその指示を読み取って、裏で問い合わせ(SQL)を自分で組み立てます、私が見ているのは「昨日ぶんを出して」という自分の文と、しばらくして返ってくる結果だけです、途中の命令文を意識しなくていいのが、思った以上に身軽でした
ひとつ注意があって、取り出す件数が多いと、既定の上限で途中まで返って打ち切られることがあります、千件を超える量を一気に頼むと、最初のいくらかが返ってきて「ここまでで止めています」という挙動になる感じですね、全部ほしいときは「もっと多く返して」と上限を上げてもらうか、条件を絞って小さく取り直します、いきなり全件をどっと返さない作りは、安全側に倒すうえでもむしろ都合がよかったです
登録自体は数行で済む
「道具を登録」と書くと身構えるかもしれませんが、Claude Codeに道具(MCPサーバー)を教えるのは設定ファイルへの数行の追記です、ファイル名は .mcp.json で、ここに「どの道具を、どう起動するか」を書きます
イメージとしてはこんな形で、サーバーの名前と起動コマンドを書くだけです(中身は環境ごとに変わります)
{
"mcpServers": {
"my-db-tool": {
"command": "(自作した道具を起動するコマンド)"
}
}
}この設定ファイルが何者なのか、ほかにどんな設定ファイルがあるのかはClaude Codeの設定ファイル早見表にまとめています、.mcp.json の置き場所や役割が気になったらそちらをどうぞ
そして設定ファイルを触るのが怖い人へ、ここも Claude自身に「.mcp.jsonにこの道具を登録して」と頼んで書かせるのが楽です、書いてもらった内容を自分で確認してから反映すれば、手で打ち間違える心配も減ります
コードを書けなくても自分専用の道具は作れる
最後にまとめます、今回いちばん伝えたいのは Claude Codeを使えば、設計から実装、レビュー、公開まで伴走してもらいながら、自分専用の道具(MCP)を作れるということです
振り返ると、私が手を動かしたのは「何を作るか相談する」「設計書を読んでOKを出す」「最後の確認をする」あたりで、実装そのものはほとんどClaudeに任せていました、それでもちゃんと動くものが手に入ります
- いきなり書かせず、まず壁打ちで「何を作るか」を言葉にする
- 設計と実装はClaudeに任せ、人間は読んで判断する側に回る
- 「作る役」と「チェックする役」を分け、最後に全体を見直す
- AIにデータを触らせるなら「読み取り専用」を基本に、権限は大本で絞る
- 設定ファイルが怖ければ、Claudeに書かせて内容を確認してから反映する
そして今回の出発点を思い出してほしいんですが、私が作ったのは「既製品が自分の環境に合わなかった」からでした、世の中にある道具が自分の環境にハマらないときこそ、自作の出番です
プログラムをゼロから書ける必要はありません、やりたいことを言葉にして、相談しながら一緒に作っていく、その伴走役としてClaude Codeは頼りになります、興味が出たら、まずは小さな「自分専用の道具」から試してみてはどうでしょうか?



「これ既製品じゃ届かないな」って思った瞬間が、自作のスタートラインなんですよね











コメント