TECH BLOG

【Public LB 1位】MMAction2で挑んだ日本舞踊の動画分類コンペ — 全プロセス公開

2026-03-25

この記事をシェアする

はじめまして、株式会社ARISE analyticsのBeyond Analytics Divisionに所属するNada（ナダ）です。

現在はAI エンジニアとして、AI エージェントソリューションの設計・実装を通じて、ワークフローの効率化や日常業務の自動化を専門としています。また、2023年から SIGNATE のコンペティションに積極的に参加しており、金メダル4個を獲得し、2025年には SIGNATE リーダーボードで Grand Master 1位に到達しました。

SIGNATEでコンペティションに参加し続ける中で、画像分類やテーブルデータの分析は何度か経験してきましたが、動画データを扱うコンペは初めてでした。「日本舞踊の動画から振りの種類を分類する」というテーマを見たとき、「面白そうだし、動画AIの実践経験を積むにはちょうどいい」と直感的に思いました。友人のnolfwinも興味を示してくれたので、Team JackMaMaとして一緒に参加することに。最初はMMAction2の使い方すら分からない状態でしたが、コンペが終わる頃にはVideo Transformerの仕組みから実践的なファインチューニングの勘所まで、短期間で一気に身につけることができました。この記事では、その全プロセスを読者の皆さんに共有したいと思います。

1. はじめに — このコンペは何？

2024年後半、私は友人のnolfwinと一緒に、SIGNATEプラットフォームで開催された「テクノプロ・デザイン社日本舞踊の画像・動画解析チャレンジ（上級部門）」(リンク)に参加しました。

このコンペの背景には、とても面白い現実的な課題があります。熟練技術者が新米技術者に技を伝えるとき、「やって見せる」場面はよくありますよね。でも、熟練者は長年の経験から身体が自然に動いているため、自分でも意識していない動作がたくさんあります。「無意識にやっていること」を言葉で説明するのは、かなり難しい。これは日本舞踊の世界でも同じで、師匠と弟子が同じ振りを踊って、その違いに気づいて修正するプロセスがとても大事になります。

このコンペは、そのプロセスを支援するための第一歩として、日本舞踊の動画から「今どの振りを踊っているか」を自動で分類するアルゴリズムを作ることが目的でした。

💡この記事を読むと何が分かるのか

動画分類は、製造業の品質検査、スポーツ分析、医療画像解析など、幅広い分野で需要が高まっている技術です。この記事では、MMAction2とVideo Transformerを使った動画分類の実践手順、データ品質の問題発見と対処法、アンサンブル戦略の考え方、そして「正しいモデル」と「勝つモデル」の違いというリアルな教訓まで、コンペの全プロセスを詳しく解説します。動画AIに興味がある方や、コンペティションに挑戦してみたい方の参考になれば幸いです。

2.課題の理解

2.1タスクの定義

タスクは17クラスの動画分類問題です。提供されたのは2,334個の学習用動画データで、それぞれに0〜16のラベルが付いています。各ラベルは日本舞踊の一曲を踊る順番に対応した振りの種別を表しています。テストデータに対して、正しいラベルを推論するモデルを構築するのがゴールです。 techblog_20260325

Fig 1: タスクの全体像 — 動画データを入力とし、動画分類モデルが0〜16の数字ラベルを出力する
（※イラストは生成AIにより作成したイメージ）

具体的な流れとしては、こんな感じです：

日本舞踊を踊っている人物の動画が与えられる
その動画がどの振り（0〜16）に該当するかを分類する
テストデータの推論結果を提出する

2.2 評価指標：Quadratic Weighted Kappa (QWK)

評価指標はQuadratic Weighted Kappa (QWK)で、−1〜1の値を取ります。QWKの特徴は、推論ラベルが正解ラベルから離れれば離れるほど、ペナルティが大きくなることです。精度が高いほど1に近づきます。 image-20260223-084225

Fig 2: QWKの計算方法

QWKでは、各予測に対する重み（ペナルティ）を以下の式で計算します：

重み = (正解ラベル − 推論ラベル)² / (ラベル数 − 1)²

本コンペの場合、ラベル数 = 17（0〜16）なので、(ラベル数 − 1)² = 16² = 256 です。

例えば、正解がラベル6の場合：

推論ラベル	差	重み計算	重み（ペナルティ）
6（正解）	0	0² / 256	0.000（ペナルティなし）
5（近い）	1	1² / 256	0.004（軽いペナルティ）
3（やや遠い）	3	3² / 256	0.035
0（遠い）	6	6² / 256	0.141（重いペナルティ）
16（最も遠い）	10	10² / 256	0.391（最大級のペナルティ）

このように、ラベル5と間違えた場合のペナルティ（0.004）に対して、ラベル0と間違えた場合のペナルティ（0.141）は約35倍も重くなります。つまり、単なる正解率だけではなく、順序関係を意識した分類が求められるわけです。

