AIの修正が終わらないなら、直さずに作り直す

こんにちは、黄島成です。

本日は、AIに作らせたものが直しても直しても終わらないとき、何を変えればいいかという話です。

AIに一箇所直させると、別のところが壊れます。それをまた直させると、また別のところが壊れる。ちょこちょこAIを使ってやるのは結構沼で、時間が溶けます。

やりがちなのは、まずプロトタイプを実装させて、そこから細かい部分をどんどん微調整していく進め方です。一見これがいちばん正しく見えます。実際は、直すたびに新しい問題が出てきて、永久ループになります。

答えは、直す精度を上げることではありませんでした。会話ごと捨てて、やりたいことを一枚のファイルにまとめ直して、もう一度ワンショットで作らせる。そして出来上がったら、そこから動かさない。

直すのをやめたら、終わるようになりました。

修正するほど遠ざかる

なぜ往復するほど悪くなるのか。AIのできることは広いんだけど、深くない。だからそこまで深くやってしまうと、逆にAIの能力を制限してしまう、というのが今の見方です。細かい修正の往復は、いちばん深いところを何度も突かせ続ける作業になります。

外部の計測でも、同じ方向の結果が出ています。LLMs Get Lost In Multi-Turn Conversationは、同じ内容を一発で渡した場合と、会話で小分けにして渡した場合を比べた研究です。六種類の生成タスクの平均で、後者は39%落ちました。落ちているのは能力そのものより信頼性のほうで、モデルは早い段階で勝手な思い込みを作り、それに乗った答えを出して、そこから軌道修正できなくなる、と書かれています。

つまり、往復が長くなるほど、こちらの指示より、AIが最初に決めた形のほうが強くなる。往復の質を上げる方向の対策はいくらでもありますが、往復そのものが劣化装置なのだとしたら、丁寧にやるほど効く、という形にはなりません。

永久ループの正体は、たぶんここです。

AIを使うと開発は遅くなる、という有名な測定もあります。METRが2025年前半に行った試験では、経験のある開発者がAIを使えるときのほうが、実際には19%遅く終わっていました。本人たちは20%速くなったと感じていたのに、です。ただしMETR自身が2026年2月の更新で、証拠はごく弱いと断ったうえで、いまの開発者は当時の推定よりAIで速くなっている可能性が高い、と書き足しています。だから、AIが遅いという話にはしません。遅いのはAIではなく、AIとの往復のほうだ、というのが自分の読み方です。

一枚にまとめて一発で渡す

では、何を渡すのか。仕様書と、やりたいことと、自分がどういう感じでやるかの大まかなロードマップを、一つのファイルにまとめます。これこれをやってください、を一枚にする。あとの細かい部分は自分で決めてしまう。そのうえで、プランモードでワンショットタスクとして走らせます。

ここで意外なのは、AIに任せる量が増えるのではなく、自分が決める量が増えることです。丸投げできるから一発で終わるわけではありません。細かい判断を先に自分で潰しておくから、AI側にノイズが残らない。

ワンショットタスクでやらせたところが、基本的にはAIができる最高到達点なんじゃないか、というのが今の見方です。ノイズがない状態でAIができる純粋な能力、という感じがしました。逆に言えば、往復して出てきたものは、その最高到達点から下がった位置にあります。

完成したら動かさない

一発で作り終えたら、そこからもう一切動かしません。新しい機能をちょこちょこ足していかない。やるとすれば、中の軽度のバグだけです。ワンチャン、それもしなくていいと思っています。

例外は一つあります。フロントで、サービスとして人に提供しているものは、バグや使いづらさがそのまま問題になるので、そこは調整しないといけない。自分が使うためのものは、ワンショットで全部やらせて、あとは軽度なバグ調整で終わらせています。

では機能が足りなくなったらどうするか。新しいモデルが出たときに、またワンショットで作り直します。モデルのできることが上がるたびに、いま作っているものの限界値も一緒に上げていく。広く浅く、自分のやりたいことを全部見つけて落とし込んで、ワンショットで作る。それをいっぱい作っていく。

作り足すのではなく、作り直す。

先に固定してしまうもの

ワンショットが成立する条件は、細かい判断を自分で先に潰せることです。そこで効いたのは、深さではなく広さのある知識でした。本番の実行基盤をどこにするか。データをどこに置くか。浅くていいので広く知っていれば、ここはこうした方がいいよね、が自分の中で決まってきます。決まったら、それを固定化する。

