Shopifyのカゴ落ちを電話で挽回する

チェックアウトまで進んだ人が支払いを残して帰っていく。その後、AIエージェントが名前を呼んで電話をかける — ただしその間に購入済みならかけない。Shopifyアプリの作成、権限、そして静かに動かなくなるすべての箇所まで、設定の手順全体を解説します。

更新日 2026年9月16日

カゴ落ち挽回のほとんどはメールです。電話がけは勝手が違います。判断を要するのは電話だけだからです。すでに買った人へのメールは目をつむれる範囲ですが、電話は双方にとって気まずい一分になります。

だからこのガイドの大半は発信の話ではありません。その前に満たされているべきこと全部の話です。実際のチェックアウトが存在すること、本当に買っていないこと、相手の深夜でないこと、電話をやめてくれと頼まれていないこと、そして名前を呼んで電話を始められるだけ名前を知っていること。

30分ほど見込んでください。その大半はShopifyでの操作で、ここではありません。

2分20秒ほど。支払われずに閉じられた決済ページ、そもそも電話をかけるかどうかを決める3つのルール、それを組み立てる一文、そして割引コードから始まる通話。

短い要約

Shopifyアプリを作成し、4つの権限にチェックを入れ、インストールする
Shopifyから2つの異なるシークレットをコピーする
両方をOmni Octoに接続として保存する
Octoにフローの構築を頼む
Webhookアドレスをコピーして、Shopifyに2回貼り付ける
待ち時間1分でテストする

つまずきやすいのはステップ1と5です。それぞれに独立したセクションがあります。

ステップ 1 — Shopifyアプリを作成してインストールする

Shopifyで：設定 → アプリと販売チャネル → アプリを開発 → アプリを作成。後で見分けられる名前を付けてください。

この権限にチェックを入れる

設定 → Admin APIの統合 → 設定 を開き、以下を許可します：

権限	目的
`read_orders`	買い手が結局購入したかどうかの確認
`read_all_orders`	60日より古い注文に対する同じ確認
`read_customers`	名前と電話番号
`read_products`	カートに入っていた内容の読み取り

チェックアウト権限を探しても見つかりません。 read_checkoutsは存在しますが、Shopifyはこれを保護対象として扱います。チェックできる一覧には現れず、要求にはShopify本体の承認が要ります。これなしでチェックアウトAPIを呼ぶと、Shopifyはこう答えます：

This action requires merchant approval for read_checkouts scope.

問題ありません。そしてこのフローがチェックアウトを読まない理由がそれです。代わりにもっと良い質問をします — 注文は現れたか？ — これはread_orders だけで足ります。

インストールする

全員が忘れるステップはこれです。 アプリを設定しても、アプリの概要ページで アプリをインストールを押すまでは何も起きません。押すまで、コピーすべき Admin APIアクセストークンは存在せず、以降のすべてのステップが別の何かが壊れているように見える失敗をします。

2つのシークレットをコピーし、混ぜない

2つの異なるものが必要で、どちらもランダムな文字列に見えるため混同しやすいです。

対象	場所	役割
Admin APIアクセストークン	インストール後のアプリのAPI資格情報タブ。`shpat_`で始まる	Omni OctoがShopifyに問い合わせるためのもの
Webhook署名シークレット	設定 → 通知 → Webhook、ページの下部	Omni OctoがShopifyの送信メッセージを検証するためのもの

1つはShopifyとの対話用。もう1つはShopifyが本当に送ったことを確認するため。混ぜるのがこのセットアップで最も高くつく失敗で、症状は原因と少しも似ていません — 何も起こらないときを参照してください。

ステップ 2 — 両方のシークレットをOmni Octoに保存する

連携ページを開き、1つずつ追加します。

Admin APIアクセストークン。 新しい連携を押し、その他の下にある HTTP / API キーのカードを選びます。shpat_トークンを貼り付けてください。一覧で見分けられる名前を付けます — 「Shopify」より「Shopify Admin API トークン」のほうが良いです。

Webhook署名シークレット。 もう一度新しい連携を押し、Signing secretを選んで、通知ページのシークレットを貼り付けます。フォームに、覚えておく価値のあることが書かれています：

The secret the sender signs with, not a key you call them with.

Signing secretの接続ダイアログ。名前フィールドとSigning secretというラベルのフィールドがある。 — 見落とされがちなのがこのカードです。ここにAdminトークンを貼るか、APIキーカードに署名シークレットを貼ると、下流のすべてが、どちらの名前も出さないエラーで失敗します。

2つの接続、2つの方向です。何かを作る前に両方保存してください。

連携ページに2つのShopify認証情報が並んでいる：HTTPの下のAdmin APIトークンと、Webhookの下の署名シークレット。どちらも有効。 — 完成形はこうです。2行、2種類 — Shopifyへの問い合わせ用が1つ、Shopifyが本当に送ったことの確認用が1つ。

ステップ 3 — Octoにフローを作らせる

