MCPサーバーをClaude CodeとClaude Desktopに接続する方法

MCPサーバーをClaude CodeとClaude Desktopの両方に接続するには、同じ設定を2か所にコピーするだけでは済みません。

Claude Codeでは、MCPサーバーをlocal、project、userという異なるスコープで設定できます。設定を済ませても、実際に接続されたと確認する前にサーバーの承認が必要な場合があります。Claude Desktopの扱いは異なり、ローカルのMCPサーバーは拡張機能またはDeveloper設定から読み込めますが、リモートサーバーは別の接続フローに従います。そのため、Claude Codeで動作するMCPサーバーが、そのままClaude Desktopでも使えるようになるわけではありません。

もうひとつよくある混乱は、「追加済み」「承認済み」「接続済み」「タスクを完了できる」を同じ意味だと思ってしまうことです。これらはそれぞれ別の段階を表しています。

「追加済み」は設定が登録されたという意味にすぎません。「承認待ち」はサーバーがまだ認可を待っている状態です。「接続済み」はMCP接続が正常に確立されたことを意味します。しかし、これらすべてが期待どおりに進んでも、エージェントが実際のタスクを完了できないことはあります。

これはブラウザを操作するMCPサーバーで特に重要です。サーバーが接続され、ツールも利用可能でも、ブラウザに必要なログインセッションやCookieなどの実行時の状態がなければ、タスクは失敗します。この時点でMCPの設定自体はすでに正しく、足りないのはブラウザ環境の状態です。

このレイヤーを担うのがego (lite)です。エージェントは、タスクに必要な状態（既存のログインセッションや現在のページ状態など）をすでに持つ実ブラウザ環境の中で作業を続けられます。すでに機能しているMCP設定を何度も変更する代わりに、エージェントはブラウザ上のタスクそのものに進めます。

つまりMCPのトラブルシューティングでは、「Connected」と表示されているかどうかで止めず、どのレイヤーが実際に失敗しているかを見極めてください。サーバーは追加済みか。承認済みか。接続済みか。そして、タスクを完了するために必要な状態をブラウザが持っているか。

実際に接続しているもの

接続の両端には2つの当事者がいます。クライアントはClaudeアプリで、ツールを検出し、いつ呼び出すかを決め、結果を表示します。サーバーは実際の機能を担う別プロセスまたはリモートエンドポイントで、データベース、チケット管理システム、ファイルシステム、ブラウザなどが該当します。MCP自体は両者の間の契約にすぎません。だからこそ用語を正確に区別する価値があります。どのサーバーを選んだかは本記事の内容に影響しません。セットアップの仕組みはすべてのサーバーで同じだからです。

プロトコル自体の定義はmodelcontextprotocol.ioにあります。トランスポート、機能、クライアントとサーバー間の契約についてのリファレンスです。

実務上の結論として、接続の問題がサーバー側にあることはほとんどありません。問題は、クライアントがサーバーを起動するかどうかを決める3つの場所、つまりどの設定ファイルを読んだか、エンドポイントに到達できるか、承認したか、にあります。この3つを頭の中で分けて考えられれば、デバッグは午後がかりの作業ではなく短いチェックリストになります。

コマンドを打つ前にスコープを選ぶ

Claude Codeでサーバー定義を置ける場所は3つあり、間違った場所を選ぶことがサーバーが「消える」最大の原因です。接続は正常でも、それはもう自分がいないディレクトリの中での話だったからです。

localがデフォルトです。まだ確信のないサーバーを試すときや、リポジトリに置きたくない認証情報を持つものに使いましょう。サーバーが本当にコードベースに属する場合（たとえばチームリポジトリ用のプロジェクト管理サーバー）はprojectを選びます。このエントリはチェックアウトと一緒に移動し、チームメイトは一度承認するだけで済みます。コードではなく自分自身に関わるサーバー（個人用ノートサーバー、自宅ラボのエンドポイント、毎回のセッションで使うもの）にはuserを選びます。

重複を作る前に覚えておきたい挙動があります。同じサーバー名が複数の場所に存在する場合、Claude Codeは一度だけ接続し、優先度が最も高いソースのエントリ全体を使います。優先順位はlocal、project、user、プラグイン提供のサーバーの順です。フィールドはマージされないため、省略されたオプションキーがより完全なuserエントリで暗黙に補われることはなく、projectエントリ全体がそのまま使われます。

