AIはコーディングできるが、ソフトウェアを構築することはできない

2025年10月28日原文(bytesauna.com)

概要

多くの人が 技術系共同創業者 や CTO を探している現状について考察 AIによる コーディング自動化 と ソフトウェア開発 の違いに注目 AIはコードは書けても 本格的なソフトウェア構築 はできない現実 生産レベルのアプリ 構築には依然として人間の技術が必要 AIと人間の役割分担の現状分析

技術系共同創業者やCTOを求める人が増えている理由

最近、 技術系共同創業者 や CTO を探す人が非常に多い傾向
よくあるパターンは「 アイデアはあるが実装力がない」タイプ
- 例： 法務担当者 や アカウントマネージャー など非技術職出身者
彼らがなぜ自分のような技術者に声をかけるのかという疑問
重要なシグナルとして「 GenAIだけでは何が実現できないのか」という問い
多くの人が「 AIはどこまでできるのか、どの仕事がなくなるのか」を知りたがっている現状

AIの限界とソフトウェアエンジニアリングの本質

もし ソフトウェアエンジニアリング が完全自動化されていれば、技術者探しは不要のはず
実際には「 AIはコードは書けても、ソフトウェアは作れない」という現実
長年AI支援下でコーディングした経験や他人のデモを見て得た結論
「 コーディングは簡単、ソフトウェアエンジニアリングは難しい」という古い格言の再確認
LLM（大規模言語モデル）は 単発の明確な問題 は解けるが、
- 本番用アプリ構築 は単なるコーディングではなくソフトウェアエンジニアリングの領域

コーディングとソフトウェアエンジニアリングの違い

デモから製品化 の段階でコーディングからソフトウェアエンジニアリングへ移行
このタイミングで非技術者が技術者へ協力を求める傾向
AIがソフトウェアを構築できない理由は 複雑性への対処能力 にある可能性
実際のプロダクションソフトウェアは「 簡単なことを大量に、かつ維持可能に」実装する必要
機能のデモはできても「 統合・拡張・長期メンテナンス」を見据えた設計が困難

現状の課題と今後

送られてくるコードを見ると「 プロダクション対応＝一から作り直し」が現実
この状況は AI技術の限界 と 人間エンジニアの重要性 を示唆
現時点では「 AIはコーディングの自動化はできても、ソフトウェア開発の本質は担えない」
今後も 人間のソフトウェアエンジニアリング力 が不可欠

Hackerたちの意見

現状ではその通りだね。モデルは主に機能を実装したり、小さなMVPを作るために使われてるけど、そこは得意なんだよね。次のステップは、モニタリングサービスやテストカバレッジ、プロダクト分析からの入力を受けながら、プロジェクトでモデルが継続的に動くことだと思う。十分なモデルに支えられたエージェントは、効果的なソフトウェアエンジニアと見なされるかもしれない。今はまだそこまで行ってないけど、そんなに遠くない気がする。

└

「今はまだそこまで行ってないけど、そんなに遠くない」って、AIに夢中になり始めた頃から聞いてるけど、もしそれが本当に遠い未来だったらどうする？

└

それには同意だね。ツールはその方向に成熟してきてると思う。GenAIでMVPを作った非技術者が、今日人間の技術的サポートを必要としているなら、明日も必要になるのかな？ツールが成熟して、ソフトウェアエンジニアリング（モニタリングサービス、テストカバレッジ、プロダクト分析）について誰でも完全に理解できるようになるほど、障壁が下がるのかな？

└

同意だよ。エージェントだけのコードベースで遊んでみたことがあって、サーバーログに接続したエージェントがエラーに遭遇したら問題を作って、エージェントがチケットを修正して、プロダクションにプッシュしてデプロイ状況をチェックするっていうのをやってみた。これが未来になりそうだっていうのは十分見えたよ。（その全体のセットアップにはclaude/codexコードも使ったけど）ちょっと細かいことを言うと、使っては捨てる小さな「ソフトウェア」プロジェクトをゼロショットでたくさん作ってる。これはSAAS製品にはならないけど、やっぱりソフトウェアだと思う。

└

次のステップは、モニタリングサービスやテストカバレッジ、プロダクト分析からの入力を受けながら、プロジェクトでモデルが継続的に動くことだと思う。十分なモデルに支えられたエージェントは、効果的なソフトウェアエンジニアと見なされるかもしれない。システムが正しいかどうかを判断する自動化システムを構築するのは、コーディングエージェント自体を作るよりも難しい。

