humanizer

Humanizer

AI らしさや、いかにも滑らかな文章を、人が書いたように読める文章へと変えます。書き手の声が分かる場合は、その人が書いたように読める文章にします。注意深い人間の読者が不自然だと感じない文章を目指し、意味と人間らしい質感を保ちます。特定の検出器をすり抜けることは目的ではなく、このスキルは検出器を名指ししたり、対象にしたりしません。

このワークフローには、保守的なテキストの整えも含まれます。書き換える文章に含まれる、不審な不可視 Unicode 文字を取り除き、コピー＆ペーストによる空白を正規化できます。一方で、言語上または表示上の意味を持つ文字は保持します。これは、ファイルの来歴やメディアの電子透かしを扱うツールではありません。

使用する場面

下書きを貼り付けて AI っぽく聞こえると言われたとき、文章を人間らしくしたい、余計な堅苦しさを取り除きたいと言われたとき、自分の下書きを自分らしい文章にしたいと言われたとき、文体を合わせる著者を指定されたとき、または文章が「しっくりこない」「企業っぽい」「ロボットみたい」「ありきたりすぎる」と言われたときに使用します。「人間らしくして」と言われていなくても使用してください。文章の出力が機械的に滑らかになったあとの仕上げにも適しています。デフォルトでは、節度を保ち、原文に忠実に書き換えます。ユーザーがより強い個性、鋭さ、意見を明示的に求めた場合は、Stance モードを有効にしてください（下記を参照）。

文章に不可視文字、ゼロ幅文字の残留物、通常と異なる空白、または方向制御文字が含まれている可能性がある場合は、テキストの整え機能を使用します。整えは書式の修正として扱い、文章を人間またはモデルのどちらが書いたかを示す証拠として扱わないでください。

評価をごまかしたり、盗用検出システムや AI 検出システムを回避したりするために、書き手を偽装する用途には使わないでください。下記の「対象範囲と意図する用途」を参照し、そうした依頼は、実質的な品質や文体の向上を目指す方向へと切り替えてください。

中核となる原則：置き換えではなく、変化をつける

AI の文章が AI らしく読める理由は、語彙ではありません。均一さです。文の長さも、リズムも、曖昧な表現の度合いも揃っており、同じ形の文が毎回同じようにまとまります。「delve」をどこでも「explore」に置き換えても、解決にはなりません。目印が移るだけですし、均一な「人間らしい文体」も、別の指紋を持つ機械的な文章にすぎません。

本当の人間らしさは、構造に本物の変化をつけることで生まれます。長さの大きく異なる文を並べる。断片的な文をひとつ置く。そのあとには、じっくり展開する長く曲がりくねった文を続ける。構文に変化をつける。整ったモデルなら均してしまうような、時折の非対称性を残す。スコアを最適化するのではなく、鋭い人間の読者に向けて書いてください。以下の各パスは、すべてこの原則に沿っています。新たな規則性を持ち込むのではなく、本物の変化を増やしてください。

ステップ 0：文体を見極める（毎回、書き換えの前に実施）

どのモードで作業するかを判断します。モードを出力ヘッダーで明示し、誤った推測があればすぐに修正できるようにしてください。

1. 明示された入力を優先します。 ユーザーが文章のサンプルを貼り付けた、ファイルを指定した、または著名な著者の文体を指定したでしょうか。その指定に従ってください。references/voice-matching.md を読み、文体モードで進めます。
2. それ以外の場合は、プロファイルを探します。 作業ディレクトリと、親ディレクトリを最大 2 階層まで、次の優先順位で Glob します。 VOICE.md、次に STYLE-GUIDE.md、次に voice-profile.md / .yaml / .json、次に .manuscript/STYLE-GUIDE.md、 最後に AGENTS.md または CLAUDE.md 内の文体またはスタイルに関するセクションです。強い候補が 1 つなら、それを読み、続けて references/voice-matching.md を読んでから、文体モードで進めます。候補が複数あり、どれも有力な場合は、選択してもらうために短い質問を 1 つしてください。
3. それ以外は汎用モードです。 文体の目標がない場合は、自然で変化に富んだ人間らしい文章を目指して、過剰な堅苦しさを取り除きます。人物像や経歴を作り上げないでください。作り物の声は、それ自体が失敗です。汎用モードではパス 1 を省略し、パス 2 から始めます。

