記事の出典・根拠を管理するエビデンス台帳の作り方｜更新期限・一次情報・引用箇所を追跡

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

記事公開時に出典を確認していても、その根拠が半年後や1年後にも有効とは限りません。統計は更新され、サービス仕様は変更され、参照ページ自体が消えることもあります。

そこで必要になるのが、記事単位の更新管理とは別に、記事内の重要な主張と根拠を1件ずつ管理する「エビデンス台帳」です。

重要なのは、URL一覧を作ることではありません。「どの主張を、何で確認し、いつまで有効と判断し、誰が次に確認するか」まで記録することです。この記事では、マーケティング担当者がそのまま運用できる台帳項目、更新期限の決め方、差し替えフローまで整理します。

関連する全体像や前提は「コンテンツ制作・運用体制とは？編集フロー・役割分担・品質チェックの仕組みを体」で整理しています。

エビデンス台帳とは、記事の「主張」と「根拠」を1件ずつ結び付ける管理表

エビデンス台帳とは、記事に含まれる重要な事実・数字・制度・仕様などについて、根拠となる情報源と確認状況を記録する管理表です。

一般的な記事管理表が「この記事をいつ更新するか」を管理するのに対し、エビデンス台帳では「この記事の中の、この主張をいつ再確認するか」まで細分化します。

たとえば、1本の記事に次の3つの記述があるとします。

• 政府統計を使った市場規模
• Googleが公開している検索仕様
• 企業が公表しているサービス料金

同じ記事内でも更新速度は異なります。年次統計なら次年度の公表時、Webサービスの仕様なら数か月後、料金なら変更告知時など、確認すべきタイミングを分けた方が合理的です。

Googleも、信頼できるコンテンツかを自己評価する観点として、明確な出典、事実誤認がないこと、コンテンツがどのように作られたかなどを挙げています。

つまり、出典管理は「参考文献を記事末尾に付ける作業」で終わらせず、公開後の品質管理までつなげる必要があります。

記事全体の更新日だけでなく、重要な主張ごとに出典・確認日・次回期限を持たせることで、根拠切れを発見しやすくなります。

なぜ記事単位の更新管理だけでは根拠切れを防ぎにくいのか

記事全体の更新日だけを管理すると、「一部の情報だけが古い」という状態を見逃しやすくなります。

特に注意したいのが、Web上の出典です。

Webページはリンク切れだけでなく、同じURLの内容が変更されることがあります。学術分野では、リンク切れと内容変化を合わせた「reference rot（参照情報の劣化）」が研究されています。

2026年に公表されたLibrary and Information Science分野の20年間を対象とした研究では、608本の論文に含まれる2,886件のWeb引用を分析しています。引用から0〜5年の情報では87%がアクセス可能だったのに対し、10年を超える引用では38%まで低下したと報告されています。

また、2014年のPLOS ONE掲載研究では、350万本を超える学術記事群を分析し、Web情報を引用する論文では、時間経過によるリンク切れや内容変化が再検証を難しくする問題が確認されています。

企業の記事も学術論文と同じ割合でリンク切れが起こると断定することはできません。ただし、「公開時にアクセスできたURLが将来も同じ情報を示すとは限らない」という性質は共通します。

そのため、台帳にはURLだけでなく、「確認日」と「次回確認期限」が必要です。

エビデンス台帳には最低11項目を記録する

実務では、最初から巨大な管理表を作る必要はありません。まずは次の11項目があれば運用できます。

エビデンス台帳では、出典URLだけでなく「どの主張を支えているか」「いつ再確認するか」「誰が確認するか」まで一続きで管理します。

「主張」は文章単位まで具体化する

「Google資料」「厚生労働省統計」のように出典名だけを記録しても、後から何を確認した資料なのか分からなくなります。

台帳には、次のように根拠と結び付く主張を残します。

悪い例：

• 総務省の資料
• Google公式
• ○○社料金ページ

良い例：

• 「2025年の国内インターネット利用率は○%」
• 「Googleは○○を検索ランキングの直接的な要因とは説明していない」
• 「○○サービスの月額料金は○円から」

