買いたいリクエスト型の調達の実務ガイド｜小さく始めて継続運用へ移す実践手順を示す

# 買いたいリクエスト型の調達の実務ガイド｜小さく始めて継続運用へ移す実践手順を示す

買いたいリクエスト型の調達を導入するとき、最初から複数機種、代替品、越境、定期購買まで扱う必要はありません。一方、一機種の募集でも、目標数量と上限、自己オファー、同時承認、期限、在庫確保、請求・検収を曖昧にすると、二重取引や過大調達が起きます。

安全な導入は、一拠点で同一モデル600台を集める案件を選び、公開条件、オファー、候補承認、商談、契約、請求、受領を別状態として設計することから始まります。本稿では、隔離DBと模擬通知を使い、90日で一案件を完走して継続運用へ移す手順を示します。

手順1：初回リクエストの対象と成功条件を決める

初回は、同一機種・容量、一通貨、一つの受領拠点、国内調達に絞ります。代替機種、複数通貨、越境、定期自動募集は対象外にします。

例として次を設定します。

• •Phone Z・128GB・国内仕様
• •品質B以上、指定した安全・機能条件
• •目標600台、上限700台
• •最小提案100台、100台単位
• •税抜円単価、送料は売り手別表示
• •60日以内、分納可
• •個体別消去結果と受領検収

成功条件は、三社以上から比較可能な提案を受けることだけではありません。自己提案ゼロ、上限超過の意図しない承認ゼロ、契約数量と請求・検収の一致、差異を元提案まで再現できることを含めます。

手順2：役割と責任を分ける

買い手作成者、買い手承認者、売り手提案者、担当スタッフ、経理、物流・検収、監査を定義します。

IPAのアクセス制御や認可制御の欠落に関する解説を参考に、APIでrole、organization_id、assignment、状態を確認します。URLや非表示メニューだけに頼りません。

手順3：状態機械と期限を定義する

リクエストは `DRAFT → SCHEDULED → OPEN → CLOSED → FULFILLING → COMPLETED` を基本とし、許可状態からだけ `CANCELLED` へ進めます。オファーは `DRAFT → ACTIVE → WITHDRAWN | EXPIRED | APPROVED | REJECTED` とします。

候補承認と契約成立を分けるなら、商談を `NEGOTIATING → AGREED → CONTRACTED` とします。請求、発送、受領、検収も別状態でつなぎます。

request_deadlineとoffer_valid_untilを分けます。再開・延長時に既存オファーを自動復活させず、売り手へ再確認を求めます。期限処理は、状態と現在の期限値が一致する場合だけ終了更新します。

手順4：リクエスト項目を必須・許容・代替へ分ける

自由文だけで募集せず、入力スキーマを作ります。

必須条件

• •model_identifier・容量・地域仕様
• •OS・通信・管理機能
• •データ消去・アカウント解除
• •電池・安全・必須機能
• •maximum_quantity・上限価格

許容条件

• •色、軽微な外観差
• •分納、納期幅
• •付属品の有無
• •品質区分内の構成差

代替条件

• •後継・近接モデルの可否
• •容量違いの優先順位
• •代替を承認できる役割
• •元機種と別集計する方法

個人情報保護委員会の機器内データ消去に関する注意喚起も参照し、初期化申告と個体別の消去結果を分けます。

手順5：目標・上限・承認数量を別に持つ

初回案件ではtarget_quantity=600、maximum_quantity=700とします。上限を超える変更には予算・保管権限者の承認を必要にします。

数量項目は次です。

• •target_quantity：調達目標
• •maximum_quantity：契約可能上限
• •offered_quantity：提案数量
• •approved_quantity：候補承認数量
• •reserved_quantity：売り手確保数量
• •contracted_quantity：契約数量
• •shipped・received・accepted_quantity

目標超過は警告、上限超過は停止とします。上限なしの業務でも、一定割合を超える場合は明示確認します。取消・辞退時の戻入を別イベントで残します。

手順6：公開範囲とQ&Aを版管理する

一般公開、審査会員、候補承認後、契約後で項目を分けます。会社の調達計画、担当者名、予算上限を必要なく一般公開しません。

添付資料から社員名、社内資産番号、過去利用者情報、管理画面を除きます。画像・一覧のダウンロード権限と監査を設定します。

質問回答が品質・数量・納期・価格判断へ影響する場合は、Q&A版を更新し、全提案者へ同じ情報と回答期限を与えます。重大変更では既存オファーを未確認状態にし、売り手が新版を承認または再提出します。

手順7：オファーを構造化して検証する

オファーに、offer_line単位で製品、数量、単価、税、送料、納期、現在在庫、将来入荷、品質、データ、安全、保証を持たせます。

