Humanizer Skill: Claude Code向け blader/humanizer 完全ガイド

「AIテキストの人間味付け（humanizing AI text）」に関する記事の多くは、検知ツールを欺くことを謳ったパラフレーズツールのSEO目的のコンテンツです。しかし、この記事は違います。 blader/humanizer は、ボランティアが実際にAIによる低品質なコンテンツ（AI slop）を修正するために使用しているWikipediaのガイドを基にした、小規模なオープンソーススキルです。サードパーティのサービスを一切介さず、Claude CodeまたはOpenCode内で動作します。ここでは、このツールが実際に何を行い、何ができないのか、そしてAI特有の書き方の癖について29のルールから何を学べるのかを解説します。

1. 一言で言うと何か

blader/humanizer は、MITライセンスで提供されるClaude CodeおよびOpenCode用スキルであり、Wikipediaの Signs of AI writing ガイドにあるAI生成テキストのパターン29種を検出し、オプションのボイスキャリブレーション工程と組み込みのセカンドパス監査を経てリライトを行います。

リポジトリの全容はこれだけです。ファイルは SKILL.md 1つのみ。バイナリも、モデルも、APIもありません。エージェントのランタイムが実際の処理を行い、リポジトリはルールブックとして機能します。

2. なぜ存在するのか

Wikipediaの編集者は問題を抱えています。2022年後半以降、同じ特徴を持つドラフトや編集が繰り返し投稿されるようになりました。以下のような単語が、 testament、 landscape、 tapestry、そして vibrant といった単語が、以前は必要なかった記事の中に現れるようになりました。文章は「not just X, but Y」という構文に頼るようになり、見出しはTitle-Case（各単語の頭文字を大文字にする形式）になり、リストには絵文字が使われるようになりました。 WikiProject AI Cleanup 大量に生成されるテキストに対処するために形成されたもので、その成果物の一つが Wikipedia: AIによる執筆の兆候 ガイドです。これは、大規模言語モデル（LLM）が頻繁に行うものの、人間はめったに行わない特徴を根気強く網羅したカタログです。

bladerはこのカタログをスキルへと昇華させました。そのコンセプトはシンプルです。テキストを貼り付けると、AI特有の「AI臭さ」が消えたテキストが返ってきます。リポジトリは一読できるほど小規模で、ルールも明確であるため、それぞれのルールに対して議論を交わすことも可能です。このオープンさこそが、価値の半分を占めています。

ここには、より静かな動機も存在します。編集者やライターは、単なる検知ツールを求めているわけではありません。彼らが求めているのは、自分自身の文章をより洗練された形で取り戻すことです。この「ヒューマナイザー（人間味付与）」スキルは、GPTZeroを回避する手段としてよりも、コピーエディット（校正）のプロセスとして非常に有用です。READMEには検知ツールを欺くといった約束は書かれておらず、SKILL.mdもAIによる執筆が一様に悪いとは主張していません。ただ、機械的だと感じさせる特定のパターンを指摘しているに過ぎません。

3. メンタルモデル：5つのバケット

The 29 patterns split cleanly into five buckets. If you remember the buckets, you can spot the type of problem before you spot the specific rule.

5つの分類は、大まかに以下に対応しています。 テキストが何を主張しているか、 その主張をどのように表現しているか、 その主張を視覚的にどのように提示しているか、 チャットインターフェースの残滓、そして 本質的な意味をなさない余分な言葉。AIが生成したような段落の多くは、これら5つのうち2つから3つに該当します。

4. 最小限のエンドツーエンドの例

AIが生成した生の文章を人間らしい出力へと変換する最短ルートを、実際のセッションの流れに沿って紹介します。

入力したテキスト：

/humanizer

AI-assisted coding serves as an enduring testament to the transformative
potential of large language models, marking a pivotal moment in the
evolution of software development. In today's rapidly evolving
technological landscape, these groundbreaking tools are reshaping how
engineers ideate, iterate, and deliver, underscoring their vital role
in modern workflows.

エージェントが返したドラフトの書き換え案：

AI coding assistants speed up some tasks. They are good at boilerplate:
config files, test scaffolding, repetitive refactors. They are bad at
knowing when they are wrong. The productivity claims are mixed.

以下の文章が「いかにもAI生成」だと感じさせる要因は何でしょうか？

- Rhythm is still slightly too even.
- "The productivity claims are mixed" is a hedge with no specifics.
- No first-person voice yet, no opinion.

