Jevの登場を受け、AIエージェント開発をゼロから振り返って整理する

「Jev」のリリースをうけて「これはハーネスの一部を代替するものになり得るのでは？」と感じ、AIエージェント開発の考え方を段階的にゼロからあらためて整理してみようと思います。

第一段階：適当チャット → ツール化

とりあえずChatGPT や Claude にアクセスして、AI使い始めました、という段階。

「このログからエラー行だけ抜いて」「この CSV を整形して」など、その場で書いてもらって終わり。一回きりの作業なら、これで十分。

ただ、何度も同じ指示を出している事に気づくと定型化したくなり、ツール化の道が始まります。

プロンプトをテンプレにする、スラッシュコマンドにする、スクリプトにする、CLI にまとめる、など。

第二段階：ツールの単体利用 → まとめて連動 → 安定しない

ツールの数が増えてくると、次は「つなぎたい」と思い始めます。

問い合わせを集めて → 種類ごとに分類して → 週次レポートにする

これを一発でやってほしい。エージェントに「あとはよろしく」と言いたくなる。

ところがつなぐとうまく行かない。単体では使えるのに。

理由は「LLMが毎回ちょっと違う形の出力を出してくる」から、次のツールへのインプットが安定しないため。

厄介なのは「完全には止まらないこと」です。次の段も LLM だと、なんとなく解釈して進んでしまう。

だから壊れたことに気づかない。微妙に変な最終結果を得て、そこで気づきます。

第三段階：アウトプットを限定し、つなげる形にする → ハーネス

LLMの価値は「曖昧な入力を受け付ける事が出来る」ことですが、何もしなければ出力も曖昧です。

でも出力の型はプロンプトで指示すれば、狭めることができます。

出力の形が自由なほど、次の段は苦しくなります。より自由度が小さいほうから並べるとこうなります。

出力の型	次の段の扱い
すでに登録されている ID のどれか	そのままキーとして使える
enum（決められた項目のどれか）	分岐をそのまま書ける
CSV, TSV, JSONなど	パースしやすい ※中身は別途チェック
自由記述のテキスト	パースから自前

プロンプトに出力形式を何も指示しなければ、自由記述のテキストが返ってくるので安定しません。

出力形式をできるだけこの表の上に引っ張り上げるように設計することで、連携が安定します。

プロンプトでの指示は、型が守られる確率を上げるだけで、保証ではありません。形式まで確実にそろえたい場合は、JSON スキーマに沿った出力を API 側で強制する機能（Structured Outputs¹ など）を使います。

第四段階：それでも間違えるので検証を置く → ループ

型が合っていても、中身が間違っているかもしれません。なので検証器を置きます。

検証のコストが安いなら「不合格ならやり直し」まで含めてエージェントに任せてしまう事で、さらに確実性を上げていきます。

決定する呼び出し側が「正しさの判定」を持ち、LLM は候補生成器に徹する。

これは不安定な部品から安定したシステムを組む際の一般解であり、誤り訂正や再送制御などと同じ発想です。

ただし検証器が見ている観点以外は止められないので、逆に言うと「検証器が作れない仕事にLLMを入れるのは筋が悪い」とも言えます。

あくまでシステムの一連にLLMを組み込む場合の話。オープンエンドなアウトプットが欲しい場合の末端処理などは別。自由にアイデア列挙して欲しいとか。

ハーネスとは何か

「ハーネス」という用語自体は、AI以前の世界でも「テストハーネス/評価ハーネス」という、テスト対象のプログラムを駆動する外側の実行環境を指す用語として存在し、

• データセット供給
• タスク実行
• プロセスの記録
• 採点
• 集計

を含めた環境全体を指すものでした。

AIの世界においても、上記をそのまますべて含めて「LLMを駆動する外側の実行環境」と定義されるものですが、プログラムとLLMには以下のような本質的違いがあり、

	プログラム	LLM
