ビジネス19分で読める

IBM累計1.5万人削減——なぜRed Hatまで手放すのか

「クラウド・AI企業への転換」を掲げてきたIBMが、その象徴的存在であるはずのRed Hatにまでリストラの手を伸ばしている。CIO.comの報道によれば、IBMは2025年第4四半期に全社員27万人の「低い一桁パーセンテージ」にあたる数千人規模の削減を実施すると発表し、続く2026年4月にはRed Hatのエンジニアリング部門で300人以上のGNU/Linuxエンジニアが一斉に解雇された。2024年9月に始まった一連の人員削減は、この最新の波を含めると累計1万5,000人を超える規模に達している。

注目すべきは、削減の対象がコールセンターや管理部門といった「AIに代替されやすい」定型業務にとどまらない点だ。libvirt・QEMUといった仮想化基盤のコア開発者、OpenShiftコンテナプラットフォームのベアメタル統合を担うROSAチームのエンジニアまでもが対象になった。IT専門メディアTechrightsが報じたところでは、影響を受けたのは主に中国拠点のエンジニアリングチームで、会社側は「APACハブへの移行」を理由に挙げているという。

本稿では、CIO.com、Techrights、KORE1、CIO Diveといった複数の一次報道を基に、IBMの人員削減の全体像、Red Hat部門が削減対象になった背景、そしてIBMのAI戦略(watsonxプラットフォーム)との関係を深掘りする。さらに、日本IBM・日本のRed Hatユーザー企業への影響、そしてエンジニアが今取るべきキャリア戦略まで論じる。

IBMの人員削減タイムライン。2024年9月の第1波(8000〜1万人)から2026年4月の第4波(Red Hatエンジニア300人超)まで4つの波を時系列で示し、累計1万5000人超に達したことを表す図

上の図は、IBMが2024年9月以降に実施してきた人員削減を時系列で整理したものだ。第1波(2024年9月、8,000〜1万人)はレガシーインフラ・管理部門が中心だったが、波を重ねるごとに対象範囲が広がり、2026年4月の第4波ではついに成長事業であるRed Hatのコアエンジニアリングにまで踏み込んだ。この推移だけを見ても、IBMの人員削減が「不採算部門の整理」という単純な話ではなく、全社的な構造転換の一環であることがうかがえる。

IBMの人員削減、4つの波を振り返る

IBMの人員削減は一度きりのイベントではなく、2024年9月から現在まで途切れることなく続く「ローリング・レイオフ」の様相を呈している。各波の内容を整理すると以下のようになる。

第1波(2024年9月): 推定8,000〜1万人。レガシー基盤事業と管理部門(HR、経理などのバックオフィス機能)が中心だった。この時期、IBMは約200のHR職をAIエージェントに置き換えたとも報じられている。

第2波(2025年3月): 推定5,000〜7,000人。特にCloud Classic(従来型クラウドインフラ)事業が大きな打撃を受けた。

第3波(2025年第4四半期): CIO.comの報道によれば、IBMは270,000人の全社員のうち「低い一桁パーセンテージ」を削減すると発表。これは推定2,700〜8,600人に相当する。同時期、Red Hatのハイブリッドクラウド事業の成長率は前四半期の16%から14%へと鈍化しており、市場予想の16%成長を下回っていた。IBMの広報担当者は「第4四半期に、グローバル従業員の低い一桁パーセンテージに影響する施策を実行している」とコメントしている。

第4波(2026年4月): Techrightsの報道によれば、Red Hatのエンジニアリング部門で300人以上のGNU/Linuxエンジニアが同時に解雇された。対象にはlibvirt(仮想化管理API)、QEMU(仮想化エミュレータ)、OpenShift/ROSA(コンテナプラットフォームのベアメタル統合)といった、Red Hatの技術的な中核を担うプロジェクトの担当者が含まれていた。報道によれば影響を受けたのは主に中国拠点のチームで、従業員は事前通告なくVPNなど社内システムへのアクセスを制限されたという。

この4波を合計すると、2024年9月以降の累計削減数は1万5,000人を超える規模に達する。KORE1の分析記事では、2026年単年だけでも3,000〜9,000人規模になると推計されている。

