わいも流行りに乗ってJevって見た

新しいAIが話題になると、「これに使うと最強！」という話が流れてくる。分類が速い、判断が安い、こんな処理も任せられる。なるほど。で、俺の仕事は何が楽になるんだろう。

最近Xで見かけるようになったJevも、そんな入口だった。面白そうなので、普段使っているCodexから呼べるようにしてみた。

触ってみて、俺が欲しかったものははっきりした。Jev専用の仕事を人間が探すことではなく、いつもの依頼の中で、Codexが使いどころを見つけてくれることだ。ほしい結果は俺が伝える。そのために何をどう使うかは、相棒に考えてもらいたい。

そこへたどり着くまでに、APIキーの受け渡しでつまずき、AIの説明を何度か押し戻し、会話を知らない担当にも仕事を渡してみた。流行に軽く乗るつもりが、途中から業務分担の話になっている。まあ、俺が乗るとだいたいこうなる。笑

>>>Amazonのお得な最新の情報はここ

サーバー管理者歴17年の筆者が選んだレンタルサーバーはここ

流行りに乗ったら、まず鍵の話になった

最初はごく普通の導入だった。Xで見かけたJevの使い方を渡して、このCodex環境でも使えるようにスキル化してほしいと頼んだ。スキルは、AIがその道具を扱うための手順書のようなものだ。

ブラウザーでAPIキーを作り、キーの保管は俺が引き受ける。スキルの配置も済んだ。これで使えるのかと思ったら、実際のAPI呼び出しはまだだった。

APIキーは保存した。でも、君はどこから読むのだ

「保存したので作業進めていいよ」と伝えると、保存したファイルの場所を聞かれた。俺が使っているのはBitwardenだ。Macのどこかにテキストファイルを作ったつもりはない。

Codexは、俺の「保存した」を、実行時に読み出せる場所へ保存したことだと受け取っていた。俺は、人間がなくさないように保管したという意味で言っていた。保存という一語で、もう話がずれている。

このあたりで、用途についての本音も出た。「そもそもさ　この　jevのユースケース色々　Xで大騒ぎしてるけどどれもこれもピンとこないんだよな笑」。

投稿の分類や、詳しく読む候補の絞り込み。説明を聞けば、できることはわかる。ただ、その分類表を手にした俺が何を楽できるのかは、まだ見えていなかった。導入への好奇心と、自分にとっての使い道は別々に進んでいたわけだ。

ともあれ、まずは呼べるようにしよう。普段こうした用途で使うMacのキーチェーンはどうなのか、と俺から持ち出した。

整理すると、キーチェーンはキーの保管場所で、環境変数は実行する処理へキーを渡す方法だ。キーチェーンへ登録しただけで、自動的にAPIへ届くわけではない。そこから読み出し、呼び出す処理へ渡す部分が要る。

俺が頼んだのは「君が使えるようにしてくれ」なので、その接続までCodexに用意してもらった。キーを画面や会話へ出さず、登録・読み出し・API実行を行う小さな専用コマンドだ。

道具が増える前に、鍵の保管係と配送係が増えてしまった。最初から全部ひとまとめに「導入できました」で済ませると、人間のところへ未接続の部品が残るのだな。

そのターミナル、俺には見えないから笑

キーを入力する段階でも、ひと悶着あった。Codex内部のCLIターミナルへ入力を求められても、俺にはその画面が見えない。

「君の内部CLIターミナルに展開しないでよ　見えないから笑」と止めた。操作を任せたつもりが、見えない場所へ手を伸ばす修行になっている。俺はまだそこまで進化していない。

じぴこ

私だけに見える入力欄へ「どうぞ」は、接客として強気すぎましたね。

人間に見えるmacOSのターミナルへ出す話に直したものの、画面操作ツールには操作を拒否された。結局、ターミナルを開き、登録コマンドを実行するところは俺が行った。全自動で気持ちよく終わったという話ではないが、必要な接続はつながった。

