Power Automateだけで作る社内問い合わせチャットボット｜Salesforce運用の属人化を解消した導入事例

社内問い合わせチャットボットとは、業務システムの操作に関する社内からの質問に、あらかじめ用意したナレッジをもとに自動で回答する仕組みです。ただし、入れれば問い合わせが減るという道具ではありません。

わたしたちは、あるお客様の Salesforce 導入にともなう社内問い合わせ対応を、この仕組みで受け止める構築と運用をお手伝いしています。独自のプログラムは1行も書かず、Power Automate だけで作りきっています。この記事では、実際に運用しているものの設計判断を、そのままご紹介します。

目次

• 1. 課題：問い合わせ対応の属人化は、質問が多いから起きるのではない
• 2. 打ち手の全体像：現場に新しいツールを増やさない
• 3. 設計の勘所：生成AIに誤答をさせないために
• 4. 「入れて終わり」にしない月次サイクル
• 5. 実績
• 6. 社内チャットボットでうまくいかなかったこと
• 7. まとめ

1. 課題：問い合わせ対応の属人化は、質問が多いから起きるのではない

基幹システムを新しく導入した直後には、必ず起きることがあります。問い合わせが特定の数人に集中するという現象です。

今回のお客様でも、Salesforce の全社導入後、操作に関する質問が担当部門に集中していました。

• 「見積の明細が修正できない」「検収書の送付ボタンが出てこない」といった、操作でつまずく質問が毎日発生する
• 質問の多くは過去に誰かが同じことを聞いているが、回答はチャットの流れに埋もれて再利用されない
• 結果として、回答できるのが担当部門の数名だけという状態になる
• その数名が離席・繁忙になると、現場の業務が止まる

ここで「問い合わせが多いからチャットボットを入れる」と考えると、打ち手を外します。本当の問題は問い合わせの量ではなく、ナレッジがドキュメントではなく人の頭に貯まっていたことでした。つまり属人化していたのはナレッジであって、人ではありません。担当者を増やしても属人化は解けず、質問が増えれば同じ状態に戻ります。

順序としては、先にナレッジを構造化する必要があります。チャットボットは、構造化されたナレッジを配る出口にすぎません。実際、この案件で最も時間をかけたのはボットの構築ではなく、過去の問い合わせから模範解答を起こしてIDを振り、検索できる形に整える作業でした。

2. 打ち手の全体像：現場に新しいツールを増やさない

構成はシンプルです。既存の業務ツールの上に乗せ、現場に新しいツールを覚えてもらわないことを優先しました。

現場から見えるのは「いつもの質問フォームに投げると、いつもの Slack に回答が返ってくる」だけです。新しいツールはひとつも増えていません。導入時の教育コストをほぼゼロにできたのは、この点が大きいと考えています。

使っているのは、Slack、Microsoft Power Automate（自動処理フロー）、AI Builder（生成AI）、Dataverse（FAQデータベース）、そして Salesforce の API です。いずれも新規のライセンス調達を最小限に抑えられる、既存資産の組み合わせです。

3. 設計の勘所：生成AIに誤答をさせないために

勘所1：AIに「考えさせない」

判断：AIの仕事を「検索」と「文面生成」の2段階に分割し、それぞれの役割を極端に狭めました。回答の中身は100%、人間が書いたFAQから来ています。

理由：生成AIに業務の質問をそのまま投げると、もっともらしいが誤った手順を返します。基幹システムの操作案内でこれが起きると、現場が誤操作し、データを直す手間が発生します。問い合わせを減らすつもりが、かえって増えることになりかねません。

やらなかったこと：社内マニュアルを丸ごとAIに読ませて自由に回答させる方式は採りませんでした。回答できる範囲は広がりますが、誤りが混ざったときに検知できないのが致命的です。検索側には「判断に迷う場合は該当なしを選ぶ」「無理に答えるより担当者につなぐほうが望ましい」という原則を明示的に持たせ、回答率より誤答の少なさを優先しました。

勘所2：分からないときは、堂々と人間に渡す

判断：以下の2つを設計上の正常動作として扱い、担当部門へメンション付きで投げるようにしました。

• 該当するFAQが見つからない（＝新規の質問）
• 該当するFAQはあるが、内容が「管理者側での対応が必要」（パスワードのリセット、データの直接修正、権限の変更など）

現在、全204件の模範解答のうち22件は「回答せずエスカレーションする」ことが正解として登録されています。

理由：チャットボットの失敗パターンで最も多いのが、「分かりません」と言えずに的外れな回答をすることです。一度これをやると、現場は二度と使ってくれません。エスカレーションは失敗ではなく、きちんと設計された出口です。

やらなかったこと：回答率をKPIに置くことはしませんでした。回答率を追うと、迷ったときに答える方向へ判断が寄り、誤答が増えます。

勘所3：レコードの「現在値」を見て答える

判断：質問文に該当レコードのURLが含まれている場合、そのレコードの現在の設定値を取得してから回答を組み立てるようにしました（2026年8月に追加）。

理由：同じ「ボタンが表示されない」という質問でも、原因はレコードの状態によって変わります。従来は汎用的な手順を一律で返していましたが、この仕組みにより「手順1から3のうち、あなたが止まっているのは2番目です」という個別化された案内が可能になりました。

やらなかったこと：取得した現在値を根拠に、手順そのものを書き換えることは禁止しています。現在値の役割は「どの手順に該当するかを示すことだけ」です。あわせて、金額・単価・原価・取引先名・個人名が含まれていても回答文に転記しない制約を課し、そもそもの参照範囲もシステム側の権限設定で絞る二重構えとしました。

