POSレジの在庫CSVを毎朝自動で取り込む方法｜手作業ダウンロードが件数上限で突然止まる前に決めておく取得方式と、古いデータで黙って動かさない仕組み

POSレジの管理画面から在庫一覧のCSVを毎朝ダウンロードして、Excelや集計の仕組みに放り込む。店舗とネット通販を両方持つ事業者では、ごく普通の運用です。ただ、この「毎朝の1手」は、ある日突然、しかも静かに止まります。

結論から書きます。在庫CSVの毎朝取り込みを自動化するときは、①取得方式は公式APIを第一候補にする、②取り込む前にファイルの中身を検証して、通らなければ配置しない、③当日分が無い朝は前日以前の在庫で動かしつつ「何日前のデータか」を必ず表示する——この3点をセットで作ります。 取得だけ自動にして②③を省くと、止まったことに誰も気づかないまま、古い在庫で製造や発注の判断が続きます。

この記事では、直営店・倉庫・工場・ネット通販の7拠点を持つ製造小売業で、約8万3千行の在庫CSVを毎朝自動で取り込んでいる仕組みをもとに、方式の選び方と守りの作り方を整理します。

手作業ダウンロードが止まる3つの理由

まず、「毎朝人が落とす」運用がなぜ続かないのかを押さえておきます。止まり方は3つあります。

1. 出力件数の上限に達する

POSの管理画面からのCSV出力には、件数の上限が設けられていることがあります。たとえばスマレジでは、在庫一覧のCSVダウンロードは出力対象10万件が上限で、超えるとダウンロードボタンが機能しなくなる旨が公式に告知されています（2019年12月のリリース）。

在庫一覧は「商品×色×サイズ×拠点」で行が増えるため、商品点数が多い事業者ほど上限に近づきます。実例の事業者では、店舗明細付きの在庫CSVが83,320行・42列・約28MB。上限の83%に達していて、残りは約1万7千行でした。新商品や新色を追加するたびに行は増えるので、ある朝、何の前触れもなくファイルが落ちてこなくなります。

2. 担当者がいない日に止まる

休み・出張・繁忙日。手作業の運用は、担当者の予定がそのまま単一障害点になります。実例でも、自動化前には2日続けて在庫CSVがアップされず、集計側が2日前の在庫で動いていた期間がありました。

3. 出力条件を選び間違える

在庫一覧のダウンロード画面では、出力形式（全店合計か店舗明細か）・改行コード・ヘッダーの有無を毎回選ぶ作りのものが多く、既定値が期待と違うこともあります。実例の画面は、毎回「全店合計」の形式で開く仕様でした。うっかりそのまま出すと、店舗ごとの在庫が消えたCSVが正常なファイルの顔をして取り込まれます。

3つとも、「エラーが出て止まる」のではなく「それらしいまま古い・欠けたデータで動き続ける」のが厄介な点です。

取得方式の選び方：APIを第一候補にする

毎朝の取得を自動化する方法は、大きく3つあります。

	①公式API	②既製の連携アプリ	③画面の自動操作
費用	契約プランに含まれることが多い	月額数百円〜	0円（保守の手間は続く）
壊れやすさ	低い	低い	高い（画面変更・ログイン仕様変更）
出力件数の上限	影響を受けない	製品による	そのまま引き継ぐ
規約	問題なし	問題なし	サービスによってはグレー

原則は①公式APIです。スマレジの場合、開発者向けサイトで自社専用の「プライベートアプリ」を登録すれば、審査なしで認証情報が発行されます。認証はアプリ単位のトークン方式で、人のログイン状態に依存しないため、夜間や早朝のバッチ処理に向いています。本番環境の取得は毎秒50回・1回1,000件まで取れるので、8万件規模でも1分かかりません。

ただし、APIに切り替える前に確かめておくべき点が3つあります。

