WordPress AI FAQチャットボットの導入設計｜公開記事限定RAGと安全運用

WordPressのAI FAQチャットボットは、公開済み記事だけを検索し、回答と同時に検証できる出典リンクを返す構成から始めます。ブラウザーからモデルAPIへ直接接続せず、サーバー側ゲートウェイで入力制限、検索、生成、出典、レート制限を扱います。答えがないときは推測せず、問い合わせ先へ戻します。

この記事は、公開判断に必要な構成、インターフェース契約、テスト、運用を決める導入設計です。コピーだけで動くWordPressプラグインやゲートウェイの完成実装は提供しません。記事収集・削除同期の実装はWordPressサイトをRAG化する方法へ分け、ここではFAQ画面から安全なフォールバックまでの責任分界を扱います。医療・法律・金銭判断、個別契約、アカウント操作など高リスク用途は、FAQボットだけで完結させないでください。

情報確認日：2026年8月17日（日本時間）

FAQボットは8段階で小さく公開する

AI FAQチャットボットが向くサイトは？

• 同じ基本質問が繰り返され、回答が公開記事に明記されている
• 料金、仕様、手順、ポリシーの正本URLと更新担当者がある
• 出典リンクを開けば利用者が自分で確認できる
• 答えがない場合の問い合わせ先とレスポンス時間が決まっている
• 公開前・更新後にテストする担当者がいる

記事が古い、同じ質問に複数の矛盾した回答がある、問い合わせ先がない場合は、ボットより先に正本を整えます。AIは出典の不備を解消せず、見つけた不備を流暢に拡大する可能性があります。検索して根拠を渡す仕組みそのものが初めてなら、先にRAGとは何かで全体像を押さえておくと、この先の構成図が読みやすくなります。

AI FAQチャットボットが向かない質問は？

全体構成はどうする？

公開WordPress記事
  ↓ REST API / scheduled sync
normalize → chunk → embedding → public-only index
                                      ↑
visitor → accessible widget → same-origin WordPress endpoint
                                      ↓
                      server-side FAQ gateway
                  validate / rate limit / retrieve
                                      ↓
                        local or approved model
                                      ↓
                 answer + sources + fallback + request ID

モデル提供元がローカルでもクラウドでも、ブラウザーへ機密情報を置きません。WordPress側の同一オリジンのエンドポイントはリクエストを受け、サーバー側で承認済みゲートウェイへ渡します。ゲートウェイだけがモデルの認証情報やローカル実行環境へ接続します。

出典ポリシーを最初に固定する

出典ポリシーはコードと運用文書の両方に置きます。「今は公開情報しかないから大丈夫」ではなく、将来追加される投稿タイプやプラグインデータが自動で混ざらない許可リストにします。

WordPress REST APIで何を取得する？

WordPressの公開投稿エンドポイントはGET /wp/v2/postsです。公開FAQに必要なフィールドだけを_fieldsで取得します。

curl -sS -D headers.txt \
  "https://example.com/wp-json/wp/v2/posts?context=view&status=publish&per_page=100&page=1&orderby=modified&order=asc&_fields=id,link,slug,modified_gmt,title.rendered,content.rendered"

status=publishを明示し、認証が必要なcontext=editを使いません。ページも対象にする場合は、同じポリシーで/wp/v2/pagesを別に取得します。カスタム投稿タイプは、その種別がRESTへ公開され、出典ポリシーで承認された場合だけ追加します。

REST取得項目の契約表

author、コメント、meta、media、プラグイン独自フィールドを「念のため」取得しません。WordPress公式資料も、_fieldsで必要なフィールドへ絞るとレスポンスと不要な処理を小さくできると説明しています。

100件を超える記事はどう同期する？

REST コレクションのper_pageは最大100です。レスポンスヘッダーのX-WP-TotalPagesを読み、1から最終ページまで取得します。

page=1を取得
  ↓ X-WP-TotalPagesを読む
page=2 ... last pageを取得
  ↓
全IDと保存中IDを照合
  ├─ new / modified → normalize・re-index
  ├─ unchanged      → keep
  └─ missing        → index・cache・citation registryから削除

modified_afterによる差分取得だけでは、削除・非公開化された投稿がレスポンスに現れません。定期的な全IDの照合を行い、公開対象から消えたIDをインデックスと出典レジストリから削除します。詳細な収集・削除設計はWordPressサイトをRAG化する方法へ分けています。

本文をどう正規化する？

1. WordPressが返した生成済みHTMLをDOMパーサーで読む
2. script、style、フォーム、ボタン、ナビゲーション、広告、関連記事を除く
3. 見出し、段落、一覧、表の意味を保ってテキスト化する
4. HTML エンティティと空白を正規化する
5. shortcodeの残骸、追跡 パラメーター、重複ブロックを除く
6. 投稿ID、タイトル、URL、更新、セクション見出しをチャンクへ付ける

