Jevの使い方・始め方｜申し込みからAPIキーまで【2026年9月】

Jevについて調べ始めた人が最初にぶつかるのは、「結局どこから申し込めばいいのか」「何をダウンロードするのか」という、いちばん手前の部分です。公式サイトは研究の話から始まり、公式ドキュメントはいきなりAPIの呼び方から入るので、その間が抜けて見えます。

先に答えを書きます。申し込み窓口はコンソールのログイン画面ひとつ、ダウンロードするものは基本的にありません。鍵を1本作れば、あとはブラウザの画面からでも、cURLからでも、PythonやJavaScriptのSDKからでも、同じAPIを呼ぶだけです。

この記事は、その手前から順番に並べ直したものです。Jevというモデルそのものの仕組み・料金の細かい内訳・LLMとの違いは Jevとは｜TypeSafe AIの料金・仕様・使い方 に書いてあるので、そちらに任せます。ここでは「今日どこまで進められるか」だけを扱います。書いてあることはすべて、2026年9月21日に公式ブログ・公式ドキュメント・公式コンソールを開いて確認した範囲です。確認できなかったことは、確認できていないとそのまま書きます。

Jevを始める3段階｜申し込み・APIキー・最初の1問

公式ドキュメントのクイックスタートを分解すると、やることは3つしかありません。順番も決まっています。

1. コンソールに登録する（console.typesafe.ai）。ここがJevの唯一の入口です。
2. APIキーを作る。公式ドキュメントは「ダッシュボードからAPIキーを取得する」と書き、エージェント向けのページでは鍵の作成先として console.typesafe.ai/keys を示しています。
3. 最初の1問を送る。ブラウザのPlayground、cURL、公式SDKのどれからでも構いません。返ってくるのは文章ではなく、型の決まった値です。

逆に言うと、この3つの外側に手順はありません。インストーラを探したり、ライセンスファイルを受け取ったり、管理コンソールでテナントを作ったりする工程は、2026年9月21日時点の公式ドキュメントには出てきません。ここを押さえておくと、以降の迷いはかなり減ります。

早期提供の申し込み｜どこから登録して何を入力するか

Jevは2026年9月15日に公開されました。公式ブログの締めくくりに、こう書かれています。「本日、早期提供を開始し、待機リストの開発者をできるだけ早く受け入れていく」。つまり現在の提供形態は一般提供ではなく、早期提供です。

入口はコンソールのログイン画面だけ

公式ドキュメントのクイックスタートは、申し込みについて独立した節を設けていません。「Playgroundを開いてログインする」「ダッシュボードからAPIキーを取得する」と書いてあるだけです。エージェント向けのページからも、鍵の作成先としてコンソールのURLが直接リンクされています。

コンソールの公開されているログイン画面（2026年9月21日に取得）には、Googleアカウントで続ける方法と、メールアドレスを入力して確認コードを受け取る方法が並んでいます。続ける前提として、利用規約とプライバシーポリシーへの同意が明記されています。会社名・用途・想定利用量といった項目をここで入力させる作りにはなっていません。

登録後にどうなるかは公式に書かれていない

ここは正直に書きます。登録したその場で鍵が発行されるのか、待機リストに入って順番待ちになるのか、待ち時間の目安はどれくらいか。この3点は、2026年9月21日時点で公式に確認できていません。公式ブログが「待機リストから順次受け入れている」と書いていること、公式ドキュメントが待機の手順をまったく書いていないこと、この2つの事実だけが確認できる状態です。

社内で稟議を回すなら、ここは「登録してみないと分からない」と正直に書いたほうが早いです。逆に言えば、稟議の前に誰か1人がメールアドレスで登録してみるのが、いちばん確実な調べ方になります。

問い合わせ先は用途で分かれている

法人として導入を検討していて、既定のレート制限で足りるか分からない場合は、最初からセールス窓口に当たったほうが話が早い可能性があります。公式ドキュメントは「より高い制限はカスタムプランとエンタープライズプランで提供する」と明記しています。

