Claude Codeを使い込んでいくと、SkillsやMCPを追加したくなります。

コードレビュー、設計、デバッグ、ドキュメント作成、ブラウザ操作、ファイル操作、Figma連携など、拡張できる範囲はかなり広くなっています。

ここでやりがちなのが、便利そうなSkillsやMCPを一度に導入することです。

一見すると強そうですが、実際には指示の競合、権限の肥大化、更新管理の複雑化が起きやすくなります。何が原因で出力が変わったのか分からず、環境がブラックボックス化することもあります。

SkillsとMCPは、多ければ多いほどよいものではありません。

この記事では、両者の役割を整理したうえで、用途に合った最小構成から始める考え方をまとめます。

SkillsとMCPの役割

最初に、SkillsとMCPの違いを整理します。

Skills：作業の進め方

Skillsは、特定の作業に必要な手順、判断基準、参考資料などをClaude Codeへ追加する仕組みです。

たとえば、次のような内容を扱います。

  • React実装のレビュー観点
  • UIとアクセシビリティの確認項目
  • システム設計の進め方
  • バグ調査の手順
  • 技術文書の構成
  • テスト駆動開発の流れ

Skillsが担当するのは、主に「どう進めるか」です。

Claude Codeがすでにアクセスできるコードやファイルを対象に、作業の型を追加します。

MCP：外部への接続

MCPは、Claude Codeから外部のツールやデータへ接続する仕組みです。

たとえば、次のような用途があります。

  • ブラウザの操作
  • 指定ディレクトリのファイル操作
  • Figmaデータの取得
  • データベースや外部APIへの接続
  • 外部サービスに対する読み取りや書き込み

MCPが担当するのは、主に「何へアクセスできるか」です。

Skillsが作業手順を増やすのに対し、MCPは実行可能な操作や接続先を増やします。

役割は競合しない

SkillsとMCPは、どちらか一方を選ぶものではありません。

たとえば、UIレビュー用のSkillで確認手順を定義し、PlaywrightのMCPで実際の画面を操作する、といった組み合わせができます。

Skill
└─ UIレビューの観点と手順

MCP
└─ ブラウザを開いて実際の画面を確認

Skillsは頭脳、MCPは手足と説明されることがあります。

分かりやすい比喩ですが、どちらも銀の弾丸ではありません。プロジェクトの要件や権限設計が曖昧なまま追加すると、むしろ事故の種になります。

SkillsとMCPを導入するときの注意点

便利そうなSkillsとMCPをまとめて入れると、導入直後は強化されたように見えます。

しかし、運用を続けると次の問題が出やすくなります。

指示の競合

似た役割のSkillsを複数入れると、同じタスクに対して異なる手順が候補になります。

たとえば、設計、計画、コードレビューに関するSkillsを大量に追加すると、単純な修正でも過剰な工程が挟まる場合があります。

軽微な文言修正にフルコースの設計レビューが始まれば、さすがにオーバーキルです。

コンテキストのノイズ

Skillsの説明や補助資料は、作業判断の材料になります。

候補を多く入れると、現在のタスクに関係しない情報まで混ざりやすくなります。その結果、回答が冗長になったり、プロジェクト固有のルールより一般論が優先されたりします。

権限の肥大化

MCPは、外部ツールやローカル環境へのアクセスを増やします。

ファイルシステム、ブラウザ、Figma、データベースなどをすべて接続すると、Claude Codeが触れられる範囲も広がります。

使っていない接続であっても、設定上アクセスできるなら攻撃面と誤操作の範囲は増えます。

原因調査の難化

出力や挙動がおかしくなったとき、追加した拡張が少なければ原因を切り分けやすくなります。

一方で、数十個のSkillsと複数のMCPを同時に入れると、どの指示やツールが影響したのか追いにくくなります。

環境を強化したつもりが、デバッグ不能な秘伝のタレになりかねません。

更新管理の負担

SkillsやMCPは更新されます。

指示内容、依存パッケージ、設定形式、必要な権限が変わる可能性があります。

