オウンドメディア棚卸しスコア表の作り方｜評価軸・配点・閾値を設計する実務手順

監修: 菊地 将（リブランディング株式会社）

数十〜数百本の記事を複数人で棚卸しするとき、判断基準を知っているだけでは運用は安定しません。担当者ごとに「重要」「古い」「重複している」の解釈が違えば、同じ記事でも採点や着手順が変わるためです。必要なのは、判断基準を誰でも同じ手順で使える列・配点・数式・ゲート条件へ変換することです。

本記事は、維持・リライト・統合・公開終了の判断基準そのものを解説する記事ではありません。判断基準は関連記事「オウンドメディア記事のリライト・統合・削除判断｜古い記事を棚卸しする6つの基準」で整理しています。本記事では、その基準を理解済みの担当者向けに、スプレッドシートへ実装する方法だけを扱います。

完成させるのは、1URLを1行として「入力→採点→ゲート確認→着手候補抽出→人間確認→履歴更新」まで追える棚卸しスコア表です。100点の記事価値スコア、処置別スコア、5段階ルーブリック、20〜30記事での閾値校正、採点者間の差1以内率、変更履歴の残し方まで、実装単位で整理します。

棚卸しを含むオウンドメディア全体の効果測定・改善サイクルは、「オウンドメディアの効果測定・改善とは？見るべき指標・使うツール・PDCAの回し方の全体像」で整理しています。

サンプル列構成｜1URL＝1行で入力・採点・判定根拠・履歴を持つ

最初に列設計を固定します。1URLを1行とし、元データ、採点値、点数根拠、ゲート、候補判定、実施履歴を同じ行で追えるようにすると、数か月後の再測定でも「なぜこの点数・判定だったか」を復元できます。Search ConsoleとGoogle Analyticsは計測対象や指標体系が異なるため、同じ数値列へ混ぜず、指標名と出典を分けて持ちます。

区分	必須列の例	目的
基本情報	記事ID／URL／タイトル／公開日／最終更新日	対象を一意に識別する
検索実績	クリック／表示回数／CTR／平均掲載順位／対象期間	検索結果での機会と実績をそろえる
事業実績	CV・キーイベント／営業利用／重要導線	検索流入以外の価値を残す
定性評価	検索意図一致／内容品質／独自性／資産性	数値だけでは見えない価値を採点する
スコア	記事価値／リライト／統合／削除候補	役割と作業優先度を分ける
判定管理	ゲート条件／最終判定／判定理由／判定者	自動判定の誤りを防ぐ
履歴	実施日／変更内容／レビュー日／次回確認日	改善後の再測定につなげる

比較期間も列として固定します。たとえば直近90日で評価するなら原則すべての記事を同じ90日で比較し、季節性が強いテーマは前年同期を別列で持ちます。期間条件まで残しておくと、次回監査で数値の意味が変わる事故を防げます。

記事価値×処置別必要性｜1つの総合点に混ぜない

記事価値スコアは「このURL・内容をサイト資産として残して育てる価値」を共通尺度で表す点数です。処置を直接決める点数ではありません。まずは5軸・100点など管理しやすい形から始め、事業目標に応じて重みを調整します。

評価軸	配点	5点の状態	1点の状態
事業貢献	25	CV・商談・営業利用など明確な役割がある	事業成果との接点を確認できない
検索実績・需要	25	継続的な表示・クリック、または明確な需要がある	需要・表示機会ともほぼ確認できない
内容品質・正確性	20	現在の問いに十分答え、根拠・具体性もある	古い・不足・誤解を招く箇所が多い
独自性・役割	20	他記事で代替できない回答や一次情報がある	他記事と役割がほぼ同じ
資産性	10	被リンク・指名参照・重要な内部導線がある	URL固有の参照価値が乏しい

配点は「重要そうだから25点」と感覚で決めるのではなく、棚卸しで守りたい成果から逆算します。問い合わせ獲得型なら事業貢献を重くし、専門情報の蓄積を重視するなら独自性や資産性を重くします。重みの理由は別の「配点根拠」列へ一文で残してください。

5段階ルーブリックと数式で自由採点をやめる

各軸を0〜25点の範囲で自由採点すると、担当者差が大きくなります。入力は1〜5の5段階に固定し、配点へ換算します。基本式は「軸スコア＝評価値÷5×配点」です。評価値と配点を別セルに置けば、重みを変えても計算式そのものを修正せずに済みます。

