Community研究&データ分析github.com

idea-check(アイデア検証)

製品やスタートアップのアイデアをエンドツーエンドで検証し、先行技術、隣接する既存企業、失敗した試み、購入者の経済性、コモディティ化の下限を網羅した、調査に基づくランドスケープレポートを返します。

idea-check(アイデア検証) とは?

idea-checkは、Claude CodeなどのAIエージェント上で動作するスキルで、ユーザーが「このアイデアはもうある?」「誰か作った?」「これって機能する?」といった質問をした際に、包括的な市場調査レポートを自動生成します。このスキルは、先行技術(競合製品、GitHubリポジトリ、特許、学術論文)、隣接する既存企業(機能として既に解決しているカテゴリ)、失敗例と経済性(シャットダウン、買収、撤退)、そしてコモディティ化の下限(無料またはバンドルされているもの)の4つの並列スレッドで調査を実行します。調査結果は3つの独立した評価者によって「オープン」「混雑」「飽和」のいずれかのラベルが付けられ、その一致・不一致も報告されます。最終的には詳細なレポートファイルと会話サマリーが出力され、ユーザーはアイデアの市場環境をエビデンスベースで把握できます。

対応✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/sakzgupzzz/idea-check/tree/HEAD

Installed? Explore more 研究&データ分析 skills: affaan-m/uspto-database, affaan-m/scholar-evaluation, affaan-m/literature-review · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

idea-check(アイデア検証) は何をしますか?

アイデアをエンドツーエンドで調査し、ランドスケープレポートを返してください。アイデアが成功するかどうかの判定は返さないでください。証拠と、そのアイデアが生き残る条件を返してください。

起動前

あなたが理解したアイデアを1段落で要約し、調査を開始することをユーザーに伝えてください。確認を待つ必要はありません。その要約はレポートにも含まれるため、ユーザーは誤読をその時点で修正できます。曖昧さによって調査すべき市場が変わる場合(例:「弁護士向けAI」は契約審査か訴訟調査かで異なる競合や失敗例がある)に限り、最初に1つだけ質問してください。

エンティティタイプを選択してください:ソフトウェア製品、ハードウェア製品、サービス、研究方向性、コンテンツ。これによって参照すべき情報源が変わります。ソフトウェアはパッケージレジストリとGitHub、ハードウェアは特許、サービスは地域市場と労働データ、研究は論文とプレプリントに依存します。

次に、過去の実行履歴を確認してください。スキルディレクトリ内の checks/ をリストし、主題が関連しそうなファイルのフロントマターを読んでください。以前のチェックが重複する領域をカバーしている場合は、その旨を先に伝え、ファイル名を明示した上で、新たに調査を実行するか、以前のレポートを拡張するかをユーザーと判断してください。既に実行したチェックを繰り返すことは、このワークフローで最も無駄な行為です。

スクラッチパッドにこの実行用のノートディレクトリを作成してください。各スレッドは調査結果をそこに書き込むため、統合処理はファイルから読み取り、長いサブエージェントの応答を覚えておく必要はありません。

4つのスレッド

汎用タイプのAgentツールを使い、1つのメッセージで4つのスレッドすべてを並列サブエージェントとして起動してください。各スレッドにはWeb検索とフェッチが必要です。この分割は固定です。独自の分割に置き換えたり、スレッドを統合したり、5つ目を追加したりしないでください。各スレッドの完全なプロンプトは references/thread-prompts.md にあります。そのファイルを読み、テンプレートをそのまま使い、アイデア、エンティティタイプ、ノートパスを適宜置き換えてください。

1. 先行技術

誰が既にこれを提供しているか。価格が公開されている商用製品、スター数・ライセンス・最終コミット日がわかるGitHubリポジトリ、学術研究、特許。各占有者について、アイデアとの近さとカバーしていない範囲を明記してください。ギャップのほうがリストよりも有益です。

2. 隣接する既存企業

