humanizer の使い方——AIっぽい文章を35個の型で直すスキルと、直しすぎない線

自分が書いた文章を読み返して、「なんかAIっぽいな」と思ったことはありませんか？

私はあります。しかも、どこがそうなのかを説明できませんでした。

なんとなく整いすぎている。読めるけど、通り過ぎてしまう。その正体が分からないまま、なんとなく語尾だけ崩したりしていました。

今日紹介する humanizer は、そこに35個の名前を付けたスキルです。

この記事では、humanizer の使い方と、どこまで直させて、どこから直させないかの線引きを書きます。うちが同じ問題を自前で1年ぶん測ってきた側なので、その実測とも突き合わせます。

humanizer の使い方は、ほぼ1行で終わる

先に使い方から書きます。

スキルを呼んで、文章を貼る。それだけです。「この文章を人間っぽく直して」と普通に頼んでも動きます。

ファイルを指定することもできます。その場合、直すのは散文だけ。コード、データ、ノート冒頭の設定欄、リンク先には触りません。ここは地味に大事なところで、直してほしくない場所を毎回説明しなくていいということです。

もうひとつ、文章の見本を一緒に渡すと、その見本の書き方に寄せてくれます。既定の作法ではなく、あなたのリズムに合わせる。

出力は、いきなり完成版が出てきません。最初の書き直しと、まだ人工的に見える部分への短い指摘が先に出ます。それを見てから、最終版。

途中を見せるという設計です。

humanizer が直すもの——35個の型の中身

判定の根拠が面白いところで、Wikipedia の「AIが書いた文章の兆候」というページを使っています。Wikipedia の中で、AIが書いた記事を掃除している人たちが維持しているものです。

つまり、大量の実物を掃除してきた人たちが作った一覧が元になっている。ここに説得力があると思います。

35個は3つに分かれます。

中身の型は、大げさに意味づけする、名前を並べて権威づける、根拠のない「専門家によれば」、宣伝みたいな形容、といったもの。文法の型は、「AだけでなくBだ」の乱発、3つ並べたがる、受け身で主語を消す、is や are を避けて飾った動詞に置き換える、あたりです。

見た目の型は、もっと即物的でした。ダッシュの多用。太字の付けすぎ。箇条書きの先頭だけ太字にする書き方。見出しの単語を全部大文字始まりにする。絵文字。

読んでいて、うちの記事に当てはまるものが普通にありました。

とくに刺さったのが「箇条書きの先頭だけ太字にする」です。うちは以前、1本の記事に箇条書きを23行、太字を36箇所入れていました。丁寧に書いたつもりでした。

あとで、note の中で読まれている記事20本を同じ物差しで数えたら、箇条書きは中央値0行、太字は12箇所でした。丁寧さのつもりでやっていたことが、そのままAIっぽさの指標だったわけです。

この時は正直、けっこう落ち込みました。

作らない、という設計がいちばん効いている

いちばん感心したのは、直し方ではなく直さない範囲の決め方です。

名前、数値、日付、引用、出典。これらは出典か書き手から来たものしか使わない、と明記されています。読みやすくするために事実を足すことをしない。

これ、当たり前に見えて、文章を良くする道具としてはかなり珍しい部分だと思います。文章を「良く」しようとすると、たいてい情報が増えるので。

うちはここで一度、実際に事故を起こしています。

表紙のコピーを機械で作らせたときに、存在しないバージョン番号が表紙に載りました。長い版数を字数に合わせて切っただけなのですが、切った結果が別物になっていた。16字以内という規格は満たしているので、機械の検査は全部通ります。目で見るまで誰も気づきませんでした。

しかも、その表紙はもう少しで公開されるところでした。壊れたのは文字数ではなく、事実のほうです。

だから、作らないと最初に宣言してある道具は信用しやすいです。

いや、AIっぽいと何が困るんですか？

ここは分けて考えたほうがいいと思っています。

