mcpField
R
readability-check

readability-check

github.com/jdevalkマーケティング・グロース109123 回インストール19 週間前に更新
リポジトリ

readability-check について

ブログの草稿や複数段落の文章を対象に、読みやすさを監査するスキルです。構成や文の明瞭さなど10項目を確認し、短いメタデータやSEO順位の評価は別のスキルに案内します。

主な機能

  1. 0110項目の読みやすさレビュー
  2. 02構成と段落のチェック
  3. 03文の長さと受動態の確認
  4. 04冗長語、接続表現、反復の確認
  5. 05Flesch Reading Easeのスコア
  6. 06メタデータとSEOレビューの使い分け

活用シーン

  1. 01完成したブログ草稿のレビュー
  2. 02長文で読みにくい箇所の特定
  3. 03導入と結論の確認
  4. 04メタデータまたはSEOレビューの利用判断

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/jdevalk/skills --skill readability-check

インストール後、Claude Code で/readability-checkを入力して読み込まれたか確認します。

同梱ファイルREADME.md

詳細

読みやすさのチェック

ブログ記事の下書きや、複数の段落からなる文章の読みやすさを監査します。ユーザーから読みやすさのチェックを依頼されたとき(「読みやすさをチェックして」「読みやすさを見直して」「これは読みやすいですか」など)、または実質的な下書きが完成した後に先回りして使います。執筆中ではなく、ブログ執筆スキルの批判的な読み直しに続く2回目の確認として行います。

ページタイトル、メタディスクリプション、スキーマの description フィールド、FAQ の回答、プロフィール文、リポジトリのキャッチコピーなど、短い文言には metadata-check スキルを使います。フレッシュの採点と以下の10項目の評価基準は、5〜30語の文字列には適しておらず、誤解を招きます。

投稿が検索順位を獲得できるかどうか(検索意図との適合、キーフレーズの配置、E-E-A-T、内部リンク)を判断するには、この監査の後に content-seo スキルを連携して使います。読みやすさは検索順位の前提ですが、代わりにはなりません。

読者に合わせた調整

読者は英語を第二言語として読むと、常に想定してください。これは例外的な想定ではなく、基本方針です。

技術記事では、読者が期待する専門用語を技術的なセクションで使ってもかまいません。ただし、技術的でない段落(導入、背景、結論、つなぎ、例、たとえ話)は、技術に詳しくない第二言語話者にも理解できる必要があります。設定や動機を説明する段落は、まだその分野を知らない読者にとって記事を理解するうえで重要です。読者を失うのも、そうした箇所です。

形式張った表現より、会話調の表現が効果的です。読者に直接語りかける記事(「あなた」「あなたの」)や、ときどき問いかける記事は、第二言語話者の読者を引きつけます。技術的でないセクションで、距離を置いた三人称の文体が長く続く場合は指摘してください。

読者が実際にどう読むか

読者は読み進めるかを決める前に、記事に目を通します。見出し、最初の段落、各段落の最初の文を見て、それだけで続きを読むかを判断します。検索エンジンや AI システムも、文章のテーマを判断する際に同じ要素を重視します。そのため、監査ではこの3つの箇所を重点的に確認します。見出しと各段落の最初の文で論旨が伝わる記事なら、ざっと読む人にも、最初から最後まで読む人にも、機械にも理解しやすくなります。

確認項目

記事全体を読み、以下の各基準について報告してください。問題がある場合は、その箇所の具体的な文章を引用し、場所(セクションの見出し、または「導入」/「結論」)を示し、問題点を説明して、具体的な修正案を提案してください。

1. 全体構成とトピックの順序

記事は、書き始める前に計画されていたかのように読める必要があります。トピックをまとめ、順序立てて、一つずつ扱い終えてください。

  • 記事では、認識しやすい順序の原則を一つ採用してください。テーマ別(側面ごと)、時系列(古いものから新しいものへ)、段階的(簡単な内容から難しい内容へ。複雑なテーマの説明に最適)、問題解決型(問題を提示してから選択肢を示す)、または逆ピラミッド型(最も重要な内容を先に示し、その後に詳細や背景を説明する。ニュースや告知に最適)です。
  • 関連するトピックは、まとめて扱う必要があります。あるテーマについて説明した後、いったん離れ、2つ後のセクションで再び取り上げるような、話題の行き来を指摘してください。
  • ざっと読むテスト:見出しと各段落の最初の文だけを読んでも、記事全体の論旨が伝わるべきです。ざっと読む人が重要な点を見落とす場合、その点は段落の中ほどに埋もれています。目立つ位置に移してください。
  • 結論では、締めくくりを示す言葉(したがって、要するに、重要なのは など)を使って、中心的なメッセージを言い直してください。導入が物語、問いかけ、統計で始まっている場合は、結論でそれに立ち返ってください。話の輪が閉じ、記事がまとまった印象になります。
2. 段落の構成

