---
title: "似てるコードは著作権侵害？ 見るべきは「依拠」と「創作的な表現」の 2 本の線"
description: "AI に書かせたコードが、あとで見つけたライブラリとそっくりだった。それだけでアウト？ そうとは限りません。日本の著作権法が守るのは「創作的に表現したもの」で、そこに最高裁が「元の著作物に依拠したか」を足しています。2 本の線を条文と判例で確かめ、実務ではライセンスを先に読む、に着地します。"
url: https://ryuuneko.com/blog/similar-code-copyright
published: 2026-09-12 20:46:41.92526
updated: 2026-09-12 20:47:36.757366
---

AI に書かせた 4 行の処理が、あとで見つけたライブラリとそっくりだった。変数名が違うだけで、処理の順序も分岐の置き方も同じ。これ、アウト？

先に答えを言うと、**似ているというだけでは何も決まりません**。日本の著作権法が守るのは「創作的に表現したもの」で（出典 4）、そこに最高裁が「元の著作物に依拠したか」という線を足しています（出典 6）。見る場所は「似ているか」ではなく、この 2 本の線です。

そのうえで、実務で実際に引っかかるのは著作権そのものより、組み込んだライブラリのライセンス条件のほうだ、というのが出してきた側の実感です。

この記事は、個人開発でよく踏む場面を、架空のコードとライブラリ名で再現したものです。条文と判例は末尾に挙げた一次情報に当たって書いています。この記事は日本の著作権法の話で、使っているライブラリが海外のものなら、また別に見ることになります。

---

## そっくりなコードが 2 つ

```js
// 自分のコード（AI の出力）
const rows = text.split(sep).map((r) => r.replace(mark, dash));
if (!rows.length) return text;
return rows.join(sep);

// ライブラリ bullet-tidy（MIT）
const lines = text.split(sep).map((l) => l.replace(mark, dash));
if (!lines.length) return text;
return lines.join(sep);
```

名前が違うだけ。これを見て「アウトかも」と思うのは自然です。でも、見る場所はそこではありませんでした。

---

## なぜ「書き方」だけが守られるのか

昔、プログラムは機械の附属物のような扱いで、著作権で守られるかもはっきりしていませんでした（出典 2）。作るのは大変なのにコピーは一瞬で、無断コピーの係争が増えた（出典 3）。そこで著作権法に、プログラムは著作物だと明記された。同時に、プログラム言語・規約・解法には保護が及ばない、という線も引かれています（出典 4、第 10 条第 3 項）。

条文を作った側は最初から「表現の前提となるアイデアやアルゴリズムは保護しない」と説明していました（出典 1）。つまり「同じやり方」というだけでは、最初から何も決まらないように作ってあるわけです。

![著作権侵害を見る 2 本の線。1 本目は元のコードに依拠したか、2 本目は創作的な表現が残っているか。似ているかどうかはどちらにも入っていない、という図](/blog/uploads/similar-code-copyright-two-lines.svg)

---

## 1 本目の線: 元のコードを、もとにしたか

これは条文ではなく判例のほうです。最高裁は、著作物の複製とは既存の著作物に依拠してその内容と形式を覚知させるに足りるものを再製することだ、とし、依拠していないなら複製にあたらない、と判断しました（出典 6）。

つまり、元を見ないで自分で書いたなら、たまたま似ても複製にはあたらない。これがクリーンルームという実務上の方法が効く理由です。ただしクリーンルームは法律で決められた手順ではなく、依拠していないことを説明しやすくするための方法のひとつです。一度見てしまうと、もとにしていないと説明するのが難しくなる。これは依拠の有無そのものではなく、説明の難しさの話です。

### AI が書いたコードは？

「自分は元のコードを見ていない。書いたのは AI」という場合、AI が出したから安全、とは言い切れません。学習データに元のコードが入っていた場合に依拠と扱われるのか、という論点があり、文化庁は生成 AI と著作権に関する判例・裁判例の蓄積が無い現状を踏まえて考え方を整理した、と明記しています（出典 8）。これは考え方であって、条文でも判例でもない。

