資材所要量計画システム（MRP）開発の完全ガイド

資材所要量計画システム（MRP）は、需要・BOM・在庫・リードタイムを連動させ、必要な資材を「いつ、何を、いくつ」手配するかを算出する仕組みです。

資材の欠品による生産停止と、欠品を恐れた過剰在庫は、製造業の計画担当者が抱えやすい代表的な課題です。MRPを導入すれば計算を自動化できますが、BOMや品目コードが不正確なままでは、誤った発注提案を速く出すだけになってしまいます。本記事では、MRPの全体像、種類、開発・導入の進め方、2026年時点の費用目安、開発会社・ベンダーの選び方、最新動向までまとめて解説します。

資材所要量計画システム（MRP）とは何ですか？全体像を解説します

MRPとは、Material Requirements Planningの略称で、日本語では資材所要量計画と呼ばれます。完成品の需要を部品表に沿って下位の部品・原材料へ展開し、在庫や発注残を差し引いたうえで、製造または購買の必要量と必要日を計算する仕組みです。単なる在庫一覧ではなく、需要を供給計画へ変換する計画エンジンである点が重要です。

MRPが計算する流れ

たとえば完成品を1,000個つくる計画があり、1個あたり部品Aを2個使う場合、まず部品Aの総所要量は2,000個と計算されます。そこから現在庫、入荷予定、すでに引き当てた数量を差し引き、さらに安全在庫を維持するための数量を加えます。部品Aの調達リードタイムが10日なら、完成品の生産開始日から逆算して、少なくとも10日前までに入荷するよう購買または内製の提案が作成されます。

実際の計算には、MPS（基準生産計画）、BOM、在庫残高、購買発注、製造指図、仕入先の納期、ロットサイズ、休日カレンダーなどが使われます。需要が受注だけでなく販売予測や内示を含む場合は、確定度の違いを区別して、どの需要を計画へ反映するかを業務ルールとして定義する必要があります。

導入前に整えるべきマスタ情報

MRPの精度を左右するのは、計算アルゴリズムだけではありません。品目コード、単位、BOMの構成と有効期間、工程、調達区分、標準リードタイム、発注ロット、安全在庫、発注点、仕入先、休日カレンダーがそろって初めて、現場で使える提案になります。BOMの旧版が残っている、同じ部品に複数の単位が使われている、標準リードタイムが担当者の経験だけで決まっている、といった状態は、先に改善する必要があります。

導入前には、品目マスタの重複率、BOMの登録率、在庫差異、納期実績と設定リードタイムの差、購買発注の未完了データを棚卸しします。目標値は、たとえば在庫差異率、欠品件数、緊急購買件数、納期回答時間、計画担当者の作業時間として設定します。導入後に効果を判断するには、導入前の基準値を記録しておくことが欠かせません。

MRPの種類と生産管理・ERP・APSの違いを整理します

MRPは単独で導入することもできますが、実務では販売、購買、在庫、製造、会計、倉庫、設計などのシステムとデータを連携させて使います。名前が似ているMPS、ERP、APS、生産管理システムとは役割が異なるため、導入範囲を決める前に境界を整理することが大切です。

MPS・生産管理システム・ERPとの違い

MPSは、どの完成品をいつどれだけ生産するかという上位の計画です。MRPはMPSを受け取り、完成品を構成する部品や原材料へ分解して、購買・内製の必要量を計算します。生産管理システムは、受注、製造指図、工程進捗、品質、原価など、製造実行に関わる広い業務を管理する仕組みです。ERPは会計や販売、購買、人事なども含めて企業全体の情報を統合する基盤であり、その一機能としてMRPを持つ場合があります。

したがって、MRPを導入すれば生産現場のすべてが自動化されるわけではありません。MPSの立て方が不安定なら、MRPは不安定な計画を部品レベルへ展開します。現場の実績収集が遅ければ、在庫や仕掛の状態が計算へ反映されず、現実と異なる提案が出ます。上位計画、実行管理、実績入力を一つの業務フローとして設計することが重要です。

能力計画・APS・DDMRPとの使い分け

一般的なMRPは、資材が必要な時期と数量を計算しますが、設備の稼働時間、金型、作業者、ラインの順序などの能力制約を十分に扱わないことがあります。塗装ラインや特定の熟練者がボトルネックになる場合は、有限能力計画やAPSと連携し、資材の到着時期と設備・人員の空き状況を同時に確認します。

DDMRPは、需要変動が激しい環境で、戦略的に置いたバッファ在庫と実消費を起点に補充する考え方です。従来型MRPの代替と決めつけるのではなく、品目や工程ごとに、予測を中心に計画する部分と、消費実績を中心に補充する部分を使い分けます。2026年1月更新の公式解説でも、DDMRPは従来型MRPを拡張する選択肢として説明されています（出典：需要駆動型補充に関する公式解説、2026年）。

