# 買いたいリクエスト型の調達の実務ガイド｜仕組みと関係者の役割を基礎から整理する

欲しい端末が商品一覧にないとき、買い手が機種、数量、状態、希望時期を公開し、複数の売り手から提案を受ける「買いたいリクエスト」は有効です。希少機種や大口数量を探しやすい一方、条件が曖昧だと、安い単価に見えて容量が違う、数量を合計すると過大になる、自社で募集して自社で提案する、期限後の古い条件で商談が進むといった問題が起きます。

リクエストは購入契約そのものではなく、調達条件を示して供給候補を集める入口です。提案、承認、商談、契約、請求、発送、検収を別状態で管理する必要があります。本稿では、買い手、売り手、プラットフォーム、スタッフ、経理、物流・検品担当の役割と、600台調達の具体例を基礎から整理します。

商品検索と買いたいリクエストを使い分ける

既に条件へ合う在庫が掲載されているなら、商品検索から商談する方が早い場合があります。リクエストが向くのは次のような場面です。

  • •一覧にない機種・容量・地域仕様を探す
  • •数百台以上を複数社から集める
  • •将来の入荷予定を含めて提案を受ける
  • •状態や電池など独自条件を指定する
  • •複数機種を代替候補として比較する
  • •定期調達の供給候補を探す

検索で見つからなかった理由が、表記ゆれ、非公開在庫、数量単位、地域条件にあることもあります。リクエスト作成前に、型番と条件を整理します。

最初に分ける四つの状態

一つの「承認済み」へ集約せず、次を分けます。

  • •リクエスト公開：買い手が希望条件を募集している
  • •オファー提出：売り手が供給可能条件を提示した
  • •候補承認：買い手が商談へ進める提案を選んだ
  • •取引契約：対象・数量・金額・履行条件を合意した

候補承認で購入義務が生じるかは、利用規約とリクエスト条件で明確にします。複数オファーを候補承認しても、全社と契約するとは限りません。売り手側にも、提案数量がいつ在庫確保へ変わるかを示します。

リクエスト票は機種名だけで作らない

「iPhoneを600台、安く」のような募集では比較できません。調達目的と許容条件を構造化します。

製品条件

  • •メーカー、製品名、モデル番号
  • •容量、色、通信仕様、地域仕様
  • •OS・アップデート条件
  • •SIM・キャリア・ロック条件
  • •付属品、保証、修理可否

品質・安全・データ条件

  • •品質区分と基準版
  • •許容する傷・機能制限・MIX
  • •電池状態と確認方法
  • •膨張、発熱、浸水等の除外
  • •データ消去と証明単位
  • •アカウント・MDM解除

個人情報保護委員会の機器内データ消去に関する注意喚起も参照し、「初期化済み」と個体別に結果を確認できる消去証明を分けます。

数量・日程・物流条件

  • •目標数量か上限数量か
  • •最小提案数量と分割単位
  • •複数社からの調達可否
  • •希望納期・分納・有効期限
  • •出品地域、引渡し、送料
  • •受領・検収場所と期限

価格・契約条件

  • •希望単価か上限単価か
  • •税抜・税込、通貨、送料、手数料
  • •数量別単価の可否
  • •支払い時期・方法
  • •検収差・返品・減額
  • •オファーと承認の拘束範囲

数量は「欲しい数」と「超えてはいけない数」を分ける

買い手が600台を目標にしていて、良い条件なら700台調達したい場合があります。逆に保管・予算上600台を超えられない場合もあります。

次を分けます。

  • •target_quantity：目標数量
  • •maximum_quantity：承認・契約の上限
  • •offer_quantity：売り手の提案数量
  • •approved_quantity：商談候補として承認した数量
  • •contracted_quantity：契約数量
  • •received・accepted_quantity：受領・検収数量

上限を設けない場合も、超過時に追加確認する閾値を決めます。複数オファーを同時承認すると、各画面が古い合計を見て上限を超えるため、承認合計と更新を同じ処理で行います。

目標超過を許す業務では、システムが勝手に拒否せず、買い手権限者へ「目標600台に対し承認予定700台」と差を示して明示確認させます。

希望価格の意味を一意にする

希望価格が、目標、上限、参考相場のどれかで売り手の提案行動が変わります。価格を表示しない募集も選べます。

オファーでは次を分けます。

  • •一台当たり税抜単価
  • •提案数量と段階価格
  • •品目小計
  • •送料・手数料
  • •税と端数
  • •支払総額見込み
  • •価格有効期限

金額は円なら整数、外貨なら最小単位または十進精度を固定して保存します。0円提案を通常の売買で認めず、無料譲渡・処分は別の条件へ分けます。

希望価格を超える提案を禁止するか、比較候補として受け付けるかも明示します。禁止しない場合は、超過額と理由を買い手へ表示します。

公開範囲は調達機会と情報リスクを比較する

社名、担当者、予算、在庫不足、納期を全公開すると、営業秘密や交渉力へ影響します。一方、条件を隠しすぎると売り手が提案できません。

