Shopify AI分析システム実装ガイド【2026年版】— 売上/在庫/顧客/商品/総合の5分析プロンプト×LLM統合の本番アーキテクチャ | 記事

Shopify AI分析システムとは、ShopifyストアのデータをLLMで分析し、売上・在庫・顧客・商品の観点から具体的なアクションプランを自動生成する仕組みである。2026年現在、Shopify Sidekickなどの公式AI機能が普及しているが、本格的な業務ではカスタム分析システムを自社実装するニーズが高まっている。本記事では、renueが自社プロダクトとして実装している`ShopifyAIAnalyzer`クラスをもとに、5種類の分析プロンプト設計と本番実装パターンを解説する。

Shopify AI分析システムの5つの分析タイプ

本番品質の分析システムは、単一のプロンプトで全てを処理するのではなく、目的別に5つの専用プロンプトを持つべきである。renueの実装では以下の5種類を定義している。

分析タイプ	データソース	主な用途
1. 売上分析	注文・返金データ	トレンド把握、平均注文額改善
2. 在庫分析	商品・在庫データ	在庫切れ/過剰在庫の検出
3. 顧客分析	顧客・注文履歴	リピーター獲得、セグメンテーション
4. 商品分析	商品パフォーマンス	ベストセラー特定、クロスセル設計
5. 総合レポート	上記全データ	ビジネス全体の戦略提案

本番品質のShopify AI分析に必要な5レイヤー

レイヤー1: 統一されたSystem Prompt設計

全ての分析タイプで共通のSystem Promptを使うことで、出力形式とトーンを統一する。renueの実装では以下のフォーマットを採用している。

ANALYSIS_SYSTEM_PROMPT = '''あなたはECストア分析の専門家です。
Shopifyストアのデータを分析し、実用的なインサイトと具体的なアクションプランを提供してください。

回答は以下の形式で日本語で提供してください:
1. 📊 概要サマリー(3-5行)
2. 💡 重要なインサイト(箇条書き3-5個)
3. ⚠️ 注意すべき問題点(あれば)
4. ✅ 推奨アクション(優先度順に3-5個)
5. 📈 改善の機会

具体的な数値を引用し、実行可能な提案を心がけてください。'''

絵文字を使う設計意図

視認性向上: ダッシュボードで項目が一瞬で識別できる
構造の強制: LLMが決まった順序で出力するよう誘導
日本語対応: 絵文字は言語を問わず通じる
ユーザー体験: テキストの羅列より読みやすい

「3-5個」という幅を持たせる理由

「必ず5個」と指定すると、LLMが無理やり項目を埋めて品質が下がる。「3-5個」と幅を持たせることで、本当に重要なインサイトのみを抽出させる。この運用上の工夫が本番品質に直結する。

レイヤー2: 5種類の専用プロンプト

売上分析プロンプト

SALES_ANALYSIS_PROMPT = '''以下のShopify売上データを分析してください:

{data}

特に以下の点に注目してください:
- 売上トレンド
- 平均注文額の妥当性
- 返金率
- 日別の売上パターン'''

売上分析では「トレンド」「平均注文額」「返金率」「日別パターン」の4つの観点を指定する。これらは売上レポートの主要KPIであり、どれか一つだけでは不十分である。

在庫分析プロンプト

INVENTORY_ANALYSIS_PROMPT = '''以下のShopify在庫データを分析してください:

{data}

特に以下の点に注目してください:
- 在庫切れのリスク
- 過剰在庫の可能性
- 補充が必要な商品
- 在庫回転率の改善機会'''

在庫分析では「切れ」と「過剰」の両方を見ることが重要である。片方だけだと機会損失または過剰コストを見逃す。

顧客分析プロンプト

CUSTOMER_ANALYSIS_PROMPT = '''以下のShopify顧客データを分析してください:

{data}

特に以下の点に注目してください:
- 顧客維持率
- リピーター獲得の機会
- 上位顧客へのアプローチ
- 顧客セグメンテーションの提案'''

商品分析プロンプト

PRODUCT_ANALYSIS_PROMPT = '''以下のShopify商品パフォーマンスデータを分析してください:

{data}

特に以下の点に注目してください:
- ベストセラー商品の特徴
- 売れ行きの悪い商品への対策
- クロスセル・アップセルの機会
- 商品ラインナップの最適化'''

総合レポートプロンプト

FULL_REPORT_PROMPT = '''以下のShopifyストアの総合データを分析してください:

{data}

ビジネス全体の観点から、最も重要な発見と優先すべきアクションを提案してください。
売上、在庫、顧客の相互関係にも注目してください。'''

