記事公開前に確認すべき項目一覧｜品質のばらつきを防ぐ

「忙しい週に出した記事だけ、誤字や出典の抜けが残る」「担当は同じなのに、記事ごとの出来が揃わない」——本数を増やしたメディアが次にぶつかる壁です。品質のばらつきは、書き手の力量差ではありません。確認の工程が、忙しさに応じて省かれているだけです。この記事では、公開前に見る項目を3層に分け、誰がどの順で確かめるかを整理します。

公開直前の15分が品質を決める

記事の品質は執筆時間の長さでは決まりません。丁寧に書いた記事でも、事実確認を飛ばせば誤情報が残り、リンクを確認しなければ切れたままになります。逆に、公開前の15分を必ず確保している運用では、記事ごとの当たり外れが小さくなります。品質のばらつきは、能力差ではなく工程の有無から生まれます。

15分という時間には理由があります。これ以上長い工程を設計すると、忙しい週に省略されます。省略される可能性のある手順は、運用として存在しないのと同じです。必ず実行できる長さに収めることが、チェック設計の最初の要件になります。

この15分で見るのは、記事を良くするための項目ではありません。公開してはいけない状態になっていないかを確認するだけです。文章を良くする作業は執筆と編集の工程で、公開前チェックは事故の検出に絞る。目的を分けると、時間が守れます。

注意力に頼ると必ず漏れる

チェックを「気をつける」で運用すると、必ず漏れます。人は自分が書いた文章の誤字を読み飛ばし、確認したつもりのリンクを開いていません。これは能力の問題ではなく、認知の仕組みの問題です。だからこそ、リスト化して目で追う形にする必要があります。

実務で効くのは、確認の順序を固定することです。毎回同じ順で同じ項目を見る。順序が固定されていると、途中で中断しても再開位置が分かります。順序が決まっていないチェックは、毎回違う項目が漏れます。

もう1つの工夫は、チェック項目を「はい/いいえ」で答えられる形にすることです。「読みやすいか」は判断が揺れますが、「1段落が5行を超えていないか」は誰が見ても同じ結論になります。判断ではなく確認で答えられる項目に落とすと、担当者が変わっても品質が揺れません。

チェックは3層に分ける

項目を並べる順序として、3層に分ける方法が扱いやすいです。第1層は事実と出典。ここに誤りがあると、記事の価値そのものが失われます。第2層は文章と表記。読みやすさと信頼感に関わります。第3層は技術とCMS設定。公開の事故に直結します。

この順序には意味があります。事実が誤っている記事は、表記を整えても公開できません。逆に、事実が正しくてもCMS設定を間違えれば、記事は誰にも読まれないか、意図しない形で公開されます。致命度の高い層から確認するのが、時間が足りない時の優先順位になります。

3層に分けると、担当の分担もしやすくなります。第1層は内容を理解している人、第2層は文章を見る人、第3層はCMSを触る人。1人で全部やる場合も、層を意識して切り替えると精度が上がります。

第1層：事実と出典の確認

最初に見るのは、書かれている事実が確認できるかどうかです。数字、固有名詞、制度名、日付、引用。これらは1つずつ出典に当たって確認します。「以前調べた記憶」で書いた数字がもっとも危険で、実際に確認すると変わっていることがよくあります。

確認すべき項目は5つに整理できます。①数値の出典があるか ②出典が一次情報か ③情報の時点が明記されているか ④引用の範囲が適切か ⑤断定していい内容かどうか。とくに⑤は生成AIを使った記事で問題になりやすく、確認できない内容が断定形で書かれていないかを見ます。確認できないことは、書かないか留保表現にするのが原則です。

出典の書き方も統一しておきます。媒体名、公表時期、参照日。リンクを張る場合は、リンク先が現在も存在するかを確認します。制度や仕様の説明では、いつ時点の情報かを本文に入れておくと、時間が経っても誤解を生みません。「現在」という語は、公開の翌年には嘘になります。

第2層：文章と表記の確認

第2層は、読みやすさと表記の統一です。誤字脱字、機種依存文字、表記ゆれ、二重表現、極端に長い段落。ここは指摘されやすい部分でもあり、記事の信頼に直結します。ブラウザで実際の表示を見ながら確認するのが確実です。

