蔵前倉庫 運用マニュアル v2 — 現場メンバー向け

0. はじめに(本書の読み方・用語ミニ辞書)

0-1. 想定読者

• 蔵前倉庫(7110)の倉庫オペレーター
• 山本山 EC / 物流チームの商品・モール管理担当
• 新規参画メンバー(オンボーディング教材として)

0-2. 本書のスコープ

0-3. 操作主体の表記ルール

本書では各操作の冒頭に 「マーチャント側」 または 「オペレーター側」 を明示する。これは ロジレスの 2 つのアカウント区分 を指す。

編集権限の境界: 出荷作業中 の伝票はマーチャント側からはロックされ編集不可。編集したいときは「出荷待ちに戻す」で物理引当解除 → 編集 → 「出荷作業中へ移動」で再開。

0-4. 用語ミニ辞書

1. 早見表

1-1. ステータス遷移

[受注] → 確認待ち → 引当待ち → 出荷待ち → 出荷作業中 → 出荷済み
            ↑ ↓                                   ↑
         (対応済み)                         (送り状番号 UP)

1-2. 受注伝票ステータス別「触っていいか」

1-3. 在庫ステータス

1-4. F3(商品分類)6 値

1-5. 引当不可日数(代表値)

完全表(F4 リスト外・警告ケース等)は 第 7 章 §7-5。

1-6. 商品コード規則

新規登録分は機能1 STEP 3-2 で 3 コード統一が完結する。

1-7. 倉庫 ID

2. 毎日のフロー(受注〜出荷)

2-1. 受注〜出荷の通常フロー(STEP 1〜10)

2-2. POS 注文の扱い(物販モデル)

POS 注文(店頭販売)は Shopify Flow で自動処理。基本的にオペレーターは何もしなくてよい。

1. 店頭で POS 購入が発生
2. Shopify Flow が「物販」タグを付与し、fulfillment を解除
3. ロジレスが通常通り受注取込(注文から 30 分後に取り込まれる)
4. マクロで「物販」タグの注文は蔵前倉庫に振り分け、出荷モデル「物販」に分類
5. Shopify 側はロジレス取り込み後に Flow で fulfillment 完了

オペレーターがやること: 毎日(または数日に 1 回)、物販モデルで該当出荷グループを「出荷完了」にするだけ。物理出荷は店頭で既に完了。

2-3. 受注後の編集が必要な項目(よくハマる)

2-3-1. 出荷伝票側で編集が必須な項目

受注編集だけでは出荷予定日が追従しない(別フィールド)。出荷予定日が古いままだと、出荷モデルの絞り込みから漏れて出荷されない事故が起きる。

2-3-2. お届け希望日変更時の手順

1. 受注詳細画面でお届け希望日を変更 → 保存
2. メインナビ「出荷」→ 該当の出荷伝票を開く
3. 出荷伝票の「配送方法」編集から 出荷予定日を変更 → 保存

出荷作業中の伝票なら「一括処理 → 編集」から出荷予定日を変更できる。

2-4. イレギュラー対応(章別ハイライト)

より章横断のトラブル早見表は 第 11 章 困った時。

2-5. 毎日のチェックリスト

• 朝: 確認待ちタブを 0 にする(STEP 1)
• 午前: 出荷待ち → 出荷作業中 へモデル選択で移動(STEP 2)
• 午前〜午後: PL 印刷 → 送り状 CSV 出力 → e 飛伝 III で送り状発行(STEP 3-4)
• 午後: ピッキング → MP 出荷検品 → 梱包(STEP 5-7)
• 集荷待ち中: 突合ファイルの準備(まだ取得しない、集荷後)
• 集荷後: 引渡書出力 → shukka_rireki DL → 機能7 で突合 → ロジレスへアップロード(STEP 8-9)
• 夕方: 事後確認(ロジレス出荷済み / Shopify 追跡反映)(STEP 10)

3. 入荷

3-1. 入荷の全体像

入荷は 「予定登録 → 入荷の登録」の 2 段構成 が基本。予定なし入荷は 2 段を飛ばして 1 段で済ませる。

[CON-NECT 発注履歴の予定]
        ↓ マーチャント側 (機能5)
[ロジレス: 入荷予定 = 入荷待ち]
        ↓ 予定表を印刷 → 現場手書き
[現場で実数・賞味期限・ロケを記録]
        ↓ オペレーター側 (機能3 予定あり / 機能4 予定なし)
[ロジレス: 在庫 = 保管中]

3-2. 入荷予定登録(機能5・マーチャント側)

/tool/inbound-schedule (サイドバー → 入荷 → 入荷予定登録)

CON-NECT 発注履歴 の 3 列(型番 / 個数 / 入荷予定日)を CSV にしてツールに食わせる → 型番 → 商品コード変換 + 予定日ごと分割 → ロジレスに直接登録 or CSV DL。

3-2-1. なぜ予定日ごとに分割するか

3-3. 入荷予定表の印刷と現場手書き

ロジレスの入荷予定帳票は型番が出せない・予定日フィルタが効かないなどの制約があるため 使わない。代わりに CON-NECT 発注履歴 を印刷ルートで使う。

1. CON-NECT 発注履歴 で当日入荷分の範囲を選択
2. そのまま印刷
3. 現場の倉庫オペレーターに渡す

倉庫メンバーは紙を持って受け入れに入り、検品しながら 紙に直接書き込む:

• 実数(予定数と違ったら数量を上書き)
• 賞味期限(出荷期限日、商品ごと)
• ロケーション(どの棚に入れたか)

この紙が、後段の入荷登録(機能3)の入力ソースになる。

3-4. 入荷登録(機能3・オペレーター側、予定あり)

/tool/inbound (サイドバー → 入荷 → 入荷(予定あり))

ロジレスの入荷予定 API を直接取得 → 編集テーブルで実数・期限・ロケを入力 → 6 列 CSV 生成 → ロジレスにアップロード。手書きの入荷予定表を見ながらツール画面に入力していく。

山本山のオペレーターアカウントは 蔵前専用 のため、倉庫選択ステップは発生しない。

3-4-2. 数量超過の扱い

実数 > 予定数 の場合、実数欄にそのまま超過分含めた値 を入れる。

• 例: 予定 30 個 → 実数 35 個 なら、CSV には 35 と書く
• ロジレスは超過分含めて全量入荷する(エラーは出ない)
• 入荷予定の「未入荷数量」にマイナス値(-5)が記録されるが、ステータスは「入荷済み」
• 予定分と超過分を分けて投入する必要はない

