中古品 相場乖離検知エンジン（used-market-arbitrage-engine）設計書

作成日: 2026-07-03 ステータス: ドラフト（ユーザーレビュー待ち・v2） 前身プロジェクト: atelier-kyo-manager（BUYMA向け新品ブランド転売システム） 関連レビュー: GLM / MiniMax 両LLMによる方向性レビュー（1回目=両者「条件付き賛成」／2回目=GLM「条件付きGO」・MiniMax「NO-GO寄り・要手戻り」）。本v2は2回目の指摘を反映。

1. 背景と問題

atelier-kyo-manager は BUYMA 向けの新品ブランド品転売システムとして作り込まれた（Flask、価格スクレイピング、出品パイプライン、注文ステートマシン、LLM連携、テスト2,070件）。しかし新品ブランド品は、ネット仕入れ（FARFETCH / italist 等）では 法人卸・VIP買付・現地買付＋VAT還付組に仕入れ原価で構造的に勝てないことが判明し頓挫した（根拠: 30_RESEARCH/atelier-kyo/ の各調査）。eBay 等への横展開も同様に厳しい感触。

一方で、このシステムに詰まっている技術資産（監視・スクレイピング・ステルス・相場分析・LLM連携・状態管理）は、ネットビジネスの基本が凝縮されており、別の土俵で活かせる可能性が高い。

2. 目的と成功基準

  • 目的: 既存システム資産を「中古品の相場乖離検知エンジン」に転用し、副収入として 月3〜10万円の粗利を現実的に狙う。
  • 成功基準（Phase 1 到達判定）: 実弾投入カテゴリで、手数料・送料・鑑定/清掃コスト込みの実測純利益が月3万円以上を2ヶ月連続で達成。
  • ゲート方式（重要）: Phase -1 → Phase 0 → Phase 1 の各段階に通過ゲートを設け、ゲート未通過なら次に進まない。特に Phase -1（§7）を通過しない限り実装（コード記述）に進まない。
  • 撤退基準: いずれかのゲートで全候補カテゴリが基準未達なら、実弾・実装を止め事業モデルを見直す。

制約・前提（ユーザー確定事項）

  • 資金: 50万円以上。有在庫OK。古物商許可: 取得済み/取得予定。
  • 運用: 購入判断・検品・発送は人間が行う（Botによる自動購入はしない）。システムは監視・候補抽出・査定・通知まで。
  • スクレイピング規約リスク: 回避のための作り込みは行う（既存ステルス資産を活用）。多重アカウント運用・法的グレーは運用者判断とし、設計上のリスク回避作り込みはステルス層に限定する。
  • SaaS化: 本スコープ外（将来オプション）。自分の成約実績・利益データが最強の営業材料になるため、実績を出した後の Phase 3 以降に棚上げ。

3. 核心仮説と、その最大の弱点

  1. 中古市場には新品ブランド品のような仕入れルートの構造壁がない。個人出品者が相場を知らずに安値で出すため、「相場より安い出品を、早く・正確に見つける」情報戦で個人でも勝てる余地がある。
  2. 個体差（状態・付属品）問題は “精度が出ない案件は買わない” で回避できる。同定・相場算出は機械的に確実にやり、状態抽出だけLLM（Vision込み）に任せ、情報が不確実な案件は保守側（見送り）に倒す。
  3. どのカテゴリで戦うかは事前に決めず、データで淘汰する。エンジンをカテゴリ非依存に作り、カテゴリ固有情報を設定ファイル化することで、実弾ゼロで勝てるカテゴリを選別する。

⚠️ この事業の生死を分ける2大前提（両LLMが最も強く指摘）

  • 前提A「相場ソースが取れるか」: Step2 の基準相場を、どこから・どの精度で取得できるかが全パイプラインの土台。メルカリ/ラクマ/Yahooフリマの成約データは取得困難な可能性が高い。ここが取れないカテゴリはエンジンが空転する。
  • 前提B「先に買われる問題」: 相場より明確に安い出品は、こちらが検知する頃には既に他の人間や業者に買われている可能性が高い。ツールの検知速度が人間に対して優位でなければ、案件を見つけても買えない。

→ この2つはコードを書く前に手動で確かめる（§7 Phase -1）。緑なら実装、赤なら早期撤退。

4. 全体アーキテクチャ（既存資産の転用マップ）

エンジンはカテゴリ非依存。カテゴリごとに異なるのは設定ファイル（§6）だけ。

[監視ループ] → [同定] → [基準相場算出] → [状態抽出(LLM+Vision)] → [減額査定(カテゴリ別DSL)] → [判定] → [通知] → 人間が購入判断

既存資産の再利用（atelier-kyo-manager から流用）

