business-evaluation

[BLOCKING] スキルの手順は、宣言された順序で実行してください。明示的にユーザーの承認を得ずに、手順を省略、並べ替え、または統合してはいけません。 [BLOCKING] 各手順またはサブスキルの呼び出しの前に、タスクの追跡情報を更新してください。手順の開始時に in_progress、終了時に completed を設定してください。 [BLOCKING] 完了またはスキップした手順には、簡潔な根拠または明示的なスキップ理由を必ず記載してください。 [BLOCKING] Task ツールを利用できない場合は、同じステータス遷移を備えた、手順ごとの同等の計画トラッカーを作成し、維持してください。

クイックサマリー

目標： 根拠に基づいた実現可能性の判定（スコア＋信頼度＋「追求／転換／保留／見送り」の推奨）を行います。完全な9ブロックのBMC、前提を明示した3年間の財務予測、軽減策を含む5件以上のリスク、段階的な実行計画とGTM計画に基づき、楽観論ではなく追跡可能な証拠に基づいて、実施可否の判断を下せるようにします。

概要：

• 7つの主要ステップをすべて順番どおりに実行します： （1）アイデアを把握する（課題／解決策／対象）、（2）市場分析データを根拠として読み込む、（3）ビジネスモデルキャンバス（BMC）の9ブロックすべてを作成する、（4）前提表を含む3年間の財務予測を作成する、（5）5件以上のリスクを評価する、（6）段階的な実行計画を作成する、（7）市場投入計画（GTM）を作成し、その後、ステップ7の判定を提示する。手順を省略、並べ替え、統合してはいけません。その理由は、AIがスキル自身の手順を忘れ、不完全な評価を出すためです。
• market-analysis の後に実行します。市場規模をここで再計算するのではなく、同スキルの市場データを根拠として取り込みます。このスキルは実現可能性を判定するものであり、市場を調査するものではありません。
• すべての成果物は、証拠による検証が必須です。BMCの9ブロックすべてに根拠を引用し、財務上の各数値に前提と情報源を付し、5件以上のリスクそれぞれに軽減策と残存リスクの記載を求めます。裏付けのない数値やブロックがあれば、この検証を通過できません。
• 判定は最も重要な成果物です。実現可能性スコア（1～10）、証拠に基づく明確な信頼度区分（95／80／60／60％未満）、実施／転換／保留／見送りの判断、そして成功に欠かせない唯一の条件を提示します。楽観論ではなく、懐疑的な見方を優先してください。
• 強制適用される .claude/templates/business-evaluation-template.md を使用して、結果を docs/knowledge/strategy/business/{slug}.md に記録します。その後、次の手順に進むため AskUserQuestion を使ってください（domain-analysis を推奨）。自動的に判断してはいけません。

ワークフロー：

1. アイデアの把握 — 課題、解決策、対象顧客
2. 市場分析の読み込み — market-analysis の市場データ
3. ビジネスモデルキャンバス — 根拠を含む9ブロックすべて
4. 財務予測 — 3年間の収益、コスト、損益分岐点
5. リスク評価 — 軽減策を含む5件以上のリスク
6. 実行計画 — マイルストーンを含む3段階の計画
7. 判定 — 実現可能性スコア、信頼度、推奨事項

主なルール：

• BMCの9ブロックすべてが必須で、それぞれに根拠が必要です
• 財務予測には、明示的な前提表が必要です
• 最低5件のリスクについて、軽減策と残存リスクの両方が必要です
• 判定は証拠に基づき、信頼度を明示する必要があります

懐疑的な姿勢で、批判的思考と順序立てた思考を用いてください。すべての主張に追跡可能な証拠と信頼度（％）が必要です（アイデアの信頼度は80％を超える必要があります）。

事業評価

ステップ1：アイデアを把握する

ユーザー入力から、以下を抽出します。

