みなさん、こんにちは。
生成AIの進化によって、仕様書さえあればコードが自動で生成されるのが当たり前の時代になってきました。
この変化を見ていると、「仕様さえ作れれば誰でも同じものが作れるようになる」「もう高価なアプリを買わなくても、自分で作ればいいんじゃない？」と考える人も多いのではないでしょうか。
確かにそれも一面の真実です。私自身、3か月かかる見込みだった機能をAIコーディングエージェントで3日で完成させた経験があります。作るコストが劇的に下がったことは間違いありません。
でも、もう少し深く考えてみると、無視できない問題が見えてきます。
それは、「作る前にじっくり考える文化」が失われてしまうかもしれないということです。
AIは「平均的な実装」を大量生産する
生成AIは、過去の膨大な成功パターンやデータの統計的平均から答えを作り出します。AIが得意なのは、すでに「答えがあるもの」を再現することです。
そのため、開発者が特別な意図を持たないままAIに頼ると、どうしても以下のような成果物に収束しがちです。
- よくあるUI
- よくある設計
- よくあるアーキテクチャ
- よくある機能構成
その結果、世の中にはメモアプリやTodoアプリ、ナレッジベース、チャットシステムといった「似たようなツール」が溢れかえることになります。
しかも、以前なら数か月かかっていたものが、たった数時間で形になってしまう。だからこそ、「本当に作るべきか？」と悩む前に、とりあえず作ってしまうのです。
「仕様さえあれば同じものができる」は本当か
ここで、「仕様駆動開発」について少し触れておきます。
以前の記事でも書いたとおり、AIに詳細な仕様書を渡して開発する手法は、2026年初に流行した「Vibe Coding」の弱点を補う形であたりまえになりつつあります。
ただ、実際の現場で使われている仕様書は、最初から完璧なものではありません。むしろ「AIとの対話のための叩き台」です。仕様書には必ず抜けや漏れがあり、すべてのエッジケースを事前に書き切ることはできません。
つまり、「仕様さえ作れれば誰でも同じものが作れる」という前提そのものが怪しいのです。同じ仕様書でも、何を意図し、どこに違和感を覚えて修正を指示するかで、出来上がるものはまったく別物になります。
そこで重要になるのが、「何を作りたいのか」「どんな価値を提供したいのか」という意図です。AIは仕様書からコードを作れても、その意図を代わりに持ってくれるわけではありません。
AIによる「車輪の再発明」
よく「AIのせいで車輪の再発明（すでに存在するものをまた作ること）が増えた」と言われますよね。そのせいで膨大なトークンが消費されている一面は否定できないでしょう。
でも、私は一概に「車輪の再発明がすべて悪い」とは思いません。
たとえば、LibreOfficeやFirefox、GIMPといった有名なオープンソースソフトウェアも、見方によっては既存製品の再発明です。これまでのOSSは、ある意味で「お手本をオープンな形で作り直す」クローン文化によって発展してきました。それでも世界中で愛され、高い価値を提供しています。
ただし、時代は変わりました。UIの再現やAPIの模倣はAIにとって朝飯前です。人間が「模倣」そのものに投じる労力の価値は、急速に薄れています。
それでもなお価値を持つクローンがあるとすれば、そこに「既存製品の何が問題で、それをどう解決したいのか」という明確な意思（思想）が存在するものです。ただ作り直すことが目的ではなく、まだ解決されていない課題へのしっかりとした「回答」になっているかどうか。AI時代のOSSは、コードそのものよりも「問題定義」を共有する場へと変わっていくのではないかと、私は考えています。
従来必要だった「思考プロセス」とAIによる逆転現象
従来のソフトウェア開発は、以下のようなステップを踏むのが一般的でした。
- ユーザーにヒアリングする
- 根本的な問題を理解する
- 仮説を立てる
- 小規模な検証を行う
- 仕様を固める
- ようやく実装する
一見するとすごく回りくどい手順に見えますよね。ですが、これには「実装コストが高すぎるため、不必要なものを作らせない」という非常に重要な防波堤の役割がありました。「本当に作る価値があるのか？」を吟味しないと、プロジェクトが大赤字になってしまうからです。
ところが、生成AIはこの順番をあっさりと逆転させてしまいました。
- 従来の流れ： 理解 ➔ 設計 ➔ 実装
- AI時代の流れ： 実装 ➔ 様子を見る ➔ 理解 ➔ 修正
個人開発の実験ならこれでも良いかもしれません。問題は、このノリが企業の開発（とりわけ本来なら厳密さが求められる受託開発など）にまで流れてきていることです。
「とりあえず作って、後から直せばいいや」という考え方が、あちこちで聞かれるようになりました。
「後から直せばいい」に潜む最大の落とし穴
確かに、AIを使えばコード自体はいくらでも修正できます。もちろん設計からやり直す局面が発生することもありますが、AIを使えば許容コスト内に収まる場合が増えてきました。
しかし、その結果として見えてきたものがあります。
AIはコードを書いてくれますが、「そもそも何が本当の問題なのか？」を自動生成することはできません。ここをスキップしたまま突き進むと、結局「誰も使わない大量の機能」が作られ、そのまま放置されるという悲しい結果になってしまいます。
しかも問題なのは、AIが出力するコードや解説があまりにも流暢で自信に満ち溢れている点です。そのスムーズさに安心しきってしまうことで、人間の脳は「本当にこれでいいのか？」と立ち止まって検証する労力を無意識にサボってしまいます（心理学でいう「認知的交付」の罠です）。検証のスイッチがオフになったまま「とりあえず動くから」と実装を進めてしまうと、後から修正が利かない「負債」だけが組織に残り続けることになります。
だからこそ、知識の量ではなく、その流暢さに惑わされずに「問題認識能力」を発揮することが先決なのです。
たとえば「社内システムが使いにくいからUIを改善したい」という依頼があったとします。すぐに画面遷移やボタン配置の見直しに手をつけたくなりますが、「それは誰の課題か？」を掘り下げると、現場の担当者は「慣れているので問題ない」と言い、困っているのは入力の遅さにイライラする管理職だった、ということがよくあります。さらに掘ると、本当の課題は「入力ルールが曖昧で、データの定義が部署ごとに違うこと」だったと分かる。この場合、UIをいくらきれいにしても問題は解決しません。
課題設定が変われば、設計は自然に良くなります。逆に、問題認識がズレたままでは、どれだけ高度な生成AIを使っても有益なシステムは生まれません。AIに実装を任せられる時代だからこそ、この入口の精度がそのまま成果物の価値を決めるのです。
AI活用で実装スピードが上がった今だからこそ、この入口の精度に時間をかけるべきなのです。
クローンアプリを作る前に、私たちが考えるべきこと
最近では、PhotoshopやIllustratorなどの巨大ソフトをオープンソースで再構築しようとする素晴らしいプロジェクトも増えています。技術チャレンジとしては本当にワクワクしますし、価値のある取り組みです。
ですが、プロダクトとして真に問うべきなのは、技術的な再現性だけではありません。
- Adobeの今の仕様の、何が課題なのか？
- 誰がどんな場面で本当に困っているのか？
- なぜ公式はそれを改善しないのか（技術的制約？ビジネス上の判断？）
ここまで解像度を上げて考え抜いた結果、「Linux環境で動かしたい」「サブスク型を避けたい」「オープンフォーマットを絶対に守りたい」といった切実な答えにたどり着いたのなら、再実装にはものすごい意味が生まれます。
ですが、もし「PhotoshopっぽいものがAIで簡単に作れそうだから作った」だけなら、それは単なる表面的な模倣品で終わってしまうのではないでしょうか。
AI時代における「本当の希少資源」とは？
AIの登場によって、コードそのものは「いくらでも手に入るもの」になりました。
その一方で、これから急速に不足していく本当の希少資源は別にあります。
- 問題認識能力（当たり前とされていることを、問題として捉え直す力）
- 観察力・注意力（現場を見て、違和感に気づく力）
- 理想像を描く力（どんな未来をつくりたいのかを想像する力）
- 問いを立てる力（理想像を、行動につながる具体的な問いに変える力）
- 批評眼（作ったものを客観的に評価する力）
特に「理想像」と「問い」は、AIには任せられない領域です。AIは膨大なデータから論理的な答えを導くのは得意ですが、「こういう未来にしたい」という願いは、人間の側からしか生まれません。優れた製品やサービスは、優れた「問い」に対する答えとして生まれます。
たとえば医療IoTなら、「心拍数を99%の精度で計測するには？」という技術起点の問いよりも、「このデバイスは、患者やご家族にどんな安心を届けられるか？」という価値起点の問いの方が、はるかに本質的です。誰もが簡単にモノを作れる時代になればなるほど、「なぜそれを作るのか？」という問いの価値はどんどん高まっていきます。
これからの時代、「良い開発者」の定義が変わる
これまでの時代は、「きれいなコードを素早く書ける人」が優秀な開発者でした。
しかし、これからのAI時代に評価されるのは、もしかすると「作れる技術があるのに、あえて作らない判断ができる人」かもしれません。
- 「既存のツールや運用で十分カバーできないか？」
- 「本当にユーザーはこれで困っているのか？」
- 「なぜ今まで誰もこの問題を解決してこなかったのか？」
- 「作る価値は、将来の保守・運用コストに見合うのか？」
こうした問いを徹底的に考え抜いたうえで、「それでも絶対に必要だ」と確信できたときにはじめてコードを書く。
もちろん、技術の理解が不要になるわけではありません。AIがどれだけ進化しても、ソフトウェアは最終的に物理的なコンピューターの上で動きますし、パフォーマンスやセキュリティといった制約からは逃れられません。人間の意図を技術的に実現可能な形へ変換するには、基礎的な技術力が前提になります。そのうえで、「何のために作るのか」を問い続けることが、本来のエンジニアリング（技術によって問題を解決すること）だったはずです。
これから最も価値を持つエンジニアリング能力
生成AIは、ソフトウェア開発のスピードを劇的に加速させてくれました。
しかし、加速されたのはあくまで「実装のスピード」であり、「思考の深さ」ではありません。
むしろ作るのが簡単になった分、「考える前に作ってしまう」という強い誘惑と、私たちは常に戦わなければならなくなっています。
コードが無限に作れる時代だからこそ、問題を問題として認識し、理想の未来から問いを立て、「そのコードを本当にこの世に生み出す価値があるのか？」を正しく判断できる力。それこそが、これから最も価値を持つエンジニアリング能力になっていくのではないでしょうか。
本日も最後までお読みいただき、ありがとうございました。
それでは、よいソフトウェア開発を！
