- エージェンティックコーディング（Agentic Coding）ツールの登場により、ソフトウェア開発の労働コストが急激に低下している
- 以前は1か月かかっていた社内向けWebアプリのプロジェクトが1週間以内で完成するほど実装速度が短縮された
- Claude Codeなどのツールが数百件のテストを数時間で生成し、少人数チームが大規模な成果を出す構造へと変化
- コスト低下は**潜在需要の爆発（Jevons Paradox）**を引き起こし、より多くの組織がカスタムソフトウェアを制作する可能性
ソフトウェア開発コスト構造の変化
- オープンソースの普及は、ソフトウェア開発の初期コストを下げた最初の転換点だった
- かつてSQL ServerやOracleなどは年間数万ドル規模のライセンス費が必要だったが、MySQLは無料でネットワークアプリケーションを構築できた
- その後、クラウド導入は初期の設備投資を削減したものの、全体的なコスト削減効果は限定的だった
- 近年、TDD、マイクロサービス、複雑なReactフロントエンド、Kubernetesなどにより、逆に複雑性が増し、コスト削減は停滞した
- 一方、AIエージェントは開発プロセスの労働コストを大幅に圧縮する
90%削減の根拠
- 2025年初頭まではAIコーディングツールに懐疑的だったが、近年エージェンティックコーディングCLIが実際に大規模な効率を実証
- 例えば、ある社内ツールの300件以上のテストコードをClaude Codeが数時間で生成した
- かつて1か月かかっていたプロジェクトが1週間以内に完了できるようになった
- 実装時間は激減したが、設計（
사고）時間は同じ
- チーム規模縮小によりコミュニケーションオーバーヘッドが消滅
- 結果として、少人数で10倍以上の生産性を達成
潜在需要の爆発
- コスト低下は、産業全体の需要を減らすのではなく逆に拡大させるJevons Paradoxで説明される
- 多くの組織は依然としてExcelベースの業務プロセスを運用しており、これをSaaSアプリへ移行する潜在需要が存在する
- 既存の5万ドル規模見積もりが5千ドル程度に低下すると、非必須プロジェクトも開発対象になる
- したがって、開発業界全体の総生産量増加の可能性がある
ドメイン知識が新たな競争力に
- 現時点でもなお人間の監督と判断が不可欠
- エージェントの進め方を監視し、誤った方針を修正する必要がある
- この技術を習得した開発者はビジネス問題解決能力が大きく向上する
- ドメイン知識 + 技術習熟度の組み合わせが中核的な競争力として浮上
- ビジネス専門家と開発者が小規模な協働単位で迅速に反復開発を行える
- ソフトウェアは**「破棄可能な資産」**となり、誤った方向であれば即座に廃棄し再開発できる
変化に備える必要がある
- LLMとエージェントモデルは急速に改善されており、既存のベンチマークはこれを反映していない
- 例：Opus 4.5は10〜20分のセッションを安定的に維持
- 大規模GPUインフラへの投資により、今後モデル性能は急激に向上する見込み
- 一部の開発者は依然として「LLMはエラーが多い」あるいは「時間短縮にならない」と主張するが、これはますます事実でなくなっている
- 2007年のiPhoneを軽視したデスクトップエンジニアの例のように、変化を拒否すると取り残されるリスクがある
- 大企業は官僚的構造で導入が遅いが、小規模チームは即時活用可能
- LLMは新規プロジェクトだけでなく、既存コードベースの分析と保守にも有効
- 古いコードの構造理解、バグ検出、修正提案などで高い効率
- 結果として、2026年は開発方法の大転換点になる可能性が高い
1件のコメント
Hacker Newsの意見
Claude Code が数時間で 300 件以上のテストを生成したという話を聞いた。
ただ、それらのテストが本当に意図した動作を検証し、次の開発者にシステムの動作方式を明確に伝えられるのかは疑問だ。
AI が素早くコードを書いても、その分の入念なレビュー時間をかけなければ品質が落ちるリスクは大きい。
私も AI コーディングに「積極的に適応してみろ」という助言に従ってみた。
しかしロボティクスや組み込み寄りだからか、Web アプリやゲームを AI で作るのはあまりに退屈でストレスのたまる体験だった。
Cursor に問題を直してくれと頼むとかえって余計にひどくなり、結局 Flask と JS を自分で学ぶ方がはるかに効率的だった。
AI はドキュメントやエラーメッセージを探すのには素晴らしかったが、**「ハンドルを任せること」**にはまったく役に立たなかった。
AI が「10 倍の生産性」をくれるという話が本当なのか疑わしい。
実際には強化版の Google / Stack Overflowのように使うのが現実的だ。
大半のコードは自分で書き、AI は単純な反復作業やスクリプト作成を手伝う程度だ。
成功するには、メンターのように明確に指示し説明する能力が必要になる。
自分で直接手を入れず、プロンプトで修正を依頼する習慣が重要で、この過程が結局はコミュニケーション能力を鍛えてくれる。
こうした記事を見ると、現場の開発チームと経営陣の認識の差がはっきり表れている。
上層部は数行の要件だけでシステム全体を理解したつもりになるが、実際には依存関係や文脈をほとんど分かっていない。
優れた開発チームがその曖昧な要求を実際の製品へと変えることこそ真の職人芸であり、それを自動化できる技術はまだない。
単純なコードを書くコストは 90% 減った。
しかし問題を単純なコードへ還元するには、依然として多くの経験と時間が必要だ。
Claude Code は古いコードベースを理解して修正するのに卓越していた。
テストやデバッグまで手伝ってくれるので、生産性が 10 倍になったように感じた。
単にコードを速く書くだけではなく、高速な第二の頭脳のように機能する。
1 時間以内にスクリプトやミニ Web サービスを作って問題を解決できた。
こうした単純作業はAI 以前から自動化されているべきだったとも思う。
LLM はシャベル 1 本から油圧ショベル 10 台にアップグレードされた感覚だが、
プロジェクトが失敗するなら、ただより速く失敗するだけでもある。
Claude Code は学習済みのパターンの範囲内なら、複雑なコードもうまく書く。
もし本当にカスタムソフトウェア開発コストが 90% 減ったのなら、
市場には低価格の SaaS があふれているはずだが、現実はそうではない。
結局、コードを書くこと自体が最大の問題ではないようだ。
保守、セキュリティ、アップグレード、ホスティング、顧客サポート、新機能追加などだ。
こうしたものが SaaS のサブスクリプション料金に含まれる本当の価値だ。
AI がこの部分まで解決するには、まだ 3〜5 年はかかりそうだ。
残りは会議、調整、待機などで埋まる。
たとえコーディングコストが 90% 減っても、総コストは半分以上残る。
しかも AI は自然言語の要約ですら正確にできないのに、
コードの意味を完全に理解して書けるのかは疑わしい。
関連動画: YouTubeリンク
今も SaaS はあふれているが、機能が良くても事業は難しいというのが現実だ。
多くのエンジニアリングは事実上、ベンダーロックインのための作業でもある。
プラットフォームでの露出、信頼、アルゴリズムによる支配のせいで、新興 SaaS は成長しにくい。
大企業がすぐにコピーしてしまい、消費者はますますお金を持っていない。
結局、市場は公正ではなく、だから多くの人が政治の領域へ目を向けつつある。
大企業で働いたことがある人なら、こういう記事には共感できないだろう。
たとえば Shutterstock のような場所では、単純な要求でも5 つのシステムに手を入れなければならない。
AI はコードを理解して修正する助けにはなるが、
開発コスト全体が 90% 減ったというのはまったく事実ではない。
この記事は実質的に企業向けの宣伝文に近い。
「どの組織にも何百もの Excel シートがあり、SaaS に置き換えた方がよい」という主張については、
それが本当に誰にとってより良いのかを聞きたい。
スプレッドシートはドメイン知識を持つ人たちが直接扱え、
アクセスしやすいので今でも強力なツールだ。
数式と UI が密接に結びついているので、内部ロジックを把握しづらい。
とくに Excel は保守が難しく、複雑になるほどコードに移した方がよいと思う。
コラボレーション、アクセス制御、テストといった構造的な補強が必要だという意味だった。
データベースのように使い始めたり、複数のユーザーが同時に扱い始めたりしたら、それが切り替え時だ。
共通の問題は SAP のようなソリューションが解決するが、
大半のシートは顧客が 1 社しかいないカスタム問題なのだ。
90/90 の法則はいまだに有効だと感じる。
AI は最初の 90% を素早く処理してくれるが、残り 10% が本当に難しい。
LLM は泥臭く掘り進める段階では有用だが、細かな仕上げの段階ではむしろ邪魔になる。
単純な Web サイト制作には魔法のように感じられるだろうが、
そういう仕事は今後生計を立てにくい領域になりそうだ。
生成結果を止めてじっくり見ると、本当に正しいのか疑わしくなる。
多くの人がいまだに AI をコピペ用チャットボットとしてしか使っていないのは驚きだ。
だが適切に指示すれば、Claude Code は数週間かかる実験を数分で再現できる。
実務では完璧なコードよりも結果を素早く出すことが重要だ。
もちろんセキュリティバグやビジネスロジックの誤りは依然としてリスク要因だ。
ドメインの専門家が一緒にいれば、こうした問題は次第に減っていくと思う。
機能開発とコードベース管理のバランスが重要だ。
Cursor のようなエージェントがこのバランスをうまく取れるのかは、まだ疑問だ。
LLM ブーム以降、Excel を置き換えようとするプロジェクトに参加したことがある。
だが実際には、非専門家が AI でアプリを作ろうとして失敗した事例だった。
データアナリストたちが Python アプリを「バイブコーディング」で作ったが、
状態管理もなく、構造もひどいものだった。
その結果、顧客データがでたらめに処理される惨事レベルの結果になった。
こうした組織には技術人材がいないため、AI はむしろリスクを加速させる。