AIっぽい日本語を直すスキル4つを、137項目のチェックリストで比べる

AIに書かせた文章を「AIっぽい」と指摘しても、次の出力で同じ癖が出ることがあります。為安圭介さんが2026年11月2日に公開した資料「AIと人間の文章をどこで判断するか」は、この繰り返しを止めるために、指摘を137項目のチェックリストにして1項目ずつ判定したものです。

日本語の文章を直すスキルや検査の道具は、ほかにもいくつか公開されています。資料の原則を物差しにすると、道具ごとに直す対象が違い、同じ書き方でも扱いが逆になる場合があります。

資料の作り方と4つの柱#

チェック項目の材料は4つです。中心は為安さんがAIに出したスライド作成の指摘で、ほかに横井公貴さんの発表「AI臭い文章とは何なのか」、Deep Researchで作った報告「AIらしい文章とは何か」、スキルのyomiyasu 2.4から集めています。

137項目を、為安さんが5段階（◎必ず守る、◯原則守る、△気づいたら提案、×元の項目と逆の向き、-）で判定しました。書き手への指示が同じ項目どうしを16の原則にまとめ、さらに4つの柱に分けています。資料の結論は「中身が具体的で、形に変化があり、筋と根拠が書き手のものになっている」です。

柱	原則の例	NGとOKの例
中身が具体的	誰が何をどうしたかを書く。読み手の分野で通じる語を使う	「残さない側に倒す」を「採否を判断できない項目は原則として除外します」に
形に変化がある	同じ形を3回続けない。見出しは内容が分かる項目名にする	「〇〇とは：仕組みと使い方」の形の見出しを「〇〇の仕組みと使い方」に
筋と根拠が書き手のもの	書き手が言ったことと確かめたことだけを書く。資料自身や作った経緯に触れない	元の発言にない「私が失敗を痛感した」を削る
IT分野の書き方を残す	IT分野の書き方は直さずに残す。一部は元の項目と逆の向きで使う	「ソリューションを提供する」はそのまま使う

形の柱には文字の大きさ（出典を8.5ptから12ptに）や補足の文字色（薄いグレーから本文に近い濃さに）のような、スライドに固有の項目も入っています。文章だけを直す道具は、この部分を扱いません。

IT分野では「直さない」項目#

資料でほかの文章の規範と違うのは、4つめの柱です。AIらしく見える書き方のうち、IT分野の資料では一般的なものを「直さない」と判定しています。

直さない書き方	資料の例
IT用語のカタカナ語	「ソリューションを提供する」
IT分野で一般的な硬い漢語や名詞化	「〜を実施することが可能です」
誇張語や決まり文句（直す基準から外した理由は資料に書かれていない）	「圧倒的な生産性」
前置きや進行の説明	「本記事ではAIの文章について紹介します」
1枚に複数の話題が並ぶこと	1枚に原因・対策・事例が並ぶ
1行に収まらない箇条書き	箇条書きは1行に収まらなくてよい

元の項目と逆の向きで使うものも1つあります。元の項目は「事実・推測・価値判断を、明示して区別する」でした。資料は「推測です」のような断り書きを添えるより、推測は文の中身として書くほうが一般的だとしています。

「設定変更の実施を行う」のように名詞化に「行う」を重ねた形は「設定を変更する」に直し、「〜を実施することが可能です」のようにIT分野で定着した硬い言い回しは残しています。機械で一律に判定しにくい境目で、資料の検査も「機械の指摘は候補にとどめて、意味を変えるかどうかは目で判断する」としています。

4つの道具の守備範囲#

日本語の文章を直す道具のうち、公開されていて中身を確かめられた4つを比べます。3つはClaude CodeやCodexに読み込ませるエージェントのスキルで、1つはtextlintの規則集です。2026年11月3日にリポジトリで確かめた版は、yomiyasuがv2.5.0、natural-japaneseがv1.6.4、meisekiがv0.10.0、textlintのプリセットが1.7.0です。

