Copilot Studio完全ガイド2026｜カスタムAIエージェント構築

結論: Microsoft Copilot Studioは、Power Platformを基盤として企業内システム・SharePoint・Dataverse・カスタムAPIを統合し、エンタープライズ向けカスタムAIエージェントをローコードで構築できるMicrosoftの公式PaaSです。

この記事の要点:

• ライセンス体系（Tenant Capacityパック/$200・25,000 Credits / Pay-as-You-Go）と実際のコスト感
• Knowledge Sources（SharePoint・Dataverse・公開Web）の設計方針と上限値
• Custom Connector・Power Automateアクション統合・Microsoft Entra ID SSOの実装手順

対象読者: Microsoft 365契約済みの情報システム部門・DX推進担当・Power Platform管理者

読了後にできること: 今日中にPower Platform管理センターで環境を設定し、最初のエージェントをTeamsに公開する

「Copilot Studioって、ChatGPTみたいに自社のデータを学習させて、社内用のAIアシスタントを作れるんですよね？」

先日、情報サービス業の顧問先（従業員約300名）のIT部門責任者から、こんな質問を受けました。正直、最初は「まあ、それに近いです」と答えたんですが、実際に一緒に触ってみて、想定以上に深いプラットフォームだということに改めて気づかされました。

Copilot Studioは単なる「ノーコードチャットボット作成ツール」ではないんです。Power Automateとのアクション統合、カスタムAPIへのConnector経由接続、Microsoft Entra IDを使ったSSO認証、さらに2026年のWave 1からはAnthropicのClaudeモデルをバックエンドに選択することまで可能になりました。

この記事では、既存の入門記事（Copilot Studioノーコード作成術）より一段深い、カスタムAIエージェントの実装・設計レイヤーにフォーカスします。YAMLによる設定例、Power Fxの活用、JavaScript連携まで、コードブロック10個以上を交えて完全解説します。M365を契約済みでCopilot Studioの本格活用を検討している方に、今すぐ使える実践知識をお届けします。

なお、AIエージェントの概念と導入ステップ全般については、AIエージェント導入完全ガイドも合わせてご参照ください。

Copilot Studioとは何か — Copilot（M365）との違い

まずここを整理しておかないと、後の実装で混乱します。実際、研修の現場でも「CopilotとCopilot Studio、どう違うの？」という質問が毎回出てきます。

Microsoft Copilotとの位置づけ

つまり、M365 Copilotは「社員が使うAIアシスタント」で、Copilot Studioは「その社員向けAIアシスタントを自社仕様でカスタム構築するプラットフォーム」です。M365 Copilotのライセンスがあれば、Copilot Studioでの拡張（エージェントビルダー連携）も一部利用可能ですが、本格的なカスタム構築には別途Copilot Studioのライセンスが必要です。

2026年Wave 1の主要アップデート

2026年のWave 1（前半期）で特に注目のアップデートは以下の通りです：

• マルチモデル対応: GPT-4o・Claude Sonnet 4.5・Claude Opus 4.1をエージェントのバックエンドモデルとして選択可能
• エージェントビルダー統合強化: M365 CopilotのエージェントビルダーをCopilot Studioで拡張可能に
• 新しいKnowledgeタイプ: ファイル添付・Dataverse仮想テーブルのサポート拡張
• 評価機能（Evaluations）: エージェントの品質を定量評価するフレームワークが追加

ライセンス・課金体系を完全理解する

Copilot Studioの課金は独特で、最初に理解しておかないと後でコスト超過になります。顧問先でも「思ったより従量課金がかかった」というケースを見てきました。

2つのライセンスモデル

1. プリペイドパック（Tenant Capacity）

# Copilot Studioプリペイドパック仕様（2026年1月時点）
パック単価   : $200 / 25,000 Credits / 月
購入単位     : テナント全体（ユーザー数に依存しない）
繰り越し     : 不可（月次リセット）
対応チャネル : Teams / Web / Slack / Custom / 音声（一部）
Premium接続 : 含む（別途Power Apps/Automateライセン不要）

