先入先出 管理 システム2026|タイ工場のFIFO・FEFO設計
先入先出 管理 システムは、古い在庫を手前へ置くだけの仕組みではありません。入荷、保管、払出、返品、移動、棚卸の各時点で、品目・ロット・期限・ロケーション・数量を同じルールで記録し、現場へ「次に取る在庫」を示す業務基盤です。本稿では、タイの工場・倉庫でFIFOとFEFOを混同せず、WMSや生産管理へ落とし込む要件を実務目線で整理します。
結論:先入先出は「入荷日の並べ替え」ではなく、受払イベントをつなぐ仕組みにする
FIFO(First In, First Out)は、原則として先に入った在庫を先に出す運用です。一方、FEFO(First Expiry, First Out)は、期限が早い在庫を先に出します。新しく入荷したロットの期限が既存在庫より早ければ、両者の出庫順は逆になります。食品、医薬品、医療関連品、接着剤、塗料など期限管理が品質に直結する品目では、FEFOが適する場合があります。
システム導入の要点は、次の5つです。
- 品目ごとにFIFO、FEFO、個別指定、出庫禁止の規則を定義する。
- 入荷日時だけでなく、ロット、期限、保管場所、在庫状態を受入時に記録する。
- 払出候補を端末へ表示し、別ロットを取る場合は理由と承認を残す。
- 移動、分割、統合、返品、保留、棚卸差異を在庫イベントとして即時記録する。
- 物理的な出庫順と会計上の在庫評価方法を別要件として設計する。
つまり、FIFOを守れるかどうかは、棚の配置だけでなく「いつ、どのロットが、どこへ、いくつ動いたか」を受払時点で確定できるかで決まります。紙や表計算でも小規模なら運用できますが、複数倉庫、複数ライン、夜勤、外部倉庫、返品が加わるほど、記録遅延と例外処理が先入先出を崩します。
FIFOとFEFOの違い:期限品を入荷順だけで出さない
WHOの倉庫管理マニュアルは、期限がある品目にはFEFO、期限がない品目にはFIFOを適用する考え方を示しています。また、新しく受け取った品でも既存在庫より早く期限を迎える場合があると注意しています。医療製品向けのWHO TRS 1025 Annex 7は2020年6月公開の文書ですが、2026年8月28日時点でもWHOの現行配布ガイドライン一覧に掲載されており、適切な在庫回転とFEFOを求めています。これはタイ国内法の代替説明ではなく、期限管理を設計する際の国際的な実務資料として参照します。
| 比較項目 | FIFO | FEFO |
|---|---|---|
| 優先キー | 入荷・受入・生成時刻 | 有効期限または優先日 |
| 向く品目 | 期限がない部品、包材、一般資材など | 食品、医薬品、有効期限のある化学品など |
| 例外 | 品質保留、顧客指定、設備適合、ロット固定 | 品質保留、最低残存期限、顧客別期限条件 |
| 必須データ | 品目、受入時刻、ロット、場所、状態、数量 | FIFO項目に加え期限、期限精度、残存期限条件 |
| 主な失敗 | 古いロットが奥に残る | 期限未入力、月単位期限の解釈不一致 |
品目マスターに「FIFO対象」というチェックだけを置くのでは不十分です。期限の有無、期限の入力単位、製造日からの算出可否、顧客が要求する最低残存日数、開封後期限、再検査日、品質状態を定義します。期限がない品目へ架空の日付を入れてFEFOを模擬すると、データの意味が曖昧になります。反対に、期限品を入荷時刻だけで並べると、後から入った短期限ロットを取り残します。
物理FIFOと会計FIFOは同じではない
倉庫のピッキングルールと、会計上の在庫評価方法は分けて考えます。たとえばWMSが古い受入ロットをピッキング候補にしても、ERPの原価計算は移動平均や標準原価かもしれません。逆に、ERPでFIFO原価を採用していても、現場が任意ロットを払出できる設定なら、物理在庫の回転は自動的には保証されません。
Microsoftの現行Dynamics 365在庫原価FAQも、FIFOを期末の在庫クローズと受払取引の決済に関わる原価モデルとして説明しています。したがってRFPでは、「FIFO対応」という一語で済ませず、物理引当、ピッキング指示、ロット実績、原価評価、月次締めを別々の受入項目にします。
先入先出 管理 システムに必要な12のデータ項目
先入先出を判定するには、現在庫の数量だけでなく履歴が必要です。GS1 Global Traceability Standardは、追跡イベントについて、イベント日時とタイムゾーン、追跡対象の個体またはロットID、場所、業務ステップと状態、必要に応じて責任主体を記録する考え方を示しています。GS1の現行標準ページは2026年8月28日に確認しています。
以下の12項目は、RFPと受入試験を具体化するための本稿の設計例です。GS1やタイ法が定める一律の最低項目ではなく、対象品目・顧客要件・既存システムに合わせて増減し、一つの在庫イベントへ結びます。
| No. | 項目 | 設計上の注意 |
|---|---|---|
| 1 | 品目ID | 表示名ではなく拠点共通の一意キーを持つ |
| 2 | ロット/バッチID | 仕入先ロットと社内ロットの対応を残す |
| 3 | 在庫単位ID | パレット、箱、袋など分割後も追えるID |
| 4 | 数量と単位 | 個、kg、mなど換算規則と端数を定義する |
| 5 | イベント種別 | 入荷、移動、払出、返品、調整、廃棄を区別する |
| 6 | イベント日時 | 端末時刻とサーバー受信時刻を区別する |
| 7 | 受入順序キー | 同時刻の場合の連番・優先順位を定義する |
| 8 | 有効期限 | 日付精度、未設定理由、算出根拠を持つ |
| 9 | ロケーション | 倉庫・ゾーン・棚・間口を階層管理する |
| 10 | 在庫状態 | 使用可、検査中、保留、不適合、廃棄待ちなど |
| 11 | 作業者・端末 | 誰がどの端末で確定したかを追跡する |
| 12 | 参照伝票 | 入荷、製造指図、払出、出荷、移動の伝票番号 |
「入荷日」は何を指すかも決めます。トラック到着、荷下ろし、検品開始、品質合格、在庫計上は別時刻です。FIFOの基準を品質合格時刻にする品目もあれば、物理受入時刻にする品目もあります。定義がないと、同じ荷物でも担当者やシステム連携順により出庫順位が変わります。

