MCPサーバーを1つは繋いだことがある人向け
GitHubのPRレビューやissue作成のような、毎回同じ長い指示文を打っていた作業を、サーバー側が用意したコマンド1発に畳みたい場面で使う。入力欄で / を押して /mcp__サーバー名__プロンプト名 を選び、必要なら後ろに対象(PR番号など)をスペース区切りで書き足して実行する。
MCPサーバーを繋ぐと、そのサーバーが「これ使えますよ」と差し出してくる定型の指示文を、/mcp__サーバー名__プロンプト名 という形のスラッシュコマンドとして呼べます。公式は「MCP servers can expose prompts that become available as commands in Claude Code」と書いていて、つまりサーバー側が作った決まり文句を、入力欄でスラッシュ1つから起動できる仕組みです。
PRレビューやissue作成みたいな、毎回同じ長文を打ち込んでいた作業を、コマンド1発に畳める。ここがこの機能の狙いです。
噛み砕くと
新しい職場の初日に、共有フォルダを開いたら「経費精算はこのテンプレ」「議事録はこのフォーマット」と、よく使う書類のひな形が並んでいた。あの感覚に近いです。
自分でゼロから文面を考えなくても、用意されたひな形を選んで中身だけ埋めれば仕事が回る。MCP Prompts はその「ひな形」を Claude Code の入力欄に並べてくれる機能だと思ってください。
そしてひな形を作ったのは私たちではなく、繋いだサーバーの側です。ここがポイント。だから同じサーバーを繋いだチーム全員に、まったく同じひな形が配られます。
大事な前提:これは「サーバーを繋いだ後」の話
MCP Prompts は、MCPサーバーを1つ繋いでいないと何も出てきません。繋いだサーバーが「プロンプト」という機能を持っていて、初めて入力欄の一覧に並びます。
そしてプロンプトはサーバー側の任意機能です。リソース(@メンションで呼ぶやつ)と同じで、サーバーが対応していなければ / を押しても1つも出てきません。「繋いだのに出ない=そのサーバーはプロンプトを配っていない」ことがあります。
「GitHub MCPサーバーを繋いでPRレビューのコマンドを呼ぶ」を例に手順を見る
実際に GitHub のサーバーを繋いで、サーバーが用意したPRレビュー用のコマンドを呼ぶところまでをやってみます。GitHub MCPサーバーを既に繋いでいる人は、ステップ1は飛ばして大丈夫です。
ステップ1: GitHub MCPサーバーを繋ぐ
ターミナルで次の1行を打ちます。GitHubの個人アクセストークン(PAT)を持っていることが前提です。
claude mcp add --transport http github https://api.githubcopilot.com/mcp/ --header "Authorization: Bearer YOUR_GITHUB_PAT"
YOUR_GITHUB_PAT の部分は、自分で発行した鍵に置き換えます。繋いだ後、Claude Code の中で /mcp を打つと接続状態が見えて、ログインが必要なサーバーはここから認証できます。
ステップ2: 「/」を押して、サーバーのコマンドが並ぶのを見る
Claude Code の入力欄で / を1つ押します。すると使えるコマンドの一覧が出て、その中にサーバー由来のものが /mcp__github__... という形で混ざって並びます。
公式の表現を借りると「MCP prompts appear with the format /mcp__servername__promptname」。mcp とサーバー名の間、サーバー名とプロンプト名の間が、それぞれアンダースコア2個で繋がっているのが目印です。
ここで初心者がよくやる勘違いがあります。/mcp 単体はサーバー管理の画面で、/mcp__github__... はプロンプト実行。どっちも /mcp で始まるので、つい同じものだと思いがちです。別物です。
ステップ3: 何も足さずに呼ぶ
一覧から、追加で何も書かずに叩けるものを選びます。公式の例だとこれ。
/mcp__github__list_prs
これを実行すると、サーバー側が定義したプロンプト(ひな形の指示文)がそのまま会話に流し込まれます。公式は「Prompt results are injected directly into the conversation」と書いていて、結果が会話に直接注入されるイメージです。
ステップ4: コマンドの後ろに対象を書き足して呼ぶ
多くのプロンプトは、コマンドの後ろにスペース区切りで追加の指定を受け取ります。PRレビューなら、レビューしたいPRの番号を後ろに添えます。
/mcp__github__pr_review 456
この 456 がPR番号です。後ろに足した指定は、そのプロンプトが定義している受け取り口に合わせて振り分けられます(公式「Arguments are parsed based on the prompt's defined parameters」)。番号だけ変えれば、同じレビュー処理を別のPRに何度でも回せます。
ステップ5: 複数語をまとめて渡したいときはクオートで囲む
別のサーバーの例ですが、Jira のサーバーでissueを作るときはこう書きます。
/mcp__jira__create_issue "Bug in login flow" high
ここが落とし穴になりやすい。"Bug in login flow" をクオートで囲まないと、Claude Code は Bug in login flow をバラバラの指定として受け取ってしまいます。スペースを含む1つのまとまりは、必ずダブルクオートで囲んでください。
つまり MCP Prompts は何をしてくれるのか
- やってくれる: サーバーが用意した定型の指示文を、
/mcp__サーバー名__プロンプト名のコマンド1発で会話に流し込む。後ろに番号やタイトルを足して中身を切り替えられます - やってくれない: プロンプトそのものを自分で作ることはここではしません。プロンプトを定義しているのはあくまでサーバー側で、Claude Code は並べて呼び出すだけです
- 意味が薄い場面: プロンプト機能を持たないサーバーしか繋いでいないとき。
/を押しても/mcp__...が1つも並ばないので、この機能の出番がありません
使いどころ3シナリオ
シナリオ1: PRレビューの長い指示文を毎回打つのをやめたいとき
「このPRの差分を見て、命名と例外処理とテスト不足を順にチェックして」みたいな長文を毎回打ち込んでいたとします。GitHub MCPサーバーがPRレビュー用のプロンプトを配っているなら、その長文はサーバー側に仕込まれています。
打つのは /mcp__github__pr_review 456 だけ。長文を覚える必要も、コピペ用のメモを探す必要もなくなります。番号を変えれば次のPRへ。
シナリオ2: チーム全員に同じ手順を配りたいとき
社内手順を埋め込んだMCPサーバーを1つ立てて、メンバー全員がそれを繋ぐ運用です。サーバーが「リリース前チェック」「障害報告のひな形」みたいなプロンプトを配れば、全員が /mcp__社内サーバー名__release_check という同じ形で呼べます。
個人ごとにバラバラのプロンプトを書く運用だと、品質も表現もてんでバラバラになる。サーバー側で一括配布すれば、そこが揃います。私はこの「全員が同じひな形を叩く」点がこの機能の一番おいしいところだと思っています。
シナリオ3: 対象だけ変えて同じ処理を量産したいとき
issueを10件まとめて起票する、PRを順番にレビューする。こういう「処理は同じ、対象だけ違う」作業は、後ろに足す指定を変えるだけで回せます。
/mcp__jira__create_issue "ログイン画面のバグ" high
/mcp__jira__create_issue "検索結果が出ない不具合" medium
タイトルと優先度だけ差し替えて連打する。同じ思考を毎回ゼロから組み直さずに済みます。
初心者が踏みやすい落とし穴
- アンダースコアは2個ずつ。
/mcp_github_list_prs(1個ずつ)ではなく/mcp__github__list_prs(2個ずつ)が正解。1個で打つと一覧に出てこず「動かない」と悩むことになります /mcp単体とプロンプト実行を混同しない。/mcpはサーバーの接続状態を見る管理画面。/mcp__サーバー名__...がプロンプト実行。どちらも/mcp始まりなので紛らわしいですが役割は別です- 名前は自動で正規化される。公式「Server and prompt names are normalized (spaces become underscores)」の通り、サーバー側のプロンプト名が「create issue」なら、コマンドでは
create_issueに化けます。元の名前そのままで探すと見つかりません - プロンプトを持たないサーバーには出ない。プロンプトはMCPの任意機能です。繋いだサーバーがプロンプトを配っていなければ、
/一覧に1つも並びません。「出ない=壊れている」ではなく「そのサーバーは配っていない」可能性を先に疑ってください - スペースを含む指定はクオートで囲む。
"Bug in login flow"のように囲まないと、単語ごとにバラバラの指定として割れてしまいます - 繋いだ直後に出ないなら再接続を疑う。プロンプトはサーバーから動的に見つけてきます。公式は
list_changed通知でサーバー側が一覧を勝手に更新できると書いていますが、通知が来ない・反映されないときは一度切って繋ぎ直すと出てくることがあります - これはサーバーが配ったもので、自前のコマンドやスキルとは別物。出どころが違います。Claude Code 自前のスラッシュコマンドや、自分で書いたスキルとは管理場所も更新タイミングも別だと覚えておいてください
書き方
/mcp__servername__promptname スペース区切りで後ろに追加の指定を書き足せる(例: /mcp__github__pr_review 456)。サーバー名とプロンプト名はアンダースコア2個ずつで繋ぐ。
やってみるとこうなる
入力
/mcp__github__pr_review 456
出力例
入力欄で / を押すと、コマンド一覧に /mcp__github__list_prs や /mcp__github__pr_review がサーバー由来として並ぶ。/mcp__github__pr_review 456 を実行すると、サーバー側が定義したPRレビュー用の指示文が会話にそのまま流し込まれる。
このページに出てきた言葉
- MCP
- Model Context Protocol の略。Claude Code を外部のツールやデータベース、APIに繋ぐための共通の決まりごと
- MCPサーバー
- MCPの決まりに沿ってツールやデータを Claude Code に渡してくれる外部サービス側の窓口。GitHubやNotionが公開している
- プロンプト(ここでの意味)
- サーバーが用意した、ある作業をやらせるための定型の指示文。自分で毎回打つのではなく、サーバーが仕込んでくれているもの
- リソース
- MCPサーバーが差し出すデータを <code>@サーバー名:protocol://...</code> の形で参照する別機能。プロンプトとは呼び出し方が違う
- list_changed
- サーバーが「使える機能が変わった」と Claude Code に送る通知。来ると一覧が自動で更新される
- PR
- Pull Request の略。GitHubで「この変更を取り込んでほしい」と出す取り込み依頼
- PAT
- GitHubの個人アクセストークン。APIを使うための、ログインの合言葉代わりの鍵