EC（Shopify）×Claude Code 活用ノウハウ集 ― 売上・コスト・生産性を動かす81の実践Tips

Shopify MCPのsearch_products/get-productで全商品を取得→（任意で競合URLをWebFetchで読ませ未カバーの訴求軸を抽出）→Claudeに『各商品のtitle・descriptionHtml・SEO title/descriptionを、産直・地域名・旬・用途の検索語を織り込んで書き直せ。競合が語っていない差別化角度を核にする。表現ルール.mdの当事者目線・上から目線NG・薬機法NGを厳守』と指示。件数が多ければサブエージェントに商品群を分割して並列で下書き→レビュー後にupdate-product（またはgraphql_mutation productUpdate）で反映。繰り返す業務なので既存の『Shopify商品登録』スキルに手順を追記してスキル化する。

Shopify MCP (search_products, get-product, update-product/graphql_mutation), WebFetch(競合分析), サブエージェント(並列下書き), スキル化

SEO流入の底上げと訴求差別化は方向として堅いが、めっけMON固有の数値効果は未実測。競合表現の模倣・盗用はせず、自社の一次情報で埋めることが前提。

Google Drive MCPで出店企業台帳・ヒアリングメモを読み込ませ、『各商品について、生産者の物語・産地・旬・おすすめの食べ方・保存方法を含む説明文を作れ。主語はコーディネーターが、AIが提案はNG。表現ルール.md準拠。台帳にない情報は創作せず空欄にして報告』と指示。生成物はレビュー後Shopify MCPで反映。属性が豊富な説明はサイト内検索やAIレコメンドの素材としても効く。

Google Drive MCP(台帳読込), Shopify MCP(update-product), 表現ルール.md準拠

属性の豊富な説明がAIエージェントの推薦対象になりやすいと複数の実務ガイドが指摘。CVRやレコメンド率への寄与は定性で、自店での定量効果は未検証。

Claudeにテーマのproduct.liquid用のJSON-LDスニペット(商品名・brand・price・availability・sku・画像複数・FAQ)をLiquid変数で生成させる。metafield運用ならgraphql_queryで現状を確認し構造化値を投入する方式も可。実装前にsearch_docs_chunks/validate_graphql_codeblocksで検証。テーマ直接編集になるため金澤さんの確認を経てからドラフト→デプロイ。

Shopify MCP (graphql_query metafields, search_docs_chunks, validate_graphql_codeblocks, テーマ), Claude(JSON-LD/Liquid生成)

構造化データがAI検索・リッチリザルトの被引用を助けるのは業界の共通見解。ただし引用される『構造化データ保有率○%』等はベンダー調査値で独立検証はなく、自店効果は未実測。方向は堅実だが数値は保証しない。

Claudeに全商品・主要ページ一覧をShopify MCPで取得させ、llms.txt(要点+リンク)とllms-full.txt(返品ポリシー・ブランド説明・商品仕様)を生成。scheduled taskで月次再生成し商品追加に追随。配信先は要注意：llms.txtはストア自身のドメイン直下に置いて初めて発見されるため、別ドメインのGitHub Pagesに置いても自店の案内としては機能しにくい。Shopifyはルート直下にファイルを置けないので、metaobject/固定ページ＋リダイレクトや対応アプリでの配信を検討する。

Shopify MCP(商品/ページ取得), Claude(Markdown生成), scheduled task(月次更新)

AIに高価値ページを明示する狙いは合理的だが、llms.txtは採用・効果ともに証明が限定的で定量ベンチマークはほぼ無い。効果は現状あくまで定性・実験的。

scheduled task(cron)で週次ジョブを組み、ClaudeにWebSearch/WebFetchで主要クエリを検索させ『自店・競合の露出有無・順位・引用文脈』を集計。結果をNotionの調査レポートDBに追記、要点をSlackに通知。露出が弱いクエリを次のコンテンツ/構造化データ施策にフィードバック。注意：Claudeが叩けるのは自身のWebSearch/WebFetchのみで、ChatGPT/Perplexity/Gemini等の他社AIエンジンをプログラムから直接クエリする機能はない。それらの被引用確認が要る場合はブラウザ操作(手動/半自動)が別途必要。

scheduled task(cron), WebSearch/WebFetch, Notion MCP(レポートDB), Slack MCP(通知)

手動では続かない露出チェックを自動化し施策のPDCAを回せる。他社AIエンジンの被引用は自動計測の範囲外なので『AI全般の被引用の完全把握』は約束できない。売上への効果は間接的。

Claudeに商品データを渡し『SEO記事＋比較表＋関連商品への内部リンク』をピラー/支柱構成で生成させ、記事同士とカテゴリページへのリンクも設計。Shopify MCPのgraphql_mutation(articleCreate)でブログ記事として投入。表現ルール準拠。量産の薄い記事は逆効果なので、1本ずつ人が価値を確認し産直の一次情報(生産者取材)を核にする。

Shopify MCP(graphql_mutation articleCreate, 商品データ), Claude(記事+内部リンク設計), サブエージェント(記事並列下書き)

クラスター化コンテンツの流入・順位維持・AI被引用の優位を示すベンダー調査はあるが、引用される『30%多い流入・2.5倍・3.2倍』等はベンダー発表値で独立検証はなく自店再現も未確認。効果は定性と捉える。

Shopify MCPで商品データを取得→Claudeに『Googleショッピング用に[ブランド+商品+規格+特徴]の順でタイトルを構成し、gtin/brand/product_typeを補完した属性リッチ版を作れ』と指示→補助フィードのCSVを生成。既存フィード全体を作り直さず属性だけ上書きできるのが利点。前提：めっけMONがGoogle Merchant Center/Shopping広告を実際に運用している（またはこれから始める）こと。

Shopify MCP(商品取得), Claude(属性生成/CSV), Google Merchant Center(補助フィード投入は手動アップロード)

フィード最適化がインプレッションシェアを広げうるのは実務の定説だが、引用される『40〜60%拡大』はベンダー値で商材・競合次第。立ち上げ期でShopping未運用ならまず運用開始の判断が先。

コピーはClaudeに『訴求軸を変えた見出し・本文を比率別(1:1フィード/9:16リール)に5案ずつ』と指示。画像はschmatz-imagegen(generate_image)に同じ訴求軸で比率別生成。生成物はGoogle Driveの該当フォルダに保存し社内レビュー後に配信。

画像生成MCP(schmatz-imagegen generate_image), Claude(コピー生成), Google Drive MCP(保存)

制作リードタイムの短縮は確実。CVR/ROASは配信テストで検証が必要で、生成量産と成果は別物。

Claudeに構成案(ファーストビュー→課題→商品→社会的証明→CTA、単一ゴール集中)を書かせ、Shopify MCPでセクションのLiquid/schemaを生成→validate_graphql_codeblocks/search_docs_chunksで検証→ドラフトテーマにデプロイしプレビューURLを確認。公開前に金澤さんが見た目とモバイル表示・速度を実機確認。既存の『20_めっけMON』構成案スキルと連携。

Shopify MCP(テーマ/セクション, search_docs_chunks, validate_graphql_codeblocks), Claude(構成案+Liquid), ドラフトテーマ(プレビュー)

プロンプトからドラフトテーマに稼働セクションを短時間で、という実例報告はある。CVは公開後のテストで検証。生成コードの品質は実機確認前提。

Claudeに『この変更(例: CTA文言A vs B)についてH1仮説・測定指標・現状CVRから必要サンプル数と検定期間・成功基準を算出せよ』と指示し設計書を作成、Notionに記録。実行はShopifyアプリ/外部A/Bツール(Shopify自体に汎用のネイティブA/B機能がある前提は置かない)。結果はrun-analytics-queryで集計しClaudeに解釈させる。

