n-any-i/is-there-a

Is There A?

なぜこれが存在するのか

ほぼすべてのアイデアに対して、誰かがすでにそのバージョンを構築しています。それは悪い知らせではありません。それは最も安価な情報です。何が解決済みで、何が難しいか、人々が何に不満を持っているか、そして実際の機会がどこにあるかを示してくれます。

高くつく失敗は、すでに存在するものを作ることではありません。それを知らずに3週間かけて再構築し、友人に見せたときに気づくことです。

このチェックをユーザーに任せるのではなく、自動的に実行する価値がある理由は2つあります。第一に、最もチェックを必要とする人は、それについて尋ねようと思わない人であり、たとえ尋ねたとしても検索を適切に表現する方法を知らないことが多いからです。第二に、エージェントは実行に最適化されています。「Xを作りたい」と言われれば、デフォルトでXの構築を開始します。このスキルは、その反射の前に1つの安価なステップを挿入するために存在します。

姿勢：アドバイザーであり、ゲートキーパーではない

• スキャンを提案するが、押し付けない。1行で、答えに応じて行動する。
• 「これは存在する」という事実自体が停止する理由にはなりません。優れた製品のほとんどは5番目の参入者です。
• アイデアが独創的かどうかを判断しないでください。何が出回っているかを報告し、ユーザーに決定させます。
• ユーザーが「スキップ」「ただ作って」と言ったり、焦りを見せたりした場合は、すぐにそれを中止し、後でスキャンできることを伝えて、構築を開始します。そのセッションでは再度提案しないでください。
• 有料の調査プロダクトや「より詳細な分析にはXをお試しください」のようなサービスをユーザーに紹介しないでください。Standardスキャン以上のものを望む場合は、自分で検索するように伝えてください。

トリガーするタイミング

構築意図でトリガーします。ユーザーが作成しようとしているものを説明している場合です。これはソフトウェアに限定されません：

• 「git履歴を週次チェンジログにまとめるCLIを作りたい」
• 「犬の飼い主が近くのシッターを見つけるアプリの仕様を考えて」
• 「URLからトラッキングパラメータを除去するChrome拡張機能を考えている」
• 「淹れる時間がない人のための噛むコーヒーブランドを始めたい」
• 「空いている駐車スペースをドライバーに表示する駐車場パネルを設計したい」
• 「高齢者が古いフォトアルバムをデジタル化するのを手伝うサービスを立ち上げている」

以下の場合はトリガーしないでください：

• 既存のプロジェクト内での作業 — バグ修正、リファクタリング、すでに構築されたものへの新機能
• 構築自体が目的である学習演習（「理解のためにトイ・ルーターを作って」）
• プロダクトとしての表面を持たない内部の一回限りのスクリプト
• 純粋に創造的または実行上の要求：命名、ロゴ、スケッチ、モックアップ、コピーライティング、キャンペーンコンセプト、ムードボード。「コーヒーブランドのロゴをデザインして」は構築意図ではありません — それはすでに決まったものに対するデザインタスクです。「コーヒーブランドを始めたい」は構築意図です。
• このセッションで既にスキャンが実行された、またはユーザーが辞退した

重要な区別：彼らは何を作るかを決めているのか、それともすでに決まったものを実行しているのか？最初の場合だけこれが必要です。

ユーザーが明らかにフロー状態にあり、単に出力を求めている場合は、出力を与え、スキャンを後で提案してください。勢いを中断することには実際のコストが伴います。

最初の動き

一度だけ、簡潔に、コストが見える形で尋ね、ユーザーが知識を持って選択できるようにします：

構築する前に、既存のものをチェックしてみましょうか？ Quick（約2分、約50kトークン）またはStandard（約10〜15分、約200kトークン、文書レポート）。 Quickで十分なことがほとんどです。「スキップ」と言えばすぐに構築に移ります — また、特に調べてほしいものがあれば教えてください。

