MCPで変わるAI開発外注の新常識｜発注者が押さえる3つの変化点【2026年版】

AI開発の外注プロジェクトを進めようとして、ベンダー各社の提案書に並ぶ「MCP対応」「MCPサーバー」「MCPゲートウェイ」といった単語にとまどっていませんか。半年前に固めたRFPはMCPに一切触れておらず、稟議の期限は迫っている。提案書のどこを評価軸にすればよいのか、判断材料が見当たらないまま意思決定を迫られている方は少なくありません。

MCP（Model Context Protocol）は、Anthropicが2024年11月に発表したLLM（大規模言語モデル）と外部ツール・データソースを接続するための標準プロトコルです。2026年に入り、OpenAI・Anthropic・Google・Microsoftといった主要プラットフォームが採用を表明したことで、事実上の業界標準として位置づけられるようになりました。この標準化は単なる技術トレンドではなく、AI開発の外注プロセスそのもの──スコープ・体制・契約──を変えています。MCPそのものの仕組みを先に押さえたい方はMCP（Model Context Protocol）とはを参照してください。

しかし、発注者目線でこの変化を整理した情報源はまだ少なく、多くの記事は「MCPとは何か」「実装手順はどうか」といった技術解説に終始しています。結果として、発注を担当する立場の方は「自社の発注計画のどこを、どう修正すべきか」を判断できないまま、ベンダーの提案を受け止めることになりがちです。

本記事では、MCPの普及によってAI開発外注の「スコープ」「体制」「契約」の3領域がそれぞれどう変わったかを、発注者の意思決定軸で整理します。最後に、社内稟議や次回ベンダー面談にそのまま持ち込める修正項目チェックリストもまとめました。読み終えた時点で、「自社のRFPに足すべき1行」「ベンダーに聞くべき3つの質問」が言語化できる状態を目指します。

MCP普及でAI開発外注の何が変わったのか──発注者が今、見直すべき3つの変化点

2026年、4大プラットフォーム採用でMCPが事実上の業界標準に

MCPはAnthropicが2024年11月にオープンソースとして公開したプロトコルで、LLMが外部のツール・データソース・API・ファイルシステムなどに接続するための共通インタフェースを定めたものです。2025年から2026年にかけて、OpenAI・Google・Microsoftが相次いで対応を表明し、主要なAIプラットフォームすべてがMCPをサポートする状況になりました（Anthropic公式: Model Context Protocol）。

これは、Web開発における「HTTP」「JSON」のような「接続の共通言語」がAIエージェントの世界に登場したと捉えると分かりやすいでしょう。これまで各ベンダーが個別に作っていた「LLM と SaaS の接続コード」が、標準化された仕様の上で再利用できるようになります。MCPと従来のAPI連携との違いはMCPとAPIの違いで詳しく比較しています。

変化点1「スコープ」: 各ベンダーが個別にツール連携を実装していた時代の終わり

MCP普及前は、Slack連携・Salesforce連携・Notion連携といった一般的なツールとの接続を、AI開発会社が案件ごとにスクラッチで実装していました。MCP対応サーバーが公開された現在、汎用ツールとの連携は「既製のMCPサーバーを呼ぶ」だけで済むケースが大半です。

つまり、RFPで「Slack連携の開発」「GitHub連携の開発」と並べて見積を取っていた工程の多くは、外注スコープから消えるべき項目になりました。発注スコープを更新せずに見積を受領すると、「すでに無償で公開されている部品の再実装費用」を支払うことになります。

変化点2「体制」: 内製ライブラリ・自社開発から、公開MCPサーバー＋カスタムMCPサーバーの組み合わせへ

開発会社のチーム編成も変わりました。MCP普及以前は「LLMアプリ全体を一気通貫で内製するチーム」が標準でしたが、現在は以下の3類型に分かれつつあります。

• 公開MCPサーバーをアセンブル（組み合わせ）して短期で立ち上げる「組合型チーム」
• 自社固有の基幹システム向けにカスタムMCPサーバーをゼロから構築する「構築型チーム」
• 両者を併走させる「ハイブリッド型チーム」

