YOLOv9のGitHub実装3種の選び方｜MIT版・GPL版のライセンスと実行手順

YOLOv9をGitHubから導入しようとすると、最初に「どのリポジトリなのか」で止まります。原論文の実装、同じ著者によるMITライセンス版、Ultralyticsパッケージ経由の実装という3系統が並存し、ライセンスも実行コマンドも別物です。とくに製品へ組み込む場合、この選択がそのままソースコード開示義務の有無に直結します。

この記事は3系統の違いをライセンスと実行手順の両面から整理します。物体検出そのものの仕組みから確認したい場合は物体検出とは？仕組み・代表手法の比較から実装判断までエンジニア向けに解説を先に読むと、YOLOv9の位置づけが掴みやすくなります。

まとめ

結論から言えば、自社製品に組み込むなら公式MIT版のMultimediaTechLab/YOLOが第一候補です。原論文リポジトリのWongKinYiu/yolov9はGPL-3.0で、最後のpushは2024年8月9日。以降は動いていません。UltralyticsパッケージはAGPL-3.0で、同社は自前学習した重みや社内利用まで制約対象と明記しているため、クローズドな製品ではまず有償のEnterpriseライセンスが前提になります。

ただしMIT版の検出モデル設定はv9-t／v9-s／v9-m／v9-cの4種類にとどまり、COCOでAP 55.6%の最大モデルv9-eがありません。最高精度が要件なら、選択肢はGPL-3.0版かUltralytics版の2つに絞られます。以下、各リポジトリの実体、ライセンスごとの開示義務、実際に動かすコマンド、モデルサイズ別の精度を順に見ていきます。なお本記事のライセンス整理は各ライセンス文と提供元の公開記述に基づく一般的な理解であり、法的助言ではありません。

YOLOv9のGitHubリポジトリ3系統の実体と更新状況

「yolov9 github」で辿り着く先は1つではありません。2026年7月30日時点のGitHub APIで各リポジトリのライセンスと更新状況を確認すると、性格の違いがはっきり出ます。

Star数だけ見ればUltralyticsが圧倒的ですが、これはYOLO26やYOLO11を含むパッケージ全体の数字で、YOLOv9単体の評価ではありません。判断材料になるのは各リポジトリの役割です。

原論文実装 WongKinYiu/yolov9 の更新停止と未処理issue

arXiv:2402.13616「YOLOv9: Learning What You Want to Learn Using Programmable Gradient Information」（Chien-Yao Wang、I-Hau Yeh、Hong-Yuan Mark Liao）に対応する実装です。ライセンスはGPL-3.0で、LICENSE.mdにGNU General Public License Version 3の全文が入っています。

公開は2024年2月18日。全ブランチを含む最終pushは2024年8月9日で、mainブランチ自体の最終コミットは2024年6月10日の「Create gelan-t.yaml」までしか進んでいません。未クローズのissueは385件、未マージのプルリクエストは41件（GitHubのopen_issues_countが示す426件はこの両方を合算した数値です）。論文の数値を再現する用途では今も基準になる一方、新しいPyTorchやCUDAへの追随は期待できません。

公式MIT版 MultimediaTechLab/YOLO のモデル構成の制約

READMEは自身を「official implementation of YOLOv7 and YOLOv9, YOLO-RD」と位置づけ、TL;DRに「This is the official YOLO model implementation with an MIT License.」と明記しています。LICENSEファイルの著作権表示は「Copyright (c) 2024 Kin-Yiu, Wong and Hao-Tang, Tsui」です。mainブランチはv1.0リリース（2025年12月30日）が最新で、developブランチでは2026年3月16日にもデータ拡張のバグ修正が入っており、GPL版とは対照的に保守が継続しています。

注意すべきは同梱モデルの範囲です。yolo/config/model にある検出モデルの設定ファイルはv9-t、v9-s、v9-m、v9-cの4種類で、v9-eの設定がありません（このほかセグメンテーション用のv9-c-segと分類用のv9-c-clsが含まれます）。COCOでAP 55.6%を出す最大モデルを前提に精度設計していると、MIT版へ移った時点で要件を満たせなくなります。

Ultralytics版はYOLOv9をパッケージのモデル群として提供

