物体検出 2：1ステージYOLO系とリアルタイム性、そしてライセンス

ステータス：下書き（2026-10-13）、一部実測。 グリッド・APの例はノートPCのCPUで直接実行した値です（code/06_yolo_ap.py, 1秒以内）。論文の数値は原文を開いて条件とともに転記し、ハードウェアはグレードで記載しました。ライセンスの内容は各リポジトリのLICENSEファイルと公式案内を2026-10-13に確認したものであり、法律上の助言ではありません。 作成ルール：実測データが基本であり、測定できなかったものは「未実測」と表記します。

目次

• 1. 一度だけ見る
  • やってみる：どのセルが責任を持つか
  • 損失の設計
  • 結果（論文）
• 2. 系譜：アンカー、マルチスケール、アンカーなし、NMSなし
• 3. やってみる：AP計算
• 4. リアルタイム性とは
• 5. ライセンス：AGPLがWebサービスにおいて意味するもの
• 6. 限界と私たちのプロジェクト
• 参考文献

1. 一度だけ見る

第5回のFaster R-CNNは画像あたり約5fpsでした。候補領域を抽出し（1ステージ）、候補ごとに切り抜いて判定する（2ステージ）ためです。RedmonらのYOLO（You Only Look Once, 2016）は問いを変えます。「検出を 1つの回帰問題として解けないだろうか？」画像をネットワークに一度通過させるだけで、すべてのバウンディングボックスとクラスが一度に出力されるようにしようということです。

YOLOv1のルールは次のとおりです。

• 448×448の入力を S×S = 7×7のグリッドに分割します。
• 物体の 中心が落ちたセルがその物体に責任を持ちます。
• セルごとにボックス B=2個（それぞれx、y、w、h、信頼度）とクラス確率 C=20個（VOC）のセットを出力します。
• したがって、出力は 7 × 7 × (2·5 + 20) = 7×7×30, 数値にして1,470個です。

やってみる：どのセルが責任を持つか

448pxの画像において、1つのセルは64pxです。卓球のシーンに当てはめてみました（実測）。

선수 몸 중심  (200,260) → 칸 (행 4, 열 3)
공 중심       (330,95)  → 칸 (행 1, 열 5)
라켓 중심     (215,270) → 칸 (행 4, 열 3)   ← 선수와 같은 칸

選手とラケットの中心が同じセルに落ちました。そのセルはクラス確率を 1セットしか出力しないため、「人物」と「ラケット」が競合します。論文でも1つのセルが制限された数の物体しか予測できないことを弱点として挙げ、小鳥の群れのように小さな物体が密集している場合に弱いと記載されています。

損失の設計

損失はボックス座標・信頼度・クラスの誤差平方和ですが、いくつかの調整にその「理由」が表れています。

• 幅と高さは 平方根で比較します。大きなボックスでの10pxのズレと、小さなボックスでの10pxのズレが同じペナルティを受けてはならないためです。
• 座標誤差にλ_coord = 5を掛け、物体が存在しないセルの信頼度誤差にはλ_noobj = 0.5を掛けます。大半のセルは空であるため、空のセルの声を小さくしないと学習が「すべて空である」という方向に偏ってしまいます。第4回のfocal lossと同様の問題を定数重みで扱ったと言えます。

結果（論文）

同論文のエラー分析において、YOLOは 位置誤差が最大の誤りタイプでした。代わりに背景を物体と勘違いすることはFast R-CNNよりも少なく、両者を組み合わせるとVOC 2012で75.0（Fast R-CNN単体では71.8）に向上しました。画像全体を一度に見るため文脈のミスは少なく、グリッドが粗いため位置の正確さがやや劣るということです。

2. 系譜：アンカー、マルチスケール、アンカーなし、NMSなし

設計上の理由をいくつか挙げると次のようになります。

