writing-guide

name	writing-guide
description	AI臭さを消す汎用執筆ガイド。ブログ・資料・スライド・書籍など、あらゆる書き物で使える文章スタイルルールと、説明文の組み立て方（用語の導入・例示の粒度・数字の扱い・段落設計・読者への態度）
user-invocable	true
model	opus

汎用執筆ガイド — AI臭さを消す文章術

技術ブログ、社内資料、手順書、スライド、書籍など、あらゆる書き物に共通する文章スタイルルール。 各プロジェクト固有ルール（CLAUDE.md等）と併用して使う。

このスキルの使い方

執筆作業時の「品質チェックリスト」として使う。

1. 執筆前: このルールを頭に入れてから書き始める
2. 執筆中: AI臭い表現が出てきたら即座に書き直す
3. 執筆後: 完成した文章を禁止リストと照合してセルフレビュー

**「提案段階のドラフト」も執筆として扱う。**本文候補の1段落・見出し案・キャッチコピー案をユーザーへ提示する時点で、すでに禁止リストの検品対象。承認後・反映時に直せばよいと後回しにすると、初稿の型（逆接タメ・「のです」締め・比喩スローガン締め等）がそのまま指摘対象になる。

**200〜300字の短い対外文こそ検品対象。**登壇のセッション概要、イベントページの掲載文、プロフィール紹介文、書籍の内容紹介など、外部に載る短い紹介文は「原稿ではないから」「短いから」と素通りしやすい。しかし短い文ほど最後の一文が目立つので、キメ台詞構文（「〜のは◯◯です」）が締めに紛れ込む確率はむしろ高い。書く前にこのスキルを開き、書いたあとに最頻出パターン6つと照合してから提示する。

　直し方は言い換えではなく削除。この種の締めは、直前の文で内容が完結しているところへ教訓を足しているだけなので、平明な言い方へ置き換えても蛇足のまま残る。

何度も再発している最頻出パターン（書き終えたら、まずこの9つを見る）

下の禁止リストは長いので、再発指摘を受けた回数が多いものだけをここへ抜き出す。書いた直後にこの9つだけは必ず自分で見返す。全部が下の表にも載っているが、表の中に埋もれると素通りしてしまう。

1. 段落末の回収まとめ文（「これが◯◯の形です」「〜という方針は、こうして形にできます」「〜と考えると整理しやすくなります」「◯◯そのものです」）。**記録上いちばん再発している型で、しかも既存原稿より自分が新しく書く文で出る。**説明が済んだ直後に抽象ラベルへ包み直す一文を足さない。言い終えたらそのまま終える

2. 「効く」の全用法（効く／効きます／効いてきます／効かせる）

3. ダッシュ（—、──、―、- での区切り）

4. 体言止めの列挙を「。」で締める（「〜する会議のメモ。」）→ 「〜など。」で終わらせる

5. こなれ比喩動詞でのキメ（届かない／拾ってくれます／地続き／一撃で／仕込みます）

6. 一段落が長いまま改行しない（とくにMEMO・コラムなど囲みの中）

7. AIの挙動を断定する（「〜されます」と一通りに言い切る。実際は複数のやり方がありうる）

8. 箇条書きの行頭を「太字ラベル＋コロン」で始める（「- 見た目を自分で決められる：HTMLの体裁は〜」）。§1 の「項目名: 説明のセット形式」と「太字の多用」が同時に出る型で、説明文をREADME・報告・資料へ書くときにほぼ毎回出る。直し方は言い換えではなく箇条書きごと地の文の段落へ戻す（ラベルを外して並べ直すだけだと、今度は同じ構文の箇条書きが残る）。2つ3つの項目を立てたくなったら、それは段落1つで書ける内容だと考える

   ⚠️ ただし「箇条書きを使うな」ではない。禁じているのは行頭太字＋コロンという形であって、箇条書きそのものではない。 このルールを丸ごと適用して地の文だけで押し通すと、条件の列挙まで段落へ溶けて逆に読めなくなる。地の文へ戻すのは「1段落で書ける内容を2〜3項目に割ったとき」だけで、並列に並ぶ条件・対象・例外が4つ以上あるなら箇条書きが正しい。判断基準は §6 の「GitHubのREADME」節にある形の選び方の表を使う