この性質はタスクの特性に非常によく合っています。日本舞踊の振りは順番に並んでいるため、隣り合うラベル（例：5と6）は動作が似ている一方、離れたラベル（例：0と16）は全く異なる動作です。「近いラベルとの混同は許容するが、遠いラベルとの混同は厳しく罰する」というQWKの性質は、まさにこのタスクに適した評価指標と言えます。

2.3 審査方法：スコアだけじゃない！

このコンペで特徴的だったのは、最終的な入賞者はリーダーボードのスコアだけでは決まらないという点です。スコアは入賞候補者の選定に使われますが、最終決定は審査発表会でのプレゼンテーションによって行われました。

つまり、「どうやってその結果に至ったか」というプロセスが、結果そのものと同じくらい重要視されていたということです。この方針のおかげで、「とりあえずスコアを上げる」だけでなく、論理的で説明可能なアプローチを意識してやることができました。

3.探索的データ分析（EDA）

モデルを作り始める前に、まず自分の目でデータを確認することに時間をかけました。正直、この段階が一番地味な作業ですが、結果的にはプロジェクト全体で最もインパクトのあるフェーズでした。ここで2つの重大な問題を発見しています。

3.1 ファイル形式の問題

まず動画ファイルを開いてみようとしたところ、一部のファイルがそもそも再生できないという問題に遭遇しました（例：train_0006.mp4）。Windows Media Playerでエラーが表示されます。

さらに、動画解析専用ライブラリを使って全データの詳細をチェックしたところ、FPS（1秒あたりのフレーム数）が統一されていないことが判明しました：

FPS値	データ数	割合
30.00	2,176	93%
59.94	106	5%
29.97	50	2%

FPSが異なると、モデル学習・推論時にフレームのサンプリングタイミングがずれるため、処理エラーや精度悪化の原因になります。これは絶対に対処しなければならない問題です。 image-20260223-084822

Fig 3: EDAで発見した問題 — 左：ファイル再生エラーの画面（train_0006.mp4）; 右：FPS別のデータ数と割合を示す円グラフ

3.2 ラベルの不一致問題
— 手動確認

コンペのデータタブには、正直に「アノテーションが間違っている可能性もございます」と記載されていました。これを無視するわけにはいかないので、本格的に確認作業を行いました。

まず手動確認です。ラベルごとの代表動画を選定し、参考動画と比較しながら一つずつ確認していきました。特に着目したのは、ラベル0〜1とラベル15〜16の境界です。

ラベルごとのデータ割合を確認すると、ラベル15と16は他のラベルと比べて数が非常に多いことがわかりました。その他ラベル（0~14）の平均割合が5.88%なのに対して、ラベル15~16は平均の約1.3倍にあたる7.80%を占めています。これは着目すべきポイントです。

実際にデータを一つずつ見ていくと、提供されたラベルと、参考動画の動作が一致しないケースを発見しました。例えばtrain_0120.mp4 は提供ラベルが15ですが、参考動画と比較すると明らかに16の動作をしています。

参考ラベル15の動作の特徴は「左手を上げる → 両手を揺らす → 90°程度まで回る」で、ラベル16は「90°回転から開始 → フル回転して座る → 顔に指を指す」です。この違いは目で見ればかなり分かりやすいのですが、提供ラベルでは入れ替わっているケースが複数ありました。

image-20260321-060713 Fig 4: 手動確認の結果 — 左：学習データのラベルごとの割合（15, 16が突出）;
右：間違いラベルの実例（提供ラベル15だが実際は16）
（※イラストは生成AIにより作成したイメージ）

3.3 問題ラベルの不一致問題
— 機械確認

手動確認に加えて、シンプルなAIモデルを使った機械的な確認も行いました。ロジックはシンプルです：

✓モデルがうまく学習できている場合 → 提供ラベルと推論ラベルがよく一致している

×モデルがうまく学習できていない場合 → 提供ラベルと推論ラベルに齟齬が多い

もしあるラベルが視覚的には明らかに区別できる動作なのに、モデルが正しく分類できないなら、それはモデルの問題ではなくラベルの問題だと考えられます。

混同行列を確認したところ、特にラベル15と16の間で多くの誤分類（混同）が見られました。拡大して見ると：

提供ラベル15のうち、正しく15と推論できたのは145件、間違えたのは31件

提供ラベル16のうち、正しく16と推論できたのは150件、間違えたのは25件

ラベル15と16は見ればすぐわかる動作なのに、なぜこんなに推論を間違えるのか？答えは明確で、提供ラベルのと、実際の動作の間に齟齬があるからです。

image-20260223-085826

Fig 5: 機械確認の結果 — 全体の混同行列（左）とラベル15, 16の拡大図（右）。提供ラベルと推論ラベルの間に大きな齟齬がある

ポイント：提供されたラベルを、常に検証の対象とすること

