キーワードフィルターをいつでもどこでもテストする方法
キーワードベースのウェブフィルター（Dansguardian、SafeSquid、POESIA、We-Blocker、その他ペアレンタルフィルター）は、単語の出現数や重み付けスコアでブロック判断を行います。安全にフィルターが動作しているか確認するには、Block That（http://www.yourfilter.org）を使って2回テストを実行し、ブラウザのキャッシュとクッキーをクリアしてから再テストしてください。管理者はプロキシ設定、ポート、TLS（HTTPS）回避の有無、フィルタールール数と閾値を確認します。
重要なポイント
- テストは必ず2回実行すること。2回目の結果が本当の判定を示す。
- キャッシュとクッキーを消去してから再テストする。
- HTTPSサイトはキーワードフィルターで検出できない場合がある。プロキシのTLS中間者（MitM）やSNIフィルタリングの導入を検討する。
- DansguardianやSafeSquidの稼働状態、プロキシIP/ポート、閾値を確認するチェックリストを用意する。
概要と用語定義
キーワードフィルター: ウェブページのHTML内やURL、メタデータに含まれる単語・フレーズを評価して、あらかじめ定めた基準（重み付けスコア、閾値）を超えればアクセスをブロックする仕組み。
重み付けスコア: 個々の単語やフレーズに割り当てられた点数の合計。合計が閾値を超えるとページはブロックされる。
閾値: ブロック判定のしきい値。低く設定すると過検知（誤検出）が増え、高く設定すると見逃しが増える。
フィルターの対象: ページ本文、見出し、URL、フォームの入力、コメント、JavaScript内文字列、画像のALTテキスト（OCRやメタ情報が利用される場合）など。
どのようにキーワードフィルターは動作するか
キーワードフィルターは次のステップで動作します。短くまとめると:
- ページコンテンツをトークン化（単語分割）する。
- トークンごとに事前定義された辞書を照合し、該当単語に点数を割り当てる。
- ページ内の該当箇所のスコアを合算し、閾値と比較する。
- 閾値以上ならブロック、未満なら許可。
実務上は次の例外や補正が使われます。
- コンテキスト判定やネガティブルール（許可リスト）による例外。
- 同一単語の複数出現を許す設定（専門的・教育的コンテンツ向け）。
- 正規表現やフレーズ一致による精度向上。
対象となる主要フィルター製品と特徴
- Dansguardian（主にLinuxで広く利用）: テキスト解析と重み付けスコア方式を採用。プロキシと組み合わせて動作。
- SafeSquid（Linux/Windows）: GUI/WEB設定が可能で、キーワードフィルターを有効にして閾値やテンプレートを調整する。
- POESIA / We-Blocker / 各種ペアレンタルコントロール: 製品ごとにルールセットやUIが異なるが、基本は同様の重み付け方式。
各製品の違いは次のとおりです。
- 管理インターフェース（CLI vs GUI）
- ルールの柔軟性（正規表現、ホワイトリスト、カテゴリー）
- プロキシの結合方法（透過型/明示型）
- HTTPSトラフィックの扱い（SNI、TLS中間者）
Block Thatで安全にフィルタをテストする理由
成人向けコンテンツ等を直接開かずに、フィルターの有効性だけを検査できる無料ウェブアプリが Block That（http://www.yourfilter.org）です。テストはページ上で擬似的に“検出語”を読み取り、カウントダウン後にON/OFFで表示するため、モニター上に不快な実コンテンツが表示されません。
テストの流れ（概略）:
- http://www.yourfilter.org にアクセス
- トップの自動チェックが動作（カウントダウン表示）
- 結果がON（ブロックできる）またはOFF（保護されていない）で表示
- 結果後、必ず「Retest（再テスト）」を実行し、ブラウザのキャッシュとクッキーを消去して再確認
キャプション: Block That のテスト開始時に表示されるカウントダウン円盤と説明領域
SafeSquidでのキーワードフィルター有効化手順（概略）
- ブラウザで http://safesquid.cfg/config を開く
- “Select a Section to Configure”（設定するセクションを選択）パネルを見つける
- ドロップダウンから “Keyword filter” を選択し Submit をクリック
- Keyword filter セクションで Enabled をオンにし、デフォルト閾値（100）を適宜調整。著者は 50 を使用。
- テンプレート下の Submit ボタンを押して保存（上部の Submit ではなく、Template ボックス下の Submit を押す点に注意）
設定後、十分なルール（キーワード／フレーズ）を用意しておくことが重要です。ルール数が少ないとスコアが不足し、検出精度が落ちます。
注: 環境によっては GUI の文言が異なるため、設定画面内の類似ラベルを探してください。
Dansguardian の稼働確認（Linux）
Dansguardian を使っている場合はサービスが起動しているか確認します。ユーザー権限に応じて次のいずれかのコマンドを実行してください。
service dansguardian status
sudo service dansguardian status
su -c 'service dansguardian status'これらのコマンドはサービスの状態（起動済み、停止、エラー）を返します。エラーが出る場合はログ（例: /var/log/dansguardian/）を確認してください。
公式ドキュメント参照: http://contentfilter.futuragts.com/wiki/doku.php?id=Main%20Index&DokuWiki=wdievqxsxe
ブラウザでキャッシュとクッキーを消す手順（主要ブラウザ）
重要: ブラウザのキャッシュやクッキーが残っているとテストが誤った結果を返すことがあります。下記の手順に従って確実に消去してください。バージョンやプラットフォームで画面が異なる場合があります。
Google Chrome
- ウィンドウ右上のメニュー（縦三点またはレンチアイコン）をクリック
- [ツール] → [閲覧履歴を消去] を選ぶ
- 「キャッシュされた画像とファイル」と「Cookieと他のサイトデータ」にチェックを入れる
- 時間範囲のドロップダウンで「全期間」を選択し、データを消去
Mozilla Firefox
- メニューから [ツール] → [最近の履歴を消去] を選択
- 「Cookie」と「キャッシュ」にチェックし、時間範囲で「すべて」を選択
- [今すぐ消去] をクリック
Internet Explorer
- メニューの [ツール] → [インターネット オプション] を開く
- [全般] タブの [閲覧の履歴] セクションで [削除] をクリック
- 「一時ファイル」と「Cookie」にチェックし、[削除] を実行
- 同じ [閲覧の履歴] 内の [設定] を開き、「Web ページを表示するたびに」オプションを選択して OK
Opera（Windows）
- メニュー → [設定] → [プライベート データの消去] を選択
- 「一時的なクッキー」「すべてのクッキー」「キャッシュ全体」「Persistent Storage」をチェックして削除
Opera（Linux）
- [ツール] → [プライベートデータを削除] → [詳細オプション] を選択
- 「一時的なクッキー」「すべてのクッキー」「キャッシュ全体」をチェックして削除
Safari（macOS）
- ウィンドウ右上付近のメニューから [環境設定] を開く
- [詳細] タブ → [設定を変更]（場合によりメニュー項目名が異なる）
- Internet Explorer と同様に履歴・キャッシュ・Cookie を削除
注意: ブラウザのバージョンや拡張機能によって操作が異なる場合があります。最新のUIに合わせた手順を事前に確認してください。
キャプション: Google Chrome の閲覧データ消去画面の一例
テスト実行の詳細な手順（推奨SOP）
管理者・保護者向けの手順書（SOP）を用意しておくと何度も安定したテストが行えます。
SOP: フィルタ検証プレイブック
- 対象クライアントでブラウザを起動し、http://www.yourfilter.org を開く。
- 初回テストを実行し、結果を記録（ON/OFF、画面ショット推奨）。
- 指示に従い [Retest] を押す前にブラウザのキャッシュとクッキーを完全に消去。
- ブラウザを再起動してから再テストを実行し、結果を記録。
- 再テストで OFF が出たら直ちに下記トラブルシュートチェックリストへ移行。
- テストが成功（ON）したら、同一ネットワーク上のランダムな5台で確認して運用を正式に承認。
トラブルシュートチェックリスト（優先度順）
- フィルターサービスが稼働しているか（Dansguardian: service status）
- プロキシのIPとポートがクライアントのブラウザ設定と一致しているか
- SafeSquidなどでキーワードフィルターが有効になっているか
- 閾値（threshold）が適切か（テスト環境では50程度から試す）
- ルール数が十分か、特にテストに使われるキーワードが辞書に存在するか
- HTTPSサイトを検査するためのTLS中間者設定があるか（なければ見逃しの原因）
- クライアントにプロキシのバイパス設定（WPADや静的例外）がないか
- ネットワーク機器（フォワーディングプロキシ、L7デバイス）が通信を遮断していないか
- ブラウザの拡張機能が通信やキャッシュ挙動に影響を与えていないか
HTTPS とキーワードフィルターの限界
現代のウェブは多くが HTTPS で配信されるため単純なキーワードスキャンは機能しません。対策は次のいずれかです。
- TLS中間者（プロキシによる証明書差し替え／インスペクション）を導入して平文解読した上でフィルタリングする（導入時はプライバシーと法的要件に注意）。
- SNI（Server Name Indication）やTLS拡張情報に基づくドメインブロックを併用する。
- クライアント側に安全なブラウザ管理（ポリシー／エンドポイント制御）を導入する。
重要: TLS中間者は通信の機密性と整合性に影響を与えるため、組織のポリシーや法規制（GDPR 等）に照らして運用を設計してください。
管理者向け決定ツリー（Mermaid）
flowchart TD
A[テスト結果: OFF?] -->|はい| B{プロキシ設定は正しいか}
B -- いいえ --> C[クライアントのプロキシ設定を修正]
B -- はい --> D{サービスは稼働しているか}
D -- いいえ --> E[サービスを再起動してログ確認]
D -- はい --> F{HTTPS検査は可能か}
F -- いいえ --> G[HTTPS検査を検討またはSNIブロックの導入]
F -- はい --> H[ルールと閾値を調整して再テスト]この決定ツリーは一般的な診断フローです。実際の環境ではネットワークトポロジーや運用手順に合わせて拡張してください。
役割別チェックリスト
管理者
- フィルタサービスの起動状況確認
- プロキシIP/ポート、ファイアウォールルール確認
- ログの確認と解析
- ルールセットと閾値の管理
ITサポート
- ユーザからの報告を受け、SOPに従い再テスト実施
- クライアント環境の確認（プロキシ設定、拡張機能）
- 必要なら遠隔でログを取得
保護者／教員
- Block That でテストを実行し、結果を記録
- 2回テストを行い、結果をスクリーンショットで保存
- 問題があれば管理者に連絡
受け入れ基準（Критерии приёмки）
- Block That の再テストで全テスト端末が ON を示すこと。
- テストを行ったすべての端末でブラウザを再起動してもONが維持されること。
- HTTPS経由の既知の試験ケースがミティゲート済みであるか、ドメイン単位のブロッキングが有効であること。
- 管理者がログにおけるブロックイベントを確認できること。
インシデント対応とロールバック手順
- 再テストで OFF が継続する場合、ただちに影響範囲の評価を行う（ユーザー数、該当端末）。
- 緊急度に応じてプロキシやフィルター設定を一時的にロールバックするが、ロールバックは慎重に記録を残す。
- 修正後、影響端末で再テストを実行し、結果を記録。
- 恒久対策としてルール追加、閾値調整、TLS検査の計画を作成。
代替アプローチと長期的対策
- カテゴリベースのフィルタリング: 単語ではなくサイトカテゴリー（ポルノ、ギャンブルなど）で制御する。偽陽性を低減しやすい。
- コンテンツ評価サービスの導入: マシンラーニングやコンテキスト解析を使うサービスで誤検知を減らす。
- エンドポイントコントロール: クラウドベースの管理ポリシーでブラウザを制限する。
- ユーザー教育: 若年ユーザーに対する利用ルールとリスク教育を実施する。
セキュリティとプライバシー上の注意
- TLS中間者を導入する場合は利用者の同意や組織の法的根拠を確立する。
- ログの保存期間とアクセス制御を定め、機密性を維持する。
- 個人データをスキャン・保存する場合は、プライバシー法（例: GDPR）を確認し、必要な同意やデータ保護対策を実施する。
テスト時のよくある失敗例（反例）
- テストを1回だけ行い、キャッシュの影響を見落とす。
- フィルター未起動のままテストを行い、誤った安心感を得る。
- HTTPSトラフィック非対応のままHTTPSサイトのブロックを期待する。
- ブラウザ拡張やVPNサービスがプロキシ設定をバイパスしているのを見落とす。
短い配布向けアナウンス（100–200語）
組織・家庭向け: 当社ではウェブコンテンツの安全確保のため、キーワードベースのフィルターが正しく動作しているかを簡単に検査する手順を公開しました。安全な検査にはBlock That（http://www.yourfilter.org）を2回実行し、必ずブラウザのキャッシュとクッキーを消去してから再テストしてください。管理者はプロキシ設定、サービス稼働、ルール数、HTTPS検査の有無を確認してください。問題が発見された場合は、添付のトラブルシュートチェックリストに従ってください。
互換性と移行のヒント
- 古いプロキシや透過プロキシは最新のTLS仕様に対応していない場合がある。機器のファームウェアを最新に保つ。
- クラウドプロキシへ移行する場合、SSLインスペクションの扱いがプロバイダーにより異なるため事前確認を行う。
- クライアント側のOSアップデートでプロキシ自動検出（WPAD）や設定が変わる可能性がある。
追加のリソース
- SafeSquid 設定参考: https://www.howtoforge.com/blocking-webpages-based-on-keywords-or-phrases-with-safesquid-proxy
- Dansguardian 注意書き: https://www.howtoforge.com/never-forget-to-turn-dansguardian-back-on-after-a-cyberspacejaywalk
- Dansguardian ドキュメント: http://contentfilter.futuragts.com/wiki/doku.php?id=Main%20Index&DokuWiki=wdievqxsxe
キャプション: SafeSquid の設定画面で “Keyword filter” を選んだ例
キャプション: テストが失敗している（OFF）場合の表示例
キャプション: フィルターが正しく動作している場合のテスト表示
キャプション: Internet Explorer の閲覧履歴削除ダイアログの例
キャプション: Opera（Windows）でプライベートデータを削除する画面
キャプション: Opera（Linux）で詳細オプションを表示した例
キャプション: Safari の設定画面の一例
キャプション: Block That のランディングページにある白黒のショートカットアイコン
まとめ
キーワードフィルターの検証は慎重に行う必要があります。Block That のような安全な検査ツールを用い、必ず2回テストを行い、キャッシュとクッキーを消去してから再テストしてください。管理者はサービス稼働、プロキシ設定、ルール数、HTTPS検査対応の有無を確認し、取得したログを元に閾値とルールを調整します。最終的にはカテゴリベースのフィルタやマシンラーニングベースのサービス、エンドポイント制御の組み合わせで運用の堅牢性を高めることを推奨します。
重要: Block That を複数のタブやウィンドウで同時にテストしないでください。また、http://www.yourfilter.org をホワイトリストやブラックリストに登録しないよう注意してください。
追加の情報は Block That の “Disclaimer” と “Doc” リンクをご参照ください。
