Salesforce Case Management の極意：サービス品質を最大化するコンサルタントの視点

概要とビジネスシーン

Salesforce Case Management は、顧客からの問い合わせ、問題、リクエスト（ケース）を一元的に管理し、解決プロセスを最適化することで、顧客満足度向上とサービス運用効率化を実現する Service Cloud の中核機能です。これは、顧客とのあらゆるインタラクションをトラッキングし、迅速かつ効果的な対応を可能にするための基盤を提供します。

実際のビジネスシーン

Salesforce Case Management は、多岐にわたる業界でその真価を発揮します。

シーンA：製造業 - 製品サポート部門

ビジネス課題： 製品の故障報告や技術的な問い合わせが電話やメールでバラバラに寄せられ、対応状況の把握が困難。技術者が個別に顧客とやり取りするため、ナレッジが属人化し、平均解決時間（Average Handle Time: AHT）が長くなりがち。
ソリューション： Web-to-Case や Email-to-Case を設定し、顧客からの問い合わせを Salesforce のケースとして自動的に作成。製品カテゴリや緊急度に基づいて担当技術者へ自動的にケースをルーティング（Assignment Rules）。過去の解決策をナレッジベース（Knowledge Base）として集約・公開し、顧客自身での問題解決を促進するとともに、サポート担当者が参照できるようにします。
定量的効果： 平均解決時間を 30%短縮、顧客満足度（CSAT）を 15%向上、ナレッジベース活用による電話対応件数を 10%削減。

シーンB：金融サービス業 - 顧客不正疑義対応

ビジネス課題： クレジットカードの不正利用疑義や口座不正アクセス報告に対し、迅速かつ正確な調査・対応が求められる。規制順守（Regulatory Compliance）の要件も高く、各ケースの進捗状況や監査証跡（Audit Trail）の管理が複雑。
ソリューション： ケースオブジェクトを活用して不正疑義報告を管理し、ケースタイプに基づいて専門の調査チームに自動割り当て。進捗状況をステータスごとに細かく定義し、SLA（Service Level Agreement）とマイルストーン（Milestones）を設定して対応期限を可視化。重要な対応ステップをフロー（Flow）で自動化し、監査に必要な情報はケースの活動履歴として自動記録します。
定量的効果： 不正疑義解決までの平均時間を 40%短縮、規制当局への報告遅延を ゼロに、顧客の信頼度を 大幅に向上。

シーンC：ヘルスケア - 患者サポート

ビジネス課題： 医療機器の不具合報告や患者からの治療に関する問い合わせが急増。個人情報保護（Privacy Protection）の重要性が高く、適切な担当者への割り当てと、機密情報を安全に扱うためのプロセスが必須。
ソリューション： セキュアなチャネル（ポータル経由など）でケースを登録し、患者情報が Salesforce 上で適切に保護されるよう、権限設定とデータマスキングを徹底。オムニチャネル（Omni-Channel）を活用して、電話、チャット、メールなど複数のチャネルからの問い合わせを一元的に管理し、医療専門家や関連部署に適切なケースをルーティング。SLAとエスカレーションルール（Escalation Rules）を設定し、緊急性の高い問い合わせに迅速に対応します。
定量的効果： 患者からの問い合わせ対応時間を 25%短縮、機密情報漏洩リスクを 最小化、患者満足度を 20%向上。

技術原理とアーキテクチャ

Salesforce Case Management は、Case 標準オブジェクトを中心に、関連する複数のオブジェクトと自動化ツールを組み合わせることで機能します。

基礎的な動作メカニズム

顧客からの問い合わせは、Web-to-Case、Email-to-Case、Lightning Web Component (LWC) を利用したカスタムフォーム、API連携、オムニチャネルルーティング（Omni-Channel Routing）などの様々なチャネルを通じて Salesforce の Case オブジェクトレコードとして作成されます。作成されたケースは、事前に設定された割り当てルール（Assignment Rules）に基づいて適切なキュー（Queue）またはユーザに自動的に割り当てられます。担当者は Service Console を利用してケースの詳細を確認し、ナレッジベースを参照しながら問題解決にあたります。解決のプロセスは、フロー（Flow）や Apex トリガー（Apex Trigger）などの自動化ツールによって支援され、SLA と連携して解決期限を管理します。

主要コンポーネントと依存関係