道具	主に扱うもの	機械の検査
yomiyasu	比喩の動詞、擬人化、主述の関係、読点	付属のlintとdiff、check（Python）
natural-japanese	元にない事実や確信を足さないこと、太字、何のことか分からない言い回し	形態素解析のlint.py（sudachipy）
meiseki	二重否定、長い連体修飾、「の」の連鎖など、読解の負荷が高い構文	prhの辞書とtextlintのプリセット（Node.js）
textlintのAI向けプリセット	太字とコロンの箇条書き、絵文字の箇条書き、誇張語	textlintの5つの規則

yomiyasu#

技術記事、設計書、PRの説明文のような実務の文章を対象にしたスキルです。7つの変換原則の1つめは、主語と述語、修飾語と掛かる先、指示語と指す対象を対応づけることです。「壊れる」「倒す」「効く」「溶かす」のような比喩の動詞を言い換え、道具や概念に意志を持たせた擬人化を直します。資料の「比喩の動詞を実際の動作に直す」「誰が何をしたかを書く」は、この原則とほぼ重なります。資料の材料の1つがyomiyasu 2.4なので、重なるのは自然です。

文の長さと読点には目安があり、平均文長30〜45文字、1文の読点0〜2個です。2.5.0では読点の位置の検査を足しました。人の文章（livedoorニュースコーパス）とAIの生成文を比べた測定では、6字以内の短い目的語のあとの「を、」は、1万文あたり人が13.2、AIが44.6でした。読点の数そのものは人の文章でも多い分野があるため、数ではなく位置で拾う規則にしたとCHANGELOGに書かれています。資料の「読点は意味の切れ目にだけ打つ」と同じ向きです。

本体を入れられない環境のために、短くしたyomiyasu-miniとyomiyasu-pocketもあります。

natural-japanese#

議事録、レポート、技術記事、PRの説明文を直すスキルです。直すときに守ることとして、元の文書にない事実、数値、意見、方針を足さず、確信の度合いも変えないことを挙げています。READMEの例は調査レポートで、元のメモには未検証の見立てが2つありました。スキルなしの出力は「強く疑われます」と書き、スキルありの出力は「どちらも未検証である」と書いていました。資料の「原典の確度のまま書く」「実践していないことは実践したと書かない」に当たります。

5種類の文書を5つのモデルに書かせた比較では、太字がスキルなしの25本で551か所、スキルありの25本で13か所でした。

READMEには苦手なことの節もあり、英語の言い方を1語ずつ訳した熟語や、動作を名詞にまとめた言い回しは半分ほど見逃すとしています。資料が「直す」と判定した「設定変更の実施を行う」のような形は、この苦手な範囲に入ります。

meiseki#

目的を「明晰さ」、つまり内容を知らない読者が一度読んで正しく理解できることに絞ったスキルです。難しい語彙ではなく構文が読みにくさの原因だとして、二重否定、否定と条件の入れ子、長い連体修飾、主語と述語の距離、「の」の連鎖、過剰な名詞化を直します。

READMEは一般論を「自分は」という意見に書き換える系統のスキルとは逆の方向だとし、文章の声や立場を足さないとしています。資料には「書き手自身の観察・経験・判断を入れる」（◯原則守る）という項目があり、書き手の材料がある場合はそれを入れる方向です。ただし資料も書き手が言っていない感情や、実践していないことは書かないとしています。書き手の材料にないことは足さない、という点では、資料とmeisekiは同じ向きだと読めます。

やさしい日本語に書き換えるyorisoi、資料から理解度のクイズを作るrikaiなど、別のスキルも同じリポジトリに入っています。

textlintのAI向けプリセット#

textlintの規則集で、エージェントのスキルではありません。原則は「表現を縛るのではなく、構造を縛る」です。含まれる規則は次の5つです。

