Post
JA EN

「AIがあるんだから軸は要らない」はどこで崩れるか——AIが安くしたのは「実装」だけ

Posted
By
43 min read
「AIがあるんだから軸は要らない」はどこで崩れるか——AIが安くしたのは「実装」だけ
  • 想定読者： 「AIがあるんだから深い専門は要らないのでは」と感じている／言われているエンジニア、AI前提でエンジニア育成や開発体制を考えるテックリード・人事
  • 前提知識： 生成AIによるコーディング支援（Copilot、エージェント型ツールなど）に触れたことがあること
  • 所要時間： 約14分

概要

「AIがあるんだから、深い専門の軸なんて要らない」——AI時代のキャリア論で、この声はますます強い。実装はAIがやってくれる、足りない知識はAIに聞けばいい、と。

だが、この言い分は一点を見落としている。AIが安くしたのは、ソフトウェア開発の”真ん中”——コードを書くという実装工程——だけだ。 実装は、概念から本番リリースまでの全工程のうち25〜35%にすぎない1。残りの「何を作るか（要件・仕様・プロダクトの判断）」と「どう本番品質に仕上げるか（レビュー・設計・セキュリティ・本番化）」は、安くなっていない。むしろAIが生成する量が増えるほど、レビューと検証の負荷は上がる。開発者の最大の不満は、いまや「ほぼ正しいが微妙に違う」AI出力の修正だ2。

つまり、軸は消えたのではない。要る”場所”が、真ん中から両端へ再配置された。 「何を作るか」というプロダクトの軸と、「どう本番にするか」という技術の軸——AIはそのどちらも肩代わりしていない。「軸が要らなくなった」のではなく、軸を持たない人でも”作り始められる”ようになっただけだ。入口は広がったが、出口（本番に出すこと）は変わっていない。

本記事では、この「真ん中だけが安くなった」という構図を起点に、「AIがあるんだから○○は要らない」という一連の言い分——浅く広くで戦える／そもそも軸は要らない／量産でいい／新人は要らない——を、一次資料で順に点検する。結論はどれも同じところに帰着する。AIは軸を持つ人を増幅し、持たない人をかえって沈める。

この記事は3部作の姉妹編にあたる。「そもそも軸を作らずに浅く広くで成功できるのか」という構造論は本体記事で、「AIがやるなら確認は軽くていいのか」はもう一本の姉妹編で扱う。

AIが安くしたのは「実装」だけ——軸は両端へ再配置される

まず、いちばん大きな誤解を解いておきたい。「AIがコードを書く」を「AIが開発をやる」と混同することだ。

コードを書く作業は、ソフトウェア開発の全体から見れば一部分にすぎない。あるコンサルティング会社の分析では、コーディングとテストは概念からローンチまでの全工程の25〜35%であり、そこを速くすると「ボトルネックはレビュー・統合・リリースという後工程へ押し上げられる」と報告されている1。実際、AI生成コードが増えた現場では、負荷がレビューと検証に移っている。約49,000人の開発者調査で最大の不満に挙がったのは「ほぼ正しいが微妙に違う」AI出力の修正であり、AIの正確性への信頼はむしろ低下した2。

この「真ん中が安くなり、両端が前景化する」構図は、現場の分業として現れ始めている。あるSaaS企業は、全社員（プロダクトマネージャー・デザイナー・サポートを含む）にコーディングエージェントを開放し、60日で非エンジニア11人が40件のプルリクエストをマージした。だが運用ルールは明確だ——「非エンジニアとエージェントはコードを作る。エンジニアがレビューしてマージする」。本番インフラへの直接アクセス、レビューなしのデプロイ、機密データへのアクセスは、非エンジニアには許されない3。「作る」は民主化したが、「本番品質に仕上げる」はエンジニア＝技術の軸を持つ人に残った。

