MCPとは何か──AIと社内データをつなぐ新標準と、製造業での「守れる設計」【2026年版】
先日、大手建材メーカーのシステム担当者からこんな相談を受けました。「生成AIに設計仕様書の話を聞かせたかったが、どうやってつなぐのかが分からなかった。API連携をゼロから実装するとなると、開発コストが見えなくて止まってしまった」。
この詰まり方をしている製造業は少なくありません。AIは十分賢い。問題は「AIが社内のデータを読めない」ことにあります。MCP(Model Context Protocol)はその問題を解決するために登場した共通規格です。製造業の現場でFDE(Forward Deployed Engineer)として関わってきた経験から、仕組みと「守れる設計」の実践を解説します。
1. なぜAIは「つながらない」のか
社内にはERP、生産管理システム、品質データベース、図面管理システムと、長年かけて積み上げてきた業務データが存在します。しかしそれらとAIをつなぐためには、これまでシステムごとに個別の連携開発が必要でした。コストが高く、変更に弱く、保守が困難——だからAI活用が止まる。
この構造的な問題を解決するために登場したのが、**MCP(Model Context Protocol)**です。

2. MCPとは何か──AIのUSB-Cが登場した
**MCP(Model Context Protocol)**とは、AIと外部システム・データソースを標準化された方法で接続するためのオープンプロトコルです。2024年11月、Anthropicが発表し、GitHubでオープンソースとして公開しました。
もっとも分かりやすい比喩は「AIのためのUSB-C」です。
USB-Cが登場する前、デバイスの充電には製品ごとに異なるコネクタが必要でした。iPhone用、Android用、PC用——それぞれ異なるケーブルを用意しなければなりませんでした。USB-Cはその煩雑さを解消し、一つの標準でさまざまなデバイスをつなぐ共通インターフェースになりました。
MCPはこれと同じことをAIの世界で実現します。これまでは「AIとSlackをつなぐ」「AIとデータベースをつなぐ」「AIとERPをつなぐ」——それぞれ個別の実装が必要でした。MCPを使えば、MCPサーバーを立てるだけで、AIが統一された方式でシステムに接続できるようになります。
2026年6月時点での普及状況を見ると、その速度は驚異的です。
- 月間SDKダウンロード数:9,700万回を突破(2026年4月時点・出典:月刊タレンタル)
- 対応プラットフォーム:OpenAI・Google・Microsoft・AWSの4大プロバイダーが公式採用
- MCP サーバー公開数:GitHub上に数千件が公開済み(2026年2月時点)
これはもはやAnthropicだけのプロトコルではありません。AI業界全体の事実上の標準(デファクトスタンダード)として定着しつつあります。

3. MCPの仕組み:3層構造と3つの機能
MCPを理解するために、まず3層構造を押さえてください。
┌─────────────────────────────────────────────┐
│ ユーザーが操作する AI アプリ │
│ (Claude Desktop / Cursor / VS Code 等) │
│ ↑ MCPホスト │
│ ↓ │
│ MCPクライアント │
│ (アプリ内でサーバーと通信) │
│ ↓ JSON-RPC 2.0 │
│ MCPサーバー │
│ (外部ツール・DBへのアクセスを提供) │
└─────────────────────────────────────────────┘
↓ 接続
社内DB / ERP / ファイルサーバー / API
MCPホストはユーザーが直接操作するAIアプリケーションです。Claude DesktopやCursor、またはVS Codeのような開発環境がこれにあたります。製造業の文脈では、社内展開したAIアシスタントがホストになります。
MCPクライアントはホスト内で動作し、MCPサーバーとの通信を仲介するコンポーネントです。ユーザーには見えませんが、AIとサーバーを正しくつなぐ役割を担います。
MCPサーバーは外部ツールやデータへのアクセスを提供する軽量プログラムです。生産管理DBのためのサーバー、図面管理システムのためのサーバー、といった形で用途ごとに立てます。通信にはJSON-RPC 2.0プロトコルを使用し、標準入出力(stdio)またはHTTPを通じてやり取りします。
MCPサーバーが提供する3つの機能
MCPサーバーがAIに提供できる機能は、以下の3種類に分類されます。
ツール(Tools)は、AIが外部システムに対してアクションを実行する機能です。「生産計画DBに新しいデータを書き込む」「品質検査結果を登録する」「ERPに発注データを送信する」といった操作を担います。AIが「考える」だけでなく、「動く」ことを可能にします。
リソース(Resources)は、AIが外部データを読み取る機能です。「過去3年分の品質データを取得する」「図面管理システムから該当図面を引っ張る」「生産実績ログを読み込む」といった情報取得を担います。AIが自社固有のデータを参照できるようになります。
プロンプト(Prompts)は、再利用可能なプロンプトテンプレートを提供する機能です。「品質不良レポートを生成する際の標準的な手順」「設備故障診断の質問フロー」といった業務特化した指示文のひな型をMCPサーバー側で管理し、AIに提供します。
この3つの組み合わせによって、AIは社内データを読み(リソース)、業務手順に沿って判断し(プロンプト)、結果をシステムに書き戻す(ツール)という一連のループを実行できるようになります。

