MCP——AIがツールにつながる共通規格
AIチャットは会話するだけでは、ファイルを読んだりコマンドを実行したりできません。AIに「手足」を与える共通規格がMCP（Model Context Protocol）です。クライアントとサーバーという関係、標準入出力でつながる仕組みは、Linuxのパイプの考え方の延長線上にあります。この単元でMCPの正体を理解します。
AIチャットに「このサーバーのログを見て原因を教えて」と頼んでも、AI単体では実際のファイルを開くことができない。会話の中で文章を生成することはできても、手元のコンピュータに触れる「手足」を持たないからだ。どれだけ賢い受け答えができても、実際のファイルを開けなければ、原因の特定は結局こちらの手作業に戻ってしまう。
この「手足がない」という制約を取り払うために生まれた共通規格が、MCP（Model Context Protocol）だ。2024年にAnthropicが公開し、特定の1社だけの仕様に閉じずオープンな規格として広まっている。オープンであることは重要で、特定のサービスに縛られず、いろいろな作り手がMCPサーバーやMCPクライアントを作れる土壌になっている。
この単元で扱うMCPは、前の単元で扱った「対話で学ぶAI」から一歩進んだ話になる。AIが答えるだけの存在から、実際に手を動かす存在に変わるとき、その手足の部分を担うのがMCPだと捉えると、全体像がぐっとつかみやすくなる。
🔌 クライアントとサーバーという関係
MCPには2つの登場人物がいる。ひとつはAIを動かす側の「クライアント」（Claude Codeのようなツール）。もうひとつは、ファイル・データベース・外部APIなど、具体的な道具への窓口になる「MCPサーバー」だ。
ここでいう「クライアント」は、いつも人が向き合っているチャット画面そのものを指すこともあれば、その裏で動いているアプリケーション本体を指すこともある。呼び方に幅はあるが、役割は一貫していて、AIモデルとMCPサーバーの間を取り持つ立場だと考えれば十分だ。
クライアントは「いま使えるMCPサーバーにはどんな機能があるか」を尋ね、必要に応じてその機能を呼び出す。MCPサーバー側は、渡された指示を実際の操作（ファイル読み込み・コマンド実行・API呼び出しなど）に変換して実行し、結果をクライアントに返す。この往復がMCPのやり取りの基本形だ。
MCPサーバーが提供する機能は、大きく分けると「ツール」（AIが呼び出せる操作）、「リソース」（AIが読み取れるデータ）、「プロンプト」（定型の指示テンプレート）といった種類がある。すべてを1つのMCPサーバーが持つ必要はなく、目的に応じて必要な種類だけを実装すればよい。
1台のクライアントに、複数のMCPサーバーを同時につなぐこともできる。ファイル操作用のサーバー、データベース用のサーバー、外部APIを叩くサーバーをそれぞれ用意し、AIが状況に応じて使い分ける、という構成も珍しくない。ひとつのAIが、状況に応じて複数の手足を持ち替えながら作業する姿をイメージすると分かりやすい。
この仕組みのおかげで、開発者は「AIモデルそのもの」と「AIに触らせたい道具」を分けて考えられるようになる。道具側の作り手は、AIの内部の仕組みを知らなくてもMCPの作法さえ守ればよく、モデル側の作り手も、個別の道具ごとに専用コードを書く必要がなくなる。
🔗 stdio——標準入出力でつながる
MCPサーバーとクライアントをつなぐ代表的な方法のひとつが、標準入出力（stdio）だ。標準入出力は、プログラムがキーボードから文字を受け取り（標準入力）、画面に文字を出す（標準出力）という、Linuxのコマンドが古くから使ってきた仕組みそのものになる。
つまりMCPは、まったく新しい奇抜な技術というより、Linuxが長年使ってきた「プログラム同士を単純な経路でつなぐ」という思想を、AIとツールの関係にも当てはめたものだと捉えられる。パイプの思想を知っている人ほど、MCPの仕組みはすんなり理解できるはずだ。
⚙️ 設定はJSONでサーバー起動コマンドを登録
MCPサーバーを使えるようにするには、クライアント側の設定ファイルに「このMCPサーバーは、このコマンドで起動できる」という情報をJSON形式で登録する。設定にはサーバーの名前、起動コマンド、必要な引数などが並ぶ。
この仕組みは、systemdがサービスの起動コマンドをユニットファイルに書いておく発想や、cronが実行するコマンドを設定ファイルに書いておく発想と似ている。「何を」「どうやって」起動するかを設定として外に出しておき、必要なときに呼び出す、という考え方はLinuxのあちこちで繰り返し使われてきた。
この設定ファイルの置き場所は、プロジェクトごとに置くのか、そのマシン全体で共有するのかといった単位でも変わってくる。プロジェクト専用のMCPサーバーを使いたいのか、どのプロジェクトでも使う共通の道具として登録したいのかによって、置き場所を使い分けると管理がしやすい。
🔧 「USB-Cのような共通端子」
MCPの立ち位置をひとことで表すなら、パソコン周辺機器の世界におけるUSB-Cのような共通端子だ。USB-Cが登場する前は、機器ごとに専用のケーブルや差込口が必要だった。USB-Cという共通規格ができたことで、どのメーカーの機器でも同じ端子でつながるようになった。
この共通化のメリットは大きい。一度作ったMCPサーバーは、対応する複数のAIクライアントから使い回せる。逆にクライアント側も、MCPに対応さえしていれば、世の中に増えていく多種多様なMCPサーバーを次々とつなげられる。作る側も使う側も、同じ規格に乗ることで手間が減る仕組みだ。
共通規格が広まると、周辺のエコシステムも育っていく。すでに公開されているMCPサーバーを探して使うだけでも、自分でコードを書かずにAIの手足を増やせる場面が出てくる。ゼロから作る前に、目的に近いものが既に無いか探してみるのも実用的な進め方だ。車輪の再発明を避けられるのも、共通規格の恩恵のひとつと言える。
🐧 自作サーバーでLinuxの何でもAIから使えるように
MCPのおもしろさは、誰でも自分専用のMCPサーバーを作れる点にもある。Linux上で動く自作のスクリプトやコマンドをMCPサーバーとしてラップしてしまえば、AIがそのスクリプトを「道具」として呼び出せるようになる。
たとえば「特定のログディレクトリを監視して、エラー行だけ抜き出す」処理をシェルスクリプトとして書き、それをMCPサーバーとして登録すれば、AIに「最近のエラーを教えて」と頼むだけでそのスクリプトが実行され、結果が返ってくるようになる。ふだん自分がターミナルで手作業していたことを、AIに窓口だけ渡すイメージだ。
この考え方は、組込みLinuxの世界とも相性がよい。センサーの値を読むコマンド、ログを集計するスクリプト、機器の状態を返すツールなど、すでに手元にあるLinuxの資産をそのままMCPサーバー化すれば、AIエージェントから呼び出せる道具に生まれ変わる。
実装の言語も特定のものに縛られているわけではない。シェルスクリプトでも、Pythonでも、他のプログラミング言語でも、標準入出力でJSON形式のやり取りさえ作法どおりにこなせれば、MCPサーバーとして成立する。すでに慣れた言語でそのまま書けるという点も、始めやすさにつながっている。
ここまで見てきたように、MCPはクライアントとサーバーの役割分担、stdioという既知の仕組みの応用、JSONによる設定、共通端子としての価値、そして自作の自由度という、いくつもの要素が組み合わさった規格だ。難しく感じたら、まずは「AIに手足を与える共通の作法」という一文だけ覚えておけば、当面は十分に扱える。
MCPは、AIを会話の相手から、実際に手を動かす相棒へと変える土台になる規格だ。次の単元では、この手足を持ったAIが、クラウドではなく手元の機器の上で動く世界——エッジAIについて、じっくり見ていくことにする。