海外ベンダーに見積もり依頼を送る時、スコープを曖昧にすると価格が読めません。
B2B発注は「RFI→RFP→RFQ」の3段構成で、各段階で求める情報粒度が違います。段階を混同すると時間と信頼を失います。
この記事では英文RFP/RFQメールの設計と、複数ベンダー比較の倫理、Q&A期間の運用まで解説します。
B2B発注の3段階
国際調達の基本プロセスを3段階で整理します。
RFI（Request for Information）
Request for Informationは「情報要求」段階です。ベンダーの能力・実績・製品ラインを広く確認します。
この段階では価格は聞かず、「そもそも候補になるか」を判断します。
RFP（Request for Proposal）
Request for Proposalは「提案依頼」段階です。要件を提示し、ベンダーから解決策と見積もりを受け取ります。
評価基準・タイムライン・評価プロセスを事前開示して、公平な比較を可能にします。
RFQ（Request for Quote）
Request for Quoteは「見積もり依頼」段階です。仕様が固まった後に、価格・納期・条件だけを比較します。
既存製品・標準化されたサービスに対して使います。
RFIメールの型
情報要求段階のメール構造です。
会社・製品情報の依頼
件名はRequest for Information – [案件名]を使います。本文ではプロジェクト概要を3-5行で説明します。
We are exploring solutions for [課題領域] and would appreciate general information about your offerings.のような書き出しです。
広い質問で絞り込み
質問項目は5-10個に抑え、広めに設定します。実績・ケーススタディ・技術スタック・サポート体制などです。
細かい価格表や仕様書を求めると、ベンダー側の工数が大きくなり、回答率が下がります。
複数ベンダー並行
5-10社に並行送付するのが一般的です。各社の回答締切は2-3週間後に設定します。
RFI段階では受諾義務はないため、断られても問題ありません。
RFPメールの型
提案依頼段階では、より詳細な情報を送ります。
要件サマリの添付
PDFの要件書（Requirements Document）を添付します。本文は2-3段落で概要を示し、詳細は添付に誘導します。
添付には背景・目的・機能要件・非機能要件・スケジュール・評価基準を含めます。
評価基準の開示
Price、Quality、Timeline、Supportの4軸の重み付けを開示します。たとえばPrice 40%、Quality 30%、Timeline 20%、Support 10%のような配分です。
ベンダーは評価軸に合わせて提案を最適化できます。公平性も担保されます。
Q&A期間設計
提案提出の1週間前までをQ&A期間とします。質問はメールで受け付け、全ベンダーに回答を共有します。
Q&A All-Vendor Callをセットして、全ベンダー同時の質疑応答を行うケースもあります。
RFQメールの型
見積もり依頼段階の書き方です。
数量・仕様・納期の明示
Quantity: 500 units / Spec: [添付PDF参照] / Delivery: Week 42のように、3要素を冒頭で明示します。
曖昧さを残すと、ベンダーは余裕を積んで高めの見積もりを出します。
価格フォーマット指定
単価・合計・送料・税の内訳を指定フォーマットで求めます。Excelテンプレートを添付して、統一フォーマットで回答させるのが効率的です。
各社バラバラのフォーマットで返ってくると、比較作業が膨大になります。
有効期限確認
見積もり有効期限をPlease indicate the validity period of your quote (e.g., 30/60/90 days).と確認します。
長期プロジェクトでは、有効期限切れで再見積もりになるリスクを把握します。
スコープ曖昧を防ぐ記述
RFP/RFQの肝は、スコープの明確化です。
In-scope / Out-of-scope の分離
Scope: In-scope / Out-of-scopeの2列表で、何を含み何を含まないかを明示します。
たとえば「デザインは含むが、バックエンド開発は含まない」のように、境界を明確化します。
Assumptions の列挙
前提条件をAssumptionsとしてリスト化します。「クライアント側でコンテンツ提供」「1営業日以内のフィードバック」などです。
ベンダーはこれを踏まえて見積もりを出します。前提違反時の費用変動も予測可能になります。
Dependencies の明示
プロジェクトの依存関係を書きます。「Phase 2はPhase 1完了後に着手」「外部APIの承認待ち」のような情報です。
依存情報があると、ベンダーは現実的なタイムラインを提案できます。
複数ベンダー通知の倫理
国際調達の暗黙ルールがあります。
競合がいる明示
We are evaluating multiple vendors for this project.と冒頭で明示します。これで価格が競争的になります。
「独占契約を前提にしている」とベンダーを誤解させるのは、倫理的な問題です。
NDAの先送り
RFI段階ではNDAなしで情報開示してもらい、RFP段階で選定ベンダーとNDA締結の流れが一般的です。
最初から全ベンダーにNDAを要求すると、交渉コストが急増します。
ベンダー情報の守秘
あるベンダーから得た情報を、他のベンダーに共有するのは禁止です。価格情報の漏洩は訴訟に発展することもあります。
Q&Aの共有でも、質問者名は伏せて回答を展開します。
評価基準の事前開示
評価軸を透明化することで、質の高い提案が集まります。
Price / Quality / Timeline の比重
Evaluation criteria: Price 40%, Quality 30%, Timeline 20%, Cultural fit 10%のように明示します。
比重を開示しないと、ベンダーは全方位で強みをアピールしようとし、提案が散漫になります。
評価マトリクス共有
細かい評価シート（scorecard）を共有するケースもあります。「API連携への対応度 1-5点」「多言語対応 Y/N」のような項目です。
ベンダー側は、どこに注力すべきかが明確になります。
Decision Criteria の公平性
評価委員会の構成（Decision-making Committee）を開示することもあります。技術・調達・法務の3部署代表で構成するなどです。
「誰が評価するか」「誰に刺さる提案が必要か」が分かると、ベンダーは効率的に動けます。
Q&A期間の設計
提案期間中の質疑応答運用です。
全ベンダーに質問共有
あるベンダーから来た質問は、匿名化して全ベンダーに共有します。Consolidated Q&A Documentとしてまとめるのが標準です。
不公平な情報格差を防ぐための基本ルールです。
締切と回答期日
Q&A締切を提案提出の2週間前、回答期日を1週間前に設定するのが一般的です。
回答が遅れると、ベンダーの提案品質が下がります。
回答一律化
同じ質問が複数ベンダーから来たら、1つの回答を全員に共有します。回答内容はスタンダード化します。
個別にメール返信すると、情報格差が生まれます。
ベンダー選定後の通知
選定結果の通知には、配慮が必要です。
当選通知
We are pleased to inform you that you have been selected as our vendor for [project name].が標準表現です。
次のステップ（契約書ドラフト共有、キックオフMTG設定）を明示します。
落選通知の配慮
Thank you for your proposal. After careful consideration, we have decided to proceed with another vendor for this specific project.のように、敬意を持って伝えます。
決定理由を1-2点簡単に示すと、ベンダーは次回への学びになります。
将来機会への橋渡し
We would like to keep your information on file for future opportunities.を添えると、関係を残せます。
今回選ばなかったベンダーも、次回のRFPで有力候補になる可能性があります。
価格交渉の最終段
選定前の最終的な価格交渉です。
BAFO（Best and Final Offer）
Best and Final Offerは「これが最後の見積もり」を要求するプロセスです。Please submit your BAFO by 2026/04/28.と依頼します。
BAFO後の価格変更は、原則として認められません。
条件変更の交渉余地
BAFO段階で、価格以外の条件（納期短縮・サポート延長・分割払い）も交渉できます。
純粋な値引きより、条件改善のほうが両者にとってWin-Winになるケースがあります。
契約条項への移行
BAFO受諾後、契約書ドラフトに移行します。MSA・SOW・DPAの3点セットが一般的な構成です。
契約レビュー期間も、プロジェクト全体のスケジュールに組み込みます。
国際RFPの特有論点
国をまたぐ発注では、追加の検討事項があります。
通貨・税・関税
見積もりはUSD、EUR、JPYなど、通貨を明示します。税込か税抜か、関税負担の所在も事前合意します。
為替変動リスクの負担者もAssumptionsに書きます。
Liability・Warranty
責任の範囲、保証期間、瑕疵対応は、RFP段階で方針を示します。契約段階での大幅変更は、コストに跳ね返ります。
Limitation of Liabilityの上限金額も、早期に議論します。
時差を前提にした期限
期限はタイムゾーンを含めて明示します。by Oct 3, 17:00 JST (GMT+9)のような形です。
あいまいに「Friday」と書くと、相手の金曜日時刻に解釈されてズレが生じます。
RFPの失敗例とリカバリー
実務で起きやすいミスと対応です。
要件漏れによる再見積もり
要件書に漏れがあると、見積もり受領後に「追加費用」が発生します。全ベンダーに再RFPを送り直す必要があります。
要件書は社内レビューを必ず通してから送ります。
ベンダー離脱
RFP中にベンダーが辞退するケースがあります。要件が非現実的、競合ベンダーが多すぎる、などが主因です。
辞退理由をヒアリングすると、RFP改善の材料になります。
期限延長の連絡
社内事情で提案期限を延長する時は、全ベンダーに同時通知します。Due to internal scheduling changes, we are extending the deadline by 1 week.のような連絡です。
一部ベンダーのみに通知すると、不公平性が生まれます。
RFPメール例6
業種別の骨格を示します。
SaaS選定
Subject: RFP – CRM Platform for 500 users. 本文: We are evaluating CRM platforms. Requirements attached. Proposals due Oct 31. Q&A period through Oct 24.
ユーザー数・期限・質問期間の3点を冒頭で明示します。
開発委託
Subject: RFP – Web Application Development. 本文: Seeking development partner for customer portal. Scope attached. Timeline: 6 months. Budget range: $100K-$150K.
予算レンジを開示することで、ベンダーの提案精度が上がります。
翻訳・ローカライズ
Subject: RFQ – Technical Documentation Translation (EN-JA). 本文: 50,000 words, technical manual, delivery in 4 weeks. Please quote per-word rate + project management fee.
単価と総額の両方を比較できるフォーマット指定です。
コンサル契約
Subject: RFP – Strategy Consulting Engagement. 本文: 12-week engagement on market entry to Southeast Asia. Proposal should include team bios, methodology, deliverables.
提案書に含める要素を事前指定すると、比較しやすくなります。
製造委託
Subject: RFQ – OEM Manufacturing (1,000 units). 本文: Product spec attached. MOQ: 1,000 units. Delivery: 90 days from PO. Payment: Net 60.
Minimum Order Quantity、納期、支払条件を明示します。
マーケティング代理店
Subject: RFP – Digital Marketing Agency (Annual). 本文: Seeking full-service agency for SEO, SEM, content. Annual budget: $500K. Start: January.
予算・開始時期・サービス範囲で、適合ベンダーを絞り込めます。
RFP関連ドキュメントの管理
RFPプロセスは書類が大量に発生します。
バージョン管理
要件書・回答集・評価シートは、バージョン管理を徹底します。requirements_v1、requirements_v2_final、requirements_v2_final_finalのような混乱を避けるため、日付ベースの命名が推奨です。
SharePoint・Box・Google Driveで1つの真実を共有します。
回答ログ
Q&Aの回答は、全ベンダーに同じ内容を配信した履歴を残します。送信日時・受信者リスト・回答内容を一覧にします。
後日「回答を受け取っていない」というトラブルに備えた記録です。
契約までのトレーサビリティ
RFPの要件書→提案書→契約書が、整合していることを確認します。契約書レビュー時に、RFP要件との照合が必須です。
提案段階で約束した内容が契約書に反映されていないと、実行段階でトラブルになります。
RFP運用の社内体制
RFPは1人で回せる規模を超えることが多いため、社内体制の整備も重要です。
案件オーナー（調達またはPM）、技術評価者、法務レビュー担当、意思決定者の4役を最低限分離します。小規模案件でも役割を明示すると、提案の評価が速くなります。
ベンダーからの問合せ窓口は、原則1名に集約します。複数の窓口から異なる回答が出ると、ベンダーは混乱し、提案品質が落ちます。
選定後の引継ぎも重要です。調達→プロジェクトチームの引継ぎ時に、RFP経緯・ベンダー比較結果・交渉履歴を文書化しておくと、実行段階での認識齟齬を防げます。
