判定専用AIが半月で3つ。記事の採否を1週間任せたら重複2件を止めた

📖 この記事で分かること

• Jev・Decisions API・Clef が相次いだ意味
• 本番の記事判定で1週間動かした実測
• キーワード照合との食い違い3件の中身
• 筆者が見る強みと死角

💡 知っておきたい用語

• 判定専用AI:文章を書かず、決めた質問ごとの確率や選択肢だけを返すAI。答案に丸を付ける採点係のようなもの

最終更新日: 2026年10月8日

▶ 公式ページ

• Decisions API ガイド(OpenAI Developers)
• Clef の発表(Cloudflare Blog)

文章を書かないAIが、判断の部品として出そろった

この記事のポイント

• tech-noisy.com は2026年10月1日から、記事の重複・守備範囲・守秘などの判定を TypeSafe AI の Jev(2026年10月時点)に任せている。
• 1週間で、キーワード照合が通した重複2件を止め、照合が保留にした別の話題1件を通した。
• 筆者は、判定専用AIは分岐の判断を担う部品として本物だと見る。ただし問われたことしか見ない。

分類や振り分けを生成AIに文章で答えさせている開発者にとって、その判断だけを切り出す選択肢が、この半月で現実のものになりました。9月の TypeSafe AI の Jev に続き、OpenAI は10月6日に Decisions API を全開発者向けの公開ベータにし、Cloudflare は10月1日に Clef を公開しました。どれも文章を書かず、問いごとの確率や選択肢を返す AI です。

Cloudflare は発表の中で、Jev への関心が「速く、小さく、用途を絞った分類モデル」の需要を示したと書いています。筆者も同じ流れを感じていて、その根拠は自分たちの運用にあります。このメディアは10月1日から、記事の採否の判定に Jev を使っているからです。製品の比較はOpenAI Decisions API と Jev の比較記事で扱ったので、ここでは本番で1週間動かして見えたことと、この流れをどう見るかを書きます。

なぜこの話題か

このメディアは、記事の題材選びから下書き、投稿前の検査までの多くを AI で自動化して運用しています。10月1日に、それまで「警告を出すだけ」だった判定を、判定専用AIの確率で決める仕組みに切り替えました。

判定専用AIの発表記事は書いてきましたが、使う側の手触りは発表資料からは分かりません。自分たちの記録が1週間分たまったので、数字つきで共有する価値があると考えました。経験の範囲は、1日3本前後の記事を書く1つのメディアの、10月1日〜8日の運用に限られます。

やってみて分かったこと

いちばん効いたのは、同じ発表を2本書いてしまう事故を、言葉の一致ではなく意味で止められたことでした。

何を任せたか

任せたのは、投稿前の判定です。既存の記事と同じ発表を扱っていないか(重複)、守備範囲の外の記事になっていないか、想定読者は誰か、顧客名や未公開情報に触れていないか、といった問いを1回の呼び出しでまとめて聞き、0〜1の確率を受け取ります。確率は設定ファイルの閾値で「自動で不採用・人が見る・自動で通す」の3つに振り分けます。重複なら0.8以上が不採用、0.2未満が自動で通る線です。

キーワード照合との食い違い3件

以前から使っていた判定は、製品名や出来事の種類を抜き出して照合する方式です。10月1日〜8日の題材チェックの記録を見ると、判定専用AIとこの方式の結論が食い違ったのは3件でした。

• 10月2日朝、「GPT-6.1 Sol」の発表を扱う候補。キーワード照合は「新しい話題」として通しましたが、判定専用AIは既存記事と同じ発表である確率を0.95と返し、不採用にしました。見出しの言い回しが違うだけで、同じ発表でした。
• 同じ日の午後、「Gemini 4 Argon」の候補。その日の朝に公開した記事と同じ発表で、確率は0.94。こちらも照合は通していました。
• 同じ日の午後、「OpenAI がAIエージェントの不正活動を100以上の組織に通知」の候補。キーワード照合は、OpenAI の別の安全対策の記事と近いとして保留にしましたが、判定専用AIの確率は0.11で、別の話題として通しました。

記録を後から見返すと、3件とも判定専用AIの結論のほうが実態に合っていました。件数は少ないので精度を語る材料にはなりませんが、どういう場面で差が出るかは分かりました。言葉の一致に頼る照合は、言い換えに弱く、同じ会社の別の話題を誤って近いと見ます。判定専用AIはその両方を拾いました。

速さと費用

10月2日〜8日に投稿された18本では、1回の判定にかかった時間は209〜555ミリ秒でした。投稿1本あたりの待ち時間として気になる長さではありません。

当サイトの費用の記録では、10月2日夜から8日午後までの呼び出しは74回、見積もりの合計は0.0037ドルです。文章を生成させて判定を読み取る構成では、この費用感にはなりません。判定のために汎用の大規模言語モデルを呼ぶ構成を残している場合、費用の面だけでも置き換えを検討する余地があります。

運用して気づいた落とし穴

うまくいった話だけではありません。1週間で3つの落とし穴に当たりました。

1つ目は、判定AIは渡したものしか読まないことです。本文を途中で切って渡していた時期は、記事の末尾にある編集部の見方や引用元が判定AIに届かず、品質の点が低く出ていました。上限を記事の最大長に合わせて解決しましたが、「判定が厳しい」と思った原因が、入力の切り方だったわけです。

