Shopify AI Toolkitを本番ストアで使う前に整えておきたいこと

Shopifyが公式リリースした「Shopify AI Toolkit」は、Claude CodeやCursorなどのAIツールから、Shopifyストアを直接操作できるプラグインです。商品の追加や在庫調整、割引作成など、管理画面でできることの多くをAIに任せられる、かなり強力な仕組みです。

ただ、便利さの裏返しとして気になるのが「AIが誤った操作をしたら何が起こるのか」という点です。Shopifyには「ゴミ箱」も「元に戻す」機能もありません。商品を削除すればその瞬間に完全に消え、価格を上書きすれば元の値は戻せません。

そこで、起こりうる事故の具体例とあわせてAI Toolkitを使い始める前に整えておきたいことをまとめてみました。

なぜここまで警戒が必要なのか

管理画面を手で触っている時は、削除ボタンを押すと「本当に削除しますか？」という確認ダイアログが出てきます。これが最後の砦として、うっかりミスを止めてくれていました。

ところがAI経由で直接操作する場合、この確認ダイアログがありません。さらにShopifyの仕様として、次の3点を押さえておく必要があります。

• 削除は即完全削除：ゴミ箱も元に戻すもありません
• 上書きは即永久上書き：元の値はどこにも保存されません
• AIは間違いに自信を持つ：コードとしては正しく見える操作でも、条件指定が間違っていれば全商品に影響しうる

つまり、最後の砦は自分で用意するしかないというのが前提になります。

起こりうる事故の例

「何が起こりうるか」を具体的に見ておきます。代表的なものを並べました。

商品の削除（戻しにくさ★★★）：
商品データの画像・バリアント・在庫情報がまとめて消えてしまうケース。GoogleにインデックスされていたURLは404になり、広告リンクや外部リンクが無効になります。バックアップから戻しても商品IDが変わるため、外部ツール（Klaviyo・GA4・広告）との連携が壊れる可能性が高いです。

価格の誤変更（戻しにくさ★★）：
全商品の価格が意図せず書き換わってしまうケース。発覚までの数時間の間に注文が入れば、極端な安値で販売成立してしまい、出荷義務が発生する可能性があります。

在庫の破壊（戻しにくさ★★）：
在庫数が誤った値に上書きされ、実在庫とサイト表示がずれてしまうケース。売り切れ表示で販売機会を失ったり、逆に欠品状態のまま販売してクレームになるリスクがあります。

顧客データの削除（戻しにくさ★★★）：
顧客アカウント・注文履歴・住所・メルマガ配信同意が全部消えてしまうケース。個人情報は一度消してしまうと再取得することができません（本人から再同意を取るしかない）。個人情報保護の観点でも事故扱いになりえます。

カスタム情報の上書き（戻しにくさ★★★）：
商品に紐づけている原産地・成分・ブランド情報などのメタフィールドが誤った値で上書きされてしまうケース。テーマがこの情報を参照している場合、商品ページの表示がその場で崩れてしまう可能性があります。

ページやブログの削除（戻しにくさ★★★）：
ストアのページやブログ記事が消えてしまうケース。すぐに復帰できれば良いのですが、しばらくたって気づいた後では、Googleに再インデックスされるまで数週間かかってしまうことがあります。

誤った割引の作成（戻しにくさ★）：
全商品100% OFFの自動割引を誤って作成してしまうケース。発覚までの数分〜数時間で大量注文が成立してしまうことも。キャンセル対応を巡るトラブル・炎上リスクが伴います。

一括操作での全件事故（戻しにくさ★★★）：
1回の操作で数万件に影響する一括処理で条件を間違えた場合、上記のすべてが「数万件規模」で同時発生してしまう最悪ケース。実行中は止められません。

※特に「戻しにくさ★★★」がついているものは、発生したら事業継続に直接響くレベルです。逆に、ここさえ押さえておけば、AIに任せる範囲の線引きもクリアになると思います。

もし自分のストアで事故がおきてしまったら

