PC業界の不正と闘った男たち――巨大企業に逆らい、技術者の誇りを守った人々の記録
Microsoft、Intel、PC OEM、そして名前の残らないエンジニアたち
パソコン業界の歴史は、技術革新と成功の物語として語られることが多い。
IntelのCPU、MicrosoftのWindows、IBMのPC、そしてDell、HP、NEC、富士通、Lenovo。
これらの企業は、世界中にパソコンを普及させ、社会を変えてきた。
しかし、その華やかな歴史の裏側には、あまり知られていない出来事がある。
独占的な取引条件、競合企業への圧力、欠陥製品への不十分な対応、そして出荷されたパソコンに潜む重大なセキュリティ問題。
こうした問題に異議を唱え、巨大企業を相手に闘った人々がいた。
彼らは経営者や弁護士だけではない。
CPUの計算結果に疑問を抱いた数学者、OSの支配力に抗議したPCメーカーの幹部、BIOSを解析した研究者、そして製品の安全を守ろうとしたセキュリティ技術者たちである。
私自身、長年PC開発の世界に身を置いてきた。
その経験から考えても、技術的に正しいことを主張するのと、企業にそれを認めさせることは、まったく別の問題だ。
今回は、裁判記録、公正取引委員会の審決、メーカーの公式発表などを手掛かりに、PC業界の不都合な歴史を振り返りたい。
なお、本記事では、独占禁止法違反が認定された事件、企業間で和解した事件、セキュリティ上の欠陥が発見された事件を区別して扱う。技術的な欠陥が存在したからといって、それが直ちに企業の故意による不正を意味するわけではない。
第1章 IBMでさえMicrosoftに逆らえなかった
1995年、Windows 95の発売を目前に控えたIBMで深刻な問題が起きていた。
IBMは自社のOS/2やLotus SmartSuiteを推進していた。Microsoftにとっては、WindowsやOfficeと競合する製品である。
MicrosoftはIBMの方針を問題視し、Windows 95のライセンス交渉が難航した。
裁判所が1999年に認定した事実によると、Microsoftは1995年7月、IBMへのWindows 95の最終版コード提供を見送り、ライセンス交渉を停止した。
IBMは競合PCメーカーがすでに最終版を受け取っていることを知っていた。
そして、IBMがWindows 95をプリインストールするためのライセンスを取得できたのは、1995年8月24日の公式発売イベント開始の、わずか15分前だった。
この遅れによってIBMは重要な商機を失った。
さらにMicrosoftは、IBM向けの担当者を3人から1人へ減らした。裁判所は、この支援縮小もIBMの開発・評価・出荷に悪影響を与えたと認定している。
この交渉の実態を法廷で証言した人物が、IBMのソフトウェア戦略担当者ギャリー・ノリスである。
ノリスの証言は、当時のPCメーカーが置かれていた立場を象徴している。
たとえIBMほどの巨大企業であっても、Windowsの供給を失えばPC事業そのものが危うくなる。
自社製品に何を搭載するか。その最終的な自由を、PCメーカーは十分に持っていなかったのである。
この一連の行為について、米国の独占禁止法訴訟ではMicrosoftによる独占維持行為の一部が違法と判断された。
第2章 富士通が実現できなかった「Excel＋一太郎」
同じ1995年、日本でもMicrosoftとの間に興味深い対立が起きていた。
舞台は富士通のFMVシリーズである。
当時、日本で人気のあったワープロソフトはジャストシステムの一太郎だった。一方、表計算ソフトではMicrosoft Excelが強い存在感を持っていた。
富士通は両者を組み合わせたパソコンを販売したいと考えた。
つまり、
ワープロは一太郎。表計算はExcel。
ユーザーの需要に沿った、合理的な製品構成である。
ところがMicrosoftは、Excel単体のプリインストール契約を認めず、Wordとのセット搭載を要求した。
富士通はExcel単体の契約を要請したが、拒否された。
結局、1995年3月1日にExcelとWordをセットで搭載する契約を締結した。
これは推測ではない。
1998年12月14日の公正取引委員会の審決に明確に記録されている。
公取委は、MicrosoftによるExcelとWord、さらにOutlookの抱き合わせを問題視し、違反行為を取りやめるよう命じた。
この事件で、富士通側の交渉担当者の実名は確認できなかった。
しかし、商品企画の自由を守ろうとした人々がいたことは確かである。
PCメーカーにとって、プリインストールソフトは単なる付属品ではない。
商品の魅力や差別化を左右する、重要な仕様だったからだ。
この事件を知ると、Windowsパソコンの製品構成が、技術やユーザーの需要だけで決まっていたわけではないことが分かる。
第3章 Intelの独占的な取引に挑んだAMD
2005年3月8日。
公正取引委員会は、日本のIntel法人に対して独占禁止法違反の排除勧告を行った。
問題となったのは、国内PCメーカーに提供されていたリベートや販売促進資金だった。
Intelは、競合CPUを採用しないことや、Intel製CPUの搭載割合を高く維持することなどを条件に、資金提供を行っていた。
対象となったのは、NEC、富士通、ソニー、東芝、日立という日本を代表するPCメーカー5社だった。
Intelは勧告に応じたものの、公取委の事実認定には同意しなかった。
そして同年6月、日本AMDがIntelに対して損害賠償請求訴訟を起こした。
日本AMDの吉沢俊介取締役らは、Intelの取引慣行がAMDの事業活動を妨げ、消費者の製品選択にも影響していると訴えた。
日本AMDの訴状には、AMD搭載モデルの削除や、展示会での製品展示への介入など、さまざまな主張が記されていた。
ただし、こうした個別の主張がすべて裁判で認められたわけではない。
2009年11月12日、IntelとAMDは包括的に和解した。
IntelはAMDに12億5,000万ドルを支払い、一定の取引慣行に関する制限にも合意した。
和解はIntelによる違法行為の全面的な自認ではないが、長年続いた訴訟に終止符が打たれた。
この事件で考えさせられるのは、PC OEMの立場である。
性能、消費電力、発熱、品質、安定性。
CPUの採用には、多くの技術的な評価項目が存在する。
しかし、実際の製品選定には調達価格、販売奨励金、経営上の取引条件も関係する。
優れた技術が必ずしも製品に採用されるとは限らない。
PC業界の競争には、技術とは別の力が働くことがあるのだ。
第4章 Intelの計算ミスを暴いた一人の数学者
1994年、数学者トーマス・ナイスリーは、Pentiumの計算結果に奇妙な現象が起きていることに気づいた。
特定の浮動小数点除算で、期待した結果が得られなかったのである。
彼は自分のプログラムを疑い、何度も検証を繰り返した。
そして、問題はプログラムではなく、Pentiumの除算処理に存在することを突き止めた。
これがPentium FDIV事件である。
Intelは以前から欠陥を認識していたが、通常の利用で問題が表面化する可能性は低いと評価していた。
当初、CPU交換への対応も限定的だった。
しかし、ナイスリーによる発見が公になり、利用者の反発が広がった。
1994年12月20日、Intelは方針を転換し、懸念する利用者には交換を提供すると発表した。
最終的にIntelは、交換対応などに関連して4億7,500万ドルの費用を計上した。
Intel自身も1994年の年次報告書で、当初は顧客満足よりもエンジニアリング上の判断を優先してしまったと振り返っている。
ナイスリーはIntelの社員ではなかった。
企業と競争する経営者でもなかった。
ただ、計算結果がおかしいという事実を見逃さなかった数学者だった。
巨大企業の公式説明を覆したのは、権力ではなく、再現可能な技術的証拠だった。
第5章 HPの音声ドライバーに残されていたキーロガー
2017年5月、スイスのセキュリティ企業modzeroは、HP製PCに搭載されたConexant製音声ドライバーの問題を公表した。
音声ドライバーには、キーボード入力を記録できるデバッグコードが残っていた。
通常、音声ドライバーが扱うのはオーディオデバイスである。
しかし、マイクのミュートキーなどの操作を監視するため、キーボード入力に関係する処理が実装されていた。
問題は、開発時に利用したデバッグ機能が、量産製品にも残されていたことだった。
特定の構成では、入力された内容がログファイルへ保存される可能性があった。
この問題について、HPのパーソナルシステムズ部門CTO、マイク・ナッシュは2017年5月12日に説明を公表した。
HPは、サプライヤーであるConexantのデバッグコードが誤って製品版に残っていたことを認め、修正ドライバーを提供した。
ここで重要なのは、意図的な情報窃取が確認された事件ではないという点だ。
しかし、完成品として出荷したPCに危険な機能が存在した以上、顧客に対する責任は残る。
PC OEMがサプライヤーのコードをそのまま信用する危険性を示した事件だった。
WHQLやHLKの試験に合格したとしても、ソフトウェアのすべてのセキュリティ上の問題が発見されるわけではない。
正常に動作することと、安全であることは同じではない。
第6章 Intel由来のBIOSコードを追跡したThinkPwn事件
2016年、セキュリティ研究者ドミトロ・オレクシウクが、Lenovo製PCのUEFIファームウェアに重大な脆弱性を発見した。
ThinkPwnと呼ばれる問題である。
攻撃者がローカル管理者権限を取得している場合、System Management Mode（SMM）の脆弱性を悪用し、さらに高い権限でコードを実行できる可能性があった。
SMMはOSよりも強い権限で動作するため、問題が深刻化すれば、ファームウェアの保護機構を回避される恐れがある。
LenovoのPSIRTは2016年6月30日、最初のセキュリティアドバイザリを公表した。
調査の結果、問題のコードが独立系BIOSベンダーを経由して製品に組み込まれていることが分かり、IntelやBIOSベンダーも調査に加わった。
その後、Lenovoは影響製品の特定とBIOS更新を進めた。
これはIntelが意図的なバックドアを仕込んだ事件ではない。
また、Lenovoの技術者がIntelの修正拒否を覆したという記録も確認できない。
しかし、外部研究者による指摘から、PC OEM、BIOSベンダー、半導体メーカーを巻き込む調査が進められた事例である。
BIOS/UEFIの脆弱性では、問題の発生元と製品を出荷する企業が異なることが珍しくない。
それでも、顧客への修正提供を調整する役割はPC OEMのPSIRTが担う。
この事件は、PSIRTが単なる脆弱性情報の受付窓口ではなく、サプライチェーン全体を動かす調整機能であることを示している。
第7章 LenovoのBIOSに残されていた製造工程用コード
2022年4月、ESETの研究者マルティン・スモラールらが、LenovoのノートPCに存在するUEFI脆弱性を公表した。
CVE-2021-3970、CVE-2021-3971、CVE-2021-3972である。
このうち2件は、製造工程で使用するためのUEFIドライバーに関係していた。
本来、量産製品では無効化されるべきコードが、適切に無効化されない状態で残っていたのである。
攻撃者がOS上で高い権限を取得した場合、SPIフラッシュの書き込み保護やSecure Bootを無効化できる危険性があった。
ESETは2021年10月11日にLenovoへ報告した。
Lenovoは翌日に受領を回答し、11月17日には脆弱性を確認した。
そして2022年4月18日、セキュリティアドバイザリを公開した。
ただし、すべての機種が修正対象になったわけではない。
開発サポートが終了した一部機種については、修正が提供されないことも明らかになった。
ここにはPC OEMの難しい問題が存在する。
脆弱性を修正することは技術的に可能でも、旧機種のBIOSを変更し、検証し、配布し続けるには開発資源が必要になる。
さらに、BIOS更新は失敗するとPCが起動しなくなる危険もある。
しかし、修正しないという判断を下すのであれば、影響機種や残留リスクについて説明することも重要である。
第8章 TPMの安全神話を揺るがしたROCA
2017年、Infineonの暗号ライブラリに重大な問題があることが明らかになった。
ROCA（CVE-2017-15361）と呼ばれる脆弱性である。
問題は、特定のRSA鍵生成処理に数学的な弱点があったことだった。
通常、RSAの公開鍵から秘密鍵を求めることは極めて困難である。
しかし、問題のあるライブラリによって生成された鍵には特殊な性質があり、条件によっては公開鍵から秘密鍵を復元できる可能性があった。
驚くべきことに、TPM内部から秘密鍵を直接読み出す必要はない。
TPMが秘密鍵を安全に保持していても、生成した鍵の数学的な強度そのものに欠陥があれば、攻撃が成立し得るのである。
この問題を発見したのは、マサリク大学などの暗号研究者たちだった。
Infineonへの非公開報告を経て、2017年10月に研究成果が公表された。
その後、複数のPC OEMが対象TPMの更新情報や対策を案内した。
TPMのファームウェア更新だけでは対応が完結しない場合もあった。
すでに生成した弱い鍵は、更新によって自動的に安全な鍵へ変わるとは限らないからである。
鍵の再生成、証明書の再発行、アプリケーションの復旧などを検討する必要があった。
この事件には重要な教訓がある。
Root of Trustは、特定の半導体やファームウェアを信用するだけでは成立しない。
暗号アルゴリズム、鍵生成、鍵管理、更新、失効、そしてOEM側の対応まで含めて、安全性を確保しなければならない。
第9章 PC OEMのエンジニアはなぜ歴史に名前を残さないのか
ここまで紹介してきた人物の中には、論文や裁判記録、セキュリティ研究報告書に実名が残る人々がいる。
しかし、興味深いことに、PC OEM内部で対応した技術者の名前は、あまり記録されていない。
例えば、LenovoのBIOS更新を担当した開発者は誰だったのか。
HPの修正ドライバーの検証を担当した品質保証の技術者は誰だったのか。
ROCA事件でTPMベンダーと交渉し、対象機種を特定し、修正ファームウェアの展開を判断したのは誰だったのか。
公式のセキュリティアドバイザリには、通常そこまで記載されない。
実際の脆弱性対応では、さまざまな部門が連携する。
研究者が問題を発見し、PSIRTが報告を受ける。
開発部門が再現し、サプライヤーが原因を調査する。
品質保証部門が修正版を検証し、商品部門が対象機種を確認する。
そして関係者が公開時期や顧客への説明を決める。
一つのCVEに対する修正の裏側には、多くの技術者の仕事が存在する。
彼らは必ずしも、巨大企業と正面から対立しているわけではない。
むしろ、取引先との関係を維持しながら、技術的な問題を解決するために協力している場合が多い。
それでも、サプライヤーの説明を鵜呑みにせず、自分たちで事実を確認する姿勢は欠かせない。
PC OEMのセキュリティ技術者は、まさにその責任を担っている。
第10章 技術者は何と闘っているのか
これらの事件を振り返ると、PC業界の技術者が直面してきた問題には、共通点がある。
それは、技術的に正しい判断が、必ずしも組織の意思決定に採用されるとは限らないということだ。
品質問題を発見しても、修正には費用がかかる。
セキュリティ上のリスクを発見しても、サプライヤーは悪用可能性が低いと判断することがある。
商品企画が顧客に適した仕様を考えても、ライセンス契約によって実現できない場合がある。
優れたCPUが存在しても、調達契約の条件によって採用が制約されることがある。
そのような状況で、技術者はどう行動するべきなのだろうか。
私は、少なくとも三つのことが重要だと考える。
第一に、事実を検証すること。
第二に、検証結果と判断の根拠を記録すること。
第三に、顧客や利用者の安全を考え、適切な経路で問題を提起すること。
もちろん、技術者の主張が常に正しいとは限らない。企業には品質、費用、納期、法務、セキュリティなど、さまざまな制約がある。
だからこそ、感情的な対立ではなく、再現可能な証拠と合理的なリスク評価が必要になる。
技術者の信念だけで企業を動かすことは難しい。
しかし、証拠がなければ、さらに難しくなる。
終章 名前の残らない英雄たちへ
PC業界には、数多くの成功物語が存在する。
Bill Gates、Andy Grove、Michael Dell、Steve Jobs。
業界を変えた経営者たちの名前は、これからも歴史に残るだろう。
しかし、もう一つの歴史がある。
Intelの計算ミスを発見したトーマス・ナイスリー。
Microsoftの取引慣行を法廷で証言したギャリー・ノリス。
BIOSの重大な欠陥を公表したドミトロ・オレクシウク。
UEFIの製造工程用コードに潜む危険を発見したマルティン・スモラール。
そして、TPMの暗号処理を数学的に検証した研究者たち。
彼らの活動がなければ、いくつもの問題は十分に明らかにならなかったかもしれない。
さらに、その裏側には大勢の名前の残らないエンジニアがいた。
BIOSを修正した人。
TPMファームウェアを評価した人。
不具合を再現した人。
サプライヤーと粘り強く交渉した人。
何度もテストを繰り返して、安全な更新プログラムを完成させた人。
彼らが全員、不正と闘っていたわけではない。
しかし、彼らの地道な仕事が、PCの品質と安全性を支えてきたことは間違いない。
PC業界の歴史は、製品を作った企業の歴史だけではない。
巨大企業の説明に疑問を持ち、自分の目で確認し、証拠を残し、問題の解決に取り組んできた技術者たちの歴史でもある。
その仕事が、もっと正当に語られてもよいのではないだろうか。
私はそう思っている。
主な参考資料
※本記事は公開された司法記録、行政機関の資料、メーカー・研究機関の発表に基づいて構成しました。各事件の法的評価や技術的な原因については、確認できる事実と当事者の主張を区別しています。
#PC業界 #パソコンの歴史 #Microsoft #Intel #富士通 #BIOS #UEFI #TPM #PSIRT #セキュリティ #エンジニア #技術者の誇り
