MCPサーバーの自作は、コードが書けなくてもできた。Claude MCPの設定と、既製で済むかの判断基準

MCPサーバーを自作する話は、ほとんどがエンジニアの実装メモとして書かれています。私はコードを書けません。それでも、仕事で必要になった道具をひとつMCPサーバーとして自作して、いまも毎日使っています。書いたのは私ではなく、Claude Codeでした。日本語で「こういうことがしたい」と伝えて、動くまで付き合ってもらっただけです。既製のMCPを6つほど繋いだうえで、どうしても足りないものが1つ残ったので作った、という順番でした。MCPとは何かというところから、繋ぐと何がどう変わるか、足りないときにどうやって作らせたかまで、非エンジニアの側から書いていきます。

MCPとは、AIに自分の道具を持たせる仕組み

MCPは Model Context Protocol の略で、AIと外部のサービスをつなぐための共通の決まりごとです。2024年の終わりにAnthropicが公開した仕様で、いまはClaude以外のAIツールでも採用が広がっています。仕様そのものが公開されているので、特定の会社の製品というより、みんなで使える規格に近い立ち位置になりました。

言葉だけだと硬いので、繋ぐ前と後で何が違うかを書きます。チャットのAIは、基本的に会話の箱の中だけで生きています。調べ物を頼まれても自分では取りに行けないので、人間が画面を開いて、検索して、結果をコピーして、会話に貼ってあげる必要があります。返ってきた答えも会話の中にあるだけなので、貼り戻すのはまた人間です。運び屋が自分、という状態です。

MCPを繋ぐと、AIが自分でそのサービスを触りに行けるようになります。キーワードの検索数を調べる道具を繋いでおけば、「この語の検索数と難易度を出して」と言うだけで、AIが調べに行って表にして返してきます。私がやることは、頼むことと、返ってきたものを見ることだけになります。

用語を3つだけ整理しておきます。解説記事では真っ先に出てくるところですが、非エンジニアには境目が分かりにくい部分でもあります。

自作するのは一番下のMCPサーバーです。サーバーという名前がついていますが、どこかにサーバーを借りて置くという話ではなく、多くの場合は自分のパソコンの中で動く小さなプログラムを指します。私が作ったものも、自分のMacの中だけで動いています。

MCPサーバーがAIに渡せるものは、仕様上3種類あります。ツール（Tools）はAIが実行できる操作、リソース（Resources）はAIが読める情報、プロンプト（Prompts）は決まった頼み方のひな形です。実務で触っている感覚だと、ほとんどの場面で登場するのはツールでした。「何ができる道具なのか」がツールとして並んでいて、AIが必要なときにその中から選んで呼ぶ、という動き方をします。

実際に繋いでいる既製のMCPと、何が変わったか

自作の話に入る前に、既製のMCPの話を先にします。順番として、まず既にあるものを繋いでみないと、自分に何が足りないのかが分からないからです。私がいま常用しているのは次の6つです。

繋いでみて分かったのは、便利さの中身が「速くなる」ではなかったことです。手数はたしかに減りますが、いちばん大きかったのは頭の切り替えが要らなくなったことでした。画面を開いて、ログインして、条件を入れて、結果を見て、また戻ってくる。往復のたびに集中が細切れになっていたぶんが、丸ごと消えます。

もうひとつは、AIが自分で確かめられるようになった点です。文章を直したあとにブラウザで開いて見に行けるので、「たぶん大丈夫です」で終わらず、実際の画面を見たうえで報告が返ってきます。Claude Code そのものの入り方は非エンジニア向けのはじめ方の記事にまとめているので、まだ触ったことがない方は先にそちらを読むと流れがつかみやすいかもしれません。

Claude MCPの設定にかかる手間

設定ファイルの中身を見ると身構えますが、実際にやることは多くありません。公式が配布しているものなら、書き足すのは数行で済みます。

