電車線設計用プログラム事件――ソースコードの「ありふれた表現」はどこまで保護されないのか

東京地判平成15年1月31日・平成13年(ワ)第17306号（著作権侵害差止等請求事件・判時1820号127頁）
判決文（裁判所ウェブサイト）

1. はじめに――「同業他社のCADマクロが自社製品とそっくり」は著作権で止められるか

SI・CADベンダーの実務家であれば、一度は次のような相談を受けたことがあるのではないでしょうか。「長年かけて開発してきた設計支援ツールと、よく似た画面・よく似た機能を持つ競合製品が出てきた。ソースコードもおそらく相当程度似通っているはずだ。著作権侵害で差止めができないか」。

プログラムは著作権法10条1項9号で明文上の著作物とされており、一見すると保護は手厚いようにも見えます。しかし、いざ訴訟になると、「確かに似ているが、具体的記述のレベルで見ると、そもそも創作性がない」として請求が退けられる事例が少なくありません。本稿で取り上げる電車線設計用プログラム事件（東京地判平成15年1月31日・平成13年(ワ)第17306号）は、AutoCAD上で動作する鉄道電気設計用のカスタマイズプログラムについて、ソースコードの個別記述ごとに創作性の有無を丁寧に判断し、最終的に侵害を否定した、プログラム著作物性に関する代表的な裁判例です。

本稿では、プログラムの著作物性に関する前提知識を整理したうえで、本判決の事案・争点・判旨を解説し、SI業界の契約実務への示唆を検討します。

2. 前提知識――プログラムの著作物性と「ありふれた表現」論

2.1 プログラムの定義と保護の仕組み

著作権法は、プログラムを「電子計算機を機能させて一の結果を得ることができるようにこれに対する指令を組み合わせたものとして表現したもの」（法2条1項10号の2）と定義し、10条1項9号で著作物として例示しています。もっとも、プログラムの「表現」として保護されるのは、あくまで思想又は感情が創作的に表現されたもの（法2条1項1号）である必要があります。

他方、10条3項は、プログラム言語（記述のための文字その他の記号及びその体系）、規約（プログラム言語の用法についての特別の約束）、解法（プログラムにおける電子計算機に対する指令の組合せの方法＝アルゴリズム）には著作権法上の保護が及ばないと明文で規定しています。要するに、言語・インタフェース仕様・アルゴリズムはアイデア領域であり、著作権の保護対象から除外されているわけです（図「プログラムの著作物性はどう判断されるか」参照）。

2.2 プログラムにおける「ありふれた表現」論

プログラムは、自然言語の文芸作品と異なり、(i) 記述に用いる記号が制約され（プログラム言語の厳格な構文規則）、(ii) 経済効率や可読性の観点から指令の組合せの選択肢が限定され、(iii) 同じ機能を実現するコードが相互に類似しやすい、という構造的特徴を持ちます。

このため、裁判例は、プログラムの著作物性を判断する際、表現の選択の幅（creativity margin）があるかどうかを重視し、選択の幅が極めて狭い記述、短く定型的な記述、一般関数の単純な組合せにすぎない記述などについては、作成者の個性が発揮されておらず創作的表現とはいえないとして、創作性を否定する傾向にあります。これを俗に「プログラムにおけるありふれた表現論」と呼びます。

侵害の場面でも、この考え方は直接に機能します。創作性のない記述は保護対象から除外されるため、創作性が認められる「具体的記述」部分のみを対比して実質的同一性・直接感得性を判断すべきであって、全体のフローやモジュール構成が似ているだけでは複製権・翻案権侵害とはいえない、というのが定着した判断枠組みです。

2.3 データと「プログラム」の境界

近年のCAD・設計ツールは、実行ロジック本体（ソースコード）と、形状定義ファイルや設定ファイル（データ）とを組み合わせて動作します。データ単体では電子計算機に対する指令とは言いにくくとも、本体プログラムと協働して機能を実現する場合、当該記述が「指令を組み合わせたものとして表現したもの」として法2条1項10号の2の「プログラム」に該当しうるかは、実務上重要な論点です。本判決はこの点にも明示的に判断を下しています。

3. 事案の概要

3.1 当事者と製品

原告Xは、AutoCAD（Autodesk社の汎用CAD）上で動作する、鉄道電気設計及び設備管理用の図面作成支援プログラムを開発し、鉄道事業者に販売していました。当該プログラムは、(i) AutoLISP言語で記述されたLISPファイル群（初期設定、計算処理、作図指令等）、(ii) メニュー表示用のメニューファイル、(iii) 特殊な記号・電気設備の部品形状を定義する形状定義ファイル（shapeファイル）などから構成されていました。

