小編精選 - 技術文章翻譯 · 06月28日

我不太感興趣 Loop Engineering 的理由

もう皆さんも LLM が吐き出した薄っぺらいスロップを読まされるのには飽き飽きしているでしょうから、最初に TL;DR を含むプロンプトを貼っておきます。

以下の論旨に沿って、元の5倍程度の文章量で Qiita に投稿するための記事の完成版を書いてください。

最近のコーディングエージェント活用手法の話題はいかにエージェントを人間の介入なしでより長く自走させるかという点に重きを置きすぎている。
しかし外部からのフィードバックなしで作られる成果物は、最初に与えたプロンプトやスキルが持つ情報量を超える独自性を持つことはできない。
例えば「最強の将棋 AI をトレーニングして」と指示すればエージェントは永遠に作業し続けられるが、それは将棋のルールをエージェントが最初から知っていてそれがずっと変わらないことに依拠している。
現実のビジネスでは業界を取り巻く状況は日々変化するし、製品の機能や品質は利用者からのフィードバックを基に適応していかなければならない。
AI は料理のレシピを考案したり効率的な調理方法を研究したりすることはできるが、作られた料理がどれくらい美味しいかどうかを自分では判断できない。
製品が価値ある独自性を持つためには、成果物に人間が触れてフィードバックを与えることが重要。その情報量が製品が持てる独自性の限界を決める。
一人の人間が生み出せるフィードバックの量は LLM が読み書きする速さに比べれば高が知れている。
数人の開発者がプロンプトや設計書を書いて AI に与えるのを繰り返しているだけでは、そこが AI に与えられる情報量のボトルネックになる。
一般大衆を対象とする製品であれば、たくさんのエンドユーザーからのフィードバックを直接 AI に与えることで、このボトルネックを避けられる。
製品が一般大衆を対象としていない場合や、エンドユーザーからのフィードバックを得る手段がない製品の場合、AI がもたらす生産性向上は「ウォーターフォール開発の下流工程がめちゃくちゃ速くなった」だけに留まりそう。

以下が生成された本編ですが、今言ったとおりそれは蛇足なので、最近話題になった日本語技術文書の文章規範スキルの効果を見てみたい人だけが読めばいいと思います。なお、生成には Claude Opus 4.8 を使用しました。

(追記: 記事を公開した後でファイルを片付けていたところ、最初に生成した時にスキルファイルの置き場所を間違えていてスキルが効いていなかったらしいことに気付きました。現在の記事はスキルを使って再生成したものに差し替えてあります。)

自走時間をめぐる議論

コーディング代理人的活用法をめぐる議論は，近來ある一點に集中している。
人類介入なしに，代理人をどれだけ長く自走させられるか，という點である。

「一晩で功能を一つ作り終えた」「人が見ていない數時間で數千行を書いた」といった報告が，活用成熟度を測る指標のように扱われる。
自律性が上がること自體は進步であり，退屈な定型作業を任せられるのはありがたい。

ただ，自走時間の長さを競う風潮には見落としがある。
外部からのフィードバックを受け取らないまま作られた成果物は，最初に與えたプロンプトやスキルが持つ情報量を超える獨自性を持てない。
これがこの記事で述べたいことである。

製品が價値ある獨自性を持てるかどうかを決めるのは，代理人的自走時間ではない。
人類が成果物に觸れて返すフィードバックの情報量である。
以下では，なぜそう言えるのかを順に示す。

なぜ將棋 AI は無限に自走できるのか

自走そのものが惡いわけではない。
問題は，何に對して自走しているかにある。

たとえば「最強の將棋 AI を訓練して」と指示したとする。
このタスクなら，代理人は理屈の上で永遠に作業を續けられる。
自己對局を繰り返し，評價函數を改善し，また自己對局へと戻る。
このループは外部からの入力をいっさい必要としない。

これが可能なのは，代理人が賢いからではない。
將棋のルールが最初から完全に分かっていて，しかもそれが變わらないからである。
盤面の大きさも，駒の動きも，勝敗の判定も固定されている。
強さは勝率という形で自己完結的に測れる。
勝ち負けというフィードバックさえ，代理人は自分自身との對局によって内部で作り出せる。

つまりこのタスクには，外部世界からの新しい情報が要らない。
將棋 AI が長く自走できるのは，問題が閉じているからである。

閉じた問題と、開いた問題

實際に作っている軟體產品の大半は，將棋とは逆の性質を持つ。

產品を取り卷く狀況は閉じていない。
競爭對手が新機能を出し，規制が變わり，利用者の期待値が上がる。
何が良い製品なのかという基準そのものが，時間とともに動く。
利用者がどこでつまずき何を求めているかは，外から觀測しなければ分からない。

產品の機能や品質は，利用者からのフィードバックを基に作り替え續けるしかない。
昨日まで正解だった仕様が，今日には的外れになることも珍しくない。

將棋にはルールブックがあるが，現實のビジネスにはない。
あるとしても，それは絶えず書き換えられていく。
閉じた問題なら無限に自走できるが，開いた問題は，外から情報を入れ續けない限り前へ進めない。

成果物の價値を誰が判斷するか

この違いを，料理で考えてみる。

LLM は料理のレシピを考案できる。
膨大な知識を組み合わせて新しい取り合わせを提案し，調理の手順を効率化し，食材のコストを最適化することもできる。
レシピを生成する速さと網羅性では，LLM は人類を上回る。

それでも LLM にできないことがある。
出來上がった料理がどれくらい美味しいかを，自分では判斷できない。
美味しさは，食べる人類の體験の中にしか存在しないからである。
鹽分濃度の數値でも營養素の充足率でもなく，誰かが口に運んで美味いと感じる，その體驗そのものが美味しさである。
レシピをどれだけ高速に量産しても，味見をする人類がいなければ，それが價値あるレシピなのかを知る手立てはない。

