【Windows対応】Claude DesktopのMCPログを読む方法|mcp.logとサーバーログの見分け方

MCPログを読む。mcp.logとサーバーログを、ログ表示のあるモニターと虫眼鏡で表現したアイキャッチ画像。

Claude DesktopでMCPがつながらない、またはConnectorsには表示されるのにツール実行が失敗する。そのような時に、設定ファイルを何度も書き換える前に確認したいのがMCPログです。

ログは「直し方」を直接教えてくれるものではありません。しかし、どの段階で止まったかを示してくれます。接続全体の記録を見るのか、特定サーバーが出した標準エラーを見るのかを分けるだけで、確認すべき場所を絞りやすくなります。

この記事では、Windows版Claude Desktopで手動JSON設定のローカルMCPを使うケースを中心に、mcp.logmcp-server-サーバー名.logの違い、最新行の確認方法、読み取り時の注意点を整理します。接続全体の確認順は、先にClaude DesktopのMCPが接続できない時の確認順を参照してください。

目次

この記事の結論

  • mcp.logは、Claude DesktopとMCPサーバーの接続全体を確認するための入口です。
  • mcp-server-サーバー名.logは、特定サーバーが標準エラー出力へ書いた起動・実行時の記録を確認するためのファイルです。
  • 最初は、現在時刻に近い行から読み、サーバー名・設定・パス・Node.js/npx・権限・ツール実行のどれに関係するかを分けます。
  • stdio方式の自作MCPサーバーでは、stdoutへログを書いてはいけません。プロトコル通信を壊すため、ログはstderrへ出します。
  • ログにはユーザー名、フルパス、トークン、APIキー、業務ファイル名が含まれる可能性があります。外部共有前に必ず伏せます。

最初に知っておきたい、2種類のMCPログ

WindowsのClaude Desktopでは、MCP関連ログは通常、次のフォルダに保存されます。

%APPDATA%\Claude\logs

主に確認するのは、次の2種類です。MCP公式のローカル接続ガイドでは、mcp.logを接続・接続失敗を含む一般的なMCPログ、mcp-server-サーバー名.logを対象サーバーのstderr出力と説明しています。[1]

ファイル最初に分かること主に確認する場面
mcp.logClaude DesktopがMCPサーバーへ接続しようとしたか、接続段階で失敗していないか。Connectorsに表示されない、設定変更後に何も起きない、どのサーバーで問題が起きたか分からない時。
mcp-server-サーバー名.log特定サーバーがstderrへ出した起動・依存関係・処理中の記録。対象サーバーを絞れた時、Node.js・npx・パス・環境変数・ツール処理の手掛かりを探す時。

ここで大切なのは、「ログファイルがある=そのファイルだけを見ればよい」ではないことです。まずmcp.logで接続全体を確認し、対象サーバーが分かったらサーバー別ログを開く、という順番にすると迷いにくくなります。

Claude DesktopのMCPログを読む順番。mcp.logで接続段階を確認し、特定サーバーの起動または実行に関係する場合はmcp-server-サーバー名.logを確認するフロー。
ログは「接続全体」から「特定サーバー」へ絞り込んで確認します。

PowerShellでログフォルダと最新のログを確認する

エクスプローラーで%APPDATA%\Claude\logsを開いても構いません。PowerShellを使うと、更新日時が新しいログから確認できます。PowerShellでは%APPDATA%ではなく、環境変数の$env:APPDATAを使います。

ログフォルダを開く

$logDir = Join-Path $env:APPDATA 'Claude\logs'
Invoke-Item $logDir

更新が新しいMCPログを一覧にする

$logDir = Join-Path $env:APPDATA 'Claude\logs'
Get-ChildItem $logDir -Filter 'mcp*.log' |
  Sort-Object LastWriteTime -Descending |
  Select-Object LastWriteTime, Name, Length

Claude Desktopを完全終了して再起動した直後に実行すると、直近で更新されたログを見つけやすくなります。設定やサーバーコードを変えた時は、ウィンドウを閉じるだけではなく、Claude Desktopを完全に終了してから起動し直します。[2]

mcp.logの末尾を確認する

$logDir = Join-Path $env:APPDATA 'Claude\logs'
Get-Content (Join-Path $logDir 'mcp.log') -Tail 80

特定サーバーのログの末尾を確認する

$logDir = Join-Path $env:APPDATA 'Claude\logs'
Get-ChildItem $logDir -Filter 'mcp-server-*.log' |
  Sort-Object LastWriteTime -Descending |
  Select-Object -First 1 |
  ForEach-Object { Get-Content $_.FullName -Tail 80 }

上の例は、最終更新日時が最も新しいサーバーログの末尾80行を表示します。サーバーが複数ある場合は、一覧でファイル名を確認してから、対象のmcp-server-サーバー名.logを指定してください。古い失敗記録と、今再現した失敗記録を混同しないためです。

ログを読む順番:時刻・サーバー名・止まった段階をそろえる

ログのエラーらしい文字列だけを検索すると、過去の失敗や別サーバーの記録に引きずられることがあります。次の3点をそろえてから、設定変更へ進んでください。

確認すること見る理由確認後の行動
時刻いま再現した直後の行かを判断するため。Claude Desktopを再起動し、Connectorsを開く、または1回だけツールを実行してから確認する。
サーバー名複数のMCPを設定している場合、別サーバーの失敗を見ないため。claude_desktop_config.jsonmcpServersのキー名とログファイル名を照合する。
止まった段階設定、起動、接続後のツール実行では、確認場所が異なるため。下表に沿って、最初の確認対象を1つに絞る。

