AIツール連携：MCPで拡張する方法入門

MCP（Model Context Protocol）は、AIアプリケーションと外部システムをつなぐための共通プロトコルです。公式仕様では、MCPはLLMアプリケーションと外部のデータソースやツールを標準化された方法で接続するためのオープンプロトコルと説明されており、Resources、Prompts、Tools を中心に構成されています。さらにOpenAIの現行ドキュメントでも、Responses API は remote MCP servers を built-in tool として扱え、関数呼び出しだけでなく、よりエージェント的な統合方法として案内されています。つまり、MCPは単なる“外部API接続の言い換え”ではなく、AIが必要な文脈を取りに行き、必要な操作を実行し、複数の外部機能を一つの対話の中で扱うための共通接続面だと考えるとわかりやすいです。本記事では、MCPの概念説明にとどまらず、何をつなぐと価値が出るのか、どのように安全設計するのか、そして業務で使いやすい実装パターンは何かを、入門者向けに整理します。

第1章：MCPの基本概念と注目理由

まずMCPの基本概念を押さえると、これはAIアプリと外部機能のあいだに共通の“差し込み口”を作る発想です。MCP公式の入門ページでは、ClaudeやChatGPTのようなAIアプリが、ローカルファイル、データベース、検索エンジン、電卓、専門ワークフローなどへ接続できる仕組みとして説明され、「AI向けのUSB-C」のような比喩が使われています。この比喩が示す通り、MCPの価値は個別の連携方法を毎回ゼロから作らなくて済む点にあります。従来は、GitHub連携、Slack連携、Drive検索、DB検索、決済リンク生成といった機能ごとに、関数定義や認証、レスポンス整形を個別に実装しがちでした。しかしMCPを使うと、AIクライアント側は共通プロトコルを理解していればよく、サーバー側は標準的な形で Tools や Resources を公開できます。

注目されている理由は、単に接続が楽だからだけではありません。OpenAIのResponses APIでは、remote MCP servers を built-in tool として使え、1回の応答の中で複数ツールをまたいだエージェント的な処理を行いやすくなっています。つまり、モデルは単に文章を返すだけでなく、必要な外部機能を発見し、呼び出し、結果を踏まえて次のアクションを判断できます。これにより、検索→取得→集計→回答、通知→確認→登録、問い合わせ分類→台帳更新→返信案作成のような流れを一つの対話としてまとめやすくなります。

さらに、MCPはAIごとに独自の連携仕様を覚える負担を減らす意味でも価値があります。公式仕様では、MCPは JSON-RPC 2.0 を使い、Hosts、Clients、Servers の役割に分かれて動作し、Resources、Prompts、Tools といった共通概念を提供します。そのため、開発者は「あるAI専用の拡張」ではなく、より再利用しやすい接続方式として扱えます。業務現場でMCPが注目されるのは、AIの賢さそのものより、AIを既存業務へ接続する部分がボトルネックになってきたからです。つまり今は、モデル単体の能力競争だけでなく、どれだけ安全に外部世界へつなげられるかが差になっています。

第2章：MCPで何をつなぐと価値が出るか

MCPで価値が出やすいのは、情報取得と業務操作が分断されている場面です。たとえば、社内ナレッジがGoogle DriveやSharePointにあり、会話履歴はSlackやTeamsにあり、案件データはCRMやデータベースにあり、最終的な作業はチケットシステムや社内申請システムで行う、という構成は珍しくありません。こうした環境では、担当者が複数の画面を行き来しながら情報を集め、判断し、別システムへ入力しています。MCPはこの断片化を埋めるのに向いています。たとえば「先週の障害報告をSlackとSentryで確認し、関連チケットをGitHub Issueとして起票する」「今朝の重要メールを要約し、必要ならCalendarの予定と照合する」といった流れは、MCPと相性のよい代表例です。