軟體產品も同じである。
代理人は功能を實裝できるが，それが使いやすいかどうかは判斷できない。
畫面を設計できるが，それが氣持ちよく使えるかどうかは判斷できない。
仕様を滿たすコードを書けるが，その仕様が顧客の本當の課題を解いているかどうかは判斷できない。
成果物が現實世界で價値を持つかどうかの判斷は，現實に接續された存在，つまり人類からのフィードバックなしには得られない。

獨自性の上限を決めるもの

ここから，情報量の話に進む。

代理人が生む成果物の獨自性は，與えられた情報量を超えられない。
代理人は，最初に與えられたプロンプト，スキル，設計書と，學習済みの一般知識を組み合わせて成果物を作る。
どれだけ長く自走させても，外から新しい情報が入らない限り，していることは與えられた情報の組み替えである。
組み替えのバリエーションは膨大でも，その全體は最初の入力という袋の中に収まる。

將棋 AI が生む棋譜が無數にあっても，それらはすべて將棋のルールという固定された情報から導かれていた。
だから自己完結できた。
ところが現實の製品では，自社の製品が顧客にとって價値を持つための固有の情報は，最初のプロンプトには入っていない。
それは現實世界の中，利用者の體驗の中，市場の反應の中にしかない。

製品が價値ある獨自性を持つには，成果物に人類が觸れてフィードバックを返すことが要る。そのフィードバックの情報量が，製品の持てる獨自性の上限を決める。

フィードバックを與えずに自走させ續けても，成果物は世間並みのベストプラクティスの再生産へ近づくだけである。
似た汎用 LLM に似た指示を出せば，似た無難な成果物が返る。
それは獨自性とは逆の方向にある。

人類が出せるフィードバックの量

ここで厄介な問題が出てくる。
フィードバックが獨自性の源だと分かっても，次はその供給量が壁になる。

LLM が讀み書きする速さは，人類とは比べものにならない。
代理人は數秒で大量のコードを書き，いくつもの選擇肢を並べて檢討する。
一方，一人の人類が成果物を實際に觸り，これは違うこうしてほしいと意味のある判斷を返すには，相應の時間と認知の負荷がかかる。
一日に味見できる料理の數には限りがある。

典型的な開發の風景を思い浮かべてみる。
數人の開發者がプロンプトや設計書を書いて代理人に渡し，出てきた成果物を見て，また指示を書き直して渡す。
一見，代理人をフル活用しているように見える。

この構圖では，情報の流れの細い場所が數人の開發者になっている。

[現實世界の情報]
│
▼
數人の開發者 ← ここが細い
（プロンプトや設計書を書く）
│
▼
代理人（生成は高速）
│
▼
成果物（大量かつ高速）

代理人側の生成能力がいくら高くても，上流で情報を注げるのが數人だけなら，製品に注ぎ込める現實世界の情報量はその數人のキャパシティで頭打ちになる。
代理人が速くなるほど，人類のフィードバックの細さが相對的に際立つ。
これは開發チームが優秀かどうかとは別の，構造的な制約である。

エンドユーザーからのフィードバック

では，この細い場所を廣げる方法はあるか。

一つの道は，フィードバックの供給源を數人の開發者から多數のエンドユーザーへ移すことである。

一般大衆を對象とする製品なら，これは現實的になる。
多數の利用者が日々製品に觸れ，行動ログ，利用のパターン，離脱の起きる場所，レビュー，問い合わせといったフィードバックが生まれる。
これらを構造化して代理人に渡す仕組みを作れば，情報の流れは變わる。
何千，何萬という利用者の體驗を情報源にすることで，注げる現實世界の情報量が桁で増える。

ここでようやく，自走の議論が意味を持つ。
自走の價値は，その長さではなく，途中で現實世界からの情報を取り込めるかどうかにある。
フィードバックのループに現實が組み込まれた自走が，價値ある自律性である。

利用者からのフィードバックを，低遲延で，大量に，代理人が消化できる形でどう取り込むか。
このデータパイプラインの設計が，これからプロンプトの巧拙以上に効いてくる。

フィードバックの經路を持たない製品

すべての製品がこの恩惠にあずかれるわけではない。
ここに非對稱がある。

次のような製品を考える。

一般大衆を對象としない製品：特定企業向けの基幹系統、ニッチな專門業務ツール、社內系統など。利用者が本質的に少なく，統計的に意味のあるフィードバックが集まりにくい。
エンドユーザーからのフィードバックを得る手段がない製品：あいだに代理店や受託開發が何層も挟まり，開發者が利用者に直接たどり着けない。あるいは機密性やオフライン運用のために利用實態を觀測できない。

こうした製品では，供給源を大衆へ廣げる道が構造的に閉じている。
情報の流れは，數人の開發者という細い場所を抜けられないまま固定される。

この場合，代理人がもたらす生産性向上は，一點にとどまりやすい。
ウォーターフォール開發の下流工程が，とても速くなった，というところである。

上流，つまり誰が何をなぜ作るかを決める部分は，依然として數人のフィードバックが細い場所であり，獨自性の上限もそこで決まったままになる。
下流，つまり設計をコードに落とし，テストを書き，實裝する部分だけが速くなる。
要件定義と設計という細い管を通った情報が，下流で猛烈に實裝される。
これは大きな效率化ではあるが，製品が持てる獨自性の天井を押し上げはしない。

速く作れることと，正しいものを作れること，獨自の價値を持つものを作れることは別である。
前者を後者と取り違えると，凡庸な製品を高速に量産する方向へ進みかねない。