• 一言で表す説明 — 1文のエレベーターピッチ
• 課題 — どのような問題を解決するのか？
• 解決策 — どのように解決するのか？
• 対象顧客 — 具体的に誰にメリットがあるのか？

ステップ 2：ビジネスモデルキャンバス

9 つのブロックすべてが必須です。

ブロック	主な質問	必要な根拠
顧客セグメント	誰にサービスを提供しますか？	市場調査
価値提案	どのような価値を提供しますか？	顧客の課題
チャネル	どのように顧客にリーチしますか？	チャネル分析
顧客との関係	どのように関係を維持しますか？	顧客維持戦略
収益の流れ	どのように収益を得ますか？	価格調査
主要リソース	何が必要ですか？	リソース評価
主要活動	何を行う必要がありますか？	運営分析
主要パートナー	誰が協力してくれますか？	パートナーの状況
コスト構造	どのようなコストがかかりますか？	コスト分析

ステップ 3：財務予測（3 年間）

収益モデル

年	ユーザー／顧客	ARPU	収益	成長率

コスト構造

カテゴリー	Y1	Y2	Y3

損益分岐点

• 月次バーンレート： ${X}
• 損益分岐点： 月／年
• 必要な資金調達額： ${X}

前提条件の表

すべての数値に、前提条件と出典を記載してください。

ステップ 4：リスク評価

リスクを最低 5 つ挙げてください。

リスク	発生可能性	影響	軽減策	残存リスク

検討するカテゴリー：市場、実行、財務、競争、規制、技術。

ステップ 5：実行計画

フェーズ	期間	重点項目	主なマイルストーン
検証	0-3 か月	顧客発見、MVP	N 件のインタビュー、プロトタイプ
構築	3-6 か月	中核製品、初期ユーザー	ベータ版のローンチ、初収益
成長	6-12 か月	拡大、最適化	収益目標、チーム規模

ステップ 6：市場投入戦略

• ローンチ戦略 — 市場への参入方法
• 初期チャネル — 上位 3 つの顧客獲得チャネル
• 価格戦略 — モデル＋根拠＋競合との比較

ステップ 7：結論

• 実現可能性スコア： 1～10 とその根拠
• 確信度： 95%／80%／60%／<60%、根拠となる証拠を記載
• 推奨事項： Pursue | Pivot | Pause | Pass
• 重要な条件： 成功に必要な条件は何ですか？

出力

.claude/templates/business-evaluation-template.md の必須テンプレートを使用して、docs/knowledge/strategy/business/{descriptive-slug}.md に書き込んでください。

---

次のステップ

必須・重要・必ず注意 — 例外なし このスキルを完了した後、必ず AskUserQuestion を使って以下の選択肢を提示してください。タスクが「簡単」または「明白」に思えても、決して省略しないでください。判断するのはユーザーです。

• 「/domain-analysis（推奨）」 — ビジネス評価からドメインモデルを分析する
• 「/plan」 — 実装計画を立てる準備ができている場合
• 「スキップして手動で続行」 — ユーザーが判断する

［重要］ 作業を始める前に、TaskCreate を使ってすべての作業を小さなタスクに分割してください。

外部メモリ： 複雑な作業や長時間にわたる作業（調査、分析、スキャン、レビュー）では、中間調査結果と最終結果を plans/reports/ のレポートファイルに記録してください。これにより、コンテキストの喪失を防ぎ、成果物としても活用できます。

エビデンスゲート： 必須・重要・必ず注意 — すべての主張、調査結果、推奨事項には、file:line による証拠、または確信度のパーセンテージを付した追跡可能な証拠が必要です。実行するには確信度が80％を超えている必要があり、80％未満の場合は、まず検証してください。

AI のミスを防ぐ — あらゆるタスクで、以下の失敗を避けてください。