2回目のパスを経た最終的な書き換え案：

AI coding assistants can speed up the boring parts of the job. Not
architecture. Not the parts where you actually have to think.

They are great at boilerplate, especially the glue code you don't want
to write yourself. They are also great at sounding right while being
wrong, which is the part that scares me. I have accepted suggestions
that compiled, passed lint, and still missed the point because I stopped
paying attention.

If you have tests, this is fine. If you don't, you are mostly judging
vibes.

モデルの切り替えや外部APIを使用せず、2回のパスで完結します。ルールが処理を担い、エージェントが編集者と自己監査役の両方を務めます。

5. インストール

このスキルは1つのMarkdownファイルで構成されています。コンパイル手順や依存関係ツリーは一切ありません。ディレクトリが存在すれば、どちらのツールも即座に認識します。

Claude Code：

mkdir -p ~/.claude/skills
git clone https://github.com/blader/humanizer.git ~/.claude/skills/humanizer

OpenCode：

mkdir -p ~/.config/opencode/skills
git clone https://github.com/blader/humanizer.git ~/.config/opencode/skills/humanizer

OpenCodeも ~/.claude/skills/を読み込むため、Claudeディレクトリに一度クローンするだけで両方に対応可能です。インストール後、エージェントのセッションを再起動し、以下を実行してください。 /humanizer。フロントマターのトリガーはファイル名ではなく、description文字列です。このスキルは humanizer 2.5.1として登録されます。

クローンしたくない場合は、 SKILL.md を humanizer という名前のフォルダ（skillsディレクトリ内）に配置するだけでも機能します。このファイル自体が契約のすべてです。

その他のAntigravityスタックのツールでも、同様の規約が適用されます。環境をゼロから構築する場合は、以下を参照してください。 Antigravity Skills Setup Guide （スキルの仕組み全般について解説しています）

6. コンテンツパターン (1–6)

コンテンツパターンは、一度見つけ方を覚えれば最も特定しやすいものです。これらは文章の「響き」ではなく「何を主張しているか」に関するものです。そのほとんどが、元の資料では正当化できないほど重要性を誇張しています。

パターン1：重要性の誇張

注意すべき言葉： stands as、 serves as、 is a testament、 is a reminder、 pivotal moment、 evolving landscape、 indelible mark、 deeply rooted、 ～の土台を築く、 転換点を示す。

動作内容: 任意の事象が、より広範なトレンドをどのように体現しているか、あるいは寄与しているかという主張を追加します。Wikipediaの編集者は、主題に対して誇張が著しく不釣り合いなマイナーなトピックにおいて、こうした記述に気づくことがあります。

修正前: カタルーニャ統計局は1989年に正式に設立され、スペインにおける地域統計の発展において極めて重要な瞬間を刻みました。

修正後: カタルーニャ統計局は、スペインの国家統計局から独立して地域統計を収集・公開するために1989年に設立されました。

パターン2: 特筆性の名前の羅列（ネームドロッピング）

注意すべき言葉: 独立した報道、メディア媒体のリスト、 アクティブなソーシャルメディアでの存在感、 第一人者による執筆。

動作内容: 主題を引用しているメディアの長いリストなどを並べ、読者に特筆性を強く印象付けようとします。修正するには、リストを削除し、具体的な引用や調査結果を一つだけ提示するようにします。

修正前: 彼女の見解は、The New York Times、BBC、Financial Times、The Hinduで引用されています。

修正後: 2024年のThe New York Timesのインタビューで、彼女はAI規制が手法ではなく成果に焦点を当てるべきだと主張しました。

パターン3: 表層的な -ing 分析

注意すべき単語: highlighting、 underscoring、 emphasizing、 ensuring、 reflecting、 symbolizing、 contributing to、 促進する、 包括する、 紹介する。

機能： 文末に現在分詞句を付け足すことで、深みがあるように見せかける。この分詞は、根拠やメカニズムを明示することなく、重要性があるかのような印象を与える。

修正前： その寺院の青、緑、金のカラーパレットは、テキサスのブルーボネット、メキシコ湾、そして多様なテキサスの風景を象徴し、この地域の自然の美しさと共鳴している。

修正後： その寺院は青、緑、金の色を使用している。建築家によると、これらは地元のブルーボネットとメキシコ湾岸を参考にして選ばれたという。

パターン4：宣伝的な表現

