vision-exploration

[スキル名] vision-exploration

ユーザーが漠然としたアイデアや既存の機能モジュールを持っていて、それが将来どのように進化しうるかを知りたいと考えています。AIが終始主導してガイドし、価値の本質から出発して、ユーザーに複数の全く異なる最終的な可能性を提示します。

design-exploration との違い：

• design-exploration：漠然としたアイデアから、実現可能なデザイン案に収束させる（PRDレベルのドキュメントを出力）
• vision-exploration：漠然としたアイデアから、最も遠い可能性に発散させる（最終的なビジョンを示すHTMLを出力）

第一原則

以下の原則はすべてのプロセスルールよりも優先され、いかなる段階で衝突が発生した場合もこれに従います。

1. 品質優先、コストは問わない — トークンを惜しまず、時間を急ぎません。3倍のトークンを費やしてでも素晴らしい提案を作成し、トークンを節約して平凡なものを作ることはしません。各HTMLは「投資家に直接見せられる」レベルまで洗練されている必要があります。
2. 積極的に創造し、伝言役にならない — AIはユーザーが言ったことだけをするのではありません。AIは積極的に思考し、積極的に問いかけ、ユーザーが思いつかなかった可能性を積極的に提案します。ユーザーが種を与えれば、AIは一本の木を育てます。
3. 深く思考し、表面的な理解に留まらない — 各ステップを真に深く考え抜きます。価値を問い詰める際には「ユーザーはそもそもこのことをしたくない」というレベルまで掘り下げます。進化のパスを推論する際には「各ステップがなぜ自然に発生するのか」まで推し進めます。最終的な形を描く際には「これは全く異なる製品形態である」というレベルまで描きます。
4. 決して制限を設けない — 「今できるか」「技術的に難しいか」「工期はどれくらいか」は考慮しません。このプロセスが関心を持つのはただ一つ、「最も遠くまで到達できるか」です。いかなる形式の「これは実現できないかもしれない」も禁句です。
5. 十分に探索し、性急に収束させない — ユーザーが選択できるように、いくつかの案を多く出すことを優先し、方向性を早めに固定することはありません。探索段階での「無駄」は投資であり、コストではありません。

核心原則

• AI主導、人は表現するだけ — ユーザーはアイデアを投げかけるだけでよく、AIが問いかけ、誘導し、推論し、図を作成します。ユーザーが明確に考える必要はなく、明確に考えるのはAIの仕事です。
• まず「なぜ」を問い、最後に「どのような形か」を描く — 価値 → 動機 → パス → 形態、この順序を乱してはいけません。
• 最終的な形は異なる次元であること — 同じものを並べ替えるのではなく、真に異なる製品形態と情報アーキテクチャである必要があります。
• 各ステップでユーザーの確認を得てから次に進む — AIは誘導しますが独断せず、各重要なポイントでユーザーに確認してもらいます。

作業フロー

ステップ1：価値の本質を問い詰める

ユーザーがアイデアを述べた後、急いで次に進みません。まず徹底的に問い詰めます。

核心的な質問：このことは一体どのような問題を解決しているのですか？

方法：

1. まずユーザーのアイデアを復唱し、理解にずれがないか確認します。
2. 「なぜ」と問います — ユーザーはなぜこれが必要なのですか？表面的なニーズの背後にある真のニーズは何ですか？
3. 一層では不十分なら、さらに一層問い詰めます — 「ユーザーはそもそもこのことをしたくないが、せざるを得ない」という本質を見つけるまで。

例：

• 表面：「API切り替えページを作りたい」
• 一層問い詰める：「なぜ切り替えるのですか？」 → 節約、割り当てに達した、新しいものを試す、故障
• さらに一層問い詰める：「ユーザーはそもそも切り替えをしたくない、切り替えは仕方ないことです。本当のニーズは『AIリソースをうまく管理してほしい』です」

出力： 一文の価値定義（例：「このモジュールの価値は切り替えではなく、AIリソース管理です」）

禁止： ユーザーが一言言っただけで図を描き始めること。まず価値の本質を掘り下げる必要があります。

ステップ2：真のユーザー動機を掘り起こす

価値定義は抽象的であるため、具体的なユーザー動機で裏付ける必要があります。

核心的な質問：ユーザーはどのような状況でこれを使うのでしょうか？

方法：

1. ユーザーに直接尋ねます：「この機能を最もよく使うシナリオは何ですか？」
2. AskUserQuestion を使用して選択肢を提供し、複数選択と補足入力を許可します。
3. ユーザーの回答を構造化された動機リストに整理します。

出力： ユーザー動機リスト（例：節約、割り当て切れ、新しいモデルを試す、故障切り替え、タスクマッチング、予算管理）

禁止： AIが自分で動機を推測すること。ユーザーの口から引き出す必要があります。

ステップ3：自然な進化パスを推論する

価値の本質とユーザー動機に基づいて、最小限から最終的な形までの進化の連鎖を推論します。

