DockerのFess FAQ検索を更新しクロールと回答表示を確認する

docker-faqsearchで、旧キーワード検索版からの更新手順と、クロール・ベクトル化の失敗検出が改善されました。helpdeskテーマにもカテゴリ選択や回答表示の修正が入り、更新後の検索結果を確かめやすくなっています。

バージョンと初期値を確認する

最新の設定例は FESS_VERSION=15.9.0、OPENSEARCH_VERSION=3.9.0、OPENSEARCH_HEAP=3g です。ただし確認時点のFess正式版は15.8.0で、15.9.0の正式イメージは配布済みと確認できていません。これらの修正を試すには対応する開発ビルドが必要です。PRでの実機検証はFess snapshotを使っています。

git pull は既存の .env や data/fess/themes/helpdesk を置き換えません。setup.shのバージョン警告は通知だけで、値は自動変更されません。更新前に .env の固定バージョンとテーマの実体を確認し、必要な値を変更してsetup.shを実行します。既存データを残す場合はバックアップを取ってから進めます。

旧15.7のキーワード検索版から文書を維持して移行する場合、メンテナンスの再インデックスで「エイリアスの更新」を行い、ベクトル対応のインデックスにします。クロールだけでは既存インデックスのベクトルマッピングは追加されません。保存済みGroovyジョブのJavaScriptへの切り替えと、Content Chunk Vector Indexerの実行も必要です。

登録スクリプトを再実行する

bin/register-faq-crawl.sh は既存の faq-content WebConfigをスクリプトのURL・除外条件などへ更新し、クロールとベクトルジョブを実行します。手動で変えた対象項目も更新される点に注意してください。--no-crawl でも設定は更新されます。

ジョブの最終状態がokでなければ失敗終了します。ベクトルジョブがokでも文書の content_chunk_status がdoneでなければ止まります。ただし検査は管理検索一覧の先頭ページのサンプルで、全件の保証ではありません。ジョブログとfess-chunk.log、実際の検索を併せて確認します。除外条件を更新しても、既に登録された入口ページなどの文書は自動削除されません。

bin/seed-faq.sh はラベルをvalue、関連コンテンツと関連クエリーをtermで照合し、未登録分だけ追加します。同じ識別子の既存内容は上書きしません。一覧取得が失敗した場合は止まります。検索ログ生成とLabel Updaterなどの実行は再実行時にも行われます。

FAQに合わせて類似度を調整する

SEMANTIC_MIN_SCORE の初期値0.3は12件のデモFAQに合わせた値です。実際のFAQでは正答の言い換えと対象外の質問を試し、モデルと内容に合わせて調整します。閾値を下げると無関係な回答も増える可能性があります。

# data/fess/opt/fess/system.properties
content_chunker.search.min_score=0.3

このファイルの値はJVMの-D指定より優先され、数秒以内に検索へ反映されます。行を削除すると-Dの値に戻ります。.env 側の値を変える場合はコンテナの再作成が必要です。検索時の閾値変更なのでベクトルジョブの再実行は不要です。3gは新しい初期値ですが、あらゆる負荷で容量不足を防げる保証ではありません。

回答画面で確かめること

helpdeskテーマでは、ホームのカテゴリタイルから移動した後の新しい検索へカテゴリが残らなくなります。利用者がオプション欄で明示的に選んだカテゴリは引き継ぎます。関連検索はURLにも反映し、400で拒否された検索では以前の回答・ページャー・ファセットを消します。

閉じたオプションパネルはTab順から外れ、開閉時のフォーカスとEscape、検索欄へ移動する /、ページリンクや狭い画面の表示が改善されました。テーマのソース版は15.9.10、minFessVersionは15.9です。

Fess本体では regex: を使うおすすめ回答の不正な正規表現を保存時に拒否し、既存の不正設定は読み込み時に警告してスキップします。空の検索ではおすすめ回答を返しません。また、空白で区切られた2語以上の通常クエリーでは、末尾の英数字に続く1つの ? を疑問符として取り除きます。I forgot my password? が対象で、単語1つの te? はワイルドカードのままです。空白なしの日本語文も対象外で、find te? の末尾ワイルドカードは使えなくなるという制限があります。

関連PR

Fessのログ保持期間と日本時間での削除境界を確認する

Fessの開発版に、ログの削除境界をUTCで計算する修正がマージされました。日本時間で動くサーバーでは、指定した保持日数より9時間早くログを削除してしまうケースへの対応です。ログを何日残すかの設定と、定期ジョブによる削除時刻を合わせて確認しましょう。

クリック・お気に入りログを削除対象へ加えた変更は以前の記事で紹介しています。今回は削除する日時の境界に関する修正です。

対応状況と適用条件

問題は、JVMの標準タイムゾーンがUTC以外で、保持日数を設定してLog Purgerがログ削除を行う場合に関係します。Asia/Tokyoでは、UTC保存の日時と比較する境界を日本時間の値で送っていたため、削除対象が9時間先まで広がっていました。修正後は境界をUTCで計算します。

保持期間の初期値は削除しない設定

管理画面の「システム > 全般」にあるログ削除日数は、初期値が-1です。-1の場合は期限による削除を行わず、保持し続けます。

