LIMSと品質管理システムの役割分担｜MES・ERP連携で決めるデータの持ち場

LIMSを入れる段になって止まるのは、機能の比較ではなく「どこまでを試験室のシステムで持ち、どこから基幹側に渡すか」の線引きです。既にMESや生産管理システムが動いている工場では、ロット番号も検査記録も複数の場所に存在し、後から入るLIMSがどれを正とするかを決めないまま接続すると、同じ数字が二重に管理されます。本記事では、LIMS・MES・ERP・品質管理システムの守備範囲をISA-95の考え方で整理したうえで、試験依頼から判定結果の返却までの受け渡し点、ロット紐付けの粒度、連携方式と周期の決め方、そして既存システムへの追加開発とスクラッチを分ける境界を、受託開発の実務目線で解説します。

まとめ｜LIMSと基幹側の持ち場を分ける三つの判断軸と連携設計の結論

結論から示します。役割分担で先に決めるのは、機能の割り振りではなく識別子の発番元です。検体番号をLIMSが発番し、ロット番号は基幹側（MESまたは生産管理システム）が発番する。この一点を固定すると、以降の設計は自動的に決まっていきます。逆に両方が採番できる構成にすると、突合表を人手で保守する運用が残り続けます。

二つ目の軸は、試験の判定結果が在庫ステータスを動かすかどうかです。合格するまで出荷引当をかけられない品目があるなら、判定結果は基幹側の在庫属性を書き換える経路が要ります。ここを帳票の印刷だけで運用している工場では、保留品の出荷という事故が構造的に起こります。帳票そのものの設計と発行フローは検査成績書とは？試験成績書・COA・ミルシートとの違いと発行フローの組み立てで整理しています。

三つ目は、再試験と規格改訂の反映経路です。1回目の不合格と2回目の合格が両方残り、どちらが有効かをシステムが判別できること。規格値を改訂したとき、過去のロットは旧規格で判定された事実が保持されること。この二つを満たさない連携は、監査で必ず指摘されます。

連携方式は、試験件数と出荷判定の締め時刻で決まります。1日あたりの試験依頼が数十件で、出荷判定に半日の余裕があるならCSVの日次連携で足ります。判定待ちが出荷そのものを止めていない限り、APIによる即時連携は費用に見合いません。既存パッケージへの追加開発で済むか、スクラッチに切り替えるかの分岐は、連携点の数と独自の合否判定ロジックの有無で判断してください。

LIMS・MES・ERP・品質管理システムの守備範囲｜ISA-95が示す四つの運用管理

4種類のシステムが混在すると、名前の似た機能があちこちに現れます。用語の定義や機能の一覧はLIMSとは？読み方と試験室データ管理の機能・導入手順を判断軸まで解説で整理しているため、ここでは接続を前提にした守備範囲の切り分けだけを扱います。

品質運用管理はレベル3の一領域｜生産・保全・在庫と並ぶLIMSの位置

製造業のシステム階層を扱う規格にISA-95（国際規格ではIEC 62264）があります。このパート3は、製造運用管理を生産・品質・保全・在庫の四領域に分け、四領域が同じ構造の活動モデルを共有する形で定義しています（2026年8月時点の規格構成）。

この構造が実務で効くのは、LIMSを「MESの外側にある別物」ではなく「品質運用管理を担う同じ階層の相方」として置けるからです。生産運用管理が作業指示と実績収集を回すのと対称に、品質運用管理は試験依頼と試験結果を回します。守備範囲がもめたときは、四領域のどれに属する活動かを先に確定させてください。

レベル3の活動をさらに細かく分解した内容や、設備から実績を取り込む方式の選び分けはMESシステムとは：製造実行システムの11機能とISA-95レベル3の実装要件に譲ります。本記事はLIMS側から見た接続面に絞ります。

どのデータを誰が持つか｜検体・ロット・規格値のマスタ所有権の決め方

連携設計の実体は、マスタの所有権を1件ずつ決める作業です。品目と取引先は基幹側、試験項目と規格値はLIMS側、工程と設備はMES側。もめるのは規格値です。

