倉庫自動化RFP作成完全ガイド｜提案依頼書の作り方と実務テンプレート

この記事の要点

倉庫自動化のRFPで重要なのは、すべての情報を最初から完璧に書き切ることではありません。
重要なのは、ベンダー各社が同じ前提・同じ粒度で提案できるように、目的、対象範囲、業務要件、性能要件、制約条件、評価基準を整理することです。

良いRFPとは、複数のベンダーから同じ前提と粒度の提案を引き出し、各社の提案を横並びで比較しやすくするための提案依頼書です。

倉庫自動化では、ASRS、AMR、コンベヤ、ソーターなど、選択肢によって対象工程・設備構成・システム連携・導入効果が大きく異なります。そのため、RFPでは「何を対象にするか」だけでなく、「何を対象外にするか」「どの条件で提案してほしいか」「どの評価軸で比較するか」まで明確にしておくことが重要です。

一方で、RFP作成時点ですべての情報を社内だけで確定できるとは限りません。不明な項目は「要確認」や「ベンダーに提案してほしいこと」として整理し、現場説明会・質疑応答・ベンダーとの対話を通じて精度を高めていく進め方も有効です。

本記事では、倉庫自動化RFPの作り方を、良いRFPと悪いRFPの違い、よくある失敗、基本構成、各章の記載ポイントに分けて解説します。記事後半では、実際にRFP作成に使えるテンプレートも紹介します。

はじめに

「RFP（Request for Proposal／提案依頼書）を作ることになったが、何をどこまで書けばいいのかわからない」
「現場の業務を完全に把握できておらず、この内容で合っているのか自信がない」
「参考にできる型やフレームワークがなく、ゼロから考えるしかない」
倉庫自動化の検討において、こうした悩みは非常によく聞かれます。
さらに検討が進むと、

• ベンダーごとに提案の前提や粒度が異なり、比較が難しい
• 各社が提案の中でフォーカスしているポイントにばらつきがあり、選定しにくい
• 自社にとって何が最適なのか判断しきれない

といった課題にも直面します。
倉庫自動化は、数千万円から数億円規模の投資になるケースも多く、RFPの内容次第でベンダーから出てくる提案の質が大きく変わります。提案の前提や粒度が揃うかどうかはRFPに依存するため、その結果として、意思決定の精度や投資の成果にも影響します。
本記事では、倉庫自動化におけるRFP作成について、単なる「書き方」だけでなく、現場と全社の両方の視点を踏まえた「実務で使えるフレームワーク」として解説します。

良いRFPとは何か

良いRFPとは、複数のベンダーから同じ前提と粒度の提案を引き出せるRFPです。
前提や粒度が揃った提案を引き出すことで、各社の提案内容を横並びで比較しやすくなります。
倉庫自動化や物流ロボットの比較検討では、「製品によってカバーする工程や機能が違う」「提案の前提が異なるため、価格や性能を単純比較できない」と感じることが少なくありません。
良いRFPとは、この比較しにくさを減らすための前提づくりです。
多くのケースでは、次のような状態が見られます。

• 会社として何を実現したいのかが明確でない
• 倉庫全体の業務プロセスや今回の提案対象範囲が曖昧
• 対象とする商品の特性や在庫区分が整理されていない
• 何を基準に提案を評価するのかが決まっていない

これらに共通しているのは、必要最低限の前提条件を整理しないままRFPを作成していることです。
倉庫自動化の投資対効果は、省人化だけでなく、出荷能力向上、保管効率、品質改善、サービスレベル向上、将来の物量増加への対応などにも表れます。

そのため、RFPの背景・目的では、「何人削減できるか」だけでなく、事業成長や利益構造にどう貢献する投資なのかを整理しておくことが重要です。

RFP作成が難しい本当の理由

RFP作成が難しい理由は、単にフォーマットを知らないからではありません。
本質的には、次の構造を整理し、社内で合意する必要があるからです。

1. 会社として何を実現したいのか
2. そのために現場で何を実現すべきか
3. それを実現するために、自動化に何を求めるか

この3つがつながっていないと、RFPは機能しません。
例えば、「人手不足を解消したい」という課題だけでは、ベンダーは必要な処理能力、対象工程、保管能力、システム連携範囲を判断できません。
一方で、「3年後の売上成長に対応するため、対象拠点では出荷件数を現状の5,000件／日から8,000件／日に引き上げる必要がある。そのために、ピッキングと保管能力を中心に自動化提案を求めたい」と整理されていれば、ベンダーは具体的な設計に入りやすくなります。

