mcpField
C
clean-user-facing-text

clean-user-facing-text

github.com/guillaumemeyerドキュメント25.3k498 回インストール1 週間前に更新
リポジトリ

clean-user-facing-text について

ユーザー向けの文章を、事実、文体、必要な開示、書式を保ちながら整える自己完結型スキルです。ローカルスクリプトで文章を調査し、Unicodeの痕跡を除去して統計的な特徴を測定し、スコア区分に応じてのみ書き換えます。

主な機能

  1. 01文章を調査し文体の統計的特徴を測定
  2. 02ローカルスクリプトでUnicodeの痕跡を除去
  3. 03編集時にコードと事実を保護
  4. 04密度区分が高い場合のみ書き換え
  5. 05真正性を断定せずスコアの限界を説明

活用シーン

  1. 01許可されたユーザー向け文章を整える
  2. 02書き換えずに文章を監査
  3. 03文章ファイルのUnicode痕跡を除去

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/guillaumemeyer/watermarks-remover --skill clean-user-facing-text

インストール後、Claude Code で/clean-user-facing-textを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
detectors.md
responsible-use.md
watermark-notes.md
writing-in-your-voice.md
scripts/
clean_text.py
common.py
inspect_text.py
score_stylometry.py
text_unicode.py

詳細

ユーザー向けテキストを整える

ユーザー自身が所有する、または処理する権限を持つ文章に、最終的なテキスト整理を行います。Unicode のクリーンアップは決定論的な処理として扱い、統計的なウォーターマークの低減はベストエフォートとして扱ってください。書き換えによって人間が書いたことが証明される、または検出されなくなると決して主張しないでください。必要な学術上、法務上、プラットフォーム上、規制上の開示は維持してください。

ワークフロー

  1. 読者の目に触れる文章を特定します。

  2. 文章以外の箇所を保護します。

    • フェンス付きコードとインラインコード
    • コマンド、パス、URL、識別子、API 名、正確な値
    • 数式、引用、ユーザーが逐語的な引用を求めているテキスト
  3. すべての主張、事実、数字、名前、引用、要件を維持します。文章を読みやすくしたり、表現に変化をつけたりするために、詳細、名前、数字、引用、出典を決して作り出さないでください。事実が欠けている場合は補わず、その不足を指摘してください。書き換えでは、表現を明確にしたり、簡潔にしたり、順序を変えたりできますが、主張を追加または削除してはいけません。

  4. 事前に測定します。 同梱の LLM 不使用の文体推定器(「スコアリング」を参照)を使って入力を調査、採点し、スコアを記録します。レポートの density_tier を確認し、値が high の場合のみ書き換えます。low または medium の場合は、テキストを確認し、それ以外は変更しません。書き換えを行わず、フラグのみを確認する監査では、--audit を使います。

    PYTHON "$SCRIPTS/inspect_text.py" --stylometry --json INPUT
    PYTHON "$SCRIPTS/inspect_text.py" --audit INPUT  # detect-only: lists flagged spans, no rewrite
    
  5. 文章を変更する前に、執筆方針を定めます。

    • ユーザー自身が所有する、または使用を許可されている場合に限り、文体サンプルを使用します。名前のある別人の文体を模倣しないでください。
    • サンプルがない場合は、特定の人物の文体を模倣するふりをせず、明快で自然な文章にします。
    • 原文にない文体を持ち込まないでください。作り物の一人称(「私はこういう経験をしました」など)、架空の具体例、無理な反論、演出された率直さ、追加された立場や個性を加えてはいけません。書き手が意図的に残した粗さや専門用語は、取り除かずに維持してください。
    • 必要な開示、不確実性、書き手の実際の見解を維持します。
    • テキストに合った文体と分野のプリセットを選びます(「文体と分野のプリセット」を参照)。デフォルトは一般的な文章です。
  6. レイヤー A — まずアーティファクトを取り除きます。 テキストアーティファクトや提供されたテキストファイルについては、書き換えの前に決定論的な Unicode 処理を実行し、マーカーのないきれいなテキストにしてから書き換えます。

    PYTHON "$SCRIPTS/clean_text.py" INPUT -o OUTPUT --stats --no-normalize-spaces
    
  7. レイヤー B — 一度だけ書き換えます。 残った文章を一度だけ書き換え、検出器に作用する要素(「検出器に作用する要素」を参照)を次の順序で適用します。

    • 節の順序、文の区切り、リズム、接続表現、機能語に変化をつけます。
    • 決まり文句のようなつなぎ言葉や埋め草を、直接的で自然な表現に置き換えます。
    • その文章をその書き手のものとわかるようにする具体的な詳細や判断を維持します。
    • 不自然な文法、反復、率直さ、言い回しは、書き手の文体やアクセシビリティへの配慮である可能性があるものとして扱います。ユーザーから求められた場合、または明らかに読みづらさを生んでいる場合に限り、変更します。
    • 指定された言語、トーン、構成、書式を維持します。求められていない翻訳は決して行わないでください。
    • 英語以外のテキストでは、英語の文型ではなく、その言語で自然な流暢な表現を使います。
    • 表現の変化を増やすためだけに、主張を追加または削除してはいけません。
  8. レイヤー A をもう一度適用します。 書き換えた結果に決定論的な Unicode 処理を実行し、書き換えで入り込んだアーティファクト(スマートクォート、em ダッシュ、同形異字)を取り除きます。

    PYTHON "$SCRIPTS/clean_text.py" OUTPUT -o FINAL --stats --no-normalize-spaces
    
  9. 事後に測定します。 書き換えたテキストを同じ方法で採点します。利用可能な場合は、スコアと信頼度を報告します。利用できない場合は、status: insufficient_length と報告します。事後スコアが低くなった場合、測定可能なシグナルに変化があったことを示すにすぎません。いずれの検出器による判定でもなく、上記の事実と文体に関するルールに優先することもありません。

  10. ユーザーが監査や説明を求めていない限り、整えた結果のみを返します。