APIキーの発行と置き場所｜先に決めておくこと

鍵を作るのは一瞬ですが、置き場所を決めずに作ると後でやり直しになります。先に決めておくべきことを並べます。

鍵はどう使われるか

JevのAPIは、HTTPヘッダーに鍵を載せる形式です。公式ドキュメントのAPIリファレンスに書かれているのは、次の3行だけです。

POST https://api.typesafe.ai/v1/systemone
Authorization: Bearer <API_KEY>
Content-Type: application/json

公式SDKを使う場合、鍵はコードに書きません。PythonのSDKもJavaScriptのSDKも、環境変数 TYPESAFE_API_KEY を読みにいく作りになっていて、クライアントを何も指定せずに生成すると、その値が使われます。

鍵が生きているかを確かめる1行

鍵を作ったら、いきなり判定を投げる前にモデル一覧を取ってみるのが安全です。公式ドキュメントのModelsページに載っている例です。

curl https://api.typesafe.ai/v1/models \
  -H "Authorization: Bearer $TYPESAFE_API_KEY"

ここが通れば、鍵と通信経路の両方が生きています。返ってくるのはモデル名・説明・リリース日の一覧で、公式ドキュメントによれば現在は別名（エイリアス）が並びます。鍵が間違っていれば 401 Unauthorized が返るので、切り分けもここで済みます。

置き場所は個人ではなく組織で決める

ここは製品を問わず同じ話ですが、最初の1本で癖が決まるので先に書いておきます。鍵をソースコードに直接書く、チャットに貼って共有する、個人のノートPCの設定ファイルだけに置く。この3つをやると、あとから回収できなくなります。macOSであればKeychainに預ける方法があり、その考え方は macOS KeychainでAPIキー管理 にまとめています。

APIキーを扱うこと自体が初めてなら、先に ChatGPT APIとは？料金・できること・始め方 を読んでおくと、鍵・エンドポイント・従量課金という3点セットの感覚がつかめます。Jevでも構造は同じです。

最初の1回｜Playground・cURL・SDKの3つの入口

公式ドキュメントは、最初の1回の試し方を3通り示しています。どれから入っても同じAPIにたどり着きます。ここから先はすべて公式ドキュメントに載っている例そのままです。

入口1：ブラウザのPlayground

公式のクイックスタートは、まずPlayground（console.typesafe.ai/playground）を開いてログインし、判定させたい文章を「state」として貼り付け、質問を1つ足す、という順番を案内しています。公式が例として挙げているstateは、次の文です。

Hi, I've been trying to connect my Stripe account for 3 days and the integration keeps failing. I'm losing sales. Please help ASAP.

これに対して足す最初の質問が、公式の例では「この文面は緊急性を示しているか」というNoul（はい／いいえの確率を返す型）です。

{
  "urgency": {
    "type": "noul",
    "instructions": "Does this message express urgency?"
  }
}

公式はこのあと「NoulとChoiceとScoreを1回の呼び出しに混ぜて、結果をまとめて見る」ことを勧めています。鍵をどこにも書かずに質問の形だけ確かめられるので、非エンジニアが最初に触るならここからが無難です。

入口2：cURLで直接叩く

公式のクイックスタートに載っているcURLの例です。

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d @- <<'EOF'
  {
    "state": "Hi, I've been trying to connect my Stripe account for 3 days and the integration keeps failing. I'm losing sales. Please help ASAP.",
    "model": "jev-latest",
    "questions": {
      "urgency": {
        "type": "noul",
        "instructions": "Does this message express urgency?"
      }
    }
  }
EOF

3つの型を1回で混ぜた例も、同じページに載っています。Choice（選択肢から1つ選ぶ）・Score（順序のある段階で採点する）・Noulが同居した、公式のリクエストボディです。

