LLMの台頭でエンジニアの価値が消える？将来が不安なあなたへ贈る生存戦略

最近、LLM（大規模言語モデル）の進化があまりにも速すぎて、自分のソフトウェアエンジニアとしてのキャリアが食いつぶされているような感覚に陥っています。同じような不安を抱えている人はいませんか？この状況にどう向き合い、今後どう生き残っていくべきか、正直なところ途方に暮れています。

木工の趣味を仕事にすることを検討すべきかな…

業界の未来をどう感じていようと、職人芸としてのソフトウェア開発以上に、職人芸としての木工で成功を収めるのは難しいと思わないか？

会社で再びいくつかの職種で採用を始めたが、ドメイン知識の深さはもう強力な差別化要因ではなくなっている。以前は「ソフトウェアエンジニア - 特定領域」のようにリストしていたが、今は単に「ソフトウェアエンジニア」となり、チーム配属はオファー承諾後に決まる。
もちろん、ドメインに深く関わるチャンスがなかった優秀なエンジニアにとっては、就職のチャンスが広がって良いことだが、一生かけてドメイン知識を蓄積してきた他の優秀なエンジニアが同じ土俵で競わされると思うと悲しい。

著者の未来予測が正しいのなら、有能なソフトウェアエンジニアは安泰だよ。ドメイン知識なんて、優れたエンジニアリング原則を適用する方法を学ぶよりずっと速く習得できるんだから。

主な競争優位性がドメイン知識にしかないエンジニアは、おそらくエンジニアリング自体はそれほど優秀ではないんだろう。彼らは、自分がこれまで知識を蓄積してきた業界の他の分野で職を見つけることはできるかもしれないけどね。

は？ LLMを一日中使ってるけど、金融プロダクトの舵取りを任されるなんて絶対にあり得ない。最初の柱（著者の言うドメイン知識の重要性）はまだ揺るぎなく存在している。著者は自分たちが与える影響を自覚していないのかもしれないが、差し戻されたプルリクエストという証拠がある以上、自分の深い知識の外に出たとき、エージェントの出鱈目を指摘できなくなることは身に染みている。我々の最も有能なエージェントでさえ、著者が語るような分散システムにアクセスさせても、定期的に間違えるし、近視眼的だし、日常的に完全に馬鹿げたことをする。それを軌道修正できるのは、チームのエンジニアたちの専門知識だけだよ。

私のキャリアパスは著者のものと驚くほど似ている。奇妙なことに、彼が「最初に崩れ去る柱」だと言っているものが、私には現時点で最も無傷に見える。

LLMは、現地の税規制、会計プロセスの詳細、元帳実装の仕様といった、我々のビジネスの特定要件には日常的に失敗する。リファクタリングや、言語間の翻訳、既存コードのバグ追跡などは得意だけど、ドメインを反復・拡張していく際には常に微妙な誤りがたくさん発生するんだ。

これは、私が働いてきた企業が、まさに「堀を築く」という理由で複雑なドメインに取り組んでいたからかもしれない。クローンを作るための参考書など存在せず、ノウハウが社内に留まっているからこそ、ビジネスが成立しているのだ。

それに、AIを使って設計ドキュメントを高速化することを推奨するフィンテック企業なんて、金を扱うビジネスとしては無頓着すぎるだろう。特に大量の少額取引を扱う場合、誤った割り当てが何百万件も発生するなんてことがあまりに簡単すぎる。こうしたバグは、修正するだけでも一苦労だし、さらにイミュータブルなDB上の誤ったデータを全て修正し、お役所仕事や顧客対応をこなさなければならない。おまけにその修正が、新しい機能やオブザーバビリティが考慮すべき「罠」になることは必至だ（「インシデントXのせいで2月2日のデータに異常があることを覚えておいて」なんてね）。

Claude CodeでOpus 4.7を使っているが、生成されるコードが間違っているわけではなく、単に書きすぎる傾向があるんだ。特定の機能をどうコードに適合させるのがベストかを考えてから実装する価値は依然としてあると思う。というのも、Claudeはスタックの特定のレイヤー（例えばプレゼンテーション層）を選んで、そこに無理やり詰め込むことが多いからだ。数週間後にそのデータが他の場所で必要になっても、Claudeはコードを再利用できず（サービス層など）、そのまま「移植」してしまう。人間が注意を払っていないと、コードの量は倍になり、ロジックの重複が生まれることになる。ClaudeのようなAIツールがこの点をすぐに改善できるとは思えない。

私の職場では、コスト削減のためにOpus 4.7の使用を控える圧力がすでにかかっていて、「単純なバグ修正」には小さなモデルを使うべきだという声もある。たまには上手くいくかもしれないが、「単純なバグ修正」だと最初から確実に言い切れることがどれだけあるだろうか？ コストが上がるにつれて、こうしたツールに「全てのコード」を書かせることへの関心は低下していくだろう。人々がより安価で性能の低いモデルに移行するにつれ、コードレビューをスキップしたいという圧力も自然と消えていくはずだ。

どうなるかは今後のお楽しみだが、投稿者が恐れるほど劇的な変化にはならないかもしれない。

スティーブ・ジョブズの有名な言葉「アイデアに価値はない（Ideas are cheap）」をいつも思い出す。もし実行（Execution）こそが全てで、最先端のLLMがその実行を解決してくれるなら、今はアイデアが豊かさを生む入り口になるかもしれない。でも、豊かさだけでは「粘り強さ（stickiness）」を保証できない。

