要るコマだけ画像にすれば、Claudeに動画を見せられる

画面を人に説明するとき、スクショ（スクリーンショット）ってあったほうが良いじゃないですか？ブログでも、手順書でも、人に聞かれて答えるときでも。「設定画面はここです」「このボタンを押すと」を1つずつ説明していく、あれ。あったほうがいいのはわかるんですよね。

くそだるいんですよね。

自分が作っているものなら Playwright（ブラウザ操作を自動化するやつ）に撮らせればいいんですけどね。他社のサービスだとそこまで手間をかけるのもな～と思いまして。

で、こうしました。動画を1本撮って、Claude に成形してもらう。

この記事で書くのは、なぜ動画のままでは渡せないのか。何を作ったのか。そして、僕がそれをどう使い分けているか。この3つです。

Claude に動画を渡そう！と思うんですが

渡せません。Claude Code に限った話ではなくて、Claude はそもそも動画に対応していないんですよね。

受け取れるのは JPEG / PNG / GIF / WebP の4つです。Claude Code で .mp4 を Read させると、こう返ってきます。

This tool cannot read binary files. The file appears to be a binary .mp4 file.

メッセージは「バイナリだから」と言っていますが、PNG もバイナリです。そして PNG は読めます。つまり動画を狙って弾いているのではなく、読める形式が決まっているだけです。

ちなみに Gemini はそのまま渡せます。これは後で効いてくるので、覚えておいてください。

ここで諦める必要はなくて。動画って、要するに画像の連続じゃないですか。1秒のなかに何十枚も絵が詰まっていて、それがパラパラ漫画みたいに並んでいる。その1枚1枚をフレーム、日本語だとコマと呼びます。

画像は読めるんです。だったら、要るコマだけ画像にして渡せばいい。

そこで作ったのが、動画から指定した場所のコマを取り出して PNG で書き出す CLI と、それを Claude から呼ぶための Skill です。Python で書いていて、使っているのは PyAV と typer、それに書き出し用の Pillow。

やることは2つだけです。動画から狙った位置のコマを取り出して、PNG で書き出す。それだけ。

正直に言うと、ffmpeg が入っている環境なら ffmpeg -i rec.webm -vf fps=1 out_%04d.png の1行で足ります。僕がわざわざ作ったのは、apt install を増やしたくない環境だったからです。逆に言えば、そこにこだわりが無いなら ffmpeg で構いません。

Python には動画を扱うライブラリが他にもあります。それぞれの特徴は、この記事の一番下に付録としてまとめました。

あとは3ステップです。

録る  →  画像にする  →  渡す

画面を録画して、CLI に通して、出てきた PNG を順番に Claude へ読ませる。

僕の使い方は、2つに分かれています

ここからは使い方の話です。同じ道具でも、動画のどこを渡すかで2通りに分かれます。 先に言っておくと、普段よく使うのは2つ目のほうです。

どこが要るか分からないときは、等間隔で切り出す

素朴に考えると、こうなります。どこが要るか分からないんだから、等間隔で全部コマを抜いて、順番に読ませればいい。

手順を丸ごと追いかけたいときは、これで合っています。このときは、まず1秒ごとで試してください。そこから、多すぎたら粗く、足りなかったら細かくする。

何秒ごとが正解、という答えはありません。動画の中身によって変わります。1秒ごとというのは「探索するときの出発点」であって、正解の粒度ではないです。

で、これをやると何が起きるか。

トークンを、クソ喰います。

どのくらい喰うかは計算できて、1枚あたりのトークン数は公式ドキュメントの式で出ます。

⌈幅 ÷ 28⌉ × ⌈高さ ÷ 28⌉

あとは枚数を掛けるだけです。1280×1000 を40枚なら、約68,000トークン。手元で実測しても式と一致しました。しかも渡した画像は会話に残るので、そのあと何往復かすれば入力側はこの何倍かになります。

尺にも気をつけてください。1秒ごとなら1分で60枚、3分で180枚。1回に渡せる枚数にも上限があるので、長い録画は範囲を切る。丸ごと処理できるのは数分までだと思っておけば大きく外しません。

秒が分かるなら、その1枚でいい

ここで戻ります。そもそも、40枚も渡す必要ありますか？

覚えておいてくださいと言った話が効いてくるのはここです。Gemini は動画をそのまま渡せます。 そこそこ大きいファイルでも受け取ってくれる。

