MCPのツール説明とAgent Skills — それぞれの役割

2026-08-14

MCPのツール説明は、呼び出せる関数1つに紐づいた1文です。何をするのか、何を受け 取るのか、何かを変更するのか。それはクライアントがモデルへ送るすべてのリクエスト に、ほかのすべてのツールの説明と並んで乗っていきます。スキルはSKILL.mdという ファイルを含むフォルダで、手順が入っています。これをして、次にあれを確認して、 このことは先に尋ねる。その本文は、モデルがあなたのリクエストと合致すると判断した ときにだけ読み込まれます。

違いはこれだけで、しかもそれはテキストがいつコンテキストに入るかの違いであって、 テキストに何が書かれているかの違いではありません。説明は入場料です。すべての説明 の分を、毎ターン、ずっと払い続けます。スキルの指示は、必要になるまで無料です。 だからこそ、ツール説明では到底正当化できない段落 — 溜まった会議の録音をどう さばくかについての300語 — も、スキルの中ならまったく妥当なのです。

この記事は、自分の指示をどちらに置くかを決める話です。プロトコル自体が初めてなら、 まずMCPサーバーとは何かで語彙を押さえ、 MCPとプラグイン・従来の連携の違いで、 従来のつなぎ方に対してMCPがどこに位置するのかを見てください。

ツール説明に書けること、書けないこと

MCPの仕様では、ツールの定義は小さく決まった形をしています。name、任意の人間 向けのtitle、description、引数を記述するinputSchema、任意のoutputSchema、 そしてannotations — 読み取り専用かどうかなど、ツールの振る舞いを記述する任意 のプロパティです。クライアントはtools/listの呼び出しで一覧をまるごと取得し、 モデルの前に置きます。MCPのツールがモデル制御と呼ばれるのはこのためで、会話に 応じてモデル自身が選びます。

この形はただ1つのことが得意です。1回の呼び出しが何をするかをモデルに伝え、正しい ものを選ばせること。一方で、構造上どうしても不得手なことが3つあります。

順序を書けません。 ツールの定義のどこにも、「チャンネルが存在していて、 ユーザーがそれを選ぶ必要があるので、share_to_channelの前にlist_channelsを 呼ぶこと」とは書けません。それぞれの説明は孤島です。

多くを入れられません。 すべての説明は、すべての会話のすべてのリクエストで コンテキストに入ります。そのツールに一生触れない会話も含めてです。15個のツールを 持ち、それぞれに1段落ずつ書いたサーバーは、ユーザーが何かを打ち込む前に、 コンテキストウィンドウのかなりの部分を使い切っています。

あなたの判断を書き込めません。 「誰に見せてよいか確信が持てないときは、共有 せずタグを付けること」は方針であって、関数の説明ではありません。同じツールに対し、 2つのチームは2つの違う方針を望みます。

プロトコルに逃がし弁が1つだけあります。クライアントの接続時にサーバーは instructionsという文字列を返すことができ、クライアントはそれをシステム プロンプトに — ツール一覧より前に — 加えることができます。ここは短い案内を置く のに適した場所です。このサーバーは何か、何につながっているか、何に注意すべきか。 ただし注意が2つ。これもセッション単位のテキストなので、短く保ちます。そして仕様 はクライアントができると書いているだけで、必須とはしていません。実際にモデルへ 見せるかどうかはクライアントによって異なります。

スキルが足すもの

スキルはSKILL.mdというファイルを含むディレクトリです。nameとdescriptionを 持つYAMLフロントマター、その後にマークダウンの指示が続きます。隣にほかのものを 同梱することもできます。実行可能なコードのためのscripts/、詳しい文書のための references/、テンプレートのためのassets/です。エージェントは、指示がそちらへ 送ったときにだけそれらを読み込みます。

この読み込みの仕組みはプログレッシブディスクロージャー（段階的開示）と呼ばれ、 仕様は3つの段階に分けて説明しています。

1. 発見。 起動時、エージェントは利用できる各スキルのnameとdescription だけを読み込みます。予算はスキル1つあたりおよそ100トークン。いつ関係しそうか が分かるだけで、それ以上ではありません。
2. 起動。 タスクが説明と合致すると、エージェントはSKILL.mdの本文をすべて コンテキストに読み込みます。推奨はおよそ5,000トークン以内、本体のファイルは 500行以内です。
3. 実行。 同梱のスクリプトや参照ファイルは、指示が実際にそれらへ手を伸ばした ときだけ読み込まれます。

つまり、スキルを20個入れておく代償は短い説明20個です。長いツール説明を20個持つ 代償は、毎ターンの長いツール説明20個です。この非対称性こそが、この層が存在する 理由です。