コンテキストが変化したら、ファイルを読み直してください。 コンテキストの圧縮、再開、または長時間の作業によって記憶が古くなることがあります。行動する前に、現在のファイルを確認してください。 生成した内容をソースの証拠と照合してください。 AI は API、名前、主張、文書の事実を幻覚することがあります。記載または参照する前に、関連するソースを確認してください。 削除または名前変更の前に、後続の参照を確認してください。 成果物を削除すると、ドキュメント、生成されたミラー、設定、呼び出し元に古い参照が残ることがあります。まず参照関係を把握してください。 編集後は、影響の連鎖を最後まで追跡してください。 定義を変更すると、派生する出力や利用側への影響を見落とすことがあります。完了を宣言する前に、影響を受ける連鎖を追跡してください。 最初の出力だけでなく、影響を受けるすべての出力を検証してください。 チェックが1つ成功しても、すべてが成功したとは限りません。変更によって影響を受ける可能性がある出力面をすべて検証してください。 既存の値は意図的なものと考え、変更または不具合として指摘する前に、その理由を確認してください。 定数、上限、フラグ、しきい値、文言、パターンを変更または報告する前に、周辺のコンテキストと履歴、呼び出し元の処理順序、同じ慣例に従う2つ以上の類似した呼び出し箇所を確認してください。「何を」説明していても「なぜ」を示していない文書は、理由が欠けているのであって、ガードが欠けている証拠ではありません。 行動する前に曖昧さを明らかにし、黙って解釈を選ばないでください。 複数の妥当な解釈がある場合は、明示的に質問するか、リスクを添えて前提を示してください。 インフラが管理する中間状態ではなく、システムが責任を持つ結果を検証してください。 非同期処理を検証する際は、最終的なビジネス状態を確認してください。共有インフラを利用する並行プロセスが書き込める配信・再試行の記録状態を確認してはいけません。このようなチェックは単独実行では成功しますが、同じインフラを別の処理と共有した途端に不安定になります。 共有ガイダンスは、役割に関連した内容にしてください。 すべてに共通するガイダンスは、それを受け取るすべてのスキルまたはエージェントに役立つものでなければなりません。コード固有の義務は、コード固有のプロトコルにのみ記載してください。

批判的思考の姿勢 — 批判的思考と逐次的思考を適用してください。すべての主張には追跡可能な証拠が必要です。行動するには確信度が80％を超えている必要があります。 幻覚の防止： 推測を事実として示さないでください。すべての主張の出典を示し、不確実性を率直に認め、出力に誤りがないか自己確認し、独立して相互参照し、自分の確信を常に疑ってください。証拠のない確信こそ、あらゆる幻覚の根本原因です。

必ず注意 批判的思考と逐次的思考を適用してください。すべての主張には、適切で追跡可能な証拠が必要です（リポジトリやコードに関する主張には file:line、調査、製品、コンテンツ、ドキュメントに関する主張にはソース URL または成果物のセクション）。行動するには確信度が80％を超えている必要があり、60％未満の場合は推奨しないでください。幻覚を防止してください。推測を事実として示さず、不確実性を率直に認め、独立して相互参照し、自分の確信を常に疑ってください。

必ず注意 AI のミスを防止してください。生成した内容を証拠と照合し、削除または名前変更の前に後続の参照を追跡し、影響を受けるすべての出力を検証し、コンテキストを失った後はファイルを読み直し、行動する前に曖昧さを明らかにしてください。

Prompt-Enhance Closing Anchors

重要：必ず注意してください このスキルで宣言された手順の順序に従ってください。ユーザーの明示的な承認なしに、手順を省略、並べ替え、統合してはなりません。 重要：必ず注意してください 各手順／サブスキル呼び出しでは、実行前に in_progress に設定し、実行後に completed に設定してください。 重要：必ず注意してください 省略した手順にはすべて明示的な理由を含めてください。完了した手順にはすべて簡潔な根拠を含めてください。 重要：必ず注意してください Task ツールを利用できない場合は、同期されたステータスを記録する、同等の段階的な計画トラッカーを維持してください。

