Moonshot AI の Kimi K3 は、API に動画ファイルをそのまま渡せます。Claude には動画の入力がないので、私はふだん動画をフレーム画像に切り出してから読ませています。Codex CLI も、K3 をつないだ場合でさえ動画を渡す口がありません (Kimi API: Codex で使う)。

この記事で使った Kimi API のクレジット ($50) は、Moonshot AI から評価用に提供されたものです。評価の設計・実行・結論に Moonshot AI は関わっていません。K3 ができなかったことや、うまく動かなかった機能もそのまま書いています。

この記事は kenimoto.dev に掲載した記事を Qiita 向けに再構成したものです。記事内の動画は kenimoto.dev 版で再生できます。

この差が実務でどれくらい効くのかを、手元の題材で確かめました。題材は、kenimoto.dev の /learn/ SSH接続の5方式シリーズを紹介する 40〜50 秒のハンズオン動画です。

分かったことは4つです。

「何が悪いか」の判断は、K3 と Claude でほぼ一致しました。 冒頭の離脱ポイント、改善案6つの中身、図を差し込む位置、先に出すべき動画まで同じでした
差が出たのは、時刻の精度と手間です。 K3 は「画面が止まっている区間」を秒未満の単位で指摘し、こちらは動画を1回渡すだけで済みました。Claude は 2 秒おきのフレームから推定しているので、時刻に ±1 秒のずれが出ます
K3 は音声を理解しません。 ナレーションの中身や音ズレは見られません
速さは Claude が上でした。 同じ依頼で K3 は 363 秒、Claude は 185 秒でした

題材: 自動生成したハンズオン動画

動画は、私が作っている handson-cast という CLI で自動生成しています。手順を書いた JSON を渡すと、コマンドを Docker のコンテナで実際に実行しながら、vhs でターミナルを録画します。そこに OpenAI の音声合成でナレーションを付け、字幕を焼き込んで 1 本の mp4 にします。中身は Python と ffmpeg です。

今回作ったのは2本です。

鍵認証の章 (55 秒): 鍵を作る → 公開鍵を置く → 鍵だけで入れるか確かめる → パスワード認証を止める
踏み台の章 (47 秒): 同じ鍵なのに ssh -J だと踏み台に拒否される → ~/.ssh/config なら通る

ターミナルに出ている出力は、OpenSSH 10.0p2 のコンテナで実際に実行したものです。演出はありません。拒否メッセージが (publickey,password) から (publickey) に変わるところも、録画の中で本当に起きたことです。

ただ、最初の版 (v1) は見てもらえる動画ではありませんでした。冒頭1秒は、録画用の内部スクリプト bash /lab/ssh-config.step-01.sh を打っている画面です。何の動画なのか分かりません (作った本人が見返しても分かりませんでした)。

最初の版 (v1、47 秒、音声あり) です。

画像をクリックすると mp4 が開きます (音声あり)。

この v1 を K3 と Claude に見せて、どこが悪いかを聞きました。

K3 に動画を渡す方法と費用

K3 の API は OpenAI 互換です。動画は先にファイルとしてアップロードし、返ってきた ID を ms:// 付きでメッセージに入れます。

from openai import OpenAI
client = OpenAI(api_key=KEY, base_url="https://api.moonshot.ai/v1")

f = client.files.create(file=Path("learn-ssh-key-auth.mp4"), purpose="video")
r = client.chat.completions.create(
    model="kimi-k3",
    max_tokens=32000,
    messages=[{"role": "user", "content": [
        {"type": "video_url", "video_url": {"url": f"ms://{f.id}"}},
        {"type": "text", "text": "この動画の冒頭3秒で離脱される理由は？"},
    ]}],
)

公開 URL は渡せません。公式ドキュメントでは、動画は「キーフレームの集まり」として扱われ、解像度が高いほどトークンも増えます (Kimi API: Vision)。

最初に、55 秒・1920×1080 の動画1本で測りました。

項目	実測
入力トークン	40,659 (ほぼ全部が動画)
出力トークン	2,500 (うち推論 1,912)
費用	約 $0.16
所要	83.5 秒

単価は入力 $3、出力 $15 (いずれも 100 万トークンあたり) で計算しています。

ここからは、実際に動かして分かった、K3 に動画を渡すときのコツを 2 つ共有します。

