MCP統合パターン
このガイドでは、本番Shopifyワークフローでの MCPサーバーの高度な使用パターンをカバーします。シングルサーバーのセットアップから、複雑なマルチサーバーオーケストレーション、CI/CD統合、自動データパイプラインまで。
パターン1:シングルサーバー構成
最もシンプルなパターンです。1つのMCPサーバーがすべてのインタラクションを処理します。
┌──────────┐ ┌───────────────┐ ┌─────────────┐
│ AIクライアント│ ──MCP──► │ shopify-mcp │ ──API──► │ Shopifyストア │
│ │ │ (GeLi2001) │ │ │
└──────────┘ └───────────────┘ └─────────────┘
使用する場面:
- 単一ストアの管理
- MCPの導入時
- シンプルな自動化タスク
設定:
{
"mcpServers": {
"shopify": {
"command": "npx",
"args": ["-y", "shopify-mcp@latest"],
"env": {
"SHOPIFY_ACCESS_TOKEN": "shpat_xxxxxxxxxxxxx",
"MYSHOPIFY_DOMAIN": "my-store.myshopify.com"
}
}
}
}
制限事項:
- ドキュメントへのアクセスなし(ライブストアデータのみ)
- APIスキーマに対するバリデーション不可
- 単一障害点
パターン2:デュアルサーバー(ドキュメント + ストア)
ほとんどの開発者に推奨されるパターンです。ドキュメントインテリジェンスとストア管理を組み合わせます。
┌──────────┐ ┌───────────────────┐
│ │────►│ Shopify Dev MCP │──► ドキュメント、スキーマ、Liquid
│ AIクライアント│ └───────────────────┘
│ │ ┌───────────────────┐
│ │────►│ Shopify Store MCP │──► 商品、注文など
└──────────┘ └───────────────────┘
使用する場面:
- 日常のShopify開発
- ストアを管理しながらのアプリ開発
- Shopifyプラットフォームの学習
設定:
{
"mcpServers": {
"shopify-dev": {
"command": "npx",
"args": ["-y", "@anthropic-ai/shopify-dev-mcp@latest"]
},
"shopify-store": {
"command": "npx",
"args": ["-y", "shopify-mcp@latest"],
"env": {
"SHOPIFY_ACCESS_TOKEN": "shpat_xxxxxxxxxxxxx",
"MYSHOPIFY_DOMAIN": "my-store.myshopify.com"
}
}
}
}
ワークフロー例:
プロンプト:「'Apparel'コレクションのすべての商品に'care_instructions'メタフィールドを
追加する必要があります。まず、正しいメタフィールドの型とミューテーションを
ドキュメントで検索してください。次にストアで実行してください。」
1. AIがDev MCPを使用 → search_docs("metafield definitions product")
2. AIがDev MCPを使用 → explore_api_schema("MetafieldDefinitionInput")
3. AIがStore MCPを使用 → get_collections(type: "custom", title: "Apparel")
4. AIがStore MCPを使用 → get_products(collection_id: "gid://...")
5. AIがStore MCPを使用 → manage_product_metafields(product_id: "...", ...)
パターン3:マルチストア管理
単一のAIセッションから複数のShopifyストアを管理します。代理店、フランチャイズ、地域別ストアを持つマーチャントに有用です。
┌──────────┐ ┌─────────────────────┐
│ │────►│ ストア:US本番 │──► us-store.myshopify.com
│ │ └─────────────────────┘
│ AIクライアント│ ┌─────────────────────┐
│ │────►│ ストア:EU本番 │──► eu-store.myshopify.com
│ │ └─────────────────────┘
│ │ ┌─────────────────────┐
│ │────►│ ストア:ステージング │──► staging.myshopify.com
└──────────┘ └─────────────────────┘
設定:
{
"mcpServers": {
"shopify-dev": {
"command": "npx",
"args": ["-y", "@anthropic-ai/shopify-dev-mcp@latest"]
},
"store-us": {
"command": "npx",
"args": ["-y", "shopify-mcp@latest"],
"env": {
"SHOPIFY_ACCESS_TOKEN": "shpat_us_token",
"MYSHOPIFY_DOMAIN": "us-store.myshopify.com"
}
},
"store-eu": {
"command": "npx",
"args": ["-y", "shopify-mcp@latest"],
"env": {
"SHOPIFY_ACCESS_TOKEN": "shpat_eu_token",
"MYSHOPIFY_DOMAIN": "eu-store.myshopify.com"
}
},
"store-staging": {
"command": "npx",
"args": ["-y", "shopify-mcp@latest"],
"env": {
"SHOPIFY_ACCESS_TOKEN": "shpat_staging_token",
"MYSHOPIFY_DOMAIN": "staging-store.myshopify.com"
}
}
}
}
ワークフロー例:
プロンプト:「USストアからEUストアに商品カタログを同期してください。
各商品について、価格をUSDからEURに1.08のレートで変換し、
説明をEU配送情報を含むよう更新してください。」
1. AIがstore-usを使用 → get_products(limit: 250)
2. 各商品について:
a. AIが価格を * 1.08で変換
b. AIがstore-euを使用 → create_product(...)またはupdate_product(...)
クロスストアの同期は必ずステージング環境で先にテストしてください。商品IDはストア間で異なるため、GIDではなくSKU、ハンドル、その他の一意識別子で照合する必要があります。
パターン4:Composioツールルーター
Composioは、単一のMCP接続を通じて複数のサービスにツール呼び出しをルーティングするミドルウェアレイヤーとして機能します。
┌──────────┐ ┌──────────────┐ ┌──────────────┐
│ │ │ │────►│ Shopify Admin │
│ │ │ │ └──────────────┘
│ AIクライアント│────►│ Composio │ ┌──────────────┐
│ │ │ ツールルーター│────►│ Google Sheets │
│ │ │ │ └──────────────┘
└──────────┘ │ │ ┌──────────────┐
│ │────►│ Slack │
└──────────────┘ └──────────────┘
使用する場面:
- 複数サービスにまたがるワークフロー
- 生のトークンの代わりにOAuthを使用したい場合
- 監査要件のあるエンタープライズ環境
セットアップ:
# Composioをインストール
pip install composio-core
# インテグレーションを追加
composio add shopify
composio add google-sheets
composio add slack
# オプション:必要なツールのみにフィルター
composio actions --app shopify --filter "product,order"
設定:
{
"mcpServers": {
"composio": {
"command": "composio",
"args": ["serve", "--apps", "shopify,google-sheets,slack"]
}
}
}
ワークフロー例:
プロンプト:「毎朝、Shopifyから昨日の注文を取得し、
Google Sheetsにまとめ、Slackの#salesチャンネルにサマリーを投稿してください。」
1. AIがComposioを使用 → shopify.get_orders(created_at_min: yesterday)
2. AIがComposioを使用 → google_sheets.append_rows(spreadsheet_id, data)
3. AIがComposioを使用 → slack.post_message(channel: "#sales", text: summary)
パターン5:CI/CDとMCP
デプロイ時の自動ストア管理のために、MCPサーバーをCI/CDパイプラインに統合します。
┌──────────┐ ┌──────────┐ ┌──────────────┐ ┌─────────┐
│ Git Push │────►│ CI/CD │────►│ Claude Code │────►│ Shopify │
│ │ │パイプライン│ │ + MCPサーバー │ │ ストア │
└──────────┘ └──────────┘ └──────────────┘ └─────────┘
GitHub Actionsの例
name: Shopify Store Sync
on:
push:
branches: [main]
paths:
- 'products/**'
- 'collections/**'
jobs:
sync-store:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install Claude Code
run: npm install -g @anthropic-ai/claude-code
- name: Configure MCP Servers
run: |
claude mcp add shopify-store \
-e SHOPIFY_ACCESS_TOKEN=${{ secrets.SHOPIFY_ACCESS_TOKEN }} \
-e MYSHOPIFY_DOMAIN=${{ secrets.SHOP_DOMAIN }} \
-- npx -y shopify-mcp@latest
- name: Sync Products
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
run: |
claude -p "Read the product definitions in ./products/
and sync them to the Shopify store. Create new products
that don't exist, update existing ones by SKU match."
CI/CD + MCPのユースケース
| トリガー | アクション | 例 |
|---|---|---|
mainへのプッシュ | 商品カタログの同期 | Gitのソースオブトゥルースとしての商品データ |
| 新しいリリースタグ | ストアテーマメタフィールドの更新 | ストアに表示されるバージョン情報 |
| スケジュールされたcron | 在庫レベルの監査 | 日次の在庫不足アラート |
| PRのマージ | コレクションルールの更新 | コードによるコレクション定義 |
| ERPからのWebhook | 在庫変更の同期 | 外部システム統合 |
自動パイプラインはShopifyのレート制限にすぐ到達する可能性があります。以下を実装してください:
- 429レスポンスに対するエクスポネンシャルバックオフ
- 可能な限りバッチ操作
- パイプラインログでのレート制限モニタリング
パターン6:自動ストア管理
スケジュールされたタスクでMCPサーバーを使用し、手間のかからないストア運用を実現します。
日次商品監査
スケジュール:毎日 6:00 AM UTC
プロンプト:「商品カタログの監査を実行してください:
1. 説明のないすべての商品を見つける
2. 画像のないすべての商品を見つける
3. すべてのロケーションで在庫ゼロのすべての商品を見つける
4. 30日以上前のすべてのドラフト商品を見つける
5. 推奨事項を含むサマリーレポートを生成」
週次価格最適化
スケジュール:毎週月曜日 8:00 AM UTC
プロンプト:「過去7日間の注文を分析してください:
1. ベストセラー上位20商品を特定
2. 販売消化率が90%を超える商品には、10%の価格引き上げを提案
3. 販売消化率が10%未満で在庫60日以上の商品には、15%のディスカウントを提案
4. 推奨事項を提示 -- 変更を自動適用しないでください」
在庫発注アラート
スケジュール:4時間ごと
プロンプト:「すべてのロケーションの在庫レベルを確認してください:
1. 再発注点(メタフィールド'custom.reorder_point'に保存)を下回るバリアントを見つける
2. 推奨発注数量を計算
3. ベンダー別にグループ化した発注リストを生成」
パターン7:データパイプラインアーキテクチャ
Shopifyデータを変換と分析のステージを通じてフローさせるデータパイプラインを構築します。
┌──────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────┐
│ Shopify │ │ 抽出 │ │ 変換 │ │ ロード │
│ Store MCP │────►│ (get_orders, │────►│ (AI駆動の │────►│ (Sheets, │
│ │ │ get_products)│ │ 分析) │ │ DB, CSV)│
└──────────┘ └──────────────┘ └──────────────┘ └──────────┘
抽出:Shopifyからデータを取得
プロンプト:「過去30日間のすべての注文を、ラインアイテム、
顧客データ、フルフィルメントステータスとともに抽出してください。
以下の計算フィールドを含めてください:
- 注文金額
- アイテム数
- 注文からの経過日数
- フルフィルメント遅延(注文から最初のフルフィルメントまでの日数)」
変換:AI駆動の分析
プロンプト:「抽出した注文を分析してください:
1. 顧客コホート分析(新規 vs リピーター)
2. 商品アフィニティ分析(よく一緒に購入されるもの)
3. 注文の地理的分布
4. 週別の平均注文金額トレンド
5. ロケーション別のフルフィルメントパフォーマンス」
ロード:結果の出力
プロンプト:「分析結果を以下の形式でフォーマットしてください:
1. データウェアハウス用の生データCSVファイル
2. 週次ステークホルダーレポート用のサマリーテーブル
3. アクション可能な推奨事項のリスト」
パターン8:カスタムMCPサーバーの構築
既存のサーバーがニーズをカバーしない場合、カスタムサーバーを構築します。
最小構成のカスタムサーバー(TypeScript)
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
const server = new Server(
{ name: "my-shopify-tools", version: "1.0.0" },
{ capabilities: { tools: {} } }
);
// カスタムツールを定義
server.setRequestHandler("tools/list", async () => ({
tools: [
{
name: "calculate_shipping_estimate",
description: "Calculate estimated shipping cost based on weight and destination",
inputSchema: {
type: "object",
properties: {
weight_kg: { type: "number", description: "Package weight in kg" },
destination_country: { type: "string", description: "ISO country code" },
shipping_method: {
type: "string",
enum: ["standard", "express", "overnight"],
description: "Shipping speed"
}
},
required: ["weight_kg", "destination_country"]
}
}
]
}));
// ツール実行のハンドリング
server.setRequestHandler("tools/call", async (request) => {
if (request.params.name === "calculate_shipping_estimate") {
const { weight_kg, destination_country, shipping_method } = request.params.arguments;
// ここにカスタムビジネスロジック
const rates = calculateRates(weight_kg, destination_country, shipping_method);
return {
content: [
{
type: "text",
text: JSON.stringify(rates, null, 2)
}
]
};
}
});
// サーバーを起動
const transport = new StdioServerTransport();
await server.connect(transport);
カスタムサーバーの登録
# Claude Code
claude mcp add my-shopify-tools -- node /path/to/my-server/index.js
# または環境変数付き
claude mcp add my-shopify-tools \
-e SHOPIFY_ACCESS_TOKEN=xxx \
-e CUSTOM_CONFIG=value \
-- node /path/to/my-server/index.js
パターン9:セキュリティファースト構成
トークンローテーションパターン
# トークンは設定ファイルではなくシークレットマネージャーに保存
# 実行時にトークンを取得するラッパースクリプトを使用
#!/bin/bash
# start-shopify-mcp.sh
export SHOPIFY_ACCESS_TOKEN=$(aws secretsmanager get-secret-value \
--secret-id shopify/production/api-token \
--query 'SecretString' --output text)
export MYSHOPIFY_DOMAIN="my-store.myshopify.com"
npx -y shopify-mcp@latest
{
"mcpServers": {
"shopify-store": {
"command": "/path/to/start-shopify-mcp.sh"
}
}
}
本番環境の読み取り専用アクセス
本番ストアには、読み取りスコープのみのトークンを作成してください:
スコープ: read_products, read_orders, read_customers, read_inventory
書き込み操作には別の開発ストアのトークンを使用してください。
監査ログ
MCPサーバーをログプロキシでラップします:
// コンプライアンスのためにすべてのツール呼び出しをログに記録
server.setRequestHandler("tools/call", async (request) => {
const startTime = Date.now();
// リクエストをログに記録
await auditLog({
timestamp: new Date().toISOString(),
tool: request.params.name,
arguments: request.params.arguments,
user: process.env.MCP_USER_ID
});
// 実際のツールを実行
const result = await executeShopifyTool(request);
// 結果をログに記録
await auditLog({
timestamp: new Date().toISOString(),
tool: request.params.name,
duration_ms: Date.now() - startTime,
success: !result.isError
});
return result;
});
適切なパターンの選び方
| パターン | 複雑さ | 最適な用途 |
|---|---|---|
| シングルサーバー | 低 | 学習、シンプルなタスク |
| デュアルサーバー(ドキュメント + ストア) | 低 | 日常の開発 |
| マルチストア | 中 | 代理店、フランチャイズ |
| Composioルーター | 中 | クロスサービスワークフロー |
| CI/CD統合 | 高 | 自動デプロイメント |
| 自動管理 | 高 | スケジュールされた操作 |
| データパイプライン | 高 | アナリティクス、レポート |
| カスタムサーバー | 高 | 固有のビジネスロジック |
| セキュリティファースト | 中 | 本番環境 |
パターン2(デュアルサーバー)から始めてください。MCPのインタラクションに慣れたら、ワークフローの要求に応じて複雑さを追加してください。ほとんどの開発者はパターン2〜3以上を必要としません。