自動化を書くのはあなたではありません。チャットを開いて、買い手を連絡先として保存する部分も含めて、やりたいことを説明します：

私のShopifyストアで誰かがカートを放棄したら、30分ほど待ってから電話をかけて。その前に、名前と電話番号と一緒に連絡先として保存して、エージェントが名前を呼んで挨拶できるようにして。+1 555 0100から、私のShopify Cart Recovery エージェントを使ってかけて。

連絡先の部分をきちんと言ってください。 それがなくてもOctoは動くフローを作りますが、挨拶はShopifyのメッセージではなく連絡先レコードから名前を取るため、エージェントは「サラさん、こんにちは」ではなく「こんにちは」で口を切ります。これを指定することが、挽回の電話と冷たい電話を分けるものです。

Octoは接続を読み、エージェントを見つけ、署名シークレットを2つ以上保存していればどれを使うか聞いてくることがあります。Adminトークンではなく署名シークレットで答えてください。

Octoがチャットで作ったフローを説明している：待ち時間と購入確認はトリガー内にあり、買い手は連絡先として保存され、それから電話がかかる。 — 1段落送っただけで、返ってくるのはこれです。待ち時間と購入確認がトリガーの一部である点に注目してください。あなたが追加し忘れるものは何もありません。

そして「有効」と表示されていることを確認します。 下書きのままのフローは Shopifyが送るものすべてを拒否し、Shopifyの配信ログは、まるでアドレス違いというような失敗で埋まります。

ステップ 4 — Shopifyにアドレスを渡す

フローを開き、図の上にあるWebhook endpointカードを探します。アドレスとステータスが表示されています：

Ready — 公開中で、署名シークレットが保存されている
Inactive — 一時停止中かまだ下書きなので、Shopifyのメッセージは拒否される

フローの概要タブにあるWebhook endpointカード：アドレス、Readyバッジ、Copyボタン、期待する署名。 — アドレスはここ、フローの概要タブにあります。Readyはフローが公開中で署名シークレットが保存済みということ。他の表示なら、Shopifyの配信は拒否されます。

Copyを押します。次にShopifyで、設定 → 通知 → Webhook → Webhookを作成と進み、同じアドレスを貼って2つ作成します：

イベント	フォーマット	理由
チェックアウトの作成	JSON	誰かがチェックアウトに達したときに発火
チェックアウトの更新	JSON	追加情報を入力したときに発火

なぜ2つか、平たく言うと

Shopifyは誰かがチェックアウトを始めた瞬間に知らせますが、それは電話番号を打つ前であることが多いです。入力が進むたびに再度知らせてきて、その後発のメッセージの1つに番号が載っている、というのが通例です。

最初の1つだけ購読すると、かける相手のいないフローができます。両方購読すれば、かける相手がいます。

同じドロップダウンにはカートの作成もあります。それらしい響きですが、違います。カートはただの買い物かごで、Shopifyにはメールも電話も名前もないため、かける相手がいません。Webhookが届いているかどうかの無害なシグナルが欲しいときにだけ使ってください。

これらのWebhookはShopify管理画面のこのページで、手作業で作成してください。 Shopify API経由で作らないでください。両方試しました。このページで作ったものは30秒ほどで届きました。API経由で作ったものは1時間以上経っても一度も届かず、どちらの場合もShopifyはエラーを出しませんでした。

どちらかでテストを送信を押してください。1分以内に、フローの実行一覧に何かが現れるはずです。この1クリックが接続の動作を証明する最速の方法で、コストはゼロです。

ステップ 5 — 1分でテストする

Octoに待ち時間を1分に変えてもらいます。

まず、自分の電話番号を顧客レコードに登録します。 Shopifyで：顧客 → 自分のメールの顧客を選ぶか作成 → 電話番号を追加して保存。

購入の前にやってください。チェックアウトページに電話番号を打ち込むだけでは 不十分です — Shopifyの1ページチェックアウトには支払い前に送信するステップがなく、そこで打った番号はShopifyに届かない可能性があります。私たちはこれで一晩を失いました。顧客レコードの番号は最初のメッセージからチェックアウトと一緒に運ばれ、それがテストを成立させます。

それから：

その顧客としてストアフロントにログインする
何かをカートに入れる
チェックアウトに進み、ページを読み込ませる
タブを閉じる

Shopifyがメッセージを配信してから1分ほどで、自分の電話が鳴るはずです。チェックアウトフォームに何も入力する必要はありません。

その後、Octoに待ち時間を30分に戻してもらってください。 1分のままだと、カード番号を打ち込んでいる最中の人に電話がかかります。

何も起こらないとき

これが、私たちが当初あれば欲しかったセクションです。上から順に — 各項目は、実際にテストを止めたものです。

フローに何も届かない

アプリをインストールを押しましたか？ 権限の設定はインストールではありません。

WebhookはAPI経由ではなく、Shopify管理画面で作りましたか？ 上を参照。これが断トツで時間を食われました。

フローは有効ですか？ 下書きはすべてを拒否します。