被告Yもまた、同種のAutoCAD用カスタマイズプログラム（鉄道電気設計・設備管理用）を開発・販売していたところ、原告は、被告プログラムが原告プログラムの複製又は翻案にあたるとして、著作権（複製権・翻案権・譲渡権）侵害に基づき、(a) 製造販売の差止め、(b) プログラムの廃棄、(c) 4000万円を超える損害賠償を請求しました。

3.2 対比の対象となった部分

原告は、被告プログラムの複数の構成部分、具体的には (1) 初期設定部のLISPコード、(2) メニュー表示用プログラム、(3) 形状定義記述（shape definition） などについて、対応する原告プログラムとの類似を主張しました。

4. 争点

主要な争点は次の3つに整理できます。

1. プログラム該当性：形状定義記述のように、単体では電子計算機への指令として機能しないデータ部分が、著作権法2条1項10号の2の「プログラム」に該当するか。
2. 創作性：原告プログラムの各構成部分（初期設定部、メニュー表示、形状定義記述等）に、創作性が認められるか。
3. 実質的同一性・侵害の成否：仮に創作性が認められる部分があるとして、被告プログラムの対応部分が、原告プログラムの創作的表現を直接感得できる程度に類似しているか。

5. 裁判所の判断

5.1 プログラム該当性――協働する記述は「プログラム」に当たる

裁判所はまず、形状定義記述について、それが単体では実行不能な座標値等の数値記述であっても、AutoCAD本体の形状読込機能と協働することで、特定の図形を描画させるという「電子計算機に対する指令の組合せ」として機能する以上、著作権法2条1項10号の2にいう「プログラム」に当たりうるとしました。データと実行コードを観念的に分離し、データ側を一律に保護対象外とする考え方を採らない点に意義があります。

5.2 創作性――具体的記述ごとの個別判断

もっとも、「プログラムに当たる」ことと「著作物である」こととは別問題です。裁判所は、創作性については原告プログラムの構成部分をひとつずつ個別に検討しました。

(1) 初期設定部（キロ程オフセット値等の入力処理）
画面に文字列を表示したうえで、ユーザーから実数値を受け取り、AutoLISPの一般的な関数を用いて変数に代入する、という極めて単純な処理を、ごく短い構文で表現しているにすぎない。どのような入力項目を設けるかという入力項目の選択はアイデアであり、変数への値設定の処理の流れは「解法」（10条3項）にあたる。表現としての選択の幅が極めて狭く、作成者の個性が発揮された表現とはいえず、創作性なし。

(2) メニュー表示用プログラム
全体として短く、AutoLISPの一般的な関数を用いて簡単な指令を組み合わせた記述が大半を占める。作成者の個性が発揮された表現とはいえず、創作性なし。

(3) 形状定義記述
形状定義は、形状番号・バイト数に続いて座標値や描画指令を数値で列挙する記述であるが、当該座標値の列挙自体は、表現したい図形（電気設備の記号等）の形状という事実・アイデアによって一義的に決まる側面が強く、座標値の記述に創作性を見出すことはできない。

5.3 侵害の成否――創作性ある記述の具体的対比

そのうえで裁判所は、プログラム相互の類似性判断の一般論として、「具体的記述のうち創作性が認められる部分を対比したうえで、実質的に同一といえるか、創作的表現を直接感得できるかという観点から判断すべきであり、全体の手順や構成が類似しているかという観点のみから判断すべきではない」という枠組みを示しました。

原告プログラムのうち創作性が認められる部分はごく限られ、かつ被告プログラムの対応部分は、構文上の相違により具体的記述が大きく相違していました。よって裁判所は、複製権侵害も翻案権侵害も認められないと結論し、原告の請求を棄却しました。

6. 本判決の射程と実務示唆

6.1 判例としての位置づけ

本判決は、(i) データ的記述も協働して機能すれば「プログラム」該当性を認めうること、(ii) もっとも創作性はサブルーチン単位・記述単位で個別に判定されること、(iii) 侵害判断は創作性ある具体的記述の対比に絞ること、という三段構えの分析枠組みを明確に示した点で、プログラム著作物性論の実務上の到達点を示すリーディングケースのひとつです。同種のCADカスタマイズ事件（AutoLISPマクロ、Excelマクロ、スクリプト言語のユーティリティ等）において、今日まで繰り返し参照されています。

