エムスリーキャリアで医師領域のSalesforceまわりの開発・運用を担当している後藤です。 今回は、社内から寄せられる問い合わせ・依頼の対応を、AIチャットで構造的に減らしにいった取り組みを紹介します。
エンジニアに寄せられる「社内依頼」の実情
私たちのチームには、営業・マーケティング・お客様センターなど各部署から、Salesforceに関する依頼が日々寄せられます。「この項目はどういう条件で更新されるのか?」という仕様の質問から、権限付与・施設ページのマージといった定型作業、項目追加や自動化などのシステム変更まで、種類も粒度もさまざまです。
直近（2026/6/1〜7/22）の起票データを見ると、内訳はこうなっていました。
| レコードタイプ | 割合 |
|---|---|
| 定型作業 | 34% |
| 質問・相談 | 28% |
| システム変更 | 28% |
| 不具合・障害 | 10% |
ここで目を引くのは、「質問・相談」と「定型作業」で全体の6割を超えるという点です。この2つは、多くが「過去に誰かが答えた質問」「手順が決まっている作業」であり、本来ならわざわざエンジニアに起票しなくても解決できる余地があります。 しかし従来は、依頼者がSalesforce画面から自力でレコードタイプを選び、白紙のフォームに要件を書いて起票する導線しかありませんでした。
結果として、
- 調べれば分かる質問がそのまま起票され、エンジニアが調査・回答に時間を割く
- レコードタイプの選択ミスや情報不足で、起票後に差し戻し・確認のやり取りが発生する
という形で、対応コストが積み上がっていました。 特に「質問・相談」は、Salesforceの仕様確認や操作方法など過去の回答の蓄積で自己解決できる余地が大きいカテゴリでした。
打ち手：入口に「社内依頼受付AI」を置く
そこで「社内依頼相談（AIアシスト）」というAIチャットを作成しました。依頼者はAIチャットに「◯◯が動かない」「◯◯をしたい」と話しかけるだけです。
チャットは次の4つを担います。
- ナレッジ・メタデータをその場で検索して回答 — Salesforceナレッジと本番Salesforceメタデータを検索し、その場で答える。ここで解決すれば、そもそも依頼を作らずに済む
- 依頼の種類（レコードタイプ）を自動判定 — 会話内容から適切な種類を提案する
- 依頼文のドラフトを自動生成 — レコードタイプごとの入力項目に沿って整形。あとは貼って保存するだけ
- システム変更依頼は一次チェックも実施 — 「工数に見合う効果があるか」をAIが先に確認し、基準を満たさない場合は修正を促す（差し戻しの削減）
ねらいは以下の2点です。 答えられる問い合わせはその場で答えて起票させない 起票される依頼は質を揃える 前者は問い合わせ総量を、後者は起票後の手戻りを減らしにいく設計です。
仕組み：Salesforce × Dify × GitHub
技術的な構成はシンプルに保ちました。本体はDify上のチャットフローです。
この構成のポイントは、判定基準・定型作業一覧・受付AIのプロンプトそのものまで、すべてGitHubの.mdファイルとして管理し、チャット実行時にリアルタイムで取得していることです。
最初はプロンプトをワークフロー定義（DSL）に埋め込んでいたのですが、文言を1行直すたびにDSLを再インポートして公開し直す必要がありました。そこで、基準・一覧・プロンプトを.mdに外出しし、DifyのHTTPノードでGitHubから取得する形に変更。運用担当が.mdを編集してpushすれば、Dify側の作業なしで即座にチャットへ反映されるようになりました。 「分類がいまいち」と思ったらその場で基準を書き換えて試せる。この"運用で回せる"状態が、AIチャットを育てていく上で効いています。
質問・相談への回答では、単に社内のナレッジ保管場所を案内するのではなく、調べて分かった中身そのものを回答に書き、根拠にしたナレッジ記事のタイトルを添えるようにしました。依頼者にとっての検索先はあくまでSalesforce上のナレッジであり、内部のファイルパスを見せるのは導線として誤りだからです。
起票の"その先"も自動でつなぐ
さらに、システム変更として起票された依頼は、AIの一次チェックがOKになると、そこからGitHub Issueが自動で作られ、社内の開発エージェントが設計書ドラフトを生成するところまでつながっています。依頼の入口（社内依頼受付AI）から設計の入口までを、人手を挟まずに橋渡しする形です。承認は人間が行い、無駄な実装を防ぐゲートは残しています。
効果：「質問・相談」の起票が約4割減った
導入前後で実際に何が変わったのか、社内依頼の起票データで確認してみました。今回のチャットの主戦場は「①ナレッジ・メタデータ検索でその場で回答する」機能なので、対象を「質問・相談」の起票件数に絞り、リリース日を挟んで前後1ヶ月を比較します。
1日あたりの起票件数で約41%の減少でした。 週次で見ても、導入直前の週をピークに、導入週から減少に転じ、その後は低い水準で安定しています。
もちろん、この減少がすべてチャットの効果だと厳密に証明できるわけではありません（依頼内容の季節性や他の要因も混ざり得ます）。 ですが、リリースのタイミングを境に明確な減少トレンドへ転じ、その後1ヶ月近く低水準が続いているのは、狙っていた「その場で自己解決させて起票させない」導線が機能していると捉えています。
あわせて、起票される依頼文の粒度が揃い、レコードタイプの選択ミスによる差し戻しも減ってきた実感があります。こちらは定性的な手応えの段階ですが、次のフェーズではDify側のログ（会話数・自己解決率・起票への転換率）も取得し、より直接的な効果測定につなげていく予定です。
作ってみて改めて思うのは、AIチャットの価値は「賢いモデルを置くこと」以上に、基準やプロンプトを運用で回せる形にしておくことにあるということでした。 現場の問い合わせは生き物なので、育てられる仕組みかどうかが効いてきます。
「自動化で楽をする」だけでなく、「自動化しても品質を落とさないためのゲートをどこに置くか」という点には特に注意を払いました。 システム変更の一次チェックや最終的な承認工程など、AIに任せるべき領域と人間が責任を持つ領域を明確に分けることが、持続可能な社内AI運用の鍵だと考えています。
おわりに
エムスリーキャリアのエンジニア組織では、こうした社内業務のAI活用を含め、さまざまな取り組みを進めています。少しでも関心を持っていただけた方は、カジュアル面談も受け付けていますので、ぜひお話しさせてください。