1メッセージ（会話ターン）あたり消費するCreditは、使用するKnowledge SourceやActionの種類によって異なります。基本的な会話は1 Credit、Generative Answersを使うとさらに加算されるケースがあります。

2. Pay-as-You-Go（従量課金）

# Pay-as-You-Go設定（Azure Subscription必須）
接続先       : Azureサブスクリプション
課金単位     : Copilot Credits（実際の使用量のみ）
メリット     : 初期投資ゼロ、PoC・小規模検証に最適
デメリット   : 本番運用ではプリペイドより割高になりやすい
推奨シナリオ : パイロット期間（3ヶ月以内）

3. M365 Copilotライセンス経由（限定利用）

M365 Copilotライセンスを保有している場合、エージェントビルダーを通じてCopilot Studioの一部機能が利用可能です。ただし、カスタムAPIコネクター・Premium Knowledge Source・外部チャネルデプロイには単独のCopilot Studioライセンスが必要です。

コスト試算の実例

想定シナリオ: 従業員200名の製造業。社内規程問い合わせエージェントをTeamsにデプロイ。1日あたり50件の問い合わせ、1会話4ターン。SharePoint Knowledgeを使用。月稼働20日。

月間メッセージ数: 50件 × 4ターン × 20日 = 4,000メッセージ/月
必要Credits: 約4,000〜8,000 Credits（Generative Answers使用時は2倍換算の目安）
プリペイドパック: 25,000 Credits/$200 → 1パックで約3ヶ月分カバー可能

この試算はあくまで目安です。実際はConnectorの呼び出し回数やGenerative Answersの設定によって変動します。本番移行前にPay-as-You-Goで1ヶ月実測することを推奨します。

環境構築 — Power Platform管理センターの設定

ここからが実装の話です。Copilot Studioで本格的なエージェントを作る前に、Power Platform管理センターでの環境設定が必要です。

環境の作成と設定

# Power Platform管理センターでの環境作成（推奨設定）
環境タイプ    : Production（本番）または Sandbox（検証）
リージョン    : Japan（uravation.comの場合 — データレジデンシー要件）
Dataverse     : 有効化必須（Copilot StudioはDataverseに依存）
言語設定      : 日本語（エージェントのデフォルト言語に影響）
セキュリティ  : Azure AD認証（Microsoft Entra ID）を紐付け

重要なのは、Dataverseを有効化することです。Copilot StudioはDataverseを基盤データストアとして使用するため、Dataverseなしの環境ではCopilot Studioを作成できません。

必要な権限の割り当て

# エージェント開発者に必要なロール（Power Platform管理センター）
System Customizer   : エージェント・フローの作成・編集
Service Admin       : 環境設定・コネクター管理
Dataverse          : テーブル読み取り/書き込み（用途に応じて）

# M365管理センター側（Exchange/SharePoint連携時）
SharePoint管理者    : サイトコレクション権限の付与
Exchange管理者      : メール連携フロー用

基本エージェント作成 — Topics・Trigger Phrasesの設計

環境が整ったら、エージェントの「会話設計」から始めます。Copilot Studioの会話設計は「Topics（トピック）」という単位で管理します。

TopicとTrigger Phrasesの構造

# Topic設計の基本構造（YAML形式・概念図）
Topic:
  name: "勤怠申請の方法"
  trigger_phrases:
    - "有給申請したい"
    - "休暇取りたい"
    - "勤怠はどうやって"
    - "有休残日数を確認したい"
  nodes:
    - type: message
      content: "勤怠申請についてご案内します。"
    - type: question
      question: "どのような申請ですか？"
      entity: "choice"
      options:
        - "有給休暇"
        - "代休"
        - "その他"
    - type: condition
      branches:
        - condition: "有給休暇"
          action: "SharePoint申請フォームへのリンクを提供"
        - condition: "代休"
          action: "代休申請手順を説明"

Trigger Phrasesの設計原則

実際にエージェントを社内展開した際に学んだことですが、Trigger Phrasesの設計はエージェントの精度に直結します。

