Salesforce ナレッジの習得：コンサルタントが解説する戦略的導入とベストプラクティス

背景と応用シナリオ

現代のビジネス環境において、顧客満足度の向上とサポート業務の効率化は、企業が成功を収めるための重要な鍵となります。この課題に対する強力なソリューションとして、Salesforce は Salesforce Knowledge (セールスフォースナレッジ) を提供しています。Salesforce Knowledge は、単なる FAQ ページを作成するツールではありません。これは、企業内に散在する知識や情報を一元的に集約、管理、共有し、それを最も必要とする人（顧客、サポートエージェント、パートナー）に適切なタイミングで届けるための戦略的なプラットフォームです。

Salesforce 相談コンサルタントとして、私は多くの企業が Knowledge を導入することで、以下のような大きな変革を遂げるのを目の当たりにしてきました。

応用シナリオ

顧客の自己解決促進: Experience Cloud (旧 Community Cloud) サイトにナレッジベースを公開することで、顧客はサポートに問い合わせる前に自分で問題を解決できるようになります。これにより、問い合わせ件数が削減され、顧客は24時間365日、迅速に回答を得ることができます。
サポートエージェントの業務効率化: Service Cloud のコンソール内で、エージェントは対応中のケースに関連するナレッジ記事を AI (Einstein) が推薦する形で受け取ったり、簡単に検索したりできます。これにより、回答の検索時間が短縮され、より迅速かつ一貫性のある質の高いサポートを提供できるようになります。新人エージェントの早期戦力化にも大きく貢献します。
社内情報の共有: サポート部門だけでなく、営業部門向けの製品情報、マーケティング部門向けのキャンペーン情報、人事部門向けの社内規定など、組織全体の知識資産を管理・共有するプラットフォームとしても活用できます。

このように、Salesforce Knowledge は守りのサポートコスト削減だけでなく、攻めの顧客エンゲージメント向上にも寄与する、極めて重要な戦略的ツールと言えるのです。本記事では、コンサルタントの視点から、その導入を成功に導くための原理、実践的なアプローチ、そしてベストプラクティスを解説します。

原理説明

Salesforce Knowledge の導入を計画する上で、その根幹をなす概念を理解することは不可欠です。特に、従来の Classic Knowledge から進化した Lightning Knowledge (ライトニングナレッジ) は、標準オブジェクトをベースに構築されており、柔軟性と拡張性が大幅に向上しています。

Lightning Knowledge のコアコンポーネント

レコードタイプ (Record Types)

Lightning Knowledge では、記事の種別を標準オブジェクトのレコードタイプ (Record Types) を使用して管理します。これにより、「FAQ」「手順書」「トラブルシューティング」「製品仕様」といった異なる種類の記事ごとに、異なるページレイアウト、項目、ライフサイクルを定義できます。例えば、「FAQ」レコードタイプはシンプルな質問と回答の項目のみを持つ一方、「手順書」レコードタイプは手順ごとの画像や詳細な説明を含むリッチテキスト項目を持つ、といった設計が可能です。これは導入初期段階で設計すべき最も重要な要素の一つです。

データカテゴリ (Data Categories)

データカテゴリ (Data Categories) は、ナレッジ記事を分類し、整理するための階層的な仕組みです。これは図書館の分類システムに似ており、ユーザーが目的の記事を簡単に見つけられるようにするだけでなく、記事へのアクセス権を制御するためにも使用されます。例えば、「製品」というカテゴリグループを作成し、その下に「製品A」「製品B」といったカテゴリを設け、さらにその下に「インストール」「設定」「トラブルシューティング」といったサブカテゴリを作成できます。ユーザーのプロファイルや権限セットに基づいて、特定のデータカテゴリに属する記事のみを表示させることが可能です。

記事のライフサイクルとバージョン管理