提供されたアノテーションが正しいとは限りません。手動確認と機械確認を組み合わせたデュアル検証は非常に有効なアプローチです。私たちの場合、このデータ品質の確認作業が、プロジェクト全体で最もインパクトの大きいステップでした。

4. データ前処理

EDAで見つかった問題を踏まえて、2つの前処理を実施しました。

4.1 ファイル形式の統一

ffmpegを使って、学習データとテストデータの全動画を映像コーデックlibx264、FPS 30で統一変換しました。これにより、ファイルが開かない問題とFPSの不統一を一気に解決できます。

コマンド的にはこんな感じです：

ffmpeg -i input.mp4 -c:v libx264 -r 30 output.mp4

地味な作業ですが、これをやらないとモデルの入力段階で既に精度が落ちてしまうため、非常に重要です。

4.2 ラベル訂正パイプライン

ラベルの訂正は、以下の3ステップのパイプラインで系統的に行いました。まず、参考データと学習データの両方を比較確認するための専用プログラムを作成し、動画を見ながら情報をメモしていきました。

STEP 1（提案ラベルの作成）: ラベル14、15、16付近のデータについて、参考動画と見比べながら、各ラベルに該当する動作が動画内でどれくらいの時間（秒数）を占めているかを人力で計測しました。そのうえで、最も長い時間を占めるラベルを「提案ラベル」としました。例えば、ある動画内でラベル15の動作が6秒、ラベル16の動作が8秒であれば、提案ラベルは16となります。
STEP 2（確信度の判定）: 最も秒数の高いラベルが次点のラベルと2秒以上の差がある場合は、高確信（Y）を設定しました。逆に差が2秒未満の場合は低確信（N）とし、訂正の判断が曖昧であることを記録しました。
STEP 3（ラベルの訂正）: 提供ラベルと提案ラベルに齟齬があり、かつ高確信（Y）と判定されたデータのみを対象として、元の提供ラベルを訂正しました。低確信のデータは誤訂正のリスクがあるため、元のラベルをそのまま維持しています。

この結果、ラベル14〜16の範囲で356件中54件（15%）のデータを訂正しました。ラベル15と16以外のラベルペアについても同様に確認・訂正を実施しています。

訂正後のクリーンなデータセットを「データセットV.1」（全ラベル訂正済み）と呼びます。また、ラベル15と16だけは訂正しないバージョンを「データセットV.2」として別途保持しました。このV.2の存在が、後で戦略的に非常に重要になります。

image-20260321-062354

Fig 6: ラベル訂正パイプラインの全体像 — 参考動画との比較ツール（左）、3段階の評価プロセス（中央）、15%のデータを訂正しV.1データセットを獲得（右）
（※イラストは生成AIにより作成したイメージ）

5. AIモデル構築

5.1 使用フレームワーク：MMAction2

モデル構築には、OpenMMLab が開発したMMAction2 (Github) を使用しました。MMAction2はPyTorchベースの動画理解（Video Understanding）専用ツールボックスで、GitHub上で★ 4.9k以上のスターを獲得しており、動画分類の研究・実務において最も広く使われているフレームワークの一つです。

MMAction2を選んだ理由は以下のとおりです：

豊富な事前学習済みモデル: TimeSformer、Video Swin Transformer、MViT V2、VideoMAE/VideoMAE V2、UniFormer V2など、2021〜2023年のトップカンファレンス（ICML, CVPR, NeurIPS, ICLR）で発表された最新のVideo Transformerアーキテクチャが設定ファイル（Config）を書き換えるだけで切り替えられます。ゼロからモデルを実装する必要がなく、コンペの限られた時間内で複数アーキテクチャの比較実験が効率的にできました。
モジュラー設計: MMAction2では、動画認識のフレームワークを「バックボーン（特徴抽出）」「ヘッド（分類層）」「データパイプライン（前処理・拡張）」に分解して考えます。例えば、「バックボーンはVideoMAE V2を使い、分類ヘッドだけ変更する」「データ拡張のパイプラインだけ差し替える」といった柔軟な構成が可能です。この設計のおかげで、実験の変数を1つずつ切り離して検証でき、「何が精度向上に効いたのか」を明確にできました。
Kinetics事前学習チェックポイント: Kinetics-400（40万本の動画、400カテゴリ）やKinetics-600/700といった大規模動画データセットで事前学習されたチェックポイントが公開されています。これらを出発点としてファインチューニングすることで、限られた学習データ（今回は2,334本）でも高い精度を達成できます。もしゼロから学習していたら、このスコアには到達できなかったでしょう。
再現性とドキュメント: 各モデルの学習Config、データ準備スクリプト、推論コードがすべて公開されており、論文の結果を再現できます。ドキュメントも充実しているため、動画分類が初めてでも比較的スムーズに始められます。

実際のワークフローとしては、こんな流れで進めました：

