AIに500文字の詳細仕様を渡したのに、期待外れのものが返ってきた経験はないか。実は、指示が長いほど良い結果が出る、というのは誤解だ。
「詳しく書けば書くほど良い」という罠
バイブコーディングを始めた人がよく陥るパターンがある。最初は短い指示で試す。うまくいかない。「もっと詳しく書けば良かったんだ」と思って、次は仕様書レベルの長文を書く。
それでも期待した結果にならない。何が悪いのか。
問題は「詳しさ」ではなく「何を詳しく書くか」だ。UIの色やピクセル数を細かく指定することは、AIにとって必ずしも助けにならない。むしろAIが本来持っている能力——何百万ものUIパターン、コードの慣習、ユーザー体験の設計知識——を殺してしまうことがある。
これをマイクロマネジメントと呼ぶ。
マイクロマネジメントの何が問題か
マイクロマネジメントとは、部下の仕事の細部まで口を出す管理スタイルだ。優秀な部下でも、一挙手一投足を指示されたら本来の力は発揮できない。「白背景で、ボーダーは1px、ボタンの色は#14B8A6で、font-sizeは14pxで……」という指示は、まさにこれだ。
AIへの指示に置き換えると、こうなる。
❌ マイクロマネジメント（悪い例）
「白背景のログインページを作って。フォームはページ中央に配置。
emailインプットは1pxのグレーボーダー（#E5E5E5）、12pxのラベル。
パスワードインプットも同様。送信ボタンは背景色#14B8A6、
白文字、font-size 14px、padding 12px 24px、border-radius 6px。
ホバー時は#0D9488に変更」
✅ ディレクション（良い例）
「最小限のSaaS向けログインページ。VercelやLinearが使うような
信頼感のあるデザイン。モバイルでも崩れないこと」
後者の方が、質の高いアウトプットが得られることが多い。理由はシンプルで、AIがすでに「VercelやLinearのデザイン言語」を学習しているからだ。細かいパラメータを渡すより、参照すべきスタイルの名前を渡す方が、AIはずっと賢い判断をする。
AIの「暗黙知」を引き出す
2026年現在のAIは、数百万ものUIパターン、ベストプラクティス、コードの慣習を学習している。「SaaSのダッシュボード」と言えば、それが何を意味するか知っている。「Notionのような清潔感」と言えば、そのデザイン言語を理解している。
この「言わなくてもわかっていること」を暗黙知と呼ぶ。
暗黙知を引き出す指示の出し方がディレクションだ。映画監督が俳優に細かい動作を指示するのではなく、「この場面で何を感じているキャラクターか」を伝えるように。AIにも「何を達成したいのか」「誰のためか」「何のスタイルを参照するか」を伝える。
「子育て中のママが使うタスク管理アプリ」という指示は、UIの色や余白を列挙した仕様書より多くの情報をAIに伝える。ターゲットユーザーの情景がAIのUX判断——情報の優先順位、インタラクションの設計、視覚的な重み付け——を自然に導くからだ。
3つの領域でのディレクション実例
デザイン・UIの指示
先述のログインページの例がわかりやすい。ポイントは、参照すべきスタイルの「名前」を使うことだ。「Vercel風」「Linear風」「Stripe風」——これらはAIにとって豊富な情報を含んでいる。
コードの指示
コードの場合は少し異なる。「目標 + 制約」の形式が有効だ。実装方法はAIに任せる。
❌ マイクロマネジメント（悪い例）
「APIのレスポンスからエラーメッセージを取得して、
ステータスコードが404なら'見つかりません'を表示、
401なら'ログインが必要です'、500なら'サーバーエラー'を表示。
エラーはtoastで3秒間表示してから消す」
✅ ディレクション（良い例）
「このAPIコールに適切なエラーハンドリングを追加して。
ユーザー向けのわかりやすいメッセージで。
既存のトースト通知の仕組みに合わせること」
後者のアプローチは、既存コードのパターンや命名規則をAI自身が読み取って判断する。前者のアプローチは、AIがコードを読む前にすでに実装方法を決めてしまっている。
アーキテクチャの指示
状態管理の例で見てみる。
❌ マイクロマネジメント（悪い例）
「親コンポーネントにuseStateを置いて、setterを3つの子コンポーネントに
propsで渡して。再レンダリングを防ぐためにuseCallbackを全ハンドラーに使って」
✅ ディレクション（良い例）
「ユーザープロフィールの状態管理を追加して。
小〜中規模のReactアプリに適した方法で、prop drillingは避けること」
前者は実装の詳細を全て指定してしまっている。useCallbackが本当に必要かどうか、AIは検討する余地もない。後者なら、AIはコードベースを読んで最適な判断をする。
「何を具体的にして、何を任せるか」の使い分け
ここで重要な注意点がある。「ディレクション思考 = すべて曖昧に」ではない。
ディレクションが有効なのは「AIがそのパターンを学習している場合」だ。カスタムデザインシステムや社内固有の命名規則、正確な数値（金額、期間、閾値）には具体的な指示が必要だ。「任せた結果を必ずレビューする」という前提も外せない。
使い分けの基準はシンプルだ。
コンテキストエンジニアリング：一度の準備が毎回の指示を楽にする
ここまで「個別の指示」の話をしてきた。しかし、プロの使い方はもう一段上にある。コンテキストエンジニアリングだ。
2025年頃からAndrej KarpathyやShopify CEOのTobi Lütkeが言語化した概念で、「プロンプトだけでなく、AIが見る情報全体を設計する」という考え方だ。
具体的には、CLAUDE.md や Cursor Rules というファイルにプロジェクトの設計思想を書いておく。
# CLAUDE.md の例
## デザインシステム
- スタイル: ミニマルSaaS。シャープなエッジ
- カラー: モノクロ基調、アクセントは teal (#14B8A6)
- 参照: Linear / Vercel のデザイン言語
- フォント: Geist
## コーディング規約
- コンポーネントは関数型のみ
- 状態管理は Zustand
- APIコールは TanStack Query
## アーキテクチャ
- Feature-Sliced Design
このファイルがあれば、以降の指示は「ユーザー一覧ページを追加して」だけで良い。
これは新入社員へのオリエンテーションと同じ構造だ。最初に会社のルールや文化をしっかり教える。そうすれば「あの件、進めといて」という短い指示で動ける。毎回「弊社のロゴは青で、フォントはゴシックで……」と説明する必要がない。
freeeのエンジニアチームが行った実験でも、「設計フェーズからAIと協働する」アプローチ（技術的なコンテキストを最初から共有する）が、抽象的な指示や後から技術ガイドラインを追加するアプローチよりも、エラーが少なく正確な実装が得られたと報告されている。
Claude Codeを使っている場合、CLAUDE.md ファイルをプロジェクトルートに置くだけで自動的に読み込まれる。一度書いておけば、プロジェクト内の全ての指示に自動で適用される。
ディレクションプロンプトの3要素
個別の指示を書くときも、型がある。「目的 + 対象 + 制約」の3要素だ。
| 要素 | 説明 | 例 |
|---|---|---|
| 目的（なにを） | 達成したいことを動詞で | 「ログインページを作る」 |
| 対象（誰のために） | ターゲットやコンテキスト | 「SaaS利用者向け」 |
| 制約（してはいけないこと / 参照スタイル） | 境界線を引く | 「Linear風、モバイル対応必須」 |
「どうやって実装するか」はAIに任せる。これがクライアントとしての立ち位置だ。建築家に「プライバシーを大切にした家族向けの家、収納たっぷりで日当たり重視」と伝えるように。壁の厚さや断熱材の種類を指定するのは建築家の仕事だ。
著名プロダクト名という「情報の圧縮」
「Duolingoのチャーミングさを持つ、Notionのような清潔感のノートアプリ」という指示は、色コードや余白の数値を並べるより、AIが一貫したデザイン判断をするために必要な情報を伝えられる。
これは「感覚的な言葉が使えるから良い」ではない。AIにとって、著名なプロダクトの名前は膨大なデザインの情報を圧縮した言葉だからだ。バイブコーディングとプロンプトエンジニアリングを組み合わせる考え方については、Graphiteのガイドも参照してほしい。
「指示が短いのに結果が良い」を目指す
AIへの指示における理想の状態は、「指示が短いのに結果が良い」だ。
それを実現するのは2つの準備だ。
1. プロジェクトの文脈を先に定義する（CLAUDE.md / Cursor Rules） デザインシステム、コーディング規約、アーキテクチャ——プロジェクトのルールを一度まとめる。これがあれば個別の指示は最小限で済む。
2. 個別の指示は「目的 + 対象 + 制約」で書く 「どうやって」はAIに任せる。AIが学習済みのパターンを信頼する。正確な数値や固有名詞が必要な部分だけ具体的に書く。
バイブコーディングが「とりあえず動くものを作る」フェーズだとすれば、ディレクション思考は「意図通りのものを作る」フェーズだ。
AIに「何でもやらせる」から「適切に指揮する」へ。それがバイブコーディングの、その先にある姿だ。