HOME/ビジネス/AIエージェント関連サービス/Microsoft-Decision-1

Microsoft-Decision-1
判断スコアリングモデルとEnterprise Decision OS

Microsoft-Decision-1の意味、LLMとの違い、仕組み、公表ベンチマークの読み方、活用シーン、導入準備、留意点までを整理します。
企業固有の判断基準の整備と本番設計は、フォワードデプロイ(現場実装)で支援します。

01/概要

Microsoft-Decision-1とは:選択肢に確率スコアを返す、判断専用のAIモデル

Microsoft-Decision-1は、Microsoftが提供する判断スコアリングモデルです。文章を生成する大規模言語モデル(LLM)とは異なり、あらかじめ決めた選択肢に対して確率スコアを返します。ルーティング、分類、優先順位付け、検証、ワークフロー制御など、ソフトウェアがそのまま使える構造化された判断を、高速かつ低コストに実行します。

Microsoft Foundryのモデルカタログとオープンな推論サービスOpenRouterから利用できます。Yes/No、複数選択肢、段階評価に対応し、AIの回答やエージェントの行動をルーブリックで採点する用途にも使えます。以下は、Microsoftが公開している一次情報です。

Microsoft-Decision-1の要点
名称 Microsoft-Decision-1(判断スコアリングモデル)
提供元 Microsoft(Office of the CTO)
入力と出力 state(テキストまたはJSON)と型付きの質問を入力し、選択肢ごとの確率スコアを出力
対応する判断 Yes/No、複数選択肢、段階評価、ルーブリックによる採点
提供形態 Microsoft Foundryのモデルカタログ、OpenRouter
価格 入力100万トークンあたり0.042米ドル、出力トークンは無料

02/注目される背景

AIエージェントの判断のボトルネック:実行できるAIと、判断を担う人

生成AIやAIエージェントの進化で、文章作成、情報検索、データ分析、システム操作といった多くのタスクをAIが実行できるようになりました。一方、実際の業務では、実行の前後に必ず「判断」が挟まります。判断を人が毎回確認する構造のままエージェントの利用が増えると、人による承認や監督が新たなボトルネックになります。MicrosoftはMicrosoft-Decision-1を、この判断を低コスト・低遅延で担う「判断モデル」という新しいカテゴリのモデルとして位置付けています。

AIの実行の前後に存在する判断の例
→ 入力された依頼を、どの業務へ振り分けるか
→ どのAIモデル、AIエージェント、ツールを使うか
→ 検索した情報を、回答の根拠として採用できるか
→ AIの生成結果が、品質基準を満たしているか
→ 処理を、継続・再実行・停止のどれにするか
→ 自動実行してよいか、人へ確認を求めるか
→ 実行結果を、正常・異常・要確認のどれに分類するか
人が毎回判断する運用
  • エージェントの数と処理量に比例して、確認の件数が増える
  • 担当者の経験によって、判断の基準が揺れる
  • 承認待ちで、処理全体の速度が決まる
  • 判断の理由と履歴が、業務データとして残りにくい
判断の種類とリスクで使い分ける運用
  • 低リスクで高頻度の判断は、判断モデルが実行する
  • 確信度が低い判断は、再評価か人の確認へ回す
  • 高リスクの判断は、責任者が最終判断する
  • スコアと修正履歴を記録し、基準の改善に使う

03/他の手段との違い

判断モデルとLLM・推論モデル・ルールの違いと使い分け

判断モデルは、LLMの代わりではなく、役割が異なる部品です。Microsoft Learnも、文章の作成・要約・書き換え・説明が必要な場面はLLMを使い、判断モデルでルーティングや関門を担ってから生成モデルに渡す組み合わせを案内しています。

生成LLM

得意なこと:文章の生成、要約、書き換え、説明、対話

判断での位置付け:判断の理由を説明する場面や、判断後の文章作成を担います。判断1件ごとの遅延と費用は、判断モデルより大きくなります。

推論モデル

得意なこと:複雑な分析、計画、多段階の問題解決

判断での位置付け:判断の前提となる分析や計画を担います。定義済みの選択肢を大量に評価する用途では、過剰になります。

Structured Output付きLLM

得意なこと:指定した形式(JSONなど)での出力

判断での位置付け:出力の形式は揃いますが、選択肢ごとの確率を判断の根拠として使う設計には、別途の工夫が必要です。

ルール・プログラム

得意なこと:確定的な条件での計算、制約、安全制御

判断での位置付け:条件が明確な判断は、ルールで処理します。曖昧な入力の分類や優先順位付けは、判断モデルが補います。

人(Human in the Loop)

得意なこと:重大・不可逆・前例のない判断

判断での位置付け:高リスクの最終判断と例外対応を担います。判断モデルは、人に回す対象を絞り込む役割です。