段落は視覚的なまとまりではなく、テーマごとのまとまりです。話題が変わっていないのに見た目だけのために空白を入れると、読者が文章の流れを把握しにくくなります。

  • 各段落の冒頭には、最も重要な文、つまり核心となる文を置いてください。最初の文だけで意味が通じるようにします。読み飛ばす読者が読むのも、AI システムが回答に使う情報として抽出するのも、この文です。
  • 段落の残りの部分では、核心となる文を詳しく説明します。根拠を示したり、補足したり、ニュアンスを加えたりする文を続け、必要に応じてまとめや次の話題への橋渡しとなる文で締めくくります。長い段落では、最後に要約の文を置くと効果的です。
  • 1 つの段落につき 1 つのアイデアに絞ります。2 つの役割を果たしている段落は分割してください。
  • 各段落は完結させ、そのテーマに関することをすべて 1 か所にまとめます。いわゆるピンポンの逆、つまり次の段落が同じ論点をそのまま続けるような段落分けにも注意してください(この場合の段落分けは構成上のものではなく、見た目だけのものです)。
  • 厳密な文数よりも、見た目の密度が重要です。ただし、約 8 文または約 120 語を超える段落には注意してください。長すぎる段落には、たいてい 2 つの話題が含まれています。適当な中間地点ではなく、話題ごとに分けてください。
  • 段落の長さに変化をつけるのはよいことです。同じ長さの段落が続くと単調に感じられます。長い段落の間に短く印象的な段落があっても、問題視する必要はありません。
3. 冒頭の段落

最初の段落は、AI システムが引用する箇所であり、読者が読み続けるかどうかを決める箇所でもあるため、特に重要です。要点にたどり着くまで前置きをする、印刷物向けの書き出しは避けましょう。ウェブの読者が判断にかける時間はわずかです。よい導入には 3 つの役割があります。メッセージを伝え、読者を引きつけ、何がわかるのかを示すことです。特に次の点を確認してください。

  • 最初の文は、背景を説明するだけでなく、投稿の要点を述べていますか?
  • 最初の段落だけで要約として成立しますか?
  • 読者が読み進める理由となる仕掛けはありますか?質問、意外な事実、統計、短いエピソードなどが挙げられます。正確でも平板な書き出しでは、曖昧な書き出しと同じように読者を失います。
  • 読者が抱えている問題を導入で明示していますか?冒頭で自分の問題に気づいた読者は、解決策を求めて読み進めます。
  • 何を学べるのか、読み終えたときに何が得られるのかを、読者が把握できるようにしていますか?
  • 投稿の主要なトピックを表す語句が、最初の段落に自然に含まれていますか?読者にも検索エンジンにも、主題を推測させてはいけません。
  • 「この記事では〜してみます」のような、削除できる曖昧な表現はありませんか?
  • 長さは、短い段落 2 つまで(合計約 10〜12 文)に収まっていますか?導入が長すぎると、要点にたどり着くのが遅くなります。

投稿の中で、導入には最も厳しい読みやすさの基準を適用してください。短い文を使い、能動態にし、難しい言葉を避けます。最も読みやすいセクションにするべきであり、最も難しいセクションにしてはいけません。

4. 文の長さ

次の段階的なしきい値を使ってください。

  • 14〜20 語:標準的な長さです。修正は不要です。
  • 21〜30 語:長い文です。段落内に複数ある場合は指摘してください。
  • 30 語以上:非常に長い文です。すべて指摘し、分割を提案してください。

長い文は、文法的な情報を作業記憶に多く保持する必要があるため、第二言語として読む人にとって特に負担になります。必要なリストなど、長い文が避けられない場合は、その前後の文が短いことを確認してください。

5. 受動態

受動態の構文(「X は Y によって行われた」「〜することが推奨されます」など)を指摘してください。それぞれについて、次の点を確認します。

  • 行為者が明確で、能動態にしても自然に読める場合は、能動態に書き換えてください。
  • 行為者が実際に不明である、重要でない、または文の主題が対象そのものである場合は、受動態を維持してください。
  • それぞれの受動態が個別には妥当でも、1 つの段落に受動態が 2 つある場合は指摘してください。
6. 難しい単語

音節数を基準にしないでください。音節数では、「information」のような一般的な単語を難しいと誤判定し、「queue」のような簡単な単語を易しいと誤判定します。代わりに、次の条件に当てはまる単語に印を付けてください。

  • 技術に詳しくない第二言語の読者が、会話ではおそらく使わない単語であり、かつ
  • 文に合う、より一般的な同義語があること。

より簡単な表現が使える場合に印を付ける単語の例:utilize(use)、leverage(use)、facilitate(help)、commence(start)、subsequently(then)、ascertain(find out)、endeavor(try)。

例外:

  • 読者が知っていることを想定できる専門用語(「structured data」、「hydration」、「middleware」など)は、技術的なセクションでは印を付けないでください。
  • 技術的な投稿の非技術的な段落では、軽い専門用語にも厳格な第二言語の基準を適用してください。

