0907 | AIの最前線ウィークリー：動画AIからエージェント仕事術まで

葵: どうも、葵です。

悠真: 悠真です。今日もAIとプロダクトまわりのニュースを、ちょうど24時間分だけピックアップしてお届けします。Product Huntの新着ローンチから厳選して四つ。今日の四つ、実は全部「速さ」と「信頼」の話でつながってるんですよね。

葵: そうなんだよね。AIが速くなった。でも速いものをどう信頼するか、というのが今日のテーマの芯。ではいきなり一つ目から。動画生成の話で、falのH3 Max。

悠真: これ、falがMiniMax H3というオープンウェイトのモデルを追加学習して作った動画生成モデルです。ブログによると、品質、プロンプト理解、美学の三つの軸で、12の大手動画モデルと人間の選好評価をやったら、全部で1位だったという主張。

葵: 検証方法がわりと具体的でね。人間がどちらの動画が良いかを比較するヘッドトゥーヘッド方式で、全体の好み、プロンプト通りにやったか、見た目の美しさの三つを独立に評価して、ベイジアンEloで集計してる。Automatedメトリクスだけだと動画の良しあしは測れない、というのはfal自身も言ってる。

悠真: で、対戦相手がすごくて。Gemini Omni Flash、Wan 3.0、Seedance 2.5、Kling 3、Veo 3.1、あと元のMiniMax H3公式版。ほぼ全部のマッチアップで勝ったと主張していて、Artificial AnalysisとかDesign Arenaみたいな独立系ベンチマークでも1位を裏付けられたと言ってます。

葵: 速度のほうがもっと印象的。5秒の動画をだいたい3秒で作れる。これは公式H3の約35倍のスループットで、同程度の品質のモデルより平均15倍速いと。速いモデルの占有率と高品質モデルの占有率って普通、別の端にいるんだけど、H3 Maxは両方取った、パレートフロンティアを動かした、という言い方してるね。

悠真: どうやってるのかというと、二つの問題を同時に潰してる。モデル側ではfal Researchがプロンプト遵守と視覚品質に特化した新しい学習データを追加学習に投入。推論側はfalの推論チームがNVIDIAのGB200 NVL72の上で配信スタックを作り直してる。学習と推論のスタックの意思決定を互いに反映させながらやってる、と。

葵: チップ単体で前世代の2倍の性能、と書いてあるね。それから面白いのは、高速化の手法って精度を下げるとかサンプリングステップを減らすとかいろいろあるんだけど、H3 Maxでは品質評価でポジションを落とすような最適化は採用しなかった、という方針を明言してること。

悠真: Design Arenaのコメントも引いてあって、「MiniMax H3の品質を50倍以上の速度で提供し、速度と選好の新しいパレートフロンティアを作った」と。MiniMax側も、品質と速度の両方で実用的なアプリケーションが広がる、falとは最初から組んでる、とコメントしてる。

葵: まあここはメーカー主張だというのは押さえておきたい。自分たちで人間評価も回してて、勝ち馬は自分たちが選んでる。独立ベンチの裏付けはあるとはいえ、実運用での品質のばらつきは未知数。

悠真: コメント欄でもそれがまさに問われてて、ある人は「3秒で5秒クリップはクレイジーだけど、速度トリックを使うと大体カメラの動きのあるシーンでmotion coherenceが落ちる。image-to-videoで実際にカメラワークのあるもので試す」って言ってて。これが一番公正な検証だと思うんですよね。

葵: そうそう、「品質が速度で保たれていれば」が条件付で書いてある。Text-to-VideoとImage-to-Videoの両エンドポイントがあって、Playground、fal Agent、API経由で使える、と。

悠真: 一方、動画の生成じゃなくて理解の側でも速度革命が起きてて。GoogleのGeminiにアジェンティックな動画理解、という新しい処理モードが入りました。

葵: これは面白い。今までの動画処理って、フレームを固定レートでスキャンしてたんですよ。全部を同じ密度で。新しいモードは、モデル自身が「どこを」「どの速度で」「どのモダリティで」見るかを決める。フレーム、音声、文字起こし、この中から必要な区画だけを内部のアジェンティックループで取得する。