判断モデル

得意なこと:定義済みの選択肢に対する、確率スコアの高速・低コストな算出

判断での位置付け:ルーティング、分類、優先順位付け、検証、ワークフロー制御を担い、結果を次の処理へ直接接続します。

04/仕組み

状態と質問を渡して、確率スコアを受け取る:3種類の質問タイプ

アプリケーションは、判断の材料となる「state(テキストまたはJSON)」と、型の決まった質問を送ります。モデルは文章ではなく、型に沿った数値の判断を返します。説明文(理由)は返さないため、確率を閾値にして、自動実行・再評価・人への確認を切り替えます。Microsoftは、Qwen3.5-9Bをベースに、単一パスの判断スコアリング向けに追加学習したモデルと説明しています。

noul

「これは真か」を問う

Yes/Noの条件に対して、0から1の確率を返します。

例:ツール呼び出しが本番データに触れるか、返信が返金を約束していないか、文書にプロンプトインジェクションが含まれるか。

choice

「どの選択肢か」を問う

固定の選択肢から1つを選び、すべての選択肢の確率を返します。

例:問い合わせを請求・技術・サポートのどの担当へ回すか、意図の分類、モデルやツールの選択。

score

「どの程度か」を問う

順序のある尺度(例:軽微・小・大・重大)に置き、各段階の確率を返します。

例:インシデントの重大度、キューの優先順位、AI回答の品質採点。

リクエストの例(問い合わせのルーティング)
{
  "model": "<deployment-name>",
  "state": "The API returns 500 on every call.",
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Which team should handle this ticket?",
      "criteria": {
        "billing": "Charges, invoices, and refunds",
        "engineering": "Bugs, errors, and outages",
        "support": "How-to and account questions"
      }
    }
  }
}
出典:Microsoft Learnのサンプルを要約
返ってくるもの
選択された選択肢と、すべての選択肢の確率(choice)
0から1の確率(noul)
順序尺度での値と、各段階の確率(score)
デプロイ名・モデル名・トークン使用量。説明文(理由)は返りません

05/設計の観点

速度・汎化・頑健性・キャリブレーション・安全性:判断モデルに求められる5つの品質

Microsoftは、信頼できる判断モデルを作るうえでの課題を5つに整理しています。判断モデルを選ぶときの評価軸としても使えます。

品質 1

速度

判断は1つ前の判断に依存して連なるため、遅延が積み上がります。100ミリ秒の遅れが20回の連続判断で2秒になる、とMicrosoftは例示しています。

品質 2

未知のタスクへの汎化

特定のベンチマークへの過学習を避けるため、学習から隔離した多数のベンチマーク(ルーティング、ランキング、長文、多言語、推論、安全性)で評価しています。

品質 3

頑健性

言い換え、選択肢の並べ替え、書式の揺れがあっても、同じ判断になることが求められます。Microsoftは8種類の摂動で、判断が変わる割合の平均が1.3%と公表しています。

品質 4

確率のキャリブレーション

確率はAPIの出力そのものです。90%と出た判断が、代表的なケースで約9割当たることが、実行・保留・確認を切り替える前提になります。

品質 5

安全性

有害な依頼を見分けつつ、無害な依頼を不必要に止めないことが求められます。11のベンチマークの5,250件の依頼で評価したと公表されています。

06/成果の読み方

公表ベンチマーク・価格・Microsoft社内テストの読み方

以下はMicrosoftが公表したベンチマーク、価格、社内テストの結果です。貴社の業務での精度・速度・費用は、データ、判断の定義、選択肢の設計、接続構成、利用リージョンによって変わるため、個別の技術検証で確認します。

精度(Microsoft公表) 36ベンチマーク・約15万問で最高精度 学習から隔離したベンチマークでの比較です。ルーティング、ランキング、長文、多言語、推論、安全性などが含まれます。 Microsoftによる比較であり、日本語や企業固有データでの精度は別途検証が必要です。
速度(Microsoft公表) 次点モデルの2.5倍、GPT-6 Solの約35倍高速 測定したモデルの中で最も高速だったと公表されています。中央値(P50)の遅延での比較です。 利用リージョン、デプロイの種類、入力の長さによって変わります。
価格(Microsoft公表) 入力100万トークンあたり0.042米ドル、出力は無料 判断の出力は短い数値であるため、費用は主に入力の長さで決まります。 ワークフロー全体の費用は、判断の回数と再評価の設計で変わります。
頑健性(Microsoft公表) 判断の変動1.3%(摂動の平均) 選択肢の説明の言い換え、並べ替えでは、判断の変動が0件だったと公表されています。 Learnでは、質問や選択肢の言い回しで結果が変わることがあると注意されています。
Microsoft社内での試験運用
Xbox Research 1万件を超えるアンケート・レビュー・SNSの自由記述を、研究者が決めたテーマに分類。品質はGPT-6 Solと同程度で、14倍超高速、200分の1の費用だったと報告されています。
Copilotチーム チャットとエージェントの応答品質の測定で、GPT5.6 Lunaと同程度の品質、100倍の速度だったと報告されています。
オンコールエンジニア ライブインシデントでの知識検索で、LLMより良好かつ高速だったと報告されています。
Microsoft Discovery 実験の評価と再計画(ルーブリックによる採点)で、LLMベースのスコアより46倍の一貫性、3倍の速度。適応的な再計画全体で約4倍の速度だったと報告されています。