• k-meansアンカー（v2）。 第5回の実験のように手動で決めたアンカーがデータの物体の形状と合致しない場合、抜けが生じます。v2では学習ボックスを 1 − IoU 距離でクラスタリングしてアンカーを決定し、5個で平均IoU 61.0を達成し、手動で選んだ9個（60.9）と同等でした。データからアンカーを決定すれば少数の数で十分です。
• マルチスケール（SSD、v3）。 小さな物体は高解像度マップ、大きな物体は低解像度マップから探します。第5回のFPNと同じ考え方です。
• アンカーなし（YOLOX）。 アンカーは手動で決める値（数、サイズ、IoUしきい値）を増やします。セルごとにボックスを直接出力し、どのセルがどの正解を担当するかを学習中に動的に決定すればアンカーは不要になります。
• NMSなし（v10）。 NMSはネットワーク外の後処理であるため時間がかかり、単一のしきい値では重なり合った物体と重複を適切に分離できません（第5回）。1つの正解に対して1つの予測のみが紐付くように学習すればNMSは不要になりますが、これは第8回のDETRが最初に見出したアイデアです。v10は1対1の紐付けのみを使用すると学習シグナルが減少するという問題を、学習時に1対多のヘッドを併置することで補いました。

3. やってみる：AP計算

検出論文の数値のほとんどは AP（Average Precision）です。正解のボールが5個あるシーンにおいて、検出器が8個のボックスを出力したとします。スコアの高い順に正解とIoU 0.5以上で紐付けられれば正解（1）、そうでなければ不正解（0）となります（実測）。

점수 순 맞음/틀림: [1, 1, 0, 1, 0, 1, 0, 0]
재현율: [0.2, 0.4, 0.4, 0.6, 0.6, 0.8, 0.8, 0.8]
정밀도: [1.0, 1.0, 0.67, 0.75, 0.6, 0.67, 0.57, 0.5]
AP = 0.683

APは、再現率（見つけた正解の割合）を横軸、適合率（出力したもののうち正解だった割合）を縦軸にした曲線の面積です。適合率を「右側から見た最大値」でならして計算します（すべての点での補間）。正解5個のうち4個しか見つけられなかったため、再現率は0.8でストップし、それ以降の面積は0になります。

同じ8個のボックスであっても、 スコアの順序が変わるとAPは変動します。

APは「正解できたか」だけでなく、「正解した対象に高いスコアを与えたか」まで採点します。信頼度スコアがめちゃくちゃな検出器は、同じボックスを出力してもAPが低くなります。論文のAPを読む際に留意すべき点です。

4. リアルタイム性とは

「リアルタイム」は相対的な言葉です。卓球の映像が1秒あたり60フレームである場合、1フレームに使える時間は16.7msであり、その中にデコード・前処理・モデル・後処理・判定のすべてが収まらなければなりません。論文のfpsを読むときは、条件を合わせて見る必要があります。

• ハードウェアのグレード：データセンターGPUとスマートフォンでは数十倍の差があります。
• 精度とランタイム：FP32 PyTorchとFP16 TensorRTでは、同じモデルでも数倍の差が生じます（YOLOv10・RT-DETRの表はTensorRT FP16）。
• バッチサイズ：SSDの59fpsはバッチサイズ8の場合であり、バッチサイズ1では46fpsでした。リアルタイム映像は通常バッチサイズ1です。
• NMSが含まれているか：ネットワークのみを測定した時間なのか、後処理まで含めた時間なのか。

TT Scoreのボール検出（BlurBall）は、サーバーGPU上の1ウィンドウ（3フレーム）あたり10.5msでした（実測、TT Scoreモデル解剖編2）。「何fps」であるかよりも、「1フレームあたり何ms、どこまで含んでいるか」で記載してこそ比較が可能になります。

5. ライセンス：AGPLがWebサービスにおいて意味するもの

YOLOという名称は複数のリポジトリで共有されています。ライセンスはリポジトリごとに異なります（各LICENSEファイル、2026-10-13確認）。

