avoid-ai-writing レビュー: 112語の置換表と74カテゴリでAI臭を機械的に潰すスキル

このスキルが埋める穴は「プロンプト一回では消えない癖」

「人間らしく書き直して」と一度頼むだけでも、明らかなAI臭は消える。消えないのは、書き換えた後の文章に残る癖だ。README はこの点を二段階検出の根拠として挙げている。一度目の編集をすり抜けた定型の接続詞、しつこく残る誇張、置換し損ねた copula（be動詞の代わりに使われる「serves as」「features」のような言い回し）を、二度目のパスで拾い直す。対象読者は、エージェントに文章を書かせてそのまま出したくない人。ブログ、ニュースレター、ドキュメントの下書きを日常的にエージェント経由で作っているライターや編集者が想定されている。逆に、ゼロから文章を生成させたいだけの人には不要で、生成側のプロンプトに数行足す方が速い。

中身は魔法ではなく、表と密度の計算

仕組みは3つの層に分かれている。第一層は112語の置換表で、3つのティアに分かれる。Tier 1 は例外がなければ無条件にフラグが立つ語（delve、tapestry など）、Tier 2 は同じ語が近い範囲に固まって現れたときに立つ語、Tier 3 は密度が高いときだけ立つ語だ。Tier 1 はさらに 1A の頻度マーカーと 1B の明瞭化編集に分かれる。両者は修正内容こそ同じだが、1A だけが「その文章がどう作られたか」の証拠として扱われ、1B は重みが低く設定されている。冗長表現の修正が文書をAI判定へ押しやらないようにするための設計だ。第二層は74のパターンカテゴリで、カタログは references/patterns.md に置かれ、この件数は CI で実際のファイルと突き合わせて検証されていると README は説明している。ハッシュタグの詰め込み、名詞句だけを並べた箇条書き、ヘッジを重ねた予測、プレースホルダや UTM パラメータのようなAIツールの痕跡、リズムの均一性などが含まれる。第三層が二度目の監査で、書き換え後の文章を読み直して残存パターンを拾う。判定の根拠が表と密度に固定されているため、同じ文章を同じモードで通せば結果は安定する。その代わり、表に載っていない新しい言い回しは素通りする。

rewrite / detect / edit の使い分け

デフォルトは rewrite モードで、パターンにフラグを立てて書き換え、二度目のパスで残りを拾う。detect モードは書き換えずにフラグだけを出す。パターンが意図的なものかもしれない場合や、内容に手を入れたくない監査、単にざっと見たいときに使うと README は書いている。このモードの価値は、どのフラグが実際の問題でどれが判断の余地があるかを分けて提示する点にある。三つ目の edit モードは Edit ツール経由で散文ファイルをその場で書き換える。変更は最小限にとどめ、すでに人間が書いた箇所は保持する。ソースコード、設定ファイル、生成されたデータは拒否される。散文の書き換えが構造化された内容を壊しうるためだ。戻り値は書き換え後のファイル全体ではなく、加えた編集と検証のレポートになる。この拒否の線引きは明快で、たとえば YAML の中の説明文だけを直したい、といった用途は edit モードの対象外になる。オプションの voice profile は casual、professional、technical、warm、blunt の5種で、読み手の文脈プロファイルとは独立に、文章の響きだけを指定する。

導入は clone かプラグイン、ただしファイルを欠かさないこと

Claude Code では skills ディレクトリに clone するのが基本形だ。

git clone https://github.com/conorbronsdon/avoid-ai-writing ~/.claude/skills/avoid-ai-writing