表記ゆれは、社内でルールを1枚決めておくと確認が速くなります。「Web/WEB/ウェブ」「サーバ/サーバー」「AI/生成AI」など、頻出するものだけで十分です。ルールがあれば、判断ではなく照合で済みます。ゆれを見つける時間より、ルールを決める時間のほうが短いのです。

読みやすさの確認は、機械的な基準に置き換えます。1段落が5行を超えていないか、同じ接続詞が連続していないか、1文が80字を超えていないか。数字で判定できる形にすれば、書き手以外でも確認できます。感覚で判断する項目を残すと、担当者によって結果が変わります。

第3層：技術とCMS設定の確認

第3層は、公開事故を防ぐための確認です。ここは項目が多いため、表にして毎回同じ順で追うのが確実です。以下は、実務で漏れが起きやすい項目をまとめたものです。

確認項目	見る場所	よくあるNG
slug（URL）	投稿設定	日本語が入っている／別記事と重複している
見出し構造	本文	H2の下にH2が続く／H3から始まっている
メタ（抜粋）	投稿設定	空のまま／本文の冒頭がそのまま入っている
内部リンク	本文	関連記事へのリンクがゼロ／リンク先が404
外部リンク	本文	リンク切れ／別タブ設定の不統一
画像	本文・アイキャッチ	alt未設定／サイズが大きすぎる／権利未確認
カテゴリ・タグ	投稿設定	未分類のまま／過去記事と粒度が違う
公開設定	投稿設定	noindexが残っている／予約日時が過去になっている
著者情報	投稿設定	テスト用アカウントのまま／プロフィールが空

この表の項目は、CMSによって名称が変わります。自社の管理画面の言葉に置き換えて、実際の画面の並び順に合わせておくと確認が速くなります。画面の順序とリストの順序を揃えるだけで、所要時間が半分になります。

生成AIを使った記事で増える確認

生成AIを執筆に使う場合、確認項目が3つ増えます。1つ目は、存在しない出典や事例が混ざっていないか。実在しない調査名や書籍名が自然な文体で書かれていることがあり、文章の質からは判別できません。必ず個別に検索して確認します。

2つ目は、日本語以外の文字や不自然な語が混入していないかです。長文の生成では、中国語の簡体字やキリル文字、英単語の断片が混ざることがあります。目視では見落としやすいため、非日本語文字を検出する簡単なスクリプトを1つ用意しておくと確実です。混入は文章の意味が通っているぶん、読んでも気づけません。

3つ目は、他社の表現をそのまま再現していないかです。特徴的な言い回しやフレーズが気になった場合は、その部分を検索して一致がないか確認します。あわせて、社内の生成AI利用ルールに沿った使い方になっているかも点検の対象です。AIを使うほど、確認の工程は増える。速く書ける分を確認に回すという前提で運用設計してください。

表現と法令の確認

BtoBの記事でも、表現の規制は無関係ではありません。効果や優位性を示す表現、他社との比較、顧客の声の掲載。いずれも根拠の裏付けが必要で、表現によっては問題になります。公開前に確認する項目として、リストに入れておくべき領域です。

具体的には、①最上級表現（業界初・No.1）に根拠と時点があるか ②効果の断定をしていないか ③他社比較が公平な基準に基づいているか ④体験談や推薦を掲載する場合に関係性が明示されているか。この4点を見るだけでも、大きな事故は避けられます。判断に迷う表現は、削るか留保表現に変えるのが早いです。

引用や画像の権利も同じ層で確認します。他社の図表を引用する場合は出典明記と引用の範囲、画像素材はライセンスの条件。「たぶん大丈夫」で公開したものが、後から一番大きな問題になります。判断がつかない場合は、その素材を使わない選択が最短です。

誰がチェックするか

チェックの担当は、書き手以外を含めるのが原則です。自分の文章のミスは、書いた本人にはほぼ見えません。理想は2名体制で、1人が内容と表記、もう1人がCMS設定を見る形です。1人しかいない場合は、執筆から時間を空けて別の環境（印刷・スマホ表示）で読むと、検出率が上がります。

公開作業をする人とチェックする人を分けるのも有効です。公開担当者は手順に集中しているため、内容の違和感に気づきにくい。作業者と確認者を分けることが、もっとも安価な品質担保です。組織が小さくても、相互チェックの形は作れます。