Claude Codeにサーバーを追加する

Claude Codeが提供するコマンドは1つですが、サーバーの提供方法によって書き方がいくつかあります。HTTP経由のリモートサーバーが最も単純なケースで、ローカルで実行するものが何もありません。

# Remote server over HTTP (the recommended transport)
claude mcp add --transport http <name> <url>

# With an auth header
claude mcp add --transport http secure-api https://api.example.com/mcp \
  --header "Authorization: Bearer your-token"

ローカルサーバーは子プロセスとして実行されるため、コマンドとその引数はダブルダッシュの後に置きます。この区切りは見た目だけのものではありません。区切りの後ろはそのままサーバーに渡されるため、Claude Codeがサーバー自身のフラグを自分のフラグとして解釈してしまうのを防ぎます。

# Local server as a child process
claude mcp add [options] <name> -- <command> [args...]

# Real shape, with an environment variable
claude mcp add --env API_KEY=your-key --transport stdio airtable \
  -- npx -y airtable-mcp-server

サーバーベンダーがJSONスニペットを提供している場合（同じスニペットがすべてのMCPクライアントで使えるため、ほとんどのベンダーがそうしています）は、フラグに書き直さずそのまま貼り付けられます。渡すのはmcpServersの中身のオブジェクトであり、その外側のラッパーではありません。

claude mcp add-json weather-api \
  '{"type":"http","url":"https://api.weather.com/mcp","headers":{"Authorization":"Bearer token"}}'

どちらも必須ではありませんが、知っておきたいフラグが2つあります。スコープのフラグはエントリの保存先を選ぶもので、次のどちらの書き方でも構いません。

claude mcp add --transport http stripe --scope local https://mcp.stripe.com
claude mcp add --transport http notion -s user https://mcp.notion.com/mcp

同じコマンドの2つの形はよく混同されます。通常のaddコマンドは名前付きエントリを丸ごと書き換えるので、ベンダーがURLを変更したときに適しています。add-jsonは同じオブジェクトをそのまま1つのエントリとして扱うので、サーバーが複数のフィールドを一度に必要とする場合に適しています。

本当に接続されたか確認する

追加に成功するとAddedという行が表示されます。この行が意味するのは設定がディスクに書き込まれたことだけであり、サーバーが動作するかどうかは何も示しません。本当の疑問に答えるのはlistコマンドで、サーバーごとにconnected、needing authentication、failed to connectのヘルスステータスを報告します。

各サブコマンドの詳細なリファレンスはClaude Code MCPの公式ドキュメントです。本記事と合わせて読む価値があります。

本記事が例として使っているブラウザサーバーのインストールと登録手順は、Claude CodeとCursor向けのPlaywright MCPセットアップガイド.

claude mcp list          # health status for every configured server
claude mcp get notion    # detail for one server, including its Issue line

ステータスが失敗を示す場合、listコマンドはその行に失敗の詳細を追加します。単一サーバーの表示では、HTTPステータスまたはエラーコードと、サーバーが返したテキストがIssue行に繰り返されます。JSONを読み返すよりも、この詳細を一次情報として扱ってください。認証情報らしきテキストは伏せられ、展開後のURLは意図的に含まれません。URLはクエリ文字列にシークレットを含むことがあるためです。

すべてのステータスが接続の試行から生まれるわけではありません。設定上の判断を報告するものもあり、Claude Codeはサーバーに一切接続せずにそれらを表示します。共有ファイルのprojectスコープのサーバーは、対話型クライアントを一度実行してプロンプトを承認するまでpending approvalのままです。設定でdisabledとして登録されているサーバーは、このプロジェクトではdisabledと表示され、アプリ内パネルから復元できます。設定エントリによって拒否されたサーバーは、単一サーバーの表示には出ますがlistには出ません。追加したはずのサーバーが消えたように見えるときに役立つ違いです。

さらにその上に信頼のゲートがあります。listと詳細コマンドが共有プロジェクトファイルの承認を読むのは、リポジトリにコミットされていない設定だけです。これは、そのワークスペースでクライアントを実行して信頼ダイアログを承認するまで続きます。クローンしたリポジトリが自分のサーバーを承認することはできません。プロジェクトの設定にコミットされた承認済みサーバーの一覧は、信頼されていないフォルダでは無視され、サーバーはヘルスチェックされずpending approvalのままになります。これは意図的な防御であり、バグではありません。クローンしたばかりの環境でサーバーが消えたように見えるのはこのためです。