Claude(実験設計), Shopify MCP(run-analytics-query), 外部A/Bツール/アプリ(実行), Notion(記録)

立ち上げ期は母数が小さく有意差が出にくい。サンプルサイズを先に見積もることで『無理なテスト』を避けられるのが主効果。

Shopify MCPのget-inventory-levels/run-analytics-queryで在庫と売れ筋を取得→Claudeに『粗利を確保しつつ滞留在庫を捌く割引対象・率・訴求を提案』と指示→承認後にShopify MCP(create-discount)またはKlaviyo MCP(create_coupon/create_coupon_code)で発行。告知はKlaviyoキャンペーン・LINE・Instagramへ。

Shopify MCP(get-inventory-levels/run-analytics-query/create-discount), Klaviyo MCP(create_coupon/create_coupon_code), Claude(企画立案)

滞留在庫の現金化と粗利保全を両立する企画立案を高速化。売上効果は企画次第で定性。

Shopify MCPのrun-analytics-query/get-collectionで売上・構成を把握→Claudeに再編案(テーマ/シーン別、産地別など)を提案させ、create-collection/update-collection/add-to-collectionで反映。商品ページの関連商品ブロック追加はテーマ編集になるため金澤さん確認。注意：Shopifyのanalyticsは売上中心で、閲覧・カート経路(ファネル)の詳細データは取りにくいため、経路分析より在庫・売上・テーマ軸の再編から始めるのが現実的。

Shopify MCP(run-analytics-query, get-collection, create/update-collection, add-to-collection, テーマ), Claude(再編提案)

回遊・関連導線の改善はAOV・回遊率に寄与しうるが、立ち上げ期はデータが薄く効果は限定的。まず情報設計を整える基盤効果が主。

Shopify MCPで全商品のtitle/tags/metafieldを棚卸し→Claudeに命名規則(mekkemon-shopify-data-model実測: タグは3語のみ、custom.product_category=振り分け、vendor=企業紐付け、wk_custom_field=テーマ表示)に照らした差分リストを作らせ、レビュー後にbulk更新(bulk-update-product-status/graphql_mutation)。定例棚卸しはscheduled taskで月次チェック。

Shopify MCP(graphql_query/mutation, bulk-update-product-status), Claude(差分検出), scheduled task(定期棚卸し)

表記統一はSEO・サイト内検索・フィード品質の土台。単体の売上効果より、後続の全集客施策の精度を上げる基盤効果。

Claudeに『Klaviyo MCPのget_flowsで全フロー一覧、各フローのget_flow_reportで開封率・注文・売上を出し、未設置フローと開封率が低いフローを表にして。改善優先度を売上インパクト順で提案して』と指示。読み取り・分析のみなので承認不要で回せる。結果はレポート出力ルールのHTMLテンプレでNotion『調査レポート』DBへ格納。フロー本体の新規作成・改変はMCPにツールが無いため、この監査は『どこを人がUIで直すか』の設計図として使う。

Klaviyo MCP (get_flows, get_flow_report, get_campaign_report), Notion MCP

自動フローは送信数のごく一部で全メール売上の約4割を生む（業界ベンチマーク）ため、穴を塞ぐ効果が最も大きい領域。手作業だと数時間かかる全フロー横断監査がMCPで数分。数値は自社実績ではなくベンチマークである点に注意。

Claudeに『表現ルール.mdとデザインルール.mdを読んだ上で、ウェルカム5通（1:歓迎と世界観、2:生産者ストーリー、3:人気逸品、4:初回クーポン、5:LINE誘導）の件名2案＋本文を作成し、Klaviyo MCPのcreate_email_templateでテンプレ保存して』。主語は『AIが提案』ではなく『コーディネーターが』。割引は3通目以降に置く（先に価値提示）。生成したテンプレをフローの各ステップに割り当てる作業はUIで人が行う（MCPにフローへのテンプレ割当ツールが無いため）。

Klaviyo MCP (create_email_template), ファイル操作（表現/デザインルール読込）

ウェルカム系は開封・初回転換が高い高インパクト帯（一般に1通目開封40〜50%台という代理店ベンチマークがあるが、幅が広く自社データで確認が必要）。カゴ落ちと並ぶフロー売上の主力。

Claudeに『カゴ落ち3通を作成。1通目=30〜60分後で「お忘れ物では？」割引なし、2通目=24時間後で商品の魅力と生産者背景、3通目=48時間後で期限つき10%ユニーククーポン。件名各2案。create_email_templateでテンプレ保存』。クーポンは別掲のユニークコード施策と連携。フローのトリガー設定・ステップ配置はUIで人が行う。

Klaviyo MCP (create_email_template, create_coupon)

カゴ落ちシーケンスは放棄チェックアウトの一定割合を回収する定番装置で、開封率も高め（代理店ベンチマークで50%前後の集計あり、幅がある）。段階割引で定価崩れを抑える。「単発比◯倍」といった倍率は集計元により大きく振れるため自社検証前提。

Klaviyoのプレビルト『Reviews: Review request』フローを土台に、Claudeで各ステップ文面をcreate_email_templateで生成。集まったレビューはget_reviewsで吸い上げ、『高評価から商品LP用の一言、低評価から要改善点サマリを作って』と指示し品質改善にも回す。

Klaviyo MCP (create_email_template, get_reviews, update_review)

生産者の顔＋実食レビューは産直と相性がよく、検証済みレビューは新規の信頼と転換を押し上げる（定性）。定量効果は自社での計測が前提。

Claudeに『Klaviyo MCPのget_segments/query_segment_valuesでチャーンリスク高またはRFMのAt-risk層の人数と特徴を出して。その層向けにWin-back3通（1:ご無沙汰の挨拶と旬の新着、2:あなた向けの一言、3:限定クーポン）を作成』。抽出→文面→クーポン準備まで1セッションで。

Klaviyo MCP (get_segments, query_segment_values, get_segment, create_email_template)

チャーン発火型のWin-backは時間基準のみより回収が増えるという代理店集計・事例があるが、倍率は事例依存。At-risk再訴求のAOV改善も事例レベルの話として扱う。

カスタムスラッシュコマンド/スキル（例 /件名 商品名 訴求軸）を定義し、『get_campaign_reportで過去キャンペーン件名の開封率を参照し、勝ちパターンを踏まえて件名を4案。絵文字有無・数字有無・旬訴求を混ぜる』とする。スパム語・記号過剰は避ける。A/Bの実施と勝敗判定はKlaviyo UIで人が設定する。

Klaviyo MCP (get_campaigns, get_campaign_report), カスタムスラッシュコマンド/スキル

件名テストは開封率改善の定番。EC平均開封率は概ね18%前後・上位は28%前後というベンチマークがある。『AIで+○%』の広い数字はベースライン依存で、勝敗は必ず自社の実データで判定する。

Claudeに『create_coupon/create_coupon_codeでウェルカム用の10%単回クーポン（プレフィックスMEKKE）を用意し、ウェルカム4通目テンプレに動的差し込みのプレースホルダを入れて』。フロー用はコードのプールを十分に確保しておく（プールが尽きると配信時にコード付与がスキップされる）。Shopify同期の有効化状態は事前に確認。

Klaviyo MCP (create_coupon, create_coupon_code), Shopify MCP（割引同期）

1人1コードで転売・共有を防ぎつつ特別感を出せる。Shopify連携が有効なら生成コードが即チェックアウトで有効。

Shopify MCPのrun-analytics-queryで『カニ購入者は次に何を買っているか』等を出し、Claudeに『カニ購入者向けに、端境期は加工品/干物、次シーズンは早割予約を提案する季節メールのカレンダーと文面を作って』。scheduled task（定期実行）で毎月頭に『今月の旬の訴求案とセグメントを出す（下書き）』を回すと運用が軽い。フロー本体の設定はUIで人が行う。

