「約18分で読めます」をやめた — ブログ記事のテンプレート作りが読みやすさの見直しに広がった話

ブログの記事を書くたびに、AI (Claude Code) に同じことを伝えていました。誇張しない、他者を批判しない、参考リンクには自分のコメントを付ける。伝え漏れると直しの往復が増えるし、記事ごとに書き方が揺れる。そこで、書き方のルールと記事の骨組みをまとめたテンプレートを作ることにしました。狙いは執筆の効率化もありますが、どちらかというと記事の品質を上げること、ブログ全体に統一感を持たせることです。

やってみると、話はテンプレートだけで終わりませんでした。「約18分で読めます」という読了時間表示への違和感、補足が本文と同じ顔で並ぶ問題、文字色がアクセシビリティ基準を満たしていなかったという積み残し、公開後に見つかった文字数カウントのバグ。15往復のレビューで、読みやすさ全般の見直しに広がった記録です。実装と検証は Claude Code が行い、私は方針の相談とレビューをしています。

書き方のルールが4箇所に散らばっていた

まず現状を調べてもらったところ、記事の「書き方」は4箇所に分散していました。それぞれ、たとえばこんな内容です。

• 執筆ルールの README — 「誇張・煽り表現 (『まさかの』『衝撃の』等) は使わない」「太字の閉じ記号の直前が記号だと Markdown が崩れる」といったトーンと技術の注意
• AI のメモリ — 「比較で劣った側にも持ち味を書く」「回避策を『最強』と書かない」といった、過去のレビューで伝えた指針
• 過去記事そのもの — テンプレートがないので、AI への指示は「ひな形は過去記事を参照」。公開前チェックリストは記事ごとに中身が微妙に違い、公開時の画像パス変更のような定型作業が書かれていたりいなかったり
• 口頭 — 「参考リンクのコメントは私の実感だから創作しないでね」のように、毎回チャットで伝える

これを _template.mdx に集約しました。frontmatter の雛形、公開前チェックリスト10項目、構成の骨子、書き方ガイドラインが入っていて、チェックリストの冒頭はこんな具合です。

1. 内容確認 — 一次メモと齟齬がないか・AI の創作/誤った憶測が混ざっていないか
2. トーン確認 — 誇張なし・断定は根拠つき・他者/他ツールを批判しない・自分ごととして書く
3. プライバシー確認 — 個人特定情報・別名義が出ていないか
4. 権利関係 — 写っている人の許可・引用/素材のライセンスと出典

あわせて役割分担も決めました。ルールの本体は README、テンプレートは実務用ダイジェスト、AI メモリはセッション横断の指針。三者が矛盾したらテンプレートを直す、という優先順位です。置き場所を1つに決めるだけで、「これどこに書いてあったっけ」が減ります。

「約18分で読めます」をやめて文字数にした

テンプレートのレビュー中に、前から気になっていた読了時間表示の話になりました。うちのブログは「約5分で読めます」のような表示を出していました。もともとこの表示は、サイトのデザインを作ったときに AI が入れてきたもので、私が頼んだものではありません。計算方法 (本文文字数 ÷ 500字/分) を確認したついでに既存記事を実測してもらうと、6,800〜9,200字の記事が並んでいて、表示は「約14分」「約18分」。

でも実際の読み方を考えると、18分の記事を18分かけて読む人は少ないと思うんです。ざっと流し読みして、気になったところだけじっくり読む。時間表示は読み方しだいで大きくずれるのに、1つの数字で言い切ってしまう。20分と言われたら読む前に閉じたくなる、というのもあります。

そこで、記事の見出し下は文字数だけ (「約8,100字」) にして、本文に入る手前に読む目安の行を入れることにしました。

文言はこう転がった

この1行の文言は、レビューのたびに転がりました。

1. 「ここから本文です — 残り 約5,200字 (精読するなら約9分)」 — 初案。でも「ここから本文です」に違和感が出ました。その前のリード文も本文といえば本文です。「精読」も少し固い
2. 「この先 約5,200字 · じっくり読むと約9分」 — 言い方は柔らかくなったものの、ざっと読む人の実態が入っていません
3. 「ここから約5,200字、ざっと読んで約3分、じっくり読むと約9分になります。」 — ざっと (1,500字/分) とじっくり (500字/分) の2段に。ただ、読むスピードは人によって違うのに「なります」と断定しているのが気になってきます
4. 「ここから約5,200字です。ざっと読んで約3分、じっくり読むと約9分が目安です。」 — 文字数は実測値なので言い切り、時間は人それぞれなので目安。ここに落ち着きました

