メールやチャットを、
手元のAIで3つに仕分ける。

確率：提示した選択肢に対するモデルの値です。「0.9」と出ても、現場で同じ判定が90%正しいと保証されたわけではありません。[2]

confidence：choiceとscoreで、どれかの選択肢をどの程度強く支持しているかを表します。これも正答率ではありません。[3]

score：「通常・本日中・即時」を0・1・2とすれば、値は 0×P(通常)＋1×P(本日中)＋2×P(即時) です。平均が1でも、「中間が有力」なのか「低・高に割れている」のかは異なります。重要な判断では分布も見られる表示にする、という設計が考えられます。後半はこの計算式から導く本記事の提案です。[3]

• 取消の後に別の依頼：「昨日の確認依頼は取り消します。代わりに、修正版を確認して返信してください。」→ 要対応を期待。
• 依頼の取消だけ：「本日の確認は不要になりました。先ほどの依頼への返信も不要です。」→ 共有のみを期待。
• 共有と依頼が混在：「更新は完了しました。営業チームは新しい案内文を確認してください。」→ 要対応（営業チーム向け）を期待。自分の担当かは別に確認。

「判断保留」は本記事で設計した選択肢です。曖昧な文が必ずそこへ入る保証はないため、この種類の例を評価に含めます。

以下は公式の呼び出し形式を使い、この記事の架空例に置き換えた未実行の実装例です。Ollama 0.40.9以降とモデルの準備が必要です。[2][3][4]

ollama run d3:2b "本日の更新作業は完了しました。追加の作業や返信は不要です。" --ask "この連絡を分類してください。追加対応が不要と明記された報告はinfoです。依頼があるものの、何について何を求めているか特定できない場合はholdです。" --choice "action=誰かに具体的な承認・返信・作業を求める依頼" --choice "info=追加の対応が不要な報告や共有" --choice "hold=依頼の対象物や作業内容が不明、文脈不足、または基準が競合"

モデルが未取得の場合、ollama runによってダウンロードが始まります。上の例は短い1件の動作確認用です。

{
  "model": "d3:2b",
  "state": {
    "body": "本日の更新作業は完了しました。追加の作業や返信は不要です。"
  },
  "questions": {
    "category": {
      "type": "choice",
      "instructions": "bodyの連絡を分類してください。追加対応が不要と明記された報告はinfoです。依頼があるものの、何について何を求めているか特定できない場合はholdです。",
      "criteria": {
        "action": "誰かに具体的な承認・返信・作業を求める依頼",
        "info": "追加の対応が不要な報告や共有",
        "hold": "依頼の対象物や作業内容が不明、文脈不足、または基準が競合"
      }
    },
    "approval_request": {
      "type": "noul",
      "instructions": "bodyに承認を求める依頼が明記されていますか。",
      "criteria": {
        "true": "承認を求める依頼が明記されている",
        "false": "承認を求める依頼が明記されていない"
      }
    }
  }
}

JSONをHTTP POSTの本文として送ります。選択肢はanswers.category.choice、各選択肢の確率はanswers.category.probabilities、承認依頼へのYesの確率はanswers.approval_request.noulから読みます。d3は理由の自由文や返信文を生成しません。

このHTMLの操作は例の表示切替・画像保存・コピーのみです。モデルや外部APIへの推論リクエストは送りません。

• 容量：ローカルのSystem One APIは、文章と質問スキーマが64 KiB以内、画像のbase64を含むリクエスト全体が32 MiB以内。さらに読み込んだコンテキスト長にも収める必要があります。[4]
• 複数質問：同じ入力への質問をまとめられますが、質問同士は回答を受け渡しません。開発元の説明では質問ごとに計算するため、質問を増やしても同じ時間とは限りません。[4][5]
• 処理場所：Ollamaはlocalhost経由でもクラウドモデルを呼べます。端末内で処理する設計ではローカルd3タグを使い、必要ならOLLAMA_NO_CLOUD=1でクラウド機能を無効にして再起動します。連絡取得アプリやログの保存先は別に確認します。[3][6]
• 待受：Ollamaの既定は127.0.0.1:11434です。複数PCへ提供する場合は、その外側の認証やアクセス制御も設計します。[6]

たとえば入力を「FAQ参照」「コード相談」「複雑な検討」「人に確認」に分類し、アプリ側の表で呼び出し先へ結び付ける設計です。ただし、質問の種類が分かることと、どのモデルなら十分な回答ができるかは別です。

行き先ごとの回答品質、費用、待ち時間を測り、同じ入力を直接処理した場合と比べます。外部送信の可否や利用権限は、文章の推定だけに任せず、既知の設定で先に制限する構成を提案します。

d3はvLLM Semantic Routerの判定モデルで、この記事はOllama上で動かす方法を扱っています。選択肢・確率を返す使い方には共通点がありますが、ローカルd3の利用にJevのAPIキーは必要ありません。「Jev Decision Index」は評価指標の名前です。APIや品質がそのまま置き換え可能かは、別途確かめる必要があります。[2][3]

OllamaとOllayaは名称が似ていますが、ここでの導入手順・仕様はOllamaのものです。

開発元のd3-nanoモデルカードには、AMD Instinct MI325X上の測定としてテキスト1件の中央値13.4 msなどが掲載されています。これは元チェックポイントと特定の実行環境の結果で、家庭用PCのOllamaで測った値ではありません。[5]

同様に、公式モデルページのJev Decision Indexは、元チェックポイントの評価です。Ollama向けに数値表現を変えた配布パッケージや、この記事の日本語業務連絡の正答率へは置き換えられません。[2]

本記事では、未検証の「何倍速い」「何%工数削減」を採用理由にしません。入力準備・待ち時間・訂正まで含む実測で比較する方針です。

高い確率でも誤るため、「0.9以上なら採用」のような値を最初から固定しません。調整用の例で、重要なクラスの確率・上位候補の差・入力不足を見て確認待ちに回す条件を作り、別の例で見逃しと確認量を評価します。入力上限・通信・モデル読込のエラーは、スコアと分けて扱います。

記録するものは、Ollamaの版、モデルタグと配布形式、PCとメモリ、質問・選択肢の版、入力本文と長さ、人の正解、各選択肢の値、処理時間、訂正結果です。モデルや基準を変更したら再評価します。

閾値による確認待ちへの振り分けはアプリ側の提案であり、d3が提供する正確な棄権保証ではありません。