文字列に名前がなくても、配信基盤の共有は見える
今回やったこと / この記事について
原稿の禁止語チェックは、本文に特定の名前が含まれているかを調べる。しかし、本文に禁止語がなくても、読者に配信されるURLやアカウント識別子から複数の媒体が同じ運営だと分かることがある。そこで検査対象を散文から配信物へ広げ、文字列の一致ではなく、識別子空間が共有されているかを調べるゲートを作った。
禁止語の照合だけでは拾えない漏れ
従来のブランド漏洩チェックは、公開される原稿の散文に禁止トークンがないかを調べる。名前やドメインが本文に直接出るケースには有効だが、本文にその文字列がない配信URLまでは判定できない。
実際に見つかったのは、異なる媒体の記事に同じ画像配信基盤のホストとパス接頭辞が使われていたケースだった。記事を一つずつ読めば、禁止語は含まれない。ところがURLを並べると、同じ配信基盤を使っていることが読者に伝わる。さらに同じホストから別系統のサイトの画像も配信されていた。文章内の単語を探すだけでは、この関係を検出できない。
問題は、特定の文字列の見落としではなく、検査する対象と判定の粒度にあった。読者が見るのは記事本文だけでなく、画像、スクリプト、フィード、リンクの絶対URL、テンプレートやウィジェットの設定なども含む。これらに共通のホストやパスの名前空間があれば、運営の関連性を推測する手がかりになる。
配信物と識別子空間を検査する
新しいゲートは、散文ではなく読者に届くファイルを対象にする。リポジトリ内の媒体ディレクトリから、内部資料やスクリプトなど読者に届かない置き場を除外し、それ以外を走査対象にする。この向きなら、新しい配信物の置き場が加わった時に、対象リストへの追加を忘れて検査から漏らす危険を減らせる。
判定の単位も変えた。ホストとパス接頭辞から作られる「識別子空間」が複数媒体にまたがるかを確認する。画像URLのパターンが共有されているなら、そのURLに媒体名が含まれていなくても関係が見つかる。アフィリエイトタグ、計測ID、広告のパブリッシャーIDなど、読者に届くアカウント識別子も同じ考え方で扱う。
台帳には媒体ごとの露出区分と、配信ホストや名前空間を記録する。既に共有が判明している空間は、個々の検出結果をファイルごとに黙らせるのではなく、空間そのものに共有関係を記録して凍結する。その空間に未登録の媒体が加わった時はエラーにする。既知の負債を明示しながら、新しい共有の追加を止める方式である。
| 検査 | 見るもの | 判定の考え方 |
|---|---|---|
| ブランド語チェック | 原稿の散文 | 禁止トークンの有無 |
| 配信識別子チェック | URLやアカウントIDなど配信物 | 識別子空間の共有関係 |
既知の共有を見えなくしない
検出したURLを大量に抑制一覧へ入れると、次の実行では鳴らなくなる。しかし、鳴らない状態が修正済みと誤解されると、既知の共有が見えない負債に変わる。空間を台帳で凍結すれば、共有中であること自体は残る。さらに、観測した媒体数やURL数を毎回サマリに出すため、件数の増加も黙って通らない。
媒体ごとに配信先を分離する作業は、このゲートとは別に進められる。検査を作ることと、過去の共有をすべて解消することは同じ作業ではない。既存分を明示した上で新規の共有を防ぐのが、この仕組みの当面の役割だ。
導入時に見るポイント
まず、散文だけを走査する検査と、配信物を走査する検査の境界を確認する。次に、新しい媒体を追加した時に、その置き場が走査対象から抜けないかを見る。最後に、既知の共有を台帳へ登録した場合でも、未登録の媒体が同じ識別子空間に現れたらエラーになることを確認する。
単語のチェックは今も必要だが、それだけで配信上の関係を検出できるわけではない。何を読者へ届けているかを調べ、共有される識別子の空間を台帳に置く。観測対象を本文から配信物へ広げることで、名前が書かれていない関係も検査できるようになる。
更新履歴
- 2026-10-11: 初稿作成。