AIに頼んだのに、自分でやった方が早いと思っていた ── 既存改修では、作らせる前に差分で合意する

この記事について

対象読者

• Claude Code や Codex に、既存システムの改修を頼むことがある方

• AIにプランを書かせても、読む負荷が高く、判断しづらいと感じる方

• AIが仕様整理や改善提案を広げすぎて、ズレを戻すのに苦労しがちな方

要点

既存システムの改修では、AIにゴールだけを渡すと、ToBeが大きく広がりすぎることがあります。

効いたのは新しいプロンプト術ではなく、まずスコープを握り、何をやる・やらないを合わせてから段階的にブレイクダウンする ── 人と仕事をするときと同じ、合意の進め方でした。

AIに頼んだのに、自分でやった方が早いと思った

Claude Code や Codex に、既存システムの改修を頼むことがあります。

やりたいこと、つまりゴールは伝えます。
すると、たいていの場合、AIはきちんとプランを出してくれます。

ただ、そのプランがどうも重い。

仕様整理が大きくなりすぎたり、こちらが求めていない改善案まで含まれていたりします。
言葉も少し硬く、ジャーゴンが増えていきます。

読めないわけではありません。
でも、読むのに力が要ります。

しかも、読む負荷が高いのに、こちらのイメージとは少しずつズレている。

そうなると、AIに任せているはずなのに、こちらはAIのプランを読み解き、ズレを見つけ、戻し、また説明することになります。

その状態になると、ふと思います。

これなら、自分でやった方が早いのではないか。

既存改修で、AIはToBeを大きくしすぎる

なぜ、そうなるのか。

たぶん、AIは悪い意味で手を抜いているわけではありません。
むしろ逆で、よくしようとしてくれます。

ゴールを聞いて、現状を見て、そこから「本来こうあるべきではないか」を組み立てる。
その結果、仕様整理が広がり、周辺の改善案も入り、全体の見直しに近づいていきます。

新規で何かを作るときなら、それが助かる場面もあります。

でも、すでに動いているシステムの改修では、話が少し違います。

既存改修で大事なのは、理想の状態をきれいに描くことだけではありません。
むしろ、いま動いているものを壊さずに、今回必要な差分だけを入れることです。

不自然に見える仕様も、実は業務上の理由があって残っているかもしれません。
古く見える画面や文言も、利用者にとっては慣れた動線かもしれません。

そこをAIが「改善対象」と見なしてしまうと、こちらが頼んだ改修よりも大きな話になります。

そして、ToBeが少しずつズレていきます。

AIから見ると、よりよい案を出している。
こちらから見ると、頼んでいない方向に広がっている。

この差が、既存改修ではかなり大きいのだと思います。

プランを書かせても、判断できなければ意味がない

そこで、AIにプランを書かせます。

何をするのか。
どの順番で進めるのか。
どこに影響があるのか。

本来なら、ここで認識がそろうはずです。

でも、実際にはここでもズレることがあります。

プランの体裁は整っています。
番号も振られていて、項目も並んでいます。

ただ、言葉が硬い。
抽象度が高い。
読む側が、毎回頭の中で翻訳しないといけない。

「影響範囲を精査します」
「既存仕様との整合性を担保します」
「段階的に実装方針を確定します」

間違ってはいません。

でも、それを読んだこちらが、何を確認すればよいのか分かりにくい。
どこにOKを出せばよいのかも、どこに待ったをかければよいのかも見えにくい。

これでは、プランがあるようで、合意はできていません。

AIにとっては、構造化された計画。
人間にとっては、判断するには重すぎる文章。

この状態で進めると、AIは「合意された」と思って先に進みます。
こちらは「まだ読み切れていない」と思いながら、後からズレを見つけることになります。

AIにプランを書かせるだけでは足りませんでした。

人間が判断できる形になっていなければ、それは合意ではなかったのだと思います。

効いたのは、差分から合意することだった