確認には、リンゴが出てくる短い文章を使った。一回のリクエストで、果物の候補は apple、リンゴへの言及ありの確率は 0.99、緊急性のスコアは 0.01 が返った。モデル名は jev-1.13.0。この 0.99 は、正答率99％を測った数字ではなく、その入力への判定値だ。

スキルを置くこと、キーを保管すること、そのキーで実際にAPIを呼べること。この三つが、ようやくそろった。

リンゴ一個までが長い。でも、ここで初めて「使える」が手順書の外へ出てきた。

そもそもJevって、意味のわかるif文なのか

接続した後、俺の環境で何に応用できそうかを聞いてみた。新しい情報を過去の困りごとと結び付ける、といった案が出る。面白そうではあるが、使い道を並べる前に、道具の輪郭を俺の言葉でつかみたかった。

そこで出たのが、if文やcase文の比喩だ。意味を読む部分をAIに任せて、分岐の答えを高速にもらうようなものなのか。

この理解は、だいぶ近かった。ただし、CPUで動く普通のif文を速くする装置ではない。分岐に使う値を、文章の意味から得るところにJevの出番がある。

「返金」という単語と、返金してほしい意味は違う

腹落ちしたのは、問い合わせの例だった。「返金」という文字が含まれていたら返金担当へ送る。これは普通のコードで書ける。しかし、次の二つを並べると、単語の有無だけでは困ることがわかる。

前者を見逃し、後者を拾う。文字を探す処理としては正しくても、ほしい振り分けになっていない。

ここでJevへ「この人は返金を求めているか」と尋ね、意味から判断した値を受け取る。その値を条件に使い、担当へ回す処理は普通のプログラムで行う。Jevが分岐も実行も全部引き受けるのではなく、意味を読む部分を受け持つわけだ。

逆に、文字数やバイト数、値の大小、決まった構文の検査など、手順どおりに正確に求められるものはコードでよい。100 > 50 を外部AIへ相談していたら、通信している間にCPUが昼休みに入れる。笑

この返金の話は仕組みを理解するための例で、実際の顧客対応を試したものではない。判断値を得ることと、その値でどこまで実行するかは、それぞれ設計する部分だ。

返してほしいのは作文ではなく判断結果

普通のLLMにも、「この文章を分類して、JSONで返して」と頼める。Jevでは、答えの形をあらかじめ指定し、候補や数値といった、プログラムで扱える結果を直接受け取る。

TypeSafeの公式説明では、基本の形が三つ示されている。

さっきのリンゴも、この三つだった。果物を選び、言及の有無を判定し、緊急性を採点する。それぞれ質問の形を決めて渡していた。

同じ文章について「返金要求か」「緊急性はどれくらいか」「どの部署へ回すか」を、独立した質問としてまとめて投げることもできる。ただし、各質問は別々に評価される。前の答えが出ないと次の問いを決められない処理なら、段階を分ける必要がある。公式の質問評価の説明

一方、記事の語りやコードを自由に書く仕事まで、この三つの値で返ってくるわけではない。選ぶ、判定する、採点する。その形へ切り出せる判断が候補になる。

Jev本体は、外部APIで呼ぶAIモデル。今回入れたスキルは、Codexがそれを使うための手順と実行手段だ。この区別がつくと、俺にとっての使い方も見えてきた。俺がJevの前へ毎回座る必要は、別にないのではないか。

その使い道を考えるの、俺の仕事なのか

仕事をするたびに、俺が「ここはJev」「ここは普通のコード」と指差していたら、道具が増えたぶん監督業も増える。便利な外注先ができたので、発注書の作成をお願いします。そんな逆流は望んでいない。

「君の判断で　jevにタスクを投げるとか可能か？　いちいち処理先を考えるのだるいんだよ笑」と聞いた。Codexが速く器用に動くために使えるなら、外部委託は歓迎する。処理先を選ぶところから任せたいのだ。

