MCPの使い方｜AIに手元の道具とフォルダを渡して動かす

「mcp 使い方」で調べる人が求めているのは、仕様の解説ではなく、手元のフォルダやコマンドをAIに渡して動かすまでの最短の順番です。設定そのものは短く、詰まる場所もほぼ決まっています。ここでは、仕組みの最小限、登場する3者、設定の手順、繋がらないときに見る場所、そして入れる前に確かめることを順に整理します。

AIに手元を触らせる方法を、1つに揃えるための決まり

AIに手元の状況を渡す方法は、これまでアプリごとに違っていました。あるアプリは独自の拡張の形を持ち、別のアプリは画面から貼り付ける形しか持たない。同じことをしたいのに、アプリを変えるたびに作り直す必要がありました。MCPはこの接続の形を揃えるための取り決めで、公開されている仕様では、LLMのアプリケーションと外部のデータやツールを繋ぐための開かれたプロトコルと説明されています。

考え方の下敷きになっているのは、エディタと言語の間に立つ仕組みです。仕様の文書自体が、プログラミング言語への対応を開発ツール全体で共通化した先例から着想を得ていると述べています。片側にAIのアプリ、もう片側に道具を置き、その間の話し方だけを決める。この形にすると、道具を1つ作れば対応するアプリすべてで使えます。

やり取りの中身はJSON-RPCの形式で、文字の符号化はUTF-8に固定されています。土台の部分は、リクエストが自己完結していること、そしてリクエストごとに使える機能を確認し合うことで成り立っています。仕様の最新版として公開されているのは2026年7月28日付のものです。

登場するのは3者。ホスト、クライアント、サーバー

用語が3つ出てきますが、役割で覚えると迷いません。

• ホスト。接続を始めるLLMのアプリケーションです。利用者が実際に触る画面を持つ側です
• クライアント。ホストの中に置かれる接続の口です。相手1つに対して1つ用意されます
• サーバー。文脈や機能を提供する側です。フォルダを読む、コマンドを動かす、外部のサービスに問い合わせる、といった役割を持ちます

この分け方で押さえておくべき点は、サーバーが必ずしも遠くの機械ではないということです。手元のMacの中で動くプログラムもサーバーになります。むしろ最初に試すものは、手元で動く小さなサーバーです。遠くの機械に置く必要が出てくるのは、社内のデータに繋ぐ段階からです。

利用者から見ると、この3者は1つの画面に隠れます。ホストの設定にサーバーを1行書くと、そのホストの中でAIが道具を使えるようになる。見えるのはそれだけで、間の話し方は決まっているので気にしなくてよい、というのが狙いです。

サーバーが差し出す3つのもの

サーバーがホストに提供できる機能は3種類あります。ここを混同すると、設定は通っているのに期待した動きにならない状態になります。

• Resources。文脈やデータです。利用者やAIのモデルが参照するために差し出されます
• Prompts。定型のメッセージや手順です。利用者が選んで使う形のものです
• Tools。AIのモデルが実行する関数です。実際に何かが起きるのはここです

フォルダを読ませたいだけなら1つ目、決まった作業の手順を渡したいなら2つ目、名前の一括変更のように実際に動かしたいなら3つ目が対象になります。逆向きの機能も1つ用意されていて、サーバーの側から利用者に追加の情報を求める仕組みがあります。確認を挟みたい作業で使われます。

これらに加えて、設定、進み具合の追跡、取り消し、エラーの報告といった補助の仕組みが土台に含まれています。長い処理を扱うときは、進み具合の追跡と取り消しが効いてくる部分になります。

手順1：ホストを決めてから、サーバーを1つだけ入れる

始め方でいちばん失敗が少ないのは、ホストを1つに決めて、サーバーを1つだけ入れることです。いきなり複数入れると、動かなかったときにどれが原因か分からなくなります。

最初に入れるサーバーとしてよく選ばれるのが、フォルダを読み書きするものです。設定の書き方は、ホストの設定ファイルにサーバーの名前と起動の方法を書く形になります。