6.2 SI・ソフトウェア開発業界への示唆

(a) ソースコード流用リスクへの過信は禁物
元従業員が競合企業に移籍し、記憶に頼って「よく似た」ツールを再構築するケースでは、原告側が「全体として瓜ふたつだ」と主張しても、個別記述レベルでは創作性が薄く、被告側の構文・実装の細部差異によって請求が通らないことが多い、という冷徹な現実を本判決は示しています。逆に言えば、ソースコード流用の抑止は著作権のみでは不十分であり、営業秘密（不正競争防止法2条1項4号～10号）、就業規則・秘密保持契約、競業避止義務契約の設計を組み合わせる必要があります。

(b) 受託開発契約における著作権帰属・利用許諾条項の再設計
発注者（鉄道事業者、大手メーカー等）が複数のベンダーに段階的に開発委託する場面では、先行ベンダーのコード資産が後続ベンダーに引き継がれることが多く、著作権侵害リスクが争点化しがちです。本判決を踏まえると、(i) どのモジュールに創作性が認められる余地があるか、(ii) ライブラリ化・部品化された記述（初期化ルーチン、入出力テンプレート、形状定義ファイル等）をどのように扱うか、をあらかじめ契約書に明記し、著作権だけでなく利用許諾範囲（サブライセンス、派生物の作成、成果物の横展開）まで具体化しておくことが望まれます。

(c) 訴訟戦略上の準備
原告側は、ソースコードのうち創作性を主張しうる部分を具体的に特定し、(i) 表現上の選択の幅の広さ、(ii) 同一機能を実現する代替記述の存在、(iii) 作成者の実際の選択過程、を立証する準備が不可欠です。単に「コード全体が類似している」という抽象主張では、本判決のような判断枠組みの下では勝訴は難しいでしょう。逆に被告側は、各記述が一般関数の単純な組合せにすぎない、アイデアに従属する記述にすぎない、アルゴリズムの必然であるという三段論法で創作性を争うのが典型的な防御線となります。

7. まとめ

電車線設計用プログラム事件は、プログラム著作権訴訟における創作性の判断単位と侵害判断の枠組みを具体的に示した重要判決です。

1. データ的記述も本体プログラムと協働すれば「プログラム」に該当しうる（著作物性の入口は広い）
2. もっとも、個別記述単位で見れば、一般関数の単純な組合せ、入力項目の選択、座標値の列挙などは創作性が否定されることが多い
3. 侵害の判断は、創作性ある具体的記述部分の実質的同一性に絞られ、全体構成の類似だけでは足りない

SI・CADベンダーとしては、「自社コードは著作権で守られている」という感覚だけでは競合対策として不十分であり、営業秘密管理・契約設計との組合せで権利保護を組み立てていく必要があります。プログラム著作権法務を考えるすべての実務家にとって、本判決は今なお避けて通れない基本判例といえるでしょう。

8. 出典・参考判例

• 電車線設計用プログラム事件：東京地判平成15年1月31日・平成13年(ワ)第17306号・判時1820号127頁

裁判所ウェブサイト・裁判例検索

• 著作権法2条1項1号、2条1項10号の2、10条1項9号、10条3項
• 関連参考：システムサイエンス事件（東京高判昭和62年5月19日）ほか、プログラム著作物性に関する一連の裁判例

【免責】 本記事は、一般的な情報提供を目的として執筆した判例解説であり、具体的な事件についての法的アドバイスを提供するものではありません。個別の紛争・契約問題については、必ず弁護士・弁理士等の専門家にご相談ください。本記事の内容は執筆時点での情報に基づくものであり、将来の裁判例・法改正により内容が変動する可能性があります。

お問い合わせはこちらから｜虎ノ門法律特許事務所

弁護士 大熊 裕司

著作権、肖像権、パブリシティ権、プライバシー権について、トラブル解決のお手伝いを承っております。音楽・映画・動画・書籍・プログラムなど、様々な版権・著作物に精通した弁護士が担当しておりますのでお気軽にお問合せください。

LINEでのお問合せ

LINEでのご相談も承っております。（無料相談は行っておりません）

お電話でのお問合せ

電話対応時間 平日 午前9時～午後9時、土日祝 午前9時〜午後6時

メールでのお問合せ

費用

相談料

法律相談料は、１時間11,000円（税込）、のち30分ごとに5,500円（税込）です。