ナレッジベースは、中身の記事があってこそ役に立ちます。Trupeerなら、すぐに使えるナレッジベース記事テンプレートから始めて、ブランドガイドラインでカスタマイズし、文章中心の記事を、顧客や従業員が実際に取り組めるわかりやすい動画ウォークスルーに変えることで、ナレッジベース記事の作成にかかる時間を何時間も節約できます。

ナレッジベース記事とは何か、テンプレートで何が解決できるのか？

ナレッジベース記事とは、検索ボックスから問題をすでに思い描いて辿り着いた人に向けた、単一で完結した回答です。システムを説明するドキュメントではありませんし、順番に読んでいくマニュアルでもありません。

テンプレートが解決するのは3つです。毎回ライターが構成をゼロから作り直してしまうのを止めます。そこに時間が吸い取られていくからです。読者が「どこを見ればいいか」を学べるほど記事の内容を一貫させます。そして、放っておくとライターが飛ばしてしまう項目を強制的に埋めます。そうした項目は、ほぼ例外なく手順そのものです。

ただし、解決できないのは、誰も検索できないライブラリ、間違ったトピックの記事、そして何も更新しないチームです。

ナレッジベース記事が失敗するのは「真ん中」ではなく「端」

良くないナレッジベース記事を読んでみると、たいてい文章自体は問題ありません。手順は正しい、スクリーンショットは最新です。誰かがそのテーマを理解して書いたことは明らかです。

問題は境界です。記事は状況の1つのバージョンを説明しているのに、読者の状況は少し違う。そして、それを知らせるものが何もありません。読者はそのまま読み進め、黙ってうまくいかず、結局チケットを切ります。しかも、何も見つからなかったときよりも、より苛立った状態で。

データ上では、ヘルプセンターで最も奇妙なパターンとして現れます。同じトピックで、閲覧数が多く、チケット発行数も多い記事です。記事は見つかる。読まれる。なのに何も解決しない。

解決策は、より良い文章を書くことではありません。ほとんどのテンプレートに用意されていない「2行」を追加することです。まず、この記事がカバーする範囲を明確にし、もし読者の状況がそれに当てはまらない場合はどこへ行けばいいかを示します。

Trupeerでこのテンプレートをカスタマイズする方法

ステップ1：テンプレートセクションを開く

メインナビゲーションからテンプレートセクションへ移動します。

ステップ2：テンプレートを選択して開く

作業したいテンプレートをクリックして開きます。

ステップ3：テンプレート表示を展開する

必要に応じて、テンプレート表示を展開し、レイアウトと詳細をはっきり確認します。

ステップ4：テンプレートを編集する

編集をクリックして、選択したテンプレートの変更を開始します。

エディター内で、次のことができます：

• 新しいセクションを追加

• 書式ルールを定義または更新

• ロゴを追加し、位置や関連設定を調整

ステップ5：カスタマイズしたテンプレートを保存する

必要な変更をすべて行ったら、保存をクリックして更新済みテンプレートを自分のものとして保存します。

ステップ6：プレビューしてテンプレートを微調整する

カスタマイズしたテンプレートがどのように表示されるか確認したい場合は、プレビューを開きます。

プレビュー画面から、必要に応じてそのまま調整を続けることができ、テンプレートが思い通りに表示されることを確認できます。

ナレッジベース記事テンプレートでできること：

• 作成時間を節約： ハウツーガイド、FAQ、トラブルシューティング記事の作り方に、実績のある構成を活用できます。

• サポートチケットを削減： わかりやすい記事により、ユーザーがセルフサービスで解決できるため、サポート負荷が下がり、より難しい課題に対応する担当者の時間を確保できます。

• ブランドを維持： Trupeerのブランドキットでロゴ、フォント、カラーを適用すれば、すべての記事が自社製品の一部であることが伝わります。

• 見つけやすさを向上： 標準化された構成により、記事のスキャン、検索、更新が簡単になります。

• グローバルにローカライズ： 1クリックでナレッジベース記事を65+言語に翻訳できます。

