記事公開時に出典を確認していても、その根拠が半年後や1年後にも有効とは限りません。統計は更新され、サービス仕様は変わり、参照したページ自体が消えることもあります。
この問題には、記事単位の更新管理とは別に、記事内の重要な主張と根拠を1件ずつ管理する「エビデンス台帳」が役立ちます。大切なのはURL一覧を作ることではありません。「どの主張を、何で確認し、いつまで有効と判断し、誰が次に確認するか」まで記録することです。
この記事では、マーケティング担当者がそのまま運用できる台帳項目、更新期限の決め方、根拠を再確認したあとの「維持・修正・差し替え・削除」の判断までを整理します。
関連する全体像や前提は「コンテンツ制作・運用体制とは?編集フロー・役割分担・品質チェックの仕組みを体系的に整理」で整理しています。
エビデンス台帳とは、記事の「主張」と「根拠」を1件ずつ結び付ける管理表
この節では、台帳が何を管理する表なのか、既存の管理方法と何が違うのかを整理します。
エビデンス台帳とは、記事に含まれる重要な事実・数字・制度・仕様などについて、根拠となる情報源と確認状況を記録する管理表です。
一般的な記事管理表が「この記事をいつ更新するか」を管理するのに対し、エビデンス台帳では「この記事の中の、この主張をいつ再確認するか」まで細かく管理します。
同じ記事の中でも、根拠によって古くなる速さは違います。たとえば、1本の記事に次の3つの記述があるとします。
- 政府統計を使った市場規模
- Googleが公開している検索仕様
- 企業が公表しているサービス料金
年次統計なら次年度の公表時、Webサービスの仕様なら数か月後、料金なら変更告知時というように、確認すべきタイミングは異なります。記事単位でまとめて管理するより、根拠ごとに分けた方が合理的です。
Googleも、信頼できるコンテンツかを自己評価する観点として、明確な出典、事実誤認がないこと、コンテンツがどのように作られたかなどを挙げています。つまり、出典管理は「参考文献を記事末尾に付ける作業」で終わらせず、公開後の品質管理までつなげる必要があります。
次の表は、台帳を既存の管理方法と比べたものです。「苦手なこと」の列を見ると、台帳以外の3つは、個々の根拠が古いか、公開後に根拠が変わったか、どの文章を支えているかのいずれかを追いにくいことが分かります。一方、台帳は主張・出典・確認日・期限・担当者まで持てますが、運用ルールがないと更新されない点には注意が必要です。
| 管理方法 | 管理単位 | 分かること | 苦手なこと |
|---|---|---|---|
| 記事一覧 | 記事 | 公開日、更新日、担当者 | 個々の根拠が古いか |
| 公開前チェックリスト | 記事 | 公開時に確認したか | 公開後の根拠変化 |
| 参考文献一覧 | 出典 | 何を参考にしたか | どの文章を支えているか |
| エビデンス台帳 | 主張・根拠 | 主張、出典、確認日、期限、担当者 | 運用ルールがないと更新されない |

