---
title: "YOLOv9のGitHub実装3種の選び方｜MIT版・GPL版のライセンスと実行手順"
url: "https://www.issoh.co.jp/tech/details/2571/"
published: 2024-06-14
updated: 2026-10-18
categories: ["AI"]
publisher: "株式会社一創"
---

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

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

この記事は3系統の違いをライセンスと実行手順の両面から整理し、2026年10月時点で各リポジトリを実際にインストールして動かした結果も載せます。物体検出そのものの仕組みから確認したい場合は[物体検出とは？仕組み・代表手法の比較から実装判断までエンジニア向けに解説](/tech/details/15323/)を先に読むと、YOLOv9の位置づけが掴みやすくなります。

## まとめ

自社製品に組み込むなら、公式MIT版のMultimediaTechLab/YOLOが第一候補です。原論文リポジトリのWongKinYiu/yolov9はGPL-3.0で、最後のpushは2024年8月9日のまま止まっています。UltralyticsパッケージはAGPL-3.0で、同社は自前学習や社内利用まで適用対象と明記しているため、ソースを公開しない製品では有償のEnterpriseライセンスが前提になります。

MIT版の弱点は2つです。検出モデルの設定がv9-t／v9-s／v9-m／v9-cの4種類で、COCOでAP 55.6%の最大モデルv9-eがありません。もう1つはCPUでの扱いで、付属の `yolo` コマンドは混合精度が固定されており、検証環境のCPUでは1枚の推論に51秒かかりました。同じ重みをPythonから単精度（fp32）で呼べば0.75秒です。

原論文リポジトリは、2026年の環境に `pip install -r requirements.txt` で素直に入れると、setuptools・PyTorch・Pillowの3か所で止まります。版を固定すれば今も動きます。以下、各リポジトリの実体、ライセンスごとの開示義務、壊れる箇所と回避策、同じCPUでの実測、モデルサイズ別の精度を順に見ていきます。ライセンスの整理は各ライセンス文と提供元の公開記述に基づく一般的な理解であり、法的助言ではありません。

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

「yolov9 github」で辿り着く先は1つではありません。2026年10月18日にGitHub APIで各リポジトリを確認した結果です。

| リポジトリ                   | ライセンス    | Star数  | 最終push     | v9-e |
| ----------------------- | -------- | ------ | ---------- | ---- |
| WongKinYiu/yolov9       | GPL-3.0  | 9,562  | 2024-08-09 | あり   |
| MultimediaTechLab/YOLO  | MIT      | 1,752  | 2026-03-16 | なし   |
| ultralytics/ultralytics | AGPL-3.0 | 62,597 | 2026-10-18 | あり   |

UltralyticsのStar数はYOLO26やYOLO11を含むパッケージ全体の数字で、YOLOv9単体の評価ではありません。

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