• 動画ウォークスルーを追加： 文章だけでは説明が難しい手順を、埋め込み動画と組み合わせて提供できます。

すべてのナレッジベース記事テンプレートに必要な「2行」

スコープ行。 この記事が適用される状況を、読者の言葉で1文にまとめます。あなたの言葉ではありません。「標準プランのアカウントに適用されます」ではなく、「メールアドレスとパスワードでサインインする場合」です。読者が、自分の状況と照らし合わせて確認できる必要があります。

出口行。 最もよくある隣接する状況を1文で示し、それにリンクします。「会社でシングルサインオンを使っている場合は、こちらへ」

どちらも手順の上に置きます。下部の注記には入れません。指示に従い始めた読者は注意書きで止まりませんし、間違った記事にいる読者は約8秒以内に離脱すべきです。

重要なのは「2行」そのものよりも規律です。出口行を書くことで、隣接するケースを名前で挙げることになります。そして名前を挙げると、2つか3つのケースはそもそも記事が存在しないことが多くの場合わかります。

ナレッジベース記事の種類と、それぞれの使いどころ

最もよくある構造上のミスは、トラブルシューティングの問題をハウツーとして書いてしまうことです。読者がまだ「何が間違っているのか」を把握していない場合、番号付き手順は不適切です。手順1が、まだ行っていない診断を前提にしてしまうからです。症状から始めて分岐させましょう。私たちのハウツー記事テンプレートでは、最初の行をより深く扱っています。

無料のナレッジベース記事テンプレート：コピーするための構造

ここからコピーしてください。必須としてマークされた項目は、タイプに関係なくすべての記事に残ります。

タイトル（必須）。 読者の言葉での質問です。読者の言葉で書きます。「サインインできません」なら「認証のトラブルシューティング」よりも適切です。問題ではなくラベルとして書かれたタイトルは、良い記事が見つからない最も一般的な理由です。

検索用語（必須）。 実際に人が使う言い回しを3〜6個。架空のものではなく、ゼロ結果の検索ログから取ります。ほとんどのプラットフォームにはこの項目があり、多くのチームは空欄のままにしています。

スコープ行（必須）。 上記と同じです。

出口行（必須）。 上記と同じです。

回答または最初の手順（必須）。 短い質問なら、2行以内に回答を全文で収めます。手順なら、手順1です。出口行とこの項目の間には何も入れません。特に「この記事は何についてです」と説明する導入文は不要です。

本文。 タイプに応じて、手順、分岐、または表。

これでうまくいかなかった場合にやること。 指名された次のステップ：別の特定の記事、フォーム、またはキューです。「サポートに連絡」ではありません。

担当者と最終確認日。 人と、誰かが最後に「記事が現実に合っていること」を確認した日です。「文言を編集した日」ではありません。

ここまでコピーしてください。特定の記事でその項目が不要に感じた場合は、テンプレートから削除せず、その記事内で削除してください。ライターが飛ばしてしまう項目こそが、実際に作業をしていた項目だからです。

よくある4つのタイプ別：ナレッジベース記事テンプレートの例

FAQ。 タイトル：「請求日の変更はできますか？」 スコープ：毎月請求されるアカウント。回答（最初の2行）：はい、請求サイクルごとに1回。Billingを開いてからScheduleを選択し、変更は次のサイクルから反映されます。出口：年払いプランはこちらへ。以上が記事のすべてです。

ハウツー。 タイトル：「ワークスペースにユーザーを追加する」。スコープ：あなたは管理者です。出口：Settingsが表示できない場合は管理者ではありません。あなたの管理者に相談してください。手順：4つ。各手順に期待される結果を添えます。次に：招待が届かない場合はどうするか。

トラブルシューティング。 タイトル：「エクスポートは完了するのに、ファイルが空です」。スコープ：Reports画面からのエクスポート。最初の分岐は、読者が助けなしで確認できること（通常は日付範囲）です。2つ目の分岐は権限。3つ目は既知の上限です。各分岐は、解決済みか、指名された次のステップで終わります。

