Claude Code vs Cursor
Claude Code(ターミナルCLI)とCursor(エディタ) — AIコーディングツールの比較。マルチエージェント、Plan Mode、Composer、IDE統合、プロダクション開発者ワークフロー。
マルチモデル・エージェント時代における、ツールとデータ接続の普遍的な標準
単一のAPI契約でモデルをアプリケーションコードに直接接続する、古典的な手法
両者は競合ではなく、スケールの閾値の違いだ。単一モデル+2〜3個の内部ツールに限定され、レイテンシが重要なプロジェクトでは、ネイティブのfunction callingの方が依然としてシンプルで速く、可動部分が少ない。マルチモデル戦略を持ち、同じツールを複数のクライアント(Claude、Cursor、Copilot)で共有する必要がある、あるいはエンタープライズの統制/アローリストが必須なら、MCPの移植性と一元的なガバナンスが優位に立つ — GitHubとAnthropicが2026年8〜9月に同時に打ち出したガバナンス施策がその証拠だ。迷ったら小さく始めよ: 内部ツールはネイティブのtool-useで書き、チーム/ベンダー数が増えたらMCPサーバーへ移行する。
| カテゴリー | MCP (Model Context Protocol) | Native Function Calling |
|---|---|---|
| パフォーマンス | 6/10 | 9/10 |
| 学習のしやすさ | 5/10 | 8/10 |
| エコシステム | 9/10 | 6/10 |
| コミュニティ | 8/10 | 7/10 |
| 求人市場 | 5/10 | 7/10 |
| 将来性 | 9/10 | 6/10 |
// Claude Code — .mcp.json にリモートHTTP MCPサーバーを追加
// 出典: code.claude.com/docs/en/mcp (remote HTTPが推奨トランスポート)
{
"mcpServers": {
"internal-docs": {
"type": "http",
"url": "https://mcp.example-internal.com/v1",
"headers": {
"Authorization": "Bearer ${MCP_API_TOKEN}"
}
}
}
}
// managed-settings.json — 組織全体への配布 + ポリシー
// 両方のキーともTOP-LEVELであり、"permissions" の下ではない。
// managedMcpServers: CHANGELOG v2.1.259 — ".mcp.jsonと同じエントリ形式";
// コマンドを実行する(stdio/local)エントリはスキップされる。
{
"managedMcpServers": {
"internal-docs": {
"type": "http",
"url": "https://mcp.example-internal.com/v1"
}
},
"deniedMcpServers": [
{ "serverUrl": "https://*.untrusted.example.com/*" }
]
}
// deniedMcpServersのエントリは単一キーのオブジェクトである(serverUrl | serverCommand |
// serverName)。serverNameはワイルドカードを展開しない — 強制するにはserverUrlを使うこと。// Anthropic Messages API - native tool use (function calling)
// 出典: platform.claude.com/docs/en/agents-and-tools/tool-use/overview
{
"model": "claude-sonnet-5",
"max_tokens": 1024,
"tools": [
{
"name": "get_weather",
"description": "Verilen sehir icin guncel hava durumunu dondurur",
"input_schema": {
"type": "object",
"properties": {
"location": { "type": "string", "description": "Sehir adi, orn. Istanbul" }
},
"required": ["location"]
}
}
],
"messages": [
{ "role": "user", "content": "Istanbul'da hava nasil?" }
]
}
// モデルはtool_useブロックを返し、アプリケーションコードが実行され、
// 結果はtool_resultとして2回目のリクエストで送り返される。
// これは2回の完全なAPIラウンドトリップを必要とする(別サーバープロセスはない)。両者は競合ではなく、スケールの閾値の違いだ。単一モデル+2〜3個の内部ツールに限定され、レイテンシが重要なプロジェクトでは、ネイティブのfunction callingの方が依然としてシンプルで速く、可動部分が少ない。マルチモデル戦略を持ち、同じツールを複数のクライアント(Claude、Cursor、Copilot)で共有する必要がある、あるいはエンタープライズの統制/アローリストが必須なら、MCPの移植性と一元的なガバナンスが優位に立つ — GitHubとAnthropicが2026年8〜9月に同時に打ち出したガバナンス施策がその証拠だ。迷ったら小さく始めよ: 内部ツールはネイティブのtool-useで書き、チーム/ベンダー数が増えたらMCPサーバーへ移行する。
無料相談を受けるFunction callingは、モデルが1回のAPI呼び出しの中でどの関数をどの引数で呼び出すかをJSONとして返すことであり、実行はアプリケーション自身のコード内でin-processに行われる。一方MCPは、JSON-RPC 2.0上に構築されたクライアント・サーバー方式のオープンプロトコルであり、ツールディスカバリー、バージョンネゴシエーション、実行を別のサーバープロセスに切り出すことで標準化する。両者は競合ではない。AnthropicのMCPコネクタ自体、基盤にネイティブのtool-use機構を使っている。