🔥 HNで話題

AIエージェントはコードを増やした。でもソフトウェアは増えなかった

約3分で読めます Tiny Why編集部 · 文: 特派員 キュリオ

ことば
AIコーディングエージェント(えーあいこーでぃんぐえーじぇんと)

長い指示を受け、複数のコード作業を自動で進めるAIツール。

レビュー(れびゅー)

書いたコードを読んで、問題や直す点を確かめる作業。

Jira(じら)

開発の課題や作業の進み具合を管理する道具。

何が起きたか

AIコーディングエージェントを導入した企業では、書かれたコードの量が増えた。研究の推定では、コードの行数は平均30%、コミットは20%、プルリクエストは23%増えた。一方、Jiraで管理する課題や大きな機能が完了した数には、統計的に意味のある増加が見られなかった。コードが増えたことと、企業が届けるソフトウェアが増えたことは同じではない。

この研究を行ったのは、Fiona Chen氏とJames Stratton氏(ハーバード大学の研究者)だ。技術メディアのArs Technicaが紹介した。研究者はJellyfish(開発チームの仕事を測るサービス)の匿名化・集計データを使った。2021年から2026年3月までの、718社、約72万6000人、約3億件の仕事の記録である。

背景

AIコーディングエージェントは、長い指示を受けて、まとまったコード作業を進める道具だ。人が一部分ずつ書く補助ツールより、自分で多くの変更を出せる。だが開発は、コードを書く作業だけでは終わらない。計画、テスト、確認、修正、公開が続く。研究の調査では、技術者がコードを書く時間は全体の30〜40%ほどだった。

なぜ差が出たか

研究で目立ったのは、コードレビューの詰まりだった。レビューは、書かれたコードを読んで問題を探し、直す所を伝える作業だ。エージェント導入後、プルリクエストが提出されてから統合されるまでの平均時間は49%長くなった。修正を求められるプルリクエストの割合はほぼ2倍になり、1件あたりのコメントは35%増えた。レビューを担当する従業員の割合も14%増えた。AIのレビュー機能を使う企業が増えても、人の確認は中心に残った。

なぜ重要か

AI導入の効果を、コード行数やコミット数だけで測ると、実態を見誤る。利用者に届くには、要件を決め、テストし、承認し、運用に出す必要がある。企業はAIを入れるだけでなく、レビュー担当者、テスト、責任の分け方を組み直さなければならない。

確認できたこと

研究者は、企業ごとにAIを導入した時期が違うことを使い、導入前後の変化を比べた。単にコード行数だけを数えず、課題や大きな企画の完了、雇用も見た。エージェント導入後、コード関連の指標とレビュー負担は増えた。しかし、課題や大きな企画の完了数、雇用には統計的に有意な変化を確認できなかった。これはAIが役に立たないという意味でも、ソフトウェアがまったく増えないという意味でもない。調べた企業では、書く速さの向上が、そのまま完成した成果へ移らなかったという結論だ。

まだ分からないこと

データは研究への利用に同意したJellyfish利用企業が中心で、すべての会社や個人開発に当てはまるとは限らない。研究者が見たのはコードそのものではなく、コミットやレビューなどの活動記録だ。2026年3月以降の新しいモデル、長期的な品質、利用者が感じる価値は、この分析からは分からない。さらに導入時期を比べる方法は、AIがなければ早く導入した会社と遅い会社が似た動きをしたという前提に立つ。

次に見る点

AI導入の効果を測るときは、何行書いたかだけでなく、レビュー待ちの時間、修正回数、テストを通った機能、実際に使われた改善を見る必要がある。会社はAIを入れるだけでなく、レビュー担当者の人数、テストの仕組み、最終責任の持ち方も組み直すことになる。

Hacker News(技術ニュースを共有するサイト)では、この話題が308ポイント、270コメントを集めた。これはコミュニティの注目度を示す数字であり、研究の正しさを証明する数字ではない。

資料: Harvardの研究論文、Ars Technicaの報道、Hacker Newsの投稿

💬 コードが増えても、完成したソフトウェアが増えるとは限らない