07/活用シーン

ルーティング・分類・優先順位付け・AI Judge・エージェント制御の活用シーン

Microsoftが挙げる活用例を、判断の種類ごとに整理しました。いずれも「選択肢が決まっていて、件数が多く、速く判断したい」業務に当てはまります。

ルーティング

モデル・エージェント・担当の振り分け

依頼の内容に応じて、品質・費用・遅延の要件に合うモデルを選びます。問い合わせを適切な担当部署やエージェントへ振り分けます。

分類

入力・出力・インシデントの分類

意図の識別、フィードバックやSNS投稿のラベル付け、インシデントの種類と緊急度の分類を、一貫した基準で行います。

優先順位付け

案件・候補・検索結果の順位付け

複数の候補や対応案件を評価して処理順を決めます。検索結果の関連度や、レコメンドの候補選択にも使えます。

検証・AI Judge

AI回答・エージェント行動の採点

AIの回答を品質基準に照らして、採用・修正・却下に振り分けます。データ入力の妥当性確認や、コード・方針違反の検出にも使えます。

ワークフロー制御

継続・停止・再試行・引き渡しの選択

エージェントが提案した次の行動を評価し、続行、停止、再試行、別のモデル・ツール・人への引き渡しを選びます。

安全・セキュリティ

リクエスト・出力・行動のリスク分類

リスクに応じて、許可・ブロック・エスカレーションを判断します。有害コンテンツの分類やフィルタリングにも使えます。

コンピューター操作

画面とタスクに基づく次の操作の選択

現在の画面とタスクをもとに、選択肢から次のインターフェース操作を選びます。Microsoftは、購入タスクの完了速度の比較を公開しています。

ロボティクス

観測と制約に基づく動作の選択

観測、タスクの目標、動作上の制約から、あらかじめ定めたロボット動作の中から選びます。安全制御は多層構成で別に設計します。

科学的発見

仮説・化合物・実験の絞り込み

定義した基準に対して候補をスクリーニングし、さらに評価する順に優先付けします。

08/判断の種類

エージェント業務の判断を、選択肢と質問タイプに置き換える

業務の判断は、「何を選ぶか」を決めると、判断モデルに渡せる形になります。エージェントの処理で発生する代表的な判断を、選択肢と質問タイプの例で示します。

入力された依頼を、どの業務へ振り分けるか 経理、総務、情報システム、営業事務、その他 choice
検索した情報を、回答の根拠として採用できるか 採用できる/採用できない(基準:出典の信頼性、期間、対象範囲) noul
生成結果が、品質基準を満たしているか 段階1(不可)から段階4(良好)。基準を満たさない場合は再生成 score
処理を、継続・再実行・停止のどれにするか 継続、再検索、再生成、追加質問、停止 choice
自動実行してよいか、人へ確認を求めるか 自動実行、別モデルで再評価、人へ確認(取り消せない処理は人へ) choice
実行結果を、正常・異常・要確認のどれに分類するか 正常、異常、要確認 choice
複数の対応案件の、処理順はどうするか 緊急度と影響範囲を段階評価し、スコアの高い順に処理 score

09/判断の階層

確率スコアとリスクで切り替える:自動判断・再評価・Human in the Loop

Human in the Loopを一律になくすのではなく、判断の種類とリスクに応じて、AI、ルール、専門モデル、人を使い分けます。モデルが返す確率スコアに、業務リスク、影響範囲、処理の可逆性、権限、監査要件を組み合わせて、処理の行き先を切り替えます。

階層 1 低リスクで反復的、取り消しが容易 判断モデルが自動で判断し、そのまま次の処理を実行します。判断ログとスコアを記録します。
階層 2 複雑な分析・計画を伴う 推論モデルや専門AIへ接続し、結果を判断モデルで評価します。
階層 3 確定的な条件で決まる ルールやプログラムで処理します。計算、制約、安全制御はモデルに任せません。
階層 4 確率スコアが閾値に届かない 別モデルによる再評価、または人への確認に切り替えます。「判断できない」を選択肢に含めます。
階層 5 高リスクまたは不可逆 責任者や専門人材が最終判断します。判断モデルは、材料の整理と優先付けにとどめます。

