generating-novel-ideas

有用で差別化されたアイデアを生み出す

同じ仕組みに別の名前を付けるのではなく、異なる仕組みを探してください。類推の転用、矛盾の解決、多様な視点、批評と改善を維持してください。プロセスの規模は依頼に合わせて調整してください。名前をいくつか考えるだけなら、製品戦略全体は必要ありません。また、推奨案を1つ求められているなら、回答に複数案を並べる必要はありません。

機会を見極める

提示された目標、対象者、制約、資産、既存のコンセプトを活用してください。重要な前提を明示し、入手可能な根拠をもとに、結果を左右する情報の不足を解消してください。命名や小規模な創作タスクをより大きな演習に発展させられるというだけの理由で、合意済みの製品概要を再検討しないでください。

ユーザーが実際に達成したいことと、両立が難しい要素を特定してください。たとえば、注意を払う量を減らしながら、より多くの制御を得ることや、データ開示を抑えながら、より高い確信を得ることです。既知の技術面、法務面、予算面、安全面の制約を、最初から明確に示してください。すでに実現可能性を否定する事実があるなら、アイデア出しを理由にその確認を先延ばしにしないでください。

収束の前に発想する

大規模なタスクでは、仕組み、ユーザーが利用するタイミング、導入経路、所有権、または構想の大きさが異なる複数の探索方向を用いてください。最初の段階では各コンセプトを短くまとめ、初回の案が出そろうまで相互比較は後回しにしてください。実用性重視または新規性重視の視点は、有用な場合に限りLENSES.mdから選んでください。

同じ会話内で行う複数の検討は、互いに独立した盲検サンプルではありません。本当に分離されたエージェントコンテキストを利用でき、それが適切な場合は、各エージェントに同じ概要と異なる探索方向を渡し、他の出力は見せないでください。それ以外の場合は、作業を別々の視点または検討回として説明し、エージェントの存在、独立性、実験、未確認の結果を捏造しないでください。

遠い領域から類推する場合は、表面的なスタイルではなく仕組みを転用してください。その仕組みが新しい領域で機能するために必要な条件を説明してください。作業の順序、所有権、可逆性、または作業の割り振りを変えることで、相反する要素を調整してください。トレードオフなしにあらゆる側面の改善を約束しないでください。

仕組みを比較し、改善する

生のコンセプトを、実際にどのような要因がメリットを生むかに基づいて分類してください。見せかけの重複案と、見落としている有用な方向性を特定してから、案を磨いてください。AI、マーケットプレイス、またはサブスクリプションの仕組みは、名称がありふれているというだけで正当な候補から除外しないでください。具体的な役割、優位性、実現可能な導入経路があることを求めてください。

有望な候補については、うまくいく可能性を最も強く裏付ける理由、最も重大な反論、改善策を示してください。改善によってメリットが失われたり、制約に反したりする候補は除外してください。評価基準は判断の補助であり、新規性や商業的成功を数値で証明するものではありません。

推奨案の根拠を示す

現在の市場、技術、文化、規制に関する主張を行う前に、適切で最新の情報源を確認してください。最も近い代替案を特定し、実際の違いを説明してください。限定的な調査で該当例が見つからなくても、世界的な新規性、特許取得可能性、名称の使用可否、または実施の自由が立証されたことにはなりません。独自性が重要な場合は、調査範囲と残る不確実性を報告してください。

研究のアイデアでは、確立された根拠と提案する仕組みを分け、測定項目と交絡要因を特定し、結果を見分けられる初回実験を具体的に示してください。製品では、最初のユーザーや利用状況についての前提と、導入に関する前提を明示してください。ドメイン別モードを使えば、テンプレートを一律に押し付けずに確認項目を調整できます。

重要な前提を否定できる、倫理的で低コストなテストを選んでください。どのような観察結果をもって判断を変えるのかを定義してください。インタビューは購入行動の証明ではありません。ウェイトリストは収益ではありません。偽の購入導線やコンシェルジュ型テストでは、期待される内容を正直に伝え、適切な同意を得たうえで、許可なく課金したり、誤解を招く主張をしたりしないでください。

任意の語彙チェック

SKILL_DIR を、このインストール済みディレクトリに解決します。

python "$SKILL_DIR/scripts/diversity_audit.py" ideas.json

入力は、文字列または name と concept／description を含むオブジェクトの JSON 配列、あるいはテキスト行ごとに 1 つのアイデアです。このヘルパーが受け付けるアイデアは最大 200 個、各フィールドは最大 2,000 文字、入力全体は最大 1 MiB です。候補となるトークン重複ペアと novelty: NOT_ASSESSED を含む JSON を返します。名前は類似度に影響しません。仕組みの同等性を推測したり、どのアイデアを破棄するかを決めたりすることはありません。似た表現でも仕組みが異なる場合があり、言い換えによって同じ仕組みが見えにくくなる場合もあります。以前の寛容な入力変換と、必須の再生成プロンプトは削除されました。

役立つ結果を届ける

依頼された形式に従い、最も有力なコンセプトまたは推奨案から示します。ユーザーが評価できるよう、仕組み、期待される効果、実践的な導入方法、主なリスク、次に行うべきテストを十分に含めます。探索的なポートフォリオでは、意味のある多様性を保ちます。品質にかかわらず、安全な案、中程度の案、大胆な案を 1 つずつ無理にそろえることはしません。依頼された成果物に役立つ場合に限り、検索の過程をそのまま示します。

差別化は自然に説明します。すべてのコンセプトを同じ「これは単なる X ではありません」という文に無理に当てはめたり、割り当てを満たすためだけに目新しく聞こえるひねりを作り出したりしないでください。改善の範囲がより限定的であること、仮説が未解決であること、あるいは制約を満たす候補がまだないことを、正直に伝える場合もあります。

メンテナー向け：語彙ヘルパーのテストには python -m unittest discover -s "$SKILL_DIR/tests" -v を実行してください。検証ケース には、別途エージェントのトレースレビューが必要です。パーサーテストに合格しても、生成されたアイデアが改善された証拠にはなりません。埋め込み配布用 ZIP はソースパッケージから削除されています。以前の成果物には Git の履歴を使用し、新しいリリースのパッケージ化はアクティブなスキルディレクトリの外で行ってください。