そこで、途中で聞き方を変えました。

細かい仕様をもっと出してほしい、という方向ではありません。
逆に、いったん粗く戻しました。

私とAIのあいだで、AsIsとToBeの認識がズレないようにするには、どう進めればよいか。
私が一度に確認できる量は、500〜1000文字くらいであること。
番号だけを並べられても、詳細は別資料と言われても、判断する負荷が高いこと。

そういう前提を、AIにそのまま伝えました。

すると、流れが変わりました。

AIがいきなり詳細に進むのではなく、まず現状をどう理解しているかを出す。
今回の改修で、何ができていれば成功なのかを出す。
何を変えて、何を変えないのかを分ける。

そして、こちらが確認すべき判断ポイントを、読める量で出してくる。

それまで膨らんでいた話が、急に扱いやすい大きさになりました。

やることが減ったというより、見るべき場所が分かったのだと思います。

AIに必要だったのは、もっと細かい指示ではなく、ズレない粗さで差分を合意する場でした。

あとから考えると、これは「差分合意プロトコル」と呼べるものだったのかもしれません。

まずスコープを握る

ただ、これは特別なAIテクニックではありませんでした。

私がこれまで、ステークホルダーと仕事を進めるときにやってきたことを、AIとの作業に持ち込んだだけでした。

人と仕事を進めるとき、私はまずスコープを握るようにしています。

何をやるのか。
何をやらないのか。
いま想定できる範囲で、まずそこを合わせる。

いきなり細かい作業や詳細仕様には入りません。

最初にスコープがズレていると、そのあとにどれだけ丁寧な資料を作っても、ズレた方向に精密になってしまうからです。

スコープを握ったら、次にそれを少し細かくします。
ブレイクダウンした単位で、また認識を合わせます。

そこでズレが見つかれば直す。
直したうえで、さらに次の粒度に下ろす。

この繰り返しです。

考えてみると、今回AIに対してやったことも、ほとんど同じでした。

AIにいきなり実装や詳細設計へ進ませるのではなく、まず今回のスコープを握る。
何を変えるのか。
何を変えないのか。
どこを人間が判断するのか。

そこを合わせてから、次の粒度にブレイクダウンする。

ズレたら、また戻して合わせ直す。

つまり、差分合意プロトコルは、新しいプロンプト術というより、ステークホルダーとの合意形成をAI向けに言い換えたものだったのだと思います。

人間相手なら、表情や反応で「ここは伝わっていないかもしれない」と気づけることがあります。

でもAIは、流暢に返してきます。
そのため、合意できていないのに、合意できたように見えやすい。

だからこそ、合意の形をこちらから決めておく必要がありました。

AIに任せる前に、まずスコープを握る。
そのスコープを、差分と維持に分けて確認する。
合ったら次の粒度に下ろし、ズレたら戻す。

今回効いたのは、たぶんこの順番でした。

500〜1000文字という合意の単位

もうひとつ効いたのは、量を決めたことでした。

私はそのとき、AIに「500〜1000文字程度で整理してほしい」と伝えました。

これは、研究で決まった絶対の数字ではありません。
ただ、私にとっては絶妙でした。

短すぎると、判断材料が足りません。
長すぎると、読むこと自体が仕事になります。

500〜1000文字くらいだと、AsIs、ToBe、差分、維持するもの、判断ポイントを、ひとまとまりとして見られます。
読むだけで疲れず、かといって抽象見出しだけにもならない。

人が一度に扱える情報には、限りがあります。

仕事の場で「A4一枚にまとめてほしい」と言われるのも、おそらく同じ理由です。
書く側の都合ではなく、読んで判断する側が扱える量に切る、という知恵です。

もちろん、500〜1000文字が誰にとっても正解、という話ではありません。

私がやっていたのは、AIのために情報を整理することではなく、私自身が判断できる大きさに、合意の単位を切り直すことでした。

大事なのは、AIがどれだけ長く考えられるかではありません。