どのチームに発注するかは、自社の既存システムの独自性、AI活用フェーズ、社内エンジニアの保守体制によって変わります。同じ案件でも、チームタイプが違えば総コストが2〜3倍変動することも珍しくありません。総コストの目安を把握したい場合はAIエージェント費用相場も併せて確認してください。

変化点3「契約」: 一括請負 →「サーバー単位の分離発注＋運用準委任」への分岐

MCPが「LLM側のロジック」と「MCPサーバー（接続層）」を疎結合に切り分けたことで、契約も一括請負からサブシステムごとの分離発注へ移行する余地が広がりました。

たとえば、汎用ツール連携は「公開MCPサーバーの設定費用」のみ、自社固有の基幹システム接続用MCPサーバーは「請負契約」、AIエージェント本体のチューニング・運用は「準委任契約」──と契約形態を分けることで、知財・運用責任・保守工数を明確に切り分けられます。一括請負のままだと、本来分離できるリスクとコストを発注者が抱え込むことになります。

本記事で扱う範囲と扱わない範囲

本記事では「発注者の意思決定がどう変わるか」に焦点を絞ります。MCPそのものの仕組み・実装手順・コードレベルの詳細、AI開発の費用相場や契約条項のひな型といった項目は扱いません。これらは別途、自社の専門記事や一次情報を参照してください。

それでは、3つの変化点を順に深掘りしていきます。

変化点1｜スコープ──「ツール連携の個別開発」が見積から消える

MCP登場前: N×M問題に支配されていたAI開発スコープ

MCP登場前、AI開発の見積で大きな比重を占めていたのが「ツール連携の個別実装」でした。たとえば「Slack・Salesforce・Notion・社内DB」の4つのデータソースを「営業支援エージェント・問い合わせ対応エージェント・経理エージェント」の3つのLLMエージェントから利用しようとすると、組み合わせは4×3＝12通りになります。

各エージェントがそれぞれのツールに対応するコードを個別に持つ必要があったため、「N個のデータソース × M個のエージェント = N×M個の実装」が発生していました。これが俗に「N×M問題」と呼ばれ、AI開発の見積を膨らませる主要因のひとつでした。

MCP登場後: N+M個の実装で済む構造への移行

MCPの本質は、この組み合わせ爆発を「N+M」に減らすことにあります。データソース側は「MCPサーバー」として一度実装すれば、どのLLMエージェントからも同じインタフェースで呼び出せます。LLM側も「MCPクライアント」を1回実装すれば、すべてのMCPサーバーに接続できます。

つまり、4つのデータソースと3つのエージェントの組み合わせは「4個のMCPサーバー + 3個のMCPクライアント = 7個の実装」で済みます。MCPサーバーが既に公開されていれば、その部分の開発工数もゼロになります。実際の業務でどのようなユースケースがあるかはMCPサーバーの業務活用パターンにまとめています。

発注スコープから「消えるべき項目」3例

具体的に、見積から削除を検討すべき項目は次のようなものです。

1. Slack・GitHub・Notion等の汎用SaaSとの個別連携実装: これらの大半は公開MCPサーバーが提供されており、独自実装は不要です。MCP公式のリファレンス実装やコミュニティ提供のMCPサーバーが多数公開されています（公式GitHub: modelcontextprotocol/servers）。
2. Google Drive・OneDrive・Box等のファイルストレージ連携: 同様に公開MCPサーバーが充実しています。
3. PostgreSQL・MySQL・SQLite等の汎用データベース読み取り: 公開MCPサーバーが利用可能です。

これらが見積に「開発項目」として並んでいる場合、ベンダーに「公開MCPサーバーの利用を検討した上での見積か」を確認してください。

発注スコープに「残るべき項目」3例

一方、MCP普及後も発注スコープに残すべき項目は次のとおりです。

1. 自社固有の基幹システム・社内データベースとの接続: 公開MCPサーバーは存在しないため、独自MCPサーバーの構築が必要です。
2. 業務ワークフロー設計・LLMプロンプト最適化: 自社業務に固有の論理は依然としてカスタム開発の対象です。
3. 評価・モニタリング・セキュリティ統制: ハルシネーション検知、権限管理、監査ログ、PII（個人識別情報）マスキングなど、運用に必要な周辺機能は標準化されていません。