既知のエラー。 タイトル：「EUアカウントのレポートが遅延しています」。ステータス、影響を受ける人、いまの間に何をすべきか、次の更新がいつ投稿されるか、そして最終更新の時間。これらは、読者が実際に探す項目です。

ナレッジベース記事の例：閲覧数が多いのにチケットも多い

約1万1,000の法人顧客を持つ給与計算プロダクトLoxwellには、約1,100本の記事のヘルプセンターと、評価の高いコンテンツチームがありました。

パスワードリセットの記事は四半期あたり約1万4,200回の閲覧がありました。同じ期間のパスワード関連チケットは約900件で、2年間動いていませんでした。どちらの数字も月次で報告されていましたが、別々のデッキで、別々の人に共有されていました。

誰かが最終的にそれらを並べました。記事は標準的なリセットをカバーしていました。メールを入力し、リンクをクリックし、新しいパスワードを選ぶ、という内容です。パスワード関連チケットの約60%は、シングルサインオンが有効になっている企業のユーザーから来ていました。ここではリセットリンクが役に立たないのです。アイデンティティプロバイダーがパスワードを保持しているためです。記事はシングルサインオンについて一度も触れていませんでした。そうした読者は記事を見つけ、従い、エラーメッセージなしで失敗するのを見て、チケットを開きました。

解決には午後一日かかりました。既存の記事の上部に、標準ケースとシングルサインオン利用者は別の場所へ誘導するための2行を追加し、さらにそのユーザー向けの短い新規記事を作成しました。そして、検索ボックスに実際に入力されていたフレーズを、両方の記事に追加しました。

次の四半期、パスワード関連チケットは約310件まで減りました。元の記事の閲覧数も約9,800まで下がりました。この下落は成功であり、後退ではありません。これらの読者のうち4,000人は、間違った記事にいたのです。

同じ午後に、2つ目の数字も判明しました。1,100本の記事のうち、340本は12か月間まったく閲覧されていませんでした。どれも問題があったわけではありません。

良いナレッジベース記事を書く手順：ステップバイステップ

機能からではなく、チケットから始めます。トピックに関する直近10件のチケットを開き、それぞれの「顧客自身の最初の1文」を読みます。その1文があなたのタイトルであり、その言葉が検索用語になります。

スコープ行は、最初に書きます。1つの確認可能な文で「誰向けか」を言えないなら、トピックは広すぎます。記事が2つ必要です。

回答または最初の手順は、出口行の直後に書きます。導入文は避けましょう。検索結果から辿り着いた人に、この記事が何についてかを説明する必要はありません。

本文を書いたら、「なぜこのシステムがこのように機能するのか」を説明する文をすべて削ります。それはドキュメントに入れるべきで、記事では有用な部分が折り返しの下に押し込まれてしまいます。

最後は、指名された次のステップと担当者で締めて、それを「その問題を抱えている人」に渡します。手助けせずに使ってもらい、その様子を見てください。

すべてのナレッジベース記事テンプレートに含めるべきものは？

6つの項目です。順番は、読者の課題として書かれたタイトル、代替の検索用語、スコープ行、出口行、回答または最初の手順、そして失敗時のための指名された次のステップです。担当者と最終確認日はメタデータに置きます。

それ以外はタイプ固有です。手順、分岐、表、ステータスブロック、スクリーンショットは記事タイプによって変わります。そして、すべての記事にそれらを必須として求めるテンプレートは、結果としてパディングされたFAQと薄いトラブルシューティングガイドを同じ割合で生み出します。

既存のナレッジベースにテンプレートを展開する方法

ライブラリ全体を後付けで作り直さないでください。記事を90本あたりで止めて、見た目に明らかに異なる2つの基準を残してしまうチームは、1つの悪い基準があるよりも悪い状態になります。

固定した日付以降に作成される新しい記事にテンプレートを適用します。その後、閲覧数が多い既存記事上位20本に対しては、スコープ行、出口行、検索用語だけを追加し、本文はそのままにします。これら20本は通常、全閲覧の大きな割合を占めるため、回収は四半期ではなく2週間で到着します。