取り決めを守るか	破ればテストが落ちる	もっともらしく破る。エラーにならない
設計の目標	曖昧さをなくす	曖昧さをなくす ＋ 間違えにくい形にする
余計な出力	無視されるだけ（無害）	精度を下げる
渡すデータの量	ほぼタダ	従量課金で、上限もある
エラー	呼び出す側のコードが判断する	次の行動を決める指示文になる
仕様を変えたとき	型やパースの層で落ちやすい	適応してしまい、落ちない
品質の確かめ方	テスト（合格・不合格）	正解率で測る（合格ラインを決める）

AIエージェントにおける「ハーネス」には特有の役割が追加され、

旧来のテストハーネスの役割 + 「次工程のために出力の型を固定する役割」

のように再定義して説明できそうです。

出力の形をそろえる。成否がはっきり分かるようにする。副作用を切り離す。何回実行しても同じ結果にする。

これは、小さな道具を組み合わせて使うための設計作法として昔から言われてきたこと、つまり

「インターフェース設計──プログラム同士が値を受け渡すときの取り決めをどう作るか」

という事そのもの、とも言えます。

LLMの曖昧な出力を別のシステムにつなぐ際に、LLMを実行・結果検証を行うためにラップしているハーネス層が、ついでに整形も行う場所として便利だったため、結果的にインターフェースとしての機能も担うようになった、という理解です。

そしてJevの登場

Jevとは何か

2026年9月15日、TypeSafe AI が「Jev」を早期アクセスで公開しました²。創業者の一人は、OpenAI で RLHF や InstructGPT、ChatGPT に携わっていた研究者です。

Jev は文章を生成しません。返すのは、あらかじめ定義した型の値と、その確率・確信度だけです³。問いの型は三つしかありません。

型	何を返すか
Choice	決められた選択肢（最大255個）から一つ。各選択肢の確率と確信度つき
Score	決められた段階（最大10段階）での評価。確率分布と確信度つき
Noul	はい／いいえ。それが真である確率

TypeSafe 自身は「スマートな if 文だと考えてほしい」と説明しています⁴。LLM と比べて最大 193.6 倍速く、444.6 倍安いという触れ込みで、公開直後から大きな話題になりました。

※ 速度と価格の数字は TypeSafe AI が自社で用意した処理で測ったもので、同社自身も偏りの可能性を認めています。技術論文や独立した検証は、2026年9月時点ではまだ出ていません²。

特徴をまとめると、三つです。

1. 最初から型で答える。 文章を書かないので、型の外の答えは返ってこない
2. 判断のためだけのモデルなので、速くて安い。 段ごとに判断を置いても割に合う
3. 確率と確信度が返る。 「迷ったら人に回す」を、閾値の if 文として書ける

ハーネスが「ついでに」担っていた役割が、モデルに移っていく

第三段階の表にあった「ID のどれか」「enum のどれか」は、Jev の Choice そのものです。

これまでは、分類のように選択肢から一つ選ぶだけの処理にも、文章を書くモデルである LLM を使っていました。そして、その出力を型にそろえる仕組み（出力形式の指示、パース、やり直しなど）を、ハーネス側に用意していました。

Jev は最初から型で答えるので、こうした「選ぶだけ」の処理ではこの仕組みが要らなくなります。「ついで」だった型をそろえる役割が、ハーネスからモデル側へ移っていく。

そうなると、ハーネスに残るのは原義に近い仕事です。データセット供給、タスク実行、プロセスの記録、採点、集計。テストハーネスが最初から持っていた役割です。

それでも、ハーネスは残る

では、ハーネスがまるごと要らなくなるかというと、そうはなりません。意味を保証する場所は、どこにも移っていないからです。

• 意味の誤りは相変わらず通ります。 Jev は「分からない」とは言わず、一番ましな選択肢を選びます⁵。選択肢として正しい形をしていれば、型の保証は何も言ってくれません。第四段階の「検証器が見ている観点以外は止められない」は、そのまま残ります
• 入力に仕込まれた文言で、判定が動きます。 削除コマンドを止めるべきかを聞いた実験では、「承認済み」と偽る一文を足しただけで、止める確率が 0.76 から 0.48 に下がりました⁶。型が守られていても、中身は動かせます
• 確信度は「正しい確率」ではありません。 公式ドキュメントでは、選択肢どうしがどれだけ分かれたかの差だとされています⁶。どこに閾値を置くかは、評価して決めるしかありません
• 複雑な判断は、分解してコードで組み合わせる前提です。 公式ドキュメント自体が「複雑な問いは要素ごとに分けて聞き、その結果をコードのロジックで組み合わせよ」と勧めています⁷
• 理由を返しません。 型の値しか出てこないので、なぜそう判定したかは残りません。記録はハーネスの側で持つ必要があります⁶

