くまさんと学ぶ、おしゃべりしない新型AI「Jev」入門

はじめに：おしゃべりしないAIとは？

ある日のこと、知的好奇心が旺盛なくまさんは、インターネットを眺めながら不思議そうに首をかしげていました。

世の中で話題のAIといえば、チャットで長い文章をすらすらとおしゃべりしてくれるものが主流です。
ところが、くまさんはある新しい噂を耳にしました。
「文章をいっさいおしゃべりしないAIが登場…？どういうことや……？」

そのAIの名前は、TypeSafe社が開発した「Jev（ジェブ）」。
Jevはおしゃべりをしません。そのかわりに、

「これはYesかNoか」
「並んだ選択肢のなかで、どれが最も当てはまるか」
「基準に照らして、何点満点中何点か」
といった、判断や分類・スコアリングだけに特化したAIなのです。

おしゃべりをしないぶん、一般的な生成AIよりも圧倒的に高速で、ブレのない「確率付きの構造化データ」を返してくれます。
「おしゃべりするんやなくて、白黒はっきり判定してくれる道具ってことか！」
くまさんは目を輝かせました。

今日はくまさんと一緒に、ブラウザで動かせる実験場（Playground）をのぞきながら、Jevが備える3つの基本機能（プリミティブ）――『Noul』『Choice』『Score』の仕組みを体験してみましょう。

Jevの実験場（Playground）の基本構成

まずはPlayground画面の基本的な構造を確認しておきましょう。画面はシンプルな領域に分かれています。

領域	役割	例
State（状態・入力データ）	判定対象のデータをJSON形式で記述する領域	`{"food": "hotdog"}`
Questions（質問・判定指示）	AIに何を判定させたいかを定義する領域	`instructions` に「`food` はサンドイッチか？」と指定
Run request ボタン	クリックするとAIが判定を実行！	—

State（状態・データ）：判定対象となる元データをJSON形式で置いておく領域。
Questions（質問）：AIへの指示（instructions）や判定基準（criteria）を定義する領域。1回のリクエストに複数の質問を含めることもできる。
Run request ボタン：設定したStateとQuestionsを送信し、判定結果を取得する実行ボタン。

★重要テクニック：バッククォートによる変数参照
質問文の中で `food` のようにバッククォートで囲むと、State内の該当フィールドを自動参照する「変数」として機能します。質問側のテンプレート（判定ロジック）を固定したまま、State側のデータだけを差し替えて再利用できる設計になっているのです。

レッスン1：真偽（Yes/No）を確率で判定する「Noul（ヌール）」

くまさんが最初に出会ったプリミティブは、『Noul（ヌール）』。
ある命題が正しい（true）か、正しくない（false）かを0〜1の確率でズバッと判定する機能です。
くまさんは、Playgroundに用意されていたテーマで試してみることにしました。

テーマ：ホットドッグはサンドイッチなのか？

「パンにソーセージを挟んだホットドッグは、果たしてサンドイッチに含まれるのだろうか？」
日常会話でも意見が分かれがちなこの問題に、Jevはどう答えるのでしょうか。

ステップ1：判定基準を決めずにそのまま聞いてみる

くまさんはまず、直球の指示のみを与えてみました。

指示（instructions）: "Is hotdog a sandwich?"（ホットドッグはサンドイッチですか？）
判定基準（criteria）: 未設定（空欄）

リクエストを実行してみます。

【判定結果】
60% true

結果は 60% true でした。
「ややYes寄りではあるけど、五分五分に近くて、AIも迷ってるみたいやな」とくまさんは気づきました。
何をもってサンドイッチと定義するのかが分からなければ、AIも判断に迷ってしまうのです。

ステップ2：判定基準（criteria）を具体的に追加

そこでくまさんは、「こういう条件を満たすものをサンドイッチとする」という判定基準（criteria）をJevに詳しく伝えてみることにしました。

true（サンドイッチである）の基準:
「パンのような構造物の間に、肉・チーズ・野菜・スプレッドなどの具材が挟まれている」
false（サンドイッチではない）の基準:
「パンで包まれていない、または1枚のパンだけを使う、またはトルティーヤ・ウエハース・クッキーのような非パン系の包みを使う」