{
  "state": "Hi, I've been trying to connect my Stripe account for 3 days and the integration keeps failing. I'm losing sales. Please help ASAP.",
  "model": "jev-latest",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this",
      "criteria": {
        "billing": "Payment or subscription issues",
        "technical": "Bugs or integration problems",
        "sales": "Pricing or account questions"
      }
    },
    "frustration": {
      "type": "score",
      "instructions": "How frustrated the customer appears",
      "criteria": [
        "Calm, just stating facts",
        "Frustrated but civil",
        "Very angry, strong language"
      ]
    },
    "is_urgent": {
      "type": "noul",
      "instructions": "The message conveys urgency or time-sensitivity"
    }
  }
}

公式が併記しているレスポンスでは、department に choice・confidence・probabilities が、frustration に score・confidence・legend・probabilities が、is_urgent に noul が入って返ります。加えて usage に入力トークン数と出力トークン数が付きます。この usage が、後で費用を見積もるときの唯一の手がかりになります。

入口3：公式SDKで書く

PythonのSDKはPython 3.10以上、JavaScriptのSDKはNode.js 20以上が条件と公式に書かれています。インストールは1行です。

pip install typesafe-sdk

npm install @typesafe-ai/sdk

公式のクイックスタートに載っているPythonの例です。環境変数から鍵を読み、既定で jev-latest を呼びます。

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()
ticket = "Hi, I've been trying to connect my Stripe account for 3 days and the integration keeps failing. I'm losing sales. Please help ASAP."

response = client.system_one(
    state=ticket,
    questions={
        "department": Choice(
            instructions="Which team should handle this",
            criteria={
                "billing": "Payment or subscription issues",
                "technical": "Bugs or integration problems",
                "sales": "Pricing or account questions",
            },
        ),
        "frustration": Score(
            instructions="How frustrated the customer appears",
            criteria=[
                "Calm, just stating facts",
                "Frustrated but civil",
                "Very angry, strong language",
            ],
        ),
        "is_urgent": Noul(
            instructions="The message conveys urgency or time-sensitivity",
        ),
    },
)

print(response.answers["department"].choice)
print(response.answers["frustration"].score)
print(response.answers["is_urgent"].noul)

JavaScriptのSDKページに載っている例も同じ構造です。

import { choice, TypeSafeClient } from "@typesafe-ai/sdk";

const client = new TypeSafeClient();
const response = await client.systemOne({
  state: { document: "I was charged twice. Please fix this ASAP." },
  questions: {
    category: choice("What is this ticket about?", {
      billing: null,
      technical: null,
      other: null,
    }),
  },
});

console.log(response.answers.category.choice);

公式ドキュメントによれば、SDKには既定の再試行ポリシーが入っていて、レート制限にあたったときの待ち時間の扱いも面倒を見てくれます。HTTPを直接叩く場合は、この部分を自分で書くことになります。

コーディングエージェントから使う

公式は、Claude CodeやCodexなどのエージェントに読ませるためのskillも配布しています。Claude Codeなら2コマンドです。

claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai

他のエージェントでは npx skills add typesafe-ai/skills --skill typesafe-ai が案内されています。公式は「インストール方法は1つだけ選ぶ」「エージェントは質問文を書くのが得意ではないので、質問としきい値は1か所にまとめて人が一緒に直す」と注意を添えています。

料金と無料の範囲｜公式が明記していることと、していないこと

ここは分けて書きます。混ぜると事故のもとです。

公式が明記していること

レート制限については、公式ドキュメントに注意書きが付いています。需要が非常に大きく、GPUの調達と利用者の受け入れが進む間は予告なく変わりうるという内容です。安定した制限が必要なら、カスタムプランかエンタープライズプランの相談になると明記されています。

公式が明記していないこと

無料枠、試用クレジット、クレジットカード登録の要否。この3つは、2026年9月21日時点で公式に確認できていません。公式サイトに料金だけをまとめた独立ページはなく、料金の記載は公式ドキュメントのModelsページにあります。そこにも無料枠の記述はありません。

「無料でどこまで試せるか」を調べに来た人への現時点での答えは、次の3行になります。