WebSocketサーバーは上記すべての例外で、listの出力には一切表示されません。確認するには単一サーバーの表示かアプリ内パネルを使ってください。

同じサーバーをClaude Desktopに追加する

Desktopは別物であり、多くの人がつまずく変化は、ローカルサーバーの主要なドキュメント化された経路がJSONファイルではなくなったことです。現在の流れはパッケージ化された拡張機能です。設定を開き、拡張機能に進み、ディレクトリを参照するか、開発者向けセクションからバンドルされた.mcpbパッケージをインストールし、パッケージが要求する設定を入力します。APIキーなどの必須値はインターフェース上で入力し、機密フィールドはオペレーティングシステムのセキュアストアで暗号化されます。ディレクトリの拡張機能は自動更新されますが、非公開で配布されたものは新しいバージョンが出たときに手動で再インストールする必要があります。

ベンダーがパッケージを提供せずJSONスニペットだけを渡してくる場合でも、手動の経路はなくなっていません。場所が変わっただけです。デスクトップアプリのメニューを開き、設定、次にDeveloperを選び、edit-configコントロールを使います。このコントロールは、ファイルがなければ作成し、あれば開きます。macOSではこのファイルは~/Library/Application Support/Claude/claude_desktop_config.jsonにあり、Windowsでは%APPDATA%\Claude\claude_desktop_config.jsonにあります。ほとんどのローカルサーバーはnpx経由で起動され、Node.jsのインストールが必要です。また、アプリがこのファイルを読むのは起動時だけなので、完全に終了して再起動するのは、縁起担ぎの一手間ではなく手順の一部です。

リモートサーバーは3つ目の経路を取り、ネットワーク的にも本当にリモートです。ClaudeはあなたのデバイスではなくAnthropicのクラウドからサーバーに到達します。これには、多くの人が苦労して気づく2つの結果があります。サーバーは公開で到達可能でなければならず、プライベートネットワークにバインドされたサービスは、接続前にそのレンジを許可リストへ追加する必要があります。また、コネクタはファイルパスではなくOAuthで認証します。そのため、サーバーのコードを一度も実行したことのないマシンでもリモートコネクタは動作します。

個人アカウントの場合、カスタマイズ設定のコネクタ画面でカスタムコネクタを追加し、サーバーのURLを貼り付けます。サーバーが動的なクライアント登録に対応していない場合は、詳細セクションでOAuthのクライアントIDとシークレットを指定できます。組織プランでは、オーナーが組織レベルでコネクタを追加し、メンバーが個別に認証します。プランの制限が適用され（無料アカウントではカスタムコネクタは1つまで）、ドメインがディレクトリの掲載と一致しない限り、コネクタはcustomとして表示されます。

両アプリで共通の設定フォーマット

見た目は異なっても、内部のエントリは同じオブジェクトです。リモートサーバーはtype、url、任意のheadersで構成されます。ローカルサーバーはcommand、そのargs、任意のenvironmentブロックです。ベンダーのドキュメントと自分のファイルが食い違うときは、この形と比較してください。

{
  "mcpServers": {
    "remote-example": {
      "type": "http",
      "url": "https://mcp.example.com/mcp",
      "headers": { "Authorization": "Bearer YOUR_TOKEN" }
    },
    "local-example": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@example/mcp-server"],
      "env": { "CACHE_DIR": "/tmp" }
    }
  }
}

このオブジェクトの3つの細部が、避けられたはずの失敗の多くを引き起こします。commandに相対パスを持つstdioエントリは、作業ディレクトリが変わった瞬間に壊れるため、絶対パスを使ってください。JSON文字列内のWindowsパスは、バックスラッシュをエスケープしないとファイルが不正な文字列としてパースされます。また、typeがまったくないリモートエントリはローカルサーバーとして解釈され、URLではなくcommandが見つからないという紛らわしいエラーになります。

2つのアプリが分かれるのは名前の付け方です。Claude Codeは英数字、ハイフン、アンダースコアのみの名前を要求しますが、デスクトップ設定のキーはもっと寛容です。両方で同じ名前にしておくのが、自分のメモを正確に保つ最も手軽な方法です。

