コーディングは「解決」したのに、なぜソフトウェアは劣化し続けるのか──ボトルネックは「書く」から「決める」に移っただけだった

銀行アプリを開くたびに顔認証を3回求められる。Slackを開いていただけなのに、突然フォーカスを奪われて入力中の文章が消える。車のインフォテインメントシステムが、走行中に再起動する。こうした「ちょっとした壊れ方」に、心当たりはないでしょうか。

2026年7月、この体感を言語化した1本のブログ記事がHacker Newsで話題になりました。タイトルは “Nothing works and everyone is euphoric”（何も動かないのに、みんな浮かれている）¹。著者のPiotr氏は、銀行アプリのFaceID認証、Slackのフォーカス問題、車のインフォテインメント、Google Maps、macOS、Android Autoなど、身近な製品の品質劣化を次々と挙げながら、こう問いかけます。「AIというこれほど強力なツールが手元にあるのに、なぜソフトウェアはよくならないのか」と。

この記事がHacker Newsに投稿されると、876ポイント・678コメント（2026年7月27日時点）という大きな反響を呼びました²。本稿では、この議論の中身と、そこから見えてくる「経営判断」の課題について整理します。

「コードは書けるのに、良くならない」というモヤモヤ

Piotr氏の指摘の核心は、KPI偏重の組織構造への皮肉にあります¹。

“This quarter, we won’t be releasing any new features, and we have no plans to redesign anything — we will exclusively focus on fixing bugs.” （今四半期は新機能をリリースせず、リデザインの予定もありません。私たちはバグ修正だけに専念します）

こう宣言するプロダクトマネージャーは、存在しません。新機能や成長KPIを追い続けることは評価され、安定性の向上は「プレゼン映えしない」からです。AIによってコードを書く速度そのものは劇的に上がりました。しかし、それがそのままプロダクトの品質やUXの向上に結びついていない ——多くの経営層・事業責任者が、薄々このモヤモヤを感じているのではないでしょうか。

Hacker Newsで876人が支持した問い

この投稿につけられた678件のコメントの中には、単なる愚痴では終わらない、構造的な指摘がいくつも並んでいました。特に支持を集めた3つの論点を見ていきましょう。

経営層の非技術的判断（alphazard）

最も支持されたコメントの一つが、alphazard氏によるものです。

“The taste-making apparatus inside the typical tech company is now entirely imposters (non-technical, non-power-users), who continue to LARP as visionaries. The people who notice broken or degraded behavior (devs and power users) and conceive of good designs are not in charge of what goes into the product.”³

日本語に訳すと、「多くのテック企業で製品の方向性を決める立場にいるのは、いまや非技術者ばかりだ。壊れた挙動に気づき、良い設計を発想できる開発者やパワーユーザーは、製品に何を入れるかを決める権限を持っていない」という趣旨です。同氏はさらに、「組織が出荷する品質は、意思決定者のスキルに比例する」とも述べています³。

VCが顧客化したビジネスモデル（bravoetch）

もう一つの有力な指摘が、bravoetch氏によるビジネスモデルの変化です。

“Old business models: Add value for the end-user, sell it on for a profit. Current business model: venture capital is the end-user now. Grow the investment by addicting customers to some distraction.”⁴

「かつてのビジネスモデルは、エンドユーザーに価値を提供し、その対価として利益を得るものだった。しかし今のビジネスモデルでは、ベンチャーキャピタルこそが『最終顧客』になっている。何かに顧客を依存させることで投資を成長させることが目的になっている」という指摘です。プロダクトの向き先が、使う人ではなく投資家に向いてしまっているのではないか、という問いかけです。

AI生成コードの雑な量産（TacticalCoder）

3つ目は、AIの使い方そのものへの指摘です。TacticalCoder氏はこう述べています。

“I use AI daily: it saves some time. But it produces an infinite amount of insecure, unnecessary, sloppy-pasta. And that sloppy-pasta doesn’t make software any better.”⁵

「私も毎日AIを使っていて、時間の節約にはなる。しかし、AIは安全性に欠け、不要な“sloppy-pasta（雑なコピペコード）”を無限に生み出す。そしてそのsloppy-pastaは、ソフトウェアを何も良くしない」という趣旨です。

本質を突いていたのは、この一言だった

数あるコメントの中で、筆者が最も本質を突いていると感じたのは、gyomu氏による次の指摘です。

“You can build software fast, but the more time you take the more you can be confident about it being correct. […] it seems like way too many software developers right now are happy to take the gains of the former but ignore the tradeoffs of the latter.”⁶

「ソフトウェアは速く作れる。しかし時間をかければかけるほど、それが正しく動くという確信は強くなる。[中略]今、あまりに多くの開発者が、前者（速さ）の恩恵だけを享受し、後者（確信を得るための時間）というトレードオフを無視しているように見える」——これは、AI時代のソフトウェア開発が抱える問題を、驚くほど正確に言い当てています。

ここで一つ、視点を移してみます。gyomu氏のコメントは「開発者の姿勢」を主語にしていますが、筆者はこれを一歩進めて、こう再定義したいと思います。速さの恩恵だけを享受し、検証への投資を怠るという判断を、そもそも最終的に許可しているのは誰でしょうか。それは現場のエンジニアではなく、リソース配分とKPI設計の権限を持つ経営層・事業責任者・投資家です。つまり、AIによって本当に変わったのは「コードを書く速度」であり、「何にどれだけの時間とリソースを割くかを決める速度」は、何一つ変わっていません。この非対称こそが、劣化の正体だというのが本稿の見立てです。