• Playgroundはログインすれば開ける。ただしPlaygroundでの利用が課金対象かどうかは公式に書かれていない。
• 出力トークンは無料と明記されている。課金されるのは入力トークンだけ。
• 入力単価が100万トークンあたり0.042ドルなので、試す規模での金額は非常に小さい。

費用の見積もり方（試算例）

以下は実測値ではなく、公式が示した数字から計算した試算です。前提と式を書いておきます。

公式クイックスタートのレスポンス例には、3問を1回で投げたときの入力トークン数として 392 という値が載っています。単価は100万トークンあたり0.042ドル。したがって、この規模の1件あたりは次のようになります。

392 トークン ÷ 1,000,000 × 0.042 ドル ≒ 0.0000165 ドル / 件

実際の業務データはこの例よりずっと長くなるので、自社の1件あたりのトークン数を usage.input_tokens で測って置き換えてください。重要なのは金額そのものではなく、質問を増やしても入力トークンは増えないという構造です。公式ドキュメントは「stateを1度取り込んで、すべての質問を並列に評価する」と説明しており、64kの予算はstateと全質問の合計で数えられます。1回の呼び出しに質問を詰め込むほど、1問あたりの単価は下がる計算になります。

ダウンロードやローカル実行を探している人への答え

検索で「jev ダウンロード」にたどり着いた人向けに、はっきり書きます。

Jev本体をダウンロードして手元で動かす方法は、2026年9月21日時点の公式ドキュメントには書かれていません。 Jevは api.typesafe.ai のエンドポイントを呼ぶAPIとして提供されていて、モデルの配布・自己ホスト・オンプレミス提供に触れた記述はありません。デスクトップアプリやスマートフォンアプリの案内もありません。

では何を「落とす」のか。公式が配布しているのは次の3つです。

どれもJevそのものではなく、Jevを呼ぶための道具です。判定は提供元の側で動きます。ここを取り違えると、「社内サーバーに入れて閉じた環境で動かす」前提で検討が進んでしまい、あとで全部やり直しになります。

データの扱いを気にして「ローカル」を探している場合は、置き場所ではなく契約の側で確認する話になります。公式ドキュメントは、顧客のリクエストとレスポンスをモデルの学習に使わないこと、ゼロデータ保持（ZDR）をエンタープライズ向けに提供していることを明記し、データ処理契約・マスターカスタマーアグリーメント・プライバシーポリシーの3つを公開しています。社内規程との突合は、その3文書を読むところからになります。

社内の1業務に当てる手順｜質問の型から人の確認まで

鍵が通ったら、次は自社の業務です。いきなりコードを書き始めるより、この5段を順番に埋めたほうが早く終わります。

1. 業務を一つ選ぶ。いま人かLLMが「分ける・点ける・通す」をやっている作業を1つだけ。問い合わせの一次振り分け、書類の不備チェック、申請の一次判定あたりが当てはまります。業務そのものの組み立て方は 問い合わせAI 完全ガイド｜中小企業のCS自動化5パターン が参考になります。
2. 質問の型を決める。分類ならChoice、程度ならScore、はい／いいえならNoul。公式ドキュメントはChoiceの選択肢を最大255個、Scoreの段階を2つ以上10個までと定めています。
3. 選択肢を書き出す。ここがいちばん時間のかかる工程です。書き方の型は次の節にまとめます。
4. しきい値を置く。ChoiceとScoreの答えには confidence が0から1で付きます（Noulには付きません）。公式は高・中・低の3帯に分ける出発点を示し、コード例では0.5を下回ったら人へ、金銭が動く操作は0.9を超えないと自動実行しない、という置き方を挙げています。
5. 人の確認を残す。低い確信度で返ってきたものが、誰の画面にどう積まれるのか。ここを決めないまま本番に入れると、自動化したはずの仕事が「気づかれない滞留」に変わります。

質問文の書き方6つの型

公式ドキュメントは、Jev 1.13が苦手とする9つの失敗モードを公開しています（最終確認日2026年9月17日）。その裏返しが、そのまま質問文の書き方になります。以下はすべて、公式のスキーマに自社の業務を当てはめたものです。日本語のまま使う前に、次の節の注意点も読んでください。