その後は、チケットに任せて進めます。チケットを生む記事は、そのチケットがクローズされたときに、クローズした担当者によって作り直されます。ライブラリは「重要な順番」で自動的に変わっていきます。キャンセルされるドキュメントのスプリントを誰も計画しません。

ナレッジベース記事のパフォーマンスはどう測る？

閲覧数だけでは、上の例が示す通り、ほとんど何もわかりません。各記事を、そのトピックのチケット発行数とセットで見て、一緒に読み解いてください。閲覧数が多くチケットも多い場合は、記事は見つかるが失敗しています。閲覧数が少なくチケットが多い場合は、見つからない（または見つけにくい）という別の問題で、同じ症状です。閲覧数が少なくチケットも少ない場合は、削除が妥当なことが多いです。

もう2つの数字も、取り組む価値があります。ゼロ結果の検索ログ（顧客が探したのに、あなたが持っていないものの一覧）と、直近6か月で検証済みとされた記事の割合です。どちらも通常は午後のうちに確認でき、どちらも多くのレポートには載りません。

書き直しサイクルなしでナレッジベース記事を維持する方法

定期的な見直しサイクルは失敗しがちです。何も変わっていないタイミングでやってきて、変化が起きた瞬間を逃すからです。代わりにトリガーを使いましょう。

記事が存在しているのにチケットが立てられたとき、記事が説明しているインターフェースが変更されたとき、ゼロ結果ログに「一致しているはずの言い回し」として出てきたとき、そして担当者が離任したときに、記事を再確認します。4つすべてに12か月間触れられなかった記事は、見直し候補ではなく削除候補です。

削除はチームが避けがちな作業です。閲覧されない記事340本は黙っているわけではありません。検索結果を薄め、有用な記事に到達しにくくします。増え続けるだけのライブラリは、維持されていません。より広い規律が重要な領域では、私たちのナレッジマネジメントテンプレートが、全体の資産にわたる所有とライフサイクルをカバーしています。

WordまたはExcelでナレッジベース記事テンプレートを入手できますか？

チームが公開前に原稿を作るなら、Wordは記事そのものに向いています。ただし、ヘルプセンターで直接下書きする方が通常は速くなります。表示（レンダリング）と検索フィールドが見えるからです。Excelは記事インデックス（所有者、タイプ、最終確認日、閲覧数、チケット発行数を含むすべての記事の一覧）に向いており、このインデックスが上記の測定を可能にします。

2つのうち、より価値が高いのはインデックスで、ほとんど誰も作りません。6つの列と月次のエクスポートがあれば、どんなテンプレートよりもナレッジベースについて多くを教えてくれます。

ナレッジベースのWebサイトテンプレートとHTML：このページで扱わないこと

この用語で検索する人の中には、ナレッジベースのWebサイトテンプレートやHTMLテーマを探している人もいます。つまり、記事そのものではなく、記事を格納するサイトのことです。このページはそれを提供するものではありませんし、そうだと見せかけることもできません。

2つの判断は無関係なので、違いを明確にしておく価値があります。ヘルプセンタープラットフォームやテーマを選ぶのは、検索、ナビゲーション、モバイル表示、権限といったWebとデザインの判断です。記事構造はライティングの判断です。スコープ行のない記事で満たされた美しいヘルプセンターでもチケットは発生しますし、スコープ行のない記事ではない、良い記事で満たされたシンプルなものでもチケットは減りません。

記事を「どこに置くか」を選んでいるのであって、「記事の中身」を選んでいるわけではない場合は、私たちのナレッジベーステンプレートが構造、カテゴリ、所有をカバーしています。

画面録画をナレッジベース記事にする方法

すべてのヘルプセンターに共通するボトルネックは、「何を書けばいいかがわからない」ことではありません。答えを知っている人がすでに問題を解決して次に進んでしまっていて、書き起こすのに必要な1時間がその人にはない、ということです。

Trupeer AIは、画面録画を、手順とスクリーンショットが揃ったフォーマット済みの記事に変換します。つまり、解決した人が「一度だけ」修正を記録して編集するだけで済み、書き起こす必要がありません。タイトル、スコープ行、出口行は自分で追加してください。これらは判断であり、残りは文字起こしだからです。

