金型・治具の保管ロケーション管理システムを検討するとき、棚番をスマートフォンで読めるだけでは足りません。重量のある型を「置ける棚」と「置いてよい棚」は異なります。重量、外形、支持方法、搬送機器の進入経路、棚の損傷状態を確認し、入庫した個体と間口を一対一で照合する設計が必要です。本稿はタイ工場の金型庫・治具庫を想定し、現物棚卸から要件定義、選定、受入試験までを具体化します。
金型・治具の保管ロケーション管理で解くべき問題
既存の金型管理システム導入ガイドでは、所有、ショット、保全、貸与型の台帳を扱いました。また治工具貸出管理システムの記事は個体ごとの貸出・返却・使用可否を扱っています。この記事の範囲はその前後にある物理保管です。型が金型庫へ戻った瞬間、どの間口に安全に載せられるか。その間口に本当に置かれたか。取り出すときにクレーンやフォークリフトが無理なく近づけるか。この三つを解く仕組みです。
金型庫の問題は「検索に時間がかかる」だけではありません。仮置きした型が台帳上は元の棚のまま、似た金型を別の間口へ誤格納、重い型を許容荷重の不明な棚へ置く、返却時の損傷を記録しないまま次の段取りで取り出す、といった事象が連鎖します。検索アプリだけを導入すると、誤った棚番を以前より速く表示することになりかねません。現物の置き方、棚の能力、移動の記録を一緒に決めるべきです。
「金型台帳」「貸出台帳」「保管ロケーション」の責任を分けます。金型台帳は型式、個体、所有者、対象製品、重量・寸法、保全状態の正本です。貸出台帳は誰がいつどのラインへ持ち出したかを扱います。保管ロケーションは建屋、ゾーン、ラック、段、間口、収容条件、現物占有状態の正本です。三者を連携させても、同じ項目を別々に手修正させないことが肝心です。
| 管理対象 | 主キー | 更新が起きる場面 | 誤りの影響 |
|---|---|---|---|
| 金型・治具の個体 | 個体ID | 登録・改造・廃棄 | 別の型を取り違える |
| 棚の間口 | ロケーションID | 棚の変更・損傷・閉鎖 | 不適合な場所へ格納する |
| 占有関係 | 個体ID+ロケーションID | 入庫・移動・出庫 | 現物と画面が食い違う |
| 移動イベント | イベントID | 実際の搬送完了時 | いつ誰が動かしたか追えない |
棚を「住所」ではなく「収容能力」として登録する
金型庫の棚番を A-03-02 と書いても、安全に格納できるかは分かりません。各間口に許容荷重、内法幅・奥行・高さ、支持面・受け具、段の高さ、荷の出し入れ方向、使用できる搬送機器、周囲のクリアランスを持たせます。金型側には実測重量、吊り具込み重量、外形と突出部、重心や支持点に関する注意、専用架台の有無を持たせます。必要な属性は実際の保管方式で変わるため、設備メーカーと現場責任者が現物を確認して決めます。ソフトウェアの画面に数値を入力するだけで棚の安全性が証明されるわけではありません。
収容判定は少なくとも「重量が棚・段・間口と取扱機器の確認済み能力内か」「型と架台が開口寸法に収まるか」「支持点が安定しているか」「搬送経路を確保できるか」「当該間口が使用停止でないか」に分けます。数値の単純比較で判断できない重心、片持ち、点荷重、地震対策、床荷重などは専門家の評価を受け、承認済みの組合せとしてマスタ化します。現場に『重量だけ合えばよい』という誤解を作らないためです。
英国HSEは保管設備が荷重に耐えられる設計・施工、損傷の報告と定期点検、搬送車両からの保護を勧めています。SEMAは棚の安全荷重表示を説明し、値が不明ならメーカーまたは専門家へ確認するよう案内しています。これらはタイ法上の義務を説明するものではなく、本稿の要件設計で参照する実務資料です。実際の設備適合と現地法令の確認は工場側で行います。

