物流・倉庫管理のAccess活用と移行｜入出庫・在庫・配送の勘所

結論：物流・倉庫のAccessは「入出庫トランザクション量」と「拠点分散」が臨界点になる

入出庫記録、在庫管理、ロケーション管理、配送手配。物流・倉庫管理でAccessが担っている業務はこのあたりが多く、当社への相談でも同じ構成が繰り返し登場します。

製造業の在庫とは文脈が違います。製造業の在庫は品目数よりも工程との紐付きが問題になるのに対し、物流・倉庫の場合は日々の入出庫トランザクション量が多く、1日数百件の入出庫を何年も積み上げることでファイルが膨らみやすい。加えて、複数倉庫や拠点にファイルが分散するパターン、ハンディターミナルやバーコードリーダーとの連携が求められる状況、繁忙期に複数名が同時に入力する場面——これらが重なると、Accessだけでは限界が来ます。

この記事では、物流・倉庫管理でよく見るAccessの使われ方と、そこで起きがちな課題、移行を考えるときの判断の勘所を整理します。特定の企業の事例ではなく、当社が支援を通じて経験した典型的なパターンとしてまとめています。

物流・倉庫管理でよくあるAccessの使われ方

WMS（倉庫管理システム）やTMS（輸送管理システム）を導入していない中小の物流会社や、3PLの荷主企業のセルフ管理でAccessが活用されているケースが多くあります。当社の経験で特に多い用途は以下の5つです。

物流・倉庫のAccessで特徴的なのは、入出庫の記録が毎日積み上がる点です。1日100件の入出庫でも年間3万件超。これを複数年続けると、在庫残高の集計クエリがクエリ設計・インデックスの状態によっては広範囲のレコードを走査するようになり、ファイルが肥大化するにつれて処理が重くなっていきます。

物流・倉庫のAccessでよく見る4つの課題

1. 入出庫トランザクション蓄積による2GB接近と処理遅延

Accessはファイルサイズの上限が2GBと決まっています（公式仕様）。物流・倉庫の用途では、入出庫記録が毎日積み上がるため、製造業の部品在庫より蓄積スピードが速くなりやすいです。当社の経験では、1日の入出庫件数が多い拠点では3〜5年でファイルが1GBを超えるケースがあります。

問題はサイズだけでなく、在庫残高を出す集計クエリの処理速度です。クエリ設計やインデックスの状態にもよりますが、何年分もの入出庫レコードを広範囲に集計するクエリは、データ量が増えるにつれて処理が重くなる傾向があります。当社の経験では「在庫確認のクエリを開くのに数分かかる」という状態になったAccessが物流・倉庫業態では比較的多く見られます。Accessの2GB上限の詳細はAccessの2GBの壁で整理しています。

2. ハンディターミナルやバーコードリーダーとの連携の限界

倉庫作業では、ハンディターミナルやバーコードリーダーを使って棚の前で入出庫をスキャンする運用があります。これをAccessと連携させようとすると、現場ではCSVファイルやテキスト出力を中間ファイルとして使い、Accessに取り込む形になります。

当社の経験でよく見るのは、ハンディの出力ファイルをVBAで自動取り込むように作り込んでいるケースです。これ自体は動いていても、ハンディの機種変更やデータ形式の変化、あるいはVBAを書いた担当者の退職で連携が壊れることがあります。CSVをバッチで取り込むこの方式では、スキャンした情報がAccessに反映されるまで数分から数十分かかるケースを当社はよく見ます。

3. 拠点分散とファイルの分裂

倉庫が複数拠点にある場合、Accessファイルも拠点ごとに別々になっているパターンが多いです。当社の経験では、A倉庫のAccessとB倉庫のAccessが別ファイルで、在庫の統合確認は月次で担当者がExcelに手動転記している、という状態をよく見ます。

拠点間で在庫をまとめて見たいときに手作業が入るため、転記ミスや集計タイミングのズレが発生しやすくなります。Accessのファイル共有型の仕組み上、WAN越しに複数拠点から同じファイルを安定して共有することはMicrosoftも推奨していません。同時利用の仕組みの問題についてはAccessが複数人で使うと遅い原因で解説しています。

4. 繁忙期（棚卸・決算期）の同時利用集中

棚卸しや決算期には、普段よりも多くのスタッフが同時にAccessを開いて数量を入力します。Accessはファイル共有型のため、同時書き込みが集中するとデータの競合やロックが発生しやすくなります。

当社の経験では「棚卸の日だけAccessがフリーズして最初からやり直した」という相談を物流・倉庫業態から受けることがあります。平時は問題なくても、棚卸という特定のタイミングに集中して顕在化するのが物流・倉庫のAccessの特徴的なパターンです。

移行を考えるときの判断基準

物流・倉庫のAccessで「何とかしたい」という相談が来たとき、当社ではまず延命が成立するかどうかを確認します。以下の数値はAccess製品仕様上の公式閾値ではなく当社の一次診断時の実務目安です。個々のシステムの構成によって判断は変わります。

Access 2021のサポートは2026年10月13日に終了します。ESUや延長プログラムはありません。物流・倉庫のAccessは入出庫データの蓄積構造上、移行前のデータ整理に時間がかかることが多いため、余裕を持って動き始めることをお勧めします。

