在庫調整に「Set To」「Adjust By」の2モード すべての変更が誰がいつ・どこで動かしたか記録される

図解 ： 在庫調整ワークフローが「変更履歴フル記録」対応に Admin / Changed 在庫調整に「Set To」「Adjust By」の2モード すべての変更が誰がいつ・どこで動かしたか記録される 管理画面の在庫調整ポップオーバーが刷新。数量の上書きと「移動」を明示的に分け、調整履歴に「ソース／デスティネーション／実行者／日時」がすべて残るようになった。 このページの構成 そもそも何が変わったのか（30秒で理解） 2つのモード ： Set To / Adjust By 仕組み図解 ： 在庫を動かしてからの流れ 記録される4項目 Bulk Editor との関係 使い分けフロー 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わったのか 管理画面の在庫調整ポップオーバーに 「Set To（数量を設定）」と「Adjust By（増減で動かす）」の2モード が並んだ。 モードに関わらず、すべての調整が 「ソース・デスティネーション・実行者・日時」付き で履歴に残る。 従来 ： 何が起きたか追えない 数量を書き換えても、誰が・なぜ・どこから動かしたのかは履歴として残らない／残し方が分かりにくい。棚卸ミスの原因追跡が困難。 これから ： 全調整が自動で履歴化 Set To でも Adjust By でも、すべての操作にソース／デスティネーション／操作者／時刻が紐づく。いつでも履歴ビューから確認できる。 2 2つのモード ： Set To / Adjust By MODE A Set To ： 数量を「上書き」する 使い方 ： 数量を入力するだけ。Shopify が差分を自動で記録する。 向いている場面 ： 棚卸の結果反映など「最終値だけ分かっている」操作。 MODE B Adjust By ： 「移動」として記録する 使い方 ： ソース（どこから）とデスティネーション（どこへ）を選んで増減を入れる。 向いている場面 ： 拠点間移動・破損・返品・補充など「どこから動かしたか」を残したい操作。 3 仕組み図解 ： 在庫を動かしてからの流れ 4 記録される4項目 Source どこから動かしたか Destination どこへ動かしたか 実行者 誰が操作したか 日時 いつ操作したか モードに関わらず（Set To でも Adjust By でも）この4項目が常に記録される。 履歴ビューはいつでも開けるので、過去の操作を追跡できる。 5 Bulk Editor との関係 操作場所 挙動 ソース／デスティネーション 在庫調整ポップオーバー （Set To） 変更後 数量入力 ＋ 差分を自動記録 不要（自動） 在庫調整ポップオーバー （Adjust By） 新規 ソース／デスティネーションを選んで移動として記録 必須 Bulk Editor 据え置き 利用可能在庫を直接設定。挙動は従来通り。 不要 Bulk Editor は変更されていない ： 一括で利用可能数を上書きする運用はそのまま継続できる。ソース／デスティネーションの入力は求められない。 6 使い分けフロー 1 棚卸の結果反映 → Set To 「最終的にいくつあるか」だけ分かっている場合。数字を入れて確定。 2 拠点間移動・補充 → Adjust By 「どこから来てどこへ行ったか」を残したい操作。トレーサビリティ重視。 3 多商品の一括上書き → Bulk Editor 個別履歴を必須としない大量編集。これまでの運用通り。 7 技術者が押さえるべき5つのポイント 1. UI の入口が「Set To / Adjust By」の2モードに分割 同じポップオーバー内でモード切替する設計。実装側ではユーザー教育用のドキュメント差し替え（手順書のスクショ等）が必要。 2. すべての調整に4項目（source / destination / user / time）が紐づく モードを問わず記録される。これまで「いつ誰が」を別管理（スプレッドシート等）でやっていた現場は、その仕組みを縮退できる可能性。 3. API／Webhook の仕様変更は記載なし 記事は管理画面の挙動のみを説明。InventoryLevel／InventoryAdjustment 等の GraphQL 仕様への影響は別途ヘルプ・開発者ドキュメントで要確認。 4. Bulk Editor は非変更 一括で利用可能在庫を上書きするフローは従来通り。ソース／デスティネーションを要求しないため、業務スクリプトや手順は据え置きでよい。 5. 履歴ビューは「いつでも閲覧可」と明記。閲覧範囲・権限・エクスポート可否は記載なし 記事は「view your full adjustment history any time」とだけ記載。 誰が見られるか／CSV エクスポートできるか／保存期間 はヘルプ documentation 側で確認が必要。監査要件のある現場では事前検証必須。 8 業務に活かせる3つのユースケース USE CASE 1 マルチロケーション店舗での「拠点間移動の証跡化」 課題 倉庫 ↔ 店舗 ↔ ポップアップ間で在庫を頻繁に動かす運用で、誰がいつ何を移したかが追えず、棚差・紛失の犯人探しに時間を取られる。 打ち手 移動操作は 必ず Adjust By を使う と運用ルール化し、ソース／デスティネーションを毎回入力。 効果 棚差発生時に履歴を遡るだけで原因特定可能。スタッフ別の操作傾向も可視化できるためトレーニング材料になる。 技術メモ Set To と Adjust By の使い分けを手順書に明記。マニュアルとスタッフ向け短尺動画の整備が運用定着の要。 USE CASE 2 棚卸フローを「Set To に統一」して二重管理を解消 課題 棚卸結果の反映を、Shopify への入力と Excel／Google スプレッドシートでの「いつ誰が」記録に二重で行っており工数が膨らんでいる。 打ち手 棚卸反映は Set To のみで運用 。実行者・日時が自動で残るため、外部スプレッドシートの履歴管理を廃止。 効果 棚卸オペレーションの工数削減。記録の正本が Shopify 内に一本化され、参照のリードタイム短縮。 技術メモ 履歴のエクスポート可否はヘルプで要確認。会計監査連携が必要な場合は事前に「履歴ビューをスクショ・PDF 化する運用」を組んでおくと安全。 USE CASE 3 調整履歴を「不正・ロス検知のシグナル」として活用 課題 在庫減少の理由（破損／盗難／システム不整合）が分からず、ロス削減施策が打てない。 打ち手 調整時に Adjust By でデスティネーションに「破損」「サンプル出庫」等の理由を付ける運用を徹底し、履歴を定期レビュー。 効果 「特定スタッフ／特定 SKU／特定時間帯」で発生する減少パターンを発見でき、棚卸ロス・内部不正の早期検知につながる。 技術メモ API での履歴取得可否が確認できれば、BI（Looker／BigQuery）に連携して異常検知ダッシュボード化も可能。記事には API 仕様の言及なし。 9 提案で使える1行サマリ 「在庫調整に Set To（上書き）／Adjust By（移動） の2モードが登場。 どちらでも ソース・デスティネーション・実行者・日時 が自動で履歴化され、Bulk Editor は据え置き。 現場の 棚差追跡・拠点間移動の証跡・ロス検知 を、追加ツールなしで実現できる。」 source ： changelog.shopify.com / inventory-adjustment-workflow-now-with-full-change-tracking generated 2026-05-23