Humanize Writing

AI 生成っぽさを検出し、人間が書いた文章として読める形へ戻す Skill。

中核は、説明を増やすことではなく、書き手の判断の跡を戻すこと。整った正論を並べるより、「なぜそうしたか」「どこを重視したか」が見える文章を優先する。

When to Use

• 原稿の AI っぽさ監査（レビュー型）
• 原稿の humanize / 文体修正（変換型）
• 最初から人間らしく書かせるための生成指示作成（生成指示型）
• 日本語記事（Qiita / WordPress / note）、英語記事（Medium）、技術ドキュメント、README
• キーワード: AIっぽさ, humanize, 人間らしく, 文体チェック, AI感, ChatGPT tells

Scope

• 太字・箇条書き・文長・読点・文末連続は印象でなく scripts/text_metrics.py で数える（標準ライブラリのみ。コードブロック・表・リンク URL は除外）。しきい値は指摘候補の目安で、ジャンルと引用を見て判断する。
• 他の日本語校正・文体調整 Skill が同時に有効だと指示が干渉し、出力が不自然になる。併用が疑われるときは片方を止めて再実行する。
• 記事を書く全工程で常時効かせる文体ポリシーは、ワークスペースの常時適用 instruction（あれば）に置く。
• 詳細な tell 辞書は references/ai-likeness-signals.md を参照する。
• 生成指示モードの長い追加指示は references/generation-style-prompt.md を参照する。

Operating Rules

• 文意・事実を変えない。直した後は、原文にあった条件・数値・制約の脱落と、原文にない主体・仕様・一般論の付加を別々に確認する。
• 事実の追加や未検証の断定語への書き換えをしない。
• 断定を増やすのは、根拠が既存本文にある場合だけ。
• 料金・仕様・preview など時点で変わる話題では、必要に応じて公開 Docs と調査時点を短く示す。仮定のトークン量・為替で比較したなら条件とキャッシュ・長文料金の除外を明示し、実請求額と混同しない。
• 敬体／常体、絵文字、温度感は既存優勢に合わせる。
• ユーザーが過去記事や文例を出した場合は、その voice を優先する。
• 単独の記号、整った文体、丁寧な構成だけで AI 判定しない。複数 tell の cluster として説明できるかを見る。
• 比喩や特徴語は印象で一律に削らない。語ごとに作品全体の出現回数、章内分布、文脈上の役割を見て判断する。複数章に分散して機能する語は voice として残し、同一章に集中する反復や、周囲の文体・抽象度から浮いて近傍の具体を言い直すだけの単発句は削るか具体化する。導入と終章で回収する比喩は、両端を残して中間だけを整理できる。同じ段落の 2 語でも、片方は削って片方は残す判断になり得る。
• 要注意語を機械的に全削除しない。SNS や話し言葉で意図的に効いている語は残してよい。
• 類義語の一対一置換で直した気にならない。禁止語を別の曖昧な語へ入れ替えても構文は直らない。規則を過剰に当てると大げさな造語が増えるため、主述と動作主を戻して一文で意味が通るかで直す。特に日本語の 速い / 早い は、速度、時期、理解しやすさのどれを言いたいのかを先に分け、必要なら しやすい や 早く〜できる にほどく。
• プロダクト、課金、契約まわりの用語は、直訳より業界で自然な日本語を優先する。必要なら公式英語を括弧で補う。技術用語も同じで、heartbeat を 心拍 と訳さず ハートビート とする。一方、IT で通じる語（決定論的 など）は無理に言い換えず、初出に括弧で平易な言い換えを添える（例: 決定論的（ルールベースの処理））。コンテキスト トークン プロンプト のように定着したカタカナ語も訳し替えない（文脈 に直すと硬い。ユーザー指摘あり）。
• 元記事の実験・統計 jargon (Treatment A / B / Cohort / Segment / Variant / Bucket) も同じ。日本語散文では自然な日本語 (パターン A / B / グループ / セグメント) を使い、初出にだけ パターン A (元記事内では Treatment A) のような括弧併記。scorecard の列ラベル / 見出し / 実装名 / feature flag など 技術ラベル は英語のまま残す。AI は英語をそのまま残しがちなので humanize バスで監視する。
• 直した後に、無難な啓発文へ寄りすぎていないか確認する。
• 検証記事では、画面表示・実測結果・完了結果・公式 Docs・未検証範囲を分ける。未実施の運用案を「普段は」「私は〜を見ます」と習慣化せず、読者の判断を変えない「未測定です」「確認できていません」の断りも書かない。読者の判断に効く未確認（料金など）は、否定文を重ねず「確認先」「聞くこと」の形で 1 箇所にまとめる。本文は結論と必要な留保に絞って詳細ログを表・付録・注記へ逃がす。
• 同じ留保・前提（例: 1 回分の表示、試算であり実請求額ではない）が複数節・手順・まとめで繰り返されていたら、出現箇所を数え、TL;DR の要約以外は最も必要な 1 箇所に寄せる。削る前に残す先へ同じ条件が実際に書かれているか確かめ、削る文にしかない条件（用途の注意、比較条件の違い）は残す先へ移す。
• 文字数超過を理由に根拠、測定条件、留保を削る前に、媒体の上限とユーザーが許容する長さを確認する。許容範囲が不明なら、勝手に圧縮せず確認する。短縮するときは具体例・行動・結果の文を残して抽象的なまとめ文を削る。具体文を削ってまとめだけを残すと、短くなっても AI 臭が強まる。短縮・書き換えで新しく書いた文自体も tell 辞書で読み直す。
• 文体修正だけでは直らない体験不足・判断不足は、捏造せず 【← ここに〜】 のような穴として返す。
• 自称を三人称ニックネームで呼んだ表現（◇◇視点 ◇◇個人の ◇◇的には）を見つけたら 振り返り 個人の 私は など中立表現に置き換える。タイトル直下の挨拶・署名だけは認める。ユーザーが「痛い」と感じる長期トリガーなので、一件でも見逃さない。

