記事の公開前チェックリスト:機械に渡す項目を先に抜く

公開前チェックリストは、作った直後がいちばん使われます。数週間もすると、開かれなくなる。原因は意志の弱さではなく、項目数のほうにあります。

項目が20も並んだリストを、公開のたびに上から潰せる人はいません。しかもその大半は、人が目で追わなくても判定がつく項目です。「お問合せ」と「お問い合わせ」のどちらに寄せるかに、編集者の判断は要らない。

だから作る順番を逆にします。まず機械に渡せる項目を抜き、残ったものだけでリストを組む。そうすると、公開のたびに回せる長さになります。

目次

書き終わりから公開までの4地点に割る

公開前チェックを書き終えた直後から公開直前まで4地点に割った手順の図

先にリストを出します。★を付けた行が、機械に渡せる項目です。

1枚の長い表にしないのは、順番が消えるからです。順番が消えたリストは「公開直前にまとめてやるもの」になり、そこで力尽きる。

書き終えた直後(本人が原稿を閉じる前)

  • ★ 表記ゆれ・冗長表現・全角半角・句読点
  • ★ 一文の長さと、1文に入る読点の数
  • ★ です・ます/だ・である の混在、同じ語尾の連続
  • ★ タイトル・スラッグURLの末尾に使う、投稿やカテゴリーごとの英数字の名前。このサイトなら plugear.net/wordpress-japan-map/ の「wordpress-japan-map」の部分。・抜粋・メタディスクリプションの表記
  • 見出しだけを続けて読んで、記事の流れが伝わるか
  • この記事が誰のどんな状況に答えるものか、1行で言えるか

自分で読み返す(できれば数時間おいてから)

  • 結論が冒頭で分かるか
  • 数字・固有名詞・日付に出典があるか
  • 画像に代替テキストが入っているか、出典と利用条件は確認したか
  • 貼ったリンクが意図した先へ飛ぶか

他人が読む(編集レビュー)

  • ★ 禁止語・注意語が残っていないか
  • 想定読者とズレていないか
  • 過去記事と主張が食い違っていないか
  • 事実として合っているか

公開ボタンの直前

  • ★ 校正を1回実行し、重大な指摘がゼロか
  • カテゴリ・タグ・アイキャッチ・公開日時
  • 公開後にスマホ幅で1回開く

★の6行を人の手から外すと、残るのは11項目。この長さなら毎回やれます。

4つに割ったのは、直すのに時間がかかる項目を前に置きたいからです。公開直前に全部やる形にすると、見出しの流れや結論の位置——書き直しが要る項目ほど後ろに来てしまい、「次の記事から直す」で終わる。

★の6行は、リストではなく編集画面に置く

公開前チェックのパネルに、Error指摘が残るとブロックされる旨と該当指摘が並んでいる画面

★を「やらなくていい」に読み替えると、ただ品質が落ちます。人のリストから外して、機械の側へ移すという意味です。

移し先を編集フローのどこに置くかという設計は編集フローに校正を組み込むに書きましたが、リストを作る側から見ると置き場所は1つしかありません。書いている画面の中です。日本語校正マネージャーの場合はブロックエディタのサイドバーで、編集中に実行すると指摘が8種別に分かれて並びます。★のうち5行は、この8種別にそのまま対応する。残る1行——公開直前の「校正を1回実行」——だけは、種別ではなく実行そのものを指しています。

リストとの決定的な違いは、閾値を数字で持っていることです。一文の文字数や読点の数には既定値があり、あとで変えられる(その数字をどう扱うかは一文の長さの基準に書きました)。数字があると、指摘を待つ前に書き手が自分で判定できます。

ボタン一つで直せるのは、置き換え先が一意に決まる3種別だけ——表記ゆれ、冗長表現、全角半角。長文や文体の指摘に修正ボタンは出ません。どこで文を割るかは構造を読まないと決まらないので、機械が決めるべきではない。

本文の外にある項目は、リストからも落ちる

チェックリストで最後まで残りやすいのが、メタディスクリプションとスラッグです。本文はレビューの動線に乗っているのに、SEOプラグインのパネルは開かないと見えない。この落ち方の構造は本文以外のフィールドの校正に書いたので繰り返しません。

リストを組む側で決めることが1つあります。タイトル・スラッグ・抜粋と、Yoast SEO / Rank Math / All in One SEO のSEO欄は同じ辞書・同じルールで見ますが、評価されるのは保存したときと手動でチェックしたときだけ。編集中に勝手には走りません。つまり「公開直前に校正を1回実行する」という行為が、そのまま本文外フィールドのチェックを兼ねます。この1行をリストに残すか、人の習慣に委ねるか。運用の判断はそこです。

人が見る11項目は、ツールを強くしても減らない

機械に渡す6行と、人が読んで守る11項目を左右に並べた比較の図

残った11項目を、もっと機械に寄せられないか。ここは短く線を引いておきます。

渡せるかどうかは、ツールの性能ではなく指摘の性質で決まります。判断材料が文字列の中で完結していれば渡せる。記事の狙いや過去記事との関係が要るものは渡せない。ルール側は形態素解析をしていないので文脈を読んだ判断はできませんし、AI最終チェックを足しても返るのは誤字脱字・読みやすさ・表記の一貫性の指摘まで。ファクトチェックはしません。

だから11項目は、減らす対象ではなく守る対象になります。ここに時間を使えるようにするために、★を外した。

チェックしたかどうかを、公開の条件にする

リストの最大の弱点は、飛ばしても何も起きないことです。

日本語校正マネージャーには公開前ゲートがあります。ただし止まるのは、その記事に効いているプロファイルで公開ブロックが有効で、かつError指摘が残っているときだけ。同梱の既定プロファイルは公開ブロックなしなので、入れただけでは何も止まりません。条件と抜け道の設計は前掲の編集フローの記事に、何をどの順番でErrorに上げるかは薬機法・景表法のNG表現を止めるのほうに書きました。

リストの側から見れば、公開の条件にできるのは★の最後の1行——「校正を1回実行して、Errorがゼロ」——だけです。ゲートが受け持つのはそこまで。残る11項目は止める対象ではなく、人が読む対象として残しておく。

明日から回すための最初の1本

このリストを自分のメディアに合わせるなら、次の順で削るのが早いはずです。

まず、直近に公開した記事1本を開いて、公開前に見た項目を全部書き出す。次に、その中で「判断材料が文字列の中だけで済むもの」に印を付ける。印が付いた行は、リストから消して校正ルールと辞書のほうへ移す。残りが、あなたのメディアの公開前チェックリストになります。

このサイトの記事も、投稿前のチェックは同じ考え方で機械と人に割ってあります。文末が「です・ます」ばかりになっていないか、同じ言い回しを1本の中で何回使ったか、書き出しが直前の記事と同じ型になっていないか——このあたりは自前のスクリプトに数えさせて、下書きのフォルダごと一度に流す。機械に渡したのは文体の数値項目だけで、結論が早い段階で分かるか、誰向けか分かるか、一次情報があるか、といった判断は人のリストに残したままです。

11項目という数は、この記事で並べたリストの場合の結果なので、そのまま使う必要はありません。大事なのは、残ったリストが人にしか判定できない項目だけになっているかどうか。そこまで削れていれば、来月も開かれます。

人のリストに何を残すかは媒体ごとに変わりますが、機械側へ渡せる8種別が何を見ているかと動作環境は、日本語校正マネージャーの製品ページにまとめてあります。

目次