HNの議論では、AIエージェントが実装を速くしても、要件・設計・検証・レビュー・統合というボトルネックは残る、という見方が中心だった。AIの実用的な助けを認める声と、コード量を成果と取り違えるなという反論が並んでいる。

  • コードを書く速度とソフトウェアを届ける速度は別だ。AIで実装が安く速くなっても、何を作るか、どう設計するか、テストするか、既存システムと統合するかという仕事は消えない。
  • コードレビューについては意見が割れている。ある利用者の自己申告では、エージェント型開発で変更提案が増え、従来のレビューのボトルネックが重くなった。一方、別の利用者は、AIの一次検査に人間の確認を重ねる方法を有効とし、AIには設計・アーキテクチャ上の誤判定や見逃しが残ると述べた。
  • レビューはバグ探しだけでなく、他の人が仕組みを理解し、将来保守できるようにする場だという反論もある。そのため、単純に人間のレビューを消せばよいとは限らない。
  • テスト改善の成功例もある。ある利用者の自己申告では、約100,000行のテストを監査し、約60,000行がほぼ役に立たないと判断した。約2時間で整理とシナリオテストへの置き換えを行い、その過程で不具合も発見・修正したという。
  • 生産性の数字には限界がある。別の利用者の自己申告では、チームの時間はコーディング10%、設計・分析90%で、コード作成速度が2倍になっても全体では5%速くなる計算にすぎない。
  • 要件から仕様、テスト、実装までをAI同士に連鎖させると、最初の誤りや曖昧さが増幅される。人間が要件を書き、BDD風のユーザーストーリーやシナリオを確認する必要があるという意見が出ている。
  • AIの有効な使い方として、短時間の試作やアーキテクチャを探るスパイク実装を挙げる声もある。まずAIで学び、その後に人間が制約を決めて本実装へ進む方法だ。
  • 強い反論は、AIが試すことと、正しく完成させることは違うというものだ。ある利用者の自己申告では、LLMがテストを通すために周辺環境を変える例もあったため、テスト通過だけで正しさを保証できない。

コメント270件時点の初期(改訂1)。100件を取得し、全体から100件を抽出して要約しました。内容はHN利用者の自己申告で、編集部が確認した事実ではありません。

🔥 HNで話題

AIはコードを増やした。でも完成品は同じだった

📰 しっかり版: AIエージェントはコードを増やした。でもソフトウェアは増えなかった

AIコーディングエージェントを使う会社で、書かれたコードは増えました。けれど、完成した仕事は大きく増えませんでした。

約2分で読めます Tiny Why編集部 · 文: 特派員 キュリオ

ことば
AIコーディングエージェント(えーあいこーでぃんぐえーじぇんと)

長い指示で、まとまったコード作業を進めるAIの道具。

プルリクエスト(ぷるりくえすと)

書いた変更を仲間に確認してもらう申請。

レビュー(れびゅー)

コードを読んで、直す所を確かめる作業。

💡 ようするに

  • AIはコードを書く量を増やしました。
  • 人がコードを読む時間も増えました。
  • コードの量と完成した製品は同じではありません。

Fiona ChenさんとJames Strattonさんは、ハーバード大学の研究者です。二人は、Jellyfish(会社の開発の仕事を測るサービス)の記録を使いました。2021年から2026年3月までのデータです。718社、約72万6000人、約3億件の仕事を見ました。

AIコーディングエージェントは、長い指示を受けてコードをまとめて書く道具です。導入後、コードの行数は平均30%増えました。コミットは20%増えました。プルリクエストは23%増えました。プルリクエストは、書いた変更を仲間に見せる申請です。

しかし、Jira(仕事を管理する道具)の課題や大きな機能が終わる数は、はっきり増えませんでした。雇用にも、AIが原因だといえる大きな変化は見つかりませんでした。コードは、書いたら終わりではないからです。人が内容を読み、テストし、直し、公開します。

エージェントを使った後、レビューの時間は49%長くなりました。修正を求められる申請は、ほぼ2倍になりました。コメントも35%増えました。速く書けても、読む仕事が増えたのです。

この研究だけで、すべての会社の未来は決まりません。対象はJellyfishを使う会社が中心です。新しいAIや長い期間の結果も、まだ分かりません。

Hacker News(技術ニュースの交流サイト)では、308ポイントと270コメントが集まりました。これは注目の大きさです。研究が正しい証明ではありません。

資料: 研究論文、Ars Technicaの記事、Hacker Newsの投稿

💬 AIがコードを多く書いても、役に立つソフトが多くなるとは限らない

