--- title: 決定モデル解説：Jev、Clef、OpenAI description: >- 決定モデルの入門ガイド：何を返すのか、テキスト生成LLMとどう異なるのか、Jev、Clef、OpenAIのDecisions APIがどこに位置するのかを解説します。 date: 2026-10-13T00:00:00.000Z updatedDate: 2026-10-13T00:00:00.000Z location: サンフランシスコ（カリフォルニア州）– 2026年10月13日 image: /images/decision-models-explained-jev-clef-hero.jpg keywords: '決定モデル解説, Jev, Cloudflare Clef, OpenAI Decisions API, 決定モデルとLLMの比較' tags: - decision-models - ai-engineering faq: - question: 決定モデルは説明を書けますか？ answer: >- JevとClefの決定インターフェースは、新しい文章ではなく選択肢とスコアを返します。OpenAIのDecisions APIもあらかじめ定められた範囲の回答を返します。アプリケーション側で文章での説明が必要な場合は、テキスト生成モデルを使用してください。 - question: 決定モデルを試すにはトレーニングデータが必要ですか？ answer: >- 新しいモデルをトレーニングしなくても、質問と許可された回答を定義できます。ただし、精度を確認し、どの結果を自動的に使用できるかを判断するには、既知の結果を持つサンプルが必要です。 - question: 決定モデルは単独でアクションを実行できますか？ answer: >- 決定モデルは判断を返すだけです。それを使用するかどうかを判断し、権限を確認し、アクションを実行するのはアプリケーションの役割です。返金ラベルを選択しても、返金が承認されるわけではありません。 locale: ja-jp translationKey: decision-models-explained-jev-clef --- **決定モデル**とは、ソフトウェアが事前に定義した選択肢の中から適切なものを選ぶのを支援する仕組みである。メッセージ、質問、許可された選択肢を与えると、確率付きの判断を返す。テキスト生成型の大規模言語モデル（LLM）が新しい返信を生成できるのに対し、決定モデルはそのメッセージを最初にどこへ送るべきかを判断するのに役立つ。 TypeSafeのJev、CloudflareのClef、OpenAIのDecisions APIは、いずれもこの種の限定的な判断をサポートしている。アプリケーションはこれらを使って、サポートキューの選択、問題の特定、重大度の評価を行える。その後の文章作成は生成モデルに任せればよい。 ## 同じメッセージ、異なる2つの仕事 ある顧客が「同じ注文で2回請求されました」と書き込んだとする。サポートシステムには2つの仕事がある。チケットを適切なチームに振り分けることと、有用な返信を書くことだ。この2つには異なる出力が求められる。 生成LLMであれば「その請求を確認いたします」と書けるかもしれない。一方、決定モデルは「どのチームが対応すべきか？」という質問に対し、`billing` と回答する。`billing`、`technical`、`review` の中から選択された結果である。 アプリケーションはこの回答を直接参照できる。確信度が高ければチケットを請求チームにルーティングし、不確実であればレビューに回す、といった処理が可能になる。その後、人間や別のモデルが返信を書けばよい。決定モデルが担うのは、より大きなプロセスの中の一つの焦点を絞った判断である。[TypeSafeのSystem One入門](https://docs.typesafe.ai/concepts/system-one)がこの役割分担について説明している。 下の図は、同じルーティングの質問に対して両方のモデルを比較したものだ。テキストモデルはJSON形式の回答を生成し、決定モデルは許可された3つの選択肢にスコアを付ける。 ## 決定モデルには何を聞けるのか？ 決定インターフェースは一般的に3種類の質問をサポートする。選択肢の選択、真偽の推定、スコアの付与である。証拠の提示と回答の意味の定義は利用者側で行う。同じ顧客メッセージに対して、複数の独立した判断を行うこともできる。 | 質問の種類 | 例 | 返されるもの | | --- | --- | --- | | 1つの選択肢を選ぶ | 最初に対応すべきチームはどれか？ | 選択されたチームと各選択肢の確率 | | はい/いいえ | このメッセージは返金を求めているか？ | 「はい」である確率 | | スコアを付ける | 定義されたスケールでこの問題の重大度はどれくらいか？ | 指定したレベルに基づく評価 | TypeSafeはこれらを[Choice](https://docs.typesafe.ai/primitives/choice)、[Noul](https://docs.typesafe.ai/primitives/noul)、[Score](https://docs.typesafe.ai/primitives/score)と呼んでいる。OpenAIはchoice、predicate、scoreという用語を使う。predicateとははい/いいえの質問のことである。 質問の表現が重要になる。「最初に対応すべきチームはどれか？」は1つのチームを尋ねている。一方、「このメッセージは請求の問題に言及しているか？」と「このメッセージは技術的な問題に言及しているか？」は別の質問であり、両方が「はい」となりうる。チケットが2つの問題を記述している場合、1つのカテゴリに無理に押し込むと有用な情報が失われることがある。 ## LLMにJSONを要求する場合と何が違うのか？ LLMもJSON内にカテゴリを返すことができる。JSONはソフトウェアが読み取れるデータ形式である。[Structured Outputs](https://developers.openai.com/api/docs/guides/structured-outputs)を使えば、サポートされているスキーマによって回答を許可された値に制限できる。これにより、多くの分類タスクにおいてLLMは有効な代替手段となる。 違いは、専用の決定モデルが回答を生成する方法にある。従来のLLMはトークンと呼ばれる小さな単位を使ってテキストを逐次的に生成する。出力が単なる`{"team":"billing"}`であっても、それはテキスト生成であることに変わりはない。 CloudflareのClefはこれとは異なり、入力を読み取り、許可された回答に対してトークンごとに書き出すことなく直接スコアを付ける。Cloudflareはこのアプローチを[Clefの発表](https://blog.cloudflare.com/clef-decision-models/)で説明している。なお、Clefは入力を理解するための基盤として引き続きLLMを使用している。 OpenAIはDecisions APIの入力と出力を文書化しているが、Clefの内部設計を使用していることは立証していない。類似したインターフェースは同一のアーキテクチャを証明するわけではない。 どちらのアプローチも有効なカテゴリを返せるが、間違ったものを選ぶこともある。有効なカテゴリであっても、顧客の問題と一致していなければ意味がない。 ## Jev、Clef、OpenAIはそれぞれどこに位置するのか？ これらのプロダクトは、ソフトウェアが参照できる焦点を絞った判断を提供する。JevはTypeSafeの決定モデルである。ClefはCloudflareのダウンロード可能なモデルファミリーで、Workers AIを通じても利用できる。OpenAIは範囲が定まった質問のためのDecisions APIを提供している。どれを選ぶかは、実際のタスクでのテストが必要である。 | プロダクト | まず知っておくべきこと | | --- | --- | | **TypeSafe Jev** | テキストと構造化データに対する型付き質問を中心に構築されている。トレーニングは有用でキャリブレーションされた確率を目標としている。 | | **Cloudflare ClefおよびClef-flash** | ダウンロード可能な重みとホスティングサービスの両方で利用可能。公開されている設計では、言語モデルのバックボーンを使用して回答にスコアを付ける。 | | **OpenAI Decisions API** | 選択肢、はい/いいえの判断、スコアのためのホスティングインターフェース。現在、`gpt-6-luna`を使用したパブリックベータ段階。 | 出典：[TypeSafe](https://docs.typesafe.ai/concepts/system-one)、[Cloudflare](https://blog.cloudflare.com/clef-decision-models/)、[OpenAI](https://developers.openai.com/api/docs/guides/decisions)。 レスポンス形式やサポートされる入力はプロダクトごとに異なる。OpenAIは拒否（refusal）を返すこともあり、アプリケーション側でそれを処理する必要がある。プロバイダー間の移行には、インテグレーションとその回答の品質の両方を確認する必要がある。 ## 確率から何がわかるのか？ 確率は、設定した質問に対してモデルが推定した回答の確からしさを表す。最尤ラベルだけでは得られない情報をアプリケーションに提供してくれる。ただし、人間のレビューを省略できるケースを判断するために使う前に、数値の検証が必要である。 このチケットに対して以下のような結果が得られたとする： | 許容される回答 | 確率の例 | | --- | --- | | 請求 | 92% | | 技術 | 5% | | レビュー | 3% | 請求が明確な勝者である。では、請求とダッシュボードの故障の両方に関する複合的なメッセージの場合はどうなるか。請求が52%、技術が43%となるかもしれない。請求が依然として勝者ではあるが、接戦であることはアプリケーションにレビューを要求する理由を与える。 **キャリブレーション**とは、多くのサンプルにわたって確率が実際の結果と一致するかどうかを確認することである。90%前後の同様の予測の中で、適切にキャリブレーションされたモデルは約90%の割合で正しくあるべきだ。ただし、90%とマークされた1つの回答が間違っている可能性は常にある。 「confidence」というフィールドは、確率がどれだけ集中しているかを要約することがある。これは自動的に測定された成功率を意味するものではない。[TypeSafeのconfidenceガイド](https://docs.typesafe.ai/confidence)がこの違いを説明している。 ## 決定モデルはいつ有用か？ 決定モデルは、タスクが意味の解釈を必要とし、かつ可能な回答がすでに既知である場合に有用である。例としては、メッセージのルーティング、関連ドキュメントの選択、ルーブリックに基づく項目の評価などがある。文章作成や調査を担う生成モデルと併用することもできる。 テキスト生成を省略することで、モデルの負荷を減らせる場合がある。それが速度やコストの改善につながるかどうかは、ネットワーク遅延、入力サイズ、フォールバック呼び出しを含むアプリケーション全体に依存する。決定モデルを比較する際は、不必要に長い説明を求めるのではなく、同じ短い回答をLLMに求めた場合と比較すべきである。 制限もある。決定モデルはメッセージを読み誤ったり、間違った選択肢を選んだり、過度に確信を持ったりすることがある。独立した[Red Hatのガードレールテスト](https://developers.redhat.com/articles/2026/10/02/benchmarking-ai-decision-models-against-traditional-guardrails)では、Jevはあるタスクで最も強い結果を示したが、別のタスクでは代替モデルが上回った。これらのテストは3つのプロダクトすべてを比較したものではない。 正確な計算や権限チェックには通常のコードを使うべきである。タスクが新しい返信、コード、または説明を必要とする場合は生成モデルを使う。決定モデルを試すには、1つの小さな判断から始め、既知の回答を持つサンプルを収集し、節約できる作業量とあわせてミスを測定することをお勧めする。 ## よくある質問 #### 決定モデルは説明を書けますか？ JevとClefの決定インターフェースは、新しい文章ではなく選択肢とスコアを返します。OpenAIのDecisions APIもあらかじめ定められた範囲の回答を返します。アプリケーション側で文章での説明が必要な場合は、テキスト生成モデルを使用してください。 #### 決定モデルを試すにはトレーニングデータが必要ですか？ 新しいモデルをトレーニングしなくても、質問と許可された回答を定義できます。ただし、精度を確認し、どの結果を自動的に使用できるかを判断するには、既知の結果を持つサンプルが必要です。 #### 決定モデルは単独でアクションを実行できますか？ 決定モデルは判断を返すだけです。それを使用するかどうかを判断し、権限を確認し、アクションを実行するのはアプリケーションの役割です。返金ラベルを選択しても、返金が承認されるわけではありません。