投稿者 投稿日: カテゴリー EC×AI活用
MCP Apps とは、AIとの会話の中に自社の業務画面を差し込む拡張仕様のことです。
2026年7月28日に確定した最新のMCP仕様では、サーバー側がHTMLの操作画面を提供し、AIクライアントがそれをサンドボックス化されたiframeの中で表示できます。「在庫を10個に直して」と会話で指示するのではなく、会話の中に在庫数の入力欄が現れる。この違いが、EC業務のどこで効くのかを整理します。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづきます。
会話にUIを差し込めると何が変わるのか
変わるのは、確認と実行の距離です。従来のMCP（AIと外部システムをつなぐ共通規格）では、AIが在庫を書き換える場合、「在庫を10に更新しますか」というテキストの確認が出て、利用者が「はい」と答える形でした。文字だけのやり取りなので、対象商品が本当に意図したものか、他に影響が出ないかを目視で確かめる手段がありません。
MCP Appsでは、サーバー側があらかじめ用意したHTMLの画面が会話の中に表示されます。商品名と現在の在庫数が並び、入力欄に新しい数値を入れて実行する。誤操作の余地が小さくなり、確認の質が上がります。Model Context Protocolの公式ブログによると、この拡張はSEP-1865として提案され、ツールがUIテンプレートを事前に宣言する仕組みになっています。
事前宣言という設計が重要です。ホスト側（AIクライアント）は、実行前にテンプレートを取得してキャッシュし、セキュリティ上の審査を行えます。実行時に初めてHTMLが送られてくる仕組みだと、審査のしようがありません。宣言を先に済ませておくことで、レビューを通した画面だけが表示される構造が作れます。
セキュリティの層も確認しておきます。表示はサンドボックス化されたiframeの中で行われ、権限は制限されます。この中で動くUIは親ページにアクセスできず、Cookieを盗むこともできず、コンテナから抜け出すこともできません。UIからホストへの通信は、MCP全体で使われているJSON-RPCという同じ通信規格を経由するため、直接のツール呼び出しと同じ監査と同意の経路を通ります。第三者が作ったサーバーの画面を、そのサーバーの作者を全面的に信頼しなくても表示できる、という設計思想です。
仕様の確定日も押さえておきます。2026-07-28版の仕様は7月28日に最終版として公開されました。5月21日から始まった10週間のリリース候補期間を経ての確定です。同じ版ではステートレス化という大きな変更も入っており、EC事業者にとっては在庫・受注連携の作り方に影響します。この点はMCPステートレス化と連携の移行チェックリストに別途まとめました。
EC業務のどこをUI化し、どこを人の画面に残すか
判断基準は「取り返しがつくかどうか」です。会話の中で完結させてよいのは、間違えても元に戻せる操作に限られます。
UI化する価値が高いのは、受注確認、在庫の数値調整、クーポンの発行、商品の公開・非公開切り替えといった、頻度が高く、状態が一目で分かり、失敗しても復旧できる操作です。楽天RMSやSeller Centralの管理画面を開いて該当商品を探し、数値を直して保存する。この一連の動作は、1回2〜3分でも、日に何度も発生すると無視できない時間になります。会話の中で完結すれば、画面を切り替える手間が消えます。
逆に、人の画面に残すべき操作もあります。価格の変更、商品の削除、一括更新、返金処理。これらは影響範囲が広く、間違えたときの復旧コストが高い操作です。会話の流れで実行できてしまうことのリスクのほうが、時間短縮の利益を上回ります。ここは意図的に「面倒なまま」にしておくのが安全な設計です。
もう一つ、中間に置くべき領域があります。複数商品にまたがる操作です。1商品の在庫調整はUI化してよいが、10商品を一度に変えるならCSVでの一括処理に回す。UIで扱う件数の上限を決めておくと、設計が明確になります。実務では、1画面で扱うのは5件までという線引きが運用しやすい水準です。
具体的な業務で考えてみます。食品ギフト系の店舗で、繁忙期に頻発するのが「在庫の残数を細かく刻む」作業です。予約が入るたびに実在庫と販売可能数の差を調整する。楽天RMSの商品編集画面を開き、該当商品を検索し、在庫数を直して保存する。1回3分の作業が日に15回発生すれば、45分が消えます。この操作はUI化の典型例です。単一商品、数値ひとつ、間違えても戻せる、頻度が高い。4条件がすべて揃っています。
一方、同じ繁忙期に発生する「配送遅延の告知文を全商品ページに追記する」作業は、UI化に向きません。複数商品にまたがり、文章の内容を都度判断する必要があり、間違えた文言が公開されると顧客対応が発生します。会話の中で文案を作らせるところまではAIに任せ、実際の反映は管理画面かCSVで行う。この分業が現実的です。AIに任せる範囲を「文案作成まで」と決めておくと、判断がぶれません。
プロンプト1：UI化する業務の仕分け
あなたはEC事業者の業務システム設計を支援するコンサルタントです。
以下は当社の日常的なEC運用業務の一覧です。
それぞれを「会話UIで完結してよい／人が管理画面で行う／CSV一括処理に回す」の3区分に分類してください。
分類の基準：
1. 誤操作したときに元に戻せるか
2. 影響範囲が単一商品か複数商品か
3. 1日あたりの発生頻度
4. 金銭の授受に直接関わるか
各業務について、区分・理由・1日あたりの想定発生回数を出してください。
判断に情報が足りない業務は「要確認」とし、必要な情報を挙げてください。
業務一覧：{貼り付け}
画面を設計するときの3原則
第1に、1画面1目的にします。在庫の画面に価格の入力欄を置かない。会話の中に表示される領域は限られており、複数の目的を詰め込むと誤操作が増えます。楽天RMSの商品編集画面のように多くの項目が並ぶ形は、会話の中には向きません。
第2に、現在値を必ず表示します。「在庫数」という入力欄だけを出すのではなく、「現在の在庫数：8」と併記したうえで新しい値を入れさせる。何を何に変えるのかが1画面で完結していないと、確認の意味がなくなります。商品名と商品管理番号も併記してください。似た名前の商品を取り違える事故は、この2つを出しておけば大半が防げます。
第3に、実行後の結果を返します。更新が成功したのか、失敗したのか、失敗ならなぜかを画面に戻す。会話が次の話題に進んでしまい、更新できていたのか分からないまま放置される。この状態が一番危険です。
プロンプト2：業務UIの画面仕様書作成
以下の業務について、MCP Appsで表示する画面の仕様書を作成してください。
含めるべき項目：
1. 画面の目的（1文で）
2. 表示する読み取り専用の情報（現在値・識別子）
3. 利用者が入力・選択する項目と、その入力制限
4. 実行ボタンの文言（何が起きるかが分かる表現にする）
5. 実行後に表示する結果メッセージ（成功時・失敗時それぞれ）
6. この画面で扱わないと決めた操作と、その理由
条件：
- 1画面1目的を守る
- 入力項目は5つ以内に収める
- 金額の変更を伴う項目を含めない
業務内容：{在庫調整／受注確認／クーポン発行 などを指定}
現在の管理画面での操作手順：{貼り付け}
導入で詰まる3つのポイント
最も多いのが、クライアント側の対応状況を確認せずに作り始めるケースです。MCP Appsは拡張仕様なので、すべてのAIクライアントが対応しているとは限りません。自社が使う予定のクライアントが対応しているか、対応バージョンはいくつからかを、MCP Appsの公式ドキュメントと各クライアントのリリースノートで先に確認してください。ここを飛ばすと、作った画面が表示されないという結果になります。
次が、権限設計の甘さです。会話の中から在庫を直せるということは、その会話に参加できる人が在庫を直せるという意味です。アルバイトスタッフが使う環境と、店長が使う環境で、接続するMCPサーバーを分ける。この分離をサーバー側で行わず、「使う人が気をつける」運用にしてしまうと、いずれ事故が起きます。読み取り専用のサーバーと、書き込みができるサーバーを分けて用意するのが基本形です。
3つ目は、モール側の規約との整合です。楽天RMSやAmazon Seller Centralの操作を外部から自動化することの扱いは、各モールの規約や利用条件に依存します。公式APIが提供されている範囲での連携か、画面操作の自動化かで、扱いは変わります。実装前に各モールの規約と、利用可能なAPIの範囲を確認してください。ここは自己判断で進めず、不明な点はモールの窓口に照会するのが確実です。
プロンプト3：MCP連携の権限設計レビュー
以下は当社が構築予定のMCPサーバーの機能一覧です。
権限設計の観点でレビューしてください。
レビューの観点：
1. 読み取り専用の機能と、書き込みを伴う機能の分離ができているか
2. 書き込み機能のうち、金銭・在庫・公開状態に影響するものはどれか
3. 利用者の役割（店長／運用担当／アルバイト）ごとに、許可すべき機能の範囲
4. 誤操作時に復旧できない操作が含まれていないか
出力：
- 役割ごとの機能許可表（文章で説明）
- サーバーを分割すべき単位の提案
- 実装前に社内で決めておくべき事項の一覧
機能一覧：{貼り付け}
工数と費用の目安
自社で開発する場合の工数を置いておきます。既存の基幹システムやモールAPIとの接続がすでにある前提で、画面1つあたりの実装は2〜5営業日というのが目安です。仕様書の作成に半日、実装に1〜3日、テストと権限まわりの確認に1日という内訳になります。接続部分から作る場合は、そちらのほうが工数として大きくなります。
費用対効果は、削減される画面切り替えの回数で測ります。在庫調整が1日20回発生し、1回あたり管理画面を開いて操作するのに2分半かかっているなら、日に50分。月20営業日で約17時間です。会話の中で30秒で終わるなら、月に10時間以上が浮く計算になります。時給換算で1,500円なら月1万5,000円相当。画面1つの開発費を回収するには数か月かかる規模感です。
この試算から分かるのは、頻度の低い業務をUI化しても割に合わないということです。日に数回しか発生しない操作は、管理画面を開いたほうが早い。UI化の対象は、頻度で絞り込んでください。現場で繰り返し見るのは、「作れるから作る」で画面が増え、どれも使われないまま保守だけが残るパターンです。
外注する場合の費用は、開発会社や要件によって幅が大きいため、複数社から見積もりを取ることをおすすめします。相場を断定できるだけの情報がないため、ここは要確認としておきます。
段階的に進める場合の順序も置いておきます。最初に作るべきは、書き込みを伴わない読み取り専用の画面です。受注一覧の表示、在庫の確認、売れ筋の抽出。これらは間違えても被害が出ないため、社内で運用に慣れるための入り口として適しています。ここで「会話の中に画面が出る」という体験を数週間試したうえで、書き込み機能に進む。いきなり在庫を書き換える画面から作ると、心理的な抵抗で使われないまま終わることがあります。
導入後の効果測定は、操作回数と誤操作件数の2つで見ます。操作回数はUI経由での実行ログから取れます。誤操作件数は、更新後に取り消し・再修正が発生した回数を数えます。管理画面での作業に比べて誤操作が減っていれば、UIの設計が機能している証拠です。増えていれば、現在値の表示不足か、確認ステップの省略が原因である場合が大半なので、Managed Agentsなどのエージェント実行制御の考え方も参考にしながら、実行前に止める仕組みを見直してください。
業務システムとAIの境界がどう動くか
MCP Appsが示しているのは、AIが業務システムを「操作する」のではなく、業務システムがAIの中に「入ってくる」という方向です。この違いは大きいと考えています。
AIに管理画面を操作させる方式は、画面のレイアウトが変わるたびに壊れます。モール側が管理画面を刷新すれば、自動化は止まります。一方、サーバー側がUIを提供する方式なら、提供する側が仕様を管理しているため、壊れる箇所が限定されます。長期的な保守性では後者が有利です。
EC事業者にとっての含意は、自社の業務データをどう外に出せる形にしておくかという点に集約されます。在庫、受注、商品マスタ。これらがAPIで取り出せる状態になっていれば、AIクライアントが何に変わっても対応できます。逆に、基幹システムがCSVの手動出力しか対応していない状態では、この流れに乗れません。MCP Appsそのものより、その手前のデータ整備のほうが投資として優先度が高い、というのが現時点の判断です。
もう一点、AIエージェントが購買を代行する動きとの関係も見ておく価値があります。外向き（消費者のAIに商品を見つけてもらう）と内向き（社内業務をAIから操作する）は、どちらもデータの構造化という同じ土台に乗ります。片方の整備がもう片方に効くため、投資の順番を考えるうえでは合わせて見るのが合理的です。外向きの論点はAIショッピングでの商品露出を調べる手順にまとめてあります。
よくある質問
MCP Appsとは何ですか
MCP Appsとは、MCPサーバーがHTMLの操作画面を提供し、AIクライアントがサンドボックス化されたiframeで表示できるようにする拡張仕様のことです。SEP-1865として提案され、ツールがUIテンプレートを事前に宣言する仕組みになっています。
セキュリティは大丈夫ですか
サンドボックス化されたiframe内で権限を制限して動作するため、親ページへのアクセスやCookieの窃取、コンテナからの脱出はできません。UIからの操作はJSON-RPC経由で、直接のツール呼び出しと同じ監査と同意の経路を通ります。ただし、自社サーバー側の権限設計は別途必要です。
すべてのAIクライアントで使えますか
いいえ、拡張仕様のため対応状況はクライアントによって異なります。開発に着手する前に、利用予定のクライアントが対応しているか、対応バージョンを公式ドキュメントとリリースノートで確認してください。
楽天やAmazonの操作を自動化してよいですか
各モールの規約と提供APIの範囲によります。公式APIの範囲内での連携か、画面操作の自動化かで扱いが変わるため、実装前に規約を確認し、不明点はモールの窓口へ照会してください。自己判断で進めるべき領域ではありません。
開発にどれくらいかかりますか
既存システムとの接続がある前提で、画面1つあたり2〜5営業日が目安です。接続部分から構築する場合は、そちらの工数が主になります。要件によって変動するため、あくまで目安として扱ってください。
小規模な店舗でも導入する意味はありますか
業務の発生頻度によります。1日20回以上発生する操作があるなら検討する価値がありますが、数回程度なら管理画面を使ったほうが早いのが実情です。まず自社の操作頻度を1週間記録してから判断してください。
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
参考文献
- Model Context Protocol｜MCP Apps – Bringing UI Capabilities To MCP Clients
- Model Context Protocol｜MCP Apps 概要
- Model Context Protocol｜The 2026-07-28 MCP Specification Release Candidate
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