図のように、記事全体の更新日だけでなく、重要な主張ごとに出典・確認日・次回期限を持たせることで、根拠切れを発見しやすくなります。
なぜ記事単位の更新管理だけでは根拠切れを防ぎにくいのか
記事全体の更新日だけを管理すると、「一部の情報だけが古い」という状態を見逃しやすくなります。特に見逃しやすいのが、Web上の出典です。
Webページは、リンク切れだけでなく、同じURLのまま内容が変更されることがあります。学術分野では、リンク切れと内容変化を合わせた「reference rot(参照情報の劣化)」が研究されています。研究例を2つ紹介します。
1つ目は、2026年に公表されたLibrary and Information Science分野の研究です。20年間を対象に、608本の論文に含まれる2,886件のWeb引用を分析しています。引用から0〜5年の情報では87%がアクセス可能だったのに対し、10年を超える引用では38%まで低下したと報告されています。
2つ目は、2014年のPLOS ONE掲載研究です。350万本を超える学術記事群を分析し、Web情報を引用する論文では、時間経過によるリンク切れや内容変化が再検証を難しくする問題が確認されています。
企業の記事も学術論文と同じ割合でリンク切れが起こると断定することはできません。ただし、「公開時にアクセスできたURLが将来も同じ情報を示すとは限らない」という性質は共通します。そのため、台帳にはURLだけでなく、「確認日」と「次回確認期限」が必要です。
エビデンス台帳には何を記録するか:最低11項目
実務では、最初から大きな管理表を作る必要はありません。まずは次の11項目があれば運用できます。
| 項目 | 記録内容 |
|---|---|
| エビデンスID | 根拠ごとの一意な番号 |
| 記事ID・記事名 | どの記事で使っているか |
| 主張・記述 | 根拠を必要とする文章 |
| 本文位置 | H2/H3や該当箇所 |
| 出典名 | 資料・ページ・論文名 |
| 出典区分 | 一次情報、研究、二次情報など |
| URL・識別子 | URL、DOIなど |
| 確認日 | 実際に内容を確認した日 |
| 次回確認期限 | 再確認する期限 |
| ステータス | 有効、要確認、差し替えなど |
| 責任者 | 再確認・修正を担当する人 |
表の「出典区分」にある「一次情報」とは、その事実を直接発表・記録している資料のことです。区分ごとの使い分けは、次の節で説明します。

エビデンス台帳では、出典URLだけでなく、「どの主張を支えているか」「いつ再確認するか」「誰が確認するか」まで一続きで管理します。
「主張」は文章単位まで具体化する
「Google資料」「厚生労働省統計」のように出典名だけを記録しても、後から何を確認した資料なのか分からなくなります。そこで台帳には、根拠と結び付く主張を、文章の単位で残します。
避けたいのは、次のように出典名だけを書く記録です。
- 総務省の資料
- Google公式
- ○○社料金ページ
残したいのは、次のように主張そのものが分かる記録です。
- 「2025年の国内インターネット利用率は○%」
- 「Googleは○○を検索ランキングの直接的な要因とは説明していない」
- 「○○サービスの月額料金は○円から」
1つの出典が複数の記述を支えている場合でも、重要な主張は分けて管理すると、更新時に判断しやすくなります。
本文位置を残して差し替え作業を早くする
根拠が古くなったことを検知できても、記事内のどこで使っているか分からなければ、使用箇所を改めて調べ直すことになります。
位置は「H2:○○の市場規模/第2段落」のように残します。CMS側で管理できるなら、アンカーやブロックIDまで記録します。こうしておくと、出典を変更するときに影響箇所へ直接移動できます。
出典は「一次情報かどうか」だけでなく、主張との適合性で判断する
出典管理では、可能な限り一次情報へさかのぼることが基本です。
International Fact-Checking Network(IFCN)の原則でも、重要な証拠の出典を読者が追跡できる形で示し、適切な一次資料が存在する場合には二次資料より一次資料を使用することが求められています。
ただし、「一次情報なら何でもよい」という意味ではありません。優先順位は次のように考えると整理しやすくなります。
- その事実を直接発表・記録している一次情報
- 原著論文・公的研究資料
- 信頼できる専門機関による解説
- 報道・専門メディア
- 他社の解説記事やまとめ記事
たとえば、Google検索の仕様を説明するならGoogle Search Central、法律なら法令本文や所管官庁、企業の料金なら当該企業の公式料金ページが優先候補です。
一方で、一次資料に書かれていない解釈を補う場合には、専門家や研究による二次情報が有効なこともあります。
重要なのは「出典の格」だけでなく、「その資料が、その主張を本当に裏付けているか」です。
更新期限は情報の変化速度によって分ける
すべての根拠を毎月確認する必要はありません。一方で、年1回の一括更新では遅すぎる情報もあります。そこで、出典ごとに更新リスクを分類し、確認期限を決めます。次の表は、その分類と期限の目安です。
| 更新リスク | 代表例 | 確認期限の目安 |
|---|---|---|
| 高 | AI・検索サービス仕様、料金、製品機能、キャンペーン | 1〜3か月 |
| 中 | 企業情報、業界データ、各種ガイドライン | 3〜6か月 |
| 定期 | 年次統計、決算、白書、定期調査 | 次回公表時または6〜12か月 |
| 低 | 基礎理論、確定済み制度史、古典的研究 | 12か月以上または変更契機時 |