悠真: 対応モデルはGemini 3.7 Flash、3.6 Flash、3.5 Flash-Lite。数字がいっぱい出てきて、トークンが最大88%削減、コストが最大66%削減、精度が最大7%向上、と。

葵: 実装面では、別製品じゃなくて既存モデルの処理モードのトグル。「agentic」を設定するだけ。標準のトークン価格で追加料金なし。AI StudioとGemini Enterprise Agent Platformでライブ。

悠真: ユースケースが書いてあって、長尺動画のニードルインヘイスタック検索、変数FPSリサンプリングによる異常検知、繰り返しの動作や物の正確なカウント、サブ秒の瞬間検索による自動編集。動画の検索、編集、モデレーション、分析ツールを作ってる開発者向け、と。

葵: ここ、H3 Maxと並べると綺麗なんだよ。falは生成側、Googleは理解側。どちらも「速さか品質か」というトレードオフが崩れてきてる、という同じ変化の両面。H3 Maxは推論とモデル研究を同時進行で。Googleはモデルに「見方」を委ねた。どちらも固定の処理ではなく、柔軟な判断を入れた、という発想の共通点がある。

悠真: 長尺動画が実用的に扱えるようになるという意味では、生成も理解もセットで進んでる。ただ、88%削減とか66%削減は「最大」の話で、どんな動画で一番効くかは長編側に偏ってると書いてある。実運用の分布はまだ分からない、というのが正直なところかな。

葵: うん。で、この「エージェント的に判断する」という発想、動画から今度は開発ツールに移ってる。二つ目のテーマ。SpeakeasyのKit、コーディングエージェントのランタイムです。

悠真: これ、キャッチコピーが「Claudeだけど速くて安くて簡潔」。仕組みが独特で、Kitはモデルに一つだけツールを与える。その名もcomposeというツールで、引数はRunletという短いプログラム。

葵: ほとんどのエージェントハーネスは複数のツールを出して、呼び出しごとにモデルのラウンドトリップが発生する。Kitは1回のラウンドトリップの中で、ファイルを読み、テストを走らせ、編集を適用し、失敗したコマンドをリトライし、サブエージェントに仕事を委譲し、構造化データを返せる。ラウンドトリップが減ると文脈の繰り返しが減って、1リクエストで多くの仕事が終わる、という理屈。

悠真: 数字も出してて、サイズを揃えた本番タスクで、Codex CLIやClaude Codeと比べて、手書き1行あたりの入力トークンとアクティブ時間が約半分だったと主張してる。

葵: composeプログラムの中で呼べるのがshell、edit、subagent、prompt、fork、tool search、tool、auth、skill、a2a、docs。独立した呼び出しは並行実行されて、データ依存やafterブロックで順序を制御。エラー処理はboundary retryとfail。

悠真: サブエージェントが再利用可能な値になってるのも特徴で、続けたり、フォークしたり、検査したり、閉じたりできる。JSONスキーマにマッチすることを要求することもできて、サブエージェントのハーネスとしてClaude Code、Codex、Cursor、Kit自身をACP越しに使える。

葵: プロトコル面ではACP v1とv2をstdio、HTTP/SSE、WebSocketでサポート。A2A v1も双方向。MCP、Agent Skills、Agent Pluginパッケージにも対応。長いセッションの話もあって、各JSONLトランスクリプト項目を受け入れる前にディスクへ同期して、コンテキスト窓の80%で自動コンパクト、tuiやpromptやACPクライアントからセッション再開も可能。

悠真: モデル選択も自由で、ChatGPTサブスクリプションをネイティブOAuthで、OpenRouterやSpeakeasyのAI Control Plane経由でも。セッション中に/modelで変えられる。

葵: で、ここ大事な注意点なんだけど。Kitには権限フレームワークもサンドボックスもWeb UIもない。READMEに「Kitはランタイムであってセキュリティ境界ではない。信頼できるセキュリティ境界の中でKitを実行せよ」とはっきり書いてある。この素朴さは、あるコメントで「静的バイナリが一番ポイントが高い、Speakeasyのものは全部ゼロ設定で動く。日々のドライバーにする」と評価されてる一方で、他の人が「サブエージェントの出力がメインセッションにマージされる時に検証ステップはあるのか、それともトップレベルが書いたものとして素通りするのか」と問うてた。

