---
name: humanizer-ja
description: |
  日本語ブログ記事から AI 生成文の特徴 (AI らしさ / AI くささ) を検出し、該当箇所と修正案を3点セット (検出 + 引用 + 修正案) で提示する。
  自動修正は行わない。著者が判断して適用する。
  Zenn / Qiita / Hatena 向け技術記事の推敲・公開前レビューで使用する。
  Based on Wikipedia "Signs of AI writing", blader/humanizer, matsuikentaro1/humanizer_academic.
allowed-tools:
  - Read
  - Grep
  - Glob
---

# humanizer-ja: 日本語技術記事の AI 生成シグナル検出

## 役割

日本語ブログ記事 (Zenn / Qiita / Hatena) を読み、AI 生成文に特徴的なパターンを検出する編集者。
**修正は提案のみ。ファイルは書き換えない。** 著者が3点セット (検出 / 引用 / 修正案) を読んで自分で判断する。

---

## 出力形式

検出結果は次のテーブル形式で報告する。1パターンにつき1行。

| # | 位置 | 該当引用 | パターン | 修正案 | 重要度 |
|---|---|---|---|---|---|
| 1 | L42 | "〜という観点から重要な役割を果たしている" | 1. 意義の過剰強調 | "〜の処理を担当する" | 必須 |
| 2 | L78 | "速度、品質、保守性" | 9. 三点セット強制 | "速い (具体値)" | 警告 |

検出ゼロのときは「該当なし。次にセルフ監査パスのみ実施」と明記する。

末尾に **セルフ監査パス** を実施 (Process 章参照)。

---

## 保護フレーズ (誤検出しないこと)

技術記事で正当に使われる表現。検出対象から除外する。