外部ライターに書いてもらう場合は、チェックリストを共有して自己点検まで依頼します。そのうえで社内が確認する二段構えにすると、修正のやり取りが減ります。基準を渡さないまま修正指示を出すのは、双方の時間を消費します。

15分の型に落とし込む

実際の運用では、時間配分を決めておくと守りやすくなります。以下は1本あたり15分を想定した進め方です。

この型を数回回すと、自分の癖として漏れやすい項目が見えてきます。漏れが2回続いた項目は、リストの先頭に移動させる。リストの順序は、自社の事故履歴に合わせて変えていくものです。

見落としが多い項目

運用の現場で繰り返し発生する見落としには、明確な傾向があります。以下は、公開後に発覚しやすい代表例です。

• 公開設定でnoindexが残っている（誰にも読まれないまま数週間経過する）
• 予約公開の日時が過去になっており、意図せず即時公開される
• アイキャッチが未設定、または前の記事の画像が流用されている
• 内部リンクの張り先が下書きのURLになっている（公開後に404）
• 抜粋（メタ）が空で、検索結果に本文の冒頭が機械的に表示される
• スマートフォン表示で表が横にはみ出している

これらはいずれも、内容の良し悪しとは無関係な事故です。記事の価値を、設定の不備で捨てないための工程が公開前チェックだと考えると、15分の投資は割に合います。

公開後15分でやる確認

公開前チェックと同じくらい重要なのが、公開直後の確認です。管理画面上では正常に見えても、公開されたページで崩れていることがあります。公開ボタンを押したら、そのまま実際のURLを開いて確認します。

見るのは4点です。①公開URLが意図した形になっているか ②スマートフォン幅で表示が崩れていないか ③SNSでシェアした時のカード表示（画像とタイトル）が正しいか ④サイト内の一覧ページに正しく並んでいるか。ここまで確認して、公開作業は完了です。公開は押した時点ではなく、表示を確認した時点で終わります。

インデックス状況の確認は、当日ではなく数日後に行います。公開直後は登録されていないのが普通で、慌てて再送信を繰り返す必要はありません。1週間経っても登録されない場合に、URL検査で状態を確認します。

チェックの記録を残すか

チェックを実施した記録を残すかどうかは、運用の規模で決まります。1人運用なら記録は不要で、リストを見ながら確認するだけで十分です。複数名が関わる場合は、誰がいつ確認したかを記録しておくと、問題が起きた時に工程のどこで漏れたかが分かります。

記録の形式は簡単なものにします。記事のタイトル、確認者、確認日、気になった点の1行メモ。スプレッドシート1枚か、CMSの内部メモ機能で足ります。記録の目的は責任追及ではなく、漏れやすい工程の特定です。ここを取り違えると、記録が形骸化します。

記録が溜まると、傾向が見えてきます。特定の項目で毎回同じ指摘が出ている場合は、執筆時のテンプレートを直したほうが早い。たとえば内部リンクの漏れが続くなら、記事の下書きテンプレートに「関連記事を書く欄」を用意しておく。チェックで毎回直している項目は、上流の工程で解決できます。

逆に、記録することで負担が増えるなら省いて構いません。チェック自体の実行率が下がるくらいなら、記録はなくてよい。優先すべきはチェックの実施であり、記録はその補助です。運用が回り始めてから、必要に応じて足す順序が現実的です。

本数が増えた時の運用

週に1〜2本なら個別に丁寧なチェックができますが、週10本になると同じやり方は成立しません。この段階で必要になるのは、チェックの階層化です。全記事に対する最小限の確認と、重要記事に対する追加の確認に分けます。

最小限の確認は、技術層に絞ります。slug・公開設定・アイキャッチ・メタ・リンク切れ。これらは自動化しやすく、機械的に処理できます。追加の確認は、検索経由の流入を狙う記事や、事業に直結するテーマの記事に限定して、事実確認と表現の確認を人が行う。全記事を同じ深さで見るのをやめると、重要な記事の品質が上がります。

本数が多い運用では、公開のタイミングをまとめるのも有効です。毎日公開するのではなく、週2回にまとめる。まとめれば、チェックの工程も集中して実施でき、確認の抜けが減ります。公開頻度を分散させると、チェックの工程も分散して形骸化します。

外部ライターを複数使う場合は、初稿の段階で機械的に判定できる基準を渡します。文字数、見出し数、出典の記載方法、表記ルール。基準に合わない原稿は、内容を読む前に差し戻す。読む前に判定できる基準を持つことが、量に耐える運用の条件です。

