product-help-center

ヘルプセンターの設計

一般公開のヘルプセンター、アプリ内セルフサービス、AI が利用できるドキュメントシステムを設計します。

以下の成果が必要な場合に、このスキルを使用します。

• ヘルプセンター、ドキュメント、サポート AI のプラットフォームを選定または比較する
• 分類体系、ナビゲーション、記事の基準、ガバナンスを設計または監査する
• サポート AI が回答の根拠とする、承認済みソース、回答の要件、エスカレーションポリシーの内容を定義する
• セルフサービスの成果を測定する。デフレクションが純増分かどうかも含める
• 人間、検索、AI エージェントが利用しやすいドキュメントを作成する

以下は別のスキルに振り分けます。

• ボットのランタイム、フロー、状態、インテントの自動化、ツールの権限 → ai-bot-builder
• 音声と IVR → ai-voice-bots
• AI 回答エンジンにページを引用させる → marketing-aeo-geo
• プロダクトコードのアクセシビリティ修正 → software-accessibility
• プロダクトコードの i18n → software-localisation。国ごとのマーケティングローカライズ → marketing-geo-localization

ワークフロー

1. 対象となるサーフェスを分類する
   • サポートヘルプセンター、開発者向けドキュメントポータル、社内ナレッジベース、アプリ内ガイダンス、またはハイブリッド。
2. 対象者とリスクを定義する
   • エンドユーザー、管理者、開発者、エージェント、規制対象の顧客、多言語ユーザー。
3. 運用モデルを選択する
   • 人間が作成するドキュメントのみ、検索優先型のサポート AI、または承認済みツールを使うエージェント型サポート。
4. 情報アーキテクチャを設計する
   • カテゴリー構造、ナビゲーション、検索戦略、メタデータ、URL のルール、バージョン管理。
   • 公開または移行の前に、上位のタスクを使ってカテゴリー階層をツリーテストし、リダイレクトを作成する前に失敗する経路を修正します。
5. コンテンツを標準化する
   • 記事の種類、執筆ルール、ビジュアルのルール、再利用可能なテンプレート。
6. 品質を測定できるようにする
   • 検索分析、セルフサービスの成果、引用の品質、引き継ぎの品質、鮮度のシグナル。
7. ナレッジ運用を行う
   • オーナー、レビュー周期、リリースに応じた更新、古くなったコンテンツの改善。

想定される成果物：

• 根拠を添えたヘルプセンターまたはドキュメントプラットフォームの推奨
• 分類体系マップ、メタデータスキーマ、記事のバックログ
• ソース、エスカレーションポリシー、ガードレールを含むサポート AI の設計
• オーナーシップ、品質保証、測定の運用モデル

クイックリファレンス

サーフェスの選択

ニーズ	主なサーフェス	適したサービス
顧客のトラブルシューティング、請求、アカウントに関するサポート	サポートヘルプセンター	Zendesk、Intercom、Freshdesk
API ガイド、SDK ドキュメント、AI が利用できるドキュメント	開発者向けドキュメントポータル	ReadMe、Mintlify、GitBook
アプリ内オンボーディングとコンテキストに応じたヘルプ	アプリ内ガイダンスレイヤー	Intercom、Pendo、Appcues、カスタム
社内専用のランブックとエージェント向けナレッジ	社内ナレッジベース	Guru、Confluence、Notion
大量のサポート業務の自動化	検索優先型のサポート AI	Zendesk AI、Intercom Fin、カスタム

コンテンツタイプの判断マトリクス

ユーザーのニーズ	コンテンツタイプ	形式	AI の役割
「〜するにはどうすればよいですか？」	手順ガイド	ステップ形式	リンクの提示、要約、手順の調整
「なぜ失敗するのですか？」	トラブルシューティング	症状 -> 原因 -> 解決策	診断と振り分け
「これはどういう意味ですか？」	概念説明	平易な説明	文脈の要約
「〜はどこにありますか？」	ナビゲーション	短い回答とリンク	該当する場所を正確に案内
「制限やルールは何ですか？」	リファレンス	表、リスト、正確な文言	事実をそのまま提示
「これを代わりに実行してもらえますか？」	タスクポリシー	実行ルールと承認	AI が実行してよいか判断

