レシピ管理が壊れるのは「1つのレシピ」で全拠点を運用しようとしたとき
化学・食品・医薬品の工場でレシピ管理の作り直しが発生する典型は、次の状況です。A工場で確立した処方を、B工場に横展開しようとする。ところがB工場の反応釜は容量が違い、撹拌機の型式が違い、原料メーカーも違う。結果として「B工場向けレシピ」を新規に作り、以後は2つのレシピが独立して改訂されていきます。3拠点になれば3つ、品種が20あれば60のレシピを個別管理することになります。
このとき失われているのは、「製品としてどう作るか」と「この設備でどう動かすか」が別の情報であるという区別です。前者は全社共通で、後者は拠点固有です。ISA-88（バッチ制御の国際標準、ANSI/ISA-88.00.01）は、まさにこの区別をレシピの階層として定義しています。
ISA-88が定める4つのレシピ階層
ISA-88はレシピを、汎用（General）／サイト（Site）／マスタ（Master）／制御（Control）の4階層に分けます。上位ほど設備から独立し、下位ほど特定の設備に結びつきます。
冒頭の失敗例をこの図に当てはめると、A工場とB工場で本来違うのはマスタレシピだけです。汎用レシピとサイトレシピは共通のまま置ける。品質に関わる要求値（反応温度の許容範囲、pHの規格）は上位に持ち、装置固有の設定（撹拌回転数、昇温レート）は下位に持つ。この分け方を最初にやっておくと、横展開は「マスタレシピを1本追加する」だけの作業になります。
設計で決めること：6項目
レシピ管理の要件定義で必ず決着させるべき論点は、次の6つです。ベンダーのデモでは見えない部分なので、RFPの段階で明示的に問う価値があります。
| 決めること | 選択肢 | 判断の目安 |
|---|---|---|
| MESが持つ階層 | サイト＋マスタ／マスタのみ／制御まで | 多拠点なら汎用・サイトを分離。単一拠点ならマスタのみで足りる |
| スケール則 | 線形／非線形（関数定義）／段階テーブル | 撹拌・伝熱が絡む工程は線形にならない。関数を持てるかを確認 |
| パラメータ許容範囲の所在 | レシピ内／品目マスタ／規格マスタ | 規制産業では規格マスタに置き、レシピは参照のみにするほうが監査で説明しやすい |
| 有効日と版の関係 | 版ごとに有効期間／指図発行時に版を固定 | 進行中バッチのレシピ版が途中で変わらない仕組みが必須 |
| 承認フロー | MES内ワークフロー／外部QMS／PLM | eBRを伴うなら電子署名の要件と揃える |
| 逸脱の扱い | ブロック／記録付き続行／権限者承認で続行 | 3種を工程ごとに使い分けられるかが実装差になりやすい |
このうち実務で最も揉めるのがパラメータ許容範囲の所在です。レシピの中に「温度80〜85℃」と書き込む実装は簡単ですが、規格が変わるたびに全レシピを改訂することになります。規格マスタを別に持ち、レシピからは参照するようにしておけば、規格改訂は1か所の変更で済みます。
よくある実装の失敗
失敗1：ディスクリート工場が「レシピ」という言葉だけ借りる。 組立や機械加工の工場でも、条件設定（溶接電流、圧入荷重、締付トルク）をレシピと呼ぶことがあります。これ自体は問題ありませんが、ISA-88の階層を無視して1つのテーブルに設備名とパラメータをフラットに並べると、設備の入れ替え時に全行を書き換えることになります。ディスクリートでも「製品としての要求値」と「設備固有の設定値」は分けてください。
失敗2：制御レシピの実績値をMESに戻していない。 マスタレシピは「こう作れ」という指示ですが、記録として価値があるのは制御レシピが実際に何をしたかです。設定値だけを記録して実測値を戻していないと、逸脱調査のときに「指示どおりの設定だったが結果が違う」以上のことが言えません。バッチエンジンからの実績書き戻しは、接続設計の最初に決める項目です。
失敗3：レシピ改訂の影響範囲を検索できない。 「この原料の規格が変わった。影響するレシピはどれか」に答えられない構造だと、改訂のたびに全件目視確認が発生します。原料・設備・パラメータからレシピを逆引きできるかは、稼働後の運用工数を大きく左右します。
製品による実装差
レシピ管理は、MES製品のなかでプロセス産業向けとディスクリート向けの差が最も大きく出る機能です。
プロセス産業に強い製品群は、ISA-88の階層とバッチエンジン連携を前提に作られています。AVEVA MESやDELMIA Aprisoのように制御層の製品系列を持つベンダーは、マスタレシピから制御レシピへの受け渡しが製品内で完結する設計を取ります。Velotic（旧GE Vernova Proficy）は2026年リリースでプロセス製造要素を拡張したと公表しており、ディスクリート起点の製品もプロセス側へ機能を広げている状況です。Critical Manufacturingは2026年時点でロットマッチングに対応したバッチ管理を追加しています。
一方、ディスクリート起点の製品では「レシピ＝パラメータセット」に留まり、スケール則や物質収支を持たないものがあります。半バッチ・ハイブリッド型の工程（混合してから成形する、調合してから充填する）を扱う工場では、この差が要件を満たせるかどうかの分かれ目になります。デモでは「パラメータを設定して設備に送る」ところまでしか見えないので、スケール則と物質収支の有無は個別に確認します。
なお、レシピ情報を外部システムと交換する標準としては、MESA Internationalが公開する BatchML（ISA-88に対応したXMLスキーマ。B2MMLと同じリポジトリで管理）があります。バージョン7が2020年11月24日にリリースされ、XMLに加えてJSONスキーマ定義が追加されました。PLMからMESへレシピを流す設計を取るなら、この語彙に寄せておくとインターフェースの議論が短くなります。標準の詳細はISA-88とバッチ制御、プロセス産業MESの前提、記録側の設計はeBR・eDHR（電子バッチレコード）とは何かで扱います。
よくある質問
ISA-88に準拠していないMESでは、バッチ生産はできないのですか？
できます。ISA-88は認証制度ではなく、モデルと用語を提供する標準です。準拠していない製品でもバッチ生産の管理自体は可能です。ただし、レシピの階層分けをせずに実装した場合、多拠点展開や設備更新のたびにレシピ全体の作り直しが発生します。単一拠点・少品種であれば実害が出ないこともありますが、将来の横展開が視野にあるなら、標準の階層に沿ったデータモデルにしておく価値があります。詳細はMESのマスタ設計、品目・工程・設備・作業者も参照します。
レシピはMESとDCS（バッチエンジン）のどちらで管理すべきですか？
役割で分けます。制御レシピの実行はバッチエンジンの仕事です。MESが担うのは、マスタレシピの版管理、承認、指図への割り当て、そして実行結果の記録です。両方でレシピを持つと二重管理になりますが、「MESがマスタを持ち、実行時にバッチエンジンへ配信する」構成であれば重複しません。実装上の論点は、配信のタイミング（指図発行時か、バッチ開始時か）と、バッチエンジン側でオペレータが値を変更できる範囲をどこまで許すかです。後者は逸脱記録の設計と直結します。
医薬品のようにレシピ変更に規制が絡む場合、どこまでMESで完結できますか？
変更管理（Change Control）そのものはQMS側のプロセスであり、MESで完結させないほうが一般的です。MESが担うのは、承認済みのレシピ版だけが製造に使われることの保証と、いつ・誰が・どの版を使ったかの記録です。EU GMPのAnnex 11改訂案（2025年7月7日公開、意見提出期限2025年10月7日）は、監査証跡とアクセス管理を従来以上に重視する構成に再編されており、レシピの版管理と操作履歴が審査対象になる前提で設計します。
- ISA88: Batch Control（International Society of Automation）
- MESA Releases Version 7 of B2MML and BatchML Specifications（Automation.com）
- B2MML-BatchML リポジトリ（MESA International、GitHub）
- See what's new in Proficy 2026（GE Vernova）
- Drafts of EU GMP Guideline Annex 11, Annex 22 and Chapter 4 released for comment（ECA Academy、2025年7月7日）