10/利用の準備

Microsoft Foundryでのデプロイ・認証・API接続の流れ

Foundryのモデルカタログからデプロイし、リソースのエンドポイントにリクエストを送ります。認証はMicrosoft Entra IDが推奨で、APIキーも使えます。

STEP 1

前提の準備

Azureサブスクリプション、Foundryプロジェクト、モデルのデプロイ権限(Cognitive Services Contributorなど)を確認します。

STEP 2

モデルのデプロイ

FoundryのモデルカタログでMicrosoft-Decision-1を選んでデプロイします。Azure CLIでも作成できます。

STEP 3

認証の設定

Microsoft Entra IDを推奨します。APIキーも使えます。

STEP 4

APIの呼び出し

リソースのエンドポイントの /providers/microsoft/v1/systemone に、stateと質問を送ります。

STEP 5

評価としきい値の決定

自社の判断のラベル付きデータで精度を測り、自動実行・再評価・確認の閾値を決めます。

デプロイの種類 GlobalStandardと、対象リージョンのDataZoneStandardがあります。DataZoneStandardは推論処理を指定のデータゾーン内にとどめ、遅延の短縮につながる場合があります。実際の遅延は、業務の条件で測定します。
リージョン 遅延を抑えるには、アプリケーションに近いリージョンにFoundryリソースを作成します。GlobalStandardは世界のどのリージョンでも処理されうるため、遅延が大きく、またはばらつくことがあります。

11/留意点

公平性・表現への感度・信頼性・有害コンテンツ:既知の限界と利用上のベストプラクティス

Microsoft Learnには、既知の限界と、利用前に行う評価の考え方が示されています。

公平性

ベースモデルと学習データの偏りを反映することがあります。個人に関する判断では、スコアだけを根拠にしないでください。

表現への感度

質問や選択肢の言い回しと並び順で、スコアが変わることがあります。不適切な質問でも、スコアは返ります。

信頼性

キャリブレーションは、なじみのあるタスクで最も強くなります。説明は返らず、古い知識に基づく場合があります。

有害コンテンツ

安全フィルタとして使う場合、微妙な有害表現を見逃したり、無害な内容を有害と判定したりすることがあります。

利用前に行う評価
  • 自社の用途を代表するデータで、利用前に検証する。
  • state、instructions、選択肢を調整し、ラベル付きデータで候補の設定を比較する。
  • 誤検知と見逃しのコストに応じて閾値を決め、「判断できない」などの保留の選択肢を含める。
  • 中立的で明確な言葉を使い、選択肢の並び順を入れ替えて結果が変わらないか確認する。
  • 与信、雇用、住居、医療、法務など、人に関する重大な判断は、人による確認を前提にした判断支援にとどめる。
  • AIが判断に関与していることを、影響を受ける利用者に伝える。

12/用語集

判断モデル(Decision model) 選択肢に対する確率スコアなど、ソフトウェアがそのまま使える構造化された判断を返すことに特化したモデル。
判断スコアリング 固定された選択肢のそれぞれに、確率や段階のスコアを付けること。
LLM(大規模言語モデル) 文章の生成、要約、対話などを得意とする、大規模なAIモデル。
ルーティング 依頼や処理を、適切なモデル、エージェント、担当部署へ振り分けること。
AI Judge AIの回答や行動を、品質基準に照らして採点・評価する仕組み。
ルーブリック 評価の観点と段階を定めた採点基準。
キャリブレーション モデルが出す確率が、実際の正答率と合っていること。90%の判断が約9割当たる状態。
閾値(しきい値) 確率スコアに対し、自動実行・再評価・人への確認を切り替える境目。
Human in the Loop(HITL) AIの処理の途中に、人による確認や承認を組み込む設計。
Agentic Work Flow 複数のAIエージェントが連携して、業務を自律的に実行するワークフロー。
マルチモデル型Agentic AI 生成、推論、検索、認識、判断、実行を、用途別のモデルで分担するエージェントの構成。
オントロジー 業務上の役割・対象・条件・関係などを整理した、AIが参照できる概念の地図。
SDI(SyncLect Data Intelligence) 会話や会議から判断理由や例外対応を抽出し、AIが使える構造化データへ変換する当社のプラットフォーム。
Microsoft Foundry Microsoftが提供する、AIアプリケーションとエージェントの構築・デプロイ・管理の基盤。
Microsoft Entra ID Microsoftの認証・アクセス制御サービス。
Evals(評価) モデルやエージェントの品質を、基準データに照らして測る評価の仕組み。

13/企業実装の論点

モデルの導入だけでは動かない:判断基準・閾値・ログ・評価の設計