規格値を基幹側の品目マスタに持たせている工場は珍しくありません。しかし試験項目には有効数字・測定条件・判定方式（上下限、片側規格、外観の官能判定）といった属性が付き、品目マスタの1項目では表現しきれなくなります。試験に関する属性はLIMS側を正とし、基幹側には「試験対象かどうか」のフラグだけを持たせる構成が保守しやすい形です。

顧客ごとに規格が違う受託製造では、規格値のキーが品目と顧客の組み合わせになります。受注情報を持つ基幹側から顧客コードを渡さないとLIMS側で規格が決まらないため、受注データの連携を先に設計してください。

品質管理システムとLIMSが重なる領域｜不適合管理をどちらに寄せるか

既に品質管理システムが動いている工場でLIMSを追加すると、不適合管理が両方に現れます。試験で規格を外れた検体はLIMSに不合格として残り、その製品ロットの処置は品質管理システムの不適合票として起票される、という二重構造になりがちです。

切り分けの基準は、記録の対象が検体か製品かです。試験値そのものと再試験の履歴はLIMSに置き、隔離・特別採用・廃棄といった製品ロットへの処置は品質管理システムに置く。LIMS側は不合格の事実と検体IDを渡すだけにとどめ、処置の進捗は追わない構成にすると責務が重なりません。不適合管理を含む機能の全体像は品質管理システムとは？機能・種類と選び方、パッケージ導入か自社開発かの判断まで解説を参照してください。

試験依頼から結果返却までの連携設計｜四つの受け渡し点と失敗する型

LIMSと基幹側のやりとりは、細かく見れば数十のメッセージになりますが、設計上押さえる受け渡し点は四つに集約できます。ここを図に落としてから機能要件を書くと、手戻りが減ります。

受け渡し点1と2｜ロット確定の通知と試験依頼データの送り方の設計

1つ目は、試験の対象となるロットが確定した事実の通知です。製造指図の完了、原料の入荷検収、中間工程の完了といったイベントが起点になります。基幹側またはMES側から、ロット番号・品目コード・数量・製造日時をLIMSへ渡します。

2つ目は試験依頼です。ロット通知をそのまま依頼と見なす設計と、依頼を別データとして起票する設計があります。抜取検査の頻度が品目ごとに違う工場では後者が要ります。「3ロットに1回」「初回と最終ロット」といった採取ルールをどちらに実装するかで、後の改修範囲が変わるためです。採取ルールは変更が頻繁なので、業務側で設定を変えられるLIMS側に置くほうが運用は回ります。

依頼データには、ロット番号のほかに、どの規格で判定するかを決める情報を必ず含めます。顧客コード・仕向地・製造ラインのいずれかが判定条件に絡む工場では、これを漏らすと後から全依頼の項目追加になります。

受け渡し点3と4｜判定結果の返却と出荷可否を止める在庫ステータス

3つ目は試験結果の返却です。ここで返すのは合否フラグだけではありません。測定値・単位・試験実施日時・判定に使った規格の版・承認者を一緒に返す設計にしてください。合否だけを返す連携は、後から「なぜ合格したのか」を追えなくなります。

4つ目が在庫ステータスの更新です。判定結果を受けて、基幹側の在庫属性を「試験中」から「出荷可」または「保留」へ変える経路を作ります。この経路がない工場では判定結果を紙で回すことになり、繁忙期に必ず取りこぼしが出ます。

特別採用（規格外だが所定の承認を経て出荷を認める処置）の扱いも、この段で決めます。LIMS側は不合格のまま保持し、基幹側で出荷可へ上書きした事実と承認者を別項目に残す。判定を書き換えて合格にする実装は、監査で証跡の改変とみなされる余地を残すため避けてください。

連携が破綻する典型｜再試験と規格変更が片方にしか反映されない状態

稼働後に問題が出るのは、ほぼこの2パターンです。1つは再試験。1回目が不合格で2回目が合格だったとき、基幹側に「合格」だけが上書きされて1回目の記録が消える実装が多く見られます。有効な判定はどれかというフラグを持たせ、履歴は残す設計にします。

もう1つは規格の改訂です。規格値を書き換えると、過去ロットの判定根拠まで変わってしまう実装が典型的な失敗になります。規格マスタに有効期間を持たせ、判定時点の版を試験結果側に記録する。この二重化を最初から入れておくと、改訂のたびに過去データを凍結する作業が不要になります。