Ultralyticsは自前のフレームワークにYOLOv9を取り込む形で提供しています。公式ドキュメントでは yolov9t.pt から yolov9e.pt までの5サイズと、yolov9c-seg.pt／yolov9e-seg.pt のセグメンテーション版が推論・検証・学習・エクスポートのすべてに対応しています。重みファイル名がハイフン無しの表記になっている点が、原論文リポジトリの yolov9-c.pt と紛らわしいところです。

環境構築の手軽さと保守の速さは3系統で最も優れています。最終pushは2026年7月29日で、更新頻度は日次に近い水準です。ライセンスの扱いだけが導入判断を左右します。

商用利用でどれを選ぶか：GPL-3.0・AGPL-3.0・MITの開示義務の差

ここが「yolov9 mit」で検索する人の本題です。3つのライセンスは、コードを外部へ出すときに何を強制されるかが決定的に違います。

MIT版は有志の再実装ではなく著者本人による公式実装

解説記事の中には、MITライセンスのYOLOv9をコミュニティによる非公式な「再実装」として紹介しているものがあります。これは事実と異なります。MultimediaTechLab/YOLOのLICENSEに記載された著作権者はKin-Yiu Wongで、原論文の筆頭著者Chien-Yao Wangと同一人物です。GitHubアカウント WongKinYiu の表示名は “Kin-Yiu, Wong”、所属は “IIS, Academia Sinica” と登録されており、これは同姓同名ではなく王建堯というひとりの研究者の広東語表記と標準中国語表記の違いにあたります。公式YOLOv7実装も同じアカウントの配下にあります。

共同の著作権者Hao-Tang Tsuiは、同リポジトリが実装するYOLO-RD論文の筆頭著者です。リポジトリの所有者は当初この個人アカウントで、現在はMultimediaTechLab組織へ移管されています。github.com/WongKinYiu/YOLO が301リダイレクトでMultimediaTechLab/YOLOへ解決するのは、その移管の痕跡です。つまりMIT版は「著者が後から出した、より緩いライセンスの公式実装」であり、精度や実装の正統性を理由に避ける必要はありません。

引用表記にも差が残っています。GPL版READMEの引用情報は @article・booktitleがarXiv preprint・著者2名ですが、MIT版READMEは @inproceedings・booktitleがECCV・year 2024・著者3名です。論文としての正式な収録先を確認したい場合はMIT版側の記載を見てください。

AGPL-3.0版をクローズドな製品やSaaSに組み込むべきでない理由

UltralyticsはAGPL-3.0の適用範囲を自社ライセンスページで明示しています。求められるのは「Open-source your entire project under AGPL-3.0, or obtain an Ultralytics Enterprise License.」の二択です。開示対象は「the complete corresponding source code for the entire derivative work, including the larger application, modifications, scripts, configuration files, and, where applicable, model weights」とされ、アプリ本体・改変・スクリプト・設定ファイルに加え、条件次第で学習済み重みまで含みます。

適用条件はさらに広く取られています。同ページは “even if you:” として、自前データでゼロから学習した場合、学習済み重みを使わない場合、社内利用やR&D限定の場合、SaaSプラットフォームやAPIなど私的なシステム経由で提供する場合、ハードウェアやエッジデバイス・商用製品へ組み込む場合を列挙しています。つまりSaaS提供と製品組み込みは、AGPLの一般的な発動条件を論じる前に、提供元自身が適用対象として名指ししている行為です。

したがって、ソースを公開しない製品やSaaSにUltralytics版を組み込む選択は取りません。有償のEnterpriseライセンスを購入する前提が立たない限り、この系統は候補から外すのが実務的な判断になります。

GPL-3.0版を選んでよい場面と避ける場面

GPL-3.0の開示義務は、原則として配布（GPL-3.0第4条から第6条が定める “conveying”）で発生します。社内のサーバーで動かして結果だけを使う、研究として論文値を再現する、といった使い方であれば衝突しません。v9-eが必要な精度検証も、この範囲なら原論文リポジトリで進めて構いません。

避けるべきは、そのコードを含んだソフトウェアを顧客へ渡す場面です。オンプレミス納品、エッジデバイスへの焼き込み、パッケージ販売はいずれも配布に当たり、GPL-3.0であれば派生物全体を同ライセンスで公開する義務が生じます。この段階まで進む予定があるなら、最初からMIT版で実装しておくほうが後戻りが少なくて済みます。

