Jev AIデモ：6つのJevモデルデモを徹底解説

Jev AI demosやJev model demosを探すとき、確認すべきことは、Jevがもっともらしい選択をできるかどうかだけではありません。どの状態を受け取り、何を選べて、どの答えを返し、周囲のソフトウェアが実際に何を実行したかを追えるかが重要です。Jevデモ一覧の6つのシナリオは、この確認の流れを中心に設計されています。

内容は、操作ごとに変化するフライトサイト、リンクだけで進む百科事典のレース、買い物かご、サポートチケットの振り分け、買掛金の審査、セキュリティアラートです。サイト、チケット、価格、請求書、インシデントはすべてシミュレーションです。各ページではライブのJev判断が説明され、サインインしてシナリオを開始するとリクエストとレスポンスを確認できます。インターフェースを理解するには役立ちますが、整ったデモだけで同じポリシーが自社データでも良好に働くと証明できるわけではありません。

このガイドでは、各デモで観察する点、判断と実行の境界、デモを小さく測定可能な評価に変える方法を説明します。記述は2026年9月27日に公開ページで確認できた内容に基づきます。特定の実行が成功したという主張ではありません。

目次

• 要点
• 6つのデモに共通する仕組み
• 6つのJevモデルデモの概要
• ブラウザー操作のデモ
• サポート振り分けでは1件に3つの判断
• 請求書審査では結論より先に証拠
• セキュリティアラートでは対応より先に証拠
• デモの実行結果を評価する方法
• シミュレーションから実際の業務へ
• よくある質問

要点

Jevのデモは、ソフトウェアのワークフロー内でモデルが範囲を限定した判断を行う様子を示します。ブラウザーのシナリオでは、承認された操作のたびにページが変化するため、Jevはその時点で利用できる要素から選び直す必要があります。サポート、財務、セキュリティのシナリオでは構造化された証拠を判断し、コードが振り分けや人のレビューに使います。各ページには手動モードと時間間隔を設けた自動モード、判断パネルがあり、実行にはサインインが必要です。次の操作を承認する前にリクエストと回答を読みたい場合は、まず手動モードを選びましょう。

6つのデモに共通する仕組み

共通する流れは観察 → 判断 → 確認 → 実行 → 再び観察です。模擬インターフェースが操作要素や記録を示し、Jevへのリクエストが現在の状態と具体的な質問を伝えます。判断パネルにはリクエスト、レスポンス、その後の操作が表示されます。変化したページが次のステップの入力になります。モデルの回答そのものがボタンをクリックしたり、返金したり、端末を隔離したりするわけではありません。回答を採用するか、どのように適用するかは周囲のアプリケーションが決めます。

この分離が設計上の重要なポイントです。モデルは次の操作要素を選んだり、チケットの深刻度を評価したりできます。一方、権限、しきい値、状態変更を強制するのは通常のコードです。実際の決済、支払い、メッセージ送信、セキュリティ操作を行わないと明記されたデモでは、この境界がとくにはっきりしています。

Jevの質問タイプを見ると、これらの例が単なるチャットの記録ではないことも分かります。

質問タイプ	回答の形	デモでの用途
Choice	事前に定義した候補から1つ選び、確率も返す	現在のページ操作やサポート担当キューを選ぶ
Score	順序のある段階で評価し、分布も返す	チケットの深刻度やアラートのリスクを評価する
Noul	明確な命題が真である確率	人のレビューが必要かを判断する

公式の開発者向けドキュメントによると、1つの状態に対して複数の型付き質問を1回のリクエストで送れます。現在の状態入力はテキスト、JSONオブジェクト、テキスト配列で、画像、音声、動画を直接入力する機能には対応していません。デモでは、アプリケーションがページや記録をモデルに評価できる状態へ変換します。ブラウザー風の画面が見えても、モデルがピクセルを直接見ていることにはなりません。

6つのJevモデルデモの概要