自分の場合、開発は基本的にローカルで全部できます。本番の実行環境はCloudflare、データベース系はOracle。この3つに、OpenAIやClaudeのフロンティアモデルを足した4つが、厳選したものです。

そのうえで、GitHubの使い方が、たぶんいちばん普通ではありません。CIもGitHub Actionsも使いません。コードをクラウドにバックアップする先としては一番優秀なので、バックアップ先としてしか使っていない。

コスパの見方も、途中で変わりました。Cloudflareは実行自体はめっちゃ安いし、速い。ただ、データベースが大規模になってくるとコスパが悪くなります。Supabaseを使っていた時期もありますが、こちらは増えれば増えるほどコスパが悪くなるので、それならOracleのほうが全然いい、と感じました。

道具を増やすほど、新しい問題とボトルネックが出てきます。一発で終わらせたいなら、選択肢が少ないほうが有利でした。

捨てるのはコード、残すのは知識

作り直す前提にすると、困ることが一つ出てきます。毎回ゼロからやり直すなら、積み上がるものがないんじゃないか。

積み上げる場所を、コードから外せば済みました。

うまくいかなかったアプローチは、システムを作ることでした。プログラミング言語やコードがごちゃごちゃになって、LLMに使わせるとスパゲッティコード化する。システムが複雑になるほど、問題も並行して増えていきます。だから、コードをあまり作らせないことが大事になる。

いま自分がやっているエージェントの育て方は、構造をMarkdownファイルで作って、情報をどんどん蓄積していく形です。コンテキストの問題なので、情報は増えるほど精査できるし、圧縮もできる。コードは知識に応じて変わるので、使い捨てでいい。

ここは自分でも意外でした。LLMにXの運用をやらせたとき、最初はAIが文章を作るのは下手で、AIっぽい投稿が多いと感じていました。それが、このやり方で運用したら、自分が作った投稿よりAIが作った投稿のほうがめちゃくちゃ成果が出ました。

ただ、AIだけに作らせるとミスも起こります。今のところ一番成果が出るのは、人間が作った下書きをAIに食わせて、添削させて、リライトさせて、最適化する形でした。自分の中から出てくるものと、エージェントの知識を組み合わせると、かなり強い。エージェントが動けば固有のデータも生まれて、それ自体が競争優位性になります。これを続ければ、収束関数的に精度が上がっていくはずだ、というのが今の見立てです。

ループを抜ける順番

いま往復にはまっているなら、手を動かす順番はこうなります。

まず、その会話を捨てる。往復が長いほど、AIは最初に決めた形にしがみつきます。
やりたいことと大まかな仕様を、一つのファイルにまとめ直す。細かい判断は、ここで自分が決めてしまう。
プランモードで、ワンショットで走らせる。出てきたものを、今のモデルの最高到達点として受け取る。
動かさない。触るのは軽度のバグだけ。人に使わせているものだけを例外にする。
使う道具を固定する。増やした分だけ、新しいボトルネックが増えます。
残すのはコードではなく、Markdownの知識にする。次のモデルで作り直すときに効くのは、そっちです。

逆の順番でやると、直しても直しても、正直、永遠に終わりません。時間が溶けるだけです。

作り直す前提で作る

この進め方で見えてきたのは、上限の置き場所が変わる、ということでした。直し続けている限り、出来上がるものの上限は、最初の会話で決まったところに固定されます。ワンショットで作り直せる状態にしておけば、モデルが上がるたびに、自分の持っているものの上限も一緒に上がる。

そのうえで、AI開発でいちばん見るべきなのは構造だと考えています。AIへちゃんと指示できて、構造もできていれば、基本的にはルールや規則通りに動く。それはAIを動かす回路みたいなものです。

Xを見ていると、エンジニアの投稿でいちばん反応を得ているのは、UIやフロントエンドの見栄えの部分です。あれは作品として面白いし、デザインの参考にもなります。こっちのほうが優れているでしょう、と競技化してぶつかり合っているのは、ラッパー同士がビーフして盛り上げている感じに近くて、見ている分にはエンタメとして強い。ただ、そこで勝っても結果には直結しません。

そして、回路を作っても、誰でも作れる回路なら競争優位性にはなりません。誰でもできるものは、誰でもできてしまう。だから、回路そのものの設計と、そこに載る自分の知識の両方が要ります。

次にAIに直させて、また別のところが壊れたら、そこで直させるのをやめてください。会話を閉じて、やりたいことを一枚にまとめ直す。捨てているのはコードだけで、あなたの知識は一つも捨てていません。