Shopify MCP (run-analytics-query), Klaviyo MCP (create_email_template, get_segments), scheduled task（scheduled-tasks MCP）

産直EC最大の課題はリピート率の低さ（旬に一度買って終わり）。定期便・季節提案・セット・加工品で『次は何を届けるか』まで設計すると売上が安定化する、と複数の日本の食品EC実務記事が共通して指摘（定性）。

Claudeに『補充フローの設計案と文面を作って。毎回同シーケンスで嫌気されないよう、まず初回購入者の2回目育成に限定する構成にして』。品カテゴリ別の一般的な消費サイクル（例：米◯週間）は人が指定してトリガー日数に反映。予測次回注文日を使う場合はデータ蓄積が前提。

Klaviyo MCP (create_email_template, get_segments), Shopify MCP（商品カテゴリ）

補充フローは消耗品ECの定番リピート装置。Klaviyoは『予測次回注文日の常時配信は配信解除を招くため、まず初回購入者の2回目育成に絞る』ことを推奨。

scheduled task（scheduled-tasks MCP）に『毎週月曜、Klaviyo MCPで先週のget_campaign_report/get_flow_reportとquery_metric_aggregates（売上・注文）を集計し、レポート出力ルールのHTMLテンプレでNotionへ格納。要点3行をSlackに下書き投稿』を登録。サブエージェントで『数値集計』と『考察・打ち手案』を分担させると精度が上がる。

scheduled task, Klaviyo MCP (get_campaign_report, get_flow_report, query_metric_aggregates), Notion MCP, Slack MCP, サブエージェント

手作業のレポート集計を恒常的に削減。読み取り＋社内格納中心の自動化で、承認ゲートと衝突しにくい。

Claudeに『(1)RFMのChampions、(2)初回購入のみ90日経過、(3)特定vendorリピーター、(4)ギフト配送先ありの各セグメント定義を提案し、get_segments/query_segment_valuesで規模を確認。各層に1通ずつ訴求案を』。全員一斉配信をやめ層別に出すだけで効く。セグメント作成の反映・配信はUIで人が確認して実施。

Klaviyo MCP (get_segments, query_segment_values, create_list)

上位優良層（Champions）は少数で売上構成比が高いのが一般的で、層別配信の価値が高い（RFMの経験則）。転換改善の事例はあるが数字は事例依存。

Claudeに『今週の旬企画を、(A)LINE配信用の短文＋リンク、(B)メール用の本文の両方で作って。LINEは30〜40文字の見出し、メールは生産者背景まで』。めっけMONの公式チャネルはLINEとInstagramのみ（Xは運用しない）方針に沿う。LINEはKlaviyo管轄外なので文面提供に留め、配信は人が実施。

Klaviyo MCP（メール側テンプレ）, ファイル操作（SNS方針・表現ルール読込）, 画像生成MCP（サムネ）

メルマガ/ステップメール/LINE公式は日本の食品ECで定番のリテンション施策。1企画を両チャネルへ横展開すると制作工数が下がる（定性）。

『メール文面チェック』をスキル/スラッシュコマンドとして定義し、表現ルール.mdを基準に(1)禁止語（FOC等）(2)スパム語(3)プロンプト残骸(4)主語が『コーディネーターが』か(5)無料/手間ゼロの明示、を必ず確認する手順にする。テンプレ生成コマンドの後段に組み込み、NG項目があれば赤字で指摘。ローカルのファイル保存イベントに絡めるならhooksで補助チェックを走らせることも可能だが、主体はスキルの手順とする。

カスタムスキル/スラッシュコマンド, ファイル操作（表現ルール読込）, （補助）hooks

AI生成の主な落とし穴はプロンプト残骸・薄いパーソナライズ・事実誤り・同型反復・QA漏れで、未レビューだとスパム判定や不信を招く。関門化で恒常的に防げる（定性）。

.claude/skills/めっけMONトンマナ/SKILL.md に (1)ブランドの声=3-5形容詞 (2)We are/We are not対比 (3)禁止語→言い換え表(『FOC』→『企業連携』、『AIが提案』→『コーディネーターが』、上から目線語の除去) (4)良い例/悪い例のbefore-after (5)出力前チェックリスト を記載。本文ルールは 00_運営ルール/表現ルール.md を参照させ二重管理を避ける。以後『トンマナスキルに従って書いて』で毎回同じ声が出る。初回は佐々木と一緒に声・禁止語を洗い出す。

スキル(SKILL.md), 既存の表現ルール.md, サブエージェント(レビュー用)

生成AIは既定だと『ネットの平均』の声に寄り没個性化する。禁止語・お手本をスキルで固定すると逸脱を仕組みで防げる(定性)。時短効果を謳う事例はあるが、めっけMONでの主効果は声の一貫性・逸脱防止と捉えるのが妥当。

スキルを機能分割: (1)リサーチスキル=WebSearchで一次情報・数値を収集しJSON化 (2)構成スキル=H2/H3見出し・字数・検索意図を設計 (3)執筆スキルはトンマナスキルを読み込んで本文化。/write のようなスラッシュコマンドで起動し、各段が『データ(JSON)』を次段に渡す設計にすると精度が上がる。初稿→人がファクトチェック・独自取材を追記、の分業で品質担保。成果物は 20_めっけMON/SEO/ 配下へ。

スキル/スラッシュコマンド, WebSearch, Notion MCP(記事DB格納)

国内でClaude Codeを使いブログ1本8時間→1時間・月50本まで量産した事例が報告されている(ベンダー自己申告の1事例で、めっけMONで同率を保証するものではない)。AIの数値・固有名詞のハルシネーションは必ず信頼できる出典で裏取りが必要。

.claude/skills/生産者ストーリー/SKILL.md に (1)事前準備=商品・産地の下調べプロンプト (2)質問リスト設計=『何を語ったか』でなく『どんな背景でその言葉が出たか』を引き出す設問 (3)原稿形式=Q&A/モノローグ/ルポの3型から選択 (4)構成=時系列でなくストーリーの流れ を定義。取材メモ(40_会議・商談/ や音声文字起こし)を投入→Claudeがトンマナスキル適用で原稿化。写真キャプション・商品ページ用の短文も同時生成。

スキル, トンマナスキル, Googleドライブ MCP(取材メモ取得), 画像生成(挿絵)

生産者の一次情報は独自性と信頼性を両立できる数少ないコンテンツ資産(定性)。取材の手間は構成・執筆をClaudeが担うことで軽減できるが、取材そのものは人が実施する前提。

リパーパススキルを2パス設計: パス1=記事を分析し要素(要点/引用/数値/CTA)をJSON抽出。パス2=各チャネル仕様(Instagram=ビジュアル前提の短文＋ハッシュタグ、LINE=一言＋リンク、Klaviyoメール=件名＋本文)で執筆スキルに通す。チャネルごとの字数・トーンは FORMAT_PROFILES として設定に外出し。『この記事をInsta・LINE・メール用に展開して』で全部出る。SNSはmekkemon.rw(Instagram)とLINEの2つのみ(Xは運用しない)。

スキル, トンマナスキル, Klaviyo MCP(メール下書き), Notion MCP

1コンテンツ多チャネル展開は高レバレッジの定石。書き分けの手作業を削減(定性)。

サブエージェントで並列化(旬カレンダー担当・生産者担当・企業連携/キャンペーン担当が同時にネタ出し)→JSONを1本のカレンダーに統合→CSV/HTMLで 20_めっけMON/ へ、案はNotion企画DBへ。scheduled task(定期実行)で『毎週月曜朝: 直近の旬食材・季節イベント・食品トレンドをWebSearchで収集→めっけMONの商品ラインと突き合わせ、翌週の記事/投稿ネタ10案＋翌週分の投稿カレンダーをNotionに下書き』を回すと、始業前にネタ棚が埋まる。既存Notion企画DBを先に検索させ重複を避ける。

