コーディングエージェントに 18 万行書かせて見えた限界と運用の勘所

まず結論 — エージェントは「量」を出せても「設計」は出さない

運用者としての結論を先に置きます。コーディングエージェント（AI が Issue を読んでコードを書き PR まで出す仕組み）は、コードの量を出すのは桁違いに速い一方で、設計の一貫性や保守性は勝手には守ってくれません。だから人間の仕事は「コードを書くこと」から「何を作りたいかを定義し、規約を渡し、出力を測ること」へ移ります。

この線引きをはっきり書いてくれているのが、Zenn に上がっていたコーディングエージェントで自作 DB を開発した記録です。著者は GitHub のエージェントを使い、推薦システム用のデータベースを 1 週間で 18 万行・200 以上の Issue / PR として生成しています。読みどころは、その量に驚く話ではなく、量を出した結果どこが壊れ、どう手綱を握り直したかという運用の順序です。便利だからと全部を任せると、後から保守できないコードの山を相手にすることになります。

何が起きたか — 1 週間で 18 万行、そして 3000 行のホットスポット

具体的に起きたのは、量のスケールに設計が追いつかない、という現象です。著者によれば、エージェントは 1 週間で 18 万行規模のコードを 200 超の Issue / PR にして書き、コミット数は人間の開発者をはるかに上回ったそうです。ところが複雑なロジックに差しかかると、1 ファイルに 3000 行クラスのホットスポット（処理が一箇所に密集した塊）が生まれ、自動解析でそこを直そうとしてもうまくいかないことが多かった、と書かれています。

この「量は出るのに、肝心の難所だけ巨大化する」のが運用者にとって一番こたえる症状です。私も自分のブログの自動投稿パイプラインを組んでいて似た経験をしました。AI に下書きを書かせる skill を増やすほど 1 本あたりの行数は伸びるのに、本当に効くのは「公開前に私が目を通す品質チェックの数行」だったりする。金曜の夜に MacBook Air の前で生成ログを眺めながら、行数と価値は比例しないなと小さく笑ってしまいました。量が出ること自体は、品質の保証には一切なりません。

なぜ量が増えるほど壊れるのか — 最短距離志向

理由を一言でいうと、LLM の出力は「いま渡された Issue を最短で満たす」方向に強く引っ張られ、将来の保守や全体の一貫性まで自発的に面倒を見ないからです。だから 1 件 1 件は通っても、積み上がると重複したロジックや巨大な関数になり、ホットスポットができます。

ここは設計パターンを事前に渡せるかどうかで結果が変わります。著者は、デザインパターンや規約をリポジトリに「スキル」としてコミットしておき、エージェントがそれを読んでから実装する形にしていました。私の運用でも同じで、SKILL.md は 220 行で切られる前提で書くに書いたとおり、AI に渡す規約は長く書けば効くわけではなく、読み切れる分量で要点を構造化して初めて守られます。規約を渡さずに量だけ出させると、最短距離の集合体になって崩れる。順序が逆だとあとで効きません。

運用の勘所 — Issue を基点に、規約を渡してから書かせる

運用の肝は、人間が Issue で「何を・どの規約で作るか」を先に固め、実装だけをエージェントに渡すことです。著者の構成は分かりやすくて、GitHub の Issue を開発の基点に据え、人間がそこでタスクを精錬し、エージェントが実装して PR を返す、という流れでした。コードを書く速度ではなく、タスクを定義する精度が成果を決めます。

この「呼ぶ前に絞る」発想は、私がLLM API のコスト暴走を『呼ばない』で防ぐ三段防御で書いた筋とまったく同じです。実装を任せる範囲を Issue で狭く切るほど、レビューも原価も読めるようになる。逆に「いい感じに作って」と広く投げるほど、出てくる PR の幅が大きすぎてレビューが破綻します。どのモデルにどの粒度を任せるかは、Opus 4.8 の effort 制御を実務で読んだときの感覚と地続きで、難所の判断は重いモデルに一回、定型の実装は軽いモデルに数多く、と役割で割り当てるのが素直です。

測ることを最優先にする — ログで手綱を握る

もう一つの勘所は、LLM の挙動を理屈で抑え込もうとせず、まずログとメトリクスを取れる形にしてから運用することです。著者も「LLM に逆らわず、計測とレポート生成を優先する」という方針を挙げていました。出力が揺れる前提で、何が起きたかを後から数えられるようにしておく。これが効きます。

私が自動投稿で先に作ったのも、凝った制御ではなく「何本書けて何本が品質ゲートで止まったか」を毎日数える仕組みでした。自動化の対象は勘ではなく測定で決めるに書いたとおり、理論値ではなく実ログから分布を見て初めて、どこを締めるべきかが分かります。エージェントに大量に書かせるなら、書かせる前にログの蛇口を用意しておく。順番を間違えると、壊れたあとで原因を追えません。

私ならどう導入するか — 量より「定義と検証」に人を置く

最後に運用者としての方針を一つ。コーディングエージェントを入れるなら、私は人間の時間を「コードを書く」ところから引き上げて、Issue でのタスク定義と、出力の検証（レビューと自動テスト）に寄せます。AI に任せるのは実装、人間が握るのは目的・規約・検証、と決めておく。

念のため自分の運用の前提も書いておきます。このブログ自体、AI が下書きを起こし、公開前に私が確認・編集してから出す形で回しています。全自動で無人投稿しているわけではなく、品質チェックと人間レビューという工程を必ず通す。コーディングエージェントも同じで、量を出す部分は任せても、設計の一貫性と「これを世に出していいか」の判断だけは手元に残す。落とし穴は、速さに引きずられてそのレビューの工程を薄くしてしまうことです。18 万行を 1 週間で受け取れる時代だからこそ、読み切れる単位に切って人間が確かめる、という地味な工程が逆に価値になります。