この記事で分かること
- Access在庫管理で数量のズレが発生する4つの技術的・運用的な根本原因
- 不整合が発生した際、データ履歴からエラーの箇所を特定するための調査ステップ
- データのズレを恒久的に防ぐためのテーブル設計の変更方法とトランザクション処理の実装手順
Accessの在庫管理で「在庫数が合わない」が発生する4大原因
Accessで構築したシステムにおいて、在庫数の不整合が発生する要因は、単なるユーザーの入力ミスだけではありません。Accessの特性を考慮していないシステム設計や、同時アクセス時の制御不足といった、構造的な問題が潜んでいるケースがほとんどです。主な原因を4つに分類して説明します。
1. 同時実行制御（排他制御）の不足による更新の競合
Accessは複数ユーザーで共有して利用できるデータベースですが、同時に同じ製品の在庫データを更新しようとした場合の制御が不十分だと、データの不整合が簡単に発生します。例えば、担当者Aが出庫処理を行っているのとほぼ同じタイミングで、担当者Bが別の出庫処理を実行したとします。排他制御が適切に設計されていないと、後から書き込まれたデータが先に処理されたデータを上書きしてしまい、一方の出庫データのみが反映されて在庫計算が狂うという事態が起こります。
2. トランザクション処理の未実装による処理の不完全性
在庫の移動処理では、複数のテーブルに対して同時に変更を加える必要があります。出庫処理を例に挙げると、「出庫テーブルへの履歴レコードの追加」と「商品マスタの現在庫数の減算」という2つの処理が同時に、どちらも完璧に完了しなければなりません。しかし、VBA（Visual Basic for Applications）のコード内でトランザクション処理（一連の更新を一塊の処理として扱う制御）が実装されていない場合、前者の履歴追加だけが成功し、後者の在庫減算のタイミングでネットワーク切断やエラーが発生して中断すると、片方の処理だけが適用されたままデータが保存されてしまいます。これが不整合の典型例です。
3. 現在庫数フィールドを直接上書きするテーブル設計の欠陥
データベース設計において、最もトラブルを招きやすいのが「商品テーブルの中に現在庫数という数値フィールドを持ち、入出庫のたびにその数値を直接上書きしていく」という設計です。一見シンプルに見えますが、この方法では「どの処理が原因で現在庫数が変わったのか」を過去に遡って検証することが不可能になります。一度でも計算ミスやシステムエラーによる上書きが発生すると、その時点でデータの正確性は完全に失われ、実在庫とのズレを検知することも困難になります。
4. 棚卸処理時の日付管理とデータ処理の一貫性欠如
棚卸の際、実在庫のカウント数値にシステムを合わせるために「在庫調整レコード」を挿入します。このとき、棚卸を実行した「日付」の扱いが曖昧な場合、不整合が生まれます。例えば、月内に発生した入出庫データをすべて入力し終える前に棚卸調整の数値を入力してしまったり、過去の日付で遡って入出庫データを後から追加修正したりすると、日付の整合性が崩れて在庫計算の基準値が狂ってしまいます。
原因究明のための「入出庫・棚卸・履歴」の確認ステップ
すでに在庫数が合わなくなってしまっている既存システムにおいて、原因となったバグや入力処理の抜け漏れを特定するための調査ステップを解説します。ただ闇雲にデータを眺めるのではなく、論理的な順序でデータを突合していく必要があります。
ステップ1：入出庫履歴とマスタデータの照合
まずは、対象となる商品の「期首在庫（または前回棚卸時の在庫数）」を起点とし、それ以降に発生した「入庫履歴」の累計を加算し、「出庫履歴」の累計を減算するクエリを作成します。この手動で再計算した数値と、現在システムが表示している画面上の在庫数、および実際の棚卸による実在庫数をそれぞれ対比します。もし「履歴の合算値」と「実在庫数」が一致しており、「画面上の在庫数」だけがズレている場合は、画面表示用のクエリやテーブルの更新プログラムに計算漏れのバグが存在することが判明します。
ステップ2：棚卸調整レコードの入力タイミングと整合性確認
直近の棚卸データがどのようにテーブルへ保存されているかを確認します。特に、棚卸の確定処理が行われた日時のあとに、その棚卸日よりも古い「伝票日付」で入出庫データが登録されていないかを調査します。伝票の入力遅れや、過去データの遡り修正が行われている場合、システムが算出する在庫遷移のロジックが破綻している可能性が非常に高くなります。
ステップ3：ユーザー操作ログとデータ更新履歴の確認
Accessファイルが共有フォルダに置かれている場合、不具合の原因がデータの上書きや競合によるものかを調べるために、更新日時ログを調査します。もしテーブルに「更新者」や「更新日時」を記録するフィールドが用意されていれば、不整合が発生した時間帯にどのような処理が重なっていたかを特定できます。こうしたログ機能がない場合は、システムの信頼性を向上させるために改修を検討すべき段階です。
| 評価項目 | 従来の不整合が起きやすい運用・設計 | 改善後の安全なデータベース運用 |
|---|---|---|
| 在庫管理の基本方針 | 現在庫フィールドの数値を毎回上書きする | 入出庫のトランザクション履歴をすべて残す | 同時アクセスの制御 | 排他制御がなく、後から書き込んだ値で上書き | レコードのロック制御により同時更新を防止 |
| システム異常発生時 | 処理が途中で止まり、データの片方のみ更新される | ロールバックにより処理前の健全な状態に復帰 |
| 棚卸データの調整 | 既存の現在庫を上書きして過去履歴を曖昧にする | 棚卸調整としての差分レコードを新規登録する |
不整合を防ぎ「在庫数が狂わない」Accessシステムへ改修する方法
不整合の原因が判明したら、システムが恒久的に正しい数値を維持できるように設計の改修を行います。Accessのポテンシャルを最大限に活かし、業務に耐えうる堅牢なシステムへアップデートするための具体的な対策を解説します。
対策1：入出庫履歴から「都度計算」する設計への移行
在庫数が合わなくなる最大の原因を排除するためには、商品マスタテーブルから静的な「現在庫数」という列を削除し、必要に応じて「入出庫履歴の合計」をその都度リアルタイムで算出するクエリ設計に切り替えます。
具体的には、「集計クエリ」を利用して、商品IDごとに『入庫数合計 － 出庫数合計 ＋ 初期在庫数（または棚卸時の確定数）』を計算させます。データ量が非常に多く、表示速度の低下が懸念される大規模なデータベースの場合は、月次などで在庫を締め切る処理（月次在庫確定テーブルの作成）を挟むことで、計算対象のレコード数を抑えつつ、データの整合性を完全に担保することができます。
対策2：VBAによるトランザクション処理の組み込み
データの不完全な更新を完全に防ぐため、データの保存を行うVBAプログラムにトランザクション制御を導入します。具体的には、DAO（Data Access Objects）またはADO（ActiveX Data Objects）の接続オブジェクトを使用して、処理の開始時に BeginTrans を宣言し、すべての更新処理（履歴の追加とマスタ関連の処理など）が正常終了したことを確認した上で CommitTrans を実行します。
もし途中で何らかのエラーが発生した場合は、Err オブジェクトのトラップ機能を用いて、速やかに Rollback を実行するようにコードを修正します。これにより、中途半端にデータが書き込まれる「データの孤立」を完全に防止できます。
対策3：ユーザー入力フォームの入力制限とバリデーション強化
運用時の人為的ミスを防ぐためのフォーム側の制御も重要です。例えば、一度確定した「過去の月度」に属する入出庫データをユーザーが誤って変更・削除できないよう、フォームの「編集許可」プロパティをVBAで制御します。また、未来の日付での出庫登録や、マスタに登録されていない無効なコードの入力を受け付けないバリデーションチェックを、登録処理を実行する前のイベントハンドラに必ず組み込むようにシステムを強化します。
自社でのAccess改修が難しい場合のプロへの相談基準
Accessは非常に自由度が高く、社内で手軽に機能を追加できる利便性がある一方で、長年の運用によってシステムが「スパゲティコード（複雑に絡み合った読めないプログラム）」と化しているケースが多々あります。以下のような兆候が見られる場合は、内製での無理な改修を避け、データベース開発の専門家に相談することを推奨します。
- 不具合の原因となっているVBAコードの記述箇所が特定できない、またはソースコードがパスワードでロックされて閲覧できない場合
- 一部のコードを修正すると、別のフォームやレポートで予期せぬエラーが誘発され、システム全体が不安定になる場合
- システムを構築した元々の開発担当者が退職・異動しており、仕様書や設計ドキュメントが一切残されていない場合
- 同時アクセス数が増え、データの破損（ファイル自体の破損やインデックスの破壊）が頻発する限界を迎えている場合
プロのシステム開発会社に現状のAccessファイルを見せることで、現在の設計上の致命的な弱点がどこにあるのかの「開発前診断」をすぐに受けることができます。既存のAccess資産を活かした部分改修で済むのか、あるいは将来を見据えて本格的なWebシステムや信頼性の高いデータベース（SQL Server等）に移行すべきなのかのロードマップを描いてもらうことが、業務効率化への最も近道となります。
現在庫テーブルを直接書き換える設計を、履歴計算に変更するには大がかりな改修が必要ですか？
テーブル構造自体を修正する必要があるため、それに関連する入力フォームやレポートの参照先クエリも書き換える必要があります。部分的な修正に比べると影響範囲は広いですが、今後データがズレなくなるメリットを考慮すれば、最も費用対効果の高い改修ポイントです。現状のファイルの構造によって難易度は変動します。
同時アクセスによるエラー（排他制御エラー）を防ぐ最も簡単な設定方法はありますか？
Accessのオプション設定にある「クライアントの設定」から、既定の開くモードを「共有」にし、既定のレコードロックを「編集済みレコード」に変更することで、簡易的な衝突回避は可能です。しかし、根本的な解決には、処理実行時のVBAコード側でのエラーハンドリング（衝突を検知して再試行するロジック）の実装が不可欠です。
長年の運用でAccessファイル自体のデータ容量が肥大化しているのも不整合と関係がありますか？
大いに関係があります。Accessファイルの容量制限（最大2GB）に近づくと、データベースの動作自体が極端に不安定になり、データの書き込み時にクラッシュして不整合が発生しやすくなります。定期的な「データベースの最適化」の実行や、蓄積された古いログデータを別ファイルへ退避するパージ処理の追加が必要です。
