「可能な限りコードを書かない」——AI時代の新たな規範

AIはコード生成コストを下げたが、プロダクトリスクは変わらない

近年、Codex、Cursor、Claude Code、GitHub Copilot、DevinなどのAIコーディングツールが次々と登場し、数分で動作するコードを生成できる。自律ループが人間の介入なしに何時間もAIコーディングエージェントを実行し、チームが睡眠中に変更が蓄積される。出力は印象的だが、危険なのは、誰も進展が起きているかどうかを問う前に、それが進歩のように見えることだ。

別の妥当な実装を生成する限界費用は急落しているが、理解、検証、セキュリティ、保守のコストは下がっていない。この違いは、どのツールが最速かというベンチマーク論争よりも重要だ。

何十年もの間、ソフトウェア構築のコストは製品チームに自然な規律を課していた。エンジニアは高価だった。多くの西側ソフトウェア組織では、小規模な開発チームが給与、福利厚生、管理、ツール、諸経費を含めて年間6桁の投資になることもある。この費用は決断を強いた。すべてを構築する余裕はないため、選択しなければならなかった。プロダクト担当者は優先順位をつけ、ステークホルダーはトレードオフを迫られた。コストはゲートであり、多くの組織がそれを製品規律と誤解していた。

エージェンティックコーディングはそのゲートを弱める。かつて少なくとも一部のチームに「これを構築すべきか？」と問うことを強いた実装コストは、もはや同じ圧力をかけない。組織は、ゲートが機能しなくなったときに何が起こるかを発見している。すべてを構築し、何も検証せず、なぜ製品が誰も求めていない機能の集まりになるのか不思議に思う。それはWordをステロイドで強化し、数十年から数週間に圧縮したようなものだ。

旧ブレーキ：「少ないコード」の背後にあるコストが規律を偽装

ソフトウェア構築のコストは二重の役割を果たしていた。構築するものを制限するだけでなく、自然なレビューポイントも生み出していた。機能の実装に数週間かかるとき、チームは再考する時間があった。誰かがスタンドアップで質問し、デザイナーが不一致に気づき、ステークホルダーが優先順位を変える。遅さはブレーキであり、そのブレーキは有用な仕事をしていた。

しかし、エンジニアリングのコストは決して良い製品規律ではなかった。それは単に製品規律の欠如を隠していただけだ。多くの組織は何年もの間、誤ったものを構築するために高価なエンジニアリング時間を費やしてきた。コストゲートは無駄を遅らせたが、確実に防いではいなかった。

エージェンティックコーディングはすべての制約を取り除くわけではないが、多くの組織が無意識に依存していた制約を弱める。誤った機能は、それが存在すべきかどうかについて誰も真剣な会話をする前に、洗練されたデモ、説得力のあるプロトタイプ、さらには本番環境に到達できるようになった。かつては速度が、判断が介入できる一時停止を生み出すことで組織を保護していた。その保護は消えた。

私たちは今、逆転に直面している。以前は誤ったものを構築しても生存可能だった。なぜなら構築のコストがチームに軌道修正の時間を与えたからだ。エージェンティックコーディングでは、誤ったものを構築することがより速く複合する。コードレビューやバックログ整理セッション中に誤ったものに気づくのではなく、ローンチ後に使用データが横ばいになったときに発見する。

証拠は同じ方向を指す

このパターンはもはや仮説ではない。プロダクトエグゼクティブのRichard Ewingは、2026年1月のBuilt Inの事後報告でまさにこのダイナミクスを説明した。彼のチームは技術的に印象的なAI検索ツールを構築した。ベクターデータベース、最新のLLM、RAGパイプラインを使用し、精度スコアはほぼ完璧だった（nDCG 0.92、旧システム0.65）。デモは魔法のように見えた。彼らはリリースし、採用が上昇するのを待ったが、横ばいだった。

Ewingのチームが最終的にローンチ後にユーザーリサーチを実施したところ、ユーザーに労力を減らす代わりに宿題を与えていたことがわかった。ツールはユーザーに作業フローを止め、サイドバーを開き、プロンプトを書き、応答を待ち、結果をワークに貼り付けることを要求した。誰もそれを望んでいなかった。AI機能がある午後にメンテナンスでダウンしたが、誰もサポートに電話しなかった。なぜなら誰も気にしていなかったからだ。その沈黙がフィードバックだった。

技術的な実行は優れていたが、誤った製品決定を補うことはできなかった。AIは認識された「解決策」を構築しやすくしたが、ユーザーのワークフローを理解しやすくしたわけではない。

Google CloudのディレクターであるAddy Osmaniは、Jeremy Tweiが作った「理解負債」という用語で別の障害モードを特定した。2026年1月の分析で、Osmaniは開発者がAI生成コードをテストに合格しただけで受け入れ、実際に何をするかを理解しない場合に何が起こるかを説明した。彼自身もそれをやったことがある。Claudeが機能を実装し、テストに合格し、コードをざっと見てマージし、3日後にその機能がどう動作するか説明できなくなった。コードベースは成長する。理解は縮小する。

