画面を人に説明するとき、スクショ（スクリーンショット）ってあったほうが良いじゃないですか？ブログでも、手順書でも、人に聞かれて答えるときでも。「設定画面はここです」「このボタンを押すと」を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⌉ 解像度 1枚あたり 1280 × 720 約 1,200 1280 × 1000 約 1,700 1920 × 1080 約 2,700 あとは枚数を掛けるだけです。1280×1000 を40枚なら、約68,000トークン。手元で実測しても式と一致しました。しかも渡した画像は会話に残るので、そのあと何往復かすれば入力側はこの何倍かになります。 尺にも気をつけてください。1秒ごとなら1分で60枚、3分で180枚。1回に渡せる枚数にも上限があるので、 長い録画は範囲を切る 。丸ごと処理できるのは数分までだと思っておけば大きく外しません。 秒が分かるなら、その1枚でいい ここで戻ります。 そもそも、40枚も渡す必要ありますか？ 覚えておいてくださいと言った話が効いてくるのはここです。 Gemini は動画をそのまま渡せます。 そこそこ大きいファイルでも受け取ってくれる。 だったら、探すほうは Gemini にやらせればいい。動画ファイルを渡して、 会話しながら「何秒のところ？」を出させる 。「設定を保存したのは何秒ですか」と聞けば返ってきます。 あとはその秒だけ、Claude 用に切り出す。 40枚渡すのと、3枚渡すのとでは、桁が違いますからね。 動画を読めるモデルに探させて、読めないモデルには答えだけ渡す 、という分担です。 僕が普段やっているのはこっちです。 並べてみると、道具に求めるものが違う この2つ、 要件で見ると別物なんですよね。 使い方 要る要件 秒が分かっている （Gemini に出させた、または見当がつく） 秒数を指定して、 そのコマが正確に取れる こと 手順を追いかけたい （どこが要るか分からない） 等間隔に切り出せる / 順序が保たれる （ファイル名の並び＝時間の並び） / 枚数に上限がある / 切り出す前に枚数を確認できる / 録画形式が通る 上は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 ライブラリの特徴 特徴 PyAV FFmpeg のバインディング。デコーダ同梱でシステムへの追加インストールが要らない。低レベルなので、シーク後にどこまで進めるかを自分で制御できる OpenCV （headless 版） 同じくデコーダ同梱で追加インストール不要。API がシンプルで扱いやすい。シークの精度は用途によって確認が要る ffmpeg を直接呼ぶ 挙動は最も素直。ただし ffmpeg 本体のインストールが必要 moviepy 高レベルで書きやすい。こちらも ffmpeg 本体が必要 「追加インストールを増やさない」を最優先にすると、上2つが残ります。そのうえで使い方Aを満たすなら、 シーク後の位置を自分で制御できるか で選んでください。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 要るコマだけ画像にすれば、Claudeに動画を見せられる first appeared on SIOS Tech Lab .

はじめに CIU (CyberAgent group Infrastructure Unit) の ...