評価	定義の型	事業貢献の例
5	継続的かつ重要	複数のCV、営業利用、重要導線への寄与が確認できる
4	明確にある	CVまたは営業利用など、残す理由が説明できる
3	限定的にある	補助的な成果・導線として機能している
2	弱い／不明確	成果との接点はあるが、再現性が乏しい
1	確認できない	現時点で事業上の役割を説明できない

ルーブリックには「定義」だけでなく、「参照列」と「点数根拠」をセットで持たせます。たとえば事業貢献4点なら「直近90日で資料請求2件、営業共有3回」のように根拠を残します。レビューでは点数の大小ではなく、根拠がルーブリックに合っているかを確認できます。

数式例｜入力値・配点・判定を別セルに分ける

数式は「入力」「重み」「結果」を分離すると保守しやすくなります。以下は考え方を示す例です。列位置は実際のシートに合わせて調整し、配点や閾値は固定値を式へ直接書かず、設定セルを参照してください。

計算対象	入力例	数式例	実装ポイント
軸スコア	評価値=4、配点=25	=評価値セル/5*配点セル	配点を変更しても式を共通化する
記事価値	5軸の換算点	=SUM(各軸スコア範囲)	処置別スコアと混ぜない
差1以内	採点者A=4、B=3	=IF(ABS(A評価-B評価)\<=1,1,0)	一致件数を集計し、率へ変換する
ゲート判定	重大誤情報=TRUE	=IF(ゲートセル,”要確認”,”通常判定”)	ゲート成立時は自動確定しない

配点は「目的→軸→重み→例外」の順で決める

配点は最初から正解を当てるものではありません。どの事業判断をスコアで支援するのかを先に決め、その目的に必要な評価軸だけへ重みを付けます。例外条件まで点数へ詰め込むと説明しにくくなるため、重大な例外は後述のゲート列へ分離します。

棚卸しで最も守りたい成果を1つ決める。例：問い合わせ獲得、認知、専門情報の蓄積。

その成果に直接関係する評価軸を3〜6個に絞る。似た軸を増やしすぎない。

合計100点になるよう重みを付け、なぜその配点なのかを一文で記録する。

重要な例外は点数へ無理に埋め込まず、後述のゲート条件へ分離する。

試験採点で明らかな違和感が出た軸だけを修正し、全配点を毎回変えない。

Googleはコンテンツの自己評価として、独自情報・十分な説明・読者にとっての有用性など複数の観点を示しています。こうした質的観点は、クリック数や表示回数とは別の定性列としてルーブリック化すると、実績値だけに偏らない採点がしやすくなります。

処置別スコアは「何をするか」ではなく「着手候補の強さ」を数値化する

記事価値が高いことと、今すぐ直す必要があることは同じではありません。価値が高くても現状で十分なら着手不要であり、価値が中程度でも改善余地と機会規模が大きければ優先候補になります。そこで記事価値とは別に、リライト・統合・公開終了などの「候補として確認すべき強さ」を処置別スコアで持ちます。最終処置は点数だけで確定しません。

リライト優先度スコアの実装例

要素	配点例	高得点になる状態
改善余地	30	検索意図への回答不足、古い情報、弱い導線が明確
機会規模	25	表示回数・需要が大きく、改善の影響範囲が広い
検索結果の取りこぼし	20	表示はあるがCTRやクリック獲得に改善余地がある
放置リスク	15	料金・制度・仕様など更新遅れの影響が大きい
事業重要度	10	重要サービス・重要導線に近い

初期閾値として70点以上を優先候補、50〜69点を通常候補などと仮置きできます。ただし、これは外部の基準ではなく自社運用の初期値です。候補数と月間更新可能本数が合うよう、20〜30記事の試験採点で校正します。

統合候補スコアの実装例

要素	配点例	確認ポイント
主要検索意図の一致	35	同じ読者が同じ問いへの答えを求めているか
回答範囲の重複	25	主要H2・結論・読後行動が重なるか
クエリ重複	15	実際の流入クエリが競合しているか
内部競合	15	同一テーマでURLが分散し代表ページが曖昧か
集約メリット	10	一本化で情報・リンク・導線を集める価値があるか

統合候補スコアは「人が重複を確認する対象」を絞るために使います。高得点でも自動統合せず、同じ読者が同じ問いへの答えを求めているかを人が確認します。統合そのものの判断基準やURL処理は関連記事へ委ねます。

公開終了候補スコアの実装例

