投稿者 投稿日: カテゴリー EC×AI活用
エージェント決済とは、AIが人の代わりに購入まで完了させる仕組みのことです。
在庫が1点だけ残った商品に、AIエージェント経由の注文が入る。決済処理が走った数十秒後に、楽天市場でも同じ商品が売れて在庫がマイナスになる。人間の買い物なら「カートに入れて、迷って、10分後に決済」の間に在庫が反映されますが、エージェント決済ではその猶予がありません。フィード上の在庫が最後に更新されたのが4時間前なら、AIは4時間前の世界を見て購入を確定させます。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづき、同期頻度の設計と注文失敗の防ぎ方をプロンプト4本つきで整理します。
「在庫が古い」がペナルティに直結する構造に変わった
結論から書くと、エージェント決済の時代に効くのは在庫数そのものではなく、在庫情報の鮮度です。理由は、AIが購入判断を下す瞬間に参照するのがフィードの値であり、実在庫ではないからです。
従来の検索連動型ショッピングでは、多少古い在庫情報でも致命傷になりませんでした。ユーザーが商品ページに到達した時点で最新の在庫が表示され、そこで判断が上書きされるためです。ところがエージェント決済では、AIがフィードの値を根拠に候補を絞り、そのまま決済まで進みます。フィードと実在庫の差分が、そのまま注文失敗として顕在化します。
GoogleはMerchant Centerのヘルプで、価格と在庫状況はサイト上の表示と一致している必要があると明示しています。在庫フィードについても、在庫フィード仕様のヘルプで更新の考え方が示されており、1日に複数回変動する商品では取得頻度の引き上げが必要になる旨が説明されています。AIモード向けには15分間隔の定期取得やリアルタイム連携が望ましいという指摘も出ていますが、これは各社の解説記事ベースの数字であり、Google公式が最低要件として定めた値ではありません（要確認）。
現場感覚では、日本のEC事業者の多くが4時間から24時間に1回のバッチ更新で回しています。この頻度は検索連動の広告配信としては実用に足りますが、エージェント決済の判断材料としては明確に粗い。ここが2026年に起きた変化点です。
もう1つ押さえたいのが、失敗の蓄積が評価に効く可能性です。AIエージェント経由で注文が確定したのに商品を届けられないケースが続けば、その出品者は候補から外されやすくなります。ペナルティの具体的な発動条件や閾値は公開されていないため断定は避けますが（要確認）、注文成立率が評価指標として使われる方向に進むのは自然な流れでしょう。
複数モールに在庫を共有している店舗ほど、この問題は深刻です。楽天市場、Amazon、Yahoo!ショッピング、自社Shopifyの4面に同じ在庫を出している場合、どこか1面で売れた瞬間に残り3面の在庫が過大表示になります。従来はこれを「多少の売り越しは謝って返金」で吸収してきました。エージェント決済が増えると、この吸収がきかなくなります。
なぜ吸収がきかなくなるのか。人間の購買では、売り越しが起きても「申し訳ありません、在庫切れでした」の連絡で大半は収まります。相手が納得すれば話は終わりです。ところがAIエージェント経由の購買では、注文の失敗そのものがデータとして残り、次回以降の候補選定に反映されうる構造になっています。1件の謝罪で終わらず、その後の露出に影響する可能性があるという点が、これまでとの決定的な違いです。
もう1つの変化は、購入までの時間が圧縮されたことです。人間の買い物では検討から決済まで数分から数日かかりますが、エージェントは候補の絞り込みから決済まで数十秒で完了させます。つまり、これまで「まあ大丈夫だろう」で通っていた4時間の同期遅延が、そのまま4時間分の失注リスクとして露出することになります。時間軸が変わったのに運用が変わっていない、というのが2026年夏時点の多くの店舗の状態でしょう。
注文失敗が起きる4つの経路
第一の経路は、単純な同期遅延です。バッチ更新の間隔のなかで売れた分が反映されず、AIが在庫ありと判断します。更新間隔が4時間なら、理論上は最大4時間分の販売が未反映のまま候補に残ります。
第二の経路は、価格の不一致です。フィード上の価格とチェックアウト時の価格がずれると、決済が止まります。タイムセールやクーポン適用で価格が動く商品ほど起きやすく、セール開始直後と終了直後の各30分が危険帯です。ある食品ジャンルの中規模店舗の事例では、セール終了時刻ちょうどにフィード更新が走らず、旧価格のまま候補に残り続けたことがありました。
第三の経路は、SKU紐付けの破綻です。在庫連携ツールを挟んでいる場合、モール側の商品コードと自社マスタのSKUが1対1で結びついていないと、更新が別商品に飛びます。バリエーション親子で在庫が二重計上されるパターンもここに含まれます。
第四の経路は、API制限との衝突です。同期頻度を上げようとすると、楽天RMSのAPIやAmazon SP-APIのリクエスト上限にぶつかります。全商品を毎回フルで送る設計のままでは、頻度を上げた瞬間にレート制限で更新が落ち、かえって鮮度が下がるという逆転が起きます。
この4経路のうち、店舗が自力で改善できるのは第一から第三までです。第四は設計の作り直しが必要になるため、社内にエンジニアがいない店舗では連携ツール側の機能に依存することになります。逆に言えば、第一から第三までを潰すだけでも注文失敗はかなり減ります。着手順としては、まず第三のSKU紐付けを点検し、次に第一の同期間隔を階層化し、最後に第二の価格まわりを整えるのが手戻りの少ない順序です。紐付けが壊れている状態で同期頻度だけ上げても、間違った商品の在庫を高頻度で更新するだけになります。
同期設計を作り直す5つの運用
運用1：商品を回転速度で3階層に分ける
全商品を同じ頻度で同期する設計をやめます。日次で10個以上売れる高速回転品、週次で10〜30個の中速品、月次で数個の低速品。この3階層に分け、高速回転品だけを短間隔で更新します。多くの店舗では高速回転品が全SKUの1割前後に収まるため、API負荷を抑えたまま鮮度を上げられます。
（用途タイトル：商品の回転速度による同期階層の設計）
プロンプト1：在庫同期の優先階層を設計する
あなたはEC在庫運用の設計に詳しいコンサルタントです。
以下の販売実績データから、在庫フィードの同期頻度を3階層に分ける設計を作ってください。
分類の基準：
1. 直近90日の販売個数と販売日数の分布
2. 在庫残数が5個以下になる頻度
3. 複数モールに同時出品しているか
4. 単価（高単価品は失注コストが大きいため優先度を上げる）
出力フォーマット：
A. 階層定義（高頻度／中頻度／低頻度、それぞれの同期間隔の推奨値と根拠）
B. 各階層に該当するSKU数と全体に占める割合
C. 階層をまたぐ商品の判定条件（季節変動・セール期間の扱い）
D. API呼び出し回数の概算（1日あたり）
販売実績データ：
{SKU／商品名／直近90日販売個数／販売日数／現在庫数／単価／出品モール}
運用2：差分更新に切り替える
全商品を毎回送るフル同期から、変化があったSKUだけを送る差分同期に切り替えます。これだけでAPI呼び出し回数が大きく減り、同じ制限のなかで頻度を上げられます。実装では、前回送信時の在庫数と価格をローカルに保持し、差分が出たものだけをキューに積む形になります。
数字で見ると効果がはっきりします。全SKUが5,000点あり、1日に在庫が動くのがそのうち300点だとすると、フル同期では1回あたり5,000件の更新を投げるのに対し、差分同期では300件で済みます。同じAPI枠なら理論上は16倍の頻度で回せる計算になります。実際にはヘッダー処理や失敗リトライがあるため単純な比例にはなりませんが、桁が変わることは確かです。
差分同期を組むうえで見落としやすいのが、失敗したときの扱いです。送信に失敗したSKUをキューから消してしまうと、次に在庫が動くまでフィード側が古いまま残ります。失敗分は必ずキューに戻す設計にし、3回連続で失敗したものはアラートを出す仕組みを入れておいてください。楽天/Amazonの両方を回している店舗で観測されたのは、片方のAPIが一時的に落ちたときに差分が消え、翌日まで在庫が更新されないまま放置されていた事例でした。
もう1つ、定期的なフル同期は残しておきます。差分同期だけを続けると、送信漏れやローカル保持データのずれが少しずつ蓄積します。週に1回、深夜帯にフル同期を走らせて整合を取り直す運用が安全です。
運用3：安全在庫を回転速度に連動させる
売り越しを構造的に防ぐには、フィードに出す在庫数を実在庫より少なく見せる安全在庫の設計が要ります。日次10個以上売れる高速回転品は2〜5個、週次10〜30個の中速品は1〜2個、月次数個の低速品は0〜1個が目安です。在庫が1点しかない希少品は、思い切って1モールに集約するほうが事故が減ります。
（用途タイトル：安全在庫の設定値と機会損失の試算）
プロンプト2：安全在庫の設定値を機会損失込みで試算する
あなたはEC在庫の数値設計を担当するアナリストです。
以下の条件で、SKUごとの安全在庫の推奨値と、それによる機会損失の試算を出してください。
試算の前提：
1. 同期間隔のあいだに売れる可能性のある個数＝（日次平均販売個数 ÷ 24）×（同期間隔の時間数）
2. 安全在庫は上記に安全係数を掛けた値とし、係数は商品の販売変動係数から決める
3. 機会損失＝安全在庫として出さなかった分が売れたはずの金額（上限は在庫数）
4. 売り越しコスト＝キャンセル対応工数＋評価下落リスク（金額換算は仮定値でよいが根拠を明記）
出力フォーマット：
SKU／推奨安全在庫／根拠となる計算／月間機会損失の概算／売り越し回避による節減の概算／推奨する同期間隔
商品データ：
{SKU／日次平均販売個数／販売のばらつき／単価／現在の同期間隔／出品モール数}
運用4：価格変更の予約と同期をひも付ける
セールの開始・終了時刻にフィード更新を確実に走らせます。手動でセール価格を変えて、フィード更新は次のバッチ待ち、という運用が価格不一致の最大の原因です。セール設定を登録した時点で、開始5分前と終了直後に同期をキューイングする仕組みを組み込みます。
日本のEC事業者にとって厄介なのは、価格を動かすイベントが多いことです。楽天市場ならお買い物マラソンとスーパーSALE、Amazonならタイムセールとプライムイベント、Yahoo!ショッピングならPayPay関連の施策。これらが月に何度も走り、そのたびに実売価格が動きます。さらにクーポンの適用条件によっては、フィード上の価格とユーザーが実際に支払う金額が構造的にずれます。
対策として、価格をフィードに出すときの基準を先に決めておきます。クーポン適用前の商品価格を出すのか、適用後を出すのか。モールごとに仕様が違うため、ここを曖昧にしたままだと不一致が常態化します。セール期間の価格については、セール価格をフィードに反映させる場合、開始と終了の両方に同期をひも付けるのが原則です。終了側の同期を忘れると、セールが終わっているのに安い価格で候補に残り、決済段階で弾かれます。
配送料の扱いも同様です。合計金額で判断するAIに対して、送料の条件が古いままだと「送料無料で買えるはず」が崩れます。送料無料ラインを変更したら、フィードの送料属性も同時に更新する手順をチェックリストに入れておいてください。
運用5：注文失敗のログを取って原因別に分ける
失敗を減らすには、まず失敗を数えられる状態にすることです。エージェント経由の注文がキャンセルになった件数を、在庫起因・価格起因・配送条件起因・その他に分類して記録します。分類の粒度が粗いと打ち手が決まりません。
記録は手作業でも構いません。日付、SKU、失敗理由、そのときのフィード上の値と実際の値。この4項目をスプレッドシートに残すだけで、1か月後には打ち手の優先順位が見えてきます。多くの店舗では、最初の1か月で在庫起因が全体の6割から7割を占めることが分かり、そこから同期設計の見直しに進む流れになります（構成比は店舗の在庫運用によって変わるため参考値）。
ログを取る過程で気づくことがもう1つあります。失敗が特定の時間帯に集中しているケースです。バッチ更新の直前、つまりフィードが最も古い時間帯に失敗が偏っているなら、間隔の短縮が直接効きます。逆に時間帯の偏りがないなら、原因は同期頻度ではなくSKU紐付けや属性設定にある可能性が高いと判断できます。
モール別に押さえる実装ポイント
楽天市場では、在庫更新はRMSのAPI経由か在庫連携ツール経由で行います。商品ページの在庫と、複数モール共有の基準在庫が別管理になっている店舗が多く、ここの二重管理が事故の温床です。基準在庫を1つに決め、そこから各モールへ配分する設計に統一してください。なお楽天R-Mailの本文に楽天市場外へのリンクを置くことは規約で認められていないため、在庫復活のお知らせを自社サイトへ誘導する形で組むのは避けます。
Amazonでは、SP-APIのレート制限が設計の制約になります。全SKUを毎回送る設計は現実的ではなく、差分同期がほぼ必須です。FBAとマケプレ出荷が混在している場合、FBA在庫はAmazon側で管理されるため、自社側から更新すべきなのは自己出荷分だけという切り分けも要ります。
Shopifyは自社ドメインなので外部誘導の制約が緩く、在庫のリアルタイム反映も比較的組みやすい環境です。Merchant Centerとの連携アプリを使う場合、アプリ側の同期間隔がボトルネックになることがあるため、アプリの仕様を確認してください。
Yahoo!ショッピングはストアクリエイターProから在庫を更新します。楽天やAmazonに比べて更新経路の選択肢が少ないため、連携ツール側の対応状況が実質的な上限になります。
（用途タイトル：注文失敗ログの原因分類）
プロンプト3：注文失敗を原因別に分類して打ち手を出す
あなたはEC運用のデータ分析担当です。
以下の注文キャンセル・失敗ログを原因別に分類し、優先度付きの改善案を出してください。
分類のルール：
1. 在庫起因（フィード上は在庫ありだが実在庫なし）
2. 価格起因（フィード価格とチェックアウト価格の不一致）
3. 配送条件起因（配送可能地域・お届け日の不整合）
4. 商品属性起因（サイズ・色などバリエーション指定の不一致）
5. その他（決済エラー等、出品側で制御できないもの）
各分類について、発生件数・発生時間帯の偏り・該当SKUの傾向を出し、
「同期頻度の変更」「安全在庫の調整」「フィード属性の修正」「運用フローの変更」のどれで解決するかを明示してください。
出品側で制御できないものは「対象外」と明記し、無理な改善案を作らないでください。
ログデータ：
{注文日時／SKU／失敗理由コード／フィード上の在庫数／実在庫数／フィード価格／実価格／最終同期時刻}
週次で回すチェック
上記4つを実装したら、週に1回の点検を回します。フィード上の在庫と実在庫を全SKUで突合し、乖離が出ているSKUを抽出する作業です。
（用途タイトル：フィードと実在庫の乖離検出）
プロンプト4：フィード在庫と実在庫の乖離を検出する
あなたはEC在庫の突合を行う品質管理担当です。
以下の2つのデータを突き合わせ、乖離しているSKUを検出してください。
検出の観点：
1. フィード在庫と実在庫の差（絶対値と比率の両方）
2. マイナス在庫が継続しているSKU
3. 最終同期時刻が想定間隔を超えて古いSKU
4. 同一SKUが複数モールで異なる在庫数になっているもの
5. バリエーション親と子の在庫合計が一致しないもの
出力フォーマット：
A. 即時対応（売り越し発生中／発生直前）
B. 24時間以内対応（同期が止まっている疑い）
C. 週次対応（軽微な乖離・親子不整合）
D. 各項目について、原因の仮説と確認手順を1〜2行
データ1（フィード側）：{SKU／在庫数／価格／最終同期時刻／モール}
データ2（実在庫側）：{SKU／実在庫数／引当済み数／入荷予定}
KPIと費用の目安
測る指標は3つに絞ります。第一に、フィード鮮度。全SKUの最終同期時刻の中央値と、最も古いSKUの経過時間を毎日記録します。第二に、注文失敗率。エージェント経由の注文のうち、在庫起因・価格起因でキャンセルになった割合です。第三に、売り越し件数。実在庫を超えて受注してしまった件数を週次で数えます。
費用面は、既存の在庫連携ツールのプラン変更が中心になります。クロスモールやネクストエンジンといった多モール連携サービスは、上位プランで同期間隔を短縮できる設計になっているのが一般的です（プラン内容と間隔は各サービスの最新の公式情報で確認してください）。自社で連携を組んでいる場合は、差分同期の実装工数が発生します。プログラム改修としては小規模で、5〜20時間程度が目安でしょう。
投資判断の考え方はシンプルです。月間の売り越し件数にキャンセル1件あたりの対応工数と機会損失を掛けた金額が、プラン差額や改修費を上回るなら着手する価値があります。直近の支援案件で観測したのは、売り越し1件あたりの実コスト（返金処理・謝罪連絡・評価対応）を店舗が過小に見積もっているケースでした。実際には30分から1時間の工数がかかっています。
試算の型を1つ示します。月間の売り越しが20件、1件あたりの対応工数が40分、担当者の時間単価を2,000円とすると、対応工数だけで月26,700円前後になります。これに機会損失（本来売れたはずの粗利）と評価下落の影響が乗ります。連携ツールの上位プラン差額が月1万円台であれば、工数だけで元が取れる計算です。自社の数字を当てはめて、まず対応工数の総和から出してみてください。
工数の見積もりで見落としがちなのが、対応の分散です。売り越しの連絡は受注担当が行い、返金処理は経理が行い、評価が下がれば店長が対応する。1件が複数部署にまたがるため、部署ごとの体感時間を足し合わせると想定より大きくなります。棚卸しの際は、関わった全員の時間を合算してください。
この先の論点
競合の解説が触れていない点を2つ挙げます。1つ目は、同期頻度を上げることが常に正解ではないという話です。低速回転品まで15分間隔で更新すると、API制限を高速回転品と奪い合うことになります。限られたリクエスト枠をどこに配分するかという発想が、今後は在庫運用の中心になります。
配分の考え方を具体化すると、まず1日あたりのAPI呼び出し可能回数を把握し、そこから安全マージンとして2割を差し引きます。残りを高速回転品に7割、中速品に2割、低速品に1割といった比率で割り当てる形です。季節商品を扱う店舗なら、シーズンに応じてこの比率を組み替えます。夏場の水回り用品と冬場の暖房関連では、回転する商品群がまるごと入れ替わるためです。
2つ目は、在庫の見せ方そのものの設計です。エージェント決済では「在庫あり・なし」の二値ではなく、入荷予定日や取り寄せ可否まで含めた情報がAIの判断材料になります。取り寄せに5日かかる商品を単純に在庫なしとするか、入荷予定つきで出すかで、候補に残るかどうかが変わります。ここは商品ページの構造化データとも連動する領域で、うるチカラではAIエージェント向け商品ページのスキーマ整備やGoogle Buy for Meへの対応で扱っています。計測の考え方はMerchant CenterのAI経由パフォーマンス計測を参照してください。
よくある質問
同期頻度はどこまで上げるべきですか
高速回転品は15分から30分、それ以外は1時間から4時間が現実的な目安です。全商品を一律で最短にする必要はありません。API制限とのバランスで決めるものなので、まず回転速度で階層を分けてから頻度を割り当ててください。
在庫連携ツールを使わず手動運用でも対応できますか
いいえ、商品数が数十点を超えると手動では追いつきません。エージェント決済は分単位で動くため、人の手で更新する運用は構造的に間に合わないためです。連携ツールの導入か、API連携の実装が前提になります。
売り越しが起きたらどう対応すべきですか
まず購入者への連絡を最優先し、キャンセル処理と代替提案を同日中に行います。そのうえで、該当SKUの安全在庫を1段引き上げ、同期間隔を短縮します。原因を記録せずに個別対応だけで終わらせると、同じ事故が繰り返されます。
楽天市場だけの運用でも関係ありますか
はい、関係します。楽天市場内でも在庫連携ツール経由で他モールと在庫を共有していれば、同じ遅延問題が起きるためです。エージェント決済に直接対応していなくても、複数チャネルを持つ時点で同期設計の課題は共通します。
フィードの更新が反映されない場合の確認手順は
最終同期時刻、API のエラーログ、レート制限への抵触、SKU紐付けの3点をこの順で確認します。多くの場合は紐付けの破綻かレート制限のどちらかです。フィード側の値が変わっていないのに反映されないときは、送信そのものが落ちている可能性が高いと考えてください。
安全在庫を増やすと機会損失になりませんか
一定の機会損失は発生します。ただし売り越し1件あたりの対応工数と評価への影響を金額換算すると、多くのケースで安全在庫のコストを上回ります。プロンプト2の試算を使って、自店の数字で比較してから決めるのが確実です。
予約販売や受注生産の商品はどう扱いますか
在庫数ではなく、出荷までの日数を正確に出す設計にします。受注後発注の商品は安全在庫の設定が不要な代わりに、お届け予定日の精度が候補入りを左右します。ここを曖昧にすると、配送条件起因の注文失敗が増えます。
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
参考文献
- Google Merchant Center ヘルプ・質の高いデータを提供する
- Google Merchant Center ヘルプ・在庫フィード仕様について
- Google Merchant Center ヘルプ・商品情報の自動更新を許可する
- Google 公式ブログ・Agentic checkout for holiday AI shopping
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
