MCP・Skill・CLIの使い分け方、3つの判断基準

MCP、Skill、CLIは、どれか一つに統一するものではありません。個人の作業を自動化するならCLI、手順を覚えさせるならSkill、ユーザーごとの権限を扱いながら複数のクライアントへ配布するならMCPが向いています。

2026年2月に公開された「MCP is dead. Long live the CLI」は、MCPの効率に疑問を投げかけました。ただし、効率だけで結論を出すと判断を誤ります。選ぶ前に確認したいのは、エージェントが誰の権限で動くのか、同じ連携を何種類のクライアントへ配るのか、接続先にCLIがあるのか、という3点です。

TL;DR

個人の開発環境では、CLIを基本にしてSkillで手順を補う
ユーザー別の認可、テナント分離、監査が必要ならMCPを検討する
複数のMCP対応クライアントへ同じツールを配布したい場合もMCPが向く
MCPサーバーには外部データやローカル環境へ触れる権限があるため、導入元と権限範囲を必ず確認する

まず、3つの役割を分けて考える

MCP（Model Context Protocol）は、AIアプリケーションを外部のシステムやデータソースにつなぐためのオープン標準です。対応クライアントは、MCPサーバーが公開するツールを共通の形式で扱えます。

MCPはローカルツール向けの実験から始まり、現在は本番環境での利用を前提に仕様が更新されています。2026年7月28日版では、ステートレスなプロトコルコア、認可の強化、拡張機能の枠組みなどが追加されました。つまり、プロトコルが終わったわけではありません。個人開発の効率と、組織で必要な権限管理を同じ物差しで比べることに無理があります。

能力層：MCP

MCPが扱うのは、AIが利用できるツールです。サーバーがツールの定義を公開し、対応クライアントが実行時にそれを見つけて呼び出します。

プロセス層：Skill

Skillが扱うのは、AIが作業を進める方法です。手順、判断基準、参照資料をまとめ、必要なときに読み込ませます。ツールそのものを追加するMCPとは役割が違います。

実行層：CLI

CLIでは、AIがシェルを介して既存のコマンドを実行します。git、curl、npm、ghなどをそのまま使えるため、個人の開発環境では追加のサーバーを用意せずに済みます。

比較一覧

次元	MCP	Skill	CLI
本質	ツール接続プロトコル	ワークフロー指示（プロンプト）	コマンドラインツール
解決すること	AIに何ができるか	AIがどう作業すべきか	AIが直接実行
媒体	サーバープロセス	Markdownファイル	既存システムツール
クロスプラットフォーム	全MCPクライアント	主にClaude Code	シェルのある全環境
運用負荷	サーバーと認可の管理が必要	主に文書の更新	CLI自体の更新と権限管理
最適な例え	USB-Cポート規格	SOPマニュアル	ポケットのスイスアーミーナイフ

3つは併用できます。Skillで手順を定義し、CLIでローカル作業を実行し、必要な外部サービスだけMCPで接続する構成も可能です。

個人開発ではCLIが有利。ただし比較範囲に注意

Scalekitは2026年3月、同じモデル、タスク、プロンプトを使い、GitHub操作をCLI、CLI＋Skill、MCPで各25回比較しました。結果は次のとおりです。

指標	CLI	MCP（直接接続）	差
トークン消費量（GitHubクエリ）	1,365	44,026	32倍
月額コスト（1万回操作）	$3.20	$55.20	17倍
成功率	100%	72%	CLI優位

単純なリポジトリ照会では、CLIが1,365トークン、MCPが44,026トークンでした。MCP側では43個のツール定義を読み込んだことが差の主因です。25回のMCP実行のうち7回は接続タイムアウトとなり、成功率は72%でした。CLIとCLI＋Skillは、どちらも25回すべて成功しています。

これはGitHubの読み取りタスクを使った75回の比較結果であり、MCP全般の成功率を示す統計ではありません。一方で、個人が自分の権限で既存のCLIを使う場面では、MCPのスキーマや接続が余分な負荷になり得ることは分かります。

3つの質問で選ぶ

1. AIは、複数ユーザーの代理で操作しますか。

ユーザー別のOAuth認可、テナント分離、監査記録が必要なら、MCPを候補にします。ただし、MCPを採用するだけで要件が自動的に満たされるわけではありません。サーバーとクライアントが対応する認可方式を確認してください。

2. 自分の作業を自動化するだけですか。

まずCLIを使い、手順や品質基準が必要ならSkillを加えます。エージェントへ渡すローカル権限は、タスクに必要な範囲へ絞ります。

3. 同じ連携を複数のクライアントで使いますか。

Claude CodeやCursorなど、複数のMCP対応クライアントから同じ社内ツールへ接続するなら、共通サーバーを用意する価値があります。接続先にCLIがあり、利用者も自分だけなら、CLIのほうが単純です。

3つの典型シナリオ

個人でClaude Codeを使い、サイドプロジェクトを開発する

CLIを基本にし、コードレビュー基準やコミット規約はSkillで渡します。

SaaSのユーザーが、AI経由で自分の外部アカウントを操作する

ユーザー別の認可とテナント分離が必要です。MCPの認可モデルを検討し、監査ログやトークン管理まで含めて設計します。

チームが複数の対応クライアントから社内Wikiを検索する

共通のMCPサーバーを用意すれば、クライアントごとに連携を作り直さずに済みます。

セキュリティリスクの開示：MCP利用前に知るべきこと

MCPサーバーは外部データやローカル環境へアクセスします。便利さと同時に、認証、入力検証、サプライチェーンの管理が必要です。

Coalition for Secure AI（CoSAI）は、MCPの脅威を12のカテゴリ、約40項目に整理しています。特に注意したいのは、認証とアクセス制御の不備、プロンプトインジェクション、サーバーや依存パッケージの改ざん、ログ不足です。

ローカルサーバーでも、インストール元を確認する

OX Securityは2026年4月、STDIO方式のMCPサーバーがローカルプロセスとして実行される仕組みに、サプライチェーン上の危険があると報告しました。設定ファイルに登録されたコマンドをクライアントが起動するため、信頼できないサーバーパッケージを追加すれば、ユーザー権限でコードが動く可能性があります。STDIOだから安全、という意味ではありません。

AIエージェントのセキュリティ防御フレームワークについてさらに詳しく知りたい方は、こちらの完全ガイドをご覧ください。

MCP利用前の防御チェックリスト

権限を絞る：タスクに必要なスコープだけを付与し、書き込み権限は必要な場合に限ります。
重要操作を別の仕組みで検証する：LLMの判断だけに任せず、送金、削除、公開などの前に承認や入力検証を置きます。
配布元と実行内容を確認する：パッケージ名だけで判断せず、リポジトリ、実行コマンド、依存関係を確認します。
ログを残す：誰が何を許可し、どのツールが何を実行したか追跡できるようにします。

まとめ

自分の環境だけを自動化するなら、CLIから始めてください。作業手順を繰り返し使うならSkillを加えます。

複数ユーザーの権限を扱う、または同じツールを複数の対応クライアントへ配布するなら、MCPを検討する段階です。その場合は接続できるかだけでなく、認可、ログ、障害時の復旧まで確認してください。

Skillを作る場合はコミュニティSkillsとAgent Fleetのガイド、MCPサーバーを選ぶ場合はおすすめMCPサーバーのガイドも参考にできます。