Workflow

1. 入力の目的を判定する。
   • 監査だけ: 問題箇所、カテゴリ、置換案を返す。
   • 直して: before / after か差分案を返す。
   • 生成指示: generation-style-prompt.md を基準にプロンプトを作る。
2. 媒体、想定読者、voice を確認する。
   • Qiita / WordPress / note / Medium / README など。
   • 想定読者が前提にできない専門用語だけ、初出で短く補う。
   • 文例があれば、文の長さ、段落長、つなぎ語、句読点、言い切りの強さを合わせる。
3. 次の順でスキャンする。
   • 事実が変わっていないか。
   • 書き手の主語と判断が見えるか。
   • 抽象語やつなぎ語で説明しすぎていないか。
   • 構造が均一すぎないか。
   • 長文生成に混ざる字形崩れが残っていないか（Generation Artifacts）。
   • 主語がモノで動詞が比喩（壊れる・倒す・溶かす・潰す）になっていないか、これ 両者 片方 が指すものを具体名詞へ戻せるか（Japanese Signals）。
4. 詳細 tell が必要な場合は ai-likeness-signals.md を使う。
5. 同じ箇所に複数の tell が重なる場合は stacking pattern として 1 件にまとめる。
6. 変換型では初稿後に「まだ AI っぽく見える理由」を短く洗い出し、必要な箇所だけ最終稿で直す。
7. 最後に声に出して読んだとき、同僚や知人にそのまま話せる文かを見る。
8. For important drafts where same-model self-review is insufficient, run one different-model or subagent skeptic pass. Verify quoted text and line numbers against the actual draft before acting on feedback.

Fix Order

時間が限られているなら上から順に処理する。下位だけ直しても AI 臭は残る。

1. 立場 — 反証可能な具体的主張があるか。重要だ 本質的だ で終わらせない。
2. 主体 — false agency（モノが主語で人間の動詞）をなくし、誰が何をしたかを書く。
3. 構造 — 命題型の見出し（H2 / H3）、テンプレ序文、ムラの欠如を崩す。
4. 語彙 — 偏愛語、横文字メタファー、副詞スタックを削る。
5. 記号 — 全角ダッシュ、不要な「」、中黒並列、装飾絵文字を整理する。

High-priority Signals