AGPL-3.0はGPLに ネットワーク条項（第13条）を追加したものです。プログラムを改変し、ユーザーがネットワーク経由でそのプログラムとインタラクションを行うようにした場合、そのユーザーに対して改変版のソースコードを入手する方法を提供しなければなりません。ソフトウェアを配布せず、サーバー上で動かすだけでも義務が生じる点がGPLとは異なります。Ultralyticsは公式の案内ページにおいて、AGPLの公開義務なしに使用するには（商用製品、SaaS・API、組み込み機器、商用利用するファインチューニングモデルなど）企業向けライセンスが必要であると説明しており、学習済みモデルも原則としてAGPL-3.0に従うという立場をとっています。最後の主張（重みデータにもAGPLが及ぶか）が法的にどこまで成立するのかは、本記事では判断できません。ただし、企業がそのように主張しているという事実自体がすでにリスク要因です。

TT ScoreはWebサービスです。そのため、ボール検出にはコードがMITであるWASB・BlurBallを、卓球台にはApache-2.0であるSAM 2.1を選択し、YOLO系のセグメンテーションモデルはAGPLの条件があるため候補から外しました（TT Scoreモデル解剖編1）。モデルを選ぶ際に、精度や速度と同等の重要度でライセンスを確認する理由がここにあります。

6. 限界と私たちのプロジェクト

• 小さな物体。 グリッドの1セル（v1では64px）よりもはるかに小さい卓球ボールは、1ステージ検出器にとっても困難です。マルチスケールによって改善されましたが、TT Scoreではボールをバウンスボックスの代わりに高解像度のヒートマップから検出しています（第3部）。
• NMS。 ネットワーク外の後処理はデプロイを複雑にします。TT Scoreの姿勢実験では、人物検出器（RTMDet）のONNXファイルに含まれるNMS演算をOpenCV DNNが読み込めず、人物のバウンディングボックスの代わりにボール周辺のボックスで回避しました（TT Scoreモデル解剖第4回）。NMSのない検出器（v10、第8回のDETR系）が歓迎される理由はこうした点にあります。
• 同じ名前、異なるモデル。 「YOLO」という名前だけでは、構造もライセンスも決まりません。バージョン番号とリポジトリを合わせて記載する必要があります。

次の記事は、畳み込みを捨てたVision Transformerです。

TTの一言。 同じ8つのボックスなのに、スコアの順序を変えただけでAPが0.8から0.4になりました。正解した対象に自信を持って高いスコアを与えることも実力です。

参考文献

• Redmon, J., Divvala, S., Girshick, R., Farhadi, A. (2016). You Only Look Once: Unified, Real-Time Object Detection. CVPR 2016. https://arxiv.org/abs/1506.02640
• Liu, W. et al. (2016). SSD: Single Shot MultiBox Detector. ECCV 2016. https://arxiv.org/abs/1512.02325
• Redmon, J., Farhadi, A. (2017). YOLO9000: Better, Faster, Stronger. CVPR 2017. https://arxiv.org/abs/1612.08242
• Redmon, J., Farhadi, A. (2018). YOLOv3: An Incremental Improvement. arXiv. https://arxiv.org/abs/1804.02767
• Ge, Z., Liu, S., Wang, F., Li, Z., Sun, J. (2021). YOLOX: Exceeding YOLO Series in 2021. arXiv. https://arxiv.org/abs/2107.08430
• Wang, A. et al. (2024). YOLOv10: Real-Time End-to-End Object Detection. NeurIPS 2024. https://arxiv.org/abs/2405.14458
• Zhao, Y. et al. (2024). DETRs Beat YOLOs on Real-time Object Detection. CVPR 2024. https://arxiv.org/abs/2304.08069
• GNU Affero General Public License v3.0: https://www.gnu.org/licenses/agpl-3.0.html
• Ultralyticsライセンス案内: https://www.ultralytics.com/license、リポジトリ https://github.com/ultralytics/ultralytics
• サンプルコードと出力: このフォルダの code/06_yolo_ap.py, code/06_yolo_ap.out.txt