「TypeSafe AI」や「System One」スタイルのモデルとして紹介されることもあるJevについて、GrokやGeminiのようなチャットモデルと同じ方法でGlarityに接続できるのか気になった方もいるかもしれません。結論は「できません」です。Jevは対話型LLMの代替として使えるように作られていません。ここでは、Jevが実際に何であるか、そしてその違いがなぜ重要なのかを説明します。
Jevが実際に行うこと
Jevは汎用チャットモデルではなく、型付き判断エンジンです。自由形式のプロンプトを受け取って自由形式のテキストを返すのではなく、構造化された状態(state)(状況を記述したテキスト)と質問(question)を受け取り、文章の段落ではなく決定・スコア・確率といった型付き出力を返します。状態と質問を合わせて32Kトークンが上限で、やり取り全体では64Kトークンの予算があります。チャットモデルが維持するような複数ターンの会話履歴はなく、各呼び出しは情報のスナップショットに対する自己完結した判断です。
違いをこう考えてみてください。チャットモデルは「ここに何を書くべきか?」に答えます。Jevは「この正確な状況において、決定は何か?」に答え、テキストを解析する必要のある文章ではなく、コードが直接利用できる値(スコア、真偽値、順位付けされた選択肢)で答えます。
Glarityの「カスタムモデル」設定に合わない理由
Glarityの設定 → 一般 → AI接続パネルは、システム/ユーザーメッセージの配列を受け取ってチャット完了を返す、OpenAI互換の/chat/completionsエンドポイントという1つの形式を前提に構築されています。Glarityがカスタムモデルでサポートするすべてのモデル——APIキーで接続する第三者のモデルを含む——はこのプロトコルを使用します。
Jevはそうではありません。チャット完了APIではなく、型付き判断APIです。Glarityの翻訳・要約・メール返信機能をマッピングできる「システムプロンプト」や「会話」という概念がありません。これらの機能は、ページや動画のコンテンツをチャットメッセージとして送信し、テキストの応答を受け取ることで動作します——これはJevの入出力の仕組みが生成する形ではありません。有効な認証情報があっても、Glarityのリクエスト形式をJevが期待する形式に一致させる方法はありません。
Jevを検討している場合の意味
自動モデレーション判断、リスクスコアリング、構造化トリアージといった実際のユースケースでJevを検討しているなら、ブラウザ拡張機能のチャットバックエンドとしてではなく、自分が管理するパイプラインの意思決定支援コンポーネントとして、独自の基準で評価する価値があります。本当に必要だったのがGlarityの日常的な翻訳・要約を動かす高速で手頃なモデルであれば、Glarityの「カスタムモデル」設定を通じて接続する標準的なチャット完了モデル(Grok、Gemini 3.8 Flashなど)がその目的に合った選択肢です。
よくある質問
Glarityのページ要約や翻訳にJevを使えますか?いいえ。Jevはこれらの機能が必要とする自由形式のテキストではなく、型付き判断(スコア、真偽値、確率)を返し、Glarityが呼び出せるチャット完了エンドポイントを公開していません。
JevはLLMと同じ種類のものですか?似た基盤技術の上に構築されていますが、公開方法が異なります——自由な文章生成ではなく、判断のための狭く構造化された入出力です。
トークン制限はどれくらいですか?状態と質問を合わせて32Kトークンが上限で、やり取り全体で64Kトークンの予算があります。
Glarityでは代わりに何を使うべきですか? OpenAI互換のチャットモデルであれば何でも構いません——GrokやGemini 3.8 Flashなどのモデルを「カスタムモデル」設定で接続する方法は、Glarityの既存ガイドを参照してください。
Glarity 編集部が、AI 検索・動画要約・ブラウザ活用の最新情報をお届けします。