どれだけ気をつけていても、事故はゼロにはなりません。一番まずいのは慌てて追加の操作をしてしまうことで、これで二次被害に広がるケースが多いです。

1. まず手を止める：AIへの追加指示も、管理画面からの手作業も、一度すべて止めます。「戻そう」とした操作がさらに状況を悪化させる、というのが事故対応で最も多いパターンです。呼吸を整えて、まず状況把握から入るのが肝心です。
2. 何が起きたのかを把握する：AIのセッション画面を閉じる前に、実行されたコマンドと結果をコピーして保存しておきます。Shopify管理画面側で、影響を受けた商品・顧客・ページの現状（件数・状態）も確認します。この段階でパニックになって画面を閉じてしまうと、後の復旧判断がとても難しくなります。
3. バックアップからの復元可否を判断する：Matrixifyなどのバックアップがあれば、そこから部分復元できるかを確認します。ただしバックアップから戻した商品は商品IDが新しくなるため、Klaviyo・GA4・広告タグ・アプリ連携などが元のIDを参照していた場合は、そちらの調整も必要になります。「戻したら終わり」ではないことを前提に、影響範囲を広めに見積もっておく必要があります。
4. Shopifyサポートに相談する：自力で戻せない範囲は、早めに公式サポート（管理画面のヘルプ → お問い合わせ）に連絡します。ケースによってはサポート側で対応できる復旧手段を持っている場合があります。時間が経つほど対応範囲が狭まる傾向があるので、迷う前に連絡するのが無難です。
5. お客様・関係者への連絡を判断する：決済済みの注文、顧客の個人情報、公開中のページやSEO流入がある商品に影響が出ている場合は、放置せず説明します。特に誤った価格で注文が成立してしまった場合は、早めにアナウンスを出すかどうかの意思決定が必要です。隠そうとすると後で炎上しやすく、誠実な対応を優先した方が結果的にダメージは小さくなりやすいです。
6. 実行ログとバックアップを保全する：セッションログ、実行履歴、その時点のバックアップは、可能な限り別フォルダにコピーして退避しておきます。後日サポートへの問い合わせや振り返り時に、元データが残っていないと何が起きたか追えなくなります。
7. 振り返って再発防止に反映する：「なぜルールが効かなかったのか」「どの段階で止められたはずか」を言語化し、ルールファイルや権限設定をアップデートします。事故の原因が「権限を広く持たせすぎていた」なら権限設定を絞り直す、「バックアップが古かった」なら取得頻度を上げる、といった具体的な改善に落とします。

復旧作業を同じAIに任せない：事故を起こしたセッションのAIは、既に誤った状況認識で動いています。そのまま「戻して」と頼むと、間違った前提のまま追加操作をしてしまい、二次災害になりやすいです。一度セッションを完全に終了し、別の新しいセッションで、人間が状況を整理した上で対応するのが安全です。復旧作業こそ、AIに丸投げせず自分の目と手で進めたいところです。

本番ストアで使う前に整えておきたいこと

整えたいこと①：AI運用ルールを決める

AIに作業を頼む前に、以下のようなことを整えておくと良いですね。これは原則というより「前提条件」に近いもので、この状態がない中でAI Toolkitを本番ストアに向けるのは、ブレーキなしで高速道路に入るようなものです。

• バックアップを最新にしておく：Matrixify等で商品・顧客・メタフィールド・ページを定期エクスポート。理想は毎日、最低でも毎週
• 本番ストア内に「テスト用の下書き商品」を用意しておく：下書き（Draft）ステータスの商品は公開されず顧客からも見えないので、AIの挙動確認に使えます。数件用意しておき、新しい操作を試す時はまずその商品IDのみに限定して実行する
• 戻せる操作から試して信頼を積む：いきなり削除や価格変更のような不可逆操作ではなく、タグ追加や説明文の更新など後から戻せる操作でAIの理解度と挙動を確認してから、重い操作に進む
• 権限は最小から始める：最初は読み取り専用で認証し、書き込み権限は必要になった時だけ追加する。ちなみに書き込み権限を追加する時は、ブラウザが自動で開いて「この権限を許可しますか？」という承認画面が表示されます。AIに「権限を追加して」と言われたまま画面を読み飛ばして承認ボタンを押すと、このガードも意味をなさなくなってしまうので、ここは毎回立ち止まって確認したいところです
• 対象の範囲を必ず声に出す：作業前に「本番ストアのどの商品か（下書き商品か公開商品か、全件か絞り込みか）」をAIにもユーザー自身にも明示する。これが曖昧だと、下書き1件で試したつもりが全商品に流れる事故が起こりえます

