MCP連携で何ができるのか｜業務システム接続のユースケースと既製／自作の選定基準【2026年8月版】

執筆: 武石幸之助（x3d株式会社代表取締役）
公開日: 2026年7月28日
最終更新日: 2026年8月5日

【結論】MCP連携とは、業務システムをMCPサーバー経由でAIに接続し、AIから直接参照・操作できる状態にすることです。

できることは4分類（参照・実行・横断・再利用）。「接続できるか」より「どの接続先から着手するか」が成果を分ける
主要SaaSは提供元自身の first-party MCPサーバーが利用でき、自作が必要なのは社内DB・基幹システム・独自ツールに限られる
見落とされやすいコストは、初期実装費ではなくスキーマ変更への追従・監査ログ・権限棚卸しの継続工数

この記事では、MCP連携の導入を検討する開発者・情報システム部門向けに、接続先の優先順位づけと「既製を使うか自作するか」の判断基準を解説します。

※本記事は「何につなぐか／既製か自作か」の選定に絞っています。仕組みの基礎はMCPサーバーとは？（x3d 公式ガイド）、自作時の設計判断はMCPサーバー自作ガイド、Claude Codeからの設定手順はClaude CodeでMCP連携する方法を参照してください。

MCP連携でできることの4分類

MCP連携とは、業務システムをMCPサーバー経由でAIに接続し、AIから直接参照・操作できる状態にすることです。従来のAPI連携と違うのは、接続実装がクライアントに依存しない点です。MCPという1つの標準に沿ってサーバーを用意すれば、Claude Code・Cursor・Codex のどれからでも同じ連携を再利用できます。

できることを整理すると、次の4分類に収まります。

分類	できること	具体例	効果が出やすい条件
参照	社内の情報をAIが根拠つきで読む	規程・仕様書・ナレッジベースの横断検索	情報が散在し、探す時間が長い業務
実行	AIが業務システムを操作する	Issue作成、PRレビュー、チケット更新	手順が定型で、件数が多い作業
横断	複数システムをまたいだ処理を1フローで完結	エラー情報を取得してIssueを起票し、担当に通知	ツール間の転記・コピペが発生している業務
再利用	一度作った接続を別のAIツールから使う	自作サーバーをCursorとClaude Codeの両方で利用	組織内で複数のAIツールが併存している場合

この4分類のうち、最初に着手すべきは「参照」です。参照は読み取り専用のため権限設計の難易度が低く、失敗しても業務データが壊れません。「実行」から入ると、権限設計と承認フローの設計が同時に必要になり、PoCが止まりやすくなります。

接続先の優先順位をどうつけるか

MCP連携が失敗する典型は、「つなげるものを全部つなぐ」ことです。接続先が増えるとAIが呼ぶツールの候補が増え、誤ったツールを選ぶ確率が上がります。運用負荷も接続先の数に比例します。

優先順位は、次の3つの軸で判断します。

判断軸	問い	高スコアの条件
頻度 × 時間	その作業は週に何回発生し、1回あたり何分かかるか	毎日発生し、1回10分以上かかる
実装の容易さ	first-party の既製サーバーが存在するか	提供元が公式MCPサーバーを公開している
リスクの低さ	失敗したときに何が壊れるか	読み取り専用で、誤りが業務データに波及しない

3軸すべてが高い接続先から始めます。実務上は、開発組織であれば GitHub の参照系、ナレッジ活用であれば Notion や社内Wikiの参照系が最初の候補になります。x3dの支援現場でも、1接続先・読み取り専用・ツール3個以内を初回スコープの目安にしています。

既製を使うか自作するかの判断基準

ここが最も判断を誤りやすい部分です。結論は「両方を使い分ける」ですが、境界線を明確にしておく必要があります。

判断項目	既製（first-party）を使う	自作する
接続先	GitHub・Notion・Sentry・Stripe など主要SaaS	社内DB・基幹システム・独自業務SaaS
初期工数	設定のみ。コード実装は不要なケースも多い	設計＋実装＋テストが必要
権限の細かさ	提供元が用意した範囲に依存	業務単位・ツール単位で自由に絞れる
API変更への追従	提供元が対応	自社で追従。継続工数が発生する
監査要件への適合	提供元のログ仕様に依存	自社の監査要件に合わせて設計できる
選ぶべき場面	標準的な使い方で足りる／早く試したい	最小権限や監査要件が厳しい／既製が存在しない

判断の順序は単純です。まず公式レジストリで既製サーバーの存在を確認し、なければ自作を検討する。既製が存在するのに自作するのは工数の無駄であり、逆に監査要件が厳しい社内データを既製の汎用サーバーで済ませようとすると、権限を絞れずに導入が止まります。

自作を選んだ場合の設計判断（公開範囲・トランスポート・権限）は、社内システムをAIエージェントにつなぐMCPサーバー自作ガイドで詳しく解説しています。

2026年8月時点で実在が確認できる主要な既製MCPサーバー