型1：そのまま読める一文にする。公式は「Jevは、書かれた質問に答えるのであって、意図した質問には答えない」と書いています。条件は省略せず、そのまま書きます。

{
  "type": "noul",
  "instructions": "この見積書には、有効期限の日付が本文中に書かれている",
  "criteria": {
    "true": "年月日が特定できる形で書かれている",
    "false": "書かれていない、または「発行から一定期間」のように日付が特定できない"
  }
}

型2：「どれでもない」を必ず置く。Choiceは選択肢の中から必ず1つを選びます。当てはまるものがない入力を受けたとき、逃げ場がないと無理に1つへ寄せます。

{
  "type": "choice",
  "instructions": "この社内問い合わせを最初に受けるべき窓口はどこか",
  "criteria": {
    "joho_system": "端末・アカウント・社内システムの不具合や設定",
    "somu": "備品・入退館・郵送・施設に関すること",
    "jinji": "勤怠・給与・休暇制度に関すること",
    "gaitou_nashi": "上のどれにも当てはまらない、または内容が読み取れない"
  }
}

型3：段階は「次にやること」で書く。Scoreの段階を「低い・普通・高い」と書くと、境目が人によって動きます。段階そのものを行動で定義すると、読み手の解釈が揃います。

{
  "type": "score",
  "instructions": "この議事録の項目について、会議後にとるべき対応はどれに近いか",
  "criteria": [
    "記録として残すだけでよい",
    "担当者が確認して、必要なら動く",
    "期日を決めて必ず着手する"
  ]
}

型4：判断材料は名前で指す。公式は、長い質問を構造化して、データを別のフィールドに置き、バッククォートで名前を参照する書き方を示しています。何と何を突き合わせるのかが曖昧なときは、この形が効きます。

{
  "type": "noul",
  "instructions": {
    "boshu_youken": {
      "hissu_keiken": "法人営業の経験3年以上",
      "hissu_shikaku": "普通自動車第一種運転免許"
    },
    "question": "`boshu_youken` の必須条件を、この応募書類はすべて満たしている"
  }
}

型5：1問に1判断まで割る。公式は「複数の要素を weigh する質問は分解し、コード側で組み合わせる」と繰り返し書いています。契約書チェックのような大きな判断は、3問に割ったほうが安定します。

{
  "kigen_jido_koushin": {
    "type": "noul",
    "instructions": "この契約書には、期間満了時に自動で更新される条項がある"
  },
  "kaiyaku_yokoku": {
    "type": "choice",
    "instructions": "解約の予告期間はどれか",
    "criteria": {
      "ikkagetsu_inai": "1か月以内",
      "sankagetsu_inai": "1か月超3か月以内",
      "sankagetsu_chou": "3か月超",
      "kisai_nashi": "記載が見つからない"
    }
  },
  "sonngai_baishou_jougen": {
    "type": "noul",
    "instructions": "この契約書には、損害賠償額の上限を定めた条項がある"
  }
}

型6：境界事例をcriteriaに書く。間違った答えを見て「本当はこういう意味で聞いたのに」と説明したくなったら、その説明文が足りていない半分だ、と公式は書いています。説明したくなった内容を、そのままcriteriaに足します。

{
  "type": "choice",
  "instructions": "この経費申請は、社内規程に照らしてどの扱いになるか",
  "criteria": {
    "sonomama_shounin": "規程の範囲内で、金額も用途も明確",
    "kakunin_hitsuyou": "規程の範囲内だが、同席者や目的の記載が不足している",
    "taishougai": "規程が対象外としている費目にあたる",
    "handan_fuka": "領収書の記載が読み取れず、判断に必要な情報が足りない"
  }
}

日本語で書くときの注意

公式ドキュメントは、Jevの主要な学習言語は英語であり、CJK（中国語・日本語・韓国語）を含む他の言語も受け付けるが精度は現時点で同等ではない、と2か所で明記しています。そのうえで「非英語の作業でJevに頼る前に、自分のデータで試すこと」「振り分けでは確信度によく注意すること」と書いています。