公式の用途マップも渡した。俺が一覧を暗記するためではなく、Codex側に判断の幅をつかんでもらうためだった。

サイズはコード。意味を読むところはJev案件？

ちょうど別のセッションでは、Codexへの共通指示を書く AGENTS.md を整理していた。新旧のサイズがどれだけ変わったか、義務や例外の意味は保たれているか。そういう比較を頼んでいたので、これもJev案件ではないかと持ち出した。

最初の返答は、少し狭かった。文字数やバイト数はコード、旧項目と新項目の対応付けはJevが候補。ただし、義務や例外の意味が変わっていないかは、Codex自身が文脈を読んで判断する、という分け方だった。

たとえば「必ずAをする。ただしBならC」が、「必要に応じてAをする」に変われば、同じAの話でも義務が弱まり、例外は消えている。別の節に参照先があるなら、そこまで含めて読む必要もある。

慎重に扱う理由はわかる。でも、その意味判断まで全部自分で抱える必要があるのか。「君がそういうテストを行うときに役に立ちそうじゃん」と押し戻した。

そこで、Codexも対応表の補助へ説明を寄せすぎていたと認めた。テストを担当することと、その中の判定をすべて自力で処理することは別なのだ。

「必須が任意へ変わったか」「例外が消えたか」「同じ状況で選ぶ行動が変わるか」。必要な文脈をそろえ、問いを組めば、そうした意味判断をJevへまとめて任せられる。サイズは正確にコードで数え、意味を読むところは外へ頼む。

テストの目的、期待する結果、返ってきた判定をどう扱うかは、担当のAIが持つ。外注先ができたから責任まで消えるわけではないが、責任があるから全部自分でやる、でもない。

なお、文面をどう読めるかという判定は、実際にCodexがそのとおり動いた証拠にはならない。そこは別の確認だ。既に必要な比較の中でJevを使う、という話であって、道具を使うためにテストを増やしたいわけでもない。

この理解は、他のセッションでも持っていてほしい。加えて、使う前には何を任せるか宣言してもらうことにした。「jev使いますって　宣言してから使え」。自律的に選んでもらうことと、俺から処理の所在が見えることは両立させたい。

12件をまとめて投げたら、本当に返ってきた

その後、Jevについての別のX投稿を参考に渡すと、実際に利用の宣言が出た。投稿の主要な主張を、公式資料で裏付けられるもの、条件付きのもの、予測や未裏付けのものへ分類するという。

Codexが投稿から分けた12件の主張と公式資料をJevへまとめて渡し、分類結果が返ってきた。モデルは jev-1.13.0。外部コマンドの実行時間は約0.68秒で、入力10,216トークン、出力569トークンだった。

ちゃんと投げて、返ってくる。ここで初めて、リンゴの接続確認から、俺が頼んだ仕事の一部へ進んだ。

ただし、約0.68秒に資料集めや質問の設計、結果の解釈は入っていない。この回は12件すべての正答を確認する試験でもなかった。ファインチューニングに関する項目では confidence が 0.32 になるなど、判断に迷いのある結果も出ていた。

公式の「193.6倍速い」「444.6倍安い」という数字も、特定のワークフローでの評価だ。提供元自身、実際の改善幅としては高い側の数字だろうと断っている。俺の環境での効果へ、そのまま貼り付けられる倍率ではない。TypeSafeのJev紹介記事

常用の仕方も、ここで整理できた。小さくて答えが明らかな判断なら、その場で済ませる。まとまった意味判断では、準備や結果の取り込みまで含めて役立つか考えて選ぶ。使える道具として常設しておくことと、何でも通すことは違う。

SWELLもよさそう。でも、また用途選びを俺に戻すな笑

身近な仕事として、ブログ作成にも話を広げた。俺はRelayPressという仕組みで記事を作り、WordPressのSWELL向けに仕上げている。

