AI が書いた日本語を自分の文体に直す ja-humanizer を作った
はじめに
最近、AI を使って書いたなと分かる記事が、note や Zenn でも増えてきた。あの特徴的な言い回しはどこから来るのだろうと思いつつ、自分でも AI で記事を書いているせいか、一瞬で「あ、AI に書かせたな」と分かるようになってきた。気になりだすとどんどん気になるもので、私も AI の下書きを手で直し続けたり、色々なスキルを入れて AI 臭さを無くす取り組みを続けている。
その添削記録から、日本語を書く、直す、検査するための Agent Skill を作り、agent-skills に ja-humanizer として公開した。この記事では、ja-humanizer の特徴と、本家の海外製 humanizer を日本語にそのまま使えなかった理由、他の方のスキルを参考にした点を紹介する。
この記事のポイント
- AI の日本語は、単語選びとリズムだけでなく、読み手が決めるのに要る事実が無い点で分かる
- 癖を第1級から第3級に分け、見つけたら直すものと、自分の文体なら残すものを区別した
- スキルは事実を足さない。足りない事実は問いにして書き手へ返し、モデルが自分で補った事実は「要確認」として列挙する
- 検査で指摘が無くても、自分の言い方になっているかは読み直す必要がある
AI の日本語は何で見分けられるのか？
直訳調の単語選び、文章の独特のリズム（これは Claude 系が特に顕著）、文章の中身の3つに分類できると考えている。単語選びでは Claude お馴染みの「閉じる」「配る」「刺さる」のような比喩動詞が多く出現し、「実現する」「可能にする」「寄与する」のような英語直訳の硬い述語も多用しがちである。私が読んだ下書きでは、語尾や一文の長さが揃い、同じ調子が続くのも気になった。ただ、同じ語尾が続くこと自体を直す必要はない。
添削記録でいちばん多かったのは中身、つまり文章のコンテンツだった。コンテンツまで全部 AI 任せでは自分の記事では無くなってしまうので、どこまでやらせるかは賛否があると思うが、例えば過去の記事で決済サービスの導入メリットを AI に書かせたとき、次のような項目が出てきた。
迅速なセットアップ:
複雑なハードウェアの導入が不要なため、短期間でシステムを立ち上げることができます。文は整っているが、不要になるものが電源なのか回線なのか専用ソフトなのかが書かれていない。私が直した後の文はこうなった。
早期導入:
電源や WIFI、専用ソフトのインストールなどは不要で、スマホにアプリをインストールするだけで
短期間でサービスを立ち上げることができます。この例では、何を用意すれば使い始められるのかを書き足した。「複雑なハードウェアが不要」だけでは、具体的に何が要らないのか分からなかったからである。
既存の humanizer をそのまま使えなかった理由
当たり前だが、本家は語のリストが英語なので、そのまま使うのは控えた。参考にした blader/humanizer からは、気になる箇所に印を付け、直してから再検査する流れと、書き手の文体見本を優先する考え方を受け継いだ。em ダッシュや直線の引用符、「delve」のような英単語の目印は英語の文向けに作られていて、日本語ではあまり意味をなさないので採用していない。
日本語版の humanizer-ja を作っておられる方もいたので、参考にさせていただいた。gonta223/humanizer-ja は20パターンのチェックリストを公開されている。ただ、私の添削記録にある「事実が無い」型の直しは語のリストでは拾えないと考え、作業の流れと等級の考え方は blader/humanizer から借り、パターン表は日本語で作り直すことにした。文章の規範は、k16shikano 氏の japanese-tech-writing が素晴らしいのでこちらを土台にさせていただき、自分なりに翻訳調の述語と、英語とカタカナの混ぜ方の規則を加えて内蔵した。
等級分けして修正を重ねていく方式
AI の癖を一つのリストにして、見つけた端から全部直すやり方は、最初に試して断念した。癖と言っても、例えば「実現する」のように単語が出てきたらまず直したいものと、太字や箇条書きのように人が意図して使うものが混ざっていて、全部を機械的に潰すと、今度は「直した後の文体」という別の癖が付いてしまう。
そこで、癖ごとに「一つ見つけたときにどう扱うか」を先に決めて、扱いが同じものをまとめることにした。これを等級と呼んでいる。一つ見つけたら直すものが第1級、直してよいが自分の文体見本に同じ型があれば残すものが第2級、単独では直さないものが第3級、の3段階である。
| 等級 | 扱い | 例 |
|---|---|---|
| 第1級 | 一つ見つけたら直す | 評価語だけで事実の無い文、比喩動詞と硬い述語、演出と脅しの締め、クッション言葉 |
| 第2級 | 直してよいが、文体見本にあれば残す | ラベルとコロンの箇条書き、常に3つの項目、「することができます」、語尾と文長の均一 |
| 第3級 | 単独では直さない | 太字、箇条書きそのもの、「〜ですね」、一文が長い |
第1級は検出器の統計からではなく、私の添削記録（業務メール3組、公開記事の書き直し2本、PR 本文1組）から抽出した。第2級は先行スキルの分類を参考にし、日本語ではあまり意味をなさない項目を外している。
第2級を「見本にあれば残す」にしたのは、解説記事ではラベルとコロンの箇条書きを書き手自身（特に私）が使うからである。言葉遣いや語尾、一文の長さは、書き手の見本に合わせる。ただし、話が矛盾していたり、なぜそうなるのか説明が抜けていたりする箇所は直す。
足りない事実をスキルが補わないのはなぜか？
「短期間で導入できる」のように、理由や条件の説明が足りない箇所を見つけたら、「何が不要になり、以前はどうで、なぜそうなるのか」を書き手に問うようになっている。書き手が回答すれば、その内容を元に書き直す。答えが無ければ、その文は削るか事実だけを残す。AI が知り得ない事実や補強すべきコンテンツを与えるのは書き手のオリジナリティが出る部分だと思うので、そこは大事にした。
書き下ろしでは、この規則だけでは足りなかった。モデルは自分が知っていると思う事実を問いにしない。同じ指示文で、旧規範だけを使った下書きと ja-humanizer を使った下書きを読み比べたとき、指示に無い「日本のクレジットカードは主に Online PIN」という記述が自信を持って書かれ、私の確認で誤りと分かった。この確認をモデルが自分から求めることは無かった。
対策として、下書きの後に、指示にも材料にも文体見本にも無い数値と年月、国や会社ごとの制度と慣行、製品名を伴う機能の有無、出典の無い統計を抜き出し、本文末尾に「要確認」として列挙する。本文からは消さない。残すか消すかの判断は書き手のものである。
検査スクリプトは何をどう数えるのか？
検査スクリプトは正規表現で、特定の言葉や同じ語尾の連続などを探す。原因の説明が現象の言い換えに留まる文や、具体的な手順の無い対策も、決めたパターンに合えば指摘する。文脈を読んで、その対比が必要か、結論が事例に見合っているかを判断するのは、スキルを読む AI と書き手の作業になる。
スキルは次のコマンドで導入できる。
npx skills add anyoneanderson/agent-skills --skill ja-humanizer -g -y同梱の評価用サンプル（冒頭の決済サービスの下書き）に、記事モードで実行した結果がこれである。第3級は1件だけ表示している。
$ node references/scripts/ja-humanizer-check.mjs --mode article tap-before.md
TIER1 thin-claim tap-before.md:5 item rests on evaluative words with no specifics
この項目で、何が不要になり、以前はどうで、なぜそうなるのかを教えてください。
TIER1 thin-claim tap-before.md:9 evaluative closer without a fact
TIER1 thin-claim tap-before.md:11 item rests on evaluative words with no specifics
TIER3 label-colon tap-before.md:2 label-plus-colon item
JA_HUMANIZER_CHECK_SUMMARY FAIL tier1=3 tier2=0 tier3=4私が直した後の版では tier1=0 になる。4項目中3項目に問いが出て、1項目目は「一台」という数字を含むため通った。数字や括弧、列挙の有無を手掛かりにしているので、説明が十分でも指摘されることがある。逆に、数字があっても説明が足りない文はある。指摘された箇所は、前後を読んで直す必要があるか判断する。
--json を付けると他のスキルや CI で読み取れる JSON が出力され、第1級があると exit 1 になる。--warn を付ければ 0 に変わる。コードブロック、インラインコード、表、frontmatter は検査の対象外である。
他のスキルとの組み合わせ
記事生成スキルから呼び出すときは、下書きの前に規範とパターン表、文体見本を読む。書いた後に検査スクリプトを実行し、指摘を確認して直す。要点の枠や FAQ などの構成は記事生成側で指定し、本文の言葉遣いは ja-humanizer で調整する。
この記事もその工程で下書きした。ただ、検査で指摘が無くなった後も、読み返すと直したい箇所が残っていた。
よくある質問
Q. 文体見本には何を置けばよいですか？
A. 自分が手で書いた文章の抜粋を、論証、読み物、メールの3ファイルに分けて置く。AI の下書きに本人が加筆したものなら、自分の言い方だと確認した箇所を抜き出す。見本の中の「〜してください」のような文を、スキルが指示として読むことはない。
Q. 日本語以外の文章にも使えますか？
A. 使えない。入力が日本語でなければ、その旨を返して止まる。英語の文章には blader/humanizer を使うのがよい。
検査を通した後にも残った違和感
この紹介記事の下書きは、検査で第1級から第3級まで0件だった。それでも note 版には「AI っぽさを消す作業の正体は」「その境界を文章の作業に引くためのもの」といった、自分では使いたくない説明が残っていた。具体例の後に大きな結論を置く書き方も気になった。
見本にした Zenn 版にも、直しきれていない表現があった。本人が添削した記事でも、その全文を文体見本にすれば、残っていた癖まで見本として読まれる可能性がある。今後は、自分の言い方だと判断した段落を選び直したい。スキル側にも、接続表現や対比を促す指示があるので、見直す必要がある。
文章を書くモデルを替えることも考えている。Claude に何度も修正を頼むより、GPT-6 Astra で下書きした方が手直しが少ないなら、文章生成はそちらに任せてもよいと思う。ただ、同じ資料と文体見本での比較はまだしていない。モデルを替えれば解決するかは、公開できる状態まで直す手間を比べて確かめたい。
参考ソース
この記事のダイジェスト版