もうひとつの実務リスクは、ライセンス条件の交渉相手がいないことです。商用利用の可否を問うissueは #623「Clarification on GPLv3 Licensing for YOLOv9 in a Commercial and R&D Context」（2025年1月13日）と #649「Commercial Licensing Inquiry for yolov9」（2025年7月29日）が立っていますが、いずれも2026年7月時点でopenのままです。更新が止まったリポジトリでは、GPLとは別条件の商用ライセンスを個別に取り付ける交渉も期待しにくくなります。なお学習済み重みがライセンスの派生物に当たるかは論点として残っており、Ultralyticsのように明示的に含める立場もあります。

公式MIT版 MultimediaTechLab/YOLO の導入と実行コマンド

MIT版はHydraベースの設定指定でタスクを切り替える方式で、原論文リポジトリのスクリプト直叩きとは操作体系が異なります。低レベルの改変手順まで踏み込む場合は、公式ドキュメント（yolo-docs.readthedocs.io）と docs/HOWTO.md が参照先になります。

pipインストールとgit cloneの使い分け

推論を試すだけならpipで足ります。学習の設定を触る、モデル定義を書き換えるといった作業をするならクローンしてください。

# 推論を試すだけならpipで完結する
pip install git+https://github.com/MultimediaTechLab/YOLO.git
yolo task.data.source=0  # 0はWebカメラ。ファイル・動画・画像フォルダも指定できる

# 設定やモデル定義を変更するならクローンする
git clone https://github.com/MultimediaTechLab/YOLO.git
cd YOLO
pip install -r requirements.txt

READMEのインストールURLは旧アカウントの WongKinYiu/YOLO 表記のままですが、301リダイレクトが張られているためgitやpipからも通常はそのまま解決されます。上記のように移管後のURLを直接指定しても同じ結果になります。READMEはSSH形式の [email protected]: を案内していますので、鍵を登録していない環境ではHTTPSに読み替えてください。

ここで落とし穴が1つ。MIT版は pyproject.toml で yolo というコンソールコマンドを登録しますが、Ultralyticsパッケージも同名の yolo を登録しています。同じ仮想環境に両方入れると、どちらが呼ばれるかはインストール順に依存して不定です。3系統を比較検証するなら環境を分けるか、python -m yolo.lazy の形式で明示的に呼び分けてください。

推論・学習・検証をタスク指定で切り替える書き方

エントリポイントは yolo/lazy.py に統一され、task= で動作が切り替わります。モデルは model=v9-c のように設定ファイル名で指定します。

# 推論（デバイスとモデルサイズ、NMSのしきい値を指定）
python yolo/lazy.py task=inference \
                    device=cuda \
                    model=v9-s \
                    task.nms.min_confidence=0.1 \
                    task.data.source=data/toy/images/train

# 学習（データセット設定はyolo/config/dataset配下を書き換える）
python yolo/lazy.py task=train task.data.batch_size=8 model=v9-c

# 検証（COCO形式のjsonを出力する）
python yolo/lazy.py task=validation

device に渡せる値はcuda、cpu、mpsの3種類。Apple SiliconのMacでmpsが使えるため、GPU無しの手元環境でも検証を始められます。ONNXやTensorRTでの高速推論に切り替えたい場合は task.fast_inference=onnx のように指定してください。

学習済み重みの配布先はv1.0-alphaタグ側

最新リリースのv1.0（2025年12月30日）にはアセットが添付されていません。重みファイルは2024年6月3日のv1.0-alphaタグ側に置かれており、v9-t.pt、v9-s.pt、v9-m.pt、v9-c.pt、それにYOLO-RDのrd-9c.pt、rd-9c-4096.pt、v7.ptが公開されています。最新タグのリリースページだけを見て「重みが配布されていない」と誤解しやすい箇所です。

同じタグには動作確認用のmock_train.zip、mock_val.zip、mock_annotations.zipも同梱されています。自前データを用意する前に task=validation dataset=toy で経路を通しておくと、設定の切り分けが楽になります。

原論文リポジトリの実行手順と-converted重みの対応関係

GPL版で最も詰まるのが重みファイルとスクリプトの対応関係です。ファイル名の -converted の有無で、呼ぶスクリプトが変わります。

detect.pyとdetect_dual.pyの使い分け