2つ目は、判定AIは問わなかったことは判定しないことです。公開前の修正版(タイトルだけ直した稿)は判定AIを通さない設計にしていたところ、修正で主語が「Microsoft AI」から「Microsoft」へ広がったタイトルが、そのまま承認画面に上がりました。今は、修正稿の数値や名前が元の記事と指示にあるかを別の仕組みで照合しています。

3つ目は、判定AIに届かないときに黙って品質が落ちることです。届かなければ従来のキーワード照合へ切り替えて記事作成は止めない設計にしましたが、それだと「実は判定AIが使えていない」ことに誰も気づきません。最後に成功した時刻と連続失敗の回数を、運用画面に出すようにしました。

確率は道具で、判断の線は人が引く

この1週間で分かったのは、判定専用AIの価値は「賢く答えること」より、「同じ問いに、比べられる数字で答えること」にあるという点です。

確率で返ってくるから、閾値をどこに置くかを議論できます。重複の閾値を0.2と0.8に置いたのは、価格改定の続報が0.35、正式公開の続報が0.54と出た例を、自動で止めずに人へ回したかったからです。生成AIに「重複していますか」と文章で聞いていたら、この線は引けませんでした。

一方で、数字は入力に敏感です。この記事の題材を確認したとき、見出しを変えずに一次ソースの URL だけを変えると、既存記事との近さは0.60〜0.68の範囲で動きました。閾値ぎりぎりの値を絶対視せず、人へ回す幅を持たせておくのが現実的です。

編集部の見方

筆者は、分岐の判断に汎用の生成AIを使っている開発者は、判定専用AIへの切り出しを検討すべきだと考えます。ただし、閾値と問いの設計は手放さないことが条件です。

• 根拠1: 1週間で、言葉の照合が見逃した重複2件を止め、誤って保留にした1件を通しました。差が出たのは、言い換えと同じ会社の別の話題という、照合が苦手な場面でした。
• 根拠2: 1回あたり209〜555ミリ秒、74回で見積もり0.0037ドル(当サイトの記録)です。速さと費用は、判定を組み込む障壁になりませんでした。
• 根拠3: 確率で返るので、閾値を設定として管理し、変更の理由を残せます。判断の線を後から説明できることは、自動化を続けるうえで精度と同じくらい大事でした。

向くのは、問い合わせの振り分けや投稿の分類のように、件数が多く、判断の基準を言葉で書ける処理です。向かないのは、判断の基準そのものが決まっていない処理です。問いが書けないものは、判定専用AIにも答えられません。

この見方が変わる条件は2つあります。数か月の運用で、人が覆す判定の割合が従来の照合より高いと分かった場合と、判定AIの提供元の仕様変更で同じ問いへの確率が大きく動く場合です。後者に備えて、判定の記録には使ったモデルの版を残しています。

読者への提案

3社の製品がそろったいま、どれを選ぶかより先に、自分の処理の中に「確率で答えられる問い」がいくつあるかを数えてみることを勧めます。筆者たちの場合、重複・読者・守秘のように1文で書ける問いは判定AIによくなじみ、「良い記事か」のような広い問いは、観察できる小さな問いに分けるまで数字が安定しませんでした。

次に、今の判定と判定AIの答えを並べて記録し、食い違った件を人が見ることです。当サイトも題材チェックでは両方の結論を記録しており、上の3件はそこから見つけました。食い違いの中身が、その処理で判定AIを信じてよい範囲を教えてくれます。

最後に、判定AIが止まった日のことを先に決めておくことです。処理を止めるのか、従来の判定へ戻すのか。どちらを選ぶにしても、戻ったことに気づける形にしておかないと、上で書いたように品質だけが黙って下がります。

よくある質問

Q: 判定専用AIと、生成AIに「はい・いいえ」で答えさせるのは何が違いますか?

A: 判定専用AIは文章を書かず、問いごとの確率を返します。OpenAI は Decisions API について、Responses API より約10倍速く型の決まった答えを返すと説明しています。確率で返るため、閾値を決めて分岐させやすいのが運用上の違いです。

Q: 3社の判定専用AIの違いは何ですか?

A: 公表資料では、Clef は画像を受け付け、Jev と同じ形で呼べるとされています。Decisions API は対応モデルが gpt-6-luna(2026年10月時点)のみで、入力100万トークンあたり0.10ドル(2026年10月時点)、正式提供は「今後数週間」と OpenAI は説明しています。

Q: 1週間の数字で精度を判断してよいですか?

A: できません。食い違いは3件だけで、精度の評価には件数が足りません。この記事は、差が出る場面と運用上の落とし穴を共有するためのものです。

まとめ

判定専用AIが半月で3つ出そろうなか、記事の重複や守秘の判定を Jev に任せた1週間で、言葉の照合が見逃した重複2件を止め、誤って保留にした1件を通しました。速さと費用は障壁になりませんでした。一方で、判定AIは渡したものと問われたことしか見ません。問いの切り方、閾値、届かないときの縮退を人が設計して初めて、確率は判断の道具になると考えています。

【用語解説】

• 閾値【いきち】: 確率がこの値を超えたら別の扱いにする、という境目の値
• 縮退: 本来の仕組みが使えないとき、より単純な仕組みに切り替えて動き続けること
• 影で動かす(シャドー運用): 本番の判断には使わず、新しい仕組みの答えを記録だけして、今の仕組みと比べる運用

引用元:

• [1] Decisions API ガイド(OpenAI Developers)
• [2] Clef decision models(Cloudflare Blog)

この記事について: AI 支援で執筆、編集部が事実確認・編集しています。誤りや追加情報があれば Contact よりお知らせください。