この形式はクライアント固有のものではありません。Agent SkillsはAnthropicが開発し、 agentskills.ioで公開されたオープンな標準として出されています。そこのクライアント 紹介には、同じフォルダを読む数十の製品が並んでいます。Claude Code、Claude、 ChatGPTとCodex、Cursor、VS Code、GitHub Copilot、Gemini CLI、Goose、Roo Code、 Kiro、Junie、Amp、Factory、Tabnine、Snowflake Cortex Code、Databricks Genie Code などです。2026年8月14日に確認しました。

必須のフロントマターは意図的に薄くしてあります。nameは最大64文字、小文字・ 数字・ハイフンで、親ディレクトリ名と一致していなければなりません。description は最大1,024文字で、そのスキルが何をするかといつ使うかの両方を書くべきです。 その文字列こそ、エージェントがファイルを開くかどうかを決める唯一の根拠だから です。任意のフィールドはlicense、compatibility、metadata、そして実験的な allowed-toolsです。

このdescriptionは、一般に払われているよりも多くの注意に値します。「会議メモを 手伝います」では何にも確実には合致しません。「最近の録音を確認して整理する。 タグを付け、話者に名前を付け、チームチャンネルに属するものを共有する。ユーザーが 片付け・仕分け・追いつきを求めたときに使う」なら合致します。

第3の層 — 毎セッション読み込まれるファイル

呼び出しごとの説明と、必要に応じて読まれるスキルのあいだに、そのどちらでもない層 があります。あなたが何を頼んだかに関係なく、エージェントがセッションの最初に読む ファイルです。

AGENTS.mdが最も素朴な形です。標準のマークダウンで必須フィールドはなく、 ディレクトリツリーをさかのぼって直近のファイルが読まれます。公式サイトは 60,000を超えるオープンソースプロジェクトでの利用を報告し、OpenAI Codex、 Google JulesとGemini CLI、Claudeのエージェント、GitHub Copilotのコーディング エージェント、Aider、VS Code、Cursor、Zed、Warp、Factory、goose、Roo Code、 Devin、Junieでの対応を挙げています。2026年8月14日に確認しました。

Cursorのルールは同じ発想にスイッチを付けたものです。.cursor/rulesに.mdc ファイルとして置かれ、それぞれがいつ含まれるかを3つのフロントマターのフィールド が決めます。alwaysApply: trueはすべてのチャットセッションに入れます。 descriptionがあるとエージェントが関連性を判断します。globsは該当するファイル が開かれているときに結び付けます。どれも設定しなければ、そのルールは@で言及した ときにだけ届きます。CursorはAGENTS.mdにも対応しており、いまはAgent Skillsにも 直接対応しています。スキルは.cursor/skills/または.agents/skills/に置かれ、 条件を満たす動的ルールやスラッシュコマンドをスキルへ変換する移行ツールもあります。 2026年8月14日に確認しました。

いまの2段落を読み返すと、型が見えてきます。形式は収束したが、読み込みの仕組み は収束していない。 いまやSKILL.mdはどこでも読まれます。しかしalwaysApplyの ルールとAGENTS.mdのブロックはセッションの範囲、スキルはタスクの範囲であり、 形式の互換性がいくら進んでもそれは変わりません。

実務上の帰結は、形式の細部よりも価値のある目安です。

長いもの、条件付きのもの、ときどきしか当てはまらないものは、すべてスキルへ。 よくある失敗は、特定の製品向けの手順150行をグローバルのAGENTS.mdに置いてしまい、 午後じゅう無関係なバックエンドを触っているあいだも、それがコンテキストに居座る というものです。

会議メモではどう見えるか

Speak-YはMCPサーバーを同梱しており、2つの層が目に見えて別の仕事をしているという 点で、なかなか良い例になっています。

ツール説明は呼び出しを受け持ちます。録音を検索する、文字起こし・要約・アクション アイテムを読む、チャンネルとタグを一覧する。さらにアプリが動いていれば、録音に タグを付ける、話者の名前を変える、タイトルを付け直す、文字起こしをやり直す、 チームチャンネルへ入れる。それぞれに読み取りか変更かを示すアノテーションが付いて いて、だからこそクライアントは変更系を実行する前に確認でき、--read-onlyも、 覚えておくべきツール名の一覧ではなくスイッチ1つで済みます。読み取りはあなたの マシン上のライブラリに対してローカルで行われ、変更系のコマンドは動作中のアプリを 通り、そこに記録が残ります。詳しくは 書き込み権限を安全にするものを どうぞ。

スキルは仕事のほうを受け持ちます。設定 → 連携から連携を導入すると、Speak-Yは サーバーの設定の隣に整理用のスキルを書き出します。録音の山をさばくときどこから 始めるか、タグが正解のときとチャンネルが正解のとき、実行前に確認すべき操作は どれか。説明にはこれは収まりませんし、サーバーのinstructionsが受け止めようと すべきものでもありません。