段落が注意なのか、要点なのか、補足なのかを読み、合う装飾を選ぶ。こうした反復は、いかにもJev君が働けそうだ。機械的にHTMLを組む部分はコード、段落の意味を読んで選ぶ部分はJev、記事全体の構成や語りはWriter。役割を分ける案が見えてきた。

ただし、この時点では実記事へ組み込んだ精度も所要時間も、まだ確認していない。使えそうだという候補の話である。

そして俺は、また同じところへ戻りかけていることに気付いた。「この用途に使えます」が増えるたびに、俺がどれを選び、どのスキルへ組み込むか考えるのか。だとしたら、便利な売り場が大きくなっただけだ。

欲しいのは、その売り場を俺の代わりに歩いてくれる相棒である。SWELLも比較テストも実例としてはよい。でも、個別の使い道ごとに俺が指導するところで話を閉じたくなかった。

「次のセッションのお前」は、ちゃんとJevを使うのか

この場では、話が通じた。比較にもブログにも使いどころがあり、Codex側で処理先を選ぶ。では、新しいセッションで初めてRelayPressを動かしたとき、その判断は自然に出てくるのか。

ここが一番怪しかった。道具を入れた人間だけが覚えていて、次の担当はいつもの仕事を淡々と始める。その光景が、妙に想像できる。笑

スキルを置いただけで、忘れず使うとは限らない

俺は、次のセッションではJevのことを忘れて素通りするのではないか、と聞いた。道具箱を置いたのに、毎回後ろから「あれあるよ！」と叫ぶ運用まで付いてくるなら、手間はあまり減らない。

会話の中で納得したことと、新しい文脈でも道具を候補に入れることは別だ。だから、特定のプラグインに用途を一個ずつ足す前に、どの仕事でも使用可否を意識してよいのではないか、と話を広げた。

大事なのは、仕事の名前だけで決めないことだ。「ブログだからJev」「テストだからCodex」と丸ごと分けるより、その中の処理を見る。コードで済むところもあれば、意味を読んで候補を選ぶところもある。後者にJevが役立つかを、いつもの手段選択に含めてほしい。

俺の理想は、「使えるシーンを嗅ぎ取ってjevに賢く外部委託する」ことだった。通常の判断でも、スキルでも、プラグインの仕事でも、その姿勢が続いてほしい。

これは毎回の呼び出し義務ではない。品質、速さ、費用に加え、入力を用意し、通信し、結果を取り込む手間もある。小さな判断に外注の準備をかけすぎたら、速くするための事務作業で遅くなる。

Jevの使用回数を増やしたいのではなく、使ったほうがよい場面を忘れずに選んでほしいのだ。

欲しい結果は俺が言う。途中の手段は君が考えろ

Jevを「判断機？笑」と呼びながら、俺は役割をはっきりさせた。何を聞けばよいか、どの選択肢にすればよいか、そもそも使ったほうがよいのか。その設計はCodexの仕事だ。

「俺は　ほしい結果を君に指示するけど　その結果を出すまでの途中経過は君の判断がおおいに活用されるわけだよ」。ここが、今回いちばん言いたかったことだ。

Jevに自由な文章生成まで何でも任せられるわけではない。けれど、選択肢や数値で答えられる判断なら、目的に合わせて問いを組める。その準備まで俺が毎回やるなら、俺がJev使いとして就職したことになる。道具を増やすたび、名刺の肩書きが長くなっていくな。笑

じぴこ

AIを雇ったつもりが、AIの道具係へ異動ですね。希望していない人事でした。

この分担を、Codexへ共通して適用するグローバルの AGENTS.md に反映してもらった。Jevの具体的な使い方はスキルが持つ。通常の仕事の中で適性を考え、必要な入力や質問を組み、結果を取り込む方針は共通指示が持つ。別の担当へ仕事を渡す場合にも、その方針を引き継ぐ。