リストを育てる仕組み

チェックリストは、作った時点が最も不完全です。事故が起きるたびに項目を1つ足していくことで、自社の実情に合ったリストになります。運用としては、公開後に見つかった問題を記録し、月に一度リストへ反映する形が現実的です。

• 事故が起きたら、原因ではなく「どの項目があれば防げたか」を1行で記録する
• 項目が増えすぎたら、発生していない項目を削る。20項目を超えると実行率が落ちる
• CMSの仕様変更やテーマ更新のあとは、技術層の項目を見直す
• 外部ライターに渡すリストは、社内用から技術層を除いた簡易版にする

項目の追加で迷うのは、1度しか起きていない事故をリストに入れるかどうかです。判断基準としては、影響の大きさで決めます。読者に誤情報が届く、法的な問題になる、記事が読まれない状態になる——この3つに当たるなら1度でも入れる。それ以外は2度目が起きてから追加する。影響の大きい事故は1回目で、小さい事故は2回目でリスト化するという線引きが運用しやすいです。

自動化の範囲は、CMSやツールの環境によって変わります。リンク切れの巡回、画像の容量チェック、表記ゆれの検出はプラグインやスクリプトで対応できることが多い。一方で、出典の妥当性や表現の適切さは自動判定に向きません。機械が判定できる項目から順に自動化し、人は判断が必要な項目に集中する配分にすると、チェックの所要時間が下がります。

リストの見直しは、四半期に一度の短い作業として設定します。追加した項目、削った項目、発生した事故を1枚に残しておけば、担当者が変わっても運用が続きます。チェックリストは記事と同じく、更新されないと劣化します。CMSのバージョンアップやテーマ変更のあとは、必ず技術層を見直してください。

自動化できる部分は、ツールに任せます。リンク切れの検出、表記ゆれの検出、非日本語文字の検出、画像サイズの確認。これらはスクリプトやプラグインで機械的に処理できます。人が見るべきなのは、判断が必要な項目だけです。

よくある質問

Q. チェック項目は何個くらいが適切ですか。
15〜20項目が実行しやすい範囲です。それ以上になると省略が始まります。項目を増やしたい場合は、既存項目の中で発生していないものを削って入れ替えてください。

Q. 1人で運用しています。自分でチェックするしかありません。
執筆と確認の間に時間を空けるのが最も効果的です。翌朝に確認する、印刷して読む、スマートフォンで読む。環境を変えると、同じ文章でも見え方が変わります。

Q. 公開前チェックで内容の修正が必要になったらどうしますか。
公開を延期します。チェックの目的は事故の検出であり、内容の書き直しは執筆工程に戻すべき作業です。無理に公開日を守ると、その記事が後の手戻りを生みます。

Q. 生成AIでチェック自体を自動化できますか。
表記ゆれや誤字、構造の確認は補助として有効です。ただし事実確認と権利の判断は人が行う必要があります。AIの指摘を鵜呑みにせず、指摘箇所を人が確認する形にしてください。

Q. 過去に公開した記事にも同じチェックをかけるべきですか。
全件に遡る必要はありません。流入の多い上位20本と、事業に直結するテーマの記事に限って点検すれば、影響の大きい問題は拾えます。過去記事の点検は、影響が大きい順に上から20本だけと決めておくと着手できます。残りは記事を更新するタイミングで、その都度確認する形が現実的です。

Q. 公開直前に上司から修正指示が入る運用です。どう組み込めばよいですか。
承認の工程は、公開前チェックより前に置きます。承認後に本文が変わると、チェック済みの内容と公開する内容が別物になるためです。順序は「執筆→承認→公開前チェック→公開」。この並びを崩さないことが、事故を防ぐ最短の設計です。

まとめ

公開前チェックは、記事を良くする工程ではなく、公開してはいけない状態を検出する工程です。事実と出典・文章と表記・技術とCMS設定の3層に分け、致命度の高い順に確認する。判断ではなく確認で答えられる項目に落とし、書き手以外の目を1つ通す。そして公開後15分で実際の表示を見る。この15分の型を守るだけで、記事ごとの品質のばらつきは目に見えて小さくなります。事故が起きたら項目を1つ足し、リストを育て続けてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。