• 在庫のAPIだけでは表が完成しない。在庫のAPIが返すのは「店舗・商品ID・在庫数・取置数・更新日時」程度で、商品名・色・サイズ・部門・品番は商品のAPIから取って結合する必要があります。在庫金額もAPIには無く、原価×在庫数で自前計算になります
• 一度も在庫が動いていない商品はレコードが存在しない。在庫が変動して初めて取得できる仕様のため、CSVと行数が一致しません。0で埋めるか、対象外にするかを先に決めます。行数の差を障害と誤認しないためです
• 管理画面では伏せていた項目が見えるようになる。実例では、画面から出すCSVでは在庫金額がマスクされていましたが、APIからは原価が取れます。自動化で「今まで見えなかった金額が見える」のは、便利さではなく権限設計の変更です。取り込む項目はクライアントと合意してから決めます

また、APIの利用には契約プランの条件があることが多いので（スマレジは上位プランが前提）、プラン差額を誰が負担するかも着手前に決めておきます。

②の既製アプリは、スケジュール取得の仕組みは合っていても、在庫が取得対象の項目に入っていないことがあります。無料体験があれば、まず対応項目を確認します。

③の画面の自動操作は、APIの権限が下りない・プラン条件を満たせないといった事情で、どうしても①②が使えない場合の次善策です。上限の問題はそのまま残り、画面が変わった日は取得できません。選ぶなら、次の章の守りを入れることが前提になります。実例の事業者は事情によりこの方式を選び、以下の守りを入れて運用しています。

取り込む前に検証する：通らなければ配置しない

取得方式が何であれ、取れたファイルをそのまま集計に渡してはいけません。取得処理は「何かのファイルを保存した」時点で成功を返してしまうからです。ログイン画面のHTMLを保存しても、途中で切れたファイルでも、処理としては成功に見えます。

実例では、取得したCSVを次の順に検証し、1つでも通らなければ集計フォルダに置かない設計にしています。

1. ファイルが0バイトでない
2. 先頭がHTMLではない（ログイン画面やエラー画面を保存していないか）
3. 想定サイズ（1MB）以上ある
4. 文字コードが想定どおりで読める
5. 列数が想定どおり（42列）
6. 必須の15列がすべてある
7. 行数が下限（6万行）以上ある
8. 最終行の列数が欠けていない（途中で切れていないか）

ポイントは6番です。先に書いた「全店合計の形式で出してしまう」ミスは、形式によっては列数が同じになる可能性があります。そこで各店舗の在庫数の列を必須列に入れておき、店舗別の列が無ければ弾くようにしています。列数だけの検証では、選び間違いを見逃します。

加えて、上限に近づいたら警告を出すようにしておきます。実例では99,000行を超えたら配置はしつつ「10万件上限に接近」と通知する設定です。上限に達してから慌てるのではなく、絞り込み出力や分割取得へ切り替える準備期間を作るためです。

検証の仕組みは、正常なファイルだけで確認しても意味がありません。0バイト・HTML・列不足・行数不足などの異常ファイルを意図的に作り、すべて弾かれることを確かめてから本番に入れます。

古いデータで黙って動かさない：鮮度を表示する

どれだけ守りを入れても、取得できない朝はあります。そのときの正しい動き方は、「止める」でも「黙って続ける」でもありません。

前日以前の在庫で処理は続けつつ、画面やレポートに「採用したのは何日前のデータか」を必ず出す。これが実務的な落としどころです。

実例では、集計側が毎朝最新の在庫CSVを探し、当日分が無ければ次のような警告を出します。

「⚠️本日分の在庫CSVがありません。採用したのは2日前（9/16）です」

在庫の判定結果にも「（2日前の在庫）」と付くため、見た人が「この数字は古い」と分かります。処理を止めてしまうと、その日の製造指示や受注の照合まで全部止まるので、影響が大きすぎます。逆に黙って続けると、古い在庫を正と信じて判断することになります。続けるが、隠さない。これが両方の事故を避ける形です。

この警告があったおかげで、手作業の時代に2日間在庫が止まっていたことも、画面を見た時点で分かる状態になっていました。自動化した後も、この表示は残しておきます。自動取得が止まった日にも同じように効くからです。

毎朝の運用設計で決めておくこと

最後に、仕組みを組む段階で決めておくと後から困らない項目をまとめます。

ファイルの置き方は「追加のみ」にする