3-4-3. 予定外 SKU が混ざった時

予定にない SKU が一緒に届いた場合(緊急出荷分が予定分と同タイミングで届いたなど)、同じ CSV に混ぜて OK。予定外 SKU 行は 入荷予定コード列を空欄 にする。

ロジレスは行ごとに「コードあり = 予定消込」「コードなし = 強制処理」を自動的に切り替える。

3-5. 緊急現物入荷(機能4・予定なし)

/tool/inventory-op (サイドバー → 入荷 → 入荷(予定なし)、機能4 入荷モード)

予定登録が間に合わなかった現物入荷・返品再在庫・部署間在庫移動など。

入荷予定コード列がない 5 列 CSV。出庫 CSV(第 4 章 §4-2)と完全同形式 なので、ファイルを相互転用できる。

3-6. ロケーション選定の考え方

CSV の「ロケーション名」列に何を入れるかの判断基準。

3-6-1. 基本ルール

1. 既存在庫があるロケに集約(同じ商品コードの保管中ロケを優先)
2. 複数ロケに分散している商品は、アルファベット昇順 + 数字昇順で 最も若いロケ に集約(B1 > B3、B1 > C1)
3. 初回入荷で既存ロケがない商品は、空きロケから選ぶ

3-6-2. W1 / W2 は使わない

W1 は _S 品(訳あり版 SKU)の販売棚、W2 は 判断保留・廃棄予備の引当不可棚。どちらも通常入荷では候補から外す。訳あり処理(第 6 章)の対象になった在庫だけがここに入る。通常入荷で訳あり商品が入ってくる場合は使う。

3-7. アップロード先フォーマット早見表

3-8. イレギュラー対応

3-9. よくある質問

4. 在庫操作

4-1. 在庫操作の全体像

在庫を直接動かす操作は 3 系統。入荷(第 3 章)が「予定 → 入荷」の 2 段だったのに対し、ここはどれも 1 段で完結。CSV をアップロードした瞬間(または API 直接登録ボタンを押した瞬間)に在庫が動く。

棚卸の差分処理(第 5 章)と訳あり振替(第 6 章)は、結果的に出庫 / 棚移動 CSV を使う場面があるが、運用としては別章の独立フロー。本章では 単発の在庫調整 に絞る。

4-2. 出庫(機能4 出庫モード)

/tool/inventory-op (サイドバー → 出荷 → 出庫)

ロジレスの保管中在庫から出したい行を選び、5 列 CSV を生成 → ロジレスにアップロード。

用途

• W2 に集めた在庫の 廃棄
• 破損品・サンプル提供などの想定外減
• 部署間の在庫移動で「出す側」
• 返品処理に伴う在庫調整

予定なし入荷 CSV(第 3 章 §3-5)と完全同形式。倉庫 ID(7110)はフォーマット側に埋め込み、CSV 本体には出ない。

4-2-2. 在庫超過は弾かれる

ロジレスは 在庫超過の出庫 CSV を完全ブロック する(「出庫数量が N 個、収容中数量が M 個なので超過しています」エラー、部分処理なし)。出庫 CSV を作る前にツール側で残数を検証してブロックする仕組みなので、現場側で気にする必要は少ないが、サジェスト時点のキャッシュとロジレス側の最新の差分でズレる可能性があるので 再読込しておくと安全。

4-2-3. ロケと期限を正確に指定する

同じ商品でも複数ロケ・複数期限に在庫が分かれていることがある。出庫 CSV ではどのロケのどの期限の在庫を減らすかを明示する必要があり、ツールはサジェストから選ばせる UI で取り違えを防いでいる。

特に注意: 引当不可ロケの長い名前(「引当不可(自動処理):株式会社山本山(マーチャント):YYYY/MM/DD」または retirement_*)は 1 文字でもズレるとエラー。サジェストからのコピペで完全一致させる(手で打たない)。

4-2-4. 重複行があると合算される

同じ「商品 × ロケ × 期限」で複数行を投げると、ロジレスは 合算処理 する(10 個 + 5 個 → 合計 15 個出庫)。エラーにはならないが、意図して合算させたいケース以外は CSV 側で 1 行にまとめておくのが事故が少ない。

4-3. 棚移動(機能6)

/tool/shelf-move (サイドバー → 在庫調整 → 棚移動)

同じ商品をロケ間で動かす 6 列 CSV を生成 → ロジレスにアップロード。引当不可ロケ → W2 一括集約はワンボタン。

用途

• 引当不可ロケから W2 への集約(最頻出、§4-4 参照)
• 通常ロケ間の整理(A1 → B1 など、倉庫レイアウト変更時)
• W2 から通常ロケへ戻す(販売判断が変わって受注引当を再開する場合、保留 → 保管中 に復帰)

4-3-2. 通常ロケ ⇄ 引当不可ロケのステータス自動変換

棚移動先のロケの種類によって、在庫ステータスが自動で切り替わる。

W1 は引当可能ロケ。W 系だからといって自動的に保留にはならない。

4-4. 引当不可ロケの集約運用(W2 集約)

引当不可ロケまわりは運用が 2 段階。本章のスコープは第 1 段階(W2 集約)まで。第 2 段階(_S 振替 / 廃棄判断)は 第 6 章。

4-4-1. 第 1 段階: 自動生成の引当不可ロケ → W2 集約

ロジレスは、商品マスタの「引当不可日数」を超えた在庫を 自動生成された引当不可ロケ(「引当不可(自動処理):…」または retirement_*)に 仮想移動 する。物理的にはまだ元のロケに置かれているが、システム上は引当対象外になる。

ロジレスには「自動生成ロケから固定ロケに集約する機能」が標準で存在しないため、手作業で W2 に集める運用 になっている → 機能6 ワンボタン集約で一発化。

1. 機能6 → 📦 引当不可ロケを W2 に一括集約 ボタン押下
2. 移動先 = W2 で自動入力された行リストを確認
3. CSV DL → ロジレス棚移動一括登録 → 全件 W2 に集約

頻度: 日次〜週次(運用しやすい頻度で)。

4-4-2. 第 2 段階(参考)

W2 に集まった在庫の処置(_S 振替 / 訳あり化 / 廃棄)は 第 6 章 訳あり処理(機能9) で扱う。判断フローは:

_S 版が登録されているか?
 ├─ No  → 廃棄(機能4 出庫モードで W2 から減算)
 │       or 第 7 章 で _S 版を登録してから _S 振替へ
 └─ Yes → 期限が引当不可日数より 30 日以上残っているか?
           ├─ No  → 廃棄(機能4 出庫モード)
           └─ Yes → 改廃品か?
                     ├─ Yes → 訳あり化(機能9 タブ2、SKU 不変)
                     └─ No  → _S 振替(機能9 タブ1、SKU 変更)

4-5. 倉庫移動(蔵前 → ココドット)

4-5-1. 基本フロー(機能4 出庫 + 機能5 入荷予定)

4-5-2. フォールバック手順(機能10、期限管理不要時のみ)

機能10 は以下のフォールバック用途のみ:

• 期限管理が完全に不要な商品(F3=資材 / グッズ で attr4=0/空欄)
• 機能4 + 機能5 の通常運用がどうしても回らないときの応急処置

エンコーディング: UTF-8 BOM、改行: CRLF、クオート: 全フィールド "。LOGILESS 側フォーマット定義は data/import_format_72733.json。

4-6. アップロード先フォーマット早見表

4-7. イレギュラー対応

4-8. よくある質問

5. 棚卸

5-1. 棚卸の全体像

棚卸は 「実数を理論で上書き → 棚卸サマリー DL → 現場で実数記入 → 差分行だけ CSV 化 → アップロード → 確定」の 6 ステップ 運用。ロジレス公式推奨フローに従う。機能8 ツールが担うのは STEP 5 の差分行抽出 + 5 列 CSV 化 のみ、その他はロジレス画面で実施する。

棚卸の種類

• 全体棚卸: 四半期〜半年に 1 回
• 部分棚卸: ロケ単位 / SKU 単位で差分発覚時に随時
• 引当不可ロケ確認: W2 集約の頻度に合わせて(第 4 章 §4-4)

5-2. 棚卸前の準備(必須 3 点)

棚卸を始める前に、以下 3 つを必ず完了させる。1 つでも漏れると棚卸が壊れる。

5-2-1. ピッキング中残のゼロ化(最重要)

ピッキング中の在庫は、保管状況 CSV で保管中数から自動的に差し引かれて出力 される(独立列がない)。例: 保管中 10 個・ピッキング中 3 個 → CSV には保管中 = 7 と記録。

ピッキング中残がある状態で棚卸すると、ピッキング中分が カウントから消失 する。

1. その日の出荷作業をすべて完了させる(出荷済みステータスまで)
2. 「保管状況」メニューでピッキング中 = 0 を確認
3. ゼロにできない伝票がある場合は、出荷待ちに戻すか、棚卸を後ろ倒し

5-2-2. 引当不可ロケの W2 集約

自動生成の引当不可ロケ(retirement_*)に在庫が残ったまま棚卸すると、長いロケ名(「引当不可(自動処理):株式会社山本山(マーチャント):YYYY/MM/DD」)を実地棚卸 CSV で扱う羽目になる。

棚卸前に 機能6 の W2 ワンボタン集約(第 4 章 §4-4-1)で引当不可ロケの在庫を W2 にまとめておく。

5-2-3. 関係者への周知

棚卸の実行中、ロジレスは以下を 凍結 する:

• 在庫操作(入荷・入庫・棚移動・出庫・変換)
• 出荷作業の開始
• 出荷作業中から出荷待ちに戻す操作

開始前にオペレーター・マーチャント双方に 開始予定時刻と終了予定時刻を共有。急ぎの出荷案件があるなら棚卸開始前に出し切っておく。

5-3. 棚卸の 6 ステップ

5-4. 実地棚卸 CSV の仕様

5-4-1. 「実際の在庫数」は絶対値方式

ロジレスは絶対値方式(実数で上書き)と符号付き方式(差分で加減)の両方に対応するが、山本山運用は絶対値方式で統一。例: 理論 17・実数 15 → CSV には 15 と書く(-2 ではない)。

5-4-2. ロケーション名はコピペ厳守

棚卸在庫サマリー CSV(8 列)の「ロケーション」列からそのままコピー。特に引当不可ロケ(W2、retirement_*)は 1 文字違いでもアップロード時にエラー。

5-4-3. 期限の扱いの罠

5-4-4. ロット番号は空欄

山本山運用ではロット番号を使わない。すべて空欄で OK。

5-4-5. 保管中と保留はロケ名で自動振り分け

実地棚卸 CSV(5 列)には「保管中 / 保留」を区別する列がない。代わりに ロケ名でロジレスが自動判定。

5-5. ケース別の処理パターン

パターン A: 通常の差分調整(最頻出)

理論 17 個、実数 15 個。

"商品コード","実際の在庫数","ロケーション名","出荷期限日","ロット番号"
"012210100","15","A1","2027-08-19",""

パターン B: 期限日付替

A1 ロケに期限 2026/10/15 で 17 個あったはずが、実は 2026/10/20 が混ざっていた、など。旧期限を実数 0 で送り、新期限を新規行として送る ことで付け替え:

"012210100","0","A1","2026-10-15",""
"012210100","17","A1","2026-10-20",""

STEP 2 の一括上書き処理を必ず実行してから投入する(CSV に含めなかった他の期限ロットが 0 確定する罠を回避)。

パターン C: 期限のくくりと違う在庫が混在

PDF には期限 2026/10/15 で 17 個と書いてあるが、現場で見たら 2026/10/15 が 15 個 + 2026/10/20 が 2 個。

1. 元の行(2026/10/15)は 実数 15 個 で実地棚卸 CSV 化(パターン A)
2. 2026/10/20 の 2 個分は 棚卸機能では処理しない
3. 棚卸確定後に 予定なし入荷 CSV(第 3 章 §3-5)で 2026/10/20 の 2 個を新規入荷として登録

元の 17 個から 3 個を勝手に減算するのではなく、PDF に書かれた本体の数を尊重し、別期限分は別途入荷扱いにする。

パターン D: Ghost 商品の扱い

Ghost 商品は実在しない(受注時に分解されて構成品から引当)ため 棚卸対象外。LOGILESS 上は article_type='Single' のまま A1 ロケに 仮想在庫(無限在庫) を持つ運用。機能8 ツールが自動除外。判定は 2 軸の OR:

• ケース販売(_B 系) → 商品マスタ article_type='Assortment'(現状 HO-J80_B / GGS-TB10PN_B の 2 件)
• Ghost(F3=セット品 運用) → ハードコードリスト 25 件: selectgift_01〜08, ymygift01〜03, NSB_NSB-F-4, NSB-4, KST-N-2R, TBSET, YMYHBTSET, ZGIFT, HANA_ARIGATO, HANA_KIMOCHI, HANA_OSEWA, seasongift01〜06

Ghost 商品が増減した場合は Kaname へ連絡(ハードコードリスト更新が必要なため)。

パターン E: 期限なし商品(グッズ・資材)

トラベルタンブラー(019002600)などの賞味期限なし商品。期限列は元から空欄、空欄のまま投入で OK。「削除指示」ではなく「もともと期限なし」と認識される。

"019002600","5","A1","",""

パターン F: 引当不可ロケ(W2、retirement_*)

ロケ名(W1, W2, 「引当不可(自動処理):…」)をそのまま実地棚卸 CSV に書けば、ロジレス側が保留として認識する。自動生成名は 1 文字違いでもエラーになるため、§5-2-2 で W2 集約を済ませて、自動生成ロケ名を実地棚卸 CSV に書かなくて済む状態 にしておくのが推奨。

5-6. 投入と確定の手順(STEP 6 詳細)

5-6-1. アップロード

1. ロジレス「実地棚卸」画面 → 画面上部(マーチャント名の横)の「操作」
2. 「実地棚卸結果をアップロード」
3. 作成した 5 列 CSV を選択してアップロード
4. ロジレスが解析し、差分のある行が画面に表示される

5-6-2. 確定前のチェックリスト

• 行数は予想通りか(差分のある行数と一致しているか)
• 大きな差分(100 個以上のマイナス等)がある行に異常がないか
• Ghost 商品が混入していないか
• 期限あり商品で期限列が空欄になっていないか
• 引当不可ロケ名が完全一致しているか

5-6-3. 「実地棚卸を確定」

1. 画面右上の 「実地棚卸を確定」 をクリック
2. 確認ダイアログでもう一度内容を確認
3. 確定 → 論理在庫が実数で上書き
4. 凍結されていた在庫操作が再開

5-6-4. 確定をキャンセルする場合

• 確定前の取消: 「操作」→ 「実地棚卸をキャンセル」で入力データを破棄して中止
• 確定後の取消: 標準機能では用意されていない。入荷 / 出庫 CSV で逆方向の在庫操作 を手動で実施(§5-7 イレギュラー対応)

5-7. イレギュラー対応

5-8. よくある質問

6. 訳あり処理

6-1. 訳あり処理の全体像

正規価格では売れない在庫を、価格を下げて売り切る or 廃棄する運用全般。2 系統のトリガー がある。

6-1-1. W1 と W2 の役割(重要)

「W 系」とまとめると引当の扱いを取り違える。本章では常に W1 / W2 を区別する。

6-1-2. _S 版とは

元商品コードに _S サフィックスを付けた別 SKU。

新規 _S 版の 商品登録は 第 7 章 で扱う。本章では「_S 版がすでに登録されている前提」で振替手順を書く。抹茶系商品(型番に MC を含む)の _S 版は引当不可日数が 30 日ではなく 20 日(鮮度低下が早いため)。

6-2. W2 在庫の判断フロー(最重要)

第 4 章 §4-4 で自動生成の引当不可ロケ(retirement_*)から W2 に集約された在庫は、ここで処置を判断する。

[W2 に集約された在庫]
        ↓
  _S 版が登録されている?
        ├── No  → 廃棄(タブ1 廃棄、§6-4)
        │       もしくは 第 7 章で _S 版を登録してから _S 振替(タブ1)
        ↓ Yes
  期限が引当不可日数(30 日 / 抹茶系 20 日)以上残っている?
        ├── No  → 廃棄(タブ1 廃棄)
        ↓ Yes
  改廃品か?
        ├── Yes → 訳あり化(タブ2、§6-6)
        ↓ No
  _S 振替(タブ1 _S 振替、§6-3)

判断時の参照情報

• _S 版の存在: 商品マスタで {元型番}_S が登録されているか
• 賞味期限: W2 在庫の出荷期限日(保管状況 CSV / ヘッダー検索で確認)
• 引当不可日数: _S 版商品マスタの F3=訳あり時の値(通常 30 日、抹茶系 20 日)
• 改廃品か否か: 後継品が登録されているか(旧 → 新マッピング情報、機能9 タブ2 で CRUD)

判断のタイミング

• W2 集約した直後: 続けて判断・処理する
• 定期チェック(週次/月次): W2 滞留在庫を一覧で見て、まとめて処置を決める

6-3. 物理不良 → _S 振替(機能9 タブ1)

物理不良の元商品在庫を _S 版 SKU + W1 ロケに振替 する出庫 + 入荷 CSV のペアを自動生成。

ユースケース

• 箱潰れ・ラベル汚れで定価販売できない
• 賞味期限が近づいて引当不可日数を切りそう(先回りして _S に移す)
• 内容物に問題はないが外装の問題で訳あり扱いにしたい

商品コードが 元コード → _S 版コード に変わる。振替後の置き場は W1。

結果として在庫数の総量は変わらず、SKU と棚だけが変わる。

6-4. 物理不良 → 廃棄(機能9 タブ1)

_S 版に振替するほどの価値もない不良在庫を出庫 CSV だけで減らす。

ユースケース

• 内容物の汚損・破損
• 期限切れ
• _S 版が登録されておらず、登録するまでもない少量の不良品

商品コードは変わらない。在庫を減らすだけ。

備考欄に「廃棄」と明記しておくと、後から監査するときに通常の出庫と区別しやすい。

6-5. 改廃品 → 訳あり化(SKU そのまま)(機能9 タブ2)

旧型番が廃番になり、後継品(FM-J → FM-J80 など)に切り替わったが、旧型番の現有在庫が残っているケース。これを売り切るために、旧型番のまま訳あり扱いに変える。

ユースケース

ポイントは SKU を変えない こと。商品マスタの中身を更新するだけで、商品コード・型番・識別コードは元のまま。MP 検品で元の JAN で通すため、識別コード継承が重要。

6-5-1. ロジレス側だけ訳あり、フロントは通常価格のまま運用