悠真: その質問は正しい視点だと思う。速度の利得と信頼のコストがセットで問われる。DocsAlot Visual Editorは、まさにこの信頼の問題をドキュメント側で解こうとしてるプロダクトです。

葵: DocsAlotの創業者Faizanが言ってるんだけど、ソフトウェアのすべてがエージェント向けに再構築されてる中、DocsAlotもCLIとMCPでエージェントにドキュメントへのアクセスを与えて、AIでコンテンツを作る更新もできる。でも「人が最終判断する」までは公開できない、という一点が核心。

悠真: 技術的に難しかったのは、視覚編集体験を作りながらMarkdownを壊さないこと、と本人が言ってる。ページは視覚モードとソースモードを行き来できて、フロントマター、テーブル、コード、リンク、構造を保つ。

葵: 編集と公開を分けてるのも特徴。変更は作業ドラフトに留まって、人が意図的にバージョンを保存し、前のバージョンに戻れて、そのバージョンがいつ公開サイトになるかを選ぶ。ナビゲーションもサイトデータとして扱われてて、ページやグループの移動が公開側の構造に反映される。

悠真: 技術コンテンツのブロックが充実してて、コードグループ、コールアウト、ステップ、テーブル、タブとカード。パーソナルなコメントで「ヘルプドキュメントで役立つのは誰かが詰まったステップで、自分で打たないとその詳細はページに残らない」というのがあって、これは実感のある意見ですね。

葵: コミュニティの議論はかなり鋭い。ある人は「人間の承認ゲートはフォーマットのミスはキャッチするが、実際にコストがかかる失敗、つまり読むと完璧に見えて動かないコードサンプルはキャッチできない。正しそうに見えるdiffを誰もrejectしない。CLIがあるんだから、スニペットをコンパイルして、言及されたエンドポイントをOpenAPIスペックと照合し、失敗したページだけ人間に見せろ。40ページの文章を承認するのは芝居で、3件のフラグ付きを承認するのは意味がある」って。

悠真: これはまさにKitとDocsAlotで共通する論点なんですよ。エージェントに任せるのは良い。でも人間はどう検証して信頼するのか。Kitの問いは「サブエージェント出力の検証ステップ」、DocsAlotの問いは「承認が実質的なチェックになっているか」。どちらも「委任した後の最後の一歩をどう担保するか」という同じ構造。

葵: あともう一つ指摘されてたのは、エージェントが提案した編集を人間がほとんどrejectした時に、エージェントは「何が変わってなぜか」を見られるのか、それとも記憶なしに最初からやり直すのか、という点。これはまだ答えが出てない未知の部分。

悠真: そしてこの流れ、開発現場からもう少し外に出て、日々のAIとの付き合い方全体に広がってます。三つ目、AI Toolbox 3.0。ChatGPT、Claude、Gemini、Grokを一つのChrome拡張で横断するツールです。

葵: 機能は豊富でね。サイドバーにフォルダとサブフォルダ、4プラットフォーム全部を一括で検索するフルテキスト検索、//と打つと保存済みプロンプトを挿入できるプロンプトライブラリ、プロンプトを複数ステップのワークフローにチェーンする機能、Markdown、PDF、JSONへの一括エクスポート、フォルダ全体のZIPも。

悠真: Claude上ではArtifact Vaultというのがあって、作ったアーティファクトやファイルを一箇所で閲覧・ダウンロードできる。それからライブコンテキストメーター、長いチャットが途中で切れないようにして、ワンクリックで新しいチャットに引き継げる。

葵: 創業者のAdiがProduct Huntのコメントで経緯を語っててね。2年前に32ドル、安いVMとChrome開発者フィーの $32 から始めて、一日中ChatGPTの中に住んでて、見つからないチャット、百回目のプロンプト再入力、エクスポート不可、に直面して作った、と。プラットフォームが基本を全然リリースしないから、足りない層を作った。今回は3回目のローンチで、Grok対応が新しく入った。

悠真: あるユーザーが「Claudeでチャットを始めて、ChatGPTで続きたくなったら、ボタン一つでチャットを要約してChatGPTの新しいチャットに運んでくれる」って書いてて。これは体験としてわかりやすい。