著名なエンジニアのSimon Willisonは、この変化を「vibe engineering」と名づけて整理している。AIで誰でもコードを出せるようになった結果、エンジニアの差別化要因はコードを書くことから、計画・仕様・テスト・レビュー・本番化・説明責任といったエンジニアリングの規律へ移った、と。彼の言葉を借りれば、「LLMが書いたコードでも、レビューし、十分にテストし、どう動くかを説明できるなら、それはvibe codingではなくソフトウェア開発だ」4。

そして見落とされがちなのが、もう一方の端——「何を作るか」にも軸が要ることだ。非エンジニアが爆速で”良い”プロトタイプを作れるのは、ユーザーやプロダクトを理解する軸を持っているからにほかならない。曖昧な指示を投げれば、AIは勝手な仮定で隙間を埋め、成果は崩れる5。要件を精密に定義し、何を作るに値するかを見極める力——これは本記事の姉妹・本体記事で言う「非技術の軸」そのものだ。

整理しよう。AIが安くしたのは「実装」という真ん中だけ。「何を作るか（プロダクトの軸）」と「どう本番品質にするか（技術の軸）」という両端は、安くなっていない。 だから——

  • 作り手が技術の軸を持つ（エンジニア）なら、軸は最初から入っていて、ひとりで本番まで運べる。プロトタイプと本番の距離が近い。
  • 作り手が技術の軸を持たない（非エンジニア／生のAI出力）なら、軸は後工程に分業として現れる。誰かが仕上げねばならない。

どちらにせよ、軸の総量は消えない。投入する場所が変わるだけだ。 本当に何の軸も持たない人——プロダクトの軸も技術の軸もない人——は、AIがあっても、良いプロトタイプすら作れず、本番にも仕上げられない。

正直な留保。 「価値が”両端に集中する”」という幾何学そのものは、まだ論説・観察の域を出ない。「価値はむしろパイプライン全体のフローに分散する」という対抗的な見方もある。また「実装が一夜でコモディティ化した」という強い言い方も過大評価だ——熟練開発者は慣れたコードベースでAIを使うとむしろ遅くなる、という実測すらある6。ただしその”減速”は、熟練者ほどAI出力の検証にコストを払う、ということ。つまり検証の軸が前景化したという本筋を、皮肉にも裏づけている。本記事は「両端に集中」と断定はせず、「軸の要る場所が真ん中から両端へ再配置された」という範囲にとどめる7。

それでも「浅く広く」はAIで戦えるのか——むしろ沈める

ここで素直な反論が来る。「両端に軸が要るとしても、AIがあれば浅く広い人でも足りない部分を補えるのでは？」。

確かに、AIがスキルを平準化する方向のデータはある。GitHub Copilotの実験では処置群が約56%速く、経験の浅い開発者ほど恩恵が大きかった8。複数社の大規模RCTでも、生産性向上はジュニア層で有意だった9。コンサルタント対象の「ジャグド・フロンティア」研究では、AIの能力が及ぶ範囲で下位半分が43%改善——底上げは起きる10。

だが、効くのは定型的で孤立した、答えの見えるタスクに限られる。同じジャグド・フロンティア研究は、AIの能力が及ばない範囲では、AI利用群がかえって19%成績を落としたことも報告している10。そして、軸の有無で結果が割れることを最も鮮明に示したのが、起業家640名のRCTだ。AIを与えると高パフォーマーは15%以上改善し、低パフォーマーは約10%悪化した。差は「何をAIに任せ、何を自分で判断するかの見極め」にあった11。AIは格差を埋めるどころか広げたのだ。

熟練側も整合する。前述のとおり、深い文脈を持つ開発者ほどAI出力の検証コストがかかり、結果が遅くなることすらある6。ある大規模調査がAIの効果を「チームを直すのではなく、増幅する」と要約したのは、この非対称性を指している12。軸がなければ、増幅される土台そのものがない。

「ベンチマークが高いんだから軸は要らない」——その数字が崩れている

最も過激な反論は、「AIが専門作業を全部やるのだから、人間が軸を持つ意味がない」というものだ。「自然言語こそ新しいプログラミング言語だ」という有名な物言いが、この気分を象徴する13。

