AIコーディングを使っていると、最近よく目にする言葉があります。MCP（Model Context Protocol）です。
Claude CodeやCodex、CursorのようなCoding Agentを使っていると、「MCPサーバーを追加する」「GitHubをMCPでつなぐ」「データベースへMCP経由でアクセスする」といった説明を見る機会が急速に増えてきました。
すると、ひとつの疑問が浮かびます。「MCPも本格的に勉強しなければならないのだろうか？」
Pythonを覚える。APIを理解する。Gitを使う。CLIにも慣れる。そこへさらにMCPまで加わると、「AIを使うために、結局また大量の技術仕様を覚え直さなければならないのか」と感じるかもしれません。
しかし、CORE SPECでは「MCPの細かなプロトコル仕様を暗記する必要はない」と考えています。一方で、AIエージェントを本格的に活用するなら、MCPが何をする仕組みなのか、そして何をAIに渡すのかという境界線は知っておく必要があります。
結論：仕様暗記は不要だが、「AIに何を渡すか」の判断は必須になる
MCPはAIを賢くするモデルそのものではありません。AIに対して「どの道具と、どの情報と、どの権限を渡すのか」を接続するための仕組みです。
普通のチャットAIは、ユーザーが画面から入力したプロンプトの範囲内だけでテキストを返します。しかしAIエージェントは、
- ローカルのファイルを読む
- GitHubのリポジトリやIssueを確認する
- データベースを検索する
- 社内システムから情報を取得する
- 必要に応じてデータを書き換える
というように、「コンピューターの外の世界へ自律的に手を伸ばす」ようになります。MCPは、そのときAIクライアントと外部のツールやデータソースを標準的な方法で接続するための架け橋です。
2026年7月公開の仕様改定（2026-07-28 Specification）でも、ステートレス化やAuthorization Hardening（認可まわりの強化）、OAuth/OIDC認可運用の堅牢化（RFC 9207のiss検証やCIMDへの移行など）が主要変更に含まれ、エージェント型ワークフローの強固な基盤として標準化が進んでいます。
つまり、MCPを学ぶ本質は「プロトコルを作ること」ではなく、「AIにどんな権限を与えて現実のシステムに触れさせるのか」を正しくコントロールすることにあります。
API・CLI・Git・MCPは、そもそも役割がまったく違う
MCPを理解しにくくしている大きな原因が、APIやCLI、Gitなど既存の開発技術との違いです。これらは競合するものではなく、以下のように役割が明確に分かれています。
| 技術 | 主な役割 | 一言で言うなら | Coding Agentとの関係 |
|---|---|---|---|
| API | ソフトウェア同士が機能やデータを送受信する | サービスの窓口 | Agentやツールが外部サービスと連携する際に利用 |
| CLI | テキストコマンドでOSやツールを操作する | 操作の入口（手） | Agentがテストやビルドを実行する実行層 |
| Git | ファイル変更の履歴や差分を記録・管理する | 変更の安全弁 | Agentの変更を確認し、壊れたら元に戻す |
| MCP | AIへ利用可能なツールや情報源を安全に接続する | AIに渡す道具箱 | Agentが「何の機能を使えるか」を提示する枠組み |
実際の開発では、これらが協調して動きます。MCPサーバーの内部でAPIが呼ばれることもあり、Coding AgentがCLI経由でテストを実行し、変更されたコードをGitで記録します。MCPが既存の技術を置き換えるのではなく、AIを中心にこれらを束ねる層としてMCPが存在しています。
APIを理解していると、MCPの裏側が手に取るようにわかる
例えば「天気情報」を扱うとします。APIなら、プログラムから「東京の今日の天気をください」というリクエストを送信します。これはソフトウェアからサービスを叩く窓口です。
一方MCPでは、「このAIエージェントは、天気を取得するツール（関数の引数仕様や説明文）を使える」という定義をAIクライアントに教えます。AIが必要だと判断した瞬間にそのツールを呼び出し、その裏側で実際の天気APIが実行されます。
この違いがわかると、APIの学習が無駄にならないことが理解できます。APIの基礎（request/response、JSON、エンドポイント）を知っている人ほど、「このMCPツールは裏でどのAPIを叩き、どんなデータを扱っているのか」を正確に見抜くことができます。
※ APIの基本的な役割については、「AI時代にAPIは学ぶべき？」で詳しく整理しています。
CLIはCoding Agentの「手」、Gitは「安全弁」
Claude Codeなどの自律型エージェントは、ターミナル（CLI）上でファイルを検索し、ビルドを行い、テストを実行します。人間がすべてのシェルコマンドを暗記する必要性は下がりましたが、「いまAgentがOSのどの層を操作しているのか」を把握するために、CLIという実行環境の存在は知っておく必要があります。
そして、Agentが高速にコードを書き換えるからこそ不可欠になるのがGitです。頼んでいないファイルまで変えてしまったり、直したつもりが別の箇所を壊したりしたとき、差分（Diff）を確認して直前の安全な状態に戻すのはGitの役割です。
MCPが「何を使わせるか」なら、Gitは「何を変えたかを確認して戻す」ための技術です。役割が完全に異なります。
※ Gitの重要性については、「AI時代にGit・GitHubは必要？」で解説しています。
なぜMCPを理解する必要があるのか──便利さ以上に「権限と安全性」
ここが最も重要なポイントです。MCPサーバーを自作する予定のない人までプロトコル仕様を覚える必要はありません。しかし、「MCPサーバーを追加すると、AIは何ができるようになるのか」という権限の境界線は必ず理解しておく必要があります。
Agentが使える能力が増えるほど、「便利かどうか」だけでつなぐことはできなくなります。
- GitHubのリポジトリを「読める」
- Google Driveのドキュメントを「読める」
- 社内Slackを「読める」
ここまでは一見安全に見えます。しかし、その先に、
- ファイルを「書き換えられる」
- Slackにメッセージを「投稿できる」
- データベースのレコードを「削除できる」
- 外部サーバーへデータを「送信できる」
という実行能力（Write権限）が加わった瞬間、「AIへ渡した権限の範囲で、現実のシステムに不可逆な影響を与えるリスク」が発生します。
OpenAIもリモートMCPの運用ガイドラインにおいて、信頼できないMCPサーバー、機密データへのアクセス、プロンプトインジェクション、機密操作への人間の承認（Human Approval）を重大な考慮事項として明示しています。
🛡️ MCPを安全に使うための5つの判断軸
公式サービス自身が提供しているか、信頼できる開発者か。出所の不明な第三者製MCPサーバーを不用意に接続しない。
「閲覧（Read）」と「変更・削除（Write）」を明確に分ける。まずは読み取り専用トークンで接続し、書き込み権限は真に必要な場合のみに絞る。
個人情報や認証トークン、本番DBの認証情報が含まれる環境に無制限のツールアクセスを与えない。
AIが外部のWebページやドキュメントを読み込んだ際、悪意ある命令（プロンプトインジェクション）が含まれていると、AIが意図せず危険なツール操作を実行するリスクがある。
破壊的な操作や外部通信を行うツールには、クライアント側で人間の承認ステップを設ける（例えばOpenAI APIのrequire_approval設定やCoding Agentの実行確認プロンプトなど）。
MCPを使う感覚は、スマートフォンに新しいアプリをインストールするときの「カメラや位置情報のアクセス許可を出すかどうか」の判断に非常に似ています。何でもかんでも許可するのではなく、「このツールには読み取りだけを許す」「重要な変更は人間が確認する」という最小権限の設計が、AIエージェント運用では不可欠になります。
MCPはどこまで学べばいい？ 3つの学習段階
CORE SPECでは、MCPの学習深度を用途に応じて3つの段階（Level 1〜3）で整理することをおすすめしています。
MCPとは何か、APIとの違い、AIにツールを接続する仕組みであることを理解する。信頼できないサーバーを繋がない、ReadとWriteを分けるといった安全管理の感覚を身につける。
Claude CodeやCursor、Codexなどに公式MCPサーバーを追加・設定できる。公開されているツールの引数仕様を確認し、不要な権限を外し、安全な作業環境を構築できる。
TypeScriptやPythonでMCPサーバーを自作する。OAuth 2.1認可フロー、ステートレスアーキテクチャ、JSON Schemaツール定義、エラーハンドリング、監査ログなどを実装できる。
全員がLevel 3を目指す必要はまったくありません。大切なのは、「AIに任せる権限の輪郭」を自分の手でコントロールできるLevel 1〜2の感覚を持っておくことです。
※ MCPを実際に使い始めると、次に問題になるのが「MCP Serverをどこで動かすか」です。LocalとRemoteでLLMそのものの知能が変わるわけではありませんが、MCP・Tool・Application・Dataの距離が変われば、帯域や遅延、アクセスできる情報の範囲も変化します。Local / Remoteの配置によって結果品質が変わる理由については、「MCPはネットワーク越しで精度が落ちる？」で整理しています。
まとめ：MCPは「AIに何をさせるか」を判断するために学ぶ
AIが自律的にコードを書き、ツールを実行する時代になっても、学ぶべき技術が消滅したわけではありません。
- APIは、外部サービスとどうデータをつなぐかを理解する。
- Gitは、何が変更されたかを管理し安全に戻せるようにする。
- CLIは、コンピューターの実行環境がどう動いているかを把握する。
- MCPは、AIへどのツールと権限を安全に渡すかを設計する。
- そしてテストやデバッグは、AIが作った出力が本当に正しいかを確かめる。
人間が担当する場所は、「一行ずつコードを手打ちする作業」から、「AIが安全かつ正確に動くための境界線を設計し、検証する役割」へと移行しています。
MCPを学ぶとは、プロトコルの暗記ではありません。AIエージェントという強力な相棒に「何を渡して、何を守るか」を判断するリテラシーを身につけることなのです。
よくある質問
MCPを使うにはプログラミング知識が必要ですか？ +
既存のMCPサーバーを利用・設定するだけであれば、本格的なプログラミングの知識は必須ではありません。Coding Agentや設定ファイル（JSON等）にサーバー接続情報を登録し、公開されているツールをAIへ渡す作業が中心です。ただし、ツールが何を実行しているかを把握するために、APIやCLIの基礎知識があるとより安全に扱えます。
MCPとAPIはどちらを学べばよいですか？ +
順序としてはAPIの概念を先に理解することをおすすめします。APIは「サービス同士がデータや機能をやり取りする窓口」であり、MCPはその背後でAPIなどを呼び出してAIへ利用可能なツールとして渡す接続仕様です。APIの仕組みを理解していると、MCPサーバーが何をしているのかを自然に把握できます。
MCPサーバーは安全ですか？ +
無条件に安全とは言えません。信頼できない提供元のMCPサーバーに機密データへのアクセス権を渡したり、Write権限を無制限に許可したりすると、データの漏洩や意図しない改変、プロンプトインジェクションによる不正操作のリスクが生じます。信頼できる提供元を選び、ReadとWriteを明確に分け、重要な書き込み操作には人間の承認を挟む運用が不可欠です。
MCPサーバーを自作できる必要がありますか？ +
すべての人に自作スキルが必要なわけではありません。日常的にAIエージェントを使うユーザーであれば、公開されている公式サーバーを適切に設定し、権限を制限して安全に利用できるレベル（Level 1〜2）で十分です。独自の社内システムと接続したり、独自のAIツールを開発したりする場合に初めて自作（Level 3）を検討してください。