既製サーバーを探すときの起点は、公式のMCPレジストリ（registry.modelcontextprotocol.io）です。2025年9月8日からプレビュー提供されており、Anthropic・GitHub・PulseMCP・Microsoft などが支えるMCPサーバーのメタデータ集約先として運営されています。

ここで実務上きわめて重要な注意点があります。Anthropic が当初 reference 実装として公開していたサーバー（GitHub・Slack・PostgreSQL・Sentry など）の多くは現在アーカイブされており、各ベンダーが提供する first-party 実装への移行が進んでいます。「公式」と紹介されている情報が古いアーカイブ版を指しているケースがあるため、導入前にメンテナンス主体を必ず確認してください。

サーバー	メンテナンス主体	主な用途
GitHub MCP	GitHub（first-party）	リポジトリ・Issue・PR・GitHub Actions の参照と操作
Notion MCP	Notion（first-party）	ページ・データベースの参照・更新
Sentry MCP	Sentry（first-party）	エラー・トレースの取得、Issue triage への組み込み
Stripe MCP	Stripe（first-party）	決済データの参照・操作（APIキーのスコープで権限を制御）
Supabase MCP	Supabase（first-party）	データベース・プロジェクト操作
Playwright MCP	Microsoft（first-party）	ブラウザ操作、E2Eテスト、スクリーンショット取得
Filesystem / Git / Memory / Fetch / Time / Sequential Thinking	MCP steering group（公式 reference）	ローカルファイル・Git操作・短期メモリ・Web取得などの基本機能
Slack MCP	コミュニティ（Anthropic の旧 reference 実装がアーカイブ後、Zencoder がメンテナンス）	チャンネル一覧、メッセージ送受信

Slack のように提供元自身の first-party 実装が存在しない接続先では、コミュニティ実装を使うかどうかの判断が必要です。判断材料はリポジトリの更新頻度・コントリビュータ数・最終コミット日で、これは通常のOSS採用判断と同じです。基幹業務に組み込むなら、コミュニティ実装への依存は避けて自作する選択も現実的です。

費用と運用負荷の考え方 — 見落とされる継続コスト

MCP連携の投資判断で誤りやすいのは、初期実装費だけを見積もることです。実際に効いてくるのは継続的に発生する運用工数です。

コスト項目	発生タイミング	見落とすと何が起きるか
接続先APIの仕様変更への追従	継続（接続先の更新ごと）	ある日突然ツールが失敗し、原因調査に時間を取られる
ツールスキーマ変更の周知	継続（自作サーバーの改修ごと）	引数名の変更で既存の手順書・プロンプトが動かなくなる
権限の棚卸し	定期（人事異動・組織変更ごと）	退職者・異動者の権限でAIが動き続ける
監査ログの保管と点検	継続	問題発生時に「誰が何をしたか」を再構成できない
LLM利用料（トークン消費）	継続（利用量に比例）	ツール定義や取得データが大きいと想定外の費用が出る

トークン消費については、接続するツール数そのものがコストになる点を押さえておく必要があります。AIはどのツールを呼ぶかを判断するために、接続されたツールの定義（名前・説明文・入力スキーマ）を読み込みます。接続先を増やすほど、1回のやり取りで消費するトークンが増えます。接続先を絞ることは、精度とコストの両方に効く設計判断です。

なお、現行仕様 2026-07-28 では tools/list などの一覧結果に有効期限（ttlMs）とキャッシュ範囲（cacheScope）が付与され、クライアント側でツール一覧をキャッシュできます。これはトークンコストの削減に直結します（出典: The 2026-07-28 Specification）。

導入企業がつまずく3つのポイント

1. 権限設計（誰の権限でAIが動くか）
最頻出の問題です。MCPサーバーを単一のサービスアカウントで動かすと、AIを使う全員が同じ権限を持ちます。人事・原価・与信などのデータを扱う場合、参照権限のない情報までAI経由で見えることになります。設計時点で「実行者の権限を引き継ぐ」か「ツール単位で範囲を絞る」かを決めます。

2. 監査ログの粒度
「ツールが呼ばれた」だけを記録していると、問題が起きたときに再現できません。いつ・誰が・どのツールを・どの引数で呼び、何が返ったかまで残します。同時に、引数や戻り値には機密情報が入るため、マスキング方針をログ設計と併せて決めます。組織の運用ルールに落とす際は、総務省・経済産業省の「AI事業者ガイドライン」が参照点になります。2026年3月31日に第1.2版が公表され、AIエージェントに関する定義とリスクの記述が追記されました。

3. スキーマ変更の管理
自作サーバーのツール引数を変えると、それを前提にした社内の手順書やプロンプトが動かなくなります。「サーバーを直したら業務が止まった」という事故はここから起きます。変更時の周知ルールと互換性の方針を、運用開始前に決めておきます。

これらは実装の問題ではなく運用設計の問題です。外部から取り込んだテキストがツールを誤発火させるリスクについてはプロンプトインジェクションとAIエージェント導入企業が備えるべきセキュリティ、承認フローの設計はHuman in the Loop（HITL）を参照してください。本番運用に必要な観測・コスト・権限の設計はAIエージェントを本番運用するための基盤設計で扱っています。

