Microsoft Work IQの拡張から考える、業務用語と判断基準

「未解決の重大な問い合わせが残っている顧客には、契約更新の提案を出さない」。

営業の手順書に、こうした社内ルールが書かれていたとします（MIFが説明のために置いた架空の例です）。

では、この手順をAIエージェントに任せるとき、エージェントは「未解決」と「重大」を、どのデータのどの値で判定するのでしょうか。

Microsoftは2026年9月25日、Work IQでDynamics 365とPower Platformの業務データや業務プロセスを活用する機能を発表しました。

Work IQ自体は、2025年11月のMicrosoft Igniteで、Microsoft 365 Copilotとエージェントを支える仕組みとして紹介されています。

今回の発表は、そのWork IQを業務アプリの領域へ広げるものです。

本稿では、業務用語と手順の定義、その管理責任に焦点を当てて、この拡張を読みます。

今回の発表で何が加わったか

Microsoftの説明によれば、今回の拡張で、Copilotやエージェントは、営業・サービス・財務などの業務アプリのデータを、Microsoft 365上のやり取りとあわせて参照できるようになります。

本稿が取り上げるのは、次の三つの仕組みです。

一つ目は、Dataverseのセマンティックモデルです。

データ項目の意味や関係を、AIが解釈できるようにまとめた仕組みで、Microsoftの技術資料では、既存のテーブル間の関連、ビュー、フォーム、項目の説明などから自動で作られると説明されています。

これに、業務用語を補う用語集（glossary）が組み合わされます。

二つ目は、ビジネススキルです。

仕事の進め方を、再利用できる指示としてまとめたもので、MCP（AIが外部の情報や機能を利用するための接続規格）を通じて、アクセス権のあるエージェントが必要に応じて見つけて使う、と説明されています。

Microsoftは、ビジネススキルを「実行可能なコードではなく、エージェントの行動を導く自然言語の指示」と明記しています。

三つ目は、権限や承認条件に従って行うデータ更新などの操作です。

Copilotやエージェントが変更案を示し、必要な承認を経て、ユーザーの権限の範囲内で元のレコードを更新する、という流れが説明されています。

時期については、今回発表された業務アプリ対応は、2026年9月30日から公開プレビューを開始し、10月にかけて順次展開する予定とされています。

Dynamics 365のERP領域は10月下旬の展開予定です。

なお、セマンティックモデルとビジネススキルの公式資料には、プレビュー機能は本番利用を目的としていない、と明記されています。

用語集は、既存の解釈と自社の基準のずれを埋める場所

冒頭の問いに戻ります。

Work IQは、「重大」の意味を何も手がかりなしに推測するわけではありません。

たとえば、すでに「重大な問い合わせ」というビューがあり、対象となる優先度や状態が設定されていれば、セマンティックモデルはそこから意味を読み取れる可能性があります。

用語集にも、利用者が追加する項目だけでなく、システムが作成した定義があり、それを編集できると説明されています。

つまり、会社がすべての言葉をゼロから定義し直す必要はありません。

私たちが重視しているのは、別の点です。

システムが読み取った意味が、会社として採用したい判断基準と一致しているかを確かめることです。

曖昧な社内ルールをAIに渡すと、AIは足りない部分を推測で埋めて動くことがあります。

その推測が妥当でも、会社がその基準を採用すると決めたわけではありません。

そこで、「重大」のように対応方針を左右する用語については、次の三つを確認することを勧めます。

• どの項目と判定条件を参照しているか
• それが自社の基準と一致しているか
• 不足や食い違いがあれば、用語集で補ったか

あわせて、その定義を誰が承認し、業務が変わったときに誰が見直すかも決めておきます。

用語集には、略語や同義語のように、判断に直接関わらない言葉も載ります。

すべての用語を同じ重さで扱う必要はなく、判断に使う言葉から優先して確認すれば十分です。

用語集・スキル・承認の仕組みは、役割が違う

この拡張を読むうえで、最も混同しやすいのがここです。

三つの仕組みは、それぞれ別のことを担います。

対象	主な役割
用語集	業務用語が何を意味し、どのデータ項目や値に対応するかを説明する
ビジネススキル	どの情報を確認し、どの順序で仕事を進めるかを、再利用できる指示としてまとめる
権限・承認の仕組み	実際にどの操作を許し、どの条件で承認を必要とするかを制御する

違いが最も表れるのは、承認です。

たとえばスキルに「値引きを提示する前に承認を得る」と書くことは、エージェントに手順を伝えることです。

一方、承認なしでは値引きを登録できないようにしたいなら、値引きの登録や顧客への送信を行う機能の側で、承認の有無を確認する仕組みが要ります。

私たちは、重要な操作の許可を、自然言語の指示だけに頼らない構成を勧めています。

スキルには、承認が必要な場面と確認事項を書きます。

そのうえで、実際の操作を行う機能や承認フローに、その条件が反映されているかを確認します。

共有するスキルは、共有前に想定条件で確かめる

ビジネススキルの利点は、一度書いた手順を複数のエージェントで使えることです。

担当者やエージェントごとに手順が違ってしまう状態を減らせるのは、確かな利点です。

その裏返しとして、共通のスキルに曖昧な指示や誤りがあれば、それを利用する複数のエージェントに影響する可能性があります。

Microsoftの作成ガイドも、曖昧な指示はエージェントの挙動の不一致につながるとして、具体的に書くこと、共有する前に実際のシナリオで挙動を確かめることを勧めています。

このガイドは、トラブル時の対応や、次の手順へ進む前の確認をスキルに書くことも挙げています。

私たちはここに、一つ加えることを勧めます。

判断に必要な情報が足りない場合は、推測で先へ進めず、誰に何を確認するかをスキルに書いておくことです。

