検証報告 ｜ 2026.08.04
もらった検証ポイントへの回答と、構成比較の結論、AI を組み込んだ運用の設計案。
結論
Shopify ネイティブ(テーマ)で立ち上げるのが正しい。ヘッドレスは、体験が売上に効くと確証が出た企画への段階投資に取っておく。
決め手は checkout でもページ上限でもなく(両構成でほぼ共通)、運用レールの構造差。ネイティブは管理画面の運用に「デプロイ」が存在せず即時反映。ヘッドレスは価格すらビルド時点で凍結され、データを変えるたび再ビルドが挟まる。
6 / 8
運用パターンでネイティブ有利
8〜9割
管理画面のみで完結する業務量
半日
軽微修正の最短 起票 → 公開
検証: 2026.08 ─ 公式一次情報 + ヘッドレス実装デモ(実働 4 日)の実測に基づく
先に短答。「＋補足」を開くと根拠が読める。
デザイン → Shopify 反映・AI 連携・git 管理
公式の GitHub 連携は使わない。CLI + CI(GitHub Actions)の自組みが定石。AI は公式の AI Toolkit が揃っている。運用の全体像は 3〜4 章。
GitHub 連携は双方向同期で、管理画面での編集がブランチへ自動コミットされ、これを無効化できない(公式明記)。設定ファイルだけ同期から外すこともできない。「コード = git 正本 / コンテンツ設定 = ストア正本」の分離を作るなら CLI + CI ルート一択。AI Toolkit は Claude Code 等のプラグインとして動き、Liquid の検証と公式ドキュメント参照をエージェント自身にやらせられる。
Shopify のページ上限
商品数は無制限(全プラン)・バリアント 2,048・商品ページは自動生成。出版社のカタログ規模なら無風。
実務で効く天井は「一覧のページ送りが通算 25,000 件まで」など表示側の制約。数百〜数千点では当たらない。
ヘッドレス(API のみ実装)の pros/cons
性能と自由度は本物。ただし運用の全作業に「再ビルド」が挟まる構造コストが重い。結論は 2 章。
デモの実測では LCP 0.14〜0.17 秒・閲覧時の API 呼び出しゼロを達成できた一方、「API が成功(200)を返しながら中身が失敗している」系の罠(配送設定不備でカートが全部 0 点に丸まる等)への防御実装を全部自前で書くことになった。Shopify 公式自身がヘッドレスの妥当ラインを「月商 3,000 万円以上・体験差別化が軸」と整理している。
負荷・同時接続
心配不要。Shopify 基盤はブラックフライデー 2025 でピーク毎分 4.89 億リクエストを処理(公式 IR)。
人気作品のピーク程度は問題にならない。なお個別ストア向けの SLA 数値は非公表なので、そこは「実績ベースの信頼」になる。
作品・画像が増えたときのメンテ
metaobjects(独自コンテンツ機能)で雑誌・作品をモデリングすれば、作品追加は管理画面で完結し、作品ページも自動公開される。
「作品」をコンテンツ型として定義し、商品から参照する構造。作品を 1 件登録するとページが生えて、コード変更・デプロイは不要になる。
製作会社への発注書(メール / PDF)
構成選定と無関係に解ける。注文データは Shopify にあるので、Admin API + 小さな自動化で PDF 生成・メール送信を実装。
都度発注でも週次まとめでも同じ仕組みで対応可能。どの構成を選んでもこの部分の実装は変わらないので、独立に検討できる。
発注をまとめて枚数割引を効かせる
週次で注文を集計してまとめ発注書を作る形が素直。締め日・分割条件はロジック側の設計だけの話。
「1〜2 週間分をまとめて送る」は注文データの集計条件にすぎないので、運用 2 の仕組みに締め処理を足すだけで成立する。
クラファン型(N 枚集まったら生産)
予約販売・クラファン系の既製アプリの選定勝負。アプリの枠を超えた体験を求めるなら Shopify の外の議論になる。
jump-lab がフルスクラッチなのはこれが理由だと理解している(実測でも Shopify 不使用・自前実装だった)。マクアケ級の体験を事業の柱にするかどうかの判断が先で、決めるならそれは構成選定ではなく開発体制への投資判断。
ネイティブは「管理画面での運用」にデプロイという概念がない。ヘッドレスは、データを変えるたびに再ビルドのパイプラインが挟まる。
商品追加・価格変更・設定内のデザイン調整が即時反映されるのがネイティブ。ヘッドレスは価格すらビルド時点で凍結される ── デモを 4 日運用しただけでも、この管理が一番の運用負担だった。
既存作品への商品追加週次〜日次
管理画面 5〜10 分で完結 vs 毎回再ビルド
新作品のグッズ一式追加月次
運用担当が即日完結 vs コード変更が必ず挟まる
設定内のデザイン変更週次
テーマエディタで即時 vs 軽微でも PR 1 周
セール・価格改定月次
即時反映 vs 再ビルド(開始時刻の厳守が苦手)
設定を超えるデザイン変更月次
型検査・自動テストの層が厚く、AI が自走しやすい
大型の新機能四半期
既製アプリで済むなら N 圧勝 / 自作なら H
障害対応(データ起因)随時
管理画面の修正で即終息 vs 再ビルド 1 周
プラットフォーム追従年次
ほぼ Shopify 任せ vs 年 1 の API 棚卸し
すべての依頼をトリアージ(振り分け)で 2 本のレールに分ける。これが運用設計の心臓。
管理画面で即日完結。デプロイなし。
統制: 管理画面の権限を役割で絞る + 設定変更を定期的にリポジトリへ写して監査ログ化
ポイントは、テーマ側の「設定項目」を上手に設計するほどデザイン変更が運用レール側に移り、開発なしで回る範囲が広がること。テーマ開発の半分は「運用担当が触れるダッシュボードの設計」だと捉えている。
インプットの受け方・AI への任せ方・品質保証の 3 点で設計し、人の関与は「起票・設計合意・承認」の 3 箇所だけに絞る。
品質保証パイプラインPR 作成 → 本番反映
1機械検査
Liquid / JSON の静的解析(Theme Check)+ 性能回帰(Lighthouse CI)+ 秘密情報の混入検査 + デザイン規約の契約検査
2AI レビュー
実装した AI とは別の、文脈を持たない AI が受け入れ条件と照合。作った本人に検品させないのと同じ理屈で、毎回見逃しを拾う
3人間レビュー
CI が PR ごとにプレビュー用テーマを自動生成して URL をコメント。リードは実物を見て判断(コード全読は不要)。デザイン案件はデザイナー本人の目視照合を含める
4公開
マージで確認用テーマへ自動反映 → 本番反映だけは人が承認して実行。「公開のタイミングは人が決める」は AI 活用でも変えない
5ロールバック
直前のテーマを保持しておき、問題があれば publish 切替で即復旧
イメージ: 軽微なデザイン修正の流れ起票から公開まで
10 分人
運用担当がチケット起票(受け入れ条件 2 個 + 現状スクショ)
数分人
リードが振り分け(設定で吸えるか確認 → 開発レールへ)
数十分AI
AI が実装 → 検査を通して PR 作成
自動CI
プレビューテーマ生成 + 機械検査 + AI レビュー
10 分人
リードがプレビューを実機で確認して承認・マージ
数分人
確認用テーマでチェック → 本番反映を承認
人の稼働AI / CI が自動で走る
起票から公開まで 最短半日 ・人の稼働は 30 分弱 (見立て)
ここまではまだ設計図。次はテスト環境で実際に 1 周流し、所要時間と AI の自走度を実測する。
テスト環境に「デザイン → AI 実装 → PR → プレビュー → 検査 + レビュー → 公開」を実際に構築して 1 周流し、所要時間と AI の自走度を実測する。表じゃなくて、動いているループを見せる。
商品追加は週何回くらいか、デザイン変更は誰がどのくらいやりたいか。2 章 の比較の重み付けがこれで決まる。案件の解像度が上がったタイミングで大丈夫。