その根拠は、たいてい一点に集約される。AIがコーディングのベンチマークで高スコアを出している、という事実だ14。だが——その数字こそ、いま激しく揺らいでいる。あるベンチマークでは成功例の約3割で課題文やコメントに解答が含まれており、課題の大半がモデルの学習データに入る時期に作られていた。推論ではなく暗記が混じっているのだ。象徴的なことに、OpenAI自身が代表的ベンチマークの利用をやめ、「もはやフロンティアのコーディング能力を測れない」と表明した15。軸不要論の最強の数値根拠は、汚染と暗記で水増しされていた。

仮にAIの能力を認めても、「だから人間に軸は要らない」とはならない。自動化研究の古典「自動化の皮肉」が指摘するとおり、自動化が進むほど、残された例外対応と監視という人間の仕事はかえって重要かつ困難になる16。ソフトウェアでは、これは「検証ギャップ」として現れる。AIアシスタントを使った被験者は、有意に脆弱性の多いコードを書き、しかも「自分は安全なコードを書けた」と誤認しやすかった17。AIが推奨するパッケージは、モデルによっては2割超が実在せず（オープンソースのモデルで21.7%）、それを狙う新手の攻撃の温床にすらなっている18。「ほぼ正しい誤り」を捕まえる網——それが軸だ。

「速いんだから量産でいい」——負債として跳ね返る

「速く作れるんだから、品質や設計は後回しで量産すればいい」。これも通らない。AI採用が25%増えるごとにデリバリの安定性が約7%低下するという大規模推定があり19、2億行超を分析した調査では、重複コードが2021年の8.3%から2024年には12.3%へ増え、2024年は史上初めて「重複の追加」が「リファクタリング」を上回った年になった20。Fortune 50規模の分析では、AI生成コードの増加に伴い権限昇格につながる経路が+322%も増えた21。「浅く広く量産」は、計測できる負債として跳ね返る。その負債を弾けるのは、設計とセキュリティの軸を持つ人だけだ。

派生する言い分も同じだ。「基礎は要らない（AIに聞けばいい）」——だが「ほぼ正しい誤り」は、基礎のない人には見えない2。「プログラミングは学ばなくていい」——もし自然言語で厳密にソフトウェアが書けるなら、そもそもプログラミング言語を作る必要はなかった。ソフトウェアの本質的な複雑さは、道具を変えても消えない22。「自分で学ばなくていい（AIが教える）」——短期は成果が出るが、苦労して身につける工程を飛ばすと、長期のスキル形成が痩せる23。いずれも、軸を持つ人がAIを使う場面でだけ成り立ち、軸のない人が丸投げする場面で破綻する。

AIを「雇う側」に回っても、軸は要る

立ち位置の変化として捉え直すこともできる。AIを使うとは、仕事を割り振り、成果を評価し、責任を負うこと——いわば雇う側、マネージャーの役割だ。実際この変化は「全従業員がエージェントの上司になる」とまで語られている2425（ただし将来像の色が濃く、コア業務を完全にAIへ委ねている企業はまだ一握りだ26）。

問題はその先。良い雇い主に必要なのは、部下の成果の良し悪しを見抜く目と、何を任せ何を自分で抱えるかの差配——これは結局「軸」そのものだ。「何でも屋」理論が言うように、起業家（＝雇う側）は最も弱いスキルに事業全体を制約される27。評価・判断の軸を持たない人ほど、無能な雇い主になり、AIに丸投げして事故を起こす。AIに任せられる範囲が広がるほど、誰もが雇う側へ押し出される。そして良い雇い主であるために、軸が要る。

「AIがあるから新人は要らない」——軸を育てる土壌が枯れる

最後に、組織の言い分を一つ。「定型業務はAIが引き受けるから、ジュニア採用や新人教育は要らない」。

