菜单
人手動画アノテーションを映像証拠から作成・監査し、既存データでは高品質例を校正に使って低tIoU項目を診断・改善し、十分な品質になったら新規動画の取得と注釈へ展開する。Temporal Grounding用GT、イベント定義、時間区間、低精度データの改善、未注釈動画の追加、動画アノテーションの一括処理を依頼されたときに使う。既定は1動画・1イベント・1区間だが、ユーザー指定の契約へ切り替えられ、特定のリポジトリ、モデル、動画形式、schemaには依存しない。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | annotate-video-events |
| description | 人手動画アノテーションを映像証拠から作成・監査し、既存データでは高品質例を校正に使って低tIoU項目を診断・改善し、十分な品質になったら新規動画の取得と注釈へ展開する。Temporal Grounding用GT、イベント定義、時間区間、低精度データの改善、未注釈動画の追加、動画アノテーションの一括処理を依頼されたときに使う。既定は1動画・1イベント・1区間だが、ユーザー指定の契約へ切り替えられ、特定のリポジトリ、モデル、動画形式、schemaには依存しない。 |
映像上の事実を正解とし、tIoUを改善サイクルの明確な品質ゲートとして使う。高tIoUを目的にGTをpredictionへ寄せてはいけないが、GTを永久固定する必要もない。映像の再監査で誤りが見つかればイベント定義と区間を新revisionへ直し、必ず再推論して確かめる。既存データの改善、新規アノテーション、両方を扱う。
開始前に次を確認し、短い作業メモへ固定する。
指定がなければ 1動画・1イベント・1区間、half-open interval [start_s, end_s)を使い、評価可能な全対象でtIoU 0.5以上を必須ゲートとする。平均値だけが0.5以上でも、個別対象が0.5未満なら未完了とする。ユーザーが別の閾値、複数イベント、複数区間を求めた場合だけ契約を明示的に変更する。
媒体を読めない、時刻へ変換できない、利用条件を確認できない、または保存先が不明なまま破壊的な上書きが必要な場合だけ停止する。
既存データがある場合、最新のGT revisionと互換性のあるpredictionだけで評価を再計算する。動画ごとに次を一覧化する。
video_id | GT revision | event count | mean tIoU | review status | prediction compatibility
次の順で処理対象を作る。
tIoUは優先順位であり、GT品質の証明ではない。高tIoUでも映像と不一致なら校正例に使わず、低tIoUでも映像上正しいGTをモデルへ合わせて変更しない。
上位から代表的な5〜10件を候補にし、映像を再確認して次を満たすものだけを校正例にする。
校正例から、イベントの粒度、開始条件、終了条件、文の具体性を短いルールにする。時刻そのものや対象動画固有の文言はコピーしない。
各動画を直列に処理する。対象ごとに実推論と評価を行い、tIoUが0.5以上になってから次へ進む。0.5未満のまま「改善完了」として扱わない。
元動画hash、GT revision、使用query、raw prediction、モデルrevision、評価値を保存する。完了済みrunは上書きせず、新しいrun IDを使う。GTとpredictionを同じファイルへ保存しない。
最初はprediction区間とtIoUを見ずに、動画全体を疎に走査する。候補区間とその前後は全annotation frameまたは利用可能な細粒度フレームを時系列に見る。
既定の単一イベント契約では、次をすべて満たす候補を選ぶ。
適格なイベントがなければ捏造せず skip: no_eligible_event とする。複数イベント契約では、各イベントに同じ映像証拠の基準を適用する。
イベント文は「誰が・何を・どうする」を基本に、識別に必要な対象物、道具、手段、方向、置き場所を加える。意図、成功、品質、危険性など画面から確認できない状態は書かない。
start_s: 定義した動作が最初に視認できる時刻end_s: 定義した動作が終了した後の最初の時刻元GTが映像証拠と一致するなら、そのrevisionを次の推論中だけ固定する。一致しない場合は、根拠フレームと変更理由を残してイベント定義、開始、終了を新しいrevisionへ修正する。schemaがcurrent pointer方式なら最新版を更新してよいが、旧revisionと旧評価の追跡可能性は失わない。
利用可能なら、粗い走査、境界精査、最終レビューをサブエージェントへ分担する。サブエージェントにはprediction、tIoU、期待する修正方向を渡さず、ファイルも編集させない。コーディネータだけが最終案を保存する。
サブエージェントを使えない場合は、predictionを見ない独立した2パスで再確認する。境界案が1 annotation frameを超えて食い違う場合は該当フレームを再確認し、解消しなければ needs_review とする。
各ラウンドで使用するGTをrevisionまたはhashで特定し、必ず対象モデルで実推論する。推論せずにイベント文や区間だけを更新して完了してはいけない。
高品質例は、queryの構造や具体性の校正に使う。対象物、道具、手段が曖昧なら具体化し、動作の中心しか検出しないなら開始から終了までを表す。ただし、正解時刻、秒数、prediction区間をqueryへ入れない。
任意の反復回数で打ち切らない。0.5未満なら次のラウンドを計画し、query、イベント定義、GT境界、フレームサンプリング、推論設定のうち未検証の原因へ移る。同じ変更を繰り返さず、各ラウンドの仮説と結果を記録する。映像上正しいGTを保ったままモデル上限で改善できない、適格なイベントが存在しない、媒体や計算資源を利用できないなど、正解を捏造せずには進めない場合だけ blocked または needs_review とし、0.5未満の値、試した変更、必要な次の条件を明示する。
全runと変更理由を残し、同じ動画で調整した値はdevelopment値として報告する。高いtIoUを持つ動画のイベント粒度、境界条件、query構造を参考にしてよいが、時刻や固有文言をコピーしない。
ユーザーが新規追加を指定した場合に進む。指示がなければ既存の0.5未満対象の改善を続け、勝手に動画をダウンロードしない。新規動画も既存動画と同じGT監査、実推論、tIoU 0.5ゲートへ入れる。
利用条件が不明な動画、個人情報や機密情報を含む動画、重複動画は追加しない。ログやmanifestへローカル絶対パス、token、cookieを残さない。
指定schemaがなければ次の最小形式を使う。
{
"video_id": "clip_001",
"interval_convention": "half-open_seconds",
"event_labels": {"event_001": "観測可能な動作"},
"events": {"event_001": [{"start_s": 2.0, "end_s": 7.0}]}
}
保存後に次を機械的に検証する。
0 <= start_s < end_s <= duration処理後は最低限、次を数字で報告する。
対象数 / 0.5以上 / 0.5未満 / GT変更 / queryのみ変更 / skip / needs_review
変更前mean tIoU / 変更後mean tIoU / 最小tIoU / 反復回数
新規取得数 / 新規注釈数 / 検証失敗数
英訳は各GT revisionを確定した後に推論queryとして作成し、元の人手イベント文を置き換えない。