サブエージェント, scheduled task(定期実行/cloud routine), WebSearch, Notion MCP, Googleカレンダー MCP

週3回以上の投稿は管理なしだとネタ切れが更新停止の最大原因。カレンダー先回りで途切れと初速のロスを防ぐ(定性)。

.claude/skills/プレスリリース/SKILL.md に基本6要素＋『ニュース価値を1文で』『客観的な数値・事実で書く』ルールを定義。トピックとキーファクトを渡すと構成・推敲まで担当。自社独自の数値・開発ストーリーは人が責任を持って記述する欄を明示(創作させない)。インフォグラフィック用の図案は画像生成で下地を作る。AI検索に引用される長期資産の観点でSEO/LLMO文脈のキーワードも織り込む。

スキル, 画像生成MCP(インフォグラフィック下地), トンマナスキル

中小企業のメディア掲載は『基本構成×ニュース価値×客観性』の型で外し方を減らせる(定性)。AI生成のまま配信は非推奨、独自情報・数値は人が記述・裏取り。

2層で守る: (A)hooks=Claudeのファイル書き込み(Write/Edit)後に走るPostToolUseのシェルコマンドフックで、禁止語リスト(『FOC』『AIが』『絶対』等)をgrep検査し、ヒットしたら即フィードバック(決定的・機械的)。(B)校閲サブエージェント=表現ルール.md/トンマナスキルに照らして重大度別に逸脱を指摘し直し方を提案(ニュアンス判断)。『校閲エージェントでこのドラフトをレビューして』で起動。皮肉・ユーモア・文化的機微はAIが外すので、そこは人が見る。

hooks(PostToolUseシェルコマンド), サブエージェント, 表現ルール.md, update-configスキル(settings.json)

AIは文書化されたルール遵守は得意・微妙なニュアンスは不得意。ルール検査を自動化し人的レビューを高付加価値に寄せられる(定性)。

画像生成MCP(schmatz-imagegen)を使い、(1)過去のお手本画像をスタイル参照として毎回添える (2)バナー内テキストは短く『』で囲んで指定し文字化けを防ぐ (3)デザインルール.mdの世界観(信頼×温かみ・イラスト図解)をプロンプトの固定接頭辞にスキル化。ビジュアルのお手本セットを1つ決めておくと一貫性が出る。生成物は該当フォルダへ保存。

画像生成MCP(schmatz-imagegen), スキル(プロンプト接頭辞), デザインルール.md

画像生成でバナー制作コストを約80%削減した事例が報告されている(ベンダーの自社事例で条件依存、めっけMONで同率を保証するものではない)。テイストのバラつきはお手本参照で抑える必要がある。

Notion MCPで記事・投稿案をDBに作成し、プロパティで『企画/執筆中/レビュー/公開済』のステータス・チャネル・公開日を管理。Claudeが下書きをページ本文に書き込み→承認後に人が公開ステータスへ。ネタ出し前にDBを検索させテーマ重複(カニバリ)を防ぐ。社内レポートはCLAUDE.mdの保存ルール(HTML・調査レポートDB格納)に沿う。

Notion MCP, スキル, サブエージェント

各工程をドキュメント化・可視化すると誰がやっても同品質になり抜け漏れを防げる(定性)。

既存の『Klaviyoメール編集』スキル＋トンマナスキルを併用し、生産者記事から件名・プリヘッダー・本文を派生(リパーパス)。Klaviyo MCPでテンプレート/フローのステップメールに下書き反映。件名はA/B用に2案出させる。配信停止・フッター等の定型文もスキルで統一。

Klaviyo MCP, 既存Klaviyoメール編集スキル, トンマナスキル

記事→メールの横展開で執筆工数を削減し声を統一(定性)。

CLAUDE.mdの学習ループに沿い、佐々木の修正が入るたび 00_運営ルール/改善ログ.md に『指摘・意図・直し方』を記録→トンマナスキルのbefore-after例に反映。反応の良かった投稿・記事はKlaviyo/Shopify分析やInstagramインサイトで特定し、お手本例に追加。上位パフォーマンス記事の抜粋をスキル/CLAUDE.mdの参照例に入れると声の再現性が上がる。

スキル更新, 改善ログ.md, Klaviyo/Shopify MCP(反応分析)

お手本例(top-performing)を参照に入れると出力の質が上がるのは定石。運用で例が増えるほど声が固まる(定性)。

既存の『Shopify商品登録』スキルを起動し『80_受信箱の◯◯台帳をShopifyに投入して。実測データモデル（wk_custom_field=テーマ表示/custom.product_category=振り分け/vendor=企業紐付け/タグは3語）に従って』と指示。少量はcreate-product/update-product、数十件以上はgraphql_mutation+bulkOperationRunMutation（JSONL）で一括。投入前に必ず差分プレビューを出させる。

Shopify MCP(create-product / update-product / graphql_mutation), Shopify商品登録スキル, Google Drive MCP

公式bulk importはJSONL1行=1商品で数千件規模を1ジョブで処理でき、管理画面の逐次入力を置き換える。ただし同一アプリで同時に走らせられるbulkジョブ数には制限があり、大量投入は順次実行になる。時間削減の具体値は自社実測が必要（誇張しない）。

ファイルをそのまま渡し『この卸価格表に1.4掛けして税込小売価格を作り、Shopify取込形式に整形して。不明点は質問して』と指示。ClaudeがPDF抽出→列マッピング→価格計算→取込ファイル生成まで実施。生成物は80_受信箱に保存し、投入は前Tipの承認フローへ渡す。標準のファイル操作だけで完結し、Matrixify等の一括取込アプリは必須ではない（使うなら追加コスト）。

ファイル操作, Shopify MCP(graphql_mutation), （任意でMatrixify等の一括取込アプリ）

供給元ファイルを無加工で渡し、価格調整・列変換・取込ファイル生成をAIが代行する運用が公式チュートリアルでも示されている。定量削減は要自社実測。

『get-inventory-levelsで現在庫を出して、この入荷リストとの差分を表にして。承認したらset-inventoryで反映』と指示。まず差分表→承認→反映の順。複数拠点があればロケーション指定を明示。

Shopify MCP(get-inventory-levels / set-inventory / graphql_query)

在庫精度の維持はオーバーセル（欠品なのに販売）による顧客体験毀損を直接防ぐ。産直モールは入荷変動が大きく効果が出やすい。

『vendorが◯◯でタグに"お試し"が付く商品を全部下書きにして。対象一覧を先に出して』と指示。bulk-update-product-statusで公開/下書き/アーカイブを一括、価格はgraphql_mutationのproductVariantsBulkUpdate。必ず対象リストを提示→承認→実行。

Shopify MCP(bulk-update-product-status / update-product / graphql_mutation), search_products

『タグ"カニ"の商品で〈冬の逸品〉コレクションを作って商品を入れて』と指示。create-collection→add-to-collection、または自動条件（ルールベース）コレクションをgraphql_mutationで設定。新商品が条件一致で自動的に入る形にすると以後メンテ不要。

Shopify MCP(create-collection / add-to-collection / update-collection / search_collections)

回遊性の高い特集面を素早く作れ、立ち上げ期の面づくりを高速化する。売上寄与そのものは要検証（誇張しない）。

『全商品をgraphql_queryで取得し、alt欠落・metafield欠落・vendor空・価格0を検出して品質レポートをHTMLで（レポート出力ルール準拠）』と指示。商品数が多ければサブエージェントに項目別（SEO班/在庫班/紐付け班）で並列監査させ結果を集約。修正案までAIに書かせ、反映は承認後。