倉庫自動化RFPでよくある4つの失敗

倉庫自動化RFPの失敗は、個別の書き方ではなく、構造に起因することが多くあります。ここでは、よくある失敗を4つに整理します。 

1. 課題だけを並べてしまう

よくある記載例は、以下のようなものです。

• 人手不足を解消したい
• 作業効率を上げたい
• ミスを減らしたい

これらは課題としては正しいものの、この情報だけではベンダーは設計できません。
必要な処理能力、対象工程、対象商品、制約条件が分からないため、各社の提案前提がばらつきやすくなります。

2. ソリューションありきで書いてしまう

 例えば、以下のような書き方です。

• ASRSを導入したい
• AMRを使いたい
• 自社で生産性を上げやすい自動倉庫を提案してほしい

自動化設備やロボットの種類を先に決めてしまうと、本来解決すべき課題や対象範囲とズレる可能性があります。また、倉庫全体の流れを見ずに一部工程だけを自動化すると、別の工程にボトルネックが移ることもあるため、導入したいマテハンという「手段」から入るのではなく、達成すべき「目的」と提案のアウトフレームとなる「制約条件」を明示し、各社からより良い提案を引き出すことが重要です。

3. 対象範囲が曖昧なまま依頼してしまう

例えば、以下のような書き方です。

• ピッキング周辺を改善したい
• 出荷工程を自動化したい
• 倉庫全体を効率化したい

この場合、どこまでが提案対象で、どこからが対象外なのかが分かりません。
対象範囲が曖昧だと、見積範囲、設備範囲、システム連携範囲が揃わず、価格比較も性能比較も難しくなります。

4. 評価基準が決まっていない

以下のような依頼の仕方も注意が必要です。

• できるだけ安価で提案をください
• ROIが良い案を選びたい
• 最も効果が高い案を提案してください

ROIの懸念もあるかも知れませんが、安価なものであっても必要な導入効果が得られなければ、そもそもの投資を行う意義が薄れてしまいます。価格、処理能力、保管能力、拡張性、導入リスク、システム連携、保守体制のどれを重視するのかを整理しておく必要があります。
また、ROIを省人化効果だけで見ると、出荷能力向上、保管効率、品質改善、ピーク対応、将来拡張性などの効果を見落とす可能性があります。

良いRFPに共通する3つの要素

実務で機能するRFPには、以下の3つが不可欠です。

1. 要件分解

業務、機能、性能を具体的に分解し、ベンダーが設計できる状態にします。
例えば「ピッキングを効率化したい」だけでは不十分です。
ピッキング方式、対象商品、処理行数、出荷締切、検品方法、補充ルール、次工程への引き渡し条件などを整理することで、ベンダーは具体的な提案を作成しやすくなります。

2. 制約条件の明示

倉庫自動化では、理想的な解よりも、制約条件の中で実現可能な解が重要になります。例えば、以下のような制約です。

• 天井高や梁下高
• 床耐荷重
• 柱や防火区画
• 既存ラックや既存設備
• 既存WMSや基幹システム
• 予算
• 工事可能期間
• 稼働開始希望時期
• 社内規定や安全要件

こうした条件が曖昧なままだと、性能は高くても導入できない提案になる可能性があります。 

3. 評価基準の定義

何をもって良い提案とするのかを、RFP作成時点で整理しておきます。
評価基準がないと、価格が安い提案、性能が高い提案、拡張性に優れた提案、導入しやすい提案を横並びで比較できません。評価項目としては、以下が考えられます。

• ROI・投資回収
• 処理能力・保管能力
• ピーク対応力
• 導入実現性
• 既存設備・既存システムとの適合性
• 拡張性・柔軟性
• 保守・サポート体制
• 導入スケジュール
• リスク・前提条件の明確さ

倉庫自動化RFPの完全構成（10章） 

倉庫自動化RFPは、以下の10章で構成すると整理しやすくなります。

1. 背景・目的
2. 現状業務・課題
3. 対象スコープ
4. 業務要件
5. 機能・システム要件
6. 性能要件
7. 制約条件
8. 提案依頼内容
9. 評価基準
10. スケジュール

実務上は、これらをさらに以下の3ブロックに分けて考えると分かりやすくなります。