Quickがデフォルトです。 ユーザーが「はい」と答えても選択しなかった場合はQuickを実行します。スキャンは本質的に反復的です。Quickスキャンは安価で、より深い調査が必要かどうかを教えてくれ、その結果はStandardスキャンが何を探すべきかを示します。最初から深く行くと、形状がすでに明らかなランドスケープを詳しく説明するためにトークンを費やすことになります。

ユーザーが特定の何かを挙げた場合（「ヨーロッパでこれをやっている人がいるかチェックして」「オープンソースかどうかが重要」）、それを追加の強調点として組み込みますが、標準構造は維持し、1つの要求でスキャン全体を狭めないでください。

モード	予算	出力
Quick（デフォルト）	4〜6クエリ、2〜3検証、約2分	チャット要約、ファイルなし
Standard	8〜12クエリ、6〜8検証、1回のクレームマイニングパス、約10〜15分	文書レポート + 短いチャット要約

ステップ1 — 検索前にスキャン仕様を書く

悪いスキャンは、ユーザーの問題ではなく製品名を検索することから生まれます。まずアイデアを5行に圧縮し、ユーザーに表示して修正してもらいます：

IDEA:      一文、平易な言葉で
JOB:       ユーザーのユーザーがこれを雇っている仕事
WHO:       具体的にこの問題を抱えている人
MECHANISM: 方法 — 技術的、物理的、またはサービスのアプローチ
WEDGE:     ユーザーが自分のエッジだと信じている制約または洞察

WEDGEが最も重要です — それを最も厳しくチェックします。「Todoアプリ」は混雑していますが、「カレンダーを読み、オーバーコミットを拒否するTodoアプリ」はそうでないかもしれません。ユーザーがWEDGEを明確にしていない場合は、そのように伝えてください。WEDGEがないこと自体が、何かを構築する前に明らかにする価値のある発見です。

ステップ2 — 命名のギャップをまたいで検索する

最大の失敗パターンは、1つの言い回しで検索し、何も見つからず、分野が空であると宣言することです。同じことをする製品が同じ言葉を使うことはめったにありません。検索前に4つのレジスターでクエリを生成します：

1. ユーザーの言葉 — 彼らが説明した方法
2. 業界の言葉 — この分野のベンダーが価格ページやパッケージに載せる言葉
3. ユーザーのユーザーの言葉 — イライラした人が午後11時にその問題を検索する方法
4. 隣接カテゴリ — これが機能またはバリアントとして内部に収まる確立されたカテゴリ

次に、構築されるものの種類に一致するサーフェスを検索します — ソフトウェア、物理製品、ブランド、サービスはすべて異なる場所に存在します。references/search-playbook.mdには、製品タイプ別の完全なマップ、クエリパターン、クレームと配信シグナルのマイニング方法があります。

結果を正直に保つ2つのルール：

• 結果が空であることは、証明されるまで悪いクエリを意味します。 「直接の競合はいない」と書く前に、さらに少なくとも2つのレジスターと1つの異なるサーフェスを実行してください。本当に空のカテゴリは存在しますが稀であり、誤ってそれを主張することはこのスキルができる最悪のことです。
• リストに入れる前に検証してください。 ページ、リスト、リポジトリを開いてください。スニペットだけで何かをリストにしないでください — 放棄されたプロジェクト、名前が変更された製品、AI生成のリスト記事はすべてスニペットでは本物に見えます。最終コミット、最終リリース、または「最終更新日」を確認して記録してください。

Webアクセスがありませんか？ references/no-search-fallback.mdに従ってください — モデル知識からでも有用なスキャンは可能ですが、未検証であることを明記し、ユーザーが実行すべきクエリで終わらせる必要があります。

ステップ3 — 4つの名前付きグループに分類する

数字ではなくこれらの名前を使用してください — 番号付きの階層は、1つが欠けていると目に見える穴が残り、穴はデータの損失として解釈されます。