認証情報、変数、そして${VAR}の罠

設定ファイルにトークンをハードコードすると、シークレットがリポジトリに入り込みます。そのためMCP設定は変数展開に対応しています。構文には基本形とデフォルト値付きの2つの形があり、展開はcommand、そのargs、environmentブロック、url、headersに適用されます。

{
  "mcpServers": {
    "api-server": {
      "type": "http",
      "url": "${API_BASE_URL:-https://api.example.com}/mcp",
      "headers": { "Authorization": "Bearer ${API_KEY}" }
    }
  }
}

罠があるのは変数が見つからないときの挙動で、変数の2つのカテゴリで異なります。未設定でデフォルトもない通常の変数は設定を壊しません。サーバーは読み込まれ、ヘルス一覧に変数未定義の警告が表示され、未展開のテキストがそのままの値として使われます。この警告が手がかりですが、見落としやすいものです。

特定の認証情報用変数は、リモートサーバーのurlとheadersでは挙動が異なります。警告なしに空として読まれ、付与したデフォルト値も無視されます。実務上の違いは、前者が大きな音で失敗し、後者が静かに失敗することです。認証されていないリクエストが送られ、接続先が返すエラーが出るだけで、自分の設定の中に原因を示すものは何もありません。変数は正しく設定されているように見えるのにリモートサーバーが認証エラーを報告する場合は、トークン自体を確認する前に、クライアントプロセスが継承した実際の環境を確認してください。

projectスコープのエントリには、より限定的な2つ目のルールがあります。commandや引数でプロジェクトディレクトリの変数を参照する場合は、デフォルト値を指定する必要があります。エントリが読まれる時点でその値が設定されている保証がないためです。プラグイン提供の設定はこれを直接置換するため、同じ要件は適用されません。

接続のトラブルシューティング

外側から内側へ、4つのステップで進めます。サーバーが起動するか、トランスポートが到達するか、ハンドシェイクが完了するか、そしてエージェントが実際に作業できるかです。各ステップには固有の症状があり、最初のステップで失敗するとそれ以降もすべて壊れて見えるため、順序が重要です。

ブラウザサーバーに同じ診断を適用した内容は、Chrome DevTools MCPの設定・既存Chrome接続ガイドで、接続とプロファイルの失敗を順に解説しています。

サーバーが起動しない。 設定からcommandと引数を取り出し、通常のターミナルで実行します。そこで失敗するなら、クライアント側の設定では解決できません。ランタイムの不足、パッケージ名の誤り、存在しないパスのいずれかです。この手順だけでローカルサーバーに関する報告の多くが解決します。設定ファイルを問題から完全に除外できるからです。

トランスポートがサーバーに到達できない。 リモートエンドポイントの場合は、URLがサービスのルートではなくMCPのパスであることを確認し、次に認証情報が実際に届いているかを確認します。接続先からの401や403は、本記事全体で最も明快なシグナルです。クライアントはサーバーに到達し、サーバーが呼び出し元を拒否したという意味なので、上の認証情報のセクションに直行してください。Connection refusedや名前解決の失敗は逆の方向、つまりアドレスやファイアウォールを示します。

ハンドシェイクが止まる、またはツール一覧が空で返る。 起動はするものの最初のやり取りを完了しないサーバーは、壊れているのではなく遅いだけのことがほとんどです。クライアントはMCPサーバーに起動タイムアウトを適用しており、大きなパッケージをnpxで初回ダウンロードするとこれを超えることがあります。パッケージをキャッシュさせるために一度手動でサーバーを実行し、それから再試行してください。接続はするのにツールを公開しないサーバーは別の問題です。起動には成功したのに何も通知していません。多くの場合、提供できるものを持つ前にenvironmentブロック経由で設定を渡す必要があります。

出力が切り捨てられている。 1つのツール結果が会話に寄与できる量には上限があり、出力がより低いしきい値を超えると警告が表示されます。応答が切り詰められているサーバーは、動作しているように見えて、すべての回答の最後の部分が欠けます。サーバーが正当に冗長なのであれば、信頼できないと結論づけるのではなく、意図的に上限を引き上げてください。