見落とされがちなのは、人間が持つ「意欲」や、あえて良い言葉を使わせてもらえば「執着心」だ。何が言いたいかというと、多くの人は単にそこまで深く考えていないか、あるいは物事を構築し、維持し、自分自身で所有することを望んでいないということだ。確かにV1を出す速度は上がるだろうけど、そのまま泥臭い開発を続けられるだろうか？

AI音楽ツールのSunoが良い例だと思う。試したことがあればわかるだろうけど、今は本当に良いものを作る。そこで何が起きているか？ 多くの人は自分だけの小さな世界で少し遊んで飽きたら離れていく。そこから仕事のように取り組むのは、ほんの一握りの多作なクリエイターだけだ。

「委任」と「実行」の規模や経済性は変わったかもしれないが、考慮すべき他の要素はまだたくさんあると思う。

どうすればいいかわからない。

波に乗るんだよ。ウェブサイトやウェブアプリが波だったときも、君はそうやって乗ってきたんだろう？ 私はインターネットが普及する前からソフトウェア業界にいるが、何度も乗り換えてきた。新しいことを学ぶのに遅すぎるなんてことはない。新しい波は新しい仕事や働き手を生む。その一部になるんだ。波を乗りこなし、ツールをマスターする。今までと全く同じゲームだよ。

AIが特定のタスクをうまくこなせるようになっただけで、著者が自分の経験をこれほど簡単に過小評価するのが不思議でならない。専門のソフトウェアエンジニアが指示を出す場合と、非技術者が指示を出す場合では、AIのできることには大きな溝がある。確かにモデルやツールは進化するだろうが、それでも「ソフトウェアがどう動くか」という直感を持ち、AIが生成したハルシネーション（幻覚）、誤った前提、あるいは単にめちゃくちゃなコードを解読し、修正できる人間の舵取りは依然として必要だ。人間がやりたいことと、それを言葉で表現できることの間にはギャップがあり、そこから生まれるエラーを直せるのは人間だからだ。

今後どうなるかはわからないが、今のところ心配はしていない。ソフトウェアの総量は増え続けており、AIはその傾向を加速させているだけだからだ。これには、これまでもソフトウェアエンジニアのスキルセットの基盤となってきた、メンタルモデルの構築やファースト・プリンシプル思考、執拗なまでの好奇心が今後も求められ続けるはずだ。

前にも投稿したけど、また書く価値があると思う。

私はLLMを非常に熱心（良い意味で）に使っている企業のDevOpsで働いている。

フェーズは基本的にこんな感じだった：

• LLMに「たくさん」やらせてみる
• さらにやらせてみる
• 複数のエージェントを動かす
• 単一エージェントに戻し、エージェントにツールを作らせる
• 決定的（Deterministic）で、人間（編集注：とLLM）の両方が使えるツールにする

理由は以下の通り：

1. 決定的なツール（デプロイとテストの両方用）は、繰り返し可能でバイナリな結果を得られる。
2. 障害発生時、人間が実行できるツールがあれば常にフォールバックできる。
3. 速い。素早いスクリプトなら30秒未満で終わるが、AIの「もっともらしい出鱈目（confabulating）」を待つと2〜3分かかる。

結局のところ、この記事（https://spawn-queue.acm.org/doi/10.1145/3194653.3197520 ）に戻るんだ。「タスクリストを作り、タスクごとにスクリプトを書き、それらを組み合わせて関数にし、システムにする」という話だ。

-- 元の投稿の終わり --

付け加えるなら：

LLMに好きなようにさせれば、喜んでコードを書いてくれる。それが正常に動くか確認するためのテストを追加することはできる（昔、人間が書いたコードでやっていたのと同じようにね）。もちろんコードを読むこともできる。

コードを読んでみると、時々完全にイカれたことをしながらも、正常に動くコードを生成していることに気づくはずだ（人間が書いたコードでも見たことはあるけど、それはまた別の話）。

要するに、構築中のシステムが理にかなっているかを確認するのは、依然として人間の仕事だということ。

もっと簡潔に言えば：

コーディングは死んだかもしれないが、ソフトウェアエンジニアリングはバリバリ現役だ。

「AIはXを80〜100%の精度でこなせない、だから私たちの職業は安泰だ」といったコメントをよく目にする。

あまり悲観的になりたくはないが、モデルは急速に進化している。約3年前に、現在のモデルの状態を予想して「ワンプロンプトで30分以内に完全なMVPアプリを作成する」なんて言ったら、SFだと思われただろう。

ハルシネーションの削減、コンプライアンスの確保、クリーンなコードベースの維持といった、モデルが直面している現在のハードルは、もう解決まで遠くないと思う。特定の情報の取得は、すでに様々なMCPサーバーやRAGによって部分的に達成されている。

もちろん、ソフトウェアエンジニアの未来については少し心配している。こうした不具合が解消されたら、彼らの仕事は業界のどこにフィットするんだろう？ AIモデルへのタスクの委任？ 残念ながら、それには長年の専門知識を必要としない。これは諸刃の剣だ。AIのアウトプットのレビュー？ 理解できない行があれば、AIに説明させればいい。

人間がデジタルコンピュータに取って代わられたように、今後も大規模なレイオフの波が来るだろう。一部の人にとって、複雑な数学計算を暗算で行うのは楽しい挑戦かもしれないが、最終的にはコンピュータで計算するより圧倒的に遅く、ミスも起きやすい。同じように、手作業でのコーディングは楽しい「挑戦」として見なされ、AIは「現代版の計算機」として見なされるようになると思う。