Claude Desktop の場合は、claude_desktop_config.json という設定用のファイルに「サーバーの名前」と「起動するコマンド」を書き足す形が基本です。最近は設定画面から追加できるものも増えてきました。Claude Code の場合は claude mcp add というコマンド1本で足せて、内容は .mcp.json というファイルに書き出されます。自分のパソコン全体で使うか、いま開いているフォルダの中だけで使うか、チームで共有するかを選べる作りになっているので、案件ごとに繋ぐ道具を変えることもできます。

手間がかかるのは、繋ぐ作業そのものより準備のほうでした。多くのMCPサーバーは Node.js か Python の上で動くので、パソコンにそれらが入っている必要があります。加えて、繋ぎ先のサービスでAPIキーを発行する手続きが要ります。APIというのは、人間が画面を触る代わりにプログラムから操作するための窓口のことで、APIキーはその窓口を開けるための鍵にあたります。

繋いだあとの動作確認は、難しく考えなくても大丈夫です。ホストを再起動してから「いま使えるツールを一覧で教えて」と聞けば、繋がっていれば道具の名前が並びます。並ばなければ繋がっていません。もう少し細かく中身を見たいときのために、MCP Inspector という公式の確認用ツールも用意されています。

認識されないときに私が疑う順番は決まっていて、①ホストを再起動していない、②起動コマンドの書き方かファイルの場所が違う、③APIキーが入っていないか権限が足りない、の3つです。体感では、最初の1つで解決することが一番多いです。それでも直らないときは、エラーの文言をそのままAIに貼って聞くのが早いです。私はそれ以上のことをしていません。

MCPサーバーを自作したきっかけ

本題に入ります。既製のMCPを一通り繋いでいくと、どこかで「これに当たるものが無い」という場面が来ます。私の場合は、ある広告媒体の操作でした。毎回まったく同じ手順を管理画面で踏んでいて、数もそれなりにあって、けれど公開されているMCPの中に自分のやりたい形のものが見つかりませんでした。

作った理由は、それだけです。MCPサーバーを自作したかったから作ったのではなく、必要だったから作りました。技術的な興味が先にあったわけではないので、いま作ったものが1本しか無いのも、必要が1つしか無かったからです。

作らせ方も、身も蓋もありません。Claude Code に「この媒体のAPIを、AIから直接呼べるようにしたい」と日本語で伝えて、公式ドキュメントの場所を渡しました。あとは動くまで往復しただけです。私がやったのは3つで、やりたいことを言葉にすること、出てきたものを実際に動かしてみること、おかしいところを日本語で伝えて直してもらうこと。コードは一行も書いていません。読んで意味が分かる箇所もありますが、書けと言われたら書けません。

作ったあとに変わったのは、管理画面を開く回数でした。前は同じ画面を行ったり来たりしながら1件ずつ手で登録していたところが、必要な材料を渡して頼むだけで、下書きの形で並ぶようになりました。私が見るのは、出来上がったものを確認する場面だけです。既製のMCPで感じた「頭の切り替えが要らない」が、いちばん面倒だった作業にも届いた、という言い方が近いかもしれません。

実装の中身は自分で決めていないので、決めてもらった内容だけ書いておきます。MCPサーバーは公式のSDK（作るための部品をひとまとめにしたもの）が用意されている言語で書くのが一般的で、PythonとTypeScriptがよく使われます。私の場合はPythonになりました。AIとサーバーのやり取りは、自分のパソコンの中で動かすなら標準入出力を通す形（stdio）が基本で、離れた場所に置くならHTTPを使います。やり取りの中身は JSON-RPC という決まった形式に沿っています。どれも「そうしてください」と頼んだ覚えはなく、用途を伝えたら勝手にそうなっていました。

もし手を動かして作りたい方であれば、公式のクイックスタートが用意されているので、そちらを見るほうが確実です。私が書けるのは作り方ではなく、作らせ方のほうだけです。

自作するか、既製で済ませるかの判断

作れると分かると、何でも作りたくなります。実際には作らないほうがいい場面のほうが多かったので、私が使っている線引きを書いておきます。

