marketplace-liquidity

マーケットプレイスの流動性管理

対象範囲

対象

• 流動性を信頼性として定義します。つまり、ユーザーが許容できる時間と品質のしきい値内で、マーケットプレイスの中核的なアクション（検索 → マッチング → 取引）をどの程度の頻度で完了できるかを定義します。
• グローバル平均だけでなく、実際に流動性が生じる場所（地域 × カテゴリー × 時間枠などの「ローカルマーケット」単位）で流動性を測定します。
• 流動性が失われる原因として、断片化、需給の不均衡（「フリップフロップ」）、マッチングや仕組みの問題、品質や信頼の崩壊を診断します。
• 実用的な流動性の運用システムを設計します。スコアカード、週次レビューの頻度、「モグラたたき」式の再調整計画（注目度・在庫・インセンティブの移動）を含みます。
• 流動性を改善するための実行可能な実験バックログ（供給、需要、マッチング、価格設定／インセンティブ、信頼と安全性）を作成します。

使用する場面

• 「マーケットプレイスの流動性／マッチ率／充足率を改善する必要がある」
• 「マッチングまでの時間が長すぎる」／「購入者が利用可能なものを見つけられない」
• 「都市やカテゴリーによって需給のバランスが崩れている」
• 「マーケットプレイスの信頼性が低い」／「利用可能なものがなく、コンバージョンが低下している」
• 「流動性ダッシュボード、運用サイクル、実験が必要」

使用しない場面

• 双方向のマーケットプレイスを運営していない（需給間のマッチングがない）。
• 主な問題がバリュープロポジション／ICPである（problem-definition または measuring-product-market-fit を使用してください）。
• 流動性の診断は不要で、価格設定の変更だけが必要である（価格戦略のスキルを使用してください）。
• マッチングの信頼性に関係のない一般的な成長計画が必要である（designing-growth-loops ／ retention-engagement を使用してください）。

入力

最低限必要な情報

• マーケットプレイスの種類と両側（「購入者」と「販売者」は誰か）
• 成功とみなす中核的なアクション（例：リクエスト → 予約、検索 → 購入、メッセージ → 採用）
• 優先する上位1～3個のセグメント（地域／カテゴリー／ユーザーコホート）と対象の時間枠
• 入手可能な最善のベースライン指標（概算でも可）：需要量、供給の利用可能性、マッチ率／充足率、マッチングまでの時間、キャンセル／品質
• 制約条件：予算、利用できる／できないインセンティブ、ポリシー／ブランド／信頼、エンジニアリングのキャパシティ、期間

情報が不足している場合の対応

• references/INTAKE.md から最大5つの質問をしてから、作業を進めてください。
• データが不足している場合は、明示的な仮定を置いて進め、確信度を記載してください。
• 機密情報や個人を特定できる情報（PII）は求めず、集計指標または匿名化した例を優先してください。

出力（成果物）

マーケットプレイス流動性管理パック（チャット内のMarkdown、または依頼された場合はファイル）を作成します。内容は次のとおりです。

1. コンテキストの概要（目標、期間、セグメント、制約、判断への活用方法）
2. 流動性の定義としきい値（信頼性の定義と「十分に良好」な目標）
3. 流動性指標ツリー（ノーススターメトリクスとドライバー指標、イベントの定義を含む）
4. 断片化マップとセグメントスコアカード（流動性が弱い／強い領域、重要な「ローカルマーケット」）
5. ボトルネックの診断（供給、需要、マッチング／仕組み、品質のいずれかを特定。「フリップフロップ」の状態も含む）
6. 介入計画と優先順位付けされた実験バックログ（再配分／「モグラたたき」計画を含む）
7. 測定と計測の計画（ダッシュボード、アラート、トラッキングの不足）
8. 運用サイクル（週次の流動性レビューのアジェンダと担当者）
9. リスク／未解決の質問／次のステップ（必ず含める）

テンプレートと詳しいガイダンス：

• references/TEMPLATES.md
• references/WORKFLOW.md
• references/CHECKLISTS.md
• references/RUBRIC.md

ワークフロー（7ステップ）

1) インテーク＋意思決定とローカル市場の定義

• 入力： ユーザーのコンテキスト、references/INTAKE.md。
• アクション： 目標（指標＋目標値＋期限）を明確にし、主要なアクションを定義し、「ローカル市場」の単位（例：都市 × カテゴリ × 週）を選び、この作業がどの意思決定に役立つのか（何を変えるのか）を決めます。
• 出力： コンテキストのスナップショット＋ローカル市場の定義。
• 確認事項： ステークホルダーが「どのセグメントを、いつまでに、どれだけ改善し、その結果に基づいて何を変えるのか」に答えられること。

2) 流動性を信頼性として定義し、しきい値を設定する

• 入力： 主要なアクション、時間的制約、品質上の制約（キャンセル、返金など）。
• アクション： しきい値（マッチングまでの時間、品質）以内に成功する確率として流動性を定義します。主要指標となる流動性指標を1つ選び、3～6個の要因（充足率／マッチ率、マッチングまでの時間、利用可能性、承諾率、キャンセル率）を設定します。
• 出力： 流動性の定義＋「十分に良い」目標値＋指標ツリーの概要。
• 確認事項： 定義が測定可能で、セグメントに分けられ、ユーザー体験（「信頼性」）に沿っていること。

