今日の文書 — RFI（情報提供依頼書）
発注前の初期段階で、複数のベンダーから「市場に何があるか」の情報を集めるための文書。RFP（提案依頼書）やRFQ（見積依頼書）と違い、提案や見積りを求めるものではない。予算も要件もまだ確定していない段階で、判断材料を集めるために出す。
この文書の勝負どころ：情報収集目的が明確で、提案を求めていないか。
RFIにうっかり「ご提案をお願いします」「お見積りをお願いします」という一文を混ぜてしまうと、ベンダー側はRFPだと誤解して本気の提案書を作り始める。結果、5社から比較できない形式の提案書が返ってきて、市場調査という当初の目的が果たせなくなる。RFIはRFPの前段階であり、この段差を保つこと自体が設計の要。
RFIにうっかり「ご提案をお願いします」「お見積りをお願いします」という一文を混ぜてしまうと、ベンダー側はRFPだと誤解して本気の提案書を作り始める。結果、5社から比較できない形式の提案書が返ってきて、市場調査という当初の目的が果たせなくなる。RFIはRFPの前段階であり、この段差を保つこと自体が設計の要。
シナリオ
あなたは当社EC事業本部・販促システム部の MOpsチームメンバー（Day002・Day003の続き）。
Day003で承認された「休眠顧客リターゲティング配信システム」の本開発は10/20週にキックオフし、順調に進行中。ところが11/5（木）の週次進捗会議で、インフラ運用チームの担当者から次の提言があった。
- 現行の自社構築メール配信基盤（2018年構築）は、通常月間配信3,800万通、ピーク時（大型セール等）は1時間あたり最大60万通まで対応できる
- 本プロジェクトによる全休眠会員82,400人への展開で、月間配信数は3,980万通に増加する見込み。これ自体は現行基盤の上限（月間4,500万通、ピーク時1時間80万通）の範囲内で耐えられる
- しかし2027年度に予定されている他キャンペーン（新規会員オンボーディング強化等）と重なると、複数キャンペーン同時配信でピーク時1時間120万通に達する可能性があり、現行基盤の上限を超える
- ハードウェア増強で対応できるかは未検討。外部ESP（Email Service Provider）への切替も選択肢としてあり得るが、市場にどんなサービスがあるか、社内の誰も把握していない
高梨部長からの指示は「まず市場調査としてRFIを出し、RFPを出すかどうか・予算を確保するかどうかの判断材料を集めてほしい。まだ予算も上長承認も得ていない段階なので、ベンダーに変な期待を持たせないように」。
- 提出先（直接の読み手）： MOpsチームマネージャー・宮田さん。11/10（火）までにドラフトを見せ、11/13（金）までに確認結果を返してもらう
- その先の読み手： 確認が通れば、11/17（火）に候補ベンダー5社（NimbusMail、StreamGate、Postlyne、Valtrix Communications、Orbital CX）へ送付。回答期限は12/1（火）17:00 JST
- 面倒な事情①： 情報システム部から「データを国内で保持できるか」という要件がまだ正式に固まっておらず、RFIの質問項目に入れるべきか判断が必要
- 面倒な事情②： 5社の中には日本語サポート体制が薄い海外ベンダー（Valtrix Communications、Orbital CX）も含まれており、同じ質問をしても回答の粒度が揃わない可能性がある
- 面倒な事情③： 宮田さんは「予算も承認も得ていない段階でベンダーに連絡して、契約を急かされたり、情報が競合に漏れたりしないか」を心配している
つまり宮田さんは、このRFIをこのまま5社に送ってよいかを判断する、最後のチェックポイントである。彼が「これなら大丈夫」と言えない限り、送付は止まる。
読み手プロファイル
| 項目 | 内容 |
|---|---|
| 誰が読むか | MOpsチームマネージャー・宮田さん（1名、直接の読み手）。承認後は候補ベンダー5社の営業担当・SE担当（各社1〜2名、実質的な最終読み手） |
| 何を判断するために読むか | ①このドラフトのまま5社に送ってよいか ②社内的なリスク（予算未承認・情報漏洩）が適切に管理されているか |
| 何を知っているか | Day003プロジェクトの進行状況、インフラ運用チームの提言（数字含む）、高梨部長からの指示の趣旨 |
| 何を知らないか | RFI/RFP/RFQの厳密な違い、5社それぞれの得意分野、情報システム部のデータ在留要件の最終結論 |
| 何を気にしているか | ① ベンダーに送った瞬間、営業から「では見積りを」「では商談を」と押し込まれないか ② 予算未承認のまま社外に情報を出すこと自体が問題にならないか ③ 5社から返ってくる回答の粒度がバラバラで、比較に使えないものにならないか |
| 読む時間と場面 | 11/10（火）の午後、他の進捗確認と合わせて15分程度。赤入れして11/13までに返す |
この読み手が変わると何が変わるか：
同じRFIでも、読み手が実際にこれを受け取るベンダーの営業担当（1周目のもう一つの現実の読み手）であれば、当社の規模感・本気度・選定プロセスの透明性が最優先になる。読み手が情報システム部長（セキュリティ承認者）であれば、データ在留・アクセス権限の質問項目が本文の先頭に来る。今回は宮田さんという「送る前の最後の関門」が読み手なので、ベンダー向けの内容そのものより「これを送って社内的に問題が起きないか」への安心材料に紙面を使うのが正解。
4段階で見る — 「2. ご協力いただきたい内容」
RFIの中で最も差が出るのはここ。背景（1章）は多少雑でも読み飛ばされるが、この章の書き方一つで「RFIのつもりがRFPとして扱われる」事故が起きる。
Bad
「ご提案を」「お見積りを」
「デモ環境を」と依頼。RFPと
混同。当社の規模感の記載
なし、期限も「なるべく早め」。Good
「情報収集が目的」と明記し
数値・質問6項目・期限を提示。
だが営業/SE区別なし、予算
未承認への言及もない。Better
「本RFIの位置づけ」を新設。
提案・確約は不要と明記し、
質問を営業/SE担当別に分離。
この後RFP予定と開示。Best
選定プロセス全4段階を提示。
「お願いしないこと」「ご負担」
を節立てで先回り。比較用
シート添付で回答粒度を統一。Bad
Asks for a "proposal",
"quote", "demo env" - reads
as an RFP. No scale data,
deadline is just "promptly".Good
States "info gathering only",
gives numbers + 6 questions +
deadline. No sales/SE split,
no note on unapproved budget.Better
New "What this is/isn't"
section. No proposal/
commitment needed. Questions
split by role. RFP timing shown.Best
Full 4-step process shown.
"Not asking for" + "your
effort" sections pre-empt
concerns. Template unifies answers.Bad — 妥協して雑に作った状態 ／ 約11行
2. ご相談内容
弊社では現在、メール配信基盤の見直しを検討しております。
つきましては、貴社サービスについてご提案をいただけますでしょうか。
・貴社の配信基盤について、当社に合った構成のご提案をお願いします
・料金プランのお見積りをお願いします
・導入スケジュールと必要な体制についてもご提示ください
・可能であれば、当社専用のデモ環境をご用意いただけますと助かります
ご多忙のところ恐縮ですが、なるべく早めにご回答いただけますと
幸いです。何卒よろしくお願いいたします。Bad
2. Our Request
We are currently reviewing our email delivery platform. Could you
please provide a proposal for your service?
- Please propose a configuration suited to our needs
- Please provide pricing quotes
- Please also share an implementation timeline and team structure
- If possible, please set up a dedicated demo environment for us
We would appreciate a prompt response. Thank you for your
cooperation.英語だと粗さがより露骨に出る
"Could you please provide a proposal" は英文でもRFP文書の定型表現そのもので、RFIとしては明確な逸脱。英語圏のベンダーは "proposal" という語を見た瞬間に正式な提案プロセスとして扱い、営業パイプラインに登録する。日本語版よりもこの誤解の発生が速い。
Good — 型は満たしている ／ 約22行
2. ご協力いただきたい内容
本RFIは、貴社サービスに関する情報収集を目的としており、
提案書や見積書のご提出をお願いするものではありません。
【当社の現状】
・月間配信数: 約3,980万通（2026年11月時点、拡張後）
・ピーク時: 大型キャンペーン時、1時間あたり最大80万通を想定
・現行基盤: 自社構築（2018年稼働開始）
【お伺いしたい項目】
(1) 貴社サービスの最大配信スループット（1時間あたり）
(2) パーソナライズ配信（セグメント配信）のAPI提供の有無
(3) データの保管場所（国内保持の可否）
(4) 日本語での導入・運用サポート体制
(5) 同規模（年間配信10億通以上）の移行実績（社数・業種）
(6) 料金体系の類型（例: 配信数課金／月額固定／ハイブリッド等。
具体的な金額の提示は不要です）
【回答方法】
2026年12月1日（火）17:00までに、下記担当宛にメールでご回答
ください。ご質問がある場合もメールでお願いします。
MOpsチーム 担当: [氏名] / [メールアドレス]Badから何が変わったか 動いた軸：③事実と解釈の分離 → ④次の行動 → ⑤想定反論
- ③ 当社の現状（配信数・ピーク・現行基盤）が数値で示された。ベンダーが回答を組み立てるための最低限の材料が揃った
- ④ 回答期限（12/1 17:00）と回答方法（メール宛先）が明記された
- ⑤ 冒頭で「提案書・見積書は不要」と明記され、Badで起きていた誤解のリスクが大きく減った
まだ足りないもの
- 「情報収集が目的」という位置づけの説明が1文で終わっている。この後どうなるのか（RFPを出すのか、いつ頃か）が書かれておらず、ベンダーの営業担当は「これで終わりなのか」を読み取れない
- 6つの質問が並列に並んでいるだけで、営業担当向けと技術担当（SE）向けが区別されていない。実際に(1)(2)(5)に答えられるのはSEであり、営業担当が受け取った時点でそのまま社内転送する手間が発生する
- 予算未承認であることに触れていない。宮田さんが最も気にしている点が、この文書のどこにも表れていない
- 料金体系の質問(6)が、依然として見積りに近い印象を与えかねない
- 5社中2社（海外ベンダー）向けの配慮がなく、日本語での回答を前提にした書き方になっている
Goodの限界は「読めば分かる」が「読まないと分からない」こと。 宮田さんはこの文書を読んでも、「本当に安全に送れるのか」を自分で判断し直す作業が残っている。
Good
2. Information Requested
This RFI is intended to gather information about your service. We
are not requesting a proposal or formal quotation at this stage.
Our Current State:
- Monthly send volume: approx. 39.8M emails (as of Nov 2026, post
expansion)
- Peak throughput: up to 800K emails/hour during major campaigns
- Current platform: in-house built (launched 2018)
Questions:
(1) Maximum sending throughput per hour
(2) Availability of a segmentation/personalization API
(3) Data residency (can data be kept within Japan)
(4) Japanese-language implementation and support availability
(5) Migration case studies at comparable scale (1B+ emails/year)
(6) Pricing model type (e.g., volume-based, flat monthly, hybrid -
specific figures not required)
Response:
Please reply by email by 1 Dec 2026, 17:00 JST, to the contact below.
MOps Team, Contact: [Name] / [Email]英語版Goodでも同じ課題が残る
質問が営業向け/技術向けに区別されておらず、"not requesting a proposal" の一文だけでは、この後どうなるのか（プロセスの続き）が読み取れない。
Better — 読み手に最適化されている ／ 約31行
2. 本RFIの位置づけと、ご協力いただきたい内容
■ まず、本RFIの位置づけについて
本RFIは、当社の配信基盤の今後の方向性（自社増強／外部ESPへの
切替）を検討するための市場調査を目的としています。
・提案書・見積書・デモ環境のご提出、ご用意は不要です
・本RFIへのご回答は、貴社を選定する／しないを確約するものでは
ありません
・回答内容を踏まえて社内で検討し、2027年1月頃を目安に、必要と
判断した場合はRFP（提案依頼書）を数社にお送りする予定です
■ 当社の現状（背景）
現行の自社構築配信基盤（2018年稼働）は月間配信3,980万通・
ピーク時1時間80万通まで対応可能ですが、2027年度に複数キャンペーン
が重なった場合、ピーク時1時間120万通に達する可能性があり、
現行基盤の上限に近づくことが分かっています。
■ お伺いしたい項目（担当者別）
[営業ご担当者様へ]
(1) 貴社サービスの導入実績のうち、当社と同規模（年間配信10億通
以上）の事例数と業種（社名は不要です）
(2) 日本語での導入・運用サポート体制の有無と、対応可能な時間帯
(3) 料金体系の類型（配信数課金／月額固定／ハイブリッド等。
具体的な金額提示は不要です。类型のみで結構です）
[技術（SE）ご担当者様へ]
(4) 最大配信スループット（1時間あたり通数）。当社が想定する
ピーク（1時間120万通）に対する余裕度が分かる情報があれば
幸いです
(5) パーソナライズ配信（セグメント配信）向けAPIの提供有無と、
連携方式（REST/Webhook等）
(6) データの保管場所（国内リージョンでの保持可否）
■ 回答方法・期限
2026年12月1日（火）17:00 (JST) までに、下記へメールでご回答
ください。英語での回答も受け付けます。
MOpsチーム 担当: [氏名] / [メールアドレス]★ Goodから何が変わったか — ここが今日の学習の中心
読み手プロファイルの各項目に、変更を1対1で対応させている。
| 読み手プロファイルの項目 | Betterで行った変更 |
|---|---|
| 何を気にしているか① 「営業から商談を押し込まれないか」 | 「本RFIの位置づけ」を新設し、冒頭で「提案書・見積書・デモは不要」「選定を確約しない」の2点を明記。Goodでは1文で済ませていた宣言を、独立した節に引き上げた |
| 何を気にしているか② 「情報漏洩・社内合意が心配」 | 「回答内容を踏まえて社内で検討し、2027年1月頃RFPを送る予定」とこの後のプロセスまで開示した。プロセスが見えることで、宮田さんの不安が「今の段階として正しい手順」だと確認できる形になった |
| 何を気にしているか③ 「5社の回答がバラバラで比較できない」 | 質問を営業担当向け／SE担当向けに分離した。Goodでは6項目が並列で、誰が答えるべきか受け手側で仕分けが必要だったが、Betterでは受け取った側がそのまま社内転送しやすい形になっている |
| 何を知らないか 「情報システム部のデータ在留要件」 | (6)としてデータ保管場所の質問を残しつつ、「まだ正式要件ではない」ことを内部的には把握した上で、質問としては聞くだけに留めた |
| 海外ベンダー2社への配慮 | 「英語での回答も受け付けます」を明記。Goodでは日本語前提の書き方だった |
特に重要な1つの動き
「この後どうなるか」を開示したことが、宮田さんの心配（予算未承認のまま送る不安）への最大の回答になっている。 RFI単体を見ると「情報を求めるだけの軽い文書」に見えるが、「次にRFPが来る」という文脈が示されることで、ベンダーは身構えて過剰な提案を作り込むこともなく、当社側も「段階を踏んで進めている」ことを社内に説明しやすくなる。
まだBestではない理由：選定プロセスの見通しが「2027年1月頃」という1文で終わっており、Step単位の地図になっていない。また、ベンダーが恐れがちな「工数負担」「進まなかった場合の扱い」への先回りがまだない。
Better
2. What This RFI Is (and Isn't), and What We're Asking
WHAT THIS IS: Market research to inform our decision between
extending our in-house platform and switching to an external ESP.
- No proposal, formal quotation, or demo environment is required
- A response to this RFI does not commit us to selecting your
company, nor does it commit you to anything
- Based on responses, we plan to issue an RFP to a shortlist of
vendors around January 2027, if we decide to proceed
BACKGROUND: Our in-house platform (launched 2018) currently handles
39.8M emails/month with a peak of 800K/hour. We expect peak demand
to reach 1.2M/hour in FY2027 when multiple campaigns overlap,
approaching our current platform's ceiling.
QUESTIONS BY ROLE:
[For Sales Contacts]
(1) Number and industry of comparable-scale deployments (1B+
emails/year) - company names not required
(2) Japanese-language support availability and hours
(3) Pricing model type only (volume-based / flat / hybrid - no
figures needed)
[For Technical (SE) Contacts]
(4) Maximum throughput per hour, and how much headroom this leaves
versus our projected peak of 1.2M/hour
(5) Segmentation/personalization API availability and integration
method (REST/Webhook, etc.)
(6) Data residency options (Japan-based storage)
RESPONSE: Please reply by 1 Dec 2026, 17:00 JST, to the contact
below. Responses in English are welcome.
MOps Team, Contact: [Name] / [Email]英語版Betterで最も効いている一文
"nor does it commit you to anything"。日本語版の「選定を確約するものではありません」は当社側の免責に近いニュアンスだが、英語ではベンダー側にも義務がないことを対にして書くのが自然な型。これにより「回答すると何か縛られるのでは」という懸念にも先回りできる。
Best — 読み手が意思決定できる ／ 約34行
2. 本RFIの位置づけとお願い（選定プロセス全体の見通しつき）
■ 選定プロセスの見通し（今回はStep 1です）
Step 1 RFI（今回） 11月 5社に送付、情報収集
Step 2 社内評価 12月〜1月 回答を比較し、RFP対象を絞る
Step 3 RFP 2027年2月頃 絞った2〜3社に提案依頼
Step 4 選定・契約 2027年4月頃 最終決定
本RFIの結果、Step 3に進まない場合（現行基盤の増強で対応する
判断になる場合を含む）もあり得ます。その場合も、ご回答いただいた
内容は今後の社内検討の参考として活用させていただきます。
■ 本RFIでお願いしないこと（誤解を避けるため）
・提案書・見積書のご提出、デモ環境のご用意
・貴社の選定を確約する回答（Step 1の時点では確約できません）
・法的拘束力のある内容（NDAが必要な詳細情報は、Step 3のRFP時に
別途締結のうえお伺いします）
■ ご回答のご負担について
以下の質問は、既存の紹介資料・FAQ等の転用で構いません。貴社の
ために新規に資料を作成いただく必要はありません（工数のご負担を
最小化したいため）。
[営業ご担当者様へ] ※既存の紹介資料の転用で可
(1) 当社と同規模（年間配信10億通以上）の事例数・業種（社名不要）
(2) 日本語サポート体制の有無・対応時間帯
(3) 料金体系の類型のみ（配信数課金／月額固定等。金額は不要）
[技術（SE）ご担当者様へ] ※技術FAQ・仕様書の転用で可
(4) 最大配信スループット（1時間あたり）。当社想定ピーク
（1時間120万通）に対する余裕度が分かると助かります
(5) パーソナライズ配信APIの提供有無・連携方式
(6) データ保管場所（国内リージョン保持の可否）※現時点では
検討項目の一つであり、必須要件として確定したものではありません
■ 回答方法・期限
2026年12月1日（火）17:00 (JST) までに、下記フォーマット（添付の
比較用シート）にご記入のうえメールでご回答ください。フォーマット
外の自由記述資料を追加いただくことも可能ですが、必須ではありません。
英語での回答も受け付けます。
MOpsチーム 担当: [氏名] / [メールアドレス]Betterから何が変わったか 動いた軸：①結論の位置 → ④次の行動 → ⑤想定反論
- ①④ 選定プロセス全体（Step 1〜4）を先頭で開示し、今回がどの段階かを明示した。Betterでは「この後RFPを送る予定」の1文だったが、Bestでは日程感つきの4段階の地図として提示している
- ⑤ 「本RFIでお願いしないこと」を独立した節として立て、ベンダーが恐れがちな3点（提案要求・確約・法的拘束力）を先回りして否定した。特に「Step 1に進まない可能性もある」と正直に書いたことで、後で「RFPが来なかった」というベンダー側の不満・不信を予防している
- ⑤ 「ご回答のご負担について」を新設し、既存資料の転用で構わないと明示した。ベンダー側の「これにどれだけ工数をかけるべきか」という不安に直接答えている
- 比較用シート（添付フォーマット）を用意した。 自由記述のままでは5社の回答粒度が揃わないという、Goodの段階から残っていた懸念に、ここで初めて手を打っている
- データ在留の質問(6)に「必須要件として確定したものではない」と明示した。 情報システム部の要件が固まっていない事実を隠さず、かつベンダーに誤った確定情報を伝えるリスクも避けている
今回はBestまで作るべきか：Best必要。
理由は2つ。① 5社への同時送付であり、回答形式がバラバラだと比較という当初の目的そのものが果たせなくなる（後戻りコストが高い） ② 宮田さんの最大の懸念（予算未承認のまま社外に出すリスク）は、選定プロセス全体を開示し「確約しない」ことを明文化しない限り解消しない。
── 逆に、今後Step 3のRFPを実際に出す段になれば、RFI以上に厳密な要件定義とNDA締結が必要になり、この文書のフォーマットのままでは不十分。RFIはあくまで「軽く・広く・比較可能に」情報を集める段階に特化した完成形であり、Best化のコストをここで使いすぎず、次のRFPに手間を残す判断も同時に必要。
理由は2つ。① 5社への同時送付であり、回答形式がバラバラだと比較という当初の目的そのものが果たせなくなる（後戻りコストが高い） ② 宮田さんの最大の懸念（予算未承認のまま社外に出すリスク）は、選定プロセス全体を開示し「確約しない」ことを明文化しない限り解消しない。
── 逆に、今後Step 3のRFPを実際に出す段になれば、RFI以上に厳密な要件定義とNDA締結が必要になり、この文書のフォーマットのままでは不十分。RFIはあくまで「軽く・広く・比較可能に」情報を集める段階に特化した完成形であり、Best化のコストをここで使いすぎず、次のRFPに手間を残す判断も同時に必要。
Best
2. Where This Fits, and What We're Asking (Low-Effort by Design)
SELECTION PROCESS OVERVIEW (this is Step 1):
Step 1 RFI (now) Nov 2026 Sent to 5 vendors
Step 2 Internal review Dec-Jan Compare responses, shortlist
Step 3 RFP ~Feb 2027 Sent to 2-3 shortlisted vendors
Step 4 Selection/contract ~Apr 2027 Final decision
We may also conclude at Step 1 that extending our in-house platform
is sufficient, in which case we will not proceed to Step 3. Your
response will still inform our internal decision either way.
WHAT WE ARE NOT ASKING FOR:
- A proposal, formal quotation, or demo environment
- A binding commitment on your part or ours
- Legally sensitive details (those requiring an NDA will be
requested separately at the RFP stage, Step 3)
ON YOUR EFFORT: Existing sales collateral, FAQs, or spec sheets are
a fine basis for your answers below. We are not expecting anything
built specifically for us at this stage.
[For Sales Contacts - existing collateral is fine]
(1) Number and industry of comparable-scale deployments (1B+
emails/year) - company names not required
(2) Japanese-language support availability and hours
(3) Pricing model type only (no figures needed)
[For Technical (SE) Contacts - existing spec sheets/FAQs are fine]
(4) Maximum throughput per hour, and headroom versus our projected
peak of 1.2M/hour
(5) Segmentation/personalization API and integration method
(6) Data residency options (Japan-based storage) - this is one item
under internal review, not yet a confirmed requirement
RESPONSE: Please use the attached comparison template and reply by
1 Dec 2026, 17:00 JST. Additional free-form material is welcome but
not required. Responses in English are welcome.
MOps Team, Contact: [Name] / [Email]英語版Bestで特徴的な見出し
"(Low-Effort by Design)"。英文の商習慣では、依頼の負荷を先に自己申告することが、回答率を上げる実務的なテクニックとして定着している。日本語版の「ご回答のご負担について」よりも、英語版は見出しの時点でその意図を前面に出す。
日英差分ノート
1. 「確約しない」の対象が日英で非対称になりがち
日本語版では「本RFIへのご回答は、貴社を選定する／しないを確約するものではありません」と、当社側の免責として書いた。英語版Betterでは同じ内容に "nor does it commit you to anything" を加え、ベンダー側にも義務がないことを対で書いている。 日本語の商習慣では「回答いただいても選ばれないことがあります」まで書くと過度に事務的・冷たく響くことがあるが、英語では双方向の免責を書かないと、片方だけが得をする取引に見える。
2. 回答負荷への言及の直接さ
日本語版は「既存の紹介資料・FAQ等の転用で構いません」という配慮を、質問項目の直前に控えめに添える形にした。英語版Bestでは見出しレベルで (Low-Effort by Design) と掲げている。英文の実務では、依頼する側が相手の工数を気にしていることを明示的にアピールすることが、暗黙の配慮より効果的だと期待されている。
3. 選定プロセスの開示密度
日本語では「2027年1月頃を目安に」という幅を持たせた表現が違和感なく機能する。英語版では同じ内容を "Step 1 (now) / Step 2 (Dec-Jan) / Step 3 (~Feb 2027)" という表形式で提示しており、幅のある予定でも、区切り（Step）を明示することで曖昧さを相殺する構成になっている。日本語の文章表現をそのまま英訳すると、Stepという区切りの明快さが失われる。
頻出表現
| 日本語 | English | トーンの強さ・使う場面 |
|---|---|---|
| 情報提供依頼書（RFI） | Request for Information (RFI) | 中立。冒頭で必ず正式名称と略称を出す |
| 提案依頼書（RFP） | Request for Proposal (RFP) | 中立。RFIとの違いを本文中で必ず一度明示する |
| 見積依頼書（RFQ） | Request for Quotation (RFQ) | 中立。価格そのものを求める段階であることを示す語 |
| 提案・見積りは不要です | We are not requesting a proposal or quotation at this stage | 中立〜強い。RFI文書の冒頭に必須の宣言 |
| 選定を確約するものではありません | This does not commit us to selecting your company | 中立。英語では相手側の無義務も対で書く |
| なるべく早めに（使わない） | by [date], [time] [timezone]（具体的な日時） | 弱い→強い。英文では期限の曖昧な表現は機能しない |
| ご負担を最小化したい | We aim to minimize the effort required on your part | 中立。回答率を上げる実務的な配慮の表現 |
| 具体的な金額の提示は不要です | No specific figures are required | 中立。RFP/RFQとの境界線を保つための定型 |
| 秘密保持契約（NDA） | Non-Disclosure Agreement (NDA) | 中立〜強い。詳細情報を求める段階（RFP以降）で必要になることを先に示す |
差分5軸まとめ
| 軸 | 🔴 Bad | 🟡 Good | 🟢 Better | 🔵 Best |
|---|---|---|---|---|
| ① 結論の位置 | 「ご提案をいただけますでしょうか」という依頼から始まり、RFIの位置づけそのものがない | 「情報収集が目的」の1文はあるが、その後どうなるかは書かれていない | 「本RFIの位置づけ」を独立節にし、冒頭で明示 | 選定プロセス全体（Step 1〜4）を地図として冒頭に提示 |
| ② 読み手適合 | 誰が読んでも同じ。営業・SEの区別なし | 質問は具体的になったが、営業向け・SE向けの区別がない | 質問を営業担当向け／SE担当向けに分離 | 分離に加え、既存資料の転用可否まで担当者ごとに明示 |
| ③ 事実と解釈の分離 | 当社の規模感の記載が一切なく、事実そのものがない | 配信数・ピークの数値を提示（事実は明確） | 数値に加え、「上限に近づく」という解釈（なぜ聞くか）を明示 | データ在留要件について「確定ではない」という不確実性まで明示 |
| ④ 次の行動 | 「なるべく早めに」で期限不明 | 回答期限・宛先を明記 | 回答方法に加え、この後RFPが来る見込み時期を明示 | 比較用シート（フォーマット）を用意し、Step 2以降の日程まで確定 |
| ⑤ 想定反論 | 無視（本気度・確約への疑念、社内リスクへの懸念のいずれにも触れない） | 「提案・見積りは不要」と軽く触れる程度 | 「選定を確約しない」を明記し、営業担当の疑念に先回り | 「お願いしないこと」「ご回答のご負担」を節として立て、ベンダーの3つの懸念（提案要求・確約・工数）すべてに先回りして回答 |
| 分量（参考） | 約11行 | 約22行 | 約31行 | 約34行 ← 最長 |
分量の行に注目。 今回はBad→Bestにかけて分量が単調に増えている回。Bestが最も長い理由は、情報収集の目的を守るために「お願いしないこと」「ご回答のご負担」「比較用シート」というベンダー側の懸念を解消するための説明を追加したため。これは詳細を積んだのではなく、5社から比較可能な回答を得るという当初の目的を守るために必要な説明である。「Bestは常に最短」ではないことを示す回として記録する。
Best版・全文
ここまでは「2. ご協力いただきたい内容」の抜粋だけを比べてきた。以下は Best 水準のRFIとしての全文。そのまま5社へ送付できる完成形。
日本語版 全文を見る
RFI（情報提供依頼書）: メール配信基盤に関する情報収集
作成: EC事業本部 販促システム部 MOpsチーム
日付: 2026年11月17日
社内レビュー: 宮田（MOpsチームマネージャー）― 11/13 確認済み
承認: 高梨部長（EC事業本部 販促システム部長）
送付先: NimbusMail様 / StreamGate様 / Postlyne様 /
Valtrix Communications様 / Orbital CX様
■ 1. 背景
当社は自社ECの販促システムの一環として、休眠顧客向けリターゲティング
配信を含むメール配信基盤を運用しています。現行の自社構築基盤
（2018年稼働開始）は、通常月間配信3,980万通、ピーク時（大型
キャンペーン時）は1時間あたり最大80万通まで対応可能です。
2027年度に複数キャンペーンが重なる場合、ピーク時1時間あたり
120万通に達する可能性があると社内で見込んでおり、現行基盤の
今後の方向性（自社増強／外部ESPへの切替）を検討するため、市場に
どのようなサービスがあるかの情報を収集したいと考えています。
■ 2. 本RFIの位置づけとお願い（選定プロセス全体の見通しつき）
【選定プロセスの見通し（今回はStep 1です）】
Step 1 RFI（今回） 2026年11月 5社に送付、情報収集
Step 2 社内評価 12月〜1月 回答を比較し、RFP対象を絞る
Step 3 RFP 2027年2月頃 絞った2〜3社に提案依頼
Step 4 選定・契約 2027年4月頃 最終決定
本RFIの結果、Step 3に進まない場合（現行基盤の増強で対応する判断
になる場合を含む）もあり得ます。その場合も、ご回答いただいた内容
は今後の社内検討の参考として活用させていただきます。
【本RFIでお願いしないこと（誤解を避けるため）】
・提案書・見積書のご提出、デモ環境のご用意
・貴社の選定を確約する回答（Step 1の時点では確約できません）
・法的拘束力のある内容（NDAが必要な詳細情報は、Step 3のRFP時に
別途締結のうえお伺いします）
【ご回答のご負担について】
以下の質問は、既存の紹介資料・FAQ等の転用で構いません。貴社の
ために新規に資料を作成いただく必要はありません。
■ 3. お伺いしたい項目（担当者別）
[営業ご担当者様へ] ※既存の紹介資料の転用で可
(1) 当社と同規模（年間配信10億通以上）の事例数・業種（社名不要）
(2) 日本語サポート体制の有無・対応時間帯
(3) 料金体系の類型のみ（配信数課金／月額固定等。金額は不要）
[技術（SE）ご担当者様へ] ※技術FAQ・仕様書の転用で可
(4) 最大配信スループット（1時間あたり）。当社想定ピーク（1時間
120万通）に対する余裕度が分かると助かります
(5) パーソナライズ配信（セグメント配信）向けAPIの提供有無・
連携方式（REST/Webhook等）
(6) データ保管場所（国内リージョン保持の可否）※現時点では検討
項目の一つであり、必須要件として確定したものではありません
■ 4. 回答方法・期限
2026年12月1日（火）17:00 (JST) までに、添付の比較用シートに
ご記入のうえ、下記宛にメールでご回答ください。フォーマット外の
自由記述資料を追加いただくことも可能ですが、必須ではありません。
英語での回答も受け付けます。
MOpsチーム 担当: [氏名] / [メールアドレス]
■ 5. お問い合わせ
本RFIの内容についてご質問がある場合も、上記の宛先までメールで
ご連絡ください。個別のお電話・訪問でのヒアリングは、本RFIの
段階では対応いたしかねますので、あらかじめご了承ください。
（添付: 比較用回答シート）English 全文を見る
Request for Information (RFI): Email Delivery Platform
Prepared by: MOps Team, Promotion Systems Dept., EC Business Unit
Date: 17 November 2026
Internal review: Miyata (MOps Team Manager) - confirmed Nov 13
Approved by: Director Takanashi (Head of Promotion Systems)
Sent to: NimbusMail / StreamGate / Postlyne /
Valtrix Communications / Orbital CX
1. BACKGROUND
As part of our EC promotions platform, we operate an email delivery
system that includes retargeting campaigns to dormant customers. Our
current in-house platform (launched 2018) handles approximately 39.8M
emails/month, with a peak of up to 800K emails/hour during major
campaigns.
We project that overlapping campaigns in FY2027 could push peak
demand to 1.2M emails/hour. To inform our decision on whether to
extend our in-house platform or move to an external Email Service
Provider (ESP), we are gathering information on what is available in
the market.
2. WHERE THIS FITS, AND WHAT WE'RE ASKING (LOW-EFFORT BY DESIGN)
SELECTION PROCESS OVERVIEW (this is Step 1):
Step 1 RFI (now) Nov 2026 Sent to 5 vendors
Step 2 Internal review Dec-Jan Compare responses, shortlist
Step 3 RFP ~Feb 2027 Sent to 2-3 shortlisted vendors
Step 4 Selection/contract ~Apr 2027 Final decision
We may also conclude at Step 1 that extending our in-house platform
is sufficient, in which case we will not proceed to Step 3. Your
response will still inform our internal decision either way.
WHAT WE ARE NOT ASKING FOR:
- A proposal, formal quotation, or demo environment
- A binding commitment on your part or ours
- Legally sensitive details (those requiring an NDA will be
requested separately at the RFP stage, Step 3)
ON YOUR EFFORT: Existing sales collateral, FAQs, or spec sheets are
a fine basis for your answers below. We are not expecting anything
built specifically for us at this stage.
3. QUESTIONS BY ROLE
[For Sales Contacts - existing collateral is fine]
(1) Number and industry of comparable-scale deployments (1B+
emails/year) - company names not required
(2) Japanese-language support availability and hours
(3) Pricing model type only (volume-based / flat monthly / hybrid -
no figures needed)
[For Technical (SE) Contacts - existing spec sheets/FAQs are fine]
(4) Maximum throughput per hour, and how much headroom this leaves
versus our projected peak of 1.2M/hour
(5) Segmentation/personalization API availability and integration
method (REST/Webhook, etc.)
(6) Data residency options (Japan-based storage) - this is one item
under internal review, not yet a confirmed requirement
4. HOW AND WHEN TO RESPOND
Please use the attached comparison template and reply by 1 December
2026, 17:00 JST, to the contact below. Additional free-form material
is welcome but not required. Responses in English are welcome.
MOps Team, Contact: [Name] / [Email]
5. QUESTIONS ABOUT THIS RFI
Please direct any questions about this RFI to the contact above by
email. We are not able to accommodate individual calls or in-person
briefings at this stage.
(Attached: comparison response template)完成の定義チェックリスト
RFIを送付する前に必ず確認する。「雑・妥協」を防ぐための外部基準。1つでも未チェックがあれば、まだ出さない。
進捗 0 / 8
今日の演習
15分版 — まずこれだけでもやる
Bad例の4つの依頼（「ご提案をいただけますでしょうか」「お見積りをお願いします」「導入スケジュールと体制のご提示」「デモ環境のご用意」）を、情報収集のみを求める設問に書き直す。
条件はこれだけ：
- 「提案」「見積り」「デモ」という言葉を使わない
- 代わりに、当社が判断材料として知りたい事実の質問に変換する
- 質問には、なぜそれを聞くのか（当社側の背景）を1つ以上添える
全部で4〜6行になれば十分。本文中のGoodの「お伺いしたい項目」を見ずに自分で書いてから見比べる。
60分版
同じRFIの「2.」を、読み手を「営業担当者ではなく、実際に質問(4)(5)(6)に回答する技術担当者（SE）」に変えて書き直す。
守る条件：
- 営業担当者向けの説明（選定プロセスの見通し、料金体系の類型）はそのまま残しつつ、SEが実際に回答作業をする前提で、なぜその質問をするのか（当社の技術的な懸念）をSE向けに具体的に補足する
- SEが自社のどの資料（仕様書・アーキテクチャ図等）を見れば回答できるかのヒントを加える
- SE担当者が「なぜここまで詳しく聞かれるのか」を訝しまないよう、当社側の技術的な事情（複数キャンペーン同時配信でのピーク見積り等）を、営業向けの版より一段詳しく開示する
- 分量はBestの技術担当者向けセクションと同程度（10〜15行）
取り組む前のヒント
考える順序
- 営業担当者が知りたいこと（商談化の可能性、当社の本気度、料金レンジ）と、SEが知りたいこと（技術的な実現可能性の判断材料になるかどうか）が違うことを、まず自分の言葉で書き出す
- SEにとって「なぜこの質問に答える価値があるのか」を1つ以上示す。技術的な好奇心や商談化の見込みだけでは、SEは優先順位を上げにくい
- SEが実際に社内で資料を探すときの手間を減らすヒントを加える（例：「一般的な導入資料のアーキテクチャ図があれば十分です」等）
陥りやすい罠
- 営業向けの文面をそのまま流用してしまう。営業担当者が気にする「選定プロセス」「確約しない」という情報は、SEにとっては前提としては重要だが、SE自身が動くための情報（技術的な背景・スループットの根拠）が別に必要
- 技術的な詳細を聞きすぎてしまう。RFI段階では、SEに提案書レベルの検証（実機検証・PoC等）まで求めるのは過剰。「既存資料で答えられる範囲」という制約を守る
チェックすべき観点
書き上げたら、「SEがこれを読んで、社内の誰にも聞かずに、既存資料を探すだけで(4)(5)(6)に答えられるか」を判定する。答えられないなら、まだ営業担当者向けの粒度で止まっている。
実務での使いどころ
RFIは調達プロセスの最初の入口に位置する文書。前後の文書との関係を押さえると、RFIにどこまで書くべきかの判断がつく。
| 関係 | 文書 | このRFIとの関係 |
|---|---|---|
| 前 | 技術選定比較資料（IT-要求・設計#10） | 「なぜ外部ESPを検討するのか」の技術的な背景が、RFIの1章（背景）の材料になることがある |
| 同時 | プロジェクト完了報告書・週次報告（PMO#6/#8） | インフラ運用チームの提言はもともと週次進捗報告の1項目だった。そこからRFIという別の文書に切り出すタイミングの判断が実務上重要 |
| 後 | RFP（調達#2） | RFIの回答を踏まえ、Step 3で絞った2〜3社に送る。RFIで「聞くだけ」にしていた要件（データ在留等）が、RFPでは確定要件として書かれることになる |
| 後 | RFQ（調達#3） | RFP後、提案内容が固まった段階で、初めて具体的な見積り（金額）を求める文書。RFIで「金額は不要です」と明示していた分を、ここで初めて求める |
| 後 | ベンダー評価表 / 選定報告書（調達#5） | RFIの回答を評価軸の材料にする場合、比較用シートの回答項目が、そのまま評価表の列になることが多い |
現場での実感として一番大きいのは、RFIとRFPの境界を保つこと自体が、後の工程を楽にする。 RFIで提案や見積りまで求めてしまうと、ベンダー側の期待値が先走り、後でRFPを出す段になって「もう提案しましたよね」という食い違いが起きる。RFIを情報収集だけに絞ることが、結果的にRFP以降のプロセスの信頼性を守る。
何が起きているか