9. 成果物への絵文字の散布。見出しの頭（## 🚀 アプリ）、箇条書きやカードのアイコン代わり（📊 パワポ作るマン）が二大パターン。**1個ずつ見ると可愛いが、並ぶと一気にAIが書いた資料になる。**装飾として足したくなった箇所は、何も足さないのが正解。チャットの応対に絵文字を混ぜるのは別ルール（~/.claude/AGENTS.md 冒頭）なので混同しない

※ ただしそのプロジェクトで承認済みの正式概念語は対象外。例：ある書籍で「ガードレール」を節見出しに採用しているなら、その本の中では禁止語ではなく用語として扱う。禁止語の一括 grep を機械実行しないのはこのため（誤検出が多すぎて使われなくなる）。

1つ目だけは字面 grep で検出できない（決まり文句を持たないため）。段落の最終文を1つずつ読み、「この文を削って段落を読み直したとき、失われる情報があるか」で判定する。残りは機械で拾えるので、書いた直後に流す：

rg -n '効[くきい]|効か|—|──|手が止ま|だったりします|合図です|届かない|地続き|一撃で|仕込[みむ]|拾ってくれ|たちが悪い|下ごしらえ|腑に落ち|泣きどころ|方向感|驚くほど|一気に|劇的に|目に見えて|構いません|構わない|ToDo|TODO' <file>

8つ目（行頭の太字ラベル）は語彙ではなく形なので、別に1本流す。ヒットしたら箇条書きごと地の文へ戻す：

rg -n '^\s*[-*] \*\*|^\s*[-*] <b>' <file>

9つ目（絵文字）も形の問題なので機械で拾える。成果物ファイルに対してだけ流す（設定ファイルやルールのメモで ⚠️ を目印に使うのは対象外）：

rg -n '[\x{1F300}-\x{1FAFF}\x{2600}-\x{27BF}\x{2B00}-\x{2BFF}\x{FE0F}]' <file>

この語彙列を固定版と思わないこと。指摘を受けるたびに増える。記憶ベースの検品はすり抜けるので、書き換え文をファイルへ当てた直後に必ず機械実行する。長い文書を継続的に触るなら、禁止語チェックをベースライン方式（ゼロ強制ではなく実測値を上限にし、正当な例外は理由つきで据え置く）でスクリプト化して常設するとよい。

登壇スライドの見出しは、文体を混ぜて型の反復を数える

社外の登壇・講義スライドの見出しは、文体を混ぜる。揃えた瞬間にAI臭くなる。 全部敬体も全部常体も避ける。基本は常体で、体言止めの短いラベル・「！」・口語の独白・敬体の落としを混ぜる。「！」を捨てないこと（読み物向けの「！の多用禁止」は登壇スライドに当てない）。社内の審査・決裁向けプレゼンだけは全枚を敬体で揃えるのが正。

文体の落差を作ったうえで、AI臭さは型の反復として残る。1枚ずつ見ると自然な日本語なのが厄介で、全ページを縦に並べて初めて分かる。 書き終えたら rg -n '^# ' <file>.md で全タイトルを出し、次の3つを数える。

1. 読点でタメて短く落とす二部構成（「覚える言葉は、この3つだけ」「大変なのは、作る前の前工程」）。読点を外すか普通の一文へ戻す
2. 接続詞・副詞で頭を揃える（しかも／実は／ちなみに／ただし／例えば／まずは／最後に）。1枚ずつは自然でも、全ページが同じ拍で始まると機械的に聞こえる。接続の言葉は口で言えばよいのでタイトルからは落とす
3. コロン見出しの連発（「品質：」「量：」「場所：」…）。軸の提示自体は有効だが、同じ型が3枚以上続くと整理癖の署名になる。あえて型を揃えないほうが人間らしい

「〜のは〜です」のキメ構文（「本当に怖いのは、人間側の慣れです」）と、禁止語「効く」「仕込む」「こぼれる」はタイトルにも普通に入るので、本文と同じ基準で見る。

