Product
開発者はたいてい、何を作るかを正確に分かっています。詰まるのは理解ではなく、伝達です。
Cursor や Windsurf で UI を磨いているとき、直したい点は明確です。このシャドウは 2px ぼかしを足す、この余白は 4px 詰める、この hover は少し持ち上げる。必要な CSS も、設計意図も分かっている。
でもそれを全部タイプで説明するのが重い。どの要素か、どこにあるか、周辺文脈は何か。時間はそこに消えます。
Architect mode はその摩擦を消すために作りました。
問題: 文脈は打鍵コストが高い
典型例として、ボタンの見た目の重みを調整するケースを考えます。
Architect mode がないと、次のように書くことになります。
"冒頭のセクションに 'Get Started' と書かれた主要ボタンがあります。今は影が薄いので、もう少し強く、0 4px 12px rgba(0,0,0,0.15) くらいに。カーソルを乗せたときは translateY(-1px) で軽く持ち上がる動きも…"
2秒で指せる内容のために、60語以上使ってしまう。
解決: 指す、話す、実行する
Architect mode はスクリーンキャプチャと音声入力を組み合わせます。
- Option をダブルタップ -> オーバーレイ表示
- 対象を囲む（「どのボタン？」の曖昧さが消える）
- 意図を話す: "影を強め、カーソルを乗せると軽く浮上、200ms で滑らかに"
- Option を再度ダブルタップ -> 構造化 spec を生成
出力はそのまま実装可能です。
"Update the primary CTA button in the hero section: > - box-shadow: 0 4px 12px rgba(0,0,0,0.15) > - hover: translateY(-1px), box-shadow: 0 6px 16px rgba(0,0,0,0.18) > - transition: all 200ms ease-out > - Verify WCAG AA contrast ratio maintained"
Cursor にそのまま貼れる。整形不要、補足説明不要です。
実装上の難所
実装にはいくつか難題がありました。
1. Latency budget: マルチモーダル LLM（GPT-4V、Claude 3.5 Sonnet）は遅い。強めの画像圧縮と streaming response を入れて、操作感を保ちました。
2. Prompt precision: 初期は抽象的な提案が出やすかった。最終 system prompt（約300語）で、正確な CSS 値、コンポーネント特定、アクセシビリティ配慮を強制しました。
3. Context preservation: LLM は指した対象だけでなく、周辺デザインシステムも理解する必要があります。可視 UI から色パレットと余白パターンを抽出して文脈を補っています。
なぜ重要か
これは技術知識の代替ではありません。ビジョンと実装の間にある翻訳レイヤーを取り除くためのものです。
マイクロインタラクションや見た目調整に没頭しているとき、最後にやりたいのは「prompt を書くモード」への切り替えです。Architect mode は flow を維持します。
優れたツールは思考法を変えません。思考と実行の摩擦を減らすだけです。
これは宣伝ではなく、作りながら実際にはまった落とし穴の記録です。