2026-04-02

エンジニア。飯の食い方変わったよね。

#生成AI #エンジニアリング #キャリア

最近Claudeを提供しているAnthropicのCEOがこんな発言をしていました。

Anthropic社内にはコードを一行も書かないエンジニアがいる。Claudeに書かせて、それを確認・編集するだけだ。

CG (@cgtwts) の投稿Anthropic CEO の発言を引用した元ポストtwitter.com

最近、自分もコードを書くよりも、コードをレビューすることがほとんどになったので、エンジニアの価値について最近考えていることをまとめてみました。

ナヴァルが語る富を生み出す三つの要素

最近投資家にすすめられていたナヴァル・ラヴィカントの本を読みました。背表紙に「良すぎて2冊買った」という書評があり、うさんくさそうですが自分は2周読みました。
ナヴァルは、AngelListの創業者でありシリコンバレーを代表する投資家・思想家です。

シリコンバレー最重要思想家ナヴァル・ラヴィカントナヴァル・ラヴィカント / エリック・ジョーゲンソンamazon.co.jp

ナヴァルは富を生み出す要素として「特殊知識・説明責任・レバレッジ」の三つを挙げています。
特殊知識とは訓練で得るものではなく、好奇心や熱量の延長にある自分固有の知識のこと。
説明責任とは、自分の名前や評判をかけてリスクをとること。
そしてレバレッジは、プログラムコードやメディアなどといった現代のツールを使って「自分が何もしなくても」その力を増幅するものです。

生成AIが変えた、エンジニアの特殊知識

エンジニアリングの対価を富とした場合に中心的な要素は「ビジネスの機能要件をコードとして実装できること」という特殊知識だったと思います。プロダクトマネージャーやCEO、コンサルタントなどが言語化した要件を、動くソフトウェアに変換できる能力。それはたしかに希少で、それだけで高い市場価値を持っていました。
さらに他の富のレバレッジツールとして「コード」を作成できるという人材である点は間違いなくエンジニアの優位性です。

そのような状況下で非エンジニアがAIを使ってそれなりに動くコードを生成できるようになりました。「機能要件→コード変換」の部分はAIが担う割合が増え、その使い方としての希少性は下がりました。生成AIは上記の構図を変えつつあると思います。

これまでは「コードとして実装できること」自体が業務の中心だった一方で、現在は生成AIを駆使して「実用的なコードを素早くデリバリーする」というケースが増えてきたかと思います。
富の構成要素の中の特殊知識としてこれまで通りの価値提供とは大きく変わっているのでしょう。

説明責任の重要度が増していく

では生成AIによってエンジニアの仕事はなくなっていくのでしょうか?
そうでもありません。
コーディング自体にかける時間が少なくなったかわりに、生成されたコードに対する評価や修正を行う、つまり「このコードで行く」と判断することが増えてきました。
本番環境に乗せる判断、セキュリティリスクの評価、技術的負債とのトレードオフ。
AIないしは人が作成したコードに対して「これは正しい」と言えるエンジニアへの信頼が、これからの価値の中心になると思います。これがまさにナヴァルのさす「説明責任」だと思います。

自分も事業の中で、CEOが生成AIでコードを書き、自分がそれをレビューするという開発プロセスが支援先で生まれています。雇用であれフリーランス参画であれ、クライアントがエンジニアに求めるのは「コーディングしてくれる人」より「そのコードに責任をとってくれる人」に変わっていくと感じています。

なので、特殊知識が不要になったわけではありません。ナヴァルの言う特殊知識とは本来「コーディングやアーキテクチャが好きで夢中になれること」そのものです。その熱量と深い理解があるからこそ、AIが生成したコードの正しさを判断できます。特殊知識は形を変えて、説明責任を果たすための土台として機能し続けます。

説明責任の重要性とリスク許容度はトレードオフ

「エンジニアはいらなくなる」という声は定期的に流れます。
でも、それが成り立つかどうかはソフトウェアに対するリスクをどこまで許容できるかのトレードオフ次第だと思います。
例えば、自分だけが使うツール、リスクを十分に理解したユーザーのみに提供するプロダクト、失敗してもすぐやり直せる実験的な開発――こういう文脈ではソフトウェアのリスクは低く、説明責任の重要性が下がるため、AIだけで完結することも増えるでしょう。
逆に、ステークホルダーが増え、障害の影響範囲が広がり、セキュリティやコンプライアンスが問われるほど、そのリスクは高くなります。
ユーザー数の多い大手SaaS企業が複数のエンジニアで機能レビューする体制はリスクを考慮する場合にビジネス的にも理に適う意思決定かと思います。
なので、エンジニアが必要かどうかは「不要論が正しいか否か」ではなく、そのリスクを誰に検証してもらい小さくしてもらうべきかという問いに帰着すると思います。

説明責任を引き受ける立場で

ナヴァルはもともと「説明責任は富の構成要素の中で最もリスクが高いが、最もリターンが大きい」と言っていました。生成AIの登場は、その比重をエンジニアの仕事においてもはっきりと前景化させています。自分自身、支援先のソフトウェアに対してそのリスクを適切にコントロールできる立場として携われたらと思っています。

一方で、生成AIで生成されたコードの品質・リスクが多くのシステムの要求を満たすレベルで小さくなればエンジニアである人が説明責任を全うするケースが少なくなることも事実です。
おそらく1年前までは「そんな状況はおきない」と思っていたのですが、最近のスピードを見ると半信半疑になってしまいますね。