葵: 対してTadataは逆方向のアプローチ。AI従業員がSlackに常駐して、ツールをつないで、仕事を「委任」でこなす。共同創業者のToriが説明してて、リードファインディングが例。探してる人物像を記述すると、内部ツールとLinkedInやGoogle Mapsみたいな外部ソースを横断して調査する。結果が違ったら返信で修正を伝える。データプロバイダを選んだり、ツールを配線したり、リサーチエージェントを作ったりはしない。仕事を委任するだけ、と。

悠真: 彼らはインフラ側から来てて、FastAPI-MCPを作ったチーム。12K GitHubスターと70M以上ダウンロード。ツールへのアクセスは持てても、実際に頼れるAI同僚を持つのとは違う、と。日常の様子も書いてあって、朝7時45分には今日の予定や前回から変わったことなどがSlackに届いて、コール後にはフォローアップメールやCRMフィールドの下書きが、承認待ちの状態で出てくる。何も承認なしには外に出ない、と。

葵: アーキテクチャ面ではモデル非依存で、自動化や設定や例外や機械学習的な「レシピ」はエクスポート、バージョン管理、持ち出しができる。データは自分のもの、プロバイダロックインなし、と明言。クレデンシャルの分離とか、接続したツールしか見えない、という記述もある。

悠真: コメント欄では「短く簡潔な回答とSlackでの指示が他のSlackボットよりシームレス」という体験談と、逆に「委任は魅力的だけど、失敗モードは何か。Tadataがリードを調査して自信を持って間違えた場合、古いデータとか幻覚の詳細、自分の不確実性をフラグするのか、それとも普通のSlackメッセージとして真実扱いされるのか」という問いが。この問いもさっきのKitやDocsAlotと同じ形ですよね。委任の先にある信頼の担保。

葵: そう。「人間が検証する」をどこに置くか。DocsAlotは公開ゲート、Tadataは送信前の承認ゲート。そしてもう一つのコメントは「Slackの会話が半分決定で半分ノイズのチャンネルをどう扱うのか、タグが必要か、裏で聞いてるのか。会社を学習する機能は1週間後と1ヶ月後でどれだけ深くなるのか」という点。これは運用次第の未知数な部分。

悠真: チャットを資産にするという思想で繋げると、AI Toolboxは蓄積したチャットを所有・整理・エクスポートする側、Tadataは逆にAIが仕事をして結果を持ち込む側。どちらも「AIとのやり取りは捨てるものじゃなくて、資産として扱うべき」という同じ立場です。

葵: ただ、所有と言えば、手に入れたくても手に入らないデジタル資産の代表がある。ドメイン。四つ目のテーマ、Notify.domainsです。

悠真: 創業者のMichael Cygerが紹介でね、ドメイン業界15年で、DomainSherpaを創設し、DNAcademyを作り、買収後にGoDaddyの教育ディレクターをやった人。そして実際に目撃したのは、欲しい名前を適切な情報が適切なタイミングでなくて失った人々。

葵: サービスはシンプルで、欲しいドメインを登録すると、WHOIS、RDAP、オークション、マーケットプレイス、サイトの状態、これらを全IANA TLDで1日20回以上チェックして、何か変わったら平易な通知と「次に何をすべきかの正確な手順」が届く。生データじゃない。

悠真: 通知の例がサイトに載ってて、「あなたのドメインに変化があった、これが見たもの」「ドメインがオークションに入った、今すぐ入札して」「ペンディングデリートが始まった、これがバックオーダーのチェックリスト」「マーケットプレイスのセールが35%下がった」みたいな。

葵: この「裏側のゲーム」の説明が正直で面白くて。期限切れのドメインは普通、誰でも取れるようにドロップするわけじゃない、と。レジストラは期限切れの名前を公表前にオークション提携先に回す。GoDaddy Auctionsに行く名前もあれば、NameJetに行くもの、もっと小さくて追跡しづらいネットワークもある。マスターリストも単一のスケジュールもない。正しい場所と時間を外すと、その名前は永遠に消える。

悠真: 価格は年24ドル、7日間の無料トライアル、クレジットカード不要。どんな名前でも取れるわけじゃない、たいていの価値ある名前はレジストラのオークションを経由して出て行く。行かないものにはバックオーダーが効く、パスはTLDで違う、と。

