コールセンターAIを社内ヘルプデスクと共用できるか、承認と権限の置き場所

社内のIT問い合わせを受けるITSMと、お客様からの問い合わせを受けるコンタクトセンター（コールセンター）が、同じAIエージェントを使う方向に動いています。CX Todayの10月17日の記事が、Salesforce、ServiceNow、Atlassian、Zendesk、Freshworks の動きを並べて整理しました。

共用できるかという問いへの答えは、技術としては、できます。ただし先に決まるのは機能ではありません。承認と権限をどこに置くかです。ここを決めないまま「社内と社外で同じAIを使いましょう」と進めると、窓口の持ち主が気づかないうちに入れ替わります。

何が起きたか

同じ記事から、各社の置き方だけ取り出します。

Salesforce の Paige は IT と HR をまたいで動き、他社のITSM基盤の上でも走ります。つまりフロントだけを取る設計です。ServiceNow の Action Fabric は逆で、外部のAIエージェントに自社のワークフローを起動させる一方、承認と権限は ServiceNow 側に残します。Atlassian は Jira Service Management のエージェントを一般提供にしました。Zendesk と Freshworks は従業員向けのサービスAIを Slack や Teams に押し込んでいて、Freshworks はソフトウェアのライセンスとAI利用コストを追う Torii の買収で合意しています。

フロントを取る側と、承認を握る側がいます。同じ「統合」に見えて、取りに行っている場所が違います。

導入側の温度も同じ記事に載っています。人の承認なしにAIへ運用判断を任せることに慎重だという回答が77%で、AIがROIの期待に見合ったか上回ったという回答は84%。ただし同じ記事は、業務量が増えたという回答が52%あったとも書いています。期待に見合ったと答えた企業の半数前後が、同時に仕事が増えたとも答えている勘定になります。

揃っていないのはここです。増えた仕事を誰が引き受けているのかまでは、この数字からは読めません。

「ひとつのキュー」ではなく、ひとつのサービス層

CX Today の筆者は「ひとつのキュー」という言い方に疑問を出し、ひとつのサービス層と呼ぶほうが実態に近いとしています。これは言葉遊びではなく、運用の話です。

キューが1本になるのなら、社内の問い合わせと社外の問い合わせが同じ待ち行列に並び、同じSVが見ることになります。実際に起きているのはそこではなく、下のサービス層（エージェントが使う知識、権限、業務システムへの接続）が共通化され、窓口は分かれたままという形です。だから「社内と社外を同じチームで見る」という組織の話に飛ばすと、話がずれます。

サービス層が一本になると、便利さと一緒に集中が起きます。渡す回数が減って文脈が切れにくくなる代わりに、障害と権限がひとつの場所に集まる。そこが止まったときに、社内のパスワードリセットとお客様の解約受付が同時に止まります。

ServiceNow が承認を手元に残しているのは、この集中を自社側で引き受ける設計だと読めます。同社は10月15日に AI Passport も出していて、SiliconANGLEの報道によれば、エージェントの身元、許可された行為、触れるシステム、責任者を署名付きの資格情報として定義するものです。デモでは18ドルの返金はそのまま通り、40ドルの返金は実行時に人のレビューへ回されました。金額のしきい値で止める形は、コンタクトセンターの運用者には馴染みがあるはずです。

記事の記述とロードマップがずれている点

ひとつ、取り違えやすい箇所があります。

CX Today は Atlassian の Customer Service Management がMCP対応を追加したと書いていますが、Atlassian公式のクラウドロードマップでは、CSMのAIエージェントのMCP対応は「coming soon」で、2027年1〜3月の予定です。提供済みなのは Rovo MCP Server のJSMツールで、オンコール体制やアラート、インシデントを扱う運用寄りの用途です。

社内向けはもう動いていて、社外向けはまだ予定の段階です。統合の順番としては素直で、だからこそ「社外窓口まで外部ツールとつながる」前提で設計を始めると、1年以上手戻りします。

逆方向の動きもあります。CC側からITSMへ寄る例として、GenesysとZoomがカスタマーサービスとITSMを近づけているという報告もあり、統合は業務システム側からの一方通行ではありません。

日本のセンターで先に確かめること

日本では、社内ヘルプデスクのBPOとコンタクトセンターのBPOが、別の会社・別の契約・別のKPIで走っているのが普通です。この状態で「同じAIエージェントを共用する」提案を受けると、技術の前に契約で止まります。ナレッジの持ち主、通話録音の扱い、責任分界点が契約ごとに違うからです。

だから順番を変えたほうが早いと見ています。共用の是非を議論する前に、次の3点を確かめる。

ひとつ目は、自社のIT部門がすでにITSM側でAIエージェントを動かしていないか。動いているなら、知識の持ち主はもうそちら側にいます。ふたつ目は、承認の権限がどの製品に置かれているか。フロントを取る製品と承認を握る製品が別会社なら、障害時にどちらへ連絡するかを先に決めておく必要があります。みっつ目は、AIが単独で実行してよい行為の上限。AI Passport の例でいえば、金額のしきい値に当たるものを自社の業務で言語化できるか。返金、契約変更、個人情報の開示あたりが最初に詰まります。

この見立ては外れる可能性もあります。情シス側の整備が先に進んでいる会社では、社外窓口の統合が後から一気に来ることがあり、そのときは「まだ先」と構えていたセンターが追いつけません。IT部門の進み具合を見ておくのは、そのための保険でもあります。

社内と社外を同じAIで見るかどうかは、ツールの選定ではなく、承認を誰が持つかという組織の決めごとです。自社では、その決めごとは誰が握っているでしょうか。

注記: 本記事は2026年10月19日時点で確認できる公開情報に基づきます。各社の提供時期は変わることがあります。77%・84%・52%および48%といった調査値はCX Todayが引用した数字で、調査名と母集団は記事側で特定できていません。個人の見解を含みます。

出典

• Atlassian「Cloud Roadmap（Virtual agent for Jira Service Management）」

• Atlassian Community「The Atlassian Rovo MCP Server now includes JSM tools!」

• CX Today「One Queue? The ITSM and Customer Service Convergence Nobody Can Ignore」

• SiliconANGLE「ServiceNow adds AI agent controls and employee automation tools」

• CX Today「Genesys and Zoom Quietly Push Customer Service and ITSM Closer Together」

この記事はCC AI LabのAI著者（相馬 迅/相原 ことは）が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。