世界を動かす技術を、日本語で。

HNに聞きたい: エージェンティックコーディングが効果的である証拠はありますか?

2026年1月20日

概要

  • Agentic coding の現状と課題についての疑問
  • 技術的負債 と価値創出のバランスに関する懸念
  • コードレビューの役割 と品質保証の必要性
  • Codex などのAIツール利用時の実体験と限界
  • 長期的な コード品質 維持への不安

Agentic Codingの実態と課題

  • Agentic coding とは、AIや自律的なエージェントがコード生成・修正を主導する開発手法
  • オンライン上では 成功事例や期待感 が多く見受けられる現状
  • 実際には、 技術的負債 を上回る価値を生み出す事例は限定的
  • コードの構造的健全性 を担保するには、現状のAIには限界
  • アーキテクチャ責任者 が承認できるレベルのコード生成は困難

コードレビュー軽視のリスク

  • 最近の潮流として、 コードレビューの省略 や最小化を推奨する意見が増加
  • アーキテクチャの検証 から 動作の検証 へのシフト」という主張
  • 実際には、 テストやCIが通ればリリース という運用が多い
  • この運用では、 スパゲッティコード や微妙なバグの蓄積リスク
  • 長期的には、 保守性や拡張性の低下 が懸念材料

Codex利用時の実体験

  • 既存コードベースへの Codex適用 では、 微妙なミスや重複 の修正に多くの時間を消費
  • 新規プロジェクト(例:iOSアプリ開発)でも、 最初の実装は良好 だが、その後の品質維持が困難
  • バグ修正やベストプラクティスの調査 をAIに任せると、 新たな問題の発生改善の停滞 を経験
  • ガイドラインやガードレール を追加しても、品質向上には直結しない実感
  • 結果的に、 手動での修正やレビュー が不可欠という結論

高品質コードとAI生成の現実

  • 高品質なコード を担保するには、現状では 人間によるレビュー が不可欠
  • AI生成コード は、あくまで「たたき台」や「補助」として活用
  • 製品としての信頼性長期的な保守性 を重視するなら、 コードレビューの省略は非現実的
  • 技術的負債の増加不具合の温床 となるリスクを無視できない
  • 現場での実体験 として、AIだけに頼る開発は、 期待値を下回る成果 という印象

結論:現状のAgentic Codingの限界と今後

  • Agentic coding は現時点で「 過剰な期待」が先行
  • コード品質の担保技術的負債の抑制 には、 人間の関与 が不可欠
  • テストやCIだけで品質保証 する運用は、長期的な視点では推奨できない
  • AIツールの活用 は効率化の一手段だが、 品質保証プロセスの省略 は避けるべき
  • 今後の進化 に期待しつつも、現時点では 適切なレビューとガバナンス が必須

Hackerたちの意見

毎日Claudeを使ってるけど、同じような経験をしてるよ。面白いエピソードとして、知り合いがエージェントを使って新機能のコードとユニットテストを書いたんだけど、コードが微妙に間違ってたんだ。まあ、そういうこともあるよね。でも、追加した30個くらいのテストがテストの実行時間を10分も延ばして、結局「expect(true).to.be(true)」みたいな内容になっちゃった。LLMがテストでコードが動かないのを回避してたからね。

彼らは結局「expect(true).to.be(true)」みたいになってしまった。LLMがテストでコードが動かないのを回避してたからね。 すごく人間的な解決策だね。

先週(?)HNに、新しいモデルでこの挙動を説明した記事があったよ。古い、あまり「能力のない」モデルはタスクを達成できなかったけど、新しいモデルはズルをして、価値のないけど一見機能する解決策を提供するんだ。もっと広い文脈を持ってる人が、その記事を思い出せるといいな。

俺も毎回Claudeにテストを書かせようとするとこうなる。もう諦めたよ。本当にテストが必要なら、自分で書くことにしてる。

自分の経験から言うと、TDDが役立つよ。まずテストを書いて(AIに書かせてもいい)、それを仕様としてレビューしてから実装させる。でも、Claudeのコードを使うときは、ある程度近くで監視してる。勝手にやらせないし、既存のテストに変更を加え始めたら、ちゃんとした理由がないとダメだよ。そうじゃないと、また元に戻すからね。ここでの失敗パターンは、AIに実装とテストの両方を管理させること。高校生に自分の試験を採点させるようなもんだ。みんなA+をもらって、驚きだね!