難しい単語が本当に必要な場合は、読者が理解する余裕を持てるよう、前後の文が短く簡潔になっているか確認してください。

7. 冗長な表現と曖昧な表現

意味を加えずに文章を長くする単語に印を付けてください。really、just、very、actually、basically、simply、in order to(→ to)、at this point in time(→ now)、due to the fact that(→ because)などです。また、理由もなく主張を弱める曖昧な表現にも印を付けてください。I think、sort of、kind of、it could be argued that などです。

8. 接続語

接続語は文と段落をつなぐ接着剤です。読者が文を読む前に、文と文の関係を伝えます。関係に合った接続語を使ってください。

  • 列挙:first、also、in addition、another、finally
  • 原因と結果:because、so、since、therefore
  • 比較または対比:however、rather、yet、while、on the other hand
  • 結論:as a result、hence、in short、the takeaway is
  • 強調:especially、most of all、above all
  • 具体例:for example、in other words、that said

確認事項:

  • 接続語のない段落が3つ以上続いていたら、印を付けてください。
  • リストや手順、結論では、接続語が特に重要です。道しるべのない列挙では、読者が構成を推測しなければならず、結論を示す言葉のない文章は結論らしく読めません。
  • 修正しすぎないでください。自然な流れも大切です。すべての段落に明示的な接続語が必要なわけではありません。
9. 表現のバリエーション
  • 約200語以内で3回以上繰り返される単語やフレーズに印を付けてください(冠詞、前置詞、専門用語は除きます)。
  • 同じ文型で始まる段落が3つ以上連続していたら、印を付けてください(たとえば、すべてが「You can...」で始まる場合)。
  • 同義語や文の組み立て直しを提案してください。
10. 小見出しと見出しの階層

書き手は、見出しが多すぎるよりも少なすぎることがほとんどです。迷ったら、見出しを追加してください。

  • 1000語を超える投稿では、小見出しなしで300語を超える文章のセクションを作らないでください。長い段落や、テーマが似ている段落のまとまりには、それぞれ見出しを付けてください。
  • 各見出しは、その下の内容を正確に表す必要があります。目を引く見出しでも、セクションの内容を説明していなければ、ざっと読む読者にも機械にも誤解を与えます。
  • 小見出しは、単独で見ても内容がわかるように具体的にしてください。目次をざっと見た読者が、投稿の構成を把握できる必要があります。
  • 見出しの階層が正しく入れ子になっているか確認してください(h2からh4へ飛ばないこと)。
  • 同じ階層の見出しは、文法的な形をそろえてください(すべて名詞句、すべて疑問形、またはすべて命令形のいずれかを選び、セクション内で統一します)。
  • 約1500語を超える投稿では、目次の追加を提案してください。道しるべのない長文が続くと、読者は読むのをためらいます。目次があれば、全体像を把握し、必要な箇所に移動できます。

スコアリング

次の2つを報告してください。

Flesch Reading Ease(計算式:206.835 − 1.015 × (words/sentences) − 84.6 × (syllables/words))。目標範囲:

  • 70以上 — 平易な英語で、第二言語として英語を読む人にも読みやすいレベルです。技術的でない記事や、技術的な記事の技術的でない段落では、この範囲を目指してください。
  • 60~70 — 標準的なレベルです。技術的でないセクションのスコアがより高ければ、技術的な記事全体としては許容できます。
  • 50~60 — やや難解です。問題点を指摘し、具体的な削除案を提案してください。
  • 50未満 — 難解です。書き直しが必要です。

Flesch は機械的な指標で、段落ごとの問題点を見落としますが、客観的な基準になります。可能であれば、導入部と結論のスコアも個別に報告してください。これらは目標範囲の上限に位置するのが望ましいです。

カテゴリごとのステータス — 上記の10項目それぞれに、次のいずれかを割り当ててください。

  • ✓ 合格 — 意味のある問題はありません。
  • ⚠ 要改善 — 修正可能な問題がいくつかあります。以下に列挙します。
  • ✗ 問題あり — 記事全体にわたる体系的な問題があります。

出力形式

## Readability audit: [post title]

### Score
- Flesch Reading Ease: [n] ([band])
- Intro: [n] · Conclusion: [n]
- Per-category: 1. ✓  2. ⚠  3. ✓  4. ✗  5. ⚠  6. ✓  7. ✓  8. ⚠  9. ✓  10. ✓

### Summary
[One paragraph: overall readability, the one or two biggest issues, and which audience the post currently serves vs. which it should serve.]

### Issues found
[Grouped by category. For each: location, quoted text, why it's a problem, concrete fix.]

### What's working
[Specific sentences, paragraphs, or transitions that read well — quote them. Vague praise ("the intro is fine") doesn't help the writer calibrate; specific praise ("the analogy in the 'Setup' section lands because it bridges to a non-technical reader") does.]

コメント