ブロック	対象章	目的
前提整理	1～3	なぜ、何を対象にするのかを整理する
要件設計	4～7	どのような業務・性能・制約で提案してほしいかを整理する
評価・選定	8～10	何を提出してもらい、どう比較・評価するかを整理する

なお、ROI前提は独立して考えるより、評価基準の中で「どの導入効果をどう評価するか」とセットで整理すると、実務上扱いやすくなります。
また、ここで紹介する項目をすべて最初から完璧に埋める必要はありません。
重要なのは、分かっていること、社内で確認すべきこと、ベンダーに提案してほしいことを切り分けることです。

各章におけるポイント解説

1. 背景・目的

背景・目的では、投資背景、事業課題、実現したい状態を整理します。
具体例としては、以下があります。

• 出荷能力を現状比130%に向上させる
• SKU拡大に対応できる物流体制を構築する
• 人員依存リスクを低減する
• 売上成長に対応できる出荷能力を確保する
• サービスレベルを維持・向上させる

ここで重要なのは、現場改善だけでなく、事業インパクトで語ることです。
「人手不足だから自動化したい」だけではなく、「事業成長に必要な出荷能力を確保する」「採用難でも安定稼働できる物流基盤を構築する」といった上位目的と接続して記載します。
提案の見るべきポイントは、この投資が売上、利益、サービスレベルにどう貢献するかです。

2. 現状業務・課題

現状業務・課題では、業務フロー、処理能力、ボトルネックを整理します。
具体例としては、以下があります。

• 入荷から出荷までの業務フロー
• ピッキング：80行／時
• 誤ピック率：0.5%
• 繁忙期に出荷締切前で処理が詰まる
• 補充遅れによりピッキング停止が発生する

課題だけを並べるのではなく、業務の流れとセットで整理することが重要です。
BtoBとBtoC、店舗向けとEC向け、ケース出荷とピース出荷などで業務フローが異なる場合は、分けて記載します。
提案の見るべきポイントは、ボトルネックが本当にそこにあるのか、工程内と工程間の両方で確認できているかです。

3. 対象スコープ

対象スコープでは、今回のRFPで対象とする工程、商品、出荷形態、拠点、システム範囲を整理します。
具体例としては、以下があります。

• 対象工程：ピッキング、仕分け、梱包
• 対象商品：常温品、ピース品、高頻度品
• 対象在庫：アクティブ在庫
• 対象出荷：EC出荷、BtoC出荷
• 対象拠点：既存倉庫の1階エリア
• 対象システム：WMS、WCS、ERP

ここで重要なのは、対象に含めるものだけでなく、対象外とするものも明確にすることです。
対象外が曖昧だと、ベンダーごとに見積範囲や提案範囲がズレます。
提案の見るべきポイントは、今回の対象範囲が、事業目標と現場課題を解決するうえで十分かどうかです。

4. 業務要件

業務要件では、現場で実現したい作業方式、運用ルール、目標状態を整理します。
「ピッキング効率を上げたい」というような内容ではなく、「ピッキング処理能力を現状120行／時から250行／時へ改善し、繁忙期でも16時の出荷締切を維持したい」といった定量的な数値と共に要件を設定することで、ベンダー各社もどのレベルの能力が必要なのかが解釈のブレ無く理解できます。
業務要件では、抽象的な改善要望ではなく、作業条件として書くことが重要です。
記載する観点としては、以下があります。

• ピッキング方式
• 仕分け方式
• 梱包方式
• 補充方式
• 出荷締切
• 優先出荷の有無
• 欠品時・在庫差異時の処理
• 作業完了後の次工程への引き渡し条件

提案の見るべきポイントは、この業務要件が現状課題と目標物量に対して妥当かどうかです。

5. 機能・システム要件

機能・システム要件では、自動化設備、ロボット、制御システムが、既存システムや現場運用とどのように連携すべきかを整理します。
主な項目は以下です。

• WMS連携
• API / CSV
• リアルタイム連携 / バッチ連携
• 商品マスタ・ロケーションマスタ
• 在庫管理
• 先入先出、期限管理
• エラー処理
• 権限管理
• 作業ログ・在庫履歴・トレーサビリティ
• 外部システム連携

ここで重要なのは、「どんな機能がほしいか」だけでなく、「現場業務の中でどのように使うか」を書くことです。例えば同じAPI連携でも、リアルタイム連携が必要なのか、バッチ連携で十分なのかによって、システム構成、開発工数、コストが大きく変わります。また、既存WMSや基幹システムとの連携が必要な場合は、API連携可否や既存システム側の改修要否も早めに確認しておくことが重要です。

