AIで作った実装計画のレビュー手順 レッドチームと仕様照合で確かめること
要約： VAONでは仕様が確定したあと、エンジニアがClaude Codeのプランモードで実装計画の下書きを作ります。計画は2段階のレビューを通します。計画を失敗させる側から問う「レッドチーム」と、仕様と照らし合わせる「検証」です。仕様から答えが出ない点は推測せず、お客様に確認します。何を直すかはテックリードが決めます。
目次
- AIが下書きする実装計画には何が書かれているのか
- 整って見えるAIの計画を、なぜあえて攻撃するのか
- 計画のレッドチームでは何を問うのか
- 仕様との照合（検証）では何を確かめるのか
- 2段階のレビューのあと、何を直すかは誰が決めるのか
- 計画のレッドチームが不要な場合と、この手順の限界
- よくあるご質問
1. AIが下書きする実装計画には何が書かれているのか
VAONでAIが下書きする実装計画は、フェーズ、変更するファイル、フェーズごとの完了条件、把握しているリスクの4つで構成されます。計画を作るのは、お客様と書面で仕様を確定したあとです。その前の工程は、仕様確定の前にAIで洗い出す確認事項でご説明しています。
エンジニアは、Claude Codeのプランモードで計画を作ります。Anthropic社のドキュメントによると、このモードではClaudeはファイルを読んで計画を提案するだけで、人が承認するまでファイルを変更しません。
| 計画の項目 | 記載する内容 | お客様にとっての意味 |
|---|---|---|
| フェーズ | 作業の順番、止められる地点 | 1〜2週間の短い単位ごとに、動くものができる |
| 変更するファイル | コード上の変更範囲 | システムのどこに手が入るかを事前に把握できる |
| 完了条件 | テストか画面操作で確かめられる条件 | 何をもって完了とするかを双方で共有できる |
| リスク | 壊れうる箇所、元に戻す方法 | コードに工数をかける前にリスクを検討できる |
計画と2段階のレビューは、VAONのClaude Codeを使った開発フローの4番目と5番目のステップにあたります。このフローは現在、多くの案件で適用している基準ですが、すべての案件ではまだありません。
2. 整って見えるAIの計画を、なぜあえて攻撃するのか
AIが書いた計画をあえて攻撃するのは、計画が整って見えるほど、抜けている前提に気づきにくくなるためです。見出しも表も揃っていて、読むと納得してしまいます。それでも、業務の前提が誤っていることはあります。
もう一つの理由は速度です。AIはコードを速く書くため、誤った計画も速く誤ったコードになります。計画の1行を直すほうが、書き終えたモジュールを直すよりはるかに安く済みます。
発注側のお客様にとっては、ここがリスクを最も安く止められる地点です。まだコードはなく、データも移しておらず、誤った方向に工数も使っていません。
3. 計画のレッドチームでは何を問うのか
計画のレッドチームとは、AIが計画を失敗させる側に立ち、問いと失敗の筋書きだけを返す工程です。AIに計画を書き直させることはしません。書き直させると、どこに問題があったのかが読み手から見えなくなるためです。
レッドチームは、計画を作った会話とは切り離して行います。新しいセッションを開くか、Claude Codeのサブエージェントを使います。ドキュメントによると、サブエージェントは新しく独立したコンテキストで動きます。AIには仕様と計画だけを渡し、計画を作ったときの推論は持ち込ませません。
次の表は、レッドチームで扱う質問の分類です。説明のために一般化した例であり、特定のお客様の案件から取ったものではありません。
| 分類 | 質問の例 | 当たったときに直す箇所 |
|---|---|---|
| ロールバック | リリース後に不具合が見つかったら、どう旧版に戻すか。新しく書き込まれたデータは失われないか | リスク欄、リリース手順 |
| データ移行の途中停止 | 移行が半分で止まったら、どこから再開するか。再実行で二重登録にならないか | フェーズの分け方、再実行手順 |
| 権限の拡大 | この変更で、これまで見えなかったデータが見えるようになる役割はないか | 変更ファイル、権限のテスト |
| 同時実行 | 2人が同じレコードを同時に編集したら、またはジョブが2回動いたらどうなるか | 完了条件、排他の方針 |
| 外部APIの障害 | 連携先のAPIが応答しないとき、待つか、再試行か、エラーにするか。再試行で注文が二重にならないか | リスク欄、エラー処理 |
| 新しい依存パッケージ | 追加するパッケージは公式レジストリに実在するか。誰が保守しているか | 依存の追加を別タスクに分ける |
| テスト | このリスクが現実になったとき、どのテストが落ちるか。落ちるテストがなければ何を足すか | 完了条件、テスト計画 |
依存パッケージの行には理由があります。AIは存在しないパッケージ名を挙げることがあるため、VAONではすべての案件で、インストール前にパッケージ名を確認しています。
4. 仕様との照合（検証）では何を確かめるのか
検証とは、仕様の要件を一つずつ計画と突き合わせ、抜けを探す工程です。レッドチームが「どう壊れるか」を問うのに対し、検証は「双方で合意した内容と合っているか」を問います。探すものは次の3種類です。
- 仕様にあるのに、計画に出てこない要件
- 計画にあるのに、仕様に根拠がない作業。範囲が知らないうちに広がるのは、たいていここです
- 仕様からは答えが出ない問い
3つ目には決まりがあります。エンジニアは推測で埋めず、お客様に確認します。説明のための例を挙げます。仕様に「大口の注文は管理者の承認が必要」とあっても、いくらからが大口かが書かれていない場合です。AIはもっともらしい金額を自分で選べてしまいます。もっともらしくても誤りは誤りで、AIはその金額を前提にしたコードをすぐに書き上げます。
検証では完了条件も確認します。「検索を速くする」では、終わったかどうかを誰も判定できません。完了条件は、テストか画面操作で確かめられる文に直します。完了条件をテストケースにする方法は、プルリクエストに含めるAI生成テストの読み方でご説明しています。
5. 2段階のレビューのあと、何を直すかは誰が決めるのか
2段階のレビュー結果はテックリードかシニアエンジニアが読み、何を直すかを決めます。AIは決めません。指摘の中には、別のフェーズですでに扱っているものや、今回の範囲外のものも混ざるため、すべてを直すわけではありません。
直さないと決めた指摘も、理由を1行添えて記録します。次にレビューする人が同じ問いを繰り返さずに済みます。作成者以外の担当者がレビューし、確認した計画だけが実装に進みます。VAONの社内手順（変更ごとの7ステップ）では、この確認を計画作成の直後に置いています。
VAONでは、検証で出たお客様への確認事項をチャットに埋もれさせません。週次報告の「お客様にご判断いただきたい事項」に載せます。ご回答によって範囲が広がる場合は、書面による変更管理の手順に沿って、費用とスケジュールへの影響をお知らせし、ご承認後に着手します。ご承認いただいていない作業の請求書をお送りすることはありません。CTOとテックリードはすべての案件に関わるため、レッドチームの結果を読むのはアーキテクチャを把握している者です。
6. 計画のレッドチームが不要な場合と、この手順の限界
計画のレッドチームは、あらゆる変更に必要なわけではなく、手順そのものにも限界があります。
- ごく小さな変更。 文言の修正やボタンの色の変更に、2段階のレビューは不要です。変更の大きさに応じて工程を省きます。
- コードや資料をAIツールに渡す許可をいただいていない場合。 AIがコードを読む工程は実行しません。エンジニアが自分で計画をレビューするため、時間がかかります。
- AIは貴社の明文化されていないルールを知りません。 よくある壊れ方については的確に問えますが、誰も書き残していないルールについては問えません。
業務についての質問に答えられる方がお客様側にいらっしゃらない場合、検証で出せるのは問いまでで、答えは出せません。また、この工程の効果を示す計測値は、VAONとしてまだ公表していません。
7. よくあるご質問
実装計画は、すべて読む必要がありますか。 必要ありません。お客様にお渡しするのは、フェーズ、完了条件、ご回答いただきたい確認事項など、お客様に関わる部分です。計画の全体はレビュー記録やテスト記録と一緒にプロジェクトの記録として保存しており、必要なときにご覧いただけます。大きな変更については、レッドチームの結果をご覧いただくこともできます。
2段階のレビューで、プロジェクトは遅くなりませんか。 計画の段階で時間は増えますが、ここは直すコストが最も小さい段階です。計画しかない時点で見つかった抜けは、数行の修正で済みます。同じ抜けがデータ移行の後に見つかると、コードとデータを直し、テストをやり直すことになります。小さな変更では、この工程を短くしています。
仕様の空白は、AIに答えさせればよいのではありませんか。 AIが選ぶのは、もっともらしい答えであり、貴社にとって正しい答えとは限らないためです。承認の基準額、端数処理のルール、誰がどのデータを閲覧できるかは、お客様が決めることです。ここを推測で埋めると、誤ったコードがすぐにできあがります。そのため、VAONのエンジニアはこうした点を確認事項にしてお客様にお送りします。
回答によって開発範囲が広がる場合はどうなりますか。 追加分は変更管理の手順に沿って進めます。費用とスケジュールへの影響を書面でお知らせし、ご承認をいただいてから着手します。ご承認いただかなかった作業は行わず、費用も発生しません。範囲が変わらないご回答は、そのまま仕様と計画に反映します。
レッドチームのために、自社のソースコードがAIツールに渡されますか。 お客様の許可がある場合に限ります。作業開始前に、どのデータを使ってよいか、誰が閲覧できるか、コードをAIツールに渡してよいかを取り決めます。許可をいただいていない場合、VAONはコードや資料をAIツールに渡さず、エンジニアが自分で計画をレビューします。時間はかかりますが、取り決めを守ることを優先します。
今日からできることが一つあります。次に大きな変更を依頼するとき、開発チームに「データ移行が途中で止まったら、どう元に戻しますか。計画のその部分は、どなたが読みましたか」と尋ねてみてください。答えが計画に書かれていなければ、その計画はまだレビューを受けていません。
この2段階のレビューを貴社の案件に当てはめるとどうなるか、無料相談（60分）でご説明します。CEOが同席します。資料のご準備は不要で、ご契約を前提としたものではありません。
参考資料
- Claude Code Docs「Common workflows：Plan before editing」：https://code.claude.com/docs/en/common-workflows（2026年10月29日確認）
- Claude Code Docs「Create custom subagents」：https://code.claude.com/docs/en/sub-agents（2026年10月29日確認）