エンジンの部品 転用元 転用内容 着手優先度
型番同定・名寄せ app/utils/product_matching.py（extract_model_numbers(), cross_site_match_score(), NOISE_WORDS） §5 Step1 の同定層にそのまま使える 最優先
価格スクレイピング基盤 app/agents/price_intelligence_agent.py Playwright ベースの取得パターン 高
LLM ルーティング 既存 LLM 連携（GLM/MiniMax/Sonnet） §5 Step3 の状態抽出（Vision含む）に流用 中（後回し）
自己修復セレクタ selector_discovery_agent.py 他 サイトDOM変更への耐性 中（後回し）
ブラウザ・ステルス層 app/agents/browser/stealth.py webdriver秘匿・Canvas/WebGLノイズ・navigator偽装 低（最後）
プロキシ・UA/viewport ローテ session_proxy.py（ProxyManager）, session_config.py プール・ローテ・セッション永続化 低（最後）
状態管理・通知 注文ステートマシン、通知フロー 案件のライフサイクル管理・通知 中
観測・トレース observability.py, trace_reporter.py 他 監視の可視化・デバッグ 中

着手順の方針転換（両LLM採用）: ステルス層・プロキシは「最初に作る資産」ではなく最後。まず「相場ソース確定 → 検知精度（Step1+2）だけ」で粗利フィージビリティを示し、LLM/Vision・ステルスは後から足す。BAN回避より先に「そもそも儲かるか」を確かめる。

新規に作る部品

  • カテゴリ設定ローダ（§6）
  • 相場DB（型番×状態クラスタごとの成約価格履歴）
  • 5段階査定パイプライン（§5）
  • Phase -1/Phase 0 の記録・集計基盤（§7, §8）

5. 査定パイプライン（本エンジンの心臓部）

設計思想: LLMに値付けさせない。LLMは「構造化抽出」だけ担当。値付けはルールベース。

Step 1: 同定（機械的・LLM不使用）

  • 出品タイトル/説明から型番・モデル名を辞書＋正規表現で特定。product_matching.py を流用。
  • 特定できなければ案件を捨てる（あいまいな物は土俵に乗せない = 精度の源泉）。
  • 出品者が業者か個人かを判別（業者=適正価格で利益薄のことが多い／個人=相場無知の安値が出やすい）。判別材料を記録し、淘汰分析に使う。

Step 2: 基準相場算出（機械的・状態クラスタ別）

  • 相場ソースは Phase -1 で確定したものだけを使う（前提A）。取得可否・精度が確認できないカテゴリはここで脱落。
  • 同一型番でも「美品/並品/難あり/ジャンク」で相場が大きく割れるため、単一の相場値ではなく状態クラスタ別のレンジを持つ（GLM/MiniMax指摘）。
  • サンプル不足（直近成約 < N件）の型番はスキップ。

Step 3: 状態・付属品の抽出（ここだけLLM・Vision必須）

  • 出品説明文＋出品画像をLLM（Visionモデル）に渡す。値段は聞かない。以下を決められたJSON形式で抽出:
    • state_grade（カテゴリ定義のグレード）
    • accessories（付属品チェックリストに対する有無）
    • defects（難あり要素の列挙。写真から傷・カビ・日焼け等を読む）
    • authenticity_flag（レプリカ/コピー/改造の疑い）
    • extraction_confidence（0.0〜1.0）
  • 出力は JSON スキーマで強制。パース失敗・低信頼度・真贋フラグ立ちは Step 5 で見送りに倒す。
  • 中古はテキストだけでは価値が測れない（写真の傷で価値激減）ため、Vision無しの設計は不可。

Step 4: 減額査定（カテゴリ別 DSL）

  • 共通の減額テーブルはカテゴリ横断で破綻する（レンズ=カビ/光学系、トレカ=PSA鑑定/PSA10プレミアム、レトロゲーム=動作/ソフト有無、ゲーム機=傷よりソフト有無）。→ カテゴリごとに独立した減額ルール（DSL）として §6 に定義。
  • Step2 の状態クラスタ相場に対し、カテゴリDSLで微調整。地雷キーワード該当は自動除外 or 大幅減額。

Step 5: 判定と通知

  • 期待利幅 = 状態クラスタ相場 − 出品価格 − 販売手数料 − 送料 − 鑑定/清掃コスト − 想定不良引当
    • 鑑定コスト（レプリカ判定・PSA鑑定等）と不良引当を粗利計算に組み込む（両LLM指摘）。
  • 利幅が閾値超え かつ extraction_confidence が閾値超え かつ 真贋フラグ無し の案件だけ人間に通知。
  • 情報不足・状態不明・信頼度低・真贋疑いは保守側（見送り）に倒す。

6. カテゴリ設定ファイル（ドメイン知識の外部化・カテゴリ別DSL）