だったら、探すほうは Gemini にやらせればいい。動画ファイルを渡して、会話しながら「何秒のところ？」を出させる。「設定を保存したのは何秒ですか」と聞けば返ってきます。

あとはその秒だけ、Claude 用に切り出す。

40枚渡すのと、3枚渡すのとでは、桁が違いますからね。動画を読めるモデルに探させて、読めないモデルには答えだけ渡す、という分担です。

僕が普段やっているのはこっちです。

並べてみると、道具に求めるものが違う

この2つ、要件で見ると別物なんですよね。

上は1枚か数枚抜くだけなので、要件も1つで足ります。下は違う。40枚を順番に読ませることが前提になるので、順序も、枚数も、事前の確認も、全部が要件になる。

つまり、要件は道具の性能ではなく、使い方から出てきます。「等間隔に切り出せること」は、機能一覧を眺めていても出てきません。「どこが要るか分からないまま渡す」という使い方を決めて、初めて出てくる。

ここで言いたいこととしては、自分で作るAI用のCLIはメンテしていく必要があるんで要件を詰めて必要なものを作って継続的にメンテしていこうね！って話です。

だから僕は、コードを配るのをやめました。配るのは要件です。環境も好みも人それぞれなので、それを AI に読ませて自分の環境で作らせたほうが早い。この記事の付録がそれです。

正直、使わなくていい場面もあります

ここまで書いておいてなんですが、僕もいまだに使い分けています。こういうときは、画像に変えていません。

• そもそも Playwright で足りるなら、それでいい。自分が開発している画面はだいたいこれです
• 動画のままでいい。 見せる相手が人間なら、画像に変える理由がありません。YouTube に上げて記事に埋めるほうが早い
• 動画ですら要らない。 1回しか映らない画面を見せたいだけなら、スクショ1枚で終わりです

1つ目に補足が要ります。他社のサービスでも Playwright は使えるんですよ。使えるんですが、検証中はどこを撮ればいいか自分でも分かっていない。撮る場所を先に指定できないなら、自動化しても嬉しくないんですよね。

Playwright に頼れないときの判断の軸はこうです。映る画面が分かっていて、しかも動きが無いなら、動画にする必要はありません。どちらか一方でも崩れたら、動画にしたほうが早い。

で、結局なにができるようになるのか

動画を渡せない前提で動いていたときは、「どこを撮るか」を撮る前に決めるしかありませんでした。 撮り終わってから「あそこも要ったな」と気づいても、もう一度操作をやり直すしかない。

Claude が動画を受け取れるようになったわけではないです。でも、画像に変える経路ができた時点で、撮り方の制約のほうが消えます。

「どこを撮るか」を、撮る前に決めなくてよくなりました。

これが一番大きいです。記事を書いている最中って、まだ検証中なんですよ。どの瞬間が素材として使えるか、撮る前には分からない。触って、返ってきて、それを見て初めて「ああ、ここか」となる。

動画にしておけば、分かってから選べます。「やっぱりここも要る」となっても、同じ動画から抜き直せる。

そしてもう1つ。撮った動画は、あとからいくらでも使い回せます。

実際にやったのは、この3つです。

• 記事の素材にする。 Gemini でスプレッドシートを触る検証をしたときは、操作をまるごと録っておいて、あとから必要な場面だけ画像にして記事に貼りました。記事に載っている画面は、全部その動画から抜いたものです
• 手順書を起こす。 業務アプリの操作を1手順ぶん録って、40枚に切り出して、正解を知らない別の AI に「この画像から手順書を書いて」と渡しました。 返ってきた手順書に「保存されたかどうかが画面から判別できない」と書いてあったので実物を見にいったら、アプリのバグでした。テストは緑だったのに、です
• 自分の姿勢を見てもらう。 ジムで「このフォーム合ってる？」となったとき、14秒だけ撮って渡す。返ってきたのは「頭・腰・かかとは一直線。ただし体が立ちすぎで、床から見て60〜65度くらい」でした（ジムで Claude にコーチをやらせている話もあります）

3つとも、渡しているのは画像です。やっていることは同じで、被写体が違うだけなんですよね。

画像にした先で何ができたかは、別の記事で1つずつ書きます。（予定）

最後に正直なところを1つだけ。これは効率化ではなく、人間の手間をトークンで買っているという話です。僕はそれで釣り合うと思っていますが、判断は分かれると思います。