1 本目は、AI が関わると「まだ誰にも分からない」になります。だから、決められる 2 本目のほうが大事です。

---

## 2 本目の線: 創作的な表現が残っているか

| これは | 著作権で |
|---|---|
| 創作性のある具体的な書き方 | 守られ得る |
| アルゴリズム・解法・処理のやり方 | 原則 守られない（第 10 条第 3 項） |
| 短い・書き方が 1 通りしかない処理 | 創作性が認めにくく 守られにくい |

条文にあるのは「言語・規約・解法」の 3 つで、「アイデア」という語は条文に無く、そこから読まれた話です。境界はグレーです。

冒頭の 4 行は「行ごとに置き換えて、つないで、空なら元を返す」という処理で、書き方も他にあまり無い。創作性は認めにくく、守られにくい側です。実際、同じ形のライブラリがもう 1 つ見つかりました。

```js
// 別のライブラリ（Apache-2.0・架空の例）
const ls = src.split(nl).map((x) => x.replace(tail, empty));
return ls.length ? ls.join(nl).replace(many, two) : src;
```

似たものが 2 つも 3 つも出てくるほど、それはやり方（定石）のほうだと分かる。定石は守られない側です。

ただし、その人らしさが出ている書き方を、まとまって持ってくると別です。どのくらいの量からかは基準が無く、ここもグレー。

### 書き換えれば別物になる？

なりません。名前を変えても、元の組み立てが残ることはある。作り変えるのも作者の権利で、翻案といいます（出典 4、第 27 条）。どこからが翻案かは条文に無く、判例は「表現上の本質的な特徴を直接感得できるか」という枠組みで見ています（出典 7）。書き換えればセーフ、は間違いで、ここも判例の枠組みで判断されるグレーです。

なお、2 本の線がそろっても、それだけで侵害が確定するわけではありません。依拠と表現の残存は必要条件で、そろって初めて中身を見る話が始まります。

---

## 実務では、ライセンスのほうが先に効く

グレーばかりなので、着地はライセンスを読むことになります。

![他人のコードとの付き合い方 3 つ。写す・呼ぶ・似せて書く。普段いちばん多いのは「呼ぶ」で、悩む場所が「似てるか」から「条件を守ったか」に移る、という図](/blog/uploads/similar-code-copyright-three-ways.svg)

| やり方 | 著作権 | 普段どうする |
|---|---|---|
| 写す | 元をもとにしている。表現が残れば複製 | やらない。呼べるなら呼ぶ |
| 呼ぶ（ライブラリとして入れる） | LICENSE があれば、許可はそこに書いてある | 条件（表示など）を守る |
| 似せて書く | やり方だけなら守られない。表現が残ればグレー | 定石なら気にしない。長い塊は避ける |

出してきた側の実感として、この 4 行が似ていて揉めたことは無く、写すより呼ぶことのほうがずっと多い。効いてくるのは条件のほうです。

```js
import { alignBullets } from "bullet-tidy";  // MIT
export const tidy = (text) => alignBullets(text);
```

似せて書き直すより、そのライブラリを呼んで使う。LICENSE があれば、許可はそこに書いてある。MIT なら著作権表示と許諾文を残す（THIRD_PARTY_NOTICES.md に）。似ているかどうかは確かめようが無かったのに対し、条件を守ったかは確かめられる。**悩む場所が「似てるか」から「条件を守ったか」に移ります**。消えるわけではありません。呼んでも条件を守る仕事は残るし、LICENSE が無ければそもそも確かめられない。LICENSE が無いライブラリの話は [GitHub のコードは勝手に使っていい？](/blog/github-code-license-can-i-use) で。

もう 1 つ。出典を書けば使える、にはなりません。それは礼儀で、許可とは別です。

---

## まとめ

- 似ているコードは、それだけでは著作権侵害と決まらない。見るのは「元に依拠したか」と「創作的な表現が残っているか」の 2 本の線
- アルゴリズムや解法、短い定石は原則守られない。その人らしさのある書き方をまとまって持ってくると別で、境界はグレー
- 書き換えれば別物、ではない。翻案という権利があり、どこからかは判例の枠組みで見る
- AI が書いたコードの依拠性は、裁判例の蓄積が無く、まだ分からない
- 実務で先に効くのはライセンスの条件。写すより呼ぶ。LICENSE があれば許可はそこに書いてあり、確かめられる側に寄せられる