Shopify MCP(graphql_query / search_products), サブエージェント（並列監査）, レポート出力ルール(HTML)

metafield（産地・重量・原産国）が揃うとGoogle Shoppingや生成AI検索が情報を正確に拾いやすい。free-textだけだと拾われにくい。

『Gmailの未返信からWISMO系を抽出、注文番号でget-orderして状況を確認、返信文を下書きに保存』と指示。Gmail MCPはcreate_draft（下書き作成）までで送信APIを持たない設計を活かし、人が最終送信する。Slackで社内共有も可。

Shopify MCP(list-orders / get-order), Gmail MCP(search_threads / create_draft), Slack MCP

WISMO/WISMR系は総チケットの40〜60%を占めるとの業界報告がある（出典参照）。ここの下書き自動化で一次対応時間を圧縮できるが、自社の削減幅は実測を推奨。

『直近の問い合わせスレッドを分類して頻出FAQトップ20を作り、NotionのナレッジDBに草案として格納』と指示。以後の一次対応（前Tip）でこのFAQを参照させると回答が安定する。

Gmail MCP(search_threads), Notion MCP(notion-create-pages), サブエージェント

『run-analytics-queryで先週の売上・注文数・AOV・vendor別売上・在庫10未満SKUを出して、レポート出力ルールのHTMLテンプレを複製して定例レポートを作り、Notion調査レポートDBに格納』と指示。数式で拾えない指標はgraphql_queryで補完。run-analytics-queryはShopifyQLを実行する公式ツール（MCPサーバ説明で確認済み）。

Shopify MCP(run-analytics-query=ShopifyQL / graphql_query), レポートテンプレート_v1.html, Notion MCP

集計→整形→格納の一連を自動化できる。読み取り主体で事故リスクが低い。

bulkOperationRunQuery（GraphQL一括エクスポート）でJSONLを吐き出し→BigQueryにロード→『このテーブルでvendor別粗利と初回/リピート比率を出してレポート化』と指示。MEMORYのmekkemon-ai-ops-architectureの5層構成に沿って別アカMCP運用と整合させる。

Shopify MCP(graphql_query bulkOperationRunQuery), BigQuery, サブエージェント, Notion MCP

Shopifyの多数エンドポイントを横断するにはBigQuery集約が定石で、単一の真実の源をつくれる。

『毎朝9時：全商品と在庫をgraphql_queryで取得、ルール（在庫<0・公開中×在庫0・価格0・SKU重複）に反する行だけ抽出してSlackの運営チャンネルに要約投稿。異常ゼロなら通知しない』というプロンプト＋cron式＋接続（Shopify読み取り/Slack）をscheduled taskに登録。同じ仕組みで定例レポート（前掲）も常設できる。まず読み取り＋通知系から常設し、書き込み系は都度承認運用のまま残す。

scheduled-tasks MCP(create_scheduled_task / list / update), Shopify MCP(graphql_query), Slack MCP

Shopifyは低在庫/異常の網羅的な自動アラートを標準提供しないため、この仕組みは実質的な穴埋めになる。ルーティンはAnthropic管理のクラウドで実行されPCが閉じていても継続する。

Claude CodeのPostToolUse/Stop系hookに、更新後の該当SKUを再取得して想定件数と一致するか検算し結果をログ保存するスクリプトを設定（settings.json）。繰り返す運用はスキル化（.claude/skills/）して承認ゲート欄・データ源・判断基準を明文化し、2回目以降は型どおり実行。

Claude Code hooks(settings.json), スキル(SKILL.md), Shopify MCP(graphql_query)

hooksは決定的（毎回必ず走る）ため、AIの気まぐれに依存せず検算・記録を強制できる。

Claude Codeで /plugin marketplace add Shopify/shopify-ai-toolkit → /plugin install shopify-plugin@shopify-ai-toolkit の2コマンド。バンドルされるスキル(shopify-liquid-themes / liquid-theme-standards / liquid-theme-a11y / functions / headless)がタスクに応じ自動発火する。書き込み系を増やしたくなければ、読み取り専用のDev MCP単体でも可：ターミナルで claude mcp add --transport stdio shopify-dev-mcp -- npx -y @shopify/dev-mcp@latest → claude mcp list でconnected確認(Node18+)。CLAUDE.mdに『Shopifyの質問前に必ず learn_shopify_api を呼ぶ／GraphQLは validate_graphql_codeblocks、Liquidは validate_theme_codeblocks を必ず通す／記憶ベースで答えない』と明記する。

Shopify AI Toolkit プラグイン、Shopify Dev MCP（validate_theme_codeblocks / validate_graphql_codeblocks / introspect_admin_schema / search_docs_chunks / learn_shopify_api）

『そんなフィールドは存在しない』系の手戻りがほぼゼロになる（定性。定量値は非公表）。注意：めっけMONは既に書き込み可能なShopify MCPを接続済みで、docs検索とGraphQL検証は重複する。純粋な追加価値はLiquidテーマ検証とテーマ/Functions/Hydrogenの公式スキル。AI Toolkitの『live store management』は接続済みMCPと同様に本番書き込みが可能な点に注意し、承認ゲートを崩さない。

テーマリポジトリ直下のCLAUDE.mdに『shopify theme push は --unpublished 以外禁止／公開中テーマには触れない／大掛かりな変更前に必ずgitコミット／見た目に影響する変更(層C・D)は金澤さん確認まで停止／計測系は業務ルール4章の4層モデルで層判定してから着手／顧客向けにFOCと書かない(→企業連携)』を明記。深い規約は別ファイルへリンクし本文は薄く保つ。karimmtarek氏のShopifyフロント規約gistを下敷きにできる。

CLAUDE.md（Claude Codeのプロジェクトメモリ）

『CLAUDE.md無し』が代表的な失敗要因として挙がる。ガードレールを明文化するだけで規約逸脱・暴走が大きく減る（定性）。既存の H:\...\CLAUDE.md（会社全体）とは別に、テーマリポジトリ専用の薄いCLAUDE.mdを置くのがポイント。

片ペインで shopify theme dev --store <めっけMONストア> を起動、もう片方でClaude Code。プロンプトは『audit→違反特定→最小修正→shopify theme check で検証→変更点サマリ』の型で回す。変更後は必ず git diff と実プレビューを金澤さん/佐々木に提示してから push。決して自動で本番公開(theme push --live)しない。Windowsでも Shopify CLI は動作するが、theme dev はPowerShell/Git Bashのどちらかで安定する方を使う。

Shopify CLI（theme dev / theme check）、Claude Code、Git

『チェックアウト・性能クリティカル・複雑ロジック・アプリ連携は人に引き継ぐ』が公式推奨の線引き。小さく刻むほどロールバック確度が上がる。

.claude/commands/ に /new-section <name> を作成し、OS2.0のJSONテンプレート・LiquidDoc・翻訳キー・schema settingsの雛形を定義。validate_theme_codeblocks を必ず通す指示を含める。定着したら .claude/skills/ にSKILL.md化して2回目以降は手順どおり実行し、承認ゲートで停止する（CLAUDE.md 4章のスキル化ループに乗せる）。

カスタムスラッシュコマンド／スキル、Shopify Dev MCP、Shopify CLI

scaffold/renaming/porting等の機械的作業をClaudeが代替。出典は『2〜3のサブエージェントで一週間分のテーマ作業を一日に圧縮しうる』とするが、これは上限の主張であり鵜呑みにしない（母数・タスク依存）。