公開情報、審査会員限定、候補承認後、契約後を分けます。

  • •一般公開：製品条件、数量帯、期限など必要最小限
  • •審査会員：詳細品質、地域、分納条件
  • •候補承認後：担当窓口、詳細検収、契約資料
  • •契約後：請求・配送・受領に必要な情報

個人名・メールを公開ページへ載せず、プラットフォーム内の組織IDで応答します。添付一覧に端末の過去利用者情報や社内資産番号を含めません。

質問回答は全提案者へ同じ情報を返す

公開後に売り手から「B以上にCを含めるか」「分納できるか」と質問が来ることがあります。回答が案件条件を補うなら、質問者だけでなく参加可能な全売り手が同じ版を確認できるようにします。個別商談で条件を変えた場合は、その売り手だけの提案条件として比較表へ明示します。

買い手担当が電話やメールで答えた内容も、価格・数量判断へ影響するなら案件Q&Aへ記録します。回答により既存オファーが不利になる場合は、提案期限を延長し、全売り手へ変更後条件を再確認する機会を与えます。

売り手オファーは在庫と将来入荷を分ける

「600台供給可能」が、現在検品済み在庫か、未入荷予定か、他案件と共有かで履行可能性が違います。

オファーに次を持たせます。

  • •available_now：現在供給可能な数量
  • •expected_quantity：将来入荷見込み
  • •available_at：供給可能予定日
  • •allocation_status：未確保、仮確保、確保済み
  • •source・location：公開範囲に応じた出荷元
  • •evidence_at：在庫確認日時

未承認オファーだけで在庫を減らすと、いたずらや放置で他取引を妨げます。契約・仮確保へ進む時点を決め、別商談と二重配分しないよう条件付き更新します。

自分のリクエストへの自己オファーを防ぐ

同じ売り手アカウントが自分で買いたいリクエストを作り、自分でオファー・承認できると、自己取引、架空実績、請求が作れます。user_idだけでなくorganization_idと案件所有者を比較します。

関連会社・代理店を許す場合は、関係性、目的、承認者を明示し、価格統計や実績へ通常取引と同じ扱いで混ぜない判断が必要です。

作成、オファー、承認、請求APIのそれぞれで認可します。画面ボタンを隠すだけでは、直接リクエストを防げません。テストは別のテスト組織を使い、本番ユーザーや売買履歴へ触れません。

オファー比較は同じ条件へ正規化する

単価だけで並べると、状態、送料、数量、納期、保証が違う提案を誤比較します。比較表には原条件と正規化条件を両方示します。

比較軸は次です。

  • •適合数量・代替品数量
  • •単価、税、送料、手数料、総額
  • •品質基準・電池・保証
  • •現在在庫・入荷見込み
  • •出荷・分納・検収日
  • •データ消去・安全・証拠
  • •最小数量・全量条件
  • •売り手の履行条件

非対応項目を0点として総合点へ隠さず、「必須不適合」として停止します。重み付き点数を使う場合は、重み、版、元値、手動変更理由を保存します。

代替機種は同等という一語で扱わない

希望機種が不足すると、売り手から後継機、容量違い、別地域仕様の提案が来ます。代替を許す場合は、必須条件と比較条件を分けます。例えばOS更新期限、対応周波数、管理機能、アプリ互換、電池、保証、単価を確認します。

代替品を元機種の数量へ自動加算せず、requested_item_idとalternative_item_idを分けます。買い手が代替200台を承認した場合も、「希望機種600台を充足」と表示するか、「希望400・代替200」と表示するかを調達目的に合わせます。

評価では、端末価格だけでなく、ケース・充電器・設定・検証・運用期間の差を含めます。型番や仕様の確認が取れない代替は、安くても必須不適合として止めます。

候補承認は数量・有効期限・競合を再確認する

買い手がオファーを開いた後、売り手が撤回、価格期限切れ、在庫減少、資格停止になる場合があります。承認時に最新状態を再確認します。

同じ処理で確認する項目は次です。

  • •リクエストがOPENで期限内
  • •オファー版がACTIVEで有効期限内
  • •売り手が現在も適格
  • •承認数量が提案範囲・単位を満たす
  • •目標・上限と既承認合計
  • •同じオファーが未処理
  • •自己取引ではない

同時承認で合計が変わった場合、自動的に数量を縮めず、最新合計と残りを買い手へ示して再確認します。

期限終了と再開は新しい版として扱う

掲載期限を過ぎたリクエストへ新規オファーを受け付けません。期限処理は、古い期限を読んだ後に担当者が延長する競合を考え、「現在もOPENで期限値が一致する」条件で終了します。

終了後に再開する場合、元リクエストを無条件にOPENへ戻さず、数量、希望価格、品質、既存オファーの有効性を確認します。既存提案を再利用するなら売り手へ再確認を求め、新しい有効期限を設定します。新規募集として複製する場合は元案件との関係を残します。

募集を重複作成すると同じ需要が二重に見えるため、同一組織・製品・期間の類似リクエストを作成時に警告します。正当な分割調達なら、地域、納期、予算、担当を明示して区別します。

商談では元リクエストと差分を管理する