1つの出典が複数の記述を支えている場合でも、重要な主張は分けて管理すると更新時に判断しやすくなります。

本文位置を残して差し替え作業を早くする

根拠が古くなったことを検知できても、記事内の使用箇所が分からなければ再調査が必要になります。

「H2：○○の市場規模／第2段落」のように位置を残すか、CMS側で管理できるならアンカーやブロックIDまで記録します。

これにより、出典変更時に影響箇所へ直接移動できます。

出典は「一次情報かどうか」だけでなく、主張との適合性で判断する

出典管理では、可能な限り一次情報へさかのぼることが基本です。

International Fact-Checking Network（IFCN）の原則でも、重要な証拠の出典を読者が追跡できる形で示し、適切な一次資料が存在する場合には二次資料より一次資料を使用することが求められています。

ただし、「一次情報なら何でもよい」という意味ではありません。

優先順位は次のように考えると整理しやすくなります。

1. その事実を直接発表・記録している一次情報
2. 原著論文・公的研究資料
3. 信頼できる専門機関による解説
4. 報道・専門メディア
5. 他社の解説記事やまとめ記事

たとえばGoogle検索の仕様を説明するならGoogle Search Central、法律なら法令本文や所管官庁、企業の料金なら当該企業の公式料金ページが優先候補です。

一方で、一次資料に書かれていない解釈を補う場合には、専門家や研究による二次情報が有効な場合もあります。

重要なのは「出典の格」だけでなく、「その資料が、その主張を本当に裏付けているか」です。

更新期限は情報の変化速度によって分ける

すべての根拠を毎月確認する必要はありません。

逆に、年1回の一括更新では遅すぎる情報もあります。

そこで、出典ごとに更新リスクを分類し、確認期限を決めます。

すべての根拠を同じ頻度で確認するのではなく、情報が変わる速度に応じて再確認期限を設定します。

これは一律の正解ではなく、社内運用のための基準例です。

同じ政府資料でも、毎月更新される統計と5年ごとの調査では期限を分けるべきです。

Googleも、Webページを大幅に更新した場合には更新日を明示することを推奨する一方、実質的な変更を伴わず日付だけを新しくすることは推奨していません。

したがって「更新期限が来た＝記事の日付を変更する」ではありません。

確認した結果、情報が変わっていなければ台帳の確認日だけを更新し、本文に実質的な変更が生じた場合に記事更新へ進めます。

更新期限が来たら「維持・修正・差し替え・削除」の4つに分ける

再確認時に毎回記事全体をリライトすると、運用負荷が大きくなります。

根拠ごとに次の4分類で処理すると効率的です。

1. 維持

出典が有効で、内容にも変更がありません。

確認日と次回期限だけを更新します。

2. 修正

出典は有効ですが、数値や表現など一部が更新されています。

該当箇所だけ修正し、必要に応じて記事の更新日も変更します。

3. 差し替え

元の出典が廃止された、より新しい公式資料が公開されたなどの場合です。

新しい根拠へ変更し、主張がそのまま成立するかも再確認します。

4. 削除

新しい根拠が見つからない、旧情報を現在の事実として残せない場合です。

無理に別の資料で補強せず、主張自体を削除または限定表現へ変更します。

再確認したすべての記事をリライトするのではなく、根拠の状態に応じて「維持・修正・差し替え・削除」を判断します。

エビデンス台帳の運用は5ステップで回す

台帳は作成しただけでは意味がありません。記事制作から更新まで同じフローに組み込みます。

STEP1：公開前に重要な主張を抽出する

すべての文章を登録する必要はありません。

優先して台帳化するのは、次のような情報です。

• 数字・割合・市場規模
• 法律・制度
• 商品・サービス仕様
• 料金
• 調査結果
• 引用
• 固有名詞を伴う事実
• 「○○である」と断定する重要な記述

STEP2：根拠となる情報源を確認する

可能な限り元資料までたどります。

他社記事から数字を見つけた場合、その記事が引用している調査・統計まで確認します。