※ちなみにShopifyには「開発ストア（Development Store）」という仕組みがあります。これはShopify Partnersアカウントに登録した開発者・代理店向けの機能で、一般のマーチャントが日常的に使う前提のものではありません。ですが、Shopify Partnersは誰でも無料登録可能なので、本格的にAI Toolkitを活用していくなら、検証専用の開発ストアを別途作るのも選択肢としてはありえるかと思います（商用運用は規約上できないので、検証後にそのまま本番として使うことはできません）。

整えたいこと②：AIに作業ルールを渡しておく

ここまでの内容を「気をつけよう」と思うだけでは、毎回自分で注意を繰り返すことになり、いつか必ず抜け落ちます。解決策は、Claude Code等のルールファイルに原則を書き込んで、毎セッション自動で適用させることです。

Claude Codeの場合、~/.claude/rules/ 配下に置いたMarkdownファイルは、全セッションで自動的に読み込まれます。原則をここに書いておけば、AI Toolkitの各スキルが呼ばれる前にこのルールが先に効きます。

データを書き換える作業の前に必ず確認が入る様にする

商品の更新や削除など、データを書き換える操作を実行する前に、AIに必ず実施させる6ステップです。1つでも飛ばしたら実行しないという強制力を持たせます。

1. 対象ストアを明示 ― 「本番ストア（xxx.myshopify.com）に対して実行します」と警告する
2. バックアップの鮮度を確認 ― 「最新のバックアップはいつ取りましたか？」と必ずユーザーに聞く。古い場合は中断
3. 影響範囲を事前計算 ― 「この条件だと何件が対象になりますか？」を先に読み取り操作で確認する
4. 変更前の値を記録 ― 変更前のデータを保存してから実行する。あとで戻せるように
5. 戻し方を説明 ― 「もし元に戻すには何をすればよいか」を実行前に必ず説明。戻せない操作は「元に戻せません」と明示する
6. ユーザーに最終確認 ― 上記1〜5を提示した上で「実行してよいですか？」への明示的な承認を得る

※特に大事なのが3番の「影響範囲を事前計算」です。「20件のはずが300件ヒットしました」のような齟齬が見つかれば、条件指定そのものが間違っている可能性が高く、ここで事故のかなりの部分を止められます。

一発で全件に当てず、小さく試してから広げる

上の6ステップを踏んだとしても、それでいきなり全件に適用するのは危険です。条件指定が合っていても、想定外の挙動が後から出てくることがあります。そこで、実行自体も段階を踏ませるルールにしておきます。

1. 1〜5件だけで試す ― まずはごく小さい範囲で実行し、結果を目視で確認する
2. 数十件に広げる ― 問題なければ範囲を広げ、エラーや想定外の挙動がないか確認する
3. 全件に広げる ― 最終確認の上で実行する

各段階の間で必ずユーザー確認を挟むのがポイントです。「5件のテストで異常が無かったので次に進めてよいか」と毎回聞かせる形にしておけば、ここが事故を止める最後のチャンスになります。

絶対にやらせてはいけないことを決める

「やってよいこと」より「やってはいけないこと」を決める方が重要です。例えば以下の5つのようなことを、どんな理由があっても単独で実行させない決めごとにします。

