数十〜数百本の記事を複数人で棚卸しすると、「重要」「古い」「重複している」の解釈が担当者ごとにずれ、同じ記事でも点数や着手の順番が変わってしまいます。判断基準を知っているだけでは、このずれは埋まりません。必要なのは、基準を、誰が使っても同じ手順で判定できる列・配点・数式と、点数にかかわらず先に人が確認する条件（ゲート条件）へ変換することです。
本記事は、維持・リライト・統合・公開終了の判断基準そのものを解説する記事ではありません。その基準は、関連記事「オウンドメディア記事のリライト・統合・削除判断｜古い記事を棚卸しする6つの基準」で整理しています。ここでは、基準を理解済みの担当者を想定し、スプレッドシートへ実装する方法に絞って説明します。
完成させるのは、1URLを1行として「入力→採点→ゲート確認→着手候補抽出→人間確認→履歴更新」まで追える棚卸しスコア表です。記事を残す価値を表す100点の記事価値スコアと、リライト・統合・公開終了といった処置ごとの候補スコア（処置別スコア）を分けて持ち、評価の目安を段階ごとに書いた基準表（5段階ルーブリック）で採点します。さらに、点数の線引き（閾値）を20〜30記事の試験採点で調整する方法と、採点者どうしのずれを「差1以内率」（点差が1点以内に収まった採点の割合）で確かめる方法を説明します。最後に、変更履歴の残し方まで、実装の単位で整理します。
棚卸しを含むオウンドメディア全体の効果測定・改善サイクルは、「オウンドメディアの効果測定・改善とは？見るべき指標・使うツール・PDCAの回し方の全体像」で整理しています。
まず列構成を決める｜1URL＝1行で入力・採点・判定根拠・履歴を持つ
最初に決めるのは列の設計です。1URLを1行とし、元データ、採点値、点数の根拠、ゲート、候補判定、実施履歴を同じ行で追えるようにします。こうしておくと、数か月後に再測定しても「なぜこの点数・判定だったのか」を復元できます。Search ConsoleとGoogle Analyticsは計測の対象も指標体系も異なるため、同じ数値列に混ぜず、指標名と出典を分けて持ちます。
必須列の例は次の表のとおりです。区分ごとの目的を押さえておけば、列を足し引きするときも判断がぶれません。
| 区分 | 必須列の例 | 目的 |
|---|---|---|
| 基本情報 | 記事ID／URL／タイトル／公開日／最終更新日 | 対象を一意に識別する |
| 検索実績 | クリック／表示回数／CTR／平均掲載順位／対象期間 | 検索結果での機会と実績をそろえる |
| 事業実績 | CV・キーイベント／営業利用／重要導線 | 検索流入以外の価値を残す |
| 定性評価 | 検索意図一致／内容品質／独自性／資産性 | 数値だけでは見えない価値を採点する |
| スコア | 記事価値／リライト／統合／削除候補 | 役割と作業優先度を分ける |
| 判定管理 | ゲート条件／最終判定／判定理由／判定者 | 自動判定の誤りを防ぐ |
| 履歴 | 実施日／変更内容／レビュー日／次回確認日 | 改善後の再測定につなげる |
表中のCVは、資料請求など、サイト上で達成したい成果（コンバージョン）を指します。CTRは、クリック率のことで、検索結果での表示回数に対するクリックの割合です。「スコア」の区分は、次の節で説明する記事価値と、処置ごとの候補スコアに分かれます。表の「削除候補」は、後述の公開終了候補スコアのことです。
比較期間も列として固定します。たとえば直近90日で評価するなら、原則としてすべての記事を同じ90日で比べます。季節性が強いテーマだけは、前年同期を別の列で持ちます。期間条件まで残しておけば、次回の棚卸しで数値の意味が変わってしまう事故を防げます。
記事価値と処置別スコアを分ける｜1つの総合点に混ぜない
記事価値スコアは、「このURL・内容をサイトの資産として残し、育てる価値」を共通の尺度で表す点数です。リライトや公開終了といった処置を直接決める点数ではありません。処置の手がかりになる処置別スコアは、記事価値とは別の点数として後の節で組みます。まずは5軸・100点のように管理しやすい形から始め、事業目標に応じて重みを調整します。
5軸の例を次の表に示します。5点と1点の状態を書き分けておくと、採点者が迷いにくくなります。
| 評価軸 | 配点 | 5点の状態 | 1点の状態 |
|---|---|---|---|
| 事業貢献 | 25 | CV・商談・営業利用など明確な役割がある | 事業成果との接点を確認できない |
| 検索実績・需要 | 25 | 継続的な表示・クリック、または明確な需要がある | 需要・表示機会ともほぼ確認できない |
| 内容品質・正確性 | 20 | 現在の問いに十分答え、根拠・具体性もある | 古い・不足・誤解を招く箇所が多い |
| 独自性・役割 | 20 | 他記事で代替できない回答や一次情報がある | 他記事と役割がほぼ同じ |
| 資産性 | 10 | 被リンク・指名参照・重要な内部導線がある | URL固有の参照価値が乏しい |
配点の合計は100点（25＋25＋20＋20＋10）です。配点は「重要そうだから25点」と感覚で決めず、棚卸しで守りたい成果から逆算します。問い合わせの獲得が目的なら事業貢献を重くし、専門情報の蓄積を重視するなら独自性や資産性を重くします。重みの理由は、別の「配点根拠」列に一文で残してください。
自由採点をやめ、5段階ルーブリックと換算式で採点する
各軸を0〜25点の範囲で自由採点すると、担当者差が大きくなります。入力は1〜5の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以内」の式は、採点者2人の評価の差が1以内なら1を返します。その合計を採点件数で割ると、差1以内率になります。「ゲート判定」の式は、ゲート条件が成立した行を自動で確定させず「要確認」にするためのものです。ゲート条件は後の節で説明します。
配点はどう決めるか｜目的→軸→重み→例外の順に決め、試験採点で見直す
上の式は、配点を設定セルに置く前提です。その配点自体は、最初から正解を当てるものではありません。どの事業判断をスコアで支援するのかを先に決め、その目的に必要な評価軸だけに重みを付けます。例外条件まで点数に詰め込むと説明しにくくなるため、重大な例外は後述のゲート列に分けます。決める順番は次のとおりです。
- 棚卸しで最も守りたい成果を1つ決めます。たとえば、問い合わせの獲得、認知、専門情報の蓄積です。
- その成果に直接関係する評価軸を3〜6個に絞ります。似た軸を増やしすぎないようにします。
- 合計100点になるよう重みを付け、なぜその配点なのかを一文で記録します。
- 重要な例外は点数へ無理に埋め込まず、ゲート条件に分けます。
- 試験採点で明らかな違和感が出た軸だけを修正し、全配点を毎回変えないようにします。
この順番にするのは、目的が決まらないと軸を絞れず、軸が決まらないと重みを付けられないためです。
評価軸を考えるときは、Googleが示している観点も参考になります。Google Search Centralの「Creating helpful, reliable, people-first content」は、コンテンツの自己評価の観点として、独自情報・十分な説明・読者にとっての有用性など複数の観点を示しています。こうした質的な観点は、クリック数や表示回数とは別の定性列としてルーブリック化すると、実績値だけに偏らない採点がしやすくなると考えます。
処置別スコアは「何をするか」ではなく「着手候補の強さ」を表す
記事価値が高いことと、今すぐ直す必要があることは別の話です。価値が高くても現状で十分なら着手は不要ですし、価値が中程度でも、改善余地と機会規模が大きければ優先候補になります。そこで、記事価値とは別に、リライト・統合・公開終了のそれぞれについて「候補として確認すべき強さ」を点数にします。これが処置別スコアです。ただし、最終的な処置は点数だけでは確定しません。以下では、リライト、統合、公開終了の順に、スコアの組み方を示します。
リライト優先度スコアの組み方
最初はリライト優先度スコア（以下、リライト優先度）です。5つの要素で100点とし、点が高いほど、リライトを優先して検討すべき状態を表します。
| 要素 | 配点例 | 高得点になる状態 |
|---|---|---|
| 改善余地 | 30 | 検索意図への回答不足、古い情報、弱い導線が明確 |
| 機会規模 | 25 | 表示回数・需要が大きく、改善の影響範囲が広い |
| 検索結果の取りこぼし | 20 | 表示はあるがCTRやクリック獲得に改善余地がある |
| 放置リスク | 15 | 料金・制度・仕様など更新遅れの影響が大きい |
| 事業重要度 | 10 | 重要サービス・重要導線に近い |
初期閾値として、70点以上を優先候補、50〜69点を通常候補などと仮置きできます。ただし、これは外部の基準ではなく、自社運用の初期値です。候補の数と月間に更新できる本数が合うよう、20〜30記事の試験採点で調整します。方法は後述します。
統合候補スコアの組み方
次は統合候補スコアです。同じ読者の同じ問いに、複数のURLが答えていないかを5つの要素で見ます。
| 要素 | 配点例 | 確認ポイント |
|---|---|---|
| 主要検索意図の一致 | 35 | 同じ読者が同じ問いへの答えを求めているか |
| 回答範囲の重複 | 25 | 主要H2・結論・読後行動が重なるか |
| クエリ重複 | 15 | 実際の流入クエリが競合しているか |
| 内部競合 | 15 | 同一テーマでURLが分散し代表ページが曖昧か |
| 集約メリット | 10 | 一本化で情報・リンク・導線を集める価値があるか |
統合候補スコアは、人が重複を確認する対象を絞るために使います。高得点でも自動では統合せず、同じ読者が同じ問いへの答えを求めているかを人が確認します。統合そのものの判断基準やURLの扱いは、冒頭で紹介した関連記事に委ねます。
公開終了候補スコアの組み方
最後は公開終了候補スコアです。ほかの2つと違い、需要や価値が弱いほど高い点になる向きで付ける点に注意してください。
| 要素 | 配点例 | 高得点になる状態 |
|---|---|---|
| 需要の弱さ | 25 | 検索・閲覧需要がほぼない |
| 事業貢献の弱さ | 25 | CV・営業・サポート用途がない |
| 独自価値の弱さ | 20 | 他記事で代替可能 |
| 資産性の弱さ | 15 | 被リンク・重要内部リンク・参照価値が乏しい |
| 維持コスト／陳腐化 | 15 | 更新負荷が高く、誤情報化のリスクがある |
公開終了候補スコアも、高いほど削除してよいという自動処分のルールではありません。需要・事業貢献・独自価値・資産性・維持の負担を同じ尺度で比べ、確認する対象を抽出するために使います。維持・統合・公開終了の一般的な判断基準やURLの扱いは、冒頭の関連記事に委ねます。
ゲート条件｜点数より先に人間の確認へ送る条件を決める
スコアは記事どうしの比較には強い一方で、重大な例外を平均化してしまいます。そこで、点数に関係なく先に確認する条件を「ゲート」列として持たせます。ゲートが立った行は自動判定を確定させず、「要確認」として人間のレビューへ送ります。
ゲート条件の例と、点数より先にやることは次の表のとおりです。
| ゲート条件 | スコアより先にすること | 理由 |
|---|---|---|
| 重大な誤情報がある | 最優先で修正へ | 法律・料金・仕様などは低流入でも放置しない |
| 継続的な直接CVがある | 自動削除を止める | 低PVでも事業価値が高い可能性がある |
| 強い被リンク・参照がある | 移行設計を確認する | URL資産の損失を防ぐ |
| 主要検索意図が他URLと重複 | 統合候補を先に確認 | 別々にリライトして競合を強めない |
| 公開直後で評価期間が短い | 保留へ | データ不足を低評価と誤認しない |
「スコアより先にすること」の列は、ゲートが立った記事を人がレビューするとき、点数の判定より先に取る対応です。たとえばURLの処理が必要なケースは、スコア表では「URL処理確認」などのフラグまでにとどめます。noindex、リダイレクト、404/410などの選択は別の工程で判断し、棚卸しシートへ実装の詳細を持ち込みすぎないほうが、シートの役割を保ちやすくなります。
ゲート列を「TRUE/FALSE＋確認理由」で実装する
実装では、ゲート条件ごとにTRUE/FALSEの列を分けるか、複数の条件をまとめた「要確認理由」列を持たせます。ゲートが立った行を通常の点数判定へ流さないことが要点です。自動判定欄には「要確認」と表示し、最終判定者と判定理由の入力を必須にします。
記事価値×リライト優先度の2軸で月次の作業順を決める
記事価値と作業の優先度を1つの総合点に混ぜると、「価値は高いが今は直さなくてよい記事」と「価値が高く、改善余地も大きい記事」を区別できません。そこで2軸を別の列で持ち、最後に人が更新枠へ当てはめます。着手の理由を説明しやすくなります。
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% | 採点定義の安定後に社内目安を更新 | 氏名/役割 |
2行目のように、採点者間の一致率の社内目安も、同じ表で履歴を残せます。
採点者が変わっても近い点になるか｜差1以内率で曖昧な軸だけ直す
複数人で使うスコア表で平均点より先に確かめたいのは、同じ記事を見たときに近い点を付けられるかどうかです。初回の校正では、2名が同じ20記事を独立して採点し、完全一致率、差1以内率、軸別平均差の3つを確認します。
| 確認指標 | 計算例 | 使い方 |
|---|---|---|
| 完全一致率 | 同じ点だった件数 ÷ 全採点件数 | 厳密に基準がそろっているかを見る |
| 差1以内率 | 点差が0〜1だった件数 ÷ 全採点件数 | 実務上の許容範囲で近いかを見る |
| 軸別平均差 | 各軸の点差合計 ÷ 記事数 | 曖昧な評価軸を特定する |
たとえば20記事×5軸＝100採点のうち86件が差1以内なら、差1以内率は86%です。目標値を外部基準のように扱う必要はありません。自社の初期目安を置き、下回った軸だけ定義文・具体例・参照列を追加します。
目的は、点数が違った担当者を無理に合わせることではありません。「なぜ差が出たか」をルーブリックに戻すことです。たとえば独自性が2点と4点で割れたなら、「独自事例が1件あれば3点」「再利用できる自社調査・独自データがあれば5点」のように、境界条件を追加します。
本番の前に、1行の入力例で「採点→ゲート→候補判定→履歴」まで通す
ルーブリックと閾値が整ったら、本番に投入する前に、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点だけを見ても「残す価値が高い」までしか分かりません。先に仮置きした初期閾値（70点以上を優先候補）を当てはめると、リライト優先度74点は優先候補です。そのうえで「料金情報が旧仕様」というゲートが立つため、スコアの高低とは別に、人間の確認を優先できます。
履歴を残す｜判定・ルール変更・実施結果を分けて更新する
スコア表は、一度作って終わる採点表ではありません。実績を見てルールを改善していく、運用の土台です。そのため、機械的に更新できる実績データと、人が確認する定性評価を分け、判定した時点の条件を履歴として残します。
履歴列は「判定」と「ルール変更」を分ける
記事ごとの履歴には、判定日、判定者、最終判定、判定理由、実施日、変更内容、次回確認日を持たせます。一方、スコア表そのもののルール変更は、配点・閾値・ルーブリックの変更履歴として別に管理します。記事の状態の変化と採点ルールの変化を分けておくと、前回との比較がしやすくなります。
月次の運用は、次の流れで回します。
- 全記事のSearch ConsoleやAnalyticsなどの数値を、同じ条件で更新します。
- 閾値を超えたリライト・統合・公開終了の候補だけを抽出します。
- ゲート条件と判定理由を人が確認し、当月の着手本数まで絞ります。
- 実施日と変更内容を記録し、同じ指標で再測定します。
- 結果が期待と違った場合は、記事だけでなく、配点・閾値・ルーブリックも見直します。
数値を更新するときは、Search ConsoleとGoogle Analyticsの使い分けにも注意します。併用すると、検索結果での露出・クリックと、サイトに到達した後の行動を分けて確認できます。ただし、両者は計測方法が異なり、数字が完全に一致するものではありません。そのため「Search Consoleのクリック」「Google Analyticsのセッション・キーイベント」のように、指標名と出典を明示します。
まとめ｜スコア表は「点数」ではなく判断の再現性を管理する
棚卸しスコア表の目的は、維持・リライト・統合・公開終了の一般的な判断基準を置き換えることではありません。すでに決めた基準を、複数人が同じ手順で使える列・配点・数式・ゲートへ実装することです。
実装の流れは次のとおりです。まず1URL＝1行の列構成を決め、記事価値と処置別スコアを別の点数として持ちます。次に、5段階ルーブリックと点数の根拠を固定し、重大な例外はゲートで人間の確認へ送ります。そのうえで20〜30記事で閾値を調整し、2名の採点で差が大きい軸だけ定義を直します。
最初に取り組むのは、列構成と5段階ルーブリックを決めて、20〜30記事で試験採点することです。運用を始めたら、閾値の変更日と理由、判定者、実施日、次回確認日を履歴に残してください。点数の高低だけで処置を自動確定せず、「なぜその点か」「なぜその候補になったか」を追える状態にしておくと、記事数が増えても担当者の感覚だけに頼らない棚卸しを続けられます。
参考文献・データ元
この記事で参照した情報を確認できます。
Creating helpful, reliable, people-first content — Google Search Central（最終更新 2025-12-10）
https://developers.google.com/search/docs/fundamentals/creating-helpful-contentUsing Search Console and Google Analytics data for SEO — Google Search Central（最終更新 2026-01-07）
https://developers.google.com/search/docs/monitor-debug/google-analytics-search-console関連記事：オウンドメディア記事のリライト・統合・削除判断｜古い記事を棚卸しする6つの基準
https://rebranding.co.jp/media/owned-media-content-audit/
‹ 親記事: オウンドメディア記事のリライト・統合・削除判断｜古い記事を棚卸しする基準