Humanize Writing

Humanize Writing

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

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

When to Use

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

Scope

• この Skill は監査・変換という特定タスクの手順書。
• 記事を書く全工程で常時効かせる文体ポリシーは .github/instructions/writing-style.instructions.md を使う。
• 詳細な tell 辞書は references/ai-likeness-signals.md を参照する。
• 生成指示モードの長い追加指示は references/generation-style-prompt.md を参照する。

Operating Rules

• 文意・事実を変えない。
• 事実の追加や未検証の断定語への書き換えをしない。
• 断定を増やすのは、根拠が既存本文にある場合だけ。
• 料金、仕様、preview、公開価格の有無など時間で動く話題では、必要に応じて公開 Docs ベースと調査時点を短く明示する。
• 敬体／常体、絵文字、温度感は既存優勢に合わせる。
• ユーザーが過去記事や文例を出した場合は、その voice を優先する。
• 単独の記号、整った文体、丁寧な構成だけで AI 判定しない。複数 tell の cluster として説明できるかを見る。
• 要注意語を機械的に全削除しない。SNS や話し言葉で意図的に効いている語は残してよい。
• プロダクト、課金、契約まわりの用語は、直訳より業界で自然な日本語を優先する。必要なら公式英語を括弧で補う。
• 直した後に、無難な啓発文へ寄りすぎていないか確認する。
• 文体修正だけでは直らない体験不足・判断不足は、捏造せず 【← ここに〜】 のような穴として返す。

Workflow

1. 入力の目的を判定する。

• 監査だけ: 問題箇所、カテゴリ、置換案を返す。
• 直して: before / after か差分案を返す。
• 生成指示: generation-style-prompt.md を基準にプロンプトを作る。

2. 媒体と voice を確認する。

• Qiita / WordPress / note / Medium / README など。
• 文例があれば、文の長さ、段落長、つなぎ語、句読点、言い切りの強さを合わせる。

3. 次の順でスキャンする。

• 事実が変わっていないか。
• 書き手の主語と判断が見えるか。
• 抽象語やつなぎ語で説明しすぎていないか。
• 構造が均一すぎないか。

4. 詳細 tell が必要な場合は ai-likeness-signals.md を使う。 5. 同じ箇所に複数の tell が重なる場合は stacking pattern として 1 件にまとめる。 6. 変換型では初稿後に「まだ AI っぽく見える理由」を短く洗い出し、必要な箇所だけ最終稿で直す。 7. 最後に声に出して読んだとき、同僚や知人にそのまま話せる文かを見る。

Fix Order

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

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

High-priority Signals

• 定型接続詞: つまり 要は 言い換えると で説明をまとめる。
• 抽象語: かなり 十分 活用 効率化 価値 で丸める。
• pivot 構文: A ではなく B A というより B で観察の代わりに対比を置く。
• 判断ログ露出: 正本として扱う 今の読み方 など、執筆時の整理を本文へ出す。
• 効果・姿勢の宣言: 効きます 正面から 多角的に 掘り下げる が、観察や判断の代わりに置かれる。
• 主語混線: 自分がやったこと、AI にやらせたこと、公式情報からの引用が混ざる。
• 構造の均一化: 段落長、見出し語尾、箇条書き数が揃いすぎる。
• 英語 tell: delve, leverage, robust, Let's dive into, In conclusion, Not just X but Y。

Review Output

監査結果は次の形式で返す。検出ゼロの場合でも、温度感、見出し、まとめの最終チェックを書く。

## AI-likeness Audit

### High-priority (要修正)

- L42 「つまり、〜」 -> 定型接続詞。削除 or 具体語
  before: つまり、サービス名に近い根拠を優先します。
  after : サービス名に近い根拠を優先する、という順番です。

### Medium

- L58-L62 文末「〜でした」x4 連続 -> 一部崩す

### Low (任意)

- L110 「かなり読みやすい」 -> 具体数値があれば置換

### Structure

- 見出し語尾: 8 箇所中 7 箇所が「〜した」 -> 1 箇所変える
- 段落長: 全段落 3-4 文で均一 -> 短段落を 2 つ混ぜる

Rewrite Output

• 原則は before / after で返す。
• 長文を丸ごと直す場合は、変更理由を先に短くまとめ、本文をその後に出す。
• 置換は一括処理しない。つまり や かなり のような語も、文脈上必要なら残す。

Done Criteria

レビュー型:

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

生成・変換型:

• 同じ書き出し・同じ文末が 3 連続していない。
• 抽象語ではなく具体語で書いている。
• 自分がやったこと、AI にやらせたこと、引用したことが主語レベルで分かれている。
• 文例がある場合、その人の voice に寄っている。
• 初稿後に残った AI っぽさを 1 回だけ自己監査し、最終稿で潰している。
• 直した後も、動機・迷い・判断が必要な分だけ残っている。