RFP書き換えのチェック項目（5項目）

既存のRFPに以下の観点が反映されているか確認してください。

• 項目1: 「ツール連携」を一括して見積するのではなく、「公開MCPサーバーで対応する範囲」と「カスタムMCPサーバーで開発する範囲」を別立てで提示することを要件化する
• 項目2: 公開MCPサーバーを採用する場合の保守責任・バージョン追随責任の所在を明記させる
• 項目3: カスタムMCPサーバーは独立したサブシステムとして仕様書・テストケースを作成することを要件化する
• 項目4: 既存のSaaS連携については「公開MCPサーバーで代替できないか」をベンダーに確認させ、その判断根拠を提案書に記載させる
• 項目5: 評価・モニタリング・セキュリティ統制を「MCPサーバーとは別の独立要件」として切り出す

変化点2｜体制──MCPサーバーを「作る側」か「使う側」かで開発会社の選び方が変わる

開発会社のMCP対応スタイル3類型

MCP普及後、AI開発会社は概ね次の3タイプに分類できます。

1. 公開MCP活用型 公開されているMCPサーバーを組み合わせて、短期間でAIエージェントを立ち上げることを得意とするチームです。実装工数を抑えられる反面、自社固有の基幹システムとの深い連携には弱い傾向があります。PoC・社内ユースケースの立ち上げに向いています。

2. 自社MCP構築型 クライアント企業の基幹システムに合わせてカスタムMCPサーバーをゼロから構築することを得意とするチームです。難易度の高い既存システムとの連携に強い反面、初期コスト・期間が大きくなりがちです。エンタープライズ向けの本格運用フェーズに向いています。

3. ハイブリッド型 汎用部分は公開MCPサーバーを活用し、自社固有部分はカスタム構築するチームです。バランスは良いものの、両方の専門性を持つチームは現時点ではまだ少なく、ベンダー選定時には実績の確認が欠かせません。

外注プロセス全体の型を先に押さえたい場合はAIエージェント外注の進め方も参考にしてください。

自社が選ぶべきタイプの判定軸

どのタイプのチームに発注すべきかは、次の3つの軸で判断できます。

• 既存システムの独自性: 一般的なSaaSのみを使っているなら公開MCP活用型、独自開発の基幹システムが中心なら自社MCP構築型
• AI活用フェーズ: PoC・初期検証なら公開MCP活用型、本番運用・スケール段階なら自社MCP構築型またはハイブリッド型
• 社内エンジニア体制: 社内に保守できるエンジニアがいなければ運用が手厚い自社MCP構築型、社内に強いエンジニアがいるなら公開MCP活用型でも引き取り可能

発注者側に求められる新しい役割

MCP普及によって、発注者側にも新しい責任が増えました。MCPサーバーは「LLMが社内システムにアクセスする入口」となるため、誰がどのデータに、どの権限でアクセスできるかの設計は、ベンダー任せにできません。

具体的には次の責任が発注者に寄ってきます。

• 権限設計の合意責任: どのMCPサーバーに対し、どの業務ロール・どのAIエージェントが、どのリソースにアクセスできるかを業務側で定義する
• 監査ログ要件の合意責任: 誰がいつ何にアクセスしたかを記録する粒度・保存期間・確認頻度を定義する
• データ持ち出しリスクの判断責任: MCPサーバー経由でLLMに渡される情報の範囲・マスキング要否を業務側で判断する

これらはAI開発外注の従来の領域というよりも、情報セキュリティ・内部統制の領域です。情報システム部門・セキュリティ担当との連携を、プロジェクト初期から組み込んでください。

ベンダー面談で確認すべき5つの質問

候補ベンダーの面談時には、次の5つを確認してください。回答の具体性で、そのベンダーが「MCP前提の体制」を構築できているかが見えてきます。