{ "mcpServers": { "filesystem": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-filesystem", "/Users/ユーザ名/Desktop", "/Users/ユーザ名/Downloads" ] } } } 出典: qiita.com

読んでほしい形は単純です。名前を付け、起動するコマンドを書き、そのコマンドに渡す引数を並べる。引数の末尾に並んでいるのが、触ってよいフォルダの範囲です。ここに書いていない場所は対象になりません。最初は2つ程度のフォルダに絞って試すのが安全です。

設定ファイルを書き換えたら、ホストのアプリを閉じて開き直します。読み込みは起動時に行われるので、書いた直後の画面には出てきません。出てこないときに設定を書き足すと、原因が増えるだけになります。

手順2：繋がらないときに見る場所

設定が正しく見えるのに動かない場合、原因は3つのどれかにほぼ収まります。1つ目は、書いたコマンドがホストから見つからないこと。2つ目は、書式の誤り。3つ目は、渡したフォルダの綴りの誤りです。

いちばん多いのが1つ目です。ターミナルでは動くコマンドが、アプリから起動したときには見つからないという状態が起こります。Node.jsの導入にVoltaのような管理の道具を使っている環境では、コマンドの名前をそのまま書いた設定では動かず、絶対パスで指定する必要があったという報告が設定手順をまとめた記事に残っています。

コマンドの名前だけを書くと、ホストのアプリが持っている検索の経路の中からしか探されません。ターミナルの設定ファイルで足した経路は、アプリには引き継がれません。これはNode.jsの管理の道具を使っている場合だけの話ではなく、Homebrewで入れたコマンドでも同じことが起きます。対処は共通で、コマンドを絶対パスで書きます。

書式の誤りは、カンマの位置と括弧の対応がほとんどです。設定ファイルはJSONなので、末尾に余分なカンマがあるだけで全体が読めなくなり、他のサーバーまで消えます。1つ足すたびに開き直して確かめると、原因が1つに絞れます。

2つの接続方式の使い分け

サーバーとの繋ぎ方は2種類が標準として決められています。どちらを選んでも、やり取りの意味は変わりません。仕様は、接続方式は運び方の取り決めであって、メッセージの意味はどの方式でも同じだと明記しています。

1つ目が、標準の入出力を使う方式です。クライアントが起動した子プロセスの標準ストリームの上で、改行で区切ったメッセージを流します。手元のMacで動かすサーバーはこの方式になります。設定に起動のコマンドを書くのは、この方式を使うからです。

2つ目が、HTTPを使う方式です。1つの受け口に対してメッセージごとにPOSTを送り、応答はJSONのオブジェクトか、そのリクエストのための流れとして返ります。遠くの機械にあるサーバーや、複数の利用者から使われるサーバーはこちらになります。独自の運び方を作ることも認められています。

選び方の目安は単純です。手元のファイルやコマンドを触るなら1つ目、社内やサービスのデータに繋ぐなら2つ目です。前者は設定だけで済み、後者は接続先の認証の話が加わります。

入れる前に確かめること

便利さと引き換えに、注意しておく点があります。仕様の安全に関する節では、道具は任意のコードの実行を意味するものであり、適切な注意をもって扱う必要があると書かれています。加えて、道具の振る舞いについての説明は、信頼できるサーバーから得たものでない限り信頼できないものとして扱うべきだとされています。説明文そのものが、AIへの指示として働きうるからです。

利用者の側で決められることは3つあります。

• 触らせる範囲を狭く始める。設定で渡すフォルダを絞り、必要になったときだけ足す
• 出どころを確かめる。誰が作ったものか、更新が続いているか、中身が読める形で公開されているかを見る
• 実行の前に確認を挟む形にする。ホストの側に、道具を呼ぶ前に許可を求める仕組みがあるなら、それを切らない

仕様も、ホストは道具を呼び出す前に利用者の明示的な同意を得なければならないという原則を置いています。設定を通すことと、何でも自動で走らせることは別の話です。仕様の本文はmodelcontextprotocol.ioで公開されているので、判断に迷ったときは原文にあたれます。

拡張で増えているもの

土台の取り決めのほかに、任意の拡張が定義されています。拡張は必ず選んで使う形で、クライアントとサーバーの双方が対応していることを接続の開始時に確認したうえで有効になります。主なものは3つ挙げられています。

1つ目が、時間のかかる処理を非同期で扱う仕組みです。進み具合の問い合わせ、途中での入力の受け取り、そして処理を指す持続的な手がかりが含まれます。ファイルの一括処理のように終わるまで待てない作業は、この仕組みの対象になります。

2つ目が、作業の手順をまとまった形で渡す仕組みです。3つ目が、会話の中に対話的な画面の部品を直接描く仕組みで、図や入力欄、再生の画面などが挙げられています。どれも、文字のやり取りだけでは足りない場面を埋めるものです。

いま対応しているアプリが少ない拡張もあります。始める段階では土台の3種類だけを押さえ、拡張は必要になってから見れば十分です。

ファイル管理と重なる場所

MCPで手元のフォルダを扱えるようにすると、もう1つの問題が浮き上がります。AIに触らせる範囲を決める作業と、実際にファイルを見る作業と、コマンドを打つ作業が、それぞれ別の窓にあるという問題です。設定は通っていても、どのフォルダを渡すべきかを決めるにはフォルダの一覧を見る必要があり、結果を確かめるにはまた別の窓に戻ることになります。

窓と窓の間で、状態は渡りません。AIが返したファイルの一覧は文字列で、それをフォルダの一覧の選択に変えるには手で探し直すことになります。フォルダとターミナルとAIが同じ窓にある形なら、この持ち替えそのものが起きません。渡す範囲の決め方も、見えているフォルダをそのまま指せる形になります。

ファイル管理アプリごとに、AIとの繋ぎ方の考え方は違います。その設計の差は他のファイル管理との比較に並べてあり、実際にどこまで扱えるかはできることで確認できます。日本語以外の環境での対応状況は対応言語にまとまっています。費用の考え方は料金にあり、細かい疑問はよくある質問に集めてあります。