GitHub developer policy / Transparency Center の2026年4月16日時点の更新で押さえるべき結論は、GitHubが「コードを置く場所」から「著作権、仲介者責任、モデレーション、透明性をめぐる政策リスクに向き合う開発者インフラ」へと、さらに明確に立場を示したことです。
特に重要なのは、米最高裁の Cox v. Sony 判決を受けて、ユーザーの侵害行為を理由にプラットフォームやインターネットサービス提供者が自動的に責任を負うわけではない、という考え方が強調された点です。同時に、GitHubはDMCA、透明性レポート、年齢確認法制への懸念も取り上げており、オープンソースメンテナーは「ライセンスを整える」「削除要請に備える」「依存先をGitHubだけにしない」ことが実務上の対策になります。(The GitHub Blog)
GitHub developer policy / Transparency Center更新の要点
今回のGitHub developer policy更新は、単なる規約変更や広報ではありません。GitHub Blogでは、開発者保護、透明性、著作権政策への関与が「開発者がソフトウェアを作り、共有し、保守する方法に直接影響する」と説明されています。(The GitHub Blog)
主なポイントは次の4つです。
| 論点 | 何が更新・強調されたか | 開発者への意味 |
|---|---|---|
| 仲介者責任 | Cox v. Sony判決を踏まえ、サービス提供者がユーザーの侵害行為について自動的に責任を負うわけではない点を強調 | GitHubのようなコードホスティングが過剰削除に傾くリスクを抑える材料になる |
| 著作権・DMCA | DMCA Section 1201の次回見直しに向け、セキュリティ研究、相互運用性、修理、アクセシビリティなどへの影響を提示 | 研究用コード、解析ツール、互換実装を扱う開発者は政策動向を追う必要がある |
| Transparency Center | 2025年通年データを公開し、濫用関連の制限、異議申し立て、復旧に関する可視化を改善 | プラットフォームの信頼性を、発言だけでなくデータで確認しやすくなる |
| 年齢確認法制 | 米国各州、ブラジル、欧州の年齢確認関連法がOSSやパッケージマネージャーに波及する懸念を表明 | 消費者向けサービスだけでなく、開発基盤にも規制が及ぶ可能性を意識すべき |
この更新が示しているのは、主要コードプラットフォームの信頼性が「稼働率」や「機能数」だけでは測れなくなっているということです。今後は、削除要請への対応、異議申し立ての仕組み、透明性データの公開、政策形成への関与も、開発者がプラットフォームを選ぶ判断材料になります。
Cox v. Sony判決がオープンソースホスティングに与える意味
Cox v. Sonyは、インターネットサービス提供者がユーザーの著作権侵害についてどこまで責任を負うかが争われた米国の事件です。米最高裁は2026年3月25日、寄与侵害責任が成立するには、サービス提供者が侵害を意図したことが必要であり、その意図は「侵害を誘導した」または「侵害向けに作られたサービスだった」といった形で示される必要があると判断しました。単に侵害の可能性を知っていた、または対応が不十分だった、というだけでは足りないという整理です。(Legal Information Institute)
GitHubがこの判決を重視する理由は明確です。コードホスティングは、動画投稿サイトやSNS以上に「再利用」「フォーク」「依存関係」「パッケージ配布」が前提になります。ひとつのリポジトリが削除されると、そのコードを直接使っていない下流プロジェクト、CI/CD、パッケージ、ドキュメント、教育用途まで影響が広がることがあります。
仮に「プラットフォームが侵害の可能性を知っただけで責任を負う」という考え方が広がれば、GitHubのようなサービスは安全側に倒れて、正当な研究コードやフェアユースの可能性があるコードまで早めに削除する圧力を受けます。これは、オープンソースにとって非常に大きなリスクです。
ただし「GitHubなら削除されない」という意味ではない
Cox v. Sony判決は、OSSメンテナーにとって追い風ではありますが、万能の保護ではありません。
GitHubのDMCA Takedown Policyでは、権利者が有効な削除通知を出した場合、GitHubは通知の要件を確認し、対象ユーザーに変更機会を与えたり、必要に応じてリポジトリやパッケージを無効化したりします。部分的な侵害であれば、ユーザーにおおむね1営業日程度の修正機会を与える運用も説明されています。(GitHub Docs)
つまり、開発者側に必要なのは「判決で守られるはず」と考えることではなく、問題が起きたときに短時間で説明・修正・異議申し立てできる状態を作っておくことです。
DMCA Section 1201はセキュリティ研究と相互運用性に直結する
今回の更新で見落としやすいのが、DMCA Section 1201の次回見直しへの言及です。Section 1201は、著作物へのアクセスを制御する技術的保護手段の回避を制限する米国著作権法上の規定です。米国著作権局は2024年の3年ごとの見直しで、一定の非侵害利用に悪影響がある場合、限定的かつ一時的な例外を採用できる仕組みを説明しています。(著作権局)
GitHubは、Section 1201がセキュリティ研究、相互運用性、修理、アクセシビリティ、AIシステムの検証、モデル調査などに影響し得ると位置づけています。2024年サイクルでは生成AIの安全性研究に関する請願もありましたが、最終的には採用されなかったとGitHubは説明しています。(The GitHub Blog)
これは、開発者にとってかなり実務的な論点です。たとえば次のようなコードやドキュメントを公開する場合、単に「研究目的です」と書くだけでは不十分になり得ます。
| 公開物の例 | 注意すべき点 | 実務上の対策 |
|---|---|---|
| セキュリティ検証ツール | アクセス制御回避や脆弱性再現コードと見なされる可能性 | 研究目的、対象範囲、悪用防止策、検証環境をREADMEに明記する |
| 互換実装・エミュレーター | 相互運用性か、回避技術かの境界が問題になりやすい | 著作物そのものを含めず、仕様・互換性・合法利用の説明を分ける |
| AIモデル解析ツール | モデル検査や安全性研究の扱いが政策上まだ流動的 | 学術・安全性目的、利用条件、制限事項、出力例の扱いを整理する |
| 修理・アクセシビリティ支援ツール | 正当な利用でも技術的保護手段との関係が問題になる場合がある | どの利用者のどの問題を解決するのかを具体的に記録する |
ここで重要なのは、GitHubのポリシー更新が「法制度の変化を待つだけではなく、開発者側の声を政策形成に反映させる必要がある」と示している点です。とくにOSSメンテナー、セキュリティ研究者、開発者アドボケイトは、2027年の見直しに向けて、実際に困っているユースケースを言語化しておく価値があります。
Transparency Centerの2025年データが示すモデレーション圧力
GitHubは今回、Transparency Centerに2025年通年データを追加し、濫用関連の制限、異議申し立て、復旧に関するチャートや可視化を改善したと説明しています。(The GitHub Blog)
特に注目すべきは、DMCAの「circumvention claims」、つまり技術的保護手段の回避に関する申し立てです。GitHubの透明性データでは、DMCA circumvention claimsが2025年に645件となり、2024年の456件を上回っています。GitHub自身も、2025年は透明性レポート開始以来もっとも多かったと説明しています。(GitHub)
さらにDMCA関連データを見ると、2025年下半期はDMCAに関連する「projects taken down」が29,267件、「takedown notices processed」が1,354件と記録されています。これは、著作権対応が単発の法務問題ではなく、プラットフォーム運用上の継続的な負荷になっていることを示します。(GitHub)
モデレーション圧力は著作権だけではない
今回の更新では、著作権以外の規制圧力にも触れています。GitHubは、米国各州、ブラジル、欧州で出てきている年齢確認法制について、商用・消費者向けサービスを対象にした要件が、意図せずOSSのオペレーティングシステム、パッケージマネージャー、重要なデジタルインフラに及ぶ可能性への懸念を示しています。(The GitHub Blog)
これは、開発者にとって「自分はSNSや動画サービスを運営していないから関係ない」とは言い切れない話です。パッケージマネージャー、プラグイン配布、CIテンプレート、AIツール、教育用OSSなどは、国や地域によって規制上の見え方が変わる可能性があります。
主要コードプラットフォームで「開発者の信頼」は何で決まるのか
今回のGitHub developer policy / Transparency Center更新から読み取れる最大のシグナルは、開発者の信頼が「便利な機能」だけではなく「不利な場面でどう扱われるか」で決まるということです。
GitHubは、モデレーション判断に対する異議申し立てと復旧の仕組みを用意しており、ユーザーはコンテンツやアカウントの制限に対して、一定期間内にAppealやReinstatementを申請できます。GitHub Docsでは、異議申し立ての判断は人間が行うこと、十分な根拠がある場合は判断の変更や措置の軽減があり得ることも説明されています。(GitHub Docs)
開発者がプラットフォームを評価するときは、次の観点を確認すると実務的です。
| 評価項目 | 見るべきポイント | なぜ重要か |
|---|---|---|
| 削除要請の透明性 | DMCA通知や政府要請を公開・集計しているか | 不透明な削除は、OSSの継続性を損なう |
| 異議申し立て | 申請窓口、期限、人間によるレビューがあるか | 誤検知や過剰対応から復旧できるかを左右する |
| 最小限の制限 | リポジトリ全体ではなく、問題箇所に絞る姿勢があるか | 下流プロジェクトへの影響を抑えられる |
| データの継続公開 | 年次・半期で比較できるデータがあるか | プラットフォームの方針変化を検知しやすい |
| 政策関与 | 著作権、年齢確認、AI規制などに意見を出しているか | 開発者の実態が政策に反映されやすくなる |
GitHubに限らず、主要コードプラットフォームは今後、法務・信頼・安全性・透明性を含めた「開発者インフラ」として比較されるようになります。大規模OSSや企業利用では、料金や機能だけでなく、ポリシー対応の成熟度も選定基準に入れるべきです。
OSSメンテナーが今すぐ確認すべき実務チェックリスト
今回の更新を受けて、OSSメンテナーが最初にやるべきことは大きく3つです。ライセンスを整え、削除要請に備え、単一プラットフォーム依存を下げることです。
ライセンスと由来を明確にする
リポジトリにLICENSEファイルを置くだけでは不十分です。第三者コード、生成物、サンプルデータ、画像、音声、モデル、バイナリを含む場合は、それぞれの由来と利用条件を分けて記録しましょう。
最低限、次を確認してください。
| 対象 | 確認内容 |
|---|---|
| ソースコード | 自作、外部ライブラリ、フォーク元、引用元を区別できるか |
| 依存パッケージ | ライセンスがプロジェクトの配布条件と矛盾しないか |
| サンプルデータ | 実在サービスや権利物のコピーを含んでいないか |
| 画像・音声・動画 | READMEやテスト用素材に無断利用がないか |
| AI関連ファイル | モデル、重み、学習データ、出力例の権利関係を説明できるか |
特に、企業の内部コードを誤って含めた場合や、商用SDKのサンプルをそのまま流用した場合は、DMCA通知の対象になりやすくなります。公開前にgit logや過去コミットも含めて確認することが重要です。
DMCA通知を受けたときの対応手順を決めておく
DMCA通知は、受け取ってから考えると時間が足りません。GitHubのDMCA Takedown Policyでは、部分的な侵害と判断される場合、ユーザーに短い修正機会が与えられることがありますが、対応が遅れればリポジトリが無効化される可能性があります。(GitHub Docs)
メンテナーは、次のような手順を事前に決めておくと安全です。
| タイミング | やること |
|---|---|
| 通知を受けた直後 | 通知対象のURL、ファイル、コミット、権利主張の内容を保存する |
| 1時間以内 | 対象ファイルが本当に含まれているか、ライセンスや許諾の根拠があるか確認する |
| 修正可能な場合 | 該当部分を削除・差し替えし、GitHubに変更完了を連絡する |
| 誤りだと考える場合 | 許諾、独自実装、フェアユース、誤認などの根拠を整理する |
| 無効化された場合 | カウンター通知やAppealの可否を確認し、必要なら専門家に相談する |
権利者側の立場でも同じです。GitHubのDMCAポリシーでは、通知前に著作権の保有、無許可利用かどうか、フェアユースの可能性を調査することが求められています。誤った通知は開発者の作業を止めるだけでなく、権利者側の信頼も損ないます。(GitHub Docs)
連絡先と復旧ルートを属人化しない
多くのOSSプロジェクトでは、GitHub通知を受け取るメールアドレスが古い、メンテナーが1人しかいない、Organizationの権限が整理されていない、といった問題が起きがちです。削除要請やアカウント制限は、技術的な障害よりも復旧に時間がかかる場合があります。
次を確認しておきましょう。
| 項目 | 推奨対応 |
|---|---|
| Organization管理者 | 最低2人以上にし、退職者・休眠アカウントを整理する |
| 通知メール | メンテナー共有のメールまたは転送設定を使う |
| リリース資産 | GitHub Releasesだけでなく、ハッシュ値や署名も公開する |
| ドキュメント | 依存先、ライセンス、削除要請時の連絡先を明記する |
| バックアップ | Gitのミラー、パッケージの再公開手順、CI設定の控えを持つ |
「GitHubが止まる」ことだけがリスクではありません。アカウント制限、特定地域での表示制限、パッケージ無効化、法的要請による一部削除など、部分的な可用性低下にも備える必要があります。
クリエイター、法務担当、開発者アドボケイトが見るべき論点
今回の更新は、OSSメンテナーだけでなく、クリエイター、企業法務、開発者アドボケイトにも関係します。
クリエイターは「削除」だけでなく「正確な申し立て」を意識する
権利侵害への対応は重要です。ただし、コードの世界では、フォーク、引用、学習目的、互換実装、ライセンス許諾、フェアユースの可能性が絡みます。GitHubはフォークを親リポジトリと自動的に同一視せず、フォークが大きく変更されていたり、別の利用条件にある可能性を考慮する方針を説明しています。(GitHub Docs)
そのため、権利者側は「似ているコードがある」だけで広範囲に通知するのではなく、対象ファイル、該当箇所、権利の根拠、許諾関係の確認結果を絞って示すことが重要です。過剰な通知は、正当な開発活動まで止める可能性があります。
企業法務は「プラットフォーム任せ」を避ける
企業がGitHub上でOSSを公開する場合、法務部門は削除要請対応をGitHub任せにしない方がよいです。社内で次の判断基準を持っておくと、対応が速くなります。
| 判断対象 | 社内で決めておくこと |
|---|---|
| 自社コード流出 | DMCA、機密情報削除、商標、セキュリティ報告のどれを使うか |
| OSSライセンス違反 | まず修正依頼をするのか、法的通知に進むのか |
| 自社OSSへの通知 | 誰が技術確認し、誰が法務判断し、誰がGitHubへ返信するか |
| 国・地域別の規制 | 米国DMCA以外の法制度が関係する場合の相談先 |
| AI・セキュリティ研究 | 公開可能範囲、悪用防止策、研究者対応方針 |
開発者アドボケイトは政策へのフィードバックを集める
GitHubが2027年のDMCA Section 1201見直しに向けて開発者からの意見に関心を示している点は重要です。開発者アドボケイトやOSS財団は、「困っている」という抽象論ではなく、具体的なユースケースを集めるべきです。(The GitHub Blog)
たとえば、次のような形で整理すると政策議論に使いやすくなります。
| 収集すべき情報 | 例 |
|---|---|
| 何をしたいのか | 脆弱性検証、相互運用性テスト、アクセシビリティ改善、修理支援 |
| 何が障害か | アクセス制御、利用規約、DMCAリスク、削除要請リスク |
| 誰が影響を受けるか | 研究者、教育機関、OSS利用企業、障害のある利用者、保守担当者 |
| 代替手段はあるか | 公式API、テスト環境、許諾プログラム、サンドボックス |
| 公益性は何か | セキュリティ向上、相互運用性、利用者保護、長期保守 |
政策は、実例がなければ「濫用防止」や「消費者保護」の名目で広く設計されがちです。開発者側が技術的な現実を説明することが、過剰規制を避ける材料になります。
よくある誤解と失敗しやすいポイント
DMCAは何でも削除できる万能窓口ではない
GitHubのDMCAプロセスは、著作権侵害に関する手続きです。商標、機密情報、個人情報、セキュリティ問題などは別のプロセスが用意されています。GitHub Docsでも、DMCAプロセスは著作権侵害の苦情に使うものであり、商標侵害やセンシティブデータの苦情には別手続きがあると説明されています。(GitHub Docs)
削除したい理由が「ブランドに似ている」「秘密情報が含まれている」「危険なコードに見える」場合、DMCAではなく、該当するポリシーやサポート窓口を確認してください。
「AI生成コードだから著作権問題はない」と考える
AI生成コードであっても、依存ライブラリ、学習元、出力結果、同梱データ、プロンプト例、モデルファイルなどに権利問題が絡む可能性があります。とくに生成AIセキュリティ研究やモデル検査は、GitHubがSection 1201の今後の課題として挙げている領域です。(The GitHub Blog)
AI関連リポジトリでは、モデルの出所、ライセンス、禁止用途、サンプルデータの権利、生成物の扱いをREADMEに明記しましょう。
フォークをすべて同じリスクとして扱う
フォークは親リポジトリのコピーですが、時間が経つと内容、ライセンス、利用目的が変わる場合があります。GitHubは、親リポジトリを無効化するときにフォークを自動的に無効化するわけではないと説明しています。(GitHub Docs)
権利者側は、フォークも侵害していると主張するなら、実際に対象フォークを確認する必要があります。メンテナー側は、自分のフォークが独自変更済みであること、問題箇所を削除済みであることを説明できるようにしておくとよいでしょう。
異議申し立ての根拠を感情的に書く
制限や削除に納得できない場合でも、「不当だ」「OSSへの攻撃だ」とだけ書いても効果は限定的です。GitHubのAppealでは、判断が誤りだった、コンテンツが違法でも規約違反でもない、または措置が重すぎたと判断できる根拠が重要になります。(GitHub Docs)
異議申し立てでは、次の順で整理すると伝わりやすくなります。
| 書く内容 | 具体例 |
|---|---|
| 対象 | リポジトリ名、URL、制限されたファイル、通知日時 |
| 事実 | そのコードの作成者、ライセンス、変更履歴、第三者コードの有無 |
| 根拠 | 許諾、独自実装、削除済み、誤認、対象外である理由 |
| 希望する措置 | リポジトリ復旧、一部ファイルのみ削除、アカウント制限の解除 |
| 再発防止 | LICENSE追記、該当ファイル削除、メンテナー体制変更 |
GitHubの更新から見える今後のコードプラットフォーム像
GitHub developer policy / Transparency Centerの更新は、今後の主要コードプラットフォームに3つの方向性を示しています。
ひとつ目は、オープンソースホスティングが法的・政策的な防波堤を必要とするインフラになったことです。GitHubのような中立的なホスティング基盤が成り立つには、ユーザー生成コンテンツに対する責任範囲が過度に広がりすぎないことが重要です。
二つ目は、モデレーション圧力が増え続けることです。DMCA、技術的保護手段、AI安全性、年齢確認、政府要請、濫用対策は、すべてコードプラットフォームに流れ込んできます。開発者は「自分のコードが合法か」だけでなく、「プラットフォームがどう判断し、どう可視化し、どう異議申し立てを受けるか」も見る必要があります。
三つ目は、開発者の信頼が透明性データと復旧手段で決まることです。削除がゼロのプラットフォームは現実的ではありません。重要なのは、削除や制限が起きたときに、理由が説明され、データが公開され、誤りを正す手段があるかどうかです。
OSSメンテナーが今すぐ取るべき行動は明確です。リポジトリのLICENSEと第三者素材を確認し、DMCA通知を受けた場合の対応手順を決め、Organizationの連絡先と権限を見直してください。セキュリティ研究、AI解析、互換実装、修理支援のような境界領域を扱う場合は、READMEに目的・制限・正当性を具体的に書くことも重要です。
GitHubの今回の更新は、開発者に不安を与えるためのものではありません。むしろ、オープンソースを支えるには、コードだけでなく、ポリシー、透明性、異議申し立て、法制度への参加まで含めて運用する必要があるという現実を示しています。主要コードプラットフォームを使う開発者ほど、この変化を早めに自分のプロジェクト運営へ組み込むべきです。
コメント