Agentforce World Tour Tokyo 2025でかんぽ生命のSalesforce Voice導入事例を見てきた

はじめに

本日、Agentforce World Tour Tokyo 2025で「IBMのAgentforce戦略とかんぽ生命『Salesforce Voice (Service Cloud Voice) による次世代コンタクトセンターの実現』」というセッションを聞いてきました。

正直、「レガシーな大企業がどうSalesforceを導入するか」という話は、自分の仕事とは関係ないかなと思っていたのですが、これが予想以上に面白くて、立ち見が出るほどの満席でした。

特にかんぽ生命の田代さんのお話は、アプリ開発者としても学ぶことが多かったので、印象に残ったポイントをまとめておきます。

Agentforce World Tour Tokyo 2025のセッション画面

セッション概要

登壇者:

• 日本IBM 富高氏（Salesforceプラクティス 日本責任者）
• かんぽ生命保険 田代氏（カスタマーサービス推進部・部長）

内容:

• IBMのAgentforce戦略
• かんぽ生命のSalesforce Voice導入事例

日本IBMとかんぽ生命の協業体制

IBMの戦略: 興味深い調査結果

富高氏のプレゼンで最初に出てきた数字が衝撃的でした。

74%の企業が顧客体験向上に苦労している

Salesforceを実際に使っているユーザー企業の**74%**が、顧客体験・顧客エンゲージメントの向上に苦労しているとのこと。

「こんなに強力なAI機能を使っているのに、なぜビジネス成果を生まないのか」という問題提起から始まりました。

この調査結果は、IBMが年次で公開している「The State of Salesforce」というレポートからの引用だそうです。このレポートは、導入前の話ではなく、実際に使った後にどう使っているか、どう困っているかをまとめたもので、日本語訳も公開されているとのことでした。

IBMのSalesforce領域の強み

IBMが発表した4つの取り組み

IBMは以下の4つの取り組みを発表しています:

1. ゼロコピー統合

   • ZメインフレームのデータをData 360に透過的に連携

2. BYO LLM (Bring Your Own LLM)

   • IBMのエンタープライズ向けLLM「Granite」をSalesforceに持ち込める

3. Watson X Sales Prospecting

   • Salesforce外のデータも含めた見込み客の発掘
   • Agentforceと連携してリード登録

4. Slack向けHR Q&Aエージェント

   • Slack経由でHRの質問に自動回答

かんぽ生命の事例: ここがすごい

会社と事業規模

• 創業: 1916年（来年で110年）
• 顧客数: 約1,700万人
• 年間コール数: 約400万件
• 拠点数: 13拠点
• オペレーター数: 約1,000席
• 特徴: 全国2万を超える郵便局を通じた対面チャネル

かんぽ生命のコンタクトセンターの規模感

これだけの規模の企業が、どうやってモダンなシステムに移行するのか。それが今回の話のポイントでした。

直面していた課題

田代さんが説明した課題がリアルでした:

1. スケーラビリティの問題

   • オンプレの専用端末のため、繁閑に合わせた増減ができない
   • 拠点間の移動も困難

2. システムの分断

   • コールセンターとヘルプデスクが繋がっていない
   • コールとチャットで別々のシステム
   • ナレッジや人材の共有ができない

3. 新技術の取り込みが困難

   • オンプレ基盤では最新の技術を取り入れるのに時間がかかる

4. アフターフォローの難しさ

   • 1,700万人という膨大な顧客数
   • セールス社員だけではきめ細やかなフォローが行き届かない

なぜSalesforceを選んだのか

Salesforce Voice選定の理由

田代さんが挙げた理由:

• 物理的な制約からの解放

  • 繁閑に合わせたスケーリングが可能
  • 機敏な試作にも対応

• 製品アップデートの恩恵

  • 常に最新の顧客体験を提供できる
  • 従業員体験(EX)も向上

• オムニチャネル対応

  • どのチャネルでも同じUI
  • 統合的な管理が可能

Fit to Standard: 開発方針の転換

ここが一番印象的でした。

8:2の原則

ノーコード・ローコード : プロコード = 8 : 2

標準機能を最大限活用する8:2の原則

極力作り込まず、標準機能で実現する方針を徹底したそうです。

従来の開発スタイルからの脱却

