avoid-ai-writingの使い方——AI文章の56の型を検出して直すスキルを、Claude CodeとCodexに入れて点数で見る

2026年9月14日 20:06

「AIに書かせた文章、どこがAIっぽいのか自分では分からない」

そう言われて、私も答えに困ったことがあります。「なんとなく」しか言えなかった。

avoid-ai-writingは、その「なんとなく」を56個の型に分けて、名指しで直すスキルです。Claude Code、Codex、OpenClaw、Cursor、Hermesに入る。MITライセンス。GitHubのスターは4,312（GitHub APIで確認）で、今月だけで1,200以上増えました。

この記事では、GitHubのREADMEに書いてあることだけで、入れ方、3つのモード、点数の見方、そして「直しすぎない線」を順に書きます。確認日は2026年9月12日です。

avoid-ai-writingとは——56の型と、3つのモード

素性を先に3つ。

1つ目、中身はスキルです。モデルではない。エージェントに「この型を探して、こう直せ」と教える文書と、それを機械で数える検出器のセットです。

2つ目、型は56個。語彙、構造、トーン、道具の痕跡の4つの層に分かれています。

「leverage」を「use」に、「Moreover」を「and」に、「Great question!」は削除。「It's not X, it's Y」は直接の文に、見出しのTitle Caseは文頭だけ大文字に、ハッシュタグが6個以上なら2〜3個に。こういう具体の対応が、型ごとに書いてある。

3つ目、モードが3つ。

Rewriteが既定で、型を引用つきで指摘し、直した版を出し、変更を要約して、2回目の監査まで回す。Detectは指摘だけで、P0・P1・P2の重要度が付く。Editは散文のファイルを最小限の変更で上書きするモードで、ソースコードや構造化データは壊さないために拒否します。

（正直、「AIっぽさ」を56個に分解して名前を付けた、という時点で、私はこのリポジトリを読む価値があると思いました）

STEP1: avoid-ai-writingを入れる——エージェントごとに置き場所が違う

入れ方は、使っているエージェントで変わります。READMEにある分だけ書きます。

Claude Codeなら、git clone https://github.com/conorbronsdon/avoid-ai-writing ~/.claude/skills/avoid-ai-writing。もう1つ、1ファイル版の dist/avoid-ai-writing.md を落として、CLAUDE.mdから「AIの型を直すときはこのファイルを読め」と参照させる方法もあります。

OpenAI Codexなら、git clone の先を .agents/skills/avoid-ai-writing にする。プロジェクトの中に置く形です。

OpenClawは clawhub install avoid-ai-writing。Cursorは .cursor/rules/avoid-ai-writing.mdc に落とす。Hermesは ~/.hermes/skills/writing/ の下。

で、置き場所が違う理由は、それぞれのエージェントがスキルを読む場所が違うからです。同じ中身を、読まれる場所に置く。

逆に言うと、置き場所を間違えると、入っているのに一度も読まれない。入れたあとに「Remove AI-isms from this post」と頼んで、反応が変わるかを見てください。変わらなければ、置き場所です。

STEP2: avoid-ai-writingの使い方の中心——3つのモードを、まずDetectから

私が勧める順番は、Detectから。

READMEの呼び出し例だと、「detect」「flag only」「audit only」「just flag」「scan」のどれかを含めると、Detectモードになります。「Audit this draft for AI tells」のような頼み方です。

なぜ先に直さないか。直された文を見ても、何が問題だったかは分からないからです。指摘だけを見ると、「自分の文章はここが型にはまっている」が分かる。それを2〜3本の記事で見てから、Rewriteに進む。

Rewriteは既定なので、「Remove AI-isms from this post」「Make this sound less like AI」で動きます。直した版と一緒に、変更の要約と2回目の監査結果が出る。

Editは、ファイルをその場で書き換えるモード。散文だけを対象にしていて、ソースコードや構造化データは拒否します。READMEにそう書いてある。だから、記事のmdファイルに使うのは良くて、設定ファイルやJSONに使おうとしても動かない。

いや、Rewriteで一気に直したほうが早くない？

早いです。ただ、直された文が自分の声でなくなることがある。

READMEには声のプロファイルが5つ（casual・professional・technical・warm・blunt）あって、トーンを指定できるようになっています。指定しないまま直すと、平らな文になりやすい、と私は思っています。まずDetectで型を知り、Rewriteではプロファイルを指定する。この順番が、直しすぎを防ぐ。

STEP3: 検出器の使い方——点数は決定的に出る

このリポジトリで一番使えると思ったのが、detector/ です。

Node 18以上で動く検出器で、npx --package avoid-ai-writing-detector avoid-ai-writing draft.md と打つと、0〜100の点数、重要度のラベル、指摘の件数が返る。--context technical のように、文脈を渡すこともできます。

何が良いかというと、「決定的」であること。同じ文を入れれば、同じ点数が出る。

モデルに頼むと、頼むたびに指摘が変わりますが、検出器は変わらない。だから、直す前と後で点数を比べられます。

もう1つ、node detector/validate.js before.md after.md。直す前と後を渡すと、保全のエラーがあれば exit 1 で止まる。直したついでに、消してはいけないものが消えていないかを見る道具です。

MCPサーバーの形もあります。claude mcp add avoid-ai-writing -- npx -y avoid-ai-writing-mcp@0.1.0 で入れると、score_text と audit_text の2つのツールが使える。

書き直しのツールはMCPには無くて、それはスキル側に残す、と明記されています。点数と指摘は機械、書き直しはエージェント、という分け方です。

avoid-ai-writingを使う前に決めること——直しすぎない線

ここは私の意見です。

56の型のなかには、日本語の文章にそのまま当てはまらないものがあります。「Title Caseの見出し」や「不要なハイフン」は英語の話です。逆に、「Moreover」の直訳にあたる「さらに」「また」の連打や、「Great question!」にあたる「素晴らしい質問ですね」は、日本語でもそのまま効きます。

だから、入れたあとに、自分の文章で3本ほどDetectを回して、「日本語でも当たる型」と「当たらない型」を分ける。当たらない型は無視していい。

もう1つ。点数を上げること自体を目的にしない。検出器の点数は、型に当てはまる数を数えているだけで、文章の良し悪しを測ってはいません。点数が高くても、伝わる文はある。直す前と後で「言いたいことが残っているか」を、自分の目で見る方が先です。

avoid-ai-writingの使い方——入れて、Detectで見て、点数で比べる

まとめます。

avoid-ai-writingの使い方は、入れる・見る・比べるの3段です。入れる場所はエージェントごとに違う。Claude Codeは ~/.claude/skills/、Codexは .agents/skills/。入れたら、頼み方を変えて反応が変わるかを見る。

モードは3つ。Detectで型を知り、Rewriteはプロファイルを指定して直し、Editは散文のファイルだけ。

点数は検出器で。決定的なので、直す前後で比べられる。validate.jsで消してはいけないものが残っているかを見る。

今日やるなら、直近に書いた文章を1本、Detectに通すだけでいいです。何が「AIっぽい」と言われたかを見て、それが日本語でも当たる型かを1つ判断する。そこからです。

OSSを実務で活用するための6大特典

日本語で当たる型の絞り方や、点数を直す前後で比べる運用を整理したい方へ。活用を進めるための6大特典をご案内しています。

👉 OSS活用の6大特典を見る