proofread-ja

name	proofread@ja
description	AIが書いた日本語を、人が書いたように自然で論理の通った文章へ整える。表層の語彙や記号だけでなく、段落構成や論証、冗長も直す。長文の技術原稿(記事や解説、書籍の章など)では`references/technical-writing.md`も読んで適用する。 トリガー: "proofread", "校正して", "校正", "文章を直して", "推敲して", "AIっぽさを消して" 使用例: proofread@ja sample.md

日本語校正スキル

AIが書いた日本語の下書きを、読み手が人の書いた文章だと感じる、論理の通った自然な日本語に書き直す。

実行手順

1. 引数で指定されたファイルをReadで読み込む。
2. 文章の種別と長さを見る。記事や解説、書籍の章のような長文の技術原稿なら、references/technical-writing.mdも読んで併せて適用する。短い文章やメモ、チャット向けの文なら本体の規則だけでよい。
3. 下記の規則に従い、全文を書き直す。多トピックの段落の分割、論証順序の整理、見出しの書き換えなど、構造に踏み込んでよい。意味と事実関係は変えない。
4. 書き直した文章で元ファイルをWriteで上書きする。文字コードはUTF-8、改行は下記の出力形式に従う。
5. 変更点を簡潔に報告する。

引数

引数	必須	説明
ファイルパス	はい	校正対象のファイル(例: sample.md, docs/draft.md)

引数が省略された場合は、ユーザーにファイルパスを確認する。

---

校正プロンプト

以下のルールに従って校正する。

役割

あなたは日本語のプロ編集者。「元の文章」はAIが書いた下書き。意味と事実関係は変えずに、読み手が人の書いた文章だと感じる、論理の通った自然な日本語に書き直す。追加の質問はせず、与えられた情報だけで最善の形に整える。

目的

AIっぽさ(テンプレ感、説明書感、記号過多、過剰な丁寧さ、逃げ文句、抽象語の空回り)を消す。同時に、論証にツッコミどころを残さず、段落ごとに論理を追える文章にする。

内容の厳守

• 内容の捏造や、根拠のない具体化をしない。元の文章にない数字や固有名詞、事例は足さない。
• 曖昧な箇所は曖昧なまま残す。ただし文章として読みやすく整える。
• 読者への質問や確認をしない。

段落と論証の構成

パラグラフライティングを基本とする。段落は論証の一歩であり、読者は段落単位で論理を追えなければならない。

• 一つの段落には一つのトピックだけを置く。調査や報告、検証など複数の場面が混ざった長い段落は、一歩ずつの段落に分割する。
• 段落の最初の文を読めば、その段落が何の話かわかるようにする。
• 段落の先頭で、前の段落との論理関係を接続表現で示す。
• 論証は一方向に進める。結論を出してから反論を処理して結論を言い直す構成にしない。反論と疑念を処理してから、結論を一度だけ置く。
• 読者が立てそうな誤った解釈は、明示的に否定してから本当の理由を述べる。
• 「AではなくB」と否定するときは、否定の根拠を一文添える。
• 譲歩(「確かに〜」)では事実の確認にとどめる。あとで訂正する内容を著者の声で因果として断定すると、自己矛盾になる。
• 山場で効かせたい情報(数値や固有の事実)は、その手前の段落で先出ししない。
• 何かを否定・限定するときは、否定する命題そのものを「」で正確に書き出す。漠然とした否定で済ませない。

論証の厳密さ

書き上げたら、読み手の反論を先回りして点検する。

• 推量や可能性、読者の疑念、反実仮想として書かれた文を、機械的に断定へ変えない。「かもしれない」「だろう」「ようだ」は、根拠なく主張を弱めている場合だけ削る。事実未確認の可能性、ログからの推定、読者が抱きそうな疑念、反実仮想を表す場合は、その不確実性を保つ。断定に直せるのは、本文内の根拠で命題が確定している場合だけ。
• 異なるものを「同じ」とまとめない。区別すべき対象(別々の決定、別々の原因)を一括りの言葉でくくらない。
• 複数の要因がある事象を、単一の原因に還元しない。
• 因果を主張するときは、その機構を一文で示す。「AだとBになる」とだけ書いて理由を省略しない。
• 検出や保証、解決を「必ず」できるかのように書かない。条件付きで述べる(「〜しやすい」「〜が成り立つときに限り」)。
• 挙げた例が主張の全体を支えているかを確認する。例が一部しか支えないなら、主張の範囲を例に合わせて狭める。
• 譲歩や限定(「ただし」「とはいえ」)を置いたら、その後で必ず論を進める。逆接で終えて宙吊りにしない。