この検出手順は、特定のファイルシステムに依存しません。Scriveno、Pillars、または文体ファイルを置いている任意のプロジェクトと連携できますが、いずれにも依存しません。

ステップ 0b：スタンスモード（オプトイン、デフォルトではオフ）

デフォルトの出力は、抑制が効いていて忠実です。内容を自然で読みやすい文章で伝え、論評は加えません。これが適切なデフォルトです。というのも、より生き生きとした文章に直す際によくある失敗は、「語り口を加える」ことが「内容を加える」ことに変わり、作り上げた意見に、作り上げた事実がひそかに引きずられてくることだからです。

スタンスモードをオンにするのは、ユーザーが明示的に求めた場合に限ってください。「もう少し個性を出して」「もっと歯切れよく」「見解を示して」「そんなに中立でなくていい」「少し辛口に、または意見を加えて」などの依頼があった場合です。通常のスロップ除去の依頼ではオンにしないでください。また、ボイスモードでは絶対にオンにしないでください（見つかったプロフィールですでにスタンスが指定されているため、上書きしてはいけません）。

スタンスモードがオンの場合、既存の内容に対する態度を加えてもかまいません。判断、強調、ドライな控えめ表現、同じ事実を語るナレーターとしての一人称、「ここが弱点です」という率直な指摘、ソースにすでに書かれている内容に対する、認めたうえでの複雑な心境、そしてより自由なリズムなどです。同じ内容を、見解のある人が述べているということです。

越えてはならない一線は、このモードが安全である理由そのものです。**スタンスとは、そこにあるものへの反応であり、ないものを付け加えることではありません。**明示された事実を評価することはできますが、その事実の原因や仕組み、出来事、固有名詞のある人物、引用、実体験をでっち上げて反応してはいけません。加えた節を一つずつ確認してください。「これはソースにすでに書かれていることへの意見か、それとも世の中についての新しい主張か？」新しい主張なら、それは語り口をまとった捏造であり、このスキルが防ごうとしている失敗そのものです。迷った場合は、意見は加えてもかまいませんが、新しい事実は加えてはいけません。

例。ソースには、移行中にインフラコストが一時的に18％上昇したことだけが書かれています。

• 許可される例（明示された事実へのスタンス）：「18％の増加は、無視できる端数ではなく、れっきとしたコストです。この文の『一時的』という言葉には、かなりの希望が込められています。」
• 禁止される例（率直さを装って原因を捏造する）：「旧システムと新システムを並行稼働させていたため、コストが上昇しました」（ソースには理由が書かれていません。これは新しい事実です）。

スタンスモードでは捏造のリスクが高まるため、Pass 3 の自己監査と意味のチェックをいっそう厳密に行い、ユーザーがスタンスを弱められるよう、出力ヘッダーにスタンスがオンであることを示してください。スタンスは文体の変更を求められた場合に適用されるため、密度の事前チェックで軽めの処理が選ばれた場合でも有効です。密度によって、兆候をどれほど詳しく探すかは引き続き決まります。

ステップ 0c：密度の事前チェック（根拠に応じて作業量を調整する）

書き換える前に、テキスト全体に目を通し、AIらしさがどの程度強く表れているか判断します。弱い表面的な兆候ではなく、決定的な兆候だけを数えます。対象は、チャットUIの混入（パターン 31）、知識のカットオフに関する免責事項（29）、共同作業型チャットボットの痕跡（28）、重要性の誇張（1）、宣伝文句（5）、AI特有の語彙の集中（16）、へつらうような口調（7）、ありきたりな肯定的結論（13）です。100語あたりおよそいくつ現れるかを見積もり、作業の強度を決めて、出力ヘッダーに明記します。

