AIコーディングの5つのレベル——なぜほとんどの人はレベル2を超えられないのか

AIコーディング・Vibe-Coding
この記事は約34分で読めます。

AIコーディングツールが普及する中、一部のチームはすでに人間がコードを一行も書かない「ダークファクトリー」を実現している一方、大多数の開発者はAIを使うことで逆に生産性が低下しているという逆説的な現実が存在する。本動画では、Dan Shapiroの「バイブコーディングの5つのレベル」フレームワークを軸に、StrongDMの事例やAnthropicとOpenAIの自己参照的な開発ループを詳述しながら、フロンティアチームと大多数の組織の間に存在する巨大なギャップの本質を解き明かす。その乖離はツールの問題ではなく、人材・文化・組織構造の問題であり、ソフトウェアエンジニアリングの未来を左右する核心的な問いとして提示される。

The 5 Levels of AI Coding (Why Most of You Won't Make It Past Level 2)
My site: Story w/ Prompts:
www.youtube.com

AIコーディングの現実：最前線と現場の大きな乖離

Claude Codeのコードベースの90%は、Claude Code自身によって書かれています。OpenAIのCodexは、Codex自身によって完全に書かれた機能をリリースしています。それなのに、AIを使っている開発者の多くは、少なくとも最初のうちは、実証的に見て生産性が下がっています。この二つの事実の間にある溝こそが、ソフトウェアの未来が宿っている場所です。

こんな言葉を職場で耳にしたとしたら、どう感じるでしょうか。「コードは人間が書いてはならない。コードは人間がレビューすることさえしてはならない。」これはStrongDMという実際の本番環境で稼働するソフトウェアチームの最初の二大原則です。彼らは「ソフトウェアファクトリー」と呼ぶ体制を持ち、エンジニアはたったの3人。誰もコードを書かず、誰もコードをレビューしません。システムはMarkdownの仕様ファイルによってオーケストレーションされたAIエージェントの集合体です。仕様を受け取り、ソフトウェアを構築し、実際の動作シナリオに対してテストを行い、自律的にリリースするように設計されています。

人間がやることは仕様を書いてアウトカムを評価することだけ。その間のすべては機械がやります。

生産性のパラドックス——AIで遅くなる開発者たち

Anthropicでは、Claude Codeのコードベースの90%がClaude Code自身によって書かれており、これは本当のことです。Claude Codeプロジェクトを率いるBoris Churnyは、ここ数ヶ月、個人的にはコードを一行も書いていません。そしてAnthropicのリーダーシップは今や、会社全体で生成されるコードの事実上100%がAI生成になると見込んでいます。

ところが同時に、同じ業界で、同じ地球上で、2025年にMETRが行った厳密なランダム化比較試験の結果、AIツールを使った経験豊富なオープンソース開発者が、AIなしで作業した開発者に比べてタスクの完了に19%長い時間がかかることが判明しました。ここに謎があります。速くなっていないどころか、遅くなっているのです。

そしてさらに動揺させられるのが、その開発者たちの自己認識です。彼らはAIによって自分が24%速くなったと信じていました。方向性だけでなく、変化の大きさすら間違えていたのです。一方では、完全自動化されたソフトウェアファクトリーを動かしているチームが存在する。もう一方では、業界の残りの大部分が、自分たちは速くなっていると周囲に向けてプレスリリースを出しながら、実際には測定可能な形で遅くなっています。この二つの現実の間の距離が、今テックの世界で最も重要なギャップであり、それを正直に語っている人はほとんどいません。そして、その溝を渡るために何が必要かについても同様です。この動画はまさにそのことについてのものです。

バイブコーディングの5つのレベル——Dan Shapiroのフレームワーク

Glow ForgeのCEOであり、ソフトウェアと物理製品の境界に立つ複数の企業を経験してきたベテラン、Dan Shapiroが2026年の初めに、業界の現状をマッピングするフレームワークを発表しました。彼はそれを「バイブコーディングの5つのレベル」と呼んでいます。名前があえてカジュアルなのは、重要なのはその名前ではなく、背後にある現実だからです。

レベル0は「スパイシーなオートコンプリート」。コードを自分で打ち込み、AIが次の行を提案し、承認するか却下するかを選ぶ。これはGitHub Copilotの最初の形式、ただ速くなったTabキーです。ここではまだ人間が実質的にソフトウェアを書いており、AIは指の動きとキーストロークを減らしているだけです。

レベル1は「コーディングのインターン」。AIに明確に範囲が定義された個別のタスクを渡します。この関数を書いて、このコンポーネントを作って、このモジュールをリファクタリングして、といった具合です。返ってきたものはすべて人間がレビューします。AIがタスクを担い、人間がアーキテクチャと判断と統合を担います。このパターン、気づきましたか？レベルを上がるごとに人間がどんどん後ろに引いていく流れが見えてきます。

レベル2は「ジュニア開発者」。AIが複数ファイルにわたる変更を扱い、コードベースをナビゲートし、依存関係を理解し、モジュールをまたいだ機能を構築できます。より複雑な出力をレビューすることになりますが、人間はまだすべてのコードを読んでいます。ShapiroはAIネイティブを自称する開発者の90%がこのレベルで動いていると推定しており、私が見てきたものから判断すると、彼は正しいと思います。ここで動いているソフトウェア開発者は、自分が実際よりも先に進んでいると思っています。

レベル3は「開発者がマネージャーになる」段階。ここで関係が逆転し始めます。面白くなってくるのはここです。もうコードを書いてAIに手伝わせるのではなく、AIに指示を出して、それが生み出したものをレビューするだけです。あなたの一日は、フィーチャーレベルやPRレベルで読むか、承認するか、却下するかという判断の積み重ねです。実装はモデルが行い、モデルがレビュー用のPRを提出します。ただし判断力は人間に求められます。現時点でほぼすべての開発者がここで頭打ちになっています。Shapiroによれば、多くの開発者がレベル3で天井にぶつかるのは、コードを手放すことへの心理的な難しさと格闘しているからだと言います。しかしレベルはまだ先があります。

ここからが熱くなってくるところです。レベル4は「開発者がプロダクトマネージャーになる」段階。仕様を書いて、その場を離れ、数時間後に戻ってきてテストがパスしているかを確認します。もうコードをほとんど読んでいません。アウトカムを評価しているだけです。コードはブラックボックスです。動くかどうかは気にかけますが、evalを十分に完璧に書いておけば、テストをパスする限りどう書かれているかをそれほど気にしなくて済みます。これにはシステムへの信頼と、仕様を書く自分の能力への信頼が必要です。そして、そのレベルで仕様を書く能力を持つ人はまだほとんどいません。

レベル5は「ダークファクトリー」。これは仕様をソフトウェアに変換するブラックボックスであり、業界が向かっている場所です。人間がコードを書かない。人間がコードをレビューすることすらない。ファクトリーは灯りを消したまま自律的に動き続け、仕様を入れると動くソフトウェアが出てくる。Shapiroは正しく、地球上でこのレベルで動いている人はほぼ皆無です。

マーケティング言語と現実の乖離

業界の大部分はレベル1からレベル3の間にいて、AIをまるでジュニア開発者のように扱っています。このフレームワークが好きなのは、ハイプに溺れていた会話に、本当に正直な言語を与えてくれるからです。ベンダーが「このツールはあなたのためにコードを書きます」と言うとき、多くの場合レベル1を意味しています。スタートアップが「エージェント型ソフトウェア開発をしています」と言うとき、多くの場合レベル2か3を意味しています。しかしStrongDMが「コードは人間が書いてはならない」と言うとき、それは本当にレベル5、ダークファクトリーを意味しており、彼らは実際にそこで動いています。マーケティング言語と実際の運営の現実の間のギャップは巨大です。そのギャップを現場で何が起きているかという現実に埋めていくには、より良いAIツールを選ぶという次元をはるかに超えた変化が必要です。多くの人がこの問題をツールの問題だと見ています。そうではありません。人の問題です。

StrongDMのソフトウェアファクトリー——レベル5の最も詳細な事例

では、レベル5のソフトウェア開発とは実際にどういうものなのか。StrongDMのソフトウェアファクトリーは、本番環境におけるレベル5の最も徹底してドキュメント化された事例だと思います。開発者ツーリングの分野で最も慎重かつ信頼できるオブザーバーの一人であるSimon Willisは、StrongDMのソフトウェアファクトリーについて「これまで見た中で最も野心的な形のAI支援ソフトウェア開発」と評しています。

詳細は本当に掘り下げる価値があります。なぜなら今日のエージェントでダークファクトリーを動かすとはどういうことかが明らかになるからです。この話を聞きながら、私たちの多くにとってこれはタイムトラベルだということを念頭に置いてほしいのです。大胆なビジョンが今日のエージェントと今日のエージェントハーネスで現実にどう翻訳されるかを目撃しているのです。2026年に向けてこれはさらに簡単になっていくでしょう。それが、これが将来のエージェント型ソフトウェア開発の実践にとって巨大な重力の中心になると思う理由の一つです。私たちは全員、レベル5へと向かっています。

チームは3人です。CTOのJustin McCarthy、Jay Taylor、そしてNan Chowanです。実は昨年の7月からファクトリーを動かしています。そして彼らが変曲点として挙げるのがClaude 3.5 Sonnetで、実際には2024年の秋にリリースされました。そこから、長期にわたるエージェント型コーディングがエラーを複利的に積み重ねるのではなく、正確性を複利的に積み重ね始めたのです。先を見越して考えていた点は称えるべきです。それほど昔の時点でダークファクトリーという観点で考えていた人はほぼいませんでした。しかし彼らは、Claude 3.5 Sonnetがセッションをまたいで十分な長さで一貫した作業を維持でき、出力が信頼できるものであり、デモ映えするだけのフラッシュ・イン・ザ・パンではないと確認し、それを基盤に構築しました。

ファクトリーはattractorというオープンソースのコーディングエージェントで動いています。リポジトリにはたった3つのMarkdown仕様ファイルがあるだけで、それがエージェントのすべてです。仕様書はソフトウェアが何をすべきかを記述し、エージェントはそれを読んでコードを書き、テストします。そしてここが本当に興味深く、多くの人のメンタルモデルが崩れ始めるところです。

StrongDMの革新的アーキテクチャ——シナリオとデジタルツイン

StrongDMは実は従来型のソフトウェアテストを使っていません。彼らが「シナリオ」と呼ぶものを使っています。この区別は重要です。テストは通常コードベースの内部に存在します。AIエージェントはそれを読めるため、正しいソフトウェアを構築するよりもテストをパスするために最適化してしまう可能性があります。意図的であれそうでなくても。それは教育における「テストのための教育」と同じ問題です。完璧なスコアが得られても、理解は浅いままということがあります。

シナリオは違います。シナリオはコードベースの外に存在します。外部の視点からソフトウェアが何をすべきかを記述した行動仕様であり、開発中にエージェントが見ることができないよう別の場所に保存されています。機械学習のユーザーが過学習を防ぐために使うホールドアウトセットと同じ概念です。エージェントはソフトウェアを構築し、シナリオはそのソフトウェアが実際に動くかどうかを評価します。エージェントは評価基準を見ることができないため、システムを操作することができません。これはソフトウェア開発における本当に新しいアイデアであり、まだほとんど実装されているのを見たことがありません。

しかしこれは、すべてのコードを人間が書いていた時代には誰も考えていなかった問題を解決します。人間がコードを書く場合、インセンティブが非常に歪んでいない限り開発者が自分のテストスイートを操作することを心配しません。そういう状況なら、そもそももっと大きな問題があります。AIがコードを書く場合、意図的にアーキテクチャを設計しない限り、テストパスへの最適化がデフォルトの挙動になります。これはAIをコードビルダーとして考え始めるときに本当に理解すべき最も重要な違いの一つです。StrongDMは外部シナリオによってその点を回避するアーキテクチャを設計しました。

もう一つの主要な構成要素がStrongDMの「デジタルツイン宇宙」と呼ばれるものです。ソフトウェアが連携するすべての外部サービスの行動クローン——シミュレートされたOkta、シミュレートされたJira、シミュレートされたSlack、Google Docs、Google Drive、Google Sheets。AIエージェントはこれらのデジタルツインに対して開発を行います。つまり、実際の本番システム、実際のAPI、実際のデータに一切触れることなく、完全な統合テストシナリオを実行できます。自律的なソフトウェア開発のために専用に構築された完全なシミュレーション環境です。

そしてアウトプットは本物です。彼らのAIコンテキストストアであるCXDBは、Rustで16,000行、Goで9,500行、TypeScriptで700行。リリース済みで、本番環境で動いており、動作し、本物のソフトウェアであり、エージェントによってエンドツーエンドで構築されています。そして、彼らがどれだけ本気かを示す指標があります。「1人の人間エンジニアあたり1,000ドル使っていなければ、あなたのソフトウェアファクトリーには改善の余地がある」と彼らは言います。これは冗談ではありません。

エンジニア1人あたり1日1,000ドルのコンピュートにより、AIエージェントが意味のある量で動けるようになります。本番ユースケースで実際のスケールと実際の実用性を持つソフトウェアを構築するというミッションを与えられているなら、そのコストは往々にして彼らが置き換えている人間よりも安いのです。

ハイパースケーラーの自己参照ループ——CodexとClaude Code

では、ハイパースケーラーが何をしているかを見てみましょう。AnthropicとOpenAIでは自己参照ループが定着しており、ハイプが示唆するよりも奇妙な現実があります。Codex 5.3は、自分自身を作ることに直接貢献した最初のフロンティアAIモデルです。これは比喩ではありません。Codexの以前のバージョンがトレーニングログを分析し、失敗したテストにフラグを立て、トレーニングスクリプトへの修正を提案することがありました。しかしこのモデルは、自分の前身のコーディング成果の直接的な産物としてリリースされました。OpenAIはCodex 5.3の構築において25%のスピード改善と93%のトークン無駄遣いの削減を報告しており、それらの改善の一部は、ビルドプロセス中にモデル自身が自分の非効率性を特定したことから来ています。すごいことだと思いませんか？

Claude Codeでも同様のことが起きています。Claude Code自体を含む、Claude Codeのコードの90%がClaude Codeによって構築されており、その数字は急速に100%に収束しています。Boris Churnyはここ数ヶ月コードを書いていないというのは本当のことで、単純に役割が仕様、方向性、判断へとシフトしたと言っているだけです。Anthropicは会社全体でほぼ今頃には完全にAI生成コードに移行すると見積もっています。Anthropicの全員がアーキテクティングを行い、機械が実装しています。

co-workについての動画を作ったとき、4人のエンジニアが10日で書いたという話をしましたが、ここで覚えておいてほしいのは、それが4人のエンジニアが超スピードで全行を手で書いたわけではないということです。違います。彼らは機械にco-workのコードを構築するよう指示していたのです。だからこそ、そんなに速かったのです。

GitHubのパブリックコミットの4%は現在Claude Codeによって直接作成されており、AnthropicはこれがSo年末までに20%を超えると考えています。私もおそらくそうなると思います。Claude Code単体でローンチから6ヶ月で10億ドルの年換算収益ランレートに達しました。これはすべて2026年2月の今日の現実です。

ツールが自分自身を構築しています。自分自身を改善しています。自分自身を改善するスピードを上げる力を私たちに与えています。つまり次世代はそうでなかった場合よりも速く、より良いものになるということです。そして私たちは複利を積み重ねていきます。AIのフィードバックループは閉じました。問いはAIを使ってAIを改善し始めるかどうかではありません。問いはそのループがどのくらい速く加速するか、そして今現在ソフトウェアを生計として構築している世界中の4,000万から5,000万人の私たちにとって何を意味するかです。

J曲線——なぜAIは多くの組織を遅くするのか

これはソフトウェア開発者と同様にベンダーにとっても当てはまることです。そしてそれをあまり語っていないと思います。なぜなら、2026年2月のフロンティアで可能なことと、実際に起きていること、そしてベンダーが売りたいものの間のギャップが、これほど大きくなったことはないからです。

あのMETRの研究——ちなみに調査ではなくランダム化比較試験です——では、AIコーディングツールを使ったオープンソース開発者がタスクを19%遅く完了したという結果が出ました。研究者たちはタスクの難易度、開発者の経験、ツールへの習熟度まで制御変数として考慮しましたが、どれも関係ありませんでした。AIは経験豊富な開発者さえも遅くしました。なぜか？co-workがあのスピードで出荷できる世界で、なぜ？

ワークフローの混乱が生成スピードを上回ったからです。開発者たちはAIの提案を評価し、もう少しで正しいコードを修正し、自分のメンタルモデルとモデルのアウトプットの間でコンテキストスイッチングを行い、正しいように見えたが実は違うという生成コードが導入した非常に微妙なバグをデバッグするのに時間を費やしました。より広い調査では46%の開発者がAI生成コードを完全には信頼していないと答えています。これは素人ではありません。経験豊富なエンジニアたちが一貫した問題に直面しています。AIは速いですが、彼らが不可欠と見なす人間のレビューなしには信頼するには信頼性が足りないということです。

これが採用研究者が繰り返し識別するJ曲線のアイロニーです。既存のワークフローにAIコーディングアシスタントを接続すると、良くなる前に生産性が落ちます。Jの底のように落ちるのです。しばらくの間、時には数ヶ月。その落ち込みが起きるのは、ツールがワークフローを変えるのに、ワークフローがそのツールに合わせて明示的に再設計されていないからです。新しいエンジンで古いトランスミッションを動かしているようなものです。ギアはきしみます。

ほとんどの組織が今このJ曲線の底に座っています。そして多くはその落ち込みをAIツールが機能しないという証拠として解釈しています。ベンダーが約束したことを守らなかった、ワークフローが適応していないという証拠が実はAIはハイプで本物ではないという証拠だと思い込んでいます。

GitHub Copilotのケース——コスト削減と複雑化

GitHub Copilotはこの最も明確な例かもしれません。2,000万ユーザー、AIコーディングツールの市場シェア42%と言われています。そしてラボ研究では独立したタスクでコード補完が55%速いという結果が出ています。GitHub Copilotを推進している人たちのスライドを喜ばせる数字でしょう。しかし本番環境では話はずっと複雑です。プルリクエストが大きくなる、レビューコストが上がる、生成されたコードによってセキュリティの脆弱性が増える、うまくやるにはどうすればいいかと開発者たちが格闘している。あるシニアエンジニアはとても鋭くこう表現しました。「Copilotはコードを書くコストを下げるが、それを所有するコストを上げる。」これは実際、業界の多くのエンジニアから聞いたとても一般的な感想です。Copilotに限らず、AI生成コードについて全般的にそう言えます。

25%から30%以上の有意な生産性向上を見ている組織は、Copilotをインストールして1日のセミナーをやってそれで終わりにした組織ではありません。慎重に考えてホワイトボードに戻り、AI能力を中心に開発ワークフロー全体を再設計した組織です。仕様の書き方を変え、コードのレビュー方法を変え、ジュニアとシニアに何を期待するかを変え、AI生成コードが導入する新しいカテゴリのエラーを捕捉するためにCI/CDパイプラインを変えた。エンドツーエンドのプロセス変革です。ツールの採用ではありません。

そしてエンドツーエンドの変革は難しい。時には政治的に争点になります。コストがかかる。時間がかかる。そしてほとんどの企業にはそれに耐える胆力がありません。だからこそほとんどの企業がJ曲線の底に引っかかっているのです。だからこそフロンティアチームとそれ以外の差は広がるだけでなく、急速に加速しています。なぜなら、ダークファクトリーを動かしているエッジのチームが最も大きなゲインを得る立場にあるからです。Claude Opus 4.6やCodex 5.3のようなツールが地球上のすべてのソフトウェアエンジニアに広範なエージェント能力を与えるとき、ソフトウェアエンジニアの95%はそれをどう使えばいいか分かっていません。レベル4やレベル5で実際に動いている人たちこそが、これらのツールの乗算的な価値を本当に得られる人たちです。

人間のための組織構造がAIの足かせに

これが政治的に争点になる問題だとしたら、ツールの問題だけでなく人の問題だとしたら、私たちはソフトウェア組織の本質を見る必要があります。ほとんどのソフトウェア組織は人間がソフトウェアを構築することを支援するために設計されました。すべてのプロセス、すべての儀式、すべての役割、それらはチームで一緒にソフトウェアを構築する人間に調整構造が必要だから存在しています。スタンドアップミーティングは、同じコードベースで作業している開発者が毎日同期する必要があるから存在します。スプリントプランニングは、人間が作業記憶に持てるタスク数に限界があり、定期的に再優先順位付けするケイデンスが必要だから存在します。コードレビューは、人間が犯すミスを他の人間が捕捉できるから存在します。QAチームは、ソフトウェアを構築する人間がそれを客観的に評価できないから存在します。

お分かりのとおり、これらの構造はすべて人間の限界への対応です。そしてコードを書いているのが人間でなくなったとき、それらの構造はオプションではなく、摩擦になります。実装が数週間ではなく数時間で行われるとき、スプリントプランニングはどうなるのか？AIが20分で生み出した差分を誰も本当にレビューできないとき、コードレビューはどうなるのか。しかもさらに20分でまた別のものを生み出します。AIが見せられなかったシナリオに対してすでにテスト済みであるとき、QAチームは何をするのか？

StrongDMの3人チームにはスプリントがありません。スタンドアップもありません。Jiraボードもありません。仕様を書き、アウトカムを評価する。それだけです。現代のソフトウェア組織の運用システムを構成する調整レイヤー全体——ほとんどのマネージャーが時間の60%を維持することに費やしているそのレイヤー——がただ削除されています。存在しません。コスト削減策として排除されたからではなく、もはや目的を果たさないからです。

組織構造の変革と役割の再定義

これは技術的な変革よりも見えにくい構造的シフトであり、より重要かもしれません。問いはこうなってきています。人間がコードを書く世界のために構築された組織構造はどうなるのか？主な価値が調整にあるエンジニアリングマネージャーはどうなるのか？12のチームが時間通りにリリースするよう確認することが仕事のスクラムマスター、リリースマネージャー、テクニカルプログラムマネージャーはどうなるのか？

見てください、これらの役割は一夜にして消えません。しかし重力の中心はシフトしています。エンジニアリングマネージャーの価値は「機能を構築するチームを調整する」から「エージェントが機能を構築できるほど明確に仕様を定義する」へ移っています。プログラムマネージャーの価値は「人間チーム間の依存関係を追跡する」から「ファクトリーを流れる仕様のパイプラインを設計する」へ移っています。

重要なスキルは調整から明確化へと急速にシフトしています。みんなが同じ方向に漕いでいることを確認することから、機械がそれを実行できるほど方向性が十分正確に記述されていることを確認することへ。そしてエンジニアリングマネージャーには追加の課題があります。エンジニアが同じことをできるようにどうコーチするか。これは人の課題です。

これを些細な変化だと思うなら、AIエージェントが人間の介入なしに正しく実装できるほど詳細な仕様を書こうとしたことがないのでしょう。そして確実に、エンジニアに同じことをするよう指導しようとしたこともないはずです。それは違うスキルです。ほとんどの組織がほとんどの人に必要としてこなかった厳密なシステム思考が必要です。なぜなら、仕様の反対側にいる人間が判断、コンテキスト、「XとYのどちらの意味ですか？」というSlackメッセージでギャップを埋められるからです。機械にはその人間的なコンテキストの層がありません。記述されたものを構築します。記述が曖昧なら、ギャップを顧客中心の推測ではなくソフトウェア的な推測で埋めたソフトウェアが返ってきます。

ボトルネックは実装速度から仕様の品質へ移動しました。そして仕様の品質は、システム、顧客、問題をどれだけ深く理解しているかの関数です。その種の理解は常にソフトウェアエンジニアリングで最も希少なリソースでした。ダークファクトリーはその需要を減らしません。ただ、それを絶対的な法則にするだけです。唯一重要なことになります。

レガシーシステムとブラウンフィールドの現実

さて、正直に言いましょう。ここまで話してきたことはすべて、ゼロから構築することを前提にしています。ソフトウェア経済の大部分はゼロから構築していません。エンタープライズソフトウェアの大半はブラウンフィールド——既存のシステムで、何年も何十年もかけて積み上げられ、本番環境で動き、実際のユーザーにサービスを提供し、実際の収益を運んでいます。ビジネストランザクションを処理するCRUDアプリケーション。15年の機能追加で有機的に成長したモノリス。特定のコードベースと特定のチームのワークフローの癖に合わせて調整されたCI/CDパイプライン。長くいるおかげであの環境変数がなぜあの値に設定されているかを覚えている3人の頭の中にある構成管理。

心当たりがある方もいるでしょう。レガシーシステムをダークファクトリーでそのまま処理することはできません。そこに接続すれば解決するふりはできません。そういうものではありません。その仕様は存在しません。テストがあったとしても既存のコードベースの30%しかカバーしておらず、残りの70%は組織の知識と口伝の上で動いています。週に1回ポロシャツで現れてコードのどこに何が埋まっているかを知っている人がいます。

システムが仕様なのです。そのシステムが何をするかの唯一の完全な記述だからです。なぜなら誰も、10年以上のパッチ、ホットフィックス、当然のように永続化した一時的な回避策の積み重ねで蓄積した何千もの暗黙の決断を書き留めたことがないからです。これがより自律的なソフトウェア開発へのこの連続体に沿った中間状態についての真実です。

ほとんどの組織にとって、道はコードを書くエージェントをデプロイするところから始まりません。実際に存在するソフトウェアが実際に何をするかの仕様を開発するところから始まります。そして、動いているシステムに埋め込まれた暗黙の知識をリバースエンジニアリングするその仕様作業は、非常に難しく、深く人間的な作業です。

請求モジュールにカナダの顧客のためのエッジケースがある理由を知っているエンジニア、2021年の障害時に急いでモノリスから切り出したマイクロサービスをその後ずっと維持し続けている経緯を覚えているアーキテクト、PRDが何と言っているかではなく実際のユーザーのためにソフトウェアが実際に何をしているかを説明できるプロダクト担当者、こういった人たちが必要です。ドメイン専門知識、容赦のない正直さ、顧客理解、システム思考——ダークファクトリー時代においてもより重要になる人間的な能力であり、減るのではありません。

ブラウンフィールドからダークファクトリーへの移行パス

移行パスは企業ごとに異なりますが、おおよそこのような形になります。まず、レベル2か3程度で開発者がすでにやっている作業——新機能の開発、バグ修正、モジュールのリファクタリング——を加速させるためにAIをできる限り活用します。ほとんどの組織が今ここにいて、J曲線の生産性低下が起きる場所でもあります。それは想定内として受け入れてください。

次に、システムが実際に何をするかをドキュメント化するためにAIを使い始めます。コードから直接仕様を生成し、実際の既存の振る舞いを捉えるシナリオスイートを構築し、将来のダークファクトリーが必要とするホールドアウトセットを作成します。

それからCI/CDパイプラインをAI生成コードの大量処理に対応するよう再設計します。異なるテスト戦略、異なるレビュープロセス、異なるデプロイゲートが必要です。

第4に、レガシーシステムを並行して維持しながら、新規開発をレベル4か5の自律エージェントパターンへとシフトし始めます。そのパスには時間がかかります。そうでないと言っている人は何かを売ろうとしています。最も速く到達する組織は、必ずしも最も高級なベンダーツールを買った組織ではありません。自分たちのコードについて最も良く、最も正直な仕様を書ける組織、最も深いドメイン理解を持つ組織、自分たちのシステムが実際に何をするかをドキュメント化するという退屈で地味な作業に投資する規律がある組織、そして人々がこの新しいダークファクトリー時代をサポートするためにスケールアップするのをサポートできる組織です。

タレントの再編——ジュニア開発者とキャリアラダーの崩壊

明確なタイムラインをお伝えすることはできません。一部の組織にとっては複数年の移行に見えており、それを隠したくありません。一部はより速く進んでいて数ヶ月に見えます。率直に言って、組織的な痛みへの耐性にかかっています。

そしてそれが人材の再編へとつながります。2025年のHarvard研究によると、AIコーディングツールの広範な採用から6四半期以内にジュニア開発者の雇用が9〜10%減少しています。キャリアの始まりにいる方々はこれを聞いてうなずき、実際にはもっとひどいと言うでしょう。英国では2024年に大学院レベルのテック職が46%減少し、2026年にはさらに53%の減少が見込まれています。米国では、ジュニア開発者の求人が67%減少しました。

簡単に言うと、ジュニア開発者のパイプラインが崩壊し始めており、その影響はエントリーレベルの仕事が見つからない人たちをはるかに超えています。もちろんそれ自体も深刻な問題ですが。ソフトウェアエンジニアリングのキャリアラダーは常にこのように機能してきました。ジュニアは実践で学びます。シンプルな機能を書き、小さなバグを直し、コードベースに浸ることで吸収します。シニアが作業をレビューしてメンタリングし、ミスを捕捉します。5年から7年かけて、ジュニアは蓄積された経験を通じてシニアになります。

このシステムは率直に言って、エンタープライズの衣をまとった徒弟制度モデルです。AIはその底を壊します。AIが簡単な機能と小さなバグ修正——ジュニアが依拠する作業——を処理するなら、ジュニアはどこで学ぶのか？AIがシニアエンジニアよりも速く、より徹底的にコードをレビューするなら、メンタリングはどこから始まるのか？キャリアラダーは下から空洞化しています。上にはシニア、下にはAI、そして学習が起きていた薄くなる中間があります。

パイプラインは崩れ始めています。そして同時に、以前よりもはるかに多くの優秀なエンジニアが必要です。以前言ったことですが、ソフトウェアエンジニアリングの死は信じません。より良いエンジニアが必要なのです。ハードルは上がっており、常に開発が最も難しく、採用が最も難しかったスキルに向かって上がっています。

2026年のジュニアには、2020年に中堅エンジニアに期待されていたシステム設計の理解が必要です。エントリーレベルの仕事が必ずしも難しくなったからではなく、エントリーレベルの仕事が自動化され、残った仕事がより深い判断力を必要とするからです。CRUDエンドポイントを書ける人はもう必要ありません。AIが数分でそれをやります。システムアーキテクチャを見て、どこが負荷でおかしくなるか、セキュリティモデルにどこに穴があるか、ユーザーエクスペリエンスがエッジケースでどこで崩れるか、ビジネスロジックが間もなく間違いになる仮定をどこにエンコードしているかを特定できる人が必要です。

ジュニアとして、AIを使えばそのギャップを埋められると思っているなら、お伝えしたいことがあります。シニアたちもAIを使いながら、その上に直感を持っています。だからシステム思考が必要で、顧客の直感が必要で、製品全体を頭に入れてパーツがどう相互作用するかを推論できる能力が必要です。エージェントが正確に実装できるほど明確に仕様を書ける能力が必要で、そのためにはエージェントが尋ねるべきだと気づかない質問を先読みできるほど問題を深く理解していることが必要です。

スキルシフト——ジェネラリストの台頭と新しいキャリアモデル

こういったスキルは、常に本当に優れたエンジニアと単に十分なエンジニアを分けてきたものです。今との違いは、十分というのがシニアを含むどのレベルでも、もはや生存可能なキャリアポジションではないということです。なぜなら、十分というのはモデルがやることだからです。

Anthropicの採用はすでにシフトしています。OpenAIの採用はすでにシフトしています。採用は業界全体でシフトしており、スペシャリストよりもジェネラリストへ向かっています。特定の非常に狭いテックスタックに精通している人よりも、ドメインをまたいで考えられる人へ。論理は非常に単純です。AIが実装を処理するとき、人間の価値は実装を正しく指示できるほど十分に広く問題空間を理解することにあります。Kubernetesについてすべてを知っているが、アーキテクチャの決断の製品的な意味を推論できないスペシャリストは、ポッドを手動で設定できなくても、システム、ユーザー、ビジネスの制約を理解しているジェネラリストよりもはるかに価値が低いのです。

一部の組織は、ジュニアエンジニアのための医療研修のようなモデルに移行しています。キャリアの初期の開発者がAIシステムと並んで作業し、AIアウトプットをレビューし、AIと作業することで何が正しくて何が微妙に間違っているかについての判断力を磨くシミュレーション環境です。ゼロからコードを書いて学ぶのと同じではありません。そうだと言うつもりはありません。しかし、仕事がコードを一から書くのではなくAIのアウトプットを指示し評価することである世界のための、より良いトレーニングかもしれません。

また以前も指摘しましたが、今まさにパイプラインが崩壊しているにもかかわらず、優先的にジュニアを採用している組織があります。それは正確に、彼らが求めているジュニアたちがChat GPTが2022年にローンチする前にキャリアをスタートした開発者が大半を占めるエンジニアリング組織に、AIネイティブな新鮮な血を注入するからです。その世界では、最初からAIネイティブな人たちがいることが巨大な加速要因になりえます。そしてそれはジュニアにとって一つのプラスを指摘しています。ジュニアなら、AIに思い切り乗ってください。ジェネラリストの能力に乗ってください。学習の速さに乗ってください。非常に広い範囲のユースケースにわたって、AIで数分で問題を把握して解決できることを見せてください。

Gartnerは2027年までにソフトウェアエンジニアの80%がAI支援開発ツールのスキルアップが必要になると予測しています。これは過小評価であり、100%になります。数字が問題なのではありません。問いはスキルが変わる必要があるかどうかではありません。変わることはみんな分かっています。問いは、私たち業界が能力の変化に合わせてトレーニングインフラを十分に速く開発できるかどうかです。正直に言うと、ソフトウェアエンジニアとして最後に触れたモデルが2026年1月にリリースされたものなら、あなたはすでに時代遅れです。2月のモデルが必要です。そしてそれは今年ずっと、来年にかけても真実であり続けます。そして、ソフトウェアに依存する組織が、人材パイプラインがこのように月単位で構築・再構築されているこの時期を乗り越えられるかどうかは大きな問いです。なぜなら、この移行期間を通じて人々に投資し続けなければならないからです。

AIネイティブスタートアップが示す未来の組織モデル

では、AIネイティブスタートアップを見ると新しい組織の形はどのようなものか。伝統的な組織と何が違うのか。AIネイティブのコードエディタであるCursorは年換算収益5億ドルを超えており、最後に数えたときには数十人の従業員がいました。従業員1人あたり約350万ドルの収益を出しています。平均的なSaaS企業が従業員1人あたり60万ドルを生み出す世界で。Midjourneyも同様です。数十人、数え方によって100人弱くらいの人員で5億ドルの収益を生んでいると言われています。Lovableはほんの数ヶ月で数億ドルの年換算収益に達しており、チームは拡大しているものの収益の成長スピードにはるかに追いついていません。彼らも従業員1人あたり数百万ドルの収益という世界を見ています。

AIネイティブスタートアップのトップ10は従業員1人あたり300万ドル強の収益を平均しており、これはSaaSの平均の5〜6倍です。これが十分に多くのケースで起きているため、外れ値ではありません。これがAIネイティブ組織のテンプレートです。

15人で年間1億ドルを生み出すとしたら——2025年に複数の事例で見てきた数字ですが——どんな姿になるのか。伝統的なソフトウェア会社には見えません。伝統的なエンジニアリングチーム、伝統的なプロダクトチーム、QAチーム、DevOpsチームはありません。ユーザーのニーズを理解することが抜群に得意な少人数のグループが、それを明確な仕様に翻訳することに長け、実装を処理するAIシステムを指示している姿です。

組織図は急激にフラットになっています。製品を構築する何百人ものエンジニアを管理するために存在する調整の層は、エンジニアリングをエージェントが行うときには削除できます。中間管理職の層は、大企業では根本的に異なる何かへ進化するか、完全に消えるかのどちらかになるでしょう。

残るのは、判断が自動化できない人だけです。誰のために何を構築すべきかを知っており、なぜかを知っており、優れたAIセンスを持っている人たち。乗馬の馬のセンスのようなもので、馬を持つ感覚があって馬を行きたい方向に向けられる、AIについてそういう感覚を持てる人が必要になります。そして、それは学習できるスキルです。

ソフトウェア開発の未来——需要の拡大と「判断力」の希少性

ますます多くの企業がCursorのような運営モデルへ向かっていくにつれて行われる再構成は——完全にそこに到達することは決してないとしても——本物です。起きるでしょう。特定の役割の特定の人にとって非常に痛みを伴うでしょう。中間管理職の層、エントリーレベルの作業が最初に自動化されているジュニア開発者、手動テストパスを実行するだけのQAエンジニア、価値の全てが調整だけのリリースマネージャー。そういった役割は変革するか消えるかのどちらかになるでしょう。そしてそういった役割の人たちは、自分の開発全体のワークフローをAI中心のエージェントで書き直す方向に進む方法を見つける必要があります。それはスタック、マネージャーのトークン支出予算、学習意欲によって見た目が異なります。しかし、自分のキャリアのために、できるだけ速くその方向へ傾いていく必要があります。

AIと雇用に関するすべての会話で失われてしまうことを一つお伝えして締めくくりたいと思います。私たちはソフトウェアの需要の天井を見つけたことがなく、知性の需要の天井を見つけたこともありません。コンピュートのコストがメインフレームからPCへ、PCからクラウドへ、クラウドからサーバーレスへと下がるたびに、世界が生み出すソフトウェアの総量は横ばいにはなりませんでした。爆発しました。古いコスト構造では経済的に不可能だったソフトウェアの新しいカテゴリが実現可能になり、そして遍在し、そして不可欠になりました。クラウドは既存のソフトウェアを安く動かすことができるようにしただけではありませんでした。SaaS、モバイルアプリ、ストリーミング、リアルタイム分析、その他、サーバーラックを買わないと何もリリースできなかった時代には存在できなかった100以上のカテゴリを生み出しました。

同じダイナミクスが今適用されると思います。そしてそれは過去のすべての移行を矮小化するスケールで適用されます。あらゆる業界のあらゆる企業がソフトウェアを必要としています。地方の病院、中規模の製造業者、家族経営の物流会社のような企業の多くは、現在の人件費では必要なものを構築する余裕がありません。カスタム在庫管理システムは伝統的には50万ドル以上かかり、1年以上かかることもあります。患者ポータルの統合には30万ドルかかるかもしれません。そういった会社は今日スプレッドシートで何とかしています。しかし私たちはソフトウェア生産のコストを1桁以上下げています。そして今、その満たされていないニーズが対処可能になっています。理論的にではなく、今です。伝統的なソフトウェア企業が決して入れなかった市場に参入できます。ソフトウェアの総市場規模が爆発しています。

これは仕事が消えて苦しんでいる人への非常に都合の良い反論のように聞こえるかもしれません。同じことではありません。市場が大きくなっているというだけでは解決しません。しかし知性が安くなるとどうなるかについての構造的な観察です。需要は上がるでしょう。下がりません。コンピュート、ストレージ、帯域幅、劇的に安くなったあらゆるリソースでこれが起きるのを見てきました。需要が飽和したことはありません。制約は常に次のボトルネックへ移りました。

そしてこのケースでは、その判断とは何を構築すべきかで誰のためにかということです。この世界で成功する人たちは、常に置き換えが最も難しかった人たちです。顧客を深く理解し、システムで考え、曖昧さを抱えて不確実性の中で意思決定でき、それが存在する前に何が存在すべきかを明確に表現できる人たち。

ダークファクトリーはそういった人たちを置き換えません。置き換えないでしょう。増幅します。5人のエンジニアを持つ優れたプロダクト思考の人を、無限のエンジニアリング能力を持つ優れたプロダクト思考の人に変えます。制約は、作れるかから、作るべきかへ移ります。そして作るべきかは常により難しく、より面白い問いでした。

おわりに——ダークファクトリーは現実であり、格差は拡大している

魔法の解決策はお伝えできませんが、この緊張に向き合わなければ不誠実だということはお伝えしなければなりません。ダークファクトリーは本物です。ハイプではありません。実際に機能しています。世界中の少数のチームが、人間が一行もコードを書かず、レビューもせずにソフトウェアを生産しています。モデルの世代が上がるごとに改善されるリリース可能な本番コードをリリースしています。

ツールは自分自身を構築しています。フィードバックループは閉じました。そしてそれらのチームはどんどん速くなっています。それなのに、ほとんどの企業はそこにいません。レベル2で引っかかっています。自分たちを速くしていると信じているAIツールで、測定可能な形で遅くなっています。間違っています。人間がすべての実装作業をやる世界のために設計された組織構造で動いています。

これらは同時に真実です。フロンティアはほとんどの人が認めたいよりはるかに先を行っており、中間はフロンティアチームが語りたいよりはるかに後ろにいます。その距離はテクノロジーのギャップではありません。人のギャップです。文化のギャップです。組織のギャップです。どんなツールもどんなベンダーも埋めることのできない、変わる意志のギャップです。

この距離を渡る企業は、最高のコーディングツールを買った企業ではありません。自分たちのシステムが何をするかをドキュメント化するという、非常に難しく、非常に遅く、非常に地味な作業をやり遂げる企業です。調整のスキルではなく判断のスキルを中心に組織図と人材を再構築する企業です。そして、構築すべきものを構築するために機械を指示できるほど深くシステムと顧客を理解する人材に投資する組織です。

そしてそういった組織は、この変化は望む速さでは起きないということを自分に対して正直に認められる必要があります。なぜなら人間はゆっくりと変わるからです。ダークファクトリーにはより多くのエンジニアは必要ありません。しかし切実により良いエンジニアを必要としています。そして良いとは数年前とは異なることを意味します。何が存在すべきかについて明確に考えられる人、機械がそれを構築できるほど十分に正確に記述できる人、構築されたものが実際にそれが構築された本当の人間に役立つかどうかを評価できる人を意味します。

これは常にソフトウェアエンジニアリングの難しい部分でした。ただ以前は、実装の複雑さが、実際にそれが得意な人がいかに少ないかを隠させていました。機械は今その迷彩を剥ぎ取りました。そして私たちは全員、自分がソフトウェアを構築することにどれだけ優れているかを明らかにしようとしています。

この動画が、自動化されたソフトウェア生産のダークファクトリーと私たちの多くが今日ソフトウェアを構築している方法の間の巨大なギャップを理解するのに役立てば幸いです。その移行を乗り越えるにあたって幸運を祈っています。さらに深く掘り下げたい方のために、Substackに大量の演習とリソースをまとめました。これは人々がもっと学びたいと思うテーマなので、できる限り多くをお伝えしたいと思いました。楽しんでください、コメント欄でお会いしましょう。

コメント

タイトルとURLをコピーしました