そして語尾。常体にするとき、敬体で書いた文の語尾だけを付け替えない（割に合いません→割に合わない、育ちました→こうして育った、伸ばせます→伸ばせる）。座りが悪くなり、ほぼ確実に指摘される。体言止め・勧誘形「〜しよう」・「！」へ作り直す。口語の砕けた語尾「〜てる」（い抜き）「〜ばいい」「〜んです」も同じくAI臭い。砕けさせるなら「OK」（「大丈夫」より）・「〜の？」（「〜？」より）・「〜しよう」。検査は rg -n '^# .*(てる|ばいい|んです)$' <file>.md でゼロを確認する。

---

1. AI臭い表現の禁止リスト

以下はAI生成文章に頻出し、読者に「AIが書いた感」を与えるパターン。意識的に避ける。

文体で避ける表現

禁止パターン	なぜダメか	代替
太字（**...**）の多用	AIが「重要」と判断した箇所を機械的に太字にしがち	本当に強調が必要な箇所のみ。基本はベタ書き
無生物主語の英語直訳構文（「使いすぎはまず待ち時間として現れる」「中心になるのは〜することと…への備えです」「〜を確かめる習慣が、この攻撃への備えも兼ねます」）	英語の "X manifests as Y" などを直訳したような書き方で、日本語として不自然。抽象名詞・「こと」・「習慣」を主語に立てたら疑う	人や動作を主語にした普通の文に開く（「使いすぎたときに起きるのは、追加の請求ではなく待ち時間です」「〜を分解し、…にどう備えるかを考えていきます」）
ダッシュ（—、──、―、- での区切り）	AI特有の区切り表現。絶対に使わない（ユーザー明示の最重要事項。スライドのタイトル・本文・blockquote すべて）	「…」、読点、または文を分ける
「項目名: 説明」のセット形式	AIのリスト化癖の典型パターン	本文ベタ書き、または見出しレベルで構造化
タイトル・見出しでのコロン多用	「XX：YY」はAIが構造化しようとして多用する	カギカッコ、読点で繋ぐ。またはサブタイトルを省いてシンプルに
見出しの「です・ます」調	全部敬体だと冗長でAIっぽい	言い切り・体言止めにする（「〜できる」「〜が必要」「〜の3ステップ」）。本文の地の文も常体寄りにし、呼びかけだけ敬体。 ⚠️ 話すスライドは、社外の登壇と社内の審査・決裁で正反対なので取り違えない。 ・社外の登壇・講義スライド＝基本は常体、ただし文体を混ぜる。体言止めの短いラベル・「！」・口語の独白・敬体の落としを織り交ぜ、全枚を同じ文体で揃えない ・社内の審査会・決裁プレゼン＝敬体が正。話し手が口に出す言葉として、敬体のほうが自然で人柄も出る。加えて理想を語る枚では断定より願望＋熱量が効く（「会社にする」→「全員が…会社にしたい」／「増やす」→「増やしたい！」）
引用・キャッチ・本文の締めを全部「体言止め」で揃える	名詞止めが連続すると「標語の貼り紙」化し、人の声が消えてAI臭が出る。上行のタイトル体言止めとは別問題で、こちらは"連続・均一"が悪い	動詞で言い切る／本音（「正直〜」「〜してしまっています」）／問いかけを混ぜ、文末のトーンを散らす。体言止めは数回まで。毎スライド機械的に引用で締めるのもやめ、本当に必要な所だけに絞る。※この行は引用・キャッチ・締めの話で、書籍・記事の見出し文末には適用しない（見出しは「セールスコピー化」行のとおり漢語動名詞の体言止めが基本。「動詞で言い切る」を見出しに持ち込むと逆にAI臭くなる）
「！」の多用	AIが親しみやすさを演出しようとする	自然な文末表現。本当に強調したい時だけ。 ⚠️ 人前で話す登壇スライドの見出しは例外。実物は7〜20%の枚に「！」が付いており、テンションの主役になっている。ここでゼロにすると書き手の資料に見えなくなる
過剰な接続詞の連打	「さらに」「加えて」「また」「一方で」が毎段落	文の流れで自然につなぐ。不要な接続詞は削る
「〜することができます」	AI頻出の冗長表現	「〜できます」で十分
「〜を活用する」の乱用	AIが「使う」の代わりに多用する	素直に「使う」「利用する」
公開プロフィール・対外向け実績紹介で、掲載先や登壇先を「先方」「お客様側」と呼ぶ	自社内メモの相対呼称。掲載先や登壇先の本人が読むと、よそ者扱いする距離感が出る	組織名・媒体名をそのまま主語にする（「ASKUL Engineering BLOGに当日の講演レポートが掲載されている」）。組織名を伏せる場合は「主催者の公式ブログ」など役割で書く
「〜についてご紹介します」	AI文章の定型オープニング	いきなり本題に入る
「6つのデプロイ先を回ります」のように具体的な行為を抽象動詞に言い換える	「紹介する」という具体的な行為を「回る」などの抽象的な移動表現に置き換えるのは、日本語として不自然でAI臭い	「今日はこれらについて紹介します」のように、行為をそのまま具体的な動詞で言う

