solo-humanize

/humanize

ユーザー向けテキストから、AIらしい文章のパターンを取り除きます。ファイルまたは貼り付けたテキストを、意味や構成を損なわず、人が書いたような文章に書き直します。

これが必要な理由

LLM の出力には、特徴的な癖があります。多用されるダッシュ、定型句、誇張した宣伝文句、わざとらしい自然さなどです。読者（そして Google）には気づかれます。このスキルは、そうしたパターンを見つけて書き直します。

使用するタイミング

• /content-gen、/landing-gen、/video-promo の後に、出力を整えるとき
• ユーザー向けの文章（ブログ記事、ランディングページ、メール）を公開する前
• CLAUDE.md や、人が読むドキュメントを編集するとき
• 単独で使用するとき：/humanize path/to/file.md

入力

• ファイルパスを $ARGUMENTS から取得し、ファイルを読み込んで上書きします
• 引数なしの場合はテキストの貼り付けを求め、整えたバージョンを出力します
• .md、.txt、および .tsx／.html 内のテキストコンテンツ（文字列リテラルのみ）に対応しています

パターンカタログ

1. ダッシュ（—）の多用

最もわかりやすい AI らしさの兆候です。カンマ、ピリオド、コロンに置き換えるか、文の構造を変えます。

変更前	変更後
"このツールは—無料ですが—とてもよく動きます"	"このツールは（無料ですが）とてもよく動きます"
"3つの特長—速度、安全性、シンプルさ"	"3つの特長：速度、安全性、シンプルさ"
"私たちはこれを作り、それがすべてを変えました"	"私たちはこれを作りました。それがすべてを変えました。"

ルール： 500語につきダッシュは最大1つです。0が理想です。

2. 定型句

「AI が書いた」と思わせる表現です。削除するか、具体的な表現に置き換えます。

冗長な表現（そのまま削除）：

• "注目に値するのは" → （事実だけを述べる）
• "結局のところ" → （削除）
• "今日の世界では"／"現代の状況では" → （削除）
• "前置きはこれくらいにして" → （削除）
• "さっそく見ていきましょう"／"詳しく見ていきましょう" → （削除）

宣伝文句の誇張（具体的な表現に置き換える）：

• "画期的" → 具体的に何が変わったのか？
• "革新的" → 実際に何が新しいのか？
• "最先端" → 技術について説明する
• "シームレス" → "設定なしで動作する"（または、実際の動作を表す表現）
• "活用する" → "使う"
• "堅牢" → "X 個のエッジケースに対応する"（具体的に）
• "効率化する" → "手順を N 個から M 個に減らす"
• "力を与える" → ユーザーに何ができるようになるのか？
• "可能性を広げる" → 実際にどんな機能が使えるのか？

わざとらしい自然さ（書き直す）：

• "正直に言うと" → （これを言う必要があるなら、それ以外は正直ではなかったのでしょうか？）
• "率直に言わせてもらうと" → （率直に言う）
• "言っておかなければならないのは" → （そのまま述べる）
• "正直なところ" → （削除）
• "本当のところ" → （削除して、事実をそのまま述べる）

3. 3つ並べる表現

AI は「速く、安全で、スケーラブル」のような3つ並べる表現を好みます。人が書く文章では、リストの長さに変化をつけます。

変更前	変更後
"速く、安全で、スケーラブル"	"速く、安全"（スケーラブルであると証明されていない場合）
"構築し、デプロイし、反復する"	"構築してリリースする"（意図がそれなら）
すべて同じことを述べる3つの箇条書き	要点をまとめた1つの箇条書き

ルール： 1つの文書に3つ以上の3項リストがある場合、少なくとも半分は崩します。

4. 構成のパターン

すべてのセクションが同じ形： AI は「見出し → 1文の導入 → 3つの箇条書き → つなぎの文」という構成で書きがちです。人が書く文章では、セクションの長さや構成に変化をつけます。

曖昧な表現で挟む構成： 「X には制約がありますが、Y を提供し、それによって Z になります。」→ どちらかを選び、明確に述べます。

見せかけの両論併記： 「一方では X、他方では Y」→ どちらかが明らかに優れているなら、そのように述べます。

5. へつらう書き出し

• "いい質問ですね！" → （削除）
• "それは素晴らしいアイデアです！" → （削除するか、具体的にどこが良いのかを述べる）
• "もちろんです！" → （本当に賛成しているのでなければ削除）
• "喜んでお手伝いします！" → （そのまま手伝う）

6. 受け身の表現／弱い動詞

• "注目すべき点として" → （削除し、そのまま述べる）
• "いくつかの要因があります" → 要因を挙げる
• "重要です" → 重要な理由を述べる
• "これは次の方法で実現できます" → "X を実行する"

