---
Title: "AI回答を支えるナレッジベース構築のプレイブック"
Url: "https://devrev.ai/blog/knowledge-base-that-answers"
Published: "2026-05-20"
Last Updated: "2026-06-04"
Author: "Shreya Talekar"
Category: "Blog, Computer"
Excerpt: "ナレッジベースは単なるドキュメントではない。カスタマーポータル、CXエージェント、AI搭載サポートを支える信頼のソースだ。初日から正しく構築する方法を学ぶ。  "
Reading Time: 5
---

# AI回答を支えるナレッジベース構築のプレイブック

## **TL;DR**

- 誰にも見つけてもらえないヘルプ記事を書いたことがある人、または顧客が無視してチケットを開いた経験がある人のためのガイドだ。ナレッジベースは、すべてのサポートコンテンツが集約される場所であり、カスタマーポータル、CXエージェント、ComputerのAI搭載回答を、同じコンテンツから提供する。
- このガイドでは、DevRevでナレッジベースをセットアップ、構造化、最適化する方法をステップバイステップで、ベストプラクティスを織り交ぜて解説する。
- 正しく構築すれば、60〜80%のディフレクション率が期待できる。間違えると、どこかですでに回答した質問に対して顧客がまだチケットを開き続けることになる。

## **記事を1つ書く前に、これを実行する**

最初から始めよう。ナレッジベースは**Settings › Support › Knowledge Base**にある。これが中央ハブだ。記事の作成、コレクションの管理、可視性の設定、パフォーマンスの追跡を行う場所だ。

コンテンツの作成を始める前に、パーミッションが適切であることを確認する：

- **すべてのチームメンバー**は編集権限で記事を作成・変更できる。
- **パブリッシャーグループメンバー**は記事を公開できる（承認ワークフローの有無に関わらず）。
- **管理者**は記事を削除し、すべての管理機能を実行できる。

パブリッシャー権限を付与する必要がある場合は、**Settings › User Management › Internal Groups › Publisher Group › + User**に移動する。



