どうも、ケニー（tsujikenzo）です。このシリーズでは、「ノンプログラマーのためのMCP入門」をお届けします。今日は第3回目です。
おさらい
前回は、「骨格と用語編」として、MCPのアーキテクチャ、プリミティブ、レイヤーという3本の柱をお届けしました。
概念としての理解が整ったところで、今回は「環境と構成ファイル」をお届けします。
1. 環境構築（インフラ準備）：実行環境の依存関係、および階層構造
MCPサーバーを動かすためには、単に一つのソフトを入れるだけでは足りません。複数のツールが「土台」として積み重なり、お互いを支え合うことで初めて機能します。
この依存関係の階層構造を整理したのが、以下の図です。（ケニー作）
⚠️ 注意：この図の見方
この図の矢印は「データの流れ」ではなく、「実行の連鎖」を表しています。
上にあるAIアプリが起動すると、まず【2】設定を参照し、そこから【3】インフラを通って【5】の道具を叩き起こす……という「土台の積み重なり」です。
実行環境を構成する4つの層
この依存関係の階層構造は、下位の層が上位の層を支える構造になっています。それぞれの役割を、土台となる層から順に見ていきましょう。
【実装層】AIへの「能力」を具体的に定義する場所（図の5, 4）
最下層に位置するのは、実際に動作するプログラム本体です。
- 【5】 道具本体（MCPサーバー）： 「天気を取得する」「データベースを検索する」といった具体的な処理（ロジック）を記述したファイルです。
- 【4】 開発キット（FastMCP）： あなたが書いた生のプログラムを、MCPのお作法（プロトコル）に適合する形へと「変換」する役割を担います。
【実行・インフラ層】プログラムを動かすエンジン（図の3.1, 3.2）
実装されたプログラムを物理的に動作させるための基盤です。
- 【3.2】 実行インフラ（Python）： プログラムを動かすための動力源（エンジン）です。
- 【3.1】 プロジェクト管理（uv）： Pythonのバージョンを固定し、必要な部品を揃え、プロジェクトごとに「独立したクリーンな環境」を維持・管理します。ここが不安定だと、上の実装したコードは一切動きません。
【制御・定義層】ホストとインフラを繋ぐマッピング（図の2）
独立して存在する「AIアプリ」と「実行インフラ」を連結させるための重要な接点です。
- 【2】 構成ファイル（JSON）： claude_desktop_config.json というファイルに、「どのコマンド（uv）を使って、どの道具（サーバー）を起動するか」という実行マニフェストを記述します。AIアプリはこの記述を読み込むことで、初めて下の階層にある道具の存在を認識できます。
【アプリケーション層】すべての司令塔（図の1）
スタックの最上位に位置し、私たちが直接操作するインターフェースです。
- 【1】 MCPホスト（Claude Desktop等）： 起動時に「制御・定義層」の指示をロードし、それに基づいて「インフラ層」のエンジンを回し、「実装層」の道具を自分の手足として統合します。
【答え合わせ】データのやり取りを支える「2つの層」との関係
第2回で学んだ「トランスポート層」と「データ層」という言葉を覚えていますか？ 実は、依存関係の階層構造の中に、その役割がしっかりと組み込まれています。
- トランスポート層（データの通り道）：【2】構成ファイルと【3.1】uvの役割
私たちがこれから設定する構成ファイル（JSON）に書く指令は、いわば「専用回線の開通命令」です。この命令によって、AI（ホスト）と道具（サーバー）の間にデータの通り道が連結されます。PC内で完結するばあいは、「stdio」という物理的なパイプが使われますが、もしこれがインターネット越しのサーバーであれば、「SSE（Server-Sent Events）」という通信路が使われます。どちらの道を使うにせよ、この「回線を繋ぐ」までがトランスポート層の仕事です。 - データ層（会話の中身）：【4】開発キット（SDK）の役割
図の「開発キット（FastMCP）」こそが、データ層の司令塔です。あなたが書いた道具の中身を読み取って、それを「JSON-RPC」という正しいお作法（プロトコル）の形式に整え、先ほど開通したパイプへ流し込みます。
つまり、「JSON設定とuvが配送ルート（トランスポート層）を確保し、SDKが中身（データ層）をお作法通りに書いている」のです。
それでは、claude_desktop_config.jsonファイルの中身を、確認してみましょう。
2. 接続の制御メカニズム：構成ファイル（JSON）の構造
MCPサーバーをAIアプリ（ホスト）に認識させるための「司令部」が、JSON形式の構成ファイルです。このファイルがどのように記述されているのか、その中身を解剖してみましょう。
まず、Claude Desktopをインストールしておきます。
claude_desktop_config.jsonファイルを開く
左下のアカウントをクリックして、「設定」をクリックします。
「開発者」をクリックして、「設定を編集」をクリックします。
表示されたclaude_desktop_config.jsonファイルを、メモ帳などで開きます。
基本構造：複数のサーバーを束ねる
構成ファイルの核心は mcpServers というプロパティです。ここには、以下のようにお好みのサーバーを好きなだけ追加することができます。
{
"mcpServers": {
"weather-tool": { // サーバー1つ目（名前は自由）
"command": "...",
"args": [...]
},
"my-database": { // サーバー2つ目（追加可能！）
"command": "...",
"args": [...]
}
}
}このように、複数のサーバーを並べて書くことで、AIは起動した瞬間に「天気予報もできるし、データベースも触れる」というマルチな能力を手に入れます。
主要なプロパティの意味
1つのサーバー設定の中には、主に3つの重要なプロパティがあります。これらは、依存関係の階層構造の各階層を動かすための「スイッチ」になっています。
① command （実行コマンド）
- 役割： どの「エンジン（実行インフラ）」を使ってサーバーを起動するかを指定します。
- 内容： uv や uvx、あるいはPCに保存されているプログラムの絶対パスを記述します。
- 階層構造との関係： 図の 【3.1】プロジェクト管理（uv） を指名する項目です。
② args （引数 / 引っ張りだすための指示）
- 役割： エンジンに対して、「どこにある、どのファイルを実行するか」という具体的な道順を伝えます。
- 内容： –directory（場所の指定）や run（実行命令）、そして app.py（ファイル名）などを配列形式で並べます。
- 階層構造との関係： 図の 【5】道具本体 を正確に指定するためのナビゲーションです。
③ env （環境変数 / 合鍵の保管場所）
- 役割： APIキーなどの機密情報を、プログラムに安全に渡すために使います。
- 内容： “API_KEY”: “sk-…” のように記述します。
- 階層構造との関係： 次章の「安全設計」で詳しく触れますが、知能（AI）には見せず、道具（サーバー）にだけ「合鍵」を渡すための秘密のポケットです。
まとめ
以上です。今回は、MCPを実際に動かすための「環境構築（インフラ準備）」と、その司令塔となる「構成ファイル（JSON）」の構造についてお届けしました。
次回は、「MCPサーバーを動かしてみる」という実践フェーズに突入します。
お楽しみに