倉庫のロケーション管理:棚番だけでなく「取れる在庫」を管理する
倉庫のロケーション管理では、在庫が存在する場所と、現在ピッキング可能かを分けます。受入場、検査待ち、保留、通常棚、ピッキング面、戻り品、廃棄待ちは、同じ品目・ロットでも状態が異なります。数量だけを合算すると、検査中の短期限ロットが最優先候補になったり、実際には通路側から取れない奥のパレットを指示したりします。
ロケーションマスターには倉庫、ゾーン、列、段、間口、保管条件、容量、ピッキング順、混載可否、固定・フリー区分を持たせます。ただしマスターを細かくしすぎると、現場が移動を記録しなくなります。バーコードやハンディ端末で「移動元→在庫ID→移動先」を三点スキャンし、数秒で完了できる導線が必要です。
FIFOの候補順は、通常、次のような多段ルールになります。
- 使用可能状態だけを対象にする。
- 顧客、製造指図、品質、保管条件の制約で候補を絞る。
- FEFO品は期限、FIFO品は受入順序で昇順にする。
- 同順位ならピッキング順、開封済み、端数、搬送効率などで並べる。
- 最低残存期限を満たさない候補は出庫禁止または承認対象にする。
Oracle WMS Cloud 26Aの公式ドキュメントは、FIFOを在庫またはLPNの生成タイムスタンプ順、FEFOをPriority Date順として明確に区別しています。製品をそのまま採用するかに関係なく、RFPで優先キーと同順位処理を明文化する参考になります。
リアルタイム在庫管理は「即時入力」と「確定時点」を決める
リアルタイム在庫管理という表現は、画面の自動更新だけを意味しません。業務で重要なのは、物が動いた時点とシステム在庫が確定する時点の差です。作業後に事務所でまとめて入力すれば、その間に次の払出指示が古い在庫を参照します。先入先出を守るには、入荷、棚入れ、補充、払出、工程投入、返品の各作業点で確定する必要があります。
端末設計では、正常系だけでなく通信断も考えます。オフライン入力を許す場合は、端末内の発生時刻、再送順、重複排除用ID、競合時の保留方法が必要です。二人が同じ在庫を同時に取る可能性があるなら、引当、作業予約、スキャン時の再検証を組み合わせます。「在庫100」と表示されても、90が別作業へ引当済みなら、利用可能数は10です。
本稿の設計例では、イベントの状態を「作成」「予約」「作業中」「確定」「取消」の5つに分けます。これは普遍的な標準ではなく、業務に応じて統合・追加します。仮登録を現在庫へ反映するか、確定後だけ反映するかは業務ごとに決めます。工程投入では物理的に使用した時点、出荷では積込または出荷確定時点など、責任の切替点を統一します。
ハンディ端末で入力を増やさず証拠を増やす
現場の入力負荷を下げるには、手入力ではなくスキャン順で業務を表現します。払出なら「指示→ロケーション→在庫ID→数量」の順に確認し、システム候補と違うロットをスキャンしたら警告します。単純にエラーで止めるだけでは、急ぎ作業で端末が使われなくなるため、理由コード、監督者承認、代替候補を用意します。
端末導入の進め方はタイ工場のハンディターミナル導入ガイドも参照してください。タイ語・英語の短い表示、手袋での操作、照明、ラベル品質、無線の死角、充電・予備機まで含めて試験することが重要です。
受入から払出まで:FIFO/FEFOを崩さない標準フロー
1. 入荷予定と現物を照合する
発注・ASN・納品書の予定情報と、現物の品目、数量、仕入先ロット、製造日、期限を照合します。期限はラベルから読み取り、日・月・年の解釈やタイ仏暦表記が混在し得る場合は、入力形式と表示形式を分けます。期限が不明な在庫を勝手に最長期限として扱わず、「期限未確認」の状態で隔離します。
WHOのFEFO標準作業手順書は、受入時にバッチ/ロット番号、期限、棚・ラック位置を記録する考え方を示しています。医療物流向け資料ですが、期限品の受入要件を洗い出す参考になります。
2. 品質状態を付けて棚入れする
受入直後から使用可能にするのか、品質検査後に解放するのかを品目別に定義します。検査待ち在庫は数量として見えても、払出候補から除外します。合格時には状態変更イベントを記録し、FIFO基準時刻を受入時のまま維持するか、解放時刻にするかを決めます。
3. 補充と移動を記録する
リザーブ棚からピッキング棚へ移す際に、在庫IDを維持します。別容器へ小分けする場合は、親IDと子ID、分割数量を記録します。複数ロットを一つの容器へ混ぜる運用は追跡を難しくするため、許可条件を限定します。
4. 引当と払出を分ける
システムは規則に従って候補を引き当てますが、実績は現場のスキャンで確定します。候補と実績の差を保存すると、棚配置、ラベル、保留、作業指示のどこに問題があるか分析できます。顧客指定ロット、試作用在庫、設備別の材料適合など、正当な例外は理由コードとして管理します。
5. 返品と残材を元の履歴へ戻す
工程から戻る未使用材料や出荷取消品を、新規入荷として登録すると順序が崩れます。元のロット、期限、開封状態、保管逸脱、残量を確認し、使用可否を判定して戻します。元IDを維持できない場合は新IDを発行し、親子関係を残します。