# 悪いTrigger Phrases設計の例
trigger_phrases:
  - "申請"      # 広すぎてどんな申請か不明
  - "休む"      # 口語すぎてマッチ精度が低い

# 良いTrigger Phrases設計の例
trigger_phrases:
  - "有給申請の方法を教えて"
  - "年次有給休暇を取得したい"
  - "PTO申請のやり方"
  - "休暇申請フォームはどこ"
  - "有給残日数を知りたい"
  # 1トピックあたり5〜15フレーズが目安
  # 自然言語の揺らぎを意図的に入れる

システムTopicと自動応答の活用

Copilot Studioには、最初から組み込まれている「システムTopics」があります。挨拶・エラー処理・エスカレーション（人間へのハンドオフ）などです。これらを適切にカスタマイズするだけで、エージェントの品質が大幅に向上します。

# 人間へのエスカレーション設定（システムTopic: Escalate）
条件: ユーザーが「人と話したい」「担当者を呼んで」等を発言
アクション:
  - Power Automate Flowを呼び出し
  - Teams チャネルに通知（Service Desk宛）
  - 会話履歴をメールで担当者に転送
  - ユーザーに「担当者に連絡します（目安XX分）」と返答

Generative Answers — Knowledge Sourcesからの回答生成

Copilot Studioの真骨頂がここです。Generative Answersは、あらかじめTopicを作らなくても、Knowledge Sourcesから自動的に回答を生成する機能です。

対応Knowledge Sourceの種類と上限

SharePoint Knowledge Sourceの追加手順

# SharePoint Knowledge Source追加（手順）
1. Copilot Studio → [Knowledge] → [+ Add]
2. ソースとして "SharePoint" を選択
3. SharePointサイトのURLを入力
   例: https://yourcompany.sharepoint.com/sites/policies
4. 認証: Microsoft Entra IDで自動認証（管理者承認が必要な場合あり）
5. インデックス作成: 5〜30分（ファイル数に依存）
6. テスト: [Test your agent] パネルで「有給申請の方法は？」等を入力して動作確認

# 注意点:
# - SharePoint検索のためにDataverse searchを有効化する必要あり
# - SharePointのアクセス権限がエージェントのサービスアカウントに必要
# - ファイルの変更は自動で再インデックス（タイムラグ: 数分〜1時間）

Dataverse Knowledge Sourceの設計

# Dataverse テーブルをKnowledge Sourceとして使う際の設計指針
# 例: 製品在庫確認エージェント向けDataverseテーブル

テーブル名: cr7a2_products（カスタムテーブル）
列の設計:
  - cr7a2_productname  (Text): 製品名
  - cr7a2_sku          (Text): SKUコード
  - cr7a2_stock        (Whole Number): 在庫数
  - cr7a2_description  (Multiline Text): 製品説明（Generative Answersが参照）
  - cr7a2_price        (Currency): 価格

# Generative Answersがdescriptionフィールドを重点的に参照する
# 構造化クエリはPower AutomateアクションでDataverse Connectorを使う方が確実

Power Automateアクション統合

Copilot StudioとPower Automateの統合は、エージェントを「会話するだけのbot」から「実際に業務を動かすエージェント」に進化させるキーポイントです。

アクションの呼び出し構造

# Copilot Studio → Power Automate フロー呼び出し（概念構造）

# 1. Copilot Studio側: アクションノードの設定
Action:
  type: "power_automate_flow"
  flow_name: "勤怠申請登録フロー"
  input_variables:
    - name: "employee_id"
      source: "system.user.id"    # Entra IDからユーザーIDを自動取得
    - name: "leave_type"
      source: "conversation.leave_type"   # 会話で収集した情報
    - name: "leave_date"
      source: "conversation.leave_date"
  output_variables:
    - name: "request_id"          # フロー実行後の申請番号を受け取る
    - name: "status"

# 2. Power Automate側: フロー定義（主要ステップ）
トリガー: Power Virtual Agentsから呼び出し
ステップ1: Dataverseに申請レコードを作成
ステップ2: 上長のメールアドレスをDataverseから取得
ステップ3: 承認メールをOutlookで送信（承認コネクター）
ステップ4: 申請番号を生成してCopilot Studioに返す

