コードが書けることの「希少性」が静かに溶けている

Andrej Karpathy（OpenAI共同創業者）が2025年2月にX上で「vibe coding」という概念を投稿した。「プログラミングの文法を覚える必要はない。やりたいことをAIに自然言語で伝えるだけで動くものが作れる」という主張で、Hacker Newsで1,092ポイント・601コメントを記録した。その後、国内エンジニアのAkira-IsegawaがQiitaでバイブコーディング作品を公開し、1,946件のLGTMを獲得している。「コードを書いたことのない人が書いたコード」が技術コミュニティで評価される、という事態がすでに起きている。

AIコーディングツール市場は2026年に約250億ドル（CAGR 28.4%）に達した。GitHub Copilot、Cursor、Claude Codeなどが主要企業内に浸透しており、「コードが書けること」の希少性は以前より確実に低下している。

ところが、米国労働省の2025年データではソフトウェアエンジニアの求人は前年比＋7.1%増加している。これをどう読むか。

構造として何が起きているか

矛盾に見えるが、実はシンプルな構造がある。コードの生産コストが下がると、これまで採算が合わなかった「小さなソフトウェア」の需要が爆発的に生まれる。Stripe社が2024年に1,370名のエンジニアチームでわずか4日間でBillingo APIへのマイグレーションを完了した事例は、その象徴だ。AIなしでは数週間かかる作業が、大幅に短縮された。コスト低下が、むしろ「より多くのソフトウェア」への需要を生んでいる。

ここで価値の地図が書き換わっている。価値が下がる領域は、CRUD実装の定型作業、既知のアルゴリズムの実装、ボイラープレートの記述といった「AIが得意なこと」だ。一方で価値が維持・上昇する領域は、アーキテクチャの判断、要件定義と問題の言語化、パフォーマンスやセキュリティのデバッグ、そして特定ドメインのコンテキスト理解（業界知識とコードの融合）だ。

一言でまとめるなら、「コードを書く技術」から「問題を定義する技術」への移行が起きている。

ここからは見方の話：5資産フレームワークをどう読むか

元記事が提示する「ポスト・コード時代の5資産」は、個人の視点・命名権・信頼ネットワーク・コンテキスト・オリジナル経験の5つだ。整理の仕方として興味深いのは、これらが全て「AIが短期間では複製できないもの」に絞られている点だ。

その中で特に刺さるのが「命名権（Naming Power）」という概念だ。「バイブコーディング」「RAG」「コンテキストウィンドウ」——新しい概念を最初に言語化した人が参照先になる。技術ブログやOSS貢献、カンファレンス発表での命名は、コードそのものより長期的な影響を持つ、という指摘だ。

これは実感として納得できる。技術コミュニティで「誰が最初に言葉にしたか」は、その後の議論の文脈をかなり規定する。コードを書く速度より、言語化のタイミングと精度の方が影響力を持つ場面が、確かに増えている。

ただ、留保も入れておきたい。この5資産フレームワークは、現状の変化を説明する概念整理としてはよくできているが、「どう計測するか」「チームや組織の文脈でどう機能するか」はまだ曖昧だ。キャリア設計の指針として使う場合、抽象的な資産概念を「今週やること」に落とさないと机上の話で終わる。

サイバーエージェントが2028年全社開発自動化を目標にしながら「なぜこのプロダクトをこう作るか」の文脈をエンジニアが保持し続ける設計をしていること、ヤマハ発動機が熟練技術者の判断プロセスをデジタル化し「Concept 451」として体系化していることは、5資産を組織レベルで実装しようとしている具体例として参照できる。

実務に落とすと、今週何をするか

元記事が提示する行動指針は3つで、これは具体的でいい。

ひとつ目は、設計判断の理由をコードに記録すること。sorted(records, key=lambda x: x['timestamp'], reverse=True)[:100]というコードに何も書かないのと、「UXテストで100件超えると認知負荷が上がる（#PR-442）。DBクエリ最適化より先にフロント件数制限を選んだのは実装コスト優先のため」と書くのでは、将来のチームへの価値が全然違う。AIはコードを生成できるが、「この判断の背景」は人間が書かなければ残らない。

ふたつ目は、障害対応・設計失敗のポストモーテムを書くこと。「昨日本番で起きたこと」はAIのデータベースにない。一次情報としての価値がある。

みっつ目は、特定ドメインの専門性とコードを結びつけること。「医療×AI」「製造×AI」「金融×AI」のように、業界固有の制約・法規制・暗黙知を理解したエンジニアは、AIが生成するコードの品質保証者として機能できる。汎用エンジニアよりドメイン特化エンジニアの需要が相対的に上がる、というのは説得力がある。

次に問題になるのはどこか

「問題を定義する力」が価値になる、という方向性は正しいと思う。ただ、その力をどう評価するか、という問題が次に来る。

コードは書いたら見える。PRのレビュー、テストの通過率、デプロイ頻度で測れる。しかし「問題定義の質」や「アーキテクチャ判断の正しさ」は、短期では見えにくい。評価軸が変わらないまま、求められる仕事だけが変わる、という状況が現場で起きる可能性がある。

また、MUFGが全行員35,000名へのChatGPT Enterprise展開と内製開発「AIDE」で定型業務を自動化しているような大企業と、まだAIコーディングツールの導入すらできていない中小企業の間で、エンジニア価値の格差が急速に広がるかもしれない。バイブコーディングが「全員に恩恵をもたらす」とは限らない。

同種のニュースを次に見るときは、「コスト低下が需要を生んでいるのか、それとも雇用を置き換えているのか」という点と、「価値が上がると言われているスキルが、実際の採用市場や給与水準に反映されているか」という点を見るといい。言説と市場の動きにズレがあれば、まだ過渡期の議論だということだ。

コードを書く速度の競争は、AIに渡す方向で終わった。次の競争は、「何を作るべきか」を先に言語化できた人間が取るフェーズに入っている。

参考元: ポスト・コード時代の設計思想 — バイブコーディング普及後のエンジニア価値の再定義（Zenn / AI Japan Index）