実務上の扱い方としては、日本語で書いて試す→同じ入力で確信度の分布を見る→低く出る質問だけ英語で書き直して比べる、の順が現実的です。公式が英語の例しか載せていない以上、日本語での精度は自社で確かめるしかありません。

管理者が先に決めること｜権限・データ・社内規程

試すだけなら1人で足りますが、本番に載せる前に情報システム側で決めておくことが3つあります。

鍵を誰が持つか

鍵は個人ではなく組織で持ちます。誰が発行し、どこに保管し、退職・異動のときに誰が失効させるのか。公式ドキュメントには鍵のローテーション手順や組織管理機能に関する記述が見当たらないため、この運用は自社側で設計する前提になります。2026年9月21日時点で、公式に確認できていない領域です。

何を渡してよいか

Jevに渡すstateには、判断に必要な材料をそのまま入れます。つまり、顧客の文面や社内書類がそのまま外部のAPIに出ていきます。公式は顧客のリクエストとレスポンスをモデルの学習に使わないと明記し、データ処理契約とプライバシーポリシーを公開していますが、社内規程との突合はそれとは別の作業です。

実務的には、個人を特定する項目を外してから渡す設計にしておくと、後の説明が楽になります。公式ドキュメントも、精度の観点から「質問に必要なフィールドだけを送る」ことを繰り返し勧めています。余計な情報を削ることが、規程上も精度上も同じ方向を向いているのは、この製品の使いやすいところです。

いつ見直すか

見落としやすいのがここです。jev-latest は別名であって、新しい版が出れば指す先が動きます。公式は「別名は新しいリリースで移動するので、答えが自社の変更なしに変わりうる」「確信度のしきい値を特定の版に合わせて調整しているなら、その版のIDを固定して、移行は自分たちの都合で行う」と書いています。

レスポンスには、実際に回答したモデルのIDが入ります。これをログに残しておけば、答えが変わったときに版の変更が原因かどうかを後から確かめられます。運用ルールとしては、「版を固定する」「レスポンスのモデルIDを記録する」「版を上げるときは同じ入力で比べ直す」の3つを決めておけば足ります。

【要注意】始め方でつまずく4つ

つまずき1：別名のまま本番に固定する

❌ "model": "jev-latest" のまま本番に載せ、しきい値だけ丁寧に調整する。
⭕ 試す段階は別名で構いませんが、確信度のしきい値を詰めたら版付きのID（jev-1.13.0）を指定に切り替える。

なぜ重要か：公式が明示している注意点です。別名は新しい版が出ると指す先が動くので、自社のコードを1行も変えていないのに答えの分布が変わりえます。しきい値は分布に合わせて決めたものなので、分布が動けば意味も変わります。

つまずき2：鍵をコードに書いて先へ進む

❌ とりあえず動かしたいので、鍵を直接コードに書いてコミットする。
⭕ 最初から環境変数 TYPESAFE_API_KEY に入れる。公式SDKはこの名前を既定で読むので、遠回りにはなりません。

なぜ重要か：あとで直すのが最も面倒な種類の借金だからです。公式SDKが環境変数を既定にしている以上、正しいやり方のほうが手数も少なくなります。

つまずき3：Playgroundで通った量のまま本番に流す

❌ 画面で数件試して問題なかったので、そのまま既存のバッチ処理に組み込んで一気に回す。
⭕ 429 Too Many Requests が返る前提で組む。公式SDKの既定の再試行ポリシーを使うか、HTTPを直接叩くなら指数バックオフを自分で書く。

なぜ重要か：公式ドキュメントが、レート制限は需要に応じて予告なく変わりうると明記しているためです。今日通った量が来週も通る保証はありません。529 Overloaded も同じ扱いで、少し待ってから再試行するよう案内されています。

つまずき4：計算や日付の判定まで任せてしまう