1. 公開MCPサーバーの活用方針: どのツールについて、どの公開MCPサーバーの利用を検討していますか。採用しない場合、その理由は何ですか
2. 独自MCPサーバーの保守責任: 案件で開発する独自MCPサーバーの保守・バージョン追随は、運用フェーズで誰が担当しますか
3. 認証・認可設計: MCPサーバーへのアクセス権限はどの単位（ユーザー / ロール / エージェント）で管理しますか。SSOや既存のIAMとの連携は可能ですか
4. ログ・監査: MCPサーバーのリクエスト・レスポンスはどの粒度で記録されますか。ログの保存期間・参照方法はどうなりますか
5. モデル更新時の保守体制: 利用するLLM（GPT-4・Claude・Gemini等）のバージョンアップ・廃止に対し、どのような体制で追随しますか

変化点3｜契約──MCPサーバーは「サブシステム」として分離発注を検討する時代

一括請負から分離発注へ──MCPサーバーをサブシステムとして切り出す利点

MCPによる疎結合化は、契約の単位にも影響します。これまでAIエージェント開発は「LLMアプリ全体を1つの請負契約」で発注するケースが多数派でした。しかし、LLM側のロジックとMCPサーバー（接続層）が分離可能になった以上、それぞれを独立した契約として切り出した方が合理的なケースが増えています。

分離発注の主な利点は次のとおりです。

• 責任範囲の明確化: 「LLMの応答品質」と「データソース接続の正確性」のどちらに障害があったかを切り分けやすい
• コスト構造の透明化: MCPサーバーは「インフラ寄り」、LLM側は「アプリ寄り」と性質が異なるため、別契約のほうが妥当な工数算定がしやすい
• 将来のリプレースの容易さ: LLM側のベンダーを変えてもMCPサーバーは継続利用できる、あるいはその逆も可能になる

契約条項の具体的な設計方針はAIエージェント契約設計の勘所にまとめています。分離発注を検討する際の準拠先としてご確認ください。

PoCを2段階に分けると意思決定が早くなる

MCP普及前のPoCは「LLMエージェント全体を作って業務利用者に試してもらう」のが定番でした。MCP普及後は、PoCを2段階に分けるアプローチが効率的です。

• 段階1: MCPサーバー単独PoC: 自社の基幹システムに対するMCPサーバーをまず構築し、開発者がコマンドラインや既製のMCPクライアントから動作を確認する。データアクセスの正確性・速度・権限制御を検証する
• 段階2: エージェント連動PoC: 段階1で動作確認したMCPサーバーをLLMエージェントから利用し、業務利用者に試してもらう。プロンプト品質・UX・業務適合性を検証する

この2段階化により、「LLMの応答が悪いのか、データアクセスが悪いのか」を切り分けながら検証できます。一括PoCで「結局何が悪かったか分からない」状態に陥るリスクを下げられます。

契約形態の組み合わせ例

具体的な契約形態の組み合わせ例として、次のようなパターンが考えられます。

この組み合わせは案件特性によって変わります。重要なのは「一括請負」を初期解にせず、サブシステムごとに最適な契約形態を選ぶという発想を持つことです。

知財・データアクセス権・運用責任の切り分けの考え方

分離発注を進める際に注意すべきは、次の3点です。

• 知財の帰属: カスタムMCPサーバーのソースコードの帰属（発注者帰属 / ベンダー帰属 / 共有）を契約書で明示する。発注者帰属にしておくと、将来別ベンダーへ移行する際の制約が減ります
• データアクセス権: MCPサーバー経由でアクセスできるデータの範囲・利用目的を契約書で明示する。学習データへの転用・第三者提供の可否も合意します
• 運用責任: MCPサーバーの稼働監視・障害対応・セキュリティパッチ適用の責任分界点を契約書で明示する。準委任契約では責任分界が曖昧になりがちなので、SLAの定義を別添するのが安全です

契約条項の具体的なひな型については、自社の法務部門・契約専門家と相談の上で作成してください。

発注者が今週から見直すべき修正項目チェックリスト

ここまでで整理してきた3つの変化点を、社内稟議や次回ベンダー面談にそのまま持ち込める形でまとめます。既存のRFP・ベンダー比較表・稟議資料を見直す際の参照リストとしてご活用ください。

