私は今でもSkillsよりMCPを好む

(david.coffee)

6 ポイント投稿者 GN⁺ 20 일 전 | 6件のコメント | WhatsAppで共有

MCP は、LLMがツールの内部構造を知らなくても処理を依頼できる API抽象化ベースの標準インターフェース であり、リモート利用と自動更新をサポートする
Zero-Install構造、OAuth認証、サンドボックス型セキュリティ により、インストール負担と権限の問題を減らし、どのプラットフォームでも同じ環境を提供する
一方 Skills は、CLIインストールへの依存、認証・デプロイの複雑さ、プラットフォームごとの互換性問題などにより、実際の実行環境では摩擦が大きい
Skillsは知識レイヤー、MCPは接続レイヤー として区別すべきであり、LLMが外部システムと相互作用するときはMCPを、手続き的知識の伝達にはSkillsを使うのが適切
MCP Nest のようなクラウドトンネリングサービスにより、ローカルMCPサーバーへリモートからアクセスでき、標準化されたAI統合環境 を構築する中核と評価される

MCPの利点

Model Context Protocol（MCP） は、LLMがツールの内部動作を理解していなくても、単にリクエストするだけで作業を実行できる API抽象化構造 に基づいている
- 例: LLMがDEVONthinkとやり取りする際、devonthink.do_x() を呼び出せば、MCPサーバーがすべての処理を担当する
Zero-Installのリモート利用 が可能で、クライアントはMCPサーバーのURLを指定するだけで、追加インストールなしにすぐ動作する
自動更新 をサポートしており、リモートMCPサーバーが新しいツールやリソースに更新されると、すべてのクライアントが即座に最新バージョンを利用できる
OAuthベースの認証 によりセキュリティが強化され、ユーザーが自分でトークンを管理する必要がない
移植性 が高く、Mac・モバイル・Webなど、どの環境からでも同じMCPサーバー経由でアクセスできる
サンドボックス構造 により、ローカル環境での直接実行権限を制限し、制御されたインターフェースだけを公開する
スマート検索と自動更新 機能により、必要なツールだけを読み込み、ローカルインストール時でも実行時に自動更新できる

Skillsの限界と摩擦

Skills は、LLMに特定の知識や使い方を教えるには有用だが、実際の動作を行う際には CLI依存性 が問題になる
多くのSkillは別途CLIのインストールを要求するが、ChatGPT・Perplexity・ClaudeのWeb版などではCLIを実行できない
その結果、次のような問題が生じる
- デプロイの複雑さ: CLIをバイナリ・NPM・uvなどで配布・管理しなければならない
- シークレット管理の問題: 認証トークンを .env ファイルに平文保存したり、セッションが初期化されると認証が失われたりする
- エコシステムの分断: Skillのインストール・更新方法がプラットフォームごとに異なり、互換性問題やYAMLパースエラーが発生する
- コンテキストの浪費: LLMが単一の関数呼び出しだけを必要としていても、SKILL.md 全体を読み込まなければならない
「まずCLIをインストールせよ」という指示を含むSkillは不要な複雑さを追加しており、リモートMCP に置き換えたほうが効率的である

適切なツール選択の基準

MCPを使う場面: LLMがWebサイト・サービス・アプリケーションなど外部システムと接続するとき、標準インターフェースとして活用する
- 例: Google CalendarはOAuthベースのリモートMCPで認証と実行を処理すべきであり、CLIのインストールを要求すべきではない
- Chrome・Hopper・Xcode・Notionなども、それぞれの機能制御のための 組み込みMCPエンドポイント を提供するのが理想的
Skillsを使う場面: 純粋な知識伝達と文脈提供に集中すべき
- すでにインストール済みのツール（curl, git, gh, gcloud）の使い方を教える用途
- 組織内の用語・業務フロー・文体の標準化
- PDF処理やシークレット管理（fnox の使い方など）のような 手続き的知識の共有
Skillsは 知識レイヤー、MCPは 接続レイヤー として区別されるべきである

コネクタとマニュアル

SkillsとMCPの役割を明確に区別するため、Skillsは LLMマニュアル（LLM_MANUAL.md）、MCPは コネクタ（Connector） と呼ぶべきだという提案
実際に運用されている例
- mcp-server-devonthink: LLMがDEVONthinkを直接制御できるローカルMCPサーバー
- microfn: mcp.microfn.dev でリモートMCPを提供
- Kikuyo: mcp.kikuyo.dev でリモートMCPを提供
- MCP Nest: ローカルMCPサーバーをクラウドへトンネリングしてリモートアクセス可能にするサービス（mcp.mcpnest.dev/mcp）
一部のプロジェクトではCLI向けSkillも併せて提供しているが、MCPの使い方を説明するSkill のほうが有用である
- Skillは、MCPの機能・ツールの関係・使うべき場面などを説明する 知識レイヤー として機能する
- MCPは実際の接続と実行を担当する
この組み合わせにより、LLMは反復的な試行錯誤なしで効率的にMCPを活用できる

MCPとSkillの併用活用

MCPの利用中に見つかった 日付形式のエラーや検索制限などの直感的でないパターン をSkillとして整理し、再利用する
こうして作成されたSkillは、MCPの チートシートの役割 を果たし、LLMが不要なトークン消費なしに正確に動作できるよう支援する
.claude/skills フォルダを通じてプロジェクトごとのAI行動指針を維持し、よく使う手順をdotfilesの形で管理する
AI統合の未来は標準化されたインターフェース（MCP） にかかっており、CLIベースの断片化したアプローチ は避けるべきである
Skyscanner・Booking.com・Trip.com・Agoda.com など主要サービスによる公式MCP提供が期待される

MCP Nestの紹介

MCP Nest は、ローカル専用のMCPサーバー（Fastmail、Gmailなど）を クラウドトンネリング によってリモートアクセス可能にするサービス
Claude・ChatGPT・Perplexity など、MCP対応クライアントで同様に利用できる
ローカルマシンを直接公開しなくても、すべてのデバイスで同じMCP環境 を維持できる

6件のコメント

jujumilk3 20 일 전

単に両者はまったく別物なのに、なぜこういう話がずっと出てくるのでしょうか

xguru 20 일 전

記事の最後にMCP Nestの宣伝をしないといけないので… ふふふ比較的な主張がかなり支持を集めているみたいですね

jjw9512151 20 일 전

Skillsは剣術で、MCPは剣です……用途が異なり、どちらも必要ですね。

ide127 20 일 전

SkillsとMCPはそれぞれ異なる役割を持つものなのに、こういう記事のせいで混同が生じ続けている気がします。