物流・倉庫での移行先の選択肢

物流・倉庫のAccessを移行するとき、規模と現場の運用形態によって選択肢が変わります。当社の経験から見た傾向を整理します。

まず現実的な第一段階として多いのが、フォームや帳票はAccessに残し、テーブルだけSQL Serverへ移す構成です。2GB制約を解消し同時利用の安定性を改善できるうえ、既存の操作画面を概ね維持できます。入出庫記録のトランザクション量が多い場合でも、SQL Server側でアーカイブ戦略を組めるため、Accessのファイル肥大化の問題から切り離せます。この構成についてはフォームはそのまま、データだけSQL Serverへ移す構成で詳しく解説しています。

拠点間の在庫集計をリアルタイムで行いたい、またはハンディ端末とのリアルタイム連携が必要という要件があれば、WMSへの移行か、kintone・Power AppsなどWebベースのシステムへの移行が選択肢になります。ただし複雑な帳票や荷主ごとの様式に合わせた出力がある場合は、ローコードツールだけでは再現が難しいことがあります。

荷主ごとの報告様式や複雑な配送ルート管理など、既製品では対応しきれない業務ロジックがある場合は、Webシステムのスクラッチ開発が最終的な選択肢になります。移行先の候補を横断的に比較したい場合はAccessの移行先を比較も参照してください。

どの移行先が合うかは現状のAccessの構造を把握してから判断するのが基本です。まず無料の解析可否チェックで現状を整理することをお勧めします。

移行前に確認しておくべきこと

物流・倉庫のAccess移行で後から問題になりやすい点を当社の経験から挙げます。

• 過去の入出庫データの扱い：何年分の入出庫記録を移行先に持ち込むか、または参照専用の形で残すかを決めておかないと、移行工程の中でデータ量の問題が大きくなります。直近1〜2年分だけ移行し、それ以前は読み取り専用のAccess（またはExcel）で参照できるようにする方法もあります。
• 在庫残高の突き合わせ基準日：移行タイミングで「どの時点の在庫数を正」とするか、棚卸との連動で整合性を取る方法を事前に決めておかないと、移行後に数量の差異が発生して現場が混乱します。
• ハンディ・バーコードの連携方式：移行先がCSV取り込みに対応しているか、APIで直接連携できるかを確認しておかないと、移行後も手動の中間作業が残ります。ハンディの機種・型番の仕様書を確保しておくことも重要です。
• 荷主ごとの帳票様式：荷主の数だけ報告様式が違う場合、それぞれ移行先で再現できるか早い段階で確認が必要です。帳票の再現性は移行工数に大きく影響します。
• VBAで組んだ在庫計算ロジック：先入先出（FIFO）やロット管理などの在庫評価ロジックがVBAに書かれている場合、移行前にロジックを文書化しておかないと移行先で同じ計算結果が出せません。

移行準備の業務フロー調査の進め方はAccess移行前の業務フロー調査に整理しています。

よくある質問

Q. 倉庫のAccessが重くなってきました。最適化・修復で改善しますか。

最適化（コンパクト）はファイル内の未使用領域を除去してサイズを縮小する機能で、一時的に軽くなることはあります。ただし何年分もの入出庫記録が蓄積したことによる処理遅延は、レコード数が減らない限り根本的には改善しません。ファイルサイズが1GBを超えていて増加ペースが続いているなら、SQL Serverへのバックエンド移行か、古い記録のアーカイブを検討するタイミングです。

Q. 複数倉庫のAccessを1つにまとめることはできますか。

データをSQL Serverへ移してバックエンドを共通化することで、各倉庫のフロントエンド（フォームや帳票）はそのままにしながら、同じデータベースへ接続させる構成が取れます。ただし各倉庫のAccessがそれぞれ独自のテーブル設計を持っている場合は、統合前にデータ構造を揃える作業が必要になります。属人化が進んでいる場合の解析についてはAccess属人化の危険度と脱・属人化の進め方で解説しています。

Q. ハンディターミナルとのデータ連携は移行後も維持できますか。

移行先がWebシステムやSQL Server＋Accessのハイブリッド構成であれば、CSVやODBC経由でハンディのデータを取り込む仕組みを移行後も設計できます。ただし連携の仕様はハンディの機種や型番で変わるため、移行前にハンディ側の出力フォーマットと仕様書を確保しておくことが前提になります。棚前でスキャンした情報をリアルタイムに反映させる要件がある場合は、WMSや専用Webアプリを含め、要件に合った構成を個別に検討することになります。

Q. 棚卸しのときだけAccessが重くなります。普段は問題ないのですが。

棚卸し時に複数人が同時入力する場面でAccessが重くなるのは、ファイル共有型のデータベース設計の限界が出ているパターンです。普段は1〜2名の入力で問題なくても、同時接続が増えた瞬間に競合やロックが発生しやすくなります。DB分割で改善できることもありますが、根本的には同時書き込みに強いSQL ServerやWebシステムへの移行が安定解になります。段階移行の考え方は製造業のAccess移行の判断基準の表も参考にしてください。