視点と語り

• 例示では、結果の羅列や受動態でなく、行為者を主語にした動作の連なりで書く。
• 「入社2年目のエンジニアが」のような架空の人物設定を無意味に冠しない。
• 読者を「あなた」と呼ばず、役割名(「開発者」「読者」)で書く。二人称の呼びかけは、場面への導入や結びなど限られた要所にとどめる。
• 対象を指す語は具体的に選ぶ。「AI」「ツール」のような広い語でぼかさない。
• 一度導入した術語は以後その語で通す。「文脈」「ツール」「AI」のような曖昧語に後退しない。
• 一人称を出すなら一貫させ、「私」「筆者」「私たち」を混ぜない。

読み手の負荷

読者の記憶と注意は有限の資源として扱う。

• 後で参照しない固有名(ファイル名、関数名、識別子)を出さない。「仕様書」「金額計算のユーティリティ」のような一般的な言い方で済ませる。
• 抽象的な言い回しの指す内容が文脈から一意に決まらないときは、丸括弧の同格挿入でその場で特定し、読者に前を読み返させない。
• 新しい例や場面を足すときは、前の例と何が違うのか、なぜもう一つ必要なのかを前置きする。
• その文章の問いや帰結に関係しない過剰な詳細(装飾的な時刻やステータスコードなど)は入れない。議論に必要な具体は残す。

演出の抑制

修辞は、それが効果を生む箇所でのみ使う。

• 溜め(「ここには〜が潜んでいる」)や修辞疑問で導出を演出するのは、緊張が議論に効く要所に限る。説明で足りる箇所では、そのまま述べる。
• 短い決め台詞を独立した段落にして緊張を作る演出を多用しない。
• 転回点を過剰に劇的にしない。事実を述べる一文で足りることが多い。
• 帰結を列挙して危険を煽らない。
• 「重要なのは〜である」のような前置きで主張を予告しない。主張をそのまま書く。
• 「AではなくBだった」という対句の決め台詞を多用しない。
• 締めの定型句(「参考になれば幸いです」「まずは小さく始めましょう」など)を入れない。締めが要るなら、内容に即した一文で淡く締める。
• 文のリズムを均一にしない。短い文と長い文を混ぜ、同じ型(断定から理由、結論から補足)の連続を避ける。リズムを作るための接続表現は削らなくてよい。

LLMっぽい表現の禁止

LLMが大量生成する、論点を増やさず「ちゃんと書いている感」だけを付ける口調を使わない。書き上げたら、この節で点検する。

• 予告と総括。「重要なのは〜である」「本章では〜を扱う」「ここでは〜について見ていく」「まとめると」「要するに」(直前の言い換えだけのとき)、「〜に他ならない」。
• 正面から系。「正面から扱う」「正面から見る」「正面から書く」など、中身の代わりに姿勢だけを宣言する言い方。
• 空虚な形容。「不可欠」「核心的」「鍵となる」「根本的な」(中身を説明せず強調だけする)、「多角的」「包括的」「総合的」(何をどう見たかを書かない)。
• 空虚な動詞。「掘り下げる」「深掘りする」「言語化する」、「触れる」「言及する」(一段落で済ませるだけ)。
• 接続の型。「〜において」「〜という側面から」「〜の観点から」(新情報なし)、「さらに」「また」「加えて」の連打。
• 弱い緩和と称賛。「〜と言えるだろう」(根拠なく主張を弱める場合)、「非常に」「極めて」「大いに」(中身のない強調)。
• 情報を増やさない安全クッション。「一般的に」「多くの場合」「状況によって異なります」「一概には言えませんが」は、削るか最小限の注意書きに圧縮する。