projectのサーバーが他の誰にも接続できない。 これは信頼のゲートであり、壊れたエントリではありません。チームメイトがクローンしたばかりの環境では、ワークスペースを信頼し、共有エントリを一度承認する必要があります。まだの場合、サーバーはpending approvalと表示され、ヘルスチェックは実行されません。

MCPサーバーがブラウザセッションを必要とするとき

ブラウザを対象とするサーバーでは、4番目のステップがすべてになります。サーバーは接続し、トランスポートも正常で、ハンドシェイクも完了し、ツール一覧も埋まっているのに、タスクは失敗します。サーバーが操作するブラウザにログイン済みセッションがないか、起動したプロファイルがCookieを保持しているものではないためです。クライアント側の症状はどれも正常に見えます。

その例で使われているサーバーはmicrosoft/playwright-mcpで、ツール一覧と既知の問題はここで管理されています。

Claude Code内でエージェントがブラウザに到達する方法を広く知りたい場合は、5つのブラウザ経路の比較.

このレイヤーを担っているのはego (lite)です。どの製品なのかを正確に述べておきます。MCPサーバーではなく、ツールも一切登録しません。すでにログイン情報を持つブラウザの中でエージェントに作業させるために作られたブラウザであり、隣に並ぶ新しい自動化プロファイルではありません。エージェントとそのブラウザの接続は、エージェントとツールの接続とは別の関心事です。MCP接続を保持するのはClaude CodeまたはClaude Desktopで、ego-browserがブラウザセッションを保持します。セッションは分離されたSpaceに保存されるため、エージェントの作業が使用中のウィンドウと衝突しません。ブラウザMCPサーバーが空のページ、ログインリダイレクト、見えない要素を返す場合、修正が必要なのは、いま確認した設定の中ではなく、ほぼ常にこの境界のブラウザ側です。

ブラウザサーバーをまだ選んでいない場合は、Claude Code向けのブラウザMCP比較で、各選択肢が何に到達でき、いくらかかるかで比較しています。

MCP、コマンドラインツール、ブラウザ拡張機能、エージェント向けに作られたブラウザは4つの異なるレイヤーであり、どれを選ぶかは、どれがより高機能かではなく、ウィンドウの所有者が誰かという問題です。実用的な判断基準はタスクが何を必要とするかです。認証済みセッションに到達でき、許容できるトークンコストで、自分のものであり続けるウィンドウで動くサーバーであること。判断が下されるのはこの最後のステップであり、ステータス行に何と表示されていても変わりません。

レイヤーごとのトレードオフは、MCPとCLIの比較、そしてブラウザ拡張機能の位置づけ.

サーバーを接続すると何を許可することになるか

サーバーを接続することは機能を付与することであり、先ほどのスコープ表は権限表も兼ねています。userスコープのサーバーは、自分が書いていないものも含め、開くすべてのプロジェクトに存在します。projectスコープのサーバーは、リポジトリをクローンする全員に存在します。どちらもそれ自体が悪いわけではありませんが、セットアップから1か月もすると忘れがちです。

3つの習慣でリスクのほとんどをカバーできます。認証情報はコミットされるファイルではなく環境変数に置き、projectスコープのエントリは移動するものだと覚えておきましょう。まだ評価中のサーバーはlocalスコープにインストールします。削除はコマンド1つで済み、バージョン管理には何も入りません。サーバーのアクセス範囲が仕事より広い場合（1つのフォルダを編集するためにホームディレクトリを指したファイルシステムサーバー、ログイン済みの全アカウントに到達できるブラウザサーバーなど）は、設定を狭める前に付与する権限を狭めてください。

何かを付与する前に他のサーバーが何を公開しているか見たい場合は、公式のMCPサーバーリポジトリにリファレンス実装とそのスコープが掲載されています。

サーバー定義は接続後にコンテキストも消費します。MCPのトークン使用量を減らす方法で、トレードオフのその側面を解説しています。

ユーザーインターフェースはこの違いを裏付けています。リモートコネクタはベンダーのクラウドから実行され、それに伴うネットワーク到達範囲を持ちます。一方、ローカルサーバーはあなたのマシン上で、あなたのアカウントの権限で実行されます。だからこそ、リモートコネクタのセキュリティ上の問いは「他に誰がそのエンドポイントに到達できるか」であり、ローカルサーバーの問いは「そのプロセスが何に触れられるか」なのです。

