Power Virtual Agents

解決する課題

• 問い合わせ対応ボットをフルコードで作ると、対話設計・自然言語理解・チャネル連携の実装が重い
• FAQ や定型対応をオペレーターが繰り返し処理しており、一次対応の自動化で負荷を下げたい
• ボットの会話設計は業務を知る担当者がしたいのに、開発者でないと手を出せない状況を解消したい
• 単に答えるだけでなく、チケット起票や在庫照会などの実処理までボットから動かしたい

これらを、ブラウザ上のグラフィカルなエディターで会話を組み立てられるローコードサービスとして提供することで解決します。業務担当者が主体となってボットを作り、必要に応じてバックエンド連携を足していけます。

主要概念と用語

• ボット / コパイロット: 利用者と会話する単位。1つのボットに複数のトピックがぶら下がる
• トピック: 1つの会話の流れ（シナリオ）。「トリガーフレーズ」で起動し、ノードをつないで応答を組み立てる
• トリガーフレーズ: そのトピックを起動させる利用者の発話例。複数登録して言い回しのゆれを吸収する
• ノード: 会話フローの構成要素。メッセージ送信、質問、条件分岐、変数設定、アクション呼び出しなどがある
• エンティティ / スロット: 発話から抽出する情報の型（日付・数値・地名など）。質問の回答を変数に格納する
• 変数: 会話の中で値を保持する入れ物。トピック内やボット全体（グローバル）で受け渡す
• アクション: Power Automate のフローや外部システムを呼び出し、業務処理を実行する仕組み
• チャネル: ボットを公開する先。Web サイト埋め込み、Microsoft Teams、各種メッセージング基盤など
• トリアージ / フォールバック: どのトピックにも合致しない発話を受け止める既定の流れ

仕様・制限・クォータ

代表的な考え方です（具体値は変動するため定性的に示します）。

• 作成形態: ブラウザ上のローコードエディターでトピックを設計する。コーディングは原則不要
• 公開チャネル: Web チャット、Microsoft Teams、各種メッセージングなど複数チャネルへ公開できる
• 連携: Power Automate のフロー呼び出しで、外部 API やデータソースへの処理を実行できる
• 環境（Environment）: Power Platform の環境単位でボットを管理する。開発・本番を環境で分離するのが基本
• 多言語: 複数言語に対応するが、言語ごとに対応範囲が異なるため要件に合うかを確認する
• 上限: トピック数、セッション、メッセージ消費量などにはプランごとの上限がある。大規模運用は容量の確認が前提

内部の仕組み

利用者の発話は、まず自然言語理解によってどのトピックのトリガーフレーズに最も近いかが判定され、合致したトピックの会話フローが起動します。フロー内では、ノードをたどりながらメッセージ送信・質問・条件分岐を進め、必要な情報を変数に蓄積していきます。

質問ノードでは、利用者の回答からエンティティで値を抽出し、変数へ格納します。これにより「いつの予約ですか」に対する日付などを構造化して受け取れます。会話の途中で外部処理が必要になると、アクションとして Power Automate のフローを呼び出し、その戻り値を変数に受け取って会話を続けられます。

• どのトピックにも合致しない発話は、フォールバック / トリアージの流れで受け止め、聞き直しや有人エスカレーションへ回す
• 作成したボットは環境内に保持され、公開操作を経て各チャネルへ反映される
• 会話ログや分析データはサービス側に集約され、運用分析に使える

設計パターン / ベストプラクティス

• トピックは小さく単機能に分割し、1トピック1シナリオを保つ。巨大な分岐ツリーは保守が破綻しやすい
• トリガーフレーズは言い回しを多めに登録して、利用者の多様な表現に当てる
• 業務処理は Power Automate 側へ寄せる。会話設計（ボット）と処理ロジック（フロー）を分離して責務を明確にする
• 環境で開発と本番を分離し、検証してから公開する。いきなり本番ボットを編集しない
• 有人エスカレーションの導線を必ず用意する。ボットで解決できない問い合わせを人へ確実に渡す
• 分析を見て継続改善する。解決率や離脱が多いトピックを定期的に見直し、トリガーや回答を磨く

運用・監視

• 標準の分析ダッシュボードで、セッション数、解決率、エスカレーション率、トピック別の利用状況を確認する
• 解決できなかった発話を洗い出し、新規トピックの追加やトリガーフレーズの補強に反映する
• 公開フローを運用ルール化し、変更は検証環境で確認してから本番へ反映する
• アクションが呼ぶ Power Automate フローの失敗を監視し、外部連携の不調がボットの応答品質に波及しないようにする
• メッセージ消費量（セッション）を監視し、容量上限に近づいたらプランや配分を見直す

コスト

• 課金は主に**処理したメッセージ量（セッション/メッセージ単位）**とライセンスに基づく
• ボットの作成数そのものより、実際にさばく会話量が増えるほどコストが積み上がる構造になりやすい
• アクションで呼ぶ Power Automate 側に別途の消費・ライセンスが絡む場合がある
• 検証は小規模から始められるが、本番で問い合わせ量が増えるとボリュームに比例して増える
• 具体的な単価や無料枠は変動するため、公式の料金ページで最新値を確認する

セキュリティ

• ボットの編集・公開権限は Power Platform の環境と RBAC で制御し、運用者ごとに最小権限を割り当てる
• 認証が必要なボットでは、Microsoft Entra ID などの認証を組み合わせ、利用者を確認したうえで個別情報を扱う
• アクションで外部システムへ渡す値は、機微情報の取り扱いに注意し、不要な情報を会話変数に残さない
• データ損失防止（DLP）ポリシーで、ボットやフローが利用できるコネクタを組織ポリシーに沿って制限する
• 公開チャネルごとに到達範囲が変わるため、社内限定か一般公開かを明確にして配置する

関連サービス・比較

会話を組み立てる Power Virtual Agents と、開発者向けに会話 AI を構築する Azure AI Bot Service の守備範囲を整理します。

Azure 内では、業務処理を担う Power Automate、自然言語理解の基盤となる Azure AI Language、開発者向けの Azure AI Bot Service が隣接します。Power Virtual Agents は「業務担当者がローコードで会話を作る」点が特徴で、込み入った処理は Power Automate へ、より自由な作り込みが必要なら Bot Service へと役割を分担できます。現在はこれらの会話 AI 機能が Microsoft Copilot Studio に集約・発展しています。

ハンズオン / CLI例

Power Virtual Agents 自体はブラウザの GUI で作成するため、専用の az コマンドはありません。前提となる Power Platform 環境の管理は、Power Platform CLI（pac）や az で扱える周辺リソースで行います。ここでは、ボットの分析や連携先となるリソースを置くリソースグループ作成の例を示します。

# 連携リソースを置くリソースグループを作成
az group create --name pva-demo-rg --location japaneast

# Power Platform CLI（pac）で認証し、環境一覧を確認する例
# （pac は Power Platform CLI。az とは別ツール）
pac auth create --name pva-demo
pac admin list

# ボット本体の作成・トピック設計は Power Virtual Agents（Copilot Studio）の
# Web エディターで行う。CLI からボットの会話フローは編集しない。