まず探します。公式・非公式を合わせるとかなりの数のMCPサーバーが公開されているので、有名なサービスならたいてい誰かが作っています。あるなら使います。自分で作ったものは自分でメンテナンスすることになるので、他人が保守してくれているものを使えるなら、そのほうが得です。

作る側に倒すのは、次の2つが両方そろったときだけにしています。ひとつは、毎週以上の頻度で同じ手順を人手で踏んでいること。もうひとつは、既製のもので代わりが利かないこと。片方しか満たしていないなら、たいてい作らないほうがよかったです。月に一度の作業のために道具を作ると、作った手間を回収する前に、その作業自体が無くなったりします。

逆に、自作したほうが良かったと感じるのは、自分の業務に合わせて形を決められるところでした。既製のものは汎用的に作られているぶん、返ってくる情報が多すぎたり、自分の使い方だと余計な操作が並んでいたりします。使う操作だけを並べた道具にすると、AIが迷わなくなります。

外に出る操作は、必ず一段止める

自作の話で、いちばん書いておきたいのがここです。私が作ったMCPには、外に出る操作を必ず停止状態で作るという決まりを入れてあります。

具体的には、広告を作る操作を頼んだとき、作りはするけれど配信は始まりません。停止した状態のものが出来上がって、そこで止まります。人間が管理画面で中身を見て、自分の手で動かします。最後のひと押しだけは絶対にAIに渡さない、という切り方です。

理由は、AIが間違えるからではありません。人間も同じくらい間違えます。困るのは、自動で最後まで流し切ってしまうと間違いに気づくのが遅れることのほうです。世の中に出てから気づくのと、出る前に気づくのとでは、取り返しのつきやすさがまったく違います。

同じ考え方で、他にもいくつか枠をはめてあります。1回で取ってくる量の上限、1日に動かせる回数の上限、それから緊急停止のスイッチの3つです。用心すべきなのはプログラムそのものではなく、外に触る部分だと思っています。あたりを付けるなら、データベースへの問い合わせ、決まった時刻の自動実行、API、チャットへの投稿の4つでしょうか。

先に枠をはめておくのには、順番としての意味もあります。あとから機能を足したときに、思っていなかった動き方をしても枠の中で止まるからです。作りながら足していく前提なら、上限は最初に決めておいたほうが楽でした。同じ考え方をGoogle Apps Scriptの自動化でも使っていて、そちらは書けないままAIにGASを書かせた記事に詳しく書いています。あわせて読んでみてください。

道具を増やしすぎたときに起きること

MCPは繋ぐのが簡単なので、つい増えます。増やしすぎると起きることが、実際に2つありました。

ひとつは、AIが道具を選び損ねるようになることです。繋いだサーバーが持っている操作は、AIが「使えるものの一覧」として常に持ち歩いています。数が多くなるほど一覧が長くなって、目の前の頼みごとに対してどれを使うべきかの判断が鈍ります。似た名前の操作が複数あると、違うほうを呼ぶこともあります。

もうひとつは、お金の話です。道具から返ってくるデータは、そのままAIの読み込み枠に入ります。読み込み枠のことをコンテキストと呼び、AIが一度に抱えられる情報量の上限だと思ってもらえれば大丈夫です。表を丸ごと返すような道具を繋いでいると、質問1回あたりに読ませる量が増えて、枠が埋まるのが早くなります。枠を食うということは、そのぶん料金がかかるということでもあります。道具を増やすほど、月末の請求にじわじわ乗ってきます。

対策として私がやっているのは、作業ごとに繋ぐものを分けることです。記事を書くフォルダではキーワード調査とブラウザ操作だけ、デザインを触るフォルダではデザイン系だけ、というように、そのとき使う道具だけが並んでいる状態にしておきます。全部入りの状態を常に持ち歩かない、というだけの話です。抱えすぎると質が落ちるのは人もAIも同じで、役割を割って渡す考え方についてはAIを分業させる記事のほうで詳しく書いています。

正直に書いておくと、繋いだのに使わなくなったMCPもあります。面白そうだから入れてみたものの、月に一度も呼ばれないまま残っていたものは外しました。使っていない道具を持ち歩く分だけ判断が鈍るので、定期的に見直したほうがよさそうです。