• 定型接続詞: つまり 要は 言い換えると で説明をまとめる。
• 抽象語: かなり 十分 活用 効率化 価値 で丸める。
• pivot 構文: A ではなく B A というより B で観察の代わりに対比を置く。節の冒頭を A だけでは決めません と否定から始めるのも同類。比較でも 〜級とは言えません 〜に届かない見込み のような否定の評価を置かず、比較相手と数値の事実だけを書く。
• 例の偏り: ツールの使い分け記事で例がコード修正・テスト・ログ調査だけに寄る。要約・調査・文書作成など読者の日常業務も並べ、筆者が試していない例は「〜なら〜で足ります」の勧め方で書く。
• 抽象比喩の二項対比: 治療になるか加速剤になるか のように、強い比喩を二択で置いて主張を大きく見せる。何が起きるかをそのまま書けるなら、比喩より現象を優先する。見出しも同じで、〜と同じ線上にあります 〜の延長です のような位置関係の言い回しにせず、内容を直接言う（例: クラウドの安いモデルに回すのも手です）。ユーザー指摘あり。
• 判断ログ露出: 元の図を採用しなかった理由 のような制作判断・検証経緯を TL;DR / 見出し / 本文 / 出典欄に流さない。読者に必要な出典 URL・測定条件・留保は残す。
• 効果・姿勢の宣言: 効きます 正面から 多角的に 掘り下げる が、観察や判断の代わりに置かれる。
• 主観動詞型の前振り: ここで一気に効いたのが ここからが一番ピンと来た話 など、接続詞の代わりに 効いた ピンと来た のような主観動詞を置く。ここまでの話の核になるのが ここで関わってくるのが などにほどく。
• 主語混線: 自分がやったこと、AI にやらせたこと、公式情報からの引用が混ざる。
• 構造の均一化: 段落長、見出し語尾、箇条書き数が揃いすぎる。追記節を **ラベル**: 説明 の箇条書き 3 点で足すのも同類。1 つの流れなら短い段落で書く。
• 副詞偏愛 cluster: 1 記事内で 個人的に 本当に ちゃんと ものすごく など同じ副詞が 3 回以上出たら、個々は High でなくても累積で AI 臭になる。箇所リストを作って 3 件以上は減らす。
• 英語 tell: delve, leverage, robust, Let's dive into, In conclusion, Not just X but Y。

Output

詳細テンプレ（Review / Rewrite / Self-scoring / Anti-patterns / Example Prompts）は references/output-templates.md を参照する。要点だけ:

• 監査: AI-likeness Audit 形式で High / Medium / Low + Structure を返す
• 変換: before / after または修正文。一括置換しない
• 生成指示: 文体指示プロンプトを返す（生成指示モード）

Done Criteria

レビュー型:

• 問題箇所を行番号または引用付きで列挙している
• 各問題にカテゴリと置換案がある
• 同じ箇所の重複シグナルを水増ししていない
• 単独 tell で決めつけず、cluster / stacking pattern として説明できるか確認している
• 温度感（敬体／常体／絵文字）が記事全体で一貫している
• 事実、感想、意図が混線していない
• 一般論ではなく、書き手の判断が読めるか確認している
• 実測結果、公式ソース、AI が補った整形結果が混ざっていない
• TL;DR・本文・まとめで推奨や結論が食い違っておらず、原典より強い断定（引用符を付けた言い換えを含む）がない

生成・変換型:

• 同じ書き出し・同じ文末が 3 連続していない。ただし番号付き手順や仕様の列挙など、形が揃うこと自体が正しい箇所は、他の tell と重ならない限り直さない
• 原文の条件・数値の脱落も、原文にない主体・仕様の付加もない
• 抽象語ではなく具体語で書いている
• 自分がやったこと、AI にやらせたこと、引用したことが主語レベルで分かれている
• 文例がある場合、その人の voice に寄っている
• 初稿後に残った AI っぽさを 1 回だけ自己監査し、最終稿で潰している
• 直した後も、動機・迷い・判断が必要な分だけ残っている

References

• output-templates.md — 出力テンプレ、Self-scoring、Anti-patterns、Example Prompts
• ai-likeness-signals.md — 詳細 tell 辞書
• generation-style-prompt.md — 生成指示モードの追加指示
• iKora128/stop-ai-slop-jp (MIT) — 修正優先順位と 5 軸採点の発想を参考にした
• nanaism/yomiyasu (MIT) — 無生物主語・比喩動詞・指示語の復元と、太字・箇条書き密度の計測という観点を参考にした（文面は転載せず自分の言葉で書き直した）
• k16shikano/japanese-tech-writing (Unlicense) — LLM 口調と技術文書の誠実さの観点を参考にした