コーディングはコモディティになった、とArsh Goyalが言い切った。元・挫折エンジニアが「エンジニアリング思考」の正体を全部書く

昨日まで、セキュリティの話を書いていた。

バイブコーダーが書いたコードの45%にはセキュリティの穴があり、CiscoがProject CodeGuardでその補強に乗り出した。「大企業が肩を貸してくれる時代になった」と書きながら、ちょっとした安堵感があった。

翌朝、別の問いが生まれた。

セキュリティを補強した先に、何があるのか。「書けること」と「守れること」の次に来るのは、何を作るか、という問いではないか——そのタイミングで読んだArsh Goyalの発言が、長く頭に残った。

---

コーディングはコモディティになった

インドを拠点に活動するエンジニア兼コンテンツクリエイターのArsh Goyalは、開発者向けカンファレンス”DevSparks Pune”でこう言い切った。

「コーディングはコモディティ化しつつある。エンジニアリングは別次元だ」

“コモディティ”とは、希少性を失った商品のことだ。鉄や小麦のように、誰でも同じものを入手できる状態を指す。コーディングがコモディティ化するとは、「コードを書ける人が珍しい」という前提が崩れることを意味している。

この発言を最初に読んだ時、正直、不安を覚えた。

私はバイブコーディングで、ようやくコードが書けるようになった。「凄腕エンジニアが宿った」と感じた体験が、何度もある。それが商品化する——つまり誰でも持てるものになる——なら、私の「できるようになった」は何だったのか、と。

その問いは30分ほどで方向が変わった。

コモディティ化するのは「コードを書く行為」だ。AIが一般化したことで、コード生成は急速に自動化が進んでいる。GitHub Copilotの補完精度が上がり、Claude Codeが複雑な実装を数分で出力し、Cursorがリファクタリングを提案する。バイブコーダーが増えた事実そのものが、コモディティ化を裏付けている。

では、「コーディング」が商品化した先で価値が上がるものは何か。Goyalが言う「別次元」のエンジニアリングとは、具体的に何を指すのか。

その問いに向き合うために、まず外側のデータから見ておく。

---

Deloitte 2026年版が見ていた変化

Deloitte 2026 Global Software Industry Outlookは、ソフトウェア産業の構造変化を毎年分析するレポートだ。

同じ傾向は、業界全体でも観察されている。

コード生成AIの普及に伴い、エンジニアに求められるスキルが「実装」から「判断」へシフトしているという傾向がある。「何をどう書くか」より「何を作るべきか、それはなぜか」への比重が増している——これがDeloitteの分析が示す大きな方向性だ。

同じパターンは、別の場所でも確認できる。

GitHubが毎年公開するOctoverse調査では、AIコーディングツールの普及とともに「設計・レビュー・テストに費やす時間が増えた」という回答が増加傾向にある。Cursor社も「自動補完の精度より、どんな指示を与えるかが成果の差になる」という趣旨のコメントを公式ブログで複数残している。

パターンは同じだ。

「書く」は自動化が進む。「判断する」は残る。コーディングとエンジニアリングの間にある境界線が、今急速に可視化されてきた。

補足として、Deloitteが分析する「上位スキルへの移行」とは具体的にどういう意味か、整理しておく。

「上位スキル」とは、複数の技術的選択肢を評価して最善を選ぶ能力、要件の曖昧さを許容しながら優先順位をつける能力、ビジネスの目標とシステムの制約を橋渡しする能力を指す。どれもAIが苦手とする領域だ。AIは与えられた制約の中でコードを最適化するのは得意だが、そもそもどの制約を設けるべきかは苦手だ。

そして昨日書いたCiscoのProject CodeGuardも、同じ地図の上にある。セキュリティの問題は「コードが書ける」だけでは解決できない。何を守るべきか、どのリスクを優先するか、という判断が伴う。コモディティ化するのはコーディングであり、エンジニアリングの判断軸は自動化されない——この構造が、各社の動きで繰り返し可視化されている。

