「明日の予定を確認して」
AIにそう言ったとき、どうなるでしょうか。
ChatGPTに聞いても、「Google Calendarにアクセスする権限がないので...」と返ってくることが多いはず。Claudeでも同じ。便利なAIツールはたくさんあるのに、いざ「私のデータを見て」と言うと、意外とできないこと多いんですよね。
なんか、もどかしくないですか。
AIって、頭はいいはずなのに。膨大な知識を持っているのに。膨大な計算能力があるのに。肝心なところで「手が届かない」。
情報を見つけることと、その情報を使って行動することは全然違う。
でも、ここ最近でその状況が変わりつつある気がします。
キーワードは MCP (Model Context Protocol)。
2024年11月にAnthropicが発表したこのプロトコル、2026年に入って急速に普及しています。2026年2月時点で、公式レジストリにはすでに 6400以上のMCPサーバー が登録されているそうです。
OpenAIは2025年3月、Googleは同年4月にMCPサポートを追加。もはや業界標準になりつつあるんですよね。
この記事では、そんなMCPについて、
- そもそも何なのか
- なぜ今注目されているのか
- 実際にどうやって使うのか
を、できるだけ分かりやすく整理してみました。
AIエージェントに「手」を与える。その方法が分かれば、あなたのAI活用の幅も大きく広がるはずです。
MCPとは: USB-Cのアナロジーで理解する
MCP (Model Context Protocol)。
聞き馴染みがないかもしれません。でも、これって2026年のAI開発において、かなり重要なキーワードになりそうなんです。
一言で言うと、**「AIエージェント用のUSB-C」**みたいなものかなと。
少し考えてみましょう。
USB-Cが登場する前、周辺機器を繋ぐにはそれぞれ専用のケーブルが必要でした。マウスはマウス用、キーボードはキーボード用、プリンターはプリンター用。
メーカーによって端子が違う。毎回「これ、どっちのケーブルだっけ」と確認する必要があった。
でもUSB-Cが登場してからは、一本のケーブルで何でも繋がるようになった。マウスも、キーボードも、外付けディスプレイも、全部同じポートでOK。
MCPも同じようなことを、AIの世界でやろうとしているんです。
今まで、AIに外部ツールを繋ぐには、それぞれのAPIに合わせて個別に実装する必要がありました。
- Google Calendarを使いたい → Google Calendar APIを調べて実装
- Gmailを使いたい → Gmail APIを調べて実装
- Slackに投稿したい → Slack APIを調べて実装
これ、結構大変なんですよね。APIごとに認証方法も違うし、エラーハンドリングも違うし。
MCPがあれば、共通のプロトコルでどのツールも同じように繋げるようになる。
AIエージェント側も、「これはGoogle Calendarのツールだな」「これはGitHubのツールだな」と統一的な方法で理解できる。
この「統一」が、AIエージェントの実用化を大きく加速させる気がします。
なぜ今MCPなのか: APIとの違いとエージェント時代の必然性
「APIがあるじゃん」と思うかもしれません。
確かにAPIは便利です。WebサービスのほとんどがAPIを提供しているし、APIを使えば外部システムと連携できます。
でも、APIってそもそも**「開発者」が使うことを想定して設計されている**んですよね。
開発者は決定論的に動きます。「このエンドポイントを叩けば、このパラメータで、この結果が返ってくる」と分かっているからコードを書ける。
一方で、AIエージェントは確率論的に動く。同じ質問をしても、毎回微妙に違う判断をする可能性がある。
この違い、意外と大きいんです。
例えば、カレンダーに予定を追加するAPIがあるとします。
開発者なら、「POST /events に title, start, end をJSONで送る」と明確にコードに書きます。
でもAIエージェントの場合、「明日の3時に会議を入れて」という自然言語の指示から、どのAPIエンドポイントを叩くべきか、どんなパラメータを渡すべきか、を自分で判断しないといけない。
APIのままでは、この「自分で判断してツールを使う」のが難しい。
MCPは、そのギャップを埋めるために作られたプロトコルなんですね。
具体的には、MCPサーバーは**「Tool」**という単位で機能を提供します。
Toolは単なるAPIのラッパーではありません。「機能の抽象化」なんです。
例えば、「カレンダーに予定を追加する」というToolの裏側では、
- ユーザーのタイムゾーンを確認する
- 重複する予定がないかチェックする
- 必要ならリマインダーを設定する
- そして実際にAPIを叩く
といった複数の処理が走るかもしれない。
AIエージェントは、その裏側を知らなくていい。「create_event」というToolを呼ぶだけで、目的が達成できる。
この「適切な抽象化」があるおかげで、AIエージェントはより確実に、より安全にツールを使えるようになるんです。
仕組みの基礎: JSON-RPCとクライアント・サーバーモデル
仕組み自体は、そこまで複雑じゃありません。
MCPは JSON-RPC 2.0 という既存のプロトコルをベースにしています。JSON形式でメッセージをやり取りする、シンプルなRPC（Remote Procedure Call：リモートのプログラムを呼び出す仕組み）です。
アーキテクチャはクライアント・サーバーモデル。
- MCPクライアント: AIエージェント側（Claude Desktop、VS Code Copilot、Cursor、OpenClawなど）
- MCPサーバー: ツールを提供する側（Google Calendar、GitHub、自作サーバーなど）
通信方式は2つあります。
stdio（標準入出力）
クライアントがサーバープロセスを子プロセスとして起動して、標準入出力で通信する方式。
ローカル環境で動くサーバー向け。例えば、ローカルのファイルシステムにアクセスするサーバーとか。
向いているケース: 個人開発、ローカルツール、セキュリティ重視の環境
Streamable HTTP
HTTPで通信する方式。サーバーはHTTPエンドポイントとして動作。
リモートサーバーや、複数のクライアントから共有されるサーバー向け。
向いているケース: チーム共有、クラウドデプロイ、複数エージェントからのアクセス
どっちを選べばいいの？
まずはstdioで始めるのがおすすめです。設定がシンプルで、外部公開を気にしなくていいので。
MCPサーバーが提供するのは、主に3つの要素です。
Tools（ツール）
AIが実行できる「操作」。
例えば：
-
get_calendar_events- カレンダーの予定を取得 -
create_issue- GitHubにIssueを作成 -
send_email- メールを送信
Toolには名前、説明、入力スキーマが定義されています。
入力スキーマ（JSON Schema） とは、「このToolにはどんなパラメータを渡せばいいか」を定義したルールのこと。例えば「日付はYYYY-MM-DD形式で」「必須パラメータはtitleとstart」みたいな。
AIはこの情報を見て、「どのToolを」「どんなパラメータで」呼ぶべきかを判断します。
Resources（リソース）
AIが読み取れる「データ」。
例えば：
-
file:///project/README.md- プロジェクトのREADME -
database://users- ユーザーテーブルのスキーマ
Toolが「操作」なのに対して、Resourceは「読み取り専用のコンテキスト」。
Prompts（プロンプトテンプレート）
再利用可能なプロンプトパターン。
例えば、「コードレビュー」用のプロンプトテンプレートを定義しておけば、AIがそのテンプレートを使ってレビューを行える。
接続のライフサイクルはシンプルです。
- 接続と初期化: クライアントがサーバーに接続し、互いの能力を交換
- ツール発見: サーバーが提供するToolの一覧を取得
- ツール実行: 必要に応じてToolを呼び出し、結果を受け取る
これだけ聞くと、「普通のAPIと同じでは？」と思うかもしれません。
違いは、ツールの「発見」と「選択」をAIが自律的に行えるという点。
人間がいちいち「このAPIを使って」と指示しなくても、AIが自分で判断してツールを選べる。ここが大きいんです。
実践: Google Calendar MCPサーバーを10分でセットアップ
では、実際にやってみましょう。
Google CalendarのMCPサーバーをセットアップして、AIに自分の予定を確認させてみます。
正直、10分もあれば終わります。やってみると意外と簡単なんですよね。
前提条件
- Node.js がインストールされている（v18以上推奨）
- Google Cloud Console でプロジェクトを作成済み
- OAuth 2.0 の認証情報（Client ID、Client Secret）を取得済み
認証情報の取得方法（ざっくり）:
- Google Cloud Console にアクセス
- プロジェクトを作成（または既存のものを選択）
- 「APIとサービス」→「認証情報」→「認証情報を作成」→「OAuth クライアント ID」
- アプリケーションの種類は「デスクトップアプリ」
- 表示された Client ID と Client Secret をメモ
Step 1: MCPサーバーのインストール
大抵のMCPサーバーはnpmパッケージとして配布されています。
Google Calendar MCPサーバーも同じ。
```bash
npx @anthropic/google-calendar-mcp
```
これだけで、サーバーが起動します。
Step 2: AIエージェントの設定
次に、あなたのAIエージェントに「このサーバーを使ってね」と設定します。
設定方法はエージェントによって異なります。
Claude Desktop の場合:
設定ファイルの場所：
- macOS: `~/Library/Application Support/Claude/claude_desktop_config.json`
- Windows: `%APPDATA%\Claude\claude_desktop_config.json`
- Linux: `~/.config/Claude/claude_desktop_config.json`
設定内容：
```json
{
"servers": {
"google_calendar": {
"command": "npx",
"args": ["@anthropic/google-calendar-mcp"],
"env": {
"GOOGLE_CLIENT_ID": "あなたのClient ID",
"GOOGLE_CLIENT_SECRET": "あなたのClient Secret"
}
}
}
}
```
Cursor / VS Code Copilot の場合:
`.vscode/mcp.json` に同様の設定を記述します。
Step 3: 認証と動作確認
Claude Desktopを再起動すると、初回は認証フローが始まります。
ブラウザが開いてGoogleアカウントでのログインを求められるので、許可を与えます。
認証が完了したら、実際に試してみましょう。
「明日の予定を教えて」と聞いてみてください。
AIがGoogle CalendarのToolを呼び出して、あなたの予定を返してくれるはずです。
セキュリティの注意点
MCPサーバーは、あなたのデータにアクセスできます。
Google Calendarなら予定を読み取れるし、Gmailならメールを読める。Database MCPなら、データベースにクエリを投げられる。
この「アクセス権限」は慎重に管理する必要があります。
- 可能な限り 読み取り専用 の権限で設定する
- 本番環境のデータベースには直接繋がない
- 不明なサーバーは安易に追加しない
- 環境変数は `.env` ファイル等で管理し、Gitにコミットしない
セキュリティのベストプラクティスは、公式ドキュメントも参照してください。
エコシステム: 押さえておくべき主要MCPサーバー
MCPサーバー、実はもう6400以上が登録されているんです（2026年2月時点）。
全部は紹介できないので、とりあえず押さえておくべきものをいくつかピックアップしてみました。
Productivity（生産性向上）
| サーバー | できること |
|---|---|
| Google Calendar | 予定の確認、作成、変更 |
| Gmail | メールの検索、読み取り、下書き作成 |
| Notion | データベースの検索、ページの作成 |
| Slack | メッセージの送信、チャンネルの確認 |
Development（開発）
| サーバー | できること |
|---|---|
| GitHub | Issueの作成、PRの確認、リポジトリ操作 |
| Context7 | 最新のライブラリドキュメントを取得 |
| PostgreSQL | データベースへのクエリ実行 |
| Filesystem | ローカルファイルの読み書き |
Infrastructure（インフラ）
| サーバー | できること |
|---|---|
| Docker | コンテナの管理、ログの確認 |
| Kubernetes | クラスター操作、デプロイ管理 |
これらを使えるようになるだけで、AIエージェントのできることの幅がかなり広がる気がします。
「GitHubのPRを確認して、レビューコメントをまとめてSlackに投稿して」とか。
「データベースの異常なレコードを検出して、Notionにレポートを作成して」とか。
組み合わせ次第で、いろんな自動化ができそうですね。
MCP vs Skills: どちらを選ぶべきか
MCPの他に「Skills」というアプローチもあります。
どっちを使えばいいの？って話ですよね。
ざっくり言うと：
| MCP | Skills | |
|---|---|---|
| 本質 | 外部システムとの連携 | AIの振る舞いをガイド |
| 形式 | 構造化されたツール定義 | 自然言語の指示書き |
| 実行 | 決定論的（同じ入力なら同じ結果） | 確率論的（解釈のぶれがある） |
| セットアップ | サーバーの設定が必要 | Markdownファイルを置くだけ |
| 向いている用途 | API連携、データベース操作 | タスクの進め方、思考プロセス |
MCPが向いているケース
- 外部サービス（Google、GitHub、Slack等）と連携したい
- 決定論的な処理が必要（同じ操作なら毎回同じ結果）
- 複数のAIエージェントで同じツールを共有したい
Skillsが向いているケース
- AIに特定の「やり方」を教えたい
- タスクの進め方をステップバイステップで指示したい
- 環境設定なしでサクッと試したい
実は、この2つは併用できます。
Skillsで「タスクの進め方」を定義して、その中でMCPのToolを使う。
例えば、「バグ修正」のSkillを作って、その中でGitHub MCPを使ってIssueを確認したり、Filesystem MCPでコードを編集したりする。
この組み合わせ、かなり強力な気がします。
2026年ロードマップ: 4つの優先分野と今後の展望
2026年のMCP、これからどうなっていくんでしょうか。
公式ブログで2026年のロードマップが公開されていて、4つの優先分野が示されています。（2026年3月時点の情報です）
1. Transport Evolution and Scalability（トランスポートの進化とスケーラビリティ）
今のHTTPトランスポート、実はスケーラビリティに課題があるそうです。
- ステートフルなセッションがロードバランサーと相性が悪い
- 水平スケーリングにワークアラウンドが必要
- サーバーの能力を接続なしで知る方法がない
これらを解決するために、セッションモデルの改善や `.well-known` でのメタデータ配信が進められています。
2. Agent Communication（エージェント間通信）
MCPの「Tasks」プリミティブが実験的にリリースされています。
エージェント間でタスクを依頼したり、結果を受け取ったりする仕組み。
本番運用からのフィードバックを受けて、リトライ semantics や有効期限ポリシーが追加されていくそうです。
3. Governance Maturation（ガバナンスの成熟化）
今は全てのSEP（Spec Enhancement Proposal）がコアメンテナーのレビューを必要としているらしい。
これがボトルネックになっているので、ワーキンググループへの権限委譲を進めていくとのこと。
オープンな標準として、コミュニティ主導の開発を加速させる動きですね。
4. Enterprise Readiness（エンタープライズ対応）
企業がMCPを本番導入する際の課題に対応する分野。
- 監査ログ（Audit trails）
- SSO連携の認証
- ゲートウェイの振る舞い
- 設定のポータビリティ
エンタープライズ対応が進めば、セキュリティやコンプライアンスの要件も満たせるようになる。そうなると、より多くの企業で採用が進む気がします。
まとめ: 今日からMCPを始めるために
MCP、ちょっとでも興味湧きましたか。
改めて整理すると、MCPはAIエージェントに「手」を与えるための共通プロトコルです。
- USB-Cがハードウェアの接続を統一したように
- MCPはAIツールの接続を統一する
- 2026年2月時点で6400以上のサーバーが登録済み
- OpenAI、Googleもサポートを追加
まずはここから始めてみませんか。
-
公式ドキュメントを見てみる
https://modelcontextprotocol.io/ -
Google Calendar MCPをセットアップしてみる
この記事の手順通りにやれば、10分で完了します。 -
MCPサーバーを探索してみる
公式レジストリ で、どんなサーバーがあるか眺めてみるだけでも面白いです。
AIエージェントに「手」を与える。
それがMCPの本質かなと思います。
2026年、このプロトコルを知っているのと知らないのとでは、AI活用の幅が全然違ってくる気がします。
まずは小さく始めてみて、徐々に活用の幅を広げていく。
そんなアプローチはいかがでしょうか。
何か分からないことがあれば、コメントで気軽に聞いてください。