CodebergはAI生成コード主体の共有を、賛成358票で利用規約上禁止しました。
- 要点1: 反対144票、棄権14票で規約改定案が可決
- 要点2: AI支援開発のすべてではなく、生成コード主体のプロジェクトが対象
- 要点3: 一斉削除や全リポジトリの自動スキャンは予定していない
対象: AI開発のルールを整備する経営者、DX推進担当者、開発責任者
今日やること: AI生成コードの申告、レビュー、保守責任を社内規定で確認する
この記事の目次
非営利のソフトウェア開発基盤Codebergは、生成AIが書いたコードを主体とするプロジェクトの共有を利用規約で禁止しました。ただし、AI支援を使った開発の全面禁止ではありません。
今回の決定が企業に突きつけるのは、特定ツールの利用可否よりも、生成物を誰が検証し、保守し、責任を持つかという問題です。この記事では、Codebergの公式声明と規約差分をもとに、決定の範囲と企業が整備すべきAIコードガバナンスを解説します。
Codebergが決めた2つのAI方針
Codeberg e.V.は年次総会で、大規模言語モデル（LLM）に関する2つの提案を会員投票にかけました。LLMとは、ClaudeやOpenAIのモデルのように、大量のデータから文章やコードを生成するAIの基盤技術です。14日間の投票期間が終了し、両方の提案が可決されました。
利用者のデータをAI学習に使わない
第1の方針は、Codebergと関連サービスが、利用者やプロジェクトのコード、データを生成AIの学習に使わないというものです。
Codebergは従来から、プライバシーポリシーで「利用者のデータを必要としない運営」を掲げていました。今回の投票により、生成AIの学習利用についても立場を明文化しました。
AI生成コード主体のプロジェクト共有を禁止する
第2の方針は、利用規約に禁止条項を追加するものです。公式の規約差分では、ClaudeやOpenAI Codexを含む生成AIツールが書いたコードを主な構成要素とするプロジェクトを共有してはならないと定めています。
投票結果は次の通りです。
| 項目 | 結果 |
|---|---|
| 賛成 | 358票 |
| 反対 | 144票 |
| 棄権 | 14票 |
| 投票率 | アクティブ会員の約50% |
規約は、対象プロジェクトについて著作権の状態が不明確になりやすく、有害なコードを含まないことを保証する仕組みも不足すると説明しています。違反時はコンテンツの削除と警告、反復時はアカウント停止の可能性があります。
禁止対象はAI支援開発のすべてではない
今回の規約変更を「CodebergがAIコーディングを全面禁止した」と理解するのは正確ではありません。Codebergの公式声明は、影響を受けにくい例と、歓迎されない可能性が高い例を分けています。
影響を受けにくいプロジェクト
Codebergは、次のプロジェクトは影響を受けにくいと説明しています。
- 利用者や保守担当者から成る活発なコミュニティがある
- LLMが普及する前から十分な開発履歴がある
- AI生成の貢献を一部受け入れていても、開発全体でLLMを多用していない
小規模なサイドプロジェクトや実験、リソース消費の少ないカスタムスクリプトも、実務上は容認される可能性があるとしています。AIを使ったという一点だけで、直ちに違反と判定する運用ではありません。
歓迎されない可能性が高いプロジェクト
一方、次の利用は規約の対象になりやすいと説明されています。
- AIエージェントが自律的に作成したプロジェクト
- LLMを多用して作成し、保守しているプロジェクト
- 関係者の人数に比べ、ストレージやCI/CDの消費が大きいプロジェクト
- LLMの利用を容易にするなど、AIエコシステムに強く結びつくプロジェクト
- 個別プロジェクトの方針に反してAI生成の貢献を送る利用者
Codebergは既存リポジトリを一斉削除せず、全コンテンツを自動スキャンする予定もないと明記しました。明白でない事例は、個別の状況を見て判断されます。
＼ Claude Codeの導入、何から始めればいいかわかります ／
法人様のAI導入に関するご相談はこちらCodebergが挙げた4つの理由
Codebergの決定は、生成AIへの思想的な賛否だけで説明できません。公式声明は、運営コスト、コード品質、著作権、コミュニティの信頼を一つの問題として扱っています。
1. 著作権とコード安全性を確認しにくい
生成AIの出力は、学習元との関係やライセンスの扱いが利用者から見えにくい場合があります。生成されたコードが既存コードと類似していても、開発者が出所を説明できない可能性があります。
安全性にも同じ問題があります。コードが動くことと、脆弱性や危険な処理を含まないことは別です。生成結果を理解できる担当者がいなければ、レビューは形式だけになります。
2. AIクローラーがサーバー負荷を増やす
Codebergによると、AI学習を目的とするクローラーは、ファイルだけでなく、課題管理の絞り込み画面やGit履歴の各時点まで大量に取得します。その結果、負荷の高いデータベース処理が発生し、サービス品質と運用担当者の作業時間を圧迫します。
公開コードを取得するだけならGitの複製で済む場面でも、Web画面を網羅的に巡回するためです。Codebergは防御策の実装に時間を取られ、正当な利用者にも制限を設けざるを得ないと説明しています。
3. 少人数のプロジェクトが多くの資源を消費する
AIコーディングでは、1人でも短期間に大量のコード、テスト、リリース成果物を生成できます。しかし、生成量が利用者数や保守体制を上回ると、ストレージとCI/CDだけが膨らみます。
Codebergは、利用者がほぼいない1人開発のプロジェクトが、大規模なコミュニティプロジェクトと同等以上の資源を使う例を問題視しました。寄付で運営する非営利基盤にとって、生成速度はそのままインフラ費用になります。
4. OSSのレビュー負担と信頼を損なう
オープンソースソフトウェア（OSS）は、コードを公開するだけでなく、他者が内容を理解し、修正し、共同で保守する仕組みです。低労力で大量に作られたAI生成の提案は、作成者よりレビュー担当者へ多くの負担を移す場合があります。
Codebergは、AIを使っていない貢献まで疑われたり、生成の痕跡を隠す指示が使われたりする状況にも触れています。量が増えても、共同保守できる人が増えなければ、OSSの価値は比例して増えません。
企業のAI開発に与える3つの示唆
Codebergの規約はCodeberg上の利用者に適用されるものであり、そのまま企業の社内規定になるわけではありません。それでも、AIコーディングの管理単位を考える材料になります。
ツールではなく成果物の責任を管理する
Claude CodeやCodex CLIを許可するかどうかだけでは、管理として足りません。同じツールでも、補完に使う場合と、AIエージェントへ設計から実装まで委ねる場合ではリスクが違います。
企業は、生成されたコードを説明できる担当者、承認者、保守期限を決める必要があります。ツールの利用許可と、成果物を本番へ入れる承認は分けて設計すべきです。（Codexの機能と企業利用の基本はこちら）
人間が保守できる量に生成を制限する
AIは実装速度を上げますが、レビュー速度を同じ比率では上げません。変更量が人間の理解を超えると、プルリクエストが承認済みでも、実質的には未検証のコードが蓄積します。
変更行数、差分の複雑さ、レビュー時間、未解決の静的解析警告を追跡し、人間が説明できない変更は分割する運用が必要です。（Claude Codeのセキュリティ対策はこちら）
インフラ費用もAI導入コストに含める
AIコーディングの費用は、モデルの利用料だけではありません。生成されたテストの実行回数、ビルド成果物、コンテナイメージ、ログ、レビュー工数も増えます。
AI導入の投資対効果を測る際は、開発時間の短縮だけでなく、CI/CD、保存容量、検証、事故対応まで含める必要があります。AIエージェントが外部システムへ操作する場合は、権限と監査ログも費用項目です。（AIエージェントのセキュリティ事故と対策はこちら）
＼ 業務自動化のお悩み、プロが30分で整理します ／
法人様のAI導入に関するご相談はこちら企業が整備すべきAIコードガバナンス5項目
企業はAI生成比率を厳密に測る前に、責任と検証の流れを固定すべきです。実務では、次の5項目から始めると判断基準をそろえやすくなります。
| 項目 | 最低限決める内容 | 確認方法 |
|---|---|---|
| 利用申告 | どのAIを何の工程で使ったか | プルリクエストのテンプレートに記録 |
| 所有責任 | 内容を説明し、保守する担当者 | コードオーナーと承認者を指定 |
| 出所と安全性 | ライセンス、秘密情報、脆弱性 | SCA、秘密情報検査、静的解析を実施 |
| 変更の証跡 | 指示、差分、検証結果 | 課題番号とテスト結果を保存 |
| 資源上限 | CI/CD、保存容量、API費用 | 月次上限と自動停止条件を設定 |
AIが作ったコードでも、人間が要件を確認し、差分を説明し、テスト結果を再現できるなら、管理可能な範囲に置けます。反対に、生成比率が低くても、出所や保守担当者が不明ならリスクは残ります。
AI開発ルール、レビュー工程、権限設計を自社の業務に合わせて整理したい企業向けに、株式会社NexaはAI顧問サービスを提供しています。
今後の焦点は運用基準の具体化
Codebergの新条項は「主に生成AIが書いたコード」で構成されるプロジェクトを対象にします。しかし、生成比率を機械的に何%で区切るかは、公式声明で示されていません。
実際の運用では、コード量だけでなく、コミュニティの有無、保守状況、資源消費、AIエージェントの自律性などが判断材料になると考えられます。これは公式声明が列挙した例から読み取れる範囲であり、判定基準の詳細は今後の運用を待つ必要があります。
企業も同じ曖昧さに直面します。「AIを使ったか」だけを問う規則は簡単ですが、軽微な補完と自律生成を区別できません。利用工程、変更規模、人間の理解、検証結果を組み合わせた基準のほうが、実務上のリスクを捉えやすくなります。
＼ AI活用の「次の一手」を一緒に考えませんか ／
法人様のAI導入に関するご相談はこちらよくある質問
Q. CodebergはAIを使った開発を全面禁止したのですか？
いいえ。禁止条項の対象は、ClaudeやOpenAI Codexなどの生成AIツールが書いたコードを主な構成要素とするプロジェクトの共有です。一部のAI支援を使った既存コミュニティプロジェクトまで、一律に禁止する方針ではありません。
Q. 既存のリポジトリはすぐ削除されますか？
Codebergは、一斉削除や全コンテンツの自動スキャンを予定していないと説明しています。明確な違反事例から運用を具体化し、判断が難しい事例は個別に扱う方針です。
Q. Claude CodeやCodex CLIを使うだけで禁止対象になりますか？
利用した事実だけで直ちに対象になるとは説明されていません。規約は、生成AIが書いたコードを主体とするプロジェクトを対象にしています。企業では、利用の有無に加えて、人間が内容を説明、検証、保守できるかを確認する必要があります。
Q. 企業は何から見直すべきですか？
プルリクエストにAI利用の申告欄を追加し、コードオーナー、検査項目、CI/CD上限を決めるところから始められます。既存のセキュリティ審査にAI生成コード専用の確認項目を足す方法なら、別工程を一から作る必要がありません。
まとめ
Codebergは会員投票を経て、生成AIが書いたコードを主体とするプロジェクトの共有を利用規約で禁止しました。賛成358票、反対144票、棄権14票で可決されましたが、AI支援開発の全面禁止や既存リポジトリの一斉削除ではありません。
企業が受け取るべき教訓は、特定ツールを禁止することではなく、生成物の責任、出所、安全性、保守能力、資源消費を管理することです。まずは直近のAI生成コードを1件選び、担当者が差分、テスト、ライセンス、運用コストを説明できるか確認してください。
AI開発のルールを自社に合わせて整備します
株式会社NexaのAI顧問では、AIツールの選定だけでなく、利用規定、レビュー工程、権限管理、効果測定まで支援しています。導入済みのAIを安全に業務へ定着させたい段階からご相談いただけます。