なぜIBMはRed Hat部門まで削減するのか

Red Hatは2019年にIBMが340億ドルで買収した、同社にとって「ハイブリッドクラウド・オープンソース戦略」の要となる事業だ。にもかかわらず、なぜ成長事業であるはずのRed Hatまで人員削減の対象になったのか。背景には複数の要因が絡み合っている。

1. 成長率の鈍化という現実

CIO.comが報じたとおり、Red Hatハイブリッドクラウド事業の売上成長率は2025年第3四半期に14%まで低下し、前四半期の16%、市場予想の16%をいずれも下回った。IBM全体の決算自体は好調で、CIO Diveの報道によれば同社は生成AI関連の顧客エンゲージメントが「1,000件以上」に達したとしている。つまり、IBM全体としては収益を伸ばしながらも、Red Hat単体の成長率だけが減速するという「まだら模様」の決算になっている。株式市場はRed Hatの成長率を同社の将来性を測る重要指標として注視しており、経営陣としては、成長率の鈍化に対して何らかの対応を示す必要に迫られた可能性が高い。

2. AIによる開発生産性の向上を「実証」する必要性

IBMはこの1年間で70以上の内部ワークフローを自動化・AIで再設計したと説明している。仮想化基盤やコンテナプラットフォームの開発は、長年の蓄積によるテストスイート・CI/CDパイプライン・ドキュメントが充実している領域であり、コーディングエージェントによる自動化の実験対象として選ばれやすい。皮肉なことに、Red Hatのようなオープンソースプロジェクトはコードベースが公開されているため、AIコーディングツールの学習・検証がしやすいという側面もある。つまり「AIで代替しやすい業務」の対象が、定型的な事務作業だけでなく、成熟した技術基盤の保守・機能追加といったソフトウェアエンジニアリング領域にまで広がっている可能性がある。

3. 地政学的コスト最適化という「もう一つの理由」

Techrightsが指摘するように、今回のRed Hat削減の対象は主に中国拠点のエンジニアリングチームであり、会社側は「APACハブへの移行」を理由として説明している。これはAIによる効率化とは別の軸で、地理的な人件費最適化・地政学リスク回避という要素が絡んでいることを示唆している。KORE1の分析でも、IBMの一連の人員削減の実際の動機は「地理的コスト最適化(米国からインドなど低コスト地域への役職シフト)」にあり、AIはその「説明しやすいナラティブ」として機能しているという見方が示されている。

4. watsonxへの経営資源の再配分

IBMはCEOのArvind Krishna体制のもと、高粗利のソフトウェア・AI事業への資源集中を進めている。CIO Diveの報道によれば、IBMはソフトウェアとインフラストラクチャの2事業領域に注力を強めており、統合技術スタックとAIパートナーシップを組み合わせた競争優位を追求しているという。watsonxプラットフォームの開発・展開、Project Bob(社内向けAIコーディングツール)、小規模言語モデルの展開などに経営資源を振り向ける一方で、それ以外の部門は人員削減の対象となりやすい構図が浮かび上がる。

Red Hatエンジニアリング部門の削減内訳を示す図。libvirt、QEMU、OpenShift/ROSAという3つの技術領域が影響を受けたこと、会社側がAPACハブへの移行を理由に説明していることを表す

上の図は、Red Hatエンジニアリング部門の削減がどの技術領域に及んだかを示したものだ。libvirt・QEMUという仮想化基盤の中核技術と、OpenShift/ROSAというコンテナプラットフォームの主力製品の双方が影響を受けている点は重要だ。これらはRed Hatの製品ポートフォリオの中でも技術的な差別化要因とされてきた領域であり、単なる「余剰人員の整理」では説明しきれない範囲にまで削減が及んでいることがわかる。

主要IT企業のレイオフ規模比較

IBMの人員削減規模を、同時期に「AI」を理由の一つに挙げた他の主要IT企業と比較してみる。

