投稿者 投稿日: カテゴリー EC×AI活用
Microsoft-Decision-1とは、判定専用のAIモデルのことです。
返品申請の一次仕分けや、問い合わせの振り分けに、文章を書くための大きな生成AIを使う必要はあるのか。Microsoftが2026年10月上旬に公開した「Microsoft-Decision-1」は、この問いに「いらない」と答えるモデルです。文章を生成せず、あらかじめ決めた選択肢それぞれに確率を付けて返すことだけに特化しており、Microsoftの試算では1ドルで27万5千件以上の判定をこなせます。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづき、Decision-1の仕組みと、返品判定・注文審査・問い合わせ分類といったEC業務への当てはめ方、そして使ってはいけない場面を整理します。
「選ぶだけ」のAIが出てきた理由
Microsoft-Decision-1が狙うのは、生成AIに任せると高くて遅い「選択肢から1つ選ぶ」タイプの判断です。InfoWorldの報道によると、Decision-1はあらかじめ定義した選択肢それぞれについて、較正済みの確率（どれくらい確からしいかを数値化したもの）を1回の処理で返します。自由な文章は書きません。1回のリクエストで複数の判断を並べて評価することもできます。
ベースになっているのは、Alibabaがオープンウェイトで公開しているQwen3.5-9Bで、Microsoftが追加の学習を施しています。提供場所はMicrosoft Foundry（Azureのモデル提供基盤）とOpenRouterです。Microsoftは今後、自社のMAIモデルやOpenAIのモデルをベースにした版への切り替えも計画しているとされます。公式の入門記事はMicrosoft Community Hubのブログで公開されています。
想定している使い方は、はい／いいえの判断、選択肢からの選択、評価、ルーブリック（評価基準表）に沿った採点です。リクエストの分類、障害対応の優先順位付け、AIの回答が根拠に沿っているかの検証、AIエージェントが次にどの行動をとるべきかの判定などが例として挙がっています。
料金は入力100万トークンあたり4.2セントで、出力には課金されません。InfoWorldが紹介したMicrosoftの例では、入力86トークン・出力2トークンの判定1件が約0.0000036ドルで、1ドルあたり27万5千件以上の計算になります。速度についても、次点のモデルより約2.5倍、OpenAIのGPT-6 Solより約35倍速いとMicrosoftは説明しています。ただし、36種のベンチマーク・約15万問で最高精度を出したという性能値も含め、これらはMicrosoft自身の主張で、第三者の検証はまだありません。一部報道では平均正答率83.5%という数字も出ていますが、公式の数値として確認できるまでは参考値として扱うのが無難です。
EC事業者にとっての意味は単純です。これまで「問い合わせの種類を分ける」「返品申請を一次仕分けする」ためだけに、ChatGPTやClaudeのAPIを1件ずつ呼んでいた処理を、桁違いに安く速く回せる可能性が出てきました。2026年11月時点の主要モデルであるGPT-6.1 Terra、Claude Opus 5.5、Gemini 4 Argonは、文章を書く力や推論の深さで勝負するモデルです。Decision-1はそれらと競うのではなく、横に置いて「判断だけを切り出す」役割を担います。
EC業務で「判定」に切り出せる仕事、切り出せない仕事
Decision-1が向くのは、選択肢が事前に決まっていて、間違えても後から取り消せる判断です。InfoWorldの記事でKanerikaのAI開発マネージャーAmit Kumar Jenaが勧めているのも、リクエストのルーティングやトリアージ（緊急度による振り分け）のような可逆的な業務から始めることでした。EC業務に置き換えると、候補は次のようになります。
1つ目は問い合わせの分類です。「配送状況」「返品・交換」「商品の仕様」「支払い・領収書」「その他」のように5〜8個の選択肢を決めておき、受信した問い合わせ文をどれに当てはまるかで振り分けます。担当者の割り当てや、テンプレート返信の選択に直結します。うるチカラで紹介したEC問い合わせ返信スキルの3段階判定の「判定」部分だけを、Decision-1に置き換えるイメージです。
2つ目は返品申請の一次仕分けです。申請理由の文章と注文情報から、「返品ポリシーの条件内」「条件外の可能性あり（要確認）」「情報不足（追加質問が必要）」の3択に振り分けます。ここで大事なのは、Decision-1に「却下」を決めさせないことです。条件内と判定されたものだけを自動処理の候補にし、それ以外は担当者が見る流れにします。返品ポリシーそのものの整合性は、返品ポリシーの整合性チェックスキルで先に固めておくと、判定の質が安定します。
3つ目は、生成AIが書いた返信文の検証です。AIが作った問い合わせへの返信案が、注文情報や店舗ポリシーと矛盾していないかを「矛盾なし／矛盾の疑いあり」の2択で判定させます。根拠との整合（グラウンデッドネス）の検証は、Decision-1の想定用途に明示されている使い方です。
4つ目は、注文の要確認フラグ付けです。配送先と請求先の組み合わせ、注文数量、過去の注文履歴などから、「通常処理」「目視確認」の2択で振り分けます。ただし、これは慎重に扱うべき領域です。後述するように、人に大きな影響を与える判断をモデルだけに委ねるべきではありません。Decision-1は「人が見る注文を絞り込む」ところまでに留めます。
5つ目はレビューの仕分けです。投稿されたレビューを「お礼の返信で十分」「不具合・破損の申告（要対応）」「配送トラブルの申告（要対応）」「返信不要」の4択に振り分けると、担当者は要対応のレビューから先に手を付けられます。月に数百件のレビューが付く店舗では、低評価レビューへの初動が1日遅れるだけで、同じ不具合の申告が続いて評価が崩れることがあります。判定の対象を「どの順番で読むか」に限定すれば、誤判定があっても実害は小さく、最初に試す業務として向いています。
逆に、Decision-1に向かない仕事もはっきりしています。返信文そのものを書く、商品説明を作る、売上の理由を考察するといった「文章を生み出す」仕事は対象外です。判定の根拠も返さず、スコアだけを返す仕様なので、「なぜその判定になったか」を顧客に説明する必要がある場面では、別途ルールや人の確認が要ります。
日本語への対応も要確認の項目です。ベースのQwen3.5は多言語に強いモデルですが、Decision-1自身がどの言語でどこまでの精度を出すかは、公式情報で確認できていません。日本語の問い合わせ文で使う場合は、後述するテストデータで精度を測ってから本番に入れてください。
返品・問い合わせ判定をDecision-1に載せる5つの手順とプロンプト5本
Decision-1を業務に載せるときの仕事の大半は、モデルを呼ぶコードよりも「何をどの選択肢で判定させるか」の設計にあります。この設計作業はChatGPT、Claude、Geminiのような対話型のAIが得意です。以下の5本のプロンプトは、どれでも動く書き方にしています。
手順1は、判定に切り出せる業務の棚卸しです。毎日繰り返していて、選択肢が決まっていて、間違えても取り消せる判断を洗い出します。
プロンプト1：判定に切り出せるEC業務の棚卸し
あなたはEC事業の業務改善コンサルタントです。
以下は当店のカスタマーサポートと受注処理で、担当者が毎日行っている判断の一覧です。
それぞれについて、判定専用AIモデル（あらかじめ決めた選択肢に確率を付けて返すモデル）に任せられるかを評価してください。
評価の観点：
1. 選択肢を5〜8個以内に固定できるか
2. 判定を間違えても、後から人が取り消せるか（可逆性）
3. 顧客個人の権利や金銭に大きく影響するか（影響度）
4. 1日あたりの件数
出力形式：
判断名／選択肢の案／可逆性（高・中・低）／影響度（高・中・低）／判定AIに任せる範囲の提案
影響度が「高」のものは、人が最終判断する前提の提案にしてください。
業務の一覧：
{判断の一覧を貼り付け}
手順2は、質問文と選択肢の設計です。InfoWorldの記事でも触れられている通り、Decision-1は質問の言い回しで結果が変わりうるとMicrosoftのドキュメントに書かれています。質問文は一度決めたら版を管理し、勝手に変えないことが前提になります。
プロンプト2：判定用の質問文と選択肢の設計
あなたは分類タスクの設計者です。
以下のEC業務の判定について、判定専用AIモデルに渡す「質問文」と「選択肢」を設計してください。
条件：
1. 質問文は1〜2文で、主語と判断基準を明確にする
2. 選択肢は互いに重ならず、すべてのケースをどれかに当てはめられるようにする
3. 判断がつかないケースのための「情報不足」または「判断できない」の選択肢を1つ入れる
4. 「却下」「拒否」のように顧客に不利益を確定させる選択肢は作らず、「要確認」に置き換える
5. 各選択肢に、当てはまる例を1つずつ添える
判定したい業務：{例：返品申請の一次仕分け}
店舗の返品ポリシー（要約）：{ポリシーを貼り付け}
手順3は、テスト用データの準備です。本番の問い合わせや返品申請を、個人情報を消したうえで50〜100件集め、担当者が正解のラベルを付けます。正解付きのデータがないと、精度も閾値も決められません。
プロンプト3：検証用データの匿名化とラベル付け補助
あなたは個人情報保護に配慮するデータ整備担当です。
以下の問い合わせ文から、氏名、住所、電話番号、メールアドレス、注文番号、カード情報に当たる部分を
[氏名][住所][電話][メール][注文番号][カード]のように置き換えてください。
置き換えたあと、各問い合わせが次の選択肢のどれに当たるか、仮のラベルを付けてください。
仮ラベルは担当者が最終確認する前提です。自信がないものには「要確認」と付けてください。
選択肢：{手順2で決めた選択肢}
問い合わせ文：
{問い合わせ文を貼り付け}
手順4は、閾値と人のレビュー基準の設計です。Decision-1は確率を返すので、「確率が何%以上なら自動処理、未満なら人が見る」という線を決めます。テストデータで、閾値ごとの正解率と人が見る件数を比べて決めるのが基本です。
プロンプト4：判定結果の閾値設計
あなたはEC運営のデータ分析担当です。
以下は、判定AIの出力（各選択肢の確率）と、担当者が付けた正解ラベルの一覧です。
閾値を50%、70%、80%、90%に置いた場合それぞれについて、次を計算してください。
1. 自動処理に回る件数と、その中の正解率
2. 人のレビューに回る件数
3. 自動処理に回ったのに誤判定だった件数と、その内訳
最後に、誤判定を全体の2%以下に抑えつつ、人のレビュー件数をできるだけ減らす閾値を提案してください。
金銭や顧客の権利に関わる選択肢は、閾値に関係なく人のレビューに回す前提で計算してください。
データ：
{判定結果と正解ラベルを貼り付け}
手順5は、監査ログと月次の見直しです。InfoWorldの記事でForresterの副社長兼主席アナリストCharlie Daiが挙げていたのも、較正テスト、質問文と閾値の管理、監査ログの3点でした。誰が、いつ、どの版の質問文で、どの確率の判定を出したかを残します。
プロンプト5：判定AIの月次レビュー報告書
あなたはEC事業のAIガバナンス担当です。
以下の1か月分の判定ログ（日時、質問文の版、選択肢ごとの確率、採用した判定、人のレビュー結果）をもとに、月次報告書を作成してください。
含める内容：
1. 判定件数、自動処理率、人のレビュー率
2. 人のレビューで判定が覆った件数と、その傾向
3. 選択肢ごとの誤判定率の前月比
4. 質問文や閾値を見直すべきかの提案と、その理由
5. 顧客からの苦情につながった判定があれば、その経緯
判定ログ：
{ログを貼り付け}
この5つの手順は、システム開発会社に実装を頼む場合でも、発注側が先に済ませておくべき準備です。質問文と選択肢、閾値、レビュー基準が決まっていれば、実装の見積もりも検証も格段にやりやすくなります。
Decision-1導入で起きやすい失敗と回避策
現場で繰り返し見るのは、判定AIの結果を「最終判断」として扱ってしまう失敗です。Decision-1は根拠を返さずスコアだけを返します。返品を断る、注文を保留にするといった顧客に不利益が出る判断を自動で確定させると、理由を説明できないまま苦情につながります。回避策は、手順2で示したように「却下」系の選択肢を作らず、不利益が出る判断はすべて人を通す設計にすることです。人に大きな影響を与える判断に人のレビューを挟むことは、記事に登場するアナリストも共通して勧めています。
2つ目の失敗は、質問文を担当者ごとに書き換えてしまうことです。Decision-1は言い回しで結果が変わりうるため、ある担当者が「もう少し分かりやすく」と質問文を直した結果、翌日から振り分けの比率が大きく変わる、ということが起こりえます。質問文には版番号を付け、変更はテストデータで精度を測ってからにします。
3つ目は、日本語での精度を測らずに本番へ入れることです。英語で公開された性能値は、そのまま日本語の問い合わせ文には当てはまりません。直近の支援案件で観測したのは、別の分類モデルで、英語では高精度だったものが、敬語の多い日本語の問い合わせや、絵文字や略語が混ざった短文で精度を落とすケースでした。50件でもいいので、正解付きの日本語データで先に測ってください。
4つ目は、顧客データの扱いです。問い合わせ文や注文情報をクラウドのAPIに送る以上、個人情報保護法上の取り扱いと、プライバシーポリシーの記載を確認する必要があります。氏名や住所が判定に不要なら、送る前に消しておくのが基本です。プロンプト3の匿名化は、テストだけでなく本番の前処理としても使えます。
コストとKPIの目安
Decision-1の利用料そのものは、EC事業者の規模ならほぼ無視できる水準です。Microsoftの試算どおりなら、1件あたり約100トークンの判定を月10万件回しても、入力料金は1ドルに届きません。費用の中心は、モデルの利用料ではなく、設計と検証にかかる人の時間です。
工数の目安として、手順1〜2の業務棚卸しと質問設計に担当者2〜3日、手順3のテストデータ作成に1〜2日、手順4の閾値設計に半日、システムへの組み込みは既存の問い合わせ管理ツールとの連携方法によって数日から数週間を見ておくと現実的です。設計作業に使うChatGPT Plus、Claude Pro、Google AI Proはいずれも月額20米ドル前後です。
追うべきKPIは4つです。1つ目は自動処理率で、判定のうち人を通さずに処理できた割合です。2つ目は誤判定率で、人のレビューや顧客からの指摘で覆った判定の割合を、選択肢ごとに見ます。3つ目は一次対応時間で、問い合わせの受信から担当者の割り当て、または最初の返信までの時間です。4つ目は判定起因の苦情件数で、ゼロを目標にします。
店舗運営の現場感覚では、問い合わせの振り分けを自動化するだけで、一次対応までの時間が半分程度に縮むケースは珍しくありません。ただし、それは判定の精度が担保されている前提の話です。最初の1か月は自動処理率を追いかけず、誤判定率の把握を優先したほうが、結果的に早く安定します。
具体的な数字で考えてみます。1日300件の問い合わせを受ける店舗で、担当者が1件あたり30秒かけて種類を見分けて振り分けているとすると、振り分けだけで1日2時間半、月に約75時間になります。このうち7割を判定AIで自動振り分けにできれば、月50時間前後の作業が浮く計算です。浮いた時間を、要確認に回った難しい問い合わせへの丁寧な返信に充てるのが、顧客満足を落とさない使い方です。
「判断の外出し」はEC運営の標準になるか
Decision-1が示しているのは、AIの使い方が「1つの大きなモデルに全部任せる」形から、「判断と生成を分けて、それぞれに合ったモデルを使う」形へ移っていく流れです。返信文は文章が得意なモデルで書き、その返信を送ってよいかの判定は判定専用モデルで行う。こうした組み合わせは、コストと速度の両面で合理的です。うるチカラでもAIのタスク単価とキャッシュ活用の考え方を紹介しましたが、判定の切り出しはそのコスト最適化をさらに一段進める手段になります。
AIエージェントが受注や問い合わせ対応を自律的に進めるようになるほど、「この行動をとってよいか」をすばやく安く確認する仕組みの価値は上がります。Decision-1の想定用途に、エージェントの行動の評価が含まれているのはそのためです。返金処理や在庫の引き当てといった取り消しにくい行動の手前に、判定のゲートを置く設計は、今後のEC運営で一般的になっていくはずです。
一方で、ベースのモデルが他社のオープンウェイトモデルであること、今後ベースを切り替える計画があることは、運用側にとっては変化のリスクでもあります。ベースが変われば、同じ質問文でも判定の傾向が変わる可能性があります。手順5の月次レビューは、こうしたモデル側の変化に気づくための仕組みとしても機能します。
次に注目したいのは、日本語での精度に関する公式情報、Microsoft以外の第三者による性能検証、そしてFoundryでの日本リージョンでの提供状況です。いずれも現時点では要確認のため、情報が出そろった段階で改めて整理します。
よくある質問
Microsoft-Decision-1とは何ですか？
Microsoft-Decision-1とは、文章を生成せず、あらかじめ決めた選択肢それぞれに較正済みの確率を返す判定専用のAIモデルのことです。MicrosoftがQwen3.5-9Bをベースに追加学習を施し、2026年10月上旬にMicrosoft FoundryとOpenRouterで公開しました。分類、優先順位付け、AIの回答の検証などに使います。
料金はいくらですか？
入力100万トークンあたり4.2セントで、出力は無料です。Microsoftの例では、判定1件が約0.0000036ドルで、1ドルあたり27万5千件以上の判定が可能とされています。中小規模のEC事業者なら、利用料よりも設計と検証の人件費のほうがはるかに大きくなります。
日本語の問い合わせでも使えますか？
現時点では要確認です。ベースのQwen3.5は多言語に対応していますが、Decision-1自身の日本語での精度は公式情報で確認できていません。導入前に、正解ラベル付きの日本語データ50〜100件で精度を測ってください。
返品の可否や注文のキャンセルを自動で決めてもよいですか？
いいえ、顧客に不利益が出る判断はモデルだけに任せるべきではないからです。Decision-1は判定の根拠を返さないため、理由を説明できません。自動処理は「条件内」と判定されたものに限り、それ以外は人が確認する設計にしてください。
ChatGPTやClaudeで分類すればいいのでは？
少量なら十分ですが、件数が多いと費用と速度で差が出ます。ChatGPTやClaudeは文章の生成や複雑な推論に強いモデルで、判定だけに使うと割高になりがちです。判定はDecision-1、返信文の作成は対話型のAI、というように役割を分けるのが合理的です。
導入の最初の一歩は何ですか？
問い合わせ分類のような、間違えても取り消せる業務の棚卸しから始めてください。本記事のプロンプト1で候補を洗い出し、プロンプト2で質問文と選択肢を設計すれば、実装を誰に頼む場合でも要件がはっきりします。
参考文献
- Microsoft separates decision-making from generative AI with a new model（InfoWorld）
- Not Every Decision Needs an LLM: Getting Started with Microsoft-Decision-1（Microsoft Community Hub）
- Microsoft separates decision-making from generative AI with a new model（Computerworld）
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