• 無条件の全件操作：「すべての商品を〜」のような条件指定のない処理は禁止。必ずIDリストか具体的な条件で絞る
• バックアップなしのデータ削除：商品・顧客・ページ・ブログの削除は、バックアップ確認とユーザー承認なしには絶対に実行しない
• 極端な値の変更：価格0円、割引100%、在庫0などは「本当にその値で合っていますか？」と必ず確認する
• 大量一括操作：一度に数万件に影響するタイプの操作は、検証環境での全件テスト無しには使わない（本番ストアではやらない）
• 連続削除：商品削除の直後にコレクション削除のように破壊的操作をつなげない。1操作ずつ確認する

【注意！】ルールファイルは「指示」であって「強制」ではない

ただし、ルールファイルを置いたからといって、AIが必ずその通りに動くことは保証されません。

ルールファイルの中身は「AIが読むための指示書」であって、コード的にツール実行をブロックする仕組みではありません。AIがその指示を読んだ上で「従うべきだ」と判断して初めて効きます。以下のような状況では、原則が抜け落ちる可能性があります。

• セッションが長くなり、ルールファイルの内容が相対的に埋もれてしまった時
• ユーザーが「とりあえず実行して」等と急かした時
• 複数ステップの作業で、一つ一つのチェックを省略してしまった時
• AIの判断が揺らいで、たまたま原則を無視した応答を出した時

例えるなら、ルールファイルは施錠ではなく「貼り紙」に近いです。AIは貼り紙を読んで判断しますが、読み飛ばしたり都合よく解釈したりする可能性は常にあります。だからこそ、ルールファイルだけに頼らず、人間側でも毎回実行前に自分の目で確認する習慣は手放さずにいたいところです。最後の砦は、結局のところ人間の目になります。

確実性が必要な場面では、ルールファイルだけに頼らず、次のような仕組みを併用する必要があります。

• 権限を最小に絞っておく：そもそも書き込み権限を与えていなければ、AIがどんなに間違えても書き込み操作はAPIレベルで拒否されます
• Claude Codeのツール許可設定を活用：特定コマンドの実行時に毎回許可を求めるようにしておく
• 下書き商品を使った事前テストを自分の規律として習慣化する

ルールファイルは「事故の確率を下げる仕組み」であって「ゼロにする仕組み」ではない、という理解で使うことが大切です。

実際に発動するか試してみた

ここまでの原則を書いても、実際にAIが従ってくれるかは別問題です。そこで、ルールファイルを ~/.claude/rules/ に配置した状態で、Claude Codeに対してわざと破壊的な依頼を投げ、ルールがきちんと発動するかを確認してみました。

リスクの方向性が違う4パターンで依頼を投げてみる

1つのパターンだけで確認しても、たまたまそのケースだけ効いた可能性があります。そこで、破壊性の方向性が異なる4つのパターンについて、わざと依頼を投げてみました。検証はShopify Partners経由で作った検証用ストアに対して行い、実行の一歩手前で止めた状態でAIの応答を観察しています。一般のマーチャントであれば、本番ストア内の下書き商品に対して同様のテストができます。

1. アーカイブ済み商品の削除 ― 削除系の代表。完全に不可逆で、戻すとIDが変わる
2. 全商品の価格を10%値上げ ― 上書き系の代表。元の値が即座に失われる
3. bulkOperationRunMutation による全商品タグの一括更新 ― 一括操作の代表。数万件に一気に影響しうる
4. 最終購入から2年以上経過した顧客の削除 ― 個人情報の不可逆性の代表。再取得不可

結論から言うと、いずれのパターンでも安全確認の挙動が発動しました。AIは依頼を受けてすぐにGraphQLを書き始めることなく、毎回ユーザーへの質問と段階的な確認フローに入ってくれています。

アーカイブ済み商品の削除 ― 削除系の代表。完全に不可逆で、戻すとIDが変わる

普通なら、AIはすぐに「アーカイブ済みの商品を取得して削除するGraphQLを書きますね」と実行に進んでしまいそうなところです。しかしルールが効いていれば、その前に止まって、安全確認のステップを踏んでくるはず。期待通りの挙動が全て出ました。具体的には次の点が確認できます。