Case オブジェクト： 顧客の問い合わせや問題を表現する中心的なオブジェクト。
Account & Contact： ケースに関連する顧客（企業）と担当者（個人）の情報。
Solution / Knowledge Article： 過去の解決策やFAQを格納し、迅速な問題解決を支援。
Entitlement & Milestones： 顧客のサービス契約に基づき、SLAを適用し、期限を管理。
Assignment Rules & Escalation Rules： ケースの自動割り当てとエスカレーションロジックを定義。
Web-to-Case / Email-to-Case： ウェブサイトやメールからのケース自動作成機能。
Omni-Channel： 複数チャネルからの問い合わせを一元管理し、エージェントに効率的にルーティング。
Service Console： サポートエージェント向けの統合ワークスペース。
Flow / Process Builder / Apex Trigger： ケースの作成、更新、クローズ時の自動化ロジック。

データフローの例：Webサイトからの問い合わせ

ステップ	説明	関与するコンポーネント
1. ケース作成	顧客がWebサイトのフォームから問い合わせを送信。	Web-to-Case
2. ケースレコード生成	Salesforce に新しい Case レコードが自動生成される。	Case オブジェクト
3. 担当者割り当て	定義された割り当てルールに基づき、適切なキューまたはユーザにケースが割り当てられる。	Assignment Rules, Queue / User
4. SLA適用	顧客のEntitlementに基づき、SLAが適用され、解決期限が設定される。	Entitlement, Milestones
5. 自動通知	担当者へケース割り当て通知、顧客へ受付完了メールが自動送信される。	Flow / Email Alert
6. 解決処理	担当者が Service Console でケースを処理し、ナレッジを参照しながら解決にあたる。	Service Console, Knowledge
7. ケースクローズ	問題が解決され、ケースがクローズされる。顧客に解決通知。	Case オブジェクト, Flow / Email Alert

ソリューション比較と選定

Case Management の実装において、Salesforce の標準機能だけでなく、カスタム開発や他システムとの連携も選択肢となります。それぞれの特性を理解し、最適なソリューションを選定することが重要です。

ソリューション	適用シーン	パフォーマンス	Governor Limits	複雑度
Salesforce Case Management (Service Cloud)	顧客サポート、社内ヘルプデスク、SLA管理、オムニチャネル連携、Salesforceエコシステム内での統合が最重要。	大規模なデータ量でもスケーラブル。リアルタイム処理に強み。	標準機能の範囲では考慮不要。FlowやApexで複雑な自動化を組む際に注意。	設定ベースで多くの機能を実装可能。拡張は中程度。
カスタムオブジェクトによるCase代替	特定の業界要件が非常に特殊で、標準 Case オブジェクトでは表現しきれない場合。または極めて小規模で単純な追跡のみを目的とする場合。	設計次第。効率的なSOQLとDMLでパフォーマンスは維持可能。	ApexやFlowでの自動化ロジックに強く依存するため、詳細な管理が必要。	機能要件全てをゼロから設計・開発するため、非常に高い。
外部 ITSM システム (例: ServiceNow, Jira Service Management) と連携	既に組織全体で特定の ITSM システムが標準化されており、Salesforce は営業・マーケティング用途が主で、サポートは既存システムで継続したい場合。または非常に複雑なITサービス管理プロセスが必要な場合。	各システムのパフォーマンスに依存。連携部分がボトルネックになる可能性。	Salesforce側のAPI連携（Callout）に注意が必要。	連携の設計・実装・保守が複雑。データ同期の問題が発生しがち。

Salesforce Case Management を使用すべき場合

✅ 顧客体験（Customer Experience）の向上と一貫性を重視し、Salesforce を顧客データ管理のハブとして活用したい場合。
✅ 電話、メール、チャット、Webサイトなど、複数のチャネルからの問い合わせを一元的に管理し、効率的なルーティングと解決プロセスを構築したい場合。
✅ SLA（Service Level Agreement）に基づいたサービスレベルの達成と、その監視・管理が必須である場合。
✅ 豊富な自動化機能（Flow, Assignment Rules, Escalation Rules, Macro）を活用し、エージェントの作業負荷を軽減し、生産性を向上させたい場合。
✅ ナレッジベース（Knowledge Base）を構築し、顧客の自己解決を促進したり、エージェントの解決時間を短縮したりしたい場合。

❌ 非常にニッチで特殊な、標準の Case オブジェクトでは対応困難なビジネスロジックが多すぎる場合（ただし、多くの場合はカスタムフィールドやカスタムオブジェクト、Flowなどで対応可能）。

実装例

ここでは、ケースがクローズされた際に、関連する未完了のタスクを自動的に完了済みにするシンプルな Apex トリガーの例を示します。これは Case Management における自動化の一例です。

/**
 * @description Case がクローズされた際に関連する未完了タスクをクローズするトリガー
 */