採用が細っているのは事実だ。米国の給与データを使った研究では、AIの影響を受けやすい職種で若手（22〜25歳）の雇用が相対的に減り、ソフトウェア開発の若手はピークから約2割減ったと報告された28。GenAIを採用した企業でジュニアの採用が減り、シニアは増え続けているという大規模分析もある（いずれも査読前で、解雇ではなく採用減である点に留意）29。ただし、この減少は利上げによるテック採用縮小の時期と重なっており、AIだけが原因とは言い切れない30。

問題は、ここにパイプラインの罠があることだ。シニアは、ジュニア時代に手を動かして軸を作った人の成れの果てである。ジュニアを育てなければ、数年後にシニアが枯渇する。マイクロソフトの技術幹部らも、初期の生産性低下を受け入れてでも若手を雇い育て続けるよう促している31。「AIがあるから新人は要らない」は、目先の効率と引き換えに、軸を育てる土壌そのものを枯らしかねない。

まとめ

  • AIが安くしたのは「実装」という真ん中だけ。 実装は全工程の25〜35%にすぎず、「何を作るか（プロダクトの軸）」と「どう本番品質にするか（技術の軸）」という両端は安くなっていない1234。
  • 軸は消えたのではなく、要る場所が真ん中から両端へ再配置された。作り手が軸を持てば最初から入り、持たなければ後工程に分業として現れる。軸の総量は不変。本当に何の軸もない人は、AIがあっても作れず仕上げられない。
  • 「浅く広くでもAIで戦える」は成り立たない。平準化が効くのは定型・孤立タスクに限られ、軸のない人はかえって沈む1011。AIは軸を持つ人を増幅する12。
  • 「ベンチマークが高いから軸は要らない」も支持できない。その数字は汚染・暗記で信頼性を失い15、自動化が進むほど検証の軸が要る（自動化の皮肉）1617。
  • 「速いから量産でいい」は、品質・安定性・セキュリティの負債として計測可能なほど跳ね返る192021。
  • AIを使う側は”雇う側”へ回るが、良い雇い主には評価・判断の軸が要る2427。
  • 「新人は要らない」は、軸を育てる土壌を枯らすパイプラインの罠を抱える（ただしAI主因とは断定できない）282930。
  • 正直な留保： 「両端に”集中”する」という幾何学は観察ベースで、「価値はフロー全体に分散する」という対抗的な見方もある。「実装の即コモディティ化」も過大評価で、熟練者はAIで減速すらする6。本記事は「軸の要る場所が再配置された」という範囲にとどめる。

この記事は3部作の姉妹編です。

関連記事

このテーマに関連する他の記事もご覧ください：

参考資料