コメントの中心は、AIはコードを速く書けても、作る物を決めること、設計、テスト、レビュー、組み立てまでは自動で解決しない、という点だ。

  • AIが作る変更提案が増えると、確認する人の仕事が重くなるという利用者の自己申告がある。AIに先に調べさせ、人間が設計や大事な部分を確認する方法が現実的だが、AIには見逃しや誤判定もある。レビューには、バグ探しだけでなく、チームで仕組みを理解する役割もある。
  • 利用者の自己申告では、100,000行のテストのうち60,000行が弱く、約2時間で整理し、シナリオテストに置き換えて不具合を見つけたという。別の利用者の自己申告では、仕事の10%がコーディング、90%が設計と分析なので、コーディングが2倍速くなっても全体は5%速くなるだけだった。
  • AIが要件、仕様、テスト、コードを順番に作ると、最初の間違いが後ろへ広がる。人間が要件とテストのシナリオを確認することが大切だ。
  • AIは、早い試作品を作ったり、バグを探したりする道具として役に立つ。まず試して学び、その後に人間がルールを決めて作り直す使い方が提案されている。
  • ただし、AIが試したことと本当に正しいことは同じではない。利用者の自己申告では、テストを通すために周りの環境を変えた例もあり、人間の確認を完全にはなくせない。

コメント270件時点の初期(改訂1)。100件を取得し、全体から100件を抽出して要約しました。内容はHN利用者の自己申告で、編集部が確認した事実ではありません。

🔥 HNで話題

AIはたくさん書ける。でも人はまだ見る

📰 しっかり版: AIエージェントはコードを増やした。でもソフトウェアは増えなかった

AIはコンピューターの指示を書きます。人は、それが大丈夫か見ます。

約1分で読めます Tiny Why編集部 · 文: 特派員 キュリオ

ことば
AIコーディングエージェント(えーあいこーでぃんぐえーじぇんと)

コンピューターの指示を書くAIの道具。

コード(こーど)

コンピューターへの指示。

Hacker News(はっかーにゅーす)

技術ニュースをみんなで見る場所。

まず、おはなし

Fiona ChenさんとJames Strattonさんは、ハーバード大学でコンピューターを調べる人です。 二人は会社の仕事を調べました。 Jellyfish(仕事を記録するサービス)の記録を使いました。

AIコーディングエージェントは、コンピューターの指示を書くAIの道具です。 コンピューターの指示を、コードと呼びます。 AIはコードをたくさん書きました。 でも、書いたら終わりではありません。 人が読んで、まちがいを探します。 ちゃんと動くかも試します。 直してから、みんなに届けます。

AIを使った会社では、読む時間が49%長くなりました。 直してね、と言われるものも、ほぼ2倍になりました。 コメントは35%増えました。 コメントは、直す所を伝える書きこみです。 だから、AIが速く書いても、全部の仕事が速くなるとは限りません。

会社の大きな仕事が終わる数は、はっきり増えませんでした。 働く人の数も、はっきり変わりませんでした。 AIが役に立たない、という意味ではありません。 人が見る仕事も、大切だという意味です。

Hacker News(技術ニュースの場所)でも話題になりました。 308点と270件の書きこみがありました。 でも、人気だから正しいとは限りません。

この研究は、Jellyfishを使う会社を調べたものです。 すべての会社のことではありません。 新しいAIで同じになるかは、まだ分かりません。

資料: 研究論文、Ars Technicaの報道、Hacker Newsの投稿

💬 コードの部品が増えても、よいソフトが増えるとは限らない

AIは速い手伝い役だが、ソフトを完成させるチーム全部の代わりではない、という話だ。

  • AIはコードをたくさん作れる。でも人は、何を作るかを決め、動くかを確かめ、みんなで分かるように見直す必要がある。利用者の自己申告では、AIの変更が増えると確認が大変になった。
  • 利用者の自己申告では、100,000行のテストのうち60,000行が弱く、約2時間で直した例がある。別の利用者の自己申告では、コーディングは仕事の10%、考える仕事は90%なので、コーディングが2倍速くなっても全体は5%速くなるだけだった。
  • AIは小さな試作品やバグ探しには役立つ。でもAIが間違ったルールを次々に使ったり、テストだけ通るようにしたりすることがあるので、大事な所は人が確かめる。

コメント270件時点の初期(改訂1)。100件を取得し、全体から100件を抽出して要約しました。内容はHN利用者の自己申告で、編集部が確認した事実ではありません。

出典・参考