導入数が増えるほど、更新内容の確認、互換性の検証、ロールバック判断も増えます。

最初に決めるべきこと

導入候補を探す前に、現在のボトルネックを一つ決めます。

次のように、困っていることを具体化します。

  • Reactのレビュー観点が担当者によってぶれる
  • バグ調査が場当たり的になっている
  • 実装前のタスク分解が甘い
  • UIを実際のブラウザで確認できていない
  • Figmaから値を転記する作業が多い
  • 長い会話をまたぐと判断経緯を失う

問題が「作業手順」にあるなら、まずSkillを検討します。

問題が「アクセスできないこと」にあるなら、MCPを検討します。

進め方が安定しない
└─ Skillの候補

外部ツールを操作できない
└─ MCPの候補

この順序にすると、目的のない拡張追加を避けやすくなります。

用途別の最小構成

ここからは、よくある用途ごとに最小構成を考えます。

すべての候補を入れるのではなく、実際の作業で必要になったものだけ追加します。

フロントエンド開発

最初は、次の3領域で十分です。

  • Reactやフレームワークの実装レビュー
  • UIとアクセシビリティの確認
  • ブラウザ上の動作確認

Skillsの候補としては、Reactのベストプラクティス、Webデザインガイドライン、コードレビューが挙げられます。

実際の画面操作が必要になった時点で、PlaywrightなどのブラウザMCPを追加します。

Figma連携は、日常的にデザインデータを参照するプロジェクトだけで検討します。たまに色や余白を確認する程度なら、常時接続する必要はありません。

バックエンド開発

バックエンドでは、次の領域を優先します。

  • タスクの分解
  • アーキテクチャ判断の記録
  • コードレビュー
  • システム化されたデバッグ

計画、ADR、レビュー、デバッグに関するSkillsから、一つずつ試します。

ファイル操作のMCPを使う場合は、リポジトリや作業ディレクトリだけを許可します。ホームディレクトリ全体やシステムルートを開放する必要はありません。

データベースへ接続する場合も、最初は読み取り専用、開発環境、限定されたスキーマから始めます。

ドキュメント作成

ドキュメント用途では、扱う形式に合わせて選びます。

  • READMEやAPI文書：technical writer系のSkill
  • 共同執筆：構成整理やレビュー用のSkill
  • PDF：PDF処理用のSkill
  • スプレッドシート：xlsxやCSV処理用のSkill

普段扱わない形式まですべて入れる必要はありません。

READMEしか書かないプロジェクトに、PDF、PowerPoint、Excelのフルセットを入れるのは過剰です。

長期プロジェクト

長期運用では、記憶や履歴管理を追加したくなります。

候補には、次のようなものがあります。

  • プロジェクト内の判断を残すADR
  • ファイルを使った進捗管理
  • 作業ログ
  • セッションをまたぐメモリ

ただし、記憶機能は情報を残せば残すほどよいわけではありません。

古い判断、撤回された仕様、誤った推測が残ると、負債として効いてきます。記憶にも賞味期限と削除ルールが必要です。

まずはリポジトリ内の文書で判断経緯を管理し、それでは足りない場合にメモリMCPを検討する方が安全です。

Skillを選ぶ基準

Skillを追加するときは、次の観点を確認します。

現在の作業に直結するか

「いつか使うかもしれない」ではなく、今週または今月に繰り返す作業かを確認します。

利用頻度が低いものは、必要になったタイミングで追加すれば十分です。

プロジェクトのルールと矛盾しないか

一般的なベストプラクティスが、現在のプロジェクトにそのまま当てはまるとは限りません。

既存の設計方針、対応ブラウザ、採用バージョン、デザインシステム、レビュー基準を優先します。

Skillはプロジェクトルールの代わりではなく、補助輪です。

内容を読めるか

導入前にSKILL.mdと同梱ファイルを確認します。

次の内容が含まれていないかを見ます。

  • 不要なシェルコマンド
  • 外部へのデータ送信
  • 広すぎるファイル操作
  • 自動的な書き込みや削除
  • 追加の認証情報