注意すべき言葉： ～を誇る、 活気に満ちた、 豊かな （比喩的）、 深遠な、 佇む、 ～の中心部に、 息をのむような、 必見の、 見事な、 名高い、 ～への取り組み。

機能： このモデルは、「文化遺産」と記述されたものすべてに対して、観光パンフレットのような表現をデフォルトで使用します。Wikipediaの地理に関する記事が、この現象が見られる典型的な例です。

修正前： エチオピアのゴンダールという息をのむような地域に佇むアラマタ・ラヤ・コボは、豊かな文化遺産と見事な自然の美しさを誇る活気ある町です。

修正後： アラマタ・ラヤ・コボはエチオピアのゴンダー地方にある町で、毎週開かれる市場と18世紀の教会で知られています。

パターン5：曖昧な帰属と責任逃れの言葉（weasel words）

注意すべき言葉： 業界レポート、 観測筋は～と指摘している、 専門家は～と主張する、 一部の批評家は～と主張する、 複数の情報源 （情報源が3つ未満の場合）

何が問題か： 意見を曖昧な権威に帰属させることで、裏付け調査を行わずに根拠があるかのように見せかけています。修正するには、実体のない権威を、実在する具体的な名称に置き換えます。

修正前： 専門家は、それが地域の生態系において重要な役割を果たしていると考えています。

修正後： 中国科学院による2019年の調査によると、ハオライ川（Haolai River）は複数の固有魚種を支えています。

パターン 6: 定型的な「課題と今後の展望」

注意すべき言葉: Despite its... faces several, Despite these challenges, Challenges and, Future Outlook.

特徴: 人為的な緊張感（課題）と人為的な解決策（繁栄し続ける）で段落を締めくくります。このパターンは、AIが生成した伝記や地理に関する記事のほぼ指紋のようなものです。

修正前: Despite its industrial prosperity, Korattur faces

修正後: 2015年に3つの新しいITパークが開業して以来、交通渋滞が悪化しました。市当局は、繰り返される洪水を解決するため、2022年に雨水排水プロジェクトを開始しました。

7. 言語パターン (7–13)

言語パターンとは、言葉の選択や文の構成に関するものです。これらは、明白な誇張表現を取り除いた後も残るパターンであり、2回目の監査で最も頻繁に指摘される箇所でもあります。

パターン 7: AIによる多用語

AIが頻繁に使用する単語: actually（実際）、additionally（さらに）、align with（〜と整合する）、crucial（極めて重要な）、delve（掘り下げる）、emphasizing（強調する）、enduring（永続的な）、enhance（強化する）、fostering（促進する）、garner（集める）、highlight（動詞：強調する）、interplay（相互作用）、intricate / intricacies（複雑な／複雑さ）、key（形容詞：重要な）、landscape（抽象名詞：状況、環境）、pivotal（中枢の）、showcase（披露する）、tapestry（織りなすもの）、testament（証拠、証し）、underscore（動詞：強調する）、valuable（価値のある）、vibrant（活気に満ちた）。

機能： これらの単語は2023年以降のテキストで頻繁に使用され、まとまって出現する傾向があります。一つ含まれている文には、他の単語も含まれていることがほとんどです。これらを平易な表現に置き換えることが、AI生成テキストを人間らしい文章にするための最も手っ取り早い方法です。

パターン8：コピュラ（繋辞）の回避

例： ～として機能する、 ～である（～として位置する）、 ～を示す、 ～を代表する、 ～を特徴とする、 ～を誇る、 ～を提供する。

機能： 退屈な形式の動詞を、より洗練された動詞に置き換えます。 to be および to have。このスキルは、可能な限りシンプルな繋辞（copula）の使用を優先します。 Gallery 825はLAAA'sの展示スペースです を凌駕します Gallery 825は、見せかけの形式張った表現を除き、あらゆる指標においてLAAA'sの展示スペースとしての役割を果たしています。 。

パターン9：否定の並列と文末の否定

例： Not only X but Y、 It's not just A, it's B、および文末に付加される以下のような断片的な否定表現 no guessing や no wasted motion 。

機能： この構成は、具体的な主張を避けており、修辞的な響きが強くなっています。否定表現を削除し、要点を直接述べるように修正してください。 重厚なビートが、攻撃的なトーンを強めています。 ビート 単なるビートの問題ではありません。それは攻撃性と雰囲気の一部です。。

パターン10：3の法則の過剰使用