デモ	Jevの課題	観察する点	重要な境界
フライト検索	変化する検索フォームと結果画面で次の操作を選ぶ	現在の操作要素、選択先、更新後の検索状態	便と価格はサンプル
Wikiリンクレース	見えている記事リンクから目的の記事へ進む	候補リンク、ここまでの経路、次の記事	架空の百科事典。検索とURL直打ちは禁止
サポート振り分け	問題の分類、深刻度、人の確認要否を判断	3つの回答と振り分けルール	返金、返信、アカウント変更はしない
買い物かご	厳密な条件に合う商品を探す	商品比較、かごの中身、停止条件	実際の決済はしない
請求書審査	関連記録を調べて処理方針を選ぶ	最終判断前に開いた証拠	架空の財務記録。支払いはしない
セキュリティアラート	証拠を調べ、権限、リスク、対応を判断	証拠の網羅性と対応の条件	模擬インシデント。実端末は変更しない

これは異なる判断の形を示すデモであり、ベンチマークの順位表ではありません。あるブラウザー操作は現在の画面では正しくても、画面が変われば間違いになるかもしれません。分類の出力形式が正しくても、担当キューが間違うことはあります。この2種類の正しさを分けて見ましょう。

ブラウザー操作のデモ

3つのシナリオで、観察、判断、操作のループを具体的に確認できます。それぞれ、範囲が定まった課題と模擬サイトから始まります。モデルは現在のページにある要素やリンクから選び、アプリケーションが課題に書かれた値を提供して、承認済みの操作を実行します。各ステップで、その操作が本当に利用可能だったか、目標に近づいたかを問うのが有効です。

フライト検索は操作のたびにフォームが変わる

フライトのデモには、チューリヒからロンドン、シンガポールから東京などの経路があります。初期課題は、2026年10月20日に大人1人がエコノミークラスでチューリヒからロンドンへ向かう片道便を探すことです。模擬AeroFinderサイトは検索要素から始まり、後に結果を表示できます。デモは「ページを読む」「操作を選ぶ」「確認する」「実行する」という4段階を示します。都市と日付の値は課題から与えられ、Jevが操作と対象を選ぶと説明されています。

正しい入力欄を選ぶことと、その欄の値を創作することは違います。有用な実行記録には、現在の番号付き要素、Jevが選んだ対象、課題由来の値、次の画面状態が含まれるはずです。画面の配置や選択肢が変わったら、決め打ちのクリック順ではなく新しい状態に基づいて次を判断する必要があります。表示される価格は実際の航空運賃ではなく、旅行計画には使えません。

Wikiリンクレースでは近道を使わない

リンクレースは「Rubber duck」から始まり、「Machine learning」への到達を目指します。検索とURLの直入力は禁止です。模擬OpenAtlas記事には現在のページにあるリンクだけが示され、Jevは1ホップずつ選びます。初期ページには「Rubber duck debugging」「Waterfowl」「Toy」などがあり、それぞれ架空の百科事典内で別の経路につながります。

これは局所的な情報だけで進路を決める小さな実験です。各ホップで、選んだリンクが画面に見えていたか、目的地との関連がありそうか、経路が前進したかを確認します。期待できそうな名前でも行き止まりになることがあります。結果はモデルの判断だけでなく、シミュレーションのページ構造にも左右されます。単一の「成功」ラベルより、表示された経路全体が参考になります。

買い物かごでは厳密な一致と停止が必要

買い物デモは、1 Lの全脂乳をちょうど1本、放し飼い卵12個入りを1パック、4ドル未満の600 g全粒粉パンを1個、かごに追加するよう求めます。Jevは模擬ストアで検索し、似た商品を比べてかごを作ります。条件がそろったら止め、決済しないと明記されています。

名前が似た商品を見つけるだけでは足りません。サイズ、種類、数量、価格、重複追加の有無が重要です。実行を確認するときは、各商品をすべての条件と照合し、必要な3商品だけで止まって無許可の決済に進まないことを見ます。価格と在庫はサンプルです。意味があるのは操作履歴と最終的なかごの状態です。

サポート振り分けでは1件に3つの判断

サポート振り分けデモは3件のサンプルチケットを使います。各チケットに対し、Jevは1回のリクエストで3つの判断を返すと説明されています。Choiceで問題の種類、Scoreで深刻度、Noulで人のレビューが必要な確率を判断します。訪問者が回答を確認した後、模擬サポートデスクがコードに定義されたルールで振り分けます。

