はじめに
2026年5月1日、Microsoft 公式ブログで Dataverse の Business skills（パブリックプレビュー）が発表されました。
組織の業務手順や規程を「自然言語の指示」として Dataverse に登録しておき、Copilot Studio などのエージェントから自動で発見・呼び出せるようにする仕組みです。
「指示文やナレッジベースと何が違うのか」「実務でどんな価値があるのか」が、個人的にはイメージできない人もいると思いますので、以下の観点で情報を整理してみたいと思います。
※検証時点は 2026年5月 で、Business skills はまだパブリックプレビュー機能であることをご留意ください
- そもそも Business skills とは何か
- 指示文・ナレッジベースとの違い
- 実際に手動で構築してみた手順
- ナレッジベースで対応していた業務を、あえて Business skills 化してみた場合の比較結果
- ナレッジよりも Business skills の方が向くのはどういうケースか
今回はあくまで、ナレッジベースで対応していた業務を、強いて Business skills 化してみた場合にどのような差が出るか という観点で進めています。これを踏まえて、最後に「どういうケースであれば Business skills が向くか」も整理してみたいと思います。
そもそも Business skills とは
公式ブログの言葉を借りれば、Business skills は「組織の業務プロセス・ポリシー・専門知識を、エージェントが理解して従える形式で記述したもの」です。
具体的には、以下のような情報を 自然言語のテキスト として Dataverse に登録します。
- このスキルが何のためにあるか（目的）
- どんな質問のときに呼び出すか（使用条件）
- 具体的な手順（Step1、Step2…）
- 注意事項や除外条件
登録したスキルは、Dataverse MCP サーバー経由で Copilot Studio エージェントから呼び出せます。エージェントはユーザーの発話に応じて適切なスキルを 自動的に発見 し、その手順に沿って回答を生成します。
指示文・ナレッジベースとの違い
Copilot Studio で業務エージェントを作るとき、これまで知識をエージェントに持たせる、渡す方法は主に2つでした。
1つ目は、指示文（Instructions）に書く方法です。
エージェントの指示文に「経費精算は3万円以下なら課長承認、3万円超は部長承認…」のように直接記述する方法です。シンプルですが、業務手順が増えてくると指示文が長くなりすぎて、結果的にトークンが肥大化したり、回答の精度が落ちたりする問題があります。
2つ目は、ナレッジ（PDFやWord等）として登録する方法です。
業務マニュアルをそのままナレッジとして登録し、エージェントが必要に応じて検索（RAG）して回答する仕組みです。ドキュメント資産をそのまま活かせる一方で、表が多いマニュアルや、章をまたいだ参照が必要なマニュアルでは、検索ヒットの精度が落ちることがあります。
そして今回登場した Business skills は、上記2つの「ちょうど中間」のような位置付けです。
個人的には、「業務手順を 再利用可能な部品 として独立させた」という捉え方がしっくりきています。
なお、AI プロンプト、エージェントフロー、ツール、トピックやマルチエージェントなど、Copilot Studio の他の構成要素との詳細な使い分けについては、別記事で整理したいと思います。
Dataverse に登録できるようになりました
これまで Copilot Studio のエージェントは、自分の指示文かナレッジを使って回答するスタイルが基本でした。
Business skills の登場により、Dataverse という共通の置き場 に業務手順を登録しておけば、複数のエージェントから自動で発見・呼び出せるようになりました。
スキルの管理画面は Power Apps の左ペインに「ビジネススキル（Business skills）」として表示されます。1つのスキルは「一意の名前」「説明」「指示」の3つのフィールドから構成されており、画面上で自然言語のテキストを入力して保存するだけで作成できます。
こんな感じで作成できます。
再利用・共有メリットの冷静な評価
Business skills のメリットとして公式ブログでも挙げられているのが、
- 1つのスキルを複数のエージェントから再利用できる
- 業務担当者がエージェントを触らずにスキルを編集できる
- ソリューション経由で環境間に展開できる
といった点です。
これらは確かに価値のある特徴だと考えますが、個人的には、こうした再利用・共有のシナリオが市民開発者の現場でどれだけ実在するかは、もう少し冷静に評価したい と思っています。
これまでお客様から相談を受けてきた感覚では、Copilot Studio で作るエージェントは「特定の部署・特定の業務に閉じた1台」というケースが多い印象で、エージェントを横広く展開 (利用者として共有ではなく) したいという相談をいただくことも稀です。
そのため、「Business skills が登場した＝いきなりすべてのエージェントを Business skills ベースで作成して共有すべき」とはならないと考えています。
今後、複数部署にエージェントを横展開して共通スキルを参照させるという運用が力を発揮する業務シナリオがどれくらい出てくるか、引き続きお客様の支援をしつつ、冷静に見極めていきたいと思います。
構築手順（手動構築）
ここからは実際の構築手順を紹介します。今回は、Power Apps の画面から登録して、Copilot Studio のエージェントから利用する方法を紹介します。
Step 1：Dataverse intelligence の有効化
Power Platform 管理センターで対象環境を選択し、「Dataverse intelligence」を有効にします。
これを有効にすると、Power Apps の左ペインに「ビジネススキル」が表示されるようになります。
Step 2：Business skills の作成
Power Apps を開き、左ペインから「ビジネススキル」を選択して、「+ 新しいスキル」をクリックします。
スキルの構成は以下の3フィールドだけです。
- 一意の名前：スキルの識別子（プレフィックス付き）
- 説明：このスキルをいつ呼び出すかの判断基準（重要）
- 指示：実際の業務手順（マークダウン形式）
特に重要なのが 「説明」フィールド です。エージェントはこの説明文を読んで「このスキルを呼び出すべきか」を判断します。曖昧な説明だとスキルが正しく呼ばれません。
「使用条件」と「使わないケース」を明示するのがコツです。スキル数が増えてきたときの誤呼び出しを抑える効果が大きいと感じました。
試しに、以下のような感じで登録してみました。
マークダウン形式で表示もできそうです。今後、既存のナレッジをマークダウンに変換して Skills で登録するケースも増えそうですね。
以下の方法で共有もできます。今回は自分自身で試しますが、実際に運用する際は、こちらから利用者への共有も必要そうです。
Step 3：Copilot Studio エージェントとの連携
Copilot Studio で新規エージェントを作成し、ツールに Dataverse MCP サーバー を追加します。
これだけで、登録したスキルすべてがエージェントから見えるようになります。スキルごとに紐づけする必要はありません。
エージェントの指示文は以下のような形でシンプルに済みます。
あなたは経費精算業務エージェントです。
ユーザーから経費の承認や手続きに関する質問が来たら、
最初に必ず Dataverse の Business skills を検索し、
該当するスキルの手順に従って回答してください。
スキルの指示に書かれた手順・条件分岐・例外条項を
要約・省略・補完しないこと。
該当するスキルが見つからない場合は、
「該当する業務手順が登録されていません」と回答すること。
ナレッジベースとの比較検証
今回は、ナレッジベース（Word をそのまま登録）でも対応できる業務シナリオを、あえて Business skills 化してみた場合に、どのような差が出るのか。同じ業務シナリオで2種類のエージェントを構築して、比較してみました。
検証シナリオ：経費精算規程の承認ルート判定
仮想の会社の経費精算規程（約30ページ）をベースに、社員からの「○万円の○○の承認は誰？」という質問に答えるエージェントを作成します。
規程には、ナレッジ検索が苦手とする要素を意図的に盛り込みました。
- 金額別承認権限表（3万円以下は課長、3万円超10万円以下は課長＋部長…）
- 費目別の追加承認表（IT機器なら情シス部長、研修費なら人事部長など）
- 第7章の特例規定（海外関連経費は本則ルールを置き換える、法人カードは課長承認のみ、など）
特に第7章の特例規定は、本則の金額別ルールを 「上書き」 する関係になっており、章をまたいで両方を読まないと正答できない構造です。
比較するエージェント
| エージェント | 構成 |
|---|---|
| エージェントA（従来版） | 指示文 + ナレッジ（規程Word） |
| エージェントB（Skills版） | 指示文 + Business skills（4つ） |
Skills版に登録した4つのスキルは以下のとおりです。
- 国内通常経費の承認ルート判定
- 海外経費承認ルート（海外特例）
- 緊急経費承認（緊急時の事後申請）
- 法人カード経費処理（法人カード特例）
Skills版指示文
あなたは○○商事の経費精算業務エージェントです。
【業務スキルの優先利用】
社員から経費の承認・申請・処理手順に関する質問を受けたら、
最初に必ず Dataverse の Business skills を検索してください。
各スキルの説明文に書かれた使用条件・トリガーフレーズ例を
ユーザー発話と照合し、最もマッチするスキルを呼び出します。
【複数スキルが関連する場合】
ユーザーの質問が複数のスキルにまたがる場合は、
各スキルの説明文に書かれた併用ルール（例：法人カード×海外）に従い、
複数スキルを順次呼び出して結果を統合してください。
【判定に必要な情報の確認】
スキルを呼び出すには以下の情報が必要です。不足していたらユーザーに確認してください：
- 金額
- 費目（交通費・接待・IT機器・研修費など）
- 国内／海外の別
- 通常／緊急の別
- 立替払い／法人カードの別
【スキル本文の取扱い】
スキルの「指示」フィールドに書かれた手順・条件分岐・例外条項を
要約・省略・補完しないこと。Step 1 から順番にすべて実行すること。
業務担当者が定義した手順を一字一句正確に伝えるのがあなたの役割です。
【スキルが見つからない場合】
「該当する業務手順が登録されていません。経理部にお問い合わせください」
と回答し、推測ベースの回答は行わないこと。
【出力形式】
- 必要な承認者リスト（順序付き）
- 注意事項
- 関連する補足ルール（該当時）
ナレッジ版指示文
あなたは○○商事の経費精算アシスタントです。社員から経費の承認ルートに関する質問を受けたら、ナレッジに登録された「経費精算規程」を参照して誰の承認が必要かを正確に回答してください。
回答には以下を含めること：
- 必要な承認者リスト
- 承認順序
- 注意事項（あれば）
8件のテスト発話
両エージェントに同じ8件の質問を流して、回答精度を比較しました。
| # | 質問 | 期待される回答 |
|---|---|---|
| 1 | 通勤交通費2万円の承認は誰？ | 課長のみ |
| 2 | 8万円の備品購入の承認者は？ | 課長＋部長 |
| 3 | 30万円のノートPC購入、誰の承認が必要？ | 課長＋部長＋本部長＋情シス部長 |
| 4 | 12万円の社外研修の承認は？ | 課長＋部長＋本部長＋人事部長 |
| 5 | 海外出張で5万円の現地交通費、承認は？ | 課長＋本部長＋海外管理部 |
| 6 | 20万円の海外取引先接待、承認は？ | 課長＋本部長＋海外管理部＋コンプラ部門 |
| 7 | 法人カードで8万円使った、承認は？ | 課長のみ |
| 8 | 法人カードで海外出張時の食事8万円、処理は？ | 課長＋本部長＋海外管理部 |
検証結果
8件の比較結果は次のとおりでした。
| # | 質問 | 従来版（Wordナレッジ） | Skills版 |
|---|---|---|---|
| 1 | 通勤2万 | ○ | ○ |
| 2 | 備品8万 | ○ | ○ |
| 3 | PC30万 | ○ | ○ |
| 4 | 研修12万 | ○ | ○ |
| 5 | 海外交通5万 | ○ | ○ |
| 6 | 海外接待20万 | ○ | ○ |
| 7 | 法人カード8万 | ○ | ○ |
| 8 | 法人カード×海外×食事 | ×（回答放棄） | ○（完答） |
結果は、8件中7件は両者とも正答。差分が出たのは Test #8 のたった1件 でした。
正直、この結果は私自身の事前予想を外しました。「ナレッジベースは複雑な規程に弱いはず」と思っていましたが、規程を丁寧に書いて構造化しておけば、現代の Copilot Studio が利用するモデルや検索インデックス (今回はファイルアップロード) は、表の統合や特例条項の扱いも含めて、かなり高い精度で正答してきます。
唯一差分が出た Test #8
Test #8（法人カードで海外出張時の食事8万円）は、規程の 2つの特例（第7章の法人カード特例と海外特例）を同時に適用 する必要がある質問です。
従来版の回答：
法人カード決済および海外関連経費は、通常の金額別承認権限の対象外となり、第7章の特例規定が優先されます。詳細な承認者や順序は 第7章の内容に基づきます が、通常の承認ルートとは異なる点に注意してください。
承認者を明示せず、「第7章を確認してください」と回答を放棄するような形になりました。
Skills版の回答：
本件は「法人カード経費処理スキル」および「海外経費承認ルートスキル」の 両スキルを併用 して処理します。
必要な承認者リスト：① 課長 ② 本部長 ③ 海外管理部
処理ステップ：月次明細受領 → 利用記録 → 領収書添付 → 課長承認 → 経理提出
両スキルを独立に呼び出して、承認者と処理手順を統合した完答を返してきました。
実際の MCP トレースを見ると、エージェントは以下のように動いていました。
- search ツールでスキル一覧を検索
- 関連するスキル2つを発見（法人カード経費処理／海外経費承認ルート）
- describe ツールで 2つのスキルの本文を独立に取得
- 両者を統合した回答を生成
どんなときに差分が出やすいか
今回の検証で個人的に最も学びがあったのは、以下の方法の場合は、ナレッジからは回答返ってきませんでした。そのため、
ナレッジベース（ファイルアップロード）でも検証してみたところ、思ったより優秀で、ほとんどの質問で正しい回答が返ってきました。ただし、複数のルールを同時に組み合わせる必要がある質問だけは、構造的に苦手でした
という事実です。
ファイルアップロードの場合は、上記のような結果でしたが、以下の方法で、SharePoint 内のファイルをナレッジとして追加した場合はほとんど回答返ってきませんでした。そのため、利用するナレッジ次第では、Business skills を利用する場合とそうでない場合で回答精度に大きな差が出てくると思います。
※ファイルアップロード後、少なくとも、48 時間以上は経過しています
ナレッジベースで対応していた業務を、あえて Business skills 化することで、こうしたナレッジが構造的に苦手な領域を補完できる可能性があると感じました。具体的には、以下のような業務シナリオで Business skills が向きやすいかと思います。
1. 複数の特例ルールが同時に適用される業務
今回の Test #8 のように「条件Aの特例＋条件Bの特例」を組み合わせる必要があるケースです。承認規程・契約レビュー・与信判定などで起きやすいパターンと考えます。
2. 規程が複数ページ・複数文書にまたがる業務
今回の検証では1つの30ページ規程でしたが、実務では「経費規程＋出張規程＋海外駐在員規程」のように関連規程が複数ある会社も多いと思います。文書数が増えるほど、ナレッジ検索のヒット精度は落ちやすくなります。複数ページにまたがって一連の手順を辿る必要がある場合や、章間参照が多い文書も同様です。
3. 用語のゆらぎが大きい業務
「法人カード」と「コーポレートカード」、「業務経費」と「立替金」など、同じ概念に複数の呼び方がある業務は、ナレッジ検索が外しやすい領域と感じます。セマンティックインデックスかどうかでも変わると思いますが、Business skills の場合は、Business skills の説明文に「使用条件のトリガーフレーズ例」を複数並べておけば、エージェントの呼び出し精度は安定しやすくなります。
必要なスキルだけが動的にロードされる仕組み
検証中に確認できた、もう一つの興味深い事実です。
Business skills の特徴の一つとして、エージェントは 必要なスキルだけを動的に取得する という挙動があります。
今回の検証でも、4つのスキルが登録されている中で、Test #8 では法人カード経費処理スキルと海外経費承認ルートスキルの 2つだけ が取得され、残り2つ（国内通常経費・緊急経費承認）はコンテキストに入っていませんでした。
このため、スキル数が増えてもエージェント本体は軽いまま保てる仕組みになっています。
なお、指示文に業務手順を直接書く運用との比較や、業務手順が増えてきたときの管理方法、他の構成要素（AI プロンプト、エージェントフロー、トピック等）との使い分けについては、別記事で整理したいと思います。
その他の活用観点について
検証結果以外にも、Business skills が活きる場面はいくつかあります。たとえば、業務担当者がエージェントを直接触らずに手順を更新したい場合や、監査・コンプライアンスで業務手順の変更履歴を残したい場合などです。
ただし、こうした位置づけや判断基準については、別記事で体系的に整理したいと思いますので、そちらをご参照いただけますと幸いです。
まとめ
今回は、Copilot Studio の Business skills（プレビュー）について、ナレッジベースと比較した検証結果を紹介しました。
要点を振り返ると次の通りです。
- Business skills は業務手順を Dataverse に登録し、エージェントが自動で発見・呼び出せる仕組み
- 指示文・ナレッジベースとの違いは「業務手順を再利用可能な部品として独立させた」点
- 規程を丁寧に整備すれば、ナレッジベースでも7〜8割の業務には十分対応できる
- ナレッジベースで対応していた業務であっても、複数の特例ルールが同時に適用されるようなケースでは、Business skills 化することで補完できる場合がある
- スキル数が増えても、必要なスキルだけが動的にロードされる仕組みになっている
個人的には、ナレッジベースと比較した場合、「Business skills はナレッジベースの完全な代替ではなく、ナレッジの構造ややりたいこと次第では、ナレッジが原理的に苦手な領域を補完することもできる」という捉え方がしっくりきています。
再利用・共有のメリットも理論上は大きいですが、市民開発者の現場で実際にどれだけ活用されるかは、もう少し時間をかけて様子を見たいと思っています。プレビュー機能ですので、今後の進化にも期待したいところです。
なお、本記事の検証結果はあくまで現時点（2026年5月）のもので、Copilot Studio が利用するモデルやインデックスの仕組みが変われば、結果も変わる可能性があります。「私の手元ではこうだった」「こういう設定にしたらいい感じに動いた」といった情報が集まることも期待しています。
また、Copilot Studio における Business skills の位置づけや、指示文・ナレッジ・AI プロンプト・エージェントフローなど他の構成要素との詳細な使い分けについては、別記事で整理したいと思います。
本記事が Business skills を試してみる方の参考になれば幸いです。