判断モデルを企業の業務に適用するには、何を判断するか、どの選択肢から選ぶか、何を優先するか、どの状態を例外とするか、どの水準で人へ引き渡すかという、企業固有の判断コンテキストが必要です。モデルは判断を実行しますが、判断の基準そのものは、企業の側で定義して整備します。

論点 1

判断の定義

何を判断するか、どの選択肢から選ぶか、何を優先するかを、業務の言葉で定義します。選択肢の説明の書き方で、出力が変わります。

論点 2

判断基準の整備

優先順位、例外条件、前提条件、リスク許容度を、AIが参照できるデータにします。暗黙知を含む基準は、ヒアリングから構造化します。

論点 3

閾値と品質ゲート

確率スコアと実際の正答率の関係を測り、自動実行・再評価・人への確認を切り替える水準を決めます。

論点 4

モデルの使い分け

判断、生成、推論、検索、ルールの役割を分け、ワークフローの各工程にモデルを配置します。

論点 5

ログと評価

判断ログ、確率スコア、人による修正履歴を保存し、更新時の回帰テストとEvalsで品質を確認します。

論点 6

認証・データ接続

Microsoft Entra IDによる認証とアクセス制御、Fabricや企業データとの接続を、運用の統制と合わせて設計します。

14/目指す姿

Enterprise Decision OS:判断基準を構造化し、判断・実行・評価・改善を回す企業基盤

Enterprise Decision OSは、企業内に存在する判断基準、優先順位、例外条件、権限、リスク許容度をデータとして構造化し、業務の状況に応じて最適なAIモデル、人、システムを選びながら、判断・実行・評価・改善を続ける企業基盤です。Microsoft-Decision-1は、この基盤で「すべてを考えるAI」ではなく、定義済みの選択肢を高速に評価して次の処理へ接続する判断レイヤーとして位置付けます。

用途別のモデル分担(マルチモデル型Agentic AI)
文章生成、説明、対話 生成AI・LLM
複雑な分析、計画 推論モデル
画像、音声、センサーデータの認識 マルチモーダルモデル・認識AI
企業情報の検索、根拠取得 RAG・Agentic RAG
分類、評価、行動選択 Microsoft-Decision-1
軽量な現場処理 SLM・エッジAI
確定的な計算、制約、安全制御 プログラム・ルール
重大または不可逆な判断 専門人材によるHuman in the Loop

人の役割は、大量の個別判断を繰り返すことから、判断基準・権限・リスク許容度・例外条件を設計し、AIの判断を監督することへ移ります。実行結果と人の修正履歴は、判断基準の改善に還元します。

15/当社の支援内容

判断のAI化の技術検証から、Foundry上の実装・統制までの5つのテーマ

当社は、Microsoft-Decision-1を単体のモデルとしてではなく、生成モデル、推論モデル、RAG、ルール、人を含むワークフロー全体の中に配置し、精度・速度・コスト・セキュリティ・監査可能性を設計します。

テーマ 1

人が担ってきた業務判断のAI化

エージェントの入力、処理結果、次の行動候補に対して、判断モデルが次の判断を実行できるかを検証します。

  • 回答や成果物を採用できるか、社内規定や品質基準を満たすか
  • 再検索・再生成・追加質問の要否、自動実行を続けるか
  • 確率スコアにリスク・影響範囲・可逆性・権限・監査要件を組み合わせた切り替え
テーマ 2

Agentic Work Flowのマルチモデル化

すべてを単一の高性能LLMに任せず、処理内容と実行環境に応じてモデルや技術を使い分けます。

  • 正答率・完結率に加え、速度・費用・処理可能量を最適化
  • データ管理、セキュリティ、監査可能性を含めた全体設計
テーマ 3

SyncLect Data Intelligenceによる判断基準の整備

業務会話・ヒアリング・会議に存在する判断理由や例外対応を抽出し、オントロジーや構造化データへ変換します。

  • 判断に必要な条件、選択肢、評価尺度の定義
  • 通常処理・例外処理・人による確認の振り分け
  • 正式な業務ルール、一時的な意見、検討中情報の分類
  • 実行結果と人の修正内容の還元
テーマ 4

Microsoft Foundryを中核とした企業実装

デプロイ、認証、API接続、ログ、評価、モデルルーティング、データ接続、ライフサイクル管理を、運用と統制の観点で設計します。

  • Microsoft Entra IDを前提とした認証・アクセス制御
  • Microsoft Fabricや企業データとの連携
  • 判断ログ・確率スコア・修正履歴の保存、更新時の回帰テストとEvals
テーマ 5

エッジAI・フィジカルAIへの適用

画像認識、音声、センサー、エッジAIが取得した状態情報に対し、クラウド側で次の行動候補を評価する構成を検討します。

  • 正常・異常・要確認の判定、作業の継続・停止・再計画
  • クラウド処理・エッジ処理・人への通知の振り分け
  • 安全停止などの重要制御は、安全機構・制御プログラム・人の監督を含む多層構成

