Claude Codeの動画解析を使いこなす：/watch-videoの深層と最適化戦略

エンジニアの現場において、新しいツールやライブラリを導入する際、我々はしばしば「魔法のような自動化」を期待してしまう。Claude Codeの/watch-videoスキルもその一つだ。「動画を渡せば、文字起こしから重要フレームの抽出、画像解析、構造化ノート作成まで全自動でやってくれる」という触れ込みは、忙殺される開発者にとってあまりに魅力的だ。しかし、実際にソースコードや仕様を深掘りしてみると、そこには「魔法」ではなく、極めて現実的かつエンジニアリング的な「トレードオフの設計」が存在していることに気づかされる。

結論から言えば、/watch-videoは単一の処理フローではない。ユーザーが明示的に選択すべき「3つの深さ」を持つモード設計が本体であり、既定値であるtranscriptモードは、あくまで文字起こしとメタデータ抽出に特化した軽量な処理に過ぎない。多くのユーザーが「画像解析までやってくれるはずなのに、なぜかテキストしか出てこない」という壁にぶつかるのは、この設計思想を理解していないからだ。我々エンジニアがこのツールを真に使いこなすためには、動画の性質に応じてモードを切り替えるという「判断」が不可欠である。

以下に、このスキルが提供する3つのモードの守備範囲とコスト構造を整理した。この表を見れば、単に「全部入り」を期待することがいかに非効率であるかが一目瞭然だろう。

特に注意すべきは、10分を超える動画に対する挙動だ。visual以上のモードを選択した場合、コスト増大を避けるために処理前に必ず確認が入る。これは「投げっぱなしで全部やってくれる」というAIエージェントの理想像とは対極にある、極めて堅実な「ガードレール」である。開発現場において、意図しないAPIコストの爆発や、不要な計算リソースの浪費を防ぐためのこの設計は、むしろ信頼に値する。我々は、AIを「何でも屋」として扱うのではなく、コストと成果のバランスを制御可能な「ツール」として再定義しなければならない。

では、具体的にどのような基準でモードを選択すべきか。ここには、動画の内容に対する深い洞察が求められる。例えば、講演やポッドキャストのように「音声情報が主」であるコンテンツに対し、visualモードを適用するのはリソースの無駄遣い以外の何物でもない。逆に、UIデザインのレビューやデモ動画においてtranscriptモードしか使わないのは、情報の半分以上を捨てているに等しい。画面共有の操作ログや、クリックの瞬間といった「視覚的コンテキスト」こそが本体である場合、visualモードのフレーム抽出は不可欠な武器となる。

さらに興味深いのは、フレーム抽出の間隔が動画の種類に応じて自動的に最適化される点だ。画面共有やデモ動画では5秒に1枚という高頻度で抽出が行われる一方、トーキングヘッド（話しているだけの動画）では30秒に1枚まで間隔が広がる。この「文脈に応じたサンプリングレートの可変」は、地味ながらも非常に洗練された実装だ。無駄なフレームを解析してClaudeのコンテキストウィンドウを汚染するリスクを最小化しつつ、必要な情報密度を確保する。この挙動を知っているか否かで、AIから得られる回答の質は劇的に変わる。

また、文字起こしエンジンが「プラットフォームの字幕」を最優先し、次にMLX-Whisper（Mac Mシリーズ向け）、最後にwhisper.cppとフォールバックする多段構えの設計も特筆すべき点だ。YouTube動画のように既に完全な字幕が存在する場合、Whisperを回す必要はない。この「既存資産の再利用」を徹底する設計は、処理速度の向上だけでなく、無駄な推論コストを削ぎ落とすという点でも極めて合理的である。導入にあたっては、yt-dlpやffmpegといった外部ツールが必須となるが、これらは動画解析のパイプラインを構築する上での「標準的なインフラ」と捉えるべきだ。

最後に、このスキルが単体で完結するものではなく、/decideや/pmといった他のスキルへ情報を橋渡しする「Maker Skills」の一部であるという事実に注目したい。動画を見て終わりではなく、そこから抽出されたアクションアイテムをどう管理し、どう実行に移すか。この「ワークフローへの統合」こそが、AIエージェントを単なるチャットボットから「実務のパートナー」へと昇華させる鍵である。我々は、動画を解析した後の「その先」のプロセスをどう設計するか、という問いに直面している。