Googleも、コンテンツの信頼性を自己評価する際に、明確な出典や簡単に確認できる事実誤認がないかを確認するよう案内しています。

STEP3：確認日と更新期限を設定する

情報の変化速度を見て、1か月、3か月、6か月、12か月などの期限を設定します。

次回確認日を空欄にしたまま公開しないことがポイントです。

STEP4：期限が近い根拠を定期抽出する

毎月1回などの頻度で、

「次回確認期限 ≦ 今月末」

となっている根拠を抽出します。

記事数が増えた場合は、記事単位ではなく期限順に根拠を並べることで、必要な確認だけを処理できます。

STEP5：変更があった根拠だけ記事更新へ送る

出典を再確認した結果、変更がなければ台帳更新で終了します。

事実が変わった場合のみ、該当記事と該当箇所を編集工程へ送ります。

これにより、「全記事を定期的に読み直す」運用から「変化可能性のある根拠を監視する」運用へ移行できます。

責任者は記事ではなく根拠の種類で分けてもよい

記事の担当者だけにすべての確認を任せると、専門領域によって品質差が出やすくなります。

運用規模が大きくなったら、根拠の種類ごとに確認担当を設定する方法もあります。

たとえば、

• 法律・制度：法務または専門担当
• 製品仕様：サービス責任者
• 自社調査：調査担当
• SEO・Google仕様：Web担当
• 料金・契約条件：営業・事業責任者

のように分けます。

最終的な記事更新責任者と、「根拠が現在も正しいかを判断できる人」を分ける考え方です。

IFCNの原則でも、出典だけでなく調査・編集・訂正方法を透明にすることが重視されています。

企業メディアでも、誰が確認し、誰が修正判断をするのかを決めておくと、担当者変更後も運用を継続しやすくなります。

最初はスプレッドシート1枚から始めればよい

エビデンス台帳のために、専用システムを最初から導入する必要はありません。

数十〜数百記事程度であれば、Googleスプレッドシートなどでも運用できます。

最低限、次の条件を満たせれば十分です。

• エビデンスIDで一意に管理できる
• 記事IDで絞り込める
• 次回確認期限で並べ替えられる
• 責任者で絞り込める
• ステータスを選択式にできる
• 過去の確認履歴を残せる

記事数や根拠数が増えたら、CMSやデータベースとの連携を検討します。

重要なのはツールではなく、「重要主張→根拠→確認日→期限→責任者→差し替え」という関係が切れないことです。

台帳を作るときに避けたい3つの運用

出典URLだけを一覧化する

URLだけでは、その資料が何を支えているのか判断できません。

必ず主張とセットで管理します。

すべての出典を同じ期限で確認する

更新速度の違いを無視すると、確認作業が過剰になるか、必要な更新が遅れます。

情報の変化速度に応じて期限を分けます。

リンクが生きていれば「有効」と判断する

HTTPエラーが出ていなくても、ページ本文が更新され、以前の主張を支えなくなっている可能性があります。

確認時には「アクセスできるか」だけでなく、「現在の内容が記事の主張を支えているか」まで確認します。

まとめ

記事の品質管理では、公開時のファクトチェックだけでなく、公開後も重要な主張と根拠の関係を追跡できる状態を作ることが重要です。

エビデンス台帳では、少なくとも「主張」「出典」「出典区分」「本文位置」「確認日」「次回確認期限」「ステータス」「責任者」を管理します。

特に重要なのは、記事単位ではなく根拠単位で期限を持つことです。

記事全体を一律に更新するのではなく、期限が来た根拠を再確認し、「維持・修正・差し替え・削除」のどれに該当するかを判断します。

まずは重要な数字・制度・仕様・料金・調査結果だけでも台帳化してください。記事数が増えた後でも、「なぜこの記述を書いているのか」「現在も根拠が有効か」を追跡できるコンテンツ運用につながります。

参考文献・データ元

‹ 親記事: コンテンツ制作・運用体制とは？編集フロー・役割分担・品質チェックの仕組みを体系的に整理