Power Fxによる動的処理

# Power Fxを使った動的なメッセージ生成（Copilot Studio内）
# 例: 残有給日数に応じてメッセージを変える

// 変数: remainingDays（Power Automateから受け取った残日数）
If(
  remainingDays >= 10,
  "有給は " & Text(remainingDays) & " 日残っています。余裕がありますね。",
  If(
    remainingDays >= 5,
    "有給は " & Text(remainingDays) & " 日残っています。",
    "有給残日数が " & Text(remainingDays) & " 日となっています。早めにご計画ください。"
  )
)

よく使うPower Automateコネクター一覧

カスタムAPI接続 — Custom Connectorの実装

社内の基幹システム（ERPや独自APIなど）とCopilot Studioを連携させる際に使うのがCustom Connectorです。これが実装できると、エージェントの活用範囲が飛躍的に広がります。

Custom Connectorの作成手順

# Custom Connector作成（Power Platform管理センター or Power Automate）

# Step 1: OpenAPI定義（Swagger）を準備
# 例: 在庫確認APIのOpenAPI定義（YAML）
openapi: "3.0.0"
info:
  title: "社内在庫管理API"
  version: "1.0.0"
servers:
  - url: "https://api.yourcompany.internal/v1"
paths:
  /inventory/{sku}:
    get:
      summary: "在庫確認"
      operationId: "GetInventory"
      parameters:
        - name: sku
          in: path
          required: true
          schema:
            type: string
      responses:
        "200":
          description: "在庫情報"
          content:
            application/json:
              schema:
                type: object
                properties:
                  sku: {type: string}
                  stock: {type: integer}
                  location: {type: string}

# Step 2: Power Automate → カスタムコネクター → 新しいカスタムコネクター
# Step 3: OpenAPI定義をインポート
# Step 4: セキュリティ設定（下記参照）
# Step 5: テスト実行
# Step 6: Copilot StudioのアクションでこのConnectorを選択

OBO認証（On-Behalf-Of）の実装

エンタープライズ環境では、エージェントがエンドユーザーの代わりにAPIにアクセスするOBO（On-Behalf-Of）認証が必要なケースがあります。

# OBO認証設定（Microsoft Entra ID経由）
# Power Automate: Custom Connector → Security設定

認証タイプ: OAuth 2.0
Identity Provider: Azure Active Directory（Microsoft Entra ID）
Client ID: [Entra IDのアプリ登録から取得]
Client Secret: [Entra IDのアプリ登録から取得]
Authorization URL: https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/authorize
Token URL: https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token
Scope: api://{your_api_app_id}/inventory.read

# Custom ConnectorのSecurity設定で
# "Enable on-behalf-of login" を true に設定することで
# エンドユーザーの認証情報でAPIにアクセス可能になる

Knowledge Sources設計 — 3層アーキテクチャ

複数のKnowledge Sourceを組み合わせる際は、「どのデータを何のために使うか」を設計段階で整理しておくことが重要です。顧問先でよく採用している3層構造を紹介します。

推奨アーキテクチャ（3層構造）

# Knowledge Source 3層アーキテクチャ（エンタープライズ向け）

Layer 1: ポリシー・手順レイヤー（SharePoint）
  対象: 就業規則・経費規程・セキュリティガイドライン・業務マニュアル
  更新頻度: 低（月次〜年次）
  ファイル形式: PDF / Word
  推奨サイト数: 1〜3サイト（部門別に分ける）

Layer 2: 業務データレイヤー（Dataverse）
  対象: 製品カタログ・価格表・顧客マスター・在庫データ
  更新頻度: 高（日次〜リアルタイム）
  テーブル数: 〜15テーブル
  注意: 個人情報を含むテーブルは列レベルでセキュリティ設定必須