3) セグメント別スコアカードを作成し、断片化を診断する

• 入力： 地域／カテゴリ／時間枠ごとのベースラインデータ（入手可能な最良のデータ）。
• アクション： 各ローカル市場のセグメント別スコアカードを作成し、需要、供給、マッチング、品質の指標を記録します。断片化（薄い市場、ロングテールのカテゴリ、地域分布の偏り）と、「ニーズの均一性」とニーズの多様性を特定します。
• 出力： 断片化マップ＋最悪のセグメントの優先順位付きリスト（流動性が成長を妨げている箇所）。
• 確認事項： スコアカードが全体平均に依存せず、有意な分析に十分なボリュームを含んでいること（または信頼度の低いセグメントにその旨が示されていること）。

4) ボトルネックを診断する（フリップフロップ＋仕組み＋品質）

• 入力： セグメント別スコアカード、定性的な証拠（サポートチケット、ユーザーフィードバック、運用メモなど）。
• アクション： 優先度の高い各セグメントについて、主な失敗モードを分類します。
  • 供給制約（利用可能な供給／在庫が不足している）
  • 需要制約（意欲／リクエストが不足している）
  • マッチング／仕組みの制約（ランキング、発見、応答時間、価格設定の摩擦）
  • 品質／信頼の制約（キャンセル、無断キャンセル、不正、低評価） また、「フリップフロップ」の動態（現在、どちら側が制約となっているか）と、成長に伴う離脱問題（トップサプライヤーの離脱）も確認します。
• 出力： セグメントごとのボトルネック診断＋根拠メモ。
• 確認事項： 各診断に、少なくとも1つの指標によるシグナルと、検証可能な因果関係の仮説が含まれていること。

5) 施策案と実験バックログを作成する（再配分を含む）

• 入力： ボトルネック診断、制約、利用可能な施策。
• アクション： ボトルネックの種類（供給、需要、仕組み、品質）ごとに施策案を作成します。「モグラたたき」対策として、セグメント間で注意、在庫、インセンティブを毎週どのように再配分するかを計画します。施策を、明確な仮説と成功指標を持つ実験に落とし込みます。
• 出力： 優先順位付きの実験バックログ＋再配分プレイブック。
• 確認事項： すべての実験に、（a）セグメント、（b）主要指標、（c）目標とする効果量または効果の方向性、（d）妥当な実施サイクルが設定されていること。

6) 測定方法と流動性運用の定期サイクルを設計する

• 入力： 選定した指標と実験。
• アクション： ダッシュボード／アラート、イベントの定義、計測の不足箇所を明確にします。毎週の流動性レビューの議題と意思決定ログ（何を再調整し、何を終了し、何を拡大するか）を作成します。
• 出力： 測定計画＋運用の定期サイクル（判明している場合は担当者も記載）。
• 確認事項： 各主要指標がデータソースと更新頻度に結び付いており、定期サイクルが状況報告ではなく具体的な意思決定につながること。

7) 品質ゲートを通過させ、パックを仕上げる

• 入力： ドラフトパック、references/CHECKLISTS.md、references/RUBRIC.md。
• アクション： チェックリストを実行し、ルーブリックで評価します。具体的で、セグメントを考慮し、テスト可能な内容になるまでパックを磨きます。必ず Risks / Open questions / Next steps を含めてください。
• 出力： 最終版のマーケットプレイス流動性管理パック。
• 確認事項： 今後2週間の作業（データ取得、1～3件の実験、実施ペース）が滞りなく進められる状態になっています。

品質ゲート（必須）

• references/CHECKLISTS.md と references/RUBRIC.md を使用します。
• 必ず Risks、Open questions、Next steps を含めてください。

例

例1（サービス型マーケットプレイス、地域ごとの分断）：
「marketplace-liquidity を使用してください。12都市で住宅清掃のマーケットプレイスを運営しています。目標は、下位4都市の予約成立率を8週間で62%から80%に引き上げることです。供給が不足し、応答時間も遅いと考えています。セグメント別スコアカード、ボトルネック診断、優先順位付きの実験バックログを含むマーケットプレイス流動性管理パックを作成してください。」

例2（B2Bマーケットプレイス、カテゴリー間の不均衡）：
「marketplace-liquidity を使用してください。スタートアップとフリーランスのデザイナーをマッチングしています。「ロゴデザイン」の流動性は高い一方、「プロダクトデザイン」と「ブランド刷新」は低い状態です。目標は、60日以内にプロダクトデザインの初回適格マッチングまでの所要時間の中央値を5日から2日に短縮することです。流動性指標ツリー、分断マップ、運用ペースを提示してください。」

境界例（流動性の問題ではない場合）：
「購入者を増やすためのGoogle Adsの広告文を書いてください。」
回答：これは主に顧客獲得／コピーライティングの課題です。マーケットプレイスの信頼性がすでに高い場合は、copywriting／チャネル別のグロース施策を使用してください。信頼性が不明な場合は、まず受付時の確認を行い、流動性のボトルネックがあるかを確認してください。