要素	配点例	高得点になる状態
需要の弱さ	25	検索・閲覧需要がほぼない
事業貢献の弱さ	25	CV・営業・サポート用途がない
独自価値の弱さ	20	他記事で代替可能
資産性の弱さ	15	被リンク・重要内部リンク・参照価値が乏しい
維持コスト／陳腐化	15	更新負荷が高く、誤情報化のリスクがある

公開終了候補スコアも「高いほど削除してよい」という自動処分ルールではありません。需要・事業貢献・独自価値・資産性・維持負荷を同じ尺度で比較し、確認対象を抽出するために使います。維持・統合・公開終了の一般的な判断基準やURL処理は、関連記事「オウンドメディア記事のリライト・統合・削除判断｜古い記事を棚卸しする6つの基準」に委ねます。

ゲート条件｜点数より先に人間確認を強制する

スコアは比較には強い一方、重大な例外を平均化してしまいます。そこで、点数に関係なく先に確認する条件を「ゲート」列として持たせます。ゲートが立った行は自動判定を確定させず、「要確認」として人間レビューへ送る設計にします。

ゲート条件	スコアより先にすること	理由
重大な誤情報がある	最優先で修正へ	法律・料金・仕様などは低流入でも放置しない
継続的な直接CVがある	自動削除を止める	低PVでも事業価値が高い可能性がある
強い被リンク・参照がある	移行設計を確認する	URL資産の損失を防ぐ
主要検索意図が他URLと重複	統合候補を先に確認	別々にリライトして競合を強めない
公開直後で評価期間が短い	保留へ	データ不足を低評価と誤認しない

たとえばURL処理が必要なケースは、スコア表では「URL処理確認」などのフラグまでに留めます。noindex、リダイレクト、404/410などの選択は別工程で判断し、棚卸しシートへ実装詳細を持ち込みすぎない方が役割を保ちやすくなります。

ゲート列は「TRUE/FALSE＋確認理由」で持つ

実装では、ゲート条件ごとにTRUE/FALSE列を分けるか、複数条件をまとめた「要確認理由」列を持たせます。重要なのは、ゲートが立った行を通常の点数判定へ流さないことです。自動判定欄には「要確認」と表示し、最終判定者と判定理由の入力を必須にします。

記事価値×リライト優先度の2軸で月次の作業順を決める

記事価値と作業優先度を1つの総合点へ混ぜると、「価値は高いが今は直さなくてよい記事」と「価値があり、しかも改善余地が大きい記事」を区別できません。2軸を別列で持ち、最後に人が更新枠へ当てはめると、着手理由を説明しやすくなります。

記事価値	リライト優先度	基本アクション
高	高	最優先でリライト
高	低	維持し、定期確認
低〜中	高	改善効果を見てリライト。統合候補も比較
低	低	統合・公開終了候補を人が確認

20〜30記事で閾値を校正し、候補数を運用可能な量へ合わせる

70点・50点といった閾値は、記事数や月間更新本数によって適切な位置が変わります。最初から全記事へ適用せず、性質の異なる20〜30記事で試験採点し、「候補抽出」と「当月着手」の2段階に分けて調整します。

明らかに維持すべき記事、明らかな改善候補、重複候補、低価値候補を混ぜて20〜30記事を選ぶ。

現行ルーブリックで記事価値と処置別スコアを採点する。

担当者の常識的な判定とスコア結果が逆転した記事だけをレビューする。

原因が「配点」「定義」「ゲート不足」のどれかを特定する。

月間の更新可能本数に合わせ、候補数が多すぎる場合は閾値を上げ、少なすぎる場合は下げる。

閾値変更日と理由を記録し、過去の結果と比較できるようにする。

たとえば月10本しか更新できないのに、リライト70点以上が40本出るなら、70点は候補抽出には使えても当月着手の線引きとしては粗すぎます。「候補閾値70点」「今月着手は候補の上位10本」のように、点数とキャパシティを別に管理します。

閾値変更履歴を別表で残す

閾値を変えると過去の候補数との比較条件が変わります。変更日・旧値・新値・理由・承認者を残し、どのルールで判定したかを後から追えるようにします。

更新日	対象スコア	旧閾値	新閾値	変更理由	承認者
YYYY-MM-DD	リライト優先度	70	75	候補数が月間更新枠を大幅に超えたため	氏名/役割
YYYY-MM-DD	差1以内率	80%	85%	採点定義の安定後に社内目安を更新	氏名/役割

採点者間一致｜差1以内率で曖昧な軸だけ直す