2026 年 8 月 5 日、 Amazon DynamoDB でのベクトル検索の一般提供についてお知らせします。運用データとともにベクトル埋め込みを DynamoDB に保存し、別のベクトルストアにデータを複製することなく、そのデータに対して直接類似度検索を実行できるようになりました。 DynamoDB は、99%以上の再現率を維持しながら、1桁ミリ秒のレイテンシーでネイティブなベクトル検索をサポートします。また、数兆個のベクトルを含む大規模なデータにも対応できるよう設計されています。サーバーのプロビジョニング、パッチ適用、管理は一切不要で、ソフトウェアのインストール、保守、運用も必要ありません。このサービスにはバージョンの管理がなく、メンテナンスウィンドウも設定されておらず、メンテナンスによるダウンタイムもゼロです。 ベクトルインデックスにはストレージ容量の制限がなく、データの増加に応じて水平方向にスケールします。DynamoDB のネイティブなベクトル検索を利用することで、エージェント型メモリ、検索拡張生成（RAG）、レコメンデーションエンジン、パーソナライズされたエクスペリエンス、異常検知など、セマンティック検索を必要とするアプリケーションを構築できるようになりました。 アプリケーションですでに DynamoDB を使用している場合、これまではベクトル検索を追加するために、データを専用のベクトルデータベースにコピーし、2つのサービス間でデータを同期するパイプラインを維持する必要がありました。これにより、運用上のオーバーヘッド、データ移動コスト、ライセンスコストが増加し、さらに大規模環境で予測可能な低レイテンシーを維持するという課題も生じていました。DynamoDB にベクトル検索が組み込まれているため、ベクトルデータと運用データを同じサーバーレスインフラストラクチャ上で管理し、同じ従量課金（リクエスト単位の課金）モデルを利用できます。 DynamoDB のベクトル検索では、ベクトル埋め込みを格納する属性に対して作成する新しいタイプのインデックスが導入されています。任意のモデル（Amazon Bedrock Titan Text Embeddings、Cohere Embed、OpenAI のテキスト埋め込みモデルなど）を使用して埋め込みを生成し、標準の PutItem 呼び出しを使用して、浮動小数点数のリストとしてテーブルに保存できます。次に、その属性に対してベクトルインデックスを作成し、次元数、距離関数、およびクエリ実行時に検索結果を絞り込むためのフィルターとして使用する非ベクトル属性を指定します。 SearchVectors API は、クエリベクトル、返される結果の数 (最大 100)、およびオプションのフィルター条件を受け入れます。類似度でランク付けされた結果を返します。 運用データがすでに DynamoDB に存在していて、別のデータベースをプロビジョニングしたり、同期パイプラインを管理したりせずに類似検索を追加したい場合は、DynamoDB のベクトル検索を使用してください。DynamoDB は完全にサーバーレスなので、ベクトル検索はインフラストラクチャを管理しなくても自動的にスケーリングされます。最大 4096 次元、ユークリッド、コサイン、ドット積の距離関数、およびインラインフィルタリングをサポートします。 DynamoDB でのベクトル検索入門 このチュートリアルでは、 DynamoDB コンソール を使用して既存の DynamoDB テーブルにベクトル検索を追加する方法を示します。このシナリオには、製品カタログテーブルを備えたオンラインスポーツ用品店が含まれています。各アイテムには、 ProductID 、 カテゴリ 、 説明 、 マーケットプレイス 、 名前 、 価格 などの標準的な操作属性があります。目的は、セマンティック検索を追加することで、購入者が完全一致するキーワードではなく、自然言語によるクエリを使って商品を検索できるようにすることです。 1.DynamoDB テーブルを準備する セマンティック検索を有効にするために、まずテーブルにすでに保存されている商品説明のベクトル埋め込みを生成します。埋め込みとは、機械学習モデルによって生成され、テキストの内容が持つ意味を捉えた数値表現です。説明が似ている2つの項目は、ベクトル空間上で互いに近い位置にある埋め込みを持つため、これによって類似度検索が可能になります。 Amazon Bedrock Titan Text Embeddings やその他の埋め込みモデルを使用して埋め込みを生成し、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDK 、 AWS CloudFormation 、またはその他の IaC ツールを使用して、それらをテーブルに追加できます。 既存の ProductCatalog のようなテーブルでは、 UpdateItem 呼び出しを使用して、各項目に descriptionEmbedding という新しい属性として埋め込みを追加します。DynamoDB は、既存の List データ型を使用してベクトル埋め込みを格納します。リストの各要素は、埋め込みベクトルの単一の浮動小数点数を表す 数値 です。つまり、既存の運用データの属性と一緒にベクトルを保存するために、新しいデータ型を導入したり、スキーマを変更したりする必要はありません。 2.ベクトルインデックスの作成 DynamoDBコンソール で ProductCatalog テーブルを開き、 インデックス タブを選択します。 ベクトルインデックスを作成 を選択します。 ベクトルインデックスを作成 ページでは、次のようにインデックスの詳細を入力します。 インデックス名 として ProductDescriptionIndex 、 ベクトル属性 として descriptionEmbedding を入力します。 埋め込みモデルの出力と一致する 次元数 を入力し、 距離関数 として コサイン を選択します。コサインはベクトルの大きさではなく角度を測定する指標であり、そのためテキスト埋め込みの意味的類似性を比較するのに有効です。DynamoDB のベクトル検索では、コサイン に加えて、 ユークリッド距離 と ドット積 の距離関数もサポートされています。 ユークリッド :購入回数などの数値でアイテムをクラスタリングする場合など、ベクトルの大きさが意味のある場合に使用します。 ドット積 :方向と大きさの両方が重要な場合に使用します。たとえば、関心の位置合わせと周波数を一緒に重み付けするレコメンデーションシステムの場合などです。原則として、距離関数を埋め込みモデルのトレーニングに使用した関数と一致させると、精度が最も高くなります。 パーティションキー として マーケットプレイス に入ります。ベクトルインデックスのパーティションキーは、DynamoDB がベクトルを各パーティションにどのように分散配置するかを制御するものであり、予測可能な低レイテンシーを維持しながら、インデックスを水平スケールアウトできるようにします。各検索は1つのパーティションキー値を対象として実行されます。そのため、複数のマーケットプレイス向けの商品カタログであっても、インデックス全体をスキャンすることなく、特定のマーケットプレイスの在庫のみを検索できます。パーティションキーは必須ではありませんが、大規模なデータセットやクエリスループットが高いワークロードでは、使用することが推奨されます。 インラインフィルター属性 を展開し、 フィルター属性としてカテゴリ を追加します。これにより、クエリ時に検索結果を特定の製品カテゴリに絞り込むことができます。フィルター条件では、完全一致の値のみサポートされます。 BETWEEN や BEGINS_WITH のような範囲条件はサポートされていません。検索結果にすべてのテーブル属性が含まれるよう、 属性の投影 は すべて に設定したままにしています。 ベクトルインデックスを作成 を選択し、インデックスのステータスが アクティブ に変わるまで待ちます。 3.ベクトル検索を実行 商品説明に使用したのと同じ埋め込みモデルを使用して、「 夏用の軽量ランニングシューズ 」などの自然言語検索用語からクエリベクトルを生成します。DynamoDB コンソールでは、左側のナビゲーションペインで 項目を検索 を選択し、 ProductCatalog テーブルを選択します。 検索 を選択してベクトル検索モードに切り替えます。 ベクトルインデックスを選択 ドロップダウンから ProductDescriptionIndex を選択し、クエリベクトルを 検索ベクトル フィールドに貼り付け、 結果の数 (上位 K) を 5 に設定します。 パーティションキー値 として US と入力して、検索範囲を米国のマーケットプレイスに限定します。  インラインフィルター属性を拡張し 、 カテゴリ を フットウェア と同じに設定して、検索をフットウェア製品のみに絞り込みます。最後に、 実行 を選択します。 DynamoDB は、フットウェアカテゴリ内で意味的に最も類似している5件の商品を、類似度スコアの高い順に返します。また、そのレスポンスには、商品名や価格などの通常の運用データ属性もあわせて含まれます。類似度スコアの意味は、インデックスに選択した距離関数によって異なります。コサイン距離関数とユークリッド距離関数では、類似度スコア値が低いほど類似度が高く、スコアが 0 の場合はベクトルが同一であることを示します。点積距離関数では、類似度スコアの値が高いほど類似度が高くなります。 API の呼び出しやドキュメントの検索など、ベクトル検索をプログラムで操作するには、お好みの AI コーディングツールで AWS MCP サーバー と プラグイン を試してください。 詳細については、 Amazon DynamoDB 開発者ガイドをご覧ください 。 今日から始めよう Amazon DynamoDB のベクトル検索は、一般的に AWS GovCloud (米国) リージョンを含むすべての商用 AWS リージョンで利用できます。リージョンごとの提供状況や今後のロードマップについては、 AWS のリージョン別提供機能 にアクセスしてください。料金の詳細については、 Amazon DynamoDB 料金表ページ をご覧ください。 ぜひ 8 月 5 日から DynamoDB のベクトル検索をお試しください。ご意見やご要望は、 Amazon DynamoDB の AWS re:Post 、または通常ご利用の AWS サポート窓口までお寄せください。 – Esra 原文は こちら です。