• no-ai-list-formatting: 「重要: 〜」のような太字とコロンの箇条書き、絵文字で始まる箇条書き
• no-ai-hype-expressions: 「革命的」「ゲームチェンジャー」「パラダイムシフト」のような誇張語
• no-ai-emphasis-patterns: 「これは非常に重要な項目です」のような文中の太字と、太字の見出し
• no-ai-colon-continuation: 「実行します:」のように、述語で終わる文のあとのコロンに続くコードや箇条書き
• ai-tech-writing-guideline: 冗長な表現（「〜することができます」を「〜します」に）、受動態、抽象的な表現などの改善の提案

textlint 15.1.0以降で動き、npx textlint --mcpのコマンドでMCPサーバーとして起動すると、Claude CodeなどのAIの道具から呼び出せます。AIが書き、textlintが検査し、その結果でAIが直す、という流れを想定した規則集です。meisekiはこの規則集を体裁と誇張語の検出に使っています。

道具ごとに扱いが分かれる書き方#

資料の判定と道具を並べると、扱いが分かれる書き方が3つあります。

書き方	為安さんのチェックリスト	道具
誇張語（「圧倒的な」「革命的」）	直す基準から外す	textlintのno-ai-hype-expressionsとmeisekiは検出する
前置き（「本記事では〜紹介します」）	置いてよい	yomiyasuは、削っても主張と比重が変わらない場合だけ削る
硬い漢語と名詞化（「〜を実施することが可能です」）	IT分野で一般的なものは残す	meisekiは過剰な名詞化を、textlintのai-tech-writing-guidelineは「〜することができます」を直す対象にする

資料と道具で扱いの差が最も大きいのは誇張語です。textlintの規則は誇張語の一覧を持って一律に検出し、為安さんのチェックリストはIT分野の資料では直さないと判定しました。製品紹介や社外向けの資料にtextlintを入れるときは、規則のallowsの設定で外す語を決めておくと、残すと決めた語にまで指摘が出るのを避けられそうです。

反対に、チェックリストが直すと判定し、道具の側にも直す規則があるものもあります。比喩の動詞と主語のない文はyomiyasu、太字とコロンの箇条書きはtextlintのプリセットとmeiseki、元にない事実を足すことはnatural-japaneseが扱います。

機械に任せる部分と目で読む部分#

資料の検査は機械で数えるものと目で読むものに分かれています。

機械で数えるのは読点の数と1文の長さ、同じ文末の繰り返し、「〜を行う」と表記ゆれ、本編の項目番号と資料自身への言及、文字の大きさと色の数です。目で読むのはタイトルや構成の型が続いていないか、見出しと結論が論理でつながっているか、言っていないことを書いていないか、初見の読み手として要点と結論を言えるか、の4つです。

natural-japaneseとyomiyasuも同じ分け方をしています。natural-japaneseはlint.pyで疑わしい箇所を出し、直すかどうかはエージェントが文脈を見て決めます。yomiyasuのlintも、AIの文章によく出る言い回しの規則には置き換え先の語を出しません。yomiyasuのREADMEは、禁止語を置き換えるだけでは別の曖昧な語に変わるだけで、文の構造は直らなかったと、それまでの方法の限界を挙げています。

各READMEが挙げる対象から選ぶと、比喩と主述の関係を直したいならyomiyasu、議事録やレポートで事実や確信の度合いを変えたくないならnatural-japaneseになります。手順書のように一読で正しく伝えたい文書ならmeiseki、CIやエディターで箇条書きの体裁と誇張語を止めたいならtextlintのプリセットです。為安さんのように分野で残す書き方を決めているなら、その一覧を道具の除外の設定に先に写しておくと、指摘の仕分けが減りそうです。

AIらしさの手がかりを研究の側から整理した記事として、「AIっぽい」と1秒で感じる手がかりも書いています。スキルがいつ読み込まれるかは、Everything Claude Codeの311スキルから選ぶで扱いました。