収容判定で「不明」を合格にしない
古い型では重量が未記入、改造後の外形が未更新、棚の耐荷重銘板が読めないことがあります。このときシステムが既定値で「空きあり」を返すのは危険です。重量不明、荷重能力不明、間口の損傷状態不明は、いったん格納候補から除外し、現物確認・設備担当承認へ回します。「不明」と「不適合」は区別して記録すれば、改善すべきマスタが一覧化できます。
同じ型でも架台付きと架台なしでは底面・高さが異なります。型本体の重量だけでなく、パレット、ベース、吊り治具を含めた搬送単位の重量と寸法を管理します。さらに、吊り上げ経路のクレーン能力と着地先棚の能力は別の確認です。片方だけが適合しても移動は開始しません。画面上の「候補表示」は現場の安全確認を代替せず、作業者が承認済み手順で実施する設計にします。
棚候補の優先順位を安全条件と分離する
システムが複数の間口を候補に返す場合、最初に適合・不適合を確定し、その後で作業効率に基づく順位を付けます。使用頻度が高い型を出入口の近くに置きたい、同じラインで使う型をまとめたい、空き間口を集約したい、といった理由は合理的ですが、重量や支持条件に優先させてはいけません。候補順位は「安全上の許可」を覆す権限ではなく、許可された場所の中から作業しやすい順に並べるためのものです。
同じラックの下段に重い型が集中した場合は、間口単位では適合してもラック全体の構成荷重や床への伝達を確認しなければなりません。棚メーカーの設計条件が間口だけでなく段・ベイ・列の荷重構成を指定していることがあります。システムが各間口の最大値だけを合計して「まだ余裕がある」と判断する設計は避け、設備担当が承認した配置条件を使います。型の重量と間口の荷重値が同じ単位で、架台や付属品の重量を含むかも明示します。
型を一時的に床へ下ろす作業も、無制限の「仮置き」を許してはいけません。安全な仮置き区画をロケーションとして定義し、区画の容量、通路からの離隔、搬送機器の通行を確認します。仮置きは時間制限や作業理由を持たせ、期限が過ぎた型を一覧に出します。ただし期限超過の通知が出ても、作業者が独断で動かしてよいという意味ではありません。適切な搬送計画と安全確認の下で移動します。
型の形状や用途によって専用架台が必要なら、型と架台をセットで識別します。架台を別の型に流用できるか、架台の状態確認が必要かをマスタで定めます。システムで「型は棚にある」と出ても、架台が修理中なら安全な再格納や搬送ができません。出庫時に型だけを追い、返却時に架台を忘れる運用を防ぐため、セットの不足を画面に示します。
ロケーション階層は現場で読める粒度にする
建屋→ゾーン→ラック→段→間口という階層を基本とし、ラベルは現場から見える位置に置きます。奥に二個並べる間口や、一つの床置き区画を複数の型が共用する場合は、左右・前後など位置を識別できる粒度を追加します。ただし細かくしすぎると作業者が正しいコードを探せません。現物を見て迷わず特定でき、違う場所への格納を検知できる最小単位にするのが実務的です。
「金型庫にある」だけでは、今すぐ取り出せるか分かりません。前列の型をどかさないと後列へ届かない間口は、奥行方向のアクセス制約を持たせます。大型型ではクレーン走行範囲、フック下高さ、フォークリフトの旋回空間、仮置き場所、取り出し順序も保管計画の一部です。ラックの能力が十分でも、搬送経路が塞がれば実際には出庫できません。通路を保管場所として数えないことも重要です。
GS1は個別資産の識別キーGIAIと物理的な場所を識別するGLNの使い分けを説明しています。GLNを棚の現物ラベルへ使う場合には、物理ロケーションを示すAI(414)が案内されています。自社内で閉じる金型庫にGS1キーが必須という意味ではありません。海外拠点や委託先と識別子を共有する場合は採用を検討し、社内だけなら衝突しない独自IDでも構いません。大切なのは、ラベルの表示文字、バーコード値、システムの主キーが一貫することです。
入庫の操作は「個体」と「置き場」の二つを照合する
入庫予定を登録するだけで所在を更新してはいけません。実際の格納後に、金型・治具の個体ラベルと棚の間口ラベルを順に読み、候補間口の適合判定、空き・占有状態、停止状態を再確認して移動イベントを確定します。ラベルが傷んで読めない場合は自由入力で通すのではなく、識別方法を指定した例外フローを用意します。適合判定が通っても、現場の目視で棚の変形や保管物のはみ出しを認めたら操作を中止できる必要があります。
一つの間口に一個体を置くなら、占有の一意制約をデータベースで守ります。共有区画なら容量単位と配置位置を明示します。同時に二台の端末が同じ空き間口へ入庫を試みた場合、後から確定する操作を拒否し、再選択させます。画面だけの「空き」表示では競合を防げません。オフラインで読み取る構成なら同期時に衝突するため、仮登録と確定の区別、衝突解決の担当者、現物照合の手順まで決めます。
出庫では個体を読んでから間口を読み、期待する位置との一致を確認します。現物が見つからないときに画面の所在だけを手修正する運用は避けます。「所在不一致」を独立した例外として記録し、周辺間口・仮置き・保全区域を確認してから修正します。例外の件数と理由を毎週見れば、無記録移動の起点を見つけられます。

