ページフィードバック

Docsbookのページフィードバックは、読者が1クリックで回答できるこのページは役に立ちましたか？というコントロールです。フォームもメールアドレスもアカウントも必要ありません。投票はそのページに対するイベントとして記録され、対応可能なWebhookとしても利用できます。収集時にモデルは呼び出されず、費用もかかりません。

評価は指標であり、スコアではありません。このページでは、評価を収集する方法だけでなく、低評価から何が証明されないのかについても同じくらい重要です。

得られるもの#

• すべてのページにワンクリック評価を、すべてのプランで1か所または2か所に設置できます。
• 投票結果がすぐに自社システムへ届きます — feedback.received webhookと、低評価の場合には2つ目のchat.negative_feedback webhookが送信されるため、悪い評価が発生した瞬間にチームのチャンネルへ届けられます。
• 読者ごとの履歴。 訪問者のタイムラインでは、投票が「ページが役に立ったと評価」または「ページが役に立たないと評価」として、読者が行ったその他すべての行動と並んで表示されます。これにより、1件の投票が意味のある情報になります。
• どう対応すべきかをすでに把握しているキュー。 提供済みの2つのエージェントルートは、否定的なフィードバックや未回答のチャット質問から始まり、下書きページの作成で終わります。

読者が評価できるものは？#

3つのコントロールがあり、それぞれ測定するものは同じではありません。

ページの下にあるバーは、ほとんどのプロジェクトでオンにしたいものです。読者はページを読み終えたときにそこへ到達します。それは読者が意見を持つタイミングです。一方、アウトラインのコントロールが目に入るのは、すでに右側のレールに視線を向けている読者だけです。2つのページコントロールは1つの系列に書き込みます。質問する場所が2つあるだけで、2つの指標ではありません。

AI回答のサムズ評価は本当に別の系列であり、異なるフィールドを持ちます。パスだけの評価は誰も行動に移せない単なるカウンターになるため、会話IDと投票の対象となった質問が記録されます。回答のオーバーフローメニューにある問題を報告も、同じ低評価イベントを書き込みます。

1ページビューにつき、各コントロールで1票。投票するとボタンはロックされ、質問の代わりに短いお礼が表示されます。この制御はコントロールごとに行われるため、両方のページコントロールをオンにしたプロジェクトでは、同じ読者から同じページに対して2票を受け取ることができます。これは意図的に許容されています。意図的に2回投票する読者は、同じことを2回伝えているからです。シグナルが増えるわけでもないのに、表示場所をまたいで重複排除するには共有状態が必要になります。

ページフィードバックをオンにする#

ページ下部（デフォルトでオン）：

1. サインインした状態でドキュメントサイトを開きます。
2. Float Widget → 設定 → コンテンツタブを開きます。
3. このページを評価をオンにします。

「このページ」パネルの場合：

1. Float Widget → 設定 → 右サイドバータブを開きます。
2. ページを評価をオンにします。

どちらも update_ui_settings（show_content_feedback、show_page_feedback）を使用してMCPクライアントから設定できます。

投票ごとに保存される内容#

ページ投票は意図的に最小限です。どちらのページコントロールにも自由記述欄はなく、セッション ID も、読者が入力した内容もありません。

数値の意味を変えるため、知っておくべき動作が 2 つあります。

• 自分のチームによる投票は分析から除外されますが、Webhook には引き続き送信されます。自分のページをテストすることは読者の反応を示すものではないため、分析への書き込みでは内部トラフィックを除外します。ただし、評価が行われたことは所有者に通知されます。
• comment フィールドはペイロードに存在しますが、これらのコントロールによって入力されることはありません。これはその値を収集する画面のために用意されていますが、現在どちらのページコントロールも収集していません。

AI 回答への投票には、プロジェクト、読者が閲覧していたページ、会話 ID、質問が保存されます。回答本文や、同じ IP ハッシュ以外の読者の識別情報は保存されません。

所有者に表示される内容#

Webhookの登録はすべてのプランで利用できます。MCP経路とREST経路は同じ機能権限を確認し、高度なイベントのうち3つ（トラフィック急増、トラフィック急減、MCPツール呼び出し）だけが分離されています。複数のMCPツールの説明では、現在もこれら2つのイベントをProとして案内していますが、その文言は動作ではなく古い情報です。