4. なぜ2026年、MCPが企業のスタンダードになったのか
「2024年11月に発表されたプロトコルが、わずか1年半で9,700万ダウンロードに達する」——これは異例の速さです。なぜここまで急速に普及したのか。
理由1:OpenAIとGoogleも採用した「中立性」
MCPはAnthropicが開発しましたが、Anthropic専用のプロトコルではありません。2026年初頭には、競合するOpenAI・Google・Microsoft・AWSが相次いで公式サポートを表明しました。
これは重要な意味を持ちます。企業がMCPベースの連携を一度作れば、AIプロバイダーを変えても接続がそのまま使える。「ベンダーロックインを避けたい」という企業の声に、MCPは構造的に応えます。
理由2:「個別実装の地獄」からの解放
MCPが登場する前、AI連携の開発者たちは共通の悩みを抱えていました。「SlackとAIをつなぐコードを書いた。次はNotionとつなぐコードを書いた。次はERPとつなぐコードを書いた——やっていることはほとんど同じなのに、毎回ゼロから書き直している」。この非効率さが、AI活用の拡大を阻んでいました。
MCPはこの問題を構造から解決します。一度MCPサーバーとして実装すれば、あらゆるMCP対応AIから使えます。開発者にとっては作業が減り、企業にとっては保守コストが下がります。つまり「AI基盤を一度作れば、AIツールを乗り換えてもつなぎ直し不要」という状態が実現します。
理由3:生成AIから「AIエージェント」への転換
2026年、AI活用の最前線は「質問に答えてもらうAI」から「自律的に業務を実行するAIエージェント」へと移行しつつあります。AIエージェントが実際に価値を出すためには、社内システムを読み書きできる接続基盤が不可欠です。MCPはこのエージェント時代のインフラになりつつあります。
ForbesのAIトレンドレポートでも、「AIエージェントが牽引する2026年のテクノロジートレンド」の中心にMCPが位置づけられています。(AIエージェントが牽引する2026年の8つのテクノロジートレンド)