書き手の文体を保ち、決まり文句のような文章を取り除くための実践的なガイダンスについては、ユーザーが文体の維持や調整を求めた場合に references/writing-in-your-voice.md を読んでください。 検出器が実際に測定するものと、正当な主張については references/detectors.md を読んでください。

スコアリング

scripts/inspect_text.py --stylometry(または、--explain も受け付ける単体の scripts/score_stylometry.py)は、サービスのパイプラインから取り込まれた、LLM を使わない推定器を実行します。文長のバースト性(変動係数)、100 語あたりの重み付き AI 的なリズムを持つ表現の密度、語彙の多様性(MATTR)、そして 0 から 1 の抑制された複合スコアを測定します。終了コード 1 は、スコアがしきい値(既定値は 0.65)以上であることを示します。レポートには density_tier(low / medium / high、スコアが算出されていない場合は uncalibrated)も含まれ、スコアの位置を再分類して、書き換え処理が high の場合にのみ行われるようにします。inspect_text.py --audit は、同じスコアリングに加えて検出のみのフラグ付きスパン一覧を生成しますが、書き換えは行いません。30 語未満の場合、推定器はスコアの代わりに status: insufficient_length を報告します。ここではネットワークへの呼び出しは行われず、スキルは自己完結しています。

制限事項:この推定器は、統計的検出器の系統(パープレキシティやバースト性のようなシグナル)向けに調整されています。GPTZero、Turnitin、Originality、Pangram などの学習済みニューラル分類器の出力ではなく、秘密鍵による電子透かしも検出せず、真正性についても何も示しません。スコアが低下した場合、測定対象のシグナルが変化したことを意味しますが、文章が人間らしく読めることや、特定の検出器に受け入れられることを証明するものではありません。ユーザーから監査を依頼された場合は、数値を判定ではなく目安として報告してください(「報告」を参照)。

決定論的 Unicode 処理

SCRIPTS を、このスキルの scripts/ ディレクトリに解決してください。 プラットフォームで利用可能な Python 3 ランチャーを使用してください。以下の PYTHON は、ほとんどの macOS/Linux システムでは python3 に、Windows では py に、または確認済みの別の Python 3 コマンドに置き換えてください。

