在庫同期のトラブルで、いちばん高くつくのは「壊れたこと」ではありません。「壊れたことに気づかなかった時間」です。同期が3日止まっていた店舗と、3時間で気づいた店舗とでは、後始末の手間がまったく違います。前者は棚卸しからやり直しになり、後者はシートを直して1回流すだけで済みます。
そして残念なことに、在庫同期は自分から「壊れました」とは言ってくれません。この記事では、在庫同期の異常に早く気づくために何を見張ればよいのか、そしてそれを大がかりな監視基盤なしに実現する方法を考えていきます。必要なのは、いくつかの小さな仕掛けと、鳴ったときに動ける準備だけです。
在庫同期は「静かに」止まる
監視の話を始める前に、そもそも在庫同期がどう壊れるのかを確認しておきましょう。壊れ方が分かれば、どこに目を光らせるべきかが自然に見えてきます。
成功ログは健康診断ではない
同期のログが「成功」と表示していても、それは処理がエラーなく終わったという意味でしかありません。対象のSKUがゼロ件でも、処理は成功します。シートの範囲指定がずれて空の行だけを読んでいても、成功します。エラーがないことと、正しく仕事をしたことは別なのです。
この違いは、監視を設計するうえでの出発点になります。見るべきは「エラーが出ていないか」ではなく「意図したことが起きたか」です。前者だけを見ていると、いちばん静かで、いちばん長く続く種類の障害を丸ごと見逃すことになります。ログに何を残しておくべきかは、同期ログを監査ログとして使うにまとめています。
止まり方には3種類ある
在庫同期の停止は、大きく3つに分けられます。ひとつめは、同期そのものが走らなくなるケース。スケジュールが解除された、認証が切れた、シートの共有設定が変わった、といった原因が典型です。これは比較的分かりやすい停止で、気づけば原因もすぐ見つかります。
ふたつめは、走っているのに何も更新しないケース。シートの列や行がずれた、対象範囲が空になった、といった状況です。そして3つめが、更新しているのに中身が間違っているケース。列を1つずらして読んでいて、別のSKUの数字を書き込んでいる、というのがこれにあたります。3つめがいちばん見つけにくく、被害も大きくなります。
この3つのうち、実際に起きやすいのは2つめと3つめです。1つめの「そもそも走らない」は認証やスケジュールの問題なので、多くの場合はどこかに記録が残ります。ところが2つめと3つめは、シートを開いた誰かの何気ない操作から始まります。列を1つ挿入する、フィルタをかけたまま閉じる、行を並べ替える。どれも悪意のない操作です。
つまり監視の設計では、システムの故障よりも人の操作を前提に置いたほうが実態に合います。シートは誰でも開けて誰でも直せるという良さがあり、その良さの裏側にこのリスクがあります。共有範囲を絞ることも対策のひとつですが、開ける人を減らしすぎると今度は運用が回らなくなります。
気づくまでの時間がそのままコストになる
在庫同期の障害コストは、ほぼ経過時間に比例します。止まった直後は、シートとShopifyの差はゼロです。差が広がるのは、その後に売れたり入荷したりしたぶんだけ。つまり1日止まれば1日分、1週間止まれば1週間分の乖離が積み上がります。
この性質は、監視への投資判断をとても分かりやすくしてくれます。完璧な監視は必要ありません。「1週間気づかない」を「1日で気づく」に変えるだけで、被害の大半は防げます。目指すべきは精度ではなく、気づくまでの時間を短くすることです。
何を見張ればよいのか
見張るべき対象は、意外なほど少なくて済みます。走ったか、変わったか、合っているか。この3つを押さえれば、さきほどの3種類の停止をそれぞれ捕まえられます。ひとつずつ見ていきましょう。
走ったかどうか（実行の有無）
いちばん基本的な確認は、同期が予定どおり実行されたかです。スケジュール同期を設定している場合、毎朝の実行記録があるかを見るだけで、1種類目の停止は捕まえられます。実行記録の日付が昨日のままなら、何かが起きています。
この確認は自動化するまでもなく、朝の業務開始時に画面を1回見るだけで足ります。むしろ人の目で見るほうが、「そういえば先週も遅かった」といった気づきが生まれやすい。監視というと自動化を考えがちですが、毎日決まった時刻に見る習慣は、それ自体が立派な監視です。
気をつけたいのは、認証の期限切れです。同期のためのアクセス権は、パスワード変更や権限の見直し、担当者の退職といった出来事で切れることがあります。そしてこの種の停止は、Shopifyやシートの側では何も壊れていないので、いっそう気づきにくい。実行記録の日付だけが、静かに止まったままになります。
社内でアカウントまわりの変更があった週は、翌日の実行記録を意識して確認しておくと安心です。退職や異動の手続きと在庫同期は、普段まったく別の話として扱われています。この2つが実はつながっていると知っているだけで、防げるトラブルがあります。
何かが変わったか（更新件数）
次に見るのは、その実行が実際に何件のSKUを更新したかです。普段は毎日30件前後が更新されている店舗で、更新件数が0件だった日があれば、それは異常のサインです。逆に、普段30件の店舗で急に800件が更新されていたら、それも確認する価値があります。
件数の異常は、シートの構造が変わったときに出やすいシグナルです。誰かが列を挿入した、フィルタをかけたまま保存した、行を並べ替えた。こうした操作は悪意なく起きますし、本人も気づいていません。件数という一次元の数字が、そうした変化を代表して知らせてくれます。
数字が合っているか（精度）
3種類目の「更新しているのに中身が違う」を捕まえるには、実際の数字を突き合わせるしかありません。ただし全商品を毎日照合する必要はなく、売れ筋の数SKUを定期的に見るだけで十分に効果があります。中身が間違っている障害は、たいてい全体に一様に影響するからです。
突き合わせるときは、シートの数量とShopifyの手持ち在庫を比べます。販売可能と比べると、未出荷注文のぶんだけ小さく出て毎回ずれて見えるので注意してください。比較対象を正しく選ぶだけで、この確認は「毎回ずれている謎の作業」から「異常だけが目立つ作業」に変わります。精度をどう測るかは、在庫同期を測る4つの数字で具体的に説明しています。
- 走ったか — 実行記録の日時。スケジュールの解除や認証切れを捕まえる
- 変わったか — 更新件数。シートの構造変化を捕まえる
- 合っているか — 主要SKUの突き合わせ。マッピングのずれを捕まえる
- 比較相手は販売可能ではなく手持ち在庫。ここを間違えると毎回ずれて見える
アラートを組み立てる
見るべきものが決まったら、次は通知の仕組みです。専用の監視ツールを導入しなくても、Shopifyの標準機能とスプレッドシートの工夫だけでかなりのところまでいけます。
Shopify Flowで在庫の動きを拾う
Shopifyが提供するShopify Flowというアプリを使うと、在庫の変化をきっかけに通知を送るワークフローを作れます。「商品バリエーションの在庫数量が変更された」というトリガーがあり、注文・手動の変更・アプリによる変更といった変化の発生源も条件に使えます。
低在庫の通知テンプレートも用意されており、在庫がしきい値を下回ったときにメールやSlackで知らせる設定が数クリックで作れます。「在庫が5未満になったら通知」のように、しきい値をまたいだときだけ鳴らす条件の書き方も公式のヘルプに解説があります。
シート側に「カナリア」を置く
同期が生きているかを確かめる、とても手軽な方法があります。シートの中に、監視専用の行をひとつ用意するのです。実際には販売していない検証用のSKUを1つ用意し、その数量を毎日変える。Shopify側でその数字が変わっていれば、同期は間違いなく生きています。
この仕掛けの良いところは、3種類の停止をまとめて検出できることです。走っていなければ数字は変わりませんし、範囲がずれていれば読まれません。数字が変わっていれば、シートからShopifyまでの経路が丸ごと通っている証拠になります。確認は10秒で終わります。
検証用のSKUを作るときは、公開されない形にしておくのを忘れないでください。商品としては下書きやアーカイブの状態にしておき、ストアフロントには出さない。在庫追跡だけは有効にしておく必要があるので、設定の組み合わせは一度確認しておきましょう。
数量の決め方にもコツがあります。日付の下2桁を入れる、あるいは1と2を交互に切り替える、といった規則にしておくと、期待値が一目で分かります。「今日は21のはず」と分かっていれば、Shopify側を見た瞬間に判断できます。ランダムな数字を入れるより、規則があるほうが確認は速く終わります。
鳴りすぎるアラートは、鳴らないのと同じ
アラートを組むときに必ず陥る罠が、通知の出しすぎです。在庫が動くたびに通知を送る設定にすると、1日に何十通も届き、2週間もすればフォルダに自動振り分けされて誰も見なくなります。これは監視がない状態より危険です。あるつもりで、実際にはないのですから。
対策はシンプルで、通知の条件を「対応が必要なとき」に絞ることです。在庫が減ったこと自体は正常な出来事なので通知は不要。しきい値を初めて下回ったとき、同期が予定時刻に走らなかったとき、更新件数がゼロだったとき。人が何かをする必要がある瞬間だけを鳴らします。
アラートが鳴ったあとの話
監視の設計で見落とされがちなのが、鳴ったあとです。通知が届いても、何をすればよいか分からなければ状況は変わりません。ここでは、鳴ってからの動き方を決めておく方法を紹介します。
最初の5分でやること
- 01同期の実行記録を開き、最後に成功したのはいつかを確認する
- 02シートを開き、列の位置と対象範囲が変わっていないかを見る
- 03検証用SKUの数字がShopifyに届いているかを確認する
- 04主要SKUを3つほど選び、シートの数量とShopifyの手持ち在庫を突き合わせる
- 05原因が特定できなければ、その時点のシートを複製して保全してから調査を続ける
最後の項目は地味ですが重要です。調査の途中でシートを触ると、元の状態が分からなくなります。Googleスプレッドシートには変更履歴が残るので復元は可能ですが、複製を1枚取っておくほうが確実で速い。焦っているときほど、この一手間が効きます。そのあとの復旧手順は、間違った在庫を同期してしまったときの戻し方にまとめました。
手順を1ページにまとめておく
上の手順は、シートのタブか社内の共有ドキュメントに1ページで書いておきましょう。分量は1画面に収まる程度で十分です。長い手順書は読まれませんし、そもそも緊急時に長文を読む余裕はありません。5行から10行くらいが現実的な上限です。
書いておくべきは手順だけではありません。誰に連絡するか、どの画面を開けばよいか、認証の再設定は誰ができるか。こうした情報が1ページにまとまっていると、担当者が休みの日でも別の人が動けます。属人化を防ぐという意味でも、この1ページの効果は大きいです。
月に一度、アラート自体を見直す
アラートは作ったら終わりではありません。月に一度、過去1か月に鳴った通知を振り返り、それぞれが実際に対応を要したかを確認します。一度も対応不要だった通知は、条件を厳しくするか止める候補です。逆に、通知なしで見つかった問題があれば、そこに新しい監視を足します。
この振り返りを続けると、通知の数はだんだん減り、届いた通知の重みは増していきます。理想は「めったに鳴らないが、鳴ったら必ず見る」状態です。数か月かけてこの状態に近づけていくつもりで、最初から完璧を目指さないのがうまくいくコツです。
在庫同期の監視は、大がかりな仕組みを必要としません。走ったか、変わったか、合っているか。この3つを見て、対応が必要なときだけ鳴るようにして、鳴ったときの手順を1ページ書いておく。これだけで、障害に気づくまでの時間は劇的に短くなります。
そして忘れないでほしいのは、監視の価値は防いだトラブルの数では測れないということです。何も起きない日が続くのは、監視が無駄だった証拠ではなく、うまく機能している証拠です。静かに壊れる仕組みに対しては、静かに見張り続けることが、いちばん確実な備えになります。