サーバー側で次を拒否します。

• •未入力、0、負数、桁超過の単価
• •最小・単位・上限に反する数量
• •必須製品識別子の欠損
• •非対応通貨・税区分
• •リクエスト期限後・非公開状態
• •同一組織による自己オファー
• •利用停止・権限外ユーザー

同じ送信の再試行には冪等キーを使います。変更は旧版を残し、有効版を一つにします。オファー提出だけで物理在庫を減らしません。

手順8：現在在庫・将来入荷・仮確保を分ける

売り手はavailable_now、expected_quantity、available_at、confidence_basis、verified_atを入力します。仕入契約済み、出荷通知済み、回収見込みを同じ「予定」にしません。

候補承認時に仮確保するか、契約時に確保するかを案件条件で決めます。確保処理では、通常商品、入札、別リクエストの予約を含む残在庫を同じトランザクションで確認します。

競合で不足した場合、提案数量を黙って縮めず、売り手へ新版、買い手へ不足を示します。確保期限を過ぎたら自動解除する場合も、商談・通知・監査へイベントを残します。

手順9：比較表は強制ゲートの後に作る

比較前に、製品仕様、データ、安全、上限価格などの必須条件で止めます。その後、単価、総額、納期、保証、履行条件を比較します。

比較表には次を表示します。

• •原提案と正規化後の金額
• •即納・予定・代替の内訳
• •必須適合・不適合・未確認
• •品質・電池・保証の差
• •分納と最終納期
• •最小数量・全量条件
• •売り手確認日時

重み付き点数には重みと版を表示し、自動承認へ直結させません。人が順位を変えた場合、元順位、理由、承認者を保存します。

手順10：候補承認を同時実行に耐えさせる

承認時にrequestとofferを固定し、現在の有効承認合計、上限、売り手資格、オファー期限、自己取引、既存処理を再確認します。

600台案件の承認例

既承認400台、上限700台に対し、AとBが各200台を提案しています。Aの承認後は合計600台、Bを全量承認すると800台で上限超過です。二人が同時操作しても、片方がversion競合で止まるようにします。

Bを100台だけ承認できるのは、部分承認と最小数量が許す場合だけです。自動的に100台へ縮めず、買い手と売り手へ確定数量を再確認します。

確定処理ではapproved_line、商談、監査、通知待ちを同時に作り、途中失敗で中間状態を残しません。

手順11：商談・契約・請求を版でつなぐ

商談では、元リクエスト、オファー、最終合意を並べ、数量、単価、納期、検収の差分を示します。変更はnegotiation_versionとして保存します。

契約確定時に、現在version、当事者、数量、確保、価格、税費用を同じ処理で確認します。契約後の変更は直接上書きせず、変更提案、当事者再承認、請求訂正へ進めます。

請求書はcontract_lineから生成し、下書き、発行、送付、支払確認を分けます。自動生成しても外部送信は分離し、送信待ち台帳で重複を防ぎます。一部契約で元オファー全品目を通知・請求へ渡しません。

手順12：発送・受領・検収差を追う

契約数量、発送数量、受領数量、検収合格数量を別項目で持ちます。発送時に個体・箱を割り当て、受領時に箱・個体を照合します。

検収差は次へ分類します。

• •欠品・予定外・別機種
• •容量・地域仕様・ロック
• •品質・電池・機能
• •データ消去・アカウント
• •膨張・発熱・浸水等の安全

交換、追加発送、返品、減額、現状受入を対象個体と数量へ結びます。金額調整で原因履歴を閉じず、売り手・案件別の再発を確認します。

手順13：隔離DBで全経路を実API検証する

実在取引先や本番通知を使わず、buyer-test、seller-a/b/c-test、staff-test、account-testを作ります。外部メール・LINEは模擬受信箱へ固定します。

必須テストは次です。

• •自己オファーと担当外アクセス
• •0円・負数・数量単位違反
• •Q&A重大変更後の旧オファー
• •期限延長と自動終了の競合
• •オファー撤回と承認の競合
• •二件の同時承認と上限超過
• •在庫確保と別取引の競合
• •部分承認・全量・最小数量
• •商談変更と契約・請求の競合
• •一部品目の通知・請求
• •通知失敗・再試行・重複防止
• •発送から検収・精算・完了

HTTP応答だけでなく、承認合計、確保数量、商談版、請求行、監査、送信待ちを確認します。失敗処理から中間データが残らないことを合格条件にします。

テストデータの後始末と再現性

テスト案件、オファー、商談、請求、送信待ちはすべてtest_run_idへ結び、本番の相場、調達実績、売り手評価へ含めません。実在する商品画像や個人情報を使わず、模擬端末IDと模擬証拠を使います。