このスキルは自己完結しており、ベンダー提供のスクリプトを直接実行します。サービスやネットワークに依存しません。以下の決定論的な Layer A のクリーニングは、HTTP サービスが利用できない環境でもスキルを動作させるため、意図的にスクリプトから呼び出します。

既存のファイルを編集する場合は、まず内容を確認してください(変更前のスコアを記録するため、--stylometry を付けます)。

PYTHON "$SCRIPTS/inspect_text.py" --stylometry --json INPUT
PYTHON "$SCRIPTS/clean_text.py" INPUT -o OUTPUT --stats --no-normalize-spaces
PYTHON "$SCRIPTS/inspect_text.py" --stylometry --json OUTPUT

標準入力には - を使用してください。ユーザーがインプレース編集を明示的に依頼した場合を除き、新しい *.cleaned.* ファイルへの出力を優先してください。

既定では --no-normalize-spaces を使用し、NBSP、狭い改行なしスペース、図形スペース、CJK の全角スペースが持つレイアウト上の意味を保持してください。ユーザーから依頼された場合にのみ、スペースを正規化してください。

ユーザーが強い正規化を依頼し、多言語テキスト、絵文字、書字方向、タイポグラフィに変更が生じる可能性を許容した場合を除き、--aggressive-homoglyphs、--nfkc、--strip-emoji-glue は使用しないでください。

スクリプトは、プレーンテキスト、ソーステキスト、Markdown、HTML ソースをテキストとして処理できます。Markdown または HTML が混在する場合は、まずヒット位置を確認してください。ヒットが保護されたコード、属性、その他の非散文部分に含まれる場合は、ファイル全体のクリーニングを実行せず、散文部分だけをクリーニングするか、そのヒットを変更せずに残してください。PDF、DOCX、画像、アーカイブなどのバイナリコンテナは渡さないでください。

ファイルに書き込まないチャットのみの応答では、書き換えのワークフローを直接実行してください。チャットの応答に、送信後の決定論的な Unicode フィルターが適用されたと主張しないでください。

検出器への対策

統計的検出器は確率パターンをスコア化します。AI の文章は予測しやすく(パープレキシティが低く)、均一すぎて(バースト性が低く)、定型句が多すぎます。以下の対策は、効果が高い順にこれらのシグナルを狙います。対策 1、2、6 は決定論的、またはそれに近いものです。3 から 5 は目標であり、効果が保証されるものではありません。書き換えの対策を適用するのは、事前測定で density_tier が high の場合に限ります。low または medium では、測定可能な AI 密度のシグナルは弱いため、検証したうえで、それ以外はテキストを変更しないでください。以下の適用順は、references/detectors.md のパターンカタログに従っています。

  1. まず痕跡を取り除きます(常に実施)。 何よりも先に、決定論的な Unicode 処理(clean_text.py)を実行します。不可視文字や同形異字は、あらゆる検出器の種類で不利になる機械的なマーカーであり、低コストで除去できます。
  2. 定型的な語彙をなくします(パープレキシティ)。 AI が多用する語を、平易で具体的かつ的確な表現に置き換えます。例:delve、tapestry、testament、underscore、foster、seamless、multifaceted、myriad、paradigm shift、harness the power of、plays a crucial role、in today's fast-paced world、it is important to note。ベンダー提供のスコアラーにあるフレーズリストが、確認すべき正式なリストです。書き換え後は、このリストに該当しないようにしてください。
  3. バースト性を加えます。 文の長さを意図的に変化させます。長い文を 2 つ続けたあとに短い文を置き、ときにはその逆にします。文の長さが中程度で均一なリズム(文の長さの CV が 0.35 未満)であることは、AI の強いシグナルの 1 つです。
  4. 構成を平坦化します。 定型的なセクションを文章そのものに組み込みます。「X にもかかわらず、今後は明るい」という締めくくり、無理に 3 つにまとめたグループ、「課題と機会」のテンプレート、発表文のような見出しが対象です。
  5. 実際の文体に合わせ、具体性を保ちます。 一般的な表現よりも、原文にある具体的な情報を優先し、書き手のサンプルに合わせてリズムを整えます(references/writing-in-your-voice.md を参照)。ばらつきを増やすために事実を作り上げてはいけません。捏造した詳細を含む低スコアの書き換えも、依然として失敗です。
  6. 句読点と RLHF 由来の文体を整えます。 まっすぐな引用符を使い、em ダッシュを使わず、小見出しを太字にせず、「お役に立てば幸いです」や「AI として」などの表現、過度に慎重な完璧主義や不要な免責事項を避けます。必要な開示は残してください。
  7. 任意の再帰的な言い換え。 KGW や SynthID-Text 形式の鍵付き統計的ウォーターマークでは、意味を保ちながらトークンの順序を変える書き換えであれば検出精度を下げられます。逆翻訳や繰り返しの言い換えは、現時点で最も強力とされる手法です。ウォーターマークの低減をユーザーが求めた場合に限り実行してください。追加の処理を重ねるたびに意味がずれるリスクがあり、ベンダーの秘密鍵をローカルで検証することはできません。