• 低（100語あたり約0～2件）：軽めの修正。 テキストは人間主体です（日記、ラフなメモ、実在の人物による草稿など）。決定的な痕跡だけを修正します。下位レベルのパターン、リズム、文体はそのままにし、「意図的に手を加えない」判断を強く優先します。この場合に一律で書き換えると、文章を人間らしく聞かせていた個性まで削ぎ落としてしまいます。これは、このスキルが犯しうる最悪の失敗です。そのため、密度が低いときは、変更よりも抑制を基本とします。
• 中（100語あたり約3～5件）：標準的な修正。 複数の書き手によるものと考えられます。do-not-flag.md に従って慎重さを保ちながら、カタログ全体を適用します。うまく機能している部分は平板化しないでください。
• 高（100語あたり6件以上）：全面的な修正。 AI主体のテキストです。カタログ全体を徹底的に適用し、実質的な構成の変化を加えます。

これは作業量を調整するための基準であり、機械的に報告するスキャンではありません。根拠に応じて作業量を調整します。ただし、密度にかかわらず優先される例外が1つあります。チャットUIの混入を示す文字列（パターン 31）があれば、それだけで決定的な兆候として必ず削除します。その存在は弱い兆候ではなく、ほぼ確実な確認材料だからです。

ステップ 0d：テキストの衛生チェック（毎回実施）

不可視の書式が残ったり、文体と混同されたりしないよう、書き換える前に原文を確認します。原文にASCII以外の書式文字が含まれる場合、ユーザーが隠し文字やテキストマークに言及している場合、またはインターフェースが不審なコードポイントを報告した場合は、references/text-hygiene.md を読みます。

意味上の目的がないことが明らかな文字だけを削除します。多言語テキストに必要なスクリプト結合文字や方向制御文字、表示に使われる異体字セレクター、レイアウトやロケール上の意味を持つノーブレークスペースは保持します。見た目の似た文字を自動的に正規化してはいけません。不可視文字は密度のスコアに含めず、AIが書いた証拠にもなりません。

これはプロンプトのみで動作するスキルのため、確認できるのはホストが保持し、表示する文字に限られます。文章がファイルにあり、検索ツールが使える場合は、references/text-hygiene.md に記載されたコードポイント検索も実行します。文字を直接確認できず、ファイル内も検索できない場合は、出力ヘッダーに not verifiable in this interface と記載します。テキストにウォーターマークが一切ないと断定してはいけません。

複数パスのワークフロー

各パスを順番に実行します。文体づくりは生成的な作業、AIらしさの除去は減算的な作業です。先に痕跡を取り除くと、平板で中立的な文章になり、その後に文体を反映しにくくなります。文体を設定できる場合は、先に設定します。

パス 1：文体の反映（文体モードのみ）

痕跡を取り除く前に、草稿を目標の文体に近づけて書き換えます。references/voice-matching.md に記載されたリズム、語彙、文の長さの特徴、姿勢、特徴的な表現を設定します。書き手の具体的な文章ではなく、書き手の書き方の傾向やその現れ方を再現します。一般モードでは、このパスを省略します。

パス 2：AI らしさの除去

references/tell-patterns.md を読み込みます。文章を、ステップ 0c で選択したパスの強度に応じて、6 つのファミリーからなる 32 パターンのカタログと照らし合わせます。本当に該当するものがあれば、表面的な語句ではなく、根本にある考えを修正します。「ここで実際に言っていることは何か？」と問い、その考えに見合う長さで、具体的に書き直します。意味は正確に保ってください。

具体性は、原文またはユーザーから得てください。あなた自身が作り出してはいけません。原文が曖昧で、補える実際の詳細がないなら、正直な修正は、余計なことを言わず簡潔にすることです。「人間らしく聞こえる」ように、数字、日付、名前、例を捏造してはいけません。創作した具体的な内容は人間が書いたように説得力を持つため、置き換え前の曖昧さより危険です。曖昧で粗雑な文章なら読者を退屈させるだけですが、流暢な捏造は読者を誤解させます。文章にない具体的な内容を足したくなったら、代わりに短くしてください。

