MCPの連携でつながる相手｜公式サーバーがあるものと、ないもの
MCP（Model Context Protocol、AIと外部のツールやデータをつなぐための標準規格）でつながる相手は、大きく2種類に分かれます。提供元が公式のサーバーを配布しているサービスと、配布されていない自社の社内システムです。
この違いは、名前の違いではなく作業量の違いとして表れます。同じ「連携する」でも、前者は当日中に動き、後者は設計から始まります。自分がつなぎたい相手がどちらなのかを先に確かめておくと、見積もりが数日単位でずれることを避けられます。
関連記事：MCPとは？Model Context Protocolの仕組みとAPIとの違いを整理
公式サーバーが配布されているサービスは、つなぐだけで済む
GitHub、Notion、Slack、Figmaのように広く使われているサービスは、提供元が公式のMCPサーバーを配布しています。この場合に必要なのは、接続先の登録と、どの操作を許可するかの選択だけです。プログラムを書く場面はありません。
提供元が用意している以上、権限の粒度もあらかじめ決まった選択肢から選ぶ形になります。細かく切りたい要望があっても、提供元が用意していない切り方はできません。逆に言えば、仕様が変わったときの追随は提供元の仕事になります。
関連記事：MCPサーバーの使い方｜ローカル型とリモート型の違いと Claude での設定手順
公式サーバーがない社内システムは、用意する側に回る
販売管理、在庫、独自に作った社内データベースのように、提供元が存在しないシステムには公式サーバーがありません。この場合はMCPサーバーを自分たちで用意することになります。ここで初めて「どの操作をAIに見せるか」を設計する仕事が発生します。
設計と実装を伴うぶん手間はかかりますが、権限の切り方を自分たちで決められます。特定のテーブルの参照だけを許可する、更新は特定の項目に限る、といった細かい制御は自前で用意したときにしかできません。
MCPサーバーは既製で足りるか、自前で用意するか
公式サーバーがない相手なら、自前で用意する以外に選択肢はありません。迷うのは公式サーバーがある相手のほうで、登録するだけで使える既製サーバーに乗るか、手間をかけてでも自前を用意するかを選べます。分かれ目は、権限をどこまで細かく切る必要があるかです。基幹データを扱うなら自前に寄り、まず1業務を試すだけなら既製で足ります。
既製と自前を比べる
両者は手間と自由度が逆向きに動きます。
| 観点 | 既製の公式サーバーを使う | 自前でサーバーを用意する |
|---|---|---|
| 対象 | 提供元が公式サーバーを配布しているサービス | 公式サーバーがない社内システム・独自データベース |
| 最初にやること | 接続先の登録と権限の許可 | どの操作をAIに見せるかの設計と実装 |
| 権限の粒度 | 提供元が用意した範囲から選ぶ | 自分たちで決められる（決めなければならない） |
| 仕様変更への追随 | 提供元が対応する | 自分たちで追随する |
| 向いている場面 | まず1業務をつないで様子を見る | 基幹データを扱う・権限を細かく切りたい |
順番としては、公式サーバーがあるサービスを1つつないで手応えを掴んでから、足りない部分が見えた時点で自前を検討するのが無理のない進め方です。最初から自社システムの実装に取りかかると、AIに何をさせたいのかが固まる前に設計を始めることになります。
自前で用意すると決めたときに背負うもの
自分たちでサーバーを用意する場合、2026年7月28日に公開された仕様の変更が前提として効いてきます。この版でプロトコルレベルのセッション管理が取り除かれ、接続ごとに状態を保持する必要がなくなりました（出典: modelcontextprotocol.io）。サーバーを常時起動しておく必要が薄れ、置き場所の選択肢が広がっています。
一方で、複数回のやり取りをまたいで状態を持ちたい場合の作り方は変わりました。サーバーが発行した識別子を、次の呼び出しでツールの引数として受け取り直す形になります。作り始める前に、この形で自社の業務が表現できるかを確認しておくと手戻りが減ります。
業務システムとの連携でどのデータをAIに渡すかを先に決める
つなぐ相手が決まったら、次は渡す範囲です。ここを決めずにつないでしまうと、後から絞ろうとしたときに業務が止まります。GiftXが実施したビジネス職生成AI活用実態調査2026では、個人が抱える課題の1位が「どこまでAI活用していいか判断できない」で27.7%でした（自社調査、複数回答、出典は後述）。範囲を決められないことは、担当者の力量ではなく設計の問題として現れます。
読み取りだけ渡すか、書き込みまで渡すか
最初に分けるのは、AIに読ませるだけか、書き込みまで任せるかです。読み取りだけなら、間違った出力が出ても業務データは壊れません。確認は人が行い、反映も人が行う形です。
書き込みまで渡すと、AIの動作がそのまま業務データに残ります。効果は大きい代わりに、間違いも残ります。書き込みを許可する場合は、対象を特定の項目に絞る、下書きの状態で作らせて確定は人が行う、といった形で影響範囲を狭められないかを先に検討します。
渡さないと決めておく情報
渡す範囲を決める作業は、渡さないものを決める作業と表裏です。個人情報を含む列、他社との契約条件、従業員の評価や処遇に関わるデータは、業務上の必要がない限り接続対象から外しておきます。
判断が難しいのは、単体では問題ないが組み合わせると個人が特定できるデータです。氏名を外しても、部署と入社年と役職が揃えば1人に絞れることがあります。テーブル単位ではなく列単位で見て、AIに見せる必要が本当にあるかを1つずつ確認します。
全国8,000人調査で、AI活用方法によって生産性向上に約3.8倍の差が生まれることが判明。
権限は最小から始めて、足りなくなったら足す
仕様側も同じ考え方を採っています。最初は読み取りなど影響の小さい権限だけを渡し、権限が必要な操作に到達した時点で不足分を要求して引き上げる進め方が推奨されています（出典: modelcontextprotocol.io）。最初に全権限を渡すと、認証情報が漏れたときの影響範囲が広がり、どの操作のために許可したのかも後から分からなくなります。
運用に落とすと、接続の申請時に「この業務のためにこの権限が要る」を1行で書ける状態にしておくことです。書けない権限は、まだ渡す段階ではありません。
MCPでつなぐときの権限と記録の設計
つないだ後に効いてくるのが、誰が何をしたかを追える形になっているかです。事故が起きてから記録を探しても、残っていないものは出てきません。ここは既製サーバーを使う場合でも、自前で用意する場合でも、業務システム側の設定として決めておく必要があります。
認証情報は自分宛てに発行されたものだけを受け取る
仕様では、MCPサーバーは自分宛てに発行されていないアクセストークン（アクセスを許可するための鍵にあたるデータ）を受け取ってはならないと定められています（出典: modelcontextprotocol.io）。別のサービス向けに発行されたトークンをそのまま受け取って、後ろのシステムに転送する作り方は禁止されています。
この禁止には運用上の理由があります。トークンを検証せずに転送すると、つなぎ先のシステムのログには、実際に操作したMCPサーバーではなく別の主体からのリクエストとして記録が残ります。障害や情報漏洩の調査で、どの経路から入った操作なのかを追えなくなります。
関連記事：MCPの危険性とは？主なセキュリティリスクと安全に使うための対策
記録が残る単位で権限を分ける
AI用のアカウントを1つ作って全部の接続で共有すると、業務システム側のログに残る名前はすべて同じになります。どの用途の連携が更新したのかを後から分けられません。
用途ごと、あるいはチームごとにアカウントと権限を分けておくと、ログを見たときに経路が分かります。あわせて、業務システム側で「人が操作したもの」と「AI経由の操作」を区別できる印を残せないかも確認しておきます。区別が付けば、想定外の更新が起きたときの切り分けが早くなります。
状態を持たせるときに気をつけること
サーバーが発行した識別子を使って複数回のやり取りをつなぐ場合、その識別子を持っていること自体を本人確認の代わりにしてはならないとされています（出典: modelcontextprotocol.io）。識別子が推測されたり流出したりすると、他人の処理内容を参照・変更できてしまうためです。
実装するときは、識別子を推測しにくい値で発行したうえで、認証済みの利用者と紐づけて保持します。別の利用者が同じ識別子を出してきたら受け付けない、という判定を必ず挟みます。
連携を社内に広げるときにつまずく3つの場所
技術的につながっても、社内で使われ続けるかは別の問題です。最初の1業務が動いた後に止まる原因は、たいてい同じ場所にあります。
運用する人が決まっていない
つないだ後には、権限の見直し、接続先の追加、動かなくなったときの一次対応が発生し続けます。試したときの担当者が別の業務に戻ると、これらを引き受ける人がいなくなります。
実際、同じ調査で挙がった組織の課題は、仕組みと人の不在に集中していました。
| 組織の課題（複数回答） | 割合 |
|---|---|
| セキュリティ制限でツールが使えない | 19.6% |
| 利用ルール・ガイドラインがない | 19.1% |
| 業務に組み込む仕組み・専門人材がいない | 19.1% |
試す前に、続ける人と、権限を承認する人を決めておきます。決められないうちは、対象を止まっても困らない業務に限定しておくほうが安全です。
詳細な調査データは「ビジネス職生成AI活用実態調査（2026年版）」にてご覧ください。
仕様が変わる前提で置き場所を決める
MCPの仕様は更新が続いています。2026年7月28日版では、古い通信方式であるHTTP+SSEが廃止予定として分類され直しました（出典: modelcontextprotocol.io）。すぐ使えなくなるわけではありませんが、これから新しくつなぐときに選ぶ理由はありません。
同じ版で、Roots・Sampling・Loggingという3つの機能も廃止が予告されました。廃止までは最低12か月の猶予を置く方針が定められているため、いま作ったものが予告なく止まる心配は小さいものの、これから作るものでこれらを前提にするのは避けます。自前で用意する場合は、仕様の更新を追う担当を決めておきます。
既存の申請フローと噛み合わない
社内の権限申請は、多くの場合「誰がどのシステムに何の権限を持つか」を人単位で管理しています。AIが人の代わりに操作する形は、この管理の前提から外れます。
申請する側も承認する側も、何を審査すればよいのか分からないまま止まることがあります。最初の1件を通すときに、申請書に書く項目（接続先・渡すデータの範囲・読み取りか書き込みか・権限を持つ期間）を決めて型にしておくと、2件目以降が進みます。
MCPで業務システムをまたいでつないだ事例
AI Growth Lab編集部を運営するGiftXでも、社内のデータと外部サービスをまたぐ連携を運用しています。2件を紹介します。
社内のデータ基盤と外部ツールをまたいで商品ラインナップを設計する
競合ECの売れ筋、自社の注文傾向、検索ボリュームという別々の場所にあるデータを、AIが統合して次シーズンの仕入れ対象を推奨する運用です。自社の注文データはデータ基盤側に、検索ボリュームは外部サービス側にあり、両方をAIから参照できる形にしています。
バイヤーが競合を調査して注文データと突き合わせていた頃はシーズンのラインナップ設計に約2週間かかっていましたが、現在は約3日に短縮しました（リードタイム約78%短縮、2026年1月から継続運用）。
全国8,000人調査で、AI活用方法によって生産性向上に約3.8倍の差が生まれることが判明。
問い合わせ内容を顧客管理システムに書き戻す
問い合わせ管理ツールに残る会話ログをAIが要約し、顧客管理システムのレコードに追記する運用です。読み取りは問い合わせ側、書き込みは顧客管理側と、渡す権限を接続先ごとに分けています。
対応後に手入力していた頃は月60時間かかっていた入力が、現在は月5時間まで減りました（工数約92%削減、2026年2月から継続運用）。書き込みまで渡した例ですが、追記先の項目を限定することで影響範囲を抑えています。
AIエージェント導入で陥りがちな3つの落とし穴
連携の設計まで決まっても、進め方を間違えると動き出しません。よく見かける詰まり方を3つ挙げます。
落とし穴1｜いきなり全てをつなごうとする
使っているシステムを一度に洗い出して全部つなごうとすると、権限の設計だけで数か月かかります。範囲が広いほど承認も通りにくくなり、動くものが1つも出ないまま検討が長引きます。
落とし穴2｜壮大なAI戦略から考えて手が止まる
全社のデータ活用構想から入ると、着手する前に前提の議論が終わりません。構想が固まる頃には、前提にしていた仕様が変わっていることもあります。手を動かして分かることのほうが多い領域です。
落とし穴3｜既製のチャット型AIでは業務フローに組み込めない
汎用のチャット型AIをそのまま使う形では、社内の権限管理や承認の流れに合わせ込めません。人が結果をコピーして貼り直す運用が残り、工数が思ったほど減らない状態で止まります。業務フローに乗せるには、どの操作をどの権限で行うかを自社側で決められる形が要ります。
スモールスタートで1業務をAIエージェントに任せる
現実的なのは、止まっても困らない1業務を選び、読み取りだけの権限でつないでみることです。1件動けば、申請の型も運用する人も決まります。そこから対象と権限を足していけば、社内の合意も取りやすくなります。GiftXでは、こうしたスモールスタート前提のAIエージェント構築を1業務単位から伴走支援しています。詳細は AIエージェント構築支援サービス をご覧ください。
MCPで業務システムをつなぐときのよくある質問
実際に検討を始めた方から挙がりやすい質問をまとめました。
自社の基幹システムがMCPに対応していなくても使えますか
使えます。業務システム側がMCPに対応している必要はありません。そのシステムを操作するMCPサーバーを用意すれば、既存のシステムには手を入れずにつなげます。既存システムから見ると、通常のアプリケーションから接続されているのと変わりません。ただしサーバーを用意する作業は自分たちで行うことになります。
既製サーバーと自前実装は途中で切り替えられますか
切り替えられます。MCPは接続の規格を揃えるものなので、AI側から見た使い方は変わりません。まず既製サーバーで試し、権限の粒度が足りないと分かった時点で自前に移す進め方は現実の選択肢になります。切り替えの手間は、AI側の設定変更ではなくサーバーを作る側に集中します。
AIに書き込みまで許可しても大丈夫ですか
対象を絞れば運用できます。全項目の更新を許可するのではなく、追記先の項目を限定する、下書きの状態で作らせて確定は人が行う、といった形にすると影響範囲を抑えられます。最初から書き込みを許可する必要がなければ、読み取りだけで始めるほうが安全です。
仕様の更新が頻繁だと聞きますが、作ったものは使い続けられますか
機能の廃止には最低12か月の猶予期間を置く方針が定められています（出典: modelcontextprotocol.io）。予告なく止まる可能性は小さいものの、廃止が予告された機能を新しく作るものの前提にするのは避けます。自前で用意する場合は、更新の告知を追う担当を決めておくと対応が後手になりません。
何人くらいの体制で始められますか
最初の1業務であれば、業務を理解している担当者1名と、権限の承認ができる方がいれば動き出せます。自前でサーバーを用意する場合は、実装と仕様の追随を担当する方が別に必要になります。人数よりも、業務の中身を分かっている人が設計に加わっているかどうかが結果を分けます。
つないだ後に何を見ておけばよいですか
どの接続がどの権限を持っているかの一覧と、業務システム側の操作ログです。使わなくなった接続の権限が残り続けると、見直しのたびに調査対象が増えます。四半期に一度など、棚卸しの間隔を決めておくと管理しやすくなります。担当者が変わったときに引き継ぐ対象も、この一覧になります。
まとめ
MCPで業務システムをつなぐときは、公式サーバーがあるサービスか、自分でサーバーを用意する相手かで作業量が大きく変わります。つなぐ相手を決めたら、渡すデータを読み取りと書き込みに分けて線引きし、渡さないものを先に決めます。権限は最小から始め、認証情報は自分宛てのものだけを受け取り、用途ごとにアカウントを分けて記録が追える形にします。社内で続けるには、運用する人と申請の型を最初の1件で決めておくことが要ります。止まっても困らない1業務を読み取りだけでつなぐところから始めると、無理なく広げていけます。
AI活用の伴走支援をご検討の方へ
本記事で紹介したMCPを使った業務システムとの連携について、自社の業務でも具体的に進めたい・相談したいとお考えの方は、ぜひGiftX AIエージェント構築支援までお問い合わせください。
GiftX AIエージェント構築支援では、貴社の業務に合わせて1業務単位のスモールスタートから本番運用まで、AIエージェント構築をワンストップで支援します。つなぐ相手の選定から、権限設計、PoC、本番運用、社内ナレッジ化まで伴走します。
AI活用にご関心のある方は、ぜひ一度ご相談ください。
▶ GiftX AIエージェント構築支援の詳細・お問い合わせはこちら
