テキスト透かしを消す?「WatermarkRemover」

【更新履歴】

 ・2026/8/12 バージョン1.0公開。
 ・2026/8/12 バージョン1.1公開。(まとめて出力を追加)
 ・2026/8/12 バージョン1.2公開。(処理を選べるようにした)
 ・2026/8/12 バージョン1.3公開。(ソースコードに対応)
 ・2026/8/12 バージョン1.4公開。(スコアテスト、差分判定を追加)
 ・2026/8/15 バージョン1.5公開。(一文ずつ言い換えを追加)


メイン画面
AI設定
基本設定(自然言語)
基本設定(ソースコード)
フォルダ一括変換
一文ずつ言い換える
差分ビューア
透かしスコアチェッカー

・ダウンロードされる方はこちら。↓




・昨今、AIによる生成コンテンツには、
 目に見えない「テキスト透かし
 (トークン出現確率の統計的偏りなど)」が
 埋め込まれるようになりつつあります。

・本ツールは、
 AIが生成したテキストの「意味」だけを抽出し、
 言語の壁を越えた再構築を行うことで、
 これらの統計的特徴や
 AI特有の言い回しをリセットします。

✨ 主な特長


強力な3段階パラフレーズ・パイプライン

・「①英語への直訳」
 ➔「②英語での要約・構造書き換え」
 ➔「③日本語への再翻訳」という3ステップを自動実行。

・単語の選択パターンや文法構造を根本から破壊し、
 透かしの検出を極めて困難にします。

完全オフラインのセキュア環境に対応

llama.cppOllama を用いたローカルLLMでの
 完全オフライン実行を標準サポート。

・機密性の高いテキストや、
 外部に送信したくないデータでも
 安全に処理できます。

「フォルダ一括処理」

・指定したフォルダ内の全テキストファイルを読み込み、
 まとめて透かし無効化処理を実行します。

・独自のアルゴリズムにより、
 数千ファイルの深い階層でも
 スタックオーバーフローを起こさず、
 安定して連続処理を行います。


《セットアップ手順》


・ローカルLLMを使用する場合は、こちらを参照。↓

・低スペックGPU環境では、オススメはこの軽量モデルです。↓

llama.cppを使用される方は、
 setup_llama_cpp.batをダブルクリックして下さい。

 そして、設定画面で、実行ファイルへのパスを入力して下さい。


📖 操作説明書

1.初期設定(AIモデルの準備)


・本ツールを使用するには、設定画面を開いて、
 使用するAIモデルの設定を行っておく必要があります。

  1. 画面上部のメニューから [設定] ➔ [システム設定] をクリックします。

  2. [AIプロバイダ] のドロップダウンから、使用する環境を選択します。

    • クラウドAPI: APIキー、モデル名、エンドポイントURLを入力します。

    • ローカル (llama.cpp): 実行ファイル(llama-server.exe)、モデルファイル(.gguf)のパスなどを指定します。

    • ローカル (Ollama): モデル名(例: llama3.2)を入力します。

  3. (ローカル環境の場合)設定画面内の [サーバーを起動] ボタンを押して、サーバーを立ち上げます。

  4. [接続テスト] ボタンを押し、「✓ 接続できました」と表示されることを確認します。

  5. 設定画面を閉じます。(入力内容は自動的に保存されます)

2. 単体テキストの処理

1つの文章の透かしを解除する基本操作です。

  1. 画面上部の 「透かし解除対象テキスト」 欄に、AIが生成した元の文章を貼り付けます。

  2. 画面右下の [出力する] ボタンをクリックします。

  3. 画面左下に進行状況(Step 1/3 など)が表示されます。処理が完了するまでお待ちください。

  4. 完了すると、下部の 「出力結果」 欄に書き換えられたテキストが表示されます。

  5. [結果をコピー] ボタンをクリックすると、クリップボードにテキストがコピーされます。

3. フォルダ一括処理

フォルダ内のすべてのテキストファイルをまとめて処理する機能です。

  1. 画面右下の [まとめて出力] ボタンをクリックします。

  2. フォルダ選択ダイアログが表示されるので、処理したいテキストファイルが入っているフォルダを選択して「OK」を押します。

  3. 自動的にファイルの読み込みとAI処理が開始されます。(処理中のファイル名は画面左下に表示されます)

  4. 処理が完了すると完了メッセージが表示されます。

  5. 出力先: 選択したフォルダ内に自動で WR_Output というフォルダが作成され、元のフォルダ構造を維持したまま、処理済みのテキストファイルが保存されます。 (※空のファイルや、テキストとして読み込めないファイルはエラー回避のためそのままコピー・スキップされます)

4. 処理のキャンセル


・処理中に [キャンセル] ボタンを押すと、
 現在の処理を安全に中断できます。

・一括処理中にキャンセルした場合、
 そこまで処理が完了したファイルは
 WR_Output フォルダに残ります。