Self-scoring

判断に迷うときは 5 軸で 1-10 点を付ける。合計 35/50 未満は再修正の合図。

• 立場 — 反証可能な具体的主張があるか
• リズム — 文長と段落長にムラがあるか
• 主体性 — 誰がやって何を判断したかが読めるか
• 具体性 — 抽象語ではなく固有名・数字・場面が出ているか
• 削減 — 削っても意味が変わらない文を残していないか

Anti-patterns

• 全文を機械的に置換する。
• 専門用語まで噛み砕き、読者層を無視する。
• 絵文字を足して親しみやすく見せる。
• 内部資産名や執筆時の判断ログを公開文に並べる。
• 事実・感想・意図を 1 文で全部処理する。
• 書き手の判断を消し、誰が書いても同じ一般論だけにする。
• ユーザーの口癖や署名表現まで矯正する。

Example Prompts

• この記事のAIっぽさを監査して
• humanize this draft
• 文体チェックだけして、修正はしないで検出だけ出して
• 生成指示モードで、次の記事の指示プロンプトを作って
• つまり・要は・かなり・十分 の残りを全部探して
• 説明文ではなく、判断の跡が残る文章にして

Standard Output

• 監査: AI-likeness Audit
• 変換: before / after または修正文
• 生成指示: 文体指示プロンプト

References

• iKora128/stop-ai-slop-jp (MIT) — 修正優先順位と 5 軸採点の発想を参考にした。
• k16shikano/japanese-tech-writing (Unlicense) — LLM 口調と技術文書の誠実さの観点を参考にした。

AI-likeness Signals

Humanize Writing の検出辞書。検出は厳密に、修正は文脈判断で行う。

Scan Priority

1. 事実が変わっていないか 2. 書き手の主語と判断が見えるか 3. 抽象語やつなぎ語で説明しすぎていないか 4. 構造が均一すぎないか 5. 反証可能な主張になっているか

Japanese Signals

English Signals

Structure Signals

• Paragraph lengths are too uniform. Mix in one- or two-sentence paragraphs.
• Heading endings repeat too much. Change at least one if all headings end the same way.
• Lists always collapse to 3 or 5 items. Use the number the content actually needs.
• A short post has both a neat 3-point summary and a 2-point advice list. Return one list item to prose or keep only the needed count.
• The opening has too much runway: disclaimers, background, glossary, digressions. Put the main claim, axis, or TL;DR first.
• Every heading has a one-sentence intro. Delete intros that only restate the heading.
• A paragraph cannot say what it receives from the previous paragraph, what role it plays, or what it passes to the next paragraph. Treat it as an argument-flow gap.
• Public-facing paragraphs explain internal structure too long. Write what became easier for the reader or operator.
• Fact, feeling, and intent are mixed in one paragraph. Separate numbers, hand-feel, and aim.
• All paragraphs have the same heat. Let important sections carry more weight.
• Observation is preceded by a label such as 〜として見ると追いやすい or 〜に見える. Put the observed fact first.
• The framework announced in the opening does not match the section structure. Remove, move, or fold out-of-axis topics.
• Sentence length variance is too low. Mix short and long sentences intentionally.
• The ending follows a problem-to-future template. Close with a concrete next action.
• The ending has multiple routes for the reader. Keep one main route and move the rest to references.
• Documentation or comments narrate the diff (added this, replaced the old approach) instead of describing current behavior. Unless it is a changelog or migration guide, write what the thing does now.
• The prose turns ordinary claims into aphorisms (X is the language of Y, X becomes a trap, X is a mirror). Replace the formula with the concrete claim.
• Several clipped fragments stack up to manufacture drama. One short emphatic sentence is fine; repeated fragments should become ordinary prose.
• Bold-label vertical lists repeat (**Speed:**, **Quality:**, **Security:**). Keep only when the list is genuinely useful; otherwise fold the points into prose.

Detection Notes

• When multiple tells overlap in the same sentence or paragraph, report them as one stacking pattern.
• Count em dashes, triples, repeated endings, and same-shaped lists instead of relying on impression.
• Say which structure creates the AI-like feel before saying it is AI-like.
• Prioritize sentences that catch when read aloud.
• For texts under 300 Japanese characters or 100 English words, add a confidence note because false positives are more likely.

False Positive Guard

• Perfect grammar, tidy headings, and readable tables are not AI tells by themselves. Professional editing and CMS templates can produce the same surface.
• Em dashes, curly quotes, transitions, or polite openings count only when they appear with other formulaic tells.
• Preserve specific, hard-to-fabricate details, era-bound phrasing, mixed feelings, and word choices the writer can defend.
• For technical, legal, reference, or encyclopedic text, neutral and plain may be the right human voice. Do not inject personality where the genre calls for restraint.