└

今はまだそこまで行ってないけど、そんなに遠くない。あなたにとって「そんなに遠くない」とはどのくらいの時間枠を指すの？もし、才能あるソフトウェアエンジニアの市場が今後10年以内に崩壊するって賭けをしたら、俺は間違いなく受けるよ。25年なら、俺の方がまだ確率がいいと思う。50年なら、賭けはしないかも。

いい見出しだね。LLMはコードを書くのが驚くほど得意なんだ。コードを書くことと、動作するソフトウェアを提供することは別物だよ。人間の専門家がソフトウェアの必要性を見極めて、ソフトウェアが何をするべきかを決めて、実現可能なことを考えて、最初のバージョンを作る（ここでAIがかなり助けてくれる）。それを評価して、ユーザーに見せて、目的に合っているかどうか話し合って、フィードバックに基づいて改善して、デプロイしてソフトウェアの価値を伝え、将来の進化を管理する必要がある。これらのことは、LLMを使っている非開発者の人たちでも扱える部分もあるけど、コードを理解している人間の専門家がやる方がずっと効果的だと思う。大きな疑問は、経験豊富なプロダクトマネジメントの人たちがプログラマーなしでこういう風に働くために必要な技術的リテラシーを身につけられるか、あるいはプログラマーがPMなしで働くためのPMスキルを身につけられるかってことだね。俺は、両方の役割が存在し続けて、お互いに利益を得るパートナーシップができると思う。そうすれば、以前は遅かった「コードを書く」部分が今よりずっと早くなるから、結果も早く出るはず。

└

タイトルの興味深い副産物の一つは、これが人間にも当てはまるってことだね。コーディングできることと、ソフトウェアエンジニアであることは同じじゃない。昔からそうだった。

└

大きな疑問は、経験豊富なプロダクトマネージャーがプログラマーなしでこういう風に働くために、十分なコーディングの技術的リテラシーを身につけられるかどうかだよね。少なくとも短期間では無理だと思う。LLMが機能するプログラムやプロダクトを生成できるからじゃなくて、実装がどう機能するかを理解して、複雑な問題を解決するためには十分な理解が必要だから。私の経験では、Claudeを使ってNettyを使ったMITM HTTPSプロキシを生成しようとしたんだけど、見た目は良さそうなコードがたくさん生成されたのに、実際には動かなかったんだ。Nettyについてあまり知らなかったから、なぜ動かないのかデバッグできなくて、LLMを使って修正しようとしても全然うまくいかなかった。PMが時間をかけて知識を身につけて、スケールできるプロダクトを実装できるようになるかもしれないけど、その頃には実質的にソフトウェアエンジニアになってるだろうね、コードを書く部分を除いて。

└

LLMはコードを書くのが驚くほど得意だよ。先週末、私はLLMが数年かかっても近づけないようなコード（Typescriptで）を設計して書いた。最先端のLLMにサブスクリプションを持ってるけど、最近はその25%くらいしか使ってない。私が解決しているソフトウェアアーキテクチャの問題は、データ構造や型、アルゴリズムのメンテナブルでパフォーマンスの良い、検証可能な設計についての数十年の理解を基にしているもので、LLMには全く理解できないものだ。そうなると、初期の解決策を考えるためにLLMを使うのは時間の無駄だと感じる。せいぜい初期のブレインストーミングに使えるくらい。LLMがコーディングできると言っている人たちの気持ちが理解できない。彼らはシンプルなbashスクリプトや複雑なリファクタリング、基本的なコードイディオムの草案には良いけど、それだけだ。これらのタスクでも、私が必要とする手助けの量はかなり多い。少なくともGemini Pro/CLIは、コンテキストが毒される前の一発のパフォーマンスが良さそうだね。

└

一般的な人間のエンジニアが「ソフトウェアを構築する」ために持っているすべてのコンテキストがLLMに利用可能になったら、この主張が本当に成り立つのかはあまり確信がない。

└

大きな問題は、経験豊富なプロダクトマネジメントの人たちがプログラマーなしでこのように働くために、十分なコーディング技術を身につけられるかどうかだ。AIは「特別な知識」を持つ人々の重要性を、役割に関係なく他の誰よりも高めると思ってる。だから、システムに深い知識を持つエンジニアや、ドメインに深い知識を持つPMが重要になるんじゃないかな。

Hacker Newsで議論の続きを見る

ハクソク