ソフトウェア（プログラム）の場合も同じですが、その性質上、少し具体的に考える必要があります。
1. 著作権法上の基本原則
日本の著作権法では、
「思想又は感情を創作的に表現したもの」
が著作物とされています（著作権法2条1項1号）。
プログラムも「プログラムの著作物」として保護対象です（同法10条1項9号）。
ここで重要なのが「創作的に表現したもの」という点です。
2. ソフトウェアにおける「創作性」とは？
ソフトウェアの創作性とは、
プログラムの具体的な表現方法に、作者の個性が表れていることです。
具体的には：
✅ 創作性が認められやすい部分
-
アルゴリズムの具体的な実装方法
-
処理手順の構成の仕方
-
モジュール分割の方法
-
変数名や関数構造の設計
-
命令の並び方
-
ソースコードの具体的記述
同じ機能を実現するにも、書き方は無数にあります。
その「選択の幅」がある部分に個性が出れば創作性が認められます。
❌ 創作性が認められない部分
一方で、次のようなものは保護されません。
-
アイデアそのもの
-
アルゴリズムの抽象的な考え方
-
数学的理論
-
単なる事実やデータ
-
仕様に従う以外に書きようがない表現
-
ごく短い・ありふれたコード
これは著作権法の「アイデアと表現の二分論」によるものです。
3. 重要なポイント：機能は保護されない
著作権法は、
「機能」や「動作」そのものは保護しない
「その具体的な表現」だけを保護する
という立場です。
例えば：
-
✖「この計算ロジックを使うこと」→保護されない
-
〇「そのロジックを特定のコードで書いた表現」→保護される
4. 創作性が否定される典型例
裁判例では、次のような場合に創作性が否定されています。
-
他に書きようがない場合（表現の選択肢がない）
-
極めて単純なコード
-
マニュアル通りに機械的に記述しただけのもの
これを「表現の不可避性（マージ理論）」と呼びます。
機能と表現がほぼ一体化している場合は保護が弱くなります。
5. まとめ
ソフトウェアの創作性とは：
機能を実現するための具体的なコード表現に、作者の個性が現れていること
であり、
-
アイデアは保護されない
-
表現が保護される
-
選択の幅がある部分に創作性が宿る
というのが基本構造です。
では、もう少し発展させて考えてみましょう。
-
「APIの著作権はどうなるのか？」
-
「生成AIが書いたコードに創作性はあるか？」
-
「リファクタリングで創作性は変わるか？
① APIの著作権はどうなるか？
■ 結論（日本法の一般的理解）
-
APIの「アイデア・機能・仕様」そのものは保護されない
-
しかし 具体的な記述方法（ソースコードや詳細な表現）には著作権が及ぶ可能性がある
1. APIとは何か？
APIは基本的に：
-
関数名
-
引数
-
戻り値
-
呼び出し規約
-
構造定義
などの「インターフェース仕様」です。
これは本質的に「機能の設計図」です。
2. 問題になるポイント
● 関数名や構造名に創作性はあるか？
通常は
-
print() -
open() -
getUserName()
のような名称は
ありふれた機能的名称であり創作性は弱いと考えられます。
● API全体の体系に創作性はあるか？
ここが難しい点です。
-
パッケージ構成
-
階層構造
-
クラス設計
-
分類方法
などに設計上の個性が表れている場合、著作物性が認められる余地があります。
3. 有名な海外事例
Google v. Oracle（米国）
Java APIの再利用が争われました。
米最高裁は最終的に「フェアユース」と判断しましたが、
APIの著作物性については完全に否定していません。
4. 日本法での考え方
日本では一般に：
-
機能的・必然的な部分 → 保護されにくい
-
設計思想が反映された体系的構成 → 保護され得る
と整理されます。
② 生成AIが書いたコードに創作性はあるか？
これは現在最もホットな論点です。
1. 日本法の大原則
著作物とは
「思想又は感情を創作的に表現したもの」
です。
ここから導かれる重要な前提：
👉 創作者は「人」である必要がある
2. 完全自動生成の場合
人間が創作的関与をしていない場合：
-
AI単独生成物 → 著作物性は否定される可能性が高い
文化庁の整理もこの方向です。
3. 人が関与した場合
次のような場合は著作物性が認められ得ます：
-
詳細なプロンプト設計
-
生成結果の選択・修正
-
大幅な編集
つまり、
AIは「道具」に過ぎず、最終的な創作的判断を人が行ったか
がポイントです。
4. 実務的な整理
| 状況 | 著作物性 |
|---|---|
| ボタン一発で自動生成 | 否定的 |
| 人が細かく設計・編集 | 肯定され得る |
| 出力をそのまま利用 | グレー |
③ リファクタリングで創作性は変わるか？
これは非常に面白い論点です。
1. リファクタリングとは？
-
機能を変えず
-
内部構造を改善する
行為です。
2. 創作性はどう評価されるか？
● 単なる機械的変換
-
変数名変更
-
自動整形
-
IDEによる変換
→ 創作性はほぼ増えない
● 設計思想を変えるレベルの変更
-
アーキテクチャ変更
-
モジュール分割の再設計
-
抽象化の導入
-
デザインパターン適用
→ 新たな創作性が加わる可能性あり
3. 二次的著作物の問題
大幅な改変をすれば：
-
原著作物を基礎とする
-
しかし新たな創作性も加わる
→ 「二次的著作物」になる可能性があります
ただし：
👉 原著作権者の許諾が必要
④ ソフトウェア創作性の核心
ソフトウェアの創作性は結局：
「設計上の選択の幅」がどれだけあるか
に帰着します。
選択の余地が広い部分には創作性が生まれやすく、
必然的な部分には生まれにくい。
まとめ（全体像）
| 論点 | 結論の方向性 |
|---|---|
| API | 機能は保護されないが構造に創作性があれば保護可能 |
| 生成AI | 人の創作的関与があれば保護可能 |
| リファクタリング | 実質的設計変更なら創作性が加わる可能性 |