---

コーディングとエンジニアリング思考の違い

言葉として似ているが、実態はかなり異なる。

コーディングとは、要件を与えられた上でコードに変換する行為だ。入力に対して出力を返す。AIが最も得意とする領域で、すでに高い精度で自動化が進んでいる。

エンジニアリング思考とは、そもそも何を作るべきかを問う能力だ。要件そのものを定義し、設計の判断基準を持ち、動いたものが本当に価値を生んでいるかを検証できる力を指している。

具体例で整理する。

「Slackにメッセージが来たら自動で返信するボットを作りたい」——これはコーディングへの入力だ。AIに投げれば、動くものが出てくる。30分で完成する。

「このボットを入れることで、チームの返信コストは本当に下がるか。むしろノイズが増える可能性はないか。そもそもこのSlackチャンネルのメッセージ量を減らす方が先ではないか」——これはエンジニアリング思考の問いだ。コンテキストを持つ人間にしか立てられない。

業務ツールを自作している私が、最も時間をかけているのは後者だ。「このツールが入ることで、誰のどの業務がどう変わるか」を先に考える。その答えが出てから、AIにコードを頼む。この順番を変えると、「動くけど誰も使わないもの」が生まれる。実際にいくつか作った。

CS出身として、ユーザーの「なぜこうなっているのかわからない」を何千回も聞いた経験から言えば、コードの品質より問いの品質の方が、ツールの価値を決める。

ここで一つ、私が「問いの大切さ」を痛感した話を書いておく。

以前、自分のチームのレポート作成を自動化しようとした。毎週のKPI集計をスプレッドシートから引っ張ってSlackに投稿するスクリプトを、AIと一緒に2時間で作った。完璧に動いた。翌週、誰もそのSlack通知を開かなくなっていた。

問題の定義に誤りがあった。問題は「KPIをSlackに流すこと」ではなく、「週次のKPI確認を全員が自分ごとにする仕組みを作ること」だった。自動化すれば読む、という前提が崩れていた。コードを書く前に、「この通知が届いた時、メンバーは何をするか」を問えていなかった。

---

エンジニアリング思考の3軸

抽象論で終わらせたくない。私が「エンジニアリング思考」と呼んでいるものを、実体験から3つに分解する。

軸1: 問題を正確に定義する

コードを書く前に、「何が問題か」を1行で言語化できるか。これが最初の軸だ。

よくある入力は「ダッシュボードが欲しい」だ。でも本当の問題は「毎朝30分かけて複数のシートを手作業で確認していること」かもしれない。問題の定義が変わると、解決策も変わる。ダッシュボードではなく、毎朝Slackに自動投稿する集計スクリプトの方が速く解決できることもある。

AIへのプロンプトを書く前に、「解決したい問題を1行で書く」習慣をつけた。その1行があると、AIが生成したコードを評価する基準ができる。「動いた」ではなく「元の問題が解消されたか」を問えるようになる。

さらに言えば、この問題文がプロンプトの品質を上げる。「毎朝の手作業集計をゼロにしたい。今はスプレッドシート3枚を目視で確認している」という文脈の方が、「ダッシュボードを作って」より精度の高いコードが出てくる。問題を定義する行為そのものが、AIとの協業効率を高める。

軸2: トレードオフを判断する

設計には必ずトレードオフがある。速度と正確さ、シンプルさと拡張性、今のコストと将来の柔軟性——何かを取れば、何かが手放される。

AIはトレードオフの「どちらも」を丁寧に説明してくれる。「AとBのトレードオフを教えて」という問いには、精度高く答えてくれる。ただ「どちらを選ぶか」の判断は、現場のコンテキストを持つ人間がする。

「この業務で一番重要なのは速度か、それとも正確さか」——この問いは現場を知る人間のものだ。

