どうもこんにちは。
最近、弊社でもClaudeCodeが普及し始めて、環境整備や知識が必要だなぁと思ったので、まずは記事にします。
この記事は、MCPやSkillsについての深い部分まではお話しません。
また、個人の感想を含みます。
MCPとSkillsの違いってなんだ？
どっちも、AIエージェントのできるタスクの範囲を広げるための方法なんですよね。外部APIを実行したり、知識を取得してきたり。
でもそれぞれ良い点と悪い点があると思っています。Skillsの方がいいに決まってるじゃん！とはなかなか言いづらいんじゃないかなぁって思います。
MCPとは
MCP（Model Context Protocol）は、外部のMCPサーバーを接続することで、エージェントが様々なツールやデータソースを扱えるようにする仕組みです。
MCPの特徴として、エージェント起動時に接続されたMCPサーバーからツール一覧や仕様などの情報を取得するという特徴があります。（静的なツール取得）
簡単に特徴をまとめるとこんな感じ。
- サーバー単位でAPIなどの機能をまとめて提供できる
- 接続するだけでエージェントがその機能を利用可能になる
- ツールの存在や仕様をエージェントが事前に（起動時に）理解する
Skillsとは
Skillsは、CLIやAPIなどを直接実行するための仕組みです。MCPのようにサーバーを介さず、必要な処理を「その場で呼び出す」形に近いです。
エージェント起動時には最小限の情報のみが読み込まれ、処理中に必要な情報を動的に取得するのが特徴です。
- 必要な処理を必要なときに実行
- 起動時のコンテキスト負荷が小さい
- CLI・APIベースで柔軟に拡張可能
MCPのメリット・デメリット
メリット
| メリット | 説明 |
|---|---|
| 導入が簡単 | 接続するだけで機能が使えるため、初期構築のハードルが低い |
| インターフェースが 統一されている |
サーバー側で抽象化されているため、扱いが一貫する |
一番は、初期導入・構築が簡単なことです。多くのMCPサーバはGitHubや記事などでインストール方法などが公開されていて、複雑な設定が必要ないものが多いです。
デメリット
| デメリット | 説明 |
|---|---|
| コンテキスト圧迫 | 起動時に全ツール情報を読み込むため、コンテキストが肥大化しやすい |
| スケールしづらい | ツールが増えるほど初期ロードが重くなる |
| 不要な情報も抱え込む | 実際には使わないツール情報も含まれる |
| MCPサーバ自体の構築の難易度が高い | PythonやTypeScriptを使ってサーバを構築する必要がある |
デメリットしては、コンテキストを圧迫することが一番大きなデメリットではないのかなと思っています。コンテキストエンジニアリングという言葉があるくらい、AIエージェントにとってコンテキストは重要です。コンテキストが圧迫され、汚れてしまうと、AIエージェントの精度は下がってしまいます。また、スケールしづらいのもデメリットです。
Skillsのメリット・デメリット
メリット
| メリット | 説明 |
|---|---|
| コンテキスト効率が良い | 起動時は最小限、必要な情報だけを後から取得 |
| スケーラビリティが高い | Skillが増えても初期負荷に影響しにくい |
| 柔軟な実装が可能 | CLIやAPIを直接扱えるため、細かい制御ができて、無駄な情報を持たない分、効率的に動作する |
| 自作できちゃう | Skillを作るSkillが存在しているので、簡単に作れる（Markdownでサクサク） |
MCPの場合の一番のデメリットである、コンテキストを圧迫することを解決できる部分が一番のメリットです。また、エージェントのできるタスク範囲を簡単に拡張できるところもとても良い点です。
デメリット
| デメリット | 説明 |
|---|---|
| ツール発見性が低い | エージェントが最初から全てを把握しているわけではない |
| 運用設計が必要 | どのタイミングでどのSkillを使うかの設計が重要。自由度が高い分、設計を誤るとエージェントが適切にSkillを使えない |
デメリットとしては、このSkillはこの場面で使うというような運用設計が必要です。使いたい場面によって、SKILL.mdの記載方法やskillsディレクトリ内の各Skillのディレクトリ構成が変わってきます。
Skillは自然言語で書ける範囲ならなんでもできてしまうので、以下のような使用場面によって作り方を変える必要があります。思いつくだけ出してみました。
| Skill例 | 場面 |
|---|---|
| 知識蓄積Skill | 各処理の終了後にナレッジを蓄積する |
| API実行Skill | エージェントがAPIを使用する場面で良きに計らって使用する |
| アプリ画面確認Skill | エージェントがアプリ画面のレビューをしたいときに使用する |
| Mermaid CLI Skill | エージェントがフローチャートやER図を書く時にMermaid CLIを使用する |
ここまででおさらいすると、以下のようなことが言えます。
MCPは「事前に必要な情報をすべて持たせる設計」であり、Skillsは「必要なときに情報へアクセスさせる設計」となっている！
MCPとSkillの使い分けってどうする？
一旦人間に例えてみる
「エージェント with MCP」と「エージェント with Skill」を人間に例えてみましょう。
入社したばかりのチームで「このプレゼン資料を任せたい」もしくは「このデカいプロダクトの開発を任せたい」と言われたとしましょう。
「このプレゼン資料を任せたい」と言われた場合、何を参照してプレゼン資料を作ればいいのか、最初に全て教えて欲しくないですか？
このように、比較的小さなタスクをやる場合には、一度にすべての情報が欲しいものです。これはAIエージェントも同じです。なので、このように比較的小さなタスクをAIエージェントに実行してもらう場合には、エージェント with MCPで足りるというわけです。
あくまでも「足りる」です。
一方で、「このデカいプロダクトの開発を任せたい」と言われた場合、一気に仕様の説明やコード規約の説明やロジックの説明をされてもすべて理解できるわけがないですよね。それに膨大なリファレンスを渡されてもどこを見れば何がわかるのかが不明瞭である場合がほとんどです。
少なくとも、「こういう時はここを見ればいい」という情報があれば、全然違いますよね。
このように、大きなタスクを実行する場合には、すべての膨大な情報を欲しいのではなく、「これをするにはここを見ればいい」というようなナビゲーション的な情報が欲しいわけです。ナビゲーションがあれば都度調べることができます。これと同じことをAIエージェントにできるようにさせたのがSkillです。
イメージ湧きましたか？
MCPが向いているケース
MCPが向いているケースは以下のようなケースじゃないかなぁ...
- 非エンジニアが利用する
- とにかくすぐ使いたい
- ツール数が比較的少ない
- プロトタイピングやPoC
すぐ使いたいや小規模タスクから始めたいというニーズに向いているんじゃないかと思います。
Skillsが向いているケース
- エンジニアが設計・運用する
- ツール数が多い
- ツールが今後増える前提
- コンテキスト効率が重要
- パフォーマンスや制御が必要
コーディングなどの大規模なタスクやどんどんエージェントの幅を広げたいというニーズには向いていると思います。
まとめ
「このタスク、AIに任せたいなぁ...」ってなった時は、はじめはMCPサーバが存在しているならMCPを使うのが良いと思います。ただ、「MCPでやってることってCLIでコマンド実行したらできるんじゃない？」ということに気づいたりしたら、迷わずSkill化しましょう。
Claude Codeにはskill-developerというSkillがありますんでね、「こんなことをしたいんじゃ！そのためのSkillを作ってくれよな！」って言ったら、すぐにいい感じのが作れます。
あとは使いながらブラッシュアップしていきましょう。使っていく中で「もっとこうしたい」っていうのが出てくるので、そうしたらClaude Codeで「もっとこうしたいんだけど、既存のSkillを改善すればできる？それとも新しいSkillを作成した方が良い？」って相談してあげればいい感じに進められます。
コードとか書いてないけど、伝わってくれるといいな。
以上