複数人で使うスコア表では、平均点より「同じ記事を見たときに近い点を付けられるか」が重要です。初回校正では2名が同じ20記事を独立採点し、完全一致率、差1以内率、軸別平均差を確認します。

確認指標	計算例	使い方
完全一致率	同じ点だった件数 ÷ 全採点件数	厳密に基準がそろっているかを見る
差1以内率	点差が0〜1だった件数 ÷ 全採点件数	実務上の許容範囲で近いかを見る
軸別平均差	各軸の点差合計 ÷ 記事数	曖昧な評価軸を特定する

たとえば20記事×5軸＝100採点のうち86件が差1以内なら、差1以内率は86%です。目標値を外部基準のように扱う必要はありません。自社の初期目安を置き、下回った軸だけ定義文・具体例・参照列を追加します。

重要なのは、点数が違った担当者を無理に合わせることではなく、「なぜ差が出たか」をルーブリックへ戻すことです。独自性2点と4点で割れたなら、「独自事例が1件あれば3点」「再利用可能な自社調査・独自データがあれば5点」など、境界条件を追加します。

1行の入力例で「採点→ゲート→候補判定→履歴」まで通す

本番投入前に、1記事分を最後まで通して、入力値からスコアが計算され、ゲートが評価され、候補判定と次回確認日までつながるか確認します。ここで計算式・入力規則・必須列の抜けを見つけます。

項目	入力例
記事ID	A-0123
対象期間	直近90日
事業貢献	4/5 → 20点
検索実績・需要	5/5 → 25点
内容品質	3/5 → 12点
独自性	4/5 → 16点
資産性	3/5 → 6点
記事価値	79/100
リライト優先度	74/100
ゲート条件	料金情報が旧仕様 → 要修正
最終判定	最優先リライト
判定理由	高需要・高価値で、料金情報の更新が必要
次回確認日	更新後60〜90日を目安に設定

この例では記事価値79点だけを見ても「残す価値が高い」までしか分かりません。リライト優先度74点に加えて「料金情報が旧仕様」というゲートが立つため、スコアの高低とは別に人間確認を優先できます。

判定履歴｜閾値・ルーブリック・実施結果を更新履歴として残す

スコア表は一度作って終わる採点表ではなく、実績でルールを改善する運用基盤です。機械更新できる実績データと、人が確認する定性評価を分け、判定時点の条件を履歴として残します。

履歴列は「判定」と「ルール変更」を分ける

記事ごとの履歴には、判定日、判定者、最終判定、判定理由、実施日、変更内容、次回確認日を持たせます。一方、スコア表そのもののルール変更は、配点・閾値・ルーブリックの変更履歴として別管理します。記事の状態変化と採点ルールの変化を分けることで、前回との比較がしやすくなります。

全記事のSearch Console・Analytics等の数値を同じ条件で更新する。

閾値を超えたリライト・統合・削除候補だけを抽出する。

ゲート条件と判定理由を人が確認し、当月の着手本数まで絞る。

実施日・変更内容を記録し、同じ指標で再測定する。

結果が期待と違った場合は記事だけでなく、配点・閾値・ルーブリックも見直す。

Search ConsoleとGoogle Analyticsを併用すると、検索結果での露出・クリックと、サイト到達後の行動を分けて確認できます。両者は計測方法が異なり数字が完全一致するものではないため、「Search Consoleのクリック」「Google Analyticsのセッション・キーイベント」のように指標名と出典を明示します。

まとめ｜スコア表は「点数」ではなく判断の再現性を管理する

棚卸しスコア表の目的は、維持・リライト・統合・公開終了の一般的な判断基準を置き換えることではありません。すでに決めた基準を、複数人が同じ手順で使える列・配点・数式・ゲートへ実装することです。

まず1URL＝1行の列構成を決め、記事価値と処置別必要性を別スコアとして持ちます。次に5段階ルーブリックと点数根拠を固定し、重大な例外はゲートで人間確認へ送ります。20〜30記事で閾値を校正し、2名採点で差が大きい軸だけ定義を修正します。

運用開始後は、閾値変更日・変更理由・判定者・実施日・次回確認日を履歴として残してください。点数の高低だけで処置を自動確定せず、「なぜその点か」「なぜその候補になったか」を追える状態にすると、記事数が増えても担当者の感覚だけに依存しない棚卸し運用を作れます。

参考文献・データ元

‹ 親記事: オウンドメディア記事のリライト・統合・削除判断｜古い記事を棚卸しする基準

関連テーマ

AIO SEO MEO 口コミ・風評対策 採用改善