接続先の選定と社内展開を体系的に進めるには、技術判断と組織設計を切り分ける視点が必要です。x3dでは4層理論をその枠組みとして用い、AI時代のエンジニア・PM育成研修のAIエージェント開発マスターで実装・運用スキルまでを扱っています。

よくある質問（FAQ）

Q1. MCP連携とは何ですか？

MCP連携とは、業務システムをMCPサーバー経由でAIに接続し、AIから直接参照・操作できる状態にすることです。従来のAPI連携との違いは、接続実装がクライアントに依存しない点です。MCPという標準に沿ってサーバーを用意すれば、Claude Code・Cursor・Codex のどれからでも同じ連携を再利用できます。

Q2. MCP連携で具体的に何ができますか？

4分類に整理できます。（1）参照：社内の規程・仕様書・ナレッジをAIが根拠つきで読む、（2）実行：Issue作成やチケット更新などをAIが操作する、（3）横断：複数システムをまたぐ処理を1フローで完結する、（4）再利用：一度作った接続を別のAIツールから使う。最初に着手すべきは権限設計の難易度が低い「参照」です。

Q3. どの接続先から始めるべきですか？

頻度×時間・実装の容易さ・リスクの低さの3軸で判断し、すべてが高い接続先から始めます。目安は「1接続先・読み取り専用・ツール3個以内」です。つなげるものを全部つなぐと、AIが誤ったツールを選ぶ確率が上がり、運用負荷も接続先の数に比例して増えます。

Q4. 既製のMCPサーバーと自作はどう使い分けますか？

まず公式レジストリで既製サーバーの存在を確認し、なければ自作を検討します。GitHub・Notion・Sentry・Stripe など主要SaaSは提供元自身の first-party 実装があるため既製が効率的です。自作が必要なのは社内DB・基幹システム・独自業務SaaSで、最小権限や監査要件が厳しい場合も自作が適します。

Q5. 「公式」と書かれたMCPサーバーを使えば安心ですか？

確認が必要です。Anthropic が当初 reference 実装として公開していたサーバー（GitHub・Slack・PostgreSQL・Sentry など）の多くはアーカイブされており、各ベンダーの first-party 実装への移行が進んでいます。紹介記事が古いアーカイブ版を指している場合があるため、導入前にメンテナンス主体と最終更新日を必ず確認してください。

Q6. MCP連携のコストで見落としやすいものは何ですか？

初期実装費ではなく継続工数です。接続先APIの仕様変更への追従、ツールスキーマ変更の周知、権限の棚卸し、監査ログの保管と点検、そしてLLM利用料が継続的に発生します。特に接続するツール数が増えると、AIがツール定義を読み込む分だけトークン消費が増える点が見落とされやすいです。

Q7. 接続先を増やすと精度は上がりますか？

上がるとは限りません。接続先が増えるとAIが選べるツールの候補が増え、誤ったツールを選ぶ確率が上がります。同時にツール定義の読み込みでトークン消費も増えます。接続先を絞ることは、精度とコストの両方に効く設計判断です。業務単位でサーバーを分ける方法も有効です。

Q8. 導入企業が最もつまずくのはどこですか？

権限設計です。MCPサーバーを単一のサービスアカウントで動かすと、AIを使う全員が同じ権限を持ち、参照権限のない情報までAI経由で見えます。次に多いのが監査ログの粒度不足と、自作サーバーのスキーマ変更で既存の手順書が動かなくなる問題です。いずれも実装ではなく運用設計の課題です。

Q9. コミュニティ製のMCPサーバーは業務利用してよいですか？

通常のOSS採用判断と同じ基準で評価します。リポジトリの更新頻度・コントリビュータ数・最終コミット日を確認します。Slack のように提供元自身の first-party 実装が存在しない接続先ではコミュニティ実装が選択肢になりますが、基幹業務に組み込む場合は依存を避けて自作する判断も現実的です。

Q10. MCP連携の接続先選定をx3dに相談できますか？

可能です。x3d株式会社では、接続先の仕分けから権限・監査設計、社内エンジニアへの内製化までを支援しています。AI時代のエンジニア・PM育成研修では、AIエージェント開発マスターやRAGOps／運用保守マスターといった講座で、MCP連携を含むAIエージェント基盤の設計・運用スキルを扱っています。

参考文献・出典

本記事は2026年8月時点の公開情報に基づいています。MCPサーバーの提供状況とメンテナンス主体は変動するため、導入時はmodelcontextprotocol.ioおよび各提供元の公式情報をご確認ください。

武石幸之助
x3d株式会社代表取締役。2017年より企業のAI導入支援に従事し、これまで1,800社超の法人支援、5,000名超の研修登壇実績を持つ（受講満足度99%／2024年度研修アンケート）。AIエージェント・MCP連携の設計から社内定着までを一貫して支援し、技術実装と組織設計の両面から企業のAI活用を伴走している。

x3d株式会社では、本記事で解説したMCP連携・業務システム接続に関する企業研修・導入支援を提供しています。
まずはお気軽にご相談ください。

→ 無料相談・お問い合わせはこちら