Skillを入れることは、プロンプト集を置くだけとは限りません。

MCPを選ぶ基準

MCPでは、機能より先に権限を確認します。

最小権限

アクセス範囲は必要な場所だけに限定します。

ファイルシステムなら対象リポジトリ、データベースなら開発環境の読み取り権限、Figmaなら必要なファイルへのアクセスだけにします。

避けたい設定
└─ ホームディレクトリ全体を読み書き可能

最初の設定
└─ 対象リポジトリだけを読み取り可能

読み取りから開始

書き込み、削除、公開、送信を伴う操作は、読み取りよりリスクが高くなります。

最初は読み取り中心で動作を確認し、必要性が明確になってから書き込み権限を追加します。

テスト環境

ブラウザ操作や外部サービス連携は、本番アカウントではなくテスト環境から試します。

フォーム送信、ファイル更新、データ変更を伴うMCPは、操作ミスがそのまま実データへ反映される可能性があります。

認証情報の管理

API Keyやアクセストークンを設定ファイルへ直書きしない運用を基本にします。

環境変数、秘密情報管理、権限の分離を使い、リポジトリへコミットしないようにします。

導入の順序

SkillsとMCPは、次の順序で追加すると切り分けやすくなります。

  1. 現在のボトルネックを一つ決める
  2. 対応するSkillを一つ追加する
  3. 小さなタスクで動作を確認する
  4. 必要な外部操作がある場合だけMCPを追加する
  5. 権限を最小に設定する
  6. 結果と問題点を記録する
  7. 必要性を再評価してから次を追加する

この進め方なら、どの拡張が効果を出したのか判断できます。

スモールスタートは地味ですが、最終的には最もデバッグしやすい構成になります。

構成例

個人のフロントエンド開発

最初の構成は、次の程度で十分です。

  • React実装レビュー用のSkill
  • UI確認用のSkill
  • システム化されたデバッグ用のSkill
  • 必要に応じてPlaywright MCP

Figmaやメモリは、実際に困り始めてから追加します。

チームのWebサービス開発

チームでは、再現性とレビュー可能性を重視します。

  • プロジェクト固有のルールをCLAUDE.mdへ記載
  • タスク計画用のSkill
  • ADR作成用のSkill
  • コードレビュー用のSkill
  • 対象リポジトリだけに限定したファイルアクセス

個人環境へ大量に追加するより、チームで必要な構成を文書化し、同じ条件で検証できる方が重要です。

ドキュメント中心の作業

  • technical writer系のSkill
  • 実際に扱う文書形式のSkillを一つ
  • 公開Webページを読む必要がある場合だけWeb取得用MCP

文書形式ごとのSkillをすべて入れず、案件で扱う形式に絞ります。

定期的な棚卸し

一度追加したSkillsやMCPも、定期的に見直します。

確認する項目は次のとおりです。

  • 直近1か月で利用したか
  • 同じ役割の拡張が重複していないか
  • 権限が広すぎないか
  • 配布元や依存関係が変わっていないか
  • 更新後も期待どおり動くか
  • 無効化や削除の手順が分かるか

使っていないものは無効化または削除します。

拡張環境にも断捨離が必要です。

まとめ

Skillsは作業の進め方を追加し、MCPは外部ツールやデータへの接続を追加します。

両者を組み合わせるとClaude Codeの対応範囲は広がりますが、導入数と開発効率は比例しません。

重要なのは、現在のボトルネックに合うものを一つ選び、小さなタスクで検証することです。

  • 手順を安定させたいならSkill
  • 外部へ接続したいならMCP
  • MCPの権限は最小限
  • 最初は読み取り中心
  • 一度に追加せずスモールスタート
  • 定期的に棚卸し

32個のSkillsや8個のMCPは、すべて導入するセットではなく、必要なものを探すためのカタログとして見る方が扱いやすくなります。

環境を盛ることより、何を入れ、なぜ必要で、どこまで権限を与えたか説明できることの方が重要です。

参考資料