公開されているルールは具体的です。**深刻度がcritical、人のレビュー確率が50%以上、または問題分類の確信度が55%未満なら人に送ります。**これはデモのポリシーであり、あらゆる業務に通用するしきい値ではありません。最初のチケットは請求の重複が続き、前月の問い合わせにも返答がなかったケースです。残りは本番APIのエラーと、通常のデータ書き出しの質問です。内容の違いを見ると、3つの判断がそれぞれ別の側面を捉えているか、全部を曖昧な1つのラベルにまとめていないかを確認できます。

問題カテゴリ、深刻度の確率分布、人のレビュー確率、コードが実際に選んだ振り分け先を記録してください。結果が意外なら、モデル回答の問題か、それを解釈するルールの問題かを切り分けます。ページには、メッセージ送信、返金、アカウント操作は行わないと明記されています。シミュレーションで変わるのは担当キューです。

請求書審査では結論より先に証拠

請求書審査デモには、記録が一致するケース、支払済みのケース、銀行口座情報が変更されたケースの3種類があります。架空のLedgerFlow画面では、Jevが請求書、発注書、納品記録、取引先情報、支払履歴を確認してから処理方針を選べます。初期の請求書には取引先、発注番号、明細、合計額、伏せ字の支払口座が表示されます。5種類の記録のうち何件を確認したかも見えます。

ここでは証拠をどれだけ調べたかが見える形になります。請求書だけで判断すると、二重払い、または変更された口座を見逃すおそれがあります。どの記録を次に開いたか、そこで何が分かったか、最後の処理方針を全証拠で説明できるかを記録しましょう。3つのケースを比べると、正常に一致する書類、支払済みで重複に注意が必要な書類、口座変更で別の確認経路が必要な書類の違いが分かります。模擬データで実際の支払いは行われません。現実の支払管理が安全だという証拠にはなりません。

セキュリティアラートでは対応より先に証拠

セキュリティデモは、本番環境での見慣れないアクセス、またはステージング環境のデプロイ活動から始まります。アラートと3つの証拠パネルを確認し、権限の有無、リスク、次の対応を1回のリクエストで判断します。対応候補はアラートのクローズ、分析担当者のレビュー、資産の隔離と当番への連絡ですが、いずれも模擬画面内だけです。

見るべき点は、実際に確認した証拠に対応が釣り合っているかです。見慣れない管理者ログインの後に本番サーバーの認証情報ストアへのアクセスを試みた状態と、予定されたステージングへのデプロイ活動は異なります。どの証拠が本当に開かれたか、型付きの回答が何を示すか、どのポリシーが最終対応を許したかを確認します。高いリスクスコアはコードと担当者への信号であり、本番端末を変更する権限ではありません。公開ページは架空の事案で、端末の隔離もアラートの実クローズも行わないと明記しています。

デモの実行結果を評価する方法

最初は手動モードを使いましょう。ページには3秒間隔の自動モードもありますが、手動なら次の操作の前にリクエストを読めます。公開シナリオの開始にはサインインが必要です。各ステップで状態、許された選択肢、Jevの回答、実行された変化の4点を残してください。これらを示さない結果カードでは、誤りの原因が見えにくくなります。

最後に課題を完了したかだけで判断せず、次を確認します。

1. **状態の忠実さ：**必要な情報が含まれ、その時点で未公開だった事実が混入していないか。
2. **操作の妥当性：**選んだ要素、リンク、処理方針は実際に提示された候補か。
3. **条件の達成：**日付、数量、価格上限、禁止された操作を守ったか。
4. **証拠の網羅：**財務やセキュリティの処理方針の前に関連記録を確認したか。
5. **不確実性への対応：**確信度の低さや高いレビュー確率を、書かれたルールどおりに反映したか。
6. **実行の境界：**コードが承認済み操作だけを行い、決済、支払い、返金、実際の隔離を防いだか。
7. **再現性：**似た状態で似た判断となり、違う分岐の理由を監査できるか。