ロット紐付けの設計｜検体IDとロットIDを結ぶ粒度と分割時の扱い

試験結果を製造ロットに結びつける部分は、連携で最も設計コストがかかります。1対1で済む工場は少なく、1ロットから複数検体、複数ロットをまとめて1検体という関係が混在します。

識別子の設計｜検体番号を発番するのはLIMSか基幹側かの決め方

検体番号はLIMSが発番するのが原則です。試験室の中で採取・分注・再試験が発生するたびに識別子が増えるため、外部から採番するとロット通知の件数と検体の件数が合わなくなります。ロット番号は基幹側またはMES側が発番し、LIMSは受け取って保持するだけにします。

両者を結ぶのは、検体レコードに持たせるロット番号の外部キーです。注意したいのは、ロット番号の桁数と体系が将来変わる可能性。合併や新ラインの追加で採番体系を変えた工場では、LIMS側が旧体系の桁数で項目定義していたために改修が発生した例があります。文字列型で余裕のある桁を確保してください。

ロットが分割・統合される工程｜親子関係を試験結果に引き継ぐ方法

製造ロットは工程を進むうちに分割され、統合されます。仕込み1ロットを複数の包装ロットに分けた場合、包装ロットごとに試験をやり直すのか、仕込み時点の試験結果を引き継ぐのかを品目ごとに決めておく必要があります。

引き継ぐ設計を選ぶなら、ロットの親子関係を基幹側が保持し、LIMSは検体が紐づく親ロットだけを持つ形が単純です。逆に、包装後にも試験を行う品目では子ロットに対する検体が別に立つため、同じ製品に対して階層の違う試験結果が並びます。この2種類が混在する工場では、試験結果の画面に「どの階層のロットに対する試験か」を必ず表示させてください。

統合（複数ロットをまとめて1ロットにする処理）はさらに扱いが難しく、実務では統合ロットに対して改めて試験を行う運用に寄せるほうが、システムの複雑さを抑えられます。

原料ロットと製品ロットの橋渡し｜受入試験の結果を追跡表につなぐ

受入試験の結果は、原料ロットに紐づきます。製品の品質に問題が出たとき、使用した原料ロットまでさかのぼって受入試験の値を確認できるかどうかが、回収範囲を絞れるかどうかを分けます。

この経路を作るには、原料ロットと製品ロットの使用関係を基幹側またはMES側が記録している必要があります。LIMS単体では作れない部分なので、既存システムに使用実績の記録がない工場では、そちらの改修が先に来る点に注意してください。追跡の範囲をどこまで広げるかという判断は製造業のトレーサビリティとは？追跡範囲とロット・シリアルの使い分け、追加開発の判断で扱っているため、連携範囲を決める前に読んでおくと見積の精度が上がります。

連携方式の選び方｜ファイル・中間テーブル・APIの適用条件と周期

方式の選定は技術的な好みではなく、試験件数と出荷判定の締め時刻から逆算します。過剰な即時性を要件に入れると、費用が膨らんだうえに復旧手順が複雑化します。

三方式の比較表｜工事不要のファイル連携から常時接続のAPIまで

CSVの受け渡しは軽視されがちですが、試験依頼が1日数十件で判定に半日の余裕がある工場では、これで十分に回ります。障害時の切り分けが容易な点も運用部門には利点です。

中間テーブル方式は、双方から読み書きできるテーブルを立てて連携する構成です。既存パッケージがAPIを公開していない場合の現実解になりますが、テーブルの排他制御と再送の設計を省くと、二重取り込みが避けられません。REST APIによる連携は、判定待ちが出荷を止めている工場や、複数拠点のLIMSを1つの基幹に集約する構成で見合います。方式選定と接続仕様の設計をまとめて相談したい場合はAPI開発・システム連携で対応しています。

同期の周期を決める基準｜出荷判定に間に合う遅延許容の見積もり方

周期は「試験完了から出荷判定までに許される時間」から決めます。出荷便の締めが16時で、試験の完了が平均14時なら、許容遅延は2時間。ここに障害時の再送とオペレーターの確認時間を見込むと、実務上は30分周期のバッチで足ります。即時連携が要るのは、許容遅延が15分を切る場合に限られます。