16/特長

判断基準のAI Ready化・Agentic Work Flowの実績・Foundry実装・フィジカル展開

特長 1

人の判断基準を、AI Readyにできる

SyncLect Data Intelligenceが、判断基準・判断理由・優先順位・例外対応・前提条件を会話から抽出し、AIが活用できるオントロジーや構造化データに変換します。インタビューを行うエージェントと、業務プロセスのオントロジーを抽出するエージェントを備えています。

SyncLect Data Intelligenceを見る
特長 2

Agentic Work Flowを、実業務で設計・評価・改善してきた

複数のAIエージェント、RAG、固定定義ロジック、評価プロセス、Human in the Loopを組み合わせ、約3万件のタスク実行と回答に対する評価(RAG評価ツール、自動集計・正誤判定ツール、人による目視評価の三段構え)で、正答率99%を達成しています。

正答率99%のリリースを見る
特長 3

Microsoft Foundryを中核に、実装・統制できる

Foundry、Fabric、Microsoft 365 Copilot、Copilot Studioなどの基盤と、企業固有の業務データを接続するエンタープライズAIを推進しています。AgentOpsラボなど、評価と運用の支援メニューも備えています。

Microsoft Foundryのページを見る
特長 4

デジタル業務から、エッジAI・ロボティクスまで

AI・IoT・ロボティクスに対応するマルチAIプラットフォーム「SyncLect」で、画像AI、音声AI、自然言語処理、エッジデバイスを組み合わせたシステムを開発してきました。エッジAIは1,000台以上の稼働実績があります。

エッジAI開発のページを見る

17/業界ユースケース

金融・製造・モビリティ・流通・エネルギー・インフラ・公共の判断業務

大量の業務判断や現場判断が発生する業界が、主な対象です。

金融

事務センター・コンタクトセンター

問い合わせの振り分け、手続きの要否判定、回答の品質確認など、規程に基づく大量の判断を分類・採点します。

製造

品質対応・設備保守

検査結果の正常・異常・要確認の判定、保全作業の優先順位、現場報告の分類を行います。

モビリティ

運行判断・異常時対応

運行状況やアラートを分類し、対応の優先度を評価して、担当や手順へ振り分けます。

流通

問い合わせ・商品データ

顧客の意図の識別、レビューの分類、商品情報の確認、対応の優先順位付けを行います。

エネルギー・インフラ

点検・監視

センサーと画像の状態情報をもとに、点検・保守の優先度と、現場へ回す対象を評価します。

公共

申請・問い合わせの一次振り分け

申請の種類と担当課の振り分け、要確認案件の抽出を行います。人に関する決定は、人が行います。

IT運用

インシデント対応

インシデントを種類と緊急度で分類し、適切なチームやワークフローへルーティングします。

適合しやすい顧客
  • 判断の件数が多く、選択肢が定義できる業務がある
  • 判断の基準が、規程・マニュアル・ベテランの経験として存在する
  • Microsoft Foundry・Azure・Microsoft 365を利用している
  • 判断の履歴を残し、基準を継続して改善する体制を作れる
適合しにくいケース
  • 判断の選択肢が定義できず、毎回内容が異なる
  • 判断の件数が少なく、人が判断しても負担が小さい
  • 個人に関する重大な決定を、モデルだけで行いたい
  • ミリ秒単位の制御や、安全停止をモデル単体に任せたい
最初に確認したいこと(Discovery質問)
AIエージェントの処理の中で、人が毎回確認している判断は何ですか。月に何件ありますか。
その判断の選択肢と、判断の基準は、文書や規程になっていますか。それとも担当者の経験ですか。
誤った判断が起きたとき、影響の範囲と、取り消しの可否はどうなりますか。
どの水準の確信度なら自動実行し、どこから人に回しますか。
Microsoft Foundry、Entra ID、Fabricは、すでに利用していますか。
判断の結果と人の修正を、記録し、評価する体制はありますか。

18/想定ROI

判断1件あたりの費用と人手の判断工数:月間判断件数別の試算

判断モデルの費用は入力トークンに対する従量課金で、出力トークンは無料です。判断の件数が多い業務ほど、モデル費用が小さく、人手の判断工数が大きくなります。現行の判断工数は業務ごとに異なるため、技術検証で実測します。

月間の判断件数入力トークンモデル費用(目安)人手の判断工数(目安)
10万件1億トークン約4.2米ドル約833時間
100万件10億トークン約42米ドル約8,333時間
1,000万件100億トークン約420米ドル約83,333時間
試算の前提:判断1件あたり入力1,000トークン、入力100万トークンあたり0.042米ドル(Microsoft公表価格)、人手の判断は1件30秒。