1. MMAction2をインストール（pip + mim経由）
   $ pip install -U openmim
   $ mim install mmengine mmcv
   $ git clone https://github.com/open-mmlab/mmaction2.git
   $ cd mmaction2 && pip install -v -e .

2. 事前学習済みモデルのConfigファイルをベースにカスタマイズ
   → configs/recognition/ 以下に各モデルのConfigが整理されている

3. 自前の日本舞踊データセットに合わせてDataset Configを設定
   → ann_file, data_prefix, num_classes=17 等を変更

4. 学習（Fine-tuning）を実行
   $ python tools/train.py configs/my_custom_config.py

5. 推論結果を出力して提出
   $ python tools/test.py configs/my_custom_config.py checkpoint.pth

コンペで時間が限られている中、MMAction2のConfig-drivenな設計のおかげで、モデルアーキテクチャの切り替えや学習パラメータの調整を素早く回すことができました。動画分類に取り組む際には、MMAction2は最初の選択肢として強くおすすめです。

MMAction2の基本情報

GitHub: GitHub - open-mmlab/mmaction2: OpenMMLab's Next Generation Video Understanding Toolbox and Benchmark （★4.9k）ライセンス: Apache 2.0（商用利用OK）サポートモデル: TimeSformer, Video Swin, MViT V2, VideoMAE V2, UniFormer V2 他多数サポートタスク: 動画分類、行動検出、骨格ベース動作認識、動画検索依存関係: PyTorch, MMCV, MMEngine

5.2 ベースアプローチ：Attention系Video Transformer

MMAction2上で、Attentionメカニズムを持つ学習済みVideo Transformerモデルをファインチューニングしました。

ここで少し背景を説明すると、従来の動画認識モデル（C3D, I3D, SlowFastなど）は3D畳み込み（3D CNN）をベースにしていましたが、2021年以降、画像認識で成功したTransformerアーキテクチャを動画に拡張したVideo Transformerが主流になってきています。Video Transformerの強みは、Self-Attentionメカニズムにより入力フレーム間の長距離依存関係を直接モデル化できる点にあります。つまり、動画の最初のフレームと最後のフレームの関連性を、畳み込みのような局所的な操作ではなく、直接的にAttentionで捉えることができるのです。

実験に使った4つのアーキテクチャを詳しく紹介します：

TimeSformer (ICML 2021) — Facebook AI Researchが提案した、Video Transformerの先駆け的存在です。最大の特徴はDivided Space-Time Attentionで、各TransformerブロックにおいてSelf-Attentionを「時間方向のAttention」と「空間方向のAttention」に分離して適用します。これにより、空間と時間の両方の情報を効率的に統合しつつ、全フレーム×全ピクセルに対するフルAttentionと比べて計算量を大幅に削減できます。Kinetics-400での報告精度はTop-1: 80.7%（ViT-Baseベース）。また、3D CNNと比較して学習が速く、テスト時の効率も高いのが特徴です。非常に長い動画（1分以上）にも適用可能で、私たちのタスク（最大16秒の動画）には十分なキャパシティがありました。
Video Swin Transformer (CVPR 2022) — Microsoftが提案した、画像認識で大きな成功を収めたSwin Transformerの動画版です。シフトウィンドウベースのローカルAttentionを3D（空間＋時間）に拡張しており、グローバルなAttentionではなく局所的なウィンドウ内でAttentionを計算します。ウィンドウをシフトすることで、隣接するウィンドウ間の情報交換を実現。この設計により、計算量を抑えつつも高い精度を達成しています。Kinetics-400でTop-1: 84.9%（Swin-Largeベース、ImageNet-22K事前学習）を記録。事前学習データ量やモデルサイズが競合手法の1/20〜1/3で済みながらも、当時のSOTA精度を達成した効率的なアーキテクチャです。階層的な特徴抽出（各ステージで解像度を下げながら特徴を抽出）により、粗い動きと細かい動きの両方を捉えることができます。
MViT V2 (CVPR 2022) — Meta（旧Facebook）が提案したMultiscale Vision Transformerの改良版です。通常のViTは全層で同じ解像度の特徴マップを使いますが、MViTはプーリングAttentionを用いて段階的に解像度を下げ、異なるスケールの情報を統合します。V2では、分解された相対位置エンベディングと残差プーリング接続が追加され、精度がさらに向上しました。Kinetics-400でTop-1: 86.1%（MViTv2-Large）を記録し、画像分類（ImageNet）、物体検出（COCO）、動画認識の3つのドメインで同時にSOTAを達成した万能アーキテクチャです。マルチスケールの特徴表現が、異なる速さの動作が混在する日本舞踊の分類に適していました。
VideoMAE V2 (CVPR 2023) — 中国科学技術大学とMeta AIが提案した、Masked Autoencoder（MAE）ベースの自己教師あり事前学習を採用したモデルです。学習の仕組みがユニークで、動画の90〜95%のパッチをマスク（隠す）し、残りのパッチから元の動画を復元するタスクで事前学習します。この非常に高いマスキング率は、動画の時間的冗長性（隣接フレームの類似性）があるからこそ可能で、画像のMAE（75%程度）よりもはるかに高い割合でマスクできます。Kinetics-400でTop-1: 87.4%（ViT-Large、追加データなし）を達成し、追加データなしの条件では当時の最高精度を記録しました。特に注目すべきは、小規模データセット（3,000〜4,000本）でも優れた性能を発揮するという報告です。今回のコンペのデータは2,334本しかなかったため、この性質は非常に有利に働きました。また、MAEの研究では「データの量よりも質が重要」という知見も報告されており、これは私たちがラベル訂正に力を入れたことと合致しています。

