社内でAIツールを使い始めたとき、最初に頭を悩ませるのは「勝手な使い方をされないか」という不安です。特に情シスや管理部門の担当者は、承認していないAPIや外部サービスに接続されてしまうリスクを常に意識しています。MicrosoftがPower Platformのロードマップに追加したMaker Guidelinesは、そうした不安を解消するための仕組みのひとつです。この記事では、この機能が具体的に何をするものなのか、中小企業の管理部門がどう活用できるかを整理します。
そもそもCopilot Studioとは

Copilot Studio(コパイロット スタジオ)は、Microsoftが提供するAIエージェントの作成ツールです。コードを書かなくても、チャットボットや業務アシスタントを社内向けに作成・公開できる環境で、Microsoft 365やPower Platformのライセンスに含まれているプランもあります。社内の問い合わせ対応を自動化したい、よくある申請手続きをチャットで完結させたい、といった用途で使われ始めている企業が増えています。
開発者(Microsoftの用語では「メーカー」と呼ばれます)が自由にエージェントを作れる点が強みである一方、どのコネクタ(外部サービスとの接続口)を使っていいか、どのAIモデルを使っていいか、そういったルールが組織内で統一されていないと、管理者がいつの間にか意図しない構成のエージェントが動いている状態になりかねません。
Maker Guidelinesが解決しようとしている問題
AIツールの社内展開において、多くの情シス担当者が直面しているのは「ルールを作っても伝わらない」という課題です。たとえばSharePointにガバナンス方針を公開しても、メーカーがそれを確認してから作業するとは限りません。ツールを操作している最中に気づいてもらえる場所に情報を置かないと、ポリシーは形骸化します。
Maker Guidelinesは、Copilot Studio上のReview(レビュー)ペインに管理者のメッセージを表示する機能です。このReviewペインはもともとエージェントの警告やブロッカー(設定上の問題)が表示される場所で、メーカーが公開前に必ず確認するパネルです。エージェントに問題がない状態でも、メッセージは表示され続けます。つまり、「使っていい機能のリスト」「申請が必要な場合の連絡先」「参照すべき社内ポリシー」を、メーカーが作業の流れの中で自然に目にできる形で届けられるようになります。
管理者が設定できる内容
Maker Guidelinesで管理者が記載できる情報は大きく4種類に整理できます。実際にどの会社でも使いやすい構成として、以下のような内容が想定されています。
- 承認済みのツール・AIモデル・コネクタの一覧
- 承認されていない機能を使いたい場合のリクエスト手順
- 参照すべき社内ポリシーの場所(社内Wikiや規程文書のURL)
- 疑問が生じたときの問い合わせ先(情シス担当者名・メールアドレス等)
設定は環境(Environment)ごとに行うため、部門別・用途別に異なるルールを適用することも可能です。たとえば「営業部門向け環境では社外向けチャンネルの公開を許可するが、経理部門向け環境では内部向けのみ」という使い分けができます。
従業員30人規模の会社で起きやすいシナリオ
従業員が30人程度の会社で、情シス専任が1名しかいないケースを考えてみます。この規模だと、Microsoft 365 Business Premiumなどのプランを契約していれば、Power PlatformやCopilot Studioの機能が利用可能な状態になっていることがあります。担当者が把握していないうちに、営業担当者がCopilot Studioで外部向けチャットボットを作り始め、承認されていないコネクタで顧客データベースに接続していた、というのは現実に起きやすい話です。
Maker Guidelinesを事前に設定しておけば、そのメーカー(この場合は営業担当者)がReviewペインを確認したとき、「このコネクタを使う前に情シスへの申請が必要です」「承認済みコネクタの一覧はこちら」という案内が表示されます。ルールを知らなかった、という状況をある程度防げるようになります。情シス担当者にとっては、ポリシー違反を後から発見して指摘するより、手を動かしている段階で気づいてもらう方がずっと負担が少ないはずです。
既存のガバナンス手段と何が違うか
Power Platformにはすでに管理者向けのガバナンス機能がいくつかあります。DLP(データ損失防止)ポリシーでコネクタの使用を制限したり、環境ごとにアクセス権を設定したりする仕組みは以前から存在しています。Maker Guidelinesはこれらの制限機能を置き換えるものではなく、補足として機能します。
下表で整理すると、それぞれの役割の違いが分かりやすくなります。
| 機能 | 役割 | タイミング |
|---|---|---|
| DLPポリシー | コネクタの使用を技術的にブロック | エラーが出て使えない |
| 環境アクセス制御 | そもそも環境に入れないようにする | アクセス前に制限 |
| Maker Guidelines | 承認ルールや連絡先を案内する | 作業中に表示 |
DLPポリシーは「ブロックする」仕組みなので、なぜ使えないのかメーカーが理解できないまま止まってしまうことがあります。Maker Guidelinesは「なぜこのルールがあるか」「どうすれば使えるか」を伝える文脈説明の役割を担います。技術的な制御と人間への説明の両方が揃って、はじめてガバナンスが機能すると考えると、この機能の位置づけが分かりやすくなります。
中小企業でAI利用ルールの周知がうまくいっていない実態
中小企業のAIツール管理の現状を見ると、利用ルールの「作りっぱなし」問題が目立ちます。社内向けAI活用の実態調査(複数の中小企業向けコミュニティでの聴取をもとにした情報)では、「ガイドラインは作ったが読まれているか確認できない」という声が多く、ルールをドキュメントとして公開するだけでは周知効果が低いと感じている管理担当者が多い状況があります。また、「想定外の使い方が起きてから初めてルールの穴に気づいた」という経験を持つ担当者も少なくありません。
Maker Guidelinesのような「作業の流れの中でルールを表示する」アプローチは、まさにこの課題へのひとつの回答です。ガイドラインの存在を知らなかった、見つけられなかった、という言い訳が成立しにくくなります。社内AI活用のプロンプト設計と合わせてルールを整備することで、担当者任せにならない仕組みが作れます。
導入前に確認しておくこと
Maker Guidelinesを使うには、Microsoft Power PlatformのAdmin Center(管理センター)にアクセスできる管理者権限が必要です。機能はPower Platformのガバナンスと管理のロードマップに含まれており、2026年中の展開が予定されています(Microsoftのロードマップ更新状況によって時期が変わる可能性があります)。
利用できるプランについては、Copilot Studioが含まれているライセンス(Microsoft 365の一部プランや、Copilot Studio単体のサブスクリプション)の契約が前提です。Microsoft 365 Business Premiumでは一定のPower Platform機能が使えますが、Copilot Studioをフル活用するには追加のライセンスが必要な場合があります。現在の契約内容と照らし合わせて確認することをお勧めします。
Copilot Studioを組織でまだ使っていない場合でも、この機能の存在を把握しておくことには意味があります。「AIエージェントを作れる環境を社員に開放するとき、どうガバナンスを組むか」は、ツールを導入する前に設計しておくべき問題だからです。ChatGPTなど他のAIツールの社内展開でも共通する考え方で、承認フローと案内の仕組みをセットで用意するアプローチは参考になります。
まとめ
AIツールを社内に展開するとき、技術的な制限だけでは不十分で、「なぜこのルールがあるか」「どうすれば使えるか」を伝える仕組みが別途必要になります。Maker Guidelinesはその役割をCopilot Studioの操作画面の中で担うもので、ガバナンスを「後から追いかける」状態から「先に案内する」状態へ変えるための機能です。
現時点でCopilot Studioを使っていない場合でも、今後AIエージェントを社内展開する際に同様の課題に直面します。社内のAI利用承認フローをどこで・どのタイミングで伝えるかを、ツールの選定と並行して考えておくと、後で慌てずに済みます。自社の承認フローをどこに置くべきか迷う場合は、AI導入支援の専門家に相談する選択肢もあります。