trigger CaseAfterUpdateTrigger on Case (after update) {

    // ケースが更新され、かつステータスが変更された場合のみ処理を実行
    if (Trigger.isUpdate) {
        // 完了状態に移行したケースのIDを収集するSet
        Set<Id> closedCaseIds = new Set<Id>();

        // 更新されたケースをループ処理
        for (Case newCase : Trigger.new) {
            // トリガーマップから変更前のケースレコードを取得
            Case oldCase = Trigger.oldMap.get(newCase.Id);

            // ケースのステータスが 'Closed' に変更されたかどうかをチェック
            // ここでは'Closed'を最終状態としていますが、組織の定義に合わせて調整してください
            if (newCase.Status == 'Closed' && oldCase.Status != 'Closed') {
                closedCaseIds.add(newCase.Id);
            }
        }

        // 完了状態になったケースが存在する場合
        if (!closedCaseIds.isEmpty()) {
            // 該当ケースに関連する未完了のタスクをクエリ
            List<Task> tasksToClose = [
                SELECT Id, Status
                FROM Task
                WHERE WhatId IN :closedCaseIds
                AND IsClosed = FALSE
            ];

            // クエリ結果が空でない場合
            if (!tasksToClose.isEmpty()) {
                // 各タスクのステータスを 'Completed' に更新
                // 'Completed' は一般的な完了ステータスですが、組織の定義に合わせて調整してください
                for (Task task : tasksToClose) {
                    task.Status = 'Completed';
                    task.IsClosed = TRUE; // タスクをクローズ済みに設定
                }
                
                // タスクを一括更新
                try {
                    update tasksToClose;
                } catch (DmlException e) {
                    // エラーハンドリング：ログ記録やエラー通知など
                    System.debug('Error closing related tasks: ' + e.getMessage());
                    // 必要に応じて、エラーを再スローするか、部分的な成功を許容するかを決定
                }
            }
        }
    }
}

実装ロジック解析：

トリガー定義： CaseAfterUpdateTrigger は Case オブジェクトの after update イベントで実行されます。これは、ケースの更新がデータベースにコミットされた後に発火し、関連レコードの操作に適しています。
ステータス変更の検出： Trigger.isUpdate で更新操作であることを確認し、Trigger.new と Trigger.oldMap を利用して、ケースのステータスが以前の「非クローズ状態」から「クローズ状態」に変わったケースの Id を収集します。
関連タスクの取得： closedCaseIds に収集されたケース Id に関連付けられ、かつ未完了（IsClosed = FALSE）である Task レコードを SOQL クエリで取得します。WhatId フィールドは、タスクがどのレコードに関連付けられているかを示す汎用的な参照フィールドです。
タスクの更新： 取得したすべてのタスクの Status を 'Completed'（または組織の定義に応じた完了ステータス）に設定し、IsClosed を TRUE に設定します。
DML 操作： 更新されたタスクのリストを update tasksToClose; で一括更新（バルク化）します。これにより、Governor Limits の回避とパフォーマンスの向上が図られます。
エラーハンドリング： try-catch ブロックを使用して、DML 操作中に発生する可能性のあるエラーを捕捉し、デバッグログに記録します。これにより、システム管理者や開発者が問題の原因を特定しやすくなります。

注意事項とベストプラクティス

権限要件

Service Cloud User License： Service Cloud の機能を利用するための必須ライセンス。
Case オブジェクトの権限： プロファイル（Profile）または権限セット（Permission Set）で、Case オブジェクトに対する「参照（Read）」「作成（Create）」「編集（Edit）」「削除（Delete）」権限を適切に設定します。
関連オブジェクトの権限： Account, Contact, Solution, Knowledge Article, Task など、ケースに関連するオブジェクトへのアクセス権限も必要です。
特定の機能権限： Omni-Channel の利用には「Omni-Channel Supervisor」などの特定の権限セットが必要な場合があります。

Governor Limits

Salesforce はマルチテナント環境であり、リソースの公平な利用を保証するため、Governor Limits を設けています。特に自動化やデータ移行では注意が必要です。

SOQL クエリの合計数： 同期トランザクションで最大 100、非同期トランザクションで最大 200。
DML ステートメントの合計数： 同期・非同期トランザクションともに最大 150。
DML 行数： 1トランザクションで最大 10,000 行。
CPU 時間： 同期トランザクションで最大 10,000ms、非同期トランザクションで最大 60,000ms。
非同期 Apex 実行数： 1日あたり最大 250,000 回（または組織ライセンスの数 × 200 のいずれか大きい方）。
ヒープサイズ： 同期 Apex で最大 6MB、非同期 Apex で最大 12MB。

エラー処理

Flow エラーハンドリング： Flow Builder の「パスの障害」要素を利用し、DML エラーなどを捕捉して、特定のエラーメッセージを表示したり、別のフローを呼び出したりします。
Apex 例外処理： 上記のコード例のように try-catch ブロックを適切に使用し、DML やその他の API コールでのエラーを捕捉し、デバッグログに記録します。部分的な成功を許容するか、全てをロールバックするかをビジネス要件に応じて決定します。
カスタムエラー通知： 大規模なバッチ処理やインテグレーションにおいてエラーが発生した場合、特定のユーザや管理者にカスタム通知（メール、Chatterなど）を送信する仕組みを構築します。

パフォーマンス最適化

バルク化（Bulkification）の徹底： Apex トリガーや Flow で、常にリストやセットを使い、SOQL クエリや DML ステートメントをループ内で実行しないようにします。大量のレコードを一括で処理する設計を心がけます。
SOQL クエリの最適化： 不要なフィールドを選択せず、WHERE 句で絞り込みを行い、ORDER BY 句の使用を最小限に抑えます。大規模なデータセットに対しては、カスタムインデックスの適用を検討します。
自動化の合理化： 複数の Flow や Apex トリガーが同じオブジェクトで動作する場合、実行順序を考慮し、冗長な処理を統合します。特に複雑な Flow は、パフォーマンスに影響を与える可能性があるため、シンプルかつ効率的な設計を心がけます。
非同期処理の活用： 大量のデータ処理や外部システムとのコールアウトが必要な場合は、Batch Apex, Queueable Apex, Future メソッドなどの非同期 Apex を積極的に利用し、同期トランザクションの負荷を軽減します。

よくある質問 FAQ

Q1：Service Console を使用する最大のメリットは何ですか？

A1：Service Console は、サポートエージェントが複数のレコードや関連情報を単一の画面で確認・操作できる統合ワークスペースです。タブ形式で複数のケースを同時に開いたり、関連レコード（取引先、取引先責任者、ナレッジ記事、活動履歴など）をサイドバーで表示したりできるため、エージェントは画面遷移を最小限に抑え、顧客対応の効率とスピードを大幅に向上させることができます。

Q2：ケースに関連する自動化（Flow や Apex）で予期せぬ動作が発生した場合、どのようにデバッグしますか？

A2：Flow の場合： Flow Builder 内の「デバッグ（Debug）」機能を使用して、特定の入力値でフローを実行し、各ステップの実行結果や変数の中身を確認できます。Apex の場合： 開発者コンソール（Developer Console）の「デバッグログ（Debug Logs）」を利用します。ログレベルを適切に設定し、デバッグ対象のユーザが実行したトランザクションの詳細なステップ（SOQL クエリ、DML 操作、Apex メソッドの呼び出し、Governor Limits の消費状況など）を確認することで、問題の原因を特定します。

Q3：ケース管理のパフォーマンスが低下していると感じた場合、どのような指標を監視すべきですか？

A3：最も重要な指標は、Apex CPU Time（Apex CPU 時間）とSOQL Queries（SOQL クエリ数）です。これらはデバッグログで確認できます。また、Salesforce の「設定（Setup）」>「プロセスオートメーション（Process Automation）」>「オートメーションの概要（Automation Home）」や「Flow の一時停止されたインタビュー（Paused Flow Interviews）」で、実行中のフローの状態やエラーを監視できます。ページロード時間やレポート実行時間も、エンドユーザー体験の低下を示す重要な指標となります。

まとめと参考資料

Salesforce Case Management は、顧客サポート業務をデジタル化し、顧客満足度の向上と運用効率の最大化を実現するための強力なプラットフォームです。コンサルタントの視点からは、単なる機能の導入に留まらず、ビジネスプロセスとの整合性、ユーザ体験、そして将来的な拡張性を考慮した設計が成功の鍵となります。豊富な標準機能と柔軟なカスタマイズ・自動化オプションを組み合わせることで、あらゆる業界の複雑なケース管理要件に対応し、企業の競争力強化に貢献します。

公式リソース

📖 公式ドキュメント：Service Cloud の概要
- https://help.salesforce.com/s/articleView?id=sf.service_console_overview.htm&type=5
📖 公式ドキュメント：Case オブジェクトの Apex 開発者ガイド
- https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_forcecom_cases.htm
🎓 Trailhead モジュール：Service Cloud の基礎
- https://trailhead.salesforce.com/content/learn/modules/service_cloud_basics
🎓 Trailhead モジュール：Service Cloud Specialist
- https://trailhead.salesforce.com/content/learn/modules/service-cloud-specialist

にゃんこのSalesforce日記

このブログを検索