ln-51-opportunity-evaluator

オポチュニティ評価

目標： 実装に着手する前に、製品の機会を評価します。観察可能な需要と到達可能な獲得経路を起点とし、弱い候補を早期に除外し、市場の精度を作り上げることなく、低コストの検証手順を1つ推奨します。

実行上の契約： 順序付きチェックボックスは完了の定義です。各項目を内部で PENDING、具体的な証拠を伴う PROVEN、条件が存在しないことを示す証拠を伴う CLEARED、または不足がある UNPROVEN として追跡してください。読み取り、委任、ツールの失敗は証明にはなりません。各セクションの後に項目を照合してください。返答する前に、すべての PENDING を解消し、PROVEN と CLEARED のみを数え、不足項目すべてにスキルの判定ルールと承認ルールを適用してください。 ユーザーの意図、スコープ、既存の承認を維持してください。承認済みの作業は続行し、重大な未解決の選択肢、または必要な外部承認についてのみ確認してください。重大なリスクに応じて調査の深さを調整しますが、チェックを黙って省略してはいけません。依存関係と安全性の順序を維持し、それ以外は各義務に適した検証方法を選択してください。

ツールの振り分け

必要な情報	優先ツール	使用する場面	代替手段
製品と制約	ユーザーのコンテキスト、および既存の製品、分析、顧客、戦略に関するドキュメント	対象ユーザー、資産、チャネル、経済性、対象外事項を特定する場合	前提を明記し、重大な意図の不足分のみ確認する
現在の需要と顧客獲得	ウェブ調査、トレンドやマーケットプレイスのデータ、コミュニティ、レビュー、広告、ディレクトリ、顧客からの一次情報	除外や推奨に影響する、外部市場に関するすべての主張	シグナルを取得できないと記載する。検索結果数から数値を推測しない
競合と価格設定	競合製品のページ、価格、リリース履歴、流通チャネル、レビュー、該当する場合は公開情報	代替製品、支払い意思のシグナル、信頼できる差別化を特定する場合	確信度を明示して定性的な証拠を使用する
実現可能性と検証コスト	既存の機能、公開 API、規制、プラットフォームのルール、最新の公式ドキュメント	最も低コストで信頼できる実験と主要な障害要因を比較する場合	推定値であることを明記し、必要な追加証拠を示す

評価は読み取り専用で行ってください。プロジェクトファイル、ロードマップ、エピック、ストーリー、実装計画、キャンペーン、出品情報、広告、顧客への働きかけを作成してはいけません。

証拠の分類

分類	意味
MEASURED	方法と日付が判明している、直接的な分析データ、取引、実験、または計測された観察結果
REPORTED	一次情報源が数値や行動を報告しているが、元の測定結果を独立して確認できない
ESTIMATED	明示された入力値と前提に基づく、明記されたモデル
INFERRED	観察可能な代理指標から導いた定性的な結論
UNKNOWN	証拠が入手できない、古い、比較できない、または判断の裏付けとして弱すぎる

REPORTED、ESTIMATED、INFERRED の証拠を、測定済みの市場規模、検索ボリューム、コンバージョン率、収益、支払い意思に関する主張へと変えてはいけません。外部情報源にはすべて日付を記載し、イベントの日付と公開日が異なる場合は区別してください。 作成者の仮説、意図する体験、好み、確信は、所有者の選好および戦略との適合性に関する入力として扱ってください。需要、顧客獲得、支払い意思を示す証拠として扱ってはいけません。

チェックリスト

1. 意思決定の枠組みを定める

• 既存の製品または機能、対象ユーザー、作成者の仮説、意図する体験、意思決定の期間、利用可能なアセット、地理的または規制上の対象範囲、制約、明示的な対象外事項を明確にします。
• ユーザーが提示した候補を受け入れるか、製品の背景と最新のシグナルから、実質的に異なる機会を一定数生成します。1つのアイデアの見た目だけを変えた案は作成しません。
• より深い検証に進む根拠を定義します。具体的には、特定できるユーザーと課題、観測可能な需要、到達可能なチャネル、信頼できる価値交換、差別化につながる切り口、手頃なコストで実施できる実験です。
• 新しい方向性の発見と、すでに確定した作業の優先順位付けや実装計画を分けます。
• 推薦を覆しうる前提を記録し、調査可能な事実とオーナーの好みを分けます。解釈の違いによって候補や実験が大きく変わる場合に限り、簡潔な質問を1つだけ尋ねます。

2. 候補ごとに1つのエビデンスバンドルを収集する

• 誰がその課題を経験しているのか、現在どのように解決しているのか、何が積極的な検索や購入のきっかけになるのか、その痛みが繰り返し発生する、またはコストがかかることを示すエビデンスは何かを特定します。
• 到達可能な獲得チャネルとその仕組みを見つけます。検索クエリ、マーケットプレイスのカテゴリ、インテグレーションのエコシステム、コミュニティ、パートナー、アウトバウンドの対象者、その他の観測可能な経路などです。
• 直接の競合、代替手段、何もしない場合の行動、価格設定、ポジショニング、流通、レビューでの不満、継続的な投資または撤退のエビデンスを調べます。
• ユニットエコノミクスを捏造せずに、価格の基準、予算の決裁者、購入頻度、切り替えコスト、提供コスト、プラットフォーム手数料、サポート負荷などの経済的なシグナルを調べます。
• 検証実験のコストに影響する、実装、データ、依存関係、規制、信頼、流通、運用上の障害を特定します。
• 出典／日付、エビデンスの分類、対象範囲、確信度、矛盾点、意思決定への影響を記録します。再利用された統計やシンジケートレポートは出所までたどります。相関関係にある転載記事は1つのシグナルであり、独立した裏付けではありません。
• 候補を除外するのに十分なエビデンスが揃った時点、または追加の情報源を調べても候補のステータスが変わらない時点で、その候補の調査を終了します。