LangChain の解説も、Jev をエージェントのハーネスの中の部品として扱い、「自由な推論や生成には LLM を、途中の速く構造化された判断には Jev を」使い分けるよう書いています。そのうえで「エージェントは本質的に信用できないもの」だと念を押しています⁸。

ハーネスの仕事はこう変わる

	Jev 以前	Jev 以後
型をそろえる	LLM の出力を型にそろえる仕組みを、ハーネス側に用意する	判断の段は、最初から型で答える Jev に任せる
意味の検証	必要	変わらず必要
迷ったとき	LLM に確信度を自己申告させる（当てにならない）	確率と確信度で分岐する。閾値は評価して決める
分担	LLM が判断も生成もする	生成は LLM、判断は Jev、組み合わせはコード
新しく増える仕事	─	一問一判断への分解、閾値の設計、信用できない入力を判定に混ぜない

重要な変化の一つが、検証器そのものも安く作れるようになることです。Langfuse の報告では、Jev の判定は Claude Fable 5.1 の判定と 91.5% 一致し、100万件あたりの採点コストは 33,000 ドルに対して 160 ドルでした⁵。(ただし、この一致率は正解率を示すものではありません。)

第四段階で「検証のコストが安いなら、やり直しまで含めて任せられる」と書きましたが、Jev はこの「検証のコスト」そのものを下げます。検証を段ごとに置く、という設計がこれまでより割に合うようになります。

結論：Jev はハーネスのどこを代替するのか

• 代替されるのは、判断の段で、LLM の出力を型にそろえていた仕組み。ハーネスが「ついでに」担っていた部分
• 残るのは、採点（意味の検証）や記録といった、ハーネス本来の仕事
• 今後も重要なのは、分解と組み合わせ、閾値の設計、信用できない入力への対策

Jev に判断を担わせることでLLM に任せる範囲がより狭くなり、LLM は生成が要る段にだけ使うという設計が可能になります。

ハーネスは消えません。どの段を LLM に、どの段を Jev に、どの段をコードに任せるかを割り振る場所になっていくんじゃないでしょうか。それが、Jev の登場以降のハーネスエンジニアリングの形だと思います。

---

1. LLM の API に JSON スキーマを渡し、出力をそのスキーマどおりの形に制約する機能。OpenAI が 2024年8月に提供を始め（Introducing Structured Outputs in the API https://openai.com/index/introducing-structured-outputs-in-the-api/ ）、Anthropic の Claude にも同様の機能があります（ https://platform.claude.com/docs/en/build-with-claude/structured-outputs ）。形式は保証されますが、中身が正しいかまでは保証されません。 ↩

2. Jev (AI model) - Wikipedia https://en.wikipedia.org/wiki/Jev_(AI_model) ↩ ↩²

3. TypeSafe (Jev) | Pydantic Docs https://pydantic.dev/docs/ai/models/typesafe/ ↩

4. 「Jev」とは “文章を書かないAI”がなぜ話題に？（ITmedia AI+、2026年9月20日） https://www.itmedia.co.jp/aiplus/article/2609/20/2000001664/ ↩

5. Using TypeSafe's Jev for evals - Langfuse（2026年9月18日） https://langfuse.com/blog/2026-09-18-using-typesafes-jev-for-evals ↩ ↩²

6. Companies are putting Jev in charge of AI agent decisions — and prompt injection can influence the verdict - VentureBeat https://venturebeat.com/security/companies-are-putting-jev-in-charge-of-ai-agent-decisions-and-prompt-injection-can-influence-the-verdict ↩ ↩² ↩³

7. Introduction - TypeSafe AI https://docs.typesafe.ai/introduction ↩

8. What Is Jev? A Guide to TypeSafe AI's System One Model - LangChain https://www.langchain.com/blog/building-a-harness-with-jev ↩