Kinetics-400とは？

・Google DeepMindが公開した動画認識の標準ベンチマーク・約10秒間のYouTube動画 × 約30万本、400種類の人間の行動を分類・多くのVideo Transformerはこのデータで事前学習 → 個別タスクにファインチューニングが一般的・本コンペでもKinetics-400の事前学習チェックポイントを活用

これらのモデルのKinetics-400ベンチマークでの比較をまとめます：

モデル	発表	K400 Top-1	事前学習	特徴
TimeSformer	ICML 2021	80.7%	ImageNet-21K	分離型Space-Time Attention、学習が速い
Video Swin	CVPR 2022	84.9%	ImageNet-22K	シフトウィンドウ、効率的なローカルAttention
MViT V2	CVPR 2022	86.1%	なし（K400のみ）	マルチスケール、3ドメインでSOTA
VideoMAE V2	CVPR 2023	87.4%	なし（自己教師あり）	小規模データに強い、データ質重視

5.3 精度向上のための2つの作戦

各モデルは、動画全体をフレームごとに処理するのではなく、動画から代表的なフレーム（スナップショット）をサンプリングして入力とします。Attentionメカニズムにより、モデルは「どのフレームのどの部分が分類に重要か」を自動的に学習します。例えば、ラベル15から16に切り替わるタイミングでは90°の回転が始まりますが、Attentionメカニズムがこの瞬間に注目できるかどうかが分類精度に直結します。

image-20260321-062354

Fig 7: モデル学習の概念図 — 動画からスナップショットをサンプリングし、Attention系モデルに入力。ラベル15→16の切り替え（90°回転）をモデルが学習する
（※イラストは生成AIにより作成したイメージ）

この仕組みを踏まえた上で、精度をさらに向上させるために以下の2つの作戦を採用しました。

作戦①：代表画像のサンプリング戦略 —1本の動画から何枚の画像を、どのくらいの間隔で取り出すかを最適化する

作戦②：モデルアンサンブル — 複数のモデルアーキテクチャの予測を組み合わせ、それぞれの得意な部分を活かす

5.3.1 作戦①：代表画像のサンプリング戦略

「動画分類」と言うと、動画をそのままモデルに入力するイメージがあるかもしれません。しかし実際には、モデルが学習するのは動画から抽出された数枚の画像（フレーム）です。1本の動画を丸ごと全フレーム入力するわけではなく、一定の間隔でフレームを抜き出し、その画像セットを入力としてモデルに渡します。

このとき、設計しなければならないのが以下の2つのパラメータです。

サンプリング回数 — 1本の動画から何枚のフレームを取り出すか
サンプリング間隔 — 何フレームおきに取り出すか（Frame/回）

・なぜこの設計が必要なのか？

直感的に理解するために、極端な例を考えてみます。

仮にサンプリング回数を30回に設定しても、間隔が1フレームごとだったらどうなるでしょうか。30回 × 1フレーム = 30フレーム、つまり動画の最初の約1秒分しかカバーできません。残りの動画は完全に無視されるため、後半に含まれる重要な動作をモデルは一切学習できなくなります。

逆に、間隔を広くしすぎると動画全体はカバーできますが、取り出す枚数が少なすぎて、動作の細かい変化を捉えられなくなります。

つまり、動画全体をカバーしつつ、十分な情報量を確保するバランスが求められるわけです。

・設計の考え方

このバランスを定量的に考えるための式はシンプルです。

サンプリング回数 [回] × サンプリング間隔 [Frame/回] ≥ 最大フレーム数 [Frame]

本コンペのデータセットでは、最も長い動画は16.32秒でした。 FPS 30で統一済みなので、16.32 × 30 = 490フレーム。これが設計上カバーすべき上限値になります。

いくつかの組み合わせを比較してみます：

パターン	サンプリング回数	サンプリング間隔	カバー範囲	評価
A	16回	32 Frame/回	512 Frame	〇 490をカバー。情報量とコストのバランスが良い
B	6回	98 Frame/回	588 Frame	△ カバーはできるが、6枚では動作の変化を見落としやすい
C	30回	1 Frame/回	30 Frame	✗ 最初の1秒しか見ていない。動画後半は完全に無視