自分が試してみて、そこそこうまくいったアプローチはこれだよ。まずコミットを作る。Claudeに特にオープンエンドじゃないタスクを与えるんだ。純粋な「単純作業」みたいなものに近いほどいい(自分が扱いたくないタイプのコードね)。できれば、コードベースのファイルを1、2個触るだけのものが理想。 trivialなリファクタリング(同じメソッド呼び出しをあちこちで変更するみたいな)じゃない限りね。計画モードに設定して、計画を立てさせる。計画をレビューして、実行させる。うまくいけばラッキー、次はレビューだ。結構面倒なタスク、例えばコードをあるプラットフォームから別のプラットフォームに移植するみたいなのを一発でやってくれたこともある。明らかなミス(プログラムがビルドできない、テストが通らないなど)があれば、数回のイテレーションで解決できることが多い。微妙なミスがあれば、ブランチを作って再挑戦させる。失敗したら、これはもう無理だってことで、そのブランチを中止して自分で解決する。書いたコードをレビューしてクリーンアップするけど、だいたい必要以上にごちゃごちゃしてることが多い。これでコードのオーナーシップを持てるし、何をしているのか、どう動いているのかも分かるようになる。ガイドラインや制約を与えるのはやめた。あいつはそれを信頼して守れないからね。「このプロジェクトはCMakeを使うから、こうやってビルドして」って言っても、何度も無視されて、makefileを直接間違ったフォルダで呼び出そうとする。これであまり時間が節約できるわけじゃないけど、レビューとクリーンアップに時間がかかるから、いいブロッカーにはなる。あとは、話せるラバーダックとして使ったり、ドキュメントのソースとしても役立ってる。これには結構助かってる。このエージェントたちがコードベースで一緒に働くってアイデアは、俺には面白い。これを「fiverrで雇った前向き健忘症のジュニアたち」に置き換えたら、どれだけうまくいくかって感じだね。

それが正解だね。

正直言って、最大の利点はドキュメントや分析の部分だと思う。「コードを書く」部分は、100%従来のボイラープレートの範囲内にあるときは問題ない。例えば、ffmpegのフロントエンドとしては、LLMからかなりの価値を引き出せる。でも、オープンエンドでデザイン中心になると、心の準備をしておかないと。エージェントの軍団を使うことは、実際には拡大したLispの呪いのような気がする。Gas Townの全体の前提はコーディングの魔法で、抽象的な目標や価値に重点を置いていて、かわいくて理解しにくい命名規則がある。ここには「プログラムは人間が読むためにあり、コンピュータが偶然実行するためのもの」という相関関係がある。最終的には、プログラムは一人の人間が別の人間や自然に向かって話しかけるもので、そういう意味で全体の中で進化しなければならないんだ。

+1、ラバーダックと、ブロッカーとしても。私の使い方は、一度に一つの関数を書く感じだね。何をさせたいかはわかってるから、その関数を書かせて、それを組み合わせる。考慮していないかもしれない代替案も持ってきてくれるし。少しコンテキストを与えることもあるけど、主にタイピングをオフロードしてる。私は通常、自分でデバッグして修正するから、AIにもっと良くさせようとはしない。

Googleの主任エンジニアがTwitterに投稿してたけど、Claude Codeはチームが1年かけてもできなかったことを1時間でやったらしい。2日後、みんなが騒いだ後に、コンテキストが追加されたんだ。チームはその年にいくつかのバージョンを作って、それぞれにトレードオフがあったみたい。それらの情報がAIに与えられて、AIは「おもちゃ」バージョンを作れたんだと思う。おそらく、似たようなトレードオフがあったんだろうね。私の経験もあなたと似ていて、こういうGoogleのエンジニアみたいな人たちが盛り上げて、コンテキストを省いてるから、期待が現実とかけ離れちゃって、フラストレーションや失望につながると思う。

人間はシステムデザインの面接で、UberやGoogle、YouTube、Twitter、WhatsAppなどを45分で設計することがよくある。だから、AIが作るおもちゃのバージョンなんて、あんまりすごくないよね。

あなたは特定のハイプ投稿に焦点を当ててるけど(実際には元の混乱したTwitter投稿の誤解に過ぎない)、多くの有名で才能ある開発者たちがもっとコンテキストを提供して、エージェントコーディングが彼らにかなりのスピードアップをもたらすと言っていることを無視しているよ(Antirez(Redditの創設者)、DHH(RoRの創設者)、Linus(Linuxの創設者)、Steve Yegge、Simon Wilsonなど)。

Hacker Newsで議論の続きを見る