音声は理解しない前提で使う

このとき、字幕を焼き込んでいない版を作り、ナレーションの最後の一文を書き起こすよう頼みました。返ってきたのは「音声は認識できない」です。聞こえないものを聞こえたふりをしないのは、レビュアーとして信用できるところです。ただし、ナレーションの内容や、字幕と音声のズレは K3 には見えません。 見られるのは画面と、焼き込んだ字幕だけです。

画面は読めます。それも正確に。4 ステップ分のコマンドと出力を時系列で拾い、権限の 600 / 644、拒否メッセージの変化、画面上のコメントまで書き出しました。読み違いは、内部スクリプトのファイル名1か所だけでした。

出力の上限は大きめに取る

K3 は必ず推論してから答えます。max_tokens を 300 にしたら、推論だけで使い切って本文が空でした。考えるだけ考えて、何も言わずに帰った形です。動画レビューで 8,000 にしたときも、1問目の途中で切れました。レビューのような長い回答では 32,000 にしています。

比較の条件

K3 と Claude に、同じ v1 の動画2本をレビューさせました。条件はこう揃えています。

	K3	Claude
動画の渡し方	ファイルをそのまま1回	フレームを切り出して画像で読む
音声	理解しない	使わない (文字起こしを切った)
ナレーション原稿	手順 JSON を添付	同じ JSON を添付
質問文	同じ文面 (5問)	同じ文面 (5問)

Claude 側は、K3 の回答を見ていないサブエージェントにやらせました。私自身は K3 の回答を先に読んでいるので、私がレビューすると引きずられます。それでは比較になりません。

フレームの切り出しには claude-video の /watch を使いました。何枚、どの解像度で切るかは Claude の判断に任せています。結果として Claude は切り出しを 4 回やり直しました。冒頭は 0 / 0.5 / 1 / 2 / 3 秒を指定し、本編は 2 秒おきで、計 34 枚を読んでいます。

質問は次の5つです。

冒頭 3 秒で離脱される理由になっている箇所
改善案を効果が大きい順に最大 6 個 (何を変えるか / なぜ効くか / どの工程で実装するか)
記事の図をターミナル録画と組み合わせるなら、どの図をどこに何秒入れるか
先に SNS に出すならどちらの動画か
今のままで良い点

結果: 指摘はほぼ一致した

ほぼ同じでした。両者の回答を並べると、表のとおり大部分が重なります。

指摘	K3	Claude
冒頭 0〜2 秒が内部スクリプトの打ち込みで、何の動画か分からない	○	○
1 文目のナレーションがサイト紹介で、見る理由になっていない	○	○
踏み台の章の `Could not resolve hostname` は強いフックなのに埋もれている	○	○
冒頭に結論や問いを出す (コールドオープン)	○	○
打ち込みとステップ間の待ちを削る	○	○
フォントを大きくし、大事な出力行を強調する	○	○
縦長版を作る	○	○
記事の図を差し込む。権限の図は `ls -l` の所、比較図は山場	○	○
最後に記事の OG 画像をエンドカードにする	○	○
先に出すなら踏み台の章	○	○
画面の上端に進捗バーを出す	○
ナレーションの書き換え案を文で出す		○
`ssh-copy-id` の INFO 4 行がノイズ		○

改善案の中身は、ショート動画でよく言われるコツとほぼ同じです。冒頭で結論を出す、無音を削る、字幕を短くする、最後に誘導を置く。定番です。どちらのモデルに聞いても出てくる種類の答えで、K3 だから見つけられた問題は、この比較では出てきませんでした。 動画を直接読めるモデルなら、Claude には見えない何かを見つけてくれるはず、という私の期待は外れました。

違いは時刻の精度

一番大きな差は、時刻の書き方に出ました。

K3 は「最初の意味のある出力が出るのは 3.7 秒後」「踏み台の章の 00:03.2 に出るエラーが埋もれている」のように、秒未満で指摘しました。細かいです。改善後の版をレビューさせたときも、「30.5〜36.1 秒は出力が出たあと画面が止まっている」と区間で返してきます。

Claude の時刻は、2 秒おきのフレームからの推定です。Claude 自身もレビューの末尾に「区間の境界には ±1 秒程度のずれがありうる」と書いています。もっと細かく切れば精度は上がりますが、そのぶん読む画像が増えます。トレードオフです。