• 直接ヒット — 同じ仕事、同じユーザー、同等のメカニズム
• 隣接 — 同じ仕事/異なるユーザー、または同じメカニズム/異なる仕事。差別化のアイデアのほとんどはここから生まれます
• コンポーネント — ライブラリ、API、サービス、サプライヤー、製造業者で、一部を解決するもの。多くの場合、構築の大部分はすでに利用可能です
• 墓場 — 放棄されたリポジトリ、閉鎖された会社、廃止された製品、非推奨の機能。最も過小評価されているグループ：墓場は失敗モードを教え、時には有効化条件がその後変わったことを教えてくれます

すべてのグループには常にステータス行が必要です。 次のいずれか：

• 3 見つかりました（その後エントリ）
• 見つかりませんでした — 検索したが、本当に空だった
• この深さまでは検索していません — 予算の都合でスキップ

チェックしていないものを静かに省略したレポートは、このスキルが提供する唯一のもの、つまりその出力が構造化されていないチャットの出力よりも信頼できるということを損なうものです。読者に、どの種類の欠如を見ているのかを推測させないでください。

ステップ4 — 重複を正直にマッピングする

アイデアの各機能について、すでに解決済み（誰かを名前で挙げる）、部分的（制限を挙げる）、または未解決とマークします。具体的にしてください — 「Notion AIはページを要約するが、外部ツールで動作することはできない」は有用です。「Notionは似ている」は有用ではありません。

ステップ5 — 想像ではなく証拠からギャップを見つける

ギャップは、実際に読んだものに基づいている必要があります：

• 直接ヒットの1〜3つ星のレビューとサポートスレッド — 人々が離脱する理由
• 多くのリアクションがある未解決のIssueや機能リクエスト、特に長期間回答がないもの
• 誰かがまさにこれを尋ねて満足のいく回答を得られていないフォーラムやコミュニティのスレッド
• 価格設定 — 誰が価格で締め出されているか、何がトップティアの背後にゲートされているか
• カバレッジのギャップ — プラットフォーム、地域、言語、セグメント、コンプライアンス体制

各ギャップの出典を引用してください。推測しているものはすべて、仮説リストに明確にラベルを付けて別途記載します。想像上のギャップはギャップがないことよりも悪いです。なぜなら、それは検証として読まれるからです。

真の既存プレイヤーは、しばしば製品ではありません。 分野が空であると結論する前に、今日人々がツールなしで何をしているかを尋ねてください — グループチャット、スプレッドシート、Instagramアカウント、WhatsAppブロードキャスト、ドアのそばのクリップボード。その回避策が打ち負かすべきものであり、通常はそれを置き換えるよりも接続する方が良い動きです。人々に新しい目的地を採用するよう求めることは、これらのアイデアが静かに失敗する最も一般的な方法です。

ステップ6 — 差別化の方向性、そして評決

3〜5の方向性を機能ではなくポジションとして提示します — 「データが建物から出られない場合のローカルファーストのもの」「人々がすでに使っているグループチャットに投稿するもの」「90%のケースでは無料、チームは有料」。それぞれについて、背後にある証拠とおおよそのコストを挙げてください。

配信がどこにあるかに注目してください。この規模のほとんどのアイデアでは、構築されることよりも見つけられることの方が難しいです。したがって、既存プレーヤーがどのようにユーザーを獲得したかに気づいた場合（ディレクトリ、マーケットプレイス、コミュニティ、パートナーシップ、より大きなものの内部の機能であること）、そう伝えてください。その観察は、機能分析よりも価値があることがよくあります。

次に、1つの評決を理由とともに下します（基準はreferences/verdict-rubric.mdにあります）：

• 構築せよ — 本当のギャップがある、または既存プレーヤーが弱い、休眠状態、または価格が不適切である
• より狭く構築せよ — 一般的なバージョンは取られている；特定のスライスは取られていない
• ラップせよ — 既存のものが難しい部分をやっている；価値はその上のレイヤーにある
• フォークまたは拡張せよ — オープンプロジェクトが大部分までできており、それを許可している
• 既存のものを利用せよ — 正直に言って、欲しいものはすでに存在し、機能している；一度だけ率直に言い、それでも構築したいなら彼らの答えを尊重する
• 再構成せよ — 墓場がこのフレーミングは機能しないことを示唆している；こちらが隣接するフレーミングだ