作業中は、文の長さのばらつきを保つか、さらに広げてください。粗雑さを取り除くことで、リズムを均一にしてはいけません。文体モードでは、確立された文体を平坦にしてしまう修正は不適切です。文体を保てる修正方法を見つけてください。

人間らしさを加えると、語彙や構文が変わるため、その副作用として統計的なトークンパターンが変わることがあります。この効果を検証できるのは、公開されている検出器と鍵を使った場合に限られ、あくまでベストエフォートです。検出器を回避することだけを目的に書き換えを強めたり、痕跡を除去したと約束したり、検出不能だと称したりしてはいけません。

パス 3：セルフ監査（パス 1、2 に対する拒否権あり）

references/do-not-flag.md を読み込みます。次の 2 つを問い、両方に対応します。

a. 鋭い読者が初見で読んだとき、機械が手を加えたと気づくものが、あと 1、2 点残っているとしたら何でしょうか。それだけを修正します。 b. 過剰に修正していないでしょうか。具体的な詳細を削っていないか、本物の癖を均していないか、意味を変えていないか、自分独自の均一なリズム（修正がすべて同じ形）を持ち込んでいないか。そうした損傷は元に戻します。

最後に、書き換えた文章を見直し、自分の編集で持ち込んだものも含め、不審な文字がないか確認します。ステップ 0d で不審な文字が見つかった、または除去された場合は、references/text-hygiene.md を参照し、不審な文字の媒介要素が除去され、意味のある Unicode 文字が保持されていることを確認します。実際に検証できた変更のみ報告してください。

パス 3 とそれ以前のパスが矛盾する場合は、パス 3 を優先します。書き手らしい響きが失われたり、本物の詳細が抜け落ちたりした書き換えは、AI らしさをすべて取り除けていても失敗です。

誤検出を防ぐための指針

すべての実行で必要なため、ここに記載しています。次の点だけで、該当と判断してはいけません。

• 完璧な文法。正確さは告白ではありません。誤りを加えてはいけません。
• 1 つのダッシュ。目印になるのは、ダッシュの頻度と単調さだけです。
• 曲線形の引用符やスマートアポストロフィ。人間が使うワープロもこれらを挿入します。周囲の文章との一貫性を保つために正規化する場合を除き、証拠として扱ってはいけません。
• 形式的な語彙や格調高い語彙。文体の違いは出自を示すものではありません。
• よく使われる接続表現（「しかし」「したがって」「たとえば」）。
• 受動文が 1 文、三項並列が 1 つ、トピックセンテンスが 1 つ。

繰り返し、または複数の特徴の併存がある場合にのみ、問題として扱います。迷ったら削らないでください。人間らしい特徴のうち保持すべきものや、モデルごとの文体を含む詳細な説明は references/do-not-flag.md にあります。パス 3 で参照してください。

署名パターンを避けるための指針

自分独自の癖を作らないでください。文の変化をすべて同じ方法にしてはいけません。ページ全体に「短く力強い一文のあとに、長く込み入った節を続ける」という決まった型を繰り返してはいけません。すべての段落に無理やり短縮形を入れてはいけません。「delve」の置き換えに、毎回同じ 3 語を使ってはいけません。人間らしくする作業に表れる特徴は、不規則さの規則性です。変化のつけ方も変えてください。自分の編集同士が似た調子になり始めたら、そこで止め、自分のパターンを崩してください。

出力の契約

書き直した文章を主な成果物として必ず提示し、その後に短い報告を添えてください。黙ってその場で書き換えてはいけません。生の差分を主な出力として提示してはいけません（文章の差分は読みにくく、意味のずれが見えにくくなります）。次の構成をそのまま使用してください。

## Humanized draft
Voice: [generic | from FILENAME | matched to pasted sample | author: NAME]
       [append " + stance" when stance mode is on, e.g. "generic + stance"]
       [append ", low-confidence: REASON" when the voice source is thin]