構成で避けるパターン

• アジェンダ・目次の自動挿入: 短い文章では不要。中身に集中する
• まとめセクション: 読めば分かることを繰り返さない
• 均等に網羅的なリスト: AIは漏れなく列挙しがち。重要なものだけ厳選する
• 「以下の通りです」→ 箇条書き: 毎回このパターンだと機械的に見える
• 結論の先出し + 箇条書き展開: AI文章の定型構造。文脈に応じて構成を変える

---

2. 人間味を出すテクニック

AI臭さを消す最大のコツは「その人にしか書けない要素」を入れること。

個人の経験・考察を入れる

• 「実際に触ってみた」姿勢を貫く。評論ではなく、自分の手で動かしてから書く
• うまくいかなかった点も正直に書く（失敗談は最高の人間味）
• 「個人的に注目しているのは〜」「これは正直微妙で〜」など主観を恐れない
• 背景やストーリーを添える（なぜこれを書こうと思ったか、何がきっかけか）
• 著者の意思と異なる内容を勝手に生成しない。壁打ち・すり合わせを経てから書く

比喩と噛み砕き

• 専門用語は初出時に日本語補足をカッコ書きで添える
  • 例: Function Calling（関数呼び出し）
• 「すごく雑に言うと」方式で厳密な定義をかみ砕く
• 比喩は身近で大胆に使う
  • 例: LLMを「ドラえもん」、コンテナを「使い捨ての仮想PC」
• ただし特定分野の素養を前提にする比喩は使わない。特に野球など スポーツ用語の比喩（「打率を気にせず」等）は不可。書き手自身が スポーツに詳しくなく、読者にも前提知識を要求するため、 「当たり外れ」など誰にでも通じる語へ開く
• 抽象→具体→比喩の3段階で説明すると伝わりやすい

読者に寄り添う

• 安心フレーズを入れる: 「他はデフォルトのまま」「ここだけ押さえればOK」
• 先回りトラブルシューティング: 読者がハマりそうなポイントを事前に説明
• 前提知識を仮定しすぎない: 初心者がついてこられるか常に意識

登壇のセッション概要・対外紹介文の型

イベントページに載るセッション概要、書籍の内容紹介、プロフィール文など、外部に載る短い紹介文は正確なだけでは通らない。2026-08-14、Qiita Conference 2026 Autumn の概要でユーザーが3箇所を直した。その基準が次の3つ。

①数字には出所を添え、読み手の語彙で言う

❌ 編集させたファイルの8割以上は日本語の書類です ✅ 統計データを見ると編集させたファイルの8割以上は日本語テキストファイルです

数字を裸で置くと主張に見えるが、出所を1語添えるだけで実測値だと伝わる。あわせて「書類」→「テキストファイル」のように、聴衆（この場合はエンジニア）が普段使う語で正確に言い直す。

②対象を否定形で語らない

❌ 素のClaude Codeだけではできないことも多く ✅ 素のClaude Codeだけではあと一歩足りないことも多く

「できない」は製品を貶める形になる。「あと一歩足りない」なら、惜しいところまで来ている前提が読み手と共有され、そこを埋める本題へ自然につながる。

③締めは説明ではなく、絵が浮かぶ言葉にする

