AI経由の直接チェックアウトで必須手数料を取り漏らさない｜ShopifyのAgentic設定・課金根拠・テスト注文台帳
ON THIS PAGE▼
AI経由の購入では、通常のオンラインストアと同じ画面遷移・同じカート操作が常に行われるとは限りません。とくに、カート画面上のJavaScript、カート属性、アプリの表示操作を前提に追加している危険品手数料、温度管理費、離島追加料金、梱包費などは、注文確定時に必ず加算される仕組みかを個別に確認する必要があります。
本稿で扱うのは「AIに商品を見つけてもらう方法」ではなく、AIチャネルで直接注文が完了しても、必要な料金と出荷条件が成立するSKUだけを販売可能にする受注統制です。
仕様の確認基準日：2025年2月。なお、Agentic Storefronts、利用可能なチャネル、Checkout Extensibilityの利用条件は更新され得ます。公開・設定変更の直前に、末尾のShopify公式ドキュメントと管理画面の表示を再確認してください。
先に確認する：AIチャネルごとに注文完了地点は異なる
ShopifyのAgentic Storefrontsでは、AIチャネルごとに購入者の導線が同一ではありません。Shopifyの公式ヘルプでは、ChatGPTはストアのチェックアウトへの遷移を案内する一方、Google AI Mode / Gemini、Microsoft Copilot、Metaでは、直接チェックアウトを有効にした場合、AIチャネル内のShopify-powered direct checkoutで購入できると説明されています。
この差は、料金設計の監査範囲を決めるうえで重要です。通常ストアで正常に見えるからといって、別のチェックアウト経路でも同じ料金が確定するとは限りません。
まず、手数料や購入制限を次のように書き出します。
- 何の費用か：冷蔵・冷凍配送費、危険品取扱費、ギフト包装費など
- どの条件で発生するか：SKU、数量、配送先、配送方法、温度帯、購入金額
- 現在どこで判定しているか：商品価格、配送設定、アプリ、テーマJavaScript、注文後の目視確認
- 注文総額のどこに表示されるか：商品小計、送料、税、別商品、注文メモ
- 料金が欠けた場合の扱い：出荷不可、差額請求、事業者負担、注文取消
Shopify Communityには、AIエージェントがストアフロントのJavaScriptを経由せず、カート段階で追加する料金アプリが機能しなかったとする投稿があります。ただし、これは単一の投稿であり、すべてのアプリやストアに同じ事象が起きる根拠にはなりません。ここから導ける実務上の判断は、「カート画面で動くこと」を必須料金の成立根拠にしないよう、自店の構成をテストすることです。
手数料ロジックを4区分し、SKU単位で販売可否を決める
全商品を一律に直接チェックアウトへ開放・停止する前に、料金の発生根拠を4区分します。商品単位だけではなく、バリエーション、配送先、配送方法を含めて判定してください。
1. 標準の送料設定で表現できる費用
配送先、配送エリア、商品重量、注文金額など、Shopifyの配送・配達設定で一貫して表現できる費用です。たとえば温度帯ごとに配送プロファイルを分け、対象商品の送料を配送方法として確定できるなら、料金はカート画面の演出ではなく配送料金に含まれます。
ただし、同一注文に常温品と冷凍品が混在したときの送料合算、送料無料閾値との関係、配送先別の例外は別途テストが必要です。「設定画面に料金がある」ことと「混在注文でも必要額になる」ことは別の確認項目です。
2. 商品価格に内包できる費用
SKUに常に発生し、配送先・数量・配送方法で変動しない費用は、商品価格に含める方法を検討できます。購入経路による課金漏れを減らせる一方で、商品比較時の表示価格、値引き時の粗利、税区分、卸売・法人向け価格との整合を確認しなければなりません。
内包後は、原価台帳に「販売価格のうち手数料相当額」を残します。そうしないと、配送費や梱包費の上昇時に、どのSKUの採算が変わったのかを追えなくなります。
3. サーバー側の検証で注文を止められる条件
料金の自動加算が直ちに難しくても、「必要条件を満たさない注文を確定させない」ことは重要な代替策です。ShopifyのCart and Checkout Validation FunctionはShopifyのサーバー上で実行され、条件に合わない場合に購入者のチェックアウト進行を止められます。
たとえば、次のような条件を検討対象にできます。
- 危険品SKUを含む注文で、許容しない配送先が指定されている
- 温度帯が異なる商品を同時購入した場合に、対応する配送方法が選ばれていない
- 追加サービスが必須の商品なのに、その成立条件を注文データから確認できない
- 法人専用・年齢確認対象など、別途の出荷条件が未充足である
Validationは料金を加算する機能ではありません。料金計算そのものを置き換えると考えるのではなく、料金または出荷条件が成立しない注文を通さない安全弁として設計します。
また、Shopifyのエージェント向け開発ドキュメントでは、エージェントが作成したチェックアウトでも検証が実行される旨が示されています。一方で、アプリ定義のチェックアウト拡張で購入者との対話が必要な場合は、購入者がチェックアウト画面で操作する必要があります。表示・クリックを前提にした確認フローだけで、必須条件を満たしたと判断しないでください。
4. カート画面のJavaScriptまたはアプリ表示に依存する条件
テーマ上のボタン操作で手数料商品をカートへ追加する、カート属性をもとにアプリが金額を作る、画面のモーダルで同意を取る、といった構成が該当します。
この区分は、直接チェックアウトを許可する前に最も慎重な検証が必要です。AI経由で必ず動かないと断定はできませんが、料金の成立根拠が画面操作にしかないなら、直接チェックアウトを許可できる根拠もありません。標準送料、価格内包、サーバー側検証へ移せない間は、対象SKUまたは対象チャネルの直接チェックアウトを止める判断が安全です。
「料金が追加されるか」だけでなく、「料金がなければ注文を確定できないか」を分けて確認してください。後者を満たせない設計では、取り漏れを受注後の人手確認に移しているだけです。
Agentic Storefrontsは「商品発見」と「直接チェックアウト」を分けて管理する
直接チェックアウトを停止するとAI経由の露出も失う、と考える必要はありません。Shopifyの管理機能では、Agentic StorefrontsでShopify Catalogへのアクセスと、対応チャネルでの直接チェックアウトの挙動を管理できます。
設定変更前には、次の順で判断します。
- 料金・出荷条件の棚卸しで、区分4に該当するSKUを特定する
- 区分1〜3で成立するSKUについて、通常ストアと対象AIチャネルのテスト注文を完了する
- 不成立または判定不能なSKUがある場合、該当チャネルの直接チェックアウトを停止する
- 商品発見のためのカタログ公開を残せるか、管理画面のチャネル設定で確認する
- 料金ロジックを移行後、再テストを通過したSKU・チャネルから直接チェックアウトを再開する
具体的な画面名称や選択肢は変更される可能性があるため、Shopify管理画面で Sales channels > Agentic を開き、カタログアクセスと各チャネルのdirect checkoutの設定を確認します。設定を変える担当者、料金ロジックを確認する担当者、出荷可否を決める担当者を分ける場合は、誰が最終承認するかも台帳に記録してください。
停止には機会損失というトレードオフがあります。しかし、必須費用を回収できない注文を受け付け、後から差額請求・キャンセル・事業者負担のいずれかを選ぶコストもあります。対象を「全ストア」ではなく、料金根拠が未移行のSKUまたはチャネルに限定することで、影響範囲を管理します。
Checkout Validationを使う前に決める設計条件
Validationの導入は、開発・保守を伴う場合があります。先に業務要件を文章化しておくと、実装可否とテスト範囲を判断しやすくなります。
条件を注文データで判定できるか
Validationで止めるには、判定に必要な情報がチェックアウト時点で取得できる必要があります。配送先の国・地域、カート内の商品、数量、配送方法などを用いる条件は、要件に落とし込みやすい候補です。
反対に、外部システムでしか分からない保冷材在庫、有人審査の結果、購入者が画面で入力する任意情報だけに依存する条件は、そのままでは自動判定できない可能性があります。無理にValidationへ寄せず、対象SKUの直接チェックアウト停止、価格・送料設計の変更、出荷保留フローの明示を比較します。
購入者へのメッセージと復旧手順を用意する
止めるだけでは購入者が購入を完了できません。エラーメッセージには、少なくとも次を含めます。
- 購入できない理由を、内部用語を避けて示す
- 解決手段：配送先変更、対象商品を分ける、通常ストアで確認するなど
- 問い合わせ先と、確認に必要な注文内容
「手数料が不足しています」のように曖昧な表示では、購入者も運用担当者も対応できません。一方、料金計算ロジックや不正対策の詳細を表示しすぎる必要もありません。
3経路で実施するテスト注文台帳
設定画面の確認だけで公開可否を決めず、実際の注文データで照合します。最低限、通常ストア、Shop Payなどのaccelerated checkout、直接チェックアウトを許可するAIチャネルの経路を分けます。利用していない経路は対象外として明記し、利用開始時に追加します。
| 確認項目 | 通常ストア | accelerated checkout | AIチャネル直接チェックアウト |
|---|---|---|---|
| 対象SKU・バリエーション | |||
| 配送先（通常／例外地域） | |||
| 配送方法 | |||
| 商品小計 | |||
| 送料・追加配送費 | |||
| 割引後の料金 | |||
| 税額・総額 | |||
| 必須条件の検証結果 | |||
| 注文属性・メモ・タグ | |||
| 出荷可否と判定者 |
テストケースは、最も売れる組み合わせだけで終えないことが大切です。料金に影響する境界条件を入れます。
- 追加料金対象SKUを1点だけ購入する
- 通常SKUと追加料金対象SKUを混在させる
- 送料の境界となる配送先、注文金額、重量、数量を選ぶ
- 割引コードまたは自動割引を適用する
- 送料無料条件をまたぐ
- 購入を止めるべき条件で、実際に注文確定を阻止できるか確認する
照合の基準は「画面上で料金が見えた」ではなく、注文詳細、決済総額、配送方法、出荷指示に必要な属性が一致することです。注文番号、テスト日時、利用経路、スクリーンショットまたは注文詳細への参照、期待値との差分、修正担当、再テスト日を台帳に残してください。
公開後は粗利差分と保留理由を定点確認する
初回テストを通過しても、商品追加、配送設定変更、アプリ更新、割引施策、AIチャネル追加で前提は変わります。日次または週次の受注確認では、AI経由かどうかだけでなく、料金の期待値と実績額の差を確認します。
運用台帳には、少なくとも以下を記録します。
- SKUまたはSKU群
- 必須費用の名称と発生条件
- 採用している根拠：送料、価格内包、Validation、手動確認
- 直接チェックアウトの許可チャネル
- 最終テスト日とテスト担当
- 差分発生時の出荷判断者
- 修正期限と再テスト結果
新しいSKUを登録する申請フローにも、「AI直接チェックアウト可否」と「必須料金の根拠」を追加します。これにより、公開後に個別の例外を探すのではなく、販売開始前に未判定SKUを止められます。
AI経由の直接購入を有効にする判断は、流入拡大だけで決めるものではありません。どの経路でも請求額・配送条件・出荷可否が同じ根拠で確定するかをSKU単位で確認し、根拠がないものは直接チェックアウトを限定する。この順序で進めると、購入機会と粗利統制の両方を比較可能な形で扱えます。
参考情報
この課題、もっと詳しく相談したい方へ
記事では答えきれない個別の状況にもお応えします。