liquid-reviewer（theme check違反とスタイル逸脱）、theme-performance-auditor（Lighthouse→Liquid改善提案）、metafield-wizard（定義とrender雛形。実測済みのwk_custom_field/custom.product_category/vendorのデータモデルを渡す）、a11y-reviewer（WCAG/キーボード操作）をYAMLフロントマターでスコープ定義。『この改修をこの4観点で並列レビューして』と指示する。

Claude Codeサブエージェント（.claude/agents/）

並列調査で観点漏れが減る（定性）。CLAUDE.mdの原則『研究・並列作業はサブエージェントに委譲』と整合。metafieldレビューには実測済みデータモデル(memory参照)を渡すと取り違え事故を防げる。

【修正版】commitのゲートは『gitのpre-commitフック』で shopify theme check を発火させる（Claude Codeのhooksはgit commitでは発火しないため、ここはgit側で組む）。加えてClaude Codeの settings.json に PostToolUse フック（Edit/Write にマッチ）を置くと、Claudeがテーマファイルを編集した直後に theme check が走り、Claudeが即自己修正できる。CLAUDE.mdに『修正後は必ず theme check を通し、違反ゼロを確認してから完了報告』と明記。

Git（pre-commitフック）、Claude Code hooks（PostToolUse）、Shopify CLI（theme check）

『theme check連携をスキップ』が典型的失敗要因。二段構え（編集直後の自己修正＋コミット時ブロック）でレビュー往復と本番不具合が減る（定性）。原案は『Claude Code hooksでコミット時に発火』としていたが、Claude Codeのhooksはgit commitイベントでは発火しないため機構を分けて修正した。

Claudeにブランチ作成・コミット・PR本文作成まで gh CLI で任せ、diffをPRに出させる。GitHub上で金澤さん/佐々木がClaudeの差分をレビューしてからマージ。mainへのマージ（＝本番テーマ更新）だけは必ず人が行う。全変更が記録され、いつでも巻き戻せる状態にする。

Git / gh CLI、Shopify GitHub integration、Claude Code

『CLIでローカル開発、GitHubが正、PRレビュー、mainマージで公開』が現代の標準ワークフロー。差分承認が制度として担保され、属人的な『うっかり本番公開』を構造的に防ぐ。

Claudeに『product.metafieldsとproductオブジェクトを使い、価格・在庫を必ず動的バインドしたProduct JSON-LDを生成。重複マークアップは出さない』と指示し、validate_theme_codeblocks とGoogleリッチリザルトテストで検証。価格ハードコード禁止。schemaは軽量に保ちCore Web Vitalsを悪化させない。

Claude Code、Shopify Dev MCP、Shopify CLI（theme）

JSON-LDはGoogle推奨でAIエンジンも解析しやすく、検索経由流入の質改善が期待できる（定性。CVへの寄与は商品・競合状況次第で定量保証はできない）。重いschemaはレンダリングを遅らせCWVに響くため軽量厳守。

ClaudeにLighthouse CIのワークフローYAMLを書かせ、PRごとにスコアを出す。CLAUDE.mdに性能予算（LCP/CLS等）を数値で書き、『変更後この予算を超えないか確認し、超えたら原因Liquidを直す』と指示。theme-performance-auditorサブエージェントと組み合わせる。GitHub連携(前掲Tip)が前提。

GitHub Actions（Shopify Lighthouse CI）、Claude Code（サブエージェント）

アプリ追加やテーマ更新は回帰を再発させやすく都度スキャンが要る。自動化で『気付かぬ劣化』を防ぐ。ただし自動ツールが検出できるWCAG問題は限定的で、キーボード/スクリーンリーダの手動確認は別途必要。

『この不具合を再現条件から特定し、原因のsection/snippetを指摘、最小diffで修正案を出し、shopify theme check と実プレビューで回帰確認して』と指示。ブラウザ操作機能で実画面のコンソールエラーやネットワークを読ませ原因の当たりを付けさせる。修正は下書きテーマで行い、差分を提示して承認を取る。

Claude Code（ファイル横断調査・ブラウザ操作）、Shopify CLI（theme check）、Dev MCP

『全Liquidを読む→scaffold→theme dev→出力を解析→エラー修正を同一ループで』回せるのがClaude Codeの強み。調査の当たり付けが速くなる（定性）。

scheduled task（定期実行）で週次バッチを組み、Claudeにブラウザ操作で主要URLを巡回させ、コンソールエラー/リンク切れ/Lighthouse主要指標を収集→前週との差分を要約→Notion『調査レポート』DBに下書き保存＋異常時のみSlackに通知案を下書き。閾値割れだけ人が見る運用にする。

Claude Code scheduled task、ブラウザ操作、Notion MCP、Slack MCP（下書き）

監視を『誰も見ない管理画面』にせずAIが差分だけ上げるので、立ち上げ期の少人数でも劣化を早期に拾える（定性）。遡及取得できない指標は早く回し始めるほど得。

.mcp.jsonをリポジトリに含め、PRでMCP設定変更もレビュー対象にする。チーム利用のDev MCPは @latest でなくバージョン指定。読み取り専用のDev MCPと、書き込み権限のあるストア操作MCP（接続済みのShopify MCP／AI Toolkitのlive管理系）を明確に分離し、後者は可能な限りステージング/開発ストアに向ける。

Claude Code MCP設定（.mcp.json）、Git

全員が同一ツール群で作業でき再現性が上がる。読み書き権限の分離で誤って本番を書き換える事故を防ぐ（定性）。

AI Toolkitのfunctionsスキルを有効化し『Functionsは副作用禁止（no network/filesystem/randomness）』の制約下で実装させる。GraphQLは validate_graphql_codeblocks、UI拡張はPolarisで validate_theme_codeblocks を通す。shopify app dev でローカル検証し、開発/ステージングストアで挙動確認してから申請。

Shopify AI Toolkit（functionsスキル）、Shopify CLI（app dev）、Dev MCP

スキルがFunctionsの純粋性制約を把握しているため無効な実装を減らせる。割引・配送最適化は客単価/CVに効きうる（実装内容次第。定量保証はできない）。

AI Toolkitのheadless/hydrogenスキルを有効化。Shopify公式hydrogenリポジトリの .claude/skills/hydrogen-dev-workflow に沿って codegen・型チェック・shopify hydrogen upgrade（メジャー1段ずつ検証）を回す。Storefront APIクエリはDev MCPで検証。まずはPoC範囲に限定し、工数と保守負荷の見積りを出す。

Shopify AI Toolkit（hydrogen/headlessスキル）、Shopify CLI（hydrogen）、Dev MCP

エージェントはloader付きroute・スキーマ整合クエリ・ネストレイアウトを的確に生成できたとの実事例あり。ただし移行は大掛かりで保守負荷が上がり、立ち上げ期のめっけMONでは優先度が低い。あくまで判断材料づくり。

サブエージェントに商品群を分担させ、Shopify MCP（search_products/get-productで取得→ドラフトはファイル出力、本番反映は保留）で処理。指示例『vendor=浜勘の全商品について、custom.product_categoryを踏まえ産地・食べ方・保存法を含む300字の説明とSEO title(60字)を生成。表現ルール.md厳守、下書きをMD/CSVで出力し本番反映はしない』。下書き→佐々木/金澤さんレビュー→update-productで反映、の3段を固定。編集で直した点を改善ログ.mdに記録し次回プロンプトへ反映（学習ループ）。手順が固まったら.claude/skills/Shopify商品登録へ反映。

Shopify MCP, サブエージェント, スキル(Shopify商品登録), ファイル出力, 改善ログ

あるベンダー事例で703商品説明を約2時間生成（手作業比で大幅短縮と主張）、別事例で88%時間短縮の報告。単一調査ではAI生成を人が編集する運用が純人手比コスト54%減・純AI比コンバージョン改善という結果。いずれも特定事例・母数依存で、自ストアでの実測が前提。純AI丸出しより人編集込みの方が品質・ブランド面で堅い。