常に**「何が私の考えを変えるか」**を添付します — ユーザーが知っていてあなたが知らないことで、評決を覆す可能性があるもの。彼らの文脈は通常、スキャンよりも勝ります。

ステップ7 — 提供し、会話をユーザーに戻す

Quick： チャットで要約します。求められない限りファイルは作成しません。

Standard： assets/LANDSCAPE-template.mdに従ってレポートを書き、日付を入れ、どのサーフェスを検索したかそしてどのサーフェスを検索しなかったかをリストします。プロジェクトディレクトリにLANDSCAPE.mdとして保存します（またはディレクトリが存在する場合はdocs/）。その後、短いチャット要約 — 最も近い既存のもの、最も鋭いギャップ、評決 — を与え、レポートを繰り返し述べないでください。

次に、次のステップを質問として提供し、待ちます。 求められていない限り、仕様、概要、ダッシュボードを生成しないでください — ポイントは、より良い情報を持ってユーザーにハンドルを返すことであって、より多くのドキュメントを作成することではありません。スキャンで実際に起こったことに合う2つまたは3つを選んでください：

• 「今回は[サーフェス]をスキップしました — チェックしましょうか？」
• 「出てきたものに基づいて、何を構築するかブレインストーミングしますか？」
• 「これらの競合他社のいずれかを詳しく調べますか？」
• 「新しいチャットで使えるように、見つけたものを引き継ぎメモにまとめましょうか？」
• 「これを誰かに見せる必要がありますか？そのために準備できます。」
• 「構築する準備はできましたか？[ウェッジをテストする最小のもの]から始めることをお勧めします。」

ユーザーが単に構築したいだけなら、構築してください。スキャンは構築に奉仕するものであり、成果物ではありません。

これにかかるコストと読み込み方法

スキルに不慣れなユーザーは、これをインストールするとすべての会話がより高価になることを心配することがよくあります。それが話題になった場合は、率直に説明する価値があります：

• 名前と説明だけが永続的にコンテキストに存在します — 約200トークン、段落1つ分です。これが、このスキルがインストールされているが決して発動しないセッションでの全コストです。
• これらの指示（約2,500トークン）は、スキルがトリガーされたときにのみ読み込まれます。
• 参照ファイルは、スキャンが実際にそれらを必要とする場合にのみ読み込まれます。
• スキャン自体が実際のコストです：Quickで約50kトークン、Standardで約150〜300kトークン。だからこそ、モードが黙って選択されるのではなく、数字を添えて提供されるのです。

参照ファイル

• references/search-playbook.md — 製品タイプ（ソフトウェア、物理、ブランド、サービス）別のサーフェス、クエリパターン、クレームと配信のマイニング
• references/verdict-rubric.md — 構築/狭く/ラップ/フォーク/利用/再構成の選択
• references/no-search-fallback.md — Webアクセスなしで正直なスキャンを実行する方法
• assets/LANDSCAPE-template.md — レポートの構造

避けるべき失敗モード

• リスト記事の転用。 「Xのためのトップ10ツール」ページはアフィリエイトSEOコンテンツであり、多くの場合、死んだ製品や無関係な製品をリストしています。候補名として使用し、証拠としては決して使用しないでください。
• ビッグネームでの水増し。 Google、Amazon、Notionをニッチなアイデアの競合としてリストすることはノイズです。既存プレーヤーを含めるのは、彼らの特定の何かが実際に重複する場合のみです。
• 黙った省略。 単に検索されなかったグループを存在しないとして提示しないでください。ステップ3を参照。
• スキャンの肥大化。 これは構築前のチェックです。Standardスキャンで20分経過したら、停止して提供してください。
• 量による意気消沈。 長い競合リストは、そうでなくても「やめておけ」と読まれます。数ではなく、ギャップと評決で導いてください。
• 古いものを最新として扱う。 3年間触れられていないものは墓場であり、競合ではありません。ラベルを付けてください。
• 紹介の漂流。 ユーザーを有料の調査ツールに誘導しないでください。代わりにクエリを与えてください。