再度リクエストを実行してみます。

【判定結果】
77% true

「なんやこれ、77% true まで上がったやん！」
くまさんは声をあげました。
「何をもってtrueとするのか」という境界条件を具体的に言語化してあげたことで、AIの確信度が明確に向上したのです。

ステップ3：変数参照を活用し「アイスクリームサンド」を判定

次にくまさんは、学んだ変数参照を使ってみることにしました。
質問文の中の "hotdog" を `food` に置き換えて、State側から食べ物のデータを渡す構成にします。

/* State */
{
  "food": "Ice cream sandwich",
  "description": "クッキー/ウエハース/薄いケーキの間にアイスクリームを挟んだ冷凍デザート"
}

「名前に『sandwich（サンド）』という単語が入ってるで。表面的なキーワードだけで判定するなら、100% true になってしまいそうやけど……」
くまさんは少しドキドキしながら結果を待ちました。

実行結果はこちらです。

【判定結果】
34% true

「34% true……！つまり約66%の確率で『サンドイッチではない』と判定されたんや！」
くまさんは驚きました。
ステップ2で定義した基準――「クッキーやウエハースのような非パン系の包みはfalse」というルールを、Jevはしっかり覚えていたのです。
名前に含まれる "sandwich" という文字列の引っかけに惑わされることなく、定義された論理構造を正しく読み取って判断してくれたのでした。

【レッスン1のまとめ】

判定基準（criteria）を具体的に定義するほど、モデルの確信度が高まる

表面的な単語の引っかけに騙されず、定義されたルールの論理構造に基づいて判断する

質問文を変数化（参照）してStateと分離することで、同じ判定ロジックを大量のデータに再利用できる

レッスン2：複数候補から最適解を選ぶ「Choice（チョイス）」

続いてくまさんが体験したのは、2つ目のプリミティブ『Choice（チョイス）』。
あらかじめ用意した選択肢（最大255個）の中から最もふさわしいものを1つ選び、それぞれの選択肢の確率分布を算出してくれる機能です。

テーマ：空は何色か？（What color is the sky?）

ステップ1：色の名前だけで選ばせてみる

まずは7つの色を用意し、各選択肢の説明文は空欄のまま質問してみました。

指示（instructions）: "What color is the sky?"（空は何色？）
選択肢（Options）: indigo（藍色）、electric blue（鮮やかな青）、baby blue（淡い水色）、gray（灰色）、lavender（ラベンダー）、salmon（サーモンピンク）、seafoam green（海の泡のような緑）

リクエストを実行してみます。

【判定結果】
baby blue: 83%
electric blue: 16%
gray: 1%
（Confidence / 確信度: 79%）

「baby blue（淡い水色）が83%で圧倒的な1位や！一般的な昼の晴天を考えたら納得の結果やなあ」
くまさんは頷きました。そして、結果の下に表示されている『Confidence（確信度）: 79%』という数値に目を留めました。

「確率（Probability）」と「確信度（Confidence）」はどう違うのでしょうか？

確率（Probability）：各選択肢に割り振られた相対的なスコア分布（全体の合計が100%）。
確信度（Confidence）：1位の答えが、2位以下に対して「どれだけハッキリ差をつけて勝っているか」を示す指標。
たとえば、徒競走で2位を大きく引き離して独走ゴールしたら確信度は高くなり、写真判定になるような僅差なら確信度は低くなるのです。

ステップ2：選択肢を詳しくしたのに……確信度が大幅ダウン！？

「AIがもっと識別しやすいように、詳しく教えたろ！」
くまさんは、各選択肢にカラーコードや詳細な説明（indigoなら『万年筆のインクのような濃い青』『#280868』など）をびっしり書き加えて実行してみました。
情報を詳細に補足したのだから、AIの確信度もさらに高まるはず……。

ところが、実行結果は意外なものになりました。

【判定結果】
baby blue: 53%
electric blue: 46%
（Confidence / 確信度: 46%）