RFP作成者だけで判断が難しい場合は、IT・システム担当者や既存WMSベンダーを説明会や質疑対応に同席させることも検討しましょう。
提案の見るべきポイントは、運用に必要なレベルで機能・システム要件を定義できているかです。

6. 性能要件

性能要件では、自動化設備やシステムに求める処理能力、保管能力、ピーク対応能力を整理します。
具体例としては、以下があります。

• ピッキング処理能力：400行／時
• 出荷件数：8,000件／日
• 対象SKU：12,000SKU
• ピーク時は平均時の1.5倍に対応
• 繁忙期でも16時の出荷締切を維持

性能要件では、平均値だけでなく、繁忙期・ピーク時の条件を必ず記載します。
平均物量だけを前提にすると、繁忙期に処理能力が不足したり、出荷締切を守れない設計になる可能性があります。
また、3年後・5年後の想定物量を書く場合は、導入方針も合わせて明記します。
初期導入時に一括で必要能力を確保するのか、事業成長に合わせて段階的に拡張するのか、あるいは両方の提案を求めるのかを整理しておくと、提案前提を揃えやすくなります。
意思決定ポイントは、性能要件が目標物量、出荷締切、ピーク条件、将来成長に対して十分かどうかです。

7. 制約条件

制約条件では、変更できない条件や、提案設計に影響する前提条件を整理します。
具体例としては、以下があります。

• 天井高
• 梁下高
• 床耐荷重
• 床面の凹凸／平坦性
• 柱・梁・壁・防火区画
• 搬入口・シャッター・バース
• 既存ラック・既存設備
• 電気容量
• ネットワーク環境
• 予算
• 工事可能期間
• 稼働開始希望時期
• 夜間・休日工事の可否
• 安全・法規・社内規定

制約条件は、ベンダーの提案を制限するためではなく、実現可能な提案に絞り込むために記載します。
建屋や既存設備の制約は、文字だけでは伝わりにくい場合があります。必要に応じて、平面図、レイアウト図、現場写真を添付し、制約となる箇所を図示すると、ベンダー側の解釈ズレを防ぎやすくなります。

提案の見るべきポイントは、提案設計に影響する制約条件が抜けていないか、また変更できる制約と変更できない制約が明確になっているかです。

8. 提案依頼内容

提案依頼内容では、ベンダーに提出してもらいたい資料、数値、前提条件を明確にします。
記載内容としては、以下があります。

• 提案概要
• レイアウト／設備構成
• 性能設計
• 運用設計
• システム連携
• 導入スケジュール
• 費用・ROI
• 保守体制
• リスク・前提条件
• 提案対象外の範囲

ここで重要なのは、「最適な提案をください」と書くのではなく、提出してほしい内容と粒度を指定することです。例えば、レイアウト図、設備構成、処理能力、必要人員数をセットで提示してもらう。WMS連携については、連携方式、対象データ、責任分界点を明記してもらう。提案上の前提条件と、顧客側で確認が必要な事項を明記してもらう。

このように提出物を指定することで、各社の提案を比較しやすくなります。
また、マテハン設備や物流ロボットでは、着手金・中間金・完了金など、複数回に分けて請求される場合もあります。見積金額だけでなく、支払いタイミング、検収条件、追加費用が発生する条件も確認しておきましょう。

提案の見るべきポイントは、各社提案を同じ形式・同じ粒度で比較できる依頼内容になっているかです。

9. 評価基準

評価基準では、ベンダーから提出された提案をどの軸で比較するかを整理します。
評価項目としては、以下があります。

• ROI・投資回収
• 処理能力・保管能力
• ピーク対応力
• 導入実現性
• 拡張性・柔軟性
• システム連携
• 保守・サポート体制
• 導入スケジュール
• リスク・前提条件の明確さ
• 価格

例えば、ROIを30%、性能要件を25%、導入実現性を15%、拡張性を15%、システム連携を10%、保守・サポートを5%といった形で配点することも考えられます。ただし、配点そのものより重要なのは、自社にとって何を重視するのかを先に決めておくことです。