❌ 本セッションでは、何が足りず、どう埋めてきたのかをお見せします ✅ 本セッションでは、メガシンカした私のAI秘書を徹底解剖します

「何が足りず、どう埋めてきたか」は正確だが平板で、読んだ人の頭に何も残らない。**メガシンカ・徹底解剖のようなカルチャー由来の語や強い動詞を恐れない。**ユーザーの文体は「正確かつ楽しい」で、正確なだけの案は却下される。

⚠️ この3つ目は §1 の「比喩キャッチフレーズ禁止」と矛盾するように見えるが対象が違う。禁止しているのは書籍・記事の本文で概念に比喩ラベルを貼って繰り返す行為で、こちらは告知文で読み手を引き込む言葉選び。媒体で使い分ける。

---

3. 情報密度のコントロール

箇条書きのルール

• 3〜4項目が上限。それ以上は分割するか、本文で説明
• 階層は1段まで。深くても2階層。3段以上のネストは読者が迷子になる
• 各項目は1〜2文。長い項目は本文に戻す

1トピック1ブロック

• スライドなら「1スライド1メッセージ」
• ブログなら「1段落1トピック」
• 書籍なら「1節1テーマ」
• 詰め込みすぎず、段階的に理解を積み上げる（ビルドアップ型）

---

4. 表記ルール（媒体共通）

コード表記

