投稿者 投稿日: カテゴリー EC×AI活用
MCPコネクタとは、AIが外部システムのデータや機能を呼び出すための標準接続部品のことです。
コネクタを入れる前に決めておくことが1つあります。「どの業務を、どこまでAIに触らせるか」です。ここを飛ばして片っ端から接続すると、受注データの参照だけで済むはずの用途に更新権限まで渡してしまい、後から外せなくなります。MCP（Model Context Protocol）は2026年7月28日付の仕様改訂で認可の考え方が整理され、業務単位で権限を切る設計がやりやすくなりました。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援を2023年から提供する株式会社オルセル（うるチカラ運営）が、受注・在庫・広告・CSの4業務それぞれで何を基準にコネクタを選ぶかを整理します。
2026年7月の仕様改訂でMCPコネクタの選び方が変わった
先に結論を書くと、2026年7月28日の仕様でMCPは「ステートレスな中核」に組み替えられ、常時接続を前提としない普通のHTTPインフラの上で動くようになりました。これが実務にとって一番大きい変化です。
Model Context Protocol公式ブログによれば、この改訂はプロトコル公開以来で最大の版とされ、ステートレス化に加えてMCP Appsによるサーバー側レンダリングUI、長時間処理を扱うTasks拡張、そしてOAuthおよびOpenID Connectの実運用に近づけた認可の3点が中心です。以前はスティッキーセッションとセッションストアが必要だったリモートサーバーが、単純なラウンドロビンの負荷分散の後ろで動かせるようになった、という説明がされています。
EC事業者の目線に落とすと、意味は3つあります。第一に、社内に閉じたローカル接続だけでなく、リモートのMCPサーバーを本番運用に載せる前提が整ったこと。第二に、認可がOAuth 2.1に寄ったことで、「参照のみ」「特定ストアのみ」「特定期間のみ」といったスコープの切り分けが、コネクタ選定の比較軸として使えるようになったこと。第三に、Tasks拡張によって、数十分かかる商品データの一括変換のような処理をAIに任せる余地が出てきたことです。
コネクタの調達先も整理されつつあります。MCP Registryは2025年9月に公開され、数か月で約2,000件規模のサーバー登録に達したと報じられていますが、この件数は媒体によって差があるため要確認としておきます。件数そのものより実務的に重要なのは、npmのようなパッケージ索引の形で探せるようになった点です。以前のように接続先のパスを手で書いて回る運用ではなくなりました。
一方で、現場で繰り返し見るのは「registryに載っているから安全だろう」という判断ミスです。登録されていることは配布経路が整っていることを意味するだけで、そのコネクタが自社の受注データにどこまで触れるかを保証するものではありません。選定はあくまで業務単位で行う必要があります。ステートレス化の技術的な背景はMCPステートレス仕様への移行を解説した記事でも整理しています。
受注・在庫・広告・CSで、見るべき基準はまったく違う
業務ごとに優先すべき基準は異なります。共通の「良いコネクタ」という基準は存在しません。4業務それぞれで最初に確認すべき点を順に整理します。
受注業務では、書き込み権限の分離が最優先です。受注データはキャンセル・返品・配送先変更などの状態遷移を持つため、AIが誤って状態を進めると業務が止まります。選定時は、参照系ツールと更新系ツールが別のツール名で分かれているか、更新系だけを無効化できるかを最初に見ます。楽天RMSやAmazon Seller Central、Shopify Adminのいずれを接続する場合でも、初期導入は参照のみで運用し、3か月ほど誤検出の傾向を見てから更新系を開ける順序を推奨します。編集部で実際に運用しているプロンプトでも、受注系は読み取り専用の接続で回しています。
在庫業務では、更新の頻度と単位が判断軸になります。在庫は1日に何度も動くため、AIが読んだ時点の値と実際の値がずれる前提で設計しなければなりません。コネクタ側が差分取得（更新日時での絞り込み）に対応しているか、1回の呼び出しで何件まで返せるかを確認します。5,000SKUを超える店舗では、全件取得型のコネクタはトークン消費が跳ね上がるため現実的ではありません。ある食品ジャンルの中規模店舗の事例では、全件取得から更新日時絞り込みに変えただけで1回あたりの入力トークンが約8割減りました。
広告業務では、レポート取得の粒度と反映の遅延が効いてきます。楽天RPPやAmazonスポンサープロダクト、Google広告の各データは、管理画面に出る値と API 経由で取れる値の反映タイミングがずれることがあります。前日分が確定しているのか、当日分は速報値なのかをコネクタのドキュメントで確認し、AIに渡す前提を明示しておかないと、確定前の数字で入札判断をしてしまいます。入札の自動変更まで任せるかどうかは、少なくとも最初の四半期は保留が無難でしょう。
CS業務では、個人情報の扱いが選定を決めます。問い合わせ本文には氏名・住所・電話番号・注文番号が含まれるため、コネクタが取得する項目を絞れるか、マスキングをかけられるかが要件になります。項目単位で除外できないコネクタは、CS用途では見送る判断が現実的です。問い合わせ内容の分類や要約だけであれば、氏名と住所を渡す必要はありません。
Yahoo!ショッピングを併売している場合は、もう1段の注意が要ります。ストアクリエイターProから取得できる項目とAPIで取れる項目は完全には一致しないため、3モール横断で同じ集計をしようとすると、モールごとに欠けている項目が出ます。集計の粒度を先に決めてから、その粒度で3モール分が揃うかを確認する順序にしてください。粒度を後から変えると、プロンプトも取得ロジックも作り直しになります。
そしてもう1つ、業務をまたぐ横断的な基準があります。呼び出し回数の上限です。受注・在庫・広告・CSの4業務を同じ認証情報で回すと、どの業務が制限を食い潰したのかが追えません。業務ごとに認証情報を分けておけば、制限に当たった時点で原因業務が即座に特定できます。最初は面倒に感じますが、事故が起きてからログを掘る時間と比べれば圧倒的に安く済みます。
自社基幹システムに接続するときの追加論点
自社の受注管理や在庫管理をオンプレミスや閉域網に置いている場合、判断すべき点が1つ増えます。「その基幹に、外から届く経路を作るのか」という点です。
結論としては、基幹に直接届く経路を作るのではなく、参照用の中間層を1枚挟む構成が現実的です。基幹から必要な項目だけを日次または時間単位で切り出し、その中間層にMCPコネクタを向けます。基幹側の認証情報が外に出ず、渡す項目も切り出し時点で確定するため、権限の設計が単純になります。中間層はクラウド上の小さなデータベースで足り、大掛かりな基盤は必要ありません。
この構成の欠点は、データの鮮度が中間層の更新頻度に縛られる点です。在庫のようにリアルタイム性が求められる業務では成立しないため、その場合は基幹側に読み取り専用のAPIを用意する方向になります。直近の支援案件で観測したのは、在庫だけリアルタイム参照、それ以外は日次の中間層という使い分けで運用が落ち着くパターンでした。
なお、社内システムへの接続では、ネットワーク経路の設計そのものが論点になります。閉域に置いた基幹をどう安全につなぐかは、コネクタ選定とは別に検討が必要な領域です。ここを曖昧にしたまま接続を先に作ると、後からセキュリティ審査で差し戻されて全部やり直しになります。情報システム部門がある会社では、業務棚卸しの段階で一度相談を入れておくと手戻りが減ります。
導入手順とコネクタ選定を助けるプロンプト5本
導入は「棚卸し、権限設計、検証、本番、監査」の5段階で進めます。ここでは各段階で使えるプロンプトを5本、番号付きで示します。ChatGPT、Claude、Geminiのいずれでも動きます。
最初に行うのは、いまAIに接続する必要がある業務の棚卸しです。接続したい理由が「便利そうだから」に留まる業務は、この段階で落とします。
プロンプト1：AI接続候補の業務棚卸し
あなたは日本のEC事業者の業務設計に詳しいコンサルタントです。
以下の業務リストについて、AI（MCPコネクタ経由）に接続する優先度を判定してください。
判定基準：
1. 月間の作業時間（多いほど優先）
2. 判断のパターン化しやすさ（定型ほど優先）
3. 誤った場合の被害の大きさ（大きいほど後回し）
4. 参照のみで完結するか、更新が必要か（参照のみを優先）
業務リスト：
- {業務1}
- {業務2}
- {業務3}
出力：優先度A/B/C、判定理由を各2文、Aの業務については「参照のみ／更新も必要」の別を明記
次に権限の設計です。ここで決めた内容が、そのままコネクタの選定要件になります。
プロンプト2：業務別の権限スコープ設計
あなたはEC事業者のシステム権限設計を担当するエンジニアです。
以下の業務についてMCPコネクタに与える権限スコープを設計してください。
業務：{業務名}
接続先：{楽天RMS / Amazon Seller Central / Shopify Admin / 自社基幹}
AIにさせたいこと：{具体的な作業}
出力項目：
1. 必要な読み取り対象（データ種別・期間・件数上限）
2. 必要な書き込み対象（不要なら「不要」と明記）
3. 絶対に渡してはいけない項目（個人情報・決済情報など）
4. この設計で満たせない要件があれば指摘
候補コネクタが複数ある場合は、要件との突き合わせを機械的に行います。
プロンプト3：候補コネクタの要件突き合わせ
あなたは技術選定のレビュアーです。
以下の要件と、候補コネクタのドキュメント記載内容を突き合わせ、適合表を文章で示してください。
要件：
{プロンプト2の出力をここに貼る}
候補コネクタのドキュメント抜粋：
{候補A：ツール一覧・認証方式・レート制限}
{候補B：同上}
出力：候補ごとに「適合／条件付き適合／不適合」と、その判断根拠。
ドキュメントに記載がない項目は「記載なし・要問い合わせ」と明記し、推測で埋めないこと。
検証段階では、想定外の呼び出しが起きていないかを確認します。
プロンプト4：接続ログの異常検出
あなたはシステム運用の監査担当です。
以下のMCPツール呼び出しログを読み、想定外の呼び出しを抽出してください。
想定している呼び出し：
{許可した操作の一覧}
ログ：
{日時・ツール名・引数の要約・結果の成否}
出力：
1. 想定外の呼び出し（該当行と理由）
2. 想定内だが頻度が異常に高いもの
3. 次に絞るべき権限の提案
本番運用に入ったら、コネクタの棚卸しを定期的に回します。使っていない接続を放置しないための工程です。
プロンプト5：四半期ごとのコネクタ棚卸し
あなたはEC事業者の情報システム責任者です。
以下の接続一覧について、継続・縮小・停止を判定してください。
接続一覧（コネクタ名／接続先／権限／直近90日の呼び出し回数／担当業務）：
{一覧を貼る}
判定基準：
- 呼び出し回数が0のものは停止候補
- 更新権限を持つが更新実績が0のものは参照のみへ縮小
- 個人情報を扱うものは項目の再確認
出力：継続／縮小／停止の別と、それぞれの理由を各1〜2文
この5本は、そのまま社内の稟議資料の下書きにも使えます。特にプロンプト2と3の出力は、外部ベンダーへの要件提示にそのまま転記できる形にしてあります。
よくある失敗と、その回避策
現場で見る失敗は3つに集約されます。順に挙げます。
1つ目は、更新権限を最初から開けてしまうケースです。動作確認の段階で「試しに全部つないでみる」と、そのまま本番運用に流れます。回避策は単純で、初期接続は参照のみに固定し、更新を開ける判断は別の稟議として扱うことです。楽天とAmazonの両方を回している店舗で観測されたのは、参照のみでも業務時間の削減効果の7割程度は得られるという傾向でした。この数字は店舗規模で振れるため目安として扱ってください。
2つ目は、レート制限の設計漏れです。AIは人間より高速に呼び出すため、商品一覧の取得を繰り返すだけで接続先のAPI制限に当たります。制限に当たると通常業務のバッチまで止まるため、影響範囲が読めなくなります。回避策は、AI経由の呼び出しに専用の認証情報を発行し、通常バッチと枠を分けることです。
3つ目は、コネクタの更新に追随しないケースです。MCPの仕様自体が2026年に大きく変わった通り、コネクタ側も破壊的な変更を入れます。四半期に1回、プロンプト5の棚卸しと合わせて、使用中コネクタの更新履歴を確認する運用を組んでおくのが定石です。複数モデルを併用している場合の設計はマルチモデルルーティングの設計記事も参考になります。
補足として、失敗ではないものの効果が出ないパターンにも触れておきます。接続はしたが、AIに渡す指示が曖昧なままというケースです。「在庫を確認して」とだけ書いて投げると、AIは全件を取りにいきます。「本日出荷予定の注文に含まれるSKUに限って、在庫数が3以下のものを列挙して」まで書けば、呼び出しは1回で済みます。コネクタの性能ではなく、指示の精度で結果が変わる領域が想像以上に広い、というのが5,000社支援の中で何度も再現したパターンです。
もう1つ、権限を絞りすぎて業務が回らなくなるパターンもあります。安全側に倒すこと自体は正しいのですが、必要な参照まで塞ぐと、AIが「取得できませんでした」を返し続けて誰も使わなくなります。参照は業務に必要な範囲まで開け、更新だけを厳格に管理する、という非対称な設計が実務では機能します。
費用と工数の目安、そして測るべきKPI
費用は、モデル利用料とコネクタ運用の2階建てで見ます。モデル側はChatGPT Plusが月20米ドル、Claude Proが月20米ドル、Gemini の有料プランが同程度の水準です。API経由で運用する場合は使用量課金になるため、月額が読みにくくなります。
コネクタ側は、既存のSaaSが公式に提供しているものであれば追加費用がかからないことが多く、自社基幹への接続を新規開発する場合に工数が発生します。参照のみの単純な接続であれば、社内にエンジニアがいる前提で2〜4人日が目安です。要件定義から外部委託する場合は、この数倍を見込む必要があります。いずれも2026年8月時点の相場感で、案件の複雑さで大きく振れます。
測るKPIは3つに絞るのが実務的です。第一に、対象業務の月間作業時間。導入前後で比較できるよう、導入前に1か月分は記録しておきます。第二に、AI経由の呼び出しのうち、人間が修正した割合。ここが下がらなければ工数は減りません。第三に、想定外の呼び出し件数。ゼロが理想で、増えていれば権限設計を見直します。
投資回収の考え方は単純です。削減できた作業時間に時給換算をかけ、モデル利用料と初期開発費の合計と比較します。月20時間の削減で時給2,000円換算なら月4万円の効果となり、初期開発費30万円なら回収に約8か月かかる計算です。この試算は前提の置き方で変わるため、自社の数字で置き換えてください。
見落とされやすいのが、削減した時間の使い道を決めていないケースです。作業時間が月20時間減っても、その20時間が空き時間として消えるだけなら、損益計算書には何も表れません。導入の稟議を通す段階で、浮いた時間を何に充てるか、例えば商品ページの改善本数を月何本増やすか、といった振替先まで書いておくと、効果測定が具体になります。ここを詰めていない導入は、半年後に「便利にはなったが数字が動いていない」という評価に落ち着きがちです。
もう1点、隠れコストとして計上しておくべきなのが監査の工数です。四半期ごとの棚卸しに半日、権限変更の稟議に都度1〜2時間、というのが実感値です。年間で見れば数人日規模になるため、初期開発費と並べて予算に入れておくと後から揉めません。
この先1年でコネクタ選定はどう変わるか
見立てとして、選定の軸は「機能の多さ」から「権限をどこまで細かく切れるか」へ移ると考えています。理由は、2026年7月の仕様改訂で認可がOAuthとOpenID Connectの実運用に寄ったことで、細かいスコープ設計が技術的に難しくなくなったためです。
そうなると、ツールを大量に持つ万能型のコネクタよりも、業務ごとに切られた小さなコネクタを複数組み合わせる構成が有利になります。受注参照用、在庫更新用、広告レポート用を別々に持ち、それぞれに別の認証情報を割り当てる形です。監査もしやすく、事故が起きたときの切り離しも容易になります。
もう1つの変化は、Tasks拡張による長時間処理の扱いです。商品説明文の一括生成や画像のタグ付けのような、数十分から数時間かかる処理を非同期で投げられるようになると、日次バッチの一部をAI側に寄せる設計が現実味を帯びます。ただしこれは仕様が固まった段階の話であり、2026年8月時点で本番運用に載せている国内EC事業者の事例は確認できていません。ここは要確認としておきます。
競合メディアの解説はプロトコルの仕様説明に寄りがちですが、EC事業者が実際に困るのは「どの業務から、どの権限で始めるか」です。仕様を読み込む前に、業務の棚卸しと権限設計を先に済ませておくと、コネクタ選定にかかる時間は大きく縮みます。
よくある質問
MCPコネクタとは何ですか
MCPコネクタとは、AIが外部システムのデータや機能を呼び出すための標準接続部品のことです。従来は各サービスごとに個別の連携を作る必要がありましたが、MCPという共通仕様に沿って作られたコネクタであれば、対応するAIツールから同じ手順で呼び出せます。
楽天RMSやAmazon Seller Centralに公式のMCPコネクタはありますか
2026年8月時点で、各モールの公式提供状況は個別に確認が必要です。公式提供がない場合はAPI経由の自社実装か、第三者製コネクタの利用になりますが、第三者製は認証情報の預け先が増えるため、扱うデータの範囲を必ず確認してください。
最初はどの業務から接続すべきですか
参照のみで完結し、かつ月間作業時間が長い業務から始めるのが定石です。具体的には、広告レポートの集計、レビューの傾向把握、問い合わせ内容の分類などが該当します。受注の更新や在庫の書き込みは、参照系での運用が安定してから検討してください。
個人情報を扱う業務でMCPコネクタを使えますか
使えますが、取得項目を絞れるコネクタに限ります。氏名・住所・電話番号・決済情報を渡す必要があるかを業務単位で棚卸しし、不要な項目は取得対象から外してください。項目単位の制御ができないコネクタは、個人情報を扱う業務では見送る判断が安全です。
コネクタは多く入れたほうが便利ですか
いいえ、業務に必要な最小限に絞るべきです。接続が増えるほど権限の管理と監査が難しくなり、使われていない接続が事故の入口になります。四半期ごとに呼び出し回数を確認し、実績のない接続は停止する運用を組んでください。
導入にエンジニアは必須ですか
公式提供のコネクタを参照のみで使う範囲であれば、設定作業だけで済むケースがあります。自社基幹システムへの接続や、権限スコープの細かい設計が必要になる段階では、エンジニアまたは外部の技術パートナーが必要です。
費用はどれくらいかかりますか
モデル利用料は主要サービスで月20米ドル前後、自社基幹への参照接続を新規開発する場合は社内エンジニアで2〜4人日が目安です。API従量課金で運用する場合は使用量次第で変動するため、最初の1か月は上限を設定して様子を見ることを推奨します。
まとめ
MCPコネクタの選定は、コネクタの機能比較から始めるとほぼ失敗します。先に業務を棚卸しし、業務ごとに必要な権限を書き出し、その要件を満たすコネクタを探す順序が正解です。2026年7月の仕様改訂で認可の設計がやりやすくなったぶん、この順序で進める価値は以前より上がっています。まずは参照のみで完結する業務を1つ選び、本記事のプロンプト1と2を回して要件を紙に落とすところから始めてください。
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
参考文献
- Model Context Protocol Blog｜The 2026-07-28 Specification
- Model Context Protocol Blog｜The 2026-07-28 MCP Specification Release Candidate
- Model Context Protocol｜Authorization 仕様
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