❌ 「この請求書の金額は前回より10%以上増えているか」「この契約はまだ有効期限内か」をそのまま質問にする。
⭕ 日付や金額は抽出だけをJevに任せ、比較と計算はコード側に残す。

なぜ重要か：公式が失敗モードとして明示しています。Jevは電卓ではなく、日付を順序のある量ではなく文字として読むため、前後関係や期間内かどうかの判定は信頼できない、と書かれています。数を数えることも苦手で、対象が大きくなるほど誤差が増えるとされています。判断は任せて、算術は残す。この線引きが、最初の1本の成否を分けます。

Uravationならこう判断する｜試す順番と決めること

法人の検討として現実的な進め方を書きます。稟議を先に通そうとすると、答えのない質問（無料枠は？待ち時間は？）で止まるので、順番を逆にするのが早いです。

はじめに：手を動かす人を1人決めて、鍵を1本作る。 対象業務も1つだけに絞ります。この段階では費用の議論をしません。入力トークンだけの従量課金で、試す規模の金額は無視できる水準です。Playgroundで質問文を3回書き直すところまでが、最初の区切りになります。

次に：いまのやり方と並べる。 同じ入力データを、現行の方法（人の目視でもLLMでも）とJevの両方に通して、答え・確信度・所要時間を並べた表を作ります。ここで初めて、自社にとって意味のある比較ができます。他社の測定値を持ってきても、自社のデータで同じ結果が出るとは限りません。

最後に決めるのは3つだけ。 しきい値をいくつにするか、下回ったものを誰が見るか、版が変わったときに誰が試し直すか。この3つが決まっていれば、本番に載せる判断はそのあとで構いません。決まっていなければ、どれだけ精度が良くても載せてはいけません。

そして、文章を書く仕事はLLMに残します。Jevは判断だけを返すモデルで、公式自身が「テキスト生成には訓練されていない。本当に文章が必要なら他のモデルを使え」と書いています。返信文の作成まで移そうとした時点で、設計を間違えています。

よくある質問

Jevの読み方は何ですか？

公式ブログは、経済学者のウィリアム・スタンレー・ジェヴォンズ（William Stanley Jevons）にちなんで名付けたと説明しています。石炭の消費が蒸気機関の効率向上で増えたのと同じ道を機械知能もたどるだろう、という趣旨です。ただし日本語でどう読ませたいかは公式が示していないため、正式なカタカナ表記は2026年9月21日時点で公式に確認できていません。

Jevはダウンロードして使えますか？

いいえ。2026年9月21日時点の公式ドキュメントに、モデルの配布・自己ホスト・オンプレミス提供の記載はありません。Jevは https://api.typesafe.ai/v1/systemone を呼ぶAPIとして提供されています。ダウンロードするものがあるとすれば、公式のPython SDK（typesafe-sdk）、JavaScript SDK（@typesafe-ai/sdk）、コーディングエージェント用のskillの3つで、いずれもJev本体ではなくJevを呼ぶための道具です。

無料で試せますか？

無料枠・試用クレジット・クレジットカード登録の要否は、2026年9月21日時点で公式に確認できていません。公式が明記しているのは、課金対象が入力トークンだけで出力トークンは無料であること、入力単価が100万トークンあたり0.042ドルであること、Playgroundはログインして使うこと、の3点です。金額そのものは非常に小さいため、実務上の障壁は費用よりも早期提供の順番待ちのほうにあります。

日本語の文面を判定させるとき、何に気をつければいいですか？

公式ドキュメントは、主要な学習言語が英語で、日本語を含むCJK言語は受け付けるものの現時点で精度は同等ではないと明記しています。そのうえで、自分のデータで試すことと、振り分けの際に確信度をよく見ることを勧めています。実務では、質問文を短く具体的に書く、選択肢に「どれにも当てはまらない」を置く、確信度が低いものは人に回す、の3つを最初から入れておくのが無難です。同じ質問を英語で書き直して確信度を比べると、言語の影響を切り分けられます。

社内で試すとき、最初に用意するものは何ですか？

