こんにちは。シリコンバレーのIT企業で人事マネージャーをしている者です。
「AIが仕事を奪う時代が来る」と言われ続けてきましたが、ここ1〜2年で、その現場レベルの話になり始めています。
我が社でも最近エンジニア３名をレイオフしました。その記事は下記。
他の事例について和訳記事でシリコンバレーの内情をお伝えします。
1. 「AIで何千人分の仕事が…」は、もうニュースの常連に
まず大きな流れとして、アメリカではここ数年、次のようなニュースが相次いでいます。
- 大手テック企業が「AIによる自動化」を理由に数百〜数千人規模のレイオフを発表
- カスタマーサポート、採用オペレーション、マーケティング制作などで、生成AIを使った自動化事例が急増
- ソフトウェア開発においても、GitHub Copilot や各社独自のコード生成AIの導入が進み、「同じ機能を少人数で開発可能になった」とのコメントが相次ぐ
これらのニュースは、多くの場合「コスト削減」「組織のスリム化」とセットで語られます。しかし、その裏側では、具体的にどの職種・どのレベルの人材が切られているかが、現場でひっそりと共有されています。
2. LLM導入で真っ先に影響を受けたのは「中堅どころ」のエンジニア
私が見てきたケースでは、LLM導入のインパクトを最初に受けたのは、意外にも「ジュニア」ではなく、中堅クラスのエンジニアでした。
ケースA: 内製ツール開発チームの再編
あるSaaS企業では、社内の業務フローを支える内製ツール群を担当するチームが、GitHub Copilotと社内向けLLMチャットボットを本格導入しました。
- 導入前: エンジニア7名体制、うち3名が「要件に従ってひたすらコードを書く中堅メンバー」
- 導入後: LLMによるコードドラフト生成・テストコード自動生成が安定し、「実装だけしている中堅3名」が徐々に余剰戦力扱いに
- その結果: アーキテクト1名＋プロダクト思考の強い2名を残し、中堅3名は「他部署異動」または「退職勧奨」という形で組織からフェードアウト
表向きは「再配置」「キャリアの新しい機会」と表現されますが、実態としては LLMを使いこなした少数精鋭チームに役割が集約され、中間層が削られた 形です。
ケースB: 受託開発会社のテスト・ドキュメント要員
別の受託開発会社では、LLMを使ったテストケース生成・仕様書ドラフト生成を導入しました。
- 導入前:
- テスト観点を洗い出すメンバー
- テストケースをExcelに書き起こすメンバー
- 仕様変更のたびにドキュメントを更新するメンバー
- 導入後:
- テスト観点のたたき台や仕様書ドラフトをLLMが数分で生成
- エンジニアがレビューと修正だけで済むようになり、「書く作業」に特化していたスタッフの仕事量が激減
その結果、テスト・ドキュメント専任の数名については契約更新が行われず、オフボーディングが静かに進められました。
3. 「LLMに詳しい人」まで切られるパラドックス
興味深いのは、「LLMに詳しい」こと自体が、必ずしも生存条件になっていないことです。
実際の現場では、こんなことが起きています。
- 社内で一番LLMに詳しいエンジニアが、モデルの違いや最新論文には詳しいものの、
- ビジネスサイドに価値を翻訳できない
- 他のエンジニアに使い方を教える「教育者」として機能していない
- チーム全体の生産性向上よりも、「自分だけが詳しい状態」を守ろうとする
- その結果として、「個人の知識」としては優れていても、組織全体から見たときの“必然性”が低い人材としてレイオフ対象になるケースが出ています。
逆に、
- LLMの中身についてはそこまで詳しくないが、
- ビジネス側の課題を聞き出し、
- LLMに投げるプロンプトに落とし込み、
- 出力された結果を安全性・妥当性の観点からレビューし、
- 他部署にもわかる言葉で説明できる
といった 「LLMと人間社会のインターフェース」を担える人が、強く求められています。
4. ニュースには出ない「静かなLLM解雇」のパターン
アメリカのテック企業では、日本と違いレイオフが比較的一般的ですが、それでも「AIで〇〇人クビにしました」とストレートに言う企業は多くありません。
代わりに、現場レベルでは次のようなかたちでLLM解雇が進んでいます。
-
PoC（お試し導入）フェーズ
- 小さなチームでLLMを導入し、どの職種・どのタスクに効くかを検証
- この段階では、むしろ「AI推進チーム」を増員するケースも多い
-
ワークフロー組み込みフェーズ
- 成功したユースケースを横展開し、GitHub Actions やCI/CDパイプライン、社内チャットボットなどに組み込む
- 「AIを使う前提」の業務設計に変わっていく
-
評価指標の変更フェーズ
- パフォーマンスレビューの基準が「AI込みの生産性」に変わる
- 「AIを使わないことで仕事が遅い人」「AIを使っても付加価値を出せない人」が可視化される
-
自然減＋再配置＋スポットレイオフ
- 退職補充をしない
- 役割の重複しているポジションを統合
- 特定チームだけのレイオフを断続的に実施
このプロセス全体を通じて、表向きは「戦略転換」や「優先順位の見直し」だが、実質的にはLLMで代替しやすいポジションから順に削られている、というのが現場感に近いです。
5. 日本のエンジニアが「他人事」にしてはいけない理由
「それはアメリカの話でしょ」と思った方もいるかもしれません。
しかし、次のような動きは、すでに日本の大手企業やスタートアップでも始まっています。
- 海外本社の方針で、開発プロセスにLLMやCopilotの利用が義務化される
- オフショア・ニアショア開発拠点が、LLM活用を前提に再設計される
- 採用面接で「AIを使った開発の経験」が当たり前のように聞かれる
つまり、「AIを使えるかどうか」ではなく、
- AIを使ったうえで、どれだけ差分の価値を出せるか
- LLMと人間の間の“通訳”になれるか
が問われる時代に、静かにシフトしつつあるということです。
6. では、どうすれば“LLM解雇”されずに済むのか？
この記事では、アメリカのIT企業で実際に起き始めている「LLM解雇」の実態をお話ししました。
- LLM導入の影響を最初に受けるのは、「実装だけ」をしている中堅層
- 「LLMに詳しい」だけでは生き残れず、「LLMと人・ビジネスをつなぐ力」が評価される
- レイオフは大々的なニュースではなく、自然減や局所的な再編として静かに進む
では、あなた自身が“LLM解雇”されないためには、具体的に何を鍛えればいいのか？
こちらの記事に詳しく書いてあるので、興味のある方は読んでみてください