Layer 3: リアルタイムデータレイヤー（Power Automate経由）
  対象: 基幹システムAPI・外部サービス・リアルタイム集計
  更新頻度: リアルタイム
  実装: HTTP ConnectorまたはCustom Connectorを使ったフロー
  用途: Layer 1/2でカバーできない動的データ

Knowledge Source選択のデシジョンツリー

# どのKnowledge Sourceを選ぶべきか（判断フロー）

Q1: データは構造化されているか？
  YES → Dataverseテーブルを検討
  NO  → SharePoint（ドキュメント）またはファイルアップロード

Q2: データはリアルタイムで更新されるか？
  YES（毎分〜毎時） → Power Automate経由のカスタムデータ
  NO（日次〜月次） → SharePoint / Dataverse で十分

Q3: データに個人情報・機密情報が含まれるか？
  YES → 列レベルセキュリティ + 行レベルセキュリティを設定
       ユーザー単位でのデータアクセス制御を実装
  NO  → 標準設定で問題なし

Q4: データ量は？
  小（〜100ドキュメント）→ ファイルアップロードで十分
  中（〜1,000ドキュメント）→ SharePoint
  大（1,000〜）→ SharePoint + Dataverse の組み合わせ + テーブル分割

Authenticationパターン — SSO・Microsoft Entra ID

企業展開での認証設定は、セキュリティと利便性のバランスが重要です。設定ミスがよくあるので、ここは丁寧に解説します。

認証パターンの選択肢

Teams向けSSO設定手順

# Teams向けSSO設定（Microsoft Entra ID）

# Step 1: Entra ID（旧Azure AD）でアプリ登録
アプリ名: "CopilotStudio-{環境名}"
サポートされるアカウント: 組織内のアカウントのみ
リダイレクトURI: https://token.botframework.com/.auth/web/redirect
APIの公開:
  - スコープ名: access_as_user
  - 承認済みクライアントアプリ: 1fec8e78-bce4-4aaf-ab1b-5451cc387264（Teams mobile/desktop）
                                 5e3ce6c0-2b1f-4285-8d4b-75ee78787346（Teams web app）

# Step 2: Copilot Studio → 設定 → セキュリティ → 認証
認証タイプ: "Authenticate with Microsoft"（Teams専用SSOの場合）
または
認証タイプ: "Manual（Azure AD）"（複数チャネル対応の場合）
  Client ID: [Step 1のアプリID]
  Client Secret: [Entra IDで生成したシークレット]
  Tenant ID: [テナントID]
  Scopes: openid profile User.Read

# Step 3: Teamsアプリのマニフェスト更新（Teamsチャネル展開時）
"webApplicationInfo": {
  "id": "[Entra IDアプリのClient ID]",
  "resource": "api://botid-[ボットID]"
}

# 注意: カスタムActive Directory認証使用時、コネクターでのSSO不可
# その場合ユーザーは各コネクターに個別サインインが必要

チャネル展開 — Teams・Web・Slack

完成したエージェントを実際のビジネスコミュニケーションツールに展開する手順です。

Teams展開（最もシンプル）

# Teams展開手順（Copilot Studio → チャネル → Microsoft Teams）

1. チャネルの有効化
   Copilot Studio → [チャネル] → [Microsoft Teams] → [有効化]

2. Teamsアプリとして配布
   オプションA: 個人使用 → Teams Storeから直接インストール
   オプションB: 組織展開 → Teamsアプリカタログにアップロード
     - zip形式のTeamsアプリパッケージをダウンロード
     - Teams管理センター → アプリ → アップロードカスタムアプリ
     - 展開ポリシーで対象ユーザー/グループを設定

3. 接続テスト
   Teams → アプリ → 該当エージェントを検索 → 起動

Web Widget埋め込み

  #msft-webchat-container {
    position: fixed;
    bottom: 20px;
    right: 20px;
    width: 400px;
    height: 600px;
    border-radius: 12px;
    box-shadow: 0 4px 24px rgba(0,0,0,0.15);
  }




  // バックエンドから取得したトークンをWebチャットに渡す
  window.addEventListener('WebChatFrameConnected', function(event) {
    event.detail.sendEvent({
      type: 'tokens/request',
      token: 'YOUR_JWT_TOKEN'  // バックエンドから動的に取得
    });
  });