判定を回避したい、という話ではありません。そもそもこの道具は中身を変えないので、書いたのがAIかどうかは変わらない。

困るのは、もっと素朴なところです。読み飛ばされる。

整いすぎた文章は、引っかかりが無いので、目が滑ります。うちがnoteで実測しているのはまさにそこで、読まれた記事とそうでない記事を分けていたのは、正しさではなく引っかかりのほうでした。

言い換えると、AI臭を消すのは礼儀の問題ではなく、読まれるかどうかの問題です。

うちは「消す」より先に「測る」をやっていた

ここからは自社の実測です。

うちは、Googleの検索で上位に出ている note 記事102本を全文集めて、同じ物差しで測りました。人間が書いて、実際に読まれている文章の分布を知りたかったからです。

いちばん効いた指標が文長のばらつきでした。25%点が19.5、中央値が28.0、75%点が45.4。

これが低いと、AIっぽくなります。全部同じ長さで刻んでいるからです。短い文と長い文が混ざっているかどうか、それだけで印象がかなり変わる。

ほかにも、です・ます率は0.59〜0.79（3割は言い切りが混ざる）、AIっぽい定型句の濃度は1000字あたり0.14〜0.64、といった帯を持っています。

ここで一度、大きく間違えました。

最初、しきい値を勘で置いたんです。「問いかけが2回未満なら不合格」「同じ語尾が4回続いたら不合格」。それらしく見えました。

その基準で、お手本にしていた記事を測ったら落ちました。

お手本の中には問いかけが0回の記事があり、語尾は5回続いている記事もあった。勘で置いた基準は、人間の書いた良い文章を弾く基準だったわけです。

以来、しきい値は必ず模範解答を同じ物差しで測ってから決めています。

この形に落ち着くまでは3段階かかりました。最初は、書いたあとに自分で読み返して直していた。次に、勘で決めた基準を機械に入れて、上のとおり失敗した。いまは、お手本の分布を先に測って、その帯から外れたときだけ知らせる形にしています。

同じ検査を毎日15本に当て続けているので、帯そのものも少しずつ更新しています。続けていること自体が、次の判断の材料になるという作り方です。

humanizer の使い方が向く場面・向かない場面

humanizer の使い方として向いているのは、下書きが既にあるときです。中身は決まっていて、読み味だけ直したい。ここは強い。

向いていないのは、中身が薄いときです。35個の型を全部消しても、書くことが無い文章は良くなりません。当然ですが、道具のせいにしやすい部分でもあります。

もうひとつ。技術文書は中立で平坦なままにする、と決められています。個人の文章は書き手の癖を残す。どちらの用途かを先に決めてから渡すと、期待とずれません。

ライセンスはMIT、中身はMarkdownだけなので、スキルに対応しているエージェントならだいたい動きます。手元に入れる負担がほぼ無いのは、試すうえで大きいです。

今日やる一歩

使い方を覚える前に、今日は自分が最近書いたものを1本だけ選んでください。記事でも、社内向けの説明でも構いません。

そして、35個の型のうち見た目の型だけを自分で当ててみる。太字が多すぎないか。ダッシュを連発していないか。箇条書きの先頭だけ太字になっていないか。

道具を入れる前に、3分で分かります。そこで心当たりが出たら、そのときに使い方を覚えれば十分です。

順番を逆にすると、たぶん道具だけ増えます。私はそれを何回かやりました。

今日はこんな話でした。

実務で使えるOSSを毎日1本ずつ調べています

オープンソース研究所では、その月に伸びているリポジトリを公式の情報だけで確かめて、実際に業務へ入れるならどこで詰まるかまで書いています。選び方の基準と、導入前に見る観点をまとめました。

👉 OSS選定6大特典を受け取る

#オープンソース #OSS #humanizer #AIライティング #エージェントスキル #文章術 #ClaudeCode #Codex #生成AI #業務自動化 #品質管理 #AI活用