state（状態）とは｜Jev に渡す材料の作り方と instructions / criteria の構造化

問い合わせ文だけでなく、注文情報や返金ポリシーも一緒に見てほしい。
そんなとき Jev（ジェヴ）には何をどう渡し、質問側はどう書けばよいのでしょうか。
結論から言うと、判断材料は state（状態）に JSON でまとめて渡し、instructions（指示文）や criteria（基準）も必要に応じて JSON の構造で書けます。
実務では、業務データをそのままの形で渡し、質問を短く保つ土台になります。

state（状態）とは

TypeSafe AI の公式ドキュメント State では、state は System One モデルに評価させる内容そのものと説明されています。
リクエストの state フィールドに質問と並べて渡します。
1回のリクエストは1つの state を評価し、すべての質問が同じ state を見て独立に判定され、Choice、Score、Noul（ヌール）を混ぜて構わないとされています。

文字列・オブジェクト・配列の3つの形

最も単純な state は "My card was charged twice." のような文字列です。
公式の例では、オブジェクトは {"message": "My card was charged twice.", "order_id": "A-104"} のような名前付きの項目や関連レコードに、配列はメッセージやレコードの並びに向くとされています。
公式の推奨は、各部分に名前が付いて関係がはっきりするオブジェクトをほとんどのリクエストで使うことで、文字列は1つのテキストで済む単純な用途向けという説明です。

チケット・注文・返金ポリシーを1つの state にまとめる

{
  "ticket": {
    "subject": "Duplicate charge",
    "messages": [
      {"from": "customer", "text": "I was charged twice for order A-104. Please refund the duplicate."},
      {"from": "support", "text": "We are checking the charges."}
    ]
  },
  "order": {
    "id": "A-104",
    "charges": [
      {"amount_usd": 49, "status": "captured"},
      {"amount_usd": 49, "status": "captured"}
    ]
  },
  "refund_policy": "Duplicate charges are eligible for a refund."
}

会話、注文、ポリシーを含んでいても、これで1つの state です。
関連情報は1つにまとめ、state には内容と事実だけを置き、「返金を求めているか」という判断は質問側に書く、という役割分担が示されています。

テキストのみ、主な学習言語は英語

公式ドキュメントの注記では、Jev はテキストのみを受け付け、画像・音声・動画は現時点で非対応とされています。
同じ注記に、Jev の主な学習言語は英語で、CJK（日本語・中国語・韓国語の文字）を含む他の言語も受け付けるが現時点では精度が低い、と書かれています。

質問から state の中の項目を指す

どの部分について聞いているかをバッククォート付きのパスで示す書き方が、公式ドキュメント Primitives (Questions) にあります。
上のサポート会話に対する Noul の instructions は Does `refund_policy` support the refund requested in `ticket.messages[0].text`, given `order.charges`? と書かれています。
ドットと添字のパスで、ポリシー、顧客の発言、請求のどれを判断材料にするかが明示されます。

instructions / criteria の構造化

公式ドキュメント Advanced: structure によると、System One モデルは構造を理解するよう学習されており、instructions、Choice の選択肢、Score の段階、Noul の criteria.true と criteria.false は文字列、オブジェクト、配列、null を受け付けます。
目安は、質問が複数の部分からなりキーのラベルで明確になるときと、すでに JSON である材料を文字列に崩さず渡したいときです。

1. instructions を field / extracted_value / question で組む

公式の例は請求書から抜き出した値の検証で、field オブジェクトで検査対象の項目を説明し、質問がキーでそれを参照します。

"instructions": {
  "field": {
    "name": "invoice_number",
    "type": "string",
    "description": "The identifier printed on the invoice."
  },
  "extracted_value": "4471",
  "question": "Does `extracted_value` match the `field` as it appears in `source_text`?"
}

同じ形で候補から選ぶ Choice や金額を段階に置く Score も組め、項目ごとに質問を作って1回で送る使い方が想定されています。
配列も使え、比較対象を compare にパスの配列で並べ、focus に着眼点を書く例があります。

2. Choice の選択肢を what / not_for / examples、または子ツリーで書く

公式の例では billing、orders、account の各選択肢に what、not_for、examples を持たせて境界を鋭くしています。
深い分類体系を歩くときは、各選択肢の値に子ツリーをそのまま入れます。

"criteria": {
  "Sporting Goods": {
    "Cycling": ["Bike Bottles & Cages", "Bike Lights", "Helmets"],
    "Fitness": ["Yoga Mats", "Resistance Bands"],
    "Outdoor": ["Tents", "Sleeping Bags", "Hydration Packs"]
  },
  "Home & Kitchen": {
    "Drinkware": ["Water Bottles", "Travel Mugs", "Tumblers"],
    "Cookware": ["Pots & Pans", "Bakeware"]
  },
  "Baby & Toddler": ["Sippy Cups", "Bottle Warmers", "Bibs"]
}

枝の下に何があるかを見せることで、モデルが枝を選ぶ前に葉の存在を知れるという説明です。
選ばれた部門の子を次の Choice の選択肢にして葉まで繰り返し、大きすぎる枝は子と葉の一部に刈り込みます。

3. Score は summary / signals、Noul は true / false で書く

Score の段階もオブジェクトにでき、公式の例では PR の説明が1つの変更に絞られているかを summary（要約）と signals（手がかり）で3段階に書いています。
Noul の criteria は省略可能ですが、境界が微妙なときは true と false に定義と例を付けられます。
公式の例は資格情報の開示を求めるメッセージかを問うもので、true 側に "Reply with your password"、false 側に "Reset your password from the settings page" のような例を置いています。

活用例｜どんな業種・職種で使えるか

• 経理・バックオフィス: 請求書の OCR（文字認識）結果を extracted_value として渡し、原文と一致するかを項目ごとに Noul で検証できます。項目の定義は field に置きます。
• EC・カタログ管理: 商品説明を state にし、分類体系の子ツリーを選択肢の値に入れて葉まで段階的に分類できます。
• 情報システム・セキュリティ: 送信者情報と本文をオブジェクトにまとめ、資格情報を要求しているかを true / false の定義と例で問えます。

つまずきポイント・注意点

• 関連データを文字列に連結して渡す。 オブジェクトに名前を付け、質問からパスで指す方が関係がはっきりします。
• 判断を state に書いてしまう。 state は内容と事実、判断は質問側という役割分担です。
• フィールド名を予約語だと思い込む。 what や focus は自分で決める名前で、短いラベルにします。
• 日本語で英語と同じ精度を前提にする。 CJK は現時点で精度が低いという公式の記述があります。

まとめ｜state は「文章を丸ごと渡す」から「材料を構造で渡す」への入り口にする

state は評価対象そのもので、文字列・オブジェクト・配列のどれでも渡せ、ほとんどの場面ではオブジェクトが推奨されています。
核心は、材料は state に、判断は質問に分け、質問の側も field や what / not_for / examples のような自分で名付けた構造で書けることにあります。
次の一手として、文字列に連結して渡している材料を1つオブジェクトに分け、質問からパスで指す形に書き換えてみてください。