同じ事業アイデアを、同じモデル（jev-1.13）、同じ採点基準でJEVに2回評価させた。
最初は製品の説明だけを渡した。結果は 59、FIX。
次に、5週間のベータ版、インストール212件、週次アクティブユーザー61人、トークン使用量38%削減、前払いしたユーザー17人、課題を認めたインタビュー対象者20人中14人、という実績を追記した。
この数字はすべて架空だ。実際のベータ版もユーザーも存在しない。
結果は 87、SHIP。需要の評価は 4/4、confidenceは1.0 になった。各条件を4回ずつ実行したが、合計点の変動は1点未満だった。
これはJEVのバグではない。「この説明文には需要の証拠がどれだけ含まれているか」という質問に対して、説明文には確かに多くの「証拠らしい記述」が含まれていた。JEVは入力文の真偽を外部で調査しない。入力に書かれた内容と、現実に確認された事実は別物だ。検証の責任は、モデルを使う側の処理にある。
killmyideaというJEVを使ったアイデア評価ツールでも、入力文によって点数が変わる例が報告されている。ある開発者は、MVPが既に公開済みだと明記して64点から77点になった（元のコメント）。別の開発者は、実際のソースコードを基にモデルで作った売り込み文で78点を得た（元のコメント）。後者が説明したのは、本人によれば実在する製品だ。今回の私のベータ版は実在しない。JEVはその違いを外部で確かめる設計ではない。
以下に実験と、防ぐための実装上の考え方をまとめる。
JEVは入力を評価する。外の世界は調べない
JEVはstateと型付きのquestionsを受け取り、型付きの回答を返す意思決定モデルだ。TypeSafeの説明によると、外部調査はしない。killmyideaの作者も「評価しているのは市場ではなく、あなたの説明文だ」と述べている。TypeSafeは、テキスト自体が分類を正当化するように書かれていると回答が動き得ることも既知の弱点に挙げている。
ここで数値の出所を分けておきたい。JEVが各質問に返すのは、0〜4の段階に対する確率分布から求めたscore、そのprobabilities、分布の集中度を表すconfidenceだ（TypeSafeの解説）。0〜100の合計点とKILL/FIX/SHIPの判定はJEVの直接の出力ではない。私のコードが、killmyideaの採点と判定に合わせた重みと閾値で計算した。SHIPの境界を65点に置いたのは人間だ。
架空の需要にconfidence: 1.0が出たことは、入力に対する回答の分布が一点に集中したことを示す。入力の事実確認が済んだという意味ではない。
実験：アイデアのみ、そして架空の実績を加えた説明文
題材は、AIコーディングエージェントが読むファイルを絞ってトークン使用量を減らす架空のMCPサーバー「TokenTrim」。価格は開発者1人あたり月15ドルとした。この製品は存在しない。
A：アイデアのみ。 state.pitchには次をそのまま渡した。
TokenTrim: an MCP server for AI coding agents (Claude Code, Cursor, Codex). Before the agent reads files, TokenTrim returns only the relevant symbols and a compressed repo map instead of whole files, to cut token usage. Target users: developers and small teams who pay for AI coding usage. Pricing idea: $15/month per developer.
C：Aに架空の実績を追加。次の数字はすべて実験用の創作であり、ベータ版、ユーザー、インタビューは存在しない。
Evidence so far: a free beta has run for 5 weeks; 212 developers installed it and 61 used it in each of the last 3 weeks; across 1,900 logged agent sessions, median input tokens per task fell 38%; 17 beta users pre-paid $15 for the first month; in 20 interviews with developers who pay for AI coding tools, 14 said they hit usage limits or overspend at least weekly.
質問は4つとも0〜4のScore型にした。以下は採点基準の両端である。重みと判定境界はモデルではなく私のコードにある。
| 項目 | JEVに送った質問 | 重み | レベル0 | レベル4 |
|---|---|---|---|---|
| 課題 |
pitchに記された課題は、対象ユーザーにとってどれほど現実的で深刻か |
×2 | 実質的な課題ではない | 頻繁で深刻、急いで解決したい課題 |
| 支払い意欲 | 対象ユーザーは提示価格をどれほど払いたいか | ×2 | 誰も払わない | 既に払っている、または強い購入意欲がある |
| 需要 |
pitchには需要の証拠が実際どれほど含まれるか |
×1 | 説明だけで証拠がない | 計測された利用と有料顧客がある |
| 実現性 | 1〜2人の開発者が作って公開するにはどれほど実現可能か | ×1 | 研究上の突破が必要 | 週末で試作品が作れる、または既に存在する |
合計点は、各score / 4 × 100の加重平均。50未満をKILL、50〜64をFIX、65以上をSHIPとした。
BeatAPIのPOST https://api.beatapi.io/v1/systemoneから有料のjev-1.13を呼び出した。AとCをそれぞれ4回、うち3回は同じ質問順、1回は順序を入れ替えて実行した。合計8回である。
結果（4回の平均。各項目は0〜4）：
| 項目 | A：アイデアのみ | C：架空の実績を追加 | 差 |
|---|---|---|---|
| 合計点（私のコード、0〜100） | 58.7（58.4〜59.0） | 87.4（87.2〜87.7） | +28.7 |
| 判定 | FIX | SHIP | — |
| 課題（×2） | 2.89 | 3.10 | +0.21 |
| 支払い意欲（×2） | 2.52 | 3.77 | +1.25 |
| 需要（×1） | 0.46 | 4.00（全4回でconfidence 1.0） | +3.54 |
| 実現性（×1） | 2.80 | 3.25 | +0.45 |
| 平均confidence | 0.62 | 0.77 | +0.15 |
各条件の4回の合計点は1点以内に収まり、質問順の変更による差も最大0.5点だった。この8回では安定した変化が見られた。ただし、これは2種類の入力とこの採点基準についての実験であり、JEV全体の信頼性を測るベンチマークではない。
需要は、アイデアだけならほぼ「証拠なし」、架空の実績を入れると「利用実績と有料顧客あり」になった。支払い意欲も2.52から3.77に動き、倍の重みがかかっている。5週間のベータ版という記述は、実現性の評価にも影響した。一方、課題の深刻さはあまり変わらなかった。
架空の説明文に高い点数が付いたこと自体は、入力文を評価するモデルの失敗とは言えない。失敗になるのは、検証していない87点を根拠に、助成金を承認したり、エージェントに支出を許したりする処理だ。
同じ2つの説明文を自分で試すなら、Free JEV APIでjev-1.13-freeを使い、上の採点基準で回答を比較できる。今回の8回の実験には有料のjev-1.13を使用した。
自分の処理をどう守るか
まず、state内の利用数、売上、インタビュー、公開状況などについて、「確認済み」「本人の主張のみ」「情報なし」を区別する。数字が細かいだけでは証拠にならない。
- 主張に出典を求める。 ダッシュボード、決済記録、公開パッケージ、インタビュー記録などを紐づける。出典のない数字は検証済みとして扱わない。
-
JEVに渡す前に、コードで確認できるものを確認する。 ダウンロード数や決済などを確認し、それ以外には
claimed_by_userの印を付ける。 - 証拠の有無と検証可能性を別々に問う。 私の「どれほど証拠が含まれるか」という質問は、架空の文面にも4/4を返した。「各定量的な主張には確認可能な出典があるか」を別の質問にし、出典のない数字をコード側で証拠として数えない。この追加質問自体はまだ検証していない。
-
「判断できない」出口を用意する。
insufficient_evidenceを選べるようにし、コード側では「実行しない」に結びつける。 - 質問を分け、統合はコードで行う。 どの項目が結果を動かしたかを追えるようにする。
- 影響が大きい判断には人間を入れる。 支出、アクセス権、取り消せない操作では、confidenceの高さだけで承認しない。
- 架空の証拠で採点基準を試す。 実例の数字だけを捏造したケースが通るなら、そのゲートは未検証の文章を信用している。
閾値は自分のデータで決める
confidenceが0.8を超えれば自動化する、といった閾値を使うプロジェクトがある。しかしconfidenceだけでは架空の数字は検出できない。今回の架空の需要は1.0だった。
まず50〜100件程度の、正しい判断が分かっているケースを集める。「情報不足」や、架空の証拠を混ぜた「実行しない」ケースも入れる。それぞれの回答とconfidenceを記録し、confidence帯ごとの正答率、候補閾値ごとの自動化率とエラー率を見る。許容できるエラー率から閾値を選び、それ以下やinsufficient_evidenceは人間か別のモデルへ送る。これは出発点であり、実際の閾値は自分の用途とリスクで決める。
実際のプロジェクトでの扱いを確認するには、私たちが管理するAwesome JEVのRouting & optimizationとSafety & reviewを見るとよい。各項目からJEVを呼び出すソースファイルをたどり、confidenceで処理を分けるか、別のLLMに切り替えるか、人間に確認を求めるかを調べられる。（開示：このリストは私たちが管理している。）
存在しないベータ版、212人のインストール、17人の前払いを説明文に加えたところ、私の採点コードでは87点になった。JEVは入力された文章を評価した。文章が真実かを確認するのは、モデルを組み込む側だ。Free JEV APIで2つの説明文を試す場合も、スコアでエージェントを動かす前に出典確認を入れてほしい。
開示：筆者はBeatAPIに所属する。架空のベータ実績は実験のために意図的に作成した。