合成データ生成パイプライン実践ガイド — アノテーション工数ゼロで 5,000 枚

1. なぜ合成データが必要か

1.1 工数比較

1.2 合成データが向く問題

• クラス不均衡の是正 — 字牌・赤ドラなど実フレームでの出現頻度が低いカテゴリを均等にサンプル可能
• occlusion / rotation などのエッジケースを系統的に生成 — 「手で隠れた牌」「斜め置きの牌」を意図的に大量投入
• 背景バリエーション — 緑フェルト以外 (木目・赤・青) の卓でも検出可能にする (将来の市販卓対応)

1.3 合成データが向かない問題

• 真の照明変動 / モーションブラー — シミュレーションでは限界がある
• カメラ固有歪み (M-League 特有のレンズ収差・色補正)
• 本番ドメイン特有の人工物 (字幕オーバーレイ・スポンサーバナー)

2. パイプライン全体像

[1. タイル素材ライブラリ]      ← 34 種 × N アングル (PNG, 透過背景)
       │
       ▼
[2. 背景ライブラリ]            ← 10〜30 種 (緑フェルト / 木目 / 単色 / 実フレーム)
       │
       ▼
[3. 配置サンプラ]              ← random / grid / hand-of-13 / discard-row パターン
       │
       ▼
[4. occlusion / rotation]      ← 手で隠す / 斜め / 重ね / 倒し
       │
       ▼
[5. augmentation]              ← brightness, blur, noise, JPEG re-encode, color jitter
       │
       ▼
[6. YOLO ラベル自動生成]       ← 配置時の bbox を YOLO 形式 (cls cx cy w h) で保存
       │
       ▼
[出力: image_NNNN.jpg + image_NNNN.txt 5,000 ペア]

2.1 ディレクトリ構成 (提案)

synthetic/
├── assets/
│   ├── tiles/            # 34 種 PNG (透過)
│   │   ├── m1.png ... m9.png
│   │   ├── p1.png ... p9.png
│   │   ├── s1.png ... s9.png
│   │   └── z1.png ... z7.png
│   └── backgrounds/      # 緑フェルト / 木目 / 実フレーム crop
│       └── *.jpg
├── output/
│   ├── images/           # image_00001.jpg ... image_05000.jpg
│   └── labels/           # image_00001.txt ... image_05000.txt
├── generate.py           # メインスクリプト
└── config.yaml           # クラス定義 / 配置パラメータ

2.2 想定 CLI

# 5,000 枚生成 (フル素材モード)
python scripts/generate-synthetic-mahjong.py \
    --tiles synthetic/assets/tiles \
    --backgrounds synthetic/assets/backgrounds \
    --out synthetic/output \
    --count 5000 \
    --seed 42

# 素材なし procedural モード (素材準備が間に合わない場合)
python scripts/generate-synthetic-mahjong.py \
    --procedural \
    --out synthetic/output \
    --count 2000

3. 先行事例: Augmented Startups Playing Cards

トランプ検出の Roboflow データセット augmented-startups/playing-cards-ow27d は 10,100 枚の合成 + augmentation で 24,240 枚に拡張した代表例。 手法は単純だが効果が高く、麻雀タイルにそのまま転用可能。

3.1 Augmented Startups の手法サマリ

3.2 麻雀との違い

4. 麻雀での実装方針 (34 種 × 10 背景)

4.1 タイル素材の収集

34 種 × 複数アングルの PNG が必要。入手経路:

1. 既存麻雀アプリのスプライト — 雀魂・天鳳のスクリーンショットから crop (要ライセンス確認)
2. Wikimedia Commons の Mahjong tile set — public domain SVG (`File:MJ*.svg`) を PNG 化
3. 手撮り素材 — 実物の麻雀牌セット 1 セットを buy & shoot (¥3,000〜¥10,000)
4. 3D レンダリング — Blender で 34 種モデル + ライティング Variant (上級者向け)

4.2 配置パターン (4 種)

4.3 occlusion / rotation の付与

# 配置後にランダム occlusion を適用
def apply_occlusion(image, bboxes, occlusion_rate=0.15):
    """画像にランダム矩形 (手・腕・他牌) を描画して bbox を一部隠す"""
    h, w = image.shape[:2]
    n_occlusions = np.random.poisson(2)
    for _ in range(n_occlusions):
        ox = np.random.randint(0, w)
        oy = np.random.randint(0, h)
        ow = np.random.randint(40, 120)
        oh = np.random.randint(40, 120)
        color = (np.random.randint(20, 80),) * 3  # 暗色矩形 = 手の影
        cv2.rectangle(image, (ox, oy), (ox+ow, oy+oh), color, -1)
    # bbox の occlusion 率を計算し、>70% 隠れたものはラベルから削除
    return filter_visible_bboxes(image, bboxes, threshold=0.30)

4.4 perspective 変形

def random_perspective(tile_img, max_skew=0.15):
    """牌に台形変形を加えて斜め視点をシミュレート"""
    h, w = tile_img.shape[:2]
    src = np.float32([[0,0],[w,0],[w,h],[0,h]])
    dst = src + np.random.uniform(-max_skew, max_skew, (4,2)) * np.array([w,h])
    M = cv2.getPerspectiveTransform(src, dst.astype(np.float32))
    return cv2.warpPerspective(tile_img, M, (w, h), borderValue=(0,0,0,0))

4.5 YOLO ラベル自動生成