本文中の引用番号に対応する参考資料を番号順に記載しています。

  1. From Pilots to Payoff: Generative AI in Software Development - Bain & Company (2025). コーディング・テストは全工程の25〜35%で、高速化はボトルネックを後工程（レビュー・統合・リリース）へ押し上げる。【信頼性: 中〜高（コンサル調査）】 ↩︎ ↩︎2 ↩︎3

  2. Stack Overflow Developer Survey 2025: AI - Stack Overflow (2025). 約49,000人。AI正確性への信頼は29%に低下、66%が「ほぼ正しいが微妙に違う」出力の修正に時間を費やす。【信頼性: 中〜高】 ↩︎ ↩︎2 ↩︎3 ↩︎4

  3. Our entire company ships code now: 40 PRs from non-engineers in 60 days - epilot 開発ブログ (2026). 非エンジニア11人が60日で40PRをマージ。運用は「非エンジニア／エージェントが作り、エンジニアがレビューしてマージ」。自社事例（ベンダー寄りの成功事例である点に留保）。【信頼性: 中】 ↩︎ ↩︎2

  4. Vibe engineering - Simon Willison (2025). AIで誰でもコードを出せる結果、差別化要因がコード生成から計画・仕様・テスト・レビュー・本番化・説明責任へ移ったと整理。著名エンジニアの一次論考（観察ベース）。【信頼性: 中（論説）】 ↩︎ ↩︎2

  5. Spec-driven development with AI: Get started with a new open-source toolkit - GitHub Blog (2025). 曖昧な指示はAIが勝手な仮定で埋め成果が崩れる。仕様＝意思決定を先に名指しする装置という整理。【信頼性: 中（ベンダー開発ブログ）】 ↩︎

  6. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity - METR (2025). 熟練OSS開発者16名・246課題のRCT。AI使用時に完了が19%遅延、当人は速くなったと誤認。小規模・特定文脈につき一般化に留意。【信頼性: 中〜高】 ↩︎ ↩︎2 ↩︎3

  7. When AI turns software development inside out - VentureBeat (2026). 開発の幾何学が「ダイヤモンド型」から「バーベル型」へ反転し、人間は要件定義と成果検証の両端で深く関与するという観察。論説（実証ではない）。【信頼性: 中（論説）】 ↩︎

  8. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot - Peng, Kalliamvakou, Cihon, Demirer, arXiv:2302.06590 (2023). 処置群が約56%高速、経験の浅い開発者ほど恩恵。単一の孤立タスク・コード品質未測定・ヘテロ効果は示唆レベル。【信頼性: 中】 ↩︎

  9. The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers - Cui et al., Management Science (2025). 4,867名の3社RCT。生産性向上はジュニア・在籍年数の短い層で有意。【信頼性: 高】 ↩︎

  10. Navigating the Jagged Technological Frontier - Dell’Acqua et al., Organization Science (2026). BCG758名実験。フロンティア内は下位43%・上位17%改善、フロンティア外はAI群が19%劣化。【信頼性: 高】 ↩︎ ↩︎2 ↩︎3

  11. The Uneven Impact of Generative AI on Entrepreneurial Performance - Otis et al., Harvard Business School Working Paper 24-042. ケニアの起業家640名RCT。高パフォーマーは改善、低パフォーマーは悪化し格差が拡大。【信頼性: 中〜高】 ↩︎ ↩︎2

  12. DORA 2025: State of AI-assisted Software Development - Google Cloud DORA (2025). 「AIはチームを直すのではなく増幅する」。AI採用は安定性とは負の関係。【信頼性: 中】 ↩︎ ↩︎2

  13. The hottest new programming language is English - Andrej Karpathy (2023). 「自然言語が新しいプログラミング言語」という見解。エビデンスではなく、軸不要論を象徴する個人の見解として参照。【信頼性: 要検証（個人の見解）】 ↩︎

  14. SWE-bench Verified - 実リポジトリのissue解決を測る人手検証済みコーディングベンチマーク（公式）。スコアの解釈は15の留保を参照。【信頼性: 中〜高（公式・測定妥当性に留保）】 ↩︎

  15. ベンチマーク汚染・暗記の指摘群: Why we no longer evaluate on SWE-bench Verified - OpenAI ／ SWE-Bench+（解の漏洩） ／ 記憶か推論かの分析. 解答漏洩・弱いテスト・学習データ汚染により高スコアが水増しされていることを指摘。【信頼性: 中〜高】 ↩︎ ↩︎2 ↩︎3

  16. Ironies of Automation - Lisanne Bainbridge, Automatica 19(6), 775–779 (1983). DOI: 10.1016/0005-1098(83)90046-8. 自動化が進むほど人間の監視・例外対応・判断が重要かつ困難になるという古典。【信頼性: 高】 ↩︎ ↩︎2

  17. Do Users Write More Insecure Code with AI Assistants? - Perry, Srivastava, Kumar, Boneh, ACM CCS (2023). AIアシスタント利用群は有意に脆弱性の多いコードを書き、安全だと誤認しやすい。【信頼性: 高】 ↩︎ ↩︎2

  18. We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs - Spracklen et al., USENIX Security Symposium (2025). 商用モデルで5.2%、オープンソースモデルで21.7%の推奨パッケージが実在せず（約20.5万件のハルシネーション）、slopsquatting攻撃の温床になりうる。【信頼性: 高】 ↩︎

  19. 2024 Accelerate State of DevOps Report - Google DORA (2024). AI採用が25%増えるごとに、デリバリの安定性が推定約7.2%低下。【信頼性: 中〜高】 ↩︎ ↩︎2

  20. AI Copilot Code Quality: 2025 Research - GitClear (2025). 2.1億行超を分析。重複コードが2021年8.3%→2024年12.3%、2024年は重複追加がリファクタリングを上回る。ベンダー分析・相関で因果は未確定。【信頼性: 中】 ↩︎ ↩︎2

  21. 4x Velocity, 10x Vulnerabilities: AI Coding Assistants Are Shipping More Risks - Apiiro (2025). Fortune 50規模・数千リポジトリ。AI生成コード増で権限昇格経路+322%、設計欠陥+153%。ベンダー分析。【信頼性: 中】 ↩︎ ↩︎2

  22. No Silver Bullet—Essence and Accident in Software Engineering - Frederick P. Brooks, IEEE Computer (1986). ソフトウェアの本質的複雑性は道具では消せない、という古典的論考。【信頼性: 高（古典）】 ↩︎

  23. Kids who offload critical thinking to AI may learn less - Hechinger Report (2024). BJET 等の研究を要約。ChatGPTを多用するほど、後のAIなし課題で成績が低下。【信頼性: 中】 ↩︎

  24. 2025 Work Trend Index: The Year the Frontier Firm Is Born - Microsoft WorkLab (2025). 「全従業員がagent boss（エージェントの上司）になる」と提示。自社AI製品を持つベンダー発・予測値である点に留保。【信頼性: 中（ベンダー調査・予測）】 ↩︎ ↩︎2

  25. To Thrive in the AI Era, Companies Need Agent Managers - Srinivasan & Wei, Harvard Business Review (2026). AIエージェントを監督する「agent manager」役割の登場を論じる。単一事例ベースの論説。【信頼性: 中（論説）】 ↩︎

  26. Harvard Business Review survey: only 6% of companies trust AI agents - Fortune報道 / HBR Analytic Services (2025). コア業務をAIエージェントに完全に委ねている企業は6%にとどまる。【信頼性: 中】 ↩︎

  27. Balanced Skills and Entrepreneurship - Edward P. Lazear, American Economic Review (2004) ／ Journal of Labor Economics (2005). 「何でも屋」理論。起業家＝ジェネラリスト（最も弱いスキルに事業が制約される）、雇われる側＝スペシャリストというモデル。【信頼性: 高（理論）】 ↩︎ ↩︎2

  28. Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence - Brynjolfsson, Chandar, Chen, Stanford Digital Economy Lab (2025). ADP給与データ。AI高曝露職の22-25歳で相対雇用が約16%減、ソフトウェア開発の若手はピークから約2割減。著者も他要因の可能性を明記。【信頼性: 中〜高】 ↩︎ ↩︎2

  29. Generative AI as Seniority-Biased Technological Change - Hosseini & Lichtinger, SSRN 5425555 (2025). 6,200万人・285,000社のデータ。GenAI採用企業でジュニア採用が減りシニアは増加。解雇でなく採用減。査読前。【信頼性: 中（査読前・大規模差分分析）】 ↩︎ ↩︎2

  30. Tracking the Impact of AI on the Labor Market - Yale Budget Lab (2026). AI曝露と雇用の明確な相関は確認されず「大規模な労働市場破壊の証拠はない（現時点では投機的）」。テック採用減はZIRP終焉・利上げと重なる交絡に注意。【信頼性: 中〜高】 ↩︎ ↩︎2

  31. The Looming Junior Developer Pipeline Crisis - InfoQ要約 / Russinovich & Hanselman, Communications of the ACM (2026). 初期の生産性低下を受け入れてでも若手を雇い育て続けるよう提言（査読オピニオン）。【信頼性: 中】 ↩︎

キャリア・学習
AI キャリア AIコーディング ジェネラリスト 専門性 AI時代
This post is licensed under CC BY 4.0 by the author.