逆方向、つまり基幹側からLIMSへのロット通知は、試験の着手待ちが発生しない周期にします。採取が製造完了の直後に行われる工程では、ロット通知が1時間遅れると試験室が手待ちになります。方向ごとに周期を変える設計は珍しくありません。連携方式そのものの基礎的な考え方はAPI連携とは？仕組み・データ連携との違い・導入判断までわかりやすく解説にまとめています。

B2MMLなど標準スキーマを使う条件と独自項目が多い場合の判断

ISA-95のオブジェクトモデルをXMLスキーマとして実装したB2MMLは、MESA Internationalが公開・維持しています（版は公開元で時点を確認してください）。パッケージ製品どうしをつなぐ場合、双方がB2MMLに対応していれば項目のマッピング工数が下がります。

一方で、標準スキーマは万能ではありません。試験項目の属性や社内独自の判定区分は拡張領域に押し込むことになり、結局はマッピング表を作る作業が残ります。判断基準は接続先の数です。3システム以上をつなぐ計画があるなら標準スキーマを土台にし、2システムまでなら独自の項目定義で進めるほうが早く動きます。

どこまでLIMSで持つか｜基幹側へ渡す境界を決める五つの判断材料

機能の割り振りで迷ったときは、次の五つを順に当てます。データの更新頻度、監査で問われる範囲、業務側が設定を変える頻度、他システムからの参照の多さ、製品を乗り換えたときに失うものの大きさです。

LIMSに残す機能｜試験手順の版管理と分析機器のデータ取り込み

試験手順書の版管理、分析機器からの測定値取り込み、試験の進捗と担当者の割当、監査証跡。この4つはLIMSに残します。いずれも試験室の中で完結し、外部からの参照が少なく、規制対応で証跡の連続性が求められる領域だからです。

機器連携は特に外へ出せません。機器ごとに出力形式が異なり、ドライバや取り込み定義がLIMS製品の資産になっているためです。ここを基幹側に持たせようとすると、機器を1台入れ替えるたびに基幹システムの改修が発生します。

基幹側へ寄せる機能｜在庫の引当と出荷指図・原価計算への実績反映

在庫の引当、出荷指図、原価への実績反映、取引先とのやりとり。この4つは基幹側です。LIMSに在庫機能を持たせると、基幹側の在庫と数量が合わなくなります。検体の消費数量を在庫に反映したい場合も、LIMSは消費実績を渡すだけにして、残高は基幹側の1か所で持ってください。

試験費用を原価に載せる要件があっても、配賦のロジックは基幹側に置き、LIMSは実績データの供給元に徹する構成にしてください。

線引きを誤ると起きること｜規格マスタの二重管理と監査証跡の分断

線引きの失敗で最も多いのが規格マスタの二重管理です。基幹側とLIMS側の両方に規格値があり、改訂のたびに両方を直す運用は、いずれ片方が古いまま残ります。参照専用でよいほうは持たせず、必要なときに問い合わせる構成にしてください。

もう一つが監査証跡の分断です。試験値の変更履歴はLIMSに、在庫ステータスの変更履歴は基幹側にあり、両者を突き合わせる手段がない状態は、査察で説明に窮します。連携時に相手側のトランザクションIDを保持していなければ、事後の突合はできません。工程内検査や出荷検査を含む現場側の運用設計は製造業の品質管理とは｜受入・工程内・出荷検査と不適合管理をシステムで回す進め方で整理しています。

追加開発とスクラッチの判断｜既存資産と改修コストで分かれる境界

既存のLIMSパッケージや基幹システムが稼働している状態で連携を作るとき、既存への追加開発で済ませるか、連携部分を別に作るかの判断が要ります。材料は連携点の数と独自ロジックの深さです。

既存LIMSへの追加開発で足りる条件｜連携点が三つ以内に収まる場合

接続する相手が基幹1系統、受け渡し点が四つ以内、そして送受信する項目が製品標準のインタフェース定義でまかなえる。この条件がそろえば、既存パッケージへの追加開発で足ります。費用も期間も、別システムを立てる場合とは桁が変わります。