冒頭の例なら、問い合わせの状態が未入力だったり、関係する契約が特定できなかったりした場合に、「重大な問い合わせなし」と扱わず、確認先へ引き継ぐ、という指示です。

設定する人と、業務ルールを承認する人を決める

Microsoftは、統制に関わる役割を三つに分けて説明しています。

AIの利用方針を管理する管理者、対象となる業務環境を管理するPower Platform管理者、そしてその範囲内でアプリやデータの公開方法を設定するアプリ作成者（maker）や開発者です。

これは製品上の役割であり、会社の業務ルールを誰が承認するかを指定しているわけではありません。

たとえば、用語集を編集する権限を持つ人が、そのまま「重大な問い合わせ」の業務上の定義を決める責任者になるとは限りません。

そこで、製品上の役割に加えて、業務用語や判定条件を誰が承認するかを明確にすることを勧めます。

業務責任者が意味と適用範囲を確認し、設定を担当する人が用語集・スキル・承認フローへ反映する、という分担です。

会社の規模によっては、同じ人が兼ねても構いません。

全社で共通にする定義と、商品・契約・業務ごとに変える条件を区別しておくと、設定へ反映しやすくなります。

契約更新業務で整理しておきたい定義と承認条件（一例）

Microsoftが発表で挙げた、契約更新前の確認手順を題材にします。

発表では、「未解決の重大なケースを確認する」「サービス改善計画の責任者を確認する」「顧客の意向を記録する（Document customer commitment）」「条件の緩和を提示する前に承認を得る」といった手順が例示されています。

以下は、MIFによる業務整理の一例です。

製品の必須設定を示すものではありません。

自社の業務・規制・リスク許容度に合わせて、各社が埋めるための叩き台として使ってください。

確認すること	事前に決める内容	反映先の例	定義・条件の承認者の例
未解決・重大な問い合わせ	今回の契約に関係する問い合わせの範囲、対象とする状態、重大とする基準。優先度を使う場合は、どの値を対象とするか	用語集、データ項目、抽出条件、スキル	サービス責任者
改善計画の責任者	どの記録を責任者の根拠にするか。未設定なら誰に確認するか	顧客・契約の記録、スキル	顧客対応の責任者
顧客の契約更新の意向・条件	顧客の意向・条件をどの記録で確認し、合意済みかどうかをどう区別するか	顧客・契約の記録、スキル	営業・サービス責任者
値引きなどの条件緩和	対象、上限、承認者、承認が必要となる時点	決裁規程、スキル、承認フロー	事業責任者
判断に必要な情報の不足	未入力・参照不可・記録の食い違いがある場合に、誰へ確認するか	スキル、業務手順	業務責任者

「重大」と「優先度」は、同じ尺度とは限りません。

処理の順番を示す優先度を、重大さの判断に使うかどうかも、会社が決めることです。

表の最後の行は、この表の要です。

判定に必要な情報が確認できなければ、「重大な問い合わせなし」と扱わず、確認先へ引き継ぎます。

条件緩和を提示する場合は、提案内容に対応した承認を確認してから進めます。

用語の定義と、判断できない場合の対応、実行前の承認をつなげることで、「言葉を書けば解決する」という話で終わらせないようにします。

導入準備で確認したいこと

一つ目は、検証の場所です。

Microsoftは、プレビュー機能は本番利用を目的としていないと説明しています。

検証用の環境で、代表的なケースと、情報が不足するケースの両方を試し、定義・手順・承認条件に不足がないかを確認します。

影響の小さい業務から始めるのは有効ですが、影響が小さければプレビューに本番業務を依存させてよい、という意味ではありません。

二つ目は、変更の反映です。

Microsoftの技術資料によれば、セマンティックモデルは定期的に再生成され、設定の変更を取り込みます。

用語集の変更も、保存した瞬間ではなく、次の再生成で取り込まれると説明されています。

業務上の前提が変わったときは、既存のビューや用語の定義が引き続き適切かを確認し、変更後には、モデルへの反映と、対象業務での回答や動作を確かめます。

三つ目は、解釈と利用範囲の区別です。

関連性の薄くなったビューなどを、意味の解釈に使う対象から外す設定と、元のデータへのアクセスを制限する設定は、別のものです。

どちらを変えたのかを、記録に残しておくと混乱を防げます。

まとめ

MIFが重視するのは、業務判断に使う言葉と、その判断の根拠を明確にすることです。

まず既存の規程やアプリ設定を確認し、AIが参照する定義に不足や食い違いがあれば補足します。

用語集には言葉の意味を、スキルには確認手順と判断できない場合の対応を整理します。

実行前に必要な承認や権限の制限は、操作を行う仕組みに反映されているかを確認します。

そのうえで、定義や手順を誰が承認し、業務が変わったときに誰が見直すかを決めます。

対象業務を一つ選び、代表的なケースと情報が不足するケースの両方で、想定した判断と動作になるかを確かめることを勧めます。

情報確認について

本記事は、2026年9月29日確認時点の次の資料をもとに作成しています。

Microsoft Dynamics 365 Blogの記事「Work IQ: Business and workplace intelligence in the flow of work」（2026年9月25日）、Microsoft 365 Blogの記事「Microsoft Ignite 2025: Copilot and agents built to power the Frontier Firm」（2025年11月18日）、Microsoft Learnの「Overview of Dataverse semantic model」「Manage semantic model glossary entries」「Business skills overview」「Create and use business skills」です。

提供時期・対象アプリ・機能の仕様は、変更される可能性があります。

導入時にはMicrosoftの公式情報で最新の条件をご確認ください。

製品機能と提供予定は、Microsoftの公表資料に基づきます。

業務用語・手順・承認条件の整理と事例はMIFによる提案であり、MIFが実際の動作や制御の有効性を独立に検証したものではありません。