もう皆さんも 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 が読み書きする速さは、人間とは比べものにならない。
エージェントは数秒で大量のコードを書き、いくつもの選択肢を並べて検討する。
一方、一人の人間が成果物を実際に触り、これは違うこうしてほしいと意味のある判断を返すには、相応の時間と認知の負荷がかかる。
一日に味見できる料理の数には限りがある。
典型的な開発の風景を思い浮かべてみる。
数人の開発者がプロンプトや設計書を書いてエージェントに渡し、出てきた成果物を見て、また指示を書き直して渡す。
一見、エージェントをフル活用しているように見える。
この構図では、情報の流れの細い場所が数人の開発者になっている。
[現実世界の情報]
│
▼
数人の開発者 ← ここが細い
（プロンプトや設計書を書く）
│
▼
エージェント（生成は高速）
│
▼
成果物（大量かつ高速）
エージェント側の生成能力がいくら高くても、上流で情報を注げるのが数人だけなら、製品に注ぎ込める現実世界の情報量はその数人のキャパシティで頭打ちになる。
エージェントが速くなるほど、人間のフィードバックの細さが相対的に際立つ。
これは開発チームが優秀かどうかとは別の、構造的な制約である。
エンドユーザーからのフィードバック
では、この細い場所を広げる方法はあるか。
一つの道は、フィードバックの供給源を数人の開発者から多数のエンドユーザーへ移すことである。
一般大衆を対象とする製品なら、これは現実的になる。
多数の利用者が日々製品に触れ、行動ログ、利用のパターン、離脱の起きる場所、レビュー、問い合わせといったフィードバックが生まれる。
これらを構造化してエージェントに渡す仕組みを作れば、情報の流れは変わる。
何千、何万という利用者の体験を情報源にすることで、注げる現実世界の情報量が桁で増える。
ここでようやく、自走の議論が意味を持つ。
自走の価値は、その長さではなく、途中で現実世界からの情報を取り込めるかどうかにある。
フィードバックのループに現実が組み込まれた自走が、価値ある自律性である。
利用者からのフィードバックを、低遅延で、大量に、エージェントが消化できる形でどう取り込むか。
このデータパイプラインの設計が、これからプロンプトの巧拙以上に効いてくる。
フィードバックの経路を持たない製品
すべての製品がこの恩恵にあずかれるわけではない。
ここに非対称がある。
次のような製品を考える。
- 一般大衆を対象としない製品：特定企業向けの基幹システム、ニッチな専門業務ツール、社内システムなど。利用者が本質的に少なく、統計的に意味のあるフィードバックが集まりにくい。
- エンドユーザーからのフィードバックを得る手段がない製品：あいだに代理店や受託開発が何層も挟まり、開発者が利用者に直接たどり着けない。あるいは機密性やオフライン運用のために利用実態を観測できない。
こうした製品では、供給源を大衆へ広げる道が構造的に閉じている。
情報の流れは、数人の開発者という細い場所を抜けられないまま固定される。
この場合、エージェントがもたらす生産性向上は、一点にとどまりやすい。
ウォーターフォール開発の下流工程が、とても速くなった、というところである。
上流、つまり誰が何をなぜ作るかを決める部分は、依然として数人のフィードバックが細い場所であり、独自性の上限もそこで決まったままになる。
下流、つまり設計をコードに落とし、テストを書き、実装する部分だけが速くなる。
要件定義と設計という細い管を通った情報が、下流で猛烈に実装される。
これは大きな効率化ではあるが、製品が持てる独自性の天井を押し上げはしない。
速く作れることと、正しいものを作れること、独自の価値を持つものを作れることは別である。
前者を後者と取り違えると、凡庸な製品を高速に量産する方向へ進みかねない。
まとめ
論旨を整理する。
- 最近のエージェント活用の議論は、人間の介入なしにどれだけ長く自走させるかに偏っている。
- だが、外部からのフィードバックなしに作られた成果物は、最初に与えた情報量を超える独自性を持てない。
- 「最強の将棋 AI を作って」が無限に自走できるのは、問題が閉じていて外部情報が要らないからである。現実のビジネスは閉じていない。
- LLM はレシピを考案できても味見はできない。成果物が価値を持つかは、現実に接続された人間にしか判断できない。
- ゆえに製品の独自性の上限は、注ぎ込めるフィードバックの情報量で決まる。
- 一人の人間が出せるフィードバックの量は、LLM の速さに対して小さい。数人の開発者がプロンプトを書くだけでは、そこが細い場所になる。
- 一般大衆向けの製品なら、多数のエンドユーザーのフィードバックを直接エージェントに渡して、この細さを避けられる。
- 大衆向けでない製品や、フィードバックの経路を持たない製品では、エージェントの恩恵は下流工程が速くなっただけにとどまりやすい。
エージェント活用の成熟度を測るとき、問うべきは、どれだけ長く無人で走り続けられるかではない。
どれだけ豊かな現実世界のフィードバックを、エージェントのループの中に組み込めているかである。
自走時間は、フィードバックという燃料があって初めて意味を持つ。
これからの開発者の腕の見せどころは、巧みなプロンプトを書くこと以上に、現実世界からの情報を、太く速く構造化された形でエージェントに流し込む仕組みを設計できるかにある。