動作： アイデアを無理やり3つのグループにまとめようとします。ソース資料が裏付けていれば2つや4つの例でも十分ですが、モデルはデフォルトで3つに丸めようとします。 イベントには講演やパネルディスカッションが含まれます。また、カジュアルなネットワーキングの時間もあります。 ビート このイベントでは、基調講演、パネルディスカッション、ネットワーキングの機会が用意されています。。

パターン11：類義語の循環（エレガント・バリエーション）

動作： 多くのLLMの学習データに含まれる「繰り返しペナルティ」により、同じ単語を使った方が自然な場合でも、モデルは類義語に置き換えようとします。 主人公は多くの試練に直面します。メインキャラクターは障害を乗り越えなければなりません。中心人物はやがて勝利を収めます。ヒーローは帰還します。 は、ほぼ常に1つの文にまとめることができ、 protagonist を繰り返すことができます。

パターン12：誤った範囲指定

動作の仕組み： 使用例： XからYまで XとYが意味のあるスケール上にない場合。 ビッグバンからダークマターまで は、範囲を設けているだけの無関係なトピックです。修正するには、トピックを直接列挙します。

パターン13：受動態および主語のない断片

動作の仕組み： 以下のような行で実行者（アクター）を省略します： 設定ファイルは不要 または 結果は自動的に保存されます。このスキルは、能動態に書き換えることで文章がより明確になる場合に、これらを書き換えます。 設定ファイルは不要です は、以下よりも優れています： 設定ファイルは不要 （実行者が実際の人間である場合）。

8. スタイルパターン (14–19, 26–29)

スタイルパターンは視覚的なものです。これらはregexで最も検出しやすく、機械的に適用すると過剰になりやすいものです。そのほとんどは単体では間違いではありません。過剰に使用されることが問題なのです。

パターン14：ダッシュ（—）の過剰使用

モデルがダッシュ（—）を多用するのは、セールスライティングでそれが「パンチが効いている」と教え込まれているからです。ほとんどのダッシュは、意味を変えることなくカンマ、ピリオド、または括弧に置き換え可能です。このスキルセットでは、よりすっきりとした句読点使いを推奨します。

パターン15：太字の多用

すべての文で重要な用語を太字にすると、強調の効果が薄れてしまいます。すべてが太字であれば、結局どこも強調されていないのと同じです。解決策として、本文中での太字の使用は控えめにするか、あるいは全く使用しないようにしてください。

パターン16：インラインヘッダー形式の箇条書き

すべての項目が太字のヘッダーとコロンで始まるリストは、記事というよりスライド資料のように見えてしまいます。項目にラベルが不可欠な場合を除き、文章形式に変換してください。

パターン17：見出しのタイトルケース

モデルは見出しの主要な単語をすべて大文字にする傾向があります。Wikipediaのハウススタイルはセンテンスケースであり、多くのニュース編集室のスタイルガイドもそれに準拠しています。 Strategic negotiations and beats Strategic Negotiations And Global Partnerships.

パターン18：絵文字

見出しや箇条書きをロケット、電球、チェックマークなどの絵文字で装飾すると、執筆された文章ではなく、チャットボットの出力のように見えてしまいます。これらは削除してください。

パターン19：カーリークォーテーション（引用符）

ChatGPTはストレートクォーテーション（" "）よりもカーリークォーテーション（“ ”）を好みます。多くのブログCMSは自動的に逆の形式へ修正するため、プレーンテキストの中にカーリークォーテーションが含まれていると、ChatGPTが生成したものであることがほぼ確実に分かってしまいます。

パターン26：ハイフンで繋がれた単語ペアの多用

例： cross-functional、 data-driven, クライアント向け, 意思決定, リアルタイム, 長期, エンドツーエンド, よく知られた, 高品質, サードパーティ.

機能： 一般的な複合修飾語のハイフンを完全に一貫したルールで処理します。人間がこれらを均一にハイフンでつなぐことは稀です。このスキルは、一般的なペアからはハイフンを除去し、技術的な複合語にのみハイフンを残します。

パターン 27：説得力のある権威の比喩

注目： 本当の問いは、 その核心において、 実際には、 真に重要なことは、 本質的に、 より深い問題は、 問題の核心は。

動作： このモデルは、ノイズを排除してより深い真実に迫るかのように装います。この決まり文句の後に続く文章は、たいていの場合、ありふれた主張を大げさに言い換えているだけです。

パターン 28：シグナリングとアナウンス