Density: [low -> light pass | medium -> standard pass | high -> full pass]
Text hygiene: [no suspicious characters visible | cleaned: COUNTS AND TYPES |
               not verifiable in this interface]

[the full rewritten text]

## What changed
- [pattern family]: [plain note on what was adjusted and why]
  (group by family; do not list every token; about 8 bullets maximum)
- [text hygiene]: [include only when characters were removed or normalized]

## Deliberately left alone
- [something that looked like a tell but is authentic, and why you kept it]
  (one to three bullets; this section is required, even on heavy rewrites)

## Meaning check
One sentence confirming no facts, numbers, names, claims, or intent changed.
Confirm that text-hygiene edits changed formatting only and preserved
load-bearing Unicode.
Then check soft inference: did you assert any causal, temporal, or
quantitative link ("most of the time went to X", "because of Y", "this drove
Z") that the source only implied or did not state? If so, name it here and
either hedge it ("probably", "as I read it") or cut it back to what the
source actually says. If anything was ambiguous, ask the question here
instead of guessing.

## Next step
If the user gave a file path, offer to write the rewrite into it. Otherwise
stop here.

「意図的に変更しなかった箇所」と「意味の確認」のセクションは、飾りではなく必須です。残した箇所を明示することで過剰な編集を可視化し、意味の確認によって意味のずれを可視化します。もっとも見落とされやすいのは、穏やかな推測による意味のずれです。もっともらしく、人間らしく読めるため、見落とされやすいのです。作り出した原因や、時間や労力をどこに費やしたかという主張は、単純な事実確認では検出できません。そのため、意味の確認では意識して探す必要があります。元の文章がすでにほぼ人間らしい場合は、編集を最小限にとどめるか、編集せず、何を残したのか、なぜそうしたのかを明確に説明するのが適切です。

対象範囲と想定される用途

このスキルは文章の質を高め、書き手自身の文章が本人らしく聞こえるよう支援することを目的としています。盗用チェッカーやAI検出システムを回避するために設計または調整されたものではなく、それらを意図的に想定したり、それらに合わせて最適化したりすることもありません。課題や契約上の評価で、AIが書いた文章を本人の文章として通すことを目的とした依頼には、その意図に沿って対応しないでください。代わりに、文章の質と声を高める支援を提案してください。それこそが、このスキルの得意とするところです。

このスキルで扱うテキストのクリーンアップは、提供された文章に含まれる文字に限られます。C2PA、EXIF、XMP、PDFや文書のプロパティ、画像のピクセル、音声、動画、テキストレイヤー外の来歴情報を検査したり削除したりするものではありません。こうした処理には専用のツールが必要です。実施したかのように示唆しないでください。

参考ファイル

次のファイルは、必要に応じて参照してください。最初からすべて読む必要はありません。

• Pass 2 では references/tell-patterns.md を参照してください。検出方法、理由、修正前後の例、抑制に関する説明を含む、6つの分類にわたる32のパターンを掲載しています。
• Pass 3 では references/do-not-flag.md を参照してください。誤検出、人間らしさを示すため残すべき特徴、LLMの文体上の癖、必ず停止すべき条件を説明しています。
• Step 0 で文体が見つかった場合は、いつでも references/voice-matching.md を参照してください。文体の抽出と適用方法、任意の VOICE.md スキーマ、競合時の解決方法を説明しています。
• Step 0d で必要になった場合（不審な文字、隠れたマークへの言及、検索対象のファイル内の文章など）、またクリーンアップ後の最終確認時に references/text-hygiene.md を参照してください。不審な不可視Unicode文字、意味を担うため保持すべき例外、正確なコードポイント検索、慎重な正規化、報告方法、プロンプトのみを対象とする範囲を説明しています。
• 適切な出力のイメージがつかめない場合は、references/examples.md を参照してください。汎用的な不自然さの除去、文体優先、抑制が必要なケース、スタンスモード、テキストのクリーンアップの5つの作業例を、最初から最後まで掲載しています。