資材所要量計画システムの開発・導入はどのように進めますか？

MRP開発は、いきなり画面を作り始めると失敗しやすい領域です。まず生産方式とデータの現状を把握し、標準機能で実現する範囲と独自開発する範囲を切り分けます。その後、代表的な品目とBOMで計算を検証し、連携・移行・教育を含めた段階導入へ進めると、現場の停止リスクを抑えられます。

現状分析と要件定義で決めること

最初に、見込生産、受注生産、個別受注、多品種少量、プロセス製造のどれに該当するかを整理します。次に、対象工場、品目数、BOMの階層数、月間の受注量、在庫拠点、仕入先数、同時利用者、既存システム、連携方式を一覧化します。内示と確定受注の扱い、納期変更、仕入先遅延、返品、BOM改訂、代替部品、分納といった例外も、要件定義の段階で確認します。

KPIは、欠品率だけでなく、在庫回転日数、緊急購買件数、納期回答にかかる時間、計画作成工数、MRP再計算時間、計画変更への反映時間で設定します。例えば「計画変更を翌営業日までに反映する」「主要品目のBOM登録率を100％にする」といった測定可能な目標が必要です。経営層、計画担当者、購買、製造、倉庫、経理、情報システムの各担当者が同じ指標を見る体制も整えます。

データ整備と小規模PoC

要件を決めたら、品目・BOM・在庫・受注・発注残・リードタイムのデータをクレンジングします。コードの重複、単位の揺れ、廃止品の扱い、在庫の保管場所、BOMの有効開始日と終了日を確認し、移行後の責任者を決めます。マスタを情報システム部門だけで直すのではなく、現場と購買が「この値なら発注できる」と判断できる状態まで整えることが大切です。

PoCでは、1工場または主要品目に対象を絞り、需要投入からBOM展開、在庫差し引き、ロット計算、リードタイム逆算、購買・製造提案までを一連で試します。正常系だけでなく、納期変更、部品欠品、仕入先の遅延、BOM改訂、代替部品、通信断を含めて検証します。PoCの目的は画面の見た目を確認することではなく、計算結果を現場が信頼して手配へつなげられるかを確かめることです。

設計・開発・テスト・切替

設計では、BOMの版管理、計算の再実行、計算ログ、アクションメッセージ、承認権限、APIの冪等性、監査ログ、バックアップとリストアを定義します。MRP計算は大量データを扱うため、夜間バッチだけでなく、差分計算や非同期ジョブが必要かも確認します。購買、販売、在庫、製造、倉庫、会計との連携では、送受信項目、エラー時の再送、重複登録の防止、データの責任部署を明確にします。

テストは、単体テスト、連携テスト、業務シナリオテスト、性能テスト、障害復旧テスト、受入テストの順に進めます。切替時は、在庫残高、発注残、製造途中の仕掛、未処理受注をいつの時点で確定するかを決め、旧システムとの並行稼働期間を設けます。全工場を一度に切り替えるより、1拠点で手順を固めてから対象を増やす段階導入のほうが、計画停止のリスクを抑えやすくなります。

資材所要量計画システムの費用相場とコストの内訳

MRPの費用は、製品の月額やライセンスだけでは決まりません。対象拠点、品目数、BOM階層、利用者数、連携先、データ移行、カスタマイズ、教育、保守運用によって大きく変わります。以下の金額は、2025年に公開された生産管理システムの相場と業務システム開発の一般的なレンジをもとにした目安であり、MRP単体の確定価格ではありません。

▶ 詳細はこちら：資材所要量計画システム（MRP）開発の見積相場や費用/コスト/値段について

導入方式別の初期費用と期間

SaaS・クラウド型は、初期10万〜100万円、月額2万〜20万円程度が公開相場の一例です。標準機能に業務を合わせやすく、数週間から2〜3か月で始められるケースがありますが、マスタ移行、API連携、教育は別費用になりやすいです。パッケージ・オンプレミス型は初期200万〜800万円程度、年間保守は本体価格の10〜15％程度が一つの目安で、導入期間は数か月を見込みます（出典：国内の生産管理システム公開相場、2025年）。

複数拠点を連携するパッケージ導入は、1,000万〜5,000万円程度、期間は6〜12か月程度と推定されます。独自のBOM、特殊な内示処理、有限能力計画、複数拠点間の在庫補充までスクラッチで実装する場合は、1,000万円から数千万円、大規模な基幹刷新では5,000万円〜1億円超になる可能性もあります。いずれも公開相場からの推定であり、データ移行と連携数が増えるほど上振れしやすい点に注意が必要です。

見落としやすい追加費用と5年TCO