「あれっ！？確信度が 79%から46%へ大幅に低下 してるやん！選択肢を詳しく説明したのに、なんでAIは迷ってしもたんやろ？」
くまさんは不思議そうに考え込みました。

実はこれこそ、「選択肢側だけをいくら詳細に記述しても、判定対象（State）側の文脈情報が何もないままだと、AIはかえって判断に困ってしまう」という現象だったのです。
「淡い水色」も「鮮やかな青」も、どちらも空の色としてあり得ます。前提となる情報がないまま選択肢の情報だけが増えたため、票が割れて拮抗してしまったのでした。
「いつ、どこの空なのか」が分からないまま絵の具のパレットだけ細かく渡されても、どれを塗ればいいか決められないのと同じだったのです。

ステップ3：Stateに「現場の前提状況」を与える

そこでくまさんは、State側に具体的な状況を与えてみることにしました。

/* State */
{
  "condition": "Tornado's a-comin'"  /* （竜巻・トルネードが接近中） */
}

トルネードが接近しているという、緊迫した状況設定です。
リクエストを実行してみます。

【判定結果（説明なし版）】
seafoam green: 62%
gray: 35%

【判定結果（説明あり版）】
indigo: 40%
seafoam green: 36%
（Confidence: 29%）

「青系の選択肢が消えて、seafoam green（緑色）や gray（灰色）が上位に入ってきたやん！空が緑色……？」
くまさんは驚いて調べてみました。
すると、巨大な竜巻が発生する直前、厚い積乱雲の中で太陽光が散乱し、空が本当に不気味な緑色に見える（グリーン・スカイ現象） という気象現象があることが分かったのです。

「Jevは、現実世界の気象知識まで踏まえて判断してるんや！」
くまさんは感銘を受けました。
Jevは広範な事前知識を備えています。だからこそ、判定対象の文脈（State）と選択肢（Options）の両方を適切に揃えてあげることで、高度で的確な推論力を発揮してくれるのでした。

【レッスン2のまとめ】

「確率（各選択肢の割合）」と「確信度（1位と2位の差の開き具合）」は別個の指標

選択肢側だけを細かくしても不十分。判定対象（State）のコンテキスト情報もセットで具体化する必要がある

Jevは自然科学や現実世界の一般知識を反映した高度な判定ができる

レッスン3：多段階のモノサシで評価する「Score（スコア）」

最後のプリミティブは、『Score（スコア）』。
世の中の事象は、Yes/Noの二者択一だけでは測れないグラデーションのある問題もたくさんあります。
Scoreは、テストの採点基準表（ルーブリック）のように、2〜10段階のレベルを設定して、対象を定量的に評価・採点する機能です。

テーマ：サルの自撮り写真、著作権の貢献度はだれのもの？

くまさんは、Playgroundに用意されていた「サルの自撮り訴訟（Naruto v. Slater）」というテーマで試してみることにしました。実際にアメリカの裁判所で大論争になった有名な事件です。

インドネシアの自然保護区で、クロザルのナルト（Naruto）が写真家スレーター（Slater）さんのカメラをいじって、見事な自撮り写真を撮影しました。スレーターさんがその写真を本にして出版したところ、「シャッターを切ったのはサルなのだから、サルの著作権ではないか」と裁判になった事件です。

/* State */
{
  "scenario": "（事件の詳細な経緯）",
  "subject": "Naruto（サル）",
  "human": "Slater（写真家）",
  "creative_work": "the grinning self-portrait（ニヤリと笑う自撮り写真）"
}

ステップ1：まずYes/No（Noul）を4回連続で判定してみる

くまさんはまず、先ほど学んだNoul（Yes/No判定）を4つ組み合わせて、状況を分析してみました。

take_action_subj: ナルト（サル）が直接その行為（シャッターを切る等）をしたか？
→ 94% true
take_action_human: スレーター（人間）が直接その行為をしたか？
→ 19% true
enabled_by_subj: ナルトの行動がこの作品を可能にしたか？
→ 96% true
enabled_by_human: スレーターの行動がこの作品を可能にしたか？
→ 88% true