プラットフォーム選定ルール

• チケット管理、SLA、引き継ぎ、コンプライアンスが最優先要件の場合は、サポートスイートを推奨します。
• 主な課題が、構造化された製品ドキュメントまたは API ドキュメントの場合は、ドキュメントポータルを推奨します。
• Notion は、軽量な社内ナレッジや立ち上げ初期の公開ドキュメントには適していますが、本格的な公開ヘルプセンターの長期的な標準としては扱わないでください。
• ベンダーを最終的に推奨する前に、料金、パッケージ、プランの上限、現在の AI 機能を確認してください。
• サポート AI エージェントを推奨する前に、ベンダー独自のプランと製品ページを確認し、AI エージェントのプラン、対応チャネル、料金モデル（シート単位、解決件数単位、またはパッケージ料金）を把握してください。これらは、このスキルよりも頻繁に変更されます。

最新のプラットフォーム適合性ルールについてはplatform-guides.mdを、推奨ソースについてはsources.jsonを参照してください。

検索設計の前に決める回答の要件

チャンク、埋め込み、サポートモデルを選ぶ前に、リスクの高いインテントごとに回答の要件を定義してください。

• 正規ソースとその管理者。
• 該当する製品バージョン、プラン、役割、ロケール、適用開始日。
• 2 つのソースが食い違う場合に適用する、正確な例外ルールまたは優先順位ルール。
• 回答を要約してよいか、正確な引用が必要か、エスカレーションが必要か。
• 完了したことを確認できる状態と、ツールの操作後に記録される証拠。

承認済みの 2 つのソースが食い違う場合、情報の新しさだけでは優先するソースを決められません。記録された権限、適用範囲、適用期間、優先順位ルールに従ってください。これらの項目から適用するソースが特定できる場合は、そのソースに基づいて回答または操作を行い、食い違いを明らかにし、権限の低い古いソースを修正対象として登録して、操作の証拠を保持してください。優先順位を決められない場合、適用するソースが適用範囲外または適用期間外の場合、あるいは残る不確実性が取り消せない操作に重大な影響を及ぼす場合に限り、影響を受ける取引を一時停止してください。この要件がないまま、もっともらしい記述を返す検索システムは、サポートの自動化に利用できる状態ではありません。

AI が利用しやすいドキュメントの原則

• 安定した正規 URL と明確なページタイトルを公開します。
• 1 ページにつき、主なタスクまたは概念を 1 つに絞ります。
• 見出し、表、リスト、エラー文字列を正確に使用します。
• 名前が明示された利用者が使う場合は、機械可読な形式（Markdown エクスポート、API リファレンス、MCP サーバー、エージェント向けインデックス）を提供します。
• llms.txt または llms-full.txt は、利用方法を明記または実演している利用者がいる場合に限り公開します。これらのファイルは実験的なインデックスとして扱い、クロール、ランキング、引用、モデルのトレーニングを証明するものとは見なさないでください。また、優れた情報アーキテクチャ、検索、構造化ドキュメントの代わりにもなりません。

AI 向けドキュメントのレイヤーについてはai-consumable-docs.mdを参照してください。

回答エンジン向けの整備

ヘルプセンターのページは AI 回答エンジンの引用元になることが多いため、引用される情報を正確に保ってください。

• 正規 URL：事実ごとに正規 URL を 1 つ定め、ヘルプセンターとマーケティングサイトで同じ回答を重複させないでください。
• 最新性：制限、価格、ポリシーを記載したページでは、レビュー日とバージョン表記を正確に保ってください。
• エンティティの一貫性：製品名、機能名、エラー文字列を、ページ間で正確かつ一貫して使用してください。

回答の書式、FAQ または HowTo のマークアップ、llms.txt によって AI 引用が増えるとは約束しないでください。引用シェアの向上に関する作業は marketing-aeo-geo に振り分けてください。