人間が、どの粒度なら迷わず読めて、違和感を見つけられるかです。

差分合意プロトコルとして使う

今なら、既存改修を頼むとき、最初にこう言います。

今回は、すでに動いている既存システムへの改修です。

いきなり実装や詳細設計に入らず、まず私との認識ズレを防ぐため、500〜1000文字程度で次を整理してください。

- AsIs：既存システム・既存仕様をどう理解したか
- ToBe：今回の改修後に、何ができていれば成功か
- スコープ：今回やること／やらないこと
- 差分：今回、明確に変えること
- 維持：今回、変えないこと・壊してはいけないこと
- 判断ポイント：私が確認すべきこと
- ズレそうな点：AIが勝手に広げたり、改善しすぎたりしそうな点

今回は「理想的な再設計」ではなく、「既存仕様を壊さない差分改修」として扱ってください。

不自然に見える既存仕様も、すぐにバグや改善対象と判断せず、まず維持対象か確認してください。

番号だけを並べたり、「詳細は別資料参照」にしたりせず、この場で読めば判断できる粒度にしてください。

この整理に私がOKを出してから、次の粒度にブレイクダウンしてください。

これは、万能の呪文ではありません。

ただ、既存改修でAIが広げすぎるときには、かなり効きやすい型だと思います。

特に大事なのは、「維持」を入れることです。

既存改修では、変えることだけが要件ではありません。
変えないことも、同じくらい大事な要件です。

AIは、変えることには強い。
でも、変えないことは、こちらが明示しないと軽く扱われやすい。

だから、差分と維持を分けて出させます。

何を変えるのか。
何は変えないのか。
どこを人間が確認するのか。

この三つが見えるだけで、プランはかなり読みやすくなります。

計画させる仕組みは、最初からあった

「作らせる前に計画させる」こと自体は、目新しい話ではありません。

Claude Code には Plan mode がありますし、Codex にも、ゴールや制約、完了の条件を先に渡して計画させる、という公式のベストプラクティスがあります。
日常的に使っている方も多いと思います。

私も、計画は出させていました。

それでも、ズレていました。

計画が悪かったのではありません。
その計画が、私の認知負荷に合っていなかった。

だから必要だったのは、計画そのものではなく、合意できる計画でした。

そして既存改修では、その合意の中心に「スコープ」「差分」「維持」を置く必要がありました。

ここが、私にとっての発見でした。

前の記事で書いた「判断の余白」の続き

以前、「人は余白で伸び、AIは余白でずれる」という記事を書きました。

そこでは、人に仕事を任せるときの余白と、AIに任せるときの余白は、同じように見えて逆を向くことがある、と書きました。

今回の話は、そのもう少し実務寄りの続きです。

AIに判断の余白を残すと、こちらの想定と違う方向に進むことがあります。
既存改修では、それが「良かれと思った仕様整理」や「頼んでいない改善」として出てきます。

では、余白を全部なくせばよいのか。

たぶん、そうではありません。

やり方まで細かく縛りすぎると、AIの良さも消えます。
一方で、何を正解とするか、何を変えないかの判断を丸投げすると、ズレます。

だから、先に合意する。

細かく命令するのではなく、差分で合意する。

それが、既存改修で見えてきた、いまの私の答えです。

作らせる前に、合意する

AIを使うと、作るスピードは上がります。

だからこそ、作る前の合意が雑だと、ズレたものも速く出てきます。

既存改修では、そのズレを後から戻すのが大変です。
プランを読み直し、実装を見直し、どこからズレたのかを探すことになります。

それなら、最初に少しだけ立ち止まった方がいい。

AsIsを合わせる。
ToBeを合わせる。
スコープを合わせる。
差分を合わせる。
維持するものを合わせる。

そのうえで、次の粒度に下ろす。

AIに任せるために、まず合意する。

既存改修では、たぶんそれくらいがちょうどいいのだと思います。