正規表現だけで複雑なHTMLを除去すると、表や見出しの関係を壊しやすくなります。実際のテーマ・プラグイン出力をテスト用データとして保存し、パーサーの回帰テストを作ります。

検索インデックスをpublic-onlyに保つ

FAQボット専用のインデックスを作り、社内資料、顧客データ、管理者向けmemoと共有しません。コレクション名が同じでメタデータ フィルターを忘れる事故を避けるため、機密区分が異なるデータは物理・論理的に分離します。

• インデックス作成時にvisibility=publicを固定する
• 出典レジストリにWordPress 投稿タイプ・ID・ステータス・URLを持つ
• クエリ時にも公開 コレクションだけを指定する
• 削除後に検索hitと引用の両方から消えたことをテストする

回答プロンプトには何を要求する？

役割: このsiteの公開FAQ案内
根拠: supplied contextだけを使う
不明: 根拠が不足・矛盾する場合は「公開記事では確認できません」と答える
個別data: 注文番号、氏名、mail、健康・契約情報を求めない
出典: claimごとにsource IDを示す
action: tool、mail、database、WordPress更新を実行しない
着地: source linkまたは問い合わせ先を案内する

「必ず回答する」より「答えない条件」を具体化します。システムプロンプトだけをセキュリティ境界にせず、検索コレクション、出力スキーマ、ゲートウェイ検証、UI描画でも制限します。

返却JSONの契約を固定する

{
  "answer": "公開記事では、返品申請は到着後7日以内と案内されています。",
  "grounded": true,
  "sources": [
    {
      "title": "返品・交換ポリシー",
      "url": "https://example.com/returns/",
      "modifiedAt": "2026-08-01T03:00:00Z"
    }
  ],
  "fallback": {
    "required": false,
    "label": "問い合わせる",
    "url": "https://example.com/contact/"
  },
  "requestId": "faq_01J..."
}

記事に根拠がない場合はgrounded=false、sources=[]、fallback.required=trueにします。HTTP 200で返すアプリケーション上の「答えなし」と、ゲートウェイ障害の5xxを分けます。

出典URLをモデルに自由生成させない

モデルには出典IDを書かせ、ゲートウェイが検索結果のレジストリからtitle、正規URL、更新を引き直します。未知ID、同一origin外、非HTTPS、公開対象外のURLは捨てます。

出典UIの詳細、主張との対応、存在しないURLを防ぐ実装はRAGの引用・出典を正しく表示する方法で確認できます。

ブラウザーへAPIキーを置かない

公開ページのHTML・JavaScript・ソースマップ・ネットワークリクエストは利用者から見えます。モデルAPIキー、ローカル実行環境のトークン、ゲートウェイの管理認証情報を埋め込まないでください。

ブラウザーは同一オリジンのWordPressエンドポイントだけを呼びます。WordPressエンドポイントとゲートウェイ間はサーバー間通信を認証し、認証情報は環境変数やシークレット管理へ保存します。公開エンドポイント自体には、レート制限、本文サイズ、タイムアウト、不正利用の監視を適用します。

ウィジェットとエンドポイントのインターフェースをどう設計する？

テーマへ直書きせず、サイト固有のプラグインのshortcodeまたはブロックで、必要なページだけへ出します。次はUIとレスポンス契約を検討するための最小例です。

<section class="faq-bot" aria-labelledby="faq-bot-title">
  <h2 id="faq-bot-title">公開記事から質問する</h2>
  <p>個人情報や注文番号は入力しないでください。回答はsourceで確認できます。</p>
  <form id="faq-bot-form">
    <label for="faq-question">質問</label>
    <input id="faq-question" name="question" maxlength="500" required>
    <button type="submit">質問する</button>
  </form>
  <div id="faq-answer" aria-live="polite"></div>
  <ul id="faq-sources" aria-label="回答の参照元"></ul>
</section>

<script type="module">
const form = document.querySelector("#faq-bot-form");
const answer = document.querySelector("#faq-answer");
const sources = document.querySelector("#faq-sources");

form.addEventListener("submit", async (event) => {
  event.preventDefault();
  answer.textContent = "公開記事を確認しています…";
  sources.replaceChildren();

  const question = new FormData(form).get("question").toString().trim();
  const response = await fetch("/wp-json/site/v1/faq", {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({ question })
  });

  if (!response.ok) {
    answer.textContent = "現在回答できません。問い合わせページをご利用ください。";
    return;
  }

  const data = await response.json();
  answer.textContent = data.answer;

  for (const source of data.sources ?? []) {
    const url = new URL(source.url, location.origin);
    if (url.origin !== location.origin || url.protocol !== "https:") continue;

    const item = document.createElement("li");
    const link = document.createElement("a");
    link.href = url.href;
    link.textContent = source.title;
    item.append(link);
    sources.append(item);
  }
});
</script>

