AIに記事を書かせていると、「合格点は出ているのに、読むと何か引っかかる」という状態がよく起きます。私は個人で、記事の下書きを生成するパイプラインに自己採点のステップを入れて運用してきましたが、その採点が何を見ていて何を見ていないのか、自分でもはっきり言語化できていませんでした。
そんなときに読んだのが、netetahitoさんの『AIの文章を読みやすくするskillを作る（文の難しさの点数化＋構造化）』です。要点は、文ごとの難しさを「長さ」「単語の使われにくさ」「係り受けの負荷」から点数にし、あわせて文章を主張・条件などに構造化して組み直すSkillを作った、という内容です。点数は目安にすぎないこと、処理に時間がかかるので長く込み入った文章に限定したほうがよいことも、限界として書かれています。
この記事では、元記事の点数化ロジックそのものには踏み込みません（私は再現していません）。代わりに、私の手元で動いている「基準を示して出力を整える」運用を、元記事の手順と並べて比べます。比べて分かったのは、同じ「点数で品質を管理する」でも、点数を出す主体が違うと、保証できる範囲がまったく変わる、ということでした。
この記事で扱うこと・扱わないこと
- 扱う: 元記事の手順と、私の運用手順（自己採点・Few-shot・CLAUDE.md）の比較
- 扱わない: 読みやすさスコアの計算式、重みの妥当性、元記事Skillの再現
- 載せる出力: 実際にその場で実行したものだけ。実行していないコードは「未実行」と明記します
比較: 点数を「計測」するか「採点」するか
元記事の記述と、私の運用の違いを表にしました。右列は私の環境の話で、一般論ではありません。
| 観点 | 元記事のSkill | 私のパイプライン |
|---|---|---|
| 何を点数にするか | 文の長さ・単語・係り受けの負荷 | 実体験・実用性・読みやすさ・エンゲージメント・SEOの5区分で100点満点 |
| 誰が点数を出すか | 主にツール側で計算（元記事の記述） | 記事を書いたのと同じLLM |
| 点数が低いと | 文を切る・並べ替えるなど書き直し | 合格点（75点）未満なら再生成 |
| 点数以外のゲート | 元記事の限界節に「点数は目安」とある | 技術claimの出典・コードと本文の整合を別途チェック |
大きな違いは3行目と2行目です。元記事は読みやすさを測る側に寄っていて、私のは自分で採点する側にいます。後者は、書いた本人が自分の答案に丸をつけている構造なので、点数の再現性は期待できません。ここは私の分析です。
私の運用1: 基準をFew-shotで見せる（コードレビュー）
自己採点の前に、基準を示して出力を整える経験が2つあります。1つ目はコードレビューです。
Claude Codeにレビューを頼んでいた頃、些細なスタイル指摘と重大なバグ指摘が同じ粒度で混ざって返ってきていました。そこでレビュー依頼のプロンプトに、重要度（Critical / Warning / Info）の分類基準をFew-shot例として3パターン添えました。出力は重要度別に整理され、Criticalの見逃しがなくなり、レビュー結果の確認にかかる時間は体感で半分ほどになりました（時間は計測ログではなく体感です）。
学びは「ルールを文章で書くより、例を3つ見せたほうが効く」でした。これは、読みやすさの点数化でいえば「基準を数値で示す」のと近い発想ですが、ここでの基準は点数ではなくラベル付きの例です。
私の運用2: CLAUDE.mdに情報設計を持ち込む
2つ目はCLAUDE.mdです。Claude Codeにgitのコミットを任せていた頃、「fix bug」「update」のような中身の見えないコミットメッセージが増えていました。そこでCLAUDE.mdにConventional Commitsのルールを具体例つきで書き、コミット前に差分を確認させるようにしました。履歴を上から読むだけで、どの変更が何のためだったかを追えるようになりました。
読みやすさの話に引き寄せると、これは「長い文を切る」のと同じで、入力側の文章を構造化して読み手（この場合はモデル）の負荷を下げる操作でした。元記事が出力文章を構造化するのに対し、私は入力の指示文を構造化していた、という違いがあります。
私の運用3: 自己採点ゲートを入れて、足りなかったところ
記事生成パイプラインには、下書きをルーブリックで自己採点して、75点未満なら再生成する工程があります。ルーブリックは実体験30・実用性25・読みやすさ20・エンゲージメント15・SEO10の配点です。このうち「読みやすさ」は20点で、中身は冒頭のフック・見出しの間隔・段落の長さ・文字数といった構成の目安を見ています。文の難しさそのものは見ていません。
ここで失敗がありました。自己採点で合格した記事が、その後の技術レビューで連続して差し戻された時期があります（2026年9月17日〜10月1日）。点数は通るのに、出典がない主張や、本文と掲載コードの食い違いが残っていたためです。自己採点は書き手の目線で採点するので、自分の書いた主張の裏が取れているかは採点の外に漏れやすい、というのが私の理解です。
そのため、採点とは別軸の足切りを足しました。
- 検証が必要な主張を本文から列挙し、一次情報へのリンクを本文中に対応づける
- コードに関する説明を列挙し、掲載コードのどこで実現しているか突き合わせる
- 各コードブロックを「実行済み／構文確認のみ／未実行／説明用」に分類し、未実行のものは動作を断定しない
点数を足しても見えない欠陥は、点数とは別の列挙作業でしか潰せませんでした。
私の運用4: 「信頼するが検証する」を仕組みにする
もう1つ、AIの出力を信じる前に検証する経験があります。新規プロジェクトでフレームワークを選ぶ際、要件を伝えてClaude Codeに比較表と推奨を作らせたところ、30分ほどで表が完成しました。ただ、AIの情報は古い可能性があるので、採用するバージョンの仕様は公式ドキュメントで確認する、と決めました。
これは文章の読みやすさとは別の話ですが、品質基準を人間の注意力に頼らず、手順として固定するという点で、元記事の「機械で検証する」姿勢と同じ方向を向いていると感じました。
自作する場合の最小の雛形（未実行）
読みやすさチェックを自分のSkillにするなら、置き場所はプロジェクト用なら .claude/skills/<skill-name>/SKILL.md、個人用なら ~/.claude/skills/<skill-name>/SKILL.md です。YAMLフロントマターの description に、いつ使うSkillかを書きます。いずれもClaude Code公式のSkillsドキュメントに記載があります（確認日: 2026年10月18日）。
以下は私が考えた雛形で、Claude Codeに読み込ませての実行は未実行です（pseudocode 扱い）。点数化の式は書かず、「何を基準に直すか」を例で示す構成にしています。
---
description: 長い説明文を読みやすく直す。ユーザーが「読みにくい」「要約して」と言ったときに使う。
---
次の順で直す。
1. 一文が二つ以上の主張を含むなら分ける。
2. 指示語（これ・それ）は、指す名詞に置き換える。
3. 直す前と後を並べ、変えた点を一行ずつ書く。判断や補足は足さない。
## 例
- 悪い例: 「これにより、それが改善されたため、対応した。」
- 良い例: 「キャッシュを追加したため、応答が改善した。そこで設定を本番に反映した。」
雛形の「例」を2つ並べているのは、先ほどのFew-shotの経験を持ち込んだためです。例の数と効果の関係は私の環境では検証していないので、3つが最適とは言えません。
実行できたこと: 下書きの体裁チェック
この記事の下書き自体に、私のリポジトリにある体裁チェッカー（qiita-inspect.js lint）をかけています。これはAIの文章の難しさではなく、閉じ忘れたコードフェンスや混入したタグといった体裁の事故を機械で拾うためのものです。
実行したコマンドと、そのまま貼った出力です（2026年10月18日、手元のリポジトリにある自作スクリプトで実行）。
node scripts/biz/qiita-inspect.js lint drafts/2028-PENDING.md
OK: 投稿前チェック通過（警告 0件）
この出力が示すのは、体裁チェックの警告が0件だったことだけです。文章が読みやすいことや、主張が正しいことは何も保証しません。
読みやすさの点数化とは別物ですが、「人の注意に頼らず機械が見る」層をひとつ持っておく、という意味では元記事と同じ考え方だと思います。
比べて分かったこと
- 点数の出し手が計測ツールか、書いた本人（LLM）かで、保証できる範囲が変わる
- 自己採点は構成の目安には使えるが、主張の裏取りやコードとの整合は別のゲートが必要だった
- 入力側（CLAUDE.md・Few-shot）の構造化と、出力側（元記事の構造化）は、読み手の負荷を下げるという点で地続きだった
結局のところ、私にとっての収穫は「自己採点は品質保証ではなく、品質の目安のひとつでしかない」と線を引けたことです。元記事のように計測できる部分は計測に任せ、裏取りのように計測できない部分は列挙と突き合わせで潰す。この役割分担を意識するだけで、「合格点なのに引っかかる」記事はだいぶ減るはずだと考えています。
私は自己採点の外に、どんなゲートを置くのが現実的なのかをまだ探っています。文章の品質管理で「ここは機械に任せた」という線引きがあれば、コメントで教えてもらえると助かります。