Phase -1 検証B: 「先に買われる問題」手動計測プロトコル

対象: used-market-arbitrage-engine 設計書 §7 検証B（前提B: 安値案件は人間に先に買われないか）目的: 相場より明確に安い出品が、副業の巡回頻度で現実的に買える鮮度・件数で存在するかを、コードを書く前に手で確かめる。期間: 7〜14日。

なぜこれを最初にやるか

両LLMが最も強く指摘した事業リスク: 「相場より安い出品は、こちらが気づく頃には既に他の人間や業者に買われている」。これが真なら、検知をどれだけ自動化しても人間の購入操作が間に合わず勝てない。この1点で事業の生死が決まるため、実弾もコードも投じる前に手で計測する。

計測対象カテゴリ

検証Aの結果、初期は カメラ・レンズ と レトロゲーム の2つを推奨（相場ソースが確実なため「安いか否か」の判定が正確にできる）。余力があればトレカを追加。

日々の手順（1カテゴリあたり）

巡回: 1日 3回（例: 朝・昼・夜）、メルカリ／ヤフオクで対象カテゴリを「新着順」で見る。
安値判定: 気になる出品の型番をオークフリー（無料）で相場検索。相場中央値より明確に安い（目安: 手数料・送料引いても利益が出る水準）ものだけを記録。
鮮度追跡: 記録した安値出品を、次の巡回でまだ買える状態かチェック。売切れ/消滅していたら「滞留時間」を記録（前回巡回〜今回巡回の間に消えた＝最大その間隔）。
記録: 下記テンプレートに1行追加。

巡回は手動でOKだが、あなたは開発者なので 検証B専用の使い捨て監視スクリプト（対象カテゴリ検索を10〜30分間隔でポーリングし、新規出品の出現と消滅=売却をログ）を組めば、滞留時間を自動・高精度で測れる。これはエンジン本体の実装ではなく計測用の使い捨てなので Phase -1 の範囲内。推奨。

記録テンプレート（CSV / スプレッドシート）

日時, カテゴリ, 型番/商品名, 出品プラットフォーム, 出品価格, 相場中央値(オークフリー), 想定利幅(手数料送料引後), 出品者種別(業者/個人/不明), 検知時に買えたか(Y/N), 滞留時間(分・売切れまで), 備考

例:

2026-07-04 08:15, カメラ, SEL55F18Z, メルカリ, 42000, 58000, +9000, 個人, Y, 25, 美品・箱あり
2026-07-04 08:20, レトロ, スーパーメトロイド 箱説付, ヤフオク, 3200, 6500, +2200, 個人, N(即売切), 5未満, 開始から数分で終了

集計指標（期間終了時）

カテゴリごとに算出:

安値案件の出現頻度: 1日あたり何件の「利益が出る安値」が観測されたか。
購入間に合い率: 検知時に「まだ買えた（Y）」割合。設計書の Phase 0 閾値は 30%以上。
平均滞留時間: 安値出品が消えるまでの平均分。短すぎる（数分）なら人間の巡回では勝てない＝自動監視＋即通知が必須。
推定月間粗利: 出現頻度 × 平均利幅 × 購入間に合い率 × 30日。設計書の Phase 0 閾値は 月3万円以上。

検証B 通過ゲート（Phase 0 へ進む条件）

相場ソースが取れるカテゴリ（検証A）で、推定月間粗利 3万円以上 かつ 購入間に合い率が現実的な巡回頻度で確保できる（＝滞留時間が「自動監視＋通知」で間に合う長さ）。
どのカテゴリも安値がほぼ即売れ（滞留数分・間に合い率<30%）なら、人間の購入操作前提の本モデルは不成立 → 事業モデル見直し（例: 検知だけでなく別の勝ち筋、または撤退）。

判定後の分岐

GREEN: Phase 0（4-5→3カテゴリ並行ペーパートレード）へ。着手順は設計書 §11。
YELLOW（滞留は短いが自動監視なら間に合いそう）: 使い捨て監視スクリプトで滞留時間を精密計測し、通知速度の要件（何秒以内に通知すれば買えるか）を確定してから Phase 0。
RED: 事業モデル見直し。