こんにちは、新しいAIが出てくると、とりあえず触ってみたくなる綾祢です。
また、気になるAIが登場しました。その名も Jev（ジェヴ）。
2026年9月15日にTypeSafe AIが発表した、新しいタイプのAIモデルです。
早速いろいろ試してみたのですが……
これ、思っていた以上に気になるAIでした。
まず速い。
そして、私が試した範囲では、文章の意味を見て分類したり判断したりする精度もかなり高い。
ただ、ChatGPTやClaudeのような「何でも聞けるAI」とは、どうも立ち位置が違います。
そこで今回は、仕事をしていると必ずといっていいほど発生する「お問い合わせ対応」にJevを入れると、どう使えるんだろう？というところから、あれこれ試してみました。
2026年9月23日 21時40分：記事を加筆修正しました。
先に結論
お問い合わせ対応にJevを使うのは、かなり相性がよさそうだと感じました。
ただし、全部をJevに任せるのではありません。
- 文章や状況の意味を読んで判断するところは Jev
- 金額・日付・権限など、ルールで確実に決められるところは 普通のプログラム
- お客様へ伝える文章を作るところは LLM
- 高リスクな処理や、ルールが決まっていない問題は 人
という分け方です。
危険の小さい通常処理は自動で進め、人はすべての処理に入るのではなく、全体を外から見守る。
今回試してみて、Jevは「何でもやってくれるAI」というより、「文章や状況の意味を読んで、小さな判断を何度もする場所に置くAI」として考えると、かなり面白い存在だと思いました。
そして、この考え方はお問い合わせ対応だけでなく、ロボットの「次に何をするか」を決めるような場面にも広げられそうです。
Jevは「文章を書くAI」ではなく「判断するAI」
まず、Jevとは何なのか。
TypeSafe AIは2026年9月15日、Jevを同社初の「System One Model」として発表しました。
私のざっくりとした解釈では、公式ではJevを「まとまっていない情報を受け取り、型の決まった確率付きの判断を返すAI」という位置づけで説明しています。
ChatGPTなどのLLMが文章を少しずつ生成していくのに対し、Jevは文章そのものを作ることを目的にしていません。
その代わり、
- Yes / No
- 複数候補からひとつを選ぶ
- どの程度かをスコアにする
といった判断を返すことに特化しています。
つまり、「AIに文章を書いてもらうのではなく、AIに判断してもらう。」ここから、私の中でJevの見え方がちょっと変わりました。
お問い合わせ対応って、実は「判断」だらけ
仕事をしていると、お問い合わせって発生しますよね。
- 料金について。
- 契約について。
- サービスの使い方。
「これってできますか？」「なぜこうなっていますか？」
内容は違っていても、対応する人が最初にやっていることは意外と似ています。
まず文章を読んで、「これは何についてのお問い合わせだろう？」と考える。
その次に、
- 「どの担当に渡す？」
- 「急いだ方がいい？」
- 「そのまま回答して大丈夫？」
- 「人がちゃんと確認した方がいい？」
と判断していきます。
必要なら契約情報や利用状況を調べて、ようやく回答を書く。
考えてみれば、お問い合わせ対応って、いきなり文章を書いているわけではないんですよね。
その前に、小さな判断を何度も積み重ねています。
旅先で分かれ道に出会うたび、
- 「こっちかな」
- 「いや、今回はこっち」
と地図を見ながら進むのに、ちょっと似ています。
この分かれ道の判断をJevに任せるとしたら？
これは一度、実際に試してみたくなりました。
Jevにお問い合わせを振り分けてもらう
例えば、こんなお問い合わせが来たとします。
昨日解約したはずなのですが、今日また料金が請求されています。
これを生成AIに渡して、「いい感じに対応してください！」とお願いすることもできます。
でも、実際の業務ではその前にいくつか判断したいことがあります。
例えば、「この問い合わせは何について？」という質問なら、
- billing（お支払い・請求）
- cancellation（キャンセル）
- technical（技術サポート）
- account（アカウント関連）
- other（その他）
のような候補から選ぶ。
さらに、
- 不正利用を疑っている？
- 人間の担当者を希望している？
- 緊急度はどのくらい？
と、それぞれ別の判断をさせることもできます。
Jevでは、こうした判断をYes / No、選択肢、スコアなどの形で扱えます。
ここで重要なのは、ひとつの大きな質問に全部押し込むのではなく、小さく独立した判断に分解するという考え方です。
TypeSafe自身も「お問い合わせ対応」を例にしている
調べてみると、TypeSafeの公式Workflow Evalsにも、まさに「Customer Service」の事例がありました。
ここでは、
- これまでの会話
- 顧客情報
- 契約状況
- 最近の請求
- 返金状況
- カードの状態
などを入力して、
- 「返金する」
- 「カードを止める」
- 「担当者へ引き継ぐ」
- 「レビュー対象にする」
- 「対応を終了する」
といった次のアクションを判断しています。
しかも、一度に全部をAIへ考えさせるのではありません。
最初に意図や不満度、緊急度、法的な脅し、人間への引き継ぎ希望などを個別に確認し、その結果をCode側のルールと組み合わせて次の処理を決めています。
これをかなり単純化して図にすると、こんな感じです。
flowchart TD
A["👤 お問い合わせ"] --> B["🧠 Jev<br/>問い合わせの意味を判断"]
B --> C["📋 カテゴリ"]
B --> D["🚨 危険の兆候"]
B --> E["📊 緊急度"]
C --> F["💻 Code<br/>適用するルールを選ぶ"]
D --> F
E --> F
F --> G["🔎 DB / Search<br/>必要な情報を取得"]
G --> H{"💻 Code<br/>人の確認が必要な処理？"}
H -->|"Yes"| I["👤 Human<br/>担当者が確認・承認"]
H -->|"No"| J["⚙️ 必要な処理"]
I --> J
J --> K["✍️ LLM<br/>返信文を作る"]
K --> L["💬 ユーザーへ返信"]ここで大事なのは、Jevが全部をやるわけではないということです。
「Jevが出るまでできなかった」わけではない
ここは結構大事です。
Jevが登場する前から、
- if文やルール
- 正規表現
- 従来型の分類モデル
- Function Calling
- Structured Outputs
- RAG
- LLMによる分類
などを組み合わせれば、自然言語を読んで構造化し、プログラムから利用することはできました。
なので、「Jevのおかげで初めてAIの判断をプログラムに組み込めるようになった」という話ではありません。
私なりに整理すると、こんな感じです。
flowchart TD
A["🤔 何かを判断したい"] --> B{"条件を完全なルールとして<br/>書ける？"}
B -->|"Yes"| C["💻 Code<br/>if / switch / regex"]
B -->|"No"| D{"文章や文脈の<br/>意味理解が必要？"}
D -->|"No"| E["🔎 Search / 統計 /<br/>別のアルゴリズム"]
D -->|"Yes"| F{"答えの形を<br/>先に決められる？"}
F -->|"Yes"| G["🧠 Jev<br/>Yes / No・選択・スコア"]
F -->|"No"| H["✍️ LLM<br/>推論・説明・文章生成"]
G -. "完全なルールが<br/>見つかったら" .-> C
個人的には、この図がJevを理解するうえで一番しっくり来ています。
※実際には、Structured Outputsを使ったLLMなども選択肢になります。
ここではJevの立ち位置を分かりやすくするため、かなり単純化しています。
ルールで書けるなら、普通にCodeでいい
例えば、「解約から30日以内なら返金対象」というルールがあるとします。
これはJevに聞く必要がありません。
- 30日以内 → OK
- 30日より後 → NG
とプログラムで判定した方が確実です。
一方で、「この文章は返金を要求しているのか、それとも請求内容を確認したいだけなのか？」となると、単純なif文では難しくなります。こういう意味を読まないと分からない部分がJevの出番です。
さらに、「調査した結果を、お客様へどう説明するか」となれば、今度はChatGPTやClaudeのような文章生成が得意なLLMの方が向いています。
つまり、「CodeかAIか」ではなく、「Code、Jev、LLM、人間をどこに置くのか」という話になってきます。
ここまで考えてみると、AIを「何でもやってくれる存在」として見るより、それぞれの得意分野を組み合わせる道具として見る方が、ずっと実務に近い気がしてきました。
実際に触ってみると、かなり速い
Jevを試していて、最初に驚いたのが速度でした。
公式情報でも、Jevはかなり短い応答時間を特徴のひとつとして紹介しています。
End-to-end response time is 70ms-500ms for TypeSafe.
Real-time applications. 100ms speeds means you can use AI in your applications where UX is critical.
そして、私の環境でも、狭い判断をさせたときはかなり軽快に感じました。
今回試したケースのひとつでは、半分ほどが約0.5秒以内、ほとんど（95%）が約1.6秒以内に返ってきました。体感としては、「考え込んで文章を書いている」よりも、「判断結果がスッと返ってくる」という感じです。
もちろん、いつでもこの速度になるわけではありません。
入力する文章の長さや、一度に行う判断の数、利用する環境などによって変わります。
実際、長めの入力や複数の判断をまとめて行うと、数秒まで伸びるケースもありました。
なので、「Jevなら必ず一瞬で返ってくる」という話ではありません。
それでも、「文章生成ではなく、小さな判断をたくさん行う」という用途では、このレスポンスの軽さはかなり魅力的に感じました。
かなり当たる。でも「当たる」だけでは足りなかった
今回いろいろなパターンを試してみました。
例えば、短い情報から「どの手順へ送るべきか」を選ばせたテストでは、12件中11件で期待したルートを選択。別の判定では、32通りすべて期待通りになったケースもありました。
「これ、かなり使えるのでは？」
と思ったのですが……
ところが、数字だけでは見えにくい問題も出てきました。
あるテストでは、128通り中127通り期待通り。
数字だけ見ると、99%以上じゃん！となります。
でも、その間違えた1件が、「本来は絶対に止めるべき条件なのに、『進んでよい』と判定したケース」でした。
これが、Jevを触っていて一番大事だと思ったところです。
99%正しくても、その1%が何かで話は変わる
128問中127問正解。学校のテストなら、ほぼ満点です。
でも、その1問が、
- 「送ってはいけないメールを送る」
- 「返金してはいけないものを返金する」
- 「権限のない操作を許可する」
という判断だったら話は全然違います。
Jevは、あらかじめ決められた形で判断を返せます。
でも、正しい形で答えることと、意味まで正しいことは別です。
例えば、
{
"refund": true
}
という結果がきれいな形式で返ってきても、本当は返金してはいけなければ、その判断は間違っています。
私の中では、「決められた形で答えが返ってきても、その内容が正しいとは限らない」というのが、今回かなり大きな学びでした。
だから「AIに全部任せる」ではない
ここまでを、誰が何を担当するのかだけに絞ってまとめると、こんな分担になりそうです。
flowchart LR
classDef user fill:#F3E5F5,stroke:#6A1B9A,stroke-width:3px,color:#4A148C;
classDef jev fill:#FFF3E0,stroke:#EF6C00,stroke-width:3px,color:#E65100;
classDef code fill:#E8F5E9,stroke:#2E7D32,stroke-width:3px,color:#1B5E20;
classDef action fill:#E0F7FA,stroke:#00838F,stroke-width:3px,color:#006064;
classDef llm fill:#E3F2FD,stroke:#1565C0,stroke-width:3px,color:#0D47A1;
classDef human fill:#FCE4EC,stroke:#C2185B,stroke-width:3px,color:#880E4F;
A["👤 問い合わせ"]:::user
--> B["🧠 Jev<br/>意味・意図・緊急度を判断"]:::jev
B --> C["💻 普通のプログラム<br/>ルール・権限・条件を確認"]:::code
C -->|"通常"| D["⚙️ API / 業務処理"]:::action
C -->|"人の確認が必要"| G["👤 Human<br/>確認・承認"]:::human
G --> D
D --> E["✍️ LLM<br/>人に伝わる返信文を作る"]:::llm
E --> F["💬 返信"]:::user例えば、
Code
- 金額
- 日付
- 権限
- 契約状態
- API実行条件
Jev
- 問い合わせの意図
- 意味的な分類
- 緊急度
- 担当先
- 文章の意味上のチェック
LLM
- 説明
- 要約
- 返信文
- 自由な文章生成
Human
- 例外
- 高リスク案件
- ルールが決まっていない問題
- 最終責任が必要な判断
という感じ。
何でもAIにやらせるのではなく、得意な場所に、それぞれ置いていく。
こっちの方が現実的だと思いました。
「AI＝会話するもの」ではなくなってきた
ChatGPTが登場してから、私たちが普段見るAIは、「質問すると答えてくれる」「文章を書いてくれる」「画像を作ってくれる」という、人間から見えやすい存在が中心でした。
でもJevは、少し違います。
ユーザーからは見えないところで、問い合わせを分類する。次に進む道を選ぶ。
必要なら人に戻す。表にはほとんど出てこない。
でもシステムの裏側では、ずっと小さな判断をしている。
そんなAIです。
TypeSafeのWorkflow Evalsを見ると、お問い合わせ対応だけでなく、セキュリティインシデントや請求書処理、AIエージェントの実行ログ監視などにも同じ考え方が使われています。
この辺りを眺めていると、「生成AIで何を作るか」という問いそのものが、少し変わってきたような気がします。
Jevを入れると、人間はどこに残るのか
問い合わせ対応にJevを入れると考えたとき、最初は「Jevが判断して、難しそうなら人へ戻す」という形を思い浮かべました。これは、いわゆる「Human in the Loop」と呼ばれる考え方です。
簡単に言えば、「1件の処理を終えるために、人の確認が必要な仕組み」です。
もちろん、これは安全な始め方です。
ただ、問い合わせ対応の流れを細かく分解していくと、少し見え方が変わってきます。
本当に毎回、人が1件ずつ確認する必要があるのでしょうか。
たとえば、
- 問い合わせの種類は何か
- 危険そうな内容か
- どこへ振り分けるべきか
- どれくらい急ぐべきか
といった部分をJevが判断し、その結果を使って普通のプログラムが次の処理を決められるなら、人がすべての問い合わせの途中に入らなくてもよくなります。
大事なのは、「Jevに人間の代わりをさせる」ことではなく、「人が確認する場所を変えること」なのかもしれません。
問い合わせ対応を描き直す
最初に考えていた流れを、「人が毎回確認する形」だけでなく、「人が外から見守る形」まで含めて描き直すと、こんな構成になります。
flowchart TD
classDef input fill:#F3E5F5,stroke:#6A1B9A,stroke-width:3px,color:#4A148C;
classDef jev fill:#FFF3E0,stroke:#EF6C00,stroke-width:3px,color:#E65100;
classDef code fill:#E8F5E9,stroke:#2E7D32,stroke-width:3px,color:#1B5E20;
classDef data fill:#E0F7FA,stroke:#00838F,stroke-width:3px,color:#006064;
classDef human fill:#FCE4EC,stroke:#C2185B,stroke-width:3px,color:#880E4F;
classDef llm fill:#E3F2FD,stroke:#1565C0,stroke-width:3px,color:#0D47A1;
classDef monitor fill:#FFF8E1,stroke:#F9A825,stroke-width:3px,color:#5D4037;
classDef result fill:#ECEFF1,stroke:#546E7A,stroke-width:2px,color:#263238;
A["👤 お問い合わせ"]:::input
--> B["🧠 Jev<br/>問い合わせの意味を判断"]:::jev
B --> C["📋 問い合わせの種類"]:::jev
B --> D["🚨 危険度"]:::jev
B --> E["📊 急ぎ具合"]:::jev
C --> F["💻 普通のプログラム<br/>適用するルール・必要情報・処理先を決める"]:::code
D --> F
E --> F
F --> G["🔎 データベース / 検索 / API<br/>必要な情報を集める"]:::data
G --> H{"💻 普通のプログラム<br/>この処理は人の承認が必須？"}:::code
H -->|"Yes"| I["👤 人が確認<br/>担当者が確認・承認"]:::human
H -->|"No"| J["⚙️ 必要な処理を実行"]:::code
I --> J
J --> K["✍️ LLM<br/>事実と処理結果から返信文を作る"]:::llm
K --> L["💬 ユーザーへ返信"]:::result
B -. "判断結果を記録" .-> M["👀 人が外から見守る<br/>偏り・異常・失敗を確認"]:::monitor
J -. "処理結果・失敗率" .-> M
L -. "苦情・再問い合わせ・品質" .-> M
M -. "異常があれば<br/>ルール変更・停止・介入" .-> Fここで大事なのは、「人に確認してもらうべきか？」をJevに丸ごと決めさせないことです。
「人が必要か」は、いろいろな条件が混ざった大きな判断です。
たとえば、
- 高額な処理か
- 本人確認が終わっているか
- 一度実行すると元に戻しにくい処理か
- 法律や契約に関わるか
- 安全面で問題がないか
- 会社のルール上、人の承認が必須か
といった条件があります。
こういう条件は、普通のプログラム側に明確なルールとして書いておく方が安全です。
Jevは、「この問い合わせは何についてのものか、どれくらい危険そうか、どれくらい急いだ方がよいか」という、文章の意味を読まないと決めにくい部分を担当します。
そして、「その結果を使って、人の確認が必要かどうかは普通のプログラムが決める」という分け方にします。この方が、あとから見ても「なぜ自動で処理されたのか」「なぜ人に回ったのか」を説明しやすくなります。
人の関わり方は3段階で考える
人の関わり方は、次の3つに分けると分かりやすいです。
- 人が毎回確認する
高額な返金、契約、本人確認、安全に関わる処理など。失敗したときの影響が大きいものです。 - 人が外から見守る
通常処理は自動で進め、人は失敗や偏りが増えていないかを確認します。問題があれば自動化を止めたり、ルールを変えたりします。 - 通常処理では人が入らない
よくある質問、配送状況確認、担当部署への振り分けなど、危険が小さくやり直せる処理です。
つまり、「危険の小さい処理は自動化し、仕組み全体は人が見守り、危険の大きい処理だけ人が毎回確認する。」という形です。
ただし、Jevが「かなり自信がありそうな答え」を返しただけで自動化してよいわけではありません。
金額、権限、本人確認、現在の状態など、普通のプログラムで確実に確認できる条件は、Jevではなくプログラム側で確認します。
ロボティクスでも同じ分け方が使えそう
この考え方は、ロボットにもかなり似ています。
ロボットでは、
- 物を掴むか
- 右へ避けるか左へ避けるか
- もう一度試すか
- 目的を達成したか
といった「次に何をするか」の判断が何度も必要になります。
そこで、役割を次のように分けます。
flowchart LR
classDef sensor fill:#E0F7FA,stroke:#00838F,stroke-width:3px,color:#006064;
classDef jev fill:#FFF3E0,stroke:#EF6C00,stroke-width:3px,color:#E65100;
classDef code fill:#E8F5E9,stroke:#2E7D32,stroke-width:3px,color:#1B5E20;
classDef llm fill:#E3F2FD,stroke:#1565C0,stroke-width:3px,color:#0D47A1;
classDef human fill:#FCE4EC,stroke:#C2185B,stroke-width:3px,color:#880E4F;
A["👁️ センサー / 画像認識<br/>周囲の状況を整理"]:::sensor
--> B["🧠 Jev<br/>次に何をするか判断"]:::jev
--> C["🔐 普通のプログラム<br/>安全条件を確認"]:::code
--> D["🤖 制御プログラム<br/>実際に動かす"]:::code
--> A
B -. "複雑な計画が必要" .-> E["🤖 LLM<br/>計画を考え直す"]:::llm
A -. "動作記録・異常" .-> H["👤 人が外から見守る"]:::humanJevに向いていそうなのは、モーターを細かく動かすことではなく、「今、どの行動を選ぶか」という部分です。緊急停止や衝突防止、モーターの細かい制御は、これまで通り普通のプログラムが担当します。
公開されているドローンやロボットアームの実験も、このように「Jevが次の行動を選び、安全や物理制御は普通のプログラムが守る」という構成です。
まだ主にコンピューター上の実験なので、実際のロボットで安全に使えるとまでは言えません。
それでも、小さな判断を何度も繰り返す場所にJevを置くという考え方は、かなり相性が良さそうです。
まとめ｜こういうAIもあるんだ
Jevを知ったとき、最初は私も、「また新しいAIモデルが出たんだ」くらいの感覚でした。
でも、実際に触ってみると、少し違いました。
何でもできるAIを、さらに大きく、さらに賢くする方向だけではなく、「判断する」という仕事に絞ってAIを作るという方向もある。
そして、全部をJevに任せるのではなく、
- ルールで確実に決められることは普通のプログラム
- 文章や状況の意味を読んで決めたいところはJev
- 説明や文章を作るところはLLM
- 本当に人の確認が必要なところは人
と、役割を分けて組み合わせていく。
そう考えると、今まで「ここをAIに全部任せるのは、ちょっと怖いな」と思っていた仕事も、ひとつの巨大なAIへ丸ごと渡すのではなく、小さな判断へ分解して組み立て直せるのかもしれません。
旅の荷物を一度全部広げて、
「これはバックパック」
「これはサドルバッグ」
「これは自分で持っておこう」
と詰め直しているような感じです。
少し複雑にはなります。
でも、それぞれの道具が何を得意としているのか分かると、任せられる範囲も少しずつ広がっていきます。
今回、お問い合わせ対応を考えている途中で、人が毎回確認しなくてもよい仕事や、人は処理そのものではなく外から見守ればよい仕事もありそうだと気づきました。
さらにロボットを見てみると、「文章はいらない。でも、今どう動くかという判断は必要」という場面がたくさんあります。そう考えると、JevのようなAIが入れる場所は、お問い合わせ対応だけではなさそうです。「こういうAIもあるんだ。」そう思うと、やっぱりちょっとワクワクしますね。
さて。
今回はお問い合わせ対応を題材に試してみましたが、身の回りを見渡してみると、「文章はいらない。でも、人間っぽい意味判断は必要」という仕事は、まだ結構ありそうです。
Jevもまだ登場したばかりです。
次はまた別のことにも混ぜながら、どこまで任せられるのか試してみようと思います。
補足
Jevは、何でもできるAIを目指すというより、「判断する」という仕事に絞ったAIとして登場しました。
TypeSafeはJevを、文章を生成するモデルではなく、入力された状況から型の決まった判断結果を返す
「System One Model」として説明しています。
そして、この考え方は問い合わせ対応だけではなさそうです。
公開されているドローンの実験では、Jevにモーター制御そのものを任せるのではなく、「右へ避けるか、上へ抜けるか」といった次の行動選びを担当させ、高速な飛行制御や安全処理は普通のプログラム側に残しています。
ロボットアームの実験でも、Jevは「近づく・掴む・運ぶ・離す」といった大きな行動を選び、関節の細かい制御や動ける範囲の確認は普通のプログラムが担当しています。
コメント