ai-humanizer について
ai-humanizer は、ドキュメントやコード関連の文章を作成・編集する人向けのライティングスキルです。README が AI 生成文に見られるとする表現パターンを避けるためのルールを示します。
主な機能
- 01文章の生成・編集ルール
- 02検出されやすい語彙を避ける指針
- 03人間らしいコミットメッセージの指針
- 04コードコメントと書式のルール
活用シーン
- 01README やドキュメントの編集
- 02コミットメッセージや PR 説明の作成
- 03コードコメントの逐語的な説明の確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ ofershap/ ai-humanizer --skill ai-humanizerインストール後、Claude Code で/ai-humanizerを入力して読み込まれたか確認します。
詳細
使用する場面
README、ドキュメント、コミットメッセージ、PR の説明、コードコメント、ブログ記事など、人が読む文章を生成または編集するときは、いつでもこのスキルを使用してください。AI 検出ツールが指摘し、経験豊富な開発者が機械生成だと見抜くパターンを防ぎます。
重要なルール
1. 区切りにダッシュ(—)を使わない
AI のパターン(検出ツールが指摘):
typescript-best-practices — enforces current best practices
Use satisfies for type checking — never use "as" for assertions
人間のパターン:
typescript-best-practices - enforces current best practices
Use satisfies for type checking. Never use "as" for assertions.
理由: ダッシュ(—)は、AI の文章を示す最も強いサインです。AI は人間の 5〜10 倍の頻度でこれを使います。代わりに、前後にスペースを入れたハイフン( - )、ピリオドを使うか、文の構成を変えてください。
2. 指摘される語彙を使わない
以下の語は、人間の文章より AI の文章で 50〜700 倍多く使われます。使わないでください。
重要性の誇張: paramount、pivotal、meticulous、holistic、robust、crucial、comprehensive、intricate、multifaceted、indispensable
冗長な動詞: delve、leverage、utilize、facilitate、streamline、optimize、elevate、empower、harness、foster、bolster、spearhead
マーケティング用語: seamless、cutting-edge、game-changing、revolutionary、groundbreaking、best-in-class、future-ready、scalable、next-generation
比喩表現: tapestry、landscape、ecosystem、paradigm、synergy
代わりに使う言葉: 平易な言葉を使います。「paramount」ではなく「important」、「meticulous」ではなく「careful」、「comprehensive」ではなく「complete」、「leverage」ではなく「use」、「optimize」ではなく「improve」を使ってください。
3. AI によくある書き出しや締めくくりを使わない
次の表現で書き始めないでください:
- "In today's fast-paced world..."
- "In an ever-changing landscape..."
- "In the realm of..."
- "Let me explain..."
- "Without further ado..."
- "At its core..."
次の表現で締めくくらないでください:
- "In summary..." / "In conclusion..."
- "By following these best practices..."
- "This approach ensures..."
- "Happy coding!"
代わりに: その文章が何をするのかから始めてください。言い終えたら、そこで終わりにします。
4. 文の長さと構成に変化をつける(リズム)
AI のパターン(リズムに変化がなく、12〜18 語の文が続く):
This plugin enforces security best practices for your codebase. It catches common
vulnerabilities that AI agents introduce. The rules run automatically on every file.
Each rule includes examples of correct and incorrect patterns.
人間のパターン(長さにばらつきがあり、自然なリズム):
Catches security issues AI agents introduce. Runs on every file automatically.
Each rule shows what's wrong and how to fix it - with real code, not theory.
理由: 検出ツールは「リズム」、つまり文の長さの変化を測定します。人間は短く歯切れのよい文と、長めの文を自然に織り交ぜます。AI の文は長さが均一になりがちです。
5. コードに説明コメントを追加しない
AI のパターン:
// Import the database client
import { db } from "./db";
// Define the user type
type User = { id: string; name: string };
// Fetch the user from the database
async function getUser(id: string): Promise<User> {
// Query the database for the user
const result = await db.query("SELECT * FROM users WHERE id = $1", [id]);
// Return the first result
return result.rows[0];
}
人間のパターン:
import { db } from "./db";
type User = { id: string; name: string };
async function getUser(id: string): Promise<User> {
const result = await db.query("SELECT * FROM users WHERE id = $1", [id]);
return result.rows[0];
}
理由: 人間は、明らかでないことにだけコメントを付けます。各行の処理を説明するコメントは、AI が書いたコードだと示す最も強いサインです。
6. Git の共同作成者トレーラーを追加しない
次のことはしないでください:
git commit --trailer "Co-authored-by: Cursor <[email protected]>"
コミットメッセージに含めないでください:
Co-authored-by: Cursor <[email protected]>
Co-authored-by: GitHub Copilot <[email protected]>
Generated-by: Claude
理由: これらのトレーラーは、Git の履歴にコミットが AI 生成であることを永久に記録します。履歴を書き換えない限り削除できません。
7. 人間らしいコミットメッセージを書く
AI のパターン:
feat: implement comprehensive user authentication system with JWT tokens
This commit introduces a robust authentication module that leverages
JSON Web Tokens for secure session management. The implementation
includes middleware for route protection, token refresh logic, and
comprehensive error handling.
人間のパターン:
add JWT auth
Middleware for protected routes, token refresh, error handling.
理由: AI のコミットメッセージは冗長で、Conventional Commits の接頭辞を過剰に使い、マーケティング用語で「何をしたか」を説明します。人間は簡潔に書きます。
8. 書式のパターンを均一にしない
避けるべき AI のパターン:
- すべてのセクションに箇条書きが 3 つずつある
- すべての箇条書きが太字の語で始まる:機能: 説明
- リストのどれもが完璧な並列構造になっている
- 三項構造:「調査、共同作業、問題解決」
- 否定の並列構造:「X が大切なのではなく、Y が大切です」
- すべての段落の長さが同じ
代わりに: リストにはばらつきを持たせます。1 語だけの項目もあれば、文になっている項目もあります。すべてに太字のラベルを付ける必要はありません。
9. Markdown の書式を使いすぎない
AI のパターン:
## Overview
This **powerful** tool provides **seamless** integration with your **existing** workflow. Key
**features** include:
- **Fast** - Lightning-quick processing
- **Reliable** - Battle-tested in production
- **Simple** - Zero configuration needed
人間のパターン:
## Overview
Integrates with your existing workflow. Fast, reliable, zero config.
理由: AI は太字、箇条書き、構造化を過剰に使います。人間は書式を控えめに使います。
10. 曖昧な表現や過剰な丁寧さを避ける
AI のパターン:
It's worth noting that this approach might potentially help improve
performance in certain scenarios. You may want to consider...
人間のパターン:
This improves performance.
理由: AI は「かもしれません」「潜在的に」「注目すべき点として」「検討してもよいでしょう」といった表現で、常に断定を避けます。人間は直接的に述べます。
パターン
README の適切な構成
- 最初に、何をするものかを一文で説明します
- インストール手順(コピーしてすぐ実行できる形式)
- 「含まれるもの」の短いリスト
- なぜ存在するのかを3~5個の箇条書きで説明します(宣伝ではなく、具体的な問題を挙げます)
- ライセンス
適切なコミットメッセージ
- 小文字で書き、末尾にピリオドを付けません
- 件名は50文字未満にします
- 理由が明らかでない場合にのみ本文を付けます
- プロジェクトで必須でない限り、Conventional Commits の接頭辞を付けません
適切なコードコメント
- WHAT ではなく、WHY だけを説明します
- チケット番号、外部ドキュメント、または自明でない制約を参照します
- バナー、セクション区切り、ASCII アートは使いません
適切な PR の説明
- 変更内容(ファイルや領域)
- 理由(課題へのリンク、または一文での説明)
- テスト方法
- 「この PR では包括的な……を導入します」のような表現は使いません
避けるべきパターン
文章で決して使わない単語
深く掘り下げる、タペストリー、活用する、利用する、促進する、合理化する、最重要の、極めて重要な、細心の、 包括的な、堅牢な、包括的な、多面的な、活用する、育む、強化する、先頭に立つ、シームレスな、 最先端の、画期的な、革命的な、革新的な、不可欠な、微妙な、複雑な、 高める、力を与える、解き放つ、強化する
決して使わないフレーズ
- 「今日の[形容詞]な世界/状況では」
- 「これは重要です/注目に値します」
- 「これにより、確実に……となります」
- 「……を活用することで」
- 「……への[形容詞]なアプローチ」
- 「X から Y まで」(範囲を誤って示す場合)
- 「X だけでなく、Y も」
- 「結局のところ」
- 「コーディング/開発を楽しみましょう!」
- 「さっそく見ていきましょう」
決して使わない構成パターン
- 区切りとしてのエムダッシュ(—)
- すべてのリストで三つ組にすること(「X、Y、そして Z」)
- 均一な段落や箇条書きの長さ
- 太字ラベル付き箇条書き:機能: 説明
- 質問から始めること:「……する方法を知りたいと思ったことはありませんか?」
- 行動を促す言葉で締めくくること:「今すぐ X を使い始めましょう!」
決して使わない Git のパターン
- AI ツールの Co-authored-by トレーラー
- 宣伝文句を含む冗長な Conventional Commits
- ファイル内での「生成元」や「作成ツール」の帰属表示