![image](https://cdn.sanity.io/images/umrbtih2/production/5c394b6339719aa49822b1e1a6fd9b9a0a6b888a-3840x2160.png)

## **ナレッジベースの構造（3つのコンセプト、混乱ゼロ）**

ナレッジベースは3つのコアコンセプトに基づいて構築されている。これらの関係を理解することで、後の再構築を大幅に節約できる。

### **記事 – 構成要素**

記事は、プロダクト、サービス、プロセスに関する情報を含む単一のドキュメントだ。すべての記事に必要なもの：

| 属性 | 機能 |
| --- | --- |
| タイトル | 顧客に表示される名前 – 意図駆動にする |
| 説明 | 検索関連性を高める簡潔な要約 |
| Part（必須） | 記事がカバーするプロダクトまたは機能 |
| Owned by（必須） | 正確性を維持する責任者 |
| ステータス | 下書き、公開済み、またはアーカイブ済み |
| コレクション | ポータルで属するカテゴリ |
| Visible to | どのオーディエンスに表示されるかを制御 |

### **コレクション – 整理構造**

コレクションは、カスタマーポータルで記事をグループ化するテーマ別カテゴリだ。顧客がブラウズするヘルプセンターの章として考えてほしい。

- コレクションとパーツは**別個のエンティティ**だ。コレクションはポータルを整理し、パーツはプロダクト構造を表す。
- **コレクションをネスト**して、マルチレベル階層を作成できる。
- ヘルプセンターでのコレクションの順序は、DevRevアカウントでの配置と一致する。

### **パーツ – プロダクトマップ**

パーツはプロダクト階層（プロダクト、機能、フィーチャー）を表す。すべての記事は少なくとも1つのパーツにリンクする必要があり、これによりComputerがコンテンツの属するプロダクト領域を理解する。  


## **5分以内に最初の記事を作成**

ステップバイステップの手順：

1. **Settings › Support › Knowledge Base**に移動する。
2. **+Article**をページ上部でクリック。
3. **タイトル**と**説明**に移動する。
4. コンテンツ方法を選択する：
   - **新しい記事を作成**し、内蔵のリッチテキストエディターを使用する。
   - **既存の記事にリンク**する（外部Webサイトでホスト）。
   - **ファイルをアップロード**する（PDFまたはMS Wordドキュメント）。
5. 設定を構成する：Part、Owned by、Status、Collection、Visible to。
6. **Create**をクリックし、以下のいずれかを選択する：
   - **Create**（下書きとして保存）。
   - **Create and submit for review**（レビュアーに送信）。
   - **Publish**（顧客に即座に表示）。

### **リッチテキストエディター – フォーマットツールキット**

エディターで /（スラッシュコマンド）を入力してアクセス：

- **テキストフォーマット。**見出し（H1、H2、H3）、太字、イタリック、下線。
- **構造。**箇条書き、番号付きリスト、テーブル、コールアウト、引用。
- **メディア。**画像、動画埋め込み（YouTube、Loom、Vimeo、Wistia）。
- **特殊要素。**ハイパーリンク、コードブロック、コンテンツブロック。
- **AIアシスタンス。**テキストを選択し、Ask AIを使用してコンテンツの言い換え、拡張、短縮、修正を行う。

**プロのヒント：**見出しタグ（H1、H2、H3）を一貫して使用する。カスタマーポータルで目次が自動生成され、Computerの検索パフォーマンスが向上する。

### **コンテンツブロック – 一度書いて、どこでも再利用**

![image](https://cdn.sanity.io/images/umrbtih2/production/c752ce927ff7de3f6eb74facf2af2e4b9bd85a9f-3840x2160.png)

  
コンテンツブロックは、複数の記事に挿入する再利用可能なスニペット（テキスト、画像、テーブル、動画）だ。ブロックを一度更新すれば、使用しているすべての記事が自動的に更新される。

- **作成：**Settings › Support › Content Blocks › Create Content Block。
- **挿入：**記事エディターで / を入力し、Content Blockを選択。
- **リンク解除：**特定の記事のためにコンテンツブロックを独立して編集するには、ホバーして3ドットメニューをクリックし、Unlinkを選択する。

##   
**公開は完了を意味しない**

### **日常的な記事管理**

**編集：**記事を開く › フルスクリーンアイコンをクリック › ペンアイコン（右上）をクリック › 変更を加える › SaveまたはPublish。

- **Save**は、顧客に現在表示されている内容に影響を与えずに新しい下書きバージョンを作成する。
- **Publish**は新しいバージョンを作成し、変更を即座に表示する。

**バージョン管理：**すべての編集は新しいバージョンとして保存される。以前のバージョンを復元するには、記事を開く › 3ドットメニュー › Versions › Restore version。

**一括操作：**メインKBビューで複数の記事を選択し、ステータスを一括変更または一括削除（削除には管理者権限が必要）。

### **承認ワークフロー – スピードより品質**

レビューサイクルが必要なチーム（特に規制産業）には、承認ワークフローがコントロールを提供する：

| ロール | できること |
| --- | --- |
| ドラフター＆承認者 | 記事のドラフト、レビュー提出、割り当てられた場合の承認 |
| パブリッシャー | ドラフターのすべての権限に加えて公開 |
| 管理者 | 削除を含むすべての機能 |

**フロー：**記事を作成 → レビューに提出 → レビュアーが承認（または変更を要求） → パブリッシャーが公開。

デフォルトでは、すべてのチームメンバーにドラフターと承認者の権限があるが、**ない**パブリッシャー権限は。コンテンツ品質を高く保ちながら、人々の速度を落とさない。



## **可視性パズル：誰が何を見るか（そしてなぜ全員がつまずくか）**

可視性は、チームが最も頻繁につまずくポイントだ。仕組みは次のとおり：

| Visible to | 誰が見えるか |
| --- | --- |
| Customers | 公開。ログイン不要（Public Portalの有効化が必要） |
| Verified Customers | プライベート。ログイン必要 |
| Customer Admins | 管理者ロールを持つrevユーザーのみアクセス可能 |
| （空白） | 内部のみ – 外部の誰にもアクセス不可 |

**重要なルール：**記事の可視性は**記事とコレクションの両方**の設定に依存する。非公開コレクション内の公開記事は誰にも表示されない。記事を表示したい場合は、コレクションが公開されていることを確認する。

**パブリックアクセスの有効化：**Settings › Plug & Portal › Portal Settings › Help CenterとPublic Portalを有効化。



## **正しいコレクション設計：組織図ではなく顧客のように考える**

コレクションの作成は簡単だ：**Settings › Support › Article Collections › +Collection** › タイトル、説明、親を入力 › Publish Collectionを有効化 › Create。

しかし、コレクション構造の背後にある_戦略_は、メカニクスよりも重要だ。

### **機能するコレクションの4つのルール**

1. **組織図ではなく、顧客の意図で整理する。**「始め方は？」は「CSチームプロセス」に勝る。顧客は内部構造を知らないし、気にしない。
2. **ネストは浅く保つ。**1〜2レベルのサブコレクションが理想的だ。深いネストはコンテンツを見つけにくくする。
3. **コレクションと記事の可視性を揃える。**プライベートコレクション内の公開記事は表示されない。両方を確認する。
4. **説明的な名前を使用する。**コレクション名は、顧客に中身が何かを即座に伝えるべきだ。

##   
**人間とAIに同時に書く（両方を満足させる9つのルール）**

ここがナレッジベース管理が本当に面白くなるところだ。Computerは記事をより小さなチャンク（段落と文）に分割して検索を強化する。すべての段落は、独立して回答として表示される可能性のあるモジュールだ。

### **AI最適化コンテンツの9つのルール**

1. **1記事1トピック。**タイトな凝集性 – 各記事は単一のテーマをカバーする。
2. **見出しタグ（H1、H2、H3）を使用する。**検索パフォーマンスを向上させ、目次を自動生成する。
3. **意味のある説明を書く。**検索関連性を高め、SEOシグナルとして機能する。
4. **意図駆動のタイトルを使用する。**「Xアカウントの閉じ方」 – 「アカウント閉鎖手順」ではなく。
5. **段落の規律。**各段落は単独で読んだときに意味が通るべきだ。「さらに」や「次に」で始めることを避ける。
6. **テーブルを最小限に。**2列テーブルは通常、AIの可読性向上のためにリストとして書くことができる。
7. **メディアのテキスト代替を含める。**画像と動画は現在モデルのトレーニングに使用されていない。常にサポートテキストを含める。
8. **承認された用語を一貫して使用する。**専門用語なし、コードネームなし。
9. **代名詞を具体的に。**「it」ではなく「Computer」。「this」ではなく「The article」。常に明確な先行詞。

### **分割 vs. 結合の判断  
**

| シナリオ | 推奨 |
| --- | --- |
| 同じプロセス、異なるプロダクト（例：プロダクトAとプロダクトBのアカウント閉鎖） | それぞれに意図駆動のタイトルを付けた別々の記事 |
| 1つのプロセスに複数の方法（例：メール、電話、アプリによるパスワードリセット） | 各方法のH2/H3見出しを持つ単一の記事 |

  
**スコアボード：何が機能しているか（何が機能していないか）を示すメトリクス**

**Settings › Support › Article Analytics**でパフォーマンスダッシュボードにアクセスする。

### **追跡すべきもの**

| メトリクス | 何を教えてくれるか |
| --- | --- |
| 閲覧数 | 総ビュー、ユニークビュー、ユーザータイプ別、チャネル別 |
| エンゲージメント | 記事の平均滞在時間 |
| ユーザーフィードバック | 読者からのアップボートとダウンボート |

### **アクションすべきもの**

- **閲覧数が高く、評価が低い記事。**見つかっているが役に立っていない。コンテンツを書き直す。
- **最も閲覧されている記事。**最も重要なコンテンツ。正確で最新に保つ。
- **閲覧数ゼロの記事。**ニッチなトピックか、発見可能性の問題（タイトルが悪い、コレクションが間違い、可視性の設定ミス）。
- **チャネル分布。**顧客がPLuG、ポータル、AI搭載検索のどれで記事を見つけているかを理解する。

## **マジックレイヤー：Computerが記事を即時回答に変換する仕組み**

Computerは顧客対応の会話で2つのモードで動作する：

1. **サジェストのみモード。**Computerがサポートエージェントに回答を提案し、エージェントは送信前に承認、編集、拒否できる。
2. **コンテンツ搭載モード。**Computerが人間に届く前に顧客のクエリに自動的に返信する。ナレッジベースを検索し、回答を生成し、顧客に有用だったかを確認する。

Computerは**QnAペア**をよくある質問への決定的な回答として優先し、より広範なクエリには記事コンテンツにフォールバックする。

### **ナレッジギャップ検出**

Computerはドキュメンテーションが不足している箇所も特定できる：

- ドキュメンテーションが欠落していたために人間のエージェントが介入する必要があった場合を検出する。
- クエリとエージェントの手動回答をキャプチャする。
- レビュー用にQ&A記事を下書き状態で自動生成する。
- 重複を避けるため、新しいコンテンツを作成する前に既存のドキュメントをクロスチェックする。

自動生成されたすべての記事は、人間のレビューまで下書きに留まる。精度、ブランドトーン、コンプライアンスを確保するためだ。  


## **顧客が感謝するものを構築しよう**

Computerのナレッジベースは、午後にセットアップして時間をかけて改善する種類のツールとして設計した。6か月のドキュメンテーションプロジェクトではない。顧客の上位5つの質問から始め、公開し、次に何を書くかはデータに導かせよう。

公開する記事は、明日のチケットが1つ減り、今日の回答が1つ速くなることを意味する。そして本当にプロダクトを_理解する_AIを意味する。5つの質問から始めよう。データが次にどこへ向かうべきかを示してくれる。