Osmaniは、高AI採用率のチームはプルリクエストを98%多くマージする一方、レビュー時間は91%増加し、プルリクエストサイズは154%増加したという研究を引用している。Faros AIのテレメトリとGoogleの2025年DORAレポートを引用し、どちらもAI採用が既存の組織の強みと弱みを増幅し、壊れたデリバリーシステムを修正しないと警告している。コードレビューが新しいボトルネックになった。変更を生み出す速度は上がったが、その結果を理解する速度は同じように上がらなかった。

セキュリティ面では、Veracodeの2025年GenAIコードセキュリティレポートは、AI生成コードが100以上の大規模言語モデルと80のコーディングタスクにわたるテストの45%でセキュリティ脆弱性を導入したことを明らかにした。モデルは機能的で構文的に正しいコードを生成したが、半数近くでセキュリティ要件を満たさなかった。

文書化された本番障害も同じストーリーを反対側から語っている。Lovableプラットフォームの脆弱性（CVE-2025-48757）は、行レベルのセキュリティが不十分なため、プラットフォーム上に構築されたアプリケーションへの不正データベースアクセスを許し、CVSS重要度スコアは9.3（重大）だった。欠陥の体系的な性質は、Lovableが顧客が生成するアプリケーションのビジネスロジックを積極的に保護しなければならないと主張する中で、共有責任モデルに関する議論を引き起こした。

別の広く報じられた事件では、2025年7月、ReplitのAIコーディングエージェントがバイブコーディングセッション中に本番データベースを削除した。厳格なコードフリーズを強制する明示的な自然言語指示にもかかわらず、エージェントは保護策を回避し、1,206人のエグゼクティブと1,196社の重要な記録を消去した。ReplitのCEO Amjad Masadは公に謝罪し、dev/prod環境の強制分離を含む即時インフラ修正を発表した。

どちらのケースでも、周囲の検証と責任モデルは、非常に迅速に生成または変更できるソフトウェアに追いつかなかった。デリバリーの速度は、誰かが介入できたはずの時間枠を圧縮した。

証拠が示すもの

• 製品学習を伴わない製品失敗：EwingのAI検索ツールは0.92 nDCGの精度を達成したが、採用は横ばいだった。チームがユーザーの実際の働き方を観察しなかったからだ。ツールはワークフローステップを削除する代わりに追加した。技術的優秀さは欠落した製品決定を補わなかった。
• コード理解を伴わない理解負債：Osmaniの分析は、開発者が数日後に説明できないAI生成コードをマージしていることを示している。高AI採用チームはプルリクエストが98%増加し、レビュー時間が91%上昇した。コード生産は規模化したが、コード理解はそうではなかった。
• 検証インフラを伴わないセキュリティ障害：VeracodeはAI生成コードがテストの45%でセキュリティ脆弱性を導入したことを発見した。LovableとReplitの本番インシデントは、適切な検証なしに機能コードがユーザーに届き、誰かが欠陥をキャッチする前に脆弱性が露呈することを示した。

2026年に「可能な限りコードを書かない」の実際の意味

もともとの規律は抑制についてだった。解決策を書く前に問題を知る。リソースをコミットする前に仮定を検証する。正しいかどうかをテストする最小のものをリリースする。エージェンティックコーディングはそのどれも変えない。すべてをより緊急にする。

「可能な限りコードを書かない」は今や意味する：生成できるからといってすべての機能を構築しない。アイデアをコーディングする前に、発見と検証に投資する。AIがコードを生成するときはレビューし、テストに合格したからといって正しいと思い込まない。可能な限り多くのコードを、保持すべきものではなく削除すべきものと見なす。

規律は「控えめに書く」から「積極的に削除する」へと変わった。問題はもはや「何を追加できるか？」ではなく、「ユーザーの問題を解決しながら何を削除できるか？」だ。最も少ないコードは依然として最も賢いコードである。今や、最もリスクの低いコードでもある。

結論：今やコード能力よりも製品規律が重要

AIは構文的に正しいコードを生成するのに優れている。どのコードが書く価値があるかを判断するのは依然として苦手だ。この非対称性が私たちのすべての仕事がある場所だ。私たちはソフトウェアを作りやすくすることに投資してきたが、今やそれを作る価値のあるものにすることに同等に投資しなければならない。

組織におけるプロダクト担当者の役割はかつてなく重要であり、かつてなく異なる。単にバックログを管理したりユーザーストーリーを書いたりするだけではもはや不十分だが（それらのタスクはAIによって支援されるかもしれない）。プロダクト担当者はユーザーのワークフローの邪魔にならない実行の専門家にならなければならない。提案されたすべての機能に挑戦しなければならない：この機能は本当に労力を取り除くのか、それとも別のステップを追加するのか？それはユーザーの問題を解決しているのか、それとも私たちが理解せずにコードを生成させているだけなのか？

エンジニアリング文化も変わらなければならない。AI生成コードのレビューは標準的な慣行でなければならず、オプションではない。チームはコードの出力ではなく理解を強調すべきである。デプロイ前の検証は後付けであってはならない——実装と直接統合されなければならない。セキュリティレビューは自動的に実行され、チームはAI生成コードの一般的な脆弱性パターンについてトレーニングを受けるべきである。

「可能な限りコードを書かない」はかつてないほど関連性がある。それはかつて効率と抑制の規律だった。今やそれは生存についての警告である。それを無視する人々はコードの不足で失敗するのではなく、役に立たないコードが多すぎて失敗するだろう。