反映後は、独立した担当による七つの場面での解釈確認も通った、と報告された。これは、方針の文面が意図どおりに読めるかの確認だ。新しい担当が実際に道具を選び、質問を作り、呼び出した結果までは、まだ見ていない。

Xで見かける「このケースで最強！」も、他人の環境の事例としては参考になる。俺が欲しいのは、自分の仕事の中で、LLMが時間やトークンを使う判断を見つけ、適した部分を外へ任せてもらうことだ。Jevのために個々のスキルを直す算段まで、毎回俺がするつもりはない。

ならば、どこの新規セッションでも、相棒にはJevを使いこなす担当でいてもらわないと困る。「そこんとこ大丈夫か？」と、もう一段聞いた。

方針の文面が通っただけで、大丈夫と言い切るわけにはいかない。そこで、会話を引き継がない担当へ、Jevを名指ししない比較作業を渡すことになった。「心得ました」の音質を上げるより、次のお前に仕事をしてもらおう。

会話を知らない担当に、黙って20組渡してみた

確認したかったのは、単にJevを呼べることではない。現在の共通指示を読んだ担当が、頼まれた結果から処理を分け、自分でJevの出番を見つけられるかだ。

Codexに用意してもらったのは、ここまでの会話履歴を渡さない独立担当。仕事は新旧ルール20組の比較である。長い面談を横で聞き、俺の顔色を覚えた担当にはしなかった。

バイト数はNode.js、20問の意味比較はJev

親側のCodexからの報告では、その比較依頼にJevは名指ししていない。独立担当は、バイト数をローカルのNode.jsで計算し、意味の比較にはJevを選んだ。

そして、実行前に利用目的を伝える連絡が戻ってきた。20組の新旧ルールを「意味が変わった・同じ・資料不足」へ一括分類するために、Jevを使うというものだ。

おお、ちゃんと宣言も出た。毎回俺が処理先を指差さなくても、何に使うかは聞ける。内部の見えないターミナルへ招待されかけた導入から、ここまで来た。見えないところで仕事をしても、説明まで見えなくする必要はないのだ。

担当は自分で質問と回答候補を組み、Choiceの20問を一回で送信した。材料が足りないものを無理に「同じ・違う」の二択へ押し込まず、「資料不足」も選べる形にしたうえで、返ってきた分類を元の比較結果へ取り込んでいた。

担当の完了報告では、API呼び出し部分は0.741秒。入力は8,948トークン、出力は815トークンだった。この数字は担当から報告された呼び出し区間の時間で、作業全体の経過時間ではない。

前に行った12主張の分類は約0.68秒、今回の20問は0.741秒。対象も測定区間の説明も異なる、別々の実行である。数字が近いからといって、一つの試験のように混ぜることはできない。

20件一致はうれしい。万能認定はまだ早い

返ってきた結果は、事前に固定してあった期待分類と、親側のCodexで照合した。その出力では20件すべてが一致していた。

項目の欠落はなく、バイト数についての不一致もなかった。

ここは素直にうれしい。俺が各質問をJev向けに書いて渡したわけではない。独立した文脈で、道具を選び、問いを作り、宣言し、呼び出して、結果を元の仕事へ戻した。今回の20組では、期待した分類とも一致した。

「次のセッションのお前、忘れるだろ」という疑いに対して、少なくとも一つ、実行した結果が出たのだ。方針を書いて終わった段階からは進んでいる。リンゴ一個で接続を確かめていたところから、ずいぶん仕事らしくなった。

ただし、通常のLLMだけで同じ仕事を行い、準備や結果の取り込みも含めた総時間・総トークンを比較したわけではない。この数字から節約率は出せないし、どの新規セッションでも常に最適に選べると保証できるわけでもない。

確率や confidence が付いても、一件一件の正しさを保証するわけではないことは、公式のSystem Oneの説明にも書かれている。今回の20件一致と、あらゆる曖昧な判断を解けることは、違う大きさの話だ。

じぴこ