まずは手元の動画を1本、読めるモデルに投げて「何秒のところ？」と聞いてみてください。そこが決まらないときだけ、等間隔で切り出せばいい。

付録：動画からコマを切り出すツールの要件

以下をまるごとコピーして、AI に「これを満たすものを作って」と渡してください。言語も構成もお好みで構いません。

できあがったら、秒数が画面に写っているもの（時計・タイマー・動画プレイヤーの再生位置）で試してみてください。指定した秒と、出てきた画像に写っている秒が一致するか。ここがズレる実装は、黙って近くのキーフレームに寄っています。

僕が動かしている環境

要件のほうにバージョン番号は書いていません。値は環境と時期で腐るので、性質だけにしてあります。参考までに、僕の手元はこれです（2026年8月時点）。

• Python 3.12
• PyAV 16.1.0 / Pillow 12.3.0 / typer 0.24.1
• 録画はブラウザの画面収録（webm）

この要件自体も、記録からではなく動いている実物から起こしました。

何をするものか

動画ファイルから、指定した時点のフレームを画像として取り出すコマンドラインツール。

全体に効くこと

• 実行環境に追加のシステムパッケージを要求しないこと。 デコーダを同梱した言語パッケージだけで完結させる
• 出力は AI が読める画像形式（PNG / JPEG）。どちらで出すか選べること
• 動画のメタデータを表示できること（尺・fps・解像度）。切り出す前に「何秒あるのか」が分からないと粒度を選べない
• 尺が取れない動画で、黙って推測しないこと。 形式によっては映像トラック側に尺が無く、コンテナ側にしか無い。順に探して、どこにも無ければ失敗させる。ここを推測で埋めると、以降の計算が全部静かにズレる
• 入力が無い・壊れている・範囲外を指定した。これらは、すべて明示的なエラーで落とすこと

使い方A：どの秒を見たいか分かっているとき

• 秒数を指定して、その時点のフレームが取れること。 複数の秒をまとめて指定できること
• 指定した秒に正確に届くこと。 多くのデコーダはキーフレーム単位でしか飛べないので、飛んだあと目的の時刻までデコードを進める実装ができること。シークに渡す値の単位にも注意（秒とは限らず、例外も出ずに見当違いの位置へ着地する）
• 出力先はファイル1つでも、ディレクトリでも指定できること。無ければ作ること
• その時刻がファイル名に入っていること

使い方B：どこが要るか分からず、手順を追いかけたいとき

• 等間隔に切り出せること。 指定の仕方は3通りあり、そのうち必ず1つだけを受け付けること
  • 秒間隔（N 秒ごと）
  • fps（1秒あたり N 枚。秒間隔の逆数と同じ結果になること）
  • 総枚数（範囲を等分して N 枚。両端を含む。1枚と言われたら開始点だけ返す）
  • 0個でも2個以上でもエラーにする。 黙ってどれかを優先すると、指定したつもりの粒度と違うものが出る
• 範囲を切れること（開始・終了）。録画の冒頭は起動待ちで何も写っていないことが多く、そこに払う理由がない
• 割り切れない間隔でも、終端を越えないこと
• ファイル名の辞書順が時間順と一致すること。 連番をゼロ埋めで先頭に置く。ファイルの列挙は辞書順で返り、その順のまま読ませることになるので、ここが崩れると手順の順序が崩れる
• 枚数に上限があり、超えたら1枚も書かずに止まること。 粒度を1段細かくすると枚数は一気に増える。途中まで書いて止まると後始末が要る。止めるときは対処法まで出す（粗くする / 範囲を狭める / 上限を上げる）
• 切り出す前に、何枚になるかを確認できること。 しかも、フレームをデコードせずに答えること。粒度選びは試行錯誤になるので、毎回デコードを待たされると選べない
• 何枚になるかを表示するとき、全部は並べないこと（先頭だけ出して残りは件数で示す）
• 一般的な録画形式が通ること。 ブラウザの録画出力は MP4 とは限らず、尺の求め方が形式ごとに違う

作らなくていいもの

• 動画の編集・変換・フォーマット変換
• GUI
• シーン変化の自動検出（等間隔で足ります）

参考：動画を扱う Python ライブラリの特徴

「追加インストールを増やさない」を最優先にすると、上2つが残ります。そのうえで使い方Aを満たすなら、シーク後の位置を自分で制御できるかで選んでください。