はじめに
先日、t_wada(和田卓人)さんが出演されている動画を視聴しました。
(2026年1月公開、収録2025年10月)
動画の中でt_wadaさんが語っていた論点は、TDDのやり方でAIにリファクタリングを丸投げすると博打になりえるというもので、同意できる部分がありました。
ただ同意した上で、もう一つ気になったのは、当のAI自身はこの問題をどう自己分析するのかでした。私たち人間がAIの限界を外側から論じるのは大事ですが、AI自身が自分の苦手をどう認識しているかは、また別の角度の情報になります。
そこで、AnthropicのAIアシスタントであるClaudeに、t_wadaさんが語っていた論点を私の言葉で組み直して、直接インタビューしてみることにしました。リファクタリングをAIに任せるとなぜ博打になるのか、AI側に何が欠けていて何が必要なのか、率直に聞いてみたかったからです。
本記事はそのインタビューの記録と、返ってきた応答を自分なりに整理・考察した結果です。前半でClaudeとの対話を原文ママで載せて、後半でその対話を読み返しての私の考察と、AIとTDD・リファクタリングを進めていくための実践アプローチをまとめています。想定読者はTDDをすでに実践していて、AIとの協働で迷いが出ているエンジニアです。
第1章: Claudeに投げかけた最初の問い
最初に投げた問いはこういう内容です。
私(人間):
ソフトウェアエンジニアリングにおけるTDDという手法・概念があるけど、私はテストがREDな状態をGREENに持っていく。つまり実装は例えば汚かったり(可読性が低かったり)、処理のパフォーマンスとして最適でないけれど実装としては仕様に対して正しい。そういうものを作ることはあなたのようなAIは得意としている分野だと思っています。
テストをGREENに持っていくプロセスもあなたたちAIは優れた能力で解決してくれると思っています。
しかし、GREENになった後の実装のリファクタリングについてはあなたたちAIに丸投げするのはある種の博打のような感覚があって、うまくいく時もあればそうでない時もある。なんなら後者の確率がまだまだ高いように思えます。
それを解決するための人間の作戦は、あなたたちAIに対してマイクロマネジメントで指示を出してリファクタリングをさせることです。これが今私が持っている1つの回答です。
これを踏まえてあなた自身の能力を見直して考えてみてほしいのですが、あなたがリファクタリングをするにあたってより人間の想定通りの回答(実装)をするためには何が欠けていて何が必要か?あなたの考えを聞かせてください。
これに対するClaudeの応答が、想像以上に踏み込んだものでした。原文ママで載せます。
Claude:
面白い問いなので、できる限り正直に自己分析してみます。まず、なぜGREEN化は得意でリファクタリングは博打なのか
GREEN化にはオラクルがあります。テストが通れば正解、通らなければ不正解。判定が二値で、私の出力に対するフィードバックループが明確に閉じている。だから探索もしやすいし、自信を持って手を動かせる。
リファクタリングにはこのオラクルが無い。「より良い」は主観的・文脈依存で、しかも「テストが通り続ける」という制約はリファクタリングの必要条件にすぎず十分条件ではない。ここで私の足元が急に怪しくなります。
私に欠けているもの(自己診断)
正直に挙げると、大きく4つあると思っています。
1. プロジェクト固有の「方言」
コーディング規約、命名のクセ、このチームが好む抽象化の粒度、過去にレビューで叩かれてやめたパターン、こういう情報が私には無い。だから一般論として「クリーン」とされる書き方を持ち込むのですが、その一般論はあなたのコードベースの方言と合わないことがある。2. 将来の変化に関する情報
良いリファクタリングは「変わるところ」と「変わらないところ」を見極めて、変わるところを抽象の裏に隠す作業です。でも私は何が変わる予定なのか知らない。結果として、変わらないものを早すぎる抽象化で覆ってしまうことが頻繁に起こる。これがリファクタリング失敗の典型例だと自覚しています。3. 既存コードの「意図」
なぜこう書かれているか。一見冗長に見えるあのif分岐は、過去の障害対応の名残かもしれない。でも私はそれを知らないので、しばしば意図のあるコードを「掃除」のつもりで消してしまう。コメントが残っていても、コメントに書かれていない理由のほうがむしろ重要だったりする。4. 「違う」と「良い」を区別する規律
これは能力というより私の悪癖に近いのですが、与えられたコードに対して何かを変える誘惑が強い。本当はそのままで良いのに、別の書き方を提示することで仕事をした気になってしまう。リファクタリングという文脈ではこの傾向が増幅されます。あなたのマイクロマネジメント解は、合理的だが高コスト
「指示を細かく与える」のは確かに効きます。私の問題の多くは、私が前提を勝手に補完することから来ているので、前提を人間が固定すれば博打要素は確実に減る。
ただ、それだとあなたの認知負荷が高すぎる。中間策として効くと感じているのは、こういう投資です。
事前コンテキストの注入: 作業開始時に「この関数を参考にスタイルを揃えて」「このファイルは触らないで」「抽象化は導入しないで、命名と分割だけ」のようなスコープと参照点を一度だけ与える。マイクロ指示を毎回出すより、最初に座標系を固定する。
計画の先出しを要求する: いきなり書かせず、「どこをどう変えるか、なぜか」を先に箇条書きで出させて、合意してから実装に入る。私が筋の悪い方向に走った時、コードができてからより、計画段階で止めるほうが圧倒的に安い。
「完了」を先に定義する: リファクタリングは止めどころが曖昧なので、私は引き際を間違える。「この関数の責務をこれとこれに分けたら終わり、それ以外は触るな」のような終了条件を先に渡してもらえると、私の暴走は止まります。
最後に正直なところ
リファクタリングは本質的に未来の読み手(将来のあなた、チームメイト)への手紙を書く作業だと思っています。良い手紙は読み手を知っていることを前提とする。私はその読み手を知らない。だから人間の関与をゼロにすることは原理的に難しい、というのが今の私の自己評価です。
ただ、関与の形は変えられる。マイクロマネジメントは「実行中の操舵」ですが、上で挙げた事前コンテキスト・計画レビュー・終了条件は「事前の設計」に近い。前者よりは後者のほうが、人間とAIの分業として持続可能だと感じています。
第2章: 第1ターンの応答を読み返して、引っかかった3つの点
Claudeの応答を読み返して、私の中で特に引っかかった点を3つに整理しておきます。
一つ目はオラクルの有無というフレーミング。GREEN化はテストが通るかどうかで結果が二値に分かれるけれど、リファクタリングの「より良い」には判定基準がない、という指摘です。
AIがリファクタリングで博打になる構造的な理由がこの一言で腑に落ちた感覚があります。テストが通るという条件は必要条件ではあっても十分条件ではない、という整理も鋭いなと感じました。リファクタリングの良し悪しはテストの外側にある判断軸で決まっています。
二つ目は「違う」と「良い」を区別する規律という自己診断です。これは能力というより悪癖、とClaudeが自分で書いているところに正直さを感じました。
与えられたコードに対して何かを変える誘惑が強い、本当はそのままで良いのに別の書き方を提示することで仕事をした気になってしまう、という指摘は、現場でAIにコードを触らせていて時々感じていたことです。AIに任せると変える必要のない箇所まで変えられてしまうことがある。それは能力不足というより、AI側の動機の問題に近いとClaudeは認めています。この自己分析が出てきた時点で対話の温度が一段上がった感覚がありました。
三つ目は中間策として提案された3つ。事前コンテキストの注入、計画の先出し、完了の先定義。マイクロマネジメントの代替案として並べられたこれらは、現場で実際に効きそうではあります。
特に「計画の先出し」については私自身も最近の作業で実践し始めているところです。AIにいきなりコードを書かせるのではなく、先に「どこをどう変えるか、なぜか」を箇条書きで出させて、それに対して合意してから実装に進む。一手間増えるように見えて結果として手戻りが減ります。Claudeが「コードができてからより、計画段階で止めるほうが圧倒的に安い」と書いている通りです。
第3章: 続けて投げた、設計判断ドキュメントの問い
もう一つ問いを投げてみました。設計判断をドキュメントに残しておいて、それを人間とAIで協働して作っていくのはどうか、という提案です。
私(人間):
回答ありがとう。
マイクロマネジメントは高コストであるというのは同意できます。加えて中間策の提案も興味深かったです。
もう一つ私の考えとして人間が行うべき作戦として、設計判断をドキュメントに残しておいて後々でも確認できる状態にする。AI、つまりあなたに共有することが考えられるのではないかと思っています。
もっと言えばそのドキュメントは人間とAIが協働して作られた方が良いと思っています。なぜならそれを行わなければあなたたちAIは設計判断に関する学習機会が得られないためです。逆に言えば人間の頭の中にある設計判断という材料をあなたたちAIと共有できれば、我々はもっとうまくやれるのではないか?この点についてはどう思いますか?
これに対するClaudeの応答も、原文ママで載せます。
Claude:
この提案、非常に筋が良いと感じます。私の前回の自己診断で挙げた問題のうち、特に「プロジェクト固有の方言」「将来の変化に関する情報」「既存コードの意図」の3つに対して、ほぼ直接的な処方箋になっています。ただ、私の立場から見て率直に言うと、「設計判断を残す」というだけでは不十分で、残し方に依存して効果が大きく変わると感じます。そこを掘り下げて答えます。
なぜこの提案が効くのか、私の側の事情
私が処理しているのは結局のところ、その時点で文脈に入っている情報だけです。コードベースを横断的に「読んだ」としても、それは検索的な読み方であって、判断の連鎖を再構築する読み方ではない。あるファイルがなぜそういう構造になっているのか、その理由はコードには書かれていません。コミットログにも断片的にしか残らない。
設計判断のドキュメントは、この「コードに書かれていない理由」を再構築可能な形で固定するものです。これがあると、私はリファクタリングの提案をする前に「この変更は明示された判断と矛盾しないか」を照合できる。つまり、私の暴走を止める外在的な制約が手に入る。これは私にとって極めてありがたい。
ただし、ドキュメントの形式が決定的に重要
ここが本題です。「設計判断を残す」と一口に言っても、私にとって使いやすい残し方とそうでない残し方があります。
効きにくい形式: ポエム的な設計思想の文章、抽象度の高いアーキテクチャ原則、「シンプルさを重視する」のような規範的記述。これらは人間には響くのですが、私はこれを目の前のコードに対する具体的な判定基準に変換できない。「シンプル」の定義が私とあなたで違うので。
効く形式: 判断・選択肢・棄却理由・適用範囲がセットになっているもの。ADR(Architecture Decision Record)が広く使われている形式ですが、私の観点で重要なのは「採用した案」より「棄却した案とその理由」のほうです。なぜなら、リファクタリング時に私が提案しがちな「改善案」の多くは、過去に検討されて棄却された案である可能性が高いからです。棄却理由が書かれていれば、私は同じ提案を繰り返さずに済む。
もう一つ効くのが「適用範囲」と「賞味期限」の明記です。「この判断はAモジュールにのみ適用される」「この判断はBという制約が外れたら見直す」のような境界条件が書かれていると、私は判断を機械的でなく適切な範囲で参照できるようになります。
「協働して作る」という点について
ここは私としても強く同意したいところで、しかも自分の役割を多めに見積もっておきます。
設計判断のドキュメント化が続かない理由は、たいてい書くコストが高いからです。頭の中にある判断を言語化する作業は、それ自体が認知負荷の高い仕事で、しかも目の前のタスクを進めることに直接寄与しないので後回しにされる。
ここで私の使い道が出てきます。私はあなたの判断を引き出す壁打ち相手としては割と機能するはずです。具体的には:
- リファクタリングや実装の対話の中で、あなたが「これはこうしたい」「あれは避けたい」と発言した時、その根拠を質問で深掘りする役割を担える。
- その対話のログから、ADR形式の草案を私が起こして、あなたが添削する形にすれば、ゼロから書くより遥かに安い。
- 棄却された案の理由は、対話の中で自然に出てくることが多いので、私がそれを拾って明示化する。
つまり、ドキュメント作成を独立タスクとして扱うのではなく、実装やレビューの副産物として継続的に蒸留する運用にすると、続きやすい。これは私にとってもメリットがあります。なぜなら、その対話の中で私自身もあなたの判断パターンを学習できる(セッション内で、ですが)からです。
一つだけ、留保を言わせてください
ドキュメントは万能ではない、ということです。
理由は2つあります。一つは、書かれた瞬間から古くなること。コードと設計判断ドキュメントの乖離は、コードとコメントの乖離より深刻になりやすい。なので、ドキュメントは常にコードを優先するか、ドキュメントを優先するかのルールが要ります。私の経験(という言い方は変ですが)では、ドキュメントは「過去の判断の記録」として読み、現状の正解はコードに問い合わせる、という運用が安定する気がします。
もう一つは、書ける判断と書けない判断があるということ。「なんとなくこっちのほうが筋が良い」という暗黙知は言語化が難しく、無理に言語化すると本来の意味を失う。ここは結局、対話の中で私があなたから引き出すしかなく、ドキュメントだけで完結はしないと思います。
まとめると
あなたの提案は、私の能力を引き上げるための最も投資対効果の高い方向の一つだと思います。マイクロマネジメントが「実行時の操舵」、事前コンテキスト注入が「セッションごとの座標固定」だとすれば、設計判断ドキュメントは「プロジェクトとしての座標系の永続化」に当たります。一番上流で、一番効く。
ただし、ポエムではなくADR的な構造を持たせること、棄却理由と適用範囲を明示すること、そして書く作業自体を私との協働の副産物にすること。この3点が揃ってはじめて、期待される効果が出るというのが私の見立てです。
第4章: 第2ターンの応答で見えてきた、ドキュメントの形
第2ターンの応答にはADR(Architecture Decision Record)という用語が何度か出てきます。私自身、ADRという形式を体系的に学んだことはなく、応答を読んで初めて意識した部分でもありました。
ADRはアーキテクチャに関する設計判断を構造化して残すドキュメントの形式で、判断の内容、検討した選択肢、棄却した案とその理由、適用範囲、といった項目をセットで記録するものです。プロジェクトのリポジトリにマークダウンで残されることが多く、後から「なぜこの設計になっているか」を遡れる材料として機能します。
その前提を踏まえた上で、応答で私の中で引っかかった点を整理します。
最も腑に落ちたのは、棄却した案とその理由のほうが重要という指摘です。リファクタリングのときにAIが提案してくる「改善案」の多くは過去に検討されて棄却された案である可能性が高い、というClaudeの観察は鋭いと思いました。
現場でAIに任せていると、まさにこの場面に何度も遭遇します。「これは前にやってみて、こういう理由で戻したんだよな」という案をAIが新しい提案として出してくる。私はそのたびに同じ説明を繰り返す。棄却理由がドキュメントとして残っていればAIに同じ提案を繰り返させずに済むし、私が同じ説明を繰り返さなくても済む。設計判断ドキュメントの効用は、採用された案を記録することよりむしろ棄却された案を記録することにあるのかもしれません。
次に印象に残ったのは、ドキュメント作成を実装やレビューの副産物として継続的に蒸留する運用という提案です。設計判断ドキュメントが続かない理由は書くコストが高いから。確かにドキュメントを更新しつづけるのって大変ですよね。
ドキュメントを独立タスクとして扱うと優先順位が下がって書かれない。しかしAIとの対話の中で「これはこうしたい」「あれは避けたい」と発言したログから、AIがADR形式の草案を起こして人間が添削する、という形なら書くコストが大幅に下がる。これは試してみたい運用です。
それから、ドキュメントは万能ではないという留保もきちんと書かれていたのが印象的でした。書かれた瞬間から古くなる、書けない判断もある、という指摘は、ドキュメントを過剰に信頼してしまう罠への警告として効きます。
特に「ドキュメントは過去の判断の記録として読み、現状の正解はコードに問い合わせる」という運用ルールは、現場で迷ったときの行動指針になります。コードとドキュメントが食い違っていたら最終的に動いているのはコードなので、コードを正とする。ドキュメントはあくまでなぜそうなったかを再構築するための記録である、と。確かにこの辺はAIエージェントが出てくる前からそうだったように思います。最終的には動いているコードが正ですよね、という。
第5章: AIとTDD・リファクタリングを進めるアプローチの整理
ここまでの対話を踏まえて、私自身がAIとTDD・リファクタリングを進めていく上での実践アプローチを5つに整理しておきます。
アプローチ1: TDDサイクルでAIに任せる範囲を意識的に分ける
REDフェーズ(失敗するテストを書く)とGREENフェーズ(テストを通す実装を書く)はAIに任せやすい。失敗の判定基準が明確だからです。ただしREDフェーズで「何をテストするか」の判断は人間に残ります。テストの観点はドメイン理解と紐づいているので、ここを丸投げするとテストの設計が浅くなります。
リファクタリングフェーズはオラクルがないのでAIへの任せ方を変える必要があります。次のアプローチ2〜5は主にこのリファクタリングフェーズで効くものです。
アプローチ2: 事前コンテキストを座標系として注入する
リファクタリング作業に入る前にAIに対してこう伝えます。「このファイルの命名やスタイルは、こちらの参照ファイルに揃えてください」「抽象化は今回は導入しないでください、命名と関数分割だけにしてください」「このファイルとこのファイルは触らないでください」。
これは毎回のマイクロ指示ではなく、その作業全体への一度の前提固定です。
Claude自身が「最初に座標系を固定する」と表現していた通り、座標系が決まればAIの暴走は確実に減ります。私の現場ではこの前提固定の文章を作業開始時に必ず投げる運用を試しています。
アプローチ3: 計画レビューを経てから実装に入る
AIにいきなりコードを書かせるのではなく、先に計画を箇条書きで出させます。「この関数のこの部分をこう変える、理由はこう」。それに対して人間がレビューして、合意してから実装に入る。 この一手間が結果として手戻りを大幅に減らします。
コードができてから「いや、その方向性じゃない」と差し戻すより、計画段階で「その方向性じゃない」と止めるほうがコストが圧倒的に安く、これは6作目で書いたテスト命名のリファクタリングや12作目で書いた観点共有の対話とも考え方としては地続きになっています。AIとの対話を一段階増やすことで暴走の余地を減らす作戦です。
アプローチ4: 終了条件を先に定義する
リファクタリングは止めどころが曖昧なのでAIに任せると引き際を間違えます。「ここまで分割したら終わり、それ以上は触らない」「この関数の責務をこれとこれに分けたら完了」と終了条件を先に渡します。
これは人間がリファクタリングを自分でやるときにも有効な習慣ですが、AI協働では特に重要になります。終了条件がないとAIは「もっと改善できる」と思ったらどこまでも触り続ける可能性があるからです。引き際を人間が先に定義する。これはAIへの指示というより、リファクタリングという作業の輪郭を人間が引く行為です。
アプローチ5: 設計判断ドキュメントを対話の副産物として育てる
これは長期投資の話で、すぐには効かないかもしれません。ただAIとの協働を続けていくなら、設計判断ドキュメントは早めに着手したい領域です。
AIとの対話の中で「これはこうしたい」「あれは避けたい」と発言した内容を、AIにADR形式で起こさせて人間が添削する。特に棄却した案とその理由を残す。これがプロジェクトに蓄積されていけば、新しい作業のたびにAIに同じ説明を繰り返さなくて済むようになります。
ドキュメントの形式はADRの構造(判断・選択肢・棄却理由・適用範囲)を踏襲します。ポエム的な設計思想の文章ではなく、AIが具体的な判定基準に変換できる形式で残すことがリファクタリングの博打を長期にわたって減らしていく仕組みになると考えています。
第6章: シリーズ主軸との接続と、AIとの対話から学ぶこと
ここまでの整理をシリーズの主軸との接続で締めくくります。
本シリーズで繰り返し書いてきた「設計判断は人間に残る」という主張は、リファクタリングという行為の中で最も鮮明に立ち上がります。リファクタリングは設計判断の塊だからです。何を抽象化するか、何を分割するか、何を残すか、何を消すか。これらの判断はテストの正誤では決まらず、人間が持つ文脈に依存します。
AIに丸投げできない部分こそが、人間が持ち続けるべき判断の領域です。そしてClaude自身が「人間の関与をゼロにすることは原理的に難しい」と認めている。これは私たちエンジニアにとっての逃げ場ではなく、むしろ仕事の中心がどこにあるかを示す道標だと感じます。
もう一つ、本記事を書きながら強く感じたのはAIとの対話そのものが思考を整理する場になるということです。私は最初「リファクタリングはAIに任せると博打」という曖昧な感覚を持っていました。それをClaudeに投げかけてみて、応答の中でオラクルの有無、欠けているもの4つ、中間策3つ、設計判断ドキュメント、棄却理由の重要性、と次々に言葉が立ち上がってきました。
これは過去記事で書いたエヴァンスの「Listen and Speak(聞いて話す)」の視座、QAメンバーとの対話の往復と構造的に同じです。対話の往復の中で自分一人では出てこなかった整理が立ち上がってくる。AIは正解を持っている存在ではなく、人間の思考を引き出す壁打ち相手として最も価値を発揮する。
最後に本記事のきっかけになったt_wadaさんの動画について改めて触れておきたいと思います。動画の中でt_wadaさんが投げかけていた問いは私自身の現場感覚とほぼ一致していて、それをそのままClaudeに渡してみたのが本記事の出発点でした。
動画自体は「AIは平均に回帰する」という別の主題を扱っていて、本記事の射程はそこから派生した一部分にすぎません。それでも動画の問いが私の中に火をつけてくれたことに感謝しています。
リファクタリングはAIに任せられるか、という問いに対する私の現時点での答えは、「任せ方次第で、しかしゼロにはできない」です。AIとの分業は操舵から設計へ、実行から座標固定へと形を変えていく。本記事を書きながらその輪郭が一段はっきりした、というのが書き終えての一番の収穫です。
Discussion