葵: 実体験のコメントもあって、「10年以上憧れてる名前を追ってる。使われてない、売りに出てない、オーナーは応答しない。でもNotify.domainsが24時間365日自分のために働いてると思うと希望がある」。「数週間テストしてて、時間を大幅に節約できる」という声もある。

悠真: 一方で議論の鋭い部分は、ある人が「難しいのは検知じゃなくてレースじゃないか。あなたが見てるなら、他のドメイナーとスナイピングサービスも同じシグナルを見てる。アラートが飛んだ後も本当に動ける窓はあるのか、それとも最速のレジストラAPIを持ってる人の勝負になるのか」と。

葵: これに対する答えはまだ見えてない。Bob Hawkesという質問者は「二人以上が同じ名前を監視するのを防ぐ仕組みはないか」と聞いてて、Michaelは「レジストラのオークション提携先が先にリストするのは、ほとんどの人が高く学ぶ部分だ」と答えてた、という記述がある。

悠真: で、あるユーザーは所有側の視点から「私は十数個の小さな送信ドメインでビジネスしてる。心配なのは自分のものが静かに失効したり、DNSが勝手に変わること。Notifyは自分が所有してるドメインも見てくれるのか、それとも獲得したい名前専用か」と。サイトのSolutionsにはBrand Protectionとして「ブランド、バリアント、競合名をステータスとリスティングの変化で監視」とあり、既存ドメインの失効・DNS変更監視のニーズも何らかの形で拾えそうな位置づけ。

葵: ある人も数年前にまさに同じパターンで.comを失ったと書いてて、「期限切れをwatchingしてたのに、ページが消えたことに気づいた時にはもうドロップキャッチャーが仕掛けてた」。この「隠されたパスを知らない素人が損をする」という業界の非透明性を、とにかく可視化しよう、というのがこのサービスの本質。

悠真: ところで、この4つを繋ぐ線をもう一度言うとね。falのH3 MaxとGeminiのアジェンティック動画理解は「速さと品質が両立できる」ことの証明をしようとしてる。KitとDocsAlotは「速く委任できるようになった分、人間の検証をどう置くか」を設計してる。AI ToolboxとTadataは、その委任ややり取りを「資産」として所有する側の話。そしてNotify.domainsは、その資産を構成する名前そのものを、透明性で手に入れようとしてる。

葵: どれも「人間がまだ最後の一歩を持っているか、手放すか」の所で設計判断が割れてる。Kitは「自分でセキュリティ境界を用意せよ」、DocsAlotとTadataは承認ゲート、AI Toolboxはローカルファーストで自分のブラウザに置く、Notify.domainsは情報を平易に渡すだけ。

悠真: 今日の未知数な部分もまとめると、H3 Maxは実運用の品質のばらつき、Geminiのアジェンティック動画は削減率が最大値であること、Kitはサブエージェント出力の検証、DocsAlotはコードサンプルの機械的チェック、AI Toolboxは検索の安定性とIndexedDBの永続化、Tadataは誤情報とSlackのノイズの処理、Notify.domainsは検知後のレースと既存ドメイン監視、と。

葵: あ、AI Toolboxの話で、もう一つ大事なのがあった。ローカルファーストとはいえ、検索インデックスはIndexedDBにあって、ある人は「Chromeはストレージ圧縮でそれを黙って削除できる。2年分の履歴とフォルダツリーが静かに消えて、拡張のバグに見える。navigator.storage.persist()を呼んでるか、quotaをUIに見せてるか。フォルダより前にそれを出すべきだ」と書いてて。この指摘も答えがまだない。

悠真: うん、まだ反応が続いてる状態で解決はしてない、というのが誠実な伝え方ですね。

葵: というわけで今日は、falのH3 Max、Googleのアジェンティック動画理解、SpeakeasyのKit、DocsAlot Visual Editor、AI Toolbox 3.0、Tadata、そしてNotify.domainsを取り上げました。

悠真: どれも「速くなったAIを、どう信頼し、どう所有するか」という同じテーマの異なる答えでした。明日もまた24時間分から厳選してお届けします。それではまた。