Gigazineで「Humanizer」の記事を見かけて、即Xのブックマークに突っ込んだ。
Claude CodeやOpenCode向けのスキルで、AI生成テキストのAI臭さを消すやつだ。
リポジトリは `blader/humanizer` 。GitHub見たら構造シンプルで、とりあえず5分で入れられそうだった。
インストールはマジで簡単で、Claude Code使ってるなら以下だけ。
自分はOpenCodeも試してるので両方入れた。
OpenCodeのほうはパスが `~/.config/opencode/skills/` になるだけで手順は同じだ。
使い方は `/humanizer [テキスト]` を投げるか、`Please humanize this text:` って頼むだけ。
このシンプルさ、好き。
気になったのは検出パターンが29個あること。
コンテンツ・言語・スタイル・コミュニケーションの4カテゴリで、具体的には「Additionally」「testament」みたいなAI頻出語彙や、エムダッシュ（—）の過剰使用、`data-driven` とか `cross-functional` みたいなハイフン多用ペアを検出する。
「Let's dive in」とか「Great question!」も引っかかるの、わかりすぎる。
自分がプロンプト書いてClaude呼ぶと、返ってくるテキストにこれ系のやつほぼ毎回入ってる。
面白いのがボイスキャリブレーションだ。
自分の文章を2〜3段落ペーストすると、それを基準にして同じ文体でhumanizeしてくれる。
指示はこう。
これ、個人開発でREADMEやchangelogをClaude Codeに書かせてるときに使いたい。
READMEって割と「書いた人の個性」が出るほうが読みやすいと思ってて、AIに一任するとどのリポジトリも同じトーンになっちゃうんだよな。
一個ハマりそうなポイントを先に言っておくと、Humanizerの検出パターンは全部英文ベースだ。
「受動態・主語のない断片」みたいなパターンは日本語にそのまま当てはまらないし、公式Issueでも多言語対応の議論は「リポジトリの方向性と合致しない」として全部クローズされている。
日本語向けには `gonta223/humanizer-ja` というインスパイアドなリポジトリが別にあって、20パターンのチェックリストを持ってるらしい。
英文コンテンツ以外を触るなら最初からこっちを見ておいたほうがいい。
正直なところ、自分が一番使いたいのはPR descriptionだ。
今のチームは6人で、PRにはかなりちゃんとした説明を書く文化がある。
自分はClaude Codeにdiffを食わせて説明文を生成させてるんだけど、出てくるやつが毎回「This PR introduces...」から始まる感じで、チームメンバーに「またAIじゃん」って雰囲気になってた。
Humanizerを通せばそのAIっぽさが取れるなら、レビュワーへの印象がだいぶ変わる気がする。
彼女に「PR descriptionってそんなに大事なの」って聞かれて、「コードレビューの印象ってdescriptionの質で3割くらい変わると思う」って答えたら「こだわりすぎ」と笑われた。
でも実際、説明が雑なPRってレビューが荒れやすいし、Humanizer使って少しでも人間らしいテキストになるなら試す価値はある。
あとは個人開発のZennやドキュメントに使うのもアリだ。
LLMにドラフトを書かせて、Humanizerで磨いてから自分で最終確認する、という三段構えが現実的なフローになりそう。
ボイスキャリブレーションの精度次第ではあるけど、まず自分の書いたZennの記事を数段落サンプルとして入れて、どこまで文体が寄ってくるか実際に検証してみる。
そこで納得できなければ promptを自分でいじるし、気に入ればチームに紹介してもいい。
動かしてから判断する、という姿勢でいく。
Claude CodeやOpenCode向けのスキルで、AI生成テキストのAI臭さを消すやつだ。
リポジトリは `blader/humanizer` 。GitHub見たら構造シンプルで、とりあえず5分で入れられそうだった。
導入は git clone 一発で終わる
インストールはマジで簡単で、Claude Code使ってるなら以下だけ。
mkdir -p ~/.claude/skills
git clone https://github.com/blader/humanizer.git ~/.claude/skills/humanizer自分はOpenCodeも試してるので両方入れた。
OpenCodeのほうはパスが `~/.config/opencode/skills/` になるだけで手順は同じだ。
使い方は `/humanizer [テキスト]` を投げるか、`Please humanize this text:` って頼むだけ。
このシンプルさ、好き。
気になったのは検出パターンが29個あること。
コンテンツ・言語・スタイル・コミュニケーションの4カテゴリで、具体的には「Additionally」「testament」みたいなAI頻出語彙や、エムダッシュ（—）の過剰使用、`data-driven` とか `cross-functional` みたいなハイフン多用ペアを検出する。
「Let's dive in」とか「Great question!」も引っかかるの、わかりすぎる。
自分がプロンプト書いてClaude呼ぶと、返ってくるテキストにこれ系のやつほぼ毎回入ってる。
ボイスキャリブレーション機能がえぐい
面白いのがボイスキャリブレーションだ。
自分の文章を2〜3段落ペーストすると、それを基準にして同じ文体でhumanizeしてくれる。
指示はこう。
/humanizer Here's a sample of my writing for voice matching: [自分の文章]
Now humanize this text: [変換したいテキスト]これ、個人開発でREADMEやchangelogをClaude Codeに書かせてるときに使いたい。
READMEって割と「書いた人の個性」が出るほうが読みやすいと思ってて、AIに一任するとどのリポジトリも同じトーンになっちゃうんだよな。
一個ハマりそうなポイントを先に言っておくと、Humanizerの検出パターンは全部英文ベースだ。
「受動態・主語のない断片」みたいなパターンは日本語にそのまま当てはまらないし、公式Issueでも多言語対応の議論は「リポジトリの方向性と合致しない」として全部クローズされている。
日本語向けには `gonta223/humanizer-ja` というインスパイアドなリポジトリが別にあって、20パターンのチェックリストを持ってるらしい。
英文コンテンツ以外を触るなら最初からこっちを見ておいたほうがいい。
自分のコードのどこに刺さるか
正直なところ、自分が一番使いたいのはPR descriptionだ。
今のチームは6人で、PRにはかなりちゃんとした説明を書く文化がある。
自分はClaude Codeにdiffを食わせて説明文を生成させてるんだけど、出てくるやつが毎回「This PR introduces...」から始まる感じで、チームメンバーに「またAIじゃん」って雰囲気になってた。
Humanizerを通せばそのAIっぽさが取れるなら、レビュワーへの印象がだいぶ変わる気がする。
彼女に「PR descriptionってそんなに大事なの」って聞かれて、「コードレビューの印象ってdescriptionの質で3割くらい変わると思う」って答えたら「こだわりすぎ」と笑われた。
でも実際、説明が雑なPRってレビューが荒れやすいし、Humanizer使って少しでも人間らしいテキストになるなら試す価値はある。
あとは個人開発のZennやドキュメントに使うのもアリだ。
LLMにドラフトを書かせて、Humanizerで磨いてから自分で最終確認する、という三段構えが現実的なフローになりそう。
ボイスキャリブレーションの精度次第ではあるけど、まず自分の書いたZennの記事を数段落サンプルとして入れて、どこまで文体が寄ってくるか実際に検証してみる。
そこで納得できなければ promptを自分でいじるし、気に入ればチームに紹介してもいい。
動かしてから判断する、という姿勢でいく。