どの既存カテゴリがこれを機能として既に解決しており、もし機能した場合に誰がそれを吸収するか。これは直接競合よりも重要です。この領域の製品は、新興企業との正面対決よりも、既存企業が上位機能としてバンドルすることで死ぬことのほうが多いのです。最も吸収する可能性の高い企業を明記してください。

3. 失敗例と経済性

ここで既に試みられて失敗したもの:シャットダウン、低価格での買収、ピボット、人員削減、隣接する上場企業の衰退。次に、購入者が誰か、実際にいくら支払っているか、そしてそのセグメントが支払えるかどうか。ビジネスケースに対しては敵対的になってください。競合を見つけるように指示されたスレッドは決して失敗例を見つけられません。これがこのスレッドが独立している理由です。

4. コモディティ化の下限

このうちどれだけが既に無料またはバンドルされているか:フロンティアモデルの能力、オープンソース、ユーザーが既に持っているサブスクリプション内の機能。有能なモデルとWeb検索で80%が無料でできるのであれば、その旨を述べ、残りの差分を明記してください。差分だけが販売可能なものです。

必須のサブエージェント指示

すべてのスレッドプロンプトに、このブロックを一字一句そのまま含めてください。テンプレートには既に含まれていますので、置き換え時に削除しないでください。

  • 「先行技術は存在すると仮定して探してください。あなたの仕事はこの領域を誰が占有しているかを見つけることであり、空であることを確認することではありません。誰が占有しているかを、率直に報告してください。」
  • 「何も見つからなかった場合は、「何も見つかりませんでした。これは存在しないことと同じではありません」と書き、何を確認しなかったかをリストしてください。」
  • 「すべての事実主張にはソースURLが必要です。」
  • 「AI生成のリスト記事、「ベストツール2026」まとめページ、プログラムによる価格サイト、シンジケート市場規模販売業者は、すべての事実主張から除外してください。破棄したソースを明記してください。このドメインの検索結果の約3分の1は、お互いについてSEO記事を書いているベンダーです。その量を調査結果として報告してください。ただし、引用はしないでください。」
  • 「すべての調査結果において、ベンダーの主張と独立した証拠を区別してください。」

このスキルにおいて最初の行が最も価値の高い行です。調査タスクを反証ではなく確証に向けてフレーミングすると、公表された測定値によれば結論が34~66パーセントポイントも変わります。そのため、このフレーミングはトーンの好みではなく、正確性の要件です。領域が空かどうかを確認するよう指示されたスレッドは、空だと報告します。

「何も見つかりませんでした」というフレーズは、ここでは証拠の不在が弱い証拠だからです。小規模な競合と倒産した企業はどちらもインデックスが不十分です。何を確認しなかったかをリストすることで、読者はその沈黙がどれほど意味するかを判断できます。

統合

4つのスレッドすべてが戻ったら、それらのノートファイルを読んでください。その後、2つのことを行います。

3回の独立したランドスケープ評価

ランドスケープに「オープン」「混雑」「飽和」のラベルを付けてください。そのラベルを独立して3回生成し、実際に独立していることを確認してください。3つの並列サブエージェントを起動し、それぞれに4つのノートファイルと以下のラベル定義のみを与え、1つのラベルと最大3文の推論を求めます。互いの出力やあなた自身の下書きを与えないでください。あなた自身のコンテキストでラベルを生成し、それを「再導出」しないでください。同じコンテキストでの2回目の読み取りは、最初の読み取りにアンカーされるからです。

各評価者に渡す定義:

  • オープン:占有者がアイデアの中核をカバーしていない。コモディティ化の下限が真の差分を残している。失敗例は空であるか、もはや当てはまらない理由で失敗している。
  • 混雑:複数の占有者がほとんどをカバーしている。楔(ウェッジ)は存在するが、既存企業が近い。経済性は狭められたセグメントでは plausible である。
  • 飽和:価格が公開された直接の占有者がいる、既存企業が既にバンドルしている、またはセグメントが支払えないことを示す失敗例がある。