実際の効果は、判断の定義、スコアの閾値、人へ回す割合、再評価の回数で決まります。当社は、技術検証で現行の判断工数と精度を測り、ワークフロー全体の費用(TCO)まで含めて判断できる状態にします。

19/ガバナンス

Entra ID・判断ログ・回帰テスト・安全機構:AIの判断を統制する運用設計

統制 1

認証とアクセス制御

Microsoft Entra IDを前提に、判断モデルとデータへのアクセスを制御します。デプロイ権限と呼び出し権限を分けます。

統制 2

判断ログの保存

入力、スコア、選択結果、人による修正履歴を保存し、判断の根拠を後から確認できるようにします。

統制 3

品質ゲートと閾値

スコアの閾値と、再評価・人への確認の条件を、リスクの大きさに応じて決め、定期的に見直します。

統制 4

回帰テストと評価

モデルや判断の定義を更新するときに、ラベル付きデータで回帰テストとEvalsを実施します。

統制 5

人の最終判断

高リスク・不可逆の判断と、個人に関する重大な決定は、責任者が最終判断します。AIの関与は利用者に伝えます。

統制 6

安全機構との分離

安全停止や設備の重要制御は、モデルに任せず、安全機構・制御プログラム・ルール・人の監督を含む多層構成にします。

20/はじめ方

スタートプラン:判断を1つ選び、HWS Agent Campで試作し、技術検証へ進む

最初は、件数が多く、選択肢が明確で、誤りの影響が小さい判断を1つ選びます。短期間で動くものを確認したい場合は、2日間のHWS Agent Campで試作できます。

STEP 1

判断の棚卸し

エージェント業務の中の判断を洗い出し、件数・リスク・選択肢の明確さで対象を選びます。

STEP 2

判断基準の定義

対象の判断について、選択肢、評価尺度、例外条件、人へ回す条件を定義します。

STEP 3

試作と精度の測定

Foundry上で試作し、日本語と自社データでの精度、速度、費用を測ります。

STEP 4

閾値と運用の設計

スコアと正答率の関係から閾値を決め、ログ・評価・権限の運用を設計します。

STEP 5

本番展開と改善

対象の判断を広げ、修正履歴を判断基準の改善へ還元します。

21/当社について

Microsoft AI Innovation Partner of the Year 2024と、Azure AI・Agentic DevOpsのSpecialization

Microsoft Azure の AI Platform/Agentic DevOps Specialization取得

Microsoft Azure の AI Platform/Agentic DevOps Specialization取得

ヘッドウォータースは「Microsoft Solutions Partner for Digital & App Innovation(Azure)」の認定に加え、上位資格である「AI Platform on Microsoft Azure」「Agentic DevOps with Microsoft Azure and GitHub」の2領域のSpecializationを取得しています。厳格な技術要件と導入実績を満たしたパートナーのみに付与される称号で、2領域の同時取得は国内でも限られています。

Microsoft AI Innovation Partner of the Year 2024 受賞

Microsoft AI Innovation Partner of the Year 2024 受賞

「AI イノベーション パートナー オブ ザ イヤー アワード」は、マイクロソフト製品の活用によってAI分野で革新を起こしたパートナーに贈られるアワードとして2024年に新設され、ヘッドウォータースは同分野において最も優れた実績をあげたとの評価を受け、初代受賞パートナーとなりました。

大和証券様のAIオペレーター、JR西日本様の「Copilot for 駅員」、日本航空様のSLM活用など、エンタープライズ企業向けのAIエージェント開発を手がけています。事例はMicrosoft Foundryのページで紹介しています。

22/関連ソリューション

SyncLect Data Intelligence

暗黙知を、 判断基準のデータに。

SyncLect Data Intelligence. インタビューや業務会話から、判断理由・優先順位・例外対応を抽出し、AIが参照できるオントロジーへ変換します。

Agentic Work Flow

複数エージェントの自律業務を、 正答率99%で。

Agentic Work Flow. RAGを活用した複数AIエージェントによる自律業務遂行で、約3万件の評価に基づき正答率99%を達成したリリースです。

Microsoft Foundry(Azure AI Foundry)エージェント

Azure上のエージェント基盤で、 Agent Opsを回す。

Microsoft Foundry(Azure AI Foundry)エージェント. モデルの選定・評価・デプロイ・運用の基盤を設計・導入し、Agent Opsによる継続的な改善を支援します。

エッジAI開発

現場の判断を、 エッジまで。

エッジAI開発. 画像・音声・センサーなど、リアルタイムの現場処理をエッジで行い、クラウドと役割を分担します。1,000台以上の稼働実績があります。

X-Tech FDE(フォワードデプロイエンジニアリング)

対象業務と責任分界を、 先に設計する。