Slack連携設定

# Slack連携（Copilot Studio → チャネル → Slack）

前提条件:
  - Slack Workspace管理者権限
  - Copilot StudioのStandalone（単独）ライセンス（M365 Copilotライセンスでは不可）

手順:
1. Slack API → Create App → From Scratch
2. Bot Token Scopesを設定:
   - app_mentions:read
   - channels:history
   - chat:write
   - im:history
   - im:write
3. Copilot Studio → チャネル → Slackを選択
4. Client ID / Client Secret / Signing Secretを入力
5. Slack側でEvent Subscriptionsを有効化
   Request URL: [Copilot Studioが提供するURL]
6. Slackワークスペースにエージェントをインストール

Analytics・テスト機能の活用

エージェントを公開した後の品質管理には、CopilotStudio組み込みのAnalytics機能が役立ちます。

主要メトリクスと確認方法

テスト機能の活用

# Copilot Studio テストパネルの活用（開発時）

テスト手順:
1. [エージェントをテスト]パネルを開く（Ctrl+F5またはUIボタン）
2. 以下の観点でテストシナリオを作成:

シナリオA: ハッピーパス
  入力: "有給申請したい" → "明日" → "1日"
  期待: 申請フォームへのリンクと確認メッセージ

シナリオB: 意図外の入力
  入力: "給料上げて"
  期待: 適切な謝辞 + 問い合わせ先の案内（エスカレーション）

シナリオC: Generative Answersのテスト
  入力: "育児休業の取り方を教えてください"（Knowledge Sourceにある場合）
  期待: SharePointから正確な手順を引用して回答

シナリオD: 認証フロー
  入力: Power Automateアクションをトリガーする質問
  確認: Entra IDによる認証フローが正常に動作するか

Anthropic / OpenAI Agents SDK との比較

「Copilot StudioとClaude’s Agents SDKとOpenAI Agents SDK、どれを選べばいい？」という質問は、コンサル現場でも多く出てきます。2026年現在の正直なところをお伝えします。

3プラットフォーム比較表

用途別の選択指針

Copilot Studioを選ぶべき場合: M365を全社展開済みで、SharePoint・Teams・Dataverseとの深い統合が必要。IT部門にPower Platform担当がいる。コンプライアンス（金融・医療・行政）で実績が必要。

OpenAI Agents SDKを選ぶべき場合: チームの大半がPythonエンジニア。OpenAIのCodexや最新GPTモデルをすぐに試したい。クラウドベースの非同期処理を大規模に行いたい。

Anthropic Claude SDKを選ぶべき場合: 複雑なコードベースへの適用・長文処理（100万トークンコンテキスト）が必要。ローカルでのエージェント実行（Claude Code）を重視。MCPによる最大限の拡張性が必要。詳しくはOpenAI Agents SDK実装ガイドも参照。

重要なのは、2026年のCopilot StudioはAnthropicとOpenAIのモデルを選択できるようになった点です。「MicrosoftのエコシステムでClaudeを使う」という選択肢が現実になりました。

【要注意】失敗パターン4選

顧問先や研修先での導入支援を通じて、何度も見てきた失敗パターンをまとめました。これを知っておくだけで、本番導入での大きなトラブルを避けられます。

失敗1: Knowledge Sourceに機密データを無制限に追加する

❌ よくある間違い: 「とりあえず全社のSharePointサイトをKnowledge Sourceに追加した。エージェントが何でも答えてくれるようになったが、アクセス権限を持たない従業員が見てはいけないデータを取得できてしまった。」

⭕ 正しいアプローチ: Knowledge Sourceに追加する前に、アクセス制御を確認する。SharePoint Knowledge Sourceはエージェントのサービスアカウントの権限で動作するため、行レベルセキュリティ（RLS）を適切に設定する。ユーザー固有のデータアクセスが必要な場合は、OBO認証でユーザーの認証情報を使ったPower Automateフロー経由でデータを取得する。