返却時には保管可否と次回使用可否を分ける
戻ってきた型は、ただちに「使用可能」とは限りません。外観損傷、錆、付属部品不足、清掃・防錆未完了、点検待ちなどを記録します。ただし状態判定と物理的な保管先の判定も同じではありません。点検待ちの型を専用隔離区画へ置くことはあり得ますが、通常棚の空きとして扱うべきではありません。状態別に許容ロケーションを定義し、保全担当の承認があるまで通常使用へ戻せないようにします。
返却時の写真は、傷の有無を比較するため撮影面と距離を決めておきます。全写真を無制限に保存するのではなく、例外と判断が必要な箇所に絞る方が運用しやすいでしょう。付属品は金型本体と別個体として管理するか、セット内の確認項目として管理するかを決めます。使うときに欠品が判明する問題を防ぐには、返却画面での確認だけでなく、実際に付属品の収納位置まで確認できる設計が必要です。
保管ラック側も状態を持ちます。衝突痕、曲がり、アンカーの異常、荷重表示の欠落があれば「使用停止」にでき、候補選択から即時除外します。点検記録はラックと間口の両方へ紐付け、故障の範囲が一段だけかラック全体かを設備担当が判断します。米OSHAの倉庫安全資料は損傷したラックの周辺隔離、荷重能力を超えない保管、重い荷の低・中段への配置などを挙げています。ここでも現地法令の代用ではなく、検討項目の参考として利用します。
データモデルは「現在地」と「移動履歴」を両立する
現在地だけを上書きする表では、誤格納の原因を追えません。個体ID、旧ロケーション、新ロケーション、作業者、時刻、搬送方法、状態、理由、承認者を含む移動イベントを残し、現在地はイベントから更新します。訂正は履歴を消すのではなく、訂正イベントで表現します。個人を過度に監視するためではなく、現物確認と棚の利用判断を再現するためです。アクセス権と保存期間は自社の方針に合わせます。
金型台帳側から重量・外形などの属性を受け、保全システムから使用停止や点検完了を受け、貸出側へ所在と出庫可否を返します。ERPの固定資産番号と現物個体IDは一対一とは限らないため、別項目で関連付けます。ラインに載っている期間は「棚番なし」ではなく、ライン設備や作業区画をロケーションとして扱うか、貸出先を別の所在区分として持たせます。どちらの方式でも、同じ個体が同時に二か所に存在しない制約が必要です。
| 状態 | 物理所在 | システムの扱い | 次のアクション |
|---|---|---|---|
| 保管中 | 承認済み棚の間口 | 出庫候補 | 指図・予約と照合 |
| 搬送中 | 搬送タスク内 | 棚を占有しない | 着地先を読取確定 |
| 使用中 | ライン・設備 | 通常棚に空きを返す | 返却予定を管理 |
| 点検待ち | 指定隔離区画 | 使用不可 | 保全判定 |
| 所在不一致 | 確定不可 | 引当停止 | 現物調査 |
| 廃棄・返却済み | 敷地外 | 候補から除外 | 証跡を保管 |
RFPでは「画面数」より実演シナリオを指定する
現物棚卸で最初に作る三つのリスト
システム導入の前に、金型・治具、保管場所、未解決の所在差異を別々のリストとして起こします。個体リストには識別番号、型式、所有者、実測重量、外形、架台、現物写真、現在の使用状態を記録します。棚リストには区画・間口、銘板、確認済み荷重、内法寸法、支持方法、搬送方向、損傷・使用停止を記録します。差異リストには「現物はあるが台帳にない」「台帳にはあるが見つからない」「ラベルが複数付いている」「同じ棚番が二つの場所に使われている」を集めます。差異を無理に正しい値へ上書きせず、解決責任者と期限を置きます。
棚卸は同じ区画を二人で独立に確認すると、読み間違いを見つけやすくなります。重い型を動かして確認する必要がある場合は、棚卸のためだけに危険な搬送をしないよう、通常の安全な移動予定に合わせてラベルを確認します。寸法・重量は図面や過去の台帳の数字をそのまま信じず、型の改造履歴と突き合わせます。確認済みの値と推定値を混ぜないため、「出典」「測定日」「承認者」の欄を設けます。
初期データの品質は稼働後の検索精度を左右します。全個体の情報が揃うまで待つ必要はありませんが、対象区画で使う型の識別、現在地、格納可否に必要な属性は稼働前に確認します。未確認型を別区画で管理し、確認できた群だけをシステムの確定在庫へ移す方法もあります。現場での移動イベントを最初から記録しなければ、初期棚卸の翌日にデータが古くなります。
タイ工場での表示・権限・通信を決める
タイ語、日本語、英語のどれを画面とラベルに使うかは、日勤・夜勤の実際の作業者に合わせます。棚ラベルのコードは言語に依存しない短い文字列にし、説明文は画面側で切り替えます。エラー表示は「格納不可」だけでは不十分です。重量超過、寸法不適合、停止棚、占有中、個体の点検待ち、マスタ未確認のどれかを短く示し、誰へ連絡するかも表示します。翻訳の違いによって同じ操作が別の意味に受け取られないよう、受入試験には各言語の作業者を参加させます。
権限も役割ごとに分けます。現場作業者は入出庫の確定と例外報告、金型庫責任者は所在差異の解決、設備担当は棚の能力・停止状態の承認、型保全は型の状態判定、管理者はマスタ変更という形が考えられます。一人が棚能力を上げ、同じ人が直後に重量超過型を格納できる設計は避けます。承認の分離が難しい小規模工場では、変更理由と事後レビューを必須にする方法を検討します。
金型庫の無線が弱い場合は、入庫画面だけオフライン対応にするか、確定操作は通信できる地点で行うかを決めます。現物が先に動いてシステムだけ後で追う状態を放置しないことが重要です。端末に未送信イベントを明示し、同期前の二重格納を防ぐための運用を定めます。通信障害時の紙の代替記録は、復旧後に誰が照合し入力するかまで手順に含めます。
ベンダー比較で「バーコード対応」「ロケーション管理対応」に丸が付いていても、自社の重量型を安全に置けるとは限りません。RFPには実物に近い型の寸法・重量、棚配置図、搬送機器、現行の例外を匿名化して付け、実演シナリオを指定します。たとえば「重量が間口能力を超える」「同じ間口への二台同時入庫」「ラベルが読めない」「ラックを使用停止にした直後」「点検待ちの型を通常棚へ戻そうとする」を実演してもらいます。
価格比較ではライセンスだけでなく、棚の実測、現物ラベルの材質・貼付、端末、無線、マスタ整備、既存システム連携、現場教育、夜勤サポート、棚替え後の保守を同じ範囲で見積もります。金型庫が高温・油・粉じんにさらされるならラベルと端末の耐久性を現場で試します。費用は工場規模と設備で変わるため、ここで相場を断定しません。比較表に「前提条件」と「含まない作業」を併記する方が、見積り後の追加費用を避けやすくなります。
導入方式も選定項目です。ERPやEAMの標準ロケーション機能が棚の間口と収容条件を扱えるなら、既存機能を優先して拡張範囲を小さくできます。標準機能が移動履歴しか持たず、重量・寸法・支持条件や入庫時の二重照合ができなければ、金型庫専用の現場アプリを連携します。一般倉庫向けWMSをそのまま当てる場合も、荷姿や数量中心のモデルが「一個体の金型」と合うかを確認します。先に業務イベントとデータの正本を決め、製品名はその後で比較します。
受入試験は現物・棚・画面の三点一致で判定する
受入試験では「登録できた」を合格にしません。検証対象の型を選び、重量・寸法を実測したうえで、正しい棚、重量超過棚、寸法不適合棚、損傷で停止した棚、占有中の棚を用意します。端末で個体ラベルと間口ラベルを読み、許可・拒否が設計どおりか確認します。その後、現物の位置、ラベル、画面の現在地を三点照合します。入庫・出庫・別棚移動・返却の順に通し、履歴が残るかを確認します。
ネットワーク断と復旧、端末電池切れ、二重スキャン、ラベル再発行、型の改造による重量変更、棚の損傷登録も試験に含めます。とくに重量が変更された型に以前の棚を自動で許可し続けないことを確認します。マスタ変更時は既存の保管状態にも再評価が必要です。現物がすでに不適合な棚にある場合、移動先候補だけを止めても問題は残ります。

