別のAIに設計を反論させる

AI 設計レビューは、コードを書く前のほうが安く済む。別のAIに一番強い反論を出させ、既に決めたことと照らして直す手順をまとめた。

設計書をエージェントに書かせると、筋の通った文書が出てきます。筋が通っているぶん、穴に気づきにくくなります。編集部の検証環境では、重い設計判断の前に、書いたのとは別系統の AI に反論を出させています。この記事は、実装の前に設計に反論させる手順と、そこで踏んだ失敗をまとめたものです。

実装したあとのコードレビューを何周で止めるかは、「AIコードレビューは何周で止める？」に書きました。こちらはその手前、まだコードが無い段階の話です。

なぜ別のAIに反論させるのか

同じモデル、同じ会話の中で「この設計の問題点は？」と聞いても、さっき自分が書いた理屈をなぞりがちです。Claude Code の公式のベストプラクティスも、新しい文脈のほうがコードレビューの質が上がる、自分が書いたばかりのコードに引っ張られないからだ、と書いています（出典：https://code.claude.com/docs/en/best-practices 、2026-10-16確認）。書いた側の会話を持たない相手に読ませるのが基本です。

編集部では、それをさらに一歩進めて、別系統のモデルに読ませます。学習元や癖が違うので、同じ見落としをしにくいからです。

反論させる手順

重い設計判断は、次の順で決めています。

• 書き手のモデルが設計書を書く
• 別系統のモデルに、その設計への「一番強い技術的な反論」を出させる
• 書き手が再反論し、両方を踏まえた合意案を作る
• 人間が、合意案の前提を実際の環境で確かめる
• 別系統のモデルが、実装計画をレビューする
• 書き手が改訂版を作り、どの指摘をどこで直したかを印で追えるようにする

ポイントは、「問題点を挙げて」ではなく「一番強い反論を」と頼むことです。問題点を頼むと、細かい指摘が並んで、本当に設計を覆す論点が埋もれます。

別系統のモデルには、Codex CLI を非対話で使っています。手元の Codex CLI（codex-cli 0.163.0、2026-10-16）の codex exec --help では、-s, --sandbox で read-only を選べ、-o, --output-last-message で最後の応答をファイルに書き出せます。公式のリファレンスにも同じオプションが載っています（出典：https://developers.openai.com/codex/cli/reference 、2026-10-16確認）。設計への反論は読むだけで済むので、読み取り専用で回します。

codex exec -s read-only -o rebuttal.md - < ask_rebuttal.md

上のコマンドは形を示すためのもので、この記事のために実行はしていません（API の利用が発生するため）。

反論に Web 検索の結果が含まれていたら、実際の環境で確かめるまで事実として扱いません。もっともらしい外部情報が、そのまま設計の前提に入り込むのを防ぐためです。

設計を書く前に、既に決めたことを引く

反論させる以前に、踏んだ失敗があります。

ある設計の初版が、既存のドキュメントで既に決めていた方針と真逆になっていました。書き手のモデルは既決事項を読まずに書き始めていました。互いの結果を見せない複数のレビュアーにかけたところ、主張はすべて退けられ、設計を書き直すことになりました。

レビューの手厚さでは、この失敗は防げません。設計を書かせる前に、決定ログや既存のドキュメントから既決事項を引かせ、設計書の冒頭に「前提として受け入れる決定」として並べさせます。反論させるときも、既決事項はひとまとめに渡しておくと、決着済みの論点を蒸し返されにくくなります。

「複雑すぎる」という直感を数で確かめる

人間が設計を読んで「複雑すぎる」「継ぎ足しが多い」と感じたら、それは警告として扱います。エージェントに「なぜこの構造が必要か」を説明させると、たいてい正当化が返ってきます。説明させるのではなく、数えます。

説明用に作ったダミーの設計書で、出てくる仕組みの名前を数えた例です（実際の設計の実測ではありません）。

queue  2
lock   2
CAS    1
flag   2
retry  2
TTL    1

5行の設計の中に、排他・再試行・検知の仕組みが重なっています。編集部で実際にあったのは、こうした仕組みを全部盛りにした設計が、レビューを何度も重ねたあげく、本番では動いていなかった例です。数を出したうえで、「これは本質的な改善か、継ぎ足しか」を問います。

名前が設計を太らせる

意外だったのは、関数や API の名前が設計の方向を決めてしまうことです。「取得して確保する」「同期する」「更新する」のような、「呼び出し側がデータを書き換える権限を持つ」と読める名前を付けると、モデルはそれを守るための排他や再試行の仕組みを次々に足していきました。

同じ役割でも、「手がかりを渡す」「取り直す」のような、補助であることが伝わる名前にすると、仕組みは増えませんでした。反論させるときは、名前が役割より強い権限を示していないかも聞きます。

反論を受け取ったあと

反論は、そのまま設計に反映しません。1つずつ、次の3つに分けます。

• 受け入れる：前提が正しく、設計を変える理由になる
• 確かめてから決める：反論の前提が、実際の環境で成り立つかどうか分からない
• 退ける：既決事項の蒸し返し、または設計の目的の外

2つ目に入ったものは、人間が実際の環境で確かめます。手順の4番目に「人間が前提を確かめる」を置いているのはこのためです。反論も設計書と同じく文章なので、もっともらしいだけで外れていることがあります。

退けたものも、理由と一緒に設計書に残します。次に別の AI に読ませたとき、同じ反論が出ても、書いてある理由で片付けられます。

仕様に落としてから実装に渡す

反論を経て固まった設計は、仕様書にまとめてから実装に渡します。Claude Code の公式のベストプラクティスにも、大きな機能では Claude に質問攻めにさせて仕様を書かせ、仕様ができたら新しいセッションで実装する、という手順があります。役に立つ仕様は自己完結していて、関わるファイルとインターフェース、範囲外のこと、最後に機能が動くことを示す確認の手順まで書いてある、とも書いています（出典：https://code.claude.com/docs/en/best-practices 、2026-10-16確認）。

編集部では、その仕様書に、受け入れた反論と退けた反論の一覧も付けています。

頼み方の型

反論を頼むときの文面は、次の形にしています。

この設計に対して、一番強い技術的な反論を1つ出してください。
- 前提として受け入れる既決事項は、下にまとめてあります。これらは蒸し返さないこと。
- 細かい指摘は不要です。設計を覆しうる論点だけを書くこと。
- 外部の情報を根拠にするときは、出典を書くこと。
- 名前が役割以上の権限を示していないかも見ること。

複数のレビュアーを並列で走らせるときは、並列ならではの事故があります。それは「サブエージェント並列運用の失敗集」にまとめました。

まとめ

• 設計への反論は、書いた会話を持たない、できれば別系統のモデルに頼む。
• 「問題点」ではなく「一番強い反論」を頼む。反論の根拠になった外部情報は、確かめるまで事実として扱わない。
• 設計を書かせる前に、既決事項を引かせる。レビューを厚くしても、この漏れは防げない。
• 「複雑すぎる」と感じたら、説明させずに仕組みの数を数える。
• 名前が権限を示すと、設計が太る。補助であることが伝わる名前にする。