AI駆動開発ベストプラクティス
「AIに全て任せる」ではなく、人間とAIの適切な役割分担によって開発効率を最大化するアプローチ。スナガク がFocusOne開発で実証した10の実践テクニックを中心に体系化。
人間が担うべき領域
- 認証周りの設計: セキュリティ上のセンシティブさからAIだけでは正確に実装できない
- 0→1バックエンド設計: 既存パターンがない場合、AIが適切な設計を行えない
- ボトルネックの特定と判断: AIは「言われたこと」は精度高くやるが、全体最適を自律的には判断しない
- 技術的限界の見極め: AIの性能不足 / 技術的に不可能 / 方法がわからない を区別する
AIに任せるべき領域
- 仕様書ベースの実装（SDD（仕様駆動開発））
- コードレビューと動作確認（Playwright MCP）
- E2Eテストの作成・修復
- リファクタリング候補のリストアップ（定期バッチ）
- デザインと実装の同時進行（Figma Make + Claude Code）
認知負荷を下げる工夫
非同期タスク委譲
- AIが作業中は別の思考作業に集中する
- ターミナルのみ表示: エディターを見るとコードが気になって集中が切れる
- CIも結果だけ確認、途中経過は見ない
コンテキスト管理
- 不要なコンテキストを削除してコンパクションを防ぐ
- 「毎回同じ指示」→ Skills化 のサイン
- 「AIがよく間違える」→ CLAUDE.md修正 のサイン
技術的負債との付き合い方
- 負債を認識した上で意図的に進める（中途半端に手を出さない）
- Domainモデルを作り込む: 影響範囲を局所化することで修正漏れを防ぐ
- リファクタリングのタイミング: 整合性保守が大変 / デバッグが辛い / 同じバグが頻発
現段階の限界
使い手の設計力・アーキテクチャ知識が開発品質に直結する。AIはベストプラクティスより「動くもの」を優先するため、保守性の担保は人間の責任。
マルチモデル戦略
| ツール | 主な用途 |
|---|---|
| Claude Code | メイン実装・Skills・SubAgent |
| Codex | 長時間E2Eテスト・放置タスク |
| Cursor | デバッグ・FE細部修正 |
| Figma Make | デザイン・モック作成 |
AIとの対話設計
推奨度付き選択肢
不明点をAIに質問させる際、「選択肢 + 推奨度 + 理由」形式で返答させると意思決定の速度と質が向上する。
CLAUDE.md への1行追記で永続化可能:
選択肢にはそれぞれ、推奨度と理由を提示する仕事の本質との接続（小川 雄太郎）
AI時代の仕事術（仕事の本質） では「AI時代に残る仕事 = 高難易度の不確実性を含むもの」と定義される。AI駆動開発においても同様の構造が現れる:
- LNOフレームワーク的視点: 設計・アーキテクチャ判断はLタイプ（後続に10倍インパクト）、実装はNタイプ
- 問題定義駆動: AIへの指示も「問題の厳密な定義」（達成条件 + 制約条件）が品質を左右する（SDD（仕様駆動開発） と共鳴）
- 思考実験優先: 実装前に「この指示でAIがどう動くか」を思考実験し、無駄な試行錯誤を減らす
- システムシンキング: ボトルネック（人間が担うべき領域）を先読みし、AIに任せる部分を設計する
日常業務自動化への展開
「AIに全て任せず、判断は人間が行う」原則はエンジニアリングだけでなく日常業務自動化にも共通する。shunya（東大院生） は 45 本の cronジョブ自動化を通じて同様の結論に達した: AIには「下書き・候補・通知」だけを出させ、最終判断は人間が行う。→ 日常業務自動化の設計原則（shunya）
世界一流エンジニアの思考法との接続（牛尾 剛）
牛尾 剛の世界一流エンジニアの思考法は、AI駆動開発ベストプラクティスと多くの原則を共有する：
- WIP=1（集中作業原則） — AIへのタスク委譲中は別の作業（非同期委譲）と共鳴する
- Be Lazy原則（最小努力・最大価値） — 20%のタスクで80%の価値を生む発想がLNOフレームワークと接続
- デザインドキュメント先行アプローチ — SDD（仕様駆動開発）の思想的基盤
- Fail Fast（早期失敗） — 試行→フィードバック→修正の高速サイクルがAI駆動開発のリズムと一致