なお、このレコード参照もPower Automate の標準コネクタで実現しています。APIを叩くプログラムを書いたわけではなく、フローに「レコードの取得」を1つ足しただけです。

勘所4：正本は人間が握る

判断：運用ガバナンスの中核です。

• FAQの正本は Git リポジトリで管理し、変更履歴がすべて残る
• ボットの実行アカウントには読み取り権限しか与えない
• ボットは「このFAQを直すべきです」という提案を投稿することしかできない
• 採用の判断と反映は、必ず人間が行う

理由：自動化を進めるほど「気づいたら誰も中身を把握していない」状態に陥りがちです。正本を人間の承認プロセスの内側に置くことで、これを構造的に防いでいます。

やらなかったこと：ボットが自分でFAQを更新する仕組みは入れませんでした。提案の精度が上がっても、AIが自分の教科書を書き換えられる状態は作らないという方針です。地味ですが、長く運用するうえで最も効いている設計だと考えています。

4. 「入れて終わり」にしない月次サイクル

チャットボットは、入れた瞬間が最も精度が低い状態です。育てる仕組みがなければ、数か月で使われなくなります。

そこで試験運用の期間中は、同じ質問が人間の回答チャネルとボットの回答チャネルの両方に流れる構成を取りました。人間の回答という「答え合わせ」が毎日蓄積される状態です。これを月次で突き合わせ、レポート化しています。

評価では、2つの指標を分けて見ています。どこを直すべきかを切り分けるためです。

この2つを混ぜて1つの「正答率」にしてしまうと、数字が下がったときに何を直せばいいか分からなくなります。分けて測ることで、毎月の改善アクションが自動的に決まる状態を作りました。

5. 実績

ある月の1例です。その月に届いた問い合わせを、1件ずつ評価しています。

担当部門に回るのは、管理者側での対応が必要な質問と、模範解答がまだない新規の質問だけです。

6. 社内チャットボットでうまくいかなかったこと

事例紹介では成功だけが語られがちなので、こちらの設計判断が誤っていた点も共有します。

カテゴリで絞り込むと、正解を取りこぼす

当初、質問をカテゴリ（見積・案件・請求など）に分類してから、そのカテゴリ内のFAQを検索していました。しかし実際の質問は、「請求の画面での操作だが、正解は見積カテゴリのFAQ」のようにカテゴリを平気でまたぎます。

対策として、カテゴリより細かい「サブカテゴリ」（対象×操作の組み合わせ。全35グループ）を新設し、カテゴリ内で十分な候補が見つからない場合は全体検索に切り替えるロジックへ改めました。

キーワードの固定ルールが誤誘導を生む

「担当部署の変更に関する質問は案件カテゴリへ」のような固定ルールを置いたところ、別業務における担当変更の質問まで案件カテゴリに引きずられ、誤った回答を返していました。キーワード単体ではなく、対象を表す語との組み合わせで判定する必要がありました。

7. まとめ

• Power Automate だけで作りきる。独自開発をしない分、業務が分かる人が中身を追え、自分で変えられる
• AIに考えさせない。回答の中身は人間が書き、AIには「選ぶ」「整える」だけをさせる
• 分からないときに人間へ渡す経路を、設計の一部として作る。回答率をKPIにしない
• 正本は人間が握り、AIには読み取り権限しか与えない
• 入れて終わりにせず、毎月の評価と改善のループを回す
• どこを直すべきかが分かる形で測る。指標を混ぜない

この案件を通じて確認できたのは、技術的に難しいのはAIそのものではなく、業務ナレッジを構造化し、それを人間の承認プロセスの内側で維持し続ける運用のほうだということです。だからこそ、仕組みの側は Power Automate だけで作りきれる範囲に収め、手を入れ続けられる状態にしておく価値があります。

Power Automate による AIエージェント開発の研修も承っています

この記事の仕組みは、特別な開発環境も、プログラムを書ける人員も必要としていません。だからこそ、外部に頼み続けるより、自社の担当者が作れるようになったほうが早い場合があります。

FROM CENTER では、Power Automate と AI Builder を使ったAIエージェント開発の研修を提供しています。実際に動く業務フローを題材に、次のような内容を扱います。

• フローの設計と、標準コネクタの組み合わせ方（この記事の構成をそのまま題材にできます）
• AI Builder のプロンプト設計 — AIに任せる範囲を、どう狭めるか
• ナレッジ（FAQ）の構造化と、Dataverse での持たせ方
• 誤答したとき・処理が失敗したときのフォールバック設計
• 運用に乗せるための評価のつくり方（何を測れば、どこを直せばよいか分かるか）

内容と難易度は、貴社の業務と受講者の習熟度に合わせて調整します。

ご相談ください

次のような課題をお持ちでしたら、お気軽にお問い合わせください。現状のヒアリングから、実現可能性の検討までご相談を承ります。

• 基幹システム導入後の問い合わせ対応が、特定の担当者に集中している
• 社内FAQを作ったが、更新されず形骸化してしまった
• 生成AIを業務に使いたいが、誤答のリスクをどう抑えるか決めきれない
• AIを使った業務自動化を内製したいが、何から手をつければよいか分からない

▶ お問い合わせ・研修のご相談はこちら

※本記事は、企業名および具体的なシステム構成・業務内容を伏せたうえでご紹介しています。