ロジレス側だけ F3=訳あり にしておくと、倉庫オペレーション(ピッキング・在庫引当ロジック)のみ訳あり扱いになり、モール上では従来通り定価で売られ続ける。在庫管理の都合で SKU を切り替えたいだけの場合に有効。

他の列(商品コード、識別コード、型番、原価、サイズ、F1、F2、F4、税率)は元の値のまま。詳細は 第 7 章。

6-6. 改廃品 → W2 集約のみ(機能9 タブ2)

改廃品の在庫を 一旦 W2 に集めるだけ で、訳あり化(販売継続)するか廃棄するかの判断はあとに回したいケース。商品マスタは変更しない、棚移動だけで済む。

ユースケース

• 後継品の在庫状況を見てから判断したい
• 訳あり化するとロジレス側で「訳あり ◯◯」「価格 × 0.7」表示になり、ピッキング表に出る等、業務都合で先送りしたい
• 単純に分散していた旧型番在庫を 1 箇所にまとめたい

W2 は引当不可ロケなので、移動した時点で在庫は保留状態になり、受注引当の対象外になる。

6-7. _S 振替 vs 訳あり化 対比

両者とも最終的に W1 に置かれるが、SKU を変えるか変えないか の違い。

6-8. 生成 CSV 早見表

6-9. イレギュラー対応

6-10. よくある質問

7. 商品登録

商品をロジレスに正しく登録しないと、注文取込で「商品マスタにない」エラーで止まる・在庫が連携されない・MP 検品が通らないといった問題が起きる。本章は 24 列の Sheets 台帳 → ツール(機能1)→ ロジレス + Shopify + 対応表 の流れを 1 周押さえることが目的。

7-1. 商品登録の全体像

ロジレスで商品を扱うには 商品マスタ と 商品対応表 の 2 つを揃える必要がある。

[商品マスタ]              [商品対応表]              [各店舗の SKU]
ロジレス側で              ロジレス商品コードと        Shopify / 楽天
商品そのものを定義  ←→   店舗 SKU の対応関係  ←→   その他店舗
(16 列 / 17 列 CSV)       (2 列 CSV)

商品マスタの CSV は 2 系統:

商品マスタだけ作っても店舗注文は引き当たらない。対応表だけ作っても物がないので意味がない。両方を揃えて初めて運用に乗る。

7-1-1. 4 つのコード

7-1-2. 3 コード統一とは

_S 版・Ghost 親・グッズ・資材 など AO コードを持たない商品 は、ロジレスが商品コードを自動採番する。最終的な「あるべき姿」は:

商品コード = 識別コード = ロジレスコード(13 桁)

この 3 つを同値に揃えることを 3 コード統一 と呼ぶ。MP 検品で識別コードでも商品コードでも通せるようにし、商品対応表で一意にひもづけるため。ツール運用では機能1 STEP 3-2(API 自動 PUT)が 3 コード統一を完結させる。

7-2. メイン手順(機能1 商品登録)

/tool/article-register (サイドバー → 商品マスタ → 商品登録)

24 列の Sheets 商品マスタ台帳を正本とし、台帳に行を追加 → ツールに取込 → 段階開示で STEP 1 → STEP 2 → STEP 3-1 → STEP 3-2 → STEP 3-3 の順に進める。

完了判定

• ロジレス: 商品マスタ → 該当型番を検索して新規行が見える
• ロジレス: 商品対応表 → 店舗フィルタ「Shopify」「楽天」で SKU を検索してヒット
• Shopify 側: 商品 → 該当 SKU が存在
• 数分以内に Shopify 在庫が同期される(定期 job)

7-3. メイン手順(機能2 商品対応表)

/tool/article-map (サイドバー → 商品マスタ → 商品対応表)

機能1 で出力される ArticleMaps CSV と同じ内容を 対応表だけ再生成 するときに使う。新規商品の登録は必ず機能1 を通す(商品マスタが先・対応表が後の順序が崩れないように)。

1. サイドバー → 商品マスタ → 商品対応表
2. 「ファイルを選択」 で台帳 CSV(もしくは ArticleMaps 形式の CSV)を取込
3. 画面下部から ArticleMaps CSV(2 列、UTF-8 BOM、QUOTE_ALL) を DL
4. ロジレス → 商品対応表 → 「標準」 → 投入

7-4. 商品種別ごとの扱い

7-4-1. _S 版(訳あり派生)

• 台帳に行を持たない。通常品行の _S 版生成フラグ TRUE でツールが自動派生
• 価格は 元価格 × 0.7(四捨五入)、引当不可日数は 抹茶系(型番に MC 含む)= 20 日 / その他 = 30 日
• 個別調整したい場合は通常品行の _S 価格上書き / _S 引当不可日数上書き 列を埋める
• STEP 3-2 で 3 コード統一が完結。Sheets 台帳への採番値書き戻しは しない(台帳 = 登録時スナップショット運用)

7-4-2. 改廃品の訳あり化

旧型番が廃番になった後の在庫を売り切るために訳あり化する。SKU は変えず、既存商品マスタを上書き。

MP 検品で 元の JAN で通すため、識別コード継承が重要。詳細は 第 6 章 §6-3。

7-4-3. Ghost 親(セット親)

• 例: 「夏ギフトセット」。親自体は在庫を持たず、構成品(茶・海苔等)から引き当てる仮想商品
• 売価 0 円・F3=セット品・引当不可日数 0 日
• セット商品定義(Ghost 親 ↔ 構成品の紐付け)は ロジレス画面の「セット商品」機能 で別途設定(本マニュアル範囲外)
• 対応表は作る → 自動生成後に 手動で連携を OFF にする(在庫追跡しないため)

7-4-4. ケース販売(_B)

単品 × N のケース売り。Ghost 親とは仕組みが根本的に違う:

7-5. 引当不可日数の決定ルール

引当不可日数は F3 と F1 / F2 / F4 から自動算出。ツールが台帳から自動で埋めるので、原則手で書かない。

7-6. Shopify / 楽天 連携の確認と修復

ロジレスに商品を登録しても、Shopify / 楽天 側で商品が無い・対応表が無いと、注文取込で「商品マスタにない」エラーで止まる。

7-6-1. 連携状態の見方

7-6-2. 連携エラー時の修復手順

7-7. よくあるハマりポイント