「なるほど……！『直接シャッターを切ったか』ではサルが圧倒的（94% vs 19%）やけど、『作品制作を可能にしたか』という間接的な貢献ではサルも人間も両方90%前後と極めて高い（96% vs 88%）んやな」
カメラをジャングルに持ち込んでセッティングしたのはスレーターさんです。実際の裁判で争われた核心部分が、確率として忠実に現れていました。
しかし、くまさんは腕組みをしました。
「4つのYes/Noの結果を見比べても、『結局どちらがどれくらい作品に貢献したのか』を総合的に比較すんのは難しいなあ」

ステップ2：Scoreプリミティブで共通の尺度により一括評価

そこで活躍するのがScoreです。
Noulを何個も積み重ねるよりも、1つのScore質問に凝縮するほうがすっきりと評価できます。共通の5段階評価（0〜4点）のルーブリックを定義して、2人の貢献度を同じモノサシで採点してみることにしました。

【評価基準（ルーブリック）】

0: None（まったく貢献していない）

1: Minorly（わずかに貢献した）

2: Moderately（一定程度貢献した）

3: Majorly（大部分を貢献した）

4: Completely（完全に1人で成し遂げた）

設定する質問はこの2つです。

サルの貢献度: "How much did \subject` contribute to `creative_work`?"`
人間の貢献度: "How much did \human` contribute to `creative_work`?"`

リクエストを実行し、結果を比較してみます。

【判定結果の比較】

項目	Naruto（サル）	Slater（写真家）
平均スコア	3.47 / 4 点	1.13 / 4 点
確率の山	Majorly 46% / Completely 51%	Minorly 69%
Confidence	56%	68%

「結果が一目瞭然や！」
くまさんは思わず声をあげました。

ナルト（サル）は「Majorly（大部分）」46%と「Completely（完全）」51%に票が集中し、平均3.47点。
スレーターさんは「Minorly（わずか）」が69%で、平均1.13点。

Noulを重ねていた段階では曖昧だった貢献度の度合いが、Scoreを用いたことで「作品そのものを直接生み出した主体はサルである」という評価として定量的に可視化されたのでした。
同一のルーブリックで評価することで、異なる対象間の比較が公平かつ明快になることに、くまさんは気づきました。

【レッスン3のまとめ】

「度合い」や「貢献度」を測定したい場合、Yes/Noを繰り返すよりもScore型で直接評価する方が解像度が高い

共通のルーブリック（採点基準）を用意することで、複数の対象を同一の尺度で公平に比較できる

さいごに：3つのプリミティブの使い分け

実験を終えたくまさんは、Jevの3つのプリミティブの特徴を整理してみました。

プリミティブ（技）	主な用途	実験から得られた要点
Noul（ヌール）	単純なYes/No（真偽）判定	判定基準（criteria）を明確化すると確信度が向上。表面的な単語ではなく構造的なルールで判断する
Choice（チョイス）	複数の選択肢から最適解を判定	選択肢の詳細だけでなく、判定対象（State）のコンテキスト情報も充実させる必要がある
Score（スコア）	度合い・貢献度の測定や複数対象の比較	Yes/Noを重ねるより、共通のルーブリックで直接採点した方が解像度高く比較できる

今回の実験全体を通じて、最も本質的だったポイントは何だったのでしょうか。
くまさんは、「判定の指示やルール（instructions / criteria）」と「入力データ（State）」の両方をバランスよく具体化することの大切さに気づきました。
どちらか一方だけを作り込んでも、空の色の実験のように期待通りの精度が出ないことがあります。

開発元のTypeSafe社が述べているように、Jevの1つひとつの判断は小さな部品（atomic decisions）ですが、極めて高速でブレがありません。この高精度な最小単位の判定パーツをパイプラインのように組み合わせることで、堅牢で知的なシステムを構築できるのです。

「生成AIの自由なテキスト出力に頼るだけやなくて、こうした確定的な判定AIを適材適所で使いこなす視点が大切なんやな」
くまさんは深く納得し、次はどんな判定パイプラインを自分で設計してみようかと、わくわくしながら胸を躍らせるのでした。