記録する。ブランド化する。翻訳する。Trupeerする。

同じ録画から、見ることを好む読者向けの動画、あなたのナレッジベース向けのドキュメント、そして誰もスタイルガイドを維持しなくてもすべての記事で一貫したフォーマットが生成されます。翻訳は、ここでは多くの場面よりも重要です。なぜなら、ある言語のヘルプセンターが、他のすべての顧客をあなたのサポートキューへ静かにルーティングしてしまうからです。ガイドではより広いワークフローを扱い、セットアップ手順はドキュメントテンプレートセットアップガイドにあります。

よくある質問

Wordで無料のナレッジベース記事テンプレートはありますか？

上記の6フィールド構造は、WordまたはGoogle Docsにそのまま貼り付けて、下書き用のシェルとして使えるように書かれています。ゲート付きのダウンロードはありません。つまり、構造の前にフォームもありません。多くのチームは、Word版の使用を1か月以内にやめて、代わりにヘルプセンターで下書きするようになります。これは問題ありませんし、より速いです。

Excelでナレッジベースのテンプレートはありますか？

記事ではなく、記事インデックスにExcelを使ってください。タイトル、タイプ、所有者、最終確認日、今四半期の閲覧数、このトピックに関するチケットの列を用意します。このシートが、ヘルプセンターをページの山から「管理できるもの」へ変えます。セットアップには約1時間かかります。

ナレッジベース記事テンプレートの例はどこで見つけられますか？

上の例のセクションに、FAQ、ハウツー、トラブルシューティング、既知のエラーをカバーする4つの記入済み例があります。より役立つ練習は、自分の「最も閲覧されている記事」上位3本を使って、それぞれにスコープ行と出口行を追加することです。あなたのケースは自社のプロダクトに固有で、どの例もそれを持っていないからです。

Wordで無料のFAQテンプレートはありますか？

FAQ記事は、他のどのタイプよりも少ない構造で済みます。見出しは質問として、顧客が尋ねるのとまったく同じ言い回しで書きます。回答は2行以内に収め、他には何も書きません。回答が2行に収まらないなら、それはFAQではなく、ハウツーまたはトラブルシューティング記事として誤ってラベル付けされているだけです。

Zendesk Guideの記事テンプレートはありますか？

Zendesk Guideは、テーマシステムを通じて記事テンプレートをサポートしており、上記の6フィールドは難なく対応できます。タイトルと検索キーワードはネイティブフィールドで、スコープ行と出口行は本文の先頭に配置されます。ここで示す構造は、意図的にプラットフォーム非依存です。チームは、想定しているよりも頻繁にヘルプセンターを移行するからです。

無料のHTMLナレッジベーステンプレートはありますか？

それは別の成果物です。つまり記事ではなく、サイト側のものです。そして、このページで扱わないことのセクションで説明しています。テーマ付きのヘルプセンターが必要なら、多くのプラットフォームには最初から用意されており、カスタマイズはライティングではなくフロントエンドの作業になります。

無料のナレッジベースWebサイトテンプレートはありますか？

同じ答えです。コンテナを選ぶのは、検索品質、権限、モバイル表示に基づくプラットフォームの判断です。このページの内容では選び方はわかりません。また、記事構造はテーマよりもチケット発行数に影響します。

ナレッジベース記事はどれくらいの長さが必要ですか？

答えがスマホでスクロールせずに見えるくらいの短さにします。FAQなら2行です。ハウツーなら9ステップ未満で、それを超える場合は通常2つの記事になります。長さが目的ではありません。目的は、読者が8秒以内に「ここが正しい場所かどうか」を判断できることです。

誰がナレッジベース記事を書くべきですか？

問題を解決した人で、ライブラリの所有者が編集します。チケットの要約からドキュメンテーションチームが書いた記事は、顧客自身の言葉を失います。顧客の言葉こそが、次の顧客が検索する言葉だからです。適切なタイトルが付いたサポート担当者のラフな記事は、誰にも見つからない完璧な記事よりも勝ちます。