見積書では、ライセンスや開発費のほかに、要件定義、現状調査、データクレンジング、移行、連携アダプター、帳票、テスト環境、教育、マニュアル、切替支援、問い合わせ対応、バックアップ、監視、脆弱性対応、追加ユーザーの費用を分けて確認します。クラウドの場合も、APIの利用量、保存容量、利用者追加、サポートレベルによって月額が変わることがあります。

費用比較は初期費用だけでなく、5年間のTCOで行います。クラウド利用料、保守、マスタ更新、追加開発、サーバーやネットワーク、教育の再実施、障害対応を合計し、欠品による停止、過剰在庫、緊急輸送、計画担当者の工数がどれだけ減るかと照らし合わせます。スクラッチの場合は、初期費用の15〜25％程度を年間保守運用費として置く考え方もありますが、監視時間や工場休日対応を含むかによって変わります。

クラウド・パッケージ・スクラッチの選び方

方式選定では、費用の安さよりも、生産形態、業務の差別化要因、既存システム、拠点数、現場のIT環境、将来の拡張性を見ます。見込生産で標準的なBOMと購買業務を扱う企業と、個別受注で案件ごとに構成が変わる企業では、必要な柔軟性が異なります。選択肢を先に決めるのではなく、要件と制約から適合性を判断します。

クラウド・SaaS型が向くケース

クラウド型は、初期投資を抑えながら短期間で標準的なMRPを始めたい企業に向きます。アップデート、バックアップ、インフラ運用を任せやすく、拠点や利用者を段階的に増やせる点もメリットです。一方で、標準業務への適合、データの所在、ネットワーク断時の継続方法、APIの制限、工場設備との接続方式を確認する必要があります。

パッケージ・ERP内蔵型が向くケース

パッケージ型は、製造業で使われる標準機能や業界テンプレートを活用し、MRP計算の実績を確認したい企業に向きます。会計、販売、購買、在庫と一体化したERP内蔵型なら、品目や取引のマスタを一本化しやすいです。ただし、全社ERP刷新と同時にすべてを変えようとすると、対象範囲が膨張します。まず対象工場や主要業務を区切り、標準機能に合わせられる業務と、競争力に直結する差分を分けます。

スクラッチ・ハイブリッド型が向くケース

スクラッチ型は、独自のBOM、特殊な補充ルール、製番ごとの計画、独自の能力制約など、標準機能だけでは競争力を再現できない企業に適しています。ただし、仕様の凍結、テスト、保守人材、法改正対応、障害復旧を発注側も担う必要があります。ハイブリッド型では、在庫・購買・MRPのコアをパッケージやERPに置き、現場入力、ワークフロー、分析、連携を別のクラウドやデータ基盤で補います。境界とデータの責任者を明確にできるかが成功条件です。

工場設備やIoTと接続する場合は、ITネットワークとOTネットワークの分離、リモート接続の制御、資産の可視化、バックアップ、復旧手順まで設計します。経済産業省は2025年4月、中小規模の製造事業者向けに工場セキュリティの重要性と始め方を示す資料を公開しています（出典：経済産業省「工場システムにおけるサイバー・フィジカル・セキュリティ対策ガイドライン」関連資料、2025年）。

開発会社/ベンダーの選び方

MRPの発注先は、知名度や機能数だけで決められません。自社の生産方式、BOMの複雑さ、対象拠点、既存システム、現場の運用体制に適合し、導入後もマスタと計画を改善できる相手を選ぶ必要があります。製品を提供するベンダーと、要件定義・設定・開発・移行・保守を担う実装パートナーが異なる場合もあるため、契約前に役割分担を確認します。

製造業実績と生産方式の適合性

まず、見込生産、受注生産、個別受注、繰返生産、プロセス製造など、自社と近い生産形態の導入実績を確認します。導入件数の多さよりも、BOMの版管理、内示と確定受注、代替部品、製番、ロット、複数工場の在庫補充など、自社の難所を経験しているかが重要です。可能であれば、匿名化した実データに近いサンプルで、計画結果と例外処理をデモしてもらいます。

連携・移行・保守の実行力

評価するのは、MRP画面の機能だけではありません。販売・購買・在庫・WMS・MES・PLM・会計・EDIとのAPI、バッチ、CSVの使い分け、エラー時の再送、マスタの同期、データ移行のリハーサルを確認します。導入後の問い合わせ窓口、障害時の復旧目標、休日の工場対応、アップデート時の回帰テスト、追加開発の単価も見積書に含めます。

提案時には、要件定義、データ診断、PoC、設計、開発、テスト、教育、切替、稼働後改善の担当者と成果物を明記してもらいます。発注先がマスタ整備を顧客責任とするなら、どの項目をいつまでに誰が直すのかを決めます。費用が安く見えても、移行や連携が別見積になっていると、稼働直前に予算と期間が膨らむためです。