企業削減規模期間・時期主な対象領域
IBM累計15,000人超2024年9月〜2026年4月レガシー基盤、Cloud Classic、Red Hatエンジニアリング
Oracle約21,000人過去12ヶ月(2026年6月時点)全社的(10-Kに「AI技術導入」と明記)
Amazon約16,000人2026年1月全社的、AI導入による効率化
Dell約11,000人2026年1月発表・3月開示AI最適化サーバー事業拡大に伴う再編
Meta約8,000人2026年5月うち7,000人はAI関連職へ配置転換
Cisco約4,000人弱2026年5月資源再配置(コスト削減目的ではないと説明)

この表からわかるとおり、IBMの累計削減規模はOracle・Amazonに次ぐ水準にある。ただし他社の多くが「単発の大型発表」であるのに対し、IBMは2024年9月から2026年4月まで4回にわたって波状的に削減を続けている点が際立つ。一度の発表で終わらせず、四半期ごとに規模を調整しながら継続的に人員を削減するスタイルは、IBMが構造改革を「一時的なコスト削減」ではなく「恒常的な経営方針」として位置づけていることを示している。

主要IT企業の累計レイオフ規模を比較した棒グラフ。Oracleが21000人で最大、IBMが15000人超、Amazonが16000人、Dellが11000人、Metaが8000人、Ciscoが4000人弱と続く

筆者の所感——「成長事業」だからこそ削減対象になった皮肉

ここまで各報道を整理してきたが、筆者が最も注目したいのは「なぜ成長事業であるはずのRed Hatが削減対象になったのか」という逆説だ。

一般的な企業のリストラは「業績不振の部門を整理し、成長部門に資源を集中する」という単純な図式で語られることが多い。ところがIBMのケースは違う。Red Hatは買収以来、IBM全体の成長ドライバーとして位置づけられてきた事業であり、2025年第3四半期時点でも前年比14%成長という、決して悪くない数字を叩き出している。それでもなお人員削減の対象になったという事実は、「業績が良いか悪いか」ではなく「AI時代にどれだけの人員で同じ成果を出せるか」という、全く別の評価軸で経営判断が下されていることを示唆している。

技術的な観点から見ても、libvirtやQEMUといった仮想化基盤は「枯れた技術」であり、機能追加よりも保守・バグ修正・セキュリティパッチが業務の中心になりやすい領域だ。こうした保守フェーズの技術は、コードベースの網羅的なテストとドキュメントさえ整っていれば、AIコーディングエージェントによる自動化の恩恵を受けやすい。つまりRed Hatが削減対象になったのは「成長が鈍化したから」だけでなく、「AIによる代替効果を最も実証しやすい領域だったから」という側面も無視できないというのが筆者の見立てだ。

一方で、Techrightsが報じた「APACハブへの移行」という説明には懐疑的にならざるを得ない。中国拠点のエンジニアが事前通告なくVPNアクセスを制限されたという運用は、通常の組織再編にしては強引すぎる。地政学的リスク回避、あるいは単なる人件費の地理的裁定という、AIとは直接関係のない経営判断が同時進行している可能性が高い。「AI」という説明は、株主・投資家向けに聞こえの良いナラティブとして機能しつつ、実際にはより複合的な要因が絡んでいるとみるのが妥当だろう。

日本ではどうなるか

IBMの一連の人員削減は米国内ポジションが中心と報じられているが、日本IBM・日本国内のRed Hatユーザー企業への影響も見過ごせない。

日本IBMへの直接的な影響は限定的、ただし警戒は必要

現時点の報道はいずれも「米国内ポジション」を対象としており、日本IBM単体での大規模な人員削減が発表された事実は確認されていない。ただし、IBMは過去にも米国本社の方針転換が数年遅れで日本法人に波及するケースが複数あった。特に今回のようにグローバル規模での「Red Hat事業の成長鈍化への対応」という構造的な要因が背景にある場合、日本法人の人員配置・組織体制にも中長期的に影響が及ぶ可能性は否定できない。日本IBMやRed Hat日本法人に勤務するエンジニアは、本社の決算発表・組織再編のニュースを継続的に注視しておく必要がある。

日本企業のオープンソース戦略への波及リスク