⚠️ 注意事項


・ローカルLLM(llama.cpp / Ollama)を使用する場合は、
 PCのスペック(特にメモリおよびVRAM)に依存して
 処理時間が変動します。

・長文や複雑なテキストを処理する際には、
 APIの応答に時間がかかる場合があります。

・頻繁にエラーになる場合は、
 システム設定から「APIタイムアウト(分)」の
 数値を増やしてください。


《 Anthropic Claudeのテキスト透かしに対する効果 》


❌ ほぼ無効な機能(不可視文字除去、ホモグリフ正規化、Unicode正規化、記号の平易化、強制フォーマット)

・これらは「文字を仕込む/入れ替える」タイプの透かし
 (ステガノグラフィ的な透かし)を対象にした機能です。

・しかし今回の仕組みは
 文字を一切追加・変更しません。

・単語そのものの「選ばれ方」に
 統計的な偏りを与えるだけなので、
 除去すべき余分な文字が
 最初から存在しません。

・これらの機能は
 今回の透かしに対しては原理的に的外れ
です。

△〜◯ 条件付きで有効な機能
 (LLMによる言い換え・翻訳→パラフレーズ→再翻訳)

・これが唯一、理論的に意味を持つ対抗手段です。

・理由は、透かしは「トークンの選ばれ方」に宿っているため、
 十分な量の単語を実際に別モデルの手で選び直させる
 
ことでしか壊せないからです。

・ただし、これが有効になるかどうかは
 どのモデルで言い換えるかに完全に依存します。

有効なケース:

・ローカルのllama.cpp/Ollamaモデルや
 Anthropic以外のクラウドAPIで言い換えさせた場合。

 別モデルのサンプリングは
 元の秘密鍵と無関係なので、
 新しく生成された単語列には
 元の透かしのシグネチャは乗りません。

逆効果になりうるケース:

・このツールの「クラウドAPI」の接続先を
 (仮に)Anthropic自身のClaude APIに向けていた場合。

・翻訳のように全文を作り直す処理は、
 透かしが全体にしっかり乗ると記事にある通り、
 Claudeに再翻訳させると、元の透かしを消すどころか、
 新しいClaudeの透かしを全文に上書きしてしまう
ことになります。

・これはご指摘の記事
 「翻訳だけは全文をClaudeが選ぶので
 透かしが全体にかかる」という説明と整合します。

△ 中途半端になりやすい機能(軽い校正・高速クリーン)

・高速クリーン(LLM非使用)は
 単語そのものには一切触れないため、
 透かしは無傷のまま残ります。

・また、LLMでも「軽く整える」程度の処理は、
 校正・翻訳・要約・ファイル変換などを経ても
 Claudeの痕跡が残りうると
 Anthropic自身が認めている通り、
 大半の単語を温存する処理ほど
 透かしが生き残りやすくなります。

ご指摘の記事
 「校正も大半の単語が
 そのまま残るから検出が難しくなる」
 という表現は、
 「消える」ではなく
 「検出しづらくなる(弱まるが残存しうる)」
 というニュアンスで捉えるのが正確です。

現実的な結論


・そもそも対象になるのは、
 2026年8月2日以降にリリースされた
 Claudeモデルが生成したテキストだけ
です。

・他社モデルや、それ以前のClaude、
 あるいはこのツール自体が生成した文章には
 関係ありません。

・コード生成については
 構文上の制約で
 トークン選択の自由度(エントロピー)が低く、
 透かしが乗りにくい、
 あるいはほぼ乗らないとみられており、
 このツールのコード関連機能
 (AST再構築・強制フォーマット・コンパイル&逆コンパイル)は、
 もともとこの種の透かしと
 ほぼ無関係な領域を扱っていることになります。

・最も効果が見込めるのは、
 Anthropic系ではない別モデルで、
 単語を大きく作り替えるレベルの言い換え
 
(3段階処理や全面リファクタリング相当)です。

・Anthropicのエンジニア自身も
 「完璧ではなく、編集すれば透かしは消せるが、
 それは第一歩に過ぎない」と認めています。

・ただし、検出用のAPIは
 2026年8月12日に「提供予定」と発表されたのみで、
 価格や提供条件は未公表のままです。

・つまり現時点では、
 このツールの処理が実際に
 統計的シグネチャをどの程度弱められているかを、
 外部から客観的に検証する手段自体が
 まだ存在しません。

・効果を数値で保証することはできないという点は
 正直にお伝えしておきます。

実務上の助言:

・この種の透かしを念頭に置くなら、
 AI設定でクラウドAPIをAnthropic以外
 (あるいはローカルLLM)に向けた上で、
 「高速クリーン」ではなく
 2段階/3段階のLLM処理
 (特に元の単語をできるだけ残さない
 全面書き換え寄りのモード)を使うのが、
 現状わかっている情報の範囲では
 最も筋が通っています。



いいなと思ったら応援しよう!