単一ファイルでルールを渡したい場合は dist/avoid-ai-writing.md を使い、CLAUDE.md から参照する。スラッシュコマンドとして使うなら ~/.claude/commands/clean-ai-writing.md を作り、SKILL.md を読むよう指示を書いて /clean-ai-writing に引数を渡す。Claude Cowork は ~/.claude/skills/ を走査せず、インストール済みプラグインからしかスキルを読み込まない。そのため Claude Code と同じ clone では認識されず、プラグインとして入れる必要があると README は明示している。ここで注意すべきなのは、SKILL.md を単体で取得する古いインストーラの存在だ。SKILL.md は監査の前に references/patterns.md を読み込む前提で書かれているため、カタログが欠けた状態では根拠のない判定になる。scripts/、detector/、examples/ は任意の機械的検証用で、なくても動くが、あると検出結果をコマンド側から確認できる。

向かない場面: 構造化データと、表の外側の文体

edit モードがソースコードや設定を拒否するのは安全側の設計だが、裏返せば「散文と構造化データが混ざったファイル」は扱いにくい。Markdown のコードブロックやフロントマターを含む記事ファイルも、境界の判断はスキル側の裁量に委ねられる。もう一つの限界は検出の性質そのものだ。112語の表と74カテゴリは、既知のパターンを漏れなく拾うための仕組みであって、未知の癖を拾う仕組みではない。表にない言い回しは、どれだけAIらしくてもフラグが立たない。また Tier 2 と Tier 3 は密度で判定するため、短い文章では固まりが作れず、フラグが立たないまま通過する。逆に、密度の高い技術文書や学術的な文章では、正当な語彙がまとまって現れて誤検知につながる可能性がある。README 自身が detect モードの用途として「意図的なパターンかもしれない場合」を挙げているのは、この誤検知を前提にした逃げ道だと読める。

代替手段との違いは判定を表に固定しているかどうか

同じ目的の手段として、汎用の校正ツールである textlint がある。textlint はルールを JavaScript で記述し、正規表現や形態素解析の結果に対してルールを適用する。判定基準はルールファイルの中に明示され、CI に組み込みやすい。avoid-ai-writing との差は適用対象の広さにある。textlint は日本語の技術文書向けルールセットが中心で、AI文体の検出を主目的にはしていない。avoid-ai-writing はエージェントのスキルとして動くため、検出だけでなく書き換えまでを同じ手順の中で行い、voice profile で出力の響きを指定できる。一方で、判定ロジックを自分で書き換えたい場合、avoid-ai-writing は表とカタログを編集することになり、textlint のようにルール単位でテストを書く仕組みは README からは読み取れない。決定的な違いは、avoid-ai-writing が「LLMに判定させる」のではなく「LLMに表を適用させる」方向に倒している点だ。再現性は上がるが、表の更新がそのまま検出力の上限になる。

更新頻度とライセンスが示すもの

リポジトリは MIT ライセンスで、アーカイブはされていない。直近のリリースは v3.33.0、v3.32.0、v3.31.0 が2026年9月5日に並んでおり、同じ日に複数のバージョンが切られている。パターンカタログと置換表を継続的に調整している運用だと推測できるが、これはリリース時刻から読み取れる範囲の話で、各版の差分までは材料からは確認できない。MIT なので社内ツールへの組み込みや改変は比較的自由だが、同梱の examples/ や docs/ に含まれる文章の扱いは別途確認する必要がある。ライセンス表示を残す条件は満たしておきたい。更新コストの見積もりで効くのは、スキル本体よりも references/patterns.md の差分だ。ここが更新されるたびに検出結果が変わるため、CI で文章を検査している場合はバージョンを固定してから上げる方が安全だ。

編集部の結論

すでに Claude Code や OpenClaw などのエージェントを常用していて、公開前にAI臭を機械的に落としたいライターや編集者に向く。逆に、文体の判定を人間の感覚に委ねたい人や、構造化データを含むファイルを一括で書き換えたい用途には向かない。導入前に確認すべきは、自分のエージェントがディレクトリ型スキルを読めるかどうかと、リポジトリを clone した先に references/patterns.md が含まれているかどうか。SKILL.md だけを取得する古いインストーラを使うと、監査の根拠になるカタログが欠けた状態で動くことになる。

公式情報源

1. conorbronsdon/avoid-ai-writing on GitHub
2. License: MIT
3. Project website
4. README
5. Releases