注目： さあ、始めましょう, 探求してみましょう, 詳細を分解してみましょう, 知っておくべきことは以下の通りです, 次に見ていきましょう, 早速始めましょう.

機能： 次の動作を実行する代わりに、その動作を宣言します。この文はメタ的な記述であり、コンテンツではありません。このような案内役の文は削除し、本題から書き始めてください。

パターン 29：断片化された見出し

機能： 見出しの直後に、その見出しを言い換えただけの1行の段落が続く構成です。この1行は情報を何も追加していません。このスキルでは、その1行を削除し、見出しが本来の役割を果たすようにします。

9. コミュニケーションパターン (20–22)

コミュニケーションパターンは、チャットインターフェースの名残です。誰かがモデルにドラフト作成を依頼した際、モデルがドラフトを丁寧な言葉で包み込み、その丁寧な言葉がドキュメントへのコピー＆ペーストでそのまま残ってしまったものです。これらは、このプレイブックの中で最も見つけやすく、削除しやすい項目です。

パターン 20：共同作業的なコミュニケーションの残滓

視聴： お役に立てれば幸いです。、 もちろんです！、 かしこまりました！、 おっしゃる通りです！、 ～はいかがでしょうか？、 let me know、 こちらが…です。。

修正前： フランス革命の概要は以下の通りです。お役に立てれば幸いです！特定のセクションについて詳しく知りたい場合はお知らせください。

修正後： フランス革命は、財政危機と食糧不足が広範な社会不安を招いた1789年に始まりました。

パターン 21：知識のカットオフに関する免責事項

確認： [date] 時点、 私の最終学習データ時点まで、 具体的な詳細は限られていますが、 利用可能な情報に基づくと。

内容： モデルの学習カットオフに対して主張全体を曖昧にしています。修正するには、信頼できるソースを見つけるか、曖昧な表現を削除して事実を述べてください。

パターン 22：おべっか／卑屈なトーン

注意点： 素晴らしい質問ですね！、 おっしゃる通りです！、 非常に鋭い指摘ですね。

内容： 回答の前に相手を褒めています。この褒め言葉は中身のないものです。前置きをカットし、直接回答してください。

10. フィラーと曖昧な表現 (23–25)

パターン 23: フィラーフレーズ（冗長な言い回し）

1語で済む意味を複数の単語で表現している場合、このスキルで直接置き換えます。

パターン 24: 過度なヘッジング（曖昧な表現の多用）

互いに打ち消し合う修飾語が積み重なっている状態。 It could potentially possibly be argued that the policy might have some effect 以下のように圧縮されます： このポリシーは結果に影響を与える可能性があります。

パターン 25: 一般的で前向きな結論

以下のような曖昧で楽観的な結びの言葉は、 「未来は明るい」 や 「ワクワクするような時代がやってくる」。具体的な計画や事実に置き換えるか、結びの言葉自体を削除してください。

11. ボイスキャリブレーション

AI特有のパターンを取り除くのは仕事の半分に過ぎません。もう半分は、認識可能な「声」を取り戻すことです。デフォルトのスキルボイスは直接的で少し無機質です。もしそれを あなたらしい声にしたい場合は、SKILL.mdでエージェントに対し、まずあなたの文章サンプルを読み込ませて、それに合わせるよう指示します。

サンプルの提供方法:

/humanizer

Here's a sample of my writing for voice matching:
[paste 2-3 paragraphs of your own writing]

Now humanize this text:
[paste AI text to humanize]

エージェントはサンプルから以下の6つの要素を読み取り、リライトに適用します:

• 文の長さのパターン。短くパンチの効いたもの、長く流れるようなもの、あるいはその混合。
• 言葉選びのレベル。カジュアル、学術的、またはその中間。
• 段落の書き出し。いきなり本題に入るか、まず文脈を説明するか。
• 句読点の癖。ダッシュ、括弧、セミコロンの使用など。
• 繰り返し使われるフレーズや口癖。
• 接続のスタイル。明示的な接続詞を使うか、単に次のポイントへ移るか。

SKILL.md において最も厳格なルール：ライターの語彙をアップグレードしてはならない。サンプルで stuff や thingsが使われている場合、それらを elements や componentsに置き換えてはならない。ボイスキャリブレーションはデフォルトではアップグレードではなくダウングレードである。モデルはすべてをよりフォーマルにしようとするが、このスキルはそれを抑制する。