3. エビデンスを優先して候補を除外する

• エビデンスが存続に必要な条件と矛盾する場合、または提示された制約内で実現可能な検証手段がないことを示す場合、候補を除外します。ルールに基づき、公開データがないだけの場合は候補を UNKNOWN として保留します。
• 競合の存在は需要や制約を調べる手がかりとして扱います。掲載されていることだけで需要が証明されたとみなさず、利用や購入のシグナルを確認します。代替手段や何もしない場合の行動に対する、具体的な切り口を必須とします。
• 検索ボリューム、競合数、ARPU、市場規模、MVPの期間に、すべてに通用するしきい値を使わないでください。
• 公開データが乏しい候補については、低コストの一次実験で不確実性を解消できる場合、無効と判断せず UNKNOWN として残します。
• すべての除外候補について、決定的なエビデンスと反証条件を記録し、却下の判断を再現できるようにします。
• 外部的な実現可能性を確認した後に限り、オーナーが対象者、チャネル、運用モデル、検証に必要な作業に取り組む意思があり、実行する能力があるかを確認します。本人の関心を推測しないでください。

4. 残った候補を比較し、次の実験を選ぶ

• 根拠の強さ、問題の深刻度、チャネルへの到達可能性、差別化、経済性、検証コスト、クリエイターの理念および目指す体験との戦略的適合性、可逆性について候補を比較し、根拠のない総合スコアにまとめないでください。
• 意味のある見解の相違や感度を保ってください。どの前提が変われば別の候補が優位になるかを示してください。
• 明示された目標に対して、ある候補の根拠が実質的に強い場合に限り、主要な推奨案を1つ選んでください。それ以外の場合はINCONCLUSIVEを返してください。
• 表明された購入意向だけに頼らず、実際の行動を通じて、決定を左右する最も弱い前提を検証する、信頼性のある最小コストの実験を定義してください。
• 実験の対象者、チャネル、オファーまたはプロトタイプ、成功と失敗を示す根拠、予算または時間の上限、安全上の制約、停止ルールを指定してください。結果を知っているかのように装ってはいけません。
• 実装を決める前に、コンシェルジュ形式の提供、プロトタイプの利用、適切な開示を伴う価格設定または予約購入の意向、チャネルからの反応、統合への需要など、後戻りできるテストを優先してください。

5. 検証して報告する

• 重要な外部の主張を収集した一次資料の根拠と照合してください。古くなった主張、矛盾する主張、意思決定に重要で根拠が不足している主張のみを更新し、弱い根拠は明示してください。
• 最終結果では、事実、推定、推論、責任者の希望、未解決の不明点を分けてください。
• 候補に信頼できる需要の兆候があり、到達可能なチャネルがあり、差別化の道筋があり、価値交換が妥当で、実行可能な検証実験がある場合に限り、RECOMMEND <candidate>を使用してください。
• 根拠から有力候補を区別できない場合、または選択前に低コストの実験が必要な場合は、INCONCLUSIVEを使用してください。
• 意思決定に必要な製品コンテキスト、候補の範囲、合法的な調査へのアクセス、安全な検証範囲が不足している場合は、BLOCKEDを使用してください。
• 推奨、除外、保留とした候補をそれぞれの根拠と照合してください。ファイルを作成したり、実験を実行したりせず、提案する次の実験を報告してください。

セルフチェック

• 返答前に照合してください。 項目ごとの根拠、要件の網羅性、矛盾、範囲、判定、該当するクリーンアップを確認してください。報告または許可された成果物を修正してください。有効な根拠は再利用し、リポジトリを自動的に再スキャンしたり、成功したコマンドを再実行したりしないでください。関連する変更、失敗、または未解決の根拠がある場合に限り、チェックを繰り返してください。残る不足を開示してください。

出力要件

次の順序で、ユーザーの言語で報告してください。5つすべてのフィールドを残し、それぞれの事実は一度だけ記載してください。結果が少量の場合は各フィールドを1行にしてもかまいません。空の表は省略し、リンク先の成果物をコピーしないでください。

1. 結果： スキル固有の判定と、根拠に裏付けられた結果。
2. 範囲： レビューまたは変更した範囲、除外事項、ベースライン、重要な前提。
3. 根拠： 以下のスキル固有の項目。事実、推論、未検証の主張を区別してください。成果物にはリンクし、必要に応じて表を使用してください。
4. 検証： チェックと結果、入手できない根拠、該当するクリーンアップまたは外部状態。
5. 完了： Checklist: X/Y complete。Incomplete: None、または各UNPROVEN項目について、その理由、結果への影響、次に行う具体的なアクションを記載してください。残るリスクと必要な意思決定も記載してください。

スキル固有の根拠： 製品、対象者、候補、制約、クリエイターの理念を市場の根拠と分けてください。需要、チャネル、代替手段／差別化要素、経済性、検証コスト、情報源／日付／分類、確信度を比較してください。除外または保留した候補については、決定的な根拠または不明点と、それを覆す条件または解決条件を示してください。推奨案または結論を出せない理由を述べ、実験の合意内容、予算、停止ルール、意思決定を変える根拠を提示してください。働きかけや実験を実行してはいけません。