カテゴリごとに1ファイル（JSON/YAML）。エンジン本体は不変。減額ルールはカテゴリ別DSLとして持つ。

category: used_camera_lens
sources:                      # 監視対象（出品側）
  - {name: mercari, search_queries: [...]}
  - {name: yahoo_auction, search_queries: [...]}
price_reference:              # 相場ソース（Phase -1で取得可否を確定したもののみ）
  source: <phase -1 で確定>
  min_sold_samples: 5
model_dictionary:             # 型番辞書・抽出パターン
  patterns: [...]
  aliases: {...}
state_grades:                 # 状態グレード定義（状態クラスタ相場のキー）
  - {id: mint, label: "新品同様"}
  - {id: good, label: "美品"}
  - {id: fair, label: "並品"}
  - {id: junk, label: "難あり"}
seller_type_hints:            # 業者/個人の判別材料
  business_markers: [...]
valuation_dsl:                # ★カテゴリ別減額DSL（横断共通にしない）
  accessories:
    - {id: box, label: "箱", penalty: 0.05}
    - {id: rear_cap, label: "リアキャップ", penalty: 0.02}
  defects:
    - {keyword: ["カビ","クモリ"], penalty: 0.40}
    - {keyword: ["チリ","ホコリ"], penalty: 0.05}
  # 例: トレカなら grade_premium(PSA10)=+X%, レトロなら動作/ソフト有無 の二項…
landmine_keywords: ["ジャンク","訳あり","コピー","レプリカ","改造"]
costs:                        # 粗利計算に入れる想定コスト
  authentication_fee: <鑑定要否・費用>
  defect_reserve_pct: 0.05
thresholds:
  min_profit_yen: 5000
  min_confidence: 0.7

初期候補カテゴリ（Phase -1/0 で検証。Phase -1 で相場ソースが取れないものは即脱落）:

  1. 中古カメラ・レンズ（オールドレンズ含む）
  2. トレカ（ポケカ/遊戯王 等）
  3. レトロゲーム・ゲーム機
  4. 中古オーディオ機器
  5. ブランド小物（既存リサーチ資産の検証枠）

7. Phase -1: フィージビリティ検証（実装前ゲート・コードゼロ／実弾ゼロ）

目的: 前提A（相場ソース）・前提B（先に買われる問題）を、コードを書く前に手動で確かめる。所要 1〜2週間。ここを通過しない限り実装に進まない。

検証A: 相場ソースの取得可否調査

  • 候補カテゴリごとに「同一型番の成約相場を、どこから・どの精度・どの頻度で取れるか」を実地調査（価格.com中古、相場系サイト、オークション落札履歴、公開API等、取得可能な”真の成約”ソース）。
  • 判定: 状態クラスタ別に信頼できる相場が引けるソースが存在するカテゴリだけ Phase 0 へ。存在しないカテゴリは脱落。

検証B: 「先に買われる問題」の手動計測

  • 1〜2カテゴリで、人間が1日数回手動巡回し、「明らかに相場より安い出品」を見つけたら記録: 検知時刻・価格・相場・その出品が何分後まで買える状態で残っていたか。
  • 判定: 副業の巡回頻度で現実的に買える鮮度・頻度の安値案件が、月あたり十分な件数存在するか。存在しなければ、検知を自動化しても人間の購入操作が間に合わず勝てない → 事業モデル見直し。

Phase -1 通過ゲート（両方満たす）

  • 相場ソースが取れるカテゴリが1つ以上ある。
  • そのカテゴリで、手動でも「月3万円粗利に届きうる件数・鮮度の安値案件」が観測できる。

8. Phase 0: カテゴリ淘汰トーナメント（実弾ゼロ + ハイブリッド検証）

Phase -1 通過後。期間 2〜4週間。通過カテゴリを並行でペーパートレード。

記録する指標（案件ごと）

  • 検知時刻・出品価格・状態クラスタ相場・期待利幅・抽出信頼度・出品者種別（業者/個人）
  • 検知から売切れ（or 出品消滅）までの経過時間（＝購入判断が間に合うか）
  • 「もし通知直後に買っていたら」の仮想損益（鑑定/不良引当込み）

淘汰の数値閾値（事前固定・恣意性排除）

カテゴリが Phase 1 へ進む条件（すべて満たす。閾値はカテゴリ単位で判定、合計母数で薄めない）:

  • 仮想月間粗利 ≥ 3万円（案件頻度 × 平均利幅 × 購入間に合い率）
  • 購入間に合い率 ≥ 30%
  • 有効サンプル ≥ 20件（各カテゴリ）
  • 平均抽出信頼度 ≥ 0.7

ハイブリッド検証（「本当に買えたか」の実測）