総合レポートでは「相互関係」を強調することがポイント。単一項目ではなく、売上×在庫、顧客×商品、在庫×顧客のような**関連性**を見つけるよう指示する。

レイヤー3: LLM呼び出しの設計

LLM呼び出しはシンプルだが、パラメータ設定が重要である。

def _call_llm(self, system_prompt, user_prompt):
    try:
        response = completion(
            model=resolve_litellm_model(self.model),
            messages=[
                {"role": "system", "content": system_prompt},
                {"role": "user", "content": user_prompt},
            ],
            temperature=0.7,
            max_tokens=2000,
        )
        return response.choices[0].message.content
    except Exception as e:
        logger.error("LLM call failed: %s", e)
        return f"分析の生成中にエラーが発生しました: {str(e)}"

temperature 0.7 の設計理由

temperature 0.0: 決定的だが創造性に欠ける(同じ入力で毎回同じ回答)
temperature 0.7(採用): 実用的な分析+多様なインサイト
temperature 1.0以上: 創造的すぎて実務に使えない

分析タスクでは「事実に基づきつつ、発想を広げる」バランスが重要。0.7は多くのLLMでこのバランスが最も良いとされる値である。

max_tokens 2000 の設計理由

概要サマリー(3-5行) + インサイト5個 + 問題点 + アクション5個 + 改善機会 = 約1500〜1800 tokens
2000で余裕を持たせつつ、過度に長くならないよう制限
コスト予測も立てやすい

レイヤー4: データ前処理(ShopifyAnalytics統合)

LLMに生データを直接渡すと、トークン消費が膨大になり品質も下がる。renueの実装では`ShopifyAnalytics`クラスでデータを前処理してからLLMに渡す。

前処理の典型パターン

集計: 1000件の注文 → 日別集計に変換
ランキング: 全商品 → 売上上位10商品+下位10商品
統計量: 生データ → 平均・中央値・標準偏差
差分: 期間比較(前月比/前年比)
セグメント化: 顧客を購入頻度別にグループ化

前処理のメリット

トークン節約: 100,000件のデータを数KBのJSONに圧縮
分析精度向上: LLMが理解しやすい構造化データ
コスト削減: API利用料を大幅に節約
レスポンス速度: 処理時間が短縮

レイヤー5: LiteLLMによるモデル抽象化

renueの実装ではLiteLLMライブラリを使ってLLMプロバイダーを抽象化している。これにより以下が可能になる。

Claude / GPT / Gemini を1行で切り替え
APIキーが切れたら別プロバイダーに自動フォールバック
タスクの性質に応じたモデル選択(精度 vs コスト)
複数モデルの結果を比較してベストを選ぶ

デフォルトモデルの選定

renueの実装では`claude-haiku-4-5`をデフォルトにしている。理由は以下の通り。

コスパ: Claude Opusの1/5のコストで十分な品質
速度: レスポンスが高速で運用に耐える
日本語対応: Claudeシリーズは日本語分析が得意
構造化出力: プロンプト指示への追従性が高い

環境変数の自動ロード

renueの実装では`.env.local`を自動ロードする工夫をしている。

from dotenv import load_dotenv
from pathlib import Path

env_path = Path(__file__).parent.parent.parent.parent / ".env.local"
if env_path.exists():
    load_dotenv(env_path, override=True)

自動ロードの設計理由

LiteLLMはAPIキーを`os.environ`から直接読む
モジュールimport時に環境変数が設定されている必要がある
`.env.local`の相対パスを絶対パスに変換してロード
ファイルが存在しない場合は無視(本番環境はシステム環境変数を使用)

エラーハンドリングの設計

LLM呼び出しは高確率で失敗する(レート制限、ネットワークエラー、モデル障害等)。renueの実装ではエラーをユーザーフレンドリーなメッセージに変換する。

try:
    response = completion(...)
    return response.choices[0].message.content
except Exception as e:
    logger.error("LLM call failed: %s", e)
    return f"分析の生成中にエラーが発生しました: {str(e)}"

エラーハンドリングのポイント

例外を握りつぶさない: 必ずログに記録
ユーザーには親切なメッセージ: スタックトレースは隠す
呼び出し側で再試行判断: 返り値は常に文字列

分析結果の構造化レスポンス

LLMから返ってくる結果はテキストだが、これを構造化してフロントエンドに返す。