Experience-writing Signals

• Separate I did this from AI did this at the subject level.
• Include the improvement process when only the result is written.
• Separate lived experience from knowledge added through AI or Web search.
• Do not mix fact, feeling, and intent in one sentence.
• Prefer wording that shows how the writer judged the situation.
• For API / MCP / CLI results, separate observed output from model-readable formatting.
• Remove process logs that do not help readers; keep outcomes and judgments.
• Do not end with instruction phrases such as 〜を意識すべき or 〜が大事 unless the reason is already in the text.

Generation Style Prompt

Humanize Writing の生成指示モードで使う追加指示。

## 文体指示

- 1 文 1 アイデア。長い文は切る
- 同じ書き出し・同じ文末を 3 連続させない
- `つまり` `要は` `かなり` `十分` `実は` は使わない
- `言い換えると` `要するに` で説明をまとめない
- `〜の方が安全です` で判断を逃がさない。根拠があるなら `〜です` `〜として扱います` に落とす
- 抽象語（重要性・効率化・活用）より具体動詞を選ぶ
- `効く` `効いた` は禁止しない。対象と変化が書けないときだけ、確認できた変化や助かった場面に言い換える
- `正面から` `多角的に` `掘り下げる` のような姿勢宣言で埋めず、何を見て何を判断したかを書く
- プロダクト名、課金語、契約語は直訳しない。日本語として不自然なら、業界で通る語に直す
- `A より B` `〜の話では終わらない` `〜に見える` のような整理用フレーズで段落を運ばない
- `面白いのは` `印象に残ったのは` `気になったのは` で観察を前置きしない
- 観察した事実を先に書き、判断ラベルは必要なら後ろに短く置く
- 日本語本文では、日本語と独立した半角英数字・英単語の境目に必要に応じて半角スペースを入れる
- `33件` `24本` `5名` `11社` `WS資料` のような数詞+助数詞、略語+名詞の密着は優先的に見直す
- 略語・英字と直後の括弧書きの間にも半角スペースを入れる（例: `2FA (2 要素認証)`）
- `GH-300` `#49` `1on1` URL のような一体で読む ID・型番・記号列は崩さない
- handbook / playbook / checklist / SSOT などの内部資産名を公開文に列挙しない
- `正本として扱う` `今の読み方` `この記事では〜として扱う` などの判断ログを公開文に出さない
- 何を管理したかより、何がやりやすくなったかを書く
- 数字、手応え、狙いを同じ段落で混ぜすぎない
- 正論を整然と並べるより、動機・迷い・判断が少し見える文を優先する
- まとめは教訓で締めすぎず、現在地や次にやりたいことで閉じる
- 見出し直後に、見出しを言い換えるだけの 1 文を置かない
- 同じ箇所に別のテンプレ表現を重ねて直さない
- 1 段落だけ急に広報文・論文調・輸入文みたいに浮かせない
- AI が何をやったか／人間が何をやったかを主語で分ける
- `〜として機能する` `〜の役割を果たす` より `〜です` `〜である` で済ませる
- 同一概念を言い換えで回さない。同じ語の繰り返しを恐れない
- `専門家は〜` `〜と言われている` で帰属をぼかさず、出典を名指しするか自分の判断として書く
- API / MCP / CLI の応答を書く場合は、サーバーが返した生データ、AI が補った URL や要約、著者が記事用に添えた参照を混同しない
- 価格、preview、仕様差分のように動きやすい話では、必要に応じて `YYYY-MM-DD 時点の公開 Docs ベース` と分かる注記を入れる
- 文例がある場合は、その voice を mirror する
- 初稿後に「まだ AI っぽく見える理由」を短く洗い出し、必要な箇所だけ最終稿で直す

## English notes

- Do not use: delve, tapestry, realm, leverage, ever-evolving, seamless, robust, embark, unlock, harness
- Do not open with: `Let's explore`, `Let's dive into`, `step-by-step guide`
- Do not rely on: `Furthermore`, `Moreover`, `That said`, `In conclusion`, `Ultimately`
- Avoid: `Not just X but Y`, `It's not about X, it's about Y`
- Use at most one em dash per paragraph
- Do not close with templated friendliness such as `I hope this helps!`

Final Check

• 声に出して読んで、同僚や知人にそのまま話せる文かを確認する
• 名詞だけ入れ替えても成立しそうな generic 文になっていないかを見る
• 1 段落だけ別の人が書いたように浮いていないかを確認する
• 段落ごとに、前から何を受け、本文で何を果たし、次へ何を渡すかが読めるか確認する
• 単独の記号や整った構成だけを理由に崩していないか確認する