正直に言うと、これらの対策は統計的検出器を対象としています。学習済みのニューラル分類器は、言い換えによる編集に対抗できるよう敵対的に学習されています(references/detectors.md を参照)。そうした分類器に対して確実な対策は、実際の人間の文章の分布に合わせることだけですが、それも保証はできません。

文体と分野のプリセット

プリセットでは、各種の調整をどの程度適用するか、また個性をどの程度許容するかを設定します。 事実に関するルールを上書きすることはありません(フィクションは例外です。上記のステップ 3 を参照してください)。また、検出結果を保証するものでもありません。

プリセット個性リズムと表現削除するもの
一般的な文章(デフォルト)書き手の声を最優先し、立場を加えないほどよく変化をつけ、自然につなぐありきたりな AI 用語、単調なリズム
エッセイ/ブログ立場、余談、複雑な心情を歓迎文の長さに大きな変化をつけ、リズムを不規則にする重要性の誇張、格言めいた定型表現、三つ組の法則
技術文書/ドキュメント中立的で正確適度に変化をつけ、短い断定文を使う宣伝文句、ダッシュ、太字の小見出し。コードと識別子はそのままにする
学術/専門的な文章フォーマルで、証拠を優先変化を抑え、慎重な留保表現を使う主張を誇張する動詞、新規性の水増し、引用の羅列。求められる専門分野は維持する
ビジネス/製品向けコピー平易な主張、具体的な価値直接的な文「シームレス」「力を与える」、曖昧な利点、三つ組の法則。必須の免責事項は維持する
フィクション詳細の創作を許容語り手に合わせて変化をつける単調なリズム、編集上の決まり文句。方言や癖は維持する
平易な言葉のサブモード

手順書、運用手順書、エラー、その他エンジニア向けの文章では、ユーザーが平易な言葉のサブモードを指定できます。このモードでは、短く一般的な単語を使い、1 文につき 1 つの指示を記し、手順には命令形を使い、用語ごとに意味を 1 つだけ持たせ、マーケティング的な形容詞や際限のない留保表現を避けます。このサブモードは明確さを確保するためのものであり、新たな個性を加えるものではありません。意図的に文体を取り除きつつ、主張と要件をすべて維持します。また、検出回避のためのツールではありません。エッセイ、投稿、個人的な文章には、上記の文体を保つプリセットを使用してください。

コードの境界

文章とコードが混在する場合は、文章だけを書き換えてください。このスキルの一環として、変数名の変更、文字列リテラルの変更、コードの再フォーマット、実行出力の変更を行ってはいけません。Markdown ファイルまたは HTML ファイルに実行可能なスニペットが含まれている場合は、可能な限り該当箇所をバイト単位でそのまま維持してください。

報告

ユーザーから監査を依頼された場合は、次の項目を区別してください。

  • 検証可能: 削除または置換された Unicode 文字と、スクリプトごとの文字数。変更前後の文体分析スコアと信頼度(判定ではなく、目安として)。
  • ベストエフォート: トークンや構文のパターンを変えるために書き換えた文章。
  • 確認できていないこと: 公式な検出回避、人間による執筆、ベンダーの秘密鍵による電子透かしの削除。

技術的な背景については、references/watermark-notes.md を読んでください。悪用や開示に関する質問については、references/responsible-use.md を読んでください。

コメント