なぜ重要か: 情報セキュリティ事故の多くは、便利さを追求するあまりアクセス制御を後回しにした結果です。設計段階でデータ分類と権限設計を行うことが必須です。

失敗2: 1つのエージェントに全業務を詰め込む

❌ よくある間違い: 「HR質問、IT問い合わせ、経費申請、製品問い合わせを1つのエージェントで処理しようとして、Topicsが100個を超えた。精度が低下し、メンテナンスが困難になった。」

⭕ 正しいアプローチ: 業務ドメインごとにエージェントを分割し、それぞれに特化させる。例えば「HRエージェント」「ITサポートエージェント」「営業支援エージェント」のように分けることで、Knowledge Sourceの精度も上がり、メンテナンスも容易になる。必要に応じて「フロントエージェント」から専門エージェントに振り分ける構成も有効。

失敗3: テストなしで本番公開する

❌ よくある間違い: 「開発環境では動いていたので、テストをスキップして全社に展開した。実際に使われ始めると、特定のフレーズでGenerative Answersが不適切な情報を返すケースが発覚した。」

⭕ 正しいアプローチ: テストパネルで最低50パターンのシナリオテストを行う。特に、「意図しない質問への応答」「感情的な問い合わせ」「プロンプトインジェクション的な入力」を含めること。パイロット展開（特定の部門・10〜20名）で実使用データを収集し、Analyticsでエスカレーション率・解決率を確認してから全社展開する。

失敗4: Power Automateフローの認証設定を見落とす

❌ よくある間違い: 「エージェントの開発者アカウントで設定したPower Automateフローが本番で動かなくなった。原因は、フロー内の接続がその担当者個人のアカウントに紐付いていたため、退職時に全接続が無効化されたことだった。」

⭕ 正しいアプローチ: Power Automateフローのコネクター接続は、個人アカウントではなくサービスアカウント（または共有アカウント）に紐付ける。Entra IDのサービスプリンシパルを使ったAPI接続を推奨。フロー所有者が組織アカウントであることを運用チェックリストに含める。

導入ロードマップ — 30日・60日・90日

「どこから始めればいいか分からない」という声に応えるため、現場で実証済みのロードマップをお伝えします。

参考・出典

• Copilot Studio licensing — Microsoft Learn（参照日: 2026-05-06）
• Overview of Microsoft Copilot Studio 2026 release wave 1 — Microsoft Learn（参照日: 2026-05-06）
• Knowledge sources summary — Microsoft Learn（参照日: 2026-05-06）
• Configure single sign-on with Microsoft Entra ID for agents in Teams — Microsoft Learn（参照日: 2026-05-06）
• Configure OBO Authentication for custom connectors — Microsoft Learn（参照日: 2026-05-06）
• Anthropic joins the multi-model lineup in Microsoft Copilot Studio — Microsoft Copilot Blog（参照日: 2026-05-06）
• Extend your agent with tools from a REST API — Microsoft Learn（参照日: 2026-05-06）

まとめ：今日から始める3つのアクション

1. 今日やること: Power Platform管理センター（admin.powerplatform.microsoft.com）にアクセスし、現在のライセンス状況とDataverse有効化の可否を確認する
2. 今週中: Pay-as-You-GoでAzureサブスクリプションと連携し、Sandbox環境でシンプルなFAQエージェント（Topics 3〜5個・SharePoint Knowledge Source 1件）を作成してTeamsで動作確認する
3. 今月中: Analytics機能で解決率・エスカレーション率を計測し、パイロット部門の10名に試験展開。Custom ConnectorまたはPower Automateアクションを1本実装して「情報提供」だけでなく「業務実行」ができるエージェントに発展させる

次回は「Microsoft 365 E7 + Agent 365の戦略的活用」をテーマに、より大規模なエンタープライズAI基盤設計について解説します。

著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。早稲田大学法学部在学中に生成AIの可能性に魅了され、X（@SuguruKun_ai）で活用法を発信（フォロワー約10万人）。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆（NewsPicks最大1,125ピックス）。

ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。