X-Tech FDE(フォワードデプロイエンジニアリング). エンジニアが顧客の現場に入り、セキュリティ・ガバナンス・既存インフラの制約に合わせて、定着まで伴走します。

HWS Agent Camp

最初の1業務を、 2日間で試作する。

HWS Agent Camp. 専門エンジニアが伴走する2日間の集中ハッカソン。約2週間の事前準備のうえで、AIエージェントの本格的なプロトタイプを構築します。

23/よくあるご質問

Q. Microsoft-Decision-1とは何ですか。 A. Microsoftが提供する判断スコアリングモデルです。あらかじめ決めた選択肢に確率スコアを返し、ルーティング、分類、優先順位付け、検証、ワークフロー制御などの判断を、高速かつ低コストに実行します。Microsoft Foundryのモデルカタログから利用できます。
Q. LLMと何が違いますか。 A. LLMは文章の生成や推論が得意で、判断モデルは固定の選択肢に対する型付きの数値判断に特化しています。説明文は返さず、確率を閾値にして処理を切り替えます。生成が必要な場面はLLMを使い、ルーティングや関門を判断モデルが担う組み合わせが案内されています。
Q. 判断の理由は返りますか。 A. 返りません。Microsoft-Decision-1は、型付きの数値の判断を返し、文章の理由は生成しません。判断の理由が必要な場合は、判断基準の定義とログ、または別の生成モデルによる説明を組み合わせます。
Q. どのような質問の形式に対応していますか。 A. Yes/Noの確率を返すnoul、固定の選択肢から1つを選ぶchoice、順序尺度に置くscoreの3種類です。同じstateに対する複数の質問を、1回のリクエストにまとめられます。
Q. 利用料金はいくらですか。 A. Microsoftは、入力100万トークンあたり0.042米ドル、出力トークンは無料と公表しています。ワークフロー全体の費用は、判断の回数、入力の長さ、再評価の設計で変わります。
Q. 日本語での精度はどうですか。 A. Microsoftの公表ベンチマークには多言語タスクが含まれますが、日本語と企業固有データでの精度は、個別の検証が必要です。当社は、日本語の業務データで精度と閾値を検証します。
Q. 確率スコアはそのまま信頼できますか。 A. キャリブレーションは、なじみのあるタスクで最も強いとされています。自社の判断のラベル付きデータで、スコアと実際の正答率の関係を測り、閾値を決めてから自動化します。
Q. すべての判断を自動化できますか。 A. できません。低リスクで反復的な判断はモデルに任せ、確信度が低い判断は再評価か人の確認へ、高リスクまたは不可逆の判断は責任者が最終判断する、という使い分けを前提にします。個人に関する重大な決定は、人による確認を前提にした判断支援にとどめます。
Q. どこから利用できますか。 A. Microsoft Foundryのモデルカタログと、OpenRouterから利用できます。FoundryではGlobalStandardと、対象リージョンのDataZoneStandardのデプロイの種類があります。
Q. 認証はどうなりますか。 A. Microsoft Entra IDによる認証が推奨されています。APIキーも使えます。デプロイにはCognitive Services Contributorなどのロールが必要です。
Q. エッジAIやロボットにも使えますか。 A. 画像・音声・センサーの認識結果をもとに、クラウド上で次の行動候補を評価する構成を検討できます。安全停止、衝突回避、重要な制御は、モデル単体に任せず、安全機構・制御プログラム・人の監督を含む多層構成にします。ミリ秒単位の制御は、エッジ側の確定ロジックや専用モデルとの役割分担を前提とします。
Q. Enterprise Decision OSとは何ですか。 A. 企業内の判断基準、優先順位、例外条件、権限、リスク許容度をデータとして構造化し、状況に応じて最適なAIモデル、人、システムを選びながら、判断・実行・評価・改善を続ける企業基盤です。当社が目指す姿として、SyncLect Data Intelligence、Agentic Work Flow、Microsoft Foundryを組み合わせて取り組んでいます。
Q. 当社は何を支援できますか。 A. 対象とする判断の選定と定義、判断基準の整備(SyncLect Data Intelligence)、Foundry上での技術検証、モデルルーティングと品質ゲートの設計、Entra IDやログを含む運用設計、エッジ・フィジカルAIへの展開を支援します。モデルの提供と利用条件は、Microsoftによります。
Q. 最初は何から始めればよいですか。 A. 件数が多く、選択肢が明確で、誤りの影響が小さい判断を1つ選ぶところから始めます。短期間で動くものを確認したい場合は、2日間のHWS Agent Campも利用できます。

Microsoft-Decision-1の活用に関するご相談

対象とする判断の選定、判断基準の整備、Foundry上での技術検証と運用設計まで、貴社の状況に合わせてご提案します。

お問い合わせ