図のように、すべての根拠を同じ頻度で確認するのではなく、情報が変わる速度に応じて再確認期限を設定します。
この表は一律の正解ではなく、社内運用のための基準例です。同じ政府資料でも、毎月更新される統計と5年ごとの調査では期限を分けるべきです。
期限が来たときに、記事の日付を変えるかどうかも整理しておきます。Googleは、Webページを大幅に更新した場合には更新日を明示することを推奨する一方、実質的な変更を伴わず日付だけを新しくすることは推奨していません。
したがって、「更新期限が来た=記事の日付を変更する」ではありません。確認した結果、情報が変わっていなければ台帳の確認日だけを更新し、本文に実質的な変更が生じた場合に記事更新へ進めます。
更新期限が来たら「維持・修正・差し替え・削除」の4つに分ける
再確認のたびに記事全体をリライトすると、運用負荷が大きくなります。そこで、根拠ごとに次の4分類で処理します。
維持:出典も内容も変わっていない場合
出典が有効で、内容にも変更がありません。この場合は、確認日と次回期限だけを更新します。
修正:出典は有効だが、一部が更新された場合
出典は有効ですが、数値や表現など一部が更新されている場合です。該当箇所だけを修正し、必要に応じて記事の更新日も変更します。
差し替え:出典そのものを変える場合
元の出典が廃止された、より新しい公式資料が公開されたなどの場合です。新しい根拠へ変更し、主張がそのまま成立するかも再確認します。
削除:根拠を確保できない場合
新しい根拠が見つからない、旧情報を現在の事実として残せない場合です。無理に別の資料で補強せず、主張自体を削除するか、限定表現へ変更します。
4つの処理を整理すると、次の表のとおりです。
| 判定 | 根拠 | 本文 | 次の処理 |
|---|---|---|---|
| 維持 | 有効 | 変更不要 | 確認日を更新 |
| 修正 | 有効だが内容更新 | 一部変更 | 本文修正 |
| 差し替え | 旧出典が不適切 | 再検証 | 新出典へ変更 |
| 削除 | 根拠を確保できない | 維持不可 | 記述削除・限定 |