3つで足ります。APIキー1本、対象業務1つ、そして「正解が分かっている過去データ」をいくつか。3つ目が抜けると、返ってきた答えが良いのか悪いのかを判断できません。過去に人が処理した案件をそのまま入力にして、当時の判断と突き合わせるのがいちばん手早い確かめ方です。

Claude CodeなどのAIエージェントから使えますか？

使えます。公式がエージェント向けのskillを配布していて、Claude Codeなら claude plugin marketplace add typesafe-ai/skills と claude plugin install typesafe@typesafe-ai の2コマンド、他のエージェントなら npx skills add typesafe-ai/skills --skill typesafe-ai で導入できると案内されています。公式は、エージェントは質問文を書くのが得意ではないので人が一緒に直すこと、質問としきい値は1つのファイルにまとめてレビューしやすくすることを注意点として挙げています。

まとめ

Jevを試すまでの道のりは、思っているより短いです。コンソールに登録し、鍵を1本作り、質問を1つ送る。公式ドキュメントが案内している手順はそれだけで、その外側にインストール作業も申込書もありません。

一方で、公式が書いていないことも同じくらいはっきりしています。無料枠の有無、登録してから使えるようになるまでの時間、鍵の組織管理の仕組み。この3つは2026年9月21日時点で確認できていないので、社内で説明するときは「確認できていない」とそのまま伝えるのが正しい扱いです。分からないことを分からないまま持ち込めるのが、早期提供の製品を検討するときの最低条件になります。

最後に、最初の1本を選ぶときの基準をもう一度。判断は任せて、計算と日付はコードに残す。文章が必要な仕事はLLMに残す。そして、確信度が低かったものを誰が見るかを、本番に載せる前に決めておく。この3つだけ守れば、最初の1本で大きく外すことはありません。

執筆者

佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。
100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』『Claude仕事術』（SBクリエイティブ・シリーズ累計約6万部）。
SBクリエイティブ「ビジネス+IT」ほかで生成AI連載を執筆（NewsPicks最大1,125ピックス）。

次の一歩

1. 今日：コンソールにメールアドレスで登録してみる。登録後に鍵がすぐ出るのか、待機になるのかは公式に書かれていないので、実際に確かめるのがいちばん早い調べ方です。
2. 今週中：いま人かLLMが判定している業務を1つ選び、選択肢を紙に書き出す。「どれにも当てはまらない」を必ず入れてください。
3. 今月中：過去に処理済みの案件をそのまま入力にして、当時の判断と並べる。しきい値と人の確認の手順を、そのうえで決めます。

ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。

参考・出典

• Introducing System One Models & Jev — TypeSafe AI 公式ブログ（2026年9月15日・参照日 2026-09-21）
• Quick start — TypeSafe AI 公式ドキュメント（参照日 2026-09-21）
• Models — TypeSafe AI 公式ドキュメント（料金・レート制限・コンテキスト長・言語対応の出典／参照日 2026-09-21）
• API reference — TypeSafe AI 公式ドキュメント（エンドポイント・選択肢と段階の上限・エラーコードの出典／参照日 2026-09-21）
• Confidence — TypeSafe AI 公式ドキュメント（確信度としきい値の出典／参照日 2026-09-21）
• Jev 1.13 jaggedness — TypeSafe AI 公式ドキュメント（失敗モードの出典・最終確認2026年9月17日／参照日 2026-09-21）
• State — TypeSafe AI 公式ドキュメント（入力形式と言語の注意の出典／参照日 2026-09-21）
• Agent skill — TypeSafe AI 公式ドキュメント（エージェント用skillの出典／参照日 2026-09-21）
• TypeSafe Python SDK / JavaScript SDK — TypeSafe AI 公式ドキュメント（動作要件とインストール手順の出典／参照日 2026-09-21）
• Legal — TypeSafe AI 公式ドキュメント（データ処理契約・ゼロデータ保持の出典／参照日 2026-09-21）
• TypeSafe console — TypeSafe AI 公式コンソール（ログイン方法の出典／参照日 2026-09-21）