向いていない使い方と、気をつけていること

MCPが合わない場面もあります。一度きりの作業なら、道具にせずその場でやってもらったほうが早いです。画面を数回クリックすれば終わることも、わざわざ繋ぐ意味は薄いでしょう。目で見て選ぶ作業、たとえば画像を並べてどれが良いか決めるようなものも、人間が画面を見たほうが確実です。

安全面で気をつけているのは、自作したMCPが自分のAPIキーを持っている点です。鍵を持った小さなプログラムが自分のパソコンの中にある状態なので、他人に配ったり、共有のフォルダに置いたりしないようにしています。読み取りしかしない用途なら、書き込みの権限は最初から付けません。

あとは、公開されているMCPサーバーを入れるときに、誰が作ったものかを一度見るようにしています。自分の道具を触らせるものなので、素性の分からないものを繋ぐのは、知らない人に家の鍵を渡すのと似たところがあります。公式が出しているものか、広く使われているものかどうか。判断できるのはその程度ですが、見ないよりはいいと思っています。

よくある質問

Q. MCPサーバーとAPIの違いは何ですか？
A. APIは、サービス側が用意している操作の窓口そのものです。MCPサーバーは、その窓口をAIから呼べる形に整えて並べ直したもの、と考えると近いです。APIは各社バラバラの作りをしているので、AIから見ると毎回説明が必要になります。MCPという共通の形に揃えておくと、AIは「使える道具が並んでいる」という同じ見え方で扱えます。つまり置き換えではなく、APIの上にかぶせる一枚だと捉えるのがよさそうです。

Q. 自作するならPythonとTypeScriptのどちらがいいですか？
A. 公式のSDKはどちらにも用意されているので、書ける側で選ぶのが素直だと思います。自分で書かずAIに任せるなら、正直どちらでも構いません。私の場合はPythonになりましたが、指定した覚えはなく、用途を伝えたら選ばれていました。ひとつだけ言えるのは、他のツールと繋げる予定があるなら、すでに手元で動いているものと言語を揃えておくと管理が楽になります。

Q. 自作したMCPサーバーはどこで動きますか？ 費用はかかりますか？
A. 多くの場合、自分のパソコンの中で動きます。ホストのアプリが必要なときに起動して、終われば止まる、という動き方です。どこかにサーバーを借りる必要はないので、その意味での費用はかかりません。かかるのは、AIとのやり取りで消費するトークン、つまり利用しているAIの料金のほうです。道具から返ってくるデータ量が多いほど読み込む量が増えるので、返す情報を絞っておくと結果的に安く済みます。

Q. MCPとRAGの違いは何ですか？
A. RAGは、あらかじめ用意した資料を検索して、答えに必要な部分を読ませる仕組みです。読ませる材料を増やす方向の話になります。MCPは、AIが外の道具を操作できるようにする仕組みなので、読むだけでなく「実行する」ところまで含みます。資料を読ませたいならRAG、作業をさせたいならMCP、という分け方をすると迷いにくいでしょう。両方を併用している場面も普通にあります。

まとめ

MCPサーバーの自作というと、仕様を読んでコードを書く話に聞こえます。私がやったのは、必要な道具が無いと気づいて、やりたいことを日本語で伝えて、動くまで付き合ってもらっただけでした。書けないままでも道具は増やせる、というのが実際に手元で起きたことです。

順番としては、まず既製のものを繋いでみるのがいいと思います。繋いでみないと、自分の仕事のどこに穴が空いているのかが見えません。穴が見えて、それが毎週のように繰り返されていて、埋めるものが世の中に無い。そこまで揃ってから作っても遅くないです。

そして、作るときには外に出る操作だけ一段止めておいてください。投稿も入稿も送信も、最後のひと押しは自分の手に残す。私が入れている枠はそのくらいですが、いまのところ大きな事故は起きていません。道具を増やすのと、暴走させないようにするのは、たぶんセットで考えたほうがうまくいきます。