Coding Agent時代に、開発速度を遅くする

こんにちは！逆瀬川ちゃん (@gyakuse) です！

今日は作らないことの難しさについて、最近考えていることを書いていきたいと思います。

誰でも爆速で作れるようになってしまった

以前の記事で書いたように、新しい時代の開発は速度を生みます。業種・ソフトウェアのタイプや規模にもよりますが、以前とは段違いの開発速度が見込めます。かつてチームで数ヶ月かけていた規模のものが数日で形になることもありえます。

この何でも作れてしまう感覚は、正直すごく楽しいです。アイデアを思いついて、Agentに伝えて、数時間後にはもう動くものがある。寝る前に仕込んでおけば朝にはできている。次から次へと新しいものを作りたくなります。

でも最近、この楽しさの裏側にあるものについて考えることが増えました。

暇に耐えられない

人間は暇が苦手です。

何もしないのは怠けているように感じます。とくに周りがガンガン作っているのを見ると自分も何か作らないとという気持ちが湧いてきます。

自分のプロジェクトで（かつユーザーがいない状態で）好き放題やるぶんには、これはまったく問題ありません。むしろ楽しい。作って壊してまた作り直す、そのサイクル自体が学びになるし、めちゃくちゃ楽しさがあります。

組織になると話が変わる

ただ、これが組織の話になると厄介です。

開発者一人ひとりの出力がAgentによって爆増すると、組織全体の機能追加速度がかつてないペースで加速します。でも顧客が受け取れる価値の量は急には変わりません。機能は増えるのに顧客体験が良くならない、むしろ複雑になって悪くなるという状況が生まれます。

そして実際にリリース速度は上がっています。Anthropicの2026 Agentic Coding Trends Reportによると、Claude Code導入後にエンジニアあたりのマージPR数が67%増加したと報告されています。作れるし、出せる。問題は、その速度で出し続けたものが本当に顧客の役に立っているかどうかです。

せっせと機能を追加しても、それが顧客価値につながらなければ意味がありません。無限に追加された機能は体験を著しく悪くします。設定画面がどんどん膨れ上がり、メニューが複雑化し、初めて触るユーザーが何をすればいいかわからなくなる。これは別にAgent時代に始まった話ではなく、昔からあるfeature creepの問題です。

ただ蛇口を開ける（機能を作る）のが簡単になったのに、蛇口を閉める（作らない判断をする）仕組みはあまり進化していません。いきなり蛇口の水圧だけが桁違いに上がってしまったため、人間側が追いついていないと感じます。feature creepの罠に全員でハマりにいっている感触です。

Break a Pencilの記事がこの感覚を的確に言語化していました。とくにこの一文が好きです。

When addition is nearly free, subtraction looks like laziness (追加がほぼ無料になると、引き算は怠惰に見える)

4年前にもう語られていた

こういう話は昔から十分に議論されてきたものです。

2022年にLayerXの@mosa_siruさんが出した社内資料「開発速度が速い #とは」は本当に好きで2ヶ月おきくらいに読んでいるのですが、今のこの環境下だからこそ意識しなければならないと感じています。

開発速度が速いとは何か。機能の開発（アウトプット）が速いことではなく、顧客への価値提供（アウトカム）が速いことだと書いてあります。使われないものは作らない。作ったものは必ず負債になり、作るほど後の開発速度を落とす。言われた通り作らない。顧客の本当のペインを解決するものを作る。

4年前にこれだけ明確に語られていたことを、なぜ改めて考える必要があるのでしょうか。

水圧が変わった

理由はシンプルで、蛇口にかかる水圧が変わったからです。

2022年当時、機能を1つ作るには少なくとも数日から数週間のエンジニアリング工数が必要でした。この工数自体がフィルターとして機能していたのです。「この機能を作るのに2週間かかります」と言われれば、本当に必要かどうか自然と議論が生まれます。工数という重力が、安易な機能追加にブレーキをかけていました。

2026年の今、同じ機能がAgentを使えば数時間で出てきます。重力が消えたのです。「まあ作ってみればいいじゃん、数時間だし」が通ってしまう。そしてそれが通り続けると、プロダクトはどんどん太っていきます。

一度出した機能は消せない

ここでAgent時代に特有のリスクについて考えておきたいです。

技術的負債はAgentがかなり返せるようになりました。リファクタリング、テスト追加、古いAPIの移行などなど、こういった仕事はAgentの得意領域です。だからとりあえず作って、後でAgentに直させればいい、というのは一見合理的です。

でも一度提供してユーザーがつき始めた機能は、技術的負債とは違う種類の負債を生みます。ユーザーがその機能に依存し始めるのです。消せばユーザーが離れる。変えれば混乱が起きる。たぶん使われてないだろうと思って消した機能が実は特定のユーザーにとってクリティカルだった、という話は珍しくありません。

技術的負債はAgentが返せるようになってきました。たぶん。でもユーザー負債はAgentには返せません。コードは書き直せますが、ユーザーの期待は書き直せないのです。

開発の負債は背負いやすくなりました。だからこそ、提供してしまった後の負債のほうが怖いと思います。一度開けた蛇口は、開けるときの何倍もの力がないと閉められません。

Go/No-Goの判断が全て

開発が爆速になった分、何を作り何を作らないかの判断が全てになってきていると思っています。

アイデア出しはAgentが壁打ち相手になってくれます。実装はAgentがほぼやってくれます。レビューも、今日リリースされたAnthropicのCode Reviewのように、人間がレビューする前の段階で複数のAgentがロジックエラーやセキュリティ脆弱性、エッジケースを並行して検出してくれる仕組みが出てきました。従来のCI/CDがフォーマットやテストといった機械的なチェックを担っていたのに対し、これはコードの意味を理解した上でバグを見つけてくれます。セキュリティ領域でもClaude Code SecurityやShannon、StrixのようにAgentが脆弱性を自動検出・検証するツールが出てきており、レビューの各レイヤーがAgent化されつつあります（ところで、Claude Code Securityは$15-25/reviewとBlogのCost欄に書いているように見えます。つまり、レビューのコストは実装の何倍も原理的にかかると考えたほうがよいです。この点はよく考える必要があります）。

でもこれを作るべきか、作らないべきかの判断はまだ自動化できていない組織が多いと思われます（その判断すら自動化させていく流れとなる気がしますが、一旦ここは2026年3月現在の見解で話を進めます）。ここで蛇口を開けすぎると、パイプラインがどれだけ優秀でも出てくるのは顧客価値のない機能の山となりえます。

しないことには苦労がいる

ここまで書いてきて思うのは、しないことには苦労が必要であるということです。

やることのコストは激減しました。一方でやらないことを決めるコストは変わっていません。むしろやれるのにやらないという判断は以前より苦しくなっています。相対的にやらない判断のコストが跳ね上がっているのです。

mosaさんの資料のバシバシやらないことを決めることはAgent時代にはより一層の覚悟が要ります。本当につらい。周りがどんどん作っている中でうちはこれを作りませんと言い切るのは勇気がいります。でもその勇気こそが、プロダクトを太らせずにユーザーに本当の価値を届けるための条件なのだと思います。

Agentが裏で動いている時間に、本当に必要なものだけを選ぶ。その選ぶ時間こそが、たぶん今いちばん価値がある行為だと感じています。効率だけを追い求めた先には体験の悪さや使われない機能の山があるだけです。

何を作るかではなく、何を作らないか。その判断に時間と労力をかけること。速い時代だからこそ、立ち止まることに意味があるのだと思うのです。