API、MCP、CLI、Claude Skill： 違いは何か、いつ何を使うべきか？
REST API、MCPサーバー、CLI、Claude Skill。最近AIツールを少し使ってみようとすると、必ず一度は出くわす単語たちです。どこかで聞いたことはあるけれど、いざ「では私たちのチームは何を使えばいいのか？」という問いの前に立たされると、明確に答えるのが難しいことが多いのではないでしょうか。
組織にAXを導入しようとされている方々の頭の中には、たいてい似たような質問が浮かんでいます。
「MCPだけ繋げば終わりじゃないんですか？」
「どうせAPIがあるんだから、APIを使えばいいのでは？」
「Agent-first時代だと聞きましたが、では全部MCPに移行すべきでしょうか？」
「Skillは…MCPの別の呼び方ですか？」
AIエージェントが使える、似ているようで異なる4つのツールが、それぞれ何で、どう違うのかを整理した記事は、意外にも見つけにくいように思います。そこでこの記事では、各ツールの定義 → 違い → いつ何を使うべきかを一度に整理します。
4つのツール
用語をそろえなければ、比較は成立しません。この記事で扱う4つのツールはどれも、AIエージェントが外部システムと働けるようにするインターフェースです。ただし「登場した時期、動作の仕組み、そして誰が呼ぶのか」という3点が、それぞれまったく異なります。
API (Application Programming Interface)
最も馴染みのあるインターフェース、APIから始めます。APIは2つのシステムが、約束した方法で対話する通路です。通常はHTTPの上でJSONをやりとりします。1990年代以降、ウェブの骨組みとして定着し、いまもすべてのSaaSの底辺のレイヤーをなしています。
# Stripeで決済を作るAPI呼び出し
POST https://api.stripe.com/v1/charges
Authorization: Bearer sk_live_...
Content-Type: application/x-www-form-urlencoded
amount=2000¤cy=usd&source=tok_visa
APIは呼び出す側が誰かを問いません。人がターミナルからcurlで呼んでも、バックエンドのコードが呼んでも、AIエージェントが呼んでも、同じように応答します。だから APIは残りの3つのツールの骨格、つまりskeletonなのです。MCPも、CLIも、Skillも、結局のところ一皮むけば内側でAPIを呼んでいます。
MCP (Model Context Protocol)
2024年11月、Anthropicが発表したオープンソースの標準です。AIエージェントが外部のツールやデータにアクセスする際、常に同じ形式で対話できるよう設計されたプロトコルで、JSON-RPCの上で動作します。
例を見てみましょう。Claude Desktopで「私のGitHubのPR一覧を見せて」と聞いたとします。Claudeがこの質問に答えるにはGitHubへアクセスする必要があります。GitHubのAPI構文をClaudeが直接覚えるわけにはいかないので、GitHubがあらかじめ「私のツールはこう呼んでください」という説明書（スキーマ）をMCPサーバーに用意しておきます。Claudeはこの説明書を読み、適した道具を呼び出します。
// MCPサーバーがClaudeに自己紹介する様子 (簡略化)
{
"tools": [
{
"name": "list_pull_requests",
"description": "Lists pull requests in a repository",
"inputSchema": {
"type": "object",
"properties": {
"owner": { "type": "string" },
"repo": { "type": "string" },
"state": { "enum": ["open", "closed", "all"] }
}
}
}
]
}
この構造が力を持つのは標準化のおかげです。Claude DesktopでもCursorでもClaude Codeでも、MCPを理解するホストならば、どの会社のMCPサーバーでも同じやり方で接続できます。実際、2025年の1年間でGitHub・Notion・Figma・Slack・Stripe・Linearをはじめとする主要SaaSが、こぞって公式MCPサーバーを公開しました。
CLI (Command Line Interface)
ターミナルで直接コマンドを入力するツールです。git push、gh pr list、aws s3 ls、npm install のようなものです。1970年代のUnixの時代からあり、開発者なら毎日使っています。
# GitHub CLIでPR一覧を見る
gh pr list --state open --limit 5
# AWS CLIでS3バケットのファイル一覧を見る
aws s3 ls s3://my-bucket/data/
# Stripe CLIで最近の決済を見る
stripe charges list --limit 3
ところがこの古い道具が、突然AI時代の主役として戻ってきました。理由は意外にも単純です。AIアシスタントもこの道具を使えるからです。Claude Code、Cursor、CodexなどはAIに、コンピューターのコマンドを直接入力できる権限を与えます。人がキーボードでコマンドを打つ代わりに、AIが代わりに打ってくれる、ということです。
すると、こういう状況が生まれます。たとえば「いまレビュー待ちのコード変更一覧を見せて」のような作業をAIに頼んだとしましょう。これまでは、こうした作業をするために、いくつもの段階を経由する別の連結装置（MCPサーバー）を作っておく必要がありました。ところがAIがコマンド一行（gh pr list）を直接打ってしまえば、それで終わりです。わざわざ複雑な橋を架ける必要がなくなった、ということです。
Skill (Claude Skills)
最も遅く登場した概念です。Skillは マークダウンファイルに書かれた手順的な知識 です。「このタスクを行うときは、この順番で、このように進めてください」というガイドをマークダウンで整理したもので、データを取りに行ったり、行動を起こしたりはしません。順序と拍子だけを名指しします。
---
name: weekly-meeting-report
description: 週次ミーティングから決定事項を抽出してレポートにする際に使用
---
## 手順
1. tiro CLIで今週の議事録を取得する
tiro notes search "OKR" --since 7d --json > meetings.jsonl
2. 各ミーティングから「決定事項」セクションだけを抽出する
3. 次のテンプレートに当てはめてマークダウンのレポートを作る
4. Slack #weekly-report チャンネルに投稿する
そのため SkillはMCPの代替ではなく、むしろ補完物 に近いものです。MCPがツールへのアクセスを提供するなら、Skillはその道具をどう効果的に使うかを伝える手順です。
同じ質問、32倍のコスト差
4つのツールの定義をそろえたところで、本題の問いに移ります。同じ仕事をさせれば、結果は似たものになるのでしょうか？結論から言うと まったく違います。 データがかなり驚くべき話を聞かせてくれます。
Scalekitが2026年3月に発表したベンチマークは、ごく単純な質問ひとつから始まります。「このGitHubリポジトリは何の言語で書かれていますか？」同じ質問、同じモデル（Claude Sonnet 4）、75回の繰り返し。
結果はこうです。
gh CLIエージェント：1,365トークン
GitHub MCPエージェント：44,026トークン
32倍の差です。
なぜこのような差が出るのか
理由は偶然ではなく構造的なものです。MCPサーバーはセッション開始時、登録されたすべてのツールのスキーマをコンテキストに一気に流し込みます。GitHub MCPのツールは43個。ユーザーが「私のPRを見せて」と一度尋ねただけなのに、Claudeのコンテキストウィンドウには、webhook管理、gist生成、repository設定のように、PRと無関係なスキーマまで毎回いっしょに入り込みます。
CLIはやり方が違います。gh --help は必要なときだけ呼ばれ、その結果だけが一時的に入ってきて、すぐ消えます。さらに gh、git、curl、aws のようなTier 1のCLIは、モデルの学習データにすでに何百万回も登場している「馴染みの顔」です。モデルがすでに覚えているのですから、スキーマをあらためて伝える必要そのものがありません。
Agent-firstはすでに変わっている
このデータ以降、流れが変わり始めました。Anthropicは同じワークフローのトークンを150,000から2,000まで減らす code execution(コード実行) パターンを公式に発表しました。98.7%の削減 です。CloudflareもCode Modeという、同じパターンを独自に発見しています。MCPが登場してそれほど時間が経っていないにもかかわらず、「Agent-firstなのだからMCP-first」という通念は、すでに静かに崩れ始めています。
だからといってCLIが正解、というわけでもありません
このデータだけ見ると、「では全部CLIに行けばいい」と結論してしまいがちです。しかしそれもまた、別の落とし穴に落ちる道です。
CLIにも明確な限界があります。
第一に、認証の分離が難しい。
会社のSlackで50人が働いているとしましょう。それぞれ見られるチャンネルや権限が違います。ところがAIが一人のパソコンでコマンドを代わりに打ってくれる仕組みだと、結局その一人の権限ですべての作業を処理することになってしまいます。誰が何をできるのかをきれいに区別しにくくなります。
第二に、結果がきれいに整っていない形で出てきます。
コマンドを実行すると、結果はただの文字の塊としてどばっと流れ出てきます。AIがそれを毎回読み直して「あ、この数字が価格で、こちらが日付なんだ」と解釈しなければなりません。決まった様式できれいに受け取れるわけではないので、ミスの余地が生まれます。
第三に、そもそもCLIが存在しないサービスが多い。
Workday、Greenhouse、Leverのようなエンタープライズ向けHR SaaSはCLIを作ったことがなく、今後作る可能性も低いです。
答えは二者択一ではない
結局のところ、答えはMCPとCLIの二者択一ではありません。2つの道具は、別々の仕事のために設計された。 この前提を押さえる必要があります。その「別々の仕事」を一行で言えるようになって初めて、「この機能をどこに出すか」の答えが見えてきます。
欠けていた軸：「結果はどこへ行くのか」
これまでこうした道具を比較するときは、いつも2つの基準で見てきました。誰が使うか（人が直接？それともプログラムが？）、そして どうつながるか（どの通信方式を使うか）。ところがこの2つの基準だけでは、4つの道具がなぜ異なる存在なのかを説明しきれません。
欠けていた軸があります。結果はどこへ行くのか。
ツール | 呼び出す側 | 結果の行き先 |
|---|---|---|
API | プログラム、別のサービス | 呼び出した側が望む場所 |
MCP | MCP対応エージェント | AIのコンテキストウィンドウ（いまの会話で参照する材料） |
CLI | シェル（人またはエージェントが直接コマンドで） | コンピューター内のファイル、次の作業 |
Skill | Claude（ホストごと） | エージェントの次の行動（作業手順の案内） |
行き先が違えば、適したタスクも違います。行き先が同じなら、事実上、同じツールです。
一行に圧縮するとこうなります。
MCPはコンテキストへ、CLIはdisk（コンピューターの作業台）へ、SkillはAIの次の行動へ、APIは正解が必要な場所へ結果を送ります。
補完物であって代替ではない
4つのツールは代替物ではありません。行き先の異なる、補完物です。
手と足の両方が必要な理由
人にはなぜ、手と足が分かれて存在しているのでしょうか。どちらも移動し操作する道具のはずなのに。
答えは精度と距離です。手は近くにある小さなものを精密に扱います。コップを持ち、文字を書き、キーボードを打ちます。代わりに遠くへは行けません。足は大きな距離を移動し、重い荷物を運びます。代わりに針に糸は通せません。
エージェントの道具も同じです。
MCPは手です。 AIが見ているコンテキストウィンドウの中の小さなデータを、schema（決まった様式）で正確に、何度もやりとりしながら精密に扱います。代わりに、50KBのtranscriptを差し出した瞬間にAIの手がいっぱいになり、コンテキストが崩れます。
CLIは足です。 コンピューターの中で大きなファイルを運び、ひとつの作業の結果を次の作業へ流し込み、自動化されたシステムにも入っていけます。代わりに結果が文字の塊として出てくるので、手ほど繊細にはなれません。
Skillは筋肉の記憶です。 「メモを検索 → transcriptを保存 → 要約 → Slackに投稿」のような順序と拍子を覚えます。データそのものには触りません。
APIは骨格です。 手も足も筋肉も、すべてこの上に付きます。骨格が揺らげば、残りすべてが揺らぎます。
なぜ手と足が必要か
これがただの比喩で終わらない理由があります。エージェントは「コンテキストウィンドウという短期記憶」と「filesystemという外部記憶」を同時に持つ存在 だからです。短期記憶は容量が決まっているので、あまりに多くのものを一度に持ち込もうとすると、あふれて壊れてしまいます。そのため、大きな荷物は外部記憶（filesystem、コンピューターの内部）に送っておき、必要なときだけ取り出して見るようにします。それが手と足の分業です。
いつ、どのツールを使うべきか
「このendpointをどこに公開するか？」を1分以内に決められる4つの問いです。
Q1. 結果は大きいですか？
KB単位以上だったり、ファイルを扱う必要があるなら、CLIです。 議事録30件を一度にダウンロードする、transcriptをマークダウンで保存する、大きなNDJSONをpipeする。すべてCLIの領域です。このデータをコンテキストウィンドウに入れると、reasoningが鈍り、トークンコストが跳ね上がります。
Q2. 一度の呼び出しで終わる単純なタスクですか？
エージェントのreasoningがとくに必要でないなら、コードからAPIを直接呼びます。 「このwebhookを登録して」「このユーザーをdeactivateして」のような作業です。
Q3. 小さなmetadataをmulti-turnでreasoningする必要がありますか？
データが軽く、段階が複数あるなら、MCPです。 「共有リンクのうち期限切れでないものだけを選んで、期限を30日延長して」のような作業です。
Q4. これらすべての順序が繰り返されますか？
毎週、毎PRごとに同じ段階を踏むなら、Skillで手順化します。 一度SKILL.mdに書いておけば、次からは一行で呼べます。
1つのendpointが複数のツールに公開される場合
1つのendpointが2つのツールに公開される必要がある場合もあります。「メモ1件のmetadata」はMCPで見せて、「同じメモのfull transcript」はCLIでdiskに保存するのが自然です。要点は 「4つのツールすべてに公開する」のではなく、各endpointを行き先に合った1〜2のツールにだけ公開する ということです。
まず行き先を尋ねてください
2026年のSaaSは、4つのツールを同時に運用できます。ただしこの事実が負担に感じられる理由は、4つを同じものの亜種として見ているからかもしれません。同じものの亜種ではありません。行き先が異なる4つの補完物です。
よいAX設計の出発点は、「どのツールが優れているか？」ではありません。
このタスクの結果は、どこへ行くべきか？
この問いひとつを正確に投げられるようになるだけで、4つのツールを運用することが、ぐっと身軽になります。
「このendpointをどこに公開するか？」と尋ねる前に、結果がどこへ行くべきかを、まず尋ねてください。
よくある質問
Q. MCPとは何ですか？一行で説明してください。
MCPはModel Context Protocolの略で、AIエージェントが外部のツールやデータにアクセスする際、常に同じ形式で対話できるようにした標準です。2024年11月にAnthropicが発表し、JSON-RPCの上で動作します。GitHub、Notion、Figma、Slackなど主要SaaSが公式MCPサーバーを提供しています。
Q. MCPとAPIは何が違うのですか？
行き先が違います。APIは呼び出した側が望む場所へ結果を送ります。MCPはAIエージェントのコンテキストウィンドウへ結果を送ります。小さなmetadataをmulti-turnで推論するときはMCPが合い、大きなデータを処理したり、別のサービスから直接呼び出すときはAPIが合います。
Q. CLIがMCPよりトークンを少なく使う理由は何ですか？
2つあります。一つ目、MCPはセッション開始時にすべてのツールのスキーマをコンテキストに注入しますが、CLIは必要なときだけ --help を呼びます。二つ目、gh、git、aws のような主要なCLIはモデルの学習データにすでに何百万回も登場するため、スキーマを新たに伝える必要がありません。Scalekitのベンチマークでは、同じタスクでCLIがMCPの4〜32倍少ないトークンで済みました。
Q. SkillはMCPの代替ですか？
いいえ。Skillはデータに直接アクセスしません。「メモ検索 → 要約 → Slack送信」のような手順をSKILL.mdファイルに名指ししたものです。MCPがツールへのアクセスを提供するなら、Skillはその道具をどう効果的に使うかを示すガイドです。両者を一緒に使うときが最も強力です。
Q. 私たちのサービスもMCP serverを作るべきですか？
データの特性によります。小さなmetadata作業が中心で、multi-turn reasoningに価値があるならMCPが合います。結果がKB単位以上で大きかったり、ファイルを扱う必要があるならCLIをまず検討してください。最も現実的な答えは「必要なツールはすべてサポートしつつ、すべてのendpointを4回公開はしない」です。各endpointを行き先に合った道具にだけ公開すれば十分です。
参考文献
関連記事
はじめる