確認すべきは、連携インタフェースに項目の追加ができるかどうかです。標準項目しか送れない製品では、顧客コードや仕向地といった判定条件を渡せずに詰まります。契約前にインタフェース定義書を取り寄せ、渡したい項目が入るかを1件ずつ照合してください。

スクラッチを選ぶ条件｜受託試験の見積連動と独自の合否判定ロジック

受託試験を事業として行っており、試験項目の組み合わせから見積を作り、実施実績から請求までつなぐ。この業態はパッケージの想定範囲を超えます。見積・受注・実施・請求が試験項目単位で連動する仕組みは、既製品の改造よりスクラッチのほうが安く収まる例が多いためです。

もう一つは判定ロジックが独自な場合です。複数試験の結果を組み合わせて総合判定する、経時変化の傾向から出荷可否を判断する、顧客ごとに異なる規格を自動で適用する。こうした要件は製品の設定機能では表現しきれず、改造の積み重ねでバージョンアップができない状態に陥ります。

開発に踏み切る前の確認｜既存パッケージの連携仕様と保守契約の範囲

開発を決める前に、既存パッケージの保守契約を確認してください。ベンダー以外が改修した場合に保守対象外となる条項があり、不具合の切り分けで揉める原因になります。

確認する項目は三つです。第三者による連携開発を認めるか、データベースへの直接アクセスを認めるか、バージョンアップ時に連携部分の動作保証があるか。いずれも「できない」と回答された場合は、パッケージの外側に連携用の層を立て、公開されたインタフェースだけを使う構成に切り替えてください。

よくある質問

LIMSと品質管理システムは両方入れる必要がありますか？

試験室で分析を行い、その結果で出荷可否を判断する工程があるならLIMSが要ります。工程内検査と不適合の是正処置が中心で、分析機器からのデータ取り込みがない工場なら、品質管理システムだけで足りる場合があります。目安は分析機器の台数です。機器が数台あり、測定値を手で転記している状態が続いているなら、LIMSの追加に見合います。

MESが入っていればLIMSは不要ではありませんか？

MESの品質機能で扱えるのは、工程内での測定値の記録と規格との照合までが中心です。検体の分注、試験手順の版管理、機器からの自動取り込み、試験室内の進捗管理といった業務は範囲外になる製品がほとんどです。試験室が独立した組織として動いており、依頼を受けて分析するという業務形態なら、MESの機能では回りません。

LIMSとERPの連携は標準機能でできますか？

製品によりますが、標準機能だけで完結する例は多くありません。ロット通知と結果返却の枠組みは用意されていても、判定条件に使う項目の追加や在庫ステータスの書き換えは個別の設定または開発になります。「標準連携あり」の表記を鵜呑みにせず、四つの受け渡し点それぞれについて標準で対応できるかを確認してください。

連携のテストはどのように進めればよいですか？

本番と同じロット番号体系のデータを用意し、正常系だけでなく再試験・特別採用・ロット分割の3ケースを必ず含めます。この3つは稼働後に必ず発生する一方、テストから漏れやすい組み合わせです。加えて、連携が止まった状態から復旧したときに二重取り込みが起きないかを確認してください。

既存のExcel台帳から段階的に移行することはできますか？

できます。おすすめの順序は、まず試験結果の記録をLIMSに移し、基幹側との連携は当面CSVの手動取り込みで運用する形です。記録の入力が定着してから自動連携に切り替えると、業務側の負担が分散します。逆に、連携の自動化を先に作り込むと、入力ルールが固まる前に仕様を凍結することになり、稼働後の改修が増えます。

関連記事

• LIMSとは？読み方と試験室データ管理の機能・導入手順を判断軸まで解説：本記事の親記事で、定義・機能分類・提供形態と導入手順を整理しています。
• 品質管理システムとは？機能・種類と選び方、パッケージ導入か自社開発かの判断まで解説：不適合管理を含む機能の全体像と選び方を扱っています。
• MESシステムとは：製造実行システムの11機能とISA-95レベル3の実装要件：レベル3の活動分解と設備実績の取り込み方式を実装目線で解説しています。
• 製造業のトレーサビリティとは？追跡範囲とロット・シリアルの使い分け、追加開発の判断：追跡範囲をどこまで広げるかの判断基準をまとめています。