Fin AI Agent と Copilot は、すべてのサポートコンテンツを活用して、お客様やチームメイトに正確で信頼できる回答を即座に提供します。
この記事を使って、Fin AI Agent と Copilot 向けに help center コンテンツを最適化しましょう。コンテンツのギャップを特定し、既存の記事を更新し、14要素のコンテンツ準備フレームワークを適用する方法を学べます。これにより、Finが正確な回答を取得し、お客様が必要な情報を見つけやすくなります。この記事は knowledge base を管理するワークスペース管理者向けです。
ギャップを埋める新しいコンテンツを作成する
トレンドを見つける - お客様の会話のパターンを見て、記事で対応できそうな内容を探しましょう。お客様がいつも尋ねる質問は何ですか?チームメイトは特定の問題を解決するためのリソースを持っていますか?Finを導入した後は、Topics Explorerからこれを行えます。
パフォーマンスを分析する - Finを導入した後、FinのOptimizeダッシュボードを訪れて、Finがサポートするためにより多くのコンテンツが必要なトピックに関するリアルタイムで実用的な洞察と、これらのギャップを埋めるために自動でコンテンツを作成・更新するAI生成の提案を得ましょう。
既存コンテンツの最適化と更新
記事がシンプルでわかりやすく包括的であればあるほど、AI(および人間!)がそれを理解しやすくなります。人間が読んで混乱する内容は、AIエージェントやcopilotにとっても混乱のもとです。以下に注力しましょう:
言葉を簡潔にする:ユーザーが質問をどのように表現するかを考え、回答が関連性があり理解しやすい表現になっているか確認しましょう。単純な「はい」や「いいえ」の回答は避け、AIが誤解しないように完全な文章で答えを明確にしましょう。
読みやすい構造を作る: コンテンツを整理された形に構成することは、人間だけでなくAIにも役立ちます。見出し、表、箇条書きなどのリッチフォーマットを使い、AIがスキャンしやすく、お客様やチームメイトが求める回答を見つけやすくしましょう。
対象ユーザーを明確にする:ユーザータイプが多様でサポートコンテンツが異なる場合は、各コンテンツに対象ユーザーの明確な記載を入れましょう。ヒント:特定の顧客セグメントをターゲットにするにはaudience rulesを使いましょう。
正確性の監査:営業、エンジニアリング、法務、セキュリティなど、知識は複数のチームや専門家(SME)によって作成されます。コンテンツを所有者ごとに分け、各チームやSMEに自分の知識領域をレビューしてもらいましょう。
重要用語の説明:特別な用語の意味や略語は、初めて使う際に説明しましょう。たとえ読者が既に知っていると思っても説明を加えることが重要です。
プロのヒント:既存コンテンツをFin向けにAIで再構成・最適化する方法を確認しましょう。
最も重要な更新を優先する
Fin向けに最初に最適化すべきコンテンツを優先するためのヒントを紹介します。
「最終更新日」でコンテンツを並べ替え、古くなっている可能性が高いコンテンツを見つけましょう。
Help Center内で閲覧数や記事から開始された会話数などの指標に基づき、トラフィックの多い記事を特定し、それらをできるだけわかりやすく有益にしましょう。
Finを導入した後は、Optimizeダッシュボードを使って、会話数が多くCXスコア(顧客体験スコア)が低いトピックを見つけ、提案を確認してFinのパフォーマンスを向上させましょう。
すべてのサポートコンテンツの誤りが同じ重要度ではありません。製品や内部workflowsの軽微な見た目の変更を反映する更新は、製品やサービスの機能的または使いやすさの大きな変更を反映する更新よりも緊急度は低いです。
ベストプラクティスの例
以下のベストプラクティスは公開記事を例にしていますが、AI対応のすべてのコンテンツ(内部記事、スニペット、同期または外部ソースを含む)に適用されます。これは、FinとCopilotが実際の顧客の質問に答えるためにコンテンツが準備できているかを判断する14要素のコンテンツ準備フレームワークに基づいています。
あいまいさを避ける(曖昧さの解消)
人間が読んで混乱したり曖昧な内容は、AIにとっても曖昧です!(そうなると誤った回答をしたり、不正確な推論をしたり、本来答えられるはずの質問に答えられなくなる可能性があります)。
以下の表は、主語を言い換えることでお客様とFinの両方にとって曖昧さが解消される例を示しています。
良い例 | チームメイトを招待してチームに参加してもらうと、プロジェクトの共同作業がしやすくなります。 |
悪い例 | チームメイトを招待すると簡単です。 |
ヒント:利用可能な情報が曖昧な場合、Finは最も役立つ回答を提供するために推論を行うことがありますが、それが時に不正確な回答につながることがあります。コンテンツをできるだけ明確かつ直接的にしたにもかかわらず矛盾が生じる場合は、意図した動作を明確に定義するガイダンスルール(例:Otherカテゴリ)を追加することを検討してください。
質問を言い換える(質問と回答の対称性)
質問と回答のペアを作る必要はありませんが、ラジオインタビューのように、文脈から切り離されて引用されても意味が通じるように書きましょう。
以下の表は、質問を回答内で言い換えることで、文脈から切り離されても回答が自己完結する例を示しています。
良い例 | 返品や交換のために商品を返送する際は、自分の梱包材を使ってもよく、元の配送箱を保存する必要はありません。 |
悪い例 | 返品商品を返送する際に元の外箱を使う必要がありますか? いいえ。 |
見出しを使う(意味的チャンク境界)
見出し(H1、H2、H3)を使ってコンテンツを焦点を絞った単一トピックのセクションに分けましょう。各セクションは一つの内容を扱うべきで、複数の話題が混ざっている場合は分割してください。これはFinが取得してお客様に提示する内容を直接制御します。三つの異なる内容を含むセクションは焦点の定まらない回答を生みます。また、FinやCopilotがHTML内のすべての見出しを取得できない場合に備え、見出しの一部をその下の段落にも含めましょう。
以下の表は、各見出しごとに文脈を含めて分けることで、Finが自己完結したセクションを取得できる例を示しています。
良い例 | ゲストとしてチェックアウトするゲストとしてチェックアウトするには、「Checkout as guest」をクリックしてメールアドレスを入力してください。注文確認と発送状況の更新に必要です。
ログインユーザーとしてチェックアウトするログインユーザーとしてチェックアウトするには、チェックアウト時に「Sign in」をクリックしてサインインまたは新規アカウント作成をしてください。これによりポイントを獲得し、すべての注文を一元管理できます。 |
悪い例 | チェックアウトはゲストまたはログインユーザーとして行えます。 「Checkout as guest」をクリックしてメールアドレスを入力してください。注文確認と発送状況の更新に必要です。また、チェックアウト時に「Sign in」をクリックしてサインインまたは新規アカウント作成もできます。 |
箇条書きリストを使用する(構造化された列挙)
複数ステップのプロセスには番号付きリストを使用してください。選択肢や項目のリストには箇条書きを使用します。「以下の通り:」という文がある場合は、段落ではなく実際のリストを続ける必要があります。AIは長く詳細な段落よりも、明確な構造でフォーマットされた文章の方が性能が良くなります。
以下の表は、密集した段落を構造化されたリストに変換することでFinが特定のポイントを抽出しやすくなることを示しています。
良い例 | Projectsを使って以下を行います:
|
悪い例 | Projectsでは、タスクの作成と管理、タイムラインの把握による進捗管理、チーム全体との効率的な協力など、多くのことができます。 |
Finに計算を頼まないでください
すべての数字、閾値、制限、期間、数量は正確に記載してください。「数分」「いくつかのリクエスト」「すぐに」などは認められません。既知の場合は正確な値を使用してください。計算を含む質問をFinに処理させたい場合は、計算方法が明確に示された具体例を含めてください。
以下の表は、正確な期間を示し細分化することで、顧客やFinが期間を計算する必要がなくなることを示しています。
良い例 | 返品は最大12営業日でアカウントに反映されます。これは、発送が倉庫に到着するまで最大7日かかり、さらに5日間処理にかかるためです。
返品状況がアカウントに更新されず、12営業日以上経過している場合は、人間に問い合わせてください。
返品がアカウントに反映されているが、返金が支払い方法に表示されるのを待っている場合は、さらに最大5営業日かかることがあります。 |
悪い例 | 返品の返金は、発送に7日、返金処理に5日、返金がアカウントに反映されるまでにさらに5日かかります。 |
連絡先情報を含める(対象者の指定)
すべてのコンテンツには対象者と必要なアクセス権限を明記してください。読者が自分の役割やプランを知っているとは限りません。「すべてのプランで利用可能」や「Workspace Owner権限が必要」といった情報は、読者が自分に該当するかどうかを理解した上で手順を進められるようにします。同じ原則は連絡先情報にも適用されます。特定の状況に特有の番号や住所がある場合は、明確に区別してください。
以下の表は、対象者ごとに連絡先をラベル付けすることで、各項目が自己説明的かつ曖昧さがなくなることを示しています。
良い例 | Salesチーム連絡先:018 4366891 Supportチーム連絡先:018 4366892 広告掲載のお問い合わせ:018 4366893 |
悪い例 | お問い合わせ Sales:018 4366891 Support:018 4366892 広告:018 4366893 |
FAQ記事やスニペットを使用する(自己完結型セクション)
AIエージェントは、高頻度で繰り返される質問を解決することで最も価値を発揮します。したがって、完全な記事が不要な小さな情報や他に適切な場所がない情報は、1つのpublic / internal記事にFAQ(よくある質問)リストとして含めるか、スニペットを作成してください。Finはそれらを見つけて顧客に提供できます。
以下の表は、Finが単独で取得して使用できる十分に構造化されたFAQエントリを示しています。
良い例 | 無料トライアルはありますか? はい、新規のお客様は登録後1か月の無料トライアルを利用できます。
ペットのプロフィール写真はアップロードする必要がありますか? いいえ、ペットのプロフィール写真をアップロードする必要はありませんが、ぜひ見せてください! |
悪い例 | この情報をサポートコンテンツから除外すると、簡単な解決策を逃すことになります。 |
FAQ記事を設定する際は、FAQの構造化にヘッダー(H1、H2、H3)を使用することを強く推奨します。
マルチメディアにコンテキストを与える(視覚コンテンツと代替テキスト)
Finはサポートコンテンツから関連する画像やGIF(最大3つ)をAI回答に送信できます。
ただし、サポートコンテンツにマルチメディアを含めている場合は、画像や動画の上または下に、ユーザーが手順を理解できるように段階的なテキスト説明を必ず含めてください。
ボーナス:段階的なテキスト説明を含めることで、視覚障害のあるユーザーにもアクセスしやすくなり、多様な学習スタイルにも対応できます。
以下の表は、画像と段階的なテキストを組み合わせることで、Finが画像を表示しなくてもプロセスの質問に答えられることを示しています。
良い例 |
新しいプロジェクトを作成するには、以下の手順に従ってください:
|
悪い例 |
注意:Finは1つのAI回答に最大3枚の画像を含めます。記事にそれ以上あってもです。画像は必ず文章の指示と組み合わせてください。Finが画像を表示しなくても正確に回答できます。また、FinはHTMLの見出しを必ずしも取得しないため、各セクションは見出しだけに頼らず、冒頭文でトピックを再度述べるべきです。
Finに正しい画像やGIFを表示させる方法
Help Centerのコンテンツから質問に答える際に、Finが正しい画像やGIFを選ぶためのヒントです。
各画像やGIFにキャプションを付ける。例えば「これはIntercomにIDプロバイダーを接続する方法を示しています。」のように正確に説明してください。キャプションがないと、Finは特定の機能やボタンではなく、見た目が似ている手順を一致させることがあります。
それぞれの異なるフローに独自の見出しを付ける。これは、同じ画面で始まり終わる2つの統合設定など、似たフローが複数ある記事で特に重要です。見出しを分けることで、Finが正しいビジュアルを正しい回答に一致させやすくなります。
各画像やGIFは1つのセクションだけで使用する。示すフローに限定し、似たセクションで使い回さないでください。
強力な冒頭段落を書く(Jobs to be done)
すべての記事の冒頭段落は、記事の内容だけでなく、読者が何を達成できるかを述べる必要があります。Finは冒頭文を使って記事の目的を理解します。弱い冒頭は関連する検索結果の表示を悪化させます。
以下の表は、トピック説明型の冒頭とJobs to be done型の冒頭の違いを示しています。
良い例 | この記事を使ってチームメンバーをワークスペースに招待し、権限を管理し、一般的なアクセス問題をトラブルシュートします。 |
悪い例 | この記事はチームメンバーの招待と権限について説明します。 |
すべての手順を完全にする(Instruction completeness)
手順は最終ステップの後も含めて、確認ダイアログや顧客が見るべき内容、見えない場合の対処法まで完全に記載してください。不完全な手順は顧客を困らせ、Finが「うまくいったか?」の質問に答える材料を失います。
以下の表は、確認ステップを含めて手順を完結させることで、操作が成功したかどうかの曖昧さがなくなることを示しています。
良い例 | Removeをクリックします。確認ダイアログが表示されるので、Confirmを選択して操作を完了します。アイテムはすぐにリストから削除されます。 |
悪い例 | Removeをクリックします。 |
制限事項と回避策を文書化する(Limitations and workarounds)
機能に既知の制限やギャップ、例外がある場合は、具体的に文書化してください。どの設定が影響を受けるか、制限内容、顧客が取るべき代替手段を明示します。これがFinが誤解を招く回答を防ぐ最も直接的な要因です。制限が文書化されていなければ、Finはそれを警告できません。
以下の表は、具体的な制限と回避策を文書化することで、Finが誤解を招く不完全な回答を防ぐことを示しています。
良い例 | カスタムレポートタイプでは一括エクスポートは利用できません。カスタムレポートをエクスポートするには、個別に開き、右上のExportボタンを使用してください。CSVとPDF形式がサポートされています。 |
悪い例 | 一部の設定では一括エクスポートがサポートされない場合があります。 |
すべての用語と略語を定義する(Defined terms)
略語や製品固有の用語は初出時に定義してください。読者がCSV、GDPR、2FAの意味を知っているとは限りません。略語が初めて出るときは完全な形で書き、その後は短縮形を使います。
以下の表は、略語を初出時に定義することで、すべての読者に内容が理解しやすくなることを示しています。
良い例 | レポートページからCSV(カンマ区切り値)ファイルとしてデータをエクスポートできます。CSVをダウンロードしたら、任意の表計算ソフトで開いてください。 |
悪い例 | レポートページからCSVとしてデータをエクスポートしてください。 |
重要な用語を繰り返す(Entity distribution)
重要な製品名や機能名は記事全体で繰り返し使うべきです。Finが記事の途中のセクションを取得する際に、何について話しているか理解するためです。「右上のボタンをクリック」とだけ書かれたセクションは、製品や機能名がないと検索で見つけられません。
以下の表は、各セクションで機能名を繰り返すことで、Finが正確にそのセクションを取得し利用できることを示しています。
良い例 | Intercomワークスペースからチームメンバーを削除するには、設定>チームメンバーに移動します。削除したいメンバーを見つけ、オプションメニューをクリックして「Remove from workspace」を選択します。メンバーは即座にIntercomワークスペースへのアクセス権を失います。 |
悪い例 | 設定>チームメンバーに移動します。削除したい人を見つけ、オプションメニューをクリックして「Remove」を選択します。すぐにアクセス権を失います。 |
すべての表や独立したブロックに導入文を入れる(Context in tables)
表や独立したブロックには、それが何をカバーし、どこで適用されるかを説明する導入文が必要です。Finは見出しなしで表を取得することがあるため、表自体が単独で意味を成す必要があります。導入文なしでいきなり行に入る表は、Finが内容を理解できません。
以下の表は、単一の導入文を加えることで、顧客とFinの両方にとって表が自明になることを示しています。
良い例 | 以下の表は、各Intercomプランでインポートがサポートされているファイル形式を示しています。
Starter: CSV Pro: CSV, XLS Premium: CSV, XLS, JSON |
悪い例 | Starter: CSV Pro: CSV, XLS Premium: CSV, XLS, JSON |
コンテンツ準備チェックリスト
コンテンツを公開する前に、これら14の要素を確認してください。すべてを満たしたコンテンツは、ユーザーが理解しやすく、Finが正確で完全な回答を提供するために取得・解析しやすくなります。
やるべきこと: 読者が達成する内容を明確に示して始まります。
曖昧さの排除: すべての参照が自己説明的です。
独立したセクション: 各セクションは単独で取得しても意味が通じます。
意味的チャンクの境界: 長いセクションは意味のある小見出しで区切られています。
質問と回答の対称性: 見出しはユーザーが質問する表現を反映しています。
構造化された列挙: 複数ステップのプロセスは番号付きリストを使用し、項目リストは箇条書きを使用します。
指示の完全性: 指示のすべてのセットを完了し、最後に何が起こるかも含みます。
数値の明確さ: すべての数字、閾値、制限、期間、数量が正確に記載されています。
定義済み用語: すべての略語と製品固有の用語を初回使用時に定義します。
対象読者の指定: コンテンツの対象者と必要なアクセス権を明示します。
制限事項と回避策: 既知の制限を明確に文書化し、回避策も示します。
エンティティの分布: 主要な製品名や機能名が本文全体に登場します(序文だけでなく)。
表の文脈: 表や独立したブロックには導入文が含まれています。
視覚コンテンツと代替テキスト: すべての画像には、スクリーンショットや図が何を示しているかを説明する代替テキストがあります。