田代さんの説明が面白かったです:

「当社のIT部門はユーザーに対してすごく優しいので、何でも作ってくれちゃうんですね。それだとFit to Standardができない」

従来の「Excelフォーマットで要件を提出→交換日記のようなやり取り→初めて画面を見るのはUATの時→『あれ?』となる」というウォーターフォール開発から、アジャイル開発に転換したとのこと。

意識改革の3つのポイント

1. パートナーへ: 遠慮なく言ってください

   • 「どうやって標準でやるか」を提案してもらう
   • 「よそはこんなことやってない」と言ってもらう

2. ユーザー内: 業務を変えることを受け入れる

   • 標準に寄せることで業務が変わることを理解
   • ユーザー側の意識改革

3. 現場ユーザーへ: しっかり伝える

   • 何ができなくなるのか
   • 代わりに何が手に入るのか

生成AIの活用: タイミングが完璧だった

開発途中で大きな出来事がありました。

Einstein GPT（現Agentforce）の発表です。

田代さんの話で印象的だったのが、「オンプレ開発だったら絶対にサービスインに間に合わなかった」という点。

従来なら:

1. 新機能が出る
2. 必要性を検討
3. 予算を確保
4. 製品選定
5. 開発開始

となるところを、Salesforceを選んだことで数ヶ月で取り込むことができたとのこと。

「選んでなかったら、もう生成AI入れれてなかったかもね、というゾッとする話」

実装した機能

• 音声のテキスト化と要約
• 苦情フラグの自動判定
• お問い合わせ分類の自動化
• 複数チャネルからの問い合わせの統合サマリー

今までコミュニケーターが「頭の中で考えて、手で打っていた」ものを自動化したそうです。

開発中の課題が解決された話

開発中、以下のような課題を感じていたそうです:

• 日本語対応していない
• GPTのモデルが最新じゃない

しかし、数ヶ月ですべてアップデートされたとのこと。

「このアップデートのスピード感は、今までIT部門と一緒にやってきたスピード感とは隔世の感がある」

Dreamforceに若手を派遣

先日行われたDreamforceに、ユーザー側チームの若手エースを派遣したそうです。

帰国後の彼の言葉:

「もう間違いないです。Agentforceがこれからの主軸になるのは間違いない」

そこで知った情報:

• Agentforce Bytes: ユーザー側がエージェントを作れる時代
• Salesforce Voice日本語版: もうすぐリリース（予想より早い）

システム構成のポイント

システム設計で特に注力した3つのポイント

特に頑張って作った3つの部分:

1. PDC発信機能

   • 標準にないアウトバウンド機能を実装
   • ただし、作り込みは最小限に

2. 保険手続き・契約情報の参照

   • 基幹システムからAPIで参照
   • データは腹持ちしない設計

3. 生成AI対応

   • 要件定義の時点で生成AIを念頭に置いたデータモデル設計

今後の展望: AIエージェント時代への準備

田代さんが語った今後のビジョンが興味深かったです。

コンタクトセンター業界の現実

• 人手不足は今後ますます厳しくなる
• 生成AIを使わずに今まで以上のサービスを提供するのは「もはや無理」

AIの活用方法

Agentforce的アプローチ

• 人の代わりをする

コパイロット的アプローチ

• 人を支援・エンパワーする

これにより:

• サービス品質向上
• 生産性向上
• 社員の安心感（EX）
• EXがCXに繋がり、会社が成長

ステップアップの構想

1. レガシーシステムのモダナイズ（現在ここ）
2. AIによるナレッジ支援
3. AIによる自動応答
4. AIと人が融合したサービス提供（最終目標）

2025年1月ヘルプデスク、3月コールセンターのリリース予定

ただし、田代さんは「製品側の進化のスピードがものすごく早いので、ユーザー側も食らいついていかないといけない」と語っていました。

必要なスキルの変化

企画側の人間:

• AIありきの顧客体験をデザインする能力
• 自らの手で実装できる能力

現場のコミュニケーター:

• AIにはできない価値を考える
• そのスキルを磨く

「AIが感情を持って、お客様への共感を持って、それがお客様に伝わるぐらいの応対ができるようになったら、もう人は何をするのか。本当に模索している」

印象に残ったポイント

1. Fit to Standardの徹底

