AIっぽい文章の直し方を、人が1本ずつ直す方法のままにできない理由
検索で上位に出てくる記事は「特徴5選」「人間味を足すリライト術」「魔法のプロンプト」のように、書かれた原稿を人が1本ずつ読んで直す前提のものがほとんどです。1回の投稿を丁寧に整える場面では、この前提で足ります。
relmeaの運用はここが違います。複数の記事アカウントと電子書籍の執筆が同時に動くため、原稿の本数が増えるほど「誰かが読んで直す」工程がボトルネックになります。直し方の技術そのものより、直す工程を誰が・いつ・どこに置くかという運用設計のほうが先に詰まる問題でした。
この記事で書くのは、点検表を書き手の定義に埋め込み、保存前に自分で通させる設計の中身と、その理由です。
点検表を書き手の定義に組み込むという設計
relmeaでは、記事アカウント2つのライターと電子書籍の執筆役に「保存前セルフチェック」という欄があります。ここにAIっぽさの点検表を1行として組み込みました。同じ欄には次の項目も並んでいます。
- 表組みと太字強調を使っていないか
- 書き出しがなぜ必要かの説明から始まっているか
- 主張に定量根拠が添えてあるか
- 固有名の混入がないか
書き手は原稿ができた時点で自分でこの欄を通し、通った最終稿だけを保存します。
検品にあたる役割（電子書籍の校正役）は別に立てていますが、その役割がやるのは修正ではありません。印をつけた箇所を「項目番号と原文の抜き出し」で報告するだけで、直すのは元の書き手です。理由は単純で、直す人と書いた人が分かれると、直す人はなぜその表現を選んだかの文脈を持たないまま書き換えることになり、事実を足したり主張を削ったりする事故が起きやすくなるためです。
なお、文体を感性寄りに運用している記事アカウント1つは、この点検表の対象外にしています。ルールを型として持つ書き手と、型に寄せない書き手を分けて扱う判断です。
22項目の内訳と、直さなくていい場合の線引き
もとは公開されているオープンソースの点検表（MITライセンス・25項目）です。日本語の記事に当てはまらない3項目（ハイフンでの語の連結、英語圏で頻出する語のリスト、曲がった引用符）を外し、22項目にしました。原典自体が、構造の癖は言語をまたいで出るという立場を取っています。ハイフン連結や引用符の形は英語特有ですが、対比を作って重みを増やす、三つ並べる、締めの一文を置くといった構造の癖は日本語の文章にもそのまま出ます。
22項目は5つのグループに分かれます。
- A「言う代わりに演出する」（5項目）: 「XではなくY」型の対比、前の段落を言い直すだけの締めの一文、深そうに聞こえる言い回し、本題の前の前置き、誰もいない相手への反論。1回見つけたら直します。
- B「規則で刻むリズム」（5項目）: 無理な三点並べ、同じ文頭の連続、ダッシュでのつなぎ、留保の重ね、主語を消す受け身。単独では弱く、同じ箇所に重なったときだけ直します。
- C「水増しと借りてきた権威」（6項目）: 意義の水増し、事実への浅い付け足し、あいまいなつながり、宣伝文句、借りてきた権威、簡単な動詞を避ける言い回し。事実は残し、飾りだけ外します。
- D「規則で飾る書式」（2項目）: 理由のない太字、飾りの見出し。
- E「チャットと下書きの名残」（4項目）: チャットの締めの言い回し、知識の限界の言い訳と推測、前の版についての言及、見出しをそのまま言い直す一文目。見つけたら消します。
判定の軸は2つだけです。その文は読者がまだ持っていない情報を足しているか。その癖は、注意深い書き手がわざとやる頻度に比べて多すぎないか。
直さない場合
引用の中、書名や固有名の中、その語句について論じている箇所はそのまま残します。珍しい具体、割り切れない気持ち、本人が理由を言える言葉の選び方、本物の脱線のような、書き手の声を運ぶ細部も残します。「XではなくY」型の対比も、否定側が読者の実際の思い込みを正しているときや、両方が情報を運んでいるときは直しません。頻度は1本の原稿全体で測るもので、1本の中に対比が数回出ること自体は問題にしていません。
保存前に自分で通す4段階のセルフチェック
- 全文を一度通して読み、見つけた癖に印をつける。強い癖から見る。段落の形も見る。二文に分かれた対比、三つ並んだ例、節ごとに同じ締め方は、同じ癖が段落単位で大きく出た形です。
- 書き直す。主張はすべて残す。退屈な箇所の短縮、段落の結合や分割、構成の変更はしてよい範囲です。
- 照合する。書き直しで数字・固有名・日付・引用が増えていないか、主張が落ちていないかを元の原稿と突き合わせる。そのうえで、書き直しでも生き残りやすい5つ（対比、一文の締め、ダッシュ、三点並べ、太字の見出し語）を探し直す。
- 仕上げる。印のついた語句を1つずつ差し替えるのではなく、段落の要点から書き直す。文の長さは長短を混ぜる。
頻度は原稿全体で測ります。運用ファイルの記録（2026-09-23）では、「ではなく」型の対比が直近30日の下書きで1万字あたり、記事アカウントの一方（AI活用領域）で6.9回、もう一方（EC領域）で6.5回でした。同じ期間に運営者本人が打った文（576発言）では3.4回で、記事の下書きは本人の発言のおよそ2倍の頻度でこの型を使っていました。点検表のA群の1項目目は、この差を縮めることを狙って置いています。
この点検表より上に立つ規則もあります。媒体の書式規則（たとえばnoteの記事ではH2見出し2〜4個・区切り線3〜6本・1段落最大3文・段落間に空行1行）、投稿テンプレートが指定する定型文と導線は、点検表より優先します。そして最も優先するのは「事実は足さない」というルールです。数字・固有名・日付・引用・体験は、元の原稿か一次情報にあるものだけを使います。直したい文に必要な事実が元原稿になければ、文を単純にするか、確認が必要な箇所として書き残します。
事実の規約を先につくり、言い回しの点検を後から足した理由
この点検表は、2026-09-23に作りました。しかし最初に作ったルールはこれではありません。
2026-08-20、教材の1つに「エアプ感を感じる」という低い評価が付きました。原因を調べると、本文の数字が一次情報につながっていませんでした。表現の癖ではなく、事実の裏づけが抜けていたことが原因でした。
そこで翌2026-08-21、先に「実物起点で書く規約」を作りました。一次情報の実物を引用する、現金と時間換算を分けて書く、出典を1行添える、計算は検算する、一次情報がなければ書かない、という5つの取り決めです。AIっぽさの点検表を作ったのはその1か月後、2026-09-23です。
この順番には理由があります。言い回しを整える点検表だけを先に運用すると、文章はなめらかになりますが、書かれている事実が本当かどうかは点検の対象になりません。なめらかで裏づけのない文章は、粗い文章より発見しづらい問題です。事実の規約を先に固定してから言い回しの点検を足すことで、点検表の手順3（照合）が「書き直しで事実が増えていないか」を必ず確かめる工程になり、言い回しを直す作業が事実を足す作業へすり替わらないようにしています。
ダッシュで節をつなぐ癖（点検表のB群の1項目）は、点検表とは別に、記事の共通の書式指示でもダッシュの連発として禁止しています。同じ癖を2か所で止めている形です。
点検表を書き手の定義に組み込んだ設計の要点は、事実の規約が言い回しの点検より常に上に立つという順番を、書き手が保存前に必ず通る手順として固定したことです。