よくある質問

1つのMCPサーバーをClaude CodeとClaude Desktopの両方で使えますか？

はい。ただし、各アプリを別々に設定する必要があります。2つのクライアントは異なる設定を読むため、Claude Codeでサーバーを追加してもDesktopには影響せず、デスクトップ拡張機能をインストールしてもClaude Codeでそのサーバーが使えるようにはなりません。両方に置いておくのが最も手間が少ないのはリモートサーバーです。同じURLがどちらでも機能し、異なるのはそれを囲むエントリだけだからです。

サーバーは実際どこで実行されますか？

ローカルサーバーは、クライアントが起動するあなたのマシン上のプロセスで、あなたのユーザーアカウントの権限で動作します。HTTP経由、または非推奨のSSEトランスポート経由のリモートサーバーにはネットワーク越しに到達し、Claude Desktopではその到達元はあなたのデバイスではなくClaudeのクラウドです。一方のアプリでは動作し、もう一方では動作しないときに、最も役立つ区別です。

サーバーがpending approvalと表示されるのはなぜですか？

このワークスペースでまだ承認していない共有プロジェクトファイル由来だからです。pending approvalは接続失敗ではなく設定上の判断なので、クライアントがサーバーに接続してこの表示を出したわけではありません。そのディレクトリで対話型クライアントを一度実行し、ワークスペースの信頼ダイアログを承認して、サーバーを承認してください。次回のチェックでステータスが変わります。

SSEはまだ使えますか、移行すべきですか？

SSEトランスポートは非推奨ですが、まだ受け付けられます。サーバーが両方のエンドポイントを提供している場合はHTTPトランスポートのほうが適しており、最近のバージョンではクライアントはHTTPを優先し、サーバーが受け付けない場合にSSEへフォールバックします。移行は再インストールではなく、エントリのtypeとurlを1行変更するだけです。

サーバーがターミナルでは動作するのにアプリでは動作しないのはなぜですか？

ほとんどの場合、アプリがシェルの環境を継承していないためです。ターミナルにはPATHとエクスポートされた変数があり、GUIアプリケーションからは見えません。そのため、コマンド名だけ指定して起動したサーバーは一方では解決し、もう一方では解決しません。commandには絶対パスを使い、サーバーが必要とする変数は周囲のシェルに頼らずenvironmentブロック経由で渡してください。

サーバーをきれいに削除するにはどうすればよいですか？

Claude Codeでは名前で削除すると、そのエントリを保持しているスコープから取り除かれます。Desktopでは拡張機能をアンインストールするか、エントリを削除して再起動します。手動のファイルは起動時にしか読まれないためです。一方から削除してももう一方からは削除されません。一方のアプリで削除したサーバーがもう一方に出続けるときは、この点を思い出してください。

projectの.mcp.jsonをリポジトリにコミットしてもよいですか？

コミットできますし、それがprojectスコープの狙いでもあります。ただし、ファイルに認証情報は含めず、チームメイトは誰でも一度は承認する必要があります。シークレットの値はエントリが参照する環境変数に置き、コミットしたファイルは、クローンがそれだけで信頼できる設定ではなく、サーバー名とコマンドの一覧として扱ってください。

Claude Codeで追加したサーバーがClaude Desktopに見えないのはなぜですか？

2つのアプリが異なる設定を読むためです。CLIで登録したサーバーはClaude Code独自のスコープファイルにあり、Desktopは拡張機能とDeveloper設定しか読みません。Desktop側でサーバーを追加し直すか、両方を同じリモートURLに向けて、管理する定義を1つにまとめてください。

設定ファイルを編集した後、アプリの再起動は必要ですか？

Claude Codeはサーバー定義を独自のコマンドで読み書きするため、手動での再起動は不要です。Claude Desktopは起動時に手動の設定ファイルを読むため、アプリの外で行った編集は再起動後にのみ反映されます。

サーバー一覧のneeds authenticationとはどういう意味ですか？

サーバーは起動して応答しましたが、サーバーから見た呼び出し元が認可されていません。リモートサーバーの場合、通常はurlまたはheadersの認証情報が届かなかったか、変数展開後に空で届いたことを意味します。他の何かを変更する前に、サーバーの設定を開いて展開後の値を確認してください。