- AIコーディングツールにコードを書く前にまず計画を立てさせる方法論で、誤った実装を防ぎ、開発速度を高められる
- 8つの計画戦略を難易度別に適用し、各戦略では特定のエージェントが並列で調査を行った後、開発者が判断と意思決定を下す構造
- 各戦略には、バグ再現、ベストプラクティス検索、既存コードベース分析、git履歴調査などが含まれ、エージェントが学習した好みやパターンが自動的に蓄積される
- オープンソースとして公開されたシステムをClaude Codeに導入するか、単一機能から始めて段階的に開発者の思考様式をAIに学習させられる
AI計画中心の開発方式
- AIがコードを書く前に計画を立てるようにするアプローチを紹介
- この方法は、単にコードを書かせるよりも機能実装の速度を高め、エラーを減らす効果がある
- 例として、メール管理アプリCoraの「email bankruptcy」機能の開発過程を紹介
- 53,000件のメールを重要メールの損失なく整理する機能を実装する際、AI研究エージェントが事前分析を実施した
- Gmailの2,000件制限、システムタイムアウト、ユーザー待機時間の問題を事前に発見し、誤った実装を防いだ
8つの計画戦略
戦略1: バグの再現と文書化
- 目的: 修正前にバグを再現し、段階的なガイドを作成
- 使用タイミング: Fidelity 1〜2、特にバグ修正時
- email bankruptcy機能のリリース直後、19人のユーザーが処理失敗状態に閉じ込められる問題が発生
- AppSignalログをたどって診断した結果、Gmailのレート制限エラーが本番環境で無視されていた
- 1つのバッチが失敗すると処理全体が停止していたが、ユーザーには通知されず、無限ロードのスピナーだけが表示されていた
- 再現の過程でバッチ処理とジョブ再開機能が必要だと判明し、単純なリトライだけでは不十分だと確認
- 複利効果: @kieran-rails-reviewerエージェントのチェックリストに「外部APIを呼ぶバックグラウンドジョブでレート制限処理があるか、リトライがあるか、部分的な状態を放置しないか」という項目を追加
戦略2: ベストプラクティスの調査
- 目的: 類似問題の解決事例をWebで検索
- 使用タイミング: あらゆる難易度、特に見慣れないパターン
- 2バージョン遅れたgemをアップグレードする際、エージェントが「バージョンXからYへのアップグレード経路」「バージョン間の破壊的変更」「一般的な移行課題」を検索
- 公式アップグレードガイドと、同じアップグレードを行ったエンジニアによるブログ記事3本を発見
- 3分の調査で、何時間もの試行錯誤によるデバッグを回避
- 非技術的な意思決定にも活用: 「SaaS価格帯のベストプラクティス」「メールドリップキャンペーンのコンバージョンコピー」「バックグラウンドジョブのリトライ戦略」など
- 複利効果: 有用なパターンを見つけると、自動的に
docs/*.md ファイルへ保存され、次回の類似質問ではWeb検索前にまず確認される
戦略3: コードベースの調査
- 目的: 既存コードから類似パターンを探す
- 使用タイミング: 既存機能の重複の可能性があるあらゆる作業
- 新機能にイベントトラッキングを追加する前に、エージェントがコードベースを検索: 「現在のイベントトラッキングの処理方法は?」「分析呼び出しのパターンは?」「イベント送信箇所は?」
- ヘルパーメソッドまで備えた既存のトラッキングシステムを発見（本人は忘れていた）
- AIがコードベースを参照しないと、最初から新しく作ろうとしがち
- 新しいトラッキングシステムを作る代わりに、既存パターンを拡張して解決し、互換性のない2つ目のシステム構築を防止
- 複利効果: 「@event-tracking-expert」エージェントを作成し、トラッキングが必要なすべての機能計画で自動実行
戦略4: ライブラリのソースコード調査
- 目的: インストール済みパッケージやgemのソースコードを直接読む
- 使用タイミング: 変化が速い、または文書化が不十分なライブラリを使うとき
- RubyLLM gemは新しいモデル、パラメータ、機能が継続的に追加される一方で、ドキュメントが追いついていない
- エージェントがRubyLLMのソースコードを分析: 「利用可能なモデルオプションは?」「渡せるパラメータは?」「最新版の未文書化機能は?」
- 「バージョン1.9でストリーミング対応が追加されたが、ドキュメント化されていない。テストスイート内のパラメータ名と使用例はこれ」と提示
- 複利効果: 依存関係を更新するたびに知識も自動更新され、古い情報で作業することがなくなる
戦略5: git履歴の研究
- 目的: コミット履歴を分析し、過去の判断意図を把握
- 使用タイミング: リファクタリング、作業の引き継ぎ、「なぜ」を理解したいとき
- 古いバージョンのEmailClassifierが使われているのを見つけ、アップグレード前にgit履歴を検索: 「なぜv1を使っているのか?」「v2へのアップグレードを試したことはあるか?」
- 3か月前の別のチームメンバーのPRを発見: v2へアップグレードしたところ、受信トレイのメールがアーカイブへ、アーカイブ済みメールが受信トレイへ送られる問題が発生
- PRの議論には、詳細な理由とともに意図的にロールバックした記録が残っていた
- 複利効果: 制度的記憶が保存され検索可能になり、新メンバーも過去の判断ロジックを引き継げる
戦略6: プロトタイピングで要件を明確化
- 目的: 別環境での高速プロトタイピングにより要件を明確にする
- 使用タイミング: Fidelity 3、UXの不確実性、探索的作業
- メールBriefインターフェースを再設計する際、5種類の異なるレイアウトプロトタイプをClaudeでそれぞれ5分ずつかけて作成
- 実際にクリックして使いにくさを把握し、一部ユーザーに最適版を提示
- あるユーザーのフィードバック: 「レイアウトが圧倒的で、メールをどうアーカイブすればいいのかわからない」
- その知見を実際の計画要件に反映: 「アーカイブボタンは左上隅に必ず配置すること — ユーザーの筋肉記憶がGmailでその位置を期待しているため」
- 複利効果: プロトタイピングが不確実性を具体的な仕様へ変換し、ユーザー反応を文書化する
戦略7: 選択肢付きで総合する
- 目的: すべての調査をトレードオフ込みの1つの計画に統合
- 使用タイミング: 調査段階の終了後、実装前
- 戦略1〜6を実行した後、エージェントが総合: 「この調査をもとに問題解決方法を3つ提示。各アプローチの実装複雑性、性能影響、保守負担、対応する既存パターンを示す」
- Gmail受信トレイ同期の例:
- オプションA—既存の同期システムを使用: 実装は速いが、コード重複と関心の分離の悪化を招く
- オプションB—リアルタイム同期: アーキテクチャはきれいだが、遅く信頼性の問題が起こり得る
- オプションC—ミラーキャッシュシステムを構築: 長期的には最良の解決策で、最もきれいに分離できるが、初期作業量が最大
- 比較を確認したうえで、30秒で情報に基づく選択が可能
- 複利効果: 選択が好みを明らかにし、「互換性優先」の好みを示せば、次回の類似判断でシステムが互換性に高い重みを与える
戦略8: スタイルエージェントレビュー
- 目的: 完成した計画を、開発者の好みを確認する専用レビュアーへ渡す
- 使用タイミング: 最終計画段階、実装前
- 自動実行される3つのレビューエージェント:
- 簡素化エージェント: 過剰なエンジニアリングを警告し、「この機能に本当にデータベーステーブルが3つ必要か? タイプフィールド付きの1テーブルで十分では?」と指摘
- セキュリティエージェント: 一般的な脆弱性を確認し、「この計画ではユーザー入力をデータベースクエリに直接許可している — 入力サニタイズの追加が必要」と指摘
- Kieranスタイルエージェント: 個人的な好みを強制し、「複雑な結合を使っているが、Kieranは単純なクエリを好むので、非正規化を検討」と指摘
- 複利効果: エージェントが時間とともに開発者の好みを蓄積し、「これは嫌い」「ここは良い」といった反応からシステムが学習する
始め方
今日すぐ試せる方法
- EveryのGithub Marketplaceで計画システムをオープンソース公開
- Claude Codeに導入すれば、
/planスラッシュコマンドと研究エージェントをすぐ利用可能
- Claude CodeまたはDroidでプラグインを使用可能
シンプルな始め方
- 今週作っているFidelity 2の機能を1つ選ぶ: 複数ファイルにまたがり、範囲が明確な作業（新しいビューの追加、フィードバックシステムの実装、コンポーネントのリファクタリング）
- Claude CodeやCursorに実装を依頼する前に15〜20分の調査を行う:
- ベストプラクティス: 他の人はどう解決したか? Webでブログ記事、Stack Overflow、ドキュメントを検索
- 自分のパターン: 自分はどう解決してきたか? 既存コードベースで類似機能を検索
- ライブラリ機能: 使っているツールは実際に何をサポートしているか? AIでドキュメントやソースコードを読む
- AIに、次の項目を含む計画へ調査結果を総合させる:
- 解決すべき問題（明確な一文）
- 2〜3種類の解決アプローチ（それぞれ率直な長所と短所）
- 適合すべき既存コードパターン
- エッジケースまたはセキュリティ上の考慮点
- 計画をレビューして反応を観察: 「複雑すぎる」または「すでにもっと良い方法がある」と感じたら、計画だけを直すのではなく、なぜそう思ったのかを捉えて記録する
- 計画に基づいて機能をリリースし、最終実装と元の計画を比較する。どこでずれたのか? なぜか? 何が計画をより良くできただろうか?
- 10分使って1つの学びを明文化: CLAUDE.mdファイルに追加し、「Xタイプの作業ではYを確認することを覚える」または「理由CによりアプローチBよりAを好む」といったルールを1つ書く
- 学びが蓄積したら、特化した研究エージェントやコマンドを作成: 「Event Tracking Expert」（自分のパターンを把握）、「Security Checker」（一般的なミスを警告）
- 翌週も繰り返し、ノートを参照し、2回目の計画が1回目より良くなっているかを確認し、数か月後には開発者の思考様式を理解するシステムを構築する
まだコメントはありません。