RFPに追記すべき条項テンプレ（5項目）

1. MCP対応の前提化: 「本案件は MCP（Model Context Protocol）をAIエージェントの標準接続プロトコルとして採用することを前提とする」と明記する
2. ツール連携の分離記述: 「ツール・データソース連携は、公開MCPサーバーで対応可能な範囲とカスタムMCPサーバーで開発する範囲を別立てで提案すること」と要件化する
3. 公開MCPサーバー採用の正当化: 「公開MCPサーバーを採用しない場合、その理由を提案書に記載すること」を要件化する
4. MCPサーバー保守責任の明示: 「カスタムMCPサーバーの運用フェーズにおける保守・バージョン追随の責任主体を提案書に明示すること」を要件化する
5. セキュリティ統制の別建て: 「権限管理・監査ログ・PIIマスキング等のセキュリティ統制要件は、MCPサーバー実装とは別の独立要件として提案すること」を要件化する

ベンダー比較表に追加すべき評価軸（5項目）

1. 公開MCPサーバーの活用実績: 過去案件で利用した公開MCPサーバーの種類・数
2. カスタムMCPサーバーの構築実績: ゼロから構築したMCPサーバーの本数・対象システム
3. MCP関連のオープンソース貢献: MCPサーバー・クライアントへのコントリビューション実績
4. 認証・認可・監査の設計力: 既存IAM・SSOとの統合実績、監査ログの設計事例
5. 保守体制: MCPサーバーの長期保守・バージョン追随の体制（人数・SLA・実績）

稟議資料に追記すべきリスク・前提条件（3項目）

1. 標準仕様の変動リスク: MCP仕様は2024年11月公開と歴史が浅く、今後仕様変更が発生する可能性がある。バージョン追随のための保守工数を予算に含める旨を明示する
2. 公開MCPサーバーの品質ばらつき: コミュニティ提供のMCPサーバーは品質・保守状況にばらつきがある。採用前に技術評価が必要である旨を明示する
3. 権限設計の社内合意工数: MCPサーバーの権限設計は情報システム部門・セキュリティ担当との合意が必要であり、業務側のリソース確保が前提となる旨を明示する

次回ベンダー面談で聞くべき質問リスト（5質問）

「変化点2」のセクションで挙げた5つの質問を、面談シートに転記してください。

1. 公開MCPサーバーの活用方針はどうですか
2. 独自MCPサーバーの保守責任はどうしますか
3. 認証・認可はどう設計しますか
4. ログ・監査の粒度・保存期間はどうしますか
5. モデル更新時の保守体制はどうですか

これらの質問への回答内容と具体性で、ベンダーの「MCP前提の体制」の成熟度が見えてきます。

まとめ──MCP対応は「ツール選び」ではなく「外注の設計思想」の問題

MCPの業界標準化は、AI開発の現場に新しい「便利機能」が登場した、というレベルの話ではありません。AI開発外注の設計思想そのものが「LLMアプリを一括で内製する時代」から「公開サーバーとカスタムサーバーを組み合わせてサブシステムとして運用する時代」へ移ったと捉える必要があります。

本記事で整理した変化点をあらためてまとめると、次のとおりです。

• スコープ: 汎用ツール連携は見積から消える。カスタム開発の対象は自社固有部分に絞る
• 体制: 開発会社の3類型（公開MCP活用型 / 自社MCP構築型 / ハイブリッド型）を理解し、自社のフェーズに合うタイプを選ぶ
• 契約: 一括請負を初期解にせず、MCPサーバーをサブシステムとして分離発注を検討する

半年前に固めたRFPや稟議資料を、この3つの軸で点検してください。「公開MCPサーバーで代替できる項目を見積から削除する」「ベンダー比較表にMCP関連の評価軸を追加する」「PoCを2段階に分ける」──この3つを今週中に着手するだけで、AI開発外注の意思決定の精度は大きく変わります。

MCP対応は単なるツール選びではなく、AI開発外注全体の設計思想を見直す機会です。自社の案件特性に合わせて、3つの変化点をどう取り込むかを設計し直すきっかけにしてください。