よくある「止まる段階」と、最初に見る場所

ログの文言は、MCPサーバー、Node.js、OS、Claude Desktopのバージョンで変わります。そのため、特定の一行だけを暗記するよりも、「どの段階の記録か」で判断する方が再現性があります。

症状・ログの方向性最初に見るログ最初に確認する項目
Connectorsにサーバーが表示されないmcp.log設定JSONの場所・構文、サーバー名、絶対パス、Claude Desktopの完全再起動。
実行ファイルやフォルダが見つからないことを示す記録mcp-server-サーバー名.logと設定JSONcommandargs、指定フォルダが実在するか。相対パスではなく絶対パスになっているか。
Node.js、npm、npx、環境変数に関係する起動失敗mcp-server-サーバー名.logPowerShellまたはコマンドプロンプトでnode --versionnpm --versionnpx --versionを確認し、必要な環境変数がJSONのenvにあるか。
接続は表示されるがツール実行で失敗する対象のmcp-server-サーバー名.log許可フォルダ、入力値、APIキーや認証、操作対象への権限、サーバー側の処理。
何を直しても状況が変わらないmcp.logと最新のサーバーログ変更後に完全再起動したか、直近ログの時刻か、複数項目を同時に変えていないか。

Windowsのパス、Node.js・npx、JSON設定、Connectors表示から切り分けたい場合は、MCPが接続できない時の確認順へ戻ってください。本記事は、そこで「ログを見よう」となった後の確認手順を詳しく扱う補完記事です。

自作MCPサーバーではstdoutへログを書かない

Node.jsなどでstdio方式のMCPサーバーを自作している場合、通常出力(stdout)はMCPのプロトコル通信に使われます。MCP公式のデバッグガイドは、stdoutへのログ出力がプロトコル動作を妨げると注意しています。ログを出したい時はstderrを使います。[2]

// 避ける:stdoutを使うため、stdioのMCP通信を壊し得る
console.log('server started');

// 使う:stderrへ診断情報を出す
console.error('[greet] server started');

ただし、stderrに出す内容にも注意が必要です。入力値、ファイル本文、APIキー、認証ヘッダー、社内URLをそのまま出力しないでください。ログは問題調査のためのものですが、出し過ぎると情報を増やすことになります。

Node.jsで最小のMCPサーバーを作る方法で紹介したような自作サーバーでは、起動、ツール実行開始、エラー条件だけを短く記録する設計から始めると、ログが読みやすくなります。

ログを外部へ共有する前のマスキングチェックリスト

ログはサポート依頼や技術コミュニティでの相談に役立ちますが、会社PCのログには社内情報が含まれる可能性があります。ログ全体をそのまま貼り付けず、問題に関係する最小行だけを取り出し、次の項目を伏せてください。

伏せる対象理由
認証情報APIキー、アクセストークン、Cookie、Authorizationヘッダー第三者がサービスへアクセスできるおそれがあるため。
個人・端末情報Windowsユーザー名、PC名、フルパス、メールアドレス利用者や端末構成を特定し得るため。
業務情報社内ドメイン、サーバー名、顧客名、案件名、業務ファイル名内部構成や業務内容を推測されるため。
入力・出力本文プロンプト、ファイル本文、ツールの戻り値会話や操作対象のデータを含む可能性があるため。

公式のデバッグガイドでも、ログを扱う際は資格情報や個人情報をサニタイズするよう案内しています。[2] 会社のルールがある場合は、外部共有の可否も先に確認してください。

共同検証で追記する一次情報

この記事では、公式資料で確認できるログの保存場所、種類、確認順を整理しました。次回は、個人PCの新規テストフォルダと架空データだけを使い、filesystem MCPまたは自作のgreetサーバーで次を確認します。

  • Claude Desktopを完全再起動した後に、どのログが更新されるか。
  • mcp.logmcp-server-サーバー名.logを開いた時に、何が読み取れるか。
  • テスト用のパスを意図的に誤った時、どのログへどのような記録が残るか。

画面やログ断片を公開する場合は、上記のマスキングを行ったうえで追記します。会社PC、会社データ、認証情報を使った検証は行いません。

まとめ:ログは「どこを直すか」を決めるために読む

MCPログの目的は、エラーを眺めることではありません。設定の問題なのか、サーバーの起動なのか、接続後のツール実行なのかを切り分け、次に確認する場所を1つに絞ることです。

まずはmcp.logで接続全体を確認し、対象サーバーが分かったらmcp-server-サーバー名.logへ進みます。直近の時刻、サーバー名、止まった段階をそろえ、設定変更は1項目ずつにしてください。ログを共有する時は、秘密情報と業務情報を伏せることも忘れないようにしましょう。

関連する記事

参考資料

  1. Model Context Protocol: Connect to local MCP servers
  2. Model Context Protocol: Debugging
  3. Anthropic Support: Getting Started with Local MCP Servers on Claude Desktop
よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

2010年入社、インフラエンジニア17年目。

Windows Server、Linux、Active Directory、仮想化、
Microsoft 365、AWSなどの設計・構築・運用・テストを経験しています。
現在は、生成AI、PowerShell、MCP、Claude Codeを実際に検証し、
インフラ技術・業務自動化・クラウド・キャリアについて発信しています。

コメント

コメントする

目次