サンプルはインターフェースと安全な描画方法を示す設計例であり、動作検証済みウィジェットではありません。textContentとDOM APIを使い、モデルのHTMLを実行しない前提です。本番ではネットワーク エラー、タイムアウト、送信中の二重クリック、フォーカス移動、スクリーンリーダー、JavaScriptなしのフォールバック、プライバシーの注意書きも実装します。

WordPress RESTエンドポイントで何を検証する？

WordPress公式のセキュリティガイドは、入力を信頼せず検証・無害化し、出力時にコンテキストに合わせてエスケープするよう案内しています。LLM出力も外部APIやデータベースと同じ信頼できないデータです。

Prompt Injectionへどう備える？

公開記事や質問に「前の指示を無視して」と書かれても、ツール実行、機密情報取得、WordPress更新へ進めない構成にします。

• コメント、フォーム入力、外部ページをインデックスへ混ぜない
• 記事本文を指示ではなく引用データとして区切る
• モデル コンテキストへ機密情報・非公開データを入れない
• FAQボットにファイルシステム、メール、データベース 書き込み、MCP ツールを接続しない
• 出典IDとURLをアプリケーション側で検証する
• 攻撃文を含む記事テスト用データと質問を回帰テストへ入れる

OWASP 2025 LLM Top 10はPrompt Injection、Improper Output Handling、Excessive Agencyなどを挙げています。FAQという用途では、テキスト回答と公開された出典リンクだけに権限を絞ることが大きな対策です。

答えがないときの文面

「分かりません」で行き止まりにせず、問い合わせURL、営業時間、通常のレスポンス目安を、公開中の正本から表示します。緊急時は通常問い合わせではなく、適切な緊急窓口へ分岐します。

ステージングでは何をテストする？

検索と回答を分けて測るデータセット設計はRAG評価のやり方を参照し、FAQ固有の問い合わせ分岐、プライバシー、アクセシビリティを追加します。

公開前チェックリスト

公開後に何を測る？

未加工の質問文を無期限に保存しません。個人情報が入力される前提で、本文を保存しない集計、短い保持、マスキング、アクセス制御を設計します。コンテンツ改善には、匿名化した話題・失敗理由・出典IDを使います。

記事更新をボット改善へつなげる

1. フォールバックが多い質問を話題単位で集計する
2. 本当にサイト 対象範囲内かコンテンツ担当者が判断する
3. 必要なら既存記事の正本へ追記し、レビュー・公開する
4. 同期後に新しい更新とチャンクが反映されたか確認する
5. 元の失敗クエリと類似クエリを回帰テストへ追加する

ボット専用の非公開回答を増やすより、利用者も検索engineも確認できる公開記事を正本として改善します。個別回答が必要な質問は公開記事へ無理に一般化せず、サポートへ残します。

停止・ロールバック手順をどう作る？

• 機能フラグでウィジェットを非表示にし、記事と問い合わせは残す
• WordPressエンドポイントをメンテナンス用レスポンスへ切り替える
• 同期処理を止め、事故時の証拠を保全する
• モデル・インデックス・プロンプト・コードを直前の承認バージョンへ戻す
• 重大な誤回答出典と影響リクエストIDを特定する
• 必要な利用者・担当者へ通知し、修正後に全テストを再実行する

停止中に「AI FAQは使えません」とだけ表示せず、検索、主要FAQ、問い合わせページへの通常リンクを示します。

役割分担はどうする？

よくある質問

FAQボットは出典付きで小さく公開する

WordPressのAI FAQチャットボットは、公開済み公開記事だけをREST APIから必要フィールドに絞って取得し、公開情報専用インデックスで検索し、回答と出典を返す設計から始めます。ブラウザーへ機密情報を置かず、サーバー側ゲートウェイで検証、レート制限、検索、スキーマを管理します。

記事にない質問、矛盾、個別データ、高リスク判断は推測せず、人の窓口へ戻します。削除・非公開の同期、出典の検証、アクセシビリティ、監視、停止・ロールバックまでを公開条件にすると、FAQボットは記事とサポートをつなぐ入口として安全に改善できます。

公式・一次資料

• WordPress REST API Handbook: Posts
• WordPress REST API Handbook: Global Parameters
• WordPress REST API Handbook: Pagination
• WordPress Common APIs Handbook: Security
• WordPress Common APIs Handbook: Escaping Data
• OWASP 2025 Top 10 for LLMs and Gen AI Apps