第4章【開発記】：Node.jsを入れて、最初のMCPサーバー（filesystem）をClaude Desktopにつないでみた
■ はじめに
まだ前回の記事を見ていない方はこちらも。
第3章【開発記】：MCPサーバー用の言語にPythonを選び、Windowsで「python --version」と打って首をかしげた
第4章では、いきなりPythonで自作には進みません。 最初にやるのは「公開されているMCPサーバーを１つ動かして、MCPがどう動くかを目で見ること」です。
理由はシンプルで、自分で書き始める前に動いている姿を一度見ておくと、後の章で書く時の地図が頭の中にできるからです。 自分のコードがエラーになった時にも「公式のサンプルは動いていた」という基準点があると、切り分けが格段にラクになります。
そのために、今回はもうひとつランタイム（Node.js）を入れます。 Pythonの隣にNode.jsが並ぶ構成は最初ややこしく感じますが、最終成果物の構成図でもNext.js側がNode.js上で動くので、ここで入れておけば後でも使い回せます。
Pythonでの自作MCPサーバーは、次章（第5章）から始めます。
■ 今回やること
第4章でやることは4つです。
①Node.jsをインストールする。
②MCPサーバーの動作範囲を限定するための「sandbox」フォルダを作る。
③claude_desktop_config.json に、公式のfilesystem MCPサーバーを設定する。
④Claude Desktopを再起動して、対話画面からMCP経由でファイルを読めることを確認する。
ここで初めて、Claude Desktopの会話画面でMCPの動きを目視します。
■ 今回出てくるツールと役割
今回、新しく出てくるツール及び重要な役割を持つものを整理します。
①Node.js：JavaScriptをPCで動かすランタイム。Pythonと同じ系統の道具で「言語を実行する仕組み」と思えばよい。
②npm：Node.jsに同梱されるパッケージ管理ツール。Pythonでいうpipに相当する。
③npx：npmが入ると一緒に使えるコマンド。「インストールせずに、その場でnpmパッケージを実行する」役割を持つ。MCPサーバーの起動に便利。
④@modelcontextprotocol/server-filesystem：MCP公式が出しているファイルシステム操作用のMCPサーバー。npx経由で動かせる。
⑤claude_desktop_config.json：第2章で場所を確認したClaude Desktopの設定ファイル。今回ここに mcpServers キーを足す。
⑥sandbox（自作フォルダ）：MCPサーバーがアクセスできる範囲を限定するためのフォルダ。今回は C:\Users\<ユーザー名>\sandbox に作る。
■ 比較：今回の選択肢
ここで2つの比較を立てます。 １つ目は「最初に動かすMCPサーバーをどれにするか」、２つ目は「MCPサーバーがアクセスする範囲をどうするか」です。
【最初に動かすMCPサーバーの候補】
①公式filesystemサーバー（@modelcontextprotocol/server-filesystem）
・形態：MCP公式が公開しているNode.js製サーバー。
・強み：ドキュメントが最も整っている。動作実績が豊富。題材が「ファイル操作」なので動きが目で見える。
・弱み：Node.jsのインストールが必要。
・今回採用するか：採用する。
②コミュニティ製のfilesystem系サーバー（Desktop Commanderなど）
・形態：有志が機能を拡張した派生版。
・強み：機能が豊富。シェル実行や差分編集まで含むものもある。
・弱み：機能が多い分、最初の確認には向かない。挙動を絞り込みづらい。
・今回採用するか：採用しない。
③Python製の自作MCPサーバー
・形態：自分でゼロから書く。
・強み：仕組みを最も深く理解できる。
・弱み：第4章でいきなりこれをやると、「正しく動いているのか間違っているのか」の判断軸が無くなる。
・今回採用するか：第5章から始める。今回は「公式が動いている姿」を見るのが先。
【MCPサーバーがアクセスする範囲の候補】
①sandboxフォルダ限定
・強み：被害範囲が限定的。動作確認に最適。
・弱み：実務で使いたいファイルはここに無い。
・今回採用するか：採用する。
②ユーザーフォルダ全体（DesktopやDocuments）
・強み：実務ファイルにすぐ手が届く。
・弱み：誤操作の影響が大きい。最初の確認で外側まで広げるのは怖い。
・今回採用するか：採用しない。
③Google Driveなど外部ストレージ連携
・強み：クラウド側のファイルも触れる。
・弱み：認証やAPI設定が増え、最初の動作確認には負担が大きい。
・今回採用するか：採用しない。第5章以降の比較で改めて触れる。
■ なぜ今回はそのツールを選ぶのか
今回はMCPサーバーとして「公式filesystemサーバー」を、アクセス範囲として「sandboxフォルダ限定」を選びます。 理由を3つに分けます。
１つ目は、最初の動作確認には「公式が動いている姿」を見るのが一番速いから。 自分でいきなり書き始めると、動かないときに「自分のコードが間違っているのか、MCPの仕組みが分かっていないのか」が切り分けられません。まず公式の動くサンプルを動かすことで、「MCPは確かに動いている」という前提を作ります。これは運用業務でも基本の発想です。まず正常系を確認するというやり方と同じです。
２つ目は、アクセス範囲をsandboxに絞ることで安心して試せる場を作るため。 MCPサーバーは設定で指定したフォルダに対して、読み書き削除までできます。最初から自分のDocumentsやDesktopに繋ぐと、誤って大事なファイルを動かす可能性があります。練習用に何もないsandboxフォルダを切っておけば、何が起きても被害がありません。LinuxのchrootやDockerのvolume指定の発想に近いです。
３つ目は、Node.jsを今のうちに入れておくと後の章で使い回せるから。 最終成果物の構成図にある「Next.jsで作る実行履歴ビューア」はNode.jsの上で動きます。今回MCPサーバー起動のためにNode.jsを入れておけば、第9章のNext.js登場時にも環境はそのまま使えます。
■ 実際に作るもの
最終的にこの章で動く構造はこうなります。
Claude Desktop（会話画面）
│
│ MCPプロトコルでツール呼び出し
▼
filesystem MCPサーバー（npxで起動したNode.jsプロセス）
│
│ ファイル読み取り
▼
C:\Users\<ユーザー名>\sandbox\hello.txt
│
│ 中身を返す
▲
filesystem MCPサーバー
│
│ 中身を会話に渡す
▲
Claude Desktop（中身を表示）ここまで動けば、最終成果物の構成図の、左半分が一通りつながった状態になります。
■ コードまたは設定例
【手順1：PowerShellの実行ポリシーを確認・設定する】
Node.js付属の npm や npx はPowerShellスクリプトとして実行されるため、実行ポリシーが制限されていると動きません。確認します。
Get-ExecutionPolicy -Scope CurrentUserRemoteSigned または Unrestricted が返れば、このまま進めます。Restricted か Undefined の場合は、次を実行します。
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUserこの設定は一度行えば永続します。後日PowerShellを開き直した直後に古い状態に見えても、Get-ExecutionPolicy -List で CurrentUser が RemoteSigned、MachinePolicy と UserPolicy が Undefined であれば、正しく保存されています。
【手順2：Node.jsを確認する】
node --versionv20 以降のバージョン番号（例：v24.15.0）が返れば導入済みです。認識されません と出た場合は未導入なので、公式サイト（https://nodejs.org）からLTS版をインストールし、PowerShellを開き直してから、もう一度 node --version で確認してください。
※実はここで既に「MCPサーバーを自作するだけ」なら完了しています。
打ったコマンド全部で5分かかりましたか？これで「MCPサーバー自作しました！」と胸を張って言える人、またそういうサイトを作成して「5分以内でMCPサーバーを自作した手順完全解説」など書いている人が信じられません。私が面接官なら、そんなポートフォリオ見せられたら100%落とします。
【手順3：npxの場所を確認する】
filesystem MCPサーバーは npx で起動します。後で設定ファイルに、この npx を絶対パスで書きます。PATHに依存せず確実に起動させるためです。
Test-Path "C:\Program Files\nodejs\npx.cmd"True が返れば、本手順のパスをそのまま使えます。False の場合のみ、Node.jsのインストール先が異なるので、次で実際の場所を確認し、以降の npx.cmd のパスを読み替えてください。
where.exe npx表示の中の npx.cmd で終わる行が、使うべき絶対パスです。
【手順4：動作確認用のフォルダとファイルを用意する】
filesystem MCPサーバーが読み書きする対象フォルダを作ります。<ユーザー名> は自分のWindowsログイン名に置き換えてください。
mkdir C:\Users\<ユーザー名>\sandbox中に確認用のテキストファイルを1つ置きます。
$content = @'
これはMCPテスト用のファイルです。
'@
[System.IO.File]::WriteAllText("C:\Users\<ユーザー名>\sandbox\hello.txt", $content, [System.Text.UTF8Encoding]::new($false))【手順5：設定ファイルを書き込む】
filesystem MCPサーバーを登録します。下記をまるごとPowerShellに貼り付けて実行します。<ユーザー名> は2か所（args 内のsandboxパスと、末尾の WriteAllText のパス）置き換えてください。
書き込みに [System.IO.File]::WriteAllText を使うのには理由があります。PowerShellの Set-Content は環境によってファイル先頭にBOM（不可視の制御バイト）を付け、その場合Claude Desktopが設定ファイルの読み込みに失敗し、起動できなくなります。WriteAllText にBOMなし指定（UTF8Encoding($false)）を渡すと、これを確実に防げます。
$content = @'
{
"mcpServers": {
"filesystem": {
"command": "C:\\Program Files\\nodejs\\npx.cmd",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"C:\\Users\\<ユーザー名>\\sandbox"
]
}
}
}
'@
[System.IO.File]::WriteAllText("C:\Users\<ユーザー名>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json", $content, [System.Text.UTF8Encoding]::new($false))command に npx ではなく絶対パス C:\\Program Files\\nodejs\\npx.cmd を書くのは、Claude Desktopが起動する環境ではPATHが通っておらず、npx だけでは見つけられないためです。バックスラッシュが2個ずつ（\\）なのは、JSONでの記法です。なお、設定ファイルのこのパスはMicrosoft Store版（MSIX版）Claude Desktopの場合のものです。インストール形態が異なると場所が変わります。
【手順6：Claude Desktopを完全に終了して再起動する】
設定ファイルは起動時にのみ読み込まれます。反映には完全な終了と再起動が必要です。タスクトレイに常駐するため、ウィンドウを閉じるだけでは終了しません。
Get-Process | Where-Object { $_.ProcessName -like "*Claude*" } | Stop-Process -Forceその後、Claude Desktopをもう一度起動します。
【手順7：MCPサーバーが認識されたことを確認する】
Claude Desktopで新しい会話を開き、入力欄の「+」ボタンからコネクタ一覧を開きます。filesystem が表示され、トグルがオン（青）になっていれば、設定は正しく読み込まれています。
起動時に「アプリ設定を読み込めませんでした」というエラーダイアログが出た場合は、JSON構文の問題かBOM混入です。その場合のみ、設定ファイルの先頭バイトを確認します。<ユーザー名> は置き換えてください。
$bytes = [System.IO.File]::ReadAllBytes("C:\Users\<ユーザー名>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json")
$bytes[0..3] | ForEach-Object { '{0:X2}' -f $_ }1バイト目が 7B（文字「{」）なら正常です。EF BB BF で始まっていればBOMが混入しているので、手順5をもう一度実行してから、再度Claude Desktopを起動してください。
【手順8：実際に動かして確認する】
Claude Desktopの会話画面で、次のように打ちます。
filesystemコネクタを使って、sandboxフォルダの中にある hello.txt の内容を読んでください。ツール使用の許可ダイアログが出たら許可します。これはMCPテスト用のファイルです。 という、手順4で作った内容が返ってくれば、Claude Desktopから対象フォルダへMCP経由でアクセスできています。
ここまで動けば、第4章の検証は完了です。
■ 次章でやること
第5章では、いよいよ自分で書く側に回ります。 Pythonで、最も小さい「Hello, world」相当のMCPサーバーを書きます。
具体的には、次のような流れで進めます。
①MCPの公式Python SDKを pip でインストールする。
②1ツールだけを持つMCPサーバーを書く（例：受け取った文字列をそのまま返すツール）。
③第4章で作った claude_desktop_config.json に、自作サーバーをもう一つ並べて登録する。
④Claude Desktopから自作ツールが呼べることを確認する。
ここまで来ると、構造としては「Claude Desktop → 自作MCPサーバー → ローカルのコード」が動いている状態になります。 最終成果物の構成図でいう、左上から中央まで線が繋がったことになります。
第5章を始める前に、お手元で次の3つを確認しておいてください。
①第4章のfilesystem MCPサーバーが、Claude Desktopから呼べている状態が継続していること。
②PowerShellで pip --version を叩いて、pip（Pythonのパッケージ管理ツール）が使えること。
③sandboxフォルダにテスト用のテキストファイルが置いてある状態が続いていること。
■次回
第5章【開発記】：Pythonで自作MCPサーバーを書いてClaude Desktopから呼び出してみた