12. 2段階監査（Two-Pass Audit）

このスキルは常に2段階のパスを実行する。最初のパスは29のルールに基づいた通常の書き換えである。2段階目のパスは、SKILL.mdで「明らかにAI生成されたものを見抜く監査」と呼んでいるものである。最初の書き換えの後、エージェントは自身に対して以下の質問を投げかける：

What makes the below so obviously AI generated?

その後、残っているAI特有の兆候を簡潔な箇条書きで挙げる。よくある例：

• リズムが均一すぎる（すべての文が同じ長さ）。
• もっともらしいが、出典のない引用や名前。
• TEDトークのように聞こえるスローガン調の締めくくり。
• 最初のパスをすり抜けた潜在的な曖昧な表現（ヘッジング）。

その後、再び自身にプロンプトを出す：

Now make it not obviously AI generated.

そしてもう一度修正を行う。2段階目のパスは短く、焦点を絞っており、驚くほど効果的である。これは、人間が書いた原稿を1時間後に読み返す編集者のテクニックと同じである。ルールはモデルに何を探すべきかを教え、2段階目のパスはモデルにもう一度確認させる役割を果たす。

13. パーソナリティと魂

SKILL.mdの中で最も主張が強いセクションは、ルールについてではありません。それは「声（ボイス）」についてです。

• すべての文が同じ長さと構造である。
• 意見がなく、中立的な報告に終始している。
• 不確実性や複雑な感情への言及がない。
• 一人称を使うべき場面で使っていない。
• ユーモアや鋭さ、個性が欠けている。
• Wikipediaの記事やプレスリリースのように読める。

文章に「声」を取り戻すためのアドバイスは、短く実践的です。

• 意見を持つこと。事実を報告するだけでなく、それに対して反応すること。
• リズムに変化をつけること。短くパンチの効いた文の後に、じっくりと読ませる長い文を続ける。
• 複雑さを認めること。 印象的だが不安をかき立てる ビート 印象的。
• 一人称を I 適宜使用すること。一人称を使うことは誠実さの表れであり、非専門的ではありません。
• 少しの乱れを許容すること。脱線や余談は人間味として伝わります。
• 感情について具体的に述べること。不安を感じさせる要素を明確に指摘すること。

SKILL.md にある対照的な例は引用する価値があります。クリーンですが魂の感じられないドラフト： その実験は興味深い結果をもたらしました。エージェントは300万行のコードを生成しました。感銘を受ける開発者もいれば、懐疑的な開発者もいました。その影響は依然として不明です。 躍動感のあるバージョン： 正直なところ、これについてどう感じるべきか分かりません。人間が眠っている間に生成された300万行のコード。開発者コミュニティの半分は驚愕し、残りの半分はなぜそれがカウントに値しないのかを説明しています。 事実は同じ。

14. 私たちが間違っていたこと

スキルを読む前に私たちが抱いていた3つの前提と、それを読んだことでどう変わったか。

前提1：これは言い換えツールになるだろう。 そうではありません。

前提2：ルールのほとんどは好みの問題であり、検知ではない。 いくつかはそうです。パターン14（ダッシュの使いすぎ）は主に好みの問題です。しかし、ルールのほとんどは統計的なものです。パターン7（AI特有の語彙）、パターン19（カーリークォート）、パターン22（お世辞のような書き出し）は、すべて2023年以降に測定可能な使用量の急増が見られます。Wikipediaのガイドはマニフェストではなく、静かな測定プロジェクトなのです。

前提3：やりすぎて技術ドキュメントを台無しにするだろう。 It can, if you let it. Pattern 13 (passive voice) and pattern 15 (boldface overuse) are actively useful in well-formatted technical writing. The skill respects bullet lists and code blocks by default, but it will rewrite headings and prose. For manuals, give it a voice sample with the formatting you want kept, or scope the rewrite to specific paragraphs.

15. 実践的なワークフロー

16. よくある間違い

