2026年9月17日（日本時間）、オープンソースのブラウザ操作エージェント「Browser Use」の開発元が、「Jev Ultrafast」というリポジトリを公開した。デモはGoogle Flightsでチューリッヒからロンドンへの片道航空券を探すという地味なもので、所要時間は7.1秒。同じ作業を従来版で行った場合と比べ、ブラウザとの通信回数は1,092回から101回に減ったという。速さの理由は、判断を担うAIが「文章を書かない」モデルだったことにある。
その判断役が、TypeSafe AIが9月15日に早期アクセスを開始した「Jev」だ。チャットもしないし、要約も書かない。プログラムの状態と「型の決まった質問」を渡すと、選択肢の番号や真偽、点数だけを70〜500ミリ秒で返す。この記事では、技術の中身は必要最小限にとどめ、クリエイター事務所やMCN、ブランドのSNS運用担当が日々こなしている「管理画面から数字を回収する」「複数アカウントを巡回する」「レポートを作る」という作業がどう変わりうるのか、そして今から何を準備しておくべきかを、一次情報で確認できた範囲と確認できていない点を分けて整理する。
9月17日に公開された「7.1秒のデモ」で起きていたこと
まず、何が公開されたのかを事実として押さえておきたい。Jev UltrafastはGitHub上でMITライセンスで公開されたブラウザ操作エージェントで、リポジトリの作成日時は協定世界時で9月16日21時30分、日本時間では9月17日の早朝にあたる。公開当日のうちにHacker Newsに投稿されて90ポイント超を集め、9月24日時点でスター数は1万9,000を超えている。日本語圏でも9月17日のうちに紹介ポストが広がっており、AI界隈では珍しくない「一夜で話題になったOSS」の一つだ。
READMEに書かれている数値は、話題性のわりに慎重だ。動画になっているGoogle Flightsの実行は7,073ミリ秒で、計測は最初のページ観測のあとから始まり、モデル呼び出し、生成した文字の入力、ブラウザの動作、やり直しになった判断、読み込み待ちをすべて含む。旧版と新版を交互に6回走らせた比較では、どちらも3回中3回成功し、タスク時間の中央値は9.450秒から7.092秒へ25%短縮、ブラウザプロトコルの呼び出し回数の中央値は1,092回から101回に減った。同じ仕組みでWikipediaの特定記事を開く作業は2.798秒、ローカルで用意したホテル検索と絞り込みの作業は1.896秒で完了したとしている。
ここで見落としたくないのは、開発元自身が「これは1つのタスクを1つのブラウザプロファイルで3回繰り返しただけで、汎用的な信頼性のベンチマークではない」と明記している点だ。7.1秒という数字は「どんな画面でも速い」ことの証明ではなく、「文章生成を判断の経路から外すと、同じ作業がこれだけ軽くなる」ことの実例として読むのが正確だろう。速さの話として消費されがちなデモだが、実務者にとって本当の論点は、その速さがどこから来たのかのほうにある。
Jevは「文章を書かないAI」──選ぶ・採点する・真偽を答える、それだけ
Jevを開発したTypeSafe AIは、創業者のDiogo Almeida氏がOpenAI在籍時にChatGPTの土台となった指示追従の研究に携わっていた人物で、2年間のステルス期間を経て9月15日に公式ブログで同社初のモデルを発表した。日本でもGIGAZINEやPC Watchが翌日までに報じている。同社はJevを「System One（システム1）モデル」と呼ぶ。心理学者ダニエル・カーネマンが「速く直感的な思考」に付けた呼び名を借りたもので、じっくり文章を組み立てる従来の大規模言語モデル（LLM）とは別の役割を担う、という宣言でもある。
仕組みは公式ドキュメントによれば単純だ。ソフトウェア側が「いまの状態」をテキストやJSONで渡し、そこに「型付きの質問」を添える。質問の型は3種類で、選択肢の中から1つを選ぶ「Choice」、決められた尺度で採点する「Score」、ある文が正しいかを0から1の確率で答える「Noul」。複数の質問を1回の呼び出しにまとめると、すべてが並列に、互いに独立して評価される。返ってくるのは文章ではなく、番号や数値と、それぞれの確信度だ。
公式ブログが掲げる数値も、生成AIの常識とはかなり違う。応答時間は70〜500ミリ秒で、同種の判断を従来のフロンティアモデルにさせた場合より40〜200倍速いとする。価格は入力100万トークンあたり0.042ドル、出力は無料。あらかじめ定義した型の外の答えは構造上出せないため「型エラーを起こさない」と同社は説明している。
提供状況は、発表から1週間で目まぐるしく動いた。9月15日はウェイトリスト制の早期アクセスとして始まり、日本時間9月21日の朝には同社の公式Xで「ウェイトリストを撤廃し、誰でも利用できる」と発表された。ところが翌22日には、需要の急増を理由に新規登録を一時停止すると投稿している（既存ユーザーの利用は継続）。本記事執筆時点の9月24日で、再開のアナウンスは確認できていない。日本からの利用条件や、日本語の画面や文章に対する精度についても、公表情報は見当たらなかった。
公式ブログの一文が、このモデルの立ち位置をよく表している。Jevが得意なのは「AIを組み込んだワークフロー、いわば賢いif文」だという。分類する、振り分ける、点を付ける、抜き出す、分岐する。手書きのルールでは脆すぎるが、文章を書いてもらう必要もない判断を、ソフトウェアの部品として埋め込む。当メディアが「クリエイターのAIエージェント時代」で整理した「人を雇うようにエージェントを雇う」流れの中で、Jevは「よく喋る同僚」ではなく「即答する判定係」として登場した。
なぜ速いのか──「画面を見て考える」から「番号表から選ぶ」へ
ブラウザ操作AIはこれまで、画面のスクリーンショットを視覚対応のモデルに渡し、「次に何をすべきか」を文章で考えさせ、その文章を解釈して座標やセレクタに変換して操作する、という手順を毎回繰り返してきた。人間の新人にたとえれば、「画面を見て、状況を説明して、どうするか考えて口頭で報告して」と一手ごとに求めているようなものだ。当然遅いし、報告の言い回しが少し変わるだけで解釈がずれる。
Jev Ultrafastはこの手順を丸ごと入れ替えた。ページを読み込むたびに、画面上で操作できる要素をすべて拾って番号付きの一覧表にする。「[2] 入力欄 出発地・サンフランシスコ」「[3] 入力欄 到着地・空欄」といった形だ。そして「クリック・文字入力・選択・上下スクロール・待機・完了・行き止まり」の8つの操作から1つを選ぶ質問と、「どの番号の要素に対してか」を選ぶ質問を、Jevへの1回の通信で同時に投げる。文章を書くのは、入力欄に都市名などを打ち込む場面で小さなLLMが呼ばれるときだけ。既定の動作ループにスクリーンショットは登場しない。
実務者として注目したいのは、安全側の設計が同時に組み込まれていることだ。READMEには、モデルの出力がそのままセレクタや座標、シェルコマンド、実行可能なJavaScriptになることは決してない、と書かれている。選ばれた番号は必ず実際に観測したDOM要素に突き合わされ、クリック前にはページが更新されていないか、対象が他の要素に覆われていないかを再確認する。「完了」と判定されても、それは結果を保証しないので独立した検証が要る、とも明記されている。
限界もはっきり書かれている。現在のバージョンではシャドウDOM、iframe、canvasで描かれたUI、ファイルアップロード、別タブで開くポップアップ、入れ子のスクロール領域、独自実装のキーボード操作ウィジェットは対象外だ。SNSの管理画面はまさにこの手の要素が多い場所なので、「明日から全部任せられる」話ではないことは、先に共有しておいたほうがよい。それでも「画面を読んで文章で考える」経路を「一覧表から番号を選ぶ」経路に置き換えられる、という原理は、管理画面の作業を考えるうえで大きなヒントになる。
SNS運用の管理画面作業はどう変わるか──数字回収・巡回・レポートの3つで考える
ここからが本題だ。クリエイター事務所やMCN、ブランドのSNS担当が「管理画面」に費やしている時間は、大きく3種類に分けられる。TikTokやInstagram、YouTubeのインサイト画面から再生数やフォロワー増減を表計算ソフトに写す「数字回収」、複数アカウントのコメント欄や案件投稿の状態を順番に見て回る「巡回」、そして集めた数字を並べて所感を添える「レポート作成」。どれも判断は小さく、量は多く、期日は動かない。
この3つを「判断」と「文章」に分けてみると、Jevのようなモデルがどこに刺さるかが見えてくる。数字回収で必要な判断は「どのタブを開くか」「期間指定はどれか」「表示された数値は前回と比べて異常か」であり、すべて選択肢か真偽で答えられる。巡回の判断は「このコメントは質問か、苦情か、スパムか」「この投稿はタイアップ表記が付いているか」で、これも分類だ。文章が本当に必要なのは、レポートの最後に付ける所感と、担当者への申し送りくらいしかない。運用担当の1日のうち、文章生成を必要とする部分は、思っているよりずっと小さい。
変化の全体像を表にまとめておく。ただし「変わりうる形」はあくまで原理からの見立てであり、実際の管理画面で動作が確認されたものではない点はお含みおきいただきたい。
| 作業 | いまの姿 | 変わりうる形 | 先に確認すること |
|---|---|---|---|
| 数字回収 | 担当者が管理画面を開き、期間を切り替え、数値を表計算に転記 | 「どのタブか・どの期間か」を型付き判断で選び、転記は機械が行う。異常値の検知だけ人へ | 公式APIやMCPで取れる数値は先にそちらへ。画面操作は「APIがない数値」に限る |
| 複数アカウント巡回 | アカウントごとにログインし、コメント欄や案件投稿を目視 | コメントの分類、表記漏れの真偽判定を並列に投げ、要対応だけを人に回す | 各プラットフォームの利用規約における自動アクセスの扱い、二段階認証の運用 |
| レポート作成 | 数字を並べ、担当者が所感を書く | 数字の異常検知と分類は判定モデル、所感の文章だけ生成AIか人が書く | 「所感」に必要な判断軸を先に選択肢として書き下せるか |
表の右列に「公式APIやMCPで取れる数値は先にそちらへ」と書いたのには理由がある。ブラウザ操作は、あくまで正規の接続手段がない場合の手段だ。当メディアで取り上げたように、TikTokは公式MCP Serverを公開し、MetaもMeta Ads MCPを提供している。エージェントに正面玄関から入らせる道が用意されている領域では、それを使うのが速くて安全で、規約上も明快だ。画面を操作させる発想は、その道がない画面や、複数ツールをまたいだ確認作業に限って検討するのが現実的だろう。
もう一つ、規約の問題は避けて通れない。自動化された手段でのアクセスや情報収集を利用規約で制限しているプラットフォームは多く、管理画面であっても「自分のアカウントだから何をしてもよい」とは限らない。二段階認証やログイン保護の仕組みも、自動操作を前提にしていない。ここは技術の話ではなく契約の話であり、導入を検討するなら各社の規約を読み、必要なら専門家に確認するところから始めることになる。
今から準備すること──作業を「選択肢」に書き下す練習
Jevの新規登録がいつ再開されるのかも、日本語での精度もまだ分からない。それでも今日から始められる準備がある。それは、ツールを待つことではなく、自分たちの作業を「型付きの質問」の形に書き直してみることだ。この作業は、Jevを使うかどうかに関係なく、どんな自動化ツールを入れるときにも効いてくる。
最初にやるのは、日々の管理画面作業を「判断」と「文章」に分解し、判断のほうを選択肢の一覧にすることだ。たとえば「このコメントに返信すべきか」という漠然とした問いは、「質問／感想／苦情／スパム／案件関連のどれか」という選択と、「返信期限は24時間以内か」という真偽に分けられる。TypeSafeの公式ドキュメントも、複数の要素を一度に問う質問は分解し、それぞれを別の質問にしてコードで合成せよ、と勧めている。選択肢に書き下せない判断は、まだ属人的なノウハウのまま残っている部分であり、そこが整理の対象だ。
次に、作業ごとに「正規の接続手段があるか」を棚卸しする。公式APIやMCPがあるものはそちらに寄せ、ないものだけをブラウザ操作の候補として残す。この棚卸しは、SNS運用の内製と外注を判断する際の材料にもなる。どの作業に人の判断が本当に必要で、どの作業が「番号を選ぶだけ」なのかが見えると、外注費の内訳も、社内に残すべき技能も、輪郭がはっきりする。
最後に、「確信度が低いときは人に戻す」設計を前提にしておく。Jevは答えと一緒に確信度を返すモデルで、公式ドキュメントでも確信度によって処理を分ける構成が基本パターンとして示されている。SNS運用で言えば、コメント分類の確信度が高いものは自動で振り分け、低いものだけ担当者の画面に並べる、という運用だ。全自動を目指すのではなく、人が見る件数を減らす。これはClaude Fable 5.1のブラウザ操作やGPT-6 Astraの「PCを操作するAI」を取り上げたときにも触れた、生成AI全般に共通する使い方でもある。
7.1秒のデモが示したのは、AIが賢くなった話ではない。AIに「考えて説明して」と頼んでいた部分の多くが、実は「一覧から選んで」で済んでいた、という発見だ。SNS運用の現場に置き換えれば、担当者が毎日こなしている管理画面の作業のうち、どれが本当に人の言葉を必要としていて、どれが番号を選ぶだけなのか。その仕分けを先に済ませておいた組織から、ツールが届いたときの立ち上がりが速くなる。
本記事は、株式会社TORIHADAが運営するクリエイターエコノミー専門メディア「CREATORS POST」がお届けしました。最新のマーケティング・クリエイター動向を、実務目線で発信しています。
この記事はAIを活用して書いています。