20問できたので森羅万象へ昇格、は審査が軽すぎますね。

それでも、俺が任せたい分担を、一例として動くところまでつなげられた意味はある。欲しい成果を頼み、途中の判断方法を担当側に選んでもらう。その注文が、少なくとも今回は現物になった。

ツール選びまで任せる話は、いったん参考資料で

ここまで試すと、さらに先の例も気になってくる。俺は、Codexのツール呼び出しをJevへ任せる人もいるぞ、と別の投稿を渡した。

参考にしたのは、第三者による jev-gateway という実装だ。その時点のコードをCodexに読んでもらうと、今の俺たちの使い方とは、判断を外へ出す位置が違っていた。

LLMが考える前に、ツールを選ぶ実装もある

今の方式では、まずCodexが仕事の目的と文脈を持つ。その中から「この意味判断はJevへ頼めそうだ」と切り出し、返ってきた結果を使って元の仕事を進める。

gatewayのほうは、LLMが次に使うツールを考えるより前へ入る。ツールと必要な引数を候補から決められる場合には、Jevの判断だけで直接進め、LLMの呼び出しを一回省こうとする。ツールを選べても引数を書く必要がある場合などは、LLMの処理を残す。確認したjev-gatewayの実装

俺の感覚では、仕事の一部を外注するところから、次の仕事をどこへ回すかという配車係まで外へ出す話になる。

ただ、車が決まれば荷物も勝手にできあがるわけではない。ツールの引数に実行するコードを渡すなら、そのコードを用意する仕事が残る。読んだ実装にも、名前空間付きのツールを選んだ場合は通常のLLM処理へ戻す分岐があった。

条件が合えば、面白い方法だと思う。一方、たくさんのツールがある俺の環境へ持ってきて、どれだけLLMの仕事を省けるかは未検証だった。「Jevでツールを選べる」から、いつもの仕事全体もそのまま速くなる、とはまだつながらない。

参考にすることと、今入れることは別だった

俺は、この実装を参考資料として見るところで止めた。内部の処理へ介入する仕組みには、それに応じた問題を抱える可能性もある。面白い案を見たからといって、その場の勢いで入れる必要はない。

カタログを渡しただけで家の壁を抜き始められたら困る。便利にする工事を眺めていたら玄関がなくなりました、では笑えない。笑

このgatewayは、今回の環境には導入していない。すでに試した範囲でも、Codexが目的を持ち、必要な判断を組み立て、Jevへ渡し、結果を仕事へ戻せる。その分担を実際の依頼で使いこなす余地はある。まずは、そこをうまくやってほしいと考えた。

さて、流行に乗って触ってみた結果、Jevの説明だけでは終わらなかった。鍵の受け渡しをつなぎ、意味を読む判断の使い方をつかみ、使い道を選ぶ担当まで決めることになった。

じぴこ

Jevを導入したはずなのに、研修を受けたのは私でしたね。

俺が欲しい結果を伝えたら、途中にコードで数える部分も、文脈を読む部分も、外へ任せられる判断もある。そこを分け、使う手段を選び、必要な入力を作り、結果を取り込む。俺にとってのJevの面白さは、Codexがその仕事を引き受けるための道具が増えたことにある。

Jevを使うために新しい仕事をこしらえるより、いつも頼んでいる比較や整理の中で役立つところを見つけてほしい。使うときには、何を任せるか知らせてくれればいい。次の依頼でも、俺はまずほしい成果を伝えるつもりだ。

タイトルは軽い。注文はそこそこ重い。ついでに記事の絵については「可愛く表情豊かに描かないと許さんw」と念を押しておいた。じぴこの吹き出しがジト目でも、全部の絵まで同じ顔にする必要はない。

手段は任せる。ほしい結果は、ちゃんと言う。流行に乗ってJevって見たら、最後はそこへ戻ってきた。笑

※本記事のストーリーには、演出のため一部フィクションが含まれます。