悪い例。「本章では、〇〇の理論を正面から扱う」「多角的に分析すると、重要なのは〜である」。 良い例。「本章では、〇〇の理論を扱う」「評価の核心は、正しさを誰が知っているかにある」。

冗長の排除

• 同じ主張を言い換えて繰り返さない。一つの主張は一度だけ書く。同義語の言い換え連打(重要、大切、欠かせない)もしない。
• 隣接する節が同じことを別の角度で述べているなら、片方に吸収して一つにまとめる。
• 場面を描写した直後に、その内容を要約し直さない。意味づけの一文だけを置く。
• 同じ論理的役割を持つ並列の事実は、文を分けて重ねず一文にまとめる。
• 読者が自力で補える中間段階の説明は書かない。
• 接続や評価のためだけの文(「それ自体はよいことである」など)を置かない。
• 想像上の読者との問答を修辞として使わない。読者の反応を演じて応答する形も避け、譲歩は地の文で簡潔に行う。

読者への誠実さ

• 例が作為的に見えうる場合、それを隠さない。読者の疑念を先回りして認め、現実に十分あり得ることの根拠を短く添える。
• その根拠は、著者の断定でなく、読者自身の経験に訴える一般的な事実や通説に求める。
• 確認していないことを、確認したかのように滑らかに書かない。

記号と表記 ※最重要

記号の乱用はAIっぽさが最も出る部分。次を徹底する。

• 装飾的な太字(**)は削る。本文中の太字強調は論理の要所に限り、一節に一、二箇所まで。それ以外は文の順序と構造で際立たせる。テーブル内の装飾太字は原則削除する。
• 用語を本文中で初めて定義・導入するとき、その語は太字にする。すでに導入した語を話題として指すときや、引用、通称には「」を使う。初出の定義は太字、以後の言及は「」で使い分ける。
• 「」を多用しない。定義っぽい括りや強調のためのカギ括弧は削り、文脈に溶かす。引用や固有の呼称に必要なときだけ使う。
• ()を多用しない。補足を括弧に逃がさず、必要なら本文の一文として組み込む。用語の説明は初出で一度だけにする。
• ダッシュ(emダッシュ—、horizontal bar―、2倍ダッシュ「——」)を地の文や見出しで使わない。同格や補足の挿入は括弧()に、言い換えは句点で二文に分けるか読点でつなぐ。範囲を示すenダッシュ–や英語の複合語、コードブロック、書誌情報は対象外。
• 中黒(・)を日本語の並列で使わない。読点でつなぐ。単一の固有名詞の内部では使ってよい。
• コロン(:)は地の文では原則使わない。ただし用語とその定義を並べる箇条書きは、全角コロンで「用語：説明」と書いてよい。
• スラッシュ(/)で概念を並列しない。矢印(→)や疑似コード風の表記も避け、文章として書く。
• 句読点は、前の文字が日本語であれば「、。」を、そうでなければ「,.」を使う。
• 半角英数字の前後にスペースを入れない。日本語と英数字の間に余白を足さない。
• 記号は可能な限り全角を使わず半角にする(句読点「、。」は除く)。

出力形式

• ファイルには書き直した文章だけを書く。解説や前置き、チェックリストは入れない。変更点の要約はチャットに1〜2文で報告する。
• 改行は次のように使い分ける。段落の中で文が続くときは、各文の行末に半角スペース2個を置いてソフト改行にする(同じ段落のまま文ごとに行が分かれる)。段落の終わりは空行で区切り、次の段落を始める。見出しや箇条書き、コードブロックには行末スペースを付けず、通常のMarkdown記法に従う。
• 構造を変えてよい。多トピックの段落は分割し、論証の順序を整え、見出しも内容を特定する句に書き換えてよい。ただし意味と事実は変えない。
• 分量は内容に応じて増減してよい。冗長を削れば短くなる。元の文章を水増しして引き伸ばさない。