赤兎馬EC運用支援
「自動化は動いているはず」——朝を見たら1本欠けていた、というのはEC運用の自動化でも普通に起きる話です。原因の多くは「失敗そのもの」ではなく、失敗を誰も再試行しない設計にあります。
この記事は自社パイプラインの実話をもとに、EC運用の自動化に効く3つの設計をまとめたものです。
深夜0時、6回連続で失敗した話
2026年9月4日、自社SNS向けにショート動画を毎時生成して予約投稿する自動パイプラインで、深夜0時すぎに画像生成側のAIサービスが約5分にわたって404と再接続エラーを返し、6回の試行が全滅しました。1時間後の実行からは正常に戻っていたのに、旧実装は「失敗理由を問わず行を『エラー』で固定する」仕様だったため、誰も再試行せず、翌朝の投稿枠が1本欠けた——それだけの事故です。
「失敗した」ことより「失敗を握りつぶしたこと」が事故の本体でした。EC運用の自動化も、たいてい同じ構造で穴が空きます。
設計①：一時障害と恒久障害を分ける
すべての失敗を1つの「エラー」に潰すと、原因も対処も分からなくなります。まずは判断基準を if-then で分けるところから始めます。
- 一時障害（5xx / 404 / タイムアウト / 接続断）→ 自動再試行の対象にする
- 恒久障害（認証切れ / 権限剥奪 / パラメータ不正）→ 人に通知して止める
- 原因不明→ まず「原因を記録に残す」設計に直す（潰す前に見える化）
「不明な失敗」をエラーで固定してしまうと、後日集計しても何も分かりません。分類より先に「理由を残す」が来ます。
設計②：再試行は上限つき（同じ行が枠を占有しない）
一時障害と判定した行は「未処理」に戻し、次の毎時実行に自動で拾わせます。ただし上限は2回。3回目以降は「エラー」で固定します。
上限を切らないと、根本原因が恒久障害だった場合に同じ行が延々とスロットを食い、後続の枠まで巻き添えにするからです。
- 上限2回 → 一時的な瞬断はほぼ吸収できる
- それでも回復しない → 原因は別（恒久障害の可能性が高い）→ 人が見に行く
「無限リトライ」は別の事故を生みます。上限は必ずつける。
設計③：通知に「原因タグ」を1行つける
失敗通知の本文に「原因タグ」を1行足しました。直近14日の集計で効果が見えました（社内記録の実測に基づく仮の内訳としてお読みください）。
- 配信失敗 13件中、10件が動画ファイル置き場の瞬断（503）
- チャンネル側の拒否ではないと、通知だけで判断できるようになった
「失敗しました」だけの通知だと、毎回ログを掘り直すコストがかかります。原因タグ1行で、翌朝の対応時間が変わります。
EC実務ではどこに効くか
同じ構造は、EC運用の自動化にもそのまま乗ります。とくに「止まったら困る処理」ほど、分類・上限・原因通知の3点を最初から設計に入れておくのが安全です。
- 価格監視：モール側の一時的な503を「取得失敗」で固定してしまうと、次回もリトライされず競合追随が止まる
- 在庫連携：一時障害の握りつぶしが最悪の連鎖を生む——欠品 → カート喪失 → 広告の空振り、と広告後粗利に直撃する
- 広告レポート取得：API側の一時障害でレポートが飛ぶと、翌日のACoSモニタリングが空白になり、判断が丸1日遅れる
とくに在庫連携は、失敗を静かに握りつぶしていると、気づいた時には広告費が空回りしていた、という事故に直結します。
まとめ：止まらないことではなく「止まり方」を設計する
自動化は「止まらないこと」ではなく、止まり方を設計することが本体です。
- 失敗の分類（一時 / 恒久 / 不明）
- 再試行の上限（無限リトライは別の事故を生む）
- 原因つきの通知（1行で運用コストが変わる）
自社の自動処理が、どこで、どんな失敗を、どう握りつぶしているか。一度棚卸ししてみてください。
店舗URLでの無料EC診断もやっています：https://ec-sekitoba.jp/#contact