image-20260313-005819

Fig 8: 代表画像サンプリング戦略 — 左：動画長さのヒストグラム（最大16.32秒）; 右：代表画像数×サンプリング頻度の計算

表からもわかるように、条件を満たす組み合わせは無数にあります。では何で決まるかというと、計算コストとのトレードオフです。

サンプリング回数 ↑ → 情報量 ↑ 精度 ↑ → ただしGPUメモリ・学習時間も ↑
サンプリング回数 ↓ → 軽量で高速 → ただし動作の特徴を見落とすリスク ↑

限られたGPUリソースの中で精度を最大化できる最適な組み合わせを見つけるには、実際に複数のパターンで実験を回して比較するしかありません。今回のコンペでは、この組み合わせを実験的にチューニングし、最終的に精度と計算効率のバランスが取れた設定を採用しました。

5.3.2 作戦②：モデルアンサンブル

モデルアーキテクチャによって得意な部分が異なります。あるモデルは時間的なパターンの捉え方が強く、別のモデルは空間的なディテールに優れています。この特性を活かすため、複数のモデルを組み合わせるアンサンブルを構築しました。

アンサンブルの構成：

様々なアーキテクチャのシングルモデル（TimeSformer, Swin, MViT, VideoMAE V2）
ラベル15, 16専用のモデル（問題のあるラベルに特化）
追加の特徴量エンジニアリング（動画の長さ、縦 or 横の方向）

シングルモデルのQWKが0.9982だったのに対し、アンサンブルによって0.9985まで向上しました。わずかな数字の差に見えますが、このレベルでは0.0003の改善はかなり大きいです。 image-20260223-094333

Fig 9: アンサンブル戦略 — シングルモデル（精度0.9982）から、複数アーキテクチャ＋専用モデル＋特徴量エンジニアリングを組み合わせてアンサンブル（精度0.9985）に向上

6. Public LB 1位への道

6.1 V.1 vs V.2 データセットの発見

コンペ終盤で、意外な発見がありました。

ラベル15と16を訂正していないデータセットV.2で学習したモデルの方が、丁寧に訂正したV.1で学習したモデルよりも、Public リーダーボードのスコアが高いのです。

え？あんなに手間をかけてラベルを訂正したのに？

実はこれ、考えてみれば当然の可能性がありました。評価用のテストデータの正解ラベルも、元の（間違っている可能性がある）ラベル体系に基づいている可能性があるからです。つまり、「正しいラベル」で学習するよりも、「評価基準と同じラベル」で学習した方がスコアが出るという皮肉な状況です。

コンペで学んだ、スコアと『正しさ』の関係

自分の訂正ラベルが「より正確」だと信じていても、評価データが同じ基準とは限りません。リーダーボードは提供された正解との一致を測るものであり、絶対的な正しさを測るものではありません。「コンペに勝つこと」と「正しいモデルを作ること」は、必ずしも一致しない — これはコンペで繰り返し現れる課題です。

6.2 齟齬解消戦略

どちらか一方のデータセットを選ぶのではなく、両方を組み合わせる戦略を考えました。

具体的にはこうです：

アンサンブルV.1（訂正ありデータセット、QWK 0.9985）で推論
アンサンブルV.2（ラベル15, 16訂正なしデータセット、QWK 0.9986）で推論
V.1とV.2の推論結果を比較
V.1がラベル16と推論した場合に、V.2がラベル15と推論していたら → V.2の推論値（ラベル15）を優先
それ以外のラベル（0〜15、および齟齬なしの16）はV.1の推論値をそのまま使用

このハイブリッドアプローチにより、QWK 0.99878を達成し、Public LB 1位を獲得しました！

image-20260223-094819

Fig 10: 齟齬解消戦略 — V.1がラベル16と推論、V.2がラベル15と推論した場合はV.2を優先。このハイブリッド手法でPublic LB 1位（QWK 0.99878）を達成

7. 最終提出と結果

最終提出の選択は、コンペ全体で最も大変な部分でした。

この時点で、私たちが学習していたモデルは以下の3つです：

モデル	使用データセット	説明
V.1モデル	V.1のみ（全ラベル訂正済み）	ラベル15/16を正しく分類できる。実世界での有用性が高い
V.2モデル	V.2のみ（ラベル15, 16訂正なし）	提供ラベルの基準に沿った推論をする
Public LB 1位モデル (V.1+V2ハイブリッド)	V.1とV.2のハイブリッド（セクション6.2の齟齬解消戦略）	Public LB 1位を獲得したモデル

SIGNATEでは最終提出を2つ選択する必要があります。Private LBのスコアに直結するため、どの2つを選ぶかが非常に重要な判断となります。

