Claude実践大全第14章:Model Context Protocol(MCP)でシステムをつなぐ──Claudeを「ツール」から「インフラ」へ

本記事は、『Claude実践大全:Chat・Cowork・Codeで「動くAI」を仕事に組み込む技術』を1章ずつ紹介するシリーズの第14回です。各記事では1つの章のエッセンスをダイジェストでお届けします。

Claudeがどれだけ賢くても、あなたの会社のSlackやGitHubの中身を知らなければ、できることは限られます。とはいえ、ツールごとに独自の連携コードを書いていては、システムが増えるたびに開発コストが膨らむ一方です。

第14章のテーマ、Model Context Protocol(MCP)は、この「統合の地獄」を終わらせる標準プロトコルです。共通の作法でつなぐから、コネクタを一度書けば複数のアプリ・チーム・文脈をまたいで使い回せる。前章のスキルと組み合わせたとき、Claudeは便利な道具から組織のインフラへと姿を変えます。

MCPとは何か——万能のデータの架け橋

MCPは、Claudeを外部のデータソースやシステムへ接続する標準化された方法です。Claudeとそれ以外のすべてをつなぐインターフェース層、と考えるとしっくりきます。Claudeがどうデータを要求し、どうツールを呼び、外部システムがどう応えるか——その作法を定義します。

効果は具体例で見ると明快です。Slack・Jira・GitHub・Google Driveを使っているとして、MCPがなければ4つの個別統合が必要です。MCPがあれば計4つのMCPサーバーを書くだけで、Claudeを使うどのアプリも自動で4つすべてにアクセスできます。5つ目を足すときもサーバーを1つ追加するだけ。既存の統合に手を入れる必要はありません。

💡 ポイント: 一度書けば使い回せる——これがMCPの本質です。統合がN×Mの掛け算から、N+Mの足し算へと変わります。

外部コンテキストを追加する——設定の実例

本書では、一般的な組織システムへの接続設定を、効果とセットで順に示します。たとえばSlack統合では、Claudeはメッセージの読み取り・投稿・履歴検索ができるようになります。ただし、アクセスは特定の3チャンネルだけ、メッセージの削除は不可、許可なくプライベートチャンネルには入れず、メールアドレスも読めない——厳格な境界が引かれています。

GitHub統合も同様に、プルリクエストのレビューや課題の議論には参加できる一方、マージ・課題の削除・リポジトリ設定の変更といった「人間の承認を要する操作」はあえて持たせません。Jira・Google Driveを含む4例の設定を、本書で具体的に確認できます。

⚠ 注意: MCP設計の肝は「与える権限」より「与えない権限」です。何ができるかと同じくらい、何をさせないかを明示的に設計してください。

スキルとMCPを組み合わせて自律ワークフローを作る

真価が出るのは、MCP(データとシステムへのアクセス)とスキル(構造化された手順)を組み合わせたときです。本来は人手の調整が要る複雑なプロセスが、自律的に回り始めます。

たとえばスプリント締めの作業。Jiraで完了課題を検索し、説明をコピーし、紐づくGitHubのプルリクエストとコミットを確認し、進捗レポートにまとめ、Slackに投稿する——この一連を、MCPを使うスキルが横断的に統括します。手順が明示的で事前承認済みだからこそ、どのステップでも人間の介入なしに進められるのです。