配置時の bbox を YOLO 形式 (正規化中心座標 + 幅高) で保存:

def write_yolo_label(label_path, bboxes, img_w, img_h):
    """bboxes = [(cls_id, x1, y1, x2, y2), ...]"""
    with open(label_path, "w") as f:
        for cls_id, x1, y1, x2, y2 in bboxes:
            cx = (x1 + x2) / 2 / img_w
            cy = (y1 + y2) / 2 / img_h
            bw = (x2 - x1) / img_w
            bh = (y2 - y1) / img_h
            f.write(f"{cls_id} {cx:.6f} {cy:.6f} {bw:.6f} {bh:.6f}\n")

5. procedural mode (素材なしフォールバック)

5.1 procedural モードの設計

1. 背景: 緑フェルト風グラデーション (HSV: H=70±10, S=120±30, V=110±30)
2. 牌: 白い角丸長方形 (60×85 px) + 上部にシンボル文字を描画
3. シンボル文字:
   • 萬子: 漢数字 (一〜九) + 「萬」
   • 筒子: 円マーク × n 個 (Unicode `●`)
   • 索子: 縦線 × n 本 (1 索だけ鳥アイコン代用)
   • 字牌: 東/南/西/北/中/發/白 (1 文字)
4. 影: 各牌の右下に半透明黒矩形でドロップシャドウ

5.2 procedural サンプルコード (短縮)

TILE_LABELS = {
    "m1": "一萬", "m2": "二萬", ..., "m9": "九萬",
    "p1": "①",   "p2": "②",  ..., "p9": "⑨",
    "s1": "鳥",   "s2": "‖",   ..., "s9": "‖‖‖‖‖‖‖‖‖",
    "z1": "東",   "z2": "南",   ..., "z7": "中",
}

def render_procedural_tile(cls_name, size=(60, 85)):
    img = np.full((size[1], size[0], 3), 240, dtype=np.uint8)  # ベージュ
    cv2.rectangle(img, (0,0), (size[0]-1, size[1]-1), (180,180,180), 2)
    label = TILE_LABELS[cls_name]
    # PIL で日本語文字描画 (cv2.putText は日本語不可)
    pil = Image.fromarray(img)
    draw = ImageDraw.Draw(pil)
    font = ImageFont.truetype("msgothic.ttc", 28)
    draw.text((size[0]//2 - 14, size[1]//2 - 18), label, font=font, fill=(40,40,40))
    return np.array(pil)

5.3 procedural モードの限界

6. 既知の限界とドメインシフト対策

6.1 ドメインシフトの正体

合成データで訓練したモデルが実物データで性能を出さない現象は "sim-to-real gap" と呼ばれ、 主に以下の要因による:

6.2 対策 (augmentation 強度を上げる)

# Albumentations による sim-to-real 緩和 augmentation
import albumentations as A

transform = A.Compose([
    A.MotionBlur(blur_limit=(3, 9), p=0.4),           # 動きぼけ
    A.GaussianBlur(blur_limit=(3, 7), p=0.3),
    A.GaussNoise(var_limit=(10, 50), p=0.5),          # センサーノイズ
    A.ImageCompression(quality_lower=50, quality_upper=85, p=0.7),  # JPEG 劣化
    A.RandomBrightnessContrast(brightness_limit=0.3, contrast_limit=0.3, p=0.6),
    A.HueSaturationValue(hue_shift_limit=10, sat_shift_limit=20, val_shift_limit=20, p=0.5),
    A.RGBShift(p=0.3),                                # 放送機器のカラー再現
    A.RandomShadow(p=0.2),
    A.CLAHE(p=0.2),
], bbox_params=A.BboxParams(format="yolo", label_fields=["class_labels"]))

6.3 段階的 augmentation 強度

• P=0.7 の JPEG 圧縮 — 実フレームの主な劣化要因
• P=0.5 の motion blur / noise — 動画キャプチャの劣化を模倣
• P=0.3 程度の色変動 — テレビ放送のカラーグレーディング
• 過度な augmentation は逆効果 — sanity check として augmented サンプルを 50 枚目視確認

7. 実物データとの混合比率

7.1 比率と期待性能 (推定)

7.2 学習スケジュール (2 段階)

1. Stage 1: 合成で warm-up (50 epoch)
   • 5,000 枚合成のみで訓練、汎化を獲得
2. Stage 2: 実物 + 合成混合で fine-tune (30 epoch)
   • 実物 500 + 合成 5,000 をバッチサンプリング比 1:1 でサンプリング
   • learning rate を Stage 1 の 1/10 に

7.3 evaluation の独立性

8. 期待効果と評価方法

8.1 mAP 寄与の期待値 (推定)

8.2 A/B 評価設計

同じ評価セット 100 枚に対して以下 3 モデルを比較:

1. Model A: 公開モデル (ベースライン)
2. Model B: 実物 500 のみで fine-tune
3. Model C: 実物 500 + 合成 5,000 で fine-tune

詳細な評価テンプレートは model-evaluation-template.html 参照。

8.3 デバッグ用 sanity check

• 合成 50 枚をランダムサンプリングして 目視で bbox 整合性を確認
• 合成データのみで訓練した一時モデルの test 性能が 0.10 以上あること (procedural モードでも 0.05 は出ること)
• 合成データのクラス分布が均等であること (各クラス 200 枚以上)

8.4 ROI 試算