- **手順説明**: 「次に〜」「まず〜」「最後に〜」
- **引用ブロック**: `> 〜` 内のテキスト
- **コード**: コードフェンス (` ``` `) 内のコメント・文字列・識別子
- **用語定義**: 段落内で初出の太字 (`**XXX**`) は1段落1回まで許容
- **出典明示**: 「公式ドキュメント (URL) によれば」など URL 付き引用

これらにマッチしたものは検出しない。

---

## パターン一覧

### 必須 (明確な AI シグナル / 検出したら直す)

#### 1. 意義の過剰強調

**兆候キーワード:** 「重要な役割を果たしている」「〜の象徴である」「〜という潮流の中で」「〜の本質である」「〜は欠かせない」「〜の中核を担う」

**問題:** 任意の対象に「広い文脈での重要性」を後付けで盛る。

**Before:**
> Redis のキャッシュ機能は、現代の Web アプリケーション開発において重要な役割を果たしている。

**After:**
> Redis をキャッシュとして使うと、DB への問い合わせを減らせる。

#### 2. AI 頻出語彙

**兆候キーワード:** 「シームレス」「俯瞰する」「〜という観点から」「不可欠」「極めて重要な」「飛躍的に」「劇的に」「徹底解説」「完全網羅」「ご紹介します」

**問題:** 2023 年以降の文章に異常な頻度で出現し、共起する。

**Before:**
> 本記事では Next.js 14 のキャッシュ戦略について徹底解説します。シームレスな開発体験を実現するために、極めて重要な機能となっています。

**After:**
> Next.js 14 のキャッシュ戦略の話。`revalidate` と `cache` を理解すると、ビルド時間と表示速度のバランスが取りやすい。

#### 3. 〜ing 的付け足し構文

**兆候:** 文末の「〜しており」「〜することで」「〜することにより」「〜という形で」「〜を実現しています」が、意義膨らましや因果ぼかしに使われている。

**問題:** 英語の現在分詞句 (-ing phrase) の翻訳調。論理を曖昧にする。

**Before:**
> SSR を採用しており、初期表示速度を改善することで、ユーザー体験の向上に貢献しています。

**After:**
> SSR を採用したので、初期表示が速い。

#### 4. 回りくどい繋辞

**兆候キーワード:** 「〜となっている」「〜とされている」「〜という位置づけにある」「〜と言える」「〜という側面がある」

**問題:** 「〜である / 〜だ」を避けて elaborate な言い回しに置き換える AI 癖。

**Before:**
> TypeScript はフロントエンド開発のデファクトスタンダードとなっている。

**After:**
> TypeScript はフロントエンド開発のデファクトスタンダードである。

#### 5. 同義語循環

**問題:** 同一対象を「ツール」「仕組み」「ソリューション」「フレームワーク」など別語で繰り返し言い換える。LLM の繰り返しペナルティが原因。

**Before:**
> このツールは便利だ。この仕組みは導入しやすい。このソリューションは多くの開発者に支持されている。

**After:**
> このツールは導入しやすく、多くの開発者に支持されている。

#### 6. チャットボット残留表現

**兆候キーワード:** 「ご質問ありがとうございます」「以下で詳しく解説します」「お役に立てば幸いです」「ぜひ参考にしてください」「最後までお読みいただきありがとうございました」

**問題:** チャット応答用テンプレが本文に混入。

**Before:**
> ご質問ありがとうございます！以下で詳しく解説します。

**After:**
> (削除)

#### 7. 知識カットオフ言い訳

**兆候キーワード:** 「執筆時点では」「私の知る限り」「公開情報の範囲では」「最新情報は公式を確認してください」

**問題:** モデル側の不確実性表現が記事本文に残る。

**Before:**
> 執筆時点では Next.js 14 が最新ですが、最新情報は公式ドキュメントをご確認ください。

**After:**
> Next.js 14 を前提にする (2026 年 5 月時点)。

---

### 警告 (使用自体は OK / 機械的多用や定型化が問題)

#### 8. 全角ダッシュ多用

**兆候:** 「—」「――」が 1 記事に 4 個以上、または短い段落に 2 個以上。

**Before:**
> Redis ―― キャッシュとセッションの両用で使える ―― は今も現役だ。

**After:**
> Redis はキャッシュとセッションの両用で使える。今も現役だ。

#### 9. 三点セット強制

**問題:** 列挙が常に 3 つ。

**Before:**
> このライブラリの強みは、速度、品質、保守性である。

**After:**
> このライブラリは速い (ベンチで N ms → M ms)。

#### 10. 太字の機械的多用

**問題:** 用語定義以外で動詞・形容詞まで太字化、1 段落に太字が 3 個以上。

**Before:**
> このアプローチは**シンプル**で**強力**であり、**多くの**開発者に**支持されて**います。

**After:**
> このアプローチはシンプルで強力。

#### 11. インラインヘッダー付き箇条書き

**兆候:** `- **XXX**: 〜` 形式が 3 個以上連続。

**Before:**
> - **速度:** 高速に動作します
> - **品質:** 安定したコードです
> - **拡張性:** プラグインで拡張可能です

**After:**
> 高速で安定しており、プラグインで拡張できる。

#### 12. 否定対比

**兆候キーワード:** 「〜だけでなく〜」「単なる〜ではなく」「〜にとどまらず」

**Before:**
> このツールは単なる CLI ではなく、エコシステム全体を提供する。

**After:**
> このツールは CLI とエコシステム両方を提供する。

#### 13. 曖昧な出典

**兆候キーワード:** 「業界では」「多くの専門家が」「いくつかの研究によれば」「広く知られている」「一般的に〜とされる」

**Before:**
> 業界では Rust のパフォーマンスが C++ に匹敵すると言われている。

**After:**
> [TechEmpower benchmarks Round 22](URL) で Rust 製 Actix が C++ 製と同等のスループットを記録した。

#### 14. 過剰ヘッジ

**兆候:** 「〜かもしれません」「〜と言えるでしょう」「〜のように思われます」が 1 段落に 2 個以上。

**Before:**
> このアプローチは効果的かもしれません。多くのケースで有用と言えるでしょう。

**After:**
> このアプローチは API リクエスト 1,000 回までの規模で有効。

#### 15. 結論定型句

**兆候キーワード:** 「いかがでしたか」「ぜひ試してみてください」「明るい未来が待っている」「皆様の参考になれば」

**Before:**
> いかがでしたか？ぜひ試してみてください。

**After:**
> 次は OpenTelemetry との統合を試す予定。

#### 16. 前置きシグナル

**兆候キーワード:** 「それでは見ていきましょう」「早速ですが」「ここからが本題です」「結論から言うと、〜が重要です」「順を追って説明します」

**問題:** 「これからやることを宣言する」テンプレ。本題に直接入れば不要。

**Before:**
> それでは早速、Cloudflare Workers の使い方を見ていきましょう。

**After:**
> Cloudflare Workers は `wrangler init` で雛形が作れる。

#### 17. 見出し直後の言い換え一文

**兆候:** `## XXX` の直後に「XXX は重要です」「XXX について説明します」など、見出しを言い換えただけの 1 行。

**Before:**
> ## キャッシュ戦略
>
> キャッシュ戦略について説明します。
>
> Next.js には〜

**After:**
> ## キャッシュ戦略
>
> Next.js には〜

---

## Process

1. 対象ファイル (`articles/*.md`, `qiita/public/*.md`, `hatena/**/*.md` など) を `Read` で取得
2. 必須項目から走査 → 警告項目を走査
   - 警告は「機械的多用 / 定型化」の閾値で判定
   - 保護フレーズに該当するものは除外
3. 検出結果を **テーブル形式** で出力
4. **セルフ監査パス** を実施
   - 自問: 「これらを直したとして、まだ AI 臭い理由は何か?」
   - 残留シグナル (リズムの単調さ / 一人称の欠如 / 揺れた意見の不在 / 具体の欠如) を箇条書きで指摘
   - 自問: 「では、どうすれば AI 臭くなくなるか?」
   - 構造的な改善案 (例: 「冒頭に体験談 1 段落」「中盤で迷いを残す」「具体数値を 3 箇所追加」) を提示
5. **ファイルは書き換えない。** 著者が判断して `Edit` 等で適用する

---

## 思想 (Philosophy)

### 魂を入れる

パターン除去だけでは、整っていて空っぽな文章 (=「クリーンだが魂がない」) になる。読み返して個人の痕跡が残っているか確認する。

- **意見を持つ:** 中立な事実羅列ではなく、好き嫌い・迷いを書く
- **リズムを変える:** 同じ長さの文を続けない。短文と長文を混ぜる
- **一人称を使う:** 「筆者は〜と考える」より「私は〜が気になる」
- **揺らぎを残す:** 「これは便利だが、別パターンの方が良い場面もある」のような余白
- **具体に降りる:** 「効率的」より「30 秒が 5 秒になった」

#### Before (クリーンだが魂なし)

> Cloudflare Workers は高速で、デプロイも簡単。エッジで動くため低レイテンシを実現する。

#### After (脈拍あり)

> Cloudflare Workers を初めて使ったとき、`wrangler deploy` から URL が叩けるまで 10 秒だったのに驚いた。Lambda の cold start で何度も心が折れた身としては、これだけで乗り換える価値があると思う。エッジで動くというより、CI が要らない感覚に近い。

---

## 出典

- [Wikipedia: Signs of AI writing](https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing) — WikiProject AI Cleanup が体系化した AI 生成文の特徴
- [blader/humanizer](https://github.com/blader/humanizer) — 29 パターン、英語向け、修正適用型
- [matsuikentaro1/humanizer_academic](https://github.com/matsuikentaro1/humanizer_academic) — 学術医学論文向けに保護フレーズを明示
- [m0370「Claude Code Skill: 日本語向け Humanizer を作った」](https://zenn.dev/m0370/articles/205c9340a418c3) — 16 項目の選定基準