プロジェクトプロトコルの適用 — このスキルを実行する前に、このスキルに適用される PROJECT オーバーレイルールを解決してください。プロジェクトのスキルプロトコル索引（デフォルトでは docs/project-reference/skill-protocols-reference.md。docs/project-config.json の referenceDocs エントリーでパスが上書きされている場合はそのパス）の Target 列にこのスキル名を照合し、最も具体的に一致する階層のみを使用します（完全一致 > glob > *）。この優先順位はオーバーレイ同士の優先順位であり、このスキルとの優先順位ではありません。一致した本文のみを読み取り、<protocols-dir>/<Name>.md として解決してください。行の Body リンクは表示テキストであり、読み取り先ではありません。一致した本文が存在しない、または不正な形式の場合は、その旨を報告してスキップしてください。索引の Description から再構成してはなりません。索引がない場合、または一致する項目がない場合は、オーバーレイなしで、何も報告せずに進めてください。完全な仕様は .claude/skills/project-skill-protocol/references/registry.md にあります。

オーバーレイは追加のみです。このスキル独自のプロトコルにルールを追加するものであり、既存のルールを置き換えたり、上書きしたり、無効化したり、解釈し直したりしてはなりません。すべてのオーバーレイを取り除いた場合、このスキルは文書化された動作と完全に同じでなければなりません。オーバーレイは簡潔な概要であり、権限を拡大するものではありません。ワークフローのゲート、Git の規律、レビューゲート、ユーザー確認ゲートを免除することはできません。オーバーレイとスキルが実際に矛盾する場合、または同じ具体性のオーバーレイ同士が直接矛盾する場合は、両方をユーザーに提示してください。黙って解決してはなりません。

必ず注意してください 実行前に、このスキルに適用されるプロジェクトプロトコルのオーバーレイを解決してください。最も具体的に一致する階層のみを使用します（完全一致 > glob > *。これはオーバーレイ同士の優先順位であり、このスキルとの優先順位ではありません）。一致した本文のみを <protocols-dir>/<Name>.md から読み取ってください。本文が存在しない、または不正な形式の場合は報告し、再構成してはなりません。オーバーレイは追加のみであり（このスキル独自のルールを置き換えてはなりません）、簡潔な概要であって、権限を拡大するものではありません。同じ具体性のオーバーレイ同士が矛盾する場合は、ユーザーに提示してください。

最後の確認事項

重要：必ず注意してください 目標： 根拠に基づく実行可能性の判定を提示します。スコア、確信度、Pursue／Pivot／Pause／Pass の推奨を含め、9ブロックの BMC を完全に作成し、前提を明示した3年間の財務予測、軽減策を伴う5件以上のリスク、段階的な実行計画と GTM 計画を提示してください。これにより、楽観論ではなく、追跡可能な根拠に基づいて go／no-go の判断ができるようにします。

必ず注意してください — 適用中のプロトコル（このスキルが引き継ぐ SYNC／共有ブロックの簡潔な要約）：

• AI の誤り防止： 生成した内容を根拠と照合し、下流の参照を追跡し、影響を受けるすべての出力を検証し、コンテキスト喪失後には読み直し、曖昧さを明示します。
• 批判的思考： 追跡可能な file:line の証拠を用い、確信度が80%を超える場合に実行します。事実として推測してはなりません。

