スキル不足がMCPプロジェクトを破綻させたのか?その真相とは

AIの新潮流における誤解:SkillsとMCPの本質的な関係 🤔

AIに関する新しい技術が登場するたびに、Tech Twitter™は必ず「何かが終わった」と宣言します。

今週の見出しは「SkillsがMCPを殺した」というものでした。

大胆に聞こえるし、自信満々に見えます。でも、これは完全に間違っています。

SkillsがMCPを殺したというのは、GitHub ActionsがBashを殺したと言うようなものです。もちろん、それは真実ではありません。Bashは今でも健在で、実際の作業を行っています。GitHub Actionsが変えたのは表現であって、実行ではありません。ワークフローをより良く記述する方法を提供したのです。「ビルド、テスト、デプロイの方法はこうです」と、よりクリーンで共有しやすい形で表現できるようになりました。しかし、内部では同じシェルコマンドが実行されているのです。YAMLは実行を整理しただけで、置き換えたわけではありません。

これがSkillsとMCPの関係性とほぼ同じです。

この視点で見ると、「SkillsがMCPを殺した」という主張は自然と崩れ去ります。

MCPの本質:実行能力の基盤 🔧

MCPは能力が存在する場所です。AIエージェントが単に会話するだけでなく、実際に何かを実行できるようにするものです。エージェントがシェルコマンドを実行したり、ファイルを編集したり、APIを呼び出したり、データベースをクエリしたり、ドライブから読み取ったり、メモリを保存・取得したり、ライブデータを取得したりできるとき、それはMCPが機能しているということです。

MCPサーバーはコードです。サービスとして実行され、呼び出し可能なツールを公開します。エージェントが現実世界と意味のある形でやり取りする必要がある場合、ほぼ確実にMCPが関与しています。

例えば、エージェントがGitHub APIにクエリを投げたり、Slackメッセージを送信したり、本番環境のメトリクスを取得したりする必要がある場合、実際の統合、実際の権限、実際の実行が必要になります。指示だけではこれを実現できません。

Skillsの本質:プロセスと知識の層 📝

一方、Skillsは異なるレイヤーに存在します。Skillsはプロセスと知識に関するものです。作業をどのように行うべきかをエンコードするMarkdownファイルです。チームの規約、ワークフロー、ドメインの専門知識を捉えます。

Skillは、デプロイメントがどのように行われるべきか、コードレビューがどのように処理されるか、インシデントがどのようにトリアージされるかを記述する可能性があります。これは制度的知識を明示的にしたものです。

例えば、エージェントにSquareアカウントとの統合方法を教えるSkillの例を見てみましょう:

---
name: square-integration
description: Squareアカウントとの統合方法
---

## Square統合

### 認証

- テストキー: `.env.test`から`SQUARE_TEST_KEY`を使用
- 本番キー: 1Passwordの「Square Production」に保存

### 一般的な操作

#### 顧客の作成

const customer = await squareup.customers.create({
  email: user.email,
  metadata: { userId: user.id }
});

#### Webhookの処理

常にWebhook署名を検証すること。ハンドラパターンは`src/webhooks/square.js`を参照。

### エラーハンドリング

- `card_declined`: ユーザーフレンドリーなメッセージを表示し、別の支払い方法を提案
- `rate_limit`: 指数バックオフを実装
- `invalid_request`: 完全なエラーをログに記録、おそらくコードのバグ

よくある混同:実行可能性の錯覚 ⚠️

Skillsには実行可能に見えるものが含まれることがあります。ここが混乱の原因だと思います。Skillにはコードスニペット、スクリプトへの参照、テンプレートやスクリプトなどのサポートファイルが含まれることがあります。そのため、Skill自体が作業を実行しているように感じられるのです。

しかし、そうではありません。

Skillフォルダに実行可能なファイルが含まれていても、Skill自体がそれらを実行しているわけではありません。エージェントは、Developer MCPサーバー経由で公開されるシェルツールなど、他の場所で提供されるツールを呼び出すことでこれらのファイルを実行します。Skillはガイダンスとアセットをパッケージ化しますが、コードを実行したり、ネットワークにアクセスしたり、システムを変更したりする能力は、MCPを介して公開できるツールから来ています。

これはGitHub Actionsの動作とまったく同じです。ワークフローファイルは、スクリプト、コマンド、再利用可能なアクションを参照できます。強力に見えるかもしれません。しかし、YAMLは何も実行しません。ランナーが実行するのです。ランナーがなければ、ワークフローは単なる計画に過ぎません。

相互補完的な関係性:殺人事件は起きていない 💡

Skillsはワークフローを記述します。MCPはランナーを提供します。

だからこそ、SkillsがMCPを置き換えるという主張は意味をなしません。MCPなしのSkillsは、よく書かれた指示書です。SkillsなしのMCPは、ガイダンスのない生の力です。一方はエージェントに何をすべきかを伝え、もう一方は何でもできるようにするのです。

要素	役割	提供するもの	類似例
MCP	実行基盤	実際の能力(API呼び出し、ファイル操作、データベースクエリ)	Bashコマンド、システムランナー
Skills	プロセス定義	手順、規約、ドメイン知識、ベストプラクティス	YAMLワークフロー、ドキュメント

簡潔に言えば、MCPはエージェントに能力を与えます。Skillsはエージェントにその能力をうまく使う方法を教えます。Bashはまだコマンドを実行しています。GitHub Actionsはまだワークフローを定義しています。同じシステム、異なるレイヤー、殺人事件は一切起きていません。

成熟するエコシステムの兆候 🚀

むしろ、両方が存在することは良い兆候です。エコシステムが成熟していることを意味します。もはやエージェントがツールを持つべきか指示を持つべきかを議論しているのではありません。両方が必要だと想定したシステムを構築しているのです。

これは置き換えではなく、進歩です。