1回の実行は製品ツアーであり、精度の推定ではありません。自社の業務を評価するなら、ラベル付き事例を集め、曖昧なケースや敵対的なケースも入れ、同じ質問定義を使い、人の判断や結果と比較します。Choiceではカテゴリ精度と混同を測ります。Scoreでは隣り合う深刻度の取り違えを調べます。Noulでは確率を区間に分け、予測されたレビュー必要率と実際の必要率を比べます。人に送る割合も測るべきです。見かけ上の高精度は、ほぼすべてを人に回しただけかもしれません。

判断ポリシーはモデルと分離してください。デモの50%しきい値は分かりやすいものの、自社に適切な値は、見逃した重大事案と不要なレビューの費用によって変わります。検証用に取っておいたデータで設定し、トレードオフを記録し、業務や顧客構成が変われば見直します。元データが足りないなら、確率を見る前に「必要な証拠がない場合は人へ」という固定ルールを適用できます。

シミュレーションから実際の業務へ

デモは設計の参考例として扱いましょう。まず、サポートキューの割り当てや文書の確認要否など、範囲の狭い本番判断を1つ選びます。許された回答、状態フィールド、各回答が起こせる操作、不確実な場合の代替経路を書きます。次にJev APIドキュメントを使い、自社の事例で状態と型付き質問を試します。認証情報はサーバーで管理し、レスポンスを検証し、すべての副作用をアプリケーションコードに任せます。

ブラウザーのワークフローでは、検証済みの少数の操作要素だけを先に示します。モデルが任意のセレクターを作ったり、画面にない操作を実行したりしないようにします。財務とセキュリティでは証拠収集と最終処理を分け、ポリシーが必須とする記録を要求します。サポートでは、顧客への連絡やアカウント変更を認める前に、振り分けや優先順位付けから始めます。

最後に、質問バージョン、状態の参照、候補、回答と確率、ポリシーバージョン、承認状況、実行操作を簡潔な監査記録として残します。予想外の結果を説明し、時間とともに起きた変化を比較できます。デモは仕組みの部品を示しますが、本番導入には測定した誤り率、明確なレビュー方針、運用責任者が必要です。

よくある質問

Jev AIデモは無料で見られますか

公開ページには、実行しなくてもシナリオの説明と模擬の初期状態が表示されます。対話型の実行には「Sign in to start」と表示されます。特定のプランや利用枠を前提にする前に、現在のサイトでアクセス条件を確認してください。

実際のサイトを操作したり取引したりしますか

いいえ。公開ページでは、フライトサイト、百科事典、店舗、財務デスク、セキュリティコンソールをシミュレーションと明記しています。実際の決済、支払い、端末隔離、顧客への送信はありません。示すのは判断とアプリケーションが制御する状態変化です。

これらのデモでJevはスクリーンショットを読みますか

現在のJev開発者向けドキュメントでは、状態入力はテキスト、JSONオブジェクト、テキスト配列で、画像入力はまだ対応していません。アプリケーションは訪問者に視覚的なページを見せながら、Jevには現在の要素や記録のテキストまたは構造化表現を渡せます。

最初に試すべきJevモデルデモはどれですか

Choice、Score、Noulを1回のリクエストで理解するならサポート振り分けです。変化するページで繰り返し操作を選ぶ様子を見るならフライト検索です。処理方針を勧める前の証拠収集が重要なら請求書審査が向いています。

自社の用途に合うと判断するための証拠は何ですか

自社業務の未使用テスト事例、明確な人の正解ラベル、文書化したポリシー、誤り率、確率の校正、レビュー件数、失敗または阻止された操作の測定が必要です。デモの履歴は仕組みを理解する助けになり、自社評価が運用要件との適合性を確かめます。

出典について：シナリオの内容は2026年9月27日に公開されていたJev AIデモページと開発者向けドキュメントで確認しました。モデルのインターフェースはTypeSafe AIの公式クイックスタートとも照合しています。Jev AIは独立運営であり、TypeSafeとの提携、TypeSafeによる運営や推奨はないと明記しています。いずれかのサービスを組み込む前に、それぞれの認証情報、エンドポイント、条件を確認してください。