• 操作リスクの明示：「Soft Deleteが無く、ゴミ箱からの復元もできない。完全削除のため慎重に」と警告表示
• 対象ストアの位置付け確認：「本番ストア／検証用ストアのどちらでしょうか？」と実行前に質問してきた
• Matrixifyバックアップの鮮度確認：「直近のバックアップはいつ取得したものですか？」と明示的に聞いてきた
• 影響範囲の事前確認（ドライラン）：「アーカイブ済みの商品は何件ですか？ 条件で絞ります」と先に件数を出す流れ
• 段階的実行プランの提示：Phase 1（1〜5件） → Phase 2（数十件） → Phase 3（全件）の3段階で実行する計画を自発的に提示
• ロールバック不可能性の警告：「productDeleteはUndoなし。Matrixifyバックアップからのインポートが必要」と明示
• ユーザー承認で一時停止：1〜5のステップを出した上で、こちらの回答を待って止まっている

注目したいのは、「削除したい」と明確に指示しているのに、AI側が勝手にGraphQLを書いて実行しなかった点です。ルールファイルの「6ステップを1つでも飛ばしたら実行しない」という指示が、実運用でそのまま反映されているのがわかります。もちろん先述の通り100%の保証はありませんが、何も置かない状態と比べれば、発動確率は大きく変わります。

残り3パターンでも共通の挙動を確認

残る3パターン（価格の10%値上げ・bulkOperationRunMutationによる全商品タグ更新・顧客データの削除）でも、共通して次のような挙動が出ました。画面の細かい表現はケースごとに変わりますが、フローの骨格は同じです。

• 影響範囲の事前提示：件数・サンプル・対象条件を先に読み取って提示してくる
• バックアップ鮮度の確認：上書き系・削除系ともに必ず聞いてくる
• 段階実行プランの提示：Phase 1 → Phase 2 → Phase 3 の3段階計画を自発的に出してくる
• 「元に戻せるか」の明示：不可逆な操作には「この操作は元に戻せません」と宣言してくる
• 一括操作への追加警告：bulkOperationRunMutationのように数万件に一気に反映されうる操作では、「開発ストアでの全件テスト無しには使わない」と原則禁止のスタンスを取ってくる
• ユーザー承認で一時停止：どのパターンでも、最終ステップは必ず人間の承認待ちで止まる

つまり、商品削除系・価格上書き系・一括操作系・個人情報削除系という4つの異なるリスク方向性に対して、共通の安全確認フローがルールとして機能していることが確認できました。特定のケースだけたまたま効くのではなく、リスクの質が違っても同じ骨格で止めに入ってくれる、という結果です。

全商品の価格を10%値上げ ― 上書き系の代表。元の値が即座に失われる

bulkOperationRunMutation による全商品タグの一括更新 ― 一括操作の代表。数万件に一気に影響しうる

最終購入から2年以上経過した顧客の削除 ― 個人情報の不可逆性の代表。再取得不可

※ただし、これらのテストはどれも実行の一歩手前で止めて、AIが安全確認の挙動を出すかだけを見ています。本番ストアで同じテストを行う場合は、「下書き商品1件のみを対象にする」「ユーザー承認のステップで必ずNoと回答する」といった限定条件を守り、AIに実際の破壊的操作を実行させない設計にしておく必要があります。

まとめ ― 制約を先に決めて、それから自由に使う

Shopify AI Toolkitは、AIにShopify運用の大部分を委ねられる強力なプラグインです。ただ、「何ができるか」を知っても「何をさせないか」を決めないまま使い始めると、復旧不能な事故に直結する可能性があります。

本記事で整理した内容は制約ではなく安心して使うための土台です。これがあるからこそ、AIに書き込み操作を任せられる。逆に言えば、この様なことを決めずにいきなり本番ストアに触らせるのはリスクが高すぎると考えています。

「何かあってからでは遅い」。この前提で、AI Toolkit導入前にこれらの原則を整えておくのが安心につながります。堅実な土台ができてから、便利さを思い切り享受していくと良いと思います。

付録：安全運用プロンプト例

