はじめに
2026年5月1日、Microsoft 公式ブログで Dataverse の Business skills（パブリックプレビュー）が発表されました。
こちらを踏まえ、Copilot Studio でエージェント作成時、どういう時に Business skills を使うとよいか整理してみます。
なお、ナレッジベースと比較して Business skills 化することで回答精度が上がるシナリオについては、以下の記事で検証結果をまとめていますので、そちらも参考にしていただければと思います。
指示文・ナレッジ・AI プロンプトとの使い分けを考える
Business skills は、業務手順や判断基準をエージェントから利用できる形で管理するための仕組みです。
ただし、Business skills が使えるようになったからといって、すべての処理を Business skills に置き換える必要はありません。
簡単な振る舞いであれば指示文で十分ですし、文章からの情報抽出、要約、分類等であれば AI プロンプトでも実現できます。また、社内規程や FAQ の参照であればナレッジを使う方が自然です。
さらに、ツール実行やデータ登録のような処理であれば、エージェントフロー、コネクタ、MCP、ツール設定を組み合わせることで実現できるケースも多いです。
そのため、Business skills は「これまでの機能ではできなかったことを、すべて置き換える機能」というより、業務プロセスを実行時に参照できる形で分離・再利用・管理するための仕組みとして捉えるとよいと思います。
この記事では、Copilot Studio における Business skills の位置づけを、特に「コンテキストの分離」と「実行時の業務プロセス参照」という観点から整理します。
Business skills は何でも置き換える機能ではない
まず前提として、Business skills は指示文、ナレッジ、AI プロンプト、ツールをすべて置き換えるものではありません。
それぞれには向いている役割があります。
| 要素 | 主な役割 |
|---|---|
| 指示文 | エージェント全体の役割、振る舞い、制約、回答方針を定義する |
| ナレッジ | FAQ、規程、マニュアル、製品資料など、参照情報を検索・利用する |
| AI プロンプト | 入力内容をもとに、要約、分類、文面作成、変換などの定型生成を行う |
| エージェントフロー | 決定的に実行したい処理、登録、通知、承認依頼などを実行する |
| ツール / MCP | 外部システム検索、データ登録、更新、通知、承認依頼などを実行する |
| Business skills | 業務ごとの手順、確認項目、判断基準、例外対応、出力形式を管理する |
たとえば、以下のような内容であれば、無理に Business skill 化する必要はないと思います。
- 回答は箇条書きにする
- 情報が不足している場合は聞き返す
- 問い合わせ内容を要約する
- メール文面を丁寧に整える
- 入力内容をカテゴリ分類する
- 指定フォーマットで申請文を作る
- 決まった項目を受け取ってシステムに登録する
- 実行前にユーザーへ確認を取る
このような簡単な制御や単発の生成処理は、指示文、AI プロンプト、エージェントフロー、ツール設定などで十分に対応できるケースが多いです。
Business skills の価値は「業務手順を資産として管理できること」
では、Business skills はどのような場面で価値が出るのでしょうか。
大きな価値は、業務手順をエージェントの中に直接埋め込むのではなく、再利用可能な業務コンテキストとして管理できることです。
たとえば、以下のような業務では、担当者によって確認観点や判断がばらつきやすくなります。
- 経費精算の確認
- 出張申請の確認
- 備品購入申請の確認
- 契約書レビュー依頼の受付
- 入退社手続きの案内
- IT 問い合わせの一次切り分け
これらは単なる FAQ ではありません。
「何を確認するか」
「どの順番で確認するか」
「どの条件なら追加確認するか」
「どの条件なら承認やエスカレーションが必要か」
「最終的にどの形式で回答するか」
「必要に応じてどのツール実行につなげるか」
といった業務プロセスが含まれます。
このような業務手順を Business skill として切り出すことで、エージェントが必要な場面でその手順を参照しやすくなります。
ナレッジやトピック切り替えでも十分なケースはある
ここで注意したいのは、経費精算チェックや出張申請チェックのような例であっても、必ず Business skills を使うべきとは限らないということです。
たとえば、ユーザーが知りたいことが以下のような内容であれば、ナレッジでも十分に対応できる可能性があります。
- 経費精算のルールを知りたい
- 出張申請の方法を知りたい
- 領収書が必要か確認したい
- 交通費精算の上限を確認したい
- 申請期限を確認したい
- どの申請フォームを使えばよいか知りたい
このようなケースでは、社内規程、FAQ、マニュアル、申請手順書などをナレッジとして登録し、そこから回答させる構成で十分な精度が出ることがあります。
また、Copilot Studio のトピックやマルチエージェント構成を使って、問い合わせ種別ごとに参照するナレッジを切り替える設計も考えられます。
たとえば、次のような構成です。
経費精算に関する質問
→ 経費精算規程・経費精算 FAQ を参照
出張申請に関する質問
→ 出張規程・出張申請マニュアルを参照
備品購入に関する質問
→ 購買規程・備品購入申請手順を参照
契約書レビューに関する質問
→ 法務依頼手順・契約書レビュー FAQ を参照
このように、問い合わせの種類ごとに適切なナレッジへ誘導できるのであれば、無理に Business skill 化しなくてもよいと思います。
特に、ユーザーの目的が「方法を知る」「ルールを確認する」「該当箇所を調べる」ことであれば、ナレッジ中心の構成が自然です。
なお、同じナレッジで対応できる業務であっても、複数のルールを同時に組み合わせる必要があるようなシナリオでは、Business skills 化することで回答精度が上がる場合もあります。具体的な検証結果については、以下の記事も参考にしてください。
Business skills は「手順を知る」ためだけのものではない
Business skills が価値を発揮しやすいのは、ユーザーが単に手順を知りたいのではなく、エージェントに実際のタスクを進めさせたい場合です。
たとえば、以下のような依頼です。
この出張内容で申請前チェックをしてください。
来週大阪に2泊3日で出張予定です。
目的は顧客との打ち合わせで、新幹線とホテルを利用します。
この場合、エージェントには単に出張規程を説明するだけでなく、以下のような動きが求められます。
- 申請に必要な情報がそろっているか確認する
- 不足情報があれば聞き返す
- 出張目的、期間、訪問先、交通手段、宿泊有無を確認する
- 社内ルールに照らして注意点を整理する
- 必要であれば申請データ作成や承認依頼などのツール実行につなげる
- 実行前にユーザーへ確認を取る
- 最終的なチェック結果や次のアクションを一定の形式で返す
このように、Business skills は「手順を知るための情報」というより、エージェントがタスクを実行するときに参照する業務プロセス定義として考えると分かりやすいです。
ナレッジ、指示文、AI プロンプト、エージェントフローでも実行はできる
ここでさらに注意したいのは、エージェントにタスクを実行させる場合でも、必ず Business skills が必要になるわけではないということです。
ナレッジを参照してルールを確認し、その結果をもとに指示文で聞き返し方を制御し、AI プロンプトで入力内容を整形し、エージェントフローやツールで登録・通知・承認依頼を実行する、という構成も十分に考えられます。
特に最近の Copilot Studio では、ツール実行時の設定も進化しています。
たとえば、ツール実行前にユーザーへ確認を取ったり、ツールの入力値ごとに不足情報をユーザーへ確認したりできます。
参考までに、以下の記事では、Copilot Studio のツール実行時の確認や入力値の確認について整理しています。
このような機能を使えば、参照だけなら確認不要、登録前には確認する、といった制御もできます。
そのため、単純な登録処理や、必要な入力項目が明確な処理であれば、Business skills を使わずに、指示文、AI プロンプト、エージェントフロー、ツール設定の組み合わせで十分に実現できるケースもあります。
たとえば、問い合わせ登録のように、必要な項目が以下のように明確な場合です。
- 件名
- 問い合わせ種別
- 詳細
- 緊急度
- 連絡先
この場合、ツールの入力値ごとに不足情報を確認し、実行前にユーザーへ確認を取る構成でかなり対応できます。
一方で、Business skills が有効になるのは、単なる入力値の不足確認を超えて、業務プロセス全体の進め方を標準化したい場合です。
トピックやマルチエージェントとの違い
トピックやマルチエージェントを使えば、問い合わせ種別ごとに処理や参照ナレッジを切り替えることはできます。
そのため、以下のような設計は十分に有効です。
経費精算トピック
→ 経費精算ナレッジを参照して回答
出張申請トピック
→ 出張規程ナレッジを参照して回答
契約書レビュー依頼トピック
→ 法務依頼手順ナレッジを参照して回答
この構成でも、問い合わせ内容が比較的シンプルで、回答の中心が「該当する情報を探して説明すること」であれば十分に機能すると思います。
一方で、Business skills は、問い合わせ種別の切り替えというより、切り替えた後に、その業務をどう進めるかを定義するものと考えると分かりやすいです。
トピック / マルチエージェント:
どの業務領域として扱うかを切り替える
ナレッジ:
その業務領域に関する情報を参照する
AI プロンプト:
入力内容を要約・分類・整形する
エージェントフロー / ツール:
登録、通知、承認依頼などを実行する
Business skills:
その業務領域で、どの順番で確認し、どう判断し、どの形式で返すかを定義する
つまり、トピックやマルチエージェントは「入口の振り分け」に強く、ナレッジは「情報参照」に強いです。
エージェントフローやツールは「実処理」に強いです。
Business skills は、その先の「業務プロセスの進め方」を再利用可能な形で管理するところに価値があります。
指示文に全部書くと何が起きるか
もちろん、業務手順を指示文に書くこともできます。
簡単なエージェントであれば、それで十分です。
しかし、複数の業務を1つのエージェントで扱う場合、指示文にすべての業務手順を書くと、次のような問題が出やすくなります。
- 指示文が長くなりすぎる
- 関係ない業務手順まで常にコンテキストに入る
- 重要な指示が埋もれる
- 業務ごとの判断基準が混ざる
- 修正時の影響範囲が分かりにくくなる
- 複数エージェントで同じ手順を再利用しにくい
たとえば、社内業務支援エージェントを考えます。
このエージェントが、経費精算、出張申請、備品購入、契約書レビュー、入退社手続き、IT 問い合わせなどに対応するとします。
それぞれの業務には、確認すべき内容が異なります。
経費精算
- 日付
- 金額
- 用途
- 領収書
- 経費区分
- 上限金額
- 事前承認の有無
出張申請
- 出張目的
- 期間
- 訪問先
- 交通手段
- 宿泊有無
- 概算費用
- 承認者
備品購入
- 購入目的
- 品目
- 金額
- 予算区分
- 既存備品の有無
- 稟議要否
契約書レビュー依頼
- 契約種別
- 相手先
- 契約期間
- 契約金額
- 個人情報・機密情報の有無
- 希望期限
入退社手続き
- 対象者
- 入社日・退社日
- 所属部署
- 貸与物
- アカウント
- 権限
- 関係部署への連携
IT 問い合わせ
- 対象サービス
- 発生日時
- エラー内容
- 影響範囲
- 再現性
- 緊急度
これらをすべて指示文に詰め込むと、指示文はかなり長くなります。
また、ある業務では重要な確認項目が、別の業務では関係ない場合もあります。
つまり、エージェントにとっては、常に大量の業務手順がコンテキストに入っている状態になります。
Business skills は必要な場面でだけ使える業務コンテキスト
Business skills を使うと、業務ごとの手順を分けて管理できます。
たとえば、社内業務支援エージェントであれば、次のような構成が考えられます。
共通指示文:
あなたは社内業務支援エージェントです。
利用者の依頼内容を確認し、必要に応じて社内ルールや業務手順に基づいて回答してください。
情報が不足している場合は、推測せず追加確認してください。
Business skills:
- 経費精算チェック Business skill
- 出張申請チェック Business skill
- 備品購入申請チェック Business skill
- 契約書レビュー依頼 Business skill
- 入退社手続き案内 Business skill
- IT 問い合わせ一次切り分け Business skill
このようにすると、エージェント全体の指示文には共通方針だけを書き、業務ごとの細かい確認手順は Business skill として分離できます。
ユーザーが経費精算について相談した場合は、経費精算チェック Business skill を使う。
出張申請について相談した場合は、出張申請チェック Business skill を使う。
契約書レビューについて相談した場合は、契約書レビュー依頼 Business skill を使う。
このように、必要な場面でだけ必要な業務コンテキストを利用できます。
コンテキストを分離するメリット
Business skills によって業務コンテキストを分離すると、いくつかのメリットがあります。
1. 指示文をシンプルに保てる
エージェント全体の指示文には、共通方針だけを書けばよくなります。
たとえば、以下のような内容です。
あなたは社内業務支援エージェントです。
利用者の依頼内容を確認し、必要に応じて社内ルールや業務手順に基づいて回答してください。
情報が不足している場合は、推測せず追加確認してください。
個別業務の手順まで指示文にすべて書く必要がなくなるため、指示文の見通しがよくなります。
2. 関係ない業務手順が混ざりにくい
経費精算の相談をしているときに、契約書レビューや入退社手続きの詳細な手順は不要です。
Business skills を使うことで、その場面に必要な業務コンテキストだけを利用しやすくなります。
3. 業務ごとの変更に対応しやすい
業務ルールや確認項目は、後から変更されることがあります。
たとえば、出張申請の確認項目が変わった場合、出張申請チェック Business skill を修正すればよい構成にできます。
指示文の中に複数業務の手順をまとめて書いている場合に比べて、修正対象が明確になります。
4. 複数エージェントで再利用しやすい
同じ業務手順を、複数のエージェントで利用したい場合があります。
たとえば、社内ポータル用エージェント、Teams 用エージェント、部門別エージェントなどで、同じ経費精算チェック手順を使いたい場合です。
このような場合、Business skill として共通化しておくことで、再利用しやすくなります。
5. 業務手順を管理対象にしやすい
Business skill として分けることで、業務手順そのものを管理しやすくなります。
特に、確認項目、判断基準、例外対応、出力形式などを明示的に管理したい場合に向いています。
Business skills を使う判断基準
Business skills を使うかどうかは、「その処理を実行できるか」だけで判断しない方がよいと思います。
指示文、ナレッジ、AI プロンプト、エージェントフロー、ツール設定を組み合わせれば、多くの処理は実現できます。
そのうえで Business skills を検討するのは、業務プロセスそのものを分離・再利用・管理したい場合です。
たとえば、以下のようなケースです。
- 複数の確認項目を、業務上意味のある順序で確認したい
- 条件によって確認項目や次アクションが変わる
- ナレッジ参照後の判断プロセスを標準化したい
- 複数のツール実行を、業務手順に沿って組み合わせたい
- 実行前確認、差し戻し、エスカレーションなどの例外対応も含めて標準化したい
- 同じ業務プロセスを複数のエージェントで再利用したい
- 業務手順を指示文から切り出し、管理対象として扱いたい
ただし、これらのうち「同じ業務プロセスを複数のエージェントで再利用したい」というシナリオが、市民開発者の現場で実際にどれくらい出てくるかは、個人的にはもう少し冷静に見極めたいと思っています。
これまでお客様から相談を受けてきた感覚では、Copilot Studio で作るエージェントは「特定の部署・特定の業務に閉じた1台」というケースが多い印象で、複数のエージェントへ横展開して共通スキルを参照させたいというご相談は稀です。
そのため、Business skills の「再利用」の側面が現場で力を発揮する場面がどれくらい出てくるかは、引き続きお客様の支援を通じて見極めていきたいと考えています。
逆に、以下のような場合は、Business skills まで使わなくてもよい可能性があります。
- ルールや方法を回答するだけ
- 参照すべきナレッジを切り替えれば十分
- 入力項目が少なく、条件分岐も少ない
- ツールの入力値確認と実行前確認で足りる
- 一つのエージェントだけで使う短い手順である
- 業務プロセスとして再利用・管理する必要がない
使い分けのまとめ
まとめると、次のように整理できます。
| やりたいこと | 向いているもの |
|---|---|
| 社内ルールや申請方法を回答したい | ナレッジ |
| 問い合わせ種別ごとに参照先を変えたい | トピック / マルチエージェント |
| 簡単な出力形式や聞き返し方を指定したい | 指示文 |
| 文章の要約・分類・整形をしたい | AI プロンプト |
| システム登録・通知・承認依頼をしたい | エージェントフロー / ツール / MCP |
| ツール実行前にユーザー確認を取りたい | ツール設定 |
| 業務ごとの確認順序・判断基準・例外対応を標準化したい | Business skills |
| 同じ業務手順を複数エージェントで再利用・管理したい | Business skills |
まとめ
今回は、Copilot Studio における Business skills の位置づけと、他機能との使い分けを整理してみました。Copilot Studio でエージェントを作成する方の中には、機能が更に増えてきて混乱する可能性もあると思います。そのような方にとって参考になれば幸いです。