私たちはV.1モデルとV.1+V.2モデルを提出しました。V.1モデルは実世界での正しさを重視した「信念の提出」、V.1+V.2モデルはPublic LB 1位の実績がある「スコア重視の提出」という位置づけです。

一方で、V.2モデル（V.2のみ）は提出しませんでした。V.1で訂正したラベルの方が正しいと信じていたため、相当精度が高かった訂正なしのV.2単体には確信が持てなかったからです。 image-20260223-095642

Fig 11: 最終提出の悩み — V.1（正しいラベル）とV.2（高スコア）の選択、そして最終結果

7.1 最終結果：Public LB 1位 → Private LB 4位

結果は以下のとおりです：

提出	モデル	Public LB	Private LB
提出①	V.1モデル（V.1のみ）	0.9984936	精度相当低い (0.9985994)
提出②	V.1+V.2モデル（ハイブリッド）	1位 (0.9987869)	4位 (0.9987904)
未提出	V.2モデル（V.2のみ）	0.9985463	提出していればより上位だった可能性 (0.9989240)

提出

モデル

Public LB

Private LB

提出①

V.1モデル（V.1のみ）

0.9984936

精度相当低い

(0.9985994)

提出②

V.1+V.2モデル（ハイブリッド）

1位 (0.9987869)

4位 (0.9987904)

未提出

V.2モデル（V.2のみ）

0.9985463

提出していればより上位だった可能性

(0.9989240)

提出②のPublicとPrivateのスコアはほぼ同一であり、モデル自体は過学習していないことが確認できます。しかし、Private LBの順位は4位に落ちました。

そして後から振り返ると、提出しなかったV.2モデル（ラベル訂正なし）の方がより高い精度を出せた可能性が高いことがわかりました。ラベルを訂正しない方が評価基準と一致するため、V.2単体の方がスコアが高くなるのは理屈としては当然です。しかし、コンペ中は「間違ったラベルで学習したモデルを提出する」ことに確信が持てず、選択肢から外してしまいました。

最終結果

Public LB 1位 (QWK: 0.9987869) → Private LB 4位 (QWK: 0.9987904) Public と Private のスコアはほぼ一致 → 過学習なし ✓ ただし、順位は1位 → 4位に変動

7.2 結果の分析

Private LBで4位になった背景を、事実ベースで整理します。

本コンペでは、提供されたラベルの一部（特にラベル15と16）に誤りがあると判断し、独自にラベルを訂正したデータセットV.1を作成しました。最終的にPrivate LB 4位となった提出②は、このV.1とV.2を組み合わせたハイブリッドモデルです。つまり、ラベル訂正の影響が一部残った状態での提出でした。

一方、最終評価（Private LB）では元の提供ラベルがそのまま正解として採用されました。これにより、ラベル訂正を一切行わなかったV.2ベースのアプローチの方が、評価基準との整合性が高くなる結果となりました。

各提出の立ち位置を整理すると、以下のようになります：

提出	アプローチ	ラベル訂正の影響	Private LB
提出①	V.1モデル（訂正済みラベルのみ）	大きい	精度低下
提出②	V.1+V.2ハイブリッド（訂正の影響が一部残る）	一部あり	4位
未提出	V.2モデル（訂正なしラベルのみ）	なし	より上位だった可能性

この表から見えてくるのは、ラベル訂正の影響が大きいほどPrivate LBの精度が下がるという傾向です。提出①（V.1のみ）は精度が大幅に低下し、提出②（ハイブリッド）は4位、そして未提出のV.2（訂正なし）が最も高い精度を出せた可能性がある。評価基準が元の提供ラベルに基づいている以上、訂正を行わないアプローチの方がスコアで有利になるのは、論理的には自然な結果です。

このこと自体は、コンペティションの性質上珍しいことではありません。評価基準は主催者が定めるものであり、参加者が「正しい」と判断したラベルと、評価上の「正解」が一致するとは限りません。

今回の反省としては、V.2モデル（訂正なし単体）も提出候補に含めるべきだったという点です。「自分が正しいと信じるラベル」と「評価基準上の正解」が異なる可能性を、もっと冷静に考慮し、提出枠の2つを「V.1+V.2ハイブリッド」と「V.2単体」に割り当てていれば、より上位に入れた可能性があります。

一方で、実務の観点から見れば、ラベル15と16を正しく区別できるV.1モデルの方が、技術伝承ツールとしての実用性は明らかに高いです。「コンペのスコアと実世界での有用性は、必ずしも一致しない 」これは、コンペを通じて得た最も価値のある教訓の一つです。

振り返って思うこと

結果は悔しいですが、このコンペを通じてデータ品質への向き合い方、モデル選択の戦略、そして「評価基準」と「実用性」のギャップという、実践でしか学べない貴重な経験を得ることができました。Private LB 4位という結果も含めて、参加して得たものは非常に大きかったと感じています。