重要：必ず注意してください すべての主張、財務数値、BMC ブロック、判定には、根拠と確信度（95／80／60／60未満）を付けてください。推測を事実として示してはなりません。理由：根拠のない数値があれば、go／no-go の判断は分析を装った楽観論になってしまいます。 重要：必ず注意してください 判定では懐疑的な姿勢を優先してください。楽観的な方向へ丸めてはなりません。成立しなければならない唯一の重要条件と、それが成立しなかった場合に残るリスクを明示してください。理由：根拠のない Pursue は資金を浪費しますが、正直な Pause ならその資金を守れます。 重要：必ず注意してください AskUserQuestion を使って、次のルートをユーザーに確認してください。domain-analysis／plan を自動で決定してはなりません。理由：このスキルが評価するのは実行可能性であり、go／no-go を決めるのは人間です。 必須・重要・必ず注意 作業を始める前に、TaskCreate を使って作業を小さなタスクに分割してください。常に 1 件を in_progress にし、証拠を添えて completed にしてください。最後にレビュー用のタスクを追加してください。理由：複数段階の作業を追跡しないと、コンテキストの圧縮時に状態が失われます。 必須・重要・必ず注意 市場データは market-analysis から取得し、根拠として使用してください。ここで市場規模を再算出してはいけません。理由：このスキルが評価するのは実現可能性であり、市場調査ではありません。市場規模の算出を重複させると、参照元と数値が一致しなくなります。 必須・重要・必ず注意 9 つの BMC ブロックすべてを含め、それぞれに根拠を示してください。財務上の数値にはすべて、前提条件と出典を前提条件表に記載してください。理由：ブロックの欠落や出典のない数値は見過ごされ、そのまま評価の土台となってしまいます。 必須・重要・必ず注意 リスクを最低 5 件挙げ、それぞれに軽減策と残存リスクの項目を設けてください。対象は市場・実行・財務・競争・規制・技術です。理由：残存リスクを記載しないリスク対策は、リスクを完全に解消したかのように見せてしまいます。 必須・重要・必ず注意 次の 7 ステップを順番どおりにすべて実行してください。アイデア → 市場データの読み込み → 9 ブロックの BMC → 3 年間の財務計画 → 5 件以上のリスク → 3 フェーズの実行計画（Validation／Build／Growth のマイルストーン）→ Go-to-market（ローンチ＋上位 3 チャネル＋価格設定の根拠）→ 評価。アイデアについて「感覚的に」結論が出たとしても、財務計画、実行計画、GTM を省略してはいけません。理由：評価の妥当性は、それを支える各ステップのうち最も弱いものに左右されます。 必須・重要・必ず注意 数値や主張を記載する前に、market-analysis の出力と過去の評価を検索し、類似パターンを 3 件以上確認して、根拠として引用してください。理由：類似事例を根拠としない数値は捏造です。 必須・重要・必ず注意 結果は、指定の .claude/templates/business-evaluation-template.md を使って docs/knowledge/strategy/business/{slug}.md に書き込んでください。構成を独自に作ってはいけません。理由：このテンプレートは、後続のスキル（domain-analysis／plan）が参照する契約です。 必須・重要・必ず注意 評価に時間がかかる場合は、中間調査結果を plans/reports/ に保存してください。理由：外部メモリがコンテキスト喪失後も残り、成果物として機能します。

非合理化の防止：

言い逃れ	反論
「このアイデアは明らかに有望だから、厳密な評価は省略しよう」	楽観論は根拠ではありません。9 ブロックすべて、財務計画、リスク評価を必ず実施してください。
「BMC ブロックを 1 つ省略しよう。関係ないから」	各ブロックには根拠を示すか、該当しない理由を明記してください。黙って省略すると、評価基準を満たしません。
「数値だけ先に見積もって、後で出典を付けよう」	前提条件と出典がなければ、数値を記載してはいけません。評価を出す前に、前提条件表を完成させてください。
「リスクを 5 件も挙げるのは多い。2 件で十分」	最低 5 件挙げ、それぞれに残存リスクを記載してください。リスクを薄く列挙すると、本当の下振れ要因が隠れてしまいます。
「推奨事項は明らかだから、確認は省略しよう」	次の進め方について、必ず AskUserQuestion で確認してください。Go／No-Go を決めるのは人間です。

重要・必ず注意 すべての数値に根拠と信頼度（％）を付けてください。推測を事実として提示してはいけません。重要・必ず注意 懐疑的な姿勢を優先し、楽観的な見積もりを上乗せしてはいけません。重要・必ず注意 次の進め方について AskUserQuestion で確認し、自動的に決定してはいけません。