[arXiv:2402.13616](https://arxiv.org/abs/2402.13616)「YOLOv9: Learning What You Want to Learn Using Programmable Gradient Information」（Chien-Yao Wang、I-Hau Yeh、Hong-Yuan Mark Liao）に対応する実装です。論文はECCV 2024の会議録に収録されています（[Springer版](https://link.springer.com/chapter/10.1007/978-3-031-72751-1%5F1)）。[リポジトリ](https://github.com/WongKinYiu/yolov9)のLICENSE.mdはGNU GPL Version 3の全文です。

mainブランチの最終コミットは2024年6月10日の「Create gelan-t.yaml」で、全ブランチを含めても2024年8月9日以降のpushはありません。2026年10月18日時点で未クローズのissueが387件、未マージのプルリクエストが41件あります（GitHubの `open_issues_count` が示す428件は両方の合算）。論文値を再現する基準としては今も使えますが、新しい依存ライブラリへの追随は期待できず、後述のとおり版固定が必須になっています。

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

[MultimediaTechLab/YOLO](https://github.com/MultimediaTechLab/YOLO)のREADMEは自身を「official implementation of YOLOv7 and YOLOv9, YOLO-RD」と位置づけ、TL;DRに「This is the official YOLO model implementation with an MIT License.」と書いています。mainブランチはv1.0リリース（2025年12月30日）が最新で、developブランチには2026年3月16日にもデータ拡張とEMAのバグ修正が入っています。

注意すべきは同梱モデルの範囲です。`yolo/config/model` にある検出用の設定はv9-t、v9-s、v9-m、v9-cの4種類で、v9-eがありません（ほかにv9-c-seg、v9-c-cls、YOLOv7用のv7、YOLO-RD用のrd-9c）。公式ドキュメントの[Model Zoo](https://yolo-docs.readthedocs.io/en/latest/2%5Fmodel%5Fzoo/0%5Fobject%5Fdetection.html)でもYOLOv9-Eの状態欄は作業中を示すアイコンのままで、S・M・Cに付いている完了の印がありません。AP 55.6%を前提に精度設計しているなら、MIT版へ移った時点で要件を満たせません。

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

Ultralyticsは自前のフレームワークにYOLOv9を取り込んでいます。[公式ドキュメント](https://docs.ultralytics.com/models/yolov9/)では `yolov9t.pt` から `yolov9e.pt` までの5サイズと、セグメンテーション用の `yolov9c-seg.pt`／`yolov9e-seg.pt` が、推論・検証・学習・エクスポートのすべてに対応しています。重みのファイル名がハイフン無しで、原論文リポジトリの `yolov9-c.pt` と紛らわしい点に注意してください。

環境構築は3系統で最も簡単で、検証時点の最新版は2026年10月18日公開の8.4.182です。非公開製品への採用ではライセンス条件を先に確認し、そのうえで精度・対応デバイス・エクスポート形式を評価します。

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

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

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

解説記事の中には、MITライセンスのYOLOv9をコミュニティによる非公式な再実装として扱うものや、YOLOv9をGPL-3.0とだけ紹介してMIT版に触れないものがあります。MultimediaTechLab/YOLOのLICENSEに記載された著作権者は「Kin-Yiu, Wong and Hao-Tang, Tsui」で、Kin-Yiu Wongは原論文の筆頭著者Chien-Yao Wangと同一人物です。GitHubアカウント `WongKinYiu` の表示名は「Kin-Yiu, Wong」、所属は「IIS, Academia Sinica」で、王建堯という研究者の広東語表記と標準中国語表記の違いにあたります。

共同著作権者のHao-Tang Tsuiは、同リポジトリが実装するYOLO-RD論文の筆頭著者です。リポジトリは当初 `WongKinYiu/YOLO` として公開され、その後MultimediaTechLab組織へ移管されました。旧URLは301リダイレクトで新URLへ解決します。MIT版は「著者が後から出した、より緩いライセンスの公式実装」であり、正統性を理由に避ける必要はありません。

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

UltralyticsはAGPL-3.0の扱いを[自社ライセンスページ](https://www.ultralytics.com/license)で明示しています。求められるのは「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」とされ、アプリ本体・スクリプト・設定ファイルに加え、条件次第で学習済み重みまで含みます。

同ページは「This applies even if you:」として、ゼロから自前学習した場合、学習済み重みを使わない場合、社内利用やR&D限定の場合、SaaS・API経由で提供する場合、エッジデバイスや商用製品へ組み込む場合を列挙しています。これは提供元の案内で、AGPL-3.0の条文そのものは配布しない利用を認め（第2条）、改変版をネットワーク越しに使わせる場合にソース提供を求めます（第13条）。ただ、提供元がここまで明言している以上、条文解釈で争う前提の採用は避けるべきです。Enterpriseライセンスを買う予算が立たないなら、ソースを公開しない製品やSaaSではこの系統を候補から外します。

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

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

避けるべきは、そのコードを含むソフトウェアを顧客へ渡す場面です。顧客へのオンプレミス納品、ソフトウェアを組み込んだエッジデバイスの引き渡し、パッケージ販売では、GPL対象の結合著作物をGPL-3.0で提供し、第6条に沿って対応するソースを入手可能にする必要があります。不特定多数への一般公開が常に必要なわけではなく、独立したプログラムの単なる集合物まで一律に対象になるわけでもありません。そこまで進む予定があるなら、最初からMIT版で実装してください。

別ライセンスの提供を前提に計画できない点も実務リスクです。商用利用を問うissue [#623](https://github.com/WongKinYiu/yolov9/issues/623)（2025年1月13日）と [#649](https://github.com/WongKinYiu/yolov9/issues/649)（2025年7月29日）は、2026年10月18日時点でどちらもopenのままです。なお学習済み重みがライセンス上の派生物に当たるかは論点として残っており、Ultralyticsのように明示的に含める立場もあります。

## MITやApache-2.0で使えるYOLO系・リアルタイム検出器の選択肢

「yolo mit」で探している人の多くは、YOLOv9に限らず「AGPLやGPLを避けて商用製品に載せられる検出器」を求めています。2026年10月時点で各リポジトリのLICENSEファイルを確認した結果です。

| 実装                     | ライセンス      | 補足                         |
| ---------------------- | ---------- | -------------------------- |
| MultimediaTechLab/YOLO | MIT        | YOLOv9（t〜c）・YOLOv7・YOLO-RD |
| LibreYOLO              | MIT        | YOLOv9の重みはMIT版から変換         |
| YOLOX                  | Apache-2.0 | Megvii-BaseDetection       |
| RT-DETR（lyuwenyu）      | Apache-2.0 | Transformer系               |
| D-FINE・DEIM            | Apache-2.0 | RT-DETR系の改良                |
| RTMDet（mmdetection）    | Apache-2.0 | OpenMMLab                  |
| YOLOv7（WongKinYiu）     | GPL-3.0    | MIT版はMultimediaTechLab側    |
| YOLO-NAS 学習済み重み        | 専用ライセンス    | 別途合意がない商用利用は不可             |

[LibreYOLO](https://github.com/LibreYOLO/libreyolo)はUltralytics風のPython・CLIを持つMITのライブラリで、PyPIの最新は1.6.0です。[LibreYOLO9tのモデルカード](https://huggingface.co/LibreYOLO/LibreYOLO9t)には、MultimediaTechLab/YOLOのv1.0-alphaの `v9-t.pt` を変換したもので、学習済みパラメータは変えていないと書かれています。ただし1.6.0は `torch>=2.4.0` を要求するため、PyTorch 2.2系までしか入らない環境では古い版が選ばれます。

注意が要るのはYOLO-NASです。[YOLO-NAS用のライセンス](https://github.com/Deci-AI/super-gradients/blob/master/LICENSE.YOLONAS.md)は「you may not use the Software for any commercial use, including in connection with any models used in a production environment.」と定めており、名前にYOLOが付いていても商用の受け皿にはなりません。Transformer系まで広げて比べるなら、RT-DETRの系譜とライセンスを[RT-DETRとは？読み方・仕組み・YOLOとの違い・ライセンスとv2〜v4の比較](/tech/details/3117/)で整理しています。

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

MIT版はHydraの設定指定でタスクを切り替える方式で、エントリポイントは `yolo/lazy.py`（コンソールコマンドは `yolo`）です。ここからは、2026年10月18日にmainブランチ（v1.0・コミットc4cb5f6）を検証環境に入れて動かした結果に基づきます。検証環境はIntel Core i9-9880H（8コア・AVX-512非対応）のmacOS、Python 3.11.15、PyTorch 2.2.2のCPU版です。

### pip導入時のLightning 2.6.1未満への版固定

推論を試すだけならpipで足ります。学習設定やモデル定義を書き換えるならクローンしてください。READMEの例は旧URLの `WongKinYiu/YOLO` とSSH形式のままですが、リダイレクトで解決するので下のようにHTTPSの新URLを指定して構いません。

```
# 推論を試すだけならpipで完結する
pip install "git+https://github.com/MultimediaTechLab/YOLO.git@c4cb5f6f56102eceeaa7d75e23e1125cd0373eaf" "lightning<2.6.1"

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

Lightningを固定する理由は実測で分かりました。`requirements.txt` は版を指定していないため、そのまま入れると検証時点で最新のLightning 2.6.6が入ります。この状態で推論すると、画像は保存されるのに直後に「TypeError: YOLORichProgressBar.refresh() got an unexpected keyword argument ‘hard’」で終了コード1になります。Lightningは[2.6.1](https://github.com/Lightning-AI/pytorch-lightning/blob/2.6.1/src/lightning/pytorch/callbacks/progress/rich%5Fprogress.py)で `refresh()` に `hard` 引数を加えており、MIT版が上書きしている同名メソッドがこれを受け取れません。2.5.6に下げると同じコマンドが終了コード0で完走しました。

### CPUとGPUの指定と、推論・学習・検証のコマンド

`task=` で動作が切り替わり、モデルは `model=v9-c` のように設定ファイル名で指定します。重みは初回実行時に `weights/v9-s.pt` のように自動で取得されます。

```
# 推論（GPUが無ければ自動でCPUになる。wandbへの送信は切る）
yolo task=inference task.data.source=data/images model=v9-s use_wandb=False

# CPUを明示する書き方（device=cpu は型エラーになる）
yolo task=inference task.data.source=data/images model=v9-s accelerator=cpu device=1

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

# 検証（COCO形式のjsonを出力する）
yolo task=validation model=v9-s
```

READMEと `docs/HOWTO.md` は `device=cpu` を案内していますが、v1.0では `device` の値がそのままLightningの `devices` に渡るため、`TypeError: devices selected with CPUAccelerator should be an int > 0.` で止まりました。CPUを明示したいときは `accelerator=cpu device=1` と書きます。GPU番号0を指定するなら `accelerator=gpu 'device=[0]'` と書きます。整数の `device=1` はGPU番号1ではなく使用台数1の指定です。Apple Siliconでは `accelerator=mps device=1` を指定します。

### Intel Core i9-9880Hでのbf16推論の遅延とfp32への切り替え

`lazy.py` はLightningの `Trainer` に `precision="16-mixed"` を固定で渡します。CPUではfp16の自動混合精度が使えないため、Lightningは警告を出してbf16に切り替えます。bf16の演算命令を持たないCPUではこれが極端に遅く、検証環境ではv9-sで画像1枚の推論に51秒かかりました。設定ファイルからは変えられません。

CPUで回すなら、CLIを使わずPython APIから単精度で呼びます。v1.0で動いた書き方が次のとおりです（公式ノートブック `examples/notebook_inference.ipynb` は `PostProccess` と `custom_logger` をimportしていますが、v1.0の `yolo/__init__.py` が公開している名前は `PostProcess` で、`custom_logger` はありません）。

```
from pathlib import Path
import torch
from hydra import compose, initialize_config_dir
from PIL import Image
import yolo
from yolo import AugmentationComposer, PostProcess, create_converter, create_model, draw_bboxes

cfg_dir = str(Path(yolo.__file__).parent / "config")
with initialize_config_dir(config_dir=cfg_dir, version_base=None):
    cfg = compose(config_name="config", overrides=["task=inference", "model=v9-s"])
cfg.model.model.auxiliary = {}  # 推論に使わない補助分岐を外す

device = torch.device("cpu")
model = create_model(cfg.model, class_num=80, weight_path=Path("weights/v9-s.pt")).to(device).eval()
transform = AugmentationComposer([], cfg.image_size)
converter = create_converter(cfg.model.name, model, cfg.model.anchor, cfg.image_size, device)
post_process = PostProcess(converter, cfg.task.nms)

# 原論文リポジトリの data/images/horses.jpg を作業ディレクトリへコピーしておく
image = Image.open("horses.jpg").convert("RGB")
tensor, _, rev_tensor = transform(image)
with torch.no_grad():
    pred = post_process(model(tensor[None]), rev_tensor[None])
for cls, x1, y1, x2, y2, conf in pred[0].tolist():
    print(cfg.dataset.class_list[int(cls)], round(conf, 2))
draw_bboxes(image, pred, idx2label=cfg.dataset.class_list).save("result.png")
```

原論文リポジトリ付属の `horses.jpg` では、このコードがNMS込み751msで馬5頭（確信度0.95、0.94、0.88、0.76、0.73）を返しました。同じ重みのモデル本体だけをbf16の自動混合精度で3回回すと64〜85秒でした。初回を除いた2回の中央値は81.6秒で、補助分岐込みのfp32測定値約1.06〜1.08秒に対して約76〜77倍です。

### v1.0 CLIでのtask.fast\_inferenceの未接続

READMEは `task.fast_inference` にonnx・trt・deployを指定できると案内しています。ところがv1.0の `lazy.py` が推論に使う `InferenceModel` には「# TODO: Add FastModel」とコメントがあるだけで、変換を担う `FastModelLoader` を呼んでいません。実際に `task.fast_inference=onnx` を付けて推論すると、エラーも警告も出ずに終了し、ONNXファイルは作られず、ログには補助分岐の構築が通常どおり出ていました。

この結果、CLIの推論は学習用の補助分岐を抱えたまま走ります。v9-sのパラメータ数は補助分岐込みで9.80M、外すと7.23Mで、原論文の公表値7.1Mに近いのは後者です。ONNXやTensorRTで動かしたい場合は、上のPython APIで補助分岐を外したモデルを `torch.onnx.export` に渡すか、`FastModelLoader` を直接呼ぶ処理を自分で書く必要があります。

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

最新リリースのv1.0にはアセットが添付されていません。重みは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が公開されています。最新タグのページだけを見ると「重みが無い」と誤解しやすい箇所です。

### Ultralytics版とMIT版のyoloコマンド名の衝突

MIT版は `pyproject.toml` で `yolo = "yolo.lazy:main"` を登録し、Ultralyticsも同名の `yolo` コマンドを登録します。空の仮想環境に順番を変えて2つを入れたところ、Ultralytics→MIT版の順では `bin/yolo` の中身が `from yolo.lazy import main`、逆順では `from ultralytics.cfg import entrypoint` になりました。どちらが動くかは後から入れた側で決まります。比較検証をするなら仮想環境を分けてください。

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

GPL版は2024年6月で止まったコードを2026年のライブラリで動かすことになるので、先に版を固定します。

### 2026年にpip installすると落ちる3か所と版固定

`requirements.txt` は `torch>=1.7.0` のように下限しか書いていないため、今入れると新しい版が入り、次の3か所で止まります。

| ライブラリ      | 壊れる版     | 症状          | 回避策           |
| ---------- | -------- | ----------- | ------------- |
| setuptools | 82.0.0以降 | import時に停止  | setuptools<82 |
| PyTorch    | 2.6以降    | 重みの読み込みで停止  | torch<2.6     |
| Pillow     | 10.0.0以降 | 日本語ラベル描画で停止 | Pillow<10     |

1つ目は `utils/general.py` の `import pkg_resources` です。[setuptools 82.0.0](https://setuptools.pypa.io/en/latest/history.html)（2026年2月8日）で `pkg_resources` が削除されたため、検証環境ではsetuptools 84.0.0が入り「ModuleNotFoundError: No module named ‘pkg\_resources’」でdetect.pyもval.pyも起動しませんでした。81.0.0まではimportでき、80.10.2に下げると動きました。

2つ目は重みの読み込みです。PyTorch 2.6で `torch.load` の `weights_only` の既定値がTrueに変わり、モデルのクラスごと保存されたYOLOv9の重みは「Weights only load failed」で読めません（[issue #632](https://github.com/WongKinYiu/yolov9/issues/632)）。`weights_only=False` を足す[PR #661](https://github.com/WongKinYiu/yolov9/pull/661)は2026年1月27日に出されたまま未マージです。`torch<2.6` に固定するか、手元で `models/experimental.py` と `train_dual.py` の `torch.load` に `weights_only=False` を足します。信頼できる配布元の重みに限る対処です。

3つ目は描画です。`utils/plots.py` はクラス名に非ASCII文字があるとPillowで描画し、`font.getsize()` を呼びます。このメソッドは[Pillow 10.0.0](https://pillow.readthedocs.io/en/stable/releasenotes/10.0.0.html)で削除済みで、検証環境（Pillow 13.0.0）でクラス名「馬」を描かせると「AttributeError: ‘FreeTypeFont’ object has no attribute ‘getsize’」になりました。英字のクラス名ならOpenCVで描くので通りますが、日本語のクラス名で自前学習する場合は `Pillow<10` が必要です。

```
git clone https://github.com/WongKinYiu/yolov9.git
cd yolov9
pip install "setuptools<82" "torch<2.6" "torchvision<0.21" "Pillow<10" "numpy<2" -r requirements.txt
```

### 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 cpu \
                 --weights './yolov9-s-converted.pt' --name yolov9_s_c_640_detect

# 未変換の重みはdual側スクリプト（--device 0 はGPU番号）
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
```

上の版固定をした環境で1つ目のコマンドを実行すると、「gelan-s summary: 489 layers, 7105888 parameters」と表示されたうえで馬5頭を検出しました。変換済み重みの中身はGELAN単体と同じ構造になっていることがログからも分かります。組み合わせを誤るとアーキテクチャと重みの構造が合わずに読み込みで失敗するので、まずファイル名に `-converted` が付いているかを確認してください。v0.1リリースのアセットには `yolov9-t-converted.pt` はあっても未変換の `yolov9-t.pt` はありません。

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

評価も同じ対応で `val.py` と `val_dual.py` を使い分けます。COCO 2017は `bash scripts/get_coco.sh` で取得します。

```
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で、小物体のAPは全体より17ポイント近く低くなります。小物体が主対象なら、入力解像度を640より上げるかモデルサイズを上げる判断が要ります。

## 同じCPUで3系統のv9-sを動かしたモデル単体の推論時間

3系統のv9-s相当を同じ検証環境に別々の仮想環境で入れ、各スクリプトで生成した形状1×3×640×640のランダムテンソルを入力し、モデル本体の推論（前処理・NMSを除く）を8回ずつ計測しました。各計測では初回をウォームアップとして除き、残る7回の中央値を求めています。検証中は同じマシンで別の処理が動いていたため、負荷が下がった2巡目と3巡目の値を載せます。GPL版だけが `fuse=True`（畳み込みとBatchNormの融合）で読み込まれており、負荷も一定ではないので、表は実行時点の参考値です。実装間の速度比を一般化する材料にはしないでください。

| 実装と状態                   | パラメータ | 2巡目     | 3巡目     |
| ----------------------- | ----- | ------- | ------- |
| GPL版 yolov9-s-converted | 7.11M | 673ms   | 701ms   |
| MIT版 補助分岐を外す            | 7.23M | 818ms   | 909ms   |
| MIT版 補助分岐込み（CLI相当）      | 9.80M | 1,080ms | 1,057ms |
| Ultralytics yolov9s.pt  | 7.32M | 823ms   | 844ms   |

Ultralytics版の `predict()` も馬5頭を検出しました（確信度0.95〜0.63）。fp32の値が673〜1,080msの幅に収まったのに対し、bf16に化けるMIT版CLI（前章の81.6秒）は桁が2つ違います。同じMIT版の中でも補助分岐を外すと1〜2割短くなっており、CPUでの速度に効くのは実装の選択より精度の指定と補助分岐の有無です。エッジのGPUやNPUへ載せる前提なら、[NVIDIA Jetsonとは？Orin・Thorの違いと選定基準・量産判断を実装視点で解説【2026年版】](/tech/details/16173/)でデバイス側の選び方を扱っています。

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

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

| モデル      | AP(val) | AP50  | パラメータ | FLOPs  |
| -------- | ------- | ----- | ----- | ------ |
| YOLOv9-T | 38.3%   | 53.1% | 2.0M  | 7.7G   |
| YOLOv9-S | 46.8%   | 63.4% | 7.1M  | 26.4G  |
| YOLOv9-M | 51.4%   | 68.1% | 20.0M | 76.3G  |
| YOLOv9-C | 53.0%   | 70.2% | 25.3M | 102.1G |
| YOLOv9-E | 55.6%   | 72.8% | 57.3M | 189.0G |

SからMでパラメータが約2.8倍になりAP(val)は4.6ポイント伸びますが、CからEではパラメータ2.3倍でも2.6ポイントしか動きません。エッジ推論ではv9-sかv9-cで止め、v9-eは精度が最優先の案件に限るのが現実的です。

Ultralytics版の公表値はv9-sが7.2M／26.7B、v9-mが20.1M／76.8B、v9-cが25.5M／102.8B、v9-eが58.1M／192.5Bで、AP(val)は原論文と同じです。公表されているパラメータ数とFLOPsには実装間の差があるため、比較時は参照する実装と測定条件を揃えてください。モデルサイズを落とす前に推論を軽くする手段として、[量子化（モデル量子化）とは？仕組み・PTQとQATの違いと実装判断を解説【2026年版】](/tech/details/15846/)の手法も比較対象になります。

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

YOLOv9の論文が提案したのはPGIとGELANの2点です。`-converted` 重みがある理由と、MIT版の補助分岐が推論に要らない理由はここから来ています。

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

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

構成要素は推論に使うmain branch、勾配を正しく伝えるauxiliary reversible branch、multi-level auxiliary informationの3つで、後ろの2つは学習時にしか使いません。切り離し済みが `-converted` 重みで、変換用の `tools/reparameterization.ipynb` も原論文リポジトリにあります。補助分岐込みのMIT版が遅かったのは、この切り離しをしていないためです。

### 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と比べたときの選定理由になります。

自社データでの学習から推論環境への組み込みまでを外部に任せたい場合は、ライセンス条件の整理を含めて[画像認識AIモデル構築](/service/ai/image%5Frecog/)で相談を受け付けています。

## よくある質問

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

できますが、使うリポジトリで条件が変わります。MITライセンスのMultimediaTechLab/YOLOなら、著作権表示と許諾表示を複製物またはソフトウェアの実質的な部分に含めることで、クローズドな製品にも組み込めます。原論文リポジトリのWongKinYiu/yolov9はGPL-3.0のため、GPL対象の結合著作物を配布する場合は、全体をGPL-3.0で提供し、ライセンス所定の方法で対応するソースを入手可能にする義務が生じます。UltralyticsパッケージはAGPL-3.0で、同社は非公開プロジェクトにはEnterpriseライセンスが必要と案内しています。ただし、条文上の義務は配布や改変版のネットワーク利用などの条件によって異なります。自社の製品形態に対する最終判断は法務確認を通してください。

### MIT版でYOLOv9-Eは使えますか？

2026年10月時点では使えません。MIT版の検出用設定はv9-tからv9-cまでで、公式Model ZooでもYOLOv9-Eは作業中の表示です。v9-eが要るなら、社内利用の範囲でGPL版を使うか、Enterpriseライセンスを前提にUltralytics版を使うかのどちらかになります。v9-tからv9-cで足りるならMIT版が候補です。同じ著者の公式実装でも原論文版と同じ精度が出る保証にはならないので、採用する重みを自社データで評価してください。

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

できます。MIT版には検出用の設定に加えて `v9-c-seg.yaml`（セグメンテーション）と `v9-c-cls.yaml`（分類）が同梱されています。Ultralytics版で使えるのは `yolov9c-seg.pt` と `yolov9e-seg.pt` の2つで、推論・検証・学習・エクスポートに対応しています。ピクセル単位でクラスを塗り分けるタスクの考え方は[セマンティックセグメンテーションとは？仕組み・代表モデルとmIoUの計算をPyTorchで解説](/tech/details/8657/)で整理しています。

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

COCOの80クラスに無い対象は、学習済み重みを起点にした転移学習で対応します。MIT版なら `yolo task=train model=v9-s dataset={データセット設定}`、GPL版なら `train_dual.py` に自作データセットのyamlを渡します。手の検出のようにクラス数が少ないタスクは、v9-cよりv9-sから試すほうが学習時間と精度の釣り合いを取りやすくなります。クラス名を日本語にするならGPL版では `Pillow<10` の固定を忘れないでください。進め方は[転移学習とは？ファインチューニング・特徴抽出との違いと実装判断を解説](/tech/details/13301/)が参考になります。

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

ライセンス条件が先に来ます。MITで商用利用したいならYOLOv9のMIT版、Apache-2.0でよければRT-DETRやD-FINEが候補です。後処理のNMSを省いて遅延を詰めたい場合は[YOLOv10とは？NMSフリーで高速化した物体検出モデルの仕組みと使い方](/column/details/2774/)で扱うYOLOv10も比較対象になります。既存の学習パイプラインを流用できるかどうかも実務の判断材料です。

## 関連記事

- [物体検出とは？仕組み・代表手法の比較から実装判断までエンジニア向けに解説](/tech/details/15323/)
- [RT-DETRとは？読み方・仕組み・YOLOとの違い・ライセンスとv2〜v4の比較](/tech/details/3117/)
- [YOLOv10とは？NMSフリーで高速化した物体検出モデルの仕組みと使い方](/column/details/2774/)
- [転移学習とは？ファインチューニング・特徴抽出との違いと実装判断を解説](/tech/details/13301/)
- [量子化（モデル量子化）とは？仕組み・PTQとQATの違いと実装判断を解説【2026年版】](/tech/details/15846/)

---

出典: [YOLOv9のGitHub実装3種の選び方｜MIT版・GPL版のライセンスと実行手順](<https://www.issoh.co.jp/tech/details/2571/>)（株式会社一創）