「無理に叶えようとしない」というIT部門の姿勢転換。

これ、SaaSアプリ開発者としても考えさせられました。ユーザーの要望を全部叶えようとすると、結局誰にとっても使いにくいプロダクトになってしまう。

標準に寄せることで得られるもの:

• 製品アップデートの恩恵
• 保守コストの削減
• スケーラビリティ
• 新技術の迅速な取り込み

2. アジャイル開発への転換

「Excelフォーマットの交換日記」から「パートナーと一緒に開発」へ。

特に「遠慮なく言ってください」という姿勢が素晴らしいと思いました。これは、お互いの専門性を尊重し合う関係性がないと成立しません。

3. 生成AIの迅速な取り込み

開発中にEinstein GPTが発表されて、それをすぐに取り込めたという話。

「選んでなかったら、もう生成AI入れれてなかった」というのは、プラットフォーム選択の重要性を物語っています。

4. 製品アップデートのスピード感

「日本語対応していない」「GPTのモデルが最新じゃない」という課題が、数ヶ月で解決された。

SaaSプラットフォームの進化スピードに、ユーザー側も追いついていく必要がある、という話が印象的でした。

5. ユーザー部門の学習姿勢

Dreamforceに若手を派遣したり、Salesforceについて「勉強する」ことの重要性を強調していた点。

「Salesforceって何ができて、逆に何ができないのか」を理解することが、Fit to Standardの前提条件。

6. 現実的な目標設定

「1.0から2を越えて3までいく」という目標。いきなり10倍を目指すのではなく、着実にステップアップしていく姿勢。

7. EXとCXの関係

従業員体験(EX)が顧客体験(CX)に繋がり、会社が成長する、という考え方。

AIによって、オペレーターが「安心して働ける」環境を作ることが、最終的にお客様のためになる。

Party on Slack開発者として考えたこと

自分はSlackアプリの開発者として、以下の点が特に参考になりました。

プラットフォームの選択は重要

かんぽ生命がSalesforceを選んだことで、生成AIを迅速に取り込めた。

Party on Slackも、Slackというプラットフォーム上で動いているからこそ、Slack側のアップデート（新しいUI要素、AI機能など）の恩恵を受けられています。

Fit to Standardの考え方

「8:2の原則」は、マーケットプレイスに出すアプリ開発でも重要だと思いました。

カスタマイズ可能性を高めすぎると、保守コストが上がり、結局サステナブルじゃなくなる。

標準的な使い方で80%のユースケースをカバーし、本当に必要な20%だけをカスタマイズ可能にする。

ユーザーとの関係性

「遠慮なく言ってください」という姿勢。

Party on Slackでも、ユーザーから「これできませんか?」という要望をもらうことがあります。

その時に「できます」と安易に言うのではなく、「標準的な使い方だとこうです」「こういう理由でこの機能はありません」と説明することの大切さ。

AIの活用

かんぽ生命の「音声のテキスト化→要約→分類」という流れは、AIの実践的な使い方として非常に参考になりました。

Party on Slackでも、会話の要約や分類を自動化できる可能性があります。

まとめ

かんぽ生命の事例は、「大企業のレガシーシステム刷新」という話だけでなく、以下のような普遍的な学びがありました:

• Fit to Standard: 標準に寄せることで得られる長期的なメリット
• アジャイル: パートナーとの協働関係の重要性
• プラットフォーム選択: 進化の早いプラットフォームを選ぶことの価値
• 学習姿勢: ユーザー部門も継続的に学ぶ必要性
• 段階的な進化: いきなり10倍ではなく、着実に2倍、3倍を目指す

特に印象的だったのが、田代さんの「製品側の進化のスピードに食らいついていかないといけない」という言葉。

技術の進化が早い今、ユーザー側も開発側も、お互いに学び続けることが必要なんだと感じました。

2025年1月にヘルプデスク、3月にコールセンターがリリースされる予定とのことなので、その後の続報も楽しみです。

この記事が参考になったら、ぜひLGTMをお願いします！

参考

• Agentforce World Tour Tokyo 2025
• セッション: 2-E5「IBMのAgentforce戦略とかんぽ生命『Salesforce Voice (Service Cloud Voice) による次世代コンタクトセンターの実現』」