書き方も、読み込みの仕組みが報いる形になっています。詳しいファイルは1か所に1つ 置き、各クライアントには、そのクライアントが読む形式で短い案内だけを渡します。 Claude CodeにはSKILL.md、Cursorには.mdcのルール、CodexにはAGENTS.mdの中の 印を付けたブロック、Gemini CLIにはGEMINI.mdの中の同じブロック。セッション範囲 のクライアントに案内だけを渡すのは、まさにセッション範囲だからです。他人の バックエンドをデバッグしているあいだ、会議メモについての150行が居座るべきでは ありません。ブロックは印のあいだに置かれるので、入れ直してもその部分だけが 置き換わり、ファイルの残りには触れません。

MCPサーバー自体は、Freeを含むすべてのプランで無料です。ワンクリック導入と各 クライアントの手動設定はAIアシスタント（MCP）にまとめてあります。

実際にどう判断するか

順番に3つの質問です。

その指示は1回の呼び出しを説明していますか。 ならばツール説明で、1文か2文に 収まるはずです。3文目を書き始めていたら、それはスキルを見つけたということです。

タスクに関係なく、どのセッションでも真ですか。 ならばAGENTS.mdか常時適用の ルールに置けます。ただし「タスクに関係なく」の部分は正直に確かめてください。 「このリポジトリはpnpmを使う」は該当します。「これがうちの会議の仕分け手順です」 は該当しません。

ステップや選択や例外を含む手順を説明していますか。 スキルです。nameと descriptionは本気で吟味してください。振り分けはこの2つの文字列がすべて担って います。そして長いものはSKILL.mdの中ではなく、隣のreferences/のファイルへ 出しましょう。

安いほうに間違えれば、コンテキストは膨らみ、無関係なすべての質問で命中率が下がり ます。高いほうに間違えれば — 手順をツール説明に詰め込めば — モデルは毎ターン あなたの方針を読みながら、それでも従わないかもしれません。説明は、従うべき指示 ではなく関数の文書として読まれるからです。

違いを具体的に見たいなら、実際に繰り返している仕事についてスキルを1つ書き、 それまで貼り付けていたプロンプトと比べるのがいちばん早い試し方です。 会議について AI に聞くためのプロンプト は候補の手頃な出どころです。2回より多く実行しているものが、ファイルに置くべき ものです。

FAQ

MCPのツール説明とスキルの違いは何ですか

ツール説明は、呼び出せる関数1つに紐づいた1文です。サーバーの作者が書き、ツール一覧の一部として毎回のリクエストとともにモデルへ送られます。スキルはSKILL.mdというファイルを含むフォルダで、手順が書かれています。複数のステップ、複数のツール、状況に応じた判断です。モデルがタスクに合うと判断するまで、コンテキストにあるのは名前と説明だけです。説明が答えるのは「この呼び出しは何をするか」、スキルが答えるのは「この仕事をどう進めるか」です。

MCPサーバーのツール説明がすでに良ければ、スキルは不要ですか

1回の呼び出しで終わるタスクなら不要です。必要になるのは、仕事が複数のツールを決まった順に使うとき、2つのツールのどちらが正しいかが説明では運べない文脈に左右されるとき、あるいは同じ手順をセッションをまたいで同じように繰り返したいときです。良い説明は1回ごとの呼び出しを正しくし、スキルは呼び出しの連なりを一定に保ちます。

SKILL.mdはClaude専用の形式ですか

いいえ。Agent SkillsはAnthropicが開発し、agentskills.ioで公開されたオープンな標準として公開されています。そこのクライアント紹介には数十の採用製品が並んでおり、Claude Code、ChatGPTとCodex、Cursor、VS Code、GitHub Copilot、Gemini CLI、Goose、Roo Code、Kiro、Junie、Factoryなどが含まれます。2026年8月14日に確認しました。

AGENTS.mdとスキルはどう違いますか

AGENTS.mdは必須フィールドのないただのマークダウンで、エージェントがディレクトリツリーの直近の場所から読み込み、あなたが何を頼んだかに関係なくセッション全体で読み込まれます。スキルの本文は、エージェントがあなたのリクエストをその説明と照合したあとで初めて読み込まれます。どちらも役に立ちますが、長いものはスキルに置くべきです。AGENTS.mdの内容は、まったく関係のないセッションを含め、すべてのセッションでコンテキストを占めるからです。

SKILL.mdはどのくらいの大きさが適切ですか

Agent Skillsの仕様は、本体のSKILL.mdを500行以内、おおよそ5,000トークン以内に保ち、詳しい参照資料は別ファイルへ移してエージェントが必要なときだけ読み込むようにすることを勧めています。名前と説明の予算はおよそ100トークンです。すべてのセッションが支払うのはこの部分だからです。