生成AIに外部ツールを使わせる方法は、大きく4つあります。ブラウザ操作、API連携、CLI連携、そしてMCP連携です。この記事では、4つの違いを図解で整理します。そのうえで、多くの人がつまずく「MCPとAPIは結局何が違うのか」に仕組みから答えます。
「MCPを入れれば楽になる」という理解のまま進めて手戻りする企業を、導入支援の現場で何社も見てきました。読み終えたときに、自社で最初に手を付けるべき方式が1つ決まる状態を目指しています。根拠にしたのは、MCPの公式仕様（リビジョン2025-11-25）と、AnthropicおよびOpenAIの公式ドキュメントです。結論を先に言うと、4つは優劣ではなく、担当する層が違います。
生成AIを外部ツールにつなぐ4つの方法
生成AIの機能拡張は、ブラウザ操作・API連携・CLI連携・MCP連携の4つに整理できます。どれもゴールは同じで、「AIが自分の中だけで完結せず、社外のデータや業務システムを触れるようにする」ことです。
違いは、AIがどの層を触るかにあります。ブラウザ操作は、人と同じように画面を見てクリックします。APIとCLIは、開発者が書いた接続を通して機能を呼び出します。
MCPだけは少し性質が異なります。接続そのものではなく、接続の「規格」を共通化し、一度作った接続を使い回せるようにする仕組みです。
4つの方式は、実装コストと自由度がほぼ反比例します。
| 方式 | 主に使う人 | 実装コスト | 自由度 | 向いている場面 |
|---|---|---|---|---|
| ブラウザ操作 | 現場の業務担当者 | ほぼゼロ | 高いが、遅くて精度が落ちる | APIのない画面、ログインが必要な作業 |
| API連携 | 開発者 | 高い | 最も高い | 自社サービスへの組み込み、大量処理 |
| CLI連携 | 開発者、情シス | 中くらい | 高い | 既存コマンドの流用、バッチ処理 |
| MCP連携 | 開発者、情シス | 中くらい | 高い | 複数のAIアプリから同じ社内システムを使う |
この4つは排他ではありません。実際の現場では、開発チームがMCPサーバーを整備し、自社プロダクトにはAPIを組み込み、どうしても届かない画面だけブラウザ操作で埋める、という併存になります。
ブラウザ操作 — 他に手段がない画面への最終手段
ブラウザ操作は、AIに人と同じ方法でブラウザを触らせる方式です。画面を見て、ボタンを押し、フォームに入力します。AnthropicのClaude for Chromeや、OpenAIがCodex向けに提供しているChrome拡張機能がこれにあたります。
できることは、人がブラウザでやっている作業とほぼ同じです。Claude for Chromeは、サイトのクリックやフォーム入力に加えて、GmailやGoogle Drive、分析ダッシュボードの操作に対応します。提供範囲は段階的に広がり、2025年11月24日にMaxプラン全体、2025年12月18日にPro・Team・Enterpriseへ拡大しました。
OpenAI側のCodex向け拡張も考え方は同じです。Codexのプラグインとして追加し、Chrome拡張をインストールして接続します。以後はプロンプトで「@Chrome」と指定すると、Salesforceの更新やGmailの確認、社内ツールへのログインといった作業を任せられます（Codex Chrome Extension の解説記事）。
最大の利点は、相手を選ばないことです。画面が表示できさえすれば、APIが公開されていない業務システムでも操作できます。ログイン済みのブラウザセッションをそのまま使えるため、認証の作り込みも不要です。
一方で、弱点も方式そのものに由来します。ブラウザ操作は「スクリーンショットを撮る→画面を解釈して座標を決める→クリックする→また撮って確認する」というループで動きます。1操作ごとに画像の解釈が挟まるため、API経由と比べて明確に遅く、精度も落ちます。
これは実装の未熟さではなく、公式も認めている性質です。Anthropicはコンピュータ操作機能について、現段階では実験的で、時に扱いにくくエラーが起きやすいと明記しています。スクロールやドラッグ、ズームのような人間が難なく行う操作も、現状は難しいとしています。
もう1つ、セキュリティ上の固有リスクがあります。閲覧しているWebページに仕込まれた指示をAIが読んでしまう、プロンプトインジェクションです。AnthropicがClaude for Chromeの発表で公開したテストでは、対策を講じない状態で意図的に狙われた場合の攻撃成功率は23.6%でした。
対策を導入した後でも11.2%が残ります。同社は保護機能が万全ではないことを明記し、金融取引やパスワード管理、機密性の高い個人データの取り扱いには使わないよう呼びかけています。
したがって、ブラウザ操作は主力ではなく最終手段として位置づけるのが現実的です。APIもCLIもMCPも用意できない画面に限って使い、扱う情報の機微度で線を引いてください。ブラウザ操作の型の使い分けは、AIにブラウザを操作させる4つの型で詳しく整理しています。
API連携 — 自社サービスへの組み込み手段
API連携は、自社のシステムやサービスの中に生成AIを組み込むときの標準的な手段です。開発者が自分のプログラムからAIのAPIを呼び出し、必要なツールを自分で定義します。
ここで押さえておきたいのが、AIモデル自身は外部のAPIを直接叩かないという点です。Anthropicのツール利用（tool use）の公式ドキュメントには、その分担が明記されています。開発者が定義したツールは、開発者のアプリケーションの中で実行されるという記述です。実際の流れはこうなります。
- 開発者がツールの名前・説明・入力スキーマをAIに渡す
- AIが「このツールをこの引数で使いたい」と返す
- 開発者のコードがそのツールを実行する
- 実行結果をAIに返し、AIが最終的な回答を作る
AIは「何を使いたいか」を決めるだけで、実行するのは常に人が書いたコードです。この分担を理解しておくと、後述するMCPの位置づけも一気に分かりやすくなります。
API連携の強みは自由度で、弱みは開発量です。接続先ごとに認証・エラー処理・レート制限の扱いを書く必要があり、つなぐ相手が増えるほどコードが増えます。どのAPIを選ぶかで工数が変わる点は、AIエージェント向け検索API選択ガイドでも整理しています。
CLI連携 — 既存資産の使い回し
CLI連携は、ターミナルで動くコマンドをAIに使わせる方法です。Claude CodeやCodexのようなCLI型のAIエージェントは、シェルコマンドを実行できます。つまり、社内にすでにあるスクリプトやコマンドラインツールが、そのままAIの道具になります。
この方式の利点は、新しく接続を作らなくてよいことです。gitでもpsqlでも、普段エンジニアが叩いているものをAIに叩かせるだけで済みます。ファイル操作やビルド、デプロイのように、もともとコマンドで完結する仕事とは相性が良い方式です。
見落としやすいのは、トークン効率の面でCLIが有利になる場面があることです。後述するMCPは、接続したサーバーが持つツールの一覧をAIに読み込ませます。サーバーを増やすほど、この一覧だけでコンテキスト（AIが一度に読み込める情報量）を消費します。
単純な処理であれば、コマンドを1行実行させたほうが軽く済みます。CLIとMCPは対立するものではなく、処理の重さで使い分ける対象です。
弱点は、実行環境と権限の管理です。AIにシェルを触らせる以上、誤ったコマンドが走るリスクがあります。実行できるコマンドを許可リストで絞る運用が前提になります。
CLI型エージェントの実装の広がりについては、OpenAI Codex App Serverとはも参考になります。
MCPとは何か — 接続の「規格」をそろえる仕組み
MCP（Model Context Protocol）は、AIアプリケーションと外部システムをつなぐためのオープンな標準規格です。Anthropicが2024年11月25日に、オープンソースとして公開しました。MCPの公式サイトは、これを「AIアプリケーションにとってのUSB-Cポート」と表現しています。
この比喩が的確なのは、MCPが機能ではなく形状をそろえるものだからです。USB-Cは電気を通す新技術ではなく、端子の形と通信のルールを統一した規格でした。MCPも同じで、AIが外部ツールを使うときの「つなぎ口」を統一します。
MCPが解決するのは組み合わせ爆発
MCPが減らすのは、機能ではなく接続の本数です。つなぐ組み合わせは、対象が増えるほど掛け算で膨らみます。AIアプリが2種類、つなぎたい外部サービスが10種類あれば、個別に実装すると2×10で20通りの接続コードが必要になります。
MCPを使うと、AIアプリ側にクライアントを1つずつ、サービス側にサーバーを1つずつ用意すれば済みます。2＋10で12個です。掛け算が足し算に変わる、というのがMCPの本質です。
3つ目のAIアプリを増やすとき、既存の10個のサーバーはそのまま使い回せます。この再利用性が、MCPを標準規格として広げた最大の理由です。
ホスト・クライアント・サーバーの3層
MCPが安全に機能するのは、ホスト・クライアント・サーバーで責任を分けているからです。MCPの公式仕様では、それぞれの責任範囲が次のように定義されています。
- ホスト／Claude DesktopやIDEなど、AIアプリ本体。接続の許可とセキュリティポリシーを管理する
- クライアント／ホストの中に置かれ、1つのサーバーと1対1で接続を保つ
- サーバー／外部サービスの機能を提供する側。ローカルのプロセスでもリモートのサービスでもよい
通信には、軽量な遠隔手続き呼び出しの規格であるJSON-RPC 2.0を使います。接続方式は2種類です。サーバーをサブプロセスとして起動し標準入出力でやり取りするstdioと、HTTPで通信するStreamable HTTPです。ローカルで動かすなら前者、リモートのサービスにつなぐなら後者になります。
サーバーが提供する3つの部品
MCPサーバーがAIに提供できるものは、ツール・リソース・プロンプトの3種類です。公式仕様では次のように定義されています。
- ツール（Tools）／AIモデルが実行できる関数。「メールを送る」「在庫を検索する」など
- リソース（Resources）／AIやユーザーが読むためのデータ。ログファイルや設計文書など
- プロンプト（Prompts）／定型の指示テンプレート。そのサービス固有の使い方を示す手順書など
逆に、クライアント側からサーバーに提供される機能もあります。サーバーがAIに推論を依頼するサンプリング、ユーザーに追加情報を尋ねるエリシテーション、作業してよい範囲を伝えるルーツの3つです。
つまりMCPは、単なるAPIの置き換えではありません。サーバーからAIに問い返す経路まで含めた、双方向のやり取りを前提にした設計になっています。
結局、MCPとAPIの違いは実行主体
MCPとAPIは競合するものではなく、層が違います。MCPサーバーの中身は、たいていAPIを呼んでいます。MCPはAPIを置き換えるのではなく、APIを「AIが使いやすい形」に包み直す層だと考えるのが正確です。
両者の違いは、突き詰めると「誰が処理を実行するか」に集約されます。
| 観点 | API | MCP |
|---|---|---|
| 誰のために設計されたか | 何を呼ぶか分かっているプログラム | 何を使うか自分で選ぶAIモデル |
| 使い方の伝え方 | 人間が読むドキュメントを開発者が実装に落とす | サーバーが自分の機能一覧をAIに提示する |
| 仕様のばらつき | サービスごとに認証も形式もばらばら | JSON-RPC 2.0で統一 |
| 再利用性 | アプリごとに書き直す | サーバーを他のAIアプリでも使い回せる |
| 実際に処理を実行する主体 | 開発者のアプリケーション | MCPサーバー |
MCPが業界標準になりつつあるのは、この再利用性が効いているためです。提唱元のAnthropic以外も、公式に対応を進めています。
OpenAIは、自社のAPIであるResponses APIについてMCP対応のドキュメントを公開しています。ChatGPTのApps SDKも、MCPサーバーを構成要素として組み込む設計です。Microsoftは2025年5月19日のWindows公式ブログで、Windows 11がMCPを基盤層として採用すると表明しました。Googleも Gemini API の公式ドキュメントでリモートMCPサーバーへの接続に触れています。
意識せずにMCPを使っている人も、すでに大勢います。ChatGPTやClaudeの画面でGoogle DriveやSlackをつなぐ「コネクタ」は、その実体がMCPだからです。OpenAIは公式ドキュメントで、コネクタを自社が保守するMCPのラッパーだと説明しています。Claude側のコネクタのヘルプも、MCPコネクタという名称で提供されています。
つまりMCPは、開発者だけのものではありません。現場が管理画面でSaaSを1つ接続した時点で、すでにMCPを使っています。
導入でつまずく4つのポイント
MCPは万能ではありません。導入支援の現場でよく出会う誤解は次の4つで、いずれも運用ルールで対処できます。
| よくある誤解 | 実際 | 対処 |
|---|---|---|
| MCPを入れれば賢くなる | つなぐサーバーが増えるほどツール一覧がコンテキストを圧迫する | 常用するサーバーだけ残し、使わないものは外す |
| MCPならAPIキーを渡さなくてよい | サーバー側の設定ファイルには認証情報を持たせる必要がある | 鍵は設定ファイルや環境変数で渡し、チャット欄に貼らない |
| 公開されているサーバーは安全 | 公式仕様は、ツールを任意コードの実行として扱うよう求めている | 提供元が明確なサーバーに限り、社内で許可制にする |
| つなげば自動で動く | ツール実行前のユーザー同意は、ホスト側の実装に委ねられている | 書き込み系の操作は承認を挟む設定にする |
とくに3つ目は重要です。MCPの公式仕様は、安全性に関する節でツールの説明文の扱いに触れています。信頼できるサーバーから得たものでない限り、信頼できないものとして扱うべきだという記述です。サーバーの説明文そのものが攻撃経路になりうる、という前提で設計されています。
そのうえで公式仕様は、プロトコル自体はこれらの原則を強制できないとも述べています。同意フローや権限制御を用意する責任は、実装する側にあります。社内展開の前に、誰がサーバーを追加してよいかを決めておく必要があります。
自社で最初にやるべきこと
最初の一歩は立場によって変わります。次の3つのうち、自社の状況に近いものから始めてください。
- 生成AIがまだ定着していない／ChatGPTやClaudeが標準で用意しているコネクタを1つだけ有効にする。中身はMCPなので、そのままMCP活用の第一歩になる
- 開発チームがAIエージェントを使っている／自社向けのMCPサーバーを1つだけ導入する。まず読み取り専用のものを選び、書き込み系は後に回す
- 自社サービスにAIを組み込みたい／API連携で設計する。ツールを実行するのは自社のコードだという前提で権限を設計する
選定でいちばん多い失敗は、方式を先に決めてしまうことです。「MCPが流行っているから」ではなく、つなぎたい相手が何個あるか、同じ接続を何種類のAIアプリから使うかで決まります。接続先が1つならAPIかCLIで十分で、複数のAIアプリから同じシステムを使うときに初めてMCPが元を取ります。
どの方式を選ぶにせよ、先に決めておくべきは権限の範囲です。読み取りだけを許すのか、書き込みまで任せるのかを最初に線引きしてください。自社だけで方式選定を進めにくい場合は、外部の伴走支援を使う選択肢もあります。
まとめ
生成AIの機能拡張は、ブラウザ操作・API連携・CLI連携・MCP連携の4層で考えると整理できます。優劣ではなく、AIが触る層と目的が違うだけです。ブラウザ操作だけは、他に手段がないときの最終手段という位置づけになります。
MCPとAPIの違いは、設計の対象にあります。APIは何を呼ぶか分かっているプログラムのためのもので、MCPは何を使うか自分で選ぶAIのためのものです。MCPサーバーの中身はAPIを呼んでいることが多く、両者は置き換え関係にありません。
そしてMCPが効くのは、接続を使い回せる場面に限られます。つなぎたい相手が1つだけなら、APIかCLIのほうが速くて軽い選択です。
まずは自社で「何個のシステムを、何種類のAIアプリからつなぎたいか」を数えてください。接続先が1つなら、APIかCLIで実装工数を見積もってください。複数のAIアプリから同じシステムを使うなら、読み取り専用のMCPサーバーを1つだけ試すところから始めてください。
なお、本記事の仕様に関する記述は2026年7月時点のMCP公式仕様（リビジョン2025-11-25）にもとづいています。仕様と各社の対応状況は更新されるため、実装前に公式ドキュメントで最新版を確認してください。
参考リンク
- Model Context Protocol 公式サイト
- MCP 公式仕様（リビジョン 2025-11-25）
- Introducing the Model Context Protocol（Anthropic, 2024年11月25日）
- Tool use overview（Anthropic 公式ドキュメント）
- Connectors and MCP servers（OpenAI 公式ドキュメント）
- Claude for Chrome の発表（Anthropic 公式ブログ）
監修者
池田 智彦 ｜ 株式会社Spovisor 代表取締役
NTTドコモ・KDDIで通信業界に21年従事し、グローバル／国内市場で10以上の新規事業の立ち上げと、1,000万ユーザー規模サービスの開発・運用を主導。事業戦略から海外展開、エンジニアリングまで横断する経験を活かし、2023年6月に株式会社Spovisorを設立。現在はAI・アプリ開発、生成AIコンサル、AI駆動開発支援、AI顧問など、企業のDXを実装まで伴走する支援に取り組む。
生成AI／AIエージェントを「成果」に変える、Spovisorの伴走支援
株式会社Spovisorは、生成AI・AIエージェントを「使ってみた」で終わらせず、業務やプロダクトに組み込んで成果を出すところまで伴走する実装パートナーです。
| 支援領域 | 内容 |
|---|---|
| 生成AI組み込みアプリ開発 | Claude／ChatGPT／AIエージェントを組み込んだ業務アプリや自社プロダクトの設計から実装まで支援 |
| 生成AI導入コンサル／AI顧問 | 経営課題や業務プロセスから導入ポイントを設計し、本番運用まで伴走 |
| AI駆動開発支援 | Claude Code／Codexを使った開発生産性向上を現場へ定着 |