単純削除でテストを終えると、監査・通知・請求の関連を確認できません。隔離DBを初期化できるスクリプトと、同じシナリオを再投入できる固定データを用意します。乱数を使う場合はseedを残し、失敗を再現できるようにします。

テスト実行者とは別の担当が、期待値、DB差分、模擬受信箱を確認します。テスト成功件数だけでなく、未実行、途中停止、外部接続設定の誤りを区別します。

90日ロードマップ

0〜30日

• •初回600台案件、成功条件、対象外を決める
• •役割、状態、項目、数量、公開範囲を承認する
• •正常・異常・同時実行の期待結果を作る
• •隔離DBと模擬受信箱を準備する

31〜60日

• •作成、公開、提案、比較、承認を実装する
• •商談、契約、請求、通知台帳を接続する
• •権限、自己取引、期限、競合テストを通す
• •売り手・買い手・経理が操作確認する

61〜90日

• •一案件を限定運用し日次照合する
• •発送、受領、検収、精算まで完走する
• •上限、確保、請求の不変条件を監視する
• •合格した機種・拠点・形式だけ広げる

本番切替前の確認

切替対象を「新規作成するリクエスト」に限定し、進行中の旧案件を無理に移行しません。移行する場合は、元ID、状態、既存オファー、承認合計、商談、請求の対応を一件ずつ確認します。

切替時には次を固定します。

• •新方式を使う組織・拠点・機種
• •旧方式の最終受付時刻
• •進行中案件の正本
• •外部通知の接続先と送信停止手段
• •障害時に募集・承認を止める条件
• •旧画面へ戻す範囲と判断者
• •24時間、7日、30日後の照合項目

障害時は、新規公開・候補承認・契約確定を止め、既に受領した端末の安全・データ隔離は継続できるようにします。復旧後に古い画面から承認を再送せず、現在versionと合計を確認します。

日次・週次・月次の運用

日次では、期限超過、オファー有効期限、承認上限、在庫確保期限、送信失敗を確認します。週次では、自己取引警告、担当外アクセス、手動順位変更、商談版の滞留、検収差をレビューします。

月次では、売り手別の即納・予定履行、買い手の目標達成、請求訂正、取消・再開、Q&A重大変更を分析します。承認件数を増やすことを目標にせず、契約・受領・検収まで完了した割合と不足理由を測ります。

監視の基本指標は次です。

• •有効承認合計とmaximum_quantityの差
• •契約数量とreserved_quantityの差
• •目標達成までの日数と提案数
• •提案から承認・契約までの滞留
• •将来入荷の予定と実績の差
• •受領・検収・請求の数量差
• •通知重複・最終失敗
• •一件を逆向きに再現できた割合

指標が悪化したら、売り手を一律停止する前に、条件の曖昧さ、画面、期限、委託、機種構成を確認します。

改善後は同じ条件で再測定します。

実装・運用チェックリスト

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

• •[ ] 初回案件と対象外を固定した
• •[ ] 作成・承認・請求を職務分離した
• •[ ] リクエスト・オファー・商談に状態と版がある
• •[ ] 必須・許容・代替条件を分けた
• •[ ] 目標と上限数量を分けた
• •[ ] 公開範囲とQ&Aを版管理する
• •[ ] サーバーで単価・数量・自己取引を検証する
• •[ ] 現在在庫と将来入荷を分けた
• •[ ] 契約時に在庫を条件付き確保する
• •[ ] 必須ゲート後に比較点数を使う
• •[ ] 同時承認で上限を超えない
• •[ ] 商談変更をversionと再承認で行う
• •[ ] 確定品目だけを通知・請求へ渡す
• •[ ] 発送・受領・検収数量を分ける
• •[ ] 隔離DBで実API競合を再現した
• •[ ] 不変条件を定期監視する

まとめ：小さく始めても、上限・自己取引・競合は省かない

買いたいリクエストを小さく始めるなら、一機種、一拠点、一通貨へ範囲を絞ります。ただし、目標と上限、自己オファー、期限、同時承認、在庫確保、商談版、請求の制御は最初から実装します。

必須・許容・代替条件を分け、公開範囲とQ&Aを版管理します。オファーは現在在庫と将来入荷を分け、強制ゲートを通した後で価格・納期を比較します。承認時には最新合計と上限を同じ処理で確認します。

90日間で、600台案件を作成から検収・精算まで完走し、自己取引、期限競合、同時承認、通知失敗を隔離環境で再現します。合格した機種・拠点だけを広げ、上限・在庫・請求の不変条件を継続監視することが、安全な調達基盤への道です。