• インラインコード（`）の前後に半角スペースを入れる
• コードブロックには必ず言語を指定する（python, sh 等）
• コードはそのままコピペ可能な状態で掲載する

主語と動作主

• 曖昧な動作主は明示する
  • NG:「設定される」→ OK:「ユーザーが設定する」「システムが自動設定する」
• 受動態より能動態を優先

製品名・ツール名はアルファベットのまま書く

• 製品・ツール・エージェントの名前をカタカナに開かない（NG:「コーデックス」 OK:「Codex」。Claude Code、Bedrock なども同様）。2026-07-24、AI Dev Day登壇アプリのスライドで「コーデックス」を Codex へ直すようユーザーから指示があった
• 一方、概念や一般名詞のカタカナは開いてよい（「ハーネス」「エージェント」等）。避けるのは固有の製品名をカタカナ表記にすることだけ

日本語の太字と全角約物（CommonMark flanking）

太字の範囲は全角約物（（）「」『』【】、。！？）の手前で切るのが既定（正本ルールは ~/.claude/AGENTS.md「表示・文章ルール」）。太字の内側の先頭・末尾に約物が来ると、CommonMark の flanking 判定で ** が記号として認識されず、画面に ** がそのまま出る。markdown-it（CommonMark 準拠）で実証した崩れ条件の全パターン：

並び	例	結果
閉じ ** の直前＝約物、直後＝日本語文字	**前者（冒頭に立てる）**を採りました	❌ 崩れる
開き ** の直前＝日本語文字、直後＝約物	ご提案のうち**（冒頭）前者**を採りました	❌ 崩れる
閉じ ** の直後が句点・約物	**前者（冒頭に立てる）**。	✅ OK
閉じ ** の直後が半角スペース	**前者（冒頭に立てる）** を採りました	✅ OK
開き ** の直前が読点などの約物	ご提案のうち、**（冒頭）前者**を採りました	✅ OK
太字の内側が約物で始まらず約物で終わらない	**前者**（冒頭に立てる）を採りました	✅ OK

条件が細かいので、太字の範囲を約物の手前で切る（最終行の形）を既定の書き方にする。それが不自然なときだけ半角スペースを足す。外部投稿前の機械検証（npx --yes markdown-it <file>.md | grep -n '\*\*'）は AGENTS.md「文章と表示のルール」を参照。

---

長い日本語テキストを書いた直後は、非日本語文字の混入を機械検査する

日本語の長文生成では、ハングル・簡体字・キリル文字が低頻度で1語だけ紛れ込むことがある（「拡張子까지示され」「риск は実験段階であること」の実例あり）。見た目が漢字・かな・カタカナに似ているため目視では拾えない。対象は Markdown だけでなく HTML・スライド原稿を含む、外部の目に触れる日本語テキスト全般。 書いた直後にこれを通す：

rg -n '[가-힣一-鿿Ѐ-ӿ]' <file> | rg -v '[ぁ-んァ-ヶ]' | head

前段でCJK全体とキリル文字を拾い、後段でかな交じり行（＝正常な日本語行）を落とす。残った行だけ目で見る。キリル文字はかな交じり行にも紛れるので、Ѐ-ӿ だけは後段のフィルタを外した rg -n '[Ѐ-ӿ]' <file> でも別に見る。

5. 説明文の組み立て（ブログ・資料・手順書・書籍で共通）

§1〜§4 が「表記と、使ってはいけない表現」なのに対し、この節は「読者に届く説明の作り方」。書籍の品質基準として数か月・数十回の赤入れをかけて固まったルールのうち、書籍という媒体に依存しない部分を抜き出してある。

用語の導入

• 語注が要るかは「その語をIT以外の職種の同僚が会話で使うか」で判定する。 業界で日常語化したカタカナ語（オプトアウト、スコープ、ハンズオン等）は、書き手の感覚では説明不要に見えて読者には未知、という取りこぼしが一番多い
• ただし語注は第2手。 専門語に説明が要ると気づいたら、まず「その語を使わずに書けないか」を問う。自分で名付けた語なら（§1「命名の儀式」）、語注を足すより語ごと廃すほうが早い
• 平易な言葉へ言い換えた機能・設定は、初出で正式名称を1回だけ併記する。 実体（ファイル名・設定名・機能名）がどこにも書かれないと、初心者は語の揺れで迷子になり、詳しい読者は公式ドキュメントと照合できなくなる。主役は平易な日本語のまま、正式名は括弧で小さく添え、2回目以降は繰り返さない（くどくなる）
• 英字の正式名の直後の区切りはコロン。 例：RAG（Retrieval-Augmented Generation：検索拡張生成）。カタカナの読み・語源と説明の区切りは句点のまま（「permissions。許可設定」）
• 括弧語注は必ず真の初出に置く。定義より前の行に裸の用語が出ていないか、登場順で確認する
• 用語の補足は抽象的な定義でなく読者の身近な体験に引きつけて書く（SSO＝「会社のGoogleアカウントなど、普段の社内アカウントでそのままログインできる仕組み」）

例示

• 例は「読者が自分に翻訳できる普遍原則」の粒度で選ぶ。 語レベルの癖の羅列も、書き手の個人ネタも、読者は持ち帰れない。複数並べるなら1本ずつが別の原則を代表する形にする
• 場面は読者層に普遍的なものから選ぶ。 自分の実体験がニッチなら、同じ構造を持つ普遍的な場面へ翻訳してから書く
• 例文は業務常識と整合させる。 時制・因果・手順の前後関係が現実の仕事の流れとして成立するかを、文体チェックとは別に読み直す（「来週の出張の精算」のような業務上ありえない例は、文体レビューだけだと何周も生き残る）
• 具体例の名詞は、締めの一文へ単語だけ差し込まず場面設定の文から同じ例で通す
• 同じ具体例を離れた場所で再演しない。読者はうんざりする。同じ論点に再度触れるときは別の角度・別の例にする

数字と効果

• 所要時間・効果の数値は実測・実体験の裏付けがあるものだけ書く。「5分から10分です」型の未検証の断定をしない。軽さ・速さを伝えたいなら、働き方のニュアンスで描く
• 全称の限定語（どれでも・何でも・必ず）を外す。 例外に当たった読者が不信感を持つ。かといって「〜の場合もあります」を並べる保険で防御的にもしない。限定語を外した肯定形の平叙文にすると、分かりやすさを保ったまま例外に耐える
• 数字を裸で置くと主張に見える。出所を1語添えるだけで実測値だと伝わる（「統計データを見ると、8割以上は〜」）
• 負担の軽さを「読むのに1分もかかりません」のような具体的な時間で誇張しない。「時間はかかりません」で足りる

段落とリズム

• 印字換算300字を超えたら分割を検討する。「ただし」「なお」で話が転じる箇所、事例・手順へ切り替わる箇所が切りどころ。逆に、最後の結論文が段落全体を受けている段落は、字数が多くても切らない（結論が片方にぶら下がって論理が痩せる）
• 1〜2文の短い段落を連続させない。 同じ話題が続くなら1つへ統合し、改行は話題の切り替わりに置く。長短の交互で緩急を作る
• 同じ文末（「〜できます」等）を3連続させない。同音・同語の連続は音読で拾う（「過剰な箇条書き」＝「かじょう」が2回でダジャレに見える）
• 図は、その図を説明している段落の直後に置く。 見出しの直後にいきなり図を置かず、何のまとめかを示す本文を1段落挟む。囲み・引用ブロックを連続させず、間に本文を挟む

読者と当事者への態度

• 読者になりうる当事者を批判調で書かない。 経営層・情報システム部門・セキュリティ担当・取引先など、説得の相手として描く人自身が読者になる。「〜は分かっていない」「〜の罠」型のあるある批判は、当事者が自分を否定されたと感じる。相手の意図（安全に進めたい等）をまず肯定し、「その意図を最短でかなえる方法はこちら」へ転換する。時代や環境の変化を主語にして、誰も悪者にしない
• 読者以外の第三者を主語に立てて行動を求めない（「情報システム部門がこの問いから考え始めると〜」）。読者の立場を先に置いて並べるか、主語を省く
• 読者の現状のやり方を貶める情緒語（惨め・ばかばかしい）を使わない。手間の大変さは事実（時間・根気）で描く。読者はまさに今その手作業をしている人
• メタな弁明を本文に置かない。「〜とは言えません」「値札は付けられません」型の限界宣言は、AI臭いうえに読者が知りたい実質まで消す。断定を避けたいなら、事実の選び方（検証可能な数値＋両端の実例）で正確さを担保する

呼びかけと引用

• 読者にやってほしい操作・規律は**「〜しましょう」が基本形**。平叙の「〜します」で書くと説明文に紛れて指示が届かない。ただし機械的な全置換はしない（「しましょう」が続くと単調で洗練されなく見える。周囲の平叙文と主語なしで揃える場面は「します」でよい）
• 頼み方や思い込みの例を鍵カッコで並べたら、「と＋動詞」を直結させず「などと」で受ける。引用が唯一の言い方に読めてしまう
• かぎ括弧のセリフを「」「」。と地の文なしで並べて終えない。 間接話法へ開くか、「〜と伝えます」のような地の文で受ける
• 読者の内心は「」で代弁してから答える。ただし地の文に口語の終助詞（「〜ますよね」）を置かない

分量の制約は、まず情報を落とさない手段で吸収する

「1行はみ出した」「ページに収まらない」を、本文・説明・図の削除で解決しない。削るのは最後の手段で、その前に情報量を保つ吸収手段を順に試す。

1. 組版・CSS・レイアウト側の設定を変える（行間・図の大きさ・段落の余白）
2. 2つの段落を1つに統合する、冗長な言い回しを詰める（意味は残す）
3. 図の再掲・移動で送りを調整する
4. どうしても削るしかないなら、削る対象を先に提示して承認を取る

「1行削れそうなところ」を探す裁量に、読者向けの語釈・用語説明を消すことは含まれない。用語の初出説明・製品の位置づけ・前提の1文は、字数調整の対象外として扱う。

「本人の運用」を書くときは、実物の記録から型を採る

ユーザーの仕事のやり方・プロンプトの投げ方・作業の流れを書く場面では、想像で組み立てず、実際の記録を検索してから書く。もっともらしい手順ほど、本人にしか分からない粒度でリアリティが破綻する。

• 探し先は案件フォルダと、~/.claude/projects/*/*.jsonl の過去セッション（ユーザーの発話だけを jq で抜けば軽い）
• 教科書的に見栄えのする工程を足さない。 「メモを取る」「振り返る」「フィードバックする」は、本人がやっていなければ書いた瞬間に嘘になる
• 実例は過去実績を引く形で書く。「この間の発表は◯枚で5分余った。今回ぴったり終わらせるにはどう調整する？」のように、本人が実際に持っている情報を入力にする

6. 媒体別の参照先

このスキルは汎用ルール。媒体固有の詳細は各プロジェクトの CLAUDE.md を参照する。

媒体	追加で確認すべきこと
技術ブログ（Qiita等）	タイトル術、SEO、スクリーンショット活用、速報性
スライド（Marp等）	テーマ・クラス指定、段階的ビルドアップ、セクション区切り
書籍	DTP制約（横幅・見出し・ページ構成）、表記揺れ統一、校正ルール
お客様向け資料	社内用語の言い換え、配慮ある表現
GitHubのREADME	見出しは機能名、形の選び方、細部を書かない。下の「GitHubのREADME」節
メール（業務・個人名義）	型・削るもの・敬称。下の「7. 対外文面の型」節
議事録・共有資料	分量の圧縮、宿題を書かない。下の「7. 対外文面の型」節

GitHubのREADME（公開リポジトリ）

自作アプリを公開リポジトリで配っていると、READMEを書く場面が繰り返し来る。売り込みすぎても素っ気なさすぎても差し戻されるので、その両方を同時に満たす基準を置く。

読者は目次から機能を探しに来る。 ここが書籍・ブログとの一番の違いで、READMEは通読される文章ではなく参照される一覧に近い。だから次の3つが同時に効く。

• 見出しは機能名の名詞にする（§1 の禁止リストにある2行が正本。主な機能／対応エージェント／スマホとの連携／頼み方の例／セットアップ の5語は採用実績あり）
• H1直下にキャッチコピーのblockquoteを置かない。 冒頭は「◯◯は、〜するツールです」の説明文から始める
• 1つの節が5段落を超えたらH3で割る。 見出しがないと読者は目的の記述へ飛べず、頭から全部読むはめになる

形は情報の性質で選ぶ。「AI臭さを避ける」を理由に全部を地の文にしない。

情報の性質	形	例
並列に並ぶ条件・対象・例外が4つ以上	箇条書き	対応している環境、動かない条件、既知の制限
3つ以上を同じ観点で見比べる	表	モードごとの用途と表示内容、プランごとの可否
因果・理由・仕組みの説明	地の文	なぜ同じ発言が二重に記録されるか
順番に実行する操作	番号リスト	インストール手順

細部は書かない。 内部ファイルの形式（index.jsonl の中身、画像がJPEGであること）、失敗時のふるまい、実装の都合は、フォルダを開けば分かるか、そもそも読者が最初に必要としない。READMEに載せる価値があるのは、動かす前に知らないと困ることだけ。

既存ルールとの関係。 READMEは既出のルールが集中的に当たる場所なので、他媒体の学びを流用できる。

• §1 の最頻出パターン8番（行頭太字＋コロン）は形の禁止であって箇条書きの禁止ではない。ここを取り違えると今回の差し戻しになる
• §1 の「見出しのセールスコピー化」（書籍向け）と同じ癖が、READMEではランディングページ調として出る。売り文句・動詞の見出し（「はじめる」「できること」）は書籍の目次と同じ理由で却下される
• §3「箇条書きは3〜4項目が上限、階層は1段まで」はREADMEでもそのまま適用する
• 「情報量は増やしてよいが、読み方を覚えさせる仕掛けは増やさない」と発想が同じ。READMEでも、事実の行数を増やすのはよいが、独自の記号・凡例・抽象ラベルを増やさない
• 成果物なので絵文字は散らさない（§1 の9番）。チャットの応対と混同しない

商業書籍はまず「出版社のハウススタイル」を合わせる

　商業書籍の文体を既刊書に寄せるときは、まず出版社を一致させる。同じ著者でも出版社ごとに書式の流儀が違い、別社の本を手本にすると流儀が混入する。たとえば同じ技術書でも、出版社によって次のように分かれる：

• H3 に連番を振らず、本文中で用語を太字にしない（** は **COLUMN** 等の構造マーカー専用）。図表は「図1.1」「表1.1」＋脚注
• H3 を「5.1.1」の連番にし、本文中で用語を太字にする

　手本にする既刊を選ぶ順序：①同じ出版社 → ②同じ編集者 → ③同じ著者。書式（見出し連番・太字可否・キャプション）は必ず同じ出版社の本で裏取りする（grep '\*\*' 等で実データを確認し、思い込みで断定しない）。