3
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AI Agentは本当に開発生産性を上げるのか?

3
Last updated at Posted at 2025-08-04

個人のお気持ちですが、誰かの助けになれば幸いです🙏

昨今、Agent型AI ── 特にClaude Code ──の導入により開発生産性がn倍になるという惹句ばかりをQiitaやZennやXで見かける。

トレンドを追うため、幾ばくかの間、Claude Code, Gemini CLI, Copilot Agent, Cursor等 Agentを使い倒してみた。その上で、私個人の感想を述べたい。

TL;DR

  • Claude Codeは魔法ではない。Agentを導入するだけで業務の開発生産性が上がると思ったら大間違いだ。
  • 徹底して人間フレンドリー(= 読みやすく・保守しやすく・Joinしやすい開発基盤があること(テストコード、ドキュメンテーション、統一されたコーディング規約、設計、タスク分割、PRの細かい粒度など...))な環境を作らなければならない。
  • そうして初めてAgentフレンドリーになるのであって、人間フレンドリーを差し置いてAgentを入れてもむしろ逆効果で、生成速度が上がる代わりに手戻りが増えることになり生産性は向上しない。

業務でAgentを導入して本当に開発生産性は上がるのか?

確かに、個人開発の側面から見れば、Agentはゲームチェンジャーだ。

初期の要件定義の壁打ちから、設計書の作成、アーキテクチャの選定、実装計画、タスク分割、チケット分け、テスト作成、実装。1文字もコードを書かずにアプリが完成する。指示の出し方を工夫するだけで、私の能力を大幅に超えた成果物が、途方もなく楽に出来上がってしまう。

「自分でゴールを決められて、自分で責任を取れる」 成果物に対して、Agentはかなり適正がある。


だが、業務の側面から見れば話は異なってくる。

業務開発の現場は、0から自由に構築できる個人開発とは全く異なる論理で動いている。

過去の意思決定の積み重ねである既存のコード、守るべき設計思想、技術的負債といった文脈をAgentは理解できない。その結果、Agentが生成するコードは、単体で見れば正しくとも、プロジェクト全体の設計思想から乖離している 「外面だけ綺麗な技術的負債」 となる。

Agentが生成したコードの品質を担保するためには、結局のところ人間によるレビューが不可欠となる。レビュワーは、コードの正しさに加え、Agentが理解できなかったであろうプロジェクト固有の文脈まで考慮して、その是非を判断しなければならない。

そして、特に問題となるのは、ドキュメントやテストコードが不十分で、人間にとっても読解が困難なコードベースにAgentを導入した場合だ。レビュワーは、Agentの提案を評価する以前に、まず既存の複雑なコードを解読し、変更による影響範囲を特定するという、極めてコストの高い作業を強いられる。

つまり、「人間が読みやすく、理解しやすい」状態になっていないコードベースにAgentを導入しても、Agentが生成したコードの妥当性を検証するコストが増大するだけなのだ。レビューするのは結局人間なのだから、ボトルネックになるのも当然だ。

クソデカPRを投げつけられても逆に人間は疲弊するだけ。リードエンジニアがジュニアのバイブコーディングPRのレビュー専用マシンと化す地獄の現場になる。


実際、多くの企業が「Agentを導入しました」という記事や「業務での役立つTips」を公開している一方で、「導入によって開発速度が定量的にn%向上した」と具体的な成果を主張する企業は、驚くほど少ないのが現状だ。
これは、多くの現場で、期待したほどの生産性向上が見られていないことの証左ではないだろうか。

実際には、導入したはいいものの、大抵の会社で開発速度は速くなっていないのだ。

この記事の反例はFindyの開発で、実際にAgentを使って業務で開発生産性を上げている。
しかし、実際にお話を伺ってみると、その理由は5年前から徹底して読みやすい・保守しやすい・joinしやすい開発基盤を整えていたからAgentがそこに乗っかれただけであり、Agentのために特別なことをしたわけじゃないらしい。

結論

真に開発生産性を向上させたいのであれば、まず取り組むべきは、Agentの導入ではなく、人間フレンドリーな環境の整備に他ならない。

では、人間フレンドリーな環境を構築するための具体的な行動とは何か?

  • 第一に、設計やアーキテクチャに関する意思決定の背景を明文化すること。
  • 第二に、テストコードを単なる品質保証の手段ではなく、コードの振る舞いを定義する「実行可能な仕様書」として整備すること。
    • テストコードは暴走するAgentのガードレールになる。
  • 第三に、一つのタスクの粒度を、Agentが単一の責任範囲で完遂できるレベルまで細分化すること。
    • 人間が課題を分析・分解し、スコープの限定された指示をAIに与えることで、Agentは質の高いコードを生成する。
    • その結果として、レビューの対象は小さく、意図が明確なコードに限定され、人間はより高度な設計的判断に集中できる。

これらは正直言って今すぐにすべてを解決できるものではない。
「テストを書く」と言っても、テストを書きやすいアーキテクチャになっていなければ、本質的な解決とは言えないだろう。

だからこそ1つ1つ丁寧に、時間がかかっても、人間ファーストの再設計をしていかなければならない。


お気づきかと思うが、これはどれも別に、Agentの有無にかかわらず、健全なソフトウェア開発に求められるプラクティスだ。

トレンドなっているAgentの導入だが、こうした開発基盤の未熟さを顕在化させ、その重要性を再認識させる契機となれば、それは嬉しいことだろう。

参考


これからもQiitaで発信していくので、気になったらぜひいいね・フォローお願いします!

3
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?