Klaviyo MCPでget_flows/get_flow_reportにより現状把握→スキル『Klaviyoメール編集』で文面作成。指示例『カゴ落ちフロー3通を、めっけMONの“つながる”価値と表現ルールに沿って作成。1通目1h後・2通目24h後・3通目72h後、送信者名・配信停止文言も設定。下書き状態で全文提示』。有効化(配信開始)前に佐々木承認。

Klaviyo MCP, スキル(Klaviyoメール編集)

業界ベンチ:自動フローは全配信の約5.3%から発生しつつメール売上の約41%を創出、受信者あたり売上は単発配信の約18倍との報告。ただし成熟ストアの合わせ技の数字で、立ち上げ期はリストが小さく絶対額は小さい。相場は約束せず、フロー有効化後に自ストアのget_flow_reportで実測する。

スキル『Klaviyoメール編集』で件名を5案生成→Klaviyo側でA/Bテスト設定。指示例『この配信の件名を、絵文字なし・煽らない・当事者目線で5案。各案の狙い(好奇心/便益/希少性)を併記』。Smart Send Timeは配信設定で有効化。結果はget_campaign_reportで回収し勝ちパターンを蓄積。

Klaviyo MCP, スキル(Klaviyoメール編集)

ベンダー公表値ではAI件名で開封率10-25%改善、Smart Send Timeで5-12%改善の報告があるが、いずれも母数・実装依存で数値の裏取りは弱い。定量は必ず自ストアのA/Bで確定させる（他社数値は仮説にとどめる）。

scheduled task（定期実行）で毎週、Shopify MCP(run-analytics-query)＋Klaviyo MCP(get_campaign_report/query_metric_aggregates)から数値取得→レポート出力ルール.mdのHTMLテンプレ(レポートテンプレート_v1.html)を複製して生成→Notion『調査レポート』DBへ格納。指示例『毎週月曜9時、先週の売上/注文数/流入/メール指標を集計し週次レポートを作成、10_会社・戦略に保存』。同じデータでdatavizスキルの配色に沿った1枚HTMLダッシュボード（日別売上・チャネル別流入・フロー別売上、ダーク/ライト両対応）も生成し定期でデータ差し替え。

Shopify MCP, Klaviyo MCP, Notion MCP, scheduled task, dataviz スキル, レポートテンプレ

Anthropic内部データではタスク単位で典型的に約80%時間短縮、ユーザー平均で週3.6h節約(45%が生産性向上を実感)。SMB全体ベンチでも平均週5.6h節約。集計・整形は最も短縮が効く領域。ダッシュボード内製は売上効果ではなく意思決定速度への寄与（Anthropic社内でも一部チームがClaude Code用途の7%超をデータ可視化フロント開発に充当）。

Shopify MCPで対象抽出→graphql_query/mutationやupdate-productで修正。指示例『custom.product_categoryが空or規定外値の商品を全件抽出し、wk_custom_fieldとvendorから正しいカテゴリを推定して下書き修正リスト(CSV)を作成。承認後にまとめて反映』。実測データモデル(mekkemon-shopify-data-model)を前提として渡す（wk_custom_field=テーマ表示・custom.product_category=振り分け・vendor=企業紐付け・タグは3語のみ）。

Shopify MCP(GraphQL), サブエージェント, ファイル出力

Anthropic社内では、あるエンジニアがClaudeを自律稼働させ800件超の修正を投入しエラー率を大幅低減、人手なら数年相当と試算した事例が公表されている（個別事例・EC文脈での再現性は別途要検証）。大量の定型データ修正はこの型にはまりやすい。

Gmail MCP(search_threads/get_message)で問い合わせ取得→Shopify MCP(get-order/list-orders)で該当注文を照会→create_draftで返信下書き作成。指示例『未返信の配送問い合わせを抽出し、注文番号から発送状況を照会して表現ルールに沿った返信ドラフトを作成。送信はしない』。

Gmail MCP, Shopify MCP, ドラフト作成

業界ベンチ:AI対応は1件$0.5-2.0、人手は$6-13.5、ECでの解決率70-84%、導入60日で55-65%のチケット自動化との報告。ただしいずれも海外・一定規模前提のベンダー数値で、立ち上げ期の日本語ニッチでは絶対額は小さい。まずは下書き工程の短縮に絞る。

工数実測シート(業務ルール6章)にClaudeがやった作業時間を都度記録（訪問・電話分は伴走中に数日〜1週間間隔で聞いて代記録、絶対ルール4-b）。1施策(例:商品説明生成)を2-4週回し削減工数と品質を数値化してから次へ。MTGアジェンダ下書きシートに、施策ごとの想定効果を“出典ベンチ＋自社での検証予定”の形で記載し、定量が無い施策は「定量データなし・要自社検証」と明記。現行方針.mdの未決定の争点と1対1で対応させる。

ファイル操作(工数実測シート/改善ログ/MTGアジェンダ下書き), 現行方針.md, スキル

MITのProject NANDA調査(2025):GenAIパイロットの約95%が測定可能な財務リターン未達、失敗要因は技術でなく業務との不整合。一方SMBベンチではAI利用小規模事業の59.2%が週1-6時間、平均5.6h/週を節約、日本企業の生成AI利用は34.6%だが日本のSMEはスキル不足・情報精度への懸念を障壁に挙げる比率が高い。“週数時間節約が現実、魔法ではない”という等身大の期待設定が定着の条件。

既存のCLAUDE.md・表現ルール・レポート出力ルール・実測データモデルを各業務のSKILL.mdに要約して埋め込む。繰り返す業務は.claude/skills/<業務名>/に手順書化（データ源・判断基準・承認ゲートを明記）。skill-creatorスキルで雛形作成。

スキル(SKILL.md), CLAUDE.md, skill-creator

Anthropicの分析では、ドメイン専門家がレビューしたセッションの検証済み成功率が28-33%だったのに対し初心者セッションは約15%と、前提の質が成果を約2倍分けたと報告。良い前提文書はそのまま“当たり率”に効く。

Shopify MCPで商品のmetafield/構造化データを整備。指示例『全商品にproduct schema用メタフィールド(原産地・内容量・保存温度帯・アレルゲン)を定義し、欠損を洗い出して下書き補完リスト(CSV)を作成。承認後に反映』。AIが引用しやすいFAQ・詳細記述も同時整備。

Shopify MCP(GraphQL/metafields), サブエージェント, ファイル出力

Shopify自社発表では2026年Q1にAI経由の店舗流入が前年比8倍、AI検索経由の注文が約13倍、AI経由新規購入者は他チャネルの約2倍のレートで注文とされる。ただしいずれもShopify全体・海外中心の自社データで、日本語ニッチの産直モールでの実効性は未知数。効果を約束せず低コスト整備にとどめる。

.claude/settings.json の permissions に3層で記述。allow=読み取り（Shopify mcp__<shopify>__get-*／list-orders／list-customers／search_products／run-analytics-query／graphql_query、Klaviyo mcp__<klaviyo>__get_*／query_*、Notion notion-fetch/notion-search、Drive read_file_content/search_files）。ask=外部影響（Shopify graphql_mutation／set-inventory／update-product／create-discount／bulk-update-product-status、Klaviyo send_campaign／create_coupon、Slack slack_send_message）。deny=絶対禁止（Read(**/.env)／Read(**/ID&Pass*)／rm -rf 等の破壊的Bash）。評価はdeny→ask→allowでdeny最優先。allowのワイルドカードは『mcp__<server>__』というliteral接頭辞の後だけ有効で mcp__github__get_* のように書ける（裸の*やmcp__*のallowは警告で無視される＝ドキュメント確認済み）。導入を速めるにはバンドルの /fewer-permission-prompts スキルで過去ログから安全な読み取り呼び出しを抽出させてallowへ追記する。