この記事の冒頭に入っているのが最終形です。文をどこで切るかで「目安」が何にかかるかが変わる、というところまで詰めて決めています。

アフィリエイト記事の PR 表記も、記事ヘッダ直下からこの行の隣に移しました。位置を下げてよいか気になったので原典を確認したところ、ステマ規制の運用基準には、事業者の表示であることが「不明瞭」とされる例として「視認しにくい表示の末尾の位置に表示する場合」「周囲の文字と比較して小さく表示した結果、一般消費者が認識しにくい表示となった場合」が挙げられています (消費者庁の運用基準 PDF)。末尾ではなく本文冒頭付近で、独立したブロックにラベル付きで出す、という今の形はこれを踏まえたものです。

公開したら文字数が間違っていた

実はこの文字数表示、公開した直後にバグが見つかりました。見つけたのは私 (人間) です。ある記事のヘッダに「約10,500字」とあるのに、本文手前の行は「ここから約7,900字」。リード文は2,000字もないので、差が合いません。

原因は、ヘッダと本文手前の行が別々の方法で文字数を数えていたことでした。本文手前の行は表示される文章そのものを数えていたのに対し、ヘッダは記事の元ファイル (Markdown) から概算していて、リンクの URL まで文字数に入れていたのです。その記事には商品リンクの長い URL が28本・合計4,860字分あり、これが「約10,500字」の正体でした。数え方を「表示される文章」基準に一本化して解決しています。

後述の付録にも出てきますが、実装中に「日本語の文字数の数え方、間違えてない?」と AI に確認したことがあって、そのときの答えは「数え方は正しい」でした。それ自体は事実だったのですが、結果として別の理由で数字は過大だった。違和感を覚えたら、理屈で納得させられても実物で検算するのが正解だったなと思います。

補足を「一段引いた」見た目にする

もう1つの気になりごとは、本文が平坦なことでした。用語の説明や時点の断り書きのような「読み飛ばしても話の筋に影響しない補足」が、本文と同じ顔で並んでいる。読者が拾い読みするとき、どこが本筋でどこが補足か、見た目で分かるようにしたい。

見た目の案を4つ (左ボーダー / 薄い背景ボックス / ※印 / 折りたたみ) 作ってもらい、実際の記事の一節に当てはめて比較して、左ボーダーを選びました。背景付きのボックスは補足というより強調に見えてしまい、役割と逆でした。1つ上の「文字数のカウント自体は〜」がその実物です。

ラベルをどうするかも、公開済み記事の実文で3パターン比較しました。

好みが分かれるところだと思いますが、私は (a) ラベルなしを選びました。左ボーダーの見た目だけで「一段引いた話」は伝わるので、ラベルは情報として重複ぎみです。「内容に合わせたラベル」も捨てがたかったのですが、それを許すと AI がラベルを多用しそうで、制御しきれない予感がありました。装飾の選択肢を増やすより、使い方を1つに絞るほうが、書くときも読むときも迷いません。本当に重要な注意なら、それは読み飛ばしてよい補足ではないので本文に書きます。

積み残していたコントラスト不足も、ついでに直した

補足も読む目安の行も「薄い色の小さめ文字」なので、この機会に持ち出した積み残しがあります。実はうちのサイトは、日付などのメタ情報の文字色が Lighthouse (ページ品質の監査ツール) にコントラスト不足を指摘されることを前から把握していて、「そのうちまとめて直そう」と後回しにしていました。AI はそこをスルーしていたので、「PageSpeed Insights で見た目の指摘が入らない?」という聞き方で改めて確認してもらいました。

実測すると、既存の薄文字色はコントラスト比 3.81:1 で、WCAG (Web アクセシビリティの標準) の AA 基準 4.5:1 に届いていませんでした。薄い文字を増やすこのタイミングで放置はできないので、「控えめに見えて基準は満たす」色を計算で探してもらい、5.04:1 の色に全サイト置き換え。並べて見ないと気づかない程度の変化です。控えめな色を感覚で選ぶと基準を割ることがある、数値で確かめる工程を挟む、が教訓です。