フローを作成または編集したばかりですか？ 数分待ってください。新しいフローは、登録されるまでの短い間「まだ準備ができていない」と応答し、Shopifyは自動で再試行します。

まずShopify自身の配信ログを確認してください。 作成したWebhookのページにあります。Shopifyが配信を表示していなければ、問題は回線の向こう側にあり、 Omni Octoのどこを見ても説明は得られません。

Shopifyは送るが、フローが拒否する

ほぼ常にシークレットの間違いです。どちらが署名するかはWebhookの作り方によりますが、それは自明ではありません：

Webhookの作成場所…	署名に使われるもの
通知ページで手作業で	同じページにある署名シークレット
アプリからAPI経由で	そのアプリ自身のAPIシークレットキー

このガイド通りに進めたなら、必要なのは1行目です。フローをステップ2の署名シークレットの接続に向けてください。

フローは始まるが、誰にも電話がかからない

電話番号はありましたか？ 実行を開き、何が届いたかを見てください。番号がなければ電話はありません。設計上そうです。

カートに追加するだけでは足りません。 カート単体ではShopifyに何も伝えません。チェックアウトページに到達し、かつShopifyが相手に連絡する手段を持っている必要があります — ログイン中のアカウントか、入力された内容です。

電話番号を打つことと送信することは別です。 Shopifyの1ページチェックアウトには支払い前の「続行」ボタンがなく、打った番号はShopifyに届かない可能性があります。確実な修正が次の項目です。

顧客レコードに電話番号を登録してください。 Shopifyで：顧客 → その人物 → 電話番号を追加。ログイン中の買い手の番号は、最初のメッセージからチェックアウトと一緒に運ばれ、上のどの問題も関係なくなります。私たち自身のテストを成立させたのは、この変更だけでした。

SMSでのログインはカウントされません。 Shopifyがログインコードを送った番号は、Shopifyのログインシステムのものです。顧客レコードには届かず、使えません。

試用期間またはパスワード保護されたストアでのテスト

自分のストアで購入するにはストアのパスワードが要ります。 オンラインストア → 各種設定 → パスワード保護にあります。

onlineStoreUrlを商品の公開サインとして信用しないでください。 パスワード保護されたストアでは、公開・非公開にかかわらずすべての商品で空だと報告されます。私たちは、公開済みの商品を公開し直して時間を無駄にしました。パスワード付きで商品ページを開いて、自分の目で確かめてください。

電話を止めるもの

4つのチェックです。それぞれは、失敗ではなく、実行が静かに、しかるべき理由で終わる場所です。その後に見える表示が異なるので、どれがどれか知っておく価値があります。

購入していた。 待ち時間の後、そのチェックアウトに注文が存在するかを Shopifyに尋ねます。存在すれば実行は停止します。待ち時間が存在する理由のすべてがこれです。Shopifyはメールアドレスが打たれた瞬間にチェックアウトを放棄扱いにしますが、それはまだカードを取り出そうとしている最中であることが多いのです。

判別できなかった。 この確認が失敗した場合 — トークンの期限切れ、権限の取り下げ、ネットワークの問題 — 実行は電話をかけずに停止します。逆に推測してかければ、支払い済みの人に電話をかけることになります。

この2つはどちらも最初のステップの前に起きます。確認がトリガーの一部だからです。そのため、こうして止まった実行は、ステップなしで完了として表示されます — 何も保存されず、誰にも発信されていません。現時点では、実行画面はどちらだったのかをまだ書き出しません。ステップなしで完了する実行が続いて電話を期待していた場合は、まずAdmin API接続を確認してください。

相手の深夜です。 発信可能時間は電話番号の国コードから決まり、タイムゾーンに置けない番号にはかけません。複数のゾーンにまたがる国では、そのすべてで昼間である必要があります。

停止の依頼がありました。 その番号の「電話しない」登録は、発信前に電話をブロックし、実行は失敗ではなく拒否を記録します。

買い手を連絡先として保存した後、発信を見合わせたフローの実行。通話ステップはdialed falseとskipped quiet_hoursを報告している。 — 拒否の記録。この実行は買い手を保存した後、午前1時半の電話を見合わせました — dialed: false、そしてその理由が隣に書かれています。

この方法でできないこと

ShopifyのWebhookは作成されません。 アドレスを貼り付けるのはあなたで、 2回です。

電話番号は捏造されません。 番号がなければ、電話もありません。

挽回の電話は「少なくとも1回」であり、「ちょうど1回」ではありません。 Shopifyは買い手が何かを変更するたびにメッセージを送り、それぞれが独自の実行を開始します。それらの実行は突き合わされるので、通常は1回の電話になりますが、メッセージ間の間隔が十分長いと2回目が発生することもあります。実際の顧客に向ける前に知っておくべきことです。

APIバージョンを最新に保ってください。 Admin API接続には、使うShopify APIのバージョンが記録されます。Shopifyは各バージョンを1年ほどサポートした後、知らせずに古いバージョンで応答するようになります。1年経っていたら、更新してください。