PoCとRFPで比較する質問

候補先には、第一に「BOMを改訂したとき、旧版の有効期間と仕掛品をどう扱うか」を尋ねます。第二に「内示が減ったとき、確定受注と発注済み資材をどう区別するか」を確認します。第三に「仕入先の遅延、在庫差異、代替部品、休日カレンダーを計画へどう反映するか」を聞きます。第四に「計算結果を誰が承認し、購買・製造指図へどうつなげるか」を確認します。

RFPには、対象範囲、用語定義、品目数、BOM階層、対象拠点、現行システム、連携先、データ量、権限、性能、監査ログ、バックアップ、導入スケジュール、教育、保守、想定するテストシナリオを記載します。候補先には同じ条件で、標準機能、設定、アドオン、個別開発、外部連携を分けた見積を依頼します。価格だけでなく、業務適合性30％、MRP・BOM機能25％、連携・拡張性20％、導入・保守体制15％、価格透明性10％など、社内の評価軸を先に定めると比較しやすくなります。

▶ 詳細はこちら：資材所要量計画システム（MRP）開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：資材所要量計画システム（MRP）開発の進め方/やり方/流れや方法/手法/工程/手順

▶ 詳細はこちら：資材所要量計画システム（MRP）開発の発注/外注/依頼/委託方法について

よくある質問（FAQ）

MRPを検討するときは、機能、費用、データ、導入期間、AI活用のどこから確認すべきか迷いやすいです。ここでは、発注前に質問されやすい内容を、判断に使える形で回答します。

MRPと生産管理システムは同じものですか？

同じものではありません。MRPは需要を部品・原材料の必要量と手配時期へ展開する計画機能で、生産管理システムは受注、製造指図、工程実績、品質、原価などを広く管理する仕組みです。生産管理システムの中にMRPを含む場合や、ERPの一機能としてMRPを利用する場合があります。

MRPはクラウド型とオンプレミス型のどちらが良いですか？

標準業務を短期間で始め、インフラ運用を軽くしたいならクラウド型が候補になります。工場のネットワーク制約、特殊な処理、設備との接続、データの保管要件、障害時の継続方法を重視するなら、オンプレミスやハイブリッド型も比較します。どちらが優れているかではなく、5年TCOと業務継続性を含めて判断します。

AI需要予測を追加すればMRPの精度は上がりますか？

AIを追加するだけでは精度は上がりません。過去の受注、欠品、キャンセル、季節性、販促、営業内示などのデータが正しく蓄積され、予測結果を人が承認し、外れた理由を学習へ戻せる運用が必要です。まずはBOM、在庫、実績、リードタイムを整えたうえで、予測の誤差率と在庫・欠品への影響を検証し、必要な品目から段階的に使います。

MRP導入でセキュリティや税務も確認すべきですか？

確認すべきです。工場設備やIoTと接続するなら、ITとOTの分離、権限、リモート接続、バックアップ、復旧、監査ログを要件に含めます。IPAは2026年4月版の制御システム向けリスク分析ガイドを公開しており、RFPのリスク分析とテスト計画に活用できます（出典：情報処理推進機構「制御システムのセキュリティリスク分析ガイド第2版」、2026年）。また、購買・検収・仕入計上と連携する場合は、電子取引データの保存や適格請求書の帳簿・書類保存について、国税庁の現行資料を確認し、監査証跡を残せる設計にします（出典：国税庁の電子取引・インボイス制度資料、2026年）。

まとめ

資材所要量計画システム（MRP）は、需要をBOMへ展開し、在庫・発注残・リードタイム・ロットを踏まえて、資材の購買や製造の提案を作る仕組みです。欠品と過剰在庫の改善に役立ちますが、効果はマスタデータの品質、現場実績の反映、例外処理、周辺システムとの連携に大きく左右されます。

導入判断で押さえる要点

導入前は、対象工場、品目数、BOM階層、生産方式、在庫精度、内示と確定受注の扱い、連携先、KPIを整理します。方式はクラウド、パッケージ、ERP内蔵、スクラッチ、ハイブリッドを比較し、初期費用だけでなく移行・教育・保守を含む5年TCOで評価します。選定時は、同じ生産形態の実績、BOMと例外処理、連携・移行、切替後の保守体制を、同じテストシナリオで比べます。

最初に取り組むこと

最初の一歩は、製品を決めることではなく、主要10〜20品目を対象に、BOM、在庫、発注残、リードタイム、納期実績を並べて、現状の計画を再現することです。そのデータで小規模PoCを行い、計算結果を購買・製造・倉庫の担当者が確認します。現場が納得できる計画ルールを作ってから、対象拠点と機能を広げることで、MRPを単なる自動計算ではなく、継続的に改善できる業務基盤へ育てられます。