みなさん、こんにちは！業務ハックLabの「よう」です。
5月に入って新入社員の方々も環境に慣れてきた頃でしょうか。この時期、情シス部門に「Teamsが繋がらない」「PCを貸してほしい」「ライセンスを付与してほしい」……という依頼がどっと増えますよね。（まあ、増えるのは5月だけじゃないんですが）
今回は、そんなITサポート依頼の受付から処理・通知までを、Copilot Studio・Power Apps・Power Automate・Dataverseで一気に自動化する「自律型ITヘルプデスク」を実際に構築してみました！
📋 この記事の要点
※ 2026年05月時点の情報です
- Copilot StudioのAIボットが依頼を受付・ヒアリングし、Dataverseへ自動起票する仕組みを構築できます。
- Power Appsのキャンバスアプリで情シス担当者がチケットを一覧・編集・処理する「作業台」を実装できます。
- Power Automateの通知フローで「対応中」「完了」の2段階Teams通知を依頼者に自動送信できます。
- Dataverse選択肢列への文字列渡しエラーは、Switchアクションで整数変換することで解決できます。
- Premium不要で使いたい場合はDataverseをSharePointに差し替える構成に対応しています。
こんな方におすすめ: 情シス部門・コーポレートエンジニア・社内ITサポート担当者で、チャットや口頭で属人化しているITサポート依頼をAIとアプリで体系的に自動化したい方。
ちなみに動画でも作り方をまとめています。
YouTube Liveで全三回でお届けしましたので実際に作っているところを見ながら一緒に作りたいという方は下記からご覧いただければと思います。(チャンネル登録、いいねもしてもらえると嬉しいです！)
- 【重要】アーキテクチャ解説：ボット（AI）とアプリ（人間）の役割分担
- Dataverse準備：「ITチケットサポート」テーブルの作成
- ステップ1：Copilot Studioによる「一次受付＆自動起票ボット」の作成
- ステップ2：Power Appsキャンバスアプリでの「チケット処理＆編集フォーム」構築
- ステップ3：アプリの「ボタン」からPower Automateを動かす（対応中・完了の2段階通知）
- 結合テスト：ボット起票〜情シスがアプリで処理〜通知まで全フロー確認
- 【Appendix】Premium不要で使う：SharePoint版への差し替えガイド
- まとめ：「受付はAI、処理は人間」の業務フローで情シス業務を変える
【重要】アーキテクチャ解説：ボット（AI）とアプリ（人間）の役割分担
このシステムの全体像を理解しておくと、各ステップの「なぜそう作るか」がクリアになります。まずはアーキテクチャ図を見てください。
登場するコンポーネントは4つです。それぞれに明確な役割があります。
- Copilot Studio：AI受付窓口。従業員からの依頼をヒアリングし、チケットを自動起票する。
- Dataverse：台帳。すべてのコンポーネントが読み書きする共有データストア。
- Power Apps（キャンバスアプリ）：情シス担当者の作業台。チケットを確認・編集・処理する。
- Power Automate（通知フロー）：裏側の処理エンジン。Power Appsのボタンから呼び出され、Teamsで通知を送る。
重要なのは「AIが受付まで、人間が処理以降」という役割の切り方です。
ボットは「何を依頼されているか」「誰からか」「詳細は何か」を漏れなくヒアリングして起票するところまでをやります。判断や処理は情シス担当者がアプリで行う。このボットと人間の役割分担が明確になっているのが、このシステムの一番のポイントです。
💡 ここが大事： 単なる「ダッシュボード」ではなく、アプリから直接「保存」「通知」が実行できる「業務の実行基盤」として設計しています。処理して台帳を更新して通知を送る、という一連の作業がアプリ上で完結します。
Dataverse準備：「ITチケットサポート」テーブルの作成
まずはすべてのデータの受け皿となるDataverseのテーブルを作ります。このテーブルがCopilot Studio・Power Apps・Power Automateの共通データストアになります。
テーブル名は「ITチケットサポート」で作成します。列の構成は以下の通りです。
チケット番号：オートナンバー型（詳細は後述）依頼者メール：テキスト型カテゴリ：選択肢型（PC貸与・ライセンス付与・障害報告）詳細：テキスト（複数行）型ステータス：選択肢型（未対応・対応中・完了）対応担当者：テキスト型対応メモ：テキスト（複数行）型完了予定日：日付と時刻型
⚠️ 先に警告：オートナンバー列は最初の設定が肝心
オートナンバー列には「一度レコードが作成されると設定変更に制約が生じる」という特性があります。後から困らないよう、テーブル作成の最初の段階で正しく設定しておきましょう。
設定内容はこの通りです。
- 種類：
文字列が先頭に付加される数 - 接頭辞：
IT- - 最小桁数：
5 - シード値：
1
この設定で「IT-00001」「IT-00002」…という形式でチケット番号が自動採番されます。（テスト中に何回か作り直してシード値をリセットしようとしたんですが、レコードが1件でもある状態だと「以前に呼び出されたフィールドです」と表示されて変更できなくなるんですよね…。最初から正しく設定しておくのが一番です）
テーブルと列の作成が完了したら、次のステップに進みます。
ステップ1：Copilot Studioによる「一次受付＆自動起票ボット」の作成
Copilot Studioでエージェントを作成し、従業員からのITサポート依頼を受け付けてDataverseに自動起票する仕組みを構築します。ポイントは「トピック設計よりも指示欄の設計がボットの品質を左右する」という点です。
生成AIオーケストレーションを使用する
今回は生成AIオーケストレーションを使用します。
基本的にはこのモードになっていますので意識する必要はないです。
指示欄のプロンプト設計
エージェントの「指示」欄に以下のプロンプトを入力します。今回の実機検証で正常動作を確認した内容です。
あなたは社内ITサポートの一次受付担当です。
従業員からのITサポート依頼をヒアリングし、チケットを起票します。
## 対応スコープ
次の3カテゴリのみ受け付ける：
- PC貸与
- ライセンス付与
- 障害報告
上記以外の質問には「その件は情シスに直接ご連絡ください」と案内する。
## ヒアリング手順
次の3つの情報を順番に収集する：
1. カテゴリ（上記3種のいずれか）
2. 依頼の詳細（何が起きているか、いつから、など）
3. 連絡先メールアドレス
3つの情報がすべて揃った場合にのみ /チケット起票フロー を呼び出す。
## 起票後の応答
起票完了後、「チケットを受け付けました。担当者より連絡いたします」と伝える。
## 応答スタイル
丁寧かつ簡潔な日本語で回答する。このプロンプトでカテゴリ認識・3ステップヒアリング・スコープ外の拒否・情報が揃う前のフライング起票なし、すべてを実機で確認できました！
⚠️ ここでハマりやすい：LLMがヒアリング質問を自律的に膨らませる
指示欄に「依頼の詳細を確認する」と書いただけで、ボットが「いつ頃からご利用が必要でしょうか？」「ご希望のスペックや台数はございますか？」と指示にない掘り下げ質問を自律生成することがあります。
問題は、Dataverseのテーブルに「スペック」「台数」の列がない場合、せっかくヒアリングした情報が起票時に捨てられてしまうことです。対処法は「指示欄の質問項目を明示的に縛る」か「テーブル列を追加して一致させる」の2択です。今回のプロンプトでは収集項目を明示することで制御しています。
テストチャットで動作を確認する
Copilot Studioのテストチャットで実際に会話を流してみましょう。「PCを借りたいんですが」と入力すると、カテゴリ確認→詳細確認→メールアドレス確認の順でヒアリングが進みます。
💡 ちなみに：内部推論は英語で動いています
テストチャットに表示される「考え中」パネルを開くと、内部推論が「Now I have all three pieces of information…」のような英語で処理されているのが見えます。公式ドキュメントには「生成AIオーケストレーションは英語のみサポート」とあります。
生成オーケストレーションを効果的かつ責任ある形で使用するためには、どのような運用要因や設定が必要ですか？
ただ日本語の指示欄・日本語の会話でも正常に動作することを実機で確認しています。オーケストレーション層が英語で処理し、ユーザー向けレスポンスを日本語で返す構造です。なお、この「考え中」パネルはテストチャット専用の表示であり、Teamsなど本番チャネルでは表示されません。
エージェントフロー（起票フロー）の作成
Copilot Studio内でエージェントフローを新規作成します。トリガーは「エージェントがフローを呼び出すとき」を選択してください。
入力パラメータを3つ定義します。
Category（テキスト）Detail（テキスト）Email（テキスト）
フローのアクション構成はこの通りです。
- 変数の初期化（
CategoryValue、整数型） - Switchアクション：
Categoryの値で整数に変換する - Dataverse「新しい行を追加する」：変換後の整数値でレコードを作成
- 「エージェントに応答する」：
Result = "起票完了"を返す
⚠️ ここでハマりやすい：選択肢列に文字列を渡すとエラーになる
実際にこんなエラーが出ました。
Action '新しい行を追加する' failed: Input parameter 'item/crad5_category' is required to be of type 'Integer/int32'. The runtime value '"PC貸与"' to be converted doesn't have the expected format 'Integer/int32'.Dataverseの選択肢型列はバックエンドで整数として管理されています。文字列「PC貸与」は直接渡せないんです。（最初これに気づかなくてしばらく悩みました…）
解決策はSwitchアクションで文字列→整数に変換してから渡すことです。
- Case
"PC貸与"→CategoryValue = 945900000 - Case
"ライセンス付与"→CategoryValue = 945900001 - Case
"障害報告"→CategoryValue = 945900002
整数値はDataverseのテーブル設定画面から確認できます。列の編集→選択肢→「値」の列に数字が並んでいます。
⚠️ 重要： この整数値はテーブルを作り直すと変わります。必ずご自身の環境のテーブル設定画面で確認してください。上記の値はあくまでも本記事の検証環境でのものです。
Switchアクションで整数変換を挟んでから「新しい行を追加する」を実行すれば、チケット番号（IT-00001形式）・カテゴリ・依頼者メール・詳細・ステータス（未対応）がすべて正しくDataverseに記録されます！
ステップ2：Power Appsキャンバスアプリでの「チケット処理＆編集フォーム」構築
情シス担当者がチケットを確認・編集・処理するためのキャンバスアプリを作ります。UIの核は「タブ切り替え」＋「ギャラリー＋EditForm」の2カラムレイアウトです。
タブ切り替えUIの実装：コンテキスト変数で「選択中」を表現する
「未対応」「対応中」「完了」の3タブを切り替えることで、ステータス別にチケットを絞り込み表示します。Power Appsでタブ切り替えUIを実装するときの定番テクニックを使います。
まず画面のOnVisibleに初期化の数式を設定します。
UpdateContext({locFilter: 945900000, locDispEdit1: DisplayMode.Disabled, locDispEdit2: DisplayMode.Edit, locDispEdit3: DisplayMode.Edit})そして各タブボタンのOnSelectに以下を設定します。
「未対応」ボタン：
UpdateContext({locFilter: 945900000, locDispEdit1: DisplayMode.Disabled, locDispEdit2: DisplayMode.Edit, locDispEdit3: DisplayMode.Edit})「対応中」ボタン：
UpdateContext({locFilter: 945900001, locDispEdit1: DisplayMode.Edit, locDispEdit2: DisplayMode.Disabled, locDispEdit3: DisplayMode.Edit})「完了」ボタン：
UpdateContext({locFilter: 945900002, locDispEdit1: DisplayMode.Edit, locDispEdit2: DisplayMode.Edit, locDispEdit3: DisplayMode.Disabled})
💡 なぜDisabledを使うの？と思った方へ
選択中のタブボタンをDisplayMode.Disabledに設定するのは、「押せない＝選択中」という状態をビジュアルで表現するためです。Disabledになったボタンはグレーアウトして押せなくなります。これが「今このタブにいる」という視覚的なフィードバックになります。専用の「選択中スタイル」をIF式で書くよりも、このDisabledテクニックの方がシンプルで管理しやすいです。Power Appsの定番テクニックとして覚えておいて損はないですよ！
ギャラリーとEditFormの設定
ギャラリーのItemsプロパティには、コンテキスト変数locFilterで絞り込む数式を設定します。
Filter('ITチケットサポート', ステータス = locFilter)EditFormのItemプロパティには選択中のギャラリーレコードを紐づけます。
Gallery1.SelectedEditFormのフィールドは「読み取り専用」と「編集可能」を分けて設定します。
- 読み取り専用：チケット番号・依頼者メール・詳細
- 編集可能：カテゴリ・対応担当者・ステータス・完了予定日・対応メモ
保存ボタンのOnSelectは以下の通りです。Refreshを入れることでギャラリーが保存直後に最新状態に更新されます。
SubmitForm(EditForm1); Refresh('ITチケットサポート')通知ボタン（後述のフロー呼び出し）のOnSelectは以下です。
通知フロー名.Run(Gallery1.Selected.ID, Gallery1.Selected.依頼者メール)チケットを選択してEditFormに情報が反映されること・保存後ギャラリーが即時更新されることを確認できました！
ステップ3：アプリの「ボタン」からPower Automateを動かす（対応中・完了の2段階通知）
Power Appsの通知ボタンから呼び出されるPower Automateフローを作ります。企画段階では「完了時のみ通知」でしたが、実装してみて「依頼者が担当者に確認されたことを知れない」という問題を感じたので、「対応中・完了の2段階通知」に拡張しました。
依頼者が「担当者が確認した」「完了した」の2つのタイミングで通知を受け取れる設計の方が、実務的に親切ですよね？ Power Appsからは1つのボタンで呼び出し、フロー側でステータスを判定して分岐する設計です。
フローの構成
トリガーは「Power Apps (V2)」を選択します。
入力パラメータを2つ定義します。
RecordId（テキスト）：チケットのDataverse行IDRequesterEmail（テキスト）：依頼者のメールアドレス
フローのアクション構成はこの通りです。
- Dataverse「行を取得する」：
RecordIdで現在のチケット情報を取得する - 条件アクション：ステータスで分岐
- 対応中（
945900001）の場合 → 「ご依頼のITサポートチケットを担当者が確認しました。対応を開始します」とTeams（フローボット）で通知 - 完了（
945900002）の場合 → 「ご依頼のITサポートチケットの対応が完了しました」とTeams（フローボット）で通知
- 対応中（
Teams通知はフローボットからRequesterEmail宛に送信します。エンドツーエンドの結合テストで対応中通知・完了通知の両方が届くことを確認しました！
結合テスト：ボット起票〜情シスがアプリで処理〜通知まで全フロー確認
ここまで作成したすべてのコンポーネントを繋げて、エンドツーエンドのテストを実施します。一連の流れを時系列で確認していきましょう。
テストの流れ
- ボットに依頼を送る
Teamsのボットチャットで「PCを借りたい」と入力。ヒアリングが完了した時点でエージェントフローが呼び出され、Dataverseに「IT-00001」レコードが作成される。 - Power Appsで確認する
情シス担当者がキャンバスアプリを開くと、「未対応」タブにIT-00001が表示されている。チケットを選択してEditFormに詳細が表示されることを確認する。 - 対応中に変更して通知を送る
ステータスを「対応中」・対応担当者・対応メモを入力して保存ボタンを押す。続いて通知ボタンを押す。依頼者のTeamsに「担当者が確認しました」の通知が届く。 - 完了処理をして完了通知を送る
「対応中」タブでチケットを選択し、ステータスを「完了」・完了予定日を設定して保存する。通知ボタンを押すと「対応が完了しました」の通知が届く。
全ステップで期待通りの動作を確認できました！（正直一発で全部繋がったときはテンション上がりました）
💡 確認のポイント： 「未対応」タブでステータスを「対応中」に変更して保存した直後、そのチケットは「未対応」タブの一覧から消えます。「対応中」タブに切り替えると確認できます。
Filter式とステータス値が正しく紐づいている証拠です。
【Appendix】Premium不要で使う：SharePoint版への差し替えガイド
「Dataverseを使いたいけどPremiumライセンスがない」という場合は、データストアをSharePointリストに差し替えることで、Microsoft 365ライセンスの範囲内で同等の仕組みを構築できます。
DataverseとSharePointの比較
| 比較項目 | Dataverse（本構成） | SharePoint版 |
|---|---|---|
| 必要ライセンス | Power Apps Premium | Microsoft 365（追加不要） |
| 選択肢列の管理 | グローバルオプションセット（整数値管理） | リスト列の選択肢（文字列管理） |
| Power Appsとの接続 | Dataverseコネクタ（標準） | SharePointコネクタ（標準） |
| Filter式の書き方 | 整数値で比較 | 文字列値で比較 |
差し替えが必要な3箇所
SharePoint版に移行する場合、以下の3箇所を変更するだけで対応できます。
① エージェントフロー（起票フロー）
Dataverse「新しい行を追加する」を、SharePoint「アイテムの作成」に差し替えます。選択肢列はSharePointでは文字列で管理されるため、Switchアクションによる整数変換は不要です。Categoryパラメータの文字列をそのまま渡せます。
② 完了通知フロー
Dataverse「行を取得する」を、SharePoint「アイテムの取得」に差し替えます。ステータスの条件分岐も整数値ではなく文字列（「対応中」「完了」）で比較します。
③ Power AppsのデータソースとFilter式
データソースをSharePointリストに差し替え、Filter式を文字列比較に変更します。
Filter('ITチケットサポート', ステータス.Value = locFilterText)コンテキスト変数も整数から文字列に変更します。
UpdateContext({locFilterText: "未対応", locDispEdit1: DisplayMode.Disabled, ...})SharePoint版でも全ステップの動作確認を行い、Microsoft 365ライセンスで同等の仕組みが動作することを実証しています。Premiumライセンスがない環境でもぜひ試してみてください！
まとめ：「受付はAI、処理は人間」の業務フローで情シス業務を変える
今回作ってみて感じたのは、「ボットと人間の役割をちゃんと分けるだけで、こんなにすっきりした仕組みになるんだ」ということです。
ヒアリング・起票はAIに任せる。判断・処理は人間がアプリで行う。通知は自動で飛ぶ。この役割分担が明確になると、情シス担当者はチャットや口頭の依頼拾い漏れを気にしなくていい状態になります。
まずは今回の構成を試してみて、自分たちの運用に合わせてカスタマイズしてみてください！ カテゴリを増やしたり、Teamsの通知内容を変えたり、拡張の余地はたくさんあります。
それでは皆さん、良い業務ハックライフを～！
コメント