まとめ

テンプレート化の目的は、記事の品質と全体の統一感でした。それはチェックリストとガイドラインの形になりましたが、振り返ると、レビューの往復で拾えた違和感 — 読了時間って実態に合ってる? 補足が本文と同じ顔をしてない? この色、基準満たしてる? — のほうが、読みやすさには効いた気がします。

実のところ、改善したいことは普段から心の中にいくつもあって、issue を立てるほどでもないものは寝かせています。そういうものを「今この AI セッションなら文脈を理解しているし、すぐ直せそうだから、ついでにお願いしちゃおう」と本題に相乗りさせるのを、ちょいちょいやっています。読了時間の見直しもコントラストの修正もそれでした。本題より、ついでのほうが記事になる。そういうこともあります。

この記事の冒頭にも 📖 の行が入っています。ざっと読むか、じっくり読むかは読者の自由 — その選択の材料を渡すのが、書き手にできる小さな親切かなと思っています。

付録: Claude Code とのやりとり (抜粋)

15往復のレビューから、方針が動いた場面を抜粋します。

最初の実装は「最初の見出しの直前に自動挿入」でした。動くものを見てから、仕組みの硬さが気になった場面です。

読了時間の計算レートを決めるとき、過去に AI の数え間違いを見てきた経験から確認を入れた場面です。

このときの回答自体は事実でしたが、のちにヘッダの文字数は別の理由 (URL の混入) で過大だったことが分かります。「カウントを間違えていないか」という違和感は、本質的に当たっていたわけです。

コントラストの件は、私が把握していた積み残しを AI がスルーしていたので、質問の形で持ち出した場面です。

補足のラベルを議論した場面。AI に裁量を渡す設計をやめる、という判断です。

振り返ると、拡張性・読み方の実態・制御できるか、という判断の軸を出すのが私の役割で、実測・実装・選択肢の提示が AI の役割でした。そして、AI の説明に納得しても違和感が残るなら実物で検算する。今回はそれで1つバグを見つけています。

参考リンク

一次情報 (公式ドキュメント):

• WCAG 2.1 (W3C) — コントラスト基準 (達成基準 1.4.3、通常文字 4.5:1) の一次情報
• ステルスマーケティング規制 (消費者庁) — 景品表示法の指定告示のページ。本文で引用した運用基準 (PDF) はここから
• PageSpeed Insights について (Google) — 本文で触れたページ品質計測ツールの公式ドキュメント

同じテーマの記事・体験談:

• ブログに「この記事は約何分で読めます」と書いてあることの意味 (WEBCRE8.jp) — 読了時間表示を「読むかどうかの判断材料として明示すべき情報」と捉える考察。メタ情報はなんでも表示すればいいわけではない、というのはそのとおりだと思いました。うちの文章も長めになってきていて出さなくてもいいのかもと思い始めていますが、それでも正直にありたい気持ちがあって、いまは出す側にいます
• Claude Codeでブログ執筆を効率化する方法 - 自分らしい文章を保ちながら (note・hidenorigoto さん) — 過去記事から文体の特徴を抽出して CLAUDE.md のスタイルガイドに育てていく方法。やっていることが似ていて、執筆方針に出てくる「誇張せず誠実な表現」という一節がうちのルールと同じで、ほっこりしました。裏を返すと、AI はやはり放っておくと誇張に流れやすい、ということなんだと思います。読んで思いついた改善点もあって、うちはレビューが体系化されておらず私が第1レビューをしている状態なので、そこも Claude Code に任せてみようかなと思っています。いまはレビューに7割くらいの力を使っているので、もう少し早く書いて、早く出したい
• Claude Codeを使ってAIにブログ記事執筆を任せてみた (tacoms テックブログ) — 文体ガイドを整備し、インタビュー・執筆・推敲を AI エージェントで分担させる構成。インタビュアーエージェントがいいですね。いまは「先に要求を確認して」と毎回お願いしているので、最初からそういう挙動にしたいところです。ブログ以外でも、プロダクト開発の要件ヒアリングに使えそうです