特に価値が高いのは、検索系の read-only ツールと、限定的な write 操作を組み合わせるパターンです。OpenAIのMCP関連ガイドでも、MCPサーバーやコネクタを通じて Google Workspace や Dropbox などの外部サービスへアクセスし、必要なときだけモデルが機能を使う設計が示されています。まずは検索、参照、要約、比較、抽出のような読み取り中心の用途から始めると安全です。そこから次の段階として、承認付きでチケット起票、下書き保存、カレンダー登録、通知送信などの操作へ広げると、現場での効果が見えやすくなります。

一方で、何でもつなげばよいわけではありません。価値が出やすいのは、入力と出力の型が比較的決まっていて、人がレビューしやすい業務です。たとえばFAQ検索、議事録の関連資料収集、商品情報の整形、営業メモのCRM登録補助、経理問い合わせの一次整理などは導入しやすい領域です。逆に、権限が強すぎる基幹操作や、誤操作の影響が大きい本番設定変更、金額確定、契約更新のような処理は、最初から全面自動化せず、人手承認を前提にするべきです。MCPで価値を出すコツは、接続数を増やすことではなく、検索・判断・操作の流れを短くできる場所から着手することにあります。

第3章：サーバー・ツール・権限の設計方法

MCP導入で差がつくのは、つなぐこと自体よりも、サーバー・ツール・権限をどう切るかです。まずサーバー設計では、「業務ドメインごとに分ける」考え方が扱いやすいです。たとえば、社内ナレッジ検索サーバー、営業データ参照サーバー、申請ワークフローサーバーのように役割ごとに分けると、責任範囲と権限境界が明確になります。反対に、あらゆるSaaSと社内DBを1サーバーへ集約すると、便利そうに見えても権限設計と監査が難しくなります。MCP公式仕様でも、Tools、Resources、Prompts は独立した機能として整理されており、何をモデルに見せるか、何を実行させるかを分離して考える前提になっています。

次にツール設計では、ツールの粒度を大きくしすぎないことが大切です。たとえば「顧客管理を全部やる」より、「顧客検索」「商談メモ取得」「下書き保存」「承認付き更新」のように責務を分けたほうが、モデルの選択ミスも減り、レビューもしやすくなります。OpenAIのMCPツールガイドでも、`allowed_tools` を使ってモデルに見せるツールを絞ることで、コストと遅延を下げ、意思決定空間を狭めることが推奨されています。実務でも、最初から10個以上のツールを見せるより、業務ごとに必要な3〜5個へ絞るほうが安定しやすいです。

さらに重要なのが権限設計です。MCPの認可仕様は、HTTPベースの transport に対して transport-level authorization を定義しており、OAuth系の考え方を踏まえて制御する前提です。加えて、MCPのセキュリティベストプラクティスでは、least-privilege の段階的スコープ設計が推奨されています。つまり、最初から全権限を渡すのではなく、検索や参照のような低リスク操作だけを初期権限にし、更新や削除のような高リスク操作は後から個別に昇格させる形です。OpenAIの Responses API 側でも `require_approval` や `allowed_tools` を使って、ツール呼び出しを許可制にしたり、利用可能ツールを制限したりできます。設計の基本は、サーバーは役割で分け、ツールは責務で分け、権限は段階的に開くことです。

第4章：接続先が増えるほど重要になる安全管理

MCPは便利ですが、接続先が増えるほどリスクも増えます。MCP公式仕様では、任意のデータアクセスやコード実行につながる強力な機能であるため、ユーザー同意、データプライバシー、ツール安全性、サンプリング制御が重要だとされています。OpenAIのMCPガイドでも、remote MCP server は第三者サービスであり、機密データの送信、モデルによる操作実行、プロンプトインジェクション、URL埋め込みなどのリスクに注意するよう案内されています。とくに、ユーザー入力や外部文書をそのままモデルへ渡し、さらにそのモデルが強い権限のMCPツールを呼べる構成は、事故の起点になりやすいです。