候補承認後、数量、単価、納期、検収を調整することがあります。元オファーを直接上書きせず、商談版として差分を残します。

契約前の確認画面には、リクエスト条件、売り手オファー、最終合意を並べます。必須条件を緩和した場合、誰が、なぜ承認したかを示します。

担当スタッフが商談内容を編集できる場合も、契約・請求後の無条件上書きを止めます。version条件を使い、別担当が先に成約・請求した場合は競合として再確認します。

請求・支払いは確定した商談へ結ぶ

候補承認だけで請求書を作らず、契約上の数量・単価・費用・税が確定した商談版を参照します。生成時に商談状態、金額版、既存請求を同じ処理で確認します。

下書き、発行、送付、支払確認を分けます。請求書を自動生成しても、自動送信とは分離できます。再生成は経理または担当権限を確認し、旧番号・旧金額・理由を残します。

メール送信が失敗しても取引確定を再実行せず、送信待ち台帳で再試行・重複防止します。通知には確定品目・数量・金額だけを載せます。

発送・受領・検収で調達数量を確定する

契約600台、発送598台、受領597台、検収合格590台のように各数量は変わります。一つのquantityを上書きしません。

発送時に個体・箱を割り当て、受領時に箱・個体を照合します。検収差は、欠品、予定外、機種・容量、品質、データ、安全へ分類します。

経済産業省の製品安全に関する流通事業者向け資料も、製品識別・記録と流通段階の安全対応を扱っています。安全上の疑いがある端末は、減額だけで通常在庫へ移さず隔離します。

交換、追加発送、返品、減額、現状受入を合意し、対象個体、数量、金額、理由を請求調整へ結びます。

具体例：600台を三社から調達する

買い手はPhone Z・128GB・B以上を目標600台、上限700台、最低提案100台、税抜上限38,000円で募集しました。

売り手提案数量単価条件
A300台37,000円検品済み、2週間以内
B250台36,500円150台即納、100台は翌月
C300台37,800円全量300台のみ

Aを300台、Bを250台承認すると550台で、目標まで50台不足です。Cは全量条件のため50台だけ承認できません。上限700台まで許容するなら、C全量を加えると850台で上限超過です。

選択肢は、A+Bで550台を契約し追加募集する、Bの将来入荷を含めず即納450台として再募集する、Cへ条件変更を依頼する、上限を権限者が見直して再承認する、です。システムがCを自動的に150台へ縮めません。

Aの検収が298台、Bの即納が149台なら、契約550、初回発送450、受領447などを段階別に残します。調達不足と売り手別の履行差を分けます。

この案件で上限を700台から900台へ変える場合、担当者が表示数だけ書き換えてCを承認してはいけません。追加予算、保管、検収能力、既存A・B契約への影響を権限者が確認し、リクエスト新版として変更理由と承認時刻を残します。Cのオファーが旧上限を前提としていたかも確認します。

逆にAが契約前に100台を撤回した場合、承認合計を450へ戻すだけでなく、Aのオファー版、仮確保、商談、通知を同じ取消処理へ結びます。残り需要150台を再募集する際は、初回募集の期限と希望価格をそのまま使わず、現在相場と納期を再確認します。

運用チェックリスト

[販売相場を確認する](/market-search)際も、リクエスト希望価格、売り手提案、最終契約価格を分け、状態・数量・税送料・時点をそろえます。

  • •[ ] 商品検索とリクエストの使い分けを決めた
  • •[ ] 公開、オファー、候補承認、契約を分けた
  • •[ ] 製品・品質・数量・価格条件を構造化した
  • •[ ] 目標数量と上限数量を分けた
  • •[ ] 超過承認に明示確認がある
  • •[ ] 単価・税・送料・総額の意味が一意
  • •[ ] 公開情報を段階別に最小化した
  • •[ ] 現在在庫と将来入荷を分けた
  • •[ ] 未承認オファーで在庫を減らさない
  • •[ ] 自己オファーを組織単位で止める
  • •[ ] オファー比較で必須不適合を隠さない
  • •[ ] 承認時に状態・期限・合計を再確認する
  • •[ ] 商談変更を版と差分で管理する
  • •[ ] 請求を確定商談版へ結ぶ
  • •[ ] 外部通知を送信待ち台帳で処理する
  • •[ ] 発送・受領・検収数量を分ける

まとめ：買いたい条件は、契約まで変化を追える形にする

買いたいリクエストは、一覧にない端末や大口数量を複数社から探す有効な入口です。ただし、製品名だけで募集せず、品質、データ、安全、数量、日程、価格、検収を構造化します。

目標数量と上限を分け、複数承認で超過できる場合は買い手へ差を示して明示確認させます。自己オファーを組織単位で止め、現在在庫と将来入荷、未承認提案と在庫確保を区別します。

候補承認時にはリクエスト・オファーの状態、期限、資格、数量合計を同じ処理で確認します。承認後の商談は元条件との差分を残し、確定版から請求、発送、受領、検収へつなぎます。600台を三社から集める場合も、全量条件と上限を構造化すれば、安い単価だけでは見えない不足・超過を説明できます。