「画面がどこで止まっているか」は、静止画を何枚か見るだけでは判断しにくい種類の問題です。動画をそのまま読める K3 の強みは、ここに出ていると思います。

手間と速さ

	K3	Claude
こちらの手間	動画を渡すだけ	切り出し方を決める (今回は Claude が 4 回やり直した)
所要	363 秒	185 秒
規模	入力 84,461 / 出力 10,863 トークン、約 $0.20 (入力の一部はキャッシュ単価)	111,313 トークン、ツール呼び出し 40 回

手間は K3 が少なく、速さは Claude が上でした。一長一短です。K3 は推論に時間を使うので、1 回のレビューに 6〜8 分かかりました。結果を待つ間に、コーヒーを淹れて戻ってこられます。

動画は実際に良くなった

直しました。レビューの指摘に沿って、handson-cast に入れた変更は次の 6 つです。

冒頭に「同じ鍵なのに ssh -J だと拒否される。なぜ？」のカードを置く
内部スクリプトの打ち込みと、ステップ間の待ちを切り落とす
コマンドを 1 文字ずつ表示し、フォントを大きくする
拒否が出た直後に、記事の図を全画面で 4.5 秒見せる
出力が出揃ったら、ターミナルの左上へゆっくりズームする
最後に記事の OG 画像と URL を出す

最終版 (v4、41 秒、音声あり) です。

画像をクリックすると mp4 が開きます (音声あり)。

同じ時刻のフレームを並べると、違いはこうなります。

踏み台の章は 46.8 秒から 41.0 秒になりました。約 6 秒の短縮です。改善後の版は、技術系ショート動画の型と照らして K3 に採点させました。型は、冒頭 3 秒のフック、1〜3 秒ごとの画面の変化、終盤だけの短い誘導など 10 項目です。結果は合格 7、惜しい 2、合格 (推定) 1 でした。「惜しい」は出力後に画面が止まる区間と、長すぎる字幕の 2 つで、どちらもその後に直しています。

なお、型の調査は K3 に任せるつもりでしたが、うまくいきませんでした。Kimi API には組み込みのウェブ検索 ($web_search) があります。ところが K3 では、検索結果を返す 2 回目の呼び出しが毎回 400 tokenization failed になりました。kimi-k2.6 では 1 回目の検索は通りましたが、2 回目以降は検索せず、検索しているふりの文字列を本文に書いて終わりました。この機能は 2026-10-20 に廃止予定とドキュメントに書かれています (Kimi API: Web Search)。諦めました。型の調査は Claude のウェブ検索でやり、結果を K3 に渡しています。

どう使い分けるか

今回の結果から、私はこう使い分けることにしました。

動画の「どこで何が起きているか」を確かめたいときは K3。 止まっている区間、画面が切れている時刻、テロップの出ている長さのように、時間の幅で答えてほしい問題です。フレームの切り出し方を考えなくて済みます
「どう直すか」を考えるのは、どちらでもよい。 改善案の中身に差はありませんでした
音声が関わるものは K3 に任せない。 ナレーションの中身や音ズレは、文字起こしを別に用意して突き合わせます
機密の入った画面は送らない。 送った動画は Moonshot AI のサーバーに渡ります。今回は公開予定の動画なので問題ありませんでしたが、社内の画面録画は別の扱いが要ります

小さな比較です。動画2本、質問1セットだけで、統計的な結論ではありません。それでも、「動画を直接読める」ことは、判断の中身には差を生まず、時刻の精度と手間に効く、という見当は付きました。次は、わざと不具合を入れた動画で、K3 と Claude がそれぞれ何個見つけるかを数えるつもりです。

References

MoonshotAI/Kimi-K3 (GitHub): モデルカード。総パラメータ 2.8T、1 トークンあたり 104B が動く MoE、コンテキスト 1M
Kimi API: Vision モデルの使い方: 動画入力の方法
Kimi API: Web Search: $web_search と廃止予定日
bradautomates/claude-video: Claude 側のフレーム切り出しに使った /watch
charmbracelet/vhs: ターミナル録画
SSH接続の5方式を7軸比較: 動画の題材にした /learn/ シリーズ