Phase 0 後半、閾値上位2カテゴリに超小口実弾プローブ（1件5,000〜10,000円 × 数件）:

  • 検知した安値案件を実際に購入できるか（決済成立率＝前提Bの再確認）
  • 実送料・実手数料・届いた現物 vs LLM査定の乖離（Step3精度の実測）
  • 売却CVR（実際に想定価格で売れるか）。→ そのため販路アカウント育成はPhase 0前半から並行（下記）。

並行準備（ボトルネック除去）

  • 販路アカウント（メルカリ/ヤフオク/eBay 等）の評価を低額出品で先に育成し、Phase 0 のうちに売却CVRまで実測する（「評価ゼロで売れない」「そもそも売れない」を早期に検出）。

9. Phase 1 以降

  • Phase 1: 実測1位カテゴリに小口実弾（1件1〜3万円 × 10件〜）。2位はペーパートレード継続（保険）。§9末の資金回転試算で在庫件数・再投資サイクルを管理。
  • Phase 2: 回転確認後に資金増額 + 販路追加（eBay 輸出）を検討。
  • Phase 3（スコープ外・将来）: 自分の成約実績を土台に SaaS/BOT 提供を検討。

資金回転試算（資金効率懸念への回答）

月間粗利 = 平均利幅 × 月間成約件数。月間成約件数 = (投下資金 ÷ 平均仕入単価) × (30 ÷ 平均回転日数)。 → 目標月3〜10万を満たす「平均利幅 × 回転日数 × 必要資金」の組合せを Phase 0 実測値で逆算し、Phase 1 の投入設計に反映。無在庫（相乗り）併用も資金効率オプションとして検討（GLM指摘）。

10. リスクと対処

リスク 深刻度 対処
相場ソースが取れず全パイプライン空転（前提A） 最高 §7 Phase -1 検証A。取れないカテゴリは実装前に脱落
安値案件は人間に先に買われる（前提B） 最高 §7 検証B（手動計測）→ §8 実弾プローブで決済成立率を実測
LLM査定が個体差で外れる 高 §5 Step3 を Vision 必須化・抽出専任・不明は見送り。§8で現物vs査定を実測
減額ルールのカテゴリ横断破綻 高 §6 カテゴリ別DSLに分離
偽物・コピー品／鑑定コスト 中 landmine＋authenticity_flagで除外、鑑定費・不良引当を粗利計算に算入、人間検品必須
古物商の帳簿・仕入先記録の運用負荷 中 取引台帳の記録フローを運用に組込み（Phase 1前に整備）
業者の適正価格を無駄に追う 中 §5 Step1 で出品者種別を判別・記録
販路アカウントBAN / 規約変更で全損 中 販路分散・アカウント事前育成。ステルスは検知側のみ
サイトDOM変更でスクレイパー破損 中 既存の自己修復セレクタ資産を流用

11. 着手モジュール順（両LLM採用・「情報戦の精度」を先に証明）

  1. Phase -1 検証（コードゼロ）: 相場ソース可否＋先に買われる問題の手動計測 → GO/NO-GO 再判定。
  2. 相場DB + Step1/Step2 の検知精度だけ試作（LLM・ステルス抜き）。型番同定→状態クラスタ相場→安値検知まで。
  3. Phase 0 記録・集計基盤（機会母数・購入間に合い率・仮想損益の自動集計）。
  4. 販路アカウント先行立ち上げ + 売却CVR測定。
  5. Step3 LLM/Vision 統合（検知が回ってから精度を足す）。
  6. ステルス層・プロキシ統合（監視頻度・網羅性を上げる段で最後に）。
  7. 実弾プローブ → Phase 1。

12. スコープ外（YAGNI）

  • 自動購入（Bot決済）— 人間が実行。
  • SaaS/BOT 販売 — Phase 3 以降。
  • 新品ブランド品仕入れ — 頓挫済み。
  • 多重アカウント自動生成 — 運用者手動。設計対象はステルス層のみ。

付記: 既存資産の確認済み事実（2026-07-03 実地確認）

  • app/utils/product_matching.py: extract_model_numbers() / cross_site_match_score() / NOISE_WORDS 実装済み → §5 Step1 に直接転用可能（最優先で使う資産）。
  • app/agents/price_intelligence_agent.py: Playwright ベースの価格取得基盤。
  • app/agents/browser/stealth.py: webdriver秘匿・Canvas/WebGLノイズ・navigator偽装（着手は最後）。
  • app/agents/browser/session_proxy.py: ProxyManager（プール・サイト別選択・ラウンドロビン）。
  • app/agents/browser/session_config.py: UA/viewportローテーション・セッション永続化。
  • 自己修復セレクタ群（selector_discovery_agent.py 他）・観測基盤（observability.py 他）実装済み。
This site uses Just the Docs, a documentation theme for Jekyll.