1. STEP 3-1 と STEP 3-2 の順序ミス — STEP 3-1 で商品マスタを ロジレスに投入してから STEP 3-2 を実行。順序を逆にすると STEP 3-2 が「型番未ヒット = 未登録」で全失敗する。
2. F3 値の選択ミス — 通常 / 訳あり / セット品 / ケース販売 / グッズ / 資材 の 6 値。F3=セット品 と F3=ケース販売 は別物。
3. ケース販売の構成数量空欄 — TRUE + 空欄 / 0 以下 → 17 列 CSV が派生出力されない(エラー)。
4. 採番値を Sheets 台帳に書き戻さない — 台帳は登録時のスナップショット。採番後の運用情報は LOGILESS が正本。
5. 既登録分の識別コード歯抜け — 過去に手で登録された _S 版 / Ghost 親 は識別コードに歯抜けがある場合あり。歯抜け修正の一括処理は Kaname に依頼。
6. F1 / F2 の表記揺れ — 全角/半角・ひらがな/カタカナ違いで集計が壊れる。既存 Articles CSV を出して表記を合わせる。
7. 税率の取り違え — 食品 = 8 / それ以外 = 10。間違えると納品書・請求書の金額が狂う。
8. Ghost 親の自動在庫連携 OFF 忘れ — 対応表登録後にロジレス画面で連携 OFF を手動設定しないと Shopify 在庫が 0 に上書きされる事故になる。

7-8. よくある質問

8. 受注マクロ運用

8-1. 受注マクロの全体像

[モール (Shopify / 楽天)]
   ↓ 受注データ
[ロジレスマクロ]   タグ付与・倉庫変更・確認待ち化・PL 転記など
   ↓ 加工された受注
[ロジレス出荷フロー (第 2 章)]

マクロは ロジレスに入ってきた受注に条件で発火 する自動処理。第 2 章 で「裏で勝手にやってくれる」と書いていた部分の正体がここ。正本 JSON: sales_order_macros_*.json(Shopify / 楽天それぞれ別ファイル)。

8-2. マクロの基本ルール

8-2-1. トリガー種別

8-2-2. 1 マクロ = 1 アクション

1 本のマクロには 条件 1 セット + アクション 1 つ しか書けない。複数処理は複数マクロに分解する。例: のしあり注文を蔵前へ振り向ける場合 — のしあり_タグづけ(条件: のしキーワード検出 → AddTag)+ のしあり_蔵前処理(条件: のしありタグあり → ChangeWarehouse=7110)の 2 本。

8-2-3. 評価順序 = 決定的

マクロは上から順に評価される。マクロ A でタグを付与 → マクロ B でそのタグを判定 という連鎖が同イベント内で可能。並び順を間違えるとタグの依存関係が崩れる。

8-2-4. モールごとに別管理

Shopify と 楽天 のマクロは 別画面・別設定。同じ「のしあり判定」でも、Shopify は外側(Shopify Flow)でタグ付け → ロジレス、楽天は受注内の articleOption をマクロでキーワード判定 と仕組みが違う。

8-2-5. 用語

statement_notes と picking_notes を取り違えると、PL に出てほしい情報が出ない事故が起きる。

8-3. 現役マクロの主な役割(カテゴリ別)

• 倉庫振り分け: 蔵前(7110)かココドット(7158)のどちらに送るかの判定(§8-4 参照)
• 確認待ち化: 下書き注文・時間指定不可地域など、自動処理させずに目視確認させたい注文を止める
• タグ付与: のしあり、蔵前確定 SKU、ココドット P1 などの分岐用タグ
• PL 転記: 購入者備考欄や時間指定不可地域の希望時間を出荷指示書に書き込む
• 送り状文言: 私用フラグ判定で店舗名・電話番号を送り状特記事項に転記
• 代引き対応: 備考欄キーワードで支払方法を変更、確定時に入金ステータスを切り替え
• POS 注文の特殊処理: 物販タグ付き注文を倉庫受取扱いに、PL にマーカーを入れる
• 季節キャンペーン対応: 山本山の日・母の日など、時期限定の同梱・配送指定日設定

マクロ規模感: Shopify 全 20 本(有効 13 / 温存 7)、楽天 全 9 本(有効 8 / 温存 1)。「温存」は削除予定ではなく、フェーズ切替時に有効化するための予約席(§8-4)。

8-4. マクロの 2 フェーズ運用設計

蔵前 vs ココドットの 「どちらをデフォルト倉庫にするか」 によって、マクロの有効/温存を反転する設計。

切替手順(将来作業の参考)

1. ロジレス組織設定でデフォルト倉庫を蔵前 → ココドットに変更
2. Shopify店舗のマクロ ON/OFF を反転(温存マクロを有効化、ココドット振り向け系を無効化)
3. 楽天店舗のマクロも同様に反転
4. 倉庫振替自動実行設定の対象/対象外を反転
5. 切替後 3 日は全注文目視チェック

8-5. のしあり判定の仕組み

のしの検出はモールごとに別レイヤーで動く。同じ「のしありタグ」でも経路が違う。

Shopify

Shopify Flow(ロジレスの外、Shopify 管理画面側のワークフロー)が注文プロパティを検査して「のしあり」タグを付与してからロジレスに送る。ロジレス側のマクロは「すでに付いているタグ」を見るだけ。Shopify でのしタグが付かない問題はロジレスのマクロを見ても解決しない → Shopify 管理画面の Flow ログ確認が必要。

楽天

ロジレスマクロが注文の lines.articleOption(商品オプション欄)に 11 キーワードのいずれか が含まれているかで OR 判定:

外のし / 内のし / 蝶結 / 結切 / 歳暮 / 中元 / 年賀 / 暑中 / 残暑 / 寒中 / シール

1 つでも該当すれば「のしあり」タグが付く。

のしあり注文は確認待ちにならない

のしあり判定後の処理は タグ付け + PL 転記(購入者備考欄経由)のみ。確認待ち化はしていない。現場は PL を見て、のしの鉄人での印刷準備に進む 運用。

8-6. マクロを編集したい時

ナレッジ §13 / §13-2 と JSON 正本(sales_order_macros_*.json)を見ながらマーチャント画面で編集する。画面 UI が変わる可能性があるため詳細な画面操作は本書では扱わない。

編集の前提

• JSON 正本を見て該当マクロの条件・アクションを確認
• 並び順(評価順)に依存している箇所があるか確認
• 編集後は 1〜2 件のテスト注文で動作確認(タグが付くか・倉庫変更されるか・PL 転記されるか)