8. 振り返りと学び

8.1 学んだ重要なポイント

データの品質 > モデルの複雑さ
最もインパクトがあったのは、最新のモデルアーキテクチャを選ぶことではなく、データを丁寧に確認して間違いラベルを訂正することでした。どんなに優秀なモデルを使っても、入力データが間違っていれば正しい結果は出ません。コンペでもプロジェクトでも、まずはデータの品質に時間を投資すべきです。
ドメイン知識が精度を決める何百本もの日本舞踊の動画を見て、各振りの微妙な違いを理解する作業は地味で大変でした。でも、このドメインへの理解がなければ、ラベルの間違いに気づくことも、ラベル15と16の境界が曖昧な理由を理解することもできませんでした。コンペに参加する前に、対象ドメインに浸かる時間を取ることを強くおすすめします。
リーダーボード1位 ≠ 最良のモデル（そして評価基準は主催者が決める
Public LBで最高スコアを出したモデルが、必ずしも一番信頼できるモデルとは限りません。さらに今回の経験で痛感したのは、自分が「正しい」と確信するデータ訂正が、評価基準とは一致しないことがあるということです。テストセットに最適化しすぎると、汎化性能のある堅牢なモデルから離れてしまう危険があります。一方で、「正しさ」を追求しすぎると、コンペの評価基準からずれてしまうこともある。このバランスは本当に難しいですが、最終的には「このモデルは実世界で動くのか？」という視点を忘れないことが大切だと思います。
学習データが推論バイアスを作る
面白い発見がありました。V.1（訂正済み）とV.2（未訂正）で学習したモデルに、まったく同じテスト動画を入力すると、推論結果が異なります：
- V.1モデル：ラベル16と推論（確信度90%）
- V.2モデル：ラベル15と推論（確信度90%）

同じ動画、同じモデルアーキテクチャなのに、学習データが違うだけで、モデルの「信念」が変わるのです。学習データは精度だけでなく、モデルの世界観そのものに影響します。

8.2 次にやるならこうしたい

振り返ってみると、もっと時間をかけるべきだった部分がいくつかあります：

間違っているラベルをもっと広く確認する: ラベル15と16に着目しすぎて、他のラベルペアの誤りを見落とした可能性があります。全ラベルに対してもっと系統的な監査を行うべきでした。
V.2データセットをもっと早く調査する: V.2（ラベル15, 16訂正なし）の方がLBスコアが高いことに最終週に気づいたのは遅すぎました。もっと早くこの発見をしていれば、より深い調査ができたはずです。
クラス不均衡対策の検討: 学習データではラベル15, 16が突出して多く、クラス不均衡対策は気になっていました。しかし、評価データのラベル分布が学習データと同様に偏っているのか均等なのかが不明で、対策の方向性を定めきれず優先度を下げてしまいました。とはいえ、本コンペのデータは一曲の日本舞踊を順番にラベル付けしたものなので、ラベル比率は振りの構成上ある程度決まっており、クラス不均衡対策の効果は限定的だった可能性もあります。
踊り手を変えた際の精度低下を確認: 実世界での適用には、学習データとは異なる踊り手の動画に対して精度がどのくらい落ちるかの検証が不可欠です。

9. まとめ

この記事で紹介したアプローチ（MMAction2によるVideo Transformerのファインチューニング）は、動画分類タスク全般に応用できます。データ品質の確認、フレームサンプリング戦略の設計、アンサンブルの構築 — これらのステップは、コンペに限らず実務プロジェクトでもそのまま使えるノウハウです。動画AIに少しでも興味がある方は、ぜひMMAction2を触ってみてください。事前学習済みモデルとConfigベースの設計のおかげで、思ったよりも早く動画分類の世界に入れるはずです。

10. おまけ — 自分で踊ってモデルを試してみた

記事の最後に、ちょっと面白い実験を紹介します。

コンペが一段落した後、「せっかくモデルを作ったんだから、自分で踊ってみたらどうなるんだろう？」という好奇心が湧いてきました。学習データに含まれている踊り手とは全く別人（しかも日本舞踊の素人）である私が踊った動画を、V.1モデルとV.2モデルにそれぞれ推論させてみたのです。

10.1 実験①：ラベル0の動作（胸の前で手を合わせるポーズ）

実際のラベル = 0 の動作を自分で真似して撮影し、モデルに推論させました。

結果は：

V.1モデル（訂正ありデータセット）: ラベル0と推論（確信度 = 84%） ✓正解！
V.2モデル（訂正なしデータセット）: ラベル0と推論（確信度 = 74%）✓正解！

両方のモデルとも正しく分類できました！ただし、V.1の方が確信度が10%ほど高いのが面白いですね。

10.2 実験②：ラベル16の動作（90°回転してからの動作）

次に、実際のラベル = 16 の動作を真似してみました。ここが面白いところです。