直接的な答え： 多くのチームにとって、AGPL-3.0のツールを使って自社ソフトウェアを作っても、あなたのソフトウェアがAGPLになることはありません——ライセンスが及ぶのはツールであって、それで書いたコードではありません。人を驚かせる義務はネットワーク条項です。ツールを改変し、改変版を他者にネットワーク越しに使わせるなら、そのソースを提供しなければなりません。本記事は一般的な情報であり、法的助言ではありません。ご自身の状況は弁護士に確認してください。
オープンソースのAIコーディングプラットフォームは、GNU Affero一般公衆ライセンス v3.0で提供されることが増えています。これは強いコピーレフトライセンスであり、その評判ゆえにAGPLツールの採用そのものに不安を抱く技術責任者もいます。その不安の多くは、まったく別の二つのこと——ソフトウェアを使うことと、改変して再配布すること——を混同することから生じます。
AGPL-3.0とは何か、何が違うのか
AGPL-3.0は、GPLファミリーの中でネットワーク時代に最も強いコピーレフトライセンスです。通常のGPLv3の義務——ソフトウェアやその改変版を**伝播（配布）**するとき、同じライセンスで対応するソースを提供しなければならない——に加えて、もう一つのトリガーを備えます。
その追加が、**第13条「リモートネットワーク交流」**です。自由ソフトウェア財団が公開するライセンス正文によれば、プログラムを改変し、その改変版とユーザーがコンピューターネットワークを通じて遠隔で交流できるようにした場合、あなたはそのユーザーに、改変版の対応ソースを受け取る機会を与えなければなりません。これがAGPLネットワーク利用条項であり、通常のGPLが残す「SaaSの抜け穴」を塞ぎます。
多くの不安を解消する区別
ここがチームの最も誤解しやすい点です。プログラムを実行することは、その派生物を作ることとは異なります。FSFのGNUライセンスFAQによれば、プログラムの出力は、出力自体がプログラムの一部を含む場合を除き、原則としてそのプログラムのライセンスに縛られません。
平たく言えば、AGPL-3.0のコーディングプラットフォームをツールとして使って自社アプリを書くなら、そのアプリはあなたのものです。AGPLが及ぶのはプラットフォームのソースコードであって、あなたがそれで生み出すソースコードではありません。これはAI生成コードの著作権は誰のものかで扱った考え方と同じです——ツールのライセンスと、あなたの成果物の帰属は、別々の問いです。
したがって実務上のリスクは「AGPLソフトを採用するとコードベースに感染する」ではありません。もっと狭く、具体的です。ツール自体を改変した場合、その改変版をどう配布・公開するのか？
義務が実際に生じるのはいつか
ライセンス正文から考えると、大きく三つの状況で挙動が大きく異なります。（繰り返しますが、一般的な情報であり、法的助言ではありません。）
- 内部での、未改変の利用。 組織内でツールを動かし、改変も配布もしない。最も軽いケースです。ネットワーク条項は、改変版を外部ユーザーに提供することで発動します。
- ツールを改変する。 ソースを変えた瞬間、改変版を伝播する、あるいは第13条に基づき遠隔ユーザーへ公開する時点で、コピーレフト義務がその改変に及びます。
- ネットワークサービスとして提供する。 改変版をホストし、外部ユーザーがネットワーク越しに交流できるようにするなら、第13条はあなたに、その改変の対応ソースを提供するよう求めます。
重要な軸は「内部か外部か」ではなく、未改変の利用か、改変して公開するかです。
実用的なコンプライアンス・チェックリスト
- スタック内のどのAIツールがAGPL-3.0か、推移的な構成要素も含めて棚卸しする。
- ツールと自社製品を分離する：自社アプリがツールを独立したサービス／ツールとして呼び出しており、ソースを自社コードにコピーしていないことを確認する。
- 改変を追跡する。 AGPLツールをforkしたりパッチを当てたりする場合、その変更を識別可能に保ち、バージョン管理下に置く。
- 公開方法を決める。 改変版を外部ユーザーにネットワーク越しに提供し得るなら、改変の対応ソースを公開する計画を立てる。
- ライセンス表示とファイルを保持する。署名やLICENSEを削除しない。
- 商用展開でこれらに依拠する前に、法務レビューを受ける。直接的な答えのAGPL-3.0はMonkeyCodeに何を意味するか、商用利用できるかを参照してください。
MonkeyCodeの位置づけ
MonkeyCodeのリポジトリはGNU AGPL-3.0で提供されており、上記の義務のもとでコードは監査・fork可能です。「自社ソフトを開発するために動かす」多くの採用者にとって、これは扱いやすく、よく理解された取り決めです——多くのオープンソース基盤ツールと同じ性質です。ライセンスガイドは事実に基づく概要と法務レビューの境界を示し、チーム向けに整ったオープンソースAIコーディングプラットフォームとはは採用の運用面を扱います。
結論
AGPL-3.0はMITやApache-2.0より厳格ですが、よくあるケース——ツールを使って自社製品を作る——では、あなたのコードには及びません。慎重になるべき唯一の場所は「改変＋ネットワーク公開」であり、そこでは第13条が改変のソース共有を求めます。AGPLツールを棚卸しし、改変を識別可能に保ち、公開モデルを早めに決め、あなたの展開の具体は弁護士に確認してもらってください。
本シリーズの関連記事
- チーム向けに整ったオープンソースAIコーディングプラットフォームとは
- セルフホスト型AI開発プラットフォーム：評価チェックリスト
- エアギャップAIコーディング：外向き通信なしでAI開発プラットフォームを運用する
出典の範囲： AGPL-3.0の義務は、自由ソフトウェア財団が公開するライセンス正文とGNUライセンスFAQ（2026年7月20日確認）に基づいて要約し、一般的な教育目的の情報として解釈したものです。本記事は法的助言ではなく、ライセンス解釈はあなたの具体的な事実に依存します——商用展開で依拠する前に、資格ある弁護士に相談してください。MonkeyCodeのライセンスは公開リポジトリが基準であり、現行のLICENSEファイルで確認してください。