8-7. イレギュラー対応

9. 出荷実績突合

集荷が終わったあと、佐川 e 飛伝 III から出力した実績 CSV(送り状番号入り)と、ロジレスの検品済み伝票を突合 → ロジレスにアップロードする実績 CSV を作る作業。これを経てロジレスの伝票が 「出荷済み」 になり、Shopify・楽天 へ追跡番号が自動通知される。

過去に Claude 依頼運用と並走で差分ゼロを確認済み。現在は本ツール一本運用。

9-1. 突合の目的

• 送り状番号の自動戻し: 数十〜100 件の伝票に手で送り状番号を貼り付けるのは現実的でないので、CSV 1 本でまとめてロジレスに戻す
• 出荷漏れ・出荷ズレの検知: ロジレスで検品したのに送り状が無い(= 物理出荷していない)ケースを浮かび上がらせる

9-2. 入力ファイル 2 種

9-2-1. ロジレス CSV のエクスポート手順

1. ロジレス → 出荷 → 出荷作業中 タブを開く
2. 当日の出荷作業中伝票を 全件チェック
3. 「伝票単位で出力」 を選択
4. 出力フォーマット 「標準」 を選択してエクスポート

出力ファイル名は OutboundDeliveries-YYYYMMDDHHMMSS.csv。フォーマット「標準」を選択する。「出荷準備完了日時」が空欄の伝票は突合対象外(= 検品済みかどうかの判定列)。

9-2-2. ファイル形式まとめ

9-3. メイン手順(機能7 ツール)

サイドバー → 出荷 → 出荷実績突合(/tool/ship-match)。

9-4. 突合の判断ロジック

ツール内部で自動適用するルール(手動チェック不要、人手で判断する場合の参考):

[ロジレス CSV]
   ↓ 出荷準備完了日時が空欄でない行だけ残す
[検品済み伝票一覧]
   ↓ 伝票コード ↔ shukka_rireki のお客様管理番号 で突合
[マッチした行]
   ↓ 同じお客様管理番号で複数あれば 送り状 No. 大の方を採用
   ↓ 削除区分 0 以外を除外
[出力 CSV (shukka_rireki 形式)]

9-4-1. ルール一覧

9-4-2. 件数の整合確認

• 「ロジレスの検品済み件数」 = 「最終出力件数」 が正常
• 不一致なら出荷漏れ or shukka_rireki 取得期間不足の可能性(§9-6 参照)

9-5. 出力 CSV → ロジレスにアップロード

9-5-2. アップロード手順

出荷作業中タブの中には、送り状用データを出す CSV をダウンロード と、実績を戻す CSV をアップロード が 対(つい) で並んでいる。

1. ロジレス → 出荷作業中タブ → CSV をアップロード
2. 出力 CSV を投入
3. 自動的に走る処理:
   • 配送ステータス → 出荷済み
   • 在庫数の減算(保管中 → 出荷済み)
   • Shopify・楽天 へ出荷通知 + 追跡番号送信

9-5-3. 投入タイミングの注意

9-6. 検品 = 出荷確定 のルール

本章の運用は 「検品したものは全部出す」 を前提に組まれている。これが崩れると、突合の不一致や顧客クレームが発生する。

9-6-1. 基本ルール

• 検品 = 出荷確定。検品した伝票は当日中に物理出荷する
• 出せないものは検品前に弾く(出荷待ちのまま留めるか、出荷待ちに戻す)

このルールが守られている限り、検品済み件数 = 出荷件数 になり、突合の不一致は理論上発生しない。

9-6-2. 検品後に「出せない」と判明した時のリカバリ

検品してから「やっぱり今日は出せない」となったケース(顧客から急なペンディング依頼、商品の不備が梱包中に判明、など)の処理:

1. ロジレスで該当伝票を 「出荷待ちに戻す」
   • 検品日時がクリアされ、自動的に当日の突合対象から外れる(ルール 1)
2. 既に発行した 送り状は破棄 する
3. 翌日以降に再度検品 → 送り状再発行 → 通常通り突合

ロジレス側のステータスを戻すだけで、突合ロジックは何もしなくていい。

9-6-3. 出荷後キャンセル

LOGILESS 側で「出荷済み → 出荷待ちに戻す → そこでキャンセル」操作が可能。機能7 「不明」分類で吸収できるので、運用上の特別対応は不要。

9-7. 不一致時の確認

突合実行時に「ロジレスでは検品済みなのに、shukka_rireki に対応送り状がない」伝票が出た場合(= 漏れ候補):

物理出荷漏れだった場合は、当日中に出荷できるなら通常通り送り状発行 → 突合に含める。出せないなら出荷待ちに戻して翌日以降に回す(§9-6-2)。

9-8. よくある質問

10. 共通 UI(ヘッダー検索・再読込・エラーログ・設定)

10-1. 画面レイアウト

┌─────────────────────────────────────────────┐
│ [ヘッダー]  商品マスタ検索窓  /  🔄 再読込  /  ユーザー名 ▾ │
├──────────┬──────────────────────────────────┤
│ サイド   │                                       │
│ バー     │           メイン領域                  │
│          │      (各機能画面 / ホーム)            │
└──────────┴──────────────────────────────────┘

サイドバーは常時固定表示(折りたたみなし)。並び順は 業務フロー順 で固定:

ホーム
─ 商品マスタ ─
  商品登録          (機能1)
  商品対応表        (機能2)
─ 入荷 ─
  入荷予定登録      (機能5、マーチャント側)
  入荷(予定あり)    (機能3)
  入荷(予定なし)    (機能4 入荷モード)
─ 出荷 ─
  出庫              (機能4 出庫モード)
  出荷実績突合      (機能7)
─ 在庫調整 ─
  棚移動            (機能6)
  棚卸              (機能8)
  訳あり処理        (機能9)
  倉庫移動          (機能10、フォールバック)
─ システム ─
  エラーログ
─ 設定 ─
  API クレデンシャル等

10-2. ヘッダー商品マスタ検索窓

配置はヘッダー中央。どの画面からでも検索可。

10-2-1. 検索仕様

• 検索キー: 型番 / 商品コード / 識別コード(JAN) / 商品名 — すべて部分一致(OR)
• トリガー: Enter 押下のみ(インクリメンタルサーチではない)
• 検索範囲: ロジレス商品マスタ全件 + 在庫(蔵前 7110 / ココドット 7158 両倉庫)。最大 50 件