3つのラベルすべてを報告し、不一致があれば示してください。平均を取らず、多数決で勝者を選ばないでください。読者が分割を見られるようにしてください。ベンチマークされた新規性の判定は、プロンプトの言い換えだけで93.5%から40.9%の精度に変動し、3回投票は12倍のコストがかかる専用のシングルパスツールよりも優れていました。評価間の不一致は、レポートの中で最も情報量の多い行です。

批評家レイヤーは不要

統合の上に批評家、レッドチーム、ディベートエージェントを追加しないでください。発表された結果によると、マルチエージェントディベートは単一の強力なパスに劣り、テストされたほとんどの設定で精度を低下させます。ノートファイルからの1つの注意深い統合が、委員会よりも優れています。

出力

3つの出力先を、この順序で出力してください。ファイルが成果物であり、会話にはサマリーのみが含まれます。

1. レポートファイル(常に)

完全なレポートをスキルディレクトリの checks/YYYY-MM-DD-<slug>.md に書き込んでください。<slug> はアイデアの短いケバブケース名です。checks/ が存在しない場合は作成してください。ファイルの先頭にYAMLフロントマターを付けて、後続の実行がレポート全体を読まなくても照合できるようにします。

---
idea: アイデアの1行説明
slug: ケバブケース名
date: YYYY-MM-DD
label: Open | Crowded | Saturated
label_reads: [read1, read2, read3]
top_occupants: [name1, name2, name3]
---

3回の評価が一致しない場合は、label を最も頻出のもの、または3つすべてが異なる場合は Split に設定してください。フロントマターはルックアップキーであり、本文で不一致が示されます。

本文:マークダウン、1200語未満。デフォルトは散文で、真に比較が必要な場合(例:価格が異なる複数の占有者)にのみ表を使用してください。emダッシュは使用しないでください。セクションはこの順序で、以下の見出しを使用してください。

  1. 理解したアイデア。 1段落。ユーザーが最初に確認します。
  2. 既にそこにいる人たち。 名前、URL、公開価格、アイデアへの近さを明記。ベンダーの主張はその旨を明示。
  3. 失敗例。 何が失敗し、なぜか。
  4. 経済性。 誰が、いくら払うか、そしてそのセグメントが支払えるか。
  5. コモディティ化の下限。 既に無料またはバンドルされているもの。
  6. ランドスケープラベル。 3回の評価すべてと、不一致があれば示す。
  7. 真実である必要があること。 アイデアが生き残るための具体的な条件と、それぞれを解決する証拠。調査ですでに反証された条件はその旨を明示。
  8. ソースと破棄したソース。 引用されたすべてのURL、次に4つのスレッドすべてから破棄したソースとその理由を一言で。

2. 会話サマリー(常に)

最大150語で出力:ランドスケープラベルと3回の評価が一致したかどうか、最も近い2~3の占有者、最も決定的な調査結果1つ、レポートファイルへのパス。誰もターミナルで1200語は読みません。

3. 共有可能なページ(利用可能な場合のみ)

セッションにアーティファクトやページを公開するツールが存在する場合は、レポートをページとして公開し、リンクをユーザーに提供してください。これはオプションとして扱ってください。実行を失敗させず、ファイルやサマリーを決して保留しないでください。このツールがない場合が多いからです。このスキルは通常Claude Codeセッションにインストールされますが、そのセッションではツールがないことがよくあります。

既知の制限

該当する場合はレポートに記載してください。

  • 証拠の不在はここでは弱い証拠です。小規模な競合と倒産した企業はどちらもインデックスが不十分です。
  • エンタープライズツールの価格は通常、営業ゲートがあり、入手できません。
  • 検索結果の量は市場規模の証拠ではありません。その多くはベンダーが互いについて書いたものです。
  • このレポートは領域が占有されているかどうかを示します。このユーザーが勝てるかどうかは示しません。それは調査では見えない情報に依存します。

関連スキル