「非対称」を裏付ける数字

これは単なる印象論ではなく、複数の独立した調査によって裏付けられる構造的な事実です。

85%が気づいている、しかし追いついていない

GitLabが2026年に発表した「AI Accountability Report」は、The Harris Pollの協力のもと、6か国1,528名の開発者・技術購買担当者を対象に実施されました⁷。この調査では、次のような回答が得られています。

85%が「AIによってボトルネックが『書く』から『レビュー・検証』へ移った」と回答⁸
80%が「組織はガバナンス体制を整える前にAIツールを導入した」と回答⁷
73%が「AI生成コードの保守性に懸念がある」と回答⁷

さらに興味深いのは、87%が「AI生成コードが原因のインシデントかどうか、24時間以内に判断できる」と自信を示す一方で、実際にインシデントを経験した組織のうち34%は、その判断ができなかったという結果です⁸（この87%と34%は同じ集団の推移ではなく、別々の質問に対する回答である点にご留意ください）。「自分たちは把握できている」という自己認識と、実際の対応力の間には、無視できないギャップがあるということです。

個人は速くなった。組織は速くなっていない

さらに踏み込んだデータが、Faros AIの「AI Productivity Paradox Report 2025」です。10,000人以上の開発者、1,255チームのテレメトリデータを分析したこの調査によれば、AIを利用する開発者はタスクを21%多くこなし、プルリクエストを98%多くマージしています⁹。ここまでは、多くの経営層が期待する「生産性向上」そのものです。

しかし同じ調査は、その裏側も明らかにしています。プルリクエストのレビュー時間は91%増加し、開発者一人あたりのバグは9%増加、平均プルリクエストサイズは154%増加しました⁹。そして最も重要なのは、次の一文です。

“No significant correlation between AI adoption and improvements at the company level.”⁹

「AIの導入と、会社全体のレベルでの改善との間には、有意な相関が見られない」——個人レベルでは生産性が上がっているように見えても、それが組織全体の成果には結びついていないのです。

この知見は、Faros AI社単独の見解にとどまりません。GitLabの調査でも「79%が、開発プロセス全体はコーディングの速度に追いついていない」と回答しており⁸、まったく独立した2つの調査機関が、同じ結論に達しています。個人の生産性と組織の成果が乖離しているという構造は、一過性の感覚論ではなく、データで裏付けられた事実だと言えるでしょう。

検証ゲートへの投資は、経営判断である

では、この非対称にどう向き合えばよいのでしょうか。筆者たちが日々運用している、ブログ記事の執筆パイプラインでの経験が、一つのヒントになります。

私たちは、AIエージェントに記事の草稿を書かせるだけでなく、公開前に懐疑的な読者の視点で事実・技術的主張をレビューする検証ゲートを設けています¹⁰。実際にこの検証ゲートによって、品質基準を満たさないと判断された記事草案を、公開せずに破棄した実例もあります¹¹。

重要なのは、この検証ゲートは「開発チームが勝手に工夫した内輪のプロセス」ではないということです。生成速度をただ上げるのではなく、検証に時間とリソースを割くという判断そのものが、経営判断です。何にどれだけ投資するかを決めるのは、常に意思決定者の役割だからです。

この構造は、実は目新しいものではありません。Stripeが2018年に実施した「The Developer Coefficient」という調査では、開発者の36%が「四半期・年次の成果ばかりを優先し、長期的な成長を優先できていない」ことを、技術的な課題に対応できない障壁として挙げていました¹²。同じ調査では、C-level経営層の96%が「開発者の生産性向上は経営の優先事項だ」と回答する一方、開発者自身の自己評価による生産性発揮度は平均68.4%にとどまっていました¹²（この2つの数値は測定している対象が異なるため、統計的な対応関係というより、認識と実感のギャップを示す並置として捉えてください）。

この調査はAI以前、2018年のものです。つまり、KPI偏重・四半期思考という土壌は、もともと存在していました。AIによる生成速度の急上昇は、その土壌の上で、書く速度と決める速度の非対称を一気に押し広げたのだと考えられます。土壌は今に始まったことではありませんが、非対称の振れ幅は、AI以前とは比べものにならない規模になっているのです。

今四半期、あなたは何に投資すると決めたか

冒頭で紹介したPiotr氏の皮肉、「今四半期は新機能を出さず、バグ修正だけに専念します」と言うPMは存在しない、という指摘に戻ります¹。

この皮肉は、開発チームだけに向けられたものではありません。むしろ、その意思決定を最終的に下すのは、経営層・事業責任者自身です。AIによってコードを書く速度が上がったからこそ、次に問われるのは「その速度で生まれた余力を、何に投資するか」という決定の質です。機能追加のKPIだけを追い続けるのか、それとも検証・レビュー体制への投資という、目立たないけれど本質的な意思決定に踏み出すのか。

今四半期、あなたのチームは、検証と品質にどれだけのリソースを配分すると決めたでしょうか。もしその答えに迷いがあるなら、AI導入時のガバナンスや検証体制の設計について、一度整理してみる価値があるかもしれません。ご関心があれば、コンタクトフォームよりお気軽にご相談ください。