はじめに
Plan モード、使ってますか？
最近、AIに負荷の高い開発作業を任せることが普通になりました。
経験上ですが、大きめの作業では最初にPlanを作らせる方がいいです。
ちなみにPlanを挟むメリットは以下です。
- AIがこれから何をするのか、自分が何を作ってるのかを把握できる
- 作業の順序や依存関係を確認できる
- 必要な工程が抜けていないか確認できる
- 実装後に「そもそも手順がおかしかった」と気付きやり直すケースを減らせる
- 問題があったときの対応を考えやすい
プランなしでやると以下のようなことありますが、マジで不毛ですよね。
なんかAIがやってるけど知らん知らん♪
↓
うわぁぁぁぁぁぁ！(泣) なんでこんな簡単なことやってねぇんだよ！！ ざっけんな！ クソッ！！！ なんでうまくいかねぇんだよ！！ ハァしかもてめぇこれやってること違うじゃねぇか俺そんなこと言ってない！！！ それは別のセッションだろ！！！ 保留にするって言ったじゃん！！ もぉぉなんで記録してんだよ意味わかんねぇ！ メモリから消せ！！ お前のせいでやり直し！ わかる！？ きょうはもうめちゃくちゃなの！ なんでこうなったか原因を考えろ！！！（トークンの無駄追加♪）
うお…w
まぁこれを防げるからプランはやる意味があります。
ただ、ちょっと問題もありますね。
AIのPlan、長い！
AIにしっかりPlanを書かせると、かなり詳細なものが出てきます。
例えば、
- 変更するファイル
- 使用するAPI
- 型定義
- データ構造
- 関数単位の変更
- テスト方法
- エラーハンドリング
- 実装上の注意点
etc...
などが大量に並びます。
もちろん実装するAIにとっては必要な情報です。
しかし、人間がPlanを確認するときに本当に見たいものは、必ずしもそこではありません。
私が確認したいのはこの順番で本当に目的を達成できるのか？ という部分です。
例えばそれは以下のようなものです。
- 現行処理への影響確認が抜けていないか
- 必要な事前調査をしているか
- 正常系だけでなく失敗時も確認するか
- 再実行した場合に問題が起きないか
- 考慮漏れがないか
この確認のために、数百行のPlanから実装詳細を読み解くのは少し大変です。
そもそも技術じゃAIに勝てないから細かい部分はほぼ任せてるんです。
実際、プランを作らない人は『どうせ分からないしAI正しいからいいや』という考えじゃないですか？
私はそうでした。
技術詳細はAIに任せて、手順を確認したい
そこで考え方を変えました。
細かな技術的実装については、実装を担当するAIに任せます。
人間向けには、Planから 「何を、どの順序で進め、何を確認するのか」 だけを抜き出します。
そのために作ったのが Simple Plan Auditor です。
これはClaude Code / Codexなどで利用するAgent Skillです。
目的は単純で、以下の通りたった一つです。
Planを人間が論理的な抜けを確認しやすく整える
どんな形になるのか
CSVインポート機能を作るPlanを例にします。
Simple Plan Auditorでは、詳細なPlanとは別に、まず人間が確認するために全体概要を出します。
概要は以下の4セクションです。
- 目的
- 全体作業マップ
- 要注意事項・人間判断
- 重要な依存・分岐
人間はここで論理的なミスの有無や手順の抜け、全体の流れを把握します。
その上で先に続く詳細セクションで気になるところだけ深掘りすればいいのです。
全体作業マップの例を表示
| 工程 | 主な作業 | 確認事項 |
|---|---|---|
| 現行把握・影響分析 | 現行の登録フローを整理 | CSV追加によって影響する既存経路が他にないか |
| 現行把握・影響分析 | 関連データへの影響を分析 | 既存データとの整合性に問題がないか |
| 仕様整理 | CSVで扱う項目を確定 | 必須項目や重複時の扱いが未決定ではないか |
| 入力処理 | CSV受付を実装 | 不正な入力を登録処理へ渡さないか |
| 検証 | 全行を検証 | 一部の行だけ検証して終了しないか |
| 検証 | エラー内容を整理 | 利用者が修正可能な情報を返せるか |
| 登録 | 検証済みデータを一括登録 | 途中失敗時に中間状態を残さないか |
| 登録 | 再実行を扱う | 重複登録や二重処理が発生しないか |
| 組み込み | 管理画面から処理を利用可能にする | 実装した処理が実際の利用経路へ接続されているか |
| 検証 | 既存機能を回帰確認 | 従来の登録方法を壊していないか |
| 導入 | 本番へ反映 | 問題発生時に切り戻せるか |
| 整理 | 暫定処理を撤去 | 一時コードや設定が残っていないか |
実際のPlanには、この下に各工程の詳細な実装内容があります。
しかし、最初からすべて読む必要はありません。
まず全体作業マップで以下を確認します。
- 作業の流れ
- 抜けていそうな工程
- 確認が必要な箇所
その後、気になった工程だけ詳細パートまで見に行きます。
大きなPlanでは粒度を変える
ただ懸念もあります。
すべての作業を1枚の表へ並べると、大規模なPlanでは概要そのものが巨大になります。
そこでSimple Plan Auditorでは、Planの規模に合わせて概要の粒度を調整します。
例えば細かな作業が100個あっても、最初の概要ではかなり大まかにまとめます。
そして後に続く詳細セクションで、概要見ていて気になったところだけ見ます。
マークダウンの索引がそのまま概要のようにも機能します。
つまりPlanそのものを短くするのではなく、最初に人間が確認する範囲を小さくしています。
ただし、論理的に必要な確認事項は省略しません。
ここは運用しながら調整していくところです。
出力したPlanを自己チェックする
Simple Plan Auditorでは、Planを整形して終わりにはしません。
出力したPlanに対して、
- LLMによる批判的レビュー
- Pythonによる構造チェック
の2段階で自己チェックします。
批判的レビュー
まずLLMが、作成したPlanをあらためて批判的に確認します。
ここでは技術的な実装方法を細かく再評価するのではなく、
- 目的達成までの工程に抜けがないか
- 作業の順序や依存関係に矛盾がないか
- 前工程の成果が次工程へ正しくつながっているか
- 暗黙の前提や、人間が判断すべき事項が埋もれていないか
といった、Plan全体の論理的な成立性を確認します。
問題が見つかった場合は、概要の「確認事項」や「要注意事項・人間判断」へ反映し、必要に応じてPlan自体を修正します。
Pythonによる構造チェック
その後、簡単なPythonバリデータで概要の構造も確認します。
こちらはPlanの内容を評価するものではありません。
確認するのは、
- 必要な概要セクションが存在する
- セクションの順序が正しい
- 全体作業マップが想定した列構造になっている
- 各作業に確認事項が記載されている
- 確認事項がない場合は「なし」と明示されている
- 依存・分岐が所定の位置に存在する
といった、人間が読みやすい形式になっているかだけです。
構造に問題があれば概要を作り直します。
役割を分けると、次のようになります。
Plan生成
↓
LLMによる批判的レビュー
├─ 手順の抜け
├─ 依存・分岐
├─ 接続漏れ
├─ 異常系・再実行
└─ 人間判断・暗黙の前提
↓
Plan修正
↓
Pythonによる構造チェック
↓
人間が概要を確認
つまり、LLMはPlanの論理を確認し、PythonはPlanの形を確認する。
その自己チェックを通した上で、人間には全体作業マップ・確認事項・要注意事項を提示します。
改めてPlanを作る意味を振り返る
AIに実装の大部分を任せる場合でも、Planは有用です。
むしろ、任せる範囲が広いほど重要だと考えています。
実装前の段階で、
既存機能の影響確認がない
出力構造が違う
と気付ければ、実装後に発覚するより修正コストを抑えられます。
こういうの抜けてること普通にありますからね。
ただ技術はもう本当に勝てないので、技術的な実装はAIに任せつつ人間は「その手順で本当にいいかな」を確認する。
これが一番ではないでしょうか。
Simple Plan Auditorは、そのためのSkillです。
おわりに
AIが書いた詳細なPlanを、人間がすべて精読するのは大変です。
一方で、Planそのものを確認しなくなると、AIがどのような手順で作業しているのか分からなくなります。
そこで、
実装の技術詳細はAIに任せる。
人間は作業の流れと論理的な確認事項を見る。
という分担にしました。
Simple Plan Auditorは、そのためにPlanを 「全部読む文書」から「確認すべき場所が分かる文書」 へ変換するSkillです。
しばらく実際の開発で使いながら、必要な監査項目や粒度調整を詰めていく予定です。