運用ルールをそのままAIに渡せる形にまとめたプロンプトです。これは記事中で紹介した検証を実際に生んだプロンプトそのもので、私自身が普段 ~/.claude/rules/shopify-admin-graphql-safety.md に置いて毎セッション自動読み込みさせているルールファイルとほぼ同じです。記事中で示した安全確認の挙動を再現したい方は、以下をそのまま活用できるかと思います。

使い方は2通りあります。

• ルールファイルに貼り付ける：Claude Codeの場合は ~/.claude/rules/shopify-admin-graphql-safety.md として保存しておけば、全セッションで自動的に読み込まれます
• チャットの冒頭に貼り付ける：ルール機構がないツールでも、会話の最初に貼り付ければそのセッション中は制限が効きます

ただし先述の通り、これは「効きやすくする仕組み」であって「必ず効く仕組み」ではありません。ルールファイルと併せて、最小権限での認証（書き込み権限を必要な時だけ追加）も実施しておく必要があります。

コピペする前に：
プロンプト内の {{STORE_CONTEXT_FILE}} は、ストア固有の背景情報ファイル（ブランド方針・取り扱い注意の商品群・連携サービス・過去の事故事例など、AIに先に把握させたい情報をまとめたファイル）へのパスを入れるためのプレースホルダです。該当ファイルが無い場合はその段落ごと削除し、ある場合は実際のパスに書き換えてから利用してください。また、ストア固有の注意事項（例：「このストアではセール用のメタフィールド xxx は触らない」など）を末尾に追記しておくと、さらに効果的です。

【注意！】このプロンプト単体で必ず同じ挙動が出るとは限りません：
記事中で紹介した挙動は、私の手元環境で確認したものです。私の環境にはこのプロンプト以外にも既に様々なルールファイルや指示が重ねて読み込まれており、それらとの相互作用によって安全確認の挙動が強化されている可能性があります。そのため、同じプロンプトをそのまま貼り付けても、100%同じ応答が再現されるとは限りません。実際の業務で使い始める前に、下書き商品1件のみを対象にした無害なテスト（例：説明文の一時変更、タグの追加など、戻しやすい操作）を数パターン投げてみて、どこまでルールが効くかをご自分の目で確認してからお使いください。実際に運用しながら「このストアではこの確認も必須」という気づきが出てきたら、末尾に追記していくことで自分の環境に合わせて育てていけます。

# Shopify Admin GraphQL 実行の安全原則（最優先）

Shopify AI Toolkitプラグインの全スキル、特に
Admin GraphQL を実行するあらゆる手段を使用する際、
以下を全セッションで遵守する。

このルールは Shopify AI Toolkit プラグインの上位レイヤーとして機能する。
プラグインが提供する全ツール（GraphQL生成・実行、
MCPサーバー経由のドキュメント検索含む）に優先して適用される。

## 背景

Admin GraphQL API は Shopify ストア運営の根幹に絶大な権限を持つ。
Shopify には「ゴミ箱」も「Undo」も存在せず、
削除＝即ハード削除、一括上書き＝即永久上書き。
AIは自信を持って誤ったGraphQLを実行する可能性があるため、
多層防御が必須。

ストア固有の背景情報（ブランド方針・取り扱い注意の商品群・
連携サービス・過去の事故事例など）が別ファイルにある場合は、
そちらも必ず参照すること：
{{STORE_CONTEXT_FILE}}

## 絶対ルール（mutation 実行前の必須手順）

書き込み（mutation）を含むGraphQLを実行する前に、
以下を順に必ず実施する。
1つでも飛ばしたら実行しない。

### 1. 対象ストアの明示
- 「本番ストア（xxx.myshopify.com）に対して実行します」と警告表示
- 本番の場合は強調して警告

### 2. バックアップの鮮度確認
- 「最新のMatrixifyバックアップはいつのものですか？」を
  必ずユーザーに聞く
- 破壊的操作（削除・一括更新）は、
  バックアップの存在確認なしに絶対に実行しない
- バックアップが古い/無い場合、取得を促してから中断する