質問中 — フィードバックタブはページの系列ではなく、AI回答の系列として読んでください。 タブの合計値とページごとの行は、AI回答の高評価・低評価が書き込むイベントである docs.ai_like / docs.ai_dislike に対するクエリから構成されています。ページのコントロールは docs.page_feedback_up / _down に書き込みますが、そのタブの背後にあるクエリはそれらを読み取りません。したがって、今日のページ投票はWebhookと訪問者タイムラインには届きますが、フィードバックタブの集計には届きません。get_negative_feedback も同じ構造で、独自のコードコメントには、ページレベルのイベントは「ここには統合されない」と明記されています。これが修正されるまでは、フィードバックタブをアシスタントの回答の指標として扱い、ページ投票にはイベントフィードまたはWebhookを使用してください。

低評価から次に書くページへ#

評価は調査結果ではありません。実行可能なものにするのは、その隣にある情報です。つまり、何も返さなかった検索、アシスタントが答えられなかった質問、そして投票後に読者が取った行動です。

この一連の流れがすでに組み込まれたエージェントルートが2つあり、どちらもProで利用できます。

ユーザーフィードバックからドキュメントを改善 — 週1回の実行を推奨します。読者が悪いと評価したページを読み、再度同じ修正を行う前に、それらのページに対する以前の修正がすでにどのような結果をもたらしたかを確認し、読者が完了しようとしていた作業を尋ね、その後で初めて編集します。変更履歴のステップが存在するのは、これがないバージョンでは、書き換えた直後の数秒後にページの健全性を測定していたためです。まだ変化し得ない数値を測定していたことになります。

アシスタントとの会話から不足を補完 — chat.no_answer イベントで実行することを推奨します。アシスタントが答えられなかった質問を読み、ドキュメントの不足と質問自体の問題を切り分け、その日に書く価値のあるものを選び、そのページの下書きを作成します。

パネル内のすべての改善ボタンの背後にあるプロンプトには、同じ4つのルールが組み込まれており、手動で適用する場合もこのルールに従います。すべての数値を何かと照らし合わせて判断し、何と比較したかを述べること。実際に読んだページとイベントを引用すること。読めない指標はゼロではなく欠落として扱うこと。そして、何かを編集する前に診断で止めることです。

評価の収集でモデルが呼び出されることはなく、使用量にも計上されません。上記のエージェントルートはモデル処理であり、プロジェクトの残高を消費します — 料金ページをご覧ください。

これが正しい方法である理由（根拠）#

この4行を実際に読むと、次のようになる。低評価が10件あるページは開いてみる価値がある。高評価が3件あるページは、それだけでは役に立つという証拠にならない。そして投票がまったくないページは、誰にも嫌われなかったページではなく、何もわからないページである。

制限#

• フィードバックタブでは現在、ページへの投票はカウントされません。 上記の質問下ブロックを参照してください。このページにある主張のうち、以前のドキュメントのバージョンが誤っていたのはこれだけであり、ひっそり削除するのではなく、ここに明記しています。
• 投票には理由が伴いません。 どちらのページコントロールも自由記述を収集しないため、低評価から分かるのは何かが間違っていたということだけで、何が間違っていたのかは決して分かりません。AI回答への低評価のほうが情報量が多いのは、質問が含まれるからです。
• 評価は読者ごとではなく、表示ごとに記録されます。 翌日に戻ってきた読者は再度投票できます。また、両方のページコントロールを有効にしたプロジェクトでは、1人の読者から1回のページ表示で2票を受け取ることがあります。
• フィードバックが最も有益なのは、手順を説明するページ — チュートリアルやハウツーガイドなど、読者がタスクを完了したかどうかが明確なページです。パラメータテーブルでは、評価から分かることはほとんどありません。
• Docsbookのフィードバック率がどの程度になるかについて、ベンチマークは公開していません。 顧客間の分布は測定されていないため、自分のサイトと比較できる「健全な」数値はありません。上記の外部ソースは一般的な任意のフィードバックについて述べたものであり、Docsbookサイトについてのものではありません。
• コメント欄はペイロードに含まれていますが、そこに入力するものは何もありません。 コメントを収集する画面を構築する場合、Webhookのコントラクトにはすでにそのための場所があります。標準状態では常に null です。

関連項目#

• AIチャット — 回答それぞれに個別の評価ボタンが付くアシスタント。
• 回答の品質 — アシスタントが回答できなかった質問に何が起こるか。
• 全文検索 — 検索の失敗は、ページが存在しないか、名前が間違っていることを示すもう一つのシグナルです。
• ウェブ分析 — 3件の投票だけでページを書き直す前に、そのページへのトラフィックを確認します。
• Webhook — feedback.received と chat.negative_feedback が完全な形で署名され、再試行されます。