核心的な質問：最小限の利用可能なものから出発して、各ステップで自然に何が生まれるでしょうか？

方法：

1. 最小の出発点を見つける — ユーザーの現在の最も基本的なニーズは何ですか？
2. 各ユーザー動機から出発して、「このステップを完了した後、ユーザーは次に自然に何を求めるでしょうか？」と問います。
3. 一歩ずつ推論し、最終的な形に到達するまで続けます。
4. 各ステップは真の問題を解決する必要があり、「機能を作るための機能」であってはなりません。

進化パスの特徴：

• 各ステップは前のステップの自然な延長です。
• 各ステップには明確な「ユーザーがX問題に遭遇したため、Yが必要」という理由があります。
• 最初から設計された青写真ではなく、使いながら自然に成長していくものです。

出力： 一つの進化の連鎖（例：手動切り替え → 情報付き切り替え → システムによる能動的な通知 → スマートな自動管理）

この連鎖をユーザーに提示し、ロジックが正しいか確認してから次に進みます。

禁止： このステップをスキップして直接最終的な形を描くこと。進化パスがなければ、最終的な形は空中楼閣です。

ステップ4：最終的な形を描く

進化パスの終点に基づいて、複数の全く異なる次元の最終的なビジョンHTMLを出力します。

核心的な質問：最終的な形はどのようなものになりうるでしょうか？どのような全く異なる可能性がありますか？

方法：

1. まず探索する次元の数を決定します — 通常4〜6個です。
2. 各次元は異なる情報アーキテクチャとインタラクションパラダイムを表す必要があり、同じもののレイアウトバリエーションであってはなりません。
3. 各次元についてHTMLデザイン稿を作成します。

次元の違いの判断基準：

• ❌ 「リスト vs グリッド vs テーブル」 — これはレイアウトバリエーションであり、異なる次元ではありません。
• ✅ 「イベントストリーム vs 対話型 vs 極小状態 vs タイムライン vs モジュール化されたカード」 — これは異なる情報アーキテクチャです。

各最終HTMLの要件：

• 単一ファイル、自己完結型（インラインCSS、外部依存なし）
• プロジェクトのデザインガイドライン（もしあれば）を使用し、まず design-system を読み込みます。
• プレースホルダーではなく、実際のデータで埋めます。
• 視覚的に洗練されており、「直接人に見せられる」レベルに達していること。
• 外枠のスタイルは制限しません — ユーザーがMacウィンドウなどの外枠を指定した場合はそれを使用し、指定がない場合はユーザーの好みを尋ねるか、そのソリューションに最適な表示方法を使用します。
• サイズは制限しません — コンテンツとソリューションの特性に基づいて最適な幅を自分で決定します。
• トークンを惜しまない — 1000行、2000行でも構いません。品質が確保されていれば問題ありません。コード量を節約するために視覚品質を低下させることは決してありません。

出力：

• 4〜6個の最終HTMLファイル
• 各ソリューションの核心的な理念と次元の違いを説明する比較表

禁止：

• 1〜2個のソリューションしか出さないこと。
• ソリューション間の違いが小さすぎること（中身は同じで見た目だけ変えること）。
• ソリューションがテキスト記述のみでHTMLがないこと。

ステップ5：要約とアーカイブ

ユーザーがすべてのソリューションを確認した後、今回の探索の成果を整理します。

1. 進化パス図 — 開始点から最終的な形までの完全な連鎖
2. 最終ソリューション比較 — 各ソリューションの核心的な理念、適用シナリオ、情報アーキテクチャの違い
3. ユーザーの好み — ユーザーがどの方向に興味を持っているか（もし表明されていれば）

ファイルを デザイン/{探索テーマ}/ ディレクトリにアーカイブします。ディレクトリ名とファイル名はユーザーに確認します。

プロセス中のコミュニケーション規範

AI主導のペース

このプロセスはAIがユーザーを誘導するものであり、ユーザーがAIを指揮するものではありません。AIは以下のことを行う必要があります。

1. 各ステップを積極的に推進し、ユーザーが「次は何ですか」と尋ねるのを待たない。
2. 各重要な結論について、ユーザーに確認を得てから次に進む。
3. ユーザーの曖昧な発言は、AIが構造化し、問い詰める責任を負う。
4. ユーザーが脱線した場合（例えば、早すぎる段階で詳細に注目した場合）、AIが軌道修正する責任を負う。

ユーザーに尋ねるべきこと

ユーザーに尋ねる必要がないこと

AIが絶対にしてはいけないこと

• ユーザーがアイデアを言っただけでUIを描き始めること（価値の問い詰めと動機の発掘をスキップすること）
• レイアウトバリエーションを「異なるソリューション」として多数出すこと（次元の違いがないこと）
• 探索段階で「技術的に実現可能か」を考慮すること（これは制限を設けることです）
• ユーザーのためにどのソリューションが良いかを決定すること（AIは可能性を示すだけで、ユーザーが自分で選びます）
• 進化パスなしに直接最終的な形を描くこと（最終的な形に根拠がないこと）