在庫差異の原因と対策:数量調整だけで閉じない
在庫差異の原因と対策では、帳簿を現物に合わせるだけでなく、どのイベントが欠けたかを特定します。差異調整を頻繁に行うと画面上の数量は合っても、FIFOの受入順、ロット、期限、場所の履歴は回復しません。原因コードと是正処置を分けて記録します。
| 差異パターン | よくある原因 | システム・運用対策 |
|---|---|---|
| 数量は合うがロットが違う | 類似ラベル、候補外ピック、戻し間違い | ロット必須スキャン、例外承認、棚の分離 |
| 帳簿はあるが現物がない | 未記録移動、払出後入力、紛失 | 作業点入力、移動三点スキャン、空棚確認 |
| 現物はあるが帳簿がない | 返品未処理、受入保留、ラベル脱落 | 返品専用フロー、仮ID、未処理キュー |
| 期限が一致しない | 手入力、日付形式、ラベル貼替 | 形式検証、元ラベル画像、変更承認 |
循環棚卸は、全倉庫を一度に止める棚卸だけではありません。高回転品、差異多発品、期限接近品、空ロケーションなどリスクに応じて対象を選びます。棚卸者に帳簿数量を見せないブラインドカウント、再カウント承認、差異確定前の取引制御を設計します。Oracleの現行Cycle Count資料もロケーション単位の在庫確認を扱っています。
KPIは「差異率」だけでは不十分です。候補外ピック率、期限未入力件数、保留在庫の滞留日数、移動未完了件数、棚卸再カウント件数、短期限廃棄数量などを原因別に追います。ただし本稿では改善率の普遍的な数値を提示しません。効果は導入前後で同じ定義・同じ対象期間を比較して確認します。
例外管理:現場を止めずにFIFO逸脱を見える化する
先入先出を100%強制すると、品質保留、顧客指定、ライン停止、棚への到達不能などで作業が止まります。反対に、警告をいつでも無視できると規則は形骸化します。本稿の設計例では、例外を「禁止」「監督者承認」「理由入力」「自動許可」の4段階に分類します。実装時は品質規程と権限設計に合わせて調整します。
たとえば、使用不可状態の在庫は原則禁止、最低残存期限を下回る出荷は品質承認、同じ期限内での別ロケーション選択は理由入力、同一ロット内の別容器は自動許可、といった段階を設けます。承認者は個人名に固定せず役割で指定し、緊急時の代行と事後確認も定めます。
ダッシュボードでは例外件数だけでなく、指示候補、実績、理由、承認者、発生工程を並べます。同じ理由が繰り返される場合、作業者の問題と決めつけず、棚配置、補充タイミング、マスター、顧客条件、システム応答時間を見直します。
WMS・生産管理・ERPの役割分担
WMSはロケーション、在庫単位、引当、ピッキング、移動、棚卸に強みがあります。生産管理/MESは、製造指図、工程投入、出来高、仕掛、材料消費、製造ロットとの関係を持ちます。ERPは購買、販売、会計、全社品目、在庫評価の正本になることが多いですが、実際の役割は既存構成に合わせて決めます。
インターフェースでは、品目、単位、倉庫、ロット、期限、在庫状態、伝票、取消を対象にします。「一日一回在庫を連携」ではリアルタイム引当が成立しないため、どのイベントを即時、どれを集計で送るかを分けます。重複送信、順序逆転、通信断、マスター未登録が起きたとき、エラーを捨てず保留キューへ置きます。
費用を検討する際はライセンスだけでなく、ラベル、ハンディ端末、無線、プリンター、マスター整備、既存システム連携、教育、現地保守を含めます。比較の観点はタイ工場向けWMS費用ガイドに整理しています。
導入要件:RFPと受入試験で確認するチェックリスト
製品デモでは正常な入出庫は確認できますが、実運用の成否は例外で決まります。RFPには機能名ではなく、データ、規則、操作、証拠、復旧を記載します。
マスター・規則
- 品目ごとにFIFO/FEFO/個別指定を設定できる。
- 受入順序キーと同順位時の優先規則を説明できる。
- 期限、最低残存期限、品質状態、顧客条件を組み合わせられる。
- ロット分割、統合、再包装、単位換算の履歴を保持できる。
- マスター変更の申請、承認、適用日、履歴を残せる。
現場操作
- タイ語または現場で合意した言語で短く指示を表示できる。
- バーコード不良、数量差、候補外ロット、通信断を処理できる。
- 作業の途中保存、取消、再開が二重計上を生まない。
- 端末交換後も未完了作業を安全に引き継げる。
- 権限に応じて例外承認と在庫調整を制御できる。
監査・復旧
- 変更前後、作業者、時刻、端末、理由を検索できる。
- 在庫残高から受払履歴へ、履歴から原伝票へ遡れる。
- ERP連携失敗を検知し、再送しても重複計上しない。
- バックアップからの復元後に在庫と未処理イベントを照合できる。
- CSV出力だけでなく、データ定義とコード値を引き渡せる。

