何が起きたか

Appleは7月、元Appleエンジニアからハードウェアの機密情報を得るための仕組みをOpenAIが組織的に作り上げた、として提訴しました。これに対しOpenAIは訴え却下の申立てを行い、新たに提出された証拠からその防御戦略が明らかになっています。

注目すべきは、OpenAIが「元Apple社員が特定の情報にアクセスしたか」という事実関係を真正面から否定していない点です。代わりに、Apple自身のセキュリティ運用と退職時の手続き（オフボーディング）が杜撰であり、その情報はそもそも法的に保護される「営業秘密」の要件を満たしていない、と主張しています。

具体的な指摘は二つです。ひとつは、Appleが従業員に業務での個人iCloudアカウント利用を許していたこと。もうひとつは、退職後にアクセス権を適切に失効させていなかったことです。OpenAIは、被告であり元Appleエンジニアの Chang Liu 氏が退職した後も、Appleのマネージャーが同氏の個人iCloudアカウントにログインしたままファイルを移し、さらに後日Appleのプロジェクトに関する技術的な質問を同氏に投げていた、というテキストメッセージ記録を提出しました。

なぜ重要か

営業秘密は「秘密として管理されていること」が保護の前提です。OpenAIはここを突き、Appleが自らの「不可解な情報管理慣行（inexplicable information-management practices）」がもたらした帰結を当初の訴状から省いた、と非難しています。退職時にシステムを適切に締めなかった結果として生じた混乱や意図しないアクセスを、Appleは今になって窃取と呼び換えているのだ、という組み立てです。

この主張は二つの効果を狙っています。ひとつは、元Apple社員は単に旧同僚を助けようとしていただけだ、という説明に整合性を与えること。実際、退職者に技術的な質問を投げていたのがApple側だという記録は、この筋書きを補強します。もうひとつは、秘密として守られていなかったのなら、それは営業秘密ではないという法的なくさびを打ち込むことです。

訴状の「特定性」という第二の論点

OpenAIはさらに、Appleがどの「営業秘密」やどの機密部品が盗まれたのかを特定していないと指摘します。Appleの記述は「部品製造、製品テスト、ベンダー・サプライヤーとの関係、流通チャネルといった、製品開発プロセスの一般的なカテゴリー」にとどまる、というのがOpenAIの整理です。営業秘密訴訟では、何が秘密なのかを原告が具体的に示せるかどうかが早い段階の関門になります。抽象的なカテゴリー列挙のままでは、被告側は防御のしようがないという反論が成立しやすくなります。

OpenAIは動機面にも踏み込み、AppleはAIハードウェア分野で競合の前進を遅らせるために訴訟を使っている、と申立てで述べています。声明も強気です。「OpenAIにAppleの営業秘密を使う用途も、必要も、欲求もない」「OpenAIはAppleにある何とも全く異なる新しいものを作っている」。人材については、優秀なエンジニアや発明家、開発者を採用することには関心がある、その多くがAppleを離れてOpenAIに来ることを選んだ、Appleはそれが気に入らないのかもしれない、という言い回しで応じています。さらに、人材市場での劣勢や従業員の引き留めの失敗、製品へのAI統合の失敗を、根拠のない口実的な訴訟で埋め合わせることは許されるべきでない、とまで書いています。

局面は拡大方向へ

一方のAppleは今週、証拠開示（ディスカバリー）の迅速化を裁判所に求めました。社内調査の結果、営業秘密の窃取とされる行為に関与した、あるいはそれを目撃した元従業員がほかにもいる可能性がある、というのが理由です。当事者が一人二人の話で終わらない可能性が出てきたことを意味します。

争いの構図は「情報が動いたか」から「その情報は守られていたか」へと移りつつあります。この転換は、退職者管理のログが法廷でどう扱われるかを示す実例になります。

💼 事業会社視点：これは自社にどう効くか

日本企業の経営陣がこの件から読むべきは、AI人材の流動化が進むほど「退職時の運用ログ」が自社の資産価値を左右する、という現実です。OpenAIの主張が通るかは別として、その論理構造——個人クラウドの業務利用を黙認し、退職後もアクセスを止めず、あろうことか退職者に技術質問を投げていた——は、日本の事業会社にそのまま当てはまります。個人のiCloudやGoogleアカウントでの資料共有、退職者のSlackやGitHub権限が数カ月放置される、前任者にLINEで仕様を聞く。どれも珍しくありません。

特に影響が大きいのは、他社に技術やノウハウを預ける立場です。受託開発・SIerは、クライアントの機密を扱いながら要員の入退場が激しく、常駐終了時のアカウント回収がプロジェクト単位で属人化しがちです。SaaSやECでは、退職したエンジニアが個人アカウントに残した設計資料や顧客データが、そのまま次の職場に持ち込まれるリスクを負います。

事業責任者が今週動くなら三つです。第一に、退職者のアカウント失効を人事システム起点で自動化し、失効の記録を残す。第二に、個人クラウドと私用メッセージアプリでの業務データ授受を明確に禁じ、例外運用を潰す。第三に、自社が「守るべき情報」を部品調達・テスト手順・取引先関係といったカテゴリーではなく、具体的なドキュメント単位で棚卸ししておく。何を秘密としているかを平時から特定できていない企業は、いざというとき法的にも守られません。