Kimi K3の動画レビュー、Claudeと互角

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

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

この差が実務でどれくらい効くのかを、手元の題材で確かめました。題材は、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 秒、音声あり) です。

この 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本で測りました。

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

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

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

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

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

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

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

比較の条件

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

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

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

質問は次の5つです。

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

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

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

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

違いは時刻の精度

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

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

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

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

手間と速さ

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

動画は実際に良くなった

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

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

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

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

踏み台の章は 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/ シリーズ