TypeSafe 創業者が語る Jev:Jev とはいったい何か? AI はとんでもなく賢いのに、自動化はどこへ行ったのか?
a16z のインタビューに公式ブログ、ロングインタビュー、外部の疑問を加えて読む。元 OpenAI 研究者の彼は、チャット型の訓練は道を誤ったと考えている。彼がつくった Jev はチャットをせず、ソフトウェアがあらかじめ用意した選択肢の中で、自信の度合いを伴う判断だけを返す。
このインタビューが読者に納得させたいことは一つだけだ。ここ 2 年の AI に欠けていたのは賢さではなく、ソフトウェアに本当に組み込まれて仕事をすることだった。TypeSafe の創業者 Diogo Almeida がつくった Jev は、その欠けた部分を埋める部品だという。
本稿は、a16z チャンネルが 2026 年 9 月 28 日に公開したインタビューを軸にしている。Ben Horowitz と Martin Casado が Diogo と対談したもので、長さは 42 分。インタビューで説明が簡略だった部分は、TypeSafe の公式ローンチブログと、Latent Space による彼へのロングインタビューで補った。外部からの疑問は KDnuggets の論評と Hacker News の議論によるもので、それぞれ出典を示し、情報源はページ末尾にまとめた。
彼はいま何が問題だと考えているのか
冒頭、Diogo は汚い言葉まじりの問いを投げかけた。いったい自動化はどこへ行ったんだ? AI はとんでもなく賢いのに、チャットとプログラミング以外ではほとんど役に立っていない、という意味だ。彼はチャットボットやプログラミング Agent をけなしているわけではないとわざわざ断っている。どちらも彼自身が愛用しているものだ。彼の目には、手元に原石が山ほどあるのに、仕事ができるところまで磨かれていないのは「悲惨」に映る。
対話ではいくつか具体的な場面が示された。
企業内部。 司会者の一人によれば、OpenAI は 2020 年から顧客サポートの自動化を試みてきたが、いまでも企業内部で自動化されたものはごくわずかで、プロジェクトもうまくいっていない。唯一の例外がプログラミングだという。
カスタマーサポートの「95%」。 Diogo は、今回の生成 AI ブーム以前にカスタマーサポートを研究していた経験を語った。ある会社がヘルプデスクへの問い合わせの 95% に回答していると言うので、さすがに高すぎると思ってデータを見ると、ほとんどがパスワードのリセットだった。問題の独自性で数えると、本当に解決されていたのはおよそ 50% にすぎない。彼の結論は、相手が人間や自然のシステムである限り、後ろには例外の長いロングテールがついて回る、というものだ。
面倒な雑用。 司会者の一人が小話を披露した。彼らのグロースファンドを率いる David George がある新しいツール(書き起こしでは Muse と聞こえる)を試し、最初にやったのは、ついにニューヨーク・タイムズの購読を解約することだった。司会者いわく、これは氷山の一角にすぎず、こうした「やるのが面倒な」ことこそ自動化が必要だ。
「普及が遅い」は理由にならない。 新しい技術が普及するには時間がかかるという説明で自動化の遅れを語る人もいるが、Diogo はまったく信じないと言う。AI の潜在力はこれほど大きく、自動化の経済的な動機もこれほど大きいのだから。
Latent Space のロングインタビューでは、彼はもっと辛辣だ。もしモデルが本当に世界の経済的に価値のある仕事の大半をこなせるのなら、なぜ数学の難問は解けるのに、経済的に価値のある仕事はほとんどこなせないのか、という問いに答えるべきだという。彼の見立てでは、この点で各社のモデルはおそらくまだゼロで、すでに始まっているとしても 1% に満たない。それが本当に起きたときには、経済統計に表れるはずだ。
彼の診断:最適化したものが手に入る
彼自身の転機。 Diogo はインタビューで、自分がどう悟ったかを語っている。2021 年末、彼は RLHF(人間のフィードバックでモデルを訓練する手法)の汎化能力に大いに驚き、チームはそれが「ズル」をしていないか反証する実験までした。たとえば「瞑想の前になぜ靴下を食べるべきか」のような、ネットで調べても出てこない質問をして、もっともらしい答えをでっち上げられるかを見たのだ。当時の自分は「能力重視派」で、そのモデルが AGI になる可能性があると一時は本気で思っていたが、そうではないとわかり、世界観が一瞬で崩れたという。公式ブログではもっと率直に書いている。彼は OpenAI で、言語モデルが指示に従い人と会話できるようにする手法づくりに携わり、それが ChatGPT の背後にある研究になった。当時はチャットモデルが AGI につながるかもしれないと考えていたが、すぐに「とても大きなピースが欠けている」と気づいた。(Latent Space の導入文は、彼を InstructGPT 論文の共著者だとしている。)
彼の判断:最適化されたのは審判で、タスクではない。 AGI についての彼の考えはもっと実務的だ。OpenAI が定義する AGI、つまり世界の経済的に価値のある仕事の大半を自動化することは、十分に実現可能だと彼は考えている。多くの仕事は機械的で単純であり、外注できる仕事にはもともと普通の人がそのとおりにやれる簡単な指示が必要で、彼の見る限り、その程度の知能はとっくにモデルの中にあるからだ。彼の「わだかまり」は、なぜそれがまだ実現していないのかという点にある。彼の説明では、RLHF 以降、業界は「大風呂敷を広げて、実際の成果が伴わない」方向に分かれていった。モデルの良し悪しを人が評価するので見た目は良くなるが、最適化されたのは審判であって、自動化そのものではない。彼は「明らかに自動化されるべきことを自動化できるかどうか」を炭鉱のカナリアにたとえる。数学は「解決」され、2 年前に Google 検索対策としてつくられた質問応答ベンチマーク GPQA も解決された。それなのに、車のドライブスルーでの注文はいまだにうまくこなせない。
ロングインタビューで彼はこの考えを一つの公式として語っている。訓練で何を目標にするかで、モデルはその姿に育つ。 主流の 3 つの訓練方法は、それぞれ目標が異なる(下表は公式ブログとロングインタビューでの彼の発言をまとめたもので、最後の行はロングインタビュー導入文の要約):
| RLHF | RLVR | RLCD(Jev) | |
|---|---|---|---|
| 何を最適化するか | 人間の評価者を満足させること | プログラムで検証できる結果 | 「正直な確率」を伴う意思決定 |
| 得意なこと | チャット、文章作成 | 数学、カーネル最適化 | ソフトウェアがそのまま使える判断 |
| 代償 | 迎合し、キャリブレーションを失い、常に人間がループに入る必要がある | 知能にムラがあり、他のソフトウェアと統合しにくい | 自由テキストを捨て、能力の範囲が狭くなる |
RLVR は検証可能な報酬による訓練を指し、RLCD は彼らが独自に提案した訓練手法で、「キャリブレーションされた意思決定のための強化学習」を意味する。ロングインタビュー導入文によれば、この技術はまだ公開されていない。彼いわく、RLVR はモデルの「システム 2」(遅い思考)で驚くべき成果を上げたが、その能力は脆く「ギザギザ」だ。一方、事前学習で得られたモデルは本質的に「システム 1」(速い直感)の思考者だという。
なぜチャット型の訓練が信頼性を損なうのか。 彼はロングインタビューで技術的な説明をしているが、かなり回りくどい。要点はこうだ。文字列生成には直感に反する事実がある。長い文章ほど間違いを含みやすいというのは数学的には自明に見えるが、実際には成り立たない。なぜなら、長い文章で間違えないために、モデルは極端に保守的にならざるを得ず、その保守性が確率の「キャリブレーション」(モデルが自分でどれだけ自信があると言うかと、実際にどれだけ正確かが一致しているか)を壊してしまうからだ。彼はこれをモード崩壊、つまりモデルが最もありふれた数種類の答えしか出さなくなる現象と呼ぶ。彼の結論は、文字列モデルで意思決定をするのは「ひどいこと」だというものだ。これは彼の見解であり、ロングインタビューでは実験データは示されていない。
「暴走」についての彼の見方。 インタビューで彼はさらに、ある微妙な理由から、当時もいまも、私たちが RSI(一般に AI の再帰的自己改善を指す)への道を歩んでいるとは考えていないと述べた。初期の OpenAI では、AGI は「Ilya に、あらゆる if 文を足したもの」と形容されていたが、この言い方は意図的にあいまいで、テントを大きく張って誰でも入れるようにしたものだという。
司会者の一人が反論を出した。現実世界のデータは裾が重く、大量の例外があるのに、AI は主に数学やコードのような低次元の世界で訓練されているからではないか? Diogo は「データ不足」という説明には完全には同意しない。ロングテールはもちろん存在する。しかし彼によれば、カナリアという文脈では、ロングテール全体を自動化する必要はない。何事も実務的であるべきで、信頼できるソフトウェアをつくることはもともと投資なのだ。
Jev とはいったい何なのか
インタビューで触れられた「メールの分析」で想像してみよう。ソフトウェアが顧客からのメールを読み、それをどの処理フローに回すべきか判断する必要がある。これまでは、大量のルールを書くか、機械学習チームに専用モデルを訓練してもらうかのどちらかだった。Jev を使う場合の考え方は、開発者が各フローの役割を自然言語でそのまま説明し、その中から選ばせるというものだ。Diogo によれば、こうした能力には、ログの分析、メールの分析、インターフェースの提供、人との対話が含まれる。
公式ブログの一文での定義は、Jev は「フロンティア知能の関数呼び出し」、つまり非構造化の状態が入り、型付きの確率的な判断が出てくるものだ。これは公式が言う「System One モデル」の一つである(名前はカーネマン『ファスト&スロー』の「システム 1」、つまり速く直感的な思考から取っている)。普通の言語モデルと比べ、公式は 3 つの違いを強調している:
- すべての答えを一度に並列で出す。token を一つずつ書き進めるのではない。
- 出力は型付きの値。選択肢と構造は開発者があらかじめ定義し、モデルは構造の外にあるものを出力しない。
- すべての答えにキャリブレーションされた確率と信頼度がつく。信頼度が高いものほど正確であるべきだ。
仕組みについては、a16z の司会者の一人がこうまとめた。これはライブラリだと考えればいい。欲しいものを自然言語で説明し、ステートマシン(一組の状態と、状態間をどう遷移するかのルール)を渡すと、ある程度の信頼度を伴って、どうすべきかを選んでくれる。司会者いわく、この「信頼度つきの選択」はソフトウェアにこれまでなかったものだ。Diogo は反対せず、いくつか補足した:
- Jev は技術的には「間違いなく分類器」だ。彼はそれを貶めることだとは思っていない。分類器はそもそも役に立つために生まれたものだ。
- 彼らは入社初日にベン図を描く。一方は AI が得意なこと、もう一方はコードにとって価値のあること。Jev はその真ん中に立つ。だから外挿で出した浮動小数点数は出力しない。AI はそれが得意ではないからだ。ただし、確率は目新しいものではない。
- Jev は 2019 年の機械学習エンジニアリングチームよりも良い仕事ができるかもしれない、と彼は推測する。当時は良いチームが少なく、狭い用途を一つ選び、自分でデータセットを集め、評価をつくる必要があった。いまはその場で自然言語で「プログラミング」できる。
- インターフェースが入力を「状態」と呼んでいるのは意図的だという。
下の小さなデモは、「ステートマシン+信頼度」を並べて見せるものだ。メールを一通選び、ソフトウェアがそれをどの状態に回すか、どれだけ自信があるかを見て、さらに「どこまで自信があれば任せるか」のしきい値を自分で調整してみてほしい。デモ内のメールと数値はすべて例示であり、Jev の実際の出力ではない。
例示デモ · 数値は Jev の実際の出力ではない
メールを一通選び、ソフトウェアがどう任せるかを見る
まず顧客からのメールを見る
「今月、二重に引き落とされました。多く引かれた分を返金してください。」
ソフトウェアがあらかじめ定義した状態(各状態を自然言語の一文で説明)
- 返金顧客が支払済みの代金の返還を求めている
- 技術的な障害製品が使えない、またはエラーが出る
- 問い合わせ機能、料金、領収書の発行などについての質問
モデルが選んだ状態と自信の度合い
選択:返金 · 自信 92%
自信がしきい値に達したので、プログラムは自動で「返金」フローに進み、人の介入は不要。
司会者はさらに問いを重ねた。これは一方の端が言語入力・言語出力、もう一方の端が従来の命令型プログラムというスライダーなのか、それとも設計空間の中の一点なのか? Diogo の答えはスライダーだった。設計上の「北極星」は 1 ドルあたりの知能だとしつつ、短期的には 1 秒あたりの知能のほうが価値があるかもしれないと認めた。公式ブログが示す速度と価格は、応答が約 70〜500 ミリ秒、入力は 100 万 token あたり 0.042 ドル、出力は無料。トップページにある「193.6 倍速く、444.6 倍安い」は、公式自身が高めの側のケースだと注記している。これらの数字がどう測られたかは後で述べる。
名前については、公式ブログによれば、Jev は経済学者 William Stanley Jevons に由来する。蒸気機関の効率が上がると、石炭の需要はかえって増えた。同じように、知能のコストが 1 桁下がるごとに、桁違いに多くのユースケースが開かれる。インタビューで Diogo も、こうしたことが可能になれば人々は新しい仕事を生み出すと付け加えている。
ローンチ後の反響も彼の予想を超えていた。知り合いの開発者全員から電話があり、使いやすくて速いと言われたという。1 時間ごとに誰かが「Jev でまったく思いもよらなかった新しい用途をつくっている」と伝えてくる。「開発者向けの ChatGPT」は誰にも予想できなかったと彼は感じており、開発者ではない友人までが Twitter でネタにしていたという。
Claude Code や Codex と何が違うのか
多くの人がいちばん聞きたいのはこれだろう。すでに Claude Code も Codex もあるのに、なぜこれが必要なのか?
Diogo はまず、この 2 つは素晴らしいと認め、ある人の「インスタント・ソフトウェア」という言い方を紹介した(書き起こしでの人名は Gary Tannenbaum だが、誤りの可能性がある)。それらはその場でソフトウェアをつくり、自然言語でプログラミングでき、表現力はソフトウェアと同じくらい強い。しかし彼が欲しいのは「インテリジェント・ソフトウェア」だ。ソフトウェアエンジニアリングを自動化するのではなく、ソフトウェアそのものができることを広げ、本来自動化できるはずのものを本当に自動化できるようにすることだという。
司会者の一人は違いをもっと端的に語った。Claude Code、Codex、Cursor が書き出すのはコードであり、そのコードは人が書いたものと本質的に変わらない。良いこともあれば悪いこともあるが、本質的には 10 年前と同じ種類のコードだ。一方 Jev は、コードを書くのが人であれプログラミング Agent であれ、新しい部品が一つ加わり、コードに組み込んでソフトウェアの能力を拡張できる。だからそれは、より速いプログラマーでエンジニアを置き換えるものではなく、いまいるエンジニアにもっと良く、もっと面白いものをつくらせるものだ。
対話の後半、この司会者はさらに一つの数字を挙げ、速くするだけでは足りない理由を説明した。大企業では 1 件の PR(コードのマージリクエスト)は平均 10 行ほどしかない。彼は Google にいたことがあり、チームがこの調査をしたのだという。だから AI がこの 10 行をより速く書いたとしても、自動化されるのはソフトウェア仕事の中で比較的副次的な部分にすぎない。しかもこの 10 行は、多くの場合、顧客についての何らかの洞察から来ており、ソフトウェア自体がそれによって新しい能力を身につけるわけではない。Jev が出てくるまで気づかなかった、と彼は言う。AI プログラミング Agent をどれだけ使っても、ソフトウェアは実は良くなっておらず、速く書けるようになっただけだ。むしろ悪くなったとさえ言える。監督が減り、多くの場合セキュリティも弱くなっているからだ。
もう一人の司会者は奇妙な質問をした。こうした部品ができたら、プログラミング Agent の価値は下がるのか? Diogo は、それはむしろプログラミング Agent 側の問題だと答えた。彼自身の体験では、これらのツールは構文は得意だが意味は不得意で、特にアーキテクチャが弱く、だいたい 50 パーセンタイルあたりにいる。アーキテクチャがわからない人にはそれで十分で、ときにはスピードこそが回すべきつまみなのだという。
ロングインタビューでは、彼は別の角度から今日のプログラミング Agent を批判している。それらは「単一のモデル」の上に築かれ、一つのモデルに閉じ込められていて、状態は後ろに追記していくしかない。だからサブタスクに安い知能を使わせることができない。彼は別のやり方を構想していた。サブタスクごとに安いモデルを割り当て、ラベルつきのタスクツリーで状態を管理し、並列するサブ Agent 同士で状態を共有し、単純なロックではなく知能によって調整する。この分野には考え直す価値のあることがたくさんあるという。
どう使えば信頼できるのか
まず、AI がなぜいつまでもソフトウェアに入り込めないのかを見る。 これは司会者の一人の分析だ。彼によれば、人々は AI とソフトウェアがどう「すれ違って」きたかを理解していない。AI をソフトウェアに組み込みたくても、言うことを聞かない。ソフトウェアは自然言語を受けつけないからだ。prompt に「こういう JSON 出力が欲しい、これが schema だ」と書いても、しばしばそのとおりにしない。結局、道は 2 つしか残らない。出力を人に見せる、つまりチャットか、出力を別の大規模モデルに渡す、つまり Agent の while ループか。自然言語を次のステップに食わせ直す必要があるからだ。彼はこの過程を見てきたが、それは悲嘆の 5 段階のようだという。まず否認し、必死に動かそうとし、次に怒り、最後に受け入れる。もういい、人か別の大規模モデルに任せよう、と。AI をステートマシンに写像でき、しかも実際に使えるという話を聞いたのはこれが初めてだ、と彼は言った。
3 つの道を並べてみると、違いは「最後の決定を誰がするか」にある。
例示フロー · 顧客からのメール一通を例に
AI をソフトウェアに入れる 3 つの道、最後の決定は誰がするか
- 顧客からのメールが届く
- AI がメールを読み、分析を書く(自然言語の文章)
- 人がその文章を読んで理解する
- 人が自分でシステムを操作する
決定するのは誰か:人。AI は語るだけで、最後のステップは常に人が引き継ぐ。
次に、Diogo が教える使い方:たくさんの小さな問いに分解する。 ロングインタビューで彼は、Jev のクエリはプログラムを書くように明確かつ構造的に書き、問いはできるだけ文字どおりにすべきだと言う。プログラムに求められるのは、厳密に実行できることだからだ。彼の例は拒否応答だ。「ここで拒否すべきか」と聞くのではなく、多数の独立した問いに分解し、それぞれの問いで一つの具体的な状況を聞き、それぞれにしきい値を設け、最終的にどうするかはあなたのコードが決める。こうするとよいことがある。どこかで間違いが見つかったら、問いを一つ、しきい値を一つ加え、それをテストケースとして記録すれば、その問題は永久に解決する。ソフトウェアは、prompt に詰め込んだ説明のように、コンテキストが長くなるにつれて「腐る」ことがない。彼はこれを「機械学習なしの機械学習」と呼ぶ。
下のデモは返金を例に(彼の元の例ではなく、彼が語った「問いを足す、しきい値を足す、テストケースを足す」の 3 ステップだけを借りている)、間違いが起きたときに「一つの大きな問い」と「分解」で何が違うかを見るものだ:
例示デモ · Diogo の語る「問いを足す、しきい値を足す、テストケースを足す」を借用。返金の場面と数値は作例
一つの大きな問いか、小さな問いに分けるか
この返金は自動で承認すべきか?
承認、自信 71%
すべての判断が一つの答えに押し込まれている。間違えたら prompt を直すしかなく、どの段階の判断がずれたのかも説明できず、個別にテストすることもできない。
最後に、「信頼性」に対する彼の要求。 司会者は、信頼性とはモデルの可用性のことか、それとも同じ呼び出しが同じ結果を返すことかと尋ねた。Diogo はそれを 3 つの層に分けた:
- 可用性:正常に呼び出せるかどうか。彼はこれを稼働時間や SLA と呼ぶ。
- 決定性:2 回呼び出して一字一句同じ結果が返るかどうか。
- 頑健性:毎回同程度の知能水準であること。
彼が求めるものに最も近いのは 3 つ目の層だという。彼の考えでは、決定性は単体テストには役立つが、正しい北極星ではない。彼らが頑健性を測る方法は、prompt に無関係なランダムな番号の列(ロングインタビューでは nonce、インタビューでは UUID と言っている)を差し込むことだ。意味的には同じ問いなので、出力は似ているはずだ。彼が求めるのは、毎回同じ関数である必要はないが、毎回十分に賢く、人が見て「この反応は妥当だ」と思えることであり、そうであって初めて開発者は安心してそれを軸にプログラミングできる。ロングインタビューでは、決定的なモデルをつくることもできるが、それは 1 ドルあたりの知能が下がることを意味するとも述べている。
同じメールで 3 つの状況を試せば、信頼性の 3 層の違いがわかる(これも例示であり、実際の出力ではない):
例示デモ · 回答内容は作例で、実際の出力ではない
同じメールで 3 回聞く、信頼性の 3 層はどこが違うか
メール:「今月、二重に引き落とされました。多く引かれた分を返金してください。」
- 1 回目
返金の依頼と判断。まず今月の引き落とし記録を確認する。
返金 - 2 回目
返金の依頼と判断。まず今月の引き落とし記録を確認する。
返金 - 3 回目
返金の依頼と判断。まず今月の引き落とし記録を確認する。
返金
- 可用性3 回とも返ってきた ✓
- 決定性一字一句同じ ✓
- 頑健性結論が一致し妥当 ✓
これが最も理想的な状況だが、実際のシステムではまず実現できないし、実現する必要もない。
彼が信頼性に与える「最高の栄誉」は、人々がサンプルクエリを書かずに、Jev に対して直接プログラミングできることだ。さらに、信頼性の 9 が一つ増えるごとに大きな価値があるとも言う。たとえ時価総額の面で最も価値のある部分でなくても、新しいアプリケーションを生み出すからだ。
「何をもって信頼できるとするか」についての彼の要求もかなり厳しい。いちばん好きなユースケースを聞かれると、それらが本当に使えるかは確信がないと答えた。彼が求めるのは、バックグラウンドで動かして安心でき、夜中に人を叩き起こさず、他の人がその上に積み上げられること、つまり「コンポーザブル」であることだ。AI 業界はアンチパターンに陥っている、極端な事例とデモばかり見ている、と彼は言う。ロングインタビューでは、自分でもどう転ぶかわからないと断ったうえで、ある構想にも触れている。キャリブレーションとモデルのカスケードを組み合わせ、自信が高ければ小さなモデルを使い、中間領域ではより大きなモデルに引き上げ、一段ずつ上がっていくというものだ。
外部の見方:いくつかの鋭い疑問
これらは Diogo の発言ではなく、外部の見方だ。ここに置くのは、Jev をどう判断するかに直接影響するからである。
「ハルシネーションゼロ」の意味は「逸脱ゼロ」であって、「誤りゼロ」ではない。 公式ブログは「Jev はハルシネーションを起こさない」と書いている。KDnuggets の論評と HN の議論はどちらも次のように指摘する。選択肢が請求、技術、営業なら、突然「法務」と答えることはあり得ない。その答えは選択肢にないからだ。しかし「技術」を選ぶべき問いを「請求」と選んでしまう可能性は残る。公式自身の言い回しは実はもっと抑制的で、型エラーは数学的に不可能であり、この数字は実測ではなく保証だ、としている。
例示デモ · 確率の数値は KDnuggets が引用した公式の例から取り、それ以外は作例
「ハルシネーションを起こさない」は何を保証しているのか
メール:「昨日アップグレードしたのに、有料機能がまだ使えません。」
これは契約条項に関わる可能性があるため、法務部門に回すことをお勧めします。
あなたが定義した選択肢の外に出ている
自由テキストは何でも言い得るので、プログラムはさらに解析・検証してはじめて、使えるかどうかがわかる。
「それってただの分類器では?」 KDnuggets の筆者は長年、分類と言語モデルに携わってきた人物で、分類、ゼロショット分類、キャリブレーションされた確率、専用の小さなモデルでコストを抑えること、どれも新しいものではないと言う。本当に新しいのは、こうしたタスクを中心に作り直したアーキテクチャ、訓練、製品かもしれない。Diogo 自身もインタビューで Jev は「間違いなく分類器」だと言っており、避けてはいない。HN でも、BERT でとっくに似たことをやっていたという声がある。
数字は自社評価の結果だ。 公式の「より速く、より安い」は、彼らが独自につくった「ワークフロー評価」によるものだ。正解は GPT-6 Astra と Fable 5.1 の平均で、問題は自社チームがつくっている。公式は偏りがあり得ることを認め、これらの倍率は実際の場面の中でも高めの側のケースだとしている。KDnuggets はさらに、公式が報告する約 68% は「フロンティアモデルの答えとの一致度」であって、実際の正答率ではないと指摘する。既存の独立した小規模テスト、たとえばあるファクトチェックテストの 96.3% や、275 本の文書の分類テストは、いずれも規模が小さい。公式はまた、速度のデータは西海岸にある彼らのノート PC で計測したものであり、価格が補助金によるものではないことは証明できず、長期的に示していくしかないとも述べている。
堀(参入障壁)はあるのか。 HN のある議論は、OpenAI は簡単に追随できると見ている。Jev にはほかに堀がなく、ただ誰もこのようにモデルをパッケージしたことがなかっただけだ、と。インターフェースを正しくつくったことが重要なのであって、堀ではない、という反論もある。どちらもネットユーザーの意見にすぎず、私は検証していない。
こうした疑問に対する Diogo の姿勢はこうだ。公式ブログには「私たちは懐疑的な人が好きだ。私たち自身もそうだ」とあり、一部の主張は証明できないとも認めている。インタビューでも、Jev が誇大に宣伝されたあらゆる用途をすでに満たせるかはわからないが、チームはそのために全力を尽くすと語っている。
論争を呼ぶ 2 つの立場
拒否応答をしない。 ロングインタビューで彼は、API 層で安全性アライメントを行うことに反対する理由を説明している。彼にとって拒否応答は「型エラー」だ。チャットで拒否されても、煩わしいだけで済む。しかしモデルがソフトウェアの依存関係の中に隠れていて、他の人は中身を知らないのに、ユーザーから変なメッセージが来たというだけでランダムに拒否すれば、ソフトウェアはランダムに落ちる。彼によれば、安全性アライメントはチャット製品には妥当だ。それは他者(OpenAI、Anthropic)の指示に従って動いているからだ。しかし API 層では受け入れられない。開発者はそれを軸にプログラミングする必要があるからだ。司会者は反論した。では人を殺すのに使われたら? 彼は、もちろんそんなことに使われないことを望むし、別の場所で力を尽くすが、技術のこの層に価値観を加えることはしないと答えた。モデルを何か奇妙な目標に迎合させるたびに、その知能を「分断」してしまうからだという。知能は同僚よりもデータベースに近いものになり、データベースはユーザーがそれで何をするかをチェックすべきではない、と彼は考えている。この立場には異論があり、私は紹介するだけで評価はしない。
公開ベンチマークを見ない。 ロングインタビューで彼は、公開ベンチマークはスコアを稼ぐのが簡単で、かつてはどの研究所にも「MMLU っぽい」データを専門に集めるチームがあったと言う。長期的には、信頼は「感覚」と、それを自分のワークフローに入れてテストすることで築くしかない。公式ブログもそうしている。汎用のランキングではなく、彼らが設計した「ワークフロー評価」を使っているのだ。その代償として外部が独立して検証するのは難しく、それこそが上に挙げた疑問の出どころになっている。
人によって何を意味するのか
開発者にとって:自分のコードに組み込める部品が一つ増え、先にモデルを訓練する必要はない。彼が期待するのは、人々が prompt を調整し続けるのではなく、それに対して直接プログラミングすることだ。公式と外部の初期ユースケースには、Agent のルーティング(ある開発者は判断が 145〜271 ミリ秒だったと報告している)、モデルのルーティング、ブラウザ Agent などがある。
SaaS 企業にとって:司会者の一人によれば、プログラミング Agent が登場したとき「SaaS 終末論」が語られ、評価額は急落した。Jev が出ると、今度はどの SaaS 企業も最高のものだと言い出した。Diogo によれば、「SaaS 終末論」で最も根拠が弱いのは「ソフトウェアは安く、簡単にコピーできる」という部分だ。前半は信じるが、後半は信じない。ソフトウェアの下には多くの歴史的な負債が積み重なっているからだ。むしろ SaaS は今回の AI の最大の勝者の一つになると彼は考えている。最も大きく、最も退屈で、ユーザーの問題を最もよく知っている企業こそ、どのワークフローを自動化すべきかを最もよくわかっている。しかもそうした企業の資本投下の大部分は、もともとすべての顧客に届くことに費やされており、いまや製品にチャットボットを足すだけでなく、ソフトウェアそのものを大きく良くできる。彼は金融市場を予測しているのではなく、能力の面での判断を語っているのだと言い、これを「逆 SaaS 終末論」と呼んだ。
一般ユーザーにとって:彼は、多肢選択式のフォームは消えるかもしれないと考えている。それらはいつも、ソフトウェアの中にすでにある自然言語を Jev のような出力に写像しているからだ。彼は 1980 年代の 4GL というものに触れた。当時も、自然言語に近いやり方でプログラムを書けるようにしようとしていた。インターフェースは根本的に変わるかもしれないが、そのためにはもっと安く、もっと速くする必要があると彼は考えている。さらに、知能は正規表現のように背景に溶け込み、もう注目されなくなるかもしれないとも言う。
システム寄りの人にとって:コストも速度も異なる大量の知能が手に入ると、最も「システム派」の人は自分でトレードオフを決める。彼らにとって Jev は「1000 倍賢すぎる」ので使い道がなく、欲しいのは近似的な推測だけで、楽観的にリクエストをあちこちにルーティングしたいのだという。良い知らせは、これで再びシステムを作り直す機会が来たということだ、と彼は言う。新しい基礎部品ができたのだから、インターネットやクライアント・サーバーの時代のように、周期的にそうしていくのだ。司会者の一人はさらに、サイバーセキュリティの問題だけでも、ほぼすべてのシステムを作り直す必要があるかもしれない、少なくとも重要インフラは確実にそうだと述べた。
雇用にとって:司会者の一人は、TypeSafe の言葉でいちばん好きなのは「私たちは製品をつくる。神はつくらない」(build prod, not God)だと言った。他の大手研究所のトップは内心喜んでいても隠すが、TypeSafe の姿勢は、はるかに良い世界をつくる、仕事は減らず、むしろもっと増えて、もっと良くなるというものだ。Diogo は同意し、悲観的な物語には賛同しないと述べた。それは皆が「一つの頭脳がすべてを支配する」という単一モデルの幻想を信じ込んだことから来ているという。
まだ答えが出ていないところ
Diogo は自分の境界線を引いている。まず簡単な仕事を自動化し、難しいものはその後だ。司会者の一人は、これがどこまで深く行けるかはまだ非常に開かれた問題だと指摘した。たとえば状態の一貫性、永続性、あるいは強い保証が必要なシステムレベルの領域だ。Diogo は同意し、確かなのは、ログの分析、メールの分析、インターフェースの提供、人との対話は必ず変わるということだと述べた。もっと先については、時間とともにインテリジェントなデータベース、さらには航空管制システムになるかもしれないと言い、対話の中では「ちょっと怖い」という声も出た。また、リソースや権限をつなぐのであれば保証、少なくとも統計的な意味での保証が必要で、それは誰かがそのためのソフトウェアを書かない限り、彼らのモデルでは短期的には実現できないとも述べた。
方向性についてもいくつか触れている。確率的プログラミングには長い歴史があり、1970 年代ごろに衰退した。今回も浮き沈みがあるだろうと彼は考えている。彼自身のラベルは「極端に実務的」で、生物に着想を得たものは好きではなく、それがうまくいったためしはないという。自分でこの仕組みを書くためではなく、世界のためにワクワクしている、とも言った。自分で書くには複雑すぎるように聞こえるからだ。
この人物は何者か
彼の経歴は少し型破りだ。数学オリンピック出身だが、実は数学を本当に好きになったことは一度もないと言い、コンピューターサイエンスは「数学に似ているけれど、クールで、役に立って、面白い」と感じている。自分を AI 研究者ではなく、コンピューターサイエンティストだと考えている。彼は Kaggle のコンペで優勝してこの世界に入ったが、そのとき頼りにしたのは高度な数学ではなく、徹底した自動化だった。その後 NeurIPS で講演することにもなった。本来は栄誉なことだが、彼はそれが嫌で、ただ黙々と仕事がしたかったという。その後、Jeremy Howard と起業し、Google Brain に在籍し、さらに OpenAI で働いた。公式ブログによれば、TypeSafe はステルス状態で 2 年間開発を続け、ようやく Jev を公開した。
インタビューの最後、彼は自分が求めるものをひと言にまとめた。do what I mean。それは世界の滑らかさであり、すべてが歯車のようにかみ合うことだという。あらゆる技術が自分の意図どおりに動くことを想像するのは、SF ではない、と。
