Microsoft Copilot Studio で AIエージェントを作り始めたものの「Topic と Action と Knowledge の使い分けがわからない」「M365 Copilot との連携で詰まる」「IT 部門のガバナンス要件をどう満たすか」で止まっている開発者・PM が多い。実際に弊社の研修・コンサル現場でも、Power Platform 経験者ですら設計段階で 1〜2 週間ハマるケースを何度も見てきた。
この記事では Microsoft Copilot Studio で本番運用に耐えるエージェントを構築するための実装プロンプト・チェックリスト・テンプレートを、Maker portal の操作順に沿って 20 個まとめた。コピペで使える Topic 設計テンプレ、Action（Connector）の権限スコープ設計、Knowledge ソースの優先順位、DLP（データ損失防止）ポリシー、Azure OpenAI 接続、Microsoft 365 Copilot 拡張までを一気通貫で扱う。
対象は「Power Platform 管理者経験ありで、初めて本格的なエージェント設計を任された開発者・PM」。所要時間の目安は読み通し 30 分、テンプレ適用しながら作業すると 1 エージェント 2〜4 時間で本番下書きまで進む。
結論：Copilot Studio 設計の 3 つの分岐軸
本論に入る前に、Copilot Studio を扱うときに最初に押さえるべき 3 つの設計分岐を提示する。これを最初に決めれば残りの作業は実装フェーズに落ちる。
- ① ホスト先：スタンドアロン Copilot Studio エージェント（独立 URL・Teams 配布）か、Microsoft 365 Copilot のエージェント拡張（M365 Copilot のチャット内で呼ばれる）か。前者は外部ユーザー対応・独立 UI、後者は社内 M365 ユーザー前提
- ② 知識（Knowledge）の置き場所：SharePoint / OneDrive / Dataverse / 外部 URL / Graph connectors のどれを一次ソースにするか。RAG 範囲とアクセス権が決まる
- ③ アクション（Action）の権限境界：ユーザー認証で動くか（OBO: On-Behalf-Of）、サービスプリンシパル/接続参照で動くか。前者は本人権限・監査容易、後者は権限の一元管理・運用容易
この 3 分岐を決めずに Maker portal を触り始めると、Topic を書いた後で「Knowledge が引けない」「権限エラーで Action が呼べない」と手戻りが必ず発生する。順序は ホスト先 → 権限境界 → Knowledge 置き場所 → Topic → Action → テスト → 公開 がベスト。
Copilot Studio の構成要素：用語整理
Microsoft Copilot Studio は、旧 Power Virtual Agents を拡張し、生成 AI ネイティブの設計思想に作り直されたローコード／プロコード両対応のエージェント構築プラットフォームである。Maker portal（make.powerautomate.com 系の URL 体系で開かれる）から作成し、Power Platform 環境（Environment）に紐づく。
主要構成要素を Microsoft Learn の用語に従って整理する。
- Agent：エージェント本体。1 エージェント = 1 ペルソナ + 1 instructions セット + 複数 Topic + 複数 Action + 複数 Knowledge
- Topic：会話の単位。トリガーフレーズ（ユーザー発話）または別 Topic からの遷移で起動し、ノードの連なりで応答を組み立てる
- Action：外部システムを呼ぶ単位。コネクタ（700+ の Power Platform コネクタ）、Power Automate フロー、カスタム HTTP、Prompt action（生成 AI 直接呼び出し）、MCP（Model Context Protocol）サーバーなどを束ねる
- Knowledge：エージェントが参照する社内知識。SharePoint・OneDrive・Dataverse テーブル・公開 URL・ファイルアップロード・Graph connectors を登録できる
- Generative orchestration：ユーザー発話を LLM が解釈し、どの Topic / Action / Knowledge を呼ぶかを判定するモード。従来の Classic（トリガーフレーズ完全一致）から推奨設定が切り替わった
- Channels：配布先。Teams、Microsoft 365 Copilot、Web、Slack、Facebook、カスタムサイト埋め込みなど
このうち、設計の中心になるのは Topic（会話設計） と Action（外部連携） と Knowledge（RAG） の 3 つだ。以下、それぞれの実装プロンプト・テンプレを順に扱う。
Step 1：エージェントの「指示（Instructions）」テンプレ
新規エージェント作成時に最初に書くのが instructions（system prompt 相当）。ここの良し悪しで残りの設計工数が 2 倍変わる。よくある失敗は「営業アシスタントです」だけ書いて、後の Topic で同じことを毎回繰り返す書き方。
Instructions テンプレ（コピペ可）
あなたは「{エージェント名}」です。
【ペルソナ】
- 役割：{例：社内営業向けの提案書作成アシスタント}
- 対象ユーザー：{例：当社の法人営業部所属の社員}
- 口調：丁寧・簡潔。1 回の応答は箇条書きを優先し、3〜5 行に収める
【できること】
- {Topic / Action / Knowledge で実装した機能を 3〜7 個列挙}
- 例：1) 過去の提案書の検索 2) 見積もりの草案作成 3) 競合製品との比較表生成
【できないこと（重要）】
- 契約条件の確定回答（必ず法務に確認するよう案内する）
- 個人情報の照会（社員番号等は扱わない）
- {他にも明示的に NG にしたいタスクを列挙}
【応答ルール】
- 知らない / 自信がないことは「分かりません」と答え、Knowledge 検索で 0 件のときは「該当する社内資料が見つかりませんでした。{担当部署} にお問い合わせください」と返す
- 推測で数字や日付を回答しない。出典が必要な場合は Knowledge から引用元 URL を併記する
- 外部に公開できない情報（{例：未発表の製品名・価格}）を質問されたら回答を拒否する
【動作モード】
- ユーザーの依頼が複数ステップに分かれる場合、最初に作業計画を 3〜5 行で提示してから実行する
- Action を呼ぶ前に、入力パラメータをユーザーに確認する（金額・宛先・件数など、間違えると影響が大きいもの）
この instructions は generative orchestration を有効にした場合に最も効果を発揮する。Classic モード（トリガーフレーズ完全一致）では一部のルールが無視される。
Instructions 設計チェックリスト
- ペルソナと対象ユーザーが 1 行で書けているか
- 「できること」が Topic/Action/Knowledge と 1 対 1 で対応しているか
- 「できないこと」を 明示的に書いているか（暗黙の NG では LLM は守らない）
- 知らない時の応答ルールがあるか（ハルシネーション抑制）
- Action 呼び出し前の確認ルールがあるか（誤実行防止）
Step 2：Topic 設計の実践テンプレ 5 種
Topic は「ユーザーの発話を起点にした会話の流れ」を定義する。Microsoft 公式ドキュメントでは Topic は「1 つの会話目的（intent）に対して 1 つ」と推奨されている。複数の目的を 1 Topic に詰めるとメンテ不能になる。
テンプレ A：Knowledge Q&A 型 Topic
社内資料に答えがあるタイプの質問用。Knowledge をそのまま呼ぶ場合、Topic を作らず generative answers に任せる選択もあるが、「特定カテゴリの質問だけ別ソースを当てたい」「回答前に確認したいことがある」場合は Topic を切る。
Topic 名：社内規程の質問
【トリガーフレーズ（5〜10 個）】
- 就業規則について教えて
- 残業申請の方法
- 有給休暇の取得手順
- 育児休業の制度
- 社内ルール
【ノード構成】
1. Trigger
2. Question：「どの規程についてですか？（就業規則 / 経費規程 / 情報セキュリティ / その他）」
- 変数：rule_category（選択肢 4 つ）
3. Branch（rule_category で分岐）
- 就業規則 → Knowledge search（source: SharePoint「人事規程」サイト限定）
- 経費規程 → Knowledge search（source: SharePoint「経理規程」サイト限定）
- 情報セキュリティ → Knowledge search + 「最新版は infosec@ に確認してください」を必ず添える
- その他 → 自由質問として Knowledge 全体検索
4. Message：検索結果 + 引用元 URL
5. Question：「他に確認したいことはありますか？（はい / いいえ）」
6. End / Loop back to step 2
ポイントは Knowledge source をカテゴリごとに絞り込むこと。全社の SharePoint を 1 つの巨大 Knowledge にすると関係ない文書を引いてくる事故が起きる。
テンプレ B：Action 起動型 Topic（承認フロー連動）
外部システムを呼ぶタイプ。Power Automate のフロー、Dataverse、Outlook、Teams、外部 SaaS のコネクタを呼び出す。
Topic 名：経費精算の申請
【トリガーフレーズ】
- 経費を申請したい
- 経費精算
- レシートを提出
【ノード構成】
1. Trigger
2. Authenticate（OBO で実行ユーザーのトークン取得）
3. Question：「申請内容を教えてください」
- 変数：expense_type（交通費 / 接待費 / 備品費 / その他）
- 変数：amount（数値）
- 変数：date（日付）
- 変数：description（文字列）
4. Question：「レシート画像を添付してください」
- 変数：receipt（ファイル）
5. Confirmation message：入力内容のサマリーを提示
6. Question：「この内容で申請しますか？（はい / いいえ）」
7. Action：Power Automate フロー「ExpenseSubmit」を呼ぶ
- 入力：上記 5 変数
- 出力：approval_id、status
8. Branch：status
- "submitted" → 「申請番号 {approval_id} で受け付けました」
- "error" → 「申請に失敗しました。{error_message}」を表示し、人手対応案内
9. End
ここで重要なのは Action 呼び出し前の Confirmation node。金額・宛先など「間違えると影響が大きいパラメータ」は LLM 任せにせず、必ずユーザーに確認させる。
テンプレ C：エスカレーション Topic
Copilot Studio で答えられない・答えるべきでない質問を人手に渡す Topic。System Topic の「Escalate」をベースにカスタマイズする。
Topic 名：人にエスカレーション
【トリガーフレーズ】
- 担当者と話したい
- 人間と話したい
- このボットでは無理
- escalate
- (System Topic「Confusion」「Escalate」から自動遷移)
【ノード構成】
1. Trigger
2. Question：「どの部門の担当者にお繋ぎしますか？（IT / 人事 / 経理 / 営業）」
3. Branch：dept で分岐
- IT → Teams メッセージ送信（service-desk@ チャネル）
- 人事 → メール送信（hr@）
- 経理 → メール送信（accounting@）
- 営業 → Teams メッセージ送信（sales-help@ チャネル）
4. Action：エスカレーション元の会話履歴（過去 5 ターン）を本文に含める
5. Message：「{dept} に転送しました。担当者から {SLA} 以内に連絡が入ります」
6. End
会話履歴を含めずに「人事にエスカレーション」とだけ送ると、受け手の担当者が「で、何の話？」になる。過去 5 ターン分のコンテキストを本文に含めるのが運用上のコツ。
テンプレ D：マルチターン要件ヒアリング Topic
顧客対応・ヒアリング・予約取得など、複数の情報を順に集める必要がある Topic。
Topic 名：問い合わせ受付
【トリガーフレーズ】
- 問い合わせしたい
- 質問がある
- 相談に乗ってほしい
【ノード構成】
1. Trigger
2. Question：「お困りごとを 1 文で教えてください」
- 変数：issue_summary
3. Adaptive question（generative）：以下を 1 つずつ確認
- 製品名 / サービス名（変数：product）
- 発生日時（変数：when）
- エラー内容 / 症状（変数：symptom）
- 緊急度（変数：urgency = high/medium/low）
4. Knowledge search：症状・製品名で社内 KB を検索
5. Branch：検索結果あり ?
- あり → 解決策提示 → 「解決しましたか？」
- なし → Topic「人にエスカレーション」へ遷移（変数を引き継ぐ）
6. End
Adaptive question は generative orchestration を有効にすると「LLM がまだ未取得の変数を順に聞いてくれる」モードになる。Classic モードでは固定順になる。
テンプレ E：プロンプトアクション内蔵 Topic（要約・翻訳・分析）
Topic 内で Prompt action（生成 AI 直接呼び出し）を埋め込むパターン。Action タイプのうち「Prompt」を選び、AI Builder のプロンプトを Topic から呼ぶ。
Topic 名：議事録要約
【トリガーフレーズ】
- 議事録を要約して
- ミーティングメモをまとめて
【ノード構成】
1. Trigger
2. Question：「議事録のテキストを貼り付けるか、ファイルを添付してください」
- 変数：minutes_text（テキスト or ファイル抽出後のテキスト）
3. Prompt action：要約 + 決定事項抽出 + ToDo 抽出
- 入力：minutes_text
- System prompt：「以下の議事録を、(1) 議題サマリー 3 行、(2) 決定事項箇条書き、(3) ToDo 一覧（担当・期限つき）の 3 セクションで日本語出力してください。発言者が不明な ToDo は『担当未定』と書いてください」
- 出力：summary_md
4. Adaptive card：summary_md を整形表示
5. Question：「この要約を Teams のどのチャネルに投稿しますか？（自分の DM / 指定チャネル / 投稿しない）」
6. Branch：選択肢で分岐
7. End
Topic 内で Prompt action を使う利点は、generative orchestration が勝手に呼ぶ「自由応答」と違い、入力スキーマ・出力スキーマが固定できること。後工程の Action にそのまま渡せる。
Step 3：Action（外部連携）設計
Action は Copilot Studio で「外部システムに何かさせる」全ての入り口。種類は大別して 5 つある。
- Connector action：Power Platform の 700+ コネクタを直接呼ぶ（Outlook、SharePoint、Dataverse、Salesforce、ServiceNow など）
- Power Automate flow action：既存の Power Automate クラウドフローを呼ぶ
- Prompt action：AI Builder のプロンプト（=生成 AI 単発呼び出し）を呼ぶ
- HTTP action（カスタムコネクタ）：任意の REST API を呼ぶ
- MCP server action：MCP（Model Context Protocol）サーバーを Copilot Studio に登録して、そのサーバーが公開する tools を呼ぶ
Action 設計のチェックリスト（必読）
- Description は LLM が読む：generative orchestration では Action の description を LLM が読んで「この発話ならこの Action を呼ぶ」と判定する。「経費精算フォームを Dataverse に書き込みます」のような具体的な動詞 + 対象で書く
- 入力パラメータの description も書く：「金額（税抜の数値・円単位）」のように、LLM が抽出に迷わない粒度で
- 権限境界を明示する：OBO（呼び出しユーザーの権限）か、接続参照（固定の Service Account）か。OBO は監査が容易、接続参照は権限管理が容易
- 失敗時のエラー応答を統一する：すべての Action でエラー時に「status: error, message: 人間が読める日本語メッセージ」を返すと、Topic 側の Branch が単純化する
- 冪等性を担保する：同じ Action を 2 回呼ばれても安全か（重複申請・二重課金が起きないか）。idempotency key を入力に含めるのが定石
Action description テンプレ
【Action 名】CreateExpenseRequest
【Description（LLM 向け）】
社員が経費精算を申請するときに呼ぶ。
入力された経費種別・金額・日付・説明・レシート画像を Dataverse の ExpenseRequest テーブルに新規レコードとして登録する。
登録が成功すると申請番号（10 桁の英数字）が返る。
似た用途で「経費の状況確認」「過去の申請の一覧」を聞かれた場合は、本 Action ではなく ListExpenseRequests を使う。
【入力パラメータ】
- expense_type（string, 必須）：経費種別。"交通費" "接待費" "備品費" "その他" のいずれか
- amount（number, 必須）：金額（税抜・円単位の整数。1 円未満は四捨五入）
- expense_date（date, 必須）：経費発生日（ISO 8601, YYYY-MM-DD）
- description（string, 必須）：用途・相手先・場所などの説明（10〜200 文字）
- receipt_url（string, 任意）：レシート画像の URL。SharePoint アップロード済みのもの
【出力】
- request_id（string）：申請番号（10 桁）
- status（string）："submitted" or "error"
- message（string）：人間向け日本語メッセージ
これだけ書いておけば、generative orchestration が「先月の交通費 3,500 円を申請」のような曖昧な発話からも、ユーザーに足りない情報（説明文・日付）を聞き返しながら Action を呼べる。
Action 権限境界：OBO vs 接続参照の選び分け
| 観点 | OBO（ユーザー認証） | 接続参照（Service Account） |
|---|---|---|
| 誰の権限で動くか | 呼び出しユーザー本人 | 固定のサービスアカウント or 接続参照 |
| 監査ログ | 個人単位で残る | サービスアカウント単位（誰が呼んだかは Copilot Studio 側ログで確認） |
| 権限変更 | 個別ユーザーの権限変更で挙動が変わる | 接続参照側で一元管理 |
| 適した用途 | 本人の OneDrive / Outlook / 個人 Dataverse 行を扱う | 共通マスタへの書き込み、SaaS API（Salesforce 共通アカウントなど） |
| 失敗パターン | 権限のないユーザーが Action 呼んでエラー | 権限が広すぎて意図しないデータが操作される |
原則は 「個人のデータは OBO、共有のデータは接続参照」。両方混ぜると監査が複雑になるので、エージェント単位でなるべく統一する。
Step 4：Knowledge（RAG）設計
Copilot Studio の Knowledge は、エージェントが応答時に参照する「社内知識ベース」。生成 AI ネイティブな RAG（Retrieval Augmented Generation）として動く。
Knowledge ソースの優先順位（推奨）
- SharePoint Online のドキュメントライブラリ：最も安定。アクセス権がそのまま継承される（OBO）
- OneDrive for Business：個人配下のファイル。ユーザー個人のエージェントには有効、共有エージェントには不向き
- Dataverse テーブル：構造化データ。FAQ テーブル、製品マスタなど
- 外部公開 URL：自社の公開 Web サイト・公開ドキュメント。クロール頻度に制限あり
- ファイルアップロード（PDF/DOCX/PPTX/XLSX/MD/TXT）：エージェント本体に紐づく。サイズ制限あり、更新時は手動再アップロード
- Microsoft Graph connectors：Confluence、Jira、Salesforce、ServiceNow など外部 SaaS を Graph 経由でインデックス
Knowledge 設計の落とし穴 5 つ
- 1 つの巨大 SharePoint サイトを丸ごと食わせる → 関係ない文書が引かれる。サブサイト・サブフォルダ・タグで絞る
- 機密文書を Knowledge に含める → アクセス権なしユーザーには見えない設計になっているが、本当に守りたい文書は別エージェント（別環境）に分離するほうが安全
- 同じ内容の古い版と新しい版が両方インデックスされる → 古い数字を引いて回答する事故が頻発。SharePoint の版管理で「最新版のみ公開」フォルダを別途用意し、Knowledge にはそれだけを登録
- PDF の画像内文字（スキャン PDF）が検索できない → OCR 済みファイルに置き換えるか、Microsoft Syntex などで OCR 処理
- 引用元 URL がエージェント応答に出ない → instructions と Topic で「引用元 URL を必ず併記する」と明示する
Knowledge 接続テンプレ（SharePoint）
【Knowledge 名】社内人事規程
【ソース】SharePoint Online
【URL】https://{tenant}.sharepoint.com/sites/HR-Policies/Shared%20Documents/Published
【設定】
- 検索対象：上記フォルダ配下のみ（サブフォルダ「下書き」「履歴」は除外）
- 認証：OBO（呼び出しユーザーの権限を継承）
- 更新頻度：自動（Microsoft 365 検索インデックスに準ずる）
【含めるファイル種別】
- .docx（規程本文）
- .pdf（正式版）
- .xlsx（料率表・限度額表）
【除外するファイル種別】
- .pptx（プレゼン資料・古い説明会資料）
- .png/.jpg（添付画像のみのファイル）
Knowledge 設計チェックリスト
- 1 Knowledge = 1 ドメイン（人事、経理、製品 A、製品 B など）に分かれているか
- 古い版が混ざらない仕組みになっているか
- OBO（個人権限）と固定権限の使い分けが明示されているか
- 機密情報が混ざっていないか（混ざっている場合は別エージェントに分離）
- 応答に引用元 URL が出る設定になっているか
Step 5：Power Platform 連携テンプレ
Copilot Studio は Power Platform の一員なので、Power Automate / Power Apps / Power BI / Dataverse とネイティブに連動する。
連携パターン A：Power Automate フローを Action として呼ぶ
既存の業務フロー（承認・通知・データ同期）を Copilot Studio から呼ぶ最頻出パターン。
【手順】
1. Power Automate 側でフローを作成（トリガー：「Copilot から呼び出されたとき」を選ぶ）
2. 入力パラメータを定義（型・必須フラグ・description）
3. フロー本体を実装（承認・メール・Dataverse 書き込みなど）
4. レスポンス（「Copilot に返す」アクション）で出力スキーマを定義
5. Copilot Studio 側で Action として「Power Automate フロー」を選び、上記フローを指定
6. Topic から Action を呼ぶ
【description の書き方（フロー側で書く）】
「経費精算の申請を承認ワークフローに投入する。
入力された 5 つのパラメータを Dataverse に書き込み、上長への承認依頼メールを送信する。
所要時間は 1〜3 秒。承認自体は人間がかかるため非同期」
連携パターン B：Dataverse テーブルを Knowledge として登録
製品マスタ・FAQ・顧客マスタなど構造化データを直接エージェントに参照させたい場合、Dataverse テーブルを Knowledge に登録する。
【手順】
1. Dataverse でテーブルを作成（例：cr_product_faq）
2. カラム：question（テキスト）、answer（テキスト）、category（選択肢）、updated_at（日時）
3. Copilot Studio の Knowledge に「Dataverse」を選択し、上記テーブルを追加
4. インデックス対象カラムを指定（question + answer）
5. テスト発話で確認
【利点】
- 更新がリアルタイム（SharePoint よりインデックス遅延が小さい）
- カラム単位で検索対象を制御できる
- Power Apps から FAQ を編集する画面を作れば、IT 不要で社内が運用できる
連携パターン C：Power BI の数値を会話で取得
「先週の売上は？」のような数値質問を Copilot Studio で受けて Power BI から答える構成。
【手順】
1. Power BI で対象データセットに「Q&A」機能を有効化
2. Copilot Studio で Action「Power BI: Execute query」を作成
3. 入力：自然文クエリ（例：「先週の関東地区の売上合計」）
4. 出力：数値 + 単位 + データ更新日
5. Topic：質問パターンを定義し、Action を呼んで結果を整形表示
【失敗パターン】
- データセットが「個人」所有のままだと社内全員から呼べない → ワークスペース化が必須
- 数値の前提（税抜/税込、円/千円）が応答に出ない → instructions で「数値は常に税抜・円単位で答える」と明示
Step 6：Microsoft 365 Copilot へのエージェント拡張
Copilot Studio で作ったエージェントを、Microsoft 365 Copilot のチャット（Word、Excel、Teams、Outlook、Edge の Copilot ペイン）から呼べるように公開できる。これがいわゆる 「agents in Microsoft 365 Copilot」。
M365 Copilot 拡張のメリット・デメリット
| 観点 | スタンドアロン Copilot Studio エージェント | M365 Copilot のエージェント拡張 |
|---|---|---|
| 配布範囲 | 外部ユーザー含めて誰でも（Web 公開・Teams 配布） | M365 ライセンス所持者のみ |
| 追加ライセンス | Copilot Studio のメッセージ消費（容量課金） | M365 Copilot ライセンス必須（ユーザー単位） |
| UI | 独立した Web チャット UI | M365 Copilot のチャット内に @エージェント名 で呼ばれる |
| コンテキスト共有 | 個別の会話履歴 | M365 Copilot 側の会話履歴・添付ファイルを引き継げる |
| 適した用途 | 顧客向け・外部ユーザー向け・社内でも独立 UI を出したいもの | 社員が Word/Outlook 編集中に呼ぶ業務アシスタント |
M365 Copilot 拡張の公開手順
1. Copilot Studio Maker portal でエージェントを開く
2. 「Channels」タブ →「Microsoft 365 Copilot」を有効化
3. 公開対象（テスト：自分のみ / プレビュー：指定ユーザー / 本番：全社）を選ぶ
4. M365 管理センター（admin.microsoft.com）の「統合アプリ」で承認
- IT 管理者が承認しないと社員からは見えない
5. M365 Copilot のチャット画面で「Get agents」/「エージェントを取得」から有効化
6. 「@エージェント名」で呼べることを確認
M365 Copilot 拡張時の設計上の注意
- 呼び出しは「@エージェント名」が前提：名前は短く、社内のほかのアプリ・部署と被らないものに（例：「ExpensePal」「HRBot」など）
- M365 Copilot 自体の Knowledge と二重インデックスになる可能性 → エージェント固有の Knowledge と M365 Copilot 既定の Graph 検索のどちらが優先されるかを明示
- 添付ファイル受け渡しは M365 Copilot のチャット内ファイルが渡される。Topic 側で「添付ファイルがある場合の処理」を必ず定義
- M365 ライセンス必須を社員に明示。導入時に「M365 Copilot ライセンス購入済みの部署のみ利用可」とアナウンスする
Step 7：Azure OpenAI 接続とカスタムモデル
Copilot Studio は既定で Microsoft が提供する基盤モデル（GPT 系）を使うが、企業独自の Azure OpenAI リソースに接続するパターンもよく使われる。理由は (1) データ常駐地域の制御、(2) 既存の Azure OpenAI 課金枠の活用、(3) ファインチューニング済みモデルの利用。
Azure OpenAI 接続のユースケース
- カスタムプロンプトアクションで Azure OpenAI を直接呼ぶ（Prompt action 内で endpoint と API key を指定）
- HTTP アクション経由で Azure OpenAI Chat Completions / Assistants API を呼ぶ
- Azure AI Search を Knowledge として登録し、Copilot Studio から RAG を回す
Azure OpenAI 接続テンプレ（カスタムコネクタ）
【カスタムコネクタ定義】
- 名前：AzureOpenAI-ChatCompletions
- ホスト：{your-resource}.openai.azure.com
- ベースパス：/openai/deployments/{deployment-name}
- 認証：API key（Header: api-key）
【アクション：CreateChatCompletion】
- メソッド：POST
- パス：/chat/completions?api-version=2025-04-01-preview
- リクエスト body：
{
"messages": [{"role":"system","content":"{system}"},{"role":"user","content":"{user}"}],
"temperature": 0.2,
"max_tokens": 1500
}
- レスポンス：choices[0].message.content を出力
【Copilot Studio 側】
- Topic 内で HTTP request node を使い、上記カスタムコネクタを呼ぶ
- 入力：system プロンプト・user プロンプト
- 出力：応答テキスト
カスタムモデル利用時の注意
- 応答時間が遅くなる：基盤モデル直接呼び出しより 1〜3 秒遅延が増える。Topic の最初に「処理中…」のメッセージを出す
- コスト管理：トークン課金が別途発生。Power Platform 管理センターの容量管理とは別に Azure 側でも監視
- 機密データの送信：Azure OpenAI に送るデータの分類が「機密」以上なら、リージョン・データ保管設定（Customer Managed Keys 含む）を IT セキュリティと事前確認
- 応答スキーマの統一：複数モデル（標準モデル / Azure OpenAI / プロンプトアクション）を混在させる場合、出力フォーマットを統一して Topic 側の処理を共通化
Step 8：エンタープライズガバナンス設定
Copilot Studio を全社展開するときに IT 部門・情報セキュリティ部門から必ず聞かれる項目をテンプレ化した。
ガバナンス チェックリスト（公開前必須）
- 環境（Environment）分離：開発・ステージング・本番でそれぞれ Power Platform 環境を分け、本番環境は管理者のみが作成・公開できる権限に
- DLP（データ損失防止）ポリシー：Power Platform 管理センターで、コネクタを「ビジネス」「非ビジネス」「ブロック」に分類。エージェント本番環境では機密データを扱うコネクタ群を一つのカテゴリに固める
- テナント分離：認可されたテナントとのみ通信するように Cross-tenant access settings を設定
- 監査ログ：Microsoft Purview Audit でエージェント呼び出しログを保管（既定 90 日、長期保管が必要なら有償拡張）
- データ保護：エージェントが扱うデータが社内 Sensitivity Label（社外秘・社内限定など）に従うことを確認
- 外部公開エージェント：認証要否・利用規約・プライバシーポリシー・利用ログ保管期間を明文化
- Generative AI のデータ取扱：Microsoft Copilot のデータ取扱ポリシーをユーザーに告知（出力データの保管期間、学習への利用可否）
- 権限委任の透明性：OBO で動く Action は、利用者本人に「あなたの権限で {コネクタ名} にアクセスします」と同意を取る画面が出ることを確認
- ロールアウト計画：パイロット部門 → 一部部門 → 全社、の段階展開。各段階で利用ログ・誤回答件数・ユーザーからのフィードバック量を計測
- 緊急停止手順：障害・情報漏洩が起きた場合に「エージェントを 1 クリックで停止」する手順を Maker portal で習熟しておく
DLP ポリシーの設計例（経費精算エージェントの場合）
【ビジネスデータ（高機密）】
- Dataverse
- SharePoint Online
- Outlook
- Teams
- Power Automate
【非ビジネスデータ（個人利用OK）】
- （このエージェントでは使わない）
【ブロック】
- Twitter / X
- Dropbox（個人版）
- 個人 OneDrive 以外の外部ストレージ
⇒ ビジネスデータと非ビジネスデータの間の組み合わせは
Power Platform 側で自動ブロックされる
失敗パターンとリカバリ
実際の現場で頻発する失敗を、原因・リカバリ含めて 8 つまとめる。
失敗 1：Topic のトリガーフレーズが効かない
- 症状：「経費を申請したい」と書いても別 Topic に飛ぶ
- 原因：(a) 別 Topic に類似トリガーフレーズがある／(b) generative orchestration の Action description のほうが「経費申請」に強くヒットしている
- 対処：Topic 一覧でトリガーフレーズの重複を grep。Action 側の description を「経費申請の状況確認」のように差別化
失敗 2：Knowledge から検索結果 0 件
- 症状：明らかに該当文書があるのに「該当する資料が見つかりません」と返る
- 原因：(a) SharePoint インデックスがまだ作成されていない（数時間〜1 日かかる）／(b) ファイルがチェックアウト中／(c) アクセス権がエージェント実行ユーザーにない
- 対処：SharePoint で対象ファイルを開けることを確認。Maker portal の「Test your copilot」を別アカウントで実行して権限切り分け
失敗 3：Action が「権限エラー」で失敗
- 症状：Power Automate フローが 401 / 403 で落ちる
- 原因：(a) フロー側の接続が切れている／(b) 呼び出しユーザーに対象データの権限がない／(c) 接続参照が DLP でブロックされている
- 対処：Power Automate の「実行履歴」でエラー詳細を確認。接続参照 vs OBO を切り替える
失敗 4：応答が遅い（10 秒以上）
- 症状：ユーザー発話から応答まで 10 秒以上
- 原因：(a) Action で外部 API を直列に多数呼んでいる／(b) Knowledge の検索範囲が広すぎる／(c) Azure OpenAI 経由でレイテンシ追加
- 対処：Topic の途中で「処理中…」のメッセージノードを挟む。並列化可能な Action は Power Automate 側で並列分岐
失敗 5：generative orchestration が暴走する
- 症状：意図しない Action を勝手に呼ぶ・想定外の Topic に遷移する
- 原因：Action description が広すぎる、Topic のトリガーフレーズが少ない、instructions に NG が書かれていない
- 対処：description を狭く絞り、instructions に「次の場合は人にエスカレーション：A、B、C」と明示
失敗 6：M365 Copilot から呼べない
- 症状：「@エージェント名」と打っても候補に出ない
- 原因：(a) M365 統合アプリで未承認／(b) ユーザーが M365 Copilot ライセンス未所持／(c) Channels で M365 Copilot 配信を未有効化
- 対処：M365 管理センターでアプリの公開状態を確認。ライセンス割当てを確認
失敗 7：環境間でエージェントが正しく移動できない
- 症状：開発環境で作ったエージェントを本番環境にエクスポートしたら、Action や接続が動かない
- 原因：接続参照が環境固有のため移行時に再設定が必要
- 対処：ソリューション（Solution）に全コンポーネントを含めてエクスポート。本番側で接続を再設定するチェックリストを作る
失敗 8：Knowledge が古い数字を回答する
- 症状：1 年前の価格・料率・限度額が回答に出てくる
- 原因：SharePoint に旧版が残っており、Knowledge が両方インデックスしている
- 対処：(a) SharePoint で旧版を「履歴」フォルダに退避し Knowledge 対象から外す／(b) ファイルに「version: 2026-05」のような前文を追記し、instructions で「最新版を優先」と書く
本番運用：監視・改善のループ
公開して終わりではない。Copilot Studio Analytics で次の指標をモニタリングする。
- セッション数：日次・週次・月次の利用状況
- エスカレーション率：人間に渡された会話の割合。20% 超えは Knowledge / Topic に改善余地
- 満足度（Feedback）：応答後の Thumbs up/down 比率
- Topic 別の利用回数：使われていない Topic は description / トリガーフレーズを見直し
- Action の失敗率：5% 超えは権限・データ品質の問題が潜在
改善ループのテンプレ（隔週運用）
【隔週ミーティング】30 分
1. 直近 2 週間の指標を確認
- セッション数 / エスカレーション率 / 満足度
2. 低評価会話（Thumbs down）を 5 件サンプリングし原因分類
- Knowledge 不足 / Topic 未整備 / instructions 不適切 / Action 失敗
3. 改善タスクを 1〜3 個選んで次の 2 週間で実装
4. 大きな仕様変更は事前に IT セキュリティ・データガバナンスに相談
関連記事
- AWS の Agent ツールキット完全ガイド：マルチクラウドエージェント設計
- OpenAI Agents SDK の TypeScript・Python 実装比較
- マルチエージェント設計パターン：Orchestrator-Worker / Hierarchy / Swarm 比較
まとめ：Copilot Studio で本番運用するための 10 ヶ条
- ホスト先（M365 Copilot 拡張 / スタンドアロン）を最初に決める
- 権限境界（OBO / 接続参照）を Action 単位で統一する
- Knowledge は 1 ドメイン 1 ソースに分割する
- Instructions に「できること」「できないこと」「知らない時の応答」を明示する
- Topic は 1 目的 = 1 Topic で分ける
- Action description は LLM が読む前提で具体的な動詞 + 対象で書く
- Action 呼び出し前に Confirmation node を入れる（金額・宛先などのパラメータ）
- DLP ポリシーと環境分離を IT セキュリティと合意してから本番公開
- Power Platform Analytics で隔週レビューする
- 緊急停止手順を Maker portal で習熟しておく
Copilot Studio は「ローコードだから簡単」と紹介されがちだが、エンタープライズで本番運用するには上記の設計分岐と運用設計を最初に決める必要がある。逆に言えば、この 20 個のテンプレ・チェックリストを最初に通せば、コンサルタント・SIer に頼まなくても社内 IT で十分本格運用までもっていける。
この記事を読んで導入イメージが固まってきた方へ
Uravationでは Microsoft Copilot Studio・Power Platform・Microsoft 365 Copilot を含む生成 AI エージェント導入の研修・コンサルティングを提供しています。設計レビュー・ガバナンス設計・社員向け研修まで一気通貫でご相談ください。
—
佐藤 傑（さとう・すぐる）
株式会社 Uravation 代表取締役。X（@SuguruKun_ai）フォロワー約 10 万人。著書『AIエージェント仕事術』。生成 AI を使ったエンタープライズ研修・実装支援を主業務とし、Microsoft Copilot Studio・Power Platform・Microsoft 365 Copilot の導入支援実績多数。