7. 修辞パターン

単語単位の修正では見逃されます。文章を短くしても残ります。300文字のメッセージにも3つ含まれることがあり、手作業で文章を削っても人間らしく聞こえるようにはならない理由はここにあります。より良い表現に書き換えるのではなく、削除してください。

パターン	修正前	修正後
二項対立	"It's not a docs problem. It's a coverage problem."	"6 questions fail because 3 devices have no docs."
否定を並べる表現	"Not a wrapper. Not a chatbot. A compiler."	"It's a compiler."
コロンで種明かし	"The catch: it needs your docs."	"It needs 3 docs nobody has written."
見せかけの洞察への導入	"The part everyone misses is distribution."	"Distribution is the moat."
前置き	"Here's the thing." / "Let me be clear."	（削除して、要点を述べる）
修辞的な導入	"What if I told you...", "Think about it:"	（削除して、主張を述べる）
-ing による見せかけの分析	"…shipped v2, highlighting their focus on speed."	"…shipped v2, which cut load time to 400ms."
重要性の誇張	"marks a pivotal moment", "a testament to"	事実を述べ、判断は読者に委ねる
メタ言説	"This matters more than it sounds."	（削除する。事実だけで伝わります）
出典を曖昧にする表現	"experts agree", "studies show"	出典を明記するか、主張を削除する
同義語の使い回し	"the agent… the assistant… the tool…"	呼び名を一つにして、繰り返し使う
深遠さを装う締めくくり	"The future isn't coming. It's already here."	削除して、最後の具体的な一文で終える
要約の繰り返し	"In conclusion…", "Overall…"	要点または次の行動で終える

汎用性テスト。 別の人物、会社、製品についても同じように読める文は、余分な記述です。この対象に固有の事実、仕組み、数値、結果に置き換えるか、削除してください。

ラベルを貼らず、具体的に示す。 要点が重要、意外、あるいは微妙だと読者に伝える解説は削除してください。文章ですでに伝わっているなら、そのラベルは不要です。

具体的な事実を守る。 詳細を一般的な重要性の表現にぼかしてはいけません。 "significantly improves productivity" → "cut review time from 30 minutes to 8."

手順

1. 入力を読む — ファイルパスまたは貼り付けられたテキストを確認します。

2. パターンを確認する — 上記の各カテゴリを確認します。カテゴリごとに違反の数を数えます。

3. 書き直す — 次の点を保ちながら、違反を一つずつ修正します。

   • 技術的な正確さ（コード、コマンド、技術用語を変更しない）
   • 構成（見出し、リスト、コードブロックを維持する）
   • トーンの意図（元の文章がくだけた調子なら、その調子を維持する）
   • 長さ（同じか短くすることを目指し、決して長くしない）

4. 変更内容を報告する：

   Humanized: {file or "pasted text"}
   
   Changes:
     Em dashes:  {N} removed
     Stock phrases: {N} replaced
     Inflation: {N} deflated
     Triplets: {N} broken
     Sycophancy: {N} cut
     Rhetorical patterns: {N} cut
     Total: {N} patterns fixed
   
   Before: {word count}
   After:  {word count}
   

5. ファイルパスの場合： 整理した内容をファイルに書き戻します。差分の概要を示します。 貼り付けられたテキストの場合： 整理した内容を直接出力します。

検出モード

「これはAIの粗雑な文章ですか？」と尋ねられた場合や、他人の下書きの監査を依頼された場合は、このスキルに該当する各パターンを挙げ、該当する行を引用し、簡潔な修正案を示します。書き直しや採点はせず、AIが書いたと断定しないでください。検出器の判定は推測にすぎませんが、パターンを具体的に挙げれば、書き手自身が確認できます。必要であれば、後から編集を申し出てください。

変更してはいけないもの

• コードブロックとインラインコード
• 技術用語、ライブラリ名、CLI コマンド
• 他者の引用（出典が明記された引用は原文のままにする）
• 数値、日付、URL
• 見出しの構成（セクションを統合したり分割したりしない）
• 内容の意味 — 言い換えだけを行い、アイデアを追加または削除しない

例外

• 短いテキスト（50語未満）： 定型表現のフィルターだけを適用し、構成の分析は省略します
• すでに問題のない文章： 「AIのパターンは見つかりませんでした。人間が書いた文章のようです。」と報告します
• コードが中心のドキュメント： コードブロックはすべて対象外とし、文章部分だけを処理します
• 英語以外のテキスト： ダッシュと構成のルール（言語を問わず適用可能）を適用し、英語の定型表現は対象外とします

クレジット

セクション7の修辞パターン分類と検出モードの仕様は、Peter Yangによるno-ai-slop（MIT）を参考にしています。