YOLOv9は学習時に補助分岐（auxiliary reversible branch）を持ちますが、推論時にはこの分岐を取り除けます。取り除いた状態に変換済みの重みが yolov9-c-converted.pt で、分岐を保持したままの重みが yolov9-c.pt です。前者は通常のスクリプト、後者は末尾に _dual が付くスクリプトで扱います。

# 変換済み重み（-converted）は通常スクリプト
python detect.py --source './data/images/horses.jpg' --img 640 --device 0 \
                 --weights './yolov9-c-converted.pt' --name yolov9_c_c_640_detect

# 未変換の重みはdual側スクリプト
python detect_dual.py --source './data/images/horses.jpg' --img 640 --device 0 \
                      --weights './yolov9-c.pt' --name yolov9_c_640_detect

# 学習も同様にtrain_dual.pyを使う
python train_dual.py --workers 8 --device 0 --batch 16 --data data/coco.yaml --img 640 \
                     --cfg models/detect/yolov9-c.yaml --weights '' --name yolov9-c \
                     --hyp hyp.scratch-high.yaml --min-items 0 --epochs 500 --close-mosaic 15

組み合わせを誤ると、スクリプトが構築するアーキテクチャと重みの構造が対応せず読み込みに失敗します。原因がエラーメッセージから読み取りにくいため、まず重みファイル名に -converted が付いているかを確認するのが早道です。GELAN単体の重み（gelan-c.pt等）は補助分岐を持たないので、通常スクリプト側で扱います。

COCOでの再現値と評価コマンド

評価も同じ対応関係に従い、val.py と val_dual.py を使い分けます。データ準備は bash scripts/get_coco.sh でCOCO 2017を取得します。

python val.py --data data/coco.yaml --img 640 --batch 32 --conf 0.001 --iou 0.7 \
              --device 0 --weights './yolov9-c-converted.pt' --save-json --name yolov9_c_c_640_val

READMEに載っている再現値はAP 0.530、AP50 0.702、AP75 0.578です。物体サイズ別ではsmall 0.362、medium 0.585、large 0.693で、小さい物体の検出精度が全体値より17ポイント近く低くなります。小物体が主対象の案件では、この差を前提に入力解像度を640より上げるか、モデルサイズを上げる判断が必要になります。

モデルサイズ別の精度とパラメータ数の選び分け

原論文リポジトリが公開しているMS COCOでの実測値です。AP(val)はIoU 0.5から0.95の平均で、入力サイズはいずれも640です。

効率の観点で見どころはSからMの区間です。パラメータが7.1Mから20.0Mへ約2.8倍になってAP(val)の伸びは4.6ポイント、さらにCからEではパラメータが2.3倍でAP(val)は2.6ポイントしか動きません。エッジ推論ではv9-sかv9-cで止めるのが現実的な落としどころで、v9-eは精度が最優先の案件に限定されます。

同じモデルでもUltralytics版の公表値はパラメータとFLOPsが微妙に違います。v9-sが7.2M／26.7B、v9-cが25.5M／102.8B、v9-eが58.1M／192.5Bで、AP(val)は原論文と一致します。実装が異なるため層構成の数え方に差が出ているもので、どちらかが誤りというわけではありません。ベンチマーク結果を比較する際は、どの実装の数字かを揃えて見る必要があります。

推論を軽くする方向を検討するなら、モデルサイズを落とす前に量子化（モデル量子化）とは？仕組み・PTQとQATの違いと実装判断を解説【2026年版】で扱っている手法との組み合わせも比較対象になります。

PGIとGELANが精度に効く仕組み

YOLOv9の論文が提案したのはPGIとGELANの2点です。理屈を押さえておくと、前述の -converted 重みが存在する理由も繋がります。

PGIが解く情報ボトルネックと推論時コストがゼロになる理由

Programmable Gradient Information（PGI）は、深いネットワークで層を通るたびに入力情報が失われ、損失計算に必要な情報が届かなくなる問題に対処する仕組みです。論文の要旨では「PGI can provide complete input information for the target task to calculate objective function」と説明されています。

構成要素は3つ。推論に使うmain branch、勾配を正しく伝えるためのauxiliary reversible branch、そしてmulti-level auxiliary informationです。このうち後ろの2つは学習時にしか使われず、推論では切り離せます。切り離しを済ませたものが配布されている -converted 重みで、リポジトリには tools/reparameterization.ipynb という変換用ノートブックも用意されています。学習時だけ重く、推論は素のGELANと同じコスト、という設計です。

