概要
AI業界では「Skills」がLLMの新標準として推進されているが、MCP（Model Context Protocol）の方が実用的で優れていると主張。 Skillsは知識伝達や既存ツールの使い方には有効だが、サービス連携にはMCPが最適。 MCPはAPI抽象化・認証・自動更新・ポータビリティなど多くの利点を持つ。 Skills中心の運用はCLI依存や運用の煩雑化など多くの課題を生む。 理想は「Skills＝マニュアル」「MCP＝コネクタ」として併用すること。
Skills偏重への疑問とMCP支持の理由
- AI業界全体 で「Skillsが新標準」「MCPは時代遅れ」との論調が強まる現状
- Claude Code, Codex, Gemini, ChatGPT, Perplexity など多様なAI・LLMを日常的に活用
- Skills は知識伝達や既存ツール利用には便利だが、サービス連携には向かない
- MCP の存続を希望。CLIやマニュアルだらけの未来は避けたい
MCPの優位性
- API抽象化 による「何をするか」だけをLLMに伝え、実装方法はサーバー側に任せる設計
- ゼロインストール ：リモートMCPサーバーならローカルインストール不要
- シームレス更新 ：サーバー更新で全クライアントが即時最新状態に
- 認証の簡素化 ：OAuth等で安全に認証。秘密情報の手動管理不要
- 高いポータビリティ ：Mac・スマホ・Web等、どこからでも同じ操作性
- サンドボックス化 ：LLMにローカル実行権限を与えず、安全な操作
- スマート発見 ：必要なツールのみ検索・読み込み、コンテキスト節約
- 自動アップデート ：npxやuv経由のローカルMCPも毎回自動更新
Skillsの課題と摩擦
- CLI依存 ：多くのSkillsがCLIのインストールを要求。Web版LLM等では利用不可
- デプロイの煩雑さ ：CLIの配布・管理・インストールが必要
- 秘密情報管理の困難 ：APIトークンの安全な保管場所が環境ごとに異なる
- エコシステム断片化 ：Skill管理方法がツールごとにバラバラ。互換性も低い
- コンテキスト肥大化 ：SKILL.md全文読込でLLMのコンテキストを圧迫
- 「まずCLIを入れて」問題 ：余計な抽象化・手順追加が発生
適材適所の提案
- MCPの活用シーン
- Webサービスやアプリとの連携インターフェース標準
- 例：Google Calendar、Chrome、Hopper、Xcode、Notion等のMCPエンドポイント
- Skillsの活用シーン
- 知識伝達・手順マニュアル・社内用語や運用ルールの教育
- 既存コマンドの使い方説明やPDF操作等のノウハウ共有
- 秘密管理手順やリポジトリごとのTipsの集約
コネクタvsマニュアルという整理
- Skills＝LLM_MANUAL.md として位置づけ、知識やノウハウの伝達に特化
- MCP＝Connector として、実際のサービス接続・操作を担当
- 両者の併用 で「実行はMCP、知識補完はSkill」という理想的な体制
- 実例 ：DEVONthink用MCPサーバー、microfnやKikuyoのリモートMCP、MCP NestによるローカルMCPのクラウド化
- SkillはMCPのチートシート として活用。MCPの運用ノウハウや落とし穴をSkillにまとめ、毎回の学習コスト削減
今後の展望と希望
- 業界標準としてのMCP存続 を強く希望
- 公式MCPエンドポイント （Skyscanner, Booking.com, Trip.com, Agoda.com等）の普及を期待
- MCP Nest などを活用し、ローカルMCPのリモート利用を推進
- 分断されたCLI文化ではなく、標準化されたコネクタ文化 への移行がAI統合の鍵
要点まとめ
- Skillsは「知識・手順マニュアル」、MCPは「サービス接続コネクタ」として役割分担
- CLI依存のSkills乱立はUX・運用面で逆行
- 標準化・自動化・安全性の観点からMCPの普及・維持が不可欠
- 両者のハイブリッド運用が最も実用的