• このスキルをAI検出器として扱うこと。 実際はその逆です。このスキルは、テキストがAI特有の形式であると仮定して編集を行います。人間が書いたテキストであっても、たまたま同じ単語が使われていれば書き換えが発生します。
• ボイスサンプルをスキップすること。 サンプルがない場合、出力は一般的なきれいな文章になります。あなた自身の文章を3段落提供することが、「AIっぽくない」ものと「あなたらしい」ものを分ける境界線となります。
• 一度実行しただけでリリースしてしまうこと。 2段階の監査機能が組み込まれていますが、出力結果をご自身でも読み直すことで、このスキルの精度はさらに向上します。2回目のパスでは表面的なミスを検出し、人間による読み直しでは論理レベルのミスを検出できます。
• 有効なエムダッシュ（—）が削除されてしまう。 パターン14は頻度に関するルールであり、禁止事項ではありません。もし意図的にエムダッシュを使用している場合は、エージェントにそのまま保持するよう指示してください。
• コードに対して使用する。 このスキルは散文用です。コードのコメントに対して実行すると、マーケティングコピーのように書き換えられてしまいます。テキストのみを対象範囲に指定してください。
• MITライセンスを「すべてそのまま再配布しても安全」と解釈する。スキル自体はMITライセンスです。処理されるテキストはユーザー自身のものです。ソースとなっているWikipediaガイドはCC BY-SAです。3つの異なるライセンスには、それぞれ異なる適用範囲があります。

17. パフォーマンスとコストに関する注意点

• トークン予算。 スキル自体は約4,500語の指示で構成されています。これは、すべての /humanizer呼び出しに追加される固定のオーバーヘッドです。Claude Sonnetの場合、一般的な800語のヒューマナイズ（人間味を持たせる処理）の往復では、SKILL.mdを含めると入力トークン数は約12kに達します。
• レイテンシ。 2回のパスと監査ステップがあるため、最低でも3回のモデル呼び出しが発生します。単一の書き換えリクエストと比較して、2〜4倍の実行時間がかかることを想定してください。
• ボイスサンプル。 サンプルを追加すると、貼り付けたトークン数分だけプロンプトが増加します。通常、3段落で300〜500トークン程度です。追加する価値はあります。
• バッチジョブ。 このスキルは対話型を前提として設計されています。何百もの記事をヒューマナイズしたい場合は、非対話モードでエージェントCLIを呼び出すスクリプトから実行してください。SKILL.mdはその用途に十分耐えうる決定論的な設計になっています。
• 品質の限界（プラトー）。 入力が約1,500語を超えると、モデルがすでに指摘したミスを把握しきれなくなるため、2回目の監査の有効性が低下します。長いドキュメントは分割して処理してください。

18. 対象読者

19. コミュニティのシグナル

読む価値のある3つの反応の分類。

1つ目は スター獲得の速度です。このリポジトリは公開から数ヶ月で16kスターを獲得しました。単一のMarkdownファイルとしては異例の速さです。実際のワークフローを捉えたスキルは、このように急激に伸びる傾向があります。Claude Codeエコシステムにおける最も近い例は obra/superpowersであり、これも同様の軌跡を辿りました。

2つ目は フォークパターン。1.6k件のフォークのほとんどはカスタマイズです。業界固有のルールを追加したり、CMSの制約で必要となるカーリークォート（波括弧引用符）のルールを削除したり、監査に失敗したPRを拒否するCIパイプラインにこのスキルを組み込んだりといった用途です。フォークの内容はベースのリポジトリよりも多様であり、これは健全な状態と言えます。

3つ目は スコープのプレッシャー。オープンなIssueでは、非英語言語への対応、他のツールにパイプするためのJSON専用モードの要望、技術文書向けの「元のフォーマットを保持する」フラグの提案などが寄せられています。これらはどれもスキルのバグではありません。多くの共感を得たプロジェクトにとって、次に目指すべき妥当なマイルストーンなのです。

20. 結論：使う価値はあるか？

このリポジトリは、求められる信頼のシグナルを獲得しています。ライセンスは寛容で、ソース資料は明記され、ルールは個別に議論可能であり、SKILL.mdは15分で読める短さです。このカテゴリでは稀なことです。

21. より大きな視点

ヒューマナイザー・スキルは、本質的には「人間味を与える」ことではありません。優れた編集者が行うように、モデルに自身の出力を読み解く方法を教えることです。これは単一のユースケースを超えた、より汎用的な能力です。「ここに悪い出力の統計的な兆候があり、ドラフト内でそれを検出し、修正する方法はこれだ」というスキルを書けば、それはあらゆる種類の執筆上の問題に適用できるテンプレートになります。トーンの監査、バイアスの監査、ハウススタイルの監査、ブランドボイスの維持など、ヒューマナイザーはそのプロトタイプなのです。