「以前の検索ログを削除」の日数は、検索ログだけでなくクリックログ、お気に入りログ、チャットログにも使われます。「以前のユーザーログを削除」はユーザー情報に適用されます。「以前のジョブログを削除」にも初期値-1がありますが、今回のUTC修正は検索・クリック・お気に入り・チャット・ユーザー情報の5種類が対象です。

7日保持を日本時間で運用する例

日本時間2026年10月12日09:00、つまりUTCの2026年10月12日00:00に、7日保持の削除を実行する場合を考えます。

  • 修正前に送られる境界: UTCとして解釈される2026年10月5日09:00
  • 修正後に送られる境界: UTCの2026年10月5日00:00

修正前は、実際にはまだ7日経過していない9時間分も対象になります。修正後は現在時刻から7日を引いた境界以前を削除します。「7日前の日付の日本時間00:00」で区切る仕組みではなく、実行時刻から日数を引いた判定です。ユーザー情報は更新日時、検索・クリック・チャットは要求日時、お気に入りは作成日時が比較対象になります。

運用で確認すること

まず各保持日数と「システム > スケジューラ」のLog Purgerの実行設定を確認します。例えば検索ログ側を7日へ変更すると、クリック・お気に入り・チャットにも同じ日数が適用されるため、分析用途に必要な期間を先に決めてください。

修正はこれから行う削除の境界を変えるもので、既に削除されたログを復元するものではありません。保持設定を変える前に、必要なログを管理画面のバックアップなどで別途保管します。そこで取得するログの*.ndjsonは、管理画面からアップロードして復元する形式ではありません。

この保持設定はOpenSearch上のログを扱います。searchlog.logなどのファイルのローテーション・保管期間は別の設定なので、ディスク使用量を管理するときは両方を確認してください。

関連PR

FessのPlaywrightサムネイルを単独プラグインで動かすための条件

Fess 15.9の開発版では、Playwrightが本体の配布物から分離されています。PlaywrightでWebページのスクリーンショットを作るサムネイルプラグインを単独導入すると、Playwrightクラスが見つからず起動できない問題を修正するPRがマージされました。

2026年10月13日時点でfess-thumbnail-playwright #14と関連する本体・文書のPRはマージ済みです。

プラグインJARにAPIとドライバーを含める

修正では、PlaywrightのJava APIとJavaScriptドライバーをサムネイルプラグインのJARへ同梱します。WEB-INF/pluginへ置いたJARのMaven依存関係をFessが自動取得する仕組みはないため、必要なクラスを配布物に含める方法です。

これにより、修正版ではクローラープラグインfess-crawler-playwrightをサムネイル生成のためだけに追加する必要がなくなります。両方を使う場合は同じFessリリース向けの版をそろえます。異なるPlaywright版の混在を安全とする変更ではありません。

Node.jsは別に用意する

修正後のREADMEにある導入例は次のとおりです。修正を含む配布物が利用可能になった時点で、Fessとプラグインの対応版を確認して実行します。

bin/fess-setup install plugin fess-thumbnail-playwright
bin/fess-setup install nodejs

プラグインはNode.jsの実行ファイルを同梱しません。Fessの起動スクリプトがインストール済みNode.jsを見つけ、PLAYWRIGHT_NODEJS_PATHを設定し、サムネイルジョブが引き継ぎます。自分で用意する場合はNode.js 20以降を指定します。

ブラウザも別の依存物で、Playwrightが初回利用時にダウンロードします。初回の取得が可能なネットワークと、実行環境に必要なブラウザ依存ライブラリーを確認してください。Node.jsを入れれば全OSで無条件に動く、という意味ではありません。

本体のセットアップヘルプと15.9移行文書も、サムネイルプラグインにNode.jsが必要であることを明記しました。fess-setup checkのNode.jsがない場合のOK・FAIL判定自体を変えた修正ではありません。

Dockerの15.9向け構成でも、どのイメージもPlaywrightクローラー・サムネイルプラグインとNode.jsを自動導入しません。必要なプラグインをFESS_PLUGINSなどで明示し、Node.jsとChromiumのOS依存ライブラリーを別途用意します。通常版イメージのサムネイルツールは画像・PDF・Office用で、HTMLのスクリーンショット生成とは別です。

15.8の起動設定を丸ごと引き継ぐと、セットアップで入れたNode.jsを検出できない場合があります。15.9の起動設定を基に自分の変更を再適用し、必要ならPLAYWRIGHT_NODEJS_PATHを明示します。

有効化と確認範囲

thumbnail.enabledはシステムプロパティで、未設定時の初期値はfalseです。サムネイルを利用する構成では有効化も確認します。プラグインのコンポーネントは起動時に読み込むので、導入後はFessを再起動します。JARを置いたまま稼働中のジョブへ即時反映する方法ではありません。

修正PRでは単独プラグインでのクラス読み込み、DI構築、実ブラウザでのPNG生成を確認しています。一方、Fess全体の起動とWindows環境の確認は含まれません。実運用への反映前に、修正版の入手状況、Node.jsのパス、ブラウザ起動、実際のサムネイルジョブを順に確認してください。

関連PR