取得したCSVは、既存のファイルを上書き・削除せず、日時入りのファイル名で追加します。実例では「在庫一覧_商品別（店舗明細）(YYYYMMDDHHMMSS).csv」という元の命名を維持し、集計側がこの日時で最新を選ぶ作りです。ファイル名の形を変えると最新の判定が狂うので、命名規則は変えないのが原則です。

後続の処理と時刻をずらす

実例では、在庫取得を6:45、受注の取り込みを7:00、受注と在庫の再照合を7:40、製造判断の集計を8:00に置いています。取得を7:00にすると受注の取り込みと同時になり、その回が前日在庫で動いてしまうため、15分前倒しにしました。取得が遅れた朝でも、7:40の再照合で当日在庫に追いつく二段構えです。

失敗しても後続を止めない

取得に失敗したら120秒おきに2回まで再試行し、それでもだめなら終了コードで「取得失敗」「検証NG」「未設定」を区別して記録します。後続の処理は止めず、前述の鮮度表示で古いデータであることを伝えます。

保存期間を決める

28MBのCSVが毎日増えると、月に約850MBになります。実例では「使用中のファイルは無条件で残す→直近3日分は残す→毎月1日分は退避フォルダへ→それ以外は削除」の順で自動整理し、164MBあったフォルダを110MBに減らしました。運用開始時点の最初の1本は、後から検証の基準にするので必ず残します。削除処理は最初に試し実行（削除対象の一覧を出すだけ）で確かめてから有効にします。

認証情報の置き場所を分ける

画面操作でもAPIでも、ログイン情報や認証キーを扱います。クラウド同期のフォルダやソースコードの管理対象には置かず、端末ローカルの権限を絞ったファイルに置きます。実例では、権限が緩いファイルからは起動自体を拒否するようにしています。

画面操作を選ぶ場合に想定しておくリスク

APIが使えず画面の自動操作を選ぶ場合、壊れる箇所はほぼ決まっています。事前に想定しておくと、止まった日の復旧が早くなります。

• ログイン画面に古い入力欄が隠れて残っていることがある。見た目どおりの欄を指定しないと、隠れた方に入力して失敗します。入力欄は種類ではなく名前で指定します
• 在庫アラートなどのパネルが、ダイアログと同じ扱いで画面に存在することがある。「最初に出たダイアログ」を掴むと、目的のダウンロード設定ではない方を操作します
• 選択肢がプルダウンではなく、隠れたラジオボタンとトグルの組み合わせになっていることがある

いずれも、画面の部品を指定する情報を設定ファイルに分けておけば、画面が変わってもコードを直さずに追従できます。失敗したときに画面のスクリーンショットとHTMLを自動で残すようにしておくと、原因の特定が速くなります。

なお、自動化してみると取得そのものは速く、実例ではログインからダウンロード完了まで約7秒でした。重さを心配するより、画面変更で止まった日をどう検知するかに設計の手間をかけるべきです。

まとめ

• 在庫CSVの手作業ダウンロードは、出力件数の上限・担当者の不在・形式の選び間違いで、エラーを出さずに止まる
• 取得方式は公式APIが第一候補。ただし商品情報との結合、変動の無い商品の扱い、見えるようになる原価の権限を先に決める。画面操作は次善策
• 取り込む前に中身を検証し、通らなければ配置しない。店舗別の列を必須にして形式の選び間違いを弾き、上限の手前で警告を出す
• 当日分が無い朝は処理を続けつつ「何日前のデータか」を表示する。止めず、隠さない
• ファイルは追加のみ、後続と時刻をずらし、保存期間と認証情報の置き場所を最初に決める

実例の事業者では、この仕組みで在庫の取り込みが4日連続で正常に回り、在庫CSVを落とす手作業はゼロになりました。「毎朝のダウンロード」が業務に残っているなら、上限に達する前に方式と守りを決めておくのが安全です。

在庫データをAIの判断に使う場合の設計は「AIに在庫管理を任せるときの設計｜計算はシステムに、判断だけをAIに分ける」、自動処理が成功と出ているのにデータが止まる問題は「自動処理が「成功」と出ているのに反映されないとき」でも整理しています。