ヘルプセンターのアーキテクチャ

カテゴリー構成のルール

主要なタスクとチケットのインテントを基にカテゴリーの規模を決めたうえで、ツリーテストを行い、カテゴリー名と階層の深さを確認してください。ユーザーの目標に沿って整理し、利用者が異なる場合はエンドユーザー向けヘルプと開発者向けドキュメントを分け、請求、セキュリティ、トラブルシューティング、リリースノートを見つけやすくしてください。

推奨するトップレベルカテゴリー

DEFAULT STRUCTURE
1. Getting Started
2. Core Workflows
3. Integrations
4. Account, Billing, and Security
5. Troubleshooting
6. Developers or API
7. Release Notes / What's New
8. Contact / Escalation

ナビゲーションパターン

• 関連するページレイアウトでユーザーが見つけやすい場所に検索を配置し、モバイルとデスクトップで見つけやすさをテストします。
• パンくずリストと関連記事は標準で用意します。
• すべてのトラブルシューティング記事にエスカレーション手順を含めます。
• すべてのハウツー記事に前提条件、完了後の状態、次の手順を含めます。
• バージョン管理された製品には、明示的なバージョンセレクターまたはバージョンラベルが必要です。

記事の基準

• 基本となる種類は、ハウツー、トラブルシューティング、概念解説、FAQ、リファレンス、リリースノートに絞ります。
• UI の正確なラベル、機能名、エラーメッセージを含めます。
• サポートコンテンツからマーケティング表現を取り除きます。
• 曖昧さを大幅に減らせる場合に限り、スクリーンショットを使用し、最新の状態に保ちます。
• すべての記事を、ユーザーにも情報検索システムにも単独で理解できる内容にします。

テンプレートについては article-templates.md、IA パターンについては taxonomy-patterns.md を使用します。

サポート AI の設計

解決モード

モード	モードに必要なコンテンツ	ソース要件
情報提供	意図に回答する承認済みの記事	引用、鮮度、フォールバック
ナビゲーション	正規のページまたはワークフローへのリンク	正確なリンク、プランとロールのラベル
診断	症状、原因、修正方法を含むトラブルシューティングコンテンツ	正確なエラーメッセージ、安全なトラブルシューティング手順
トランザクション	前提条件、承認、完了状態を含むタスクポリシーのコンテンツ	発効日が明記された、責任者承認済みのポリシー
エスカレーション	トリガーと引き継ぎ項目を含むエスカレーションポリシーのコンテンツ	トリガールール、要約、取得したコンテキスト

各モードで AI が実行できること、使用を許可するツール、確認ルールは、ai-bot-builder の Intent Automation Gate で定義します。

ガードレール

• 承認済みソースの一覧。
• 上記リンク先の bot-builder ゲートで設定する、インテントごとのツール権限。
• 根拠が不十分な場合、リスクが高い場合、または失敗が繰り返される場合のエスカレーショントリガー。
• 事実に関する主張には引用を必須とします。
• ライブトラフィックを増やす前に、シミュレーションと QA を実施します。

実装パターンについては ai-integration.md を参照してください。

指標と品質

主な指標

指標	何を確認するか
検索の成功率	ユーザーは関連する情報を見つけられましたか？
セルフサービス完了率	サポートを受けずに問題を解決できましたか？
引用の品質	回答は適切なソースに基づいていましたか？
エスカレーションの品質	AI は適切なタイミングで、十分なコンテキストを添えて引き継ぎましたか？
鮮度のカバー率	影響の大きいページは最新の状態ですか？
コンテンツギャップ率	まだ適切な回答がないインテントはどれですか？

AI 固有の指標

• 未解決インテント率
• 引用率
• ツール呼び出し成功率
• AI 対応後の再オープン率
• 古いソースの参照率
• 引き継ぎ受諾率

