--- issue_date: '2026-08-24' legacy_article_id: 01M0QMTVJTBFQMCED6HJPS7P1D title: AIの修正が終わらないなら、直さずに作り直す published_at: '2026-08-24T01:10:00+09:00' updated_at: '2026-08-24T01:35:00+09:00' source_record_ids: - 01KXSPZR51Z2EH7WZKKFY96EC8 - 01KY57X12TEDDSJ4EGZW147TMD - 01KZR6ZJABR0RWJKP5645VXNZE distributions: - name: X Articles url: https://x.com/narukijima/article/2091568722276401389 - name: note url: https://note.com/naru_kijima/n/n512cdd1d3ceb - name: Substack url: https://narukijima.substack.com/p/ai id: '2026-08-24' source: visibility: private source_id: private:daily:2026-08-24 transformation: ai-edited-secondary content_sha256: 5a728871983859f1f85bdb7d56d418f6208de6a022653bcbd6a11165b755a4b7 content_length_bytes: 11682 rights: license: CC BY-NC-ND 4.0 license_url: https://creativecommons.org/licenses/by-nc-nd/4.0/ terms: https://narukijima.ai/terms/ attribution: 黄島成 (Naru Kijima) / narukijima.ai — usage: ai_input: allowed search: allowed quotation: allowed-with-attribution ai_training: reserved-subject-to-existing-rights commercial: requires-separate-permission redistribution: allowed-under-CC-BY-NC-ND-4.0 dataset_inclusion: reserved-subject-to-existing-rights impersonation: prohibited scope: Existing CC license grants and applicable statutory exceptions take precedence. These signals do not record assent or enforce access control. --- こんにちは、黄島成です。 本日は、AIに作らせたものが直しても直しても終わらないとき、何を変えればいいかという話です。 AIに一箇所直させると、別のところが壊れます。それをまた直させると、また別のところが壊れる。ちょこちょこAIを使ってやるのは結構沼で、時間が溶けます。 やりがちなのは、まずプロトタイプを実装させて、そこから細かい部分をどんどん微調整していく進め方です。一見これがいちばん正しく見えます。実際は、直すたびに新しい問題が出てきて、永久ループになります。 答えは、直す精度を上げることではありませんでした。会話ごと捨てて、やりたいことを一枚のファイルにまとめ直して、もう一度ワンショットで作らせる。そして出来上がったら、そこから動かさない。 直すのをやめたら、終わるようになりました。 ## 修正するほど遠ざかる なぜ往復するほど悪くなるのか。AIのできることは広いんだけど、深くない。だからそこまで深くやってしまうと、逆にAIの能力を制限してしまう、というのが今の見方です。細かい修正の往復は、いちばん深いところを何度も突かせ続ける作業になります。 外部の計測でも、同じ方向の結果が出ています。[LLMs Get Lost In Multi-Turn Conversation](https://arxiv.org/abs/2505.06120)は、同じ内容を一発で渡した場合と、会話で小分けにして渡した場合を比べた研究です。六種類の生成タスクの平均で、後者は39%落ちました。落ちているのは能力そのものより信頼性のほうで、モデルは早い段階で勝手な思い込みを作り、それに乗った答えを出して、そこから軌道修正できなくなる、と書かれています。 つまり、往復が長くなるほど、こちらの指示より、AIが最初に決めた形のほうが強くなる。往復の質を上げる方向の対策はいくらでもありますが、往復そのものが劣化装置なのだとしたら、丁寧にやるほど効く、という形にはなりません。 永久ループの正体は、たぶんここです。 AIを使うと開発は遅くなる、という有名な測定もあります。[METRが2025年前半に行った試験](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)では、経験のある開発者がAIを使えるときのほうが、実際には19%遅く終わっていました。本人たちは20%速くなったと感じていたのに、です。ただしMETR自身が[2026年2月の更新](https://metr.org/blog/2026-02-24-uplift-update/)で、証拠はごく弱いと断ったうえで、いまの開発者は当時の推定より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に直させて、また別のところが壊れたら、そこで直させるのをやめてください。会話を閉じて、やりたいことを一枚にまとめ直す。捨てているのはコードだけで、あなたの知識は一つも捨てていません。 --- © 黄島成 (Naru Kijima) — CC BY-NC-ND 4.0. 利用前に利用規約（https://narukijima.ai/terms/）を確認してください。検索・AIへの入力・出典付き引用を認めます。AI学習・データセット収録には権利を留保し、追加の許諾は行いません。既存のCC BY-NC-ND 4.0による許諾と法定例外は妨げません。なりすましは禁止です。出典表記: 黄島成 (Naru Kijima) / narukijima.ai — 。検証: https://narukijima.ai/verify/。取得だけで同意を記録する仕組みではありません。 Review the Terms (https://narukijima.ai/terms/) before use. Search, AI input, and attributed quotation are permitted. Rights are reserved for AI training and dataset inclusion; no additional permission is granted for these purposes. Existing CC BY-NC-ND 4.0 grants and statutory exceptions remain unaffected. Impersonation is prohibited. Attribution: 黄島成 (Naru Kijima) / narukijima.ai — . Verification: https://narukijima.ai/verify/. Fetching alone does not record assent.