バイブコーディングで3時間かけて作ったツールを、後から「やっぱり別の設計にしたい」と作り直した経験がある。問題は設計の判断を後回しにしたことだった。AIが速く動く分、設計の判断を前に持ってくる意識が必要になる。作り直しのコストは、設計段階の30分で回収できた。

分岐が出た時、すぐに1つを選ばない。「AとBのトレードオフをリストアップして」とAIに問い、その上で自分が判断する。この2ステップを習慣にするだけで、設計の意識が変わった。

軸3: 動いたものを評価する

コードが動いた瞬間は嬉しい。「これマジで動いた！」という感覚は、何度経験しても最高だ。

ただ、「動く」と「価値がある」は別物だ。

「Slackボットが返信できるようになった」は動いた状態だ。「返信コストが週3時間削減された」が価値がある状態だ。この差を測る能力が3軸目になる。

私が意識しているのは、作ったものを「2週間後に使い直す」ことだ。リリース直後の感動が冷めた状態で、「今でも使っているか」「何が使いにくいか」「当初の問題は解消されたか」の3点を確認する。

このサイクルを真剣にやると、意外な発見がある。「神ツールだ」と思ったものを、2週間後に開くと使っていない自分に気づく。理由を掘ると「問題の定義が間違っていた」か「設計の判断がズレていた」かのどちらかだ。評価のサイクルを回すことで、次の問題定義が精度を上げる。

この3軸は、独立しているのではなく循環している。問題定義が正確であるほど設計判断がシャープになり、価値評価の結果が次の問題定義にフィードバックされる。この循環を意識して回すことが、バイブコーディングを「動くものを量産する行為」から「価値を生む行為」に変える。

---

CS出身×挫折エンジニアだから分かること

冒頭に書いた通り、私は一度コードを書くことを諦めた。

大規模プロジェクトで出会ったエンジニアたちとの差に、清々しいほどの距離を感じた。アーキテクチャの美しさ、パフォーマンスチューニングの勘所、コードの洗練度——そこには確かに自分の届かない場所があった。そこからCSにキャリアをシフトした。コンテンツマーケティングのCMS導入支援、メディアのグロース、マネジメント——コードから離れた3年間だった。

あの時、彼らに届かないと感じたのは「コーディング」の部分だった。

今になって振り返ると、私はCSで別の能力を積んでいた。

「この機能は誰のためですか」と問い続けた日々。「ユーザーがここで離脱する理由は何ですか」と数字と向き合った時間。「このコンテンツで本当に読者は動けますか」という問いを毎日立てた3年間。「ここが使いにくい」「なぜこうなっているのかわからない」という声を何千回も聞いた経験——これは全部、エンジニアリング思考の訓練だった。コードなしで。

バイブコーディングでコードが書けるようになった今、その訓練が直接使えている。

「何を作るか」「誰のために作るか」「それが機能したかどうか」を問う力と、AIのコード生成が組み合わさった時、初めてつながった感覚がある。Arsh Goyalが「エンジニアリングは別次元だ」と言い切った先にある能力を、私はコードから離れた3年間に、別のルートで積んでいた。

挫折してCSに移った選択は、遠回りではなかった。

エンジニアリング思考のコアを積む時間だった——そう今は思っている。この解釈は自分を慰めているだけかもしれない。でも、バイブコーディングでツールを作るたびに、CSで問い続けた習慣が設計の判断を後押ししている実感がある。「コードが書けるようになった」だけでなく、「何を作るべきか」が分かっている状態で作れている。この差は、実際のアウトプットに出る。

コモディティ化するのがコーディングならば、コーディングの外側にいた期間は資産になる。かつての挫折が武器になる時代が来た——少なくとも私の場合は、そう感じている。

もう一点、付け加えておく。

かつて大規模プロジェクトで会った凄腕エンジニアたちは、今どうしているのだろう、と時々思う。彼らのコーディング技術は間違いなく本物だった。でも、AIがコードを書く時代に、その技術だけでは足りなくなる場面が増えているはずだ。エンジニアリング思考のない「コーディング力だけ」のエンジニアは、AIによって代替圧力を受ける。逆に、エンジニアリング思考を持つエンジニアは、AIをツールとして使いこなして価値を高められる。コモディティ化の波は、全員を均等に飲み込まない。