def analyze_sales(self, days=30):
    data = self.analytics.get_sales_data(days=days)
    prompt = SALES_ANALYSIS_PROMPT.format(data=json.dumps(data, ensure_ascii=False, indent=2))
    analysis = self._call_llm(ANALYSIS_SYSTEM_PROMPT, prompt)
    return {
        "type": "sales_analysis",
        "period_days": days,
        "raw_data": data,
        "ai_analysis": analysis,
        "generated_at": datetime.now().isoformat(),
    }

レスポンス構造の設計

type: 分析の種類(フィルタリング用)
period_days: 分析期間
raw_data: 元データ(再計算用)
ai_analysis: LLM生成テキスト
generated_at: 生成日時(キャッシュ判定用)

キャッシュ戦略

同じ分析を何度も実行するとコストが膨らむ。renueの実装ではRedisキャッシュを推奨している。

キャッシュキーの設計

分析タイプ(sales/inventory/customer/product/full)
分析期間(days)
ストアID
モデル名

キャッシュTTLの目安

売上分析: 1時間(日内変動大)
在庫分析: 15分(リアルタイム性重要)
顧客分析: 6時間(変動小)
商品分析: 1時間
総合レポート: 3時間

renueの実装特徴

renueは「Self-DX First」の方針のもと、Shopify AI分析機能を自社プロダクトとして実装している。社内12業務を553のAIツールで自動化済み(2026年1月時点)であり、Shopify連携もEC運用の一機能として組み込まれている(全て公開情報)。

技術スタック

言語: Python 3.11
LLMクライアント: LiteLLM(プロバイダー抽象化)
デフォルトモデル: claude-haiku-4-5
temperature: 0.7
max_tokens: 2000
データ前処理: ShopifyAnalytics
API統合: ShopifyClient

業界別の活用パターン

業界	重視すべき分析
D2C商品	商品分析・顧客分析(LTV重視)
アパレル	在庫分析・商品分析(シーズン性)
食品・サプリ	売上分析・顧客分析(リピート重要)
家電・家具	商品分析・顧客分析(高単価)
化粧品	顧客分析・商品分析(ブランド戦略)
ギフト	売上分析・在庫分析(イベント連動)

Shopify Sidekickとの比較

Shopify公式のSidekickは基本的な分析を自動化してくれるが、以下の点で自社実装のメリットがある。

項目	Shopify Sidekick	自社実装
カスタム分析観点	固定	自由
出力フォーマット	固定	自由
他システム統合	限定的	柔軟
LLMモデル選択	不可	自由
コスト	Shopifyプラン内	LLM API従量
データ所有	Shopify側	自社

導入時のよくある失敗パターン

1つのプロンプトで全分析: 品質が下がり、アクションが曖昧になる
生データを直接LLMに渡す: トークンコスト爆発、精度低下
temperature 0で実行: 毎回同じ回答で飽きられる
エラー時にスタックトレース表示: ユーザーが混乱
キャッシュなし: コストが予算超過
絵文字や構造化なし: 読みづらい長文になる
固定項目数を強制: 無理な項目埋めで品質低下

Shopify以外への応用

この設計パターンはShopifyに限らず、他のECプラットフォームにも応用可能である。

BASE / STORES: 国内ECカート
EC-CUBE: オープンソース
Magento: 大規模EC
WooCommerce: WordPress系
楽天 / Amazon: モール型(API制約に注意)

共通するのは「データ取得 → 前処理 → プロンプト選択 → LLM呼び出し → 構造化レスポンス」という5段階パイプライン。この設計は再利用可能である。

よくある質問

LLMのコストはどれくらい?

claude-haiku-4-5 で1分析あたり数円〜数十円程度。月100分析で月額数百円〜数千円。キャッシュを効かせれば大幅に削減できる。

分析の精度は?

前処理されたデータと明確なプロンプトを組み合わせれば、人間のアナリストに近い品質が得られる。ただし最終判断は人間が行うべき。AIは「気づきを提供する」位置づけに留める。

データを外部LLMに送るのは大丈夫?

売上データ・顧客データには個人情報が含まれる場合がある。Enterprise契約のLLMなら学習に使われない保証があるが、個人情報は必ず匿名化してから送信する。renueの実装では顧客メールアドレス等を前処理でマスクする設計が推奨される。

リアルタイム分析は可能?

Shopify APIのWebhookと組み合わせれば、注文発生時にリアルタイム分析を実行できる。ただし頻度が高すぎるとコストとAPIレート制限に引っかかるため、1時間単位のバッチ実行が現実的。

導入後に最も改善するKPIは?

「分析レポート作成時間」が最も劇的に改善する(数時間 → 数分)。次いで「在庫切れ検出までの時間」「顧客セグメンテーションの粒度」「クロスセル機会の発見数」が改善する。