### 3. ドライラン（影響範囲の事前計算）
- Shopifyのmutationには基本的に dry_run オプションが無い
- 代わりに同じ条件の read query を先に実行して
  件数とサンプルを取得する
- 例: productVariantsBulkUpdate 前に
  products(first: X, query: "...") を実行
- 結果をユーザーに提示：
  「この条件で N 件がヒットします。サンプル3件：...」

### 4. 現在値の記録
- 変更前の値をJSON等でログファイルに保存してから
  mutation実行
- ロールバック用の元データとして必須
- 大量件数の場合は該当フィールドを先にエクスポート

### 5. ロールバック手順の提示
- 「もしこの操作を戻すには何をすればよいか」を
  実行前に必ず説明
- ロールバック不可能な操作（削除等）は明示的に
  「この操作は元に戻せません」と宣言

### 6. ユーザー承認
- 上記1〜5を提示した上で、実行可否をユーザーに確認
- 「実行してよいですか？」への明示的な承認なしに
  mutation を実行しない

## 禁止事項

- 全件対象操作の禁止：
  products(first: 250) のような無条件クエリから
  直接 mutation に繋げない。
  必ず ID リストまたは具体的な条件で絞る
- 削除系の単独実行禁止：
  productDelete, customerDelete, articleDelete,
  metaobjectDelete, pageDelete 等は、
  バックアップ確認＋ユーザー承認なしに絶対に実行しない
- ゼロ値 / 極端値の警告：
  価格0円、割引100%、在庫0等は
  「意図した値か」を必ず再確認
- bulkOperationRunMutation の原則禁止：
  一括操作は数万件に影響するため、
  検証環境での全件テスト無しには使わない
- 破壊的mutationのチェーン禁止：
  productDelete → collectionDelete のような連鎖は禁止。
  1操作ずつ確認を取る

## 段階実行の原則

一発で全件に当てない。必ず段階的に拡大する。

1. Phase 1: 小範囲テスト（1〜5件）→ 目視確認
2. Phase 2: 中範囲検証（数十件）→ 途中結果をユーザーに報告
3. Phase 3: 全範囲実行 → 最終確認の上で実行

各フェーズの間に必ずユーザー確認を挟む。

## 取り返しのつかない操作（特に慎重に扱う）

以下のmutationは特に慎重に扱うこと（復旧難度★★★）：

- productDelete — Soft Delete無し
- customerDelete — 個人情報は再入力不可
- metafieldsSet（既存値上書き） — バックアップなしで完全消失
- metaobjectDelete — スキーマごと消える可能性
- articleDelete / pageDelete — Googleインデックスも消える
- bulkOperationRunMutation — 数万件に一気に反映されうる

## スコープ最小原則

- shopify store auth 時は read_* スコープから始める
- write_* はそのタスクに必要な分だけ追加
- タスク完了後、不要な write_* は外すことを検討

## 事故発生時の対応

1. 即座にユーザーに報告（隠さない）
2. 追加の破壊的操作を止める
   （「戻そうとして」さらに操作するのは危険）
3. 復旧手順の候補を提示
   （バックアップからの復元、変更前ログからの個別復元等）
4. 実行ログを保全（GraphQL・結果・タイムスタンプ）
5. 再発防止の振り返り
   （なぜガードが効かなかったかを記録）

## Shopify AI Toolkit スキル別の注意

- Admin GraphQL 実行系スキル：
  上記全ルールが最優先適用される
- Shopify Functions 系スキル：
  shopify app deploy は絶対に実行しない
- Liquid / テーマ系スキル：
  コード生成・検証のみ。
  ストアへの反映は必ず GitHub 連携フロー経由にする
- カスタムデータ（メタフィールド・メタオブジェクト）系スキル：
  設計支援は可だが、既存データへの上書きは本ルール適用

参考情報

• Shopify AI Toolkit 公式ドキュメント：shopify.dev/docs/apps/build/ai-toolkit
• GitHubリポジトリ：github.com/Shopify/shopify-ai-toolkit