Jevエコシステム観察（第3回）：4日間の失敗事例と、信頼すべきでない場面

前回までの2本の記事では、このエコシステムが4日間で生み出した成功面を取り上げました。本記事ではもう一方の側面である失敗の記録に焦点を当てます。根拠の基準は変わりません。すべて2026-09-15から09-19にかけて実施した10回のスキャンに基づき、第三者の数値はすべて作者の自己申告で、A/B/Cの3段階で評価しています。ただし、本記事で引用する主要な評価については、原文を一言一句読み込みました。

$1.43で行った厳密な検証

独立系の評価サイトagentjournalは、このエコシステムで最も堅実な対照実験の1つを実施しました。3つの分類タスク、5,477件のテスト行、34.1Mトークン、総コスト$1.43で、「単一の直接クエリ」と「12-14の観点に分けて採点し、ローカルでフィッティングする方法」を比較したものです。押さえておくべき5つの知見を順に紹介します。

1. 単純なタスクでは、次元分割を避けるべきです。トラップを含む200件の合成サンプルでは、直接クエリの正解率は100%でした（ラベルを入れ替えた後も100%で、位置バイアスはありませんでした）。一方、12次元分割のパイプラインは98.0%でした。より多くのトークンを費やしたにもかかわらず、結果は悪化しました。
2. 評価データの分割が不適切だと、数値は実態を反映しなくなります。ランダムな交差検証では98.0%でしたが、テンプレートファミリーでグループ化し、一致する特徴量を除外すると90.0%に下がりました。テンプレートのリークによる8ポイントの差です。同じ分割条件では、コストのかからない文字バイグラムのベースラインが93.5%に達し、これを上回りました。作者の2つの習慣は取り入れる価値があります。まず多数派クラスのベースラインを必ず出力すること、そしてデータセットを見る前に分割方法を設計することです。
3. 次元分割で効果が出るのは難しいタスクだけです。複数の弱いシグナルを集約した中にラベルが隠れている300件のタスクでは、直接クエリが64.7%、次元分割が74.0%でした（9ポイントの改善、p=0.0050）。ただし、無料の文字バイグラムのベースラインも同じく74.0%を達成しています。まず無料のベースラインを実装し、その後でモデルを検討してください。
4. 選択肢が多いと、必ず破綻します。実際の帳簿データで、単一の選択式プロンプトに12個の選択肢を与えた場合、正解率はわずか0.3998でした。「すべての単語を理解していたにもかかわらず、12個から1個を選ぶことには失敗した」という結果で、ボトルネックは理解ではなく判断の形式にあることを示しています。14次元に分割して重み付けすると正解率は0.9105まで回復し、n-gramと組み合わせると0.9695に達しました。
5. 誤検知が重大な問題となる場面では、次元分割は壊滅的な結果を招きます。判定の難しい良性サンプル339件（セキュリティドキュメント、レッドチームのメモ、本記事のような「攻撃手法に言及しているものの無害」なサンプル）では、直接クエリの誤検知率が1.5%だったのに対し、12次元分割では37.2%でした。約25倍の差で、4つの修正策を試しても、いずれも失敗しました。作者の結論は、これはパラメータ調整ではなく次元設計の問題だというものです。適切な直接呼び出しは、特徴量としてモデルに組み込むのではなく、独立した判定者としてモデルと並べて配置すべきです。

公式も例外ではない

公式Python SDKのクイックスタートに関するIssue #2には、コミュニティによる次の報告があります。サンプル内のチケットコメントではtechnicalに分類される想定でしたが、報告者が実際に測定したところbilling（0.67）が返り、100回繰り返しても結果は変わりませんでした。カスタマーサポートのチケットに支払いの失敗と連携エラーの両方が含まれる場合、3分類の境界はもともと曖昧です。それでも、公式サンプルが自身の記載どおりに動作しないことは、初心者の信頼に確かな打撃を与えます。

製品側が率直に明かした事例

公式の失敗例よりも価値があるのは、製品側が開示した欠点です。主張検証製品のAttestは2つの数値を公開しました。実際の検証24件中22件が0.95～0.99の間に収まったため、確信度フィールドを削除しました（「常に同じ値になる数値は情報ではない」）。また、根拠の順序を逆にすると判定の5.8%が変わります。スタートアップのアイデア評価ツールkillmyideaは、ユーザーのテストで3文字削るだけでスコアが大きく変動することが判明し、作者は「一貫性のある直感チェックにすぎず、神託ではない」と認めました。ゲーム分野では、ドッグファイトAIの作者が「かなり出来が悪い」と自己評価しています。トレード分野では、375回のシミュレーション取引で勝率41.1%という未加工のデータを投稿した人もいます。誰もが良いニュースばかりを報告するこのエコシステムでは、誇張のない数値は1つずつ記録しておく価値があります。

メタな警告もあります。著名な開発者のsteve8708は、X上で話題になったJevのデモに早送りされた内容と捏造された内容が混在していると公に指摘しました。私たちはこれへの対応を掲載基準に盛り込みました。「超人的な速さ」をうたうデモは、手法の全容と実行トレースが示されている場合にのみ掲載対象とします。

信頼すべきでないとき

本記事と前回の記事の教訓を合わせると、次のような注意点のチェックリストが得られます。

• 確信度が0.9以上でも正しいとは限りません。確信度の高い42%の行での正解率はわずか72.2%でした。
• 次元分割によって厳密さが高まるわけではありません。誤検知が重大な問題となる場面では、誤検知率が25倍に悪化します。
• 10を超える選択肢を一度に与えると、正解率はランダムなベースラインまで落ち込みます。
• 入力の順序や言い回しが変わると、判断もそれに応じて変動することがあります。
• コストのかからないベースライン（n-gram、ナイーブベイズ、ルール）を実行するまでは、正解率の数値を割り引いて見てください。
• 実際の分布に基づいて分割を設計しないと、テンプレートリークだけで正解率が見かけ上8ポイントも上がることがあります。

これに対応する自己防衛チェックリストは6項目です。直接クエリを優先する、選択肢を絞る、入力順序を固定する、まずベースラインを実行する、独立した評価セットを維持する、直接呼び出しを独立した判定者として扱う。決定プリミティブのスイートスポット（狭い問題×高頻度×限定的なアクション）は依然として有効ですが、そこを外れると実際に痛い目を見ることがあります。

本シリーズの次回の記事では、個別の事例から一歩進み、このエコシステムがすでに育んできたインフラレイヤーを検証します。判断レイヤーの入力として信頼できるコメント、評判、価格データが必要な場合は、統合データAPI連携ガイドから始めてください。