gists

クリーンルーム設計（Clean Room Design）

概要

ソフトウェアやハードウェアを開発する際に、著作権侵害の訴訟リスクを避けるために使われる手法。日本語では「クリーンルーム手法」や「中国の壁方式」とも呼ばれる。

基本的な仕組み

開発チームを2つに分けて、間に情報の壁（クリーンルーム）を作る。

チーム1：仕様解析チーム

元の製品を分析
「何をするものか」という仕様書だけを作成
コードや内部実装には触れない

チーム2：実装チーム

元の製品を一切見ない
チーム1が書いた仕様書だけを頼りにゼロからコードを書く

なぜこれで合法になるのか

著作権は「表現」を保護するもの
「アイデアや機能」そのものは保護しない
「元のコードを見ていない」ことを証明できれば侵害にならない

歴史的事例：IBM PC互換機

背景

1981年にIBM PCが大ヒット
他社も互換機を作りたかった
BIOS（基盤ソフトウェア）の互換実装が必要
IBMのBIOSコードをコピーすれば著作権侵害

Phoenix Technologies社の解決策

解析チームがIBM BIOSを調査し、動作仕様書を作成
IBM BIOSを一切見たことがないエンジニアだけで実装チームを構成
仕様書だけを見てゼロからコードを書く
プロセスを全て記録・文書化

結果

Phoenix社がBIOSを各社にライセンス販売
Compaq、Dell、HP、Gatewayなどが互換機を製造
IBM PC互換機市場が爆発的に拡大
皮肉にもIBM自身は後にPC事業から撤退

現代でも使えるのか

結論

有効だが、当時よりハードルは上がっている。

現代の使用例

Wine：Linux上でWindowsアプリを動かす
ReactOS：Windows互換のオープンソースOS
Proton（Valve社）：Steam DeckでWindows向けゲームを動作
LibreOffice：Microsoft Office形式の互換実装
レトロゲーム機のエミュレーター

現代で難しくなった理由

要因	内容
特許の壁	著作権は回避できても、特許は「アイデア自体」を保護するため別問題
エンジニアの「汚染」	GitHubやStackOverflowで他社コードを目にする機会が多い
利用規約（EULA）	「リバースエンジニアリング禁止」条項が一般的
DMCA等の法規制	暗号化解除などが別途違法になるケースがある

AI時代の新しい論点

AIが生成したコードは「クリーン」と言えるか？
学習データに元コードが含まれていた可能性
法整備が追いついておらず、今後の判例次第

「元コードを見たことがないエンジニア」は必須か？

結論

法的には必須ではないが、訴訟で勝つための強力な予防策。

法的に問われること

被告のコードが原告のコードをコピーしたものか
エンジニアが生涯一度も見たことがないか、ではない

必要な証明

実装時に元のコードを参照していない
実装は独立した情報源に基づいている
開発プロセスが記録・追跡可能

それでも「見たことがない人」が理想とされる理由

1. 潜在意識の汚染（subconscious copying）

過去に見たコードを無意識に真似る可能性
米国判例では意識的でなくても侵害認定されうる
有名事例：ジョージ・ハリスンの音楽訴訟

2. 立証責任の問題

「見たが参照しなかった」の証明は困難
「アクセスできなかった」の証明は容易

3. 相手側の攻撃材料

原告側弁護士は必ず過去の接触歴を追及
「見ていません」と言い切れる方が有利

実務上の段階的アプローチ

レベル	内容	リスク
1：純粋クリーンルーム	元製品の知識ゼロ（Phoenix BIOS方式）	最小
2：機能のみ接触	ユーザーとして使ったが、コードは未見	小
3：過去接触あり	以前扱ったが一定期間離れている	中
4：ドキュメント化で代替	見たが参照しないことを記録で証明	大

実例

Compaq（1982年）：BIOSエンジニア採用時にIBMコード接触歴をスクリーニング
Wine / ReactOS：Microsoft機密情報に触れた経験者の貢献を慎重に扱う

まとめ

クリーンルーム設計は著作権侵害を回避する合法的なテクニック
歴史的にはIBM PC互換機市場を生んだ画期的な手法
現代でも有効だが、特許・EULA・DMCAなど他のハードルが増加
単独の解決策ではなく、法務戦略全体の一部として運用するのが現代的
プロジェクトのリスク許容度に応じて厳格さを調整するのが実務

This site is open source. Improve this page.