GELANが従来の畳み込みだけで効率を上げる構造

Generalized ELAN（GELAN）はCSPNetとELANを一般化したアーキテクチャです。論文の要旨は「GELAN only uses conventional convolution operators to achieve better parameter utilization than the state-of-the-art methods developed based on depth-wise convolution」と述べています。比較対象はdepth-wise畳み込みをベースにした当時の最新手法で、それに対して通常の畳み込みだけでパラメータ効率が上回った、という主張です。

実務上の利点は移植性にあります。特殊な演算子や自己注意機構に依存しないため、ONNXやTensorRTへエクスポートする際に未対応オペレータへ当たるリスクが小さく済みます。TransformerベースのRT-DETRと比較検討するなら、この変換しやすさが選定理由になることもあるでしょう。両者の設計思想の違いはRT-DETRとは？Baidu製リアルタイム物体検出モデルの仕組みとYOLOとの違いで整理しています。

よくある質問

YOLOv9は商用利用できますか？

できますが、どのリポジトリを使うかで条件が変わります。MITライセンスのMultimediaTechLab/YOLOであれば、著作権表示を残すことでクローズドな製品への組み込みも可能です。原論文リポジトリのWongKinYiu/yolov9はGPL-3.0のため、コードを含むソフトウェアを配布する場合は派生物全体の公開義務が生じます。UltralyticsパッケージはAGPL-3.0で、ソースを公開しないなら有償のEnterpriseライセンスが必要です。以上は各ライセンス文と提供元の記述に基づく一般的な整理であり、自社の製品形態に対する最終判断は法務確認を通してください。

MIT版とGPL版で検出精度は変わりますか？

変わりません。同じモデルサイズであれば設計は同一で、どちらも著者本人による公式実装です。差が出るのは選べるモデルの範囲だけで、MIT版にはv9-eの設定がない点に注意してください。v9-t〜v9-cの範囲で足りる要件なら、精度を理由にMIT版を避ける必要はありません。

YOLOv9でセグメンテーションもできますか？

できます。MIT版には検出用の設定に加えて v9-c-seg.yaml（セグメンテーション）と v9-c-cls.yaml（分類）が同梱されています。Ultralytics版で使えるのは yolov9c-seg.pt と yolov9e-seg.pt の2つで、推論・検証・学習・エクスポートの4モードすべてに対応済みです。ピクセル単位でクラスを塗り分けるタスクそのものの考え方はセマンティックセグメンテーションとは何か？基本概念から重要性まで機械学習エンジニア向けに徹底解説で整理しています。

手や特定の物体だけを検出したい場合はどうしますか？

COCOの80クラスに含まれない対象は、学習済み重みを起点にした転移学習で対応します。MIT版なら python yolo/lazy.py task=train model=v9-c dataset={データセット設定}、GPL版なら train_dual.py に自作データセットのyamlを渡す形です。手の検出のようにクラス数が少ないタスクでは、v9-cのような大きいモデルよりv9-sから試したほうが学習時間と精度のバランスを取りやすくなります。進め方は転移学習とは？ファインチューニング・特徴抽出との違いと実装判断を解説が参考になります。

YOLOv9とYOLOv10・RT-DETRはどう選び分けますか？

ライセンス条件が先に来ます。MITライセンスで商用利用したいならYOLOv9のMIT版が有力な選択肢です。後処理のNMSを省いて推論遅延を詰めたい場合はYOLOv10とは？NMSフリーで高速化した物体検出モデルの仕組みと使い方で扱うYOLOv10、アンカーとNMSの調整自体を避けたい場合はRT-DETRが候補になります。既存の学習パイプラインを流用できるかどうかも実務では判断材料になります。

関連記事

• 物体検出とは？仕組み・代表手法の比較から実装判断までエンジニア向けに解説
• YOLOv10とは？NMSフリーで高速化した物体検出モデルの仕組みと使い方
• RT-DETRとは？Baidu製リアルタイム物体検出モデルの仕組みとYOLOとの違い
• 転移学習とは？ファインチューニング・特徴抽出との違いと実装判断を解説
• 量子化（モデル量子化）とは？仕組み・PTQとQATの違いと実装判断を解説【2026年版】