もう一つの側面は、スキルとは何かという概念の静かな変化です。1年前、Claude Codeのスキルは外部CLIの薄いラッパーに過ぎませんでした。しかし、ヒューマナイザーにはCLIがありません。スキル全体が、 思考方法を記した1つのMarkdownファイルで構成されています。これはツール統合というよりもシステムプロンプトに近い、異なるモードです。次にくる有用なスキルの波は、これと同じようなものになるでしょう。つまり、短く、独自の意見を持ち、テキストのみで構成され、真のドメインエキスパートのプレイブックから構築されたものです。

スキルが他のエージェントプリミティブとどのように構成されるかについての詳細は、私たちの Mastering Agent Skills ガイドと、 Karpathy Claude Code Skills Guide を参照してください。 なぜテキストベースのスキルがエージェントスタックを席巻しているのかという哲学的背景や、Humanizerが組み込まれるエージェント開発の広範なプレイブックについては、 Claude Code ベストプラクティスガイド が公式のコンパニオンとなります。

22. よくある質問 (FAQ)

23. 用語集

• AIボキャブラリー — 以下のような単語 testament、 landscape、 pivotal、そして vibrant など、2023年以降のLLMの出力において、それ以前の人間による記述よりもはるかに頻繁に出現する言葉。
• 繋辞 (Copula) — 動詞 to be、または 持つ。LLMはこれらを避け、より洗練された動詞を好んで使用します。 ～として機能する または 機能。
• カーリークォート（波型引用符） — ChatGPTがデフォルトで出力する、方向性のある二重引用符（“ ”）。ほとんどのプレーンテキストエディタでは、代わりにストレートな二重引用符（" "）が使用されます。
• エムダッシュ — LLMがカンマ、ピリオド、括弧の代わりによく使用する幅の広いダッシュ（—）。スキルにおけるパターン14。
• 偽の範囲（False range） — XからYまで という構成で、XとYが意味のある尺度上にないもの。パターン12。
• フロントマター — SKILL.mdファイルの先頭にあるYAMLブロックで、スキルの名前、説明、バージョン、許可されたツールを宣言します。Claude Codeはこれを読み取ってスキルを登録します。
• OpenCode — Claude Codeのスキル形式に従うオープンソースのCLIエージェント。humanizerスキルは両方で動作します。
• 否定的な並列構造（Negative parallelism） — 以下のような構成 Xだけでなく、Y または 単なるAではなく、Bである。パターン9。
• 3の法則 — 項目を3つずつグループ化する修辞的習慣。LLMは、ソース資料に3つの要素があるかどうかにかかわらず、これを適用する。パターン10。
• SKILL.md — Claude CodeやOpenCodeのスキルを定義する単一のMarkdownファイル。ヒューマナイザーのリポジトリ全体は、本質的にこれの一つである。
• お世辞のようなトーン — ユーザーを喜ばせるような導入句。例： 素晴らしい質問ですね！ または おっしゃる通りです！。パターン22。
• 末尾否定 — 文末に付け加えられる短い断片。例： 推測なし または 無駄な動きなし。パターン9のサブケース。
• 2段階監査 — スキルが自らプロンプトを生成して行う2回目のレビュー。質問によって開始されます。 以下の文章がAIによって生成されたものであると明らかに分かる理由は何ですか？.
• 文体調整（Voice calibration） — 自身の文章を2〜3段落提供することで、リライト結果を自分のスタイルに合わせるオプションのステップです。
• WikiProject AI Cleanup — Wikipediaのボランティアグループで、以下の項目を管理しています。 Signs of AI writing ガイド。このスキルのすべてのルールの主要な情報源です。

24. すべてのソースとリンク

主要な情報源

• blader/humanizer GitHub repo
• SKILL.md (スキル全体、フロントマター、およびルール)
• README.md (インストール、使用方法、バージョン履歴)
• Issue tracker (機能リクエスト、言語サポート、フォーマットフラグ)
• Pull requests
• Release history (バージョン1.0.0から2.5.1まで)

基礎となるソース資料

• Wikipedia: Signs of AI writing (主要な情報源)
• WikiProject AI Cleanup（管理組織）

互換性のあるエージェント

• Claude Code（公式）
• OpenCode（オープンソースCLIエージェント）

内部リンク

• エージェントスキルの習得
• KarpathyによるClaude Codeスキルガイド
• Antigravityスキルセットアップガイド
• Claude Codeベストプラクティスガイド
• Androidリバースエンジニアリングスキルガイド

25. ソース帰属テーブル