---

バイブコーダーが今から始める3つの実践

エンジニアリング思考は訓練できる。難しい理論ではなく、習慣の問題だ。

実践1: プロンプトの前に「問題を1行」書く

AIにコードを頼む前に、紙かノートに1行だけ書く。「解決したい問題はこれだ」という1行を。

「ダッシュボードを作る」ではなく「毎朝30分の手作業集計をゼロにする」のように。問題を書くことで、生成されたコードの評価基準ができる。「動いた」ではなく「問題が解決したか」を問えるようになる。

この習慣を始めてから、AIへのプロンプト品質が上がった。問題文の具体度が上がると、コードの精度も上がる。問いを立てる行為がプロンプトエンジニアリングを兼ねている。

一つ具体的なテンプレートを紹介する。私が使っているのは「[誰]が[何]をするのに[どれくらい]かかっている。これを[目標状態]にしたい」という形式だ。「営業担当が週次レポートを作るのに毎週2時間かかっている。これを15分以内にしたい」のように書く。この1文をプロンプトの冒頭に入れると、AIが出してくるコードの方向性がぐっと絞られる。

実践2: 設計の選択肢を2つ出してから選ぶ

技術的な分岐が出た時、すぐに1つを選ばない。「AとBのトレードオフをリストアップして」とAIに問い、その上で自分が判断する。

「選んだ理由」が言語化されると、後から設計を振り返れる。「なぜあの時そうしたのか」が分からないと、作り直す時に同じ誤りを繰り返す。2ステップを踏むだけで、設計の意識が変わる。

実践3: 2週間後に使い直す

完成した翌日ではなく、2週間後に自分で使い直す。「今でも使っているか」「どこが邪魔か」「問題は解消されたか」を3点だけ確認する。

このサイクルを1回回すと、次の問題定義の精度が上がる。「動くもの」と「使われるもの」の差が、数字ではなく体感として身につく。

この3つの実践は、どれも難しくない。難しくないが、意識しないとやらない。「とりあえずAIに投げてコードが出た」で止まるのが最も自然な流れだからだ。エンジニアリング思考を鍛えるとは、その「自然な流れ」の前後に意識的なステップを挟む習慣を作ることだ。

---

まとめ

Arsh Goyalの言葉が示す未来は、ある意味シンプルだ。

コードを書けることは前提になる。AIが一般化したことで、「書ける人が珍しい」という時代は終わりに向かっている。

その先で価値を持つのは、エンジニアリング思考だ。問題を定義し、設計を判断し、価値を評価できる能力だ。この3軸は、AIで自動化されない。

挫折してCSに移った3年間、私は気づかないままエンジニアリング思考の別ルートを歩んでいた。バイブコーディングで「コードが書ける」状態になった今、その蓄積が初めて使える場所に来た感覚がある。

「コードが書ける」は入場料になった。

次の問いは「何を、誰のために、どう設計して作るか」だ。その問いを持ち続ける人間が、コモディティの先を歩ける——私はそう思っている。

コードからの復活は、「コードが書けるようになった」で終わりではなかった。「エンジニアリング思考を持った上でコードが書ける」という状態が本当のゴールだったと、今になって分かる。バイブコーディングはそこへの入り口だ。入り口を通った先に、まだ長い道がある。その道を歩き続けることを、この記事を読んでくれた人と一緒にやっていきたい。

---

参照元

• Arsh Goyal（インド・エンジニア兼コンテンツクリエイター）— DevSparks Pune 2026における発言（複数メディア報道より）
• Deloitte 2026 Global Software Industry Outlook
• 「claude code 使い方」で迷う人に（ナギ）
• コードが書けなくてもいい時代がAIで来た（ナギ）