デフレクションは、ホールドアウトまたは段階的なロールアウトと比較して測定します。同じインテントについて、設定した期間内にサポートへの問い合わせが発生しなかった場合に限り、セルフサービスのセッションを解決済みとして数えます。ユーザーが数値を求め、最新データを確認できた場合を除き、固定の ROI やベンチマーク数値は使用しないでください。metrics-optimization.md の測定フレームワークを使用します。

チェックリストを超えた判断

チェックリストによる監査では、記事の欠落やリンク切れを検出できます。しかし、より重要で判断を要する次のような失敗は検出できません。

• 問い合わせ回避と問題解決の乖離：問い合わせ率の低下は、ユーザーが自力で問題を解決できていることを示す場合もあれば、問い合わせ経路が見つけにくくなったことや、AI アシスタントがエスカレーションせずに対応を引き延ばしていること、あるいは不満を抱えたユーザーが再度問い合わせることなく静かに離脱していることを示す場合もあります。対応品質を示す指標と組み合わせずに、問い合わせ回避率や自己解決率を信用しないでください。問い合わせ回避目標が逆効果になる場合を参照してください。
• コンテンツの負債と不足：既存の正確で最近レビューされた記事があるトピックについて問い合わせ件数が多い場合、通常はコンテンツ不足の問題ではありません。記事の内容とユーザーが問題を説明する方法にずれがあるか、過去の再設計によって情報アーキテクチャが競合していることを示しています。執筆を追加で依頼する前に、負債を診断してください。コンテンツ負債の診断を参照してください。
• AI の浅いグラウンディング：AI の回答に引用があっても、回答が正しいとは限りません。チャンク分割によってルールとその例外が切り離される場合や、検索で適切な事実が見つかっても、対象のプランやバージョンが異なる場合、または正確な2つの情報源を統合した結果、不正確な主張が生成される場合があります。引用率だけでは、こうした問題を検出できません。引用された主張を元のテキストと照合し、人間がレビューする必要があります。グラウンディング品質の判断を参照してください。

ナレッジ運用

ヘルプセンターをプロダクトとして運用します。

• カテゴリごと、および影響の大きい記事群ごとに担当者を割り当てます
• コンテンツの更新を、リリース、インシデント、検索件数の多いギャップに関連付けます
• 検索結果がゼロの検索、記事閲覧後のエスカレーション、評価の低い記事を、定めた間隔でレビューします
• 可能な限り、事実領域ごとに正規の情報源を1つ維持します

knowledge-ops.md、content-migration-guide.md、multilingual-support.md、accessibility-standards.mdを参照してください。

ナビゲーション

リソース	内容
article-templates.md	よくあるヘルプセンター記事の種類向けテンプレート
taxonomy-patterns.md	情報アーキテクチャとメタデータのパターン
ai-integration.md	検索を優先するサポート AI、ツールポリシー、エスカレーション
ai-consumable-docs.md	llms.txt、MCP、Markdown エクスポート、エージェント向けドキュメント
platform-guides.md	サポートスイートやドキュメントポータルに適したプラットフォームの指針、アプリ内ガイダンスのコンテンツ要件
metrics-optimization.md	測定フレームワークと計測パターン
knowledge-ops.md	ガバナンスとレビュー間隔
content-migration-guide.md	移行、リダイレクト、検証
multilingual-support.md	翻訳ワークフローとロケール運用
accessibility-standards.md	ヘルプコンテンツ向け WCAG 2.2 AA の指針
sources.json	信頼性と変動性のメタデータを含む、厳選された外部情報源

学びのループ

過去の判断や落とし穴が関係する場合は、learnings.consolidated.mdがあれば参照してください。必要な履歴を確認するとき、または利用可能な代替として使うときに限り、learnings.mdを参照してください。それ以外の場合は、どちらも参照しないでください。

適用した後、記憶に留める価値のあるパターン、防止すべき間違い、または意外だったドメイン上の事実に遭遇した場合は、agents-skills-feedback-loop/scripts/append_learning.pyを使用して、日付入りの箇条書きを1つlearnings.mdに追記してください。SKILL.md自体は変更しないでください。