また、ROIを評価する際は、省人化効果だけで判断しないことが重要です。倉庫自動化は、人員削減だけでなく、出荷能力の向上、保管効率の改善、ミス削減、ピーク対応、サービスレベル向上、将来拡張性などにも効果があります。そのためRFPでは、「ROIを出してください」と依頼するだけでなく、どの導入効果を評価対象に含めたいのかを示しておくと、各社の提案を比較しやすくなります。ROIの評価基準が社内で明確に定まっていない場合は、ベンダーに対して「どの導入効果を、どのような前提で定量化できるか」を提案してもらう形にしても構いません。

社内規定として「投資回収○年以内」などの基準がある場合は、その基準が絶対条件なのか、導入効果や投資の重要性によって例外検討が可能なのかも整理しておくとよいでしょう。

提案の見るべきポイントは、自社にとって価格、ROI、性能、拡張性、導入実現性のうち何を最も重視するのかです。

10. スケジュール

スケジュールでは、RFP配布からベンダー選定までのスケジュールと、導入・稼働・能力達成までのスケジュールを整理します。RFP・選定プロセスでは、以下を記載します。

• RFP配布日
• 質疑受付期間
• 質疑回答日
• 現場説明会・現地見学
• 提案書提出期限
• 提案プレゼン日
• ベンダー選定予定日
• 契約予定日

導入・稼働計画では、以下を記載します。

• 契約予定時期
• 詳細設計開始時期
• 製造・調達期間
• 搬入・工事期間
• システム連携テスト期間
• 試運転・教育期間
• 本稼働開始希望時期
• 安定稼働目標時期
• 目標生産性の達成期限
• 3年後・5年後の想定物量

倉庫自動化では、現場制約やシステム連携条件によって提案内容が大きく変わるため、ベンダーが現場理解や見積作成を行うための時間を確保することが重要です。

提案の見るべきポイントは、各社が同じ情報・同じ条件で提案できるスケジュールになっているか、また本稼働開始時期や能力達成時期が事業計画と整合しているかです。

RFPはすべてを埋め切る資料ではない

ここまで、倉庫自動化RFPに含めるべき項目を解説してきました。ただし、すべての項目を最初から完璧に埋める必要はありません。
重要なのは、以下を切り分けることです。

• 分かっていること
• 社内で確認すべきこと
• ベンダーに提案してほしいこと

未記入の項目がある場合でも、それが「不要」なのか、「要確認」なのか、「ベンダーに提案してほしい」のかを明確にしておけば、RFPとしての実用性は高まります。
RFPテンプレートでは、項目を以下のように分けて整理すると進めやすくなります。

区分	意味
必須項目	RFPとして最低限必要な項目。未記入の場合は、少なくとも「要確認」と明記する
推奨項目	記入できると提案精度や比較しやすさが高まる項目
可能であれば埋める項目	自社で確定しきれない場合、ベンダーに提案を求めてもよい項目

RFPは、すべてを自社だけで決め切るための資料ではありません。
むしろ、分かっていることと分かっていないことを整理し、ベンダーとの対話を通じて精度を高めていくためのたたき台として活用することが大切です。

まとめ

倉庫自動化のRFPは、単なる要件整理の資料ではありません。良いRFPとは、ベンダー各社から同じ前提・同じ粒度の提案を引き出し、横並びで比較しやすくするための資料です。
そのためには、以下を整理する必要があります。

• 会社として何を実現したいのか
• 現場で何を実現すべきなのか
• どの工程・商品・拠点を対象にするのか
• どの条件や制約の中で提案してほしいのか
• 何を提出してもらうのか
• どの評価軸で比較するのか
• 分からないことをどう確認し、どう提案してもらうのか

ただし、最初から完璧なRFPを作る必要はありません。
重要なのは、RFPを議論のスタート地点として位置づけ、社内関係者、現場メンバー、ベンダーとの対話を通じて、自社に合った提案を引き出せる状態にしていくことです。

倉庫自動化RFPテンプレートを活用する

本記事で解説した内容を、実際にRFP作成に使える形式で整理した「倉庫自動化RFPテンプレート」をご用意しています。テンプレートでは、以下を整理できます。

• 背景・目的
• 現状業務・課題
• 対象スコープ
• 業務要件
• 機能・システム要件
• 性能要件
• 制約条件
• 提案依頼内容
• 評価基準
• スケジュール
• 配布前チェックリスト

すべてを最初から埋める必要はありません。分かる範囲から記入し、要確認事項やベンダーに提案してほしい項目を整理するためのたたき台としてご活用ください。