Lightning KnowledgeはService Cloud向けのSalesforceの記事ライブラリです。担当者が記事を書き、Record TypeがFAQとポリシーを分け、Data Categoryが誰が何を見つけられるかを決め、承認の後でも担当者が改めてPublishをクリックする必要があります。有効化は一方通行で元に戻せず、書く人全員にKnowledge Userライセンスが必要で、最初に当たる上限は記事数ではなくArticle Versionです。最初の記事を書く前にCategoryを設計してください。ライブラリができれば、eesel for SalesforceのようなAIエージェントがケースへの返信を作成する際にそれらの記事を読めます。
Lightning Knowledgeとは何か
私はeeselのサポートキューを担当していて、Salesforce Knowledgeについて一番よく聞かれる質問は「担当者がケースの途中にいるとき、その回答はそもそもどこから来るのか」というものです。Lightning Knowledgeはその場所です。eesel CLIを使えば、AIコーディングエージェントが、エクスポートしたKnowledge記事やポリシーなど承認済みの記事テキストをアップロードし、テスト質問を投げて公開前に回答を確認できますが、接続自体はSalesforce管理者が承認します。
SalesforceのKnowledge概要によると、ナレッジベースは記事から構築され、記事とは製品のリセット方法や対応ストレージ容量のような情報文書です。経験豊富な担当者や社内ライターがそれらを書き、記事は社内にも社外にも公開でき、顧客サイトやパートナーサイト、一般公開サイト、SNS投稿やメールにも展開できます。同じページによれば、Knowledgeを初めて使うorgはLightning Knowledgeを使います。
Google Docsのフォルダとの違いは2つあります。記事は本物のSalesforceレコードなので、レポートを作成したり、ケースに添付したり、他のオブジェクトと同じ権限で制御したりできます。そして記事はDraft、Published、アーカイブ済みバージョンというライフサイクルをたどり、管理作業の大半はそこに発生します。製品の他の部分を把握したいなら、私のService Cloud概要とチケットシステムのガイドがこの記事の隣に並びます。
Lightning KnowledgeはClassic Knowledgeと何が違うのか
Lightning Knowledgeはカスタムのarticle typeを標準のRecord Typeに置き換え、誰が何をできるかも変えます。Salesforceの上限ページによれば、有効化するとデータモデルがArticle TypeではなくRecord Typeを使う形に変わり、その後は無効化できません。Classicの権限はパブリックグループとArticle Actionから来ていました。Lightningではユーザープロファイル権限またはPermission Setがそれに代わります。
同じページには見逃せない期限付きの指示もあります。orgは2025年6月1日より前に移行ツールを実行しないとKnowledgeへのアクセスを維持できない、というものです。Classic orgでこれを読んでいるなら、Salesforce管理者に状況を確認してください。Salesforceの移行ページでは、Supportに依頼を提出し、1〜2週間の猶予を見て、まずサンドボックスでテストするよう案内されています。
上限ページには引き継がれなかった機能も挙げられており、いくつかは意外に思われます。
- 星評価はなくなりました。残るのはThumbs UpとThumbs Downだけで、古い3〜5つ星の評価はThumbs Upに変換されます。
- Lightning Knowledgeは連合検索に対応しておらず、Public Knowledge Baseパッケージも使えません。
- アーカイブを将来の日付で予約することはできません。Salesforceは日付フィールドを基準に記事をアーカイブするFlowを使うよう提案しています。
- Printable Viewアクションは利用できません。
- 有効化後、Article TypeフィールドはSOQLやAPIから参照できなくなり、それを問い合わせるカスタムコードが壊れます。
Lightning Knowledgeはどう設定するのか
5つの手順で進み、最初の手順には後戻りがありません。Salesforceの有効化ページと設定概要に手順が示されています。
- サンドボックスかトライアルorgでテストする。 有効化は恒久的なので、Salesforceは本番の前にこれを行うよう勧めています。上限ページによれば、まずarticle typeを含むインストール済みパッケージを削除してください。
- 有効化する。 SetupのQuick FindでKnowledgeと入力し、Knowledge Settingsをクリックし、続けてEditをクリックして、Enable Lightning Knowledgeを選んで保存します。有効化にはArticle Typeが1つ、ページを見るにはKnowledge Userライセンスが必要です。
- アクセス権を付与する。 Salesforceのユーザーアクセスページによれば、Read権限を持つすべての社内ユーザーはデフォルトで公開済み記事を読めます。読む以上のことをするには、担当者のユーザーレコードでKnowledge Userライセンスにチェックが必要です。
- Record TypeとPage Layoutを作成する。 コンテンツの種類ごとにRecord Typeを1つずつ、それぞれ専用のレイアウトとともに用意します。
- Categoryを設計してから公開する。 Data Category Groupを設定し、各タイプをどのChannelに出すか決め、最初の記事を書きます。
サポート管理者の午後をまるごと節約する権限の細部があります。Draft記事でCategoryを見るには、標準ユーザーにKnowledge UserとManage Articleの両方が必要で、アーカイブ済み記事の削除にはModify All Recordsが必要です。私のマクロガイドにも別機能で同じ教訓があります。担当者としてテストし、管理者としてテストしないことです。
Salesforceには、Lightning Knowledgeを有効化し、記事の作成者を選び、Data Category Groupを作成するガイド付き設定フローもあり、その設定フローページによれば、デフォルトのFAQ Record Typeとレイアウトを自動で有効化します。
Record Type、Page Layout、Data Categoryはどう機能するのか
Record Typeは記事に何を入れるかを決め、Data Categoryはそれをどこで見つけられるかを決めます。SalesforceのRecord Typeページははっきり言っています。FAQページはチュートリアルと異なり、チュートリアルはポリシー文書とも異なり、Record Typeが記事のコンテンツとレイアウトを制御すると。Page Layoutは、Record Typeとプロファイルに応じて担当者がどのフィールドを見て編集できるかを決めます。
Data Categoryはフィルター層です。Salesforceのベストプラクティス記事には上限が挙げられています。
| Data Categoryの上限 | 値 |
|---|---|
| Category Group数 | 最大3 |
| グループあたりの階層レベル | 最大5 |
| グループあたりのCategory数 | 最大100 |
| 1記事・1グループあたりのCategory数 | 最大8 |
| 可視性設定 | Role、Permission Set、またはProfileをAll、None、Customのいずれかに設定 |
そのページの例は覚えておく価値があります。Categoryのない記事は製品フィルターが設定されていると表示されず、All Productsを付けた記事はフィルターの有無にかかわらず表示されます。Salesforceの作成ページはさらに、ユーザーは適用されたCategoryか、その親Category、あるいは子Categoryのいずれかを通じてしか記事を見つけられないと付け加えています。だから人が自然に探しそうなCategoryを選んでください。また、Data CategoryはKnowledgeのリストビューには表示されないため、代わりにCategoryで絞り込むレポートを作るよう注意喚起しています。
キュー側からの私の助言は、最初のCategory Groupを「どの製品についてか」のような1つの問いに絞ることです。初日に3つのグループを作ると、記事が結局どれにも属さなくなります。Salesforceの計画ページも作業順序について同意しており、設定する前にCategory階層とロール階層へのマッピングを計画するよう管理者に伝えています。
Channelは誰が記事を見られるかをどう決めるのか
Channelは記事ごとの可視性スイッチです。SalesforceはLightning Knowledgeで4つのフィールドを定義しています。Visible in Internal App、Visible to Customer、Visible to Partner、Visible in Public Knowledge Baseで、Channelの記事によれば、これらはデフォルトで非表示になっており、作成者が編集できるようにするにはPage Layoutに追加する必要があります。公開すると、選択したすべてのChannelで記事が表示されるようになり、翻訳付きの記事を公開すると、公開ページによればその翻訳も一緒に公開されます。
外部読者向けには、Salesforceの上限ページによるとExperience CloudやSalesforce SitesでLightning Knowledgeの記事を共有でき、未認証ユーザーとの共有にはHelp Centerを使えます。TitleとURL Nameは必須フィールドなのでレイアウトから外せず、これはExperience Cloudのサイトにも当てはまります。
他のヘルプセンターと比較しているなら、私のGorgiasナレッジベース、HubSpotナレッジベース、Freshserviceナレッジベースの記事では、同じ仕事をより少ない可動部分で実現している様子を紹介しています。
承認と公開はどう機能するのか
承認はコンテンツの門番ですが、公開することは決してありません。Salesforceの承認ページによれば、Approval Processの最後で記事が自動的に公開されることはなく、担当者が改めてPublishをクリックする必要があります。また、それが可能になるよう、最終承認アクションを「Unlock the record for editing」に設定するよう案内しています。
このページと公開ページにある他のルールです。
- 承認者は手動で選ぶか、階層フィールドから割り当てるか、Queueに送るか、特定のユーザーに固定でき、1ステップあたり最大
25人です。 - Approval ProcessはDraftから公開までの段階だけをカバーします。Salesforceによれば、翻訳やアーカイブには使えません。
- Publish Articlesアクションを持つ担当者はPublishとSubmit for Approvalの両方を見られるため、承認に意味を持たせたいならそのアクションを少人数に限定してください。
- Approval Process中の記事はロック解除できず、承認前に公開予定として設定された記事は、承認状況にかかわらずそのまま公開されます。
- 予約公開は15分間隔で実行されるため、正確な分までは保証されません。
Salesforce自身のページ同士が食い違う箇所が1つあります。公開ページでは予約公開を取り消すにはCancel Publicationをクリックするとしていますが、同じページでLightning ExperienceのDraftからはそのボタンが使えないとも書かれており、上限ページでは予約公開はそもそもまったく取り消せないとされています。作成者に予約記事を取り下げられると約束する前に、サンドボックスで試してください。
Workflow Ruleは別物です。記事が条件を満たしたときにメール通知を送ったり、フィールドを更新したり、Outbound Messageを送ったりできますが、Salesforceは記事のWorkflowではTaskに対応していないと注記しています。あなたの問題が遅さではなく古さにあるなら、私のAIナレッジベース監査と古くなったヘルプコンテンツの検出のガイドが、私なら行うチェックです。
記事バージョンはどう機能するのか
各記事はDraft1つ、Published1つ、そして複数のアーカイブ済みバージョンを持てます。Salesforceのバージョンページによると、前のバージョンを残すには公開時にFlag as new versionにチェックを入れ、新しいバージョンには次の連番が割り当てられます。
ケースとの紐づけが賢い部分です。記事がケースに添付された状態で新しいバージョンが公開されると、添付されていたバージョンは古いものとしてマークされ、Version 2は「Version 2 (outdated)」になり、ケースには担当者が実際に読んだ内容が恒久的に記録されます。デフォルトでは、システムは記事ごとに最大10バージョンを保存し、それに加えてケースに添付されたバージョンも保存されますが、そのケース紐づけバージョンは記事あたりの上限にはカウントされません。
Lightningには2つの癖があります。削除できるのはアーカイブ済みとDraftのバージョンだけで、30を超えるバージョンを持つ記事では、上限ページによれば30を超えた分はClassicには表示されますがLightningには表示されません。また複数の担当者が同じ記事を同時に編集でき、警告なしにお互いの変更を上書きし合えるため、Salesforceは作成者に自分に割り当てられた記事だけを編集するよう伝えることを勧めています。
Lightning Knowledgeの費用と、誰にライセンスが必要か
SalesforceはService料金ページでKnowledge単体の価格を掲載していません。エディション比較の中に「Knowledge Management」というFeature行として登場しますが、ページ本文からはどのエディションの列にそれが含まれるのかを確認できなかったので、担当者に聞いてください。そのページに載っているユーザーあたりの定価は次のとおりです。
| エディション | ユーザーあたり月額の定価 |
|---|---|
| Starter Suite | 25ドル |
| Pro Suite | 100ドル |
| Core | 195ドル |
| Advanced | 395ドル |
| Max | 550ドル |
記事に直接関係するAIアドオンが2つあります。ページにはKnowledge CreationとEnterprise KnowledgeがCoreとAdvancedの下で「Available for purchase」と表示されています。ライターにとって重要なのはKnowledge Userライセンスで、Salesforceによれば記事を読む以上のことをするのに必要です。Salesforceの現在のService Cloud料金は私の料金ガイドで整理しており、AI利用量はFlex Creditsとして別建てで計測されます。
管理者が計画しておくべき上限は何か
人を驚かせる上限は記事数ではなくバージョン数です。Salesforceのスケーラビリティページによれば、バージョンの総数は記事数×記事あたりの保持バージョン数×バージョンあたりの翻訳数で決まり、記事100,000件、バージョン5つ、翻訳5つという例では2,500,000バージョンになるとしています。
同じページにある、エディションごとのデフォルト割り当てです。
| エディション | 記事数 | 記事あたりのバージョン数 | 言語数 |
|---|---|---|---|
| Essentials | 500 | 10 | 1 |
| Professional | 500 | 10 | 1 |
| Enterprise | 50,000 | 10 | 5 |
| Developer | 50,000 | 10 | 5 |
| Unlimited | 150,000 | 10 | 10 |
正直に言うと注意点があります。この表は古いエディション名を使っていますが、料金ページでは今はCore、Advanced、Maxが表示されており、どちらのページも両者を対応づけていません。Salesforce Supportに上限の引き上げを依頼することもでき、Spring '18より前に作成されたorgはデフォルトで16言語になっています。Classic Knowledgeはarticle typeを25まで許可していましたが、Lightning Knowledgeは1オブジェクトあたり最大200のRecord Typeを許可します。
同じページにあるサポートチームに影響する他の上限です。リッチテキストフィールド1つに他の記事へのリンクを最大100件まで入れられます。KnowledgeのフッターはLightning Service Consoleには存在しません（代わりにレコードページにKnowledgeコンポーネントを追加します）。そしてケースをクローズする際に記事を作成するオプションはClassicにしか存在しません。そしてFAQで約束したとおり、Knowledge記事でマクロは使えず、記事をマクロに挿入することもできないため、私のマクロガイドとこの記事は別々の2つのライブラリを説明しています。
AIエージェントはLightning Knowledgeをどう使うのか
記事は、SalesforceがService向けに販売するAI機能に供給され、サードパーティのエージェントもそれを読みます。重要なSalesforceの詳細が3つあります。
執筆。 SalesforceのEinstein Knowledge Creationは、担当者がケース、インシデント、ワークオーダーからプロンプトテンプレートを使って記事を下書きし、レビュー、編集、保存できるようにします。Salesforceは生成した記事の分だけ課金すると述べています。
Grounding。 Ground with Knowledgeでは、TitleとSummaryフィールドが必須です。Salesforceによれば、インデックス作成には数時間かかることがあり、新しい記事は24時間に1回インデックスされ、ユーザーはアクセス権のあるフィールドとバージョンから得られたgrounding済みの回答しか見られません。対応するのはStringとText Areaフィールドのみで、暗号化フィールドは対応していません。
外部ソース。 SalesforceのUnified Knowledgeページによれば、Summer '27リリースで廃止予定とされており、Data 360を基盤とするEnterprise Knowledgeが後継になります。
私の見方では、AIエージェントに求められる品質基準は担当者と同じですが、より容赦がありません。TitleとSummaryがgroundingに必須のフィールドなので、「Returns info」のような曖昧なSummaryは、どんなモデルのアップグレードよりもコストがかかります。私のサポートにおけるAIハルシネーションとナレッジベースのトレーニングのガイドでさらに掘り下げています。
smavaは、SalesforceではなくZendeskでこの反対側を示しています。2026年8月8日から9月8日の間に、eeselはsmavaと姉妹ブランドのために約27,000件のチケットを処理し、マクロとヘルプセンターを横断する検索を約14,400回実行し、人が承認するための返信案を約15,300件用意しました。SaunaSpaceはGorgias上で同じことを行い、ヘルプセンターと過去のチケットから、落ち着いた直接的な声で下書きし、常に人が送信します。どちらの場合も、エージェントはすでに人が書いたヘルプコンテンツをもとに動いています。だから私なら、どんなAIを買う前にもまず記事を整えます。
Salesforce自体では、eeselの連携がCase上のエージェントとして動作します。連絡先とアカウントのコンテキストとともにケースを読み、返信を下書きまたは送信し、内部メモを追加し、フィールドを更新し、Queueへルーティングし、そのページによれば過去のケースとナレッジ記事から学習します。料金はeesel料金ページにあり、チケットやチャット1件が1クレジットになる固定クレジットプランで、500クレジットが月299ドルから、7日間は100クレジットが無料です。SalesforceにAIを任せたいなら、Agentforceエージェント、Agentforceの代替のまとめ、Service Cloudに最適なAIをご覧ください。
最初の記事を書く前に私なら何をするか
サポート管理者に渡すとしたら、このチェックリストです。
- まずサンドボックスで実行する。 有効化は恒久的で、Salesforceは複数のページでこの警告を繰り返しています。
- Record Typeは最大3つに絞る。 FAQ、How-to、Policyです。レイアウトが本当に異なる場合だけ追加してください。
- Category Groupは1つから始め、ロール階層と照らし合わせて計画します。
- Channelのフィールドは初日からレイアウトに追加する。そうしないと作成者が設定できません。
- 誰が公開できるかを決める。 承認が重要なら、Publish Articlesアクションを制限し、最終承認ステップでレコードのロックを解除するよう設定します。
- Summaryフィールドは担当者ではなくエージェント向けに書く。 TitleとSummaryがgroundingに必須の2フィールドです。
- バージョンとケースの紐づけを毎月見直し、誰も読まないものはアーカイブします。私のAIナレッジマネジメントガイドにレビューのリズムがあります。
記事がボットに供給されるなら、私のAIで記事を書く、AIを会社のナレッジに接続する、ヘルプセンター検索の記事はこれとよく合います。隣接するService Cloudのガイドとして、ケースマージ、Omni-Channelルーティング、Enhanced Messaging、ケースサマリーがあります。多言語ライブラリについては多言語サポートとSalesforce翻訳を、外部からの視点としては最良のナレッジマネジメントソフトウェアをご覧ください。
Salesforce Service Cloud向けにeeselを試す
担当者がすでに記事を持っているのに、それでも回答を打ち直しているなら、eeselはあなたのService Cloud orgに入り込む新しいメンバーのように働きます。アカウントの履歴とナレッジ記事とともに新しいケースをすべて読み、担当者が承認できる内部コメントとして返信案を残します。管理者が見られる範囲を制御でき、実際のケースに触れる前に過去のケースでシミュレーションできます。100クレジットで無料で試せます。