判断は「似ているか」を眺めていても出ません。確かめられるほう、つまりライセンスから固めるのが、作った人の側でできることです。

※ この記事は日本の著作権法と、2026 年 8 月時点の文化庁の公表資料をもとにしています。判例はその事件についての判断で、いつでも同じ結論になるわけではありません。個別の事案は専門家に相談してください。

## 動画版

同じ題材を、YouTube「黒猫開発部」では 2 人の会話で扱っています。動画はそっくりなコードを前にして 2 本の線に気づくまで、この記事は条文と判例を文章で確かめる向けです。

- 黒猫開発部 No.006「似てるコード＝アウト、ではない」（2026-10-02 公開予定）
- [チャンネル: 黒猫開発部](https://www.youtube.com/@黒猫開発部)

## 出典

1. [国会会議録 — 参議院文教委員会 昭和 60 年 6 月 6 日](https://kokkai.ndl.go.jp/txt/110215077X01119850606/87) — 政府委員答弁「表現の前提となっておりますアイデアとかアルゴリズム、そういった原理につきましては保護をしない」「プログラム言語、規約、解法は当然にこの保護の対象にはならない、そういう趣旨を明確にしたのが十条三項の規定でございます」
2. [国会会議録 — 参議院文教委員会 昭和 60 年 5 月 30 日](https://kokkai.ndl.go.jp/txt/110215077X00919850530/5) — 文部大臣提案理由「従来における機器の附属物として扱われる傾向から、機器から分離独立した高い価値を持った創作物として扱われるようになってきております。」
3. [著作権審議会 第 6 小委員会（コンピュータ・ソフトウェア関係）中間報告](https://www.cric.or.jp/db/report/s59_1/s59_1_main.html)（著作権情報センター収録） — 「プログラムを開発するためには、多額の資金と多くの人間の長期にわたる努力が必要であるのに対し、そのコピーは簡単にできるため、…ソフトウェアに関する係争事件が増大している。」
4. [e-Gov 法令検索 — 著作権法](https://laws.e-gov.go.jp/law/345AC0000000048) — 第 2 条第 1 項第 1 号「思想又は感情を創作的に表現したもの」／第 10 条第 1 項第 9 号「プログラムの著作物」／第 10 条第 3 項「その著作物を作成するために用いるプログラム言語、規約及び解法に及ばない」／第 27 条「翻訳し、編曲し、若しくは変形し、又は脚色し、映画化し、その他翻案する権利を専有する」
5. [日本法令外国語訳データベース — 著作権法](https://www.japaneselawtranslation.go.jp/ja/laws/view/4207) — 同条文の日英対訳
6. [最高裁 昭和 53 年 9 月 7 日判決 民集 32 巻 6 号 1145 頁（ワン・レイニー・ナイト・イン・トーキョー事件）](https://www.courts.go.jp/app/hanrei_jp/detail2?id=54015) — 「著作物の複製とは、既存の著作物に依拠し、その内容及び形式を覚知させるに足りるものを再製することをいう」
7. [最高裁 平成 13 年 6 月 28 日判決 民集 55 巻 4 号 837 頁（江差追分事件）](https://www.courts.go.jp/app/hanrei_jp/detail2?id=52350) — 翻案とは「既存の著作物に依拠し、かつ、その表現上の本質的な特徴の同一性を維持しつつ、…これに接する者が既存の著作物の表現上の本質的な特徴を直接感得することのできる別の著作物を創作する行為」
8. [文化庁 — AI と著作権について](https://www.bunka.go.jp/seisaku/chosakuken/aiandcopyright.html) — 「生成AIと著作権の関係に関する判例及び裁判例の蓄積がないという現状を踏まえて、生成AIと著作権に関する考え方を整理し」（「AI と著作権に関する考え方について」令和 6 年 3 月 15 日）