10-2-2. 結果表示項目

各セル右側にコピーボタン。商品の詳細編集はロジレス側で行う想定で、ツール側にはコピーと詳細ページリンク以外のアクションは持たない。

10-2-3. ドロップダウンの閉じ方

• 外側クリック
• Esc キー
• 別画面遷移

10-3. 再読込ボタン

配置はヘッダー右上。現在表示中の画面のデータを API から再取得する。

• 粒度: 画面全体のデータを再取得(セクション単位の細かい再読込はしない)
• 機能1/2/5/9 でも再読込が活性化(商品マスタ reload を基本、機能9 タブ2 は加えて改廃品マッピングも再読込)
• 登録なしのページ(ホーム・ログイン等)では ボタンが disabled

10-4. ホーム画面と処理履歴

ホーム画面の主目的は 「直近の処理履歴」の俯瞰。

[ホーム]

▼ 直近の処理履歴(最大 20 件)
  日時          機能          SKU      ロット      期限      処理内容           ユーザー
  05-03 14:23   訳あり処理    FM-J     -           -         訳あり化           kaname
  05-03 13:10   出庫CSV       NCZ      LOT001      26-04-30  50 個 出庫         kaname
  05-03 11:45   出荷突合      -        -           -         57 件突合済        kaname
  ...

• 履歴はサーバ側に全ユーザー共有で保存
• 表示は 最大 20 件。21 件目以降は古い順に自動削除(CSV 生成時の post-process)
• ダウンロード履歴・再ダウンロード機能は無い。CSV は手元の DL フォルダで管理する運用

履歴に記録される項目

10-5. ログイン・ログアウト

• ID/パスワード方式(社内専用、権限分けなし)
• セッションは 12 時間スライディング。リクエストの度に自動延長される。12 時間アクセスがないとセッション失効 → ログイン画面へ自動リダイレクト
• ログアウトはヘッダー右上の ユーザー名クリック → メニュー → 「ログアウト」
• セルフ パスワード変更機能あり

セッション切れで操作が止まったときは、再ログインしてから同じ画面に戻れば作業を続けられる。入力中の編集行はリロード時に失われる(localStorage 永続化されているのは棚卸機能のみ)。

10-6. 共通 UI 部品

複数の機能で再利用される共通コンポーネント。

10-7. エラー表示の見方

ツール内のエラーは 4 タイプに分類されて表示される。

表示パターン 3 種

原則リトライしない(手動で再試行)。例外は HTTP 429(レート制限)のみツールが 1 回だけ自動リトライする。

10-8. エラーログ画面(システム)

サイドバー → システム → エラーログ。ツール内で発生したエラーを画面で確認する。phpMyAdmin で DB 直接アクセスせずに済むようにするための画面。

[エラーログ]

期間: [過去 24 時間 ▼]   タイプ: [すべて ▼]    [更新]

発生日時             ユーザー    タイプ          メッセージ
2026-05-06 14:23:11  kaname     Rate Limit      ロジレス API の利用制限に達しました
2026-05-06 11:05:42  arai       認証エラー       セッションが切れました
2026-05-06 09:15:03  -          システムエラー   Internal Server Error
...

(行クリックで詳細モーダル: 秒まで日時 / フルメッセージ / リクエスト URL / スタックトレース)

• ソートは発生日時の降順固定(新しい順)
• 古いログは月次 cron で自動削除(保持 3 ヶ月)
• ページング・検索は無い(フィルタで絞れば数十〜数百件に収まる前提)
• アクセス権は全ユーザーだが、運用上は Kaname が主に参照する想定

10-9. 設定(API クレデンシャル)

サイドバー → 設定 → API クレデンシャル等。read-only で状態を確認 + 接続テスト用の画面。

• Client ID は末尾 4 桁のみ表示(その他はマスキング)
• ロジレストークンの有効期限が表示される
• 「API 接続テスト」 ボタンで articles?limit=1 を実行 → OK / NG をその場で確認できる
• ロジレストークンは ツール全体で 1 セット(全ユーザー共有)、サーバ側で自動更新される。期限切れ自動更新はツールが内部で処理するため、現場が触る必要なし

倉庫設定 — 蔵前(7110) / ココドット(7158) — も同画面で確認できる。両倉庫モードで動く機能(機能5 入荷予定 / 機能10 倉庫移動 / ヘッダー検索)はこの設定値を参照する。

10-10. よくある質問

11. 困った時(章横断トラブル早見表)

各章の「イレギュラー対応」「よくある質問」も併読推奨。本章で解決しない場合は 最終的に Kaname へ Slack / 口頭で確認(エスカレーション)。

11-1. 受注 / 出荷フローのトラブル

11-2. 入荷 / 在庫操作のトラブル

11-3. 棚卸 / 訳あり処理のトラブル

11-4. 商品登録 / 連携のトラブル

11-5. 出荷実績突合のトラブル

11-6. ツール共通のトラブル

11-7. 定期タスク / 設定のトラブル

11-8. エスカレーション基準

以下のいずれかが当てはまったら Kaname へ Slack / 口頭で確認:

• 本章および各章の「イレギュラー対応」「よくある質問」に該当しない症状
• 同じエラーが複数ユーザーで発生している
• エラーログ画面に「システムエラー」が連続している
• ロジレス API 接続テストが NG、ヘッダー検索が動かない
• 出荷漏れの可能性がある(突合「漏れ候補」が当日中に解消しない)
• 商品マスタの整合が崩れている疑い(対応表ヒットしない・3 コード歯抜けが大量)

12. 定期タスク

12-1. 楽天 licenseKey 更新(90 日周期)

楽天 API 連携の認証キー(licenseKey)は 90 日で失効。失効すると楽天店舗からの 受注取込・在庫連携・出荷実績送信 のすべてが止まる。

トリガー

楽天市場から 「【楽天市場】licenseKey の有効期限のお知らせ」 という件名のメールが届いたら更新作業に入る。期限到来前に通知が来る。

反映タイミング

公式マニュアル

LOGILESS ヘルプセンター「楽天市場 licenseKey を更新する」を参照。

12-2. その他の定期タスク

付録(CSV サンプル一覧 / リンク集 / 改訂履歴)

A. サンプル CSV 一覧

B. 関連リンク

C. 章 ↔ 機能 マトリクス

D. 改訂履歴