また、MCP固有の注意点として、proxy 型の構成で起こる confused deputy 問題があります。MCPのセキュリティ文書では、第三者APIへの中継を行う MCP proxy server が、静的 client ID と動的登録、同意クッキーの組み合わせにより、適切なユーザー同意なしに認可コードを奪われるリスクがあると説明されています。このため、per-client consent を実装し、誰のどの要求でどの権限が使われたのかを明確に残すことが重要です。ここを曖昧にすると、MCPは便利な統合レイヤーであると同時に、権限混線の温床にもなりえます。

実務では、安全管理を三層で考えると整理しやすくなります。第一に接続先の信頼性です。OpenAIは、可能であれば公式提供元がホストするMCPサーバーを選ぶことを推奨しています。第二に権限の最小化です。最初は read-only と低権限スコープから始め、操作系ツールは approval 必須にします。第三に監査です。どの入力で、どのツールが、どんな引数で呼ばれ、どのデータが外部へ送られたかをログ化します。OpenAIのガイドでも、MCPサーバーへ送るデータをログし、定期レビューすることが勧められています。つまり、MCPの安全性は一つの設定で担保されるものではなく、接続先審査、権限分離、承認、監査ログを重ねて作るものです。

第5章：業務利用で効く実装パターン集

最後に、業務利用で効きやすい実装パターンを整理します。まず導入しやすいのは「検索＋取得＋要約」の read-only パターンです。たとえば社内規程や手順書を格納したMCPサーバーを用意し、`search` と `fetch` を中心に文書検索を行う形です。OpenAIが公開している MCP サーバー構築ガイドでも、ChatGPT deep research や company knowledge 向けの互換サーバーとして、read-only の `search` と `fetch` を実装する形が案内されています。この構成は、ナレッジ検索、監査資料の収集、FAQ裏どり、議事録の関連文書参照などに向いています。

次に効果が高いのは「参照＋下書き＋承認付き更新」の半自動パターンです。たとえば、Slack や Gmail で関連情報を集め、社内DBやCRMを照会し、AIが返信案や登録内容の下書きを作り、人が確認後にチケット起票や更新を実行する形です。この構成なら、誤操作リスクを抑えつつ、担当者の検索・転記・整形の負荷を減らせます。また、OpenAIのMCPツールガイドが示すように、複数のMCPサーバーと web search、code interpreter などの他ツールを組み合わせると、価格比較、障害調査、売上分析のような多段処理にも広げやすくなります。

さらに最近は、MCP Apps のようにツールが対話内でUIを返す方向も注目されています。2026年初頭に正式拡張として公開された MCP Apps では、ツール結果を plain text ではなく、ダッシュボード、フォーム、可視化、レビュー画面として返し、クライアント側が sandboxed iframe で描画する仕組みが整備されました。これは、テキストだけでは扱いにくい設定ウィザード、帳票確認、地図、監視ダッシュボード、契約レビューなどと相性が良いです。つまり、MCPの業務活用は「AIに全部やらせる」方向だけでなく、AIが文脈整理を行い、人は必要な場面でUI上で判断する形へ進んでいます。まずは read-only パターンで成果を出し、次に approval 付き更新、最後に UI を伴うワークフローへ広げると、現場での定着率は高まりやすくなります。

MCPは、AIを外部システムへ安全に接続するための共通基盤として、今後ますます重要になります。ポイントは、MCPそのものを魔法の仕組みと見るのではなく、何をつなぐと価値が出るか、どう権限を絞るか、どこで人の承認を残すかを設計することです。まずは検索や取得のような read-only パターンから始め、`allowed_tools`、`require_approval`、最小権限、監査ログを基本に据えてください。そのうえで、下書き生成や承認付き更新へ広げれば、MCPは単なる技術トレンドではなく、業務で効く実装パターンとして育てやすくなります。