期限が来た記事をすべてリライトするのではなく、根拠の状態に応じて「維持・修正・差し替え・削除」を判断します。
エビデンス台帳の運用は5ステップで回す
台帳は、作成しただけでは意味がありません。記事制作から更新まで、同じフローに組み込みます。次の5ステップで回します。
STEP1:公開前に重要な主張を抽出する
すべての文章を登録する必要はありません。優先して台帳化するのは、次のような情報です。
- 数字・割合・市場規模
- 法律・制度
- 商品・サービス仕様
- 料金
- 調査結果
- 引用
- 固有名詞を伴う事実
- 「○○である」と断定する重要な記述
STEP2:根拠となる情報源を確認する
可能な限り元資料までたどります。他社記事から数字を見つけた場合は、その記事が引用している調査・統計まで確認します。
これは、最初の節で触れたGoogleの案内にも沿った確認です。Googleは、コンテンツの信頼性を自己評価する際に、明確な出典や、簡単に確認できる事実誤認がないかを確認するよう案内しています。
STEP3:確認日と次回確認期限を設定する
情報の変化速度を見て、1か月、3か月、6か月、12か月などの期限を設定します。次回確認期限を空欄にしたまま公開しないことがポイントです。
STEP4:期限が近い根拠を定期抽出する
毎月1回などの頻度で、「次回確認期限 ≦ 今月末」となっている根拠を抽出します。
記事数が増えた場合は、記事単位ではなく期限順に根拠を並べることで、必要な確認だけを処理できます。
STEP5:変更があった根拠だけ記事更新へ送る
出典を再確認した結果、変更がなければ台帳の更新で終了します。事実が変わった場合のみ、該当記事と該当箇所を編集工程へ送ります。
これにより、「全記事を定期的に読み直す」運用から「変化の可能性がある根拠を監視する」運用へ移行できます。
責任者は記事ではなく根拠の種類で分けてもよい
記事の担当者だけにすべての確認を任せると、専門領域によって品質差が出やすくなります。運用規模が大きくなったら、根拠の種類ごとに確認担当を設定する方法もあります。たとえば、次のように分けます。
- 法律・制度:法務または専門担当
- 製品仕様:サービス責任者
- 自社調査:調査担当
- SEO・Google仕様:Web担当
- 料金・契約条件:営業・事業責任者
ねらいは、最終的な記事更新責任者と、「根拠が現在も正しいかを判断できる人」を分けることです。
IFCNの原則でも、出典だけでなく調査・編集・訂正方法を透明にすることが重視されています。企業メディアでも、誰が確認し、誰が修正判断をするのかを決めておくと、担当者変更後も運用を継続しやすくなります。
最初はスプレッドシート1枚から始めればよい
エビデンス台帳のために、専用システムを最初から導入する必要はありません。数十〜数百記事程度であれば、Googleスプレッドシートなどでも運用できます。最低限、次の条件を満たせれば十分です。
- エビデンスIDで一意に管理できる
- 記事IDで絞り込める
- 次回確認期限で並べ替えられる
- 責任者で絞り込める
- ステータスを選択式にできる
- 過去の確認履歴を残せる
記事数や根拠数が増えたら、CMSやデータベースとの連携を検討します。重要なのはツールではなく、「重要主張→根拠→確認日→期限→責任者→差し替え」という関係が切れないことです。
台帳を作るときに避けたい3つの運用
台帳を作っても、次の3つの運用では効果が薄れます。
出典URLだけを一覧化する
URLだけでは、その資料が何を支えているのか判断できません。必ず主張とセットで管理します。
すべての出典を同じ期限で確認する
更新速度の違いを無視すると、確認作業が過剰になるか、必要な更新が遅れます。情報の変化速度に応じて期限を分けます。
リンクが生きていれば「有効」と判断する
HTTPエラーが出ていなくても、ページ本文が更新され、以前の主張を支えなくなっている可能性があります。確認時には「アクセスできるか」だけでなく、「現在の内容が記事の主張を支えているか」まで確認します。
まとめ:まず重要な主張から台帳化する
記事の品質管理では、公開時のファクトチェックに加えて、公開後も重要な主張と根拠の関係を追跡できる状態を作ることが欠かせません。
エビデンス台帳では、「主張」「出典」「出典区分」「本文位置」「確認日」「次回確認期限」「ステータス」「責任者」などを管理します。
特に重要なのは、記事単位ではなく根拠単位で期限を持つことです。記事全体を一律に更新するのではなく、期限が来た根拠を再確認し、「維持・修正・差し替え・削除」のどれに該当するかを判断します。
最初の一歩は、重要な数字・制度・仕様・料金・調査結果だけでも台帳化することです。記事数が増えた後でも、「なぜこの記述を書いているのか」「現在も根拠が有効か」を追跡できるコンテンツ運用につながります。
参考文献・データ元
この記事で参照した情報を確認できます。
- Google Search Central「有用で信頼性の高い、ユーザーを第一に考えたコンテンツの作成」。明確な出典、正確性、「誰が・どのように・なぜ」コンテンツを制作したかに関する考え方を参照。 Google Search Central
- Google Search Central「Help Google Search know the best date for your web page」。ページの公開日・更新日の考え方を参照。 Google Search Centralの日付ガイド
- International Fact-Checking Network「Code of Principles」。一次情報、出典透明性、方法論、訂正に関する原則を参照。 IFCN Code of Principles
- Sadatmoosavi, A., Khasseh, A. A., Tajedini, O. “Link rot in LIS literature: a 20-year study of web citation decay, recovery and preservation challenges.” Aslib Journal of Information Management, 2026. DOI: 10.1108/AJIM-05-2025-0286。Web引用の経年変化に関する数値を参照。
- Klein, M. et al. “Scholarly Context Not Found: One in Five Articles Suffers from Reference Rot.” PLOS ONE, 2014. DOI: 10.1371/journal.pone.0115253。Web引用のリンク切れ・内容変化に関する背景を参照。
‹ 親記事: コンテンツ制作・運用体制とは?編集フロー・役割分担・品質チェックの仕組みを体系的に整理
関連記事
- › 記事品質チェックリストの作り方|編集基準・校正・根拠確認・公開承認を標準化する
- › SEO記事のコンテンツブリーフ作成方法|検索意図・見出し・根拠・内部リンクを制作前に定義する
- › オウンドメディアの著者・監修者設計|誰が書き、誰が確認したかを記事単位で明示する方法
- › オウンドメディア編集部の作り方|編集長・ライター・監修者・SEO担当の役割分担
- › 記事の更新期限を決める方法|鮮度・重要度・順位下落で判断
- › オウンドメディアの編集権限・版管理を設計する方法|誤公開・上書き・承認漏れを防ぐ
- › 生成AIを記事制作に使う運用ルールの作り方|利用範囲・人間レビュー・機密情報を管理
- › 記事の出典を定期確認|リンク切れ・情報鮮度・一次情報をチェック
- › オウンドメディアのアクセス権限を定期確認|退職・異動時の対応
- › 生成AIを使った記事制作の検証ログを作る方法|プロンプト・根拠確認・修正履歴を残す
- › コンテンツ制作の遅れを確認|企画・執筆・確認・公開を可視化
- › 外注記事の受入れ基準を作る方法|納品形式・根拠・著作権・修正責任を標準化
- › オウンドメディアの画像・図版ライセンスを管理する方法|出典・利用範囲・期限を台帳化
- › 外注ライター・制作会社の評価スコアカードを作る方法|品質・納期・修正回数・専門性を継続評価
- › オウンドメディアの緊急訂正・公開停止フロー|訂正・一時非公開・削除の判断基準と復旧手順
- › 法人向けサービスページの比較表の作り方|料金・対象・対応範囲・実績・契約条件を同じ軸で整理
- › 導入事例ページの作り方|成果数値・導入期間・取り組み内容
- › オウンドメディア担当者の引き継ぎチェックリスト|記事・CMS・編集ルール・分析データ・進行中企画を整理
- › 導入事例ページの作り方|業種・課題・成果で探せる構成と導線
- › 法人向けサービスページのFAQの作り方|料金・対象・導入条件・契約・セキュリティの質問を整理
- › 法人向けサービスページの導入フローの作り方|期間・準備物・担当・例外条件まで整理
- › 法人向けサービスのセキュリティ情報の載せ方|認証・データ保管・権限・問い合わせ先の整理方法
- › 法人向けサービスサイトの情報更新を誰が持つ?営業・法務・制作で料金・実績・契約条件を管理する方法
- › オウンドメディアの表記ガイドラインの作り方|表記ゆれ・数字・固有名詞・引用ルールを統一
- › オウンドメディアのインタビュー記事の作り方|企画・質問設計・取材・原稿確認・公開まで
- › オウンドメディアの記事テンプレートの作り方|原稿フォーマット・出典・CTA・FAQ・著者欄を標準化
- › Claudeの料金プラン比較|無料・Pro・Team・法人向けの選び方
- › NotebookLMの使い方|資料の読み込み・要約・質問の基本手順