合否条件は定量化できます。試験対象の個体について「ロケーション二重占有ゼロ」「不適合間口への確定ゼロ」「例外処理後の現物・画面の一致」「停止棚が候補に出ない」を必須とします。検索時間の短縮などは自社の現状値を測り、同じ型群と時間帯で比較します。仮の数値を業界平均として使わず、サンプル数、測定条件、夜勤と日勤の差を記録します。
段階導入は一つの金型庫・一つの搬送経路から始める
稼働後に見る指標は「検索速度」だけにしない
検索に要した時間は分かりやすい指標ですが、それだけで成果を測ると、誤った棚番を素早く表示するシステムでも成功に見えます。現物・画面の一致率、所在不一致件数、無記録の仮置き件数、停止棚への格納試行、棚能力不明の間口数、返却時の損傷未判定件数を合わせて見ます。安全に関わる拒否を単純に「システムエラー」と数えないことも必要です。正しい拒否は保護機能が働いた結果です。
改善会議では、件数だけで作業者を責めないようにします。停止棚への格納試行が多いなら、空き棚の不足、ラベル位置、画面上の候補順、搬送経路の制約に原因があるかもしれません。例外ごとに現場を確認し、棚の配置を変えるのか、マスタを直すのか、画面の誘導を変えるのかを決めます。実際の物理作業とデータの整合性を継続して合わせることが、保管システムを使い続けられる条件です。
棚の配置変更はシステム変更だけで完了させません。旧ラベルを剥がす、新ラベルを貼る、残った型を移す、空間と能力を再確認する、現物棚卸を終える、という順序を一つの変更作業として扱います。途中で新旧二つの棚番が同時に有効になると、返却した型が旧間口へ戻される恐れがあります。変更日時を決めて対象間口を一時停止し、現場の責任者が現物を確認してから再開します。ラックを補修した場合も、単に「停止」を解除せず、補修内容と再使用の承認を残します。
拠点をまたぐ移送では、出荷元の棚から消した時点と、受入先の棚に置いた時点の間を「輸送中」として持ちます。トラックに載っている型をどちらかの工場の空き棚に残すと、計画担当が誤って引き当てます。委託先が保管する場合は、相手の棚番まで共有する必要があるか、外部保管先の区分だけでよいかを契約と運用で決めます。識別子を共有するなら、個体IDの重複と、返却時の読み替えを防ぐ設計が必要です。
このように、最初の対象区画を限定しても、移動、停止、修理、拠点間移送までの状態を先に描いておくと、後から拡大するときにデータの意味を変えずに済みます。現場で起きる例外を設計資料へ戻し、次の区画の導入条件に反映してください。
最初から全工場の型を登録すると、古い重量値や棚番の不整合を一度に抱えます。保管区画を一つ選び、現物棚卸、棚能力の確認、ラベル、入出庫フロー、例外処理を通してから拡大します。PoC中は紙台帳との二重入力を無期限に続けないよう、いつからどちらを正本にするか決めます。切替当日は全個体の所在地を確定し、未確認個体は「不明」として保留します。
担当者は少なくとも金型庫、型保全、生産管理、安全・設備、情報システムから参加します。金型庫は入出庫の作業性を、生産管理は次の指図に必要な型の検索を、設備担当は棚能力と搬送経路を、型保全は返却状態の判定を、情報システムはマスタ・権限・連携を確認します。全員の承認対象を一枚の表にしておけば、導入後に「誰が棚を開放できるか」が曖昧になりません。
既存の金型寿命予測と保全計画の記事は、型の状態と保全の判断をさらに掘り下げています。本稿の保管システムはその判定を受け、使えない型を通常棚の出庫候補から外す役割です。保全アルゴリズムやショット数の台帳まで保管画面に作り直す必要はありません。
選定会議で確認する「現物起点」の判断表
システムの見積りを依頼する前に、棚の適合判定がどの情報に基づくかを関係者で合意します。たとえば型の質量は、図面上の設計値なのか、改造後に実測した値なのか。棚の能力は、建設時の仕様なのか、現在のラック構成でメーカーが認めた値なのか。搬送可能性は、クレーンの定格だけでなく、吊り具、フックの高さ、旋回や着地の空間を含めて確認したのか。情報の出典が不明なまま自動判定を有効にすると、正確そうな画面が根拠の薄い判断を隠してしまいます。
次の判断表を作り、各項目について「確認済み」「要確認」「不適合」を分けます。重量や棚寸法が合っていても、型の底面が梁に安定して載らないなら格納できません。逆に、旧台帳で不適合とされていた間口も、設備担当の確認と必要な補修後には使えるかもしれません。承認の根拠と有効日を残し、画面上の判定結果だけを永久の事実として扱わないことが重要です。
| 確認項目 | 現物・資料で確認すること | システム上の制御 |
|---|---|---|
| 型の質量・外形 | 改造後の実測値、架台や付属品の有無 | 未確認なら候補から除外 |
| ラックの能力 | メーカー資料、銘板、現在の梁構成と損傷 | 停止中の間口を選択不可 |
| 支持と安定 | 底面、支持点、受け具、転倒・滑動の防止 | 承認済みの組合せだけ許可 |
| 搬送経路 | 使用機器、曲がり角、通路、吊り高さ | 到達できない間口を除外 |
| 格納の実在 | 個体・間口のラベル、占有状態、仮置き | 二重照合後に所在を確定 |
この表の判定は設備や安全の専門家を置き換えません。システムは確認済みの判断を現場の操作へ反映し、後で根拠を追えるようにする道具です。新しい型を登録した日、ラックを移設した日、梁の位置を変えた日、搬送機器を変更した日は再評価の起点にします。年一回の棚卸だけで更新する設計では、変化の早い金型庫に追い付きません。
停止・例外・再開の責任を画面に埋め込む
保管作業中にラックの変形を見つけたら、現場作業者がその間口を直ちに使用停止として報告できるようにします。ただし再開は同じ操作権限で即時にできない方がよいでしょう。設備担当が損傷範囲を確認し、必要な補修と点検を記録し、責任者が再使用を承認してから候補へ戻します。報告しやすさと再開の統制を分けることで、異常を隠さずに済みます。
型のラベルが読めない場合も、空欄の個体IDで入庫を確定しません。型式、現物写真、刻印、保全履歴を使って識別し、仮IDを発行するなら後で本IDへ統合する手順を設けます。似た外観の型を目視だけで確定することは避けます。棚ラベルが読めない場合は、近くの棚番を入力して流用するのではなく、間口の位置を責任者が確認し、ラベルを再発行します。例外を簡単に抜けるための隠れたボタンを設けると、二重照合の意味が薄れます。
使用予定のある型が点検待ちの区画にある場合、急ぎの製造指図を理由に状態を上書きしないことも重要です。生産管理へ「使用不可の理由と確認担当」を返し、代替型、保全の優先順位、段取り変更を判断できるようにします。棚から取り出せることと、生産で使用してよいことは別の判断です。出庫操作を許す場合でも、点検や修理へ運ぶ出庫と、ラインへ投入する出庫を区別します。
実データで試すべき境界条件
受入試験のサンプルは、最も扱いやすい標準型だけにしません。寸法が間口の限界に近い型、重心が偏る型、専用架台が必要な型、付属品を別置きする型、改造で重量が変わった型を含めます。現場の責任者が実物を選び、搬送機器と棚の状態を確認したうえで、安全な範囲だけを試験します。危険な格納を実演する必要はなく、不適合候補が端末上で拒否されることを確認すれば十分です。
棚側には、空き、占有中、点検停止、荷重不明、ラベル破損、搬送経路が塞がれた間口を用意します。一つの間口で複数条件が重なる場合、画面がどの理由を優先して示すかも見ます。たとえば「占有中」の警告だけでは、その棚が損傷で使用停止していることを見落とします。作業者に必要な情報を簡潔に見せつつ、責任者が詳細な根拠へ辿れるようにします。
試験結果には、画面の許可・拒否だけでなく、現物の最終位置、移動イベント、棚の占有表示、型の状態、例外処理の承認履歴を記録します。測定や判定に使った棚・型の版も残します。後日ラックを改造したとき、当時どの条件で合格したかを追えるためです。合格したサンプルだけで全棚・全型に適合すると断定せず、未試験の類型を残課題として明示します。
よくある質問
金型・治具の保管ロケーション管理システムはWMSで代用できますか?
WMSが個体ID、棚の間口、重量・寸法などの収容条件、使用停止、二重スキャン、移動履歴を扱えれば選択肢になります。一方、数量とロット中心のWMSでは、同じ型式の個体差や大型型の搬送条件を十分に表せないことがあります。実際の棚と型を使った受入試験で判断します。
バーコードとRFIDのどちらを選ぶべきですか?
まず「個体」と「間口」を確実に照合する運用を決めます。バーコードは低コストで読取対象を意識させやすい一方、ラベルの汚れや見通しに影響されます。RFIDは一括読取の余地がありますが、金属の型や棚、近接する個体で読取範囲を検証する必要があります。技術を先に決めず、現物環境で誤読・未読を試験します。
棚の耐荷重が分からない場合はどうしますか?
推測値を登録して自動承認しません。メーカー資料や銘板を確認し、不明なら設備担当と専門家の評価が終わるまで候補から外します。SEMAの技術FAQも、棚の安全荷重が不明ならメーカーまたは専門家へ確認するよう案内しています。
金型がラインに出ている間はどこを現在地にしますか?
ライン・設備を所在として登録するか、貸出先を別の所在区分として連携します。「棚番が空なので紛失」という表示にせず、搬送中、使用中、点検待ちを区別します。どの方式でも一個体が同時に二つの確定所在地を持たないようにします。
導入費用を比較するときに何を揃えるべきですか?
ソフトウェア費用だけでなく、棚の能力調査、型の重量・寸法確認、ラベル・端末・無線、ERP・保全連携、教育、例外運用、保守を同じ範囲で見ます。実測や棚の補修が必要かで費用は変わるため、現物調査前の固定額だけで選ばないことが重要です。
まとめ
金型・治具の保管ロケーション管理システムは、棚番検索の道具である前に、個体と間口の適合・占有・移動を現物と一致させる仕組みです。重量と外形だけでなく支持・搬送・棚の状態を確認し、入庫時に個体と間口を二重照合します。不明値や損傷棚を合格扱いしないこと、返却時の状態を出庫可否と分けること、現物を使った受入試験を通すことが導入の要点です。
タイ工場の金型庫で、棚の実測からデータ項目、端末操作、既存台帳との連携まで検討中であれば、要件が固まる前の段階でもTOMAS TECHに相談できます。現場の搬送手順と棚の条件を確認しながら、必要な範囲を一緒に整理します。