より広範な懸念として、日本国内でRed Hat Enterprise Linux(RHEL)やOpenShiftを基幹システムに採用している企業への影響が挙げられる。金融機関や製造業の基幹システムでRHEL・OpenShiftを利用する企業は多く、libvirtやQEMUといった仮想化基盤のコア開発者が減少すれば、長期的には製品の開発速度・サポート品質に影響が及ぶ可能性がある。特にエンタープライズ向けサポート契約を通じてRed Hatに依存している企業にとっては、開発体制の変化が保守契約の内容・SLA(サービス品質保証)にどう反映されるか、今後の動向を注視する必要がある。

「オープンソース人材の空洞化」という副次的リスク

日本のオープンソースコミュニティにとっても、libvirtやQEMUのような基盤プロジェクトのコア開発者が企業側の都合で流出することは、プロジェクト全体の持続可能性に関わる問題だ。日本国内でもKVM/QEMUベースの仮想化基盤を採用する企業・クラウド事業者は少なくなく、上流プロジェクトの開発体制縮小は、間接的に日本のインフラエンジニアリングにも影響を及ぼしうる。日本企業がオープンソース戦略を検討する際は、特定ベンダー(この場合はRed Hat/IBM)への過度な依存を避け、コミュニティ全体の健全性を含めた技術選定を行うことが、これまで以上に重要になるだろう。

筆者の見解・予測——レガシーIT企業のAI移行、次に何が起きるか

IBMのケースは、いわゆる「レガシーIT企業」がAI時代に生き残りをかけて構造転換を図る際の典型的なパターンを示している。今後、同様の動きが他の伝統的IT企業(Cisco、SAP、Oracleなど)でも加速すると筆者は予測する。

第一に、「成長事業だから安全」という前提はもはや通用しない。今回のRed Hatのケースが示すように、AI時代の経営判断では「事業が伸びているかどうか」よりも「同じ成果をより少ない人員で達成できるかどうか」が優先される局面が増えていく。エンジニアとしては、自分が所属する部門の業績だけでなく、その業務がAIエージェントによってどの程度自動化可能かという観点からも、自身のキャリアリスクを評価する必要がある。

第二に、「保守フェーズにある成熟した技術」ほどAI代替のリスクが高いという逆説的な構図に注意が必要だ。新機能開発やアーキテクチャ設計のような創造的業務よりも、テストが充実し仕様が固まった保守業務の方が、AIコーディングエージェントによる自動化の効果を発揮しやすい。長年同じ技術基盤の保守に従事してきたエンジニアほど、意識的に新しい技術領域・上流工程のスキルを獲得していく必要があるだろう。

第三に、地政学的要因とAI要因は今後さらに絡み合っていく。今回のRed Hat削減が「APACハブへの移行」と「AI効率化」という二つの説明を伴っていたように、今後の企業の人員削減発表では、複数の理由が同時に語られるケースが増えるとみられる。表面的な説明を鵜呑みにせず、決算資料・組織再編の実態を多角的に読み解くリテラシーが、エンジニア・ビジネスパーソン双方に求められる時代になっている。

読者へのアクションステップ

  1. 自分の担当領域の「AI代替可能性」を棚卸しする: 担当業務がテスト・ドキュメントの整った保守フェーズにあるか、あるいは仕様が流動的な新規開発フェーズにあるかを見極め、前者に偏っている場合は上流工程やアーキテクチャ設計などのスキルを意識的に伸ばす。
  2. オープンソースコミュニティへの直接関与を増やす: 企業の人員削減リスクに左右されにくいキャリア基盤として、個人でOSSプロジェクトにコントリビュートし、コミュニティ内での信頼・実績を築いておく。企業を離れても評価されるポートフォリオになる。
  3. 決算発表・組織再編ニュースを定点観測する習慣をつける: 自社・取引先企業の四半期決算やSEC提出資料に目を通し、「AI」という言葉がどの文脈で使われているかを継続的にチェックする。表面的な説明の裏にある実態を早期に察知できれば、キャリアの選択肢を主体的に確保しやすくなる。

Red HatのようなオープンソースおよびLinux基盤に携わるエンジニアにとって、今回の一件は「成長事業だから安泰」という思い込みを見直す契機になるはずだ。技術力そのものに加えて、AI時代における自分の役割をどう再定義するかが、今後のキャリアを左右する分岐点になるだろう。

この記事をシェア