5. 製造業でのMCP活用:生産管理・品質・図面DBとの接続
製造業においてMCPが特に力を発揮するのは、**「孤立したシステム同士をAIが横断して使える環境」**を作る場面です。
ユースケース1:生産管理DB × AI
生産管理システムには、製造指図・実績・在庫・設備稼働データが蓄積されています。通常このデータはシステム内で完結し、「分析したいときはExcelに手動コピー」という運用が多い。
MCPを使えば、AIが生産管理DBに接続し、「今月の不良品発生数が多い工程と時間帯を教えて」という質問に直接答えられるようになります。
私たちが関わったある化学製造業の工場では、AIと生産管理DBをつなぐことで、品質異常の検知から原因候補のリストアップまでの時間が大幅に短縮されました。以前は「報告書を手で作って、会議で議論して、翌週に原因特定」という流れが、AIが実績データをリアルタイムで参照することで、当日中に初期仮説を立てられるようになりました。
ユースケース2:図面・仕様書DB × AI
製造業で最も価値が高く、最もデジタル化が遅れているデータの一つが「図面と仕様書」です。PDF図面、CADデータ、紙の仕様書——これらはシステム外に眠っていることが多い。
MCPのリソース機能を使えば、AIが図面管理システムから該当図面を取得し、「この部品の材質と加工精度を確認して、過去の類似部品の不良事例と照合してほしい」という複合的なリクエストに応えられます。
私たちが支援した大手建材メーカーでは、図面DBとAIを接続したことで、「過去の類似図面から塗装面積を概算する」「設計ミスのパターンを学習させて見落としを指摘する」という業務を実現しました。(AI-Path 公開導入事例 — 建材メーカー)
ユースケース3:ERPの受発注データ × AI
ERPは製造業のデータの中枢です。しかし「ERPに聞く」には専門知識が必要で、現場の担当者は困ったことがあっても情報システム部門に問い合わせるしかありませんでした。
MCPを介してAIがERPに接続できれば、現場担当者が自然言語で「今週の生産計画に対して、部品の在庫は足りているか。不足が見込まれるものを優先度順に教えて」と聞けるようになります。これはERPのUIを覚える必要もなく、SQL知識も不要です。
6. 守れる設計としてのMCP──セキュリティリスクと現場の対策
MCPは強力な接続基盤ですが、セキュリティを後回しにすると深刻なリスクを生みます。AI-Pathが「守れる設計」を掲げる理由は、MCPに関してもまったく同じです。
現状のリスク:認証なしのMCPサーバーが8,000件以上
トレンドマイクロの調査(2026年)によると、公開インターネット上に8,000を超えるMCPサーバーが露出しており、うち約500件は認証も暗号化もない状態でアドミンパネルに誰でもアクセスできる状態だったと報告されています。(公開状態のMCPサーバが機密データのバックドアとして悪用されるリスク)
製造業のデータは特に機密性が高い。図面・製造ノウハウ・顧客発注データが社外に流れることは、競争優位の喪失に直結します。
製造業が意識すべき3つのリスク
1. 認証・認可の不備 MCPサーバーには、「誰がどのデータにアクセスできるか」を厳密に制御する仕組みが必要です。工場長だから全データを参照できる、品質担当者だから品質DBのみアクセスできる——機能レベルのRBAC(ロールベースアクセス制御)をMCPサーバー側に実装しなければなりません。
2. ツールの過剰権限 MCPのツール機能でAIに「書き込み権限」を渡す場合、範囲を最小限に絞ることが重要です。「生産計画DBに読み取りアクセスできるMCPサーバー」と「生産指図の承認・送信ができるMCPサーバー」は別物として設計し、後者には人間の確認ステップを設ける設計にします。
3. プロンプトインジェクション攻撃 悪意のある入力によってAIが意図しないデータにアクセスしたり、システムを操作したりするリスクです。MCPサーバー側で入力バリデーションを実装し、AIが実行できる操作の範囲を厳密に定義することで対策します。
守れる設計の4原則
私たちがMCPを設計する際に守る原則は4つです。
原則1:最小権限の徹底。MCPサーバーがアクセスできるデータとアクションは、業務上必要な最小限に絞ります。「全DBに接続できるマスターMCPサーバー」は作りません。
原則2:書き込みには人間の承認。AIが外部システムに書き込む(ツール機能)場合は、承認ステップを設けます。AIは候補を提示し、人間が確認してから実行する設計にします。
原則3:監査ログの整備。MCPを通じたすべてのデータアクセスと操作をログに記録します。「誰がいつ何のデータをAIに渡したか」を追跡できる状態を維持します。
原則4:クローズドネットワークでの運用。製造業の機密データに接続するMCPサーバーは、インターネットに公開せずクローズドネットワーク内(オンプレミスまたは閉域クラウド)に置きます。Sovereign AI(ソブリンAI)の思想はMCPサーバーの配置にも適用されます。
7. FDEとして現場でMCPを設計して見えてきたこと
私たちAI-Pathは、製造業を中心とした企業にFDE(Forward Deployed Engineer)として現場に入り込み、AIシステムの設計・実装・定着まで責任を持つスタイルで仕事をしています。その経験からMCPについて正直に話します。
「つなぐこと」より「何をつなぐか」の設計が難しい
MCPの技術的な実装は、経験あるエンジニアであれば数日で動かせます。難しいのは「どのデータをAIに渡すか」の設計です。
製造業の社内データは膨大で、全部をAIに渡せばいいわけではありません。品質異常の検知に必要なのは、生産ログ・気温・設備稼働状態の3つで十分かもしれない。材料の発注判断に必要なのは、在庫数・製造計画・リードタイムの3つかもしれない。
**「AIに何を見せるか」を業務視点で設計できる人間がいなければ、MCPは接続されただけのシステムになります。**私たちが現場でやっているのは、この「何をつなぐか」の整理です。
データが汚いとAIも汚い
ある製造業のお客様から「MCPで生産管理DBをつないだが、AIの回答がバラバラで信頼できない」という相談を受けたことがあります。調べると、生産管理DBのデータ入力ルールが現場によって異なり、同じ「設備停止」でもコードが3種類存在していました。
MCPは接続基盤であって、データクレンジングはしてくれません。ゴミを入れればゴミが出てくる。AIに渡すデータの品質をどう担保するか——この問いへの答えが、MCPの前に必要な業務プロセス設計です。
小さく始めて、検証してから広げる
私たちが製造業へのMCP導入で繰り返し実践しているアプローチは「1つの業務・1つのシステム・1つのMCPサーバー」から始めることです。
品質データDBとAIをつなぐMCPサーバーを1つ作り、品質担当者3名が2週間使う。そこで見えた「このデータはAIに見せたくない」「この操作は人間が確認したい」という現場の声を反映してから次のシステムに拡張する。この積み上げ方が、製造業でMCPを定着させる実践的な道筋だと実感しています。
8. MCPで変わること、変わらないこと
MCPについて語る際、過大な期待と過小評価の両方があります。正直に整理します。
変わること
「システムごとの個別開発」が不要になる。一度MCPサーバーとして実装すれば、AIの種類が変わっても、AIツールが更新されても、接続がそのまま使えます。これはメンテナンスコストを大幅に下げます。
「AIが社内データを知らない」問題が解消される。汎用AIに自社の生産データ・品質ノウハウ・技術文書を持たせた「自社専用AI」を作ることが現実的なコストで実現できます。
「AIエージェントの実行範囲が広がる。ツール機能によって、AIが単に回答するだけでなく、承認された範囲で実際に業務を実行するエージェントとして機能できます。
変わらないこと
業務プロセスの設計は人間がやる。「どのデータをAIに渡すか」「どこまでAIに決めさせるか」「承認はどこで人間が入るか」——この設計は人間にしかできません。
データの品質はMCPでは解決しない。接続先データが汚ければ、AIの回答も汚い。MCPの前に、データの整理は必要です。
「AIが間違えたとき誰が気づくか」は変わらない。MCPによってAIが社内システムを操作できるようになるほど、ハルシネーション(誤情報生成)のリスクは大きくなります。人間の確認ポイントを設計から削除してはなりません。
9. まず何から始めるか
MCPを自社で活用するために、最初にやるべきことは技術の勉強ではありません。
「AIに何をさせたいか」を業務レベルで1つ決めることです。
「品質異常の初期分析を、毎朝AIが自動でやってレポートを出す」「設備が止まったとき、過去の類似事例をAIが10秒で調べて原因候補を3つ出す」——具体的なユースケースが決まれば、必要なMCPサーバーの設計も見えてきます。
ユースケースの設定に迷うなら、その前段として業務プロセスの棚卸しが必要です。現場のどの業務で、どのデータを使って、今どういう非効率が起きているか。この整理なしにMCPを導入しても、「つながったけど使われない」に終わります。
ユースケースの設定に迷う場合や、「そもそもどの業務からAIを使えばいいかわからない」という段階であれば、まず業務全体を棚卸しすることから始める方が確実です。
まず試すなら
- 自社の業務で「毎日データを見ているが分析できていない」場面を1つ特定する。品質ログ・生産実績・在庫データ——手作業でExcelに落としている業務が候補です。
- その業務でAIが答えるべき「問い」を1文で書く。「今週の不良品が多い工程はどこか」「在庫が不足しそうな部品はどれか」のように具体化します。
- AI-Pathの無償業務プロセス診断(BPR)に相談する。FDEが現場に入り、どのシステムのどのデータをMCPでAIに渡すべきかを整理します。1日で動くプロトタイプを作り、現場で検証するところまで伴走します。
AI-Pathでは、FDEが現場に入って業務プロセスを整理し、AIで効果が出る業務から順番に設計する無償の業務プロセス診断(BPR)を実施しています。お気軽にご相談ください。
MCPは強力な接続基盤です。ただし「何をつなぐか」の設計なしに動かしても価値は生まれません。まずは自社の業務から始めましょう。
関連記事
MCPをより深く理解するために、以下の記事も参照してください。
- FDEとは何か──AI導入を「成功」させる新しいパートナーの選び方:MCPを使って何をするか——「現場で定着させる」FDEの役割を解説します。
- RAGとは何か──社内ナレッジを「使える知識」に変える仕組みと、製造業での実践:MCPでデータをつなぎ、RAGで知識を引き出す——2つの技術の使い分けを解説します。
- ソブリンAIとは何か──製造業が自社データと技術ノウハウを守るための完全ガイド【2026年版】:MCPサーバーをどこに置くかはソブリンAIの問いと直結します。
まとめ
- MCPは、AIと社内システムをつなぐための新しい共通規格(オープンプロトコル)
- 2024年11月Anthropic発表。2026年時点でOpenAI・Google・Microsoft・AWS全社が採用
- 3層構造(ホスト・クライアント・サーバー)と3機能(ツール・リソース・プロンプト)で動く
- 製造業での活用は「生産管理DB」「図面・仕様書DB」「ERP」との接続が主戦場
- セキュリティは後回しにすると危険。最小権限・承認ステップ・監査ログ・閉域運用が基本
- 「つなぐ技術」は比較的簡単。「何をつなぐかの設計」が本質的な難しさ
関西大学法学部法律学科卒業。財務コンサルティング会社(エフアンドエム)、外資系生保営業(Prudential)でコンサルティング営業の経験を積んだ後、起業しさまざまな企業のCTO/CMOを歴任。その後、デロイトトーマツコンサルティング(Big4)、ABEJA(AI研究開発の国内リーディングカンパニー)にて官公庁・製造業・金融業・小売業・不動産業を中心に延べ20社以上のDX推進や業務システム刷新をPM/SMとしてリード。利用者目線での現場の課題解決にフォーカスしたものづくりに拘り、導入ではなく「定着化」を目的とした伴走型のプロジェクト推進・システム導入を得意とする。2025年にAI駆動開発(VibeCoding)と出会い、より多くの人・企業に価値提供するためにAI-Pathを創業。
関連コラム
AIエージェントの運用体制をどう作るか——「新入社員」として迎える発想の落とし穴
「AIエージェントを新入社員として迎えよう」という提案が広がる一方、2026年5月のハーバード・ビジネス・レビューはこの発想に警鐘を鳴らしました。AI-PathがFDEとして製造業の現場で見てきた、AI運用体制が定着する組織と崩れる組織の分かれ目をお伝えします。
AIで成果を出す組織の設計——人材採用より先に整えるべき3つの仕組み
「AI人材が欲しい」という相談が急増しています。しかしAI活用で本当の成果を出している企業はわずか6%。差は人材の数ではなく、仕組みにあります。BPRと連動した「採用より先に整えるべき3つの仕組み」をAI-Pathの現場経験からお伝えします。
AI導入より先にやるべきこと:業務プロセス診断(BPR)が成否を決める理由
AI導入率12%、最大障壁は「何から始めればいいかわからない」62%。失敗の原因は技術でも予算でもなく、業務プロセスを整理していなかったことにあります。FDEとして製造業・建設業・商社の現場に伴走してきた経験から、AI導入前に必要な業務プロセス診断(BPR)の具体的な3ステップを解説します。