Claude Code permissions（.claude/settings.json）／fewer-permission-prompts skill／Shopify・Klaviyo・Slack・Notion・Drive の各MCP

承認忘れによる本番誤反映・誤送信の事故確率を下げる。承認ゲートを『人の注意』から『システムの強制』へ移せるのが本質。回数削減・事故率の定量出典はない。

SKILL.md frontmatter に disable-model-invocation: true を付けるとClaudeが空気を読んで勝手に実行しなくなる（既存の『Shopify商品登録』『Klaviyoメール編集』スキルに即追加が効く）。argument-hint で必要な引数を明示し、本文では $ARGUMENTS（引数全体）や $0/$1（位置引数。0始まりなので$0が第1引数）で受ける。同じfrontmatterの allowed-tools にそのスキルが使う読み取りツールだけを列挙（例 allowed-tools: mcp__<shopify>__get-product mcp__<shopify>__search_products Read Grep）、書き込みツールはあえて入れず実行時にpermissionsのaskへ落とす。背景ループから AskUserQuestion 等を外したいときは disallowed-tools を使う。

Claude Code skills（.claude/skills/*/SKILL.md の disable-model-invocation / allowed-tools / disallowed-tools / argument-hint）

『コードが完成して見えるからデプロイした』的な勝手実行を構造的に防ぎ、1スキル内で読み取り即・書き込み承認の段差を作れる。公式が/deploy等の副作用系に推奨する設計。

.claude/agents/ に役割別サブエージェント（competitor-research／seo-audit／report-drafter 等）をMarkdown+YAML frontmatterで定義（/agents コマンドで対話生成可）。descriptionは能力ではなく『いつ委譲するか』の条件で書くとルーティング精度が上がる（例『産直モールの競合価格を横断調査するとき』）。frontmatterの tools で許可ツールを明示列挙し、書き込み系MCP（graphql_mutation, set-inventory, send_campaign, slack_send_message, create_draft）を含めない。各サブエージェントは独自のsystem prompt・ツール・モデルを持てるので『調査係＝読み取りのみ』『下書き係＝Drive/Notion書き込みまで、送信はしない』と階層化する。既存の deep-research スキルは内部でファンアウト検索するのでそのまま使える。

Claude Code subagents（.claude/agents/、frontmatter tools/model）／/agentsコマンド／deep-research skill

文脈分離＋並列化で長い調査をメイン会話を止めずに回せ、渡すツールを絞れば人が全子タスクを見張らなくても外部影響を封じられる。定量出典なし。

.claude/settings.json の hooks に PreToolUse を設定。stdinのJSON（tool_name, tool_input.file_path / tool_input.command）を検査するスクリプトを噛ませ、(A)セキュリティ＝.envやID&PassへのRead/Edit、rm -rf・curl|bash・削除系を検知したら exit code 2 で停止（stderrがClaudeに返る）。(B)保存先＝Write/Editのfile_pathが共有フォルダの番号フォルダ外（デスクトップ等）や命名規則YYYYMMDD_内容_vNに反する新規作成を検知したら警告。PreToolUseフックはbypassPermissionsモードでも発火する決定論的ブロック層で、公式も『Claudeの判断に関係なくブロックしたいならPreToolUseフックを使え』と明記している。

Claude Code hooks（PreToolUse, settings.json）

機密保護・削除禁止・保存先という運用ルールを『注意』から『機械的ブロック』へ格上げし、フォルダ運用の一貫性を維持する。

Desktop scheduled task（ローカルのMCP・スキル・ファイルにフルアクセスできる恒久タスク）を作り、cron 3 9 * * 1（月曜9時台）などで起動。プロンプトは『Shopifyの run-analytics-query で先週の売上/注文を取り、Klaviyoの get_campaign_report/get_flow_report を集計し、レポート出力ルールのHTMLテンプレートで定例レポートを作り10_会社・戦略に保存、要約を slack_send_message_draft でCOOに下書き提示』。恒久運用にはDesktop task（マシン起動が要る／ローカルファイル可）かCloudルーティン(Routines)（マシン不要／ローカルファイル不可・最短1時間間隔）を用途で選ぶ。セッション内の /loop・CronCreate は7日で失効しセッションを閉じると止まるので恒久運用には向かない。

Desktop scheduled tasks／Cloudルーティン(Routines)／CronCreate・CronList・CronDelete／Shopify MCP analytics／Klaviyo reports／Slack MCP（draft）

定例レポート作成の手作業を毎週削減。Desktopタスクは各実行でファイル・MCP・スキルにフルアクセスできる。立ち上げ期はデータ量が小さく中身は薄いが、基盤として先に敷いておく価値がある。定量出典なし。

1プロンプトまたはスキル化して連結：Shopify get-inventory-levels で在庫僅少/売れ筋を検出 → Klaviyoで対象セグメント確認(get_segments) → create_coupon＋create_coupon_code でクーポン生成（発行のみ・配信しない） → 施策サマリを slack_send_message_draft でCOOに提示。実配信(send_campaign)・実投稿(slack_send_message)・スケジュール送信(slack_schedule_message)は必ず人の承認後。定型化したら .claude/skills/ にスキル化して /weekly-promo で起動。

Shopify MCP（inventory）／Klaviyo MCP（segment, coupon, campaign）／Slack MCP（draft）

販促の企画→準備までを自動化し人は意思決定に集中できる。実売上効果は施策依存で保証なし・定量出典なし。

送信・公開の各MCPで『止まる版』を標準化：Gmailは create_draft（そもそも送信ツールが無く下書きのみ＝安全）、Slackは slack_send_message_draft、Klaviyoは create_campaign_clone＋update_campaign（send_campaignは人）、Shopify商品はDRAFTステータスで作成。CLAUDE.mdの承認不要リストには『下書き作成まで』を、承認ゲートには『実送信・実公開・予約送信』を対応づけて明記する。

Gmail MCP（create_draft）／Slack MCP（draft）／Klaviyo MCP（campaign clone）／Shopify MCP（product draft status）

ブランド毀損・誤送信リスクを負わずに準備工数だけ自動化でき、承認の粒度を『実行の直前』に統一できる。

ルートCLAUDE.mdは200行目安・事実と原則だけに保つ（公式が200行超で遵守率低下と明記）。承認不要リストや各業務手順は .claude/skills/ へ（スキル本文は使うときだけロードされ普段はコンテキストを消費しない）。共通参照は @path/to/file でimport（相対/絶対可・最大4ホップ、launch時に展開ロード）。特定フォルダだけに効かせたいルールは paths frontmatter付きの .claude/rules/*.md に分離すると、そのパスのファイルを触ったときだけロードされる。現在ロード中のCLAUDE.md/ルールは /memory と /context で確認できる。

Claude Code memory（CLAUDE.md, @import, .claude/rules, /memory, /context）／skills

長いCLAUDE.mdはコンテキストを食い遵守率を下げる。薄いルート＋オンデマンドの手順書/ルールが公式推奨。

接続前に提供元・セキュリティ方針・利用規約を確認（外部コンテンツを取得するMCPはプロンプトインジェクションの経路になり得る）。接続後は即settings.jsonで当該サーバの書き込み系をask/denyに落とし読み取りだけallow。認証情報は環境変数経由で渡し共有フォルダに平文で置かない（CLAUDE.md絶対ルール2と一致）。この手順を .claude/skills/mcp-onboarding/SKILL.md 化して毎回同じチェックを回す。

Claude Code MCP設定（.mcp.json / settings.json）／permissions／skills

未検証サーバの接続によるデータ流出・インジェクション事故を予防。公式は『信頼するサーバのみ接続』を明記。