japanese-tech-writing
Skill0 starsChanged 31 days agoMITView on GitHub
日本語の社内文書と技術文書の文章規範。結論先行、見出しへの結論埋め込み、固有名詞と実数による接地、確信度のラベル化、段落構造などの整形、パラグラフライティングによる段落と論証の構成、論証の厳密さ、読み手の負荷の管理、視点と語り、演出の抑制、LLM っぽい空句の禁止、翻訳調の比喩と擬人化の禁止、冗長の排除、文の読みやすさ、読者への誠実さを定める。調査レポート、議事録、社内ガイド、企画書、設計文書のほか、技術書の章や記事を日本語で書くとき、または推敲やリライトをするときに使う。
15 other projects use a version of this, 13 of them edited.
Adopted by
Most recently taken up by
- msageha/skillsedited, first seen Nov 8, 2026
- H-ymt/skillsedited, first seen Nov 8, 2026
- snowkiss13/ja-writing-normsedited, first seen Nov 1, 2026
- fujita-pineal/claude-skillsedited, first seen Nov 1, 2026
- ymuichiro/auto-research-skilledited, first seen Oct 15, 2026
- takatoku23/my-ai-skilltheir own version, first seen Oct 11, 2026
Used with
Projects with it also use cognitive-rhythm-writing.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
trappleSkillcognitive-rhythm-writing
Japanese writing rules for designing cognitive rhythm (緩急) in explanatory prose — treating pacing not as decoration but as switching of the reader's cognitive modes (observe → waver → assert → re-examine) and management of unresolved tension. Covers sentence beats, paragraph density waveforms, section openings, telling slack from filler, and a mechanical post-writing inspection procedure. Companion layer on top of japanese-tech-writing. Use when writing chapters, articles, or explanations meant to be read as engaging prose, when diagnosing or fixing dense-but-flat writing, or when user says "認知リズム", "緩急をつけて", "平坦で退屈", "リズムを設計", or "cognitive-rhythm-writing".
Also in 8 projects that use this
Other versions15 projects use a version of this.
Word for word · 0
None found.
Edited · 13
- aToy0m0/skills★ 259% same
- fujita-pineal/claude-skills★ 241% same
- ymuichiro/auto-research-skill★ 248% same
- himadajin/skills★ 156% same
- mjun0812/skills★ 152% same
- H-ymt/skills★ 060% same
- ivgtr/claude-skills★ 059% same
- krkrkrr/skills★ 059% same
- ktateishi/skills★ 055% same
- msageha/skills★ 056% same
3 more not listed
Wrote their own version · 2
- hideki5123/agent-skill-set★ 2same name
- takatoku23/my-ai-skill★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository13 other files it gives its agents.
- ai-credit-efficient-reviewSkill
- branch-tldrSkill
- drafting-tweet-from-todaySkill
- finding-unused-customizationsSkill
- hacker-news-digest-jaSkill
- natural-japaneseSkill
- pr-branch-composition-checkSkill
- prompt-feedback-skillSkill
- resume-improverSkill
- semantic-commit-helperSkill
- session-stockerSkill
- syncing-forked-skillsSkill
- tf-destroy-plan-inverterSkill
The file
Files
日本語文書の文章規範
日本語の文書を書くとき、または推敲するときは、以下の規範に従う。
主対象は社内文書である。調査レポート、議事録、社内ガイド、企画書、設計文書のように、通読されるより拾い読みされる文書を想定している。書籍の章や記事のような読み物にも使えるが、両者で判断が分かれる箇所は社内文書の側に寄せてある。読み物にだけ当てはまる箇条には冒頭に (読み物) を付けたので、社内文書を書くときは読み飛ばしてよい。節の全体が読み物寄りの場合は、その節の冒頭で断ってある。
規範は多いので、一度にすべてを守ろうとせず、四つのパスに分けて適用する。推敲やリライトの依頼では、設計パスと執筆パスの規範も点検の観点に加える。
- 設計パス:本文を書く前に「設計」で読者、主メッセージ、見出しスケルトン、濃淡を決める。
- 執筆パス:「整形」「段落と論証の構成」「読み手の負荷の管理」「視点と語り」「見出しの付け方」に従って書く。
- 論証点検パス:書き上げたら「論証の厳密さ」「読者への誠実さ」で論理の穴を点検する。
- 表現点検パス:最後に「演出の抑制」「LLM っぽい表現の禁止」「翻訳調の比喩と擬人化の禁止」「冗長の排除」「文の読みやすさ」で文面を点検する。
設計
本文を書き始める前に決める。ここを飛ばすと、後段で「一般論しか言えていない」と気付いても直しようがない。
- 誰が読み、読んだ後に何が起きてほしい文書かを特定する。わからなければ依頼者に聞く。
- 主メッセージを一文で書く。書けないなら素材不足であり、書き方の問題ではない。
- 見出しスケルトンを作り、見出しだけを順に読んで論旨が通ることを確認してから本文に進む。
- 節ごとの濃淡を先に割り振る。重要な節を厚く、軽い節は正直に軽く書く。全節を同じ厚みで書くと、それ自体が整いすぎた不自然さになる。特筆すべきことがない節は「この節に特別な示唆はない」と書いてよい。
- ただし「どれにも等しく当てはまる」ことが主張の核であれば、同格に見えるのが正しい。
- 濃淡は強弱であって順序づけではない。内容がもともと持っていない段階や優先順位を付けない。普遍的な枠組みを説くはずの文章が「まずこれ、次にこれ」という段階導入にすり替わるのが、その典型である。
- 主張を支える固有名詞、年月、実数を先に集める。手元になければ、何を確認すれば書けるかを一言添えて空欄を残す。
整形
- 段落の区切りは空行で示す。
- 日本語テキストと英単語・数字の間には半角スペースを入れる。「GitHub リポジトリ 1」のように、境界ごとに一つずつ置く。
- コード、差分、ログ、設定ファイルの断片はコードブロックで示す。
- インラインコードは、その文脈で重要な変数名・関数名・識別子・記号にだけ使う。コードブロックはこの制限の対象外とする。
- 絵文字を使わない。
(読み物)用語の由来や定式化の名称など、本筋から一段外れる補足は、本文に並べず脚注 ([^ラベル]) に降ろす。- 定義や分類の列挙は箇条書きで示してよい。定義される用語は太字にする。太字を使ってよいのは、この用語定義と、「演出の抑制」で認めた論理の要所に限る。
- 用語を本文中で初めて定義・導入するときも、その語は太字にする。すでに導入した語を話題として指すとき、引用、通称には「」を使い、太字と使い分ける (初出の定義は太字、以後の言及は「」)。
- ダッシュ (em ダッシュ
—、horizontal bar―、いわゆる 2 倍ダッシュ——) を日本語の地の文・見出しで使わない。同格・補足の挿入A——挿入——Bは丸括弧に、言い換え・敷衍A——Bは句点で二文に分けるか読点でつなぐ。範囲を示す en ダッシュ–や英語の複合語 (Curry–Howardなど)、コードブロック・書誌情報は対象外。 - 丸括弧は半角
()を使い、全角の丸括弧を使わない。半角スペースは括弧の外側にだけ置き、内側には置かない。閉じ括弧の直後が句読点や閉じ括弧のときは、外側のスペースも置かない。 - 中黒 (・) を日本語の並列で使わない。ただし単一の固有名詞の内部では使ってよい。
- 見出しに、区切り線 (罫線
─U+2500 やダッシュ類) で「種別──主題」「主題──概念」のように二要素を詰め込まない。見出しは単一の自然な句にする (要素を一つに絞るか、助詞・読点でつなぐ)。 (読み物)コラム見出しも「基礎」「補足」のような種別名だけで済ませず、「同値関係としての分類」「ループ不変条件と帰納法」のように内容を特定する。- 用語とその定義を並べる箇条書きは、区切り線ではなく全角コロンで「用語:説明」と書く。
- 箇条書きをネストするときの字下げ幅は半角スペース 4 文字とする。
段落と論証の構成
パラグラフライティングを基本とする。段落は論証の一歩であり、読者は段落単位で論理を追えなければならない。
- 結論は冒頭に置く。「本稿では〜について述べる」のような前置きを書かず、タイトルと最初の一文に結論を渡す。長い文書では冒頭に結論、数値、スコープを 3,4 文の要約として置き、本文はその裏付けにあてる。
- 論証は一方向に進める。冒頭で示した結論を、本文の途中で何度も言い直さない。反論と疑念は本文で処理する。
- 結びは要約の繰り返しにせず、要点を 1,2 文に再統合する。調査や分析の文書は事実の記述で終えず、その結果から次に何をすべきかへの接続を最低 1 段落書く。ただし根拠が支える範囲を超えた処方は書かない。書けるだけの根拠がなければ、事実の再統合で止めてよい。
(読み物)物語的に運ぶ章では、反論と疑念の処理を終えてから、結論を末尾に一度だけ置く構成をとってよい。- 一つの段落には一つのトピックだけを置く。場面の進行 (調査、報告、検証、評価) が複数混ざった長い段落は、一歩ずつの段落に分割する。
- 段落の最初の文を読めば、その段落が何の話かわかるようにする。
- 段落の先頭では、前の段落との論理関係を接続表現で明示する (「であれば」「実際」「しかし」「この例自体からも」)。
- 因果と経緯は、接続詞でつないだ地の文で書く。箇条書きにしてよいのは、項目が同じ文法構造、同じ抽象度で本当に並んでいる場面に限る。「整形」で認めた定義や分類の列挙や、議事録の決定事項一覧のように項目それぞれが独立した担当者と期日を持つ場合がこれにあたる。
- 見出しの直後に箇条書きが三つ以上並んでいたら、項目間に「そのため」「だが」で言える関係が隠れていないか疑う。隠れているなら地の文に戻す。
(読み物)例への弁明 (作為的に見える、への先回りなど) は、場面の山場の直後に挟んで流れを切らない。次の節の冒頭でまとめて処理する。- 読者が立てそうな誤った解釈は、明示的に否定してから本当の理由を述べる (「その理由は『〜だから』ではない。〜だからだ」)。
- 「A ではなく B」と否定するときは、否定の根拠を一文添える。反実仮想 (「もし A なら、〜だっただろう」) が使えることが多い。
- 同じ概念を二つの対象で対比定義するときは、両文の述部を同じ型にする。既出の説明の回収は文頭の枠に置き、定義そのものを「〜だと説明した」に埋め込まない。特徴の句は「」で切り出し、対比の接続を明示する。第二極について続ける属性は、主語を改めて名乗らず継承する。
- 譲歩 (「確かに〜」) では、事実の確認にとどめる。あとで訂正する内容を著者の声で因果として断定すると、自己矛盾になる。表面的な診断を一度認めたいときは、読者や通説の声に帰属させる (「〜と要約できてしまうかもしれない」)。
(読み物)山場で印象づけたい情報 (数値、固有の事実) は、その手前の段落で先出ししない。- 何かを否定・限定するときは、否定する命題そのものを「」で正確に書き出す (「明文化されていればすべてを任せられる」を意味しない、など)。「何もかもが解決するわけではない」のような漠然とした否定で済ませない。
- 「後の章で扱う」のような前方参照は、論証が一段落した位置 (段落末・節末) に置く。論証の途中に挟んで流れを切らない。
論証の厳密さ
文章の論理にツッコミどころを残さない。書き上げたら、読み手の反論を先回りして次の点を点検する。
- 確信度は語尾のぼかしで均さず、ラベルで書き分ける。未検証の内容は【要確認】、推定にとどまる内容は「〜と推定する」と書く。全文に「〜と思われます」をまぶして確信度を均さない。ラベルは角括弧で目立たせ、本文の文体に紛れさせない。
- 事実は出典やデータとともに書き、意見には「筆者は〜と考える」のような話者標識を立てる。文末の形では事実と意見を区別できない。出典を示せない事実は、事実として書かない。
- 推量・可能性・読者の疑念・反実仮想として書かれている文を、機械的に断定へ変えない。 「かもしれない」「だろう」「ようだ」「らしい」は、根拠なく主張を弱めている場合だけ削る。 事実未確認の可能性、作中人物の認識、ログからの推定、読者が抱きそうな疑念、反実仮想を表す場合は、その不確実性を保つ。 社内文書では、保った不確実性を語尾に置いたままにせず、上のラベルに移す。 断定に直せるのは、本文内の根拠によって命題が確定している場合に限る。 悪い例:「提示し続けているかもしれない」を「提示し続けている」に変える。 良い例:「提示し続けている可能性がある」のように、不確実性を残して文を整える。
(読み物)作中人物の認識や読者が抱きそうな疑念を地の文で描く場面では、ラベルではなく語尾で不確実性を保つ。- 異なるものを「同じ」とまとめない。区別すべき対象 (別々の決定、別々の原因、種類の違う問題) を一括りの言葉でくくらない。悪い例:相互依存する三つの未決事項を「同じ決定を別々に下していた」と書く。良い例:「どれも別々の決定であり、しかも互いに依存している」と腑分けする。
- 複数の要因がある事象を、単一の原因に還元しない。例が複数種類の問題を含むなら、それぞれを切り分け、どの道具がどれを説明するのかを対応づける。悪い例:契約の不在と情報隠蔽の失敗が混ざった事故を、丸ごと「情報隠蔽の問題」と説明する。
- 章・節をまたいで、同じ概念の扱いを一致させる。ある節で「人間が決める」と分類したものを、別の節で「チームで合意する」と書かない。分類・定義・用語の地位は全体で揃える。
- 因果を主張するときは、その機構 (なぜそうなるのか) を一文で示す。「A だと B になる」とだけ書いて理由を省略しない。悪い例:「手順で分けると変更が全体に波及する」。良い例:「各工程がデータを受け渡すための表現を共有してしまい、その表現を変えると全体に波及する」。
- 検出・保証・解決を「必ず」できるかのように書かない。条件付きで正確に述べる (「〜しやすい」「〜できることが多い」「〜が成り立つときに限り」)。
- 主張は、挙げた例が実際にその全体を支えているかを確認する。例が主張の一部しか支えないなら、主張の範囲を例に合わせて狭める。
- 「次節で扱う」と前方に逃がした論点は、本当にそこで回収されることを確認する。回収しない伏線を張らない。
- 譲歩や限定 (「ただし」「とはいえ」) を置いたら、その後で必ず論を進める。逆接で終えて宙吊りにしない。
- 節の中心となる語は、その節以前に定義・対象範囲を述べてから使う。定義せず使い始めない。
- 複数の概念を一つの上位語にまとめるときは、命名の直前に、それらが同じものに帰着すると一文で述べる。腑分けの逆の操作にも橋を架ける。
読み手の負荷の管理
読者の記憶と注意は有限の資源として扱う。ただし、負荷を下げることと中身を薄めることは別である。
- 主張を支える固有名詞、年月、実数は必ず書く。段落から固有名詞と数値と実例をすべて抜いても文意が変わらないなら、その段落はまだ一般論の域を出ていない。抽象的な主張が三文続いたら、書き方ではなく素材が足りていない。
- 省いてよいのは、主張の裏付けにならない装飾的な固有名 (後で参照しないファイル名や識別子) と、装飾的な精度 (時刻、HTTP ステータス、カバレッジ率) だけである。
- 読者が順読みで保持する情報は、一度に一段だけ増やす。一段で足りる許可や読み方は、含みに頼らず直接書く。記述を削ったら残った言及を辿り、この文書のほかで使われなくなった主題は落とす。
- 抽象的な言い回しの指す内容が文脈から一意に決まらないときは、可能なときは丸括弧による同格挿入でその場で特定し、できるだけ読者に前を読み返させない。
- 概念を初めて示す文では、その概念が何であるか (データ構造、手順、制約などの種類や地位) を、読者が順に読んだだけで読み取れる語順にする。その概念を既に知っている読者にだけ自然な性質や仕組みを、種類の同定より前に置かない。前置すると、未習の読者は読み終えた時点で逆戻りしなければ核となる情報を掴めない。
- 新しい例や場面を追加して、読者が保持すべき文脈が増えるときは、前の例と何が違うのか、なぜもう一つ必要なのかを前置きして納得感を与える。
- 同一節内に図、表、コードなど複数の提示があるとき、各媒体が担う説明 (配置の見え方、数値、手順など) を分けて書く。媒体間で型やデータを揃える必要はなく、別例として並べてよい。指示語 (「この 2 つ」「上記の例」) は、どの媒体のどの例を指すか文脈だけで一意に決まるように置く。一つの媒体で確認した性質を、別の媒体の例にもそのまま当てはめない。二方式を「A の代わりに B」と対比するときも、やめる側と採る側の語順を置換関係と一致させ、後に書く側が採用される方式であることを順読みで読み取れるようにする。
- 章冒頭や節の導入では、これから例で扱う内容に関係しない過剰な詳細を詰め込まない。
- 例の節の中でも、その節の問いや帰結に関係しない過剰な詳細だけを省く。議論に必要な具体は残す。
視点と語り
- 専門用語は、まず現象や機能を平易な言葉で説明し、そのあとで「これを〜と呼ぶ」と名前を渡す。名前を先に投げない。初出に括弧内の一言注釈を添えるだけでも同じ効果が得られる。
- 例示では、結果の羅列や受動態 (「特定され、判明した」) ではなく、行為者を主語にした動作の連なり (「リポジトリを調査して特定し、見つけてくれた」) で書く。
- 「入社 2 年目のエンジニアが」のような架空の人物設定を無意味に冠しない。
- 論証の中で読者を「あなた」と呼ばず、役割名 (「開発者」「読者」) で書く。二人称の呼びかけは、場面への導入 (「〜としよう」) や章の結びなど、限られた要所にとどめる。
- 対象を指す語は具体的に選ぶ。「AI」「ツール」のような広い語でぼかさない。
- 章や節で定式化・術語 (K、契約、不変条件など) を導入したら、以後はその語で通す。「文脈」「ツール」「AI」のような曖昧語に後退しない (定式化する前の導入語として「文脈」などを使うのはよい)。
- 一般的な英単語を地の文にそのまま置かず、定着したカタカナ語か和語に寄せる (
pathはパス、ruleはルール)。ただし固有名詞、製品名・サービス名、リソース名、その分野で定着した略称は英語表記のままでよい。 - 術語・訳語は、その分野で慣用されている語を選ぶ (プッシュ通知は「配送」ではなく「配信」、など)。意味の近い漢語を一般語の感覚で充てない。
(読み物)人物そのものに言及するときは原綴りで書く (Lehman、Bainbridge)。ただし、歴史上の人物や、人名を冠した概念を定着名で紹介するときは、日本語で通用しているカタカナの通称を使う。- 術語の響きを持つ語を、術語でない場面に流用しない (システムから人間までの連なりを「経路」と呼ぶ、など)。「届くまでの流れ」「あいだに何があるか」のように普通の言い方で書く。
演出の抑制
演出の規範は全面禁止ではなく、節度の規範である。修辞は、それが効果を生む箇所でのみ使う。社内文書に演出の余地はほとんどないので、以下で例外として認めた使い方は、書籍や記事のような読み物に限ると考えてよい。
- 溜め (「ここには〜が潜んでいる」) や修辞疑問で導出を演出するのは、緊張が論証を助ける要所に限る。説明で足りる箇所では、そのまま述べる。
- 短い決め台詞を独立した段落にして緊張を作る演出を多用しない。段落内の短い体言止め (「ここまでわずか数十秒。」など) は、場面の山場に限り使ってよい。
- 本文中の太字強調を多用しない。誤読を防ぐ否定や節の帰結など、論理の要所に限り、一節に一、二箇所まで使ってよい (導入部でも可)。それ以外は文の順序と構造で際立たせる。
- 定義文の型、節の内部構成、文の書き出しのいずれであっても、同じ型が三回続いたら、少なくとも一つは入り口を変える。悪い例:「2020 年に開始した。2022 年に拡大した。2024 年に終了した。」良い例:「2020 年に開始し、2022 年に拡大した。転機は 2024 年の終了だった。」
- 「〜してはならない」という命令調の断定より、「〜するわけにはいかない」のような、作業者の判断として書く形を選ぶ。
- 転回点を過剰に劇的にしない。事実を述べる一文で足りる場合が多い。議論の山場にかぎり、感嘆符つきの短い一文程度は許容する。
- 帰結の列挙によって事故や危険を煽らない。
- 「重要なのは〜である」のような前置きで主張を予告しない。主張をそのまま書く。ただし、主張の様式を宣言する前置き (「標語として言い換えれば」など) は使ってよい。
- 「A ではなく B だった」という対句の決め台詞を多用しない。軽い補足や評価は括弧書きで添えてよい。
- 慣用表現をひねった言い回し (「知識を体に入れる」など) や、指す内容が一意に決まらない比喩 (「報告の外側に世界が広がっている」など) を使わない。平易な動詞でそのまま言う (「身につく」「気付く機会が減る」)。
LLM っぽい表現の禁止
LLM が大量生成する、中身のない型に誘惑されない。書き上げたら、この節で点検する。 文書の術語 (本質的複雑さ、回収、判断の配置など) を議論に使うのはよい。空虚な装飾として使うのが問題である。
次のような言い回しは、論点を増やさず「ちゃんと書いている感」だけを付ける LLM 口調である。使わない。
- 予告と総括:「重要なのは〜である」「本章では〜を扱う/探求する」「ここでは〜について見ていく」「まとめると」「要するに」 (直前の言い換えだけのとき)、「〜に他ならない」
- 正面から系:「正面から扱う」「正面から回収する」「正面から見る/書く/立てる」 (中身の代わりに姿勢だけを宣言する)
- 空虚な形容:「不可欠」「核心的」「鍵となる」「根本的な」 (主張の中身を説明せず強調だけする)、「多角的」「包括的」「総合的」 (何をどう見たかを書かない)
- 空虚な動詞:「掘り下げる」「深掘りする」「言語化する」 (何をどう書いたかを示さず終わる)、「触れる」「言及する」 (一段落で済ませるだけ)
- 接続の型:「〜において」「〜という側面から」「〜の観点から」 (新情報なし)、「さらに」「また」「加えて」の連打
- 弱い緩和と称賛:「〜と言えるだろう」「〜かもしれない」による根拠のない緩和。削るか残すかの判断は「論証の厳密さ」の確信度の基準に従う。「非常に」「極めて」「大いに」 (中身のない強調)
- 締めの定型:「いかがでしたか」「ぜひ〜してみてください」「以上、〜について解説した」
悪い例:「本章では、〇〇の理論を正面から扱う」「この前提を、ここで正面から回収する」「多角的に分析すると、重要なのは〜である」。 良い例:「本章では、〇〇の理論を扱う」「ここで、この前提を回収する」「評価の核心は、正しさを誰が知っているかにある」。
翻訳調の比喩と擬人化の禁止
LLM は、日本語として存在しない言い回しを、次の三つの経路で生成する。 前節の空句と違い、書き手に比喩や演出の意識がないまま混入するので、比喩を使ったつもりのない文も含めて点検する。
- 英語慣用句の直訳:英語の技術文では carry / open / expose / live / land などの比喩的用法が慣用句として定着しており、比喩として意識されない。これを日本語の対応語に直訳すると、日本語では慣用化していないため、字義どおりに読める奇妙な生きた比喩になる。
- 悪い例:「このフラグが設定意図を運ぶ」 (carry)。良い例:「設定意図がフラグとして表現される」「フラグに反映される」。
- 悪い例:「この問いは開かれている」 (open question)。良い例:「この問いにはまだ答えが出ていない」「未解決である」。
- 悪い例:「移行の判断軸が露出する」 (expose)。良い例:「移行の判断軸が取り出せる」。
- 悪い例:「この設定はモジュールに住んでいる」 (live in)。良い例:「この設定はモジュールに含まれる」。
- 無生物主語構文の直輸入:英語では無生物主語の他動詞文が普通だが、そのまま日本語にすると、システム、データ、指標、コストといった抽象物が意思を持って振る舞う擬人化になる。人か処理を主体に戻すか、「〜から分かる」「〜に含まれる」の形に言い直す。
- 悪い例:「監視は障害の兆候を知っている」。良い例:「監視の記録には障害の兆候が残っている」など、確認できる事実として書く。
- 悪い例:「データが語るのは〜である」。良い例:「データから分かるのは〜である」。
- 口頭議論の話し言葉の混入:会議や雑談で流通する動詞 (「効く」「刺さる」「筋がいい」など) は、話し言葉としては通じるが、書き言葉では俗語である。効果や見込みの内容を具体的に書く。
- 悪い例:「この対策が効く」。良い例:「この対策を入れると再発率が下がる」。
- 悪い例:「この方式は筋がいい」。良い例:「この方式は〜という理由で有望である」。
判定の目安は二段である。 まず、その述語を初めて見る読者が字義どおりの動作 (運ぶ、開く、住む) を想像しうるなら、翻訳調の比喩を疑う。 次に、動作の主体と対象を具体語で言い直せるか試す。 言い直せるなら、その言い直しをそのまま書く。 言い直せないなら、その文は指す内容が特定できていないので、主張として成立していない。削るか、内容を確定させてから書き直す。
冗長の排除
無駄な文章をなるべく残さない。
- 同じ主張を言い換えて繰り返さない。一つの主張は一度だけ書く。題材が直前と同じでも、その文が加えている命題が違えば繰り返しではない。列挙の各項が同じ論理的地位であることを示す枠語の反復や、定義の直後に適用条件や限定を足す文も、繰り返しではない。
- 隣接する節が同じことを別の角度で述べているなら、役割が重複している。片方に吸収して一つの節にまとめる。
- 場面を描写した直後に、その内容を要約し直さない。意味づけの一文 (「このような作業は、ほぼ完全に任せられる」など) だけを置く。
- 同じ論理的役割を持つ並列の事実は、文を分けて重ねず一文にまとめる。その事実群の論理的地位は文頭の語で示す (「当然、経理部の月次処理も顧客の支払いも〜」)。
- 冗長さは文字数や文数で判定しない。「文の読みやすさ」の字数の目安は一文の読みやすさの指標であって、冗長かどうかの基準ではない。短文化と一文化は、動機、対象、操作、その同一性、因果、条件が順読みで明示されたまま保てる場合に限る。これらを読者の推論に委ねる圧縮はせず、必要な反復と長さを残す。
- 接続や評価のためだけの文 (「それ自体はよいことである」など) を置かない。
- 想像上の読者との問答 (問いを立てて一語で答える形など) を修辞として使わない。主張はそのまま述べる。読者の反応を演じて応答する形 (「〜と感じたかもしれない。そのとおりである」) も同様に避け、譲歩は地の文で簡潔に行う (「もちろん、処置そのものは開発者が決める問題ではない」)。
- 読者が抱きそうな発想を、メタな枠取り (「ここまでの話には自然な続きがある」「〜という発想である」) で紹介しない。その発想自体を直接書く。読者の疑問なら疑問文のまま書いてよい (「その保守も任せればよいのではないだろうか」)。
- 「本書もそれを否定しない」のような、著者の立場の弁明や断りを書かない。事実の記述 (「〜に書かせる場合が多い」) だけを置く。
- 文脈を最短で読み手と共有できる文章にする。導出を一歩ずつ展開しなくても伝わるなら、構造に名前を与えて言い切る。
- 本文でまだ導入していない概念や文書名を、先回りして持ち出さない。
- ためらいのある弱い述語 (「有効な対策であり」など) で済ませない。本文内の根拠で確定していることは強く具体的に言い切る (「活用において必須であり」など)。ただし、残すべき弱い述語の判断は「論証の厳密さ」の確信度の基準に従う。語調を整えるための意図的な緩和 (「必須だと言ってもいい」など) は許す。
- 文章のリズムを作るための接続表現 (「しかし一方で」など) は、冗長と見なさない。
文の読みやすさ
文そのものの整え方は機械的な閾値では判断できないので、書き上げたら目で確かめる。
- 一文は 50 字から 60 字を目安にする (文化庁「公用文作成の考え方」)。一文には一つの内容だけを入れる。
- 修飾語は、長いものを先に、短いものを直前に置く。
- 主語と述語をできるだけ近づける。従属節を入れ子にして両者を引き離さない。
- ですます体とである体は、文書内で統一する。
- こそあど言葉は、指示先が一意に決まるときだけ使う。
- 翻訳調を避ける。連体修飾の入れ子、「〜を持つ」、「〜することによって」は、いずれも英語の統語が透けている。「〜することができる」は「〜できる」に直す。無生物主語に他動詞を取らせる形は「翻訳調の比喩と擬人化の禁止」で扱う。
- 短さそのものを目的にしない。事実が保たれ、主語と述語の係り受けが正しいことを確かめたうえで、同等の候補が並んだときにだけ短いほうを選ぶ。
見出しの付け方
見出しは内容を特定できる具体的なものにする。見出しだけを順に拾い読みしても論旨が通る状態を目指す。
- 見出しには節の結論を埋め込む。「背景」「課題」「まとめ」のような箱の名前は、そこに何が書いてあるかを教えない。
- 作業の手順だけを述べる見出し (「例に戻す」「〜を読み直す」など) や、情報量のない見出しにしない。その節が答える問い、または扱う対象を見出しにする。
- 全見出しを「名詞ラベル: 結論文」の同一書式に揃えない。結論見出しという手法自体がテンプレートに転化し、拾い読みが単調な対句の羅列に見える。コロン型、文型、問い型を内容に応じて混ぜ、短い節は素のラベルのままでよい。
- 疑問形でも、扱う対象を指す名詞句でもよく、本文のトーンに合うほうを選ぶ。問うのは、扱う対象や読者の持つ問いを指しているかである。
- 見出しは本文の確信度を超えない。本文が「未定」「予定」と書いていることを、見出しで断定に格上げしない。
- 既存文書のリライトでは、結論化する見出しを、開いて中身を探す手間が実際に大きい 2,3 箇所に絞る。全見出しを結論化した改稿は、個々の変換が正しくても、全体としては原文より機械的に見える。
(読み物)書籍や記事では、見出しを節の結論を言い切るセリフにせず、読者がオチを先に知る状態を避けてよい。
読者への誠実さ
- 確認していないことを、確認したかのように滑らかに書かない。
(読み物)例が作為的に見えうる場合、それを隠さない。読者の疑念を先回りして認め、現実に十分あり得ることの根拠を短く添える。(読み物)その根拠は、著者の断定 (「十分あり得る状況だ」) ではなく、読者自身の経験に訴える一般的事実や通説に求める (「この症状は珍しくないだろう」「〜という言い方もよく耳にする」)。
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