受入試験の設計例:10シナリオ
次の10件は一律の認証基準ではなく、対象範囲に合わせて追加・変更する受入試験の例です。
- 同一品目で古い受入と新しい受入を作り、FIFO候補を確認する。
- 後から受け入れたロットの期限を早くし、FEFO候補を確認する。
- 最優先ロットを品質保留にして、次候補へ切り替わることを確認する。
- 顧客の最低残存期限を満たさない在庫を除外する。
- パレットを分割し、親子数量と期限が一致することを確認する。
- 候補外ロットをスキャンし、警告、理由、承認を記録する。
- 通信断中に作業し、再接続後の順序と重複排除を確認する。
- 返品を元ロットへ関連付け、状態判定後に再利用する。
- 棚卸差異を再カウントし、調整前後の履歴を確認する。
- ERP連携を一度失敗させ、再送後も在庫が二重にならないことを確認する。
テストデータは、実在顧客や機密品目を避けつつ、タイ語名、英語名、類似品番、異なる単位、月末、年末、同時刻、期限なしを含めます。合格条件は画面表示だけでなく、履歴、API、帳票、在庫残高まで照合します。
段階導入:90日で業務ルールを検証する例
90日は法定期間でも万能な標準でもなく、対象範囲を限定した導入例です。第1段階で一つの倉庫・品目群のマスターと現状フローを整理し、第2段階で端末、ラベル、引当、例外、連携を試し、第3段階で夜勤、通信断、棚卸、月次照合を含めて本番可否を判断します。
| 期間例 | 主な活動 | 完了証拠 |
|---|---|---|
| Day 1–30 | 現状調査、品目分類、FIFO/FEFO規則、ロケーション整備 | 承認済み業務フロー、マスター定義、差異ベースライン |
| Day 31–60 | 受入・移動・払出・返品、端末、ラベル、ERP連携 | シナリオ試験記録、例外一覧、教育記録 |
| Day 61–90 | 夜勤運用、通信断、棚卸、復旧、月次照合 | 受入判定、未解決課題、運用責任表、展開計画 |
対象を最初から全品目へ広げず、期限品、ロット追跡品、高回転品など、課題が見えやすい範囲を選びます。ただし、簡単な正常系だけを選ぶと本番の例外を検証できません。返品、保留、分割、単位換算、緊急払出を含む品目群にします。
FAQ
先入先出 管理 システムとは何を管理するものですか?
入荷日の一覧だけでなく、品目、ロット、期限、数量、ロケーション、在庫状態と、入荷・移動・払出・返品・調整の履歴を管理します。規則に基づく払出候補を現場へ示し、候補外を選んだ理由と承認も残すことで、物理的な在庫回転を支えます。
FIFOとFEFOはどちらを選ぶべきですか?
期限がない品目はFIFOが基本候補です。食品、医薬品、有効期限のある材料などはFEFOが適する場合があります。実際には品目特性、品質保証、顧客の最低残存期限、保管条件、現地の規制・契約要件を確認して決めます。両者を同義として設定しないことが重要です。
倉庫のロケーション管理では固定棚とフリーロケーションのどちらがよいですか?
一律の正解はありません。固定棚は見つけやすい一方で空間効率が下がりやすく、フリーロケーションは柔軟ですが移動記録と端末利用が必須です。高回転のピッキング面は固定、リザーブはフリーなど、品目特性と作業動線で組み合わせます。
リアルタイム在庫管理には常時オンラインが必須ですか?
常時オンラインが望ましい場面は多いものの、倉庫の通信断をゼロにはできません。オフラインを許すなら、イベントID、発生時刻、再送順、競合検知、重複排除、復旧後照合を設計します。画面更新の速さだけでリアルタイム性を評価しないでください。
在庫差異の原因と対策で最初に見るべき点は何ですか?
数量を修正する前に、最後に正しかったイベントと、欠けた移動・払出・返品・調整を探します。数量差、ロット差、期限差、場所差を分け、原因コード、再発防止、担当、期限を記録します。差異調整だけではFIFO履歴は直りません。
WMSがあれば先入先出は自動的に守れますか?
いいえ。マスター、ラベル、棚配置、スキャン、例外承認、教育、ERP/生産管理連携が揃って初めて機能します。デモでは候補が正しくても、現場が別ロットを取り、後で一括入力すれば履歴は崩れます。実業務の例外シナリオで受入試験を行います。
まとめ
先入先出を定着させるには、FIFOとFEFOを品目別に区別し、入荷・期限・ロット・ロケーション・状態を受入時に確定し、移動と払出を作業点で記録する必要があります。物理ピッキングと会計原価を分け、候補外ピック、返品、保留、通信断、棚卸差異を例外として追跡できることが重要です。システム選定では「FIFO対応」の有無ではなく、優先キー、制約、端末操作、履歴、連携、復旧をシナリオで確認してください。
タイ工場でFIFO/FEFO、ロケーション管理、ハンディ端末、既存ERP・生産管理との連携を整理したい場合は、要件が固まる前の段階でもTOMAS TECHへご相談ください。現場フローと在庫データを確認し、無理なく運用できる範囲から検討できます。
参考資料
- WHO TRS 1025 Annex 7: Good storage and distribution practices for medical products(2020年6月17日公開、2026年8月28日にWHO現行配布一覧を確認)
- WHO Guidelines: Distribution(2026年8月28日に現行一覧を確認)
- WHO eManual: Warehouse and Stock Management(2026年8月28日確認)
- WHO Standard operating procedures: FEFO(2026年8月28日確認)
- GS1 Global Traceability Standard(2026年8月28日現行版ページ確認)
- Oracle WMS Cloud 26A: Choosing an Allocation Method(2026年8月28日確認)
- Oracle WMS Cloud 25D: Expiration Dates(2026年8月28日確認)
- Microsoft Learn: Inventory costing FAQ(2026年8月28日確認)