ナレッジ記事には明確なライフサイクルが存在します。「ドラフト」→「レビュー中 (承認プロセス経由)」→「公開済み」→「アーカイブ済み」というステータスを遷移します。記事が更新されるたびに新しいバージョンが作成され、過去のバージョンも保持されるため、変更履歴の追跡が容易です。承認プロセス (Approval Process) を組み込むことで、記事が公開される前に法務部門や製品担当者など、適切なレビュー担当者による承認を必須とすることができ、情報の正確性と品質を担保できます。

チャネル (Channels)

作成したナレッジ記事をどこに公開するかを制御するのがチャネル (Channels) です。以下の4つの主要なチャネルがあります。

Internal App: Salesforce 社内ユーザーのみがアクセス可能。サポートエージェント向けの内部情報などに利用します。
Customer: Experience Cloud サイトを通じて顧客に公開されます。
Partner: Experience Cloud サイトを通じてパートナーに公開されます。
Public Knowledge Base: ログイン不要で、インターネット上の誰もがアクセスできる公開ナレッジベースです。

記事ごとに公開するチャネルを選択できるため、情報の機密性に応じた柔軟な配信が可能です。

サンプルコード

コンサルタントとして、ナレッジベースを他のシステムと連携させたり、カスタムコンポーネントで高度な検索機能を提供したりする要件に直面することがよくあります。その際、API を使用してナレッジ記事を検索・取得する必要が出てきます。Salesforce の強力な検索言語である SOSL (Salesforce Object Search Language) は、ナレッジ記事のような非構造化テキストデータの検索に非常に適しています。

以下のコードは、指定したキーワードを含み、特定のデータカテゴリに属する、日本語で公開中のナレッジ記事を検索する Apex コードの例です。

// 検索キーワードを定義
String searchTerm = '設定方法';

// SOSL クエリを構築
// FIND句: 全文検索の対象となるキーワードを指定します。
// IN ALL FIELDS句: 全てのテキスト項目を検索対象とします。
// RETURNING句: 取得するオブジェクトと項目を指定します。
// Knowledge__kav は公開済み記事のバージョンを表すAPI参照名です。
// WHERE句: さらに絞り込み条件を指定します。
// PublishStatus='Online' は公開中の記事のみを対象とします。
// Language='ja' は日本語の記事を対象とします。
// WITH DATA CATEGORY句: 特定のデータカテゴリに属する記事を絞り込みます。
// ここでは、'製品'というカテゴリグループ内の'ラップトップ'カテゴリ、
// かつ、'地域'カテゴリグループ内の'日本'カテゴリに属する記事を検索しています。
String soslQuery = 'FIND :searchTerm IN ALL FIELDS RETURNING ' +
                   'Knowledge__kav(Id, Title, UrlName, Summary ' +
                   'WHERE PublishStatus=\'Online\' AND Language=\'ja\') ' +
                   'WITH DATA CATEGORY 製品__c AT ラップトップ__c AND 地域__c AT 日本__c';

// SOSLクエリの実行
List<List<SObject>> searchResults = Search.query(soslQuery);

// 結果の取得（Knowledge__kavオブジェクトの結果は最初のリストに含まれる）
List<Knowledge__kav> articles = (List<Knowledge__kav>)searchResults[0];

// 結果をデバッグログに出力
for(Knowledge__kav article : articles){
    System.debug('記事ID: ' + article.Id + ', タイトル: ' + article.Title);
}

この SOSL クエリは非常に強力で、WITH DATA CATEGORY 句を使うことで、複雑な分類構造の中からでもピンポイントで必要な情報を探し出すことができます。カスタムの Lightning Web Component (LWC) からこの Apex メソッドを呼び出すことで、標準コンポーネントにはない、独自のナレッジ検索体験を構築することが可能です。

注意事項

Salesforce Knowledge の導入プロジェクトを成功させるためには、技術的な側面だけでなく、運用面やガバナンスに関する注意点を十分に理解しておく必要があります。

移行計画 (Migration Plan)

もし Classic Knowledge を利用している場合、Lightning Knowledge への移行は必須のステップとなります。Salesforce が提供する Knowledge Migration Tool (ナレッジ移行ツール) を使用しますが、これは単純なボタンクリックで終わる作業ではありません。記事タイプとレコードタイプのマッピング、データカテゴリ構造の見直し、添付ファイルの移行など、慎重な事前計画とテストが不可欠です。

権限とライセンス (Permissions and Licenses)

ナレッジ記事を作成・管理するためには、ユーザーに Knowledge User License (ナレッジユーザーライセンス) を割り当てる必要があります。その上で、プロファイルや権限セットを用いて、オブジェクトレベル（参照、作成、編集、削除）および項目レベルのアクセス権を細かく設定します。さらに、データカテゴリの表示設定により、ユーザーの役割に応じて閲覧できる記事の範囲を制御することが、セキュリティと利便性の両立のために重要です。

コンテンツガバナンス (Content Governance)

「誰が、いつ、どのような内容の記事を作成し、誰がレビューし、いつ公開・更新・アーカイブするのか」という一連のルール、すなわちコンテンツガバナンスを定義しなければ、ナレッジベースはすぐに陳腐化し、信頼性を失います。コンテンツのスタイルガイド（文体、用語の統一）、承認プロセスの定義、定期的な見直しと棚卸しのプロセスを確立することが不可欠です。

API とオブジェクトモデル (API and Object Model)

API を通じてナレッジを扱う際は、オブジェクトモデルを正しく理解する必要があります。Knowledge__kav は「公開済み」または「翻訳済み」の記事バージョンを表すオブジェクトであり、主に参照に使用されます。一方、記事のマスター（全バージョンを束ねる親）は Knowledge__ka という API 参照名を持ちます。記事を作成・編集する際は Knowledge__ka を操作します。この違いを理解しないと、API 連携で問題が発生する可能性があります。また、SOQL/SOSL クエリは Salesforce のガバナ制限に従うため、大量のデータを扱う際は注意が必要です。

まとめとベストプラクティス

Salesforce Knowledge は、正しく導入・運用すれば、顧客満足度の向上、サポートコストの削減、業務効率の劇的な改善を実現する強力なプラットフォームです。しかし、そのポテンシャルを最大限に引き出すためには、技術的な設定だけでなく、戦略的な視点からのアプローチが求められます。

Salesforce 相談コンサルタントとして推奨するベストプラクティスは以下の通りです。

明確な戦略から始める: 導入の目的（例：問い合わせ削減率 15% 向上、初回コール解決率 10% 向上）を具体的に定義し、それを達成するための KPI を設定します。技術導入ありきではなく、ビジネスゴールから逆算して計画を立てます。
スケーラブルなデータ構造を設計する: 初期段階で、将来の事業拡大や製品ラインの追加を見越した、拡張性の高いデータカテゴリ構造とレコードタイプを設計します。後からの大幅な変更は多大なコストを要します。
コンテンツの品質を最優先する: 優れたプラットフォームも、中身のコンテンツが貧弱では意味がありません。明確で、簡潔で、常に見つけやすい高品質なコンテンツを作成・維持するためのガバナンス体制を構築します。
ユーザー体験を最適化する: 顧客向けの Experience Cloud サイトでは、検索のしやすさや記事の見やすさを追求します。エージェント向けのコンソールでは、ケース情報からワンクリックで関連性の高い記事にたどり着けるよう、コンポーネントの配置や設定を最適化します。
分析と継続的な改善: Salesforce のレポート・ダッシュボード機能を活用し、どの記事がよく見られているか、どの記事がケース解決に貢献しているか、どの検索キーワードで記事が見つかっていないかなどを分析します。そのデータに基づき、コンテンツの追加や改善を継続的に行い、ナレッジベースを「生きた」資産として育てていくことが成功の鍵です。

Salesforce Knowledge は、一度構築して終わりではありません。ビジネスの変化に合わせて進化し続ける、知識管理のエコシステムなのです。このエコシステムを戦略的に育てることで、企業は持続的な競争優位性を築くことができるでしょう。

にゃんこのSalesforce日記

このブログを検索