情報源・コンテンツ検証

ジャーナリズムと調査報道のために、情報源・主張・デジタルコンテンツを体系的に検証する手順とテンプレート集。 記者の意図を聞き取り、検証の段取りと記録方法を提案する。記事化の最終判断と事実認定は記者が行う。

注意：検証ツールの提供状況・料金・機能は頻繁に変わる。本スキルに挙げたツール名や仕様は目安であり、利用前に各サービスの最新状態を確認すること。本スキルは一般的な手引きであり、法的助言ではない。

検証の枠組み

SIFT法（基本の型）

S - Stop（止まる）：未確認情報をすぐに共有・記事化しない。確認が済むまで保留する。 I - Investigate the source（発信元を調べる）：誰が、どんな立場で発信しているか。 F - Find better coverage（よりよい情報源を探す）：信頼できる他の情報源は何と言っているか。 T - Trace claims（出所までたどる）：主張・引用・画像・数値を元の一次情報までさかのぼる。

情報源の信頼性チェックリスト

## 情報源評価テンプレート

### 基本的な身元確認
- [ ] 氏名・所属が特定できる
- [ ] 連絡先が検証可能である
- [ ] 専門的な資格・経歴が確認できる
- [ ] 複数のプラットフォームで来歴が一貫している

### 専門性の評価
- [ ] 当該主張に関する専門性があるか
- [ ] その分野での実績があるか
- [ ] 同業者・専門家に認知されているか
- [ ] 過去に誤情報を広めた経歴がないか

### 動機の分析
- [ ] 利益相反の可能性はないか
- [ ] 結果に金銭的な利害はないか
- [ ] 政治的・思想的な動機はないか
- [ ] 個人的な怨恨が絡んでいないか

### 裏付け（コロボレーション）
- [ ] 主張を独立して検証できるか
- [ ] 他の信頼できる情報源が確認しているか
- [ ] 文書などの物証があるか
- [ ] 矛盾する情報源はないか

デジタル検証の技法

SNSアカウントの分析

より深いオープンソース・インテリジェンス（OSINT）やプラットフォーム別の分析手法は、別途専門の手引きを参照する。ここでは「引用・記事化の前に検証すべきか」を判断するための、検証文脈に絞った要点を扱う。

## アカウント検証チェックリスト

### アカウントの年齢と履歴
- 作成時期（古いアカウントほど一般に信頼性が高い）
- 投稿の頻度とパターン
- 活動の空白（長期休眠の後、突然活発化していないか）
- 表記・言葉づかいが時系列で一貫しているか

### ネットワーク分析
- フォロワー／フォロー比
- フォロワーの質（実在アカウントかボットか）
- やり取りのパターン（誰が反応しているか）
- 認証済み・既知のアカウントとの相互関係

### 投稿内容のパターン
- 独自投稿か、リポスト・引用のみか
- 一貫して扱っているテーマ
- 投稿に含まれる地理的な手がかり
- 投稿活動の時間帯（主張される所在地と整合するか）

### 危険信号（レッドフラグ）
- 作成直後のアカウントが大胆な主張をしている
- テーマや論調が突然転換している
- 他アカウントと協調した同時拡散の兆候
- プロフィール画像がフリー素材・他人の写真の流用
- 具体性のない定型的なプロフィール

日本語SNS環境での補足。

• 日本では X（旧Twitter）、LINE、YouTube、TikTok、Instagram のほか、匿名掲示板（5ちゃんねる等）、まとめサイト、Yahoo!ニュースのコメント欄が一次拡散源になりやすい。匿名性が高いぶん、発信元の特定には投稿時刻・方言・固有名詞・画像の手がかりなど周辺情報の積み上げが要る。
• なりすまし・パロディアカウントが日本語名・公式風アイコンを使う例が多い。公式サイトや既知の連絡先から逆にたどって真偽を確かめる（公式アカウントのリンク先が本人のドメインか等）。
• 「拡散している」こと自体は真実性の証拠にならない。ボット・組織的アカウントによる増幅（インプレッション稼ぎ目的を含む）を疑う。

逆画像検索のワークフロー

## 画像検証の手順

### 手順1：逆画像検索
使うツール：
- Google 画像検索 / Google レンズ（images.google.com）
- TinEye（tineye.com）
- Yandex 画像検索（yandex.com/images）：顔の検索に強い
- Bing ビジュアル検索

複数のエンジンで検索する。エンジンごとに得意な対象・収録範囲が異なる。

### 手順2：メタデータ（Exif）の確認
- 元の撮影日時
- カメラ・機器の情報
- GPS座標（記録されていれば）
- 編集に使われたソフトウェア

ツール：
- Exif ビューア各種（exif.regex.info 等）
- FotoForensics（fotoforensics.com）：誤差レベル分析（ELA）
- InVID / WeVerify の検証プラグイン

※ SNSにアップロードされた画像はメタデータが削除されていることが多い。
　 Exifが無い＝加工の証拠、ではない。

### 手順3：画像の中身を分析
- 天候（報じられた日付と整合するか）
- 影（時間帯と整合するか）
- 看板・標識・文字（その場所の言語・表記として正しいか）
- 建築・街並み（主張される場所と一致するか）
- 服装（季節として妥当か）

### 手順4：初出をたどる
- ネット上での最も古い出現
- 元の撮影者・出所
- 最初に公開されたときの文脈
- 別の文脈で使い回されていないか

日本での撮影地・日時の照合（ジオロケーション）。

• 地図・空中写真の照合には Google マップ／ストリートビュー、国土地理院の「地理院地図」、自治体の都市計画図・空中写真が使える。日本独特の手がかり（電柱の住居表示プレート、バス停名、自販機・店舗の看板、ナンバープレートの地名、道路標識の地名・国道番号）は場所の特定に有効。
• 日時の照合には、影の向きから日時を推定するツール（SunCalc 等）、過去の天気（気象庁の「過去の気象データ検索」）、桜・紅葉など季節の手がかりが使える。
• 「いつ・どこで」が崩れると主張全体が崩れることが多い。撮影地・日時の照合は検証の中心に置く。

動画の検証

## 動画検証チェックリスト

### 技術的な分析
- [ ] 解像度が全編で一貫しているか
- [ ] 音声と映像が同期しているか
- [ ] 目立つ編集痕がないか
- [ ] フレーム間で照明が一貫しているか
- [ ] 影が物理的に自然か

### 内容の分析
- [ ] 場所が特定・検証できるか
- [ ] 時刻の手がかり（太陽の位置・影）
- [ ] 天候が過去の記録と整合するか
- [ ] 背景の細部が一貫しているか
- [ ] 人物の服装が文脈に合っているか

### メタデータの確認
- [ ] 投稿日と主張される事象の日付の関係
- [ ] 元の出所が特定できるか
- [ ] 入手経路（チェーン・オブ・カストディ）をたどれるか
- [ ] 別アングルの映像があるか

### ツール
- InVID / WeVerify ブラウザ拡張（キーフレーム抽出・逆画像検索）
- 動画プラットフォームのアップロード日時を確認する各種ビューア
- フレーム単位の解析ツール

生成・合成メディア（AI生成）の検知

2026年時点で、高品質な合成メディアを肉眼で見抜くのはもはや当てにならない。検知ツールも拡散モデル（ディフュージョンモデル）の進歩に追いついていない。単一ツールの判定は一つの入力に過ぎず、最終判断にはしない。

検証は二層で考える。来歴（プロビナンス）＝作成時に電子署名されたか、と検知（ディテクション）＝生成物らしく見えるか。来歴は存在すれば強い手がかりだが、無いからといって偽とは限らない。

第1層 — コンテンツ来歴（C2PA / Content Credentials）の確認

C2PA（Coalition for Content Provenance and Authenticity）は、画像・音声・動画ファイルの中に、由来と編集履歴を記した暗号署名付きの「マニフェスト」を埋め込む規格。対応する生成AI・カメラ・編集ソフトが増えている。

対応の広がり（目安）：

• 生成AI画像・動画：主要な画像生成サービス・動画生成サービスの一部は、生成物に来歴情報を既定で書き込む。可視の電子透かしを併用する場合もある。Adobe（Photoshop・Lightroom・Firefly）、Microsoft 系、Google 系の一部も来歴情報を書き込む。
• カメラ（撮影時署名）：一部の高級ミラーレス機・放送用カメラ、スマートフォンの一部が撮影時に来歴署名に対応している（機種・ファームウェアによる）。
• 署名鍵の脆弱性事例：あるメーカーのカメラで署名鍵の脆弱性により来歴サービスが一時停止・証明書失効となった事例がある。「署名がある＝絶対に正しい」ではない点に注意。
• 報道機関：海外の主要通信社・新聞社が来歴規格の推進団体に参加しているが、現場の制作工程への統合度は各社まちまち。

確認ツール：ファイルを contentcredentials.org/verify に投入すると、マニフェスト・撮影機器・編集履歴・AIツールの関与の有無を読み取れる。Adobe の検証ツールや C2PA 対応のブラウザ拡張でも同様の確認ができる。

ハードバインディングとソフトバインディング。 ハードバインディングは署名済みマニフェストに本体のハッシュ（SHA-256等）を埋め込み、1ピクセルでも変えると無効になる（完全性は強いが再エンコードに弱い）。ソフトバインディングは知覚的フィンガープリントや不可視の電子透かしをマニフェスト・リポジトリに保存し、スクリーンショットや変換に耐えるが完全性の保証は弱い。ソフトバインディングはメタデータ削除後にマニフェストを復元できる利点がある。

既知の限界。

• スクリーンショットはハードバインディングのマニフェストを完全に消す。
• 多くのSNSはアップロード時にメタデータを削除する。一部のプラットフォームが来歴の保持を始めているが、対応は部分的。
• 来歴情報が無いことは偽の証拠にならない。現在流通しているカメラ・スマホ画像の大半は署名されていない。
• 署名鍵の漏えいは現実の攻撃経路。上流の侵害があれば「有効な署名」も信用を損なう。

第2層 — 自動検知ツール

ツール種別	用途	留意点
商用の総合検知API	画像・動画・音声・テキストの判定。大量処理向き	無料枠と有料プランがある。判定は確率でしかない
高速トリアージ系	画像の一次判定	速いが権威ある判定ではない。第一段階に留める
フォレンジック・エンタープライズ系	政府・法務向けの精密判定	高価で記者の予算に合わないことが多い
学術系の無料ツール	ディープフェイク検知（大学等）	提供状況が変わりやすい。利用前に稼働確認

具体的なサービス名・料金は変動が激しい。いずれのツールも単独で結論にしない。 最低でも2つの検知ツールにかけ、判定が割れたら「より深い分析または情報源への直接確認に進む合図」と捉える。なお、過去に有名だった検知サービスのいくつかは終了しているので、リンク先や名称が現役かを利用前に確認する。

第3層 — 目と耳による検知（2026年の感覚値）

指の本数がおかしい、耳が歪む、瞳孔が左右非対称、といった古い「アラ」は、現在の拡散モデルや高品質動画ではほぼ消えた。なお漏れやすいのは：

• 境界部：髪の生え際、耳の縁、歯の境目、眼鏡と肌の境界。細かく見ると微妙な不整合が出る。
• 照明と影の物理：シーンの光源方向と合わないハイライト、欠落・矛盾する落ち影。
• 目の反射のずれ：左右の瞳に映り込む光（キャッチライト）がシーンと整合しない。
• 音声と口の同期：数秒の長さで音素と口の動きの同期がずれていく。
• 肌の質感：部分的に蝋のように滑らか。本来は表面で変わるはずのノイズが画面全体で一様。
• 音声クローン：息継ぎの位置、破裂音、部屋の残響（ルームトーン）が手がかりとして残る。ただし音声クローンは一般の聞き手には聞き分け困難な水準に達しており、音声だけの確認は破綻すると想定する。

目視・聴取による検知は単独では当てにならない。 トリアージと「深掘りに進むかの判断」に使い、最終的な決め手にはしない。

疑わしいメディアの検証ワークフロー

1. まず来歴を確認：ファイルを contentcredentials.org/verify に投入。既知の署名者による有効なマニフェストは強い肯定材料。無くても何も証明しない。
2. 逆画像検索：Google レンズ・TinEye・Yandex（顔は依然として強い）。最古の出現を探す。
3. 検知ツールを2つ走らせる：画像なら総合API＋高速トリアージ。判定が割れたらエスカレーション。
4. フレーム単位・音声の分析：動画は境界の不整合と口の同期を確認。音声はスペクトログラム・息継ぎ・ルームトーンの一様性を調べる。
5. 情報源に直接当たる：直接の確認が最も信頼度が高い。C2PAは「誰が署名したか」を示すが「誰が目撃したか」は示さない。

文書の検証

PDF・文書の分析

## 文書検証の手順

### メタデータの確認
- 作成日と更新履歴
- 作成者の情報
- 作成に使われたソフトウェア
- 埋め込みフォント・画像

### 目視検査
- 全体を通じて書式が一貫しているか
- フォントが揃っているか（テキストの貼り合わせがないか）
- 文字と画像の位置がそろっているか
- ページ間で品質が一貫しているか
- 署名・印影が本物らしいか

### 内容の検証
- 日付に内部矛盾がないか
- 氏名の表記が全体で一致しているか
- 整理番号・文書番号が有効か
- 連絡先が検証可能か
- レターヘッド・公印が既知の例と一致するか

### 来歴（プロビナンス）
- どのように入手した文書か
- 入手経路（チェーン・オブ・カストディ）を記録しているか
- 原本か写しか
- 情報源は追加の文脈を提供できるか

行政文書の真正性確認には、情報公開請求で同じ文書を正規に取り寄せて突き合わせる方法も有効（別途「情報公開請求」スキルを参照）。

検証トレイル（検証記録）の作成

記録テンプレート

## 検証記録

**検証する主張：**
[具体的な主張を記載]

**主張の出所：**
- 氏名／アカウント：
- プラットフォーム：
- 初めて見た日時：
- URL（アーカイブ済み）：

**実施した検証手順：**

### 手順1：[内容]
- 行ったこと：
- 使ったツール・方法：
- 結果：
- 保存した証拠（スクリーンショット等）：[ファイル名]

### 手順2：[内容]
- 行ったこと：
- 使ったツール・方法：
- 結果：
- 保存した証拠：[ファイル名]

[手順ごとに続ける]

**裏付けとなる情報源：**
1. [情報源1] - [何を裏付けるか]
2. [情報源2] - [何を裏付けるか]
3. [情報源3] - [何を裏付けるか]

**矛盾する情報：**
1. [情報源] - [何と矛盾するか]

**確度の評価：**
- [ ] 真と確認
- [ ] おそらく真（高確度）
- [ ] 未確認（証拠不十分）
- [ ] おそらく偽（矛盾する証拠あり）
- [ ] 偽と確認

**判断の根拠：**
[証拠にもとづく結論の説明]

**検証実施者：**
**日付：**

証拠のアーカイブ

ウェブアーカイブの実務

ページは消える、書き換えられる、有料化される。記事に使う可能性があると判断した一次情報URLは、その時点で必ずアーカイブする。 単一のアーカイブが落ちても証拠が残るよう、Wayback Machine と Archive.today の両方に同時保存する。詳細な一括処理・復旧の手順は別途専門の手引きを参照。

import requests
from urllib.parse import quote

def archive_url(url: str, perma_cc_api_key: str | None = None) -> dict:
    """URL を Wayback Machine と Archive.today にアーカイブする。

    各サービスごとにアーカイブ済みURL（またはエラー）を辞書で返す。
    perma_cc_api_key を渡すと Perma.cc にも保存する（要アカウント）。
    """
    results = {}

    # Internet Archive Wayback Machine
    try:
        response = requests.get(
            f'https://web.archive.org/save/{quote(url, safe="")}',
            timeout=60,
            allow_redirects=True,
        )
        if response.status_code == 200:
            results['wayback'] = response.url
        else:
            results['wayback_error'] = f'HTTP {response.status_code}'
    except requests.RequestException as e:
        results['wayback_error'] = str(e)

    # Archive.today — /submit/ に POST。アーカイブ済みURLは
    # Refresh ヘッダ（または 302 の Location ヘッダ）に現れる。
    try:
        response = requests.post(
            'https://archive.ph/submit/',
            data={'url': url},
            timeout=120,
            allow_redirects=False,
            headers={'User-Agent': 'Mozilla/5.0 (verification archive bot)'},
        )
        archived = response.headers.get('Refresh', '').split('url=')[-1] \
            or response.headers.get('Location', '')
        if archived:
            results['archive_today'] = archived
        else:
            results['archive_today_error'] = f'no archived URL returned (HTTP {response.status_code})'
    except requests.RequestException as e:
        results['archive_today_error'] = str(e)

    # Perma.cc（任意、Perma アカウントの API キーが必要）
    if perma_cc_api_key:
        try:
            response = requests.post(
                'https://api.perma.cc/v1/archives/',
                json={'url': url},
                headers={'Authorization': f'ApiKey {perma_cc_api_key}'},
                timeout=60,
            )
            if response.status_code == 201:
                results['perma_cc'] = f"https://perma.cc/{response.json()['guid']}"
            else:
                results['perma_cc_error'] = f'HTTP {response.status_code}'
        except requests.RequestException as e:
            results['perma_cc_error'] = str(e)

    return results

報道時点で取得したアーカイブは、公開前に消えてしまう引用と、後から裏付けられる引用の分かれ目になる。

スクリーンショットの記録

## スクリーンショットのベストプラクティス

1. **ページ全体を撮る**：全画面キャプチャの拡張機能を使う
2. **URLバーを含める**：出所URLが分かるようにする
3. **日時を残す**：システム時計を写し込むか、手動で付記する
4. **メタ情報を記録**：いつ・どう取得したかをメモする
5. **複数形式で保存**：PNG（可逆）と PDF
6. **安全に保管**：ファイルのハッシュを取り、安全に保管する

※ ブラウザの「PDFに印刷」はURLと日付を含められる簡便な方法。

取材・インタビューの検証

取材前の情報源チェック

## 情報源の身辺確認

### 公的記録
- [ ] 専門職の資格（士業の登録等）
- [ ] 裁判記録（係属・判決の有無）
- [ ] 法人の登記情報（商業登記・法人番号）
- [ ] 不動産登記（関係する場合）
- [ ] 政治資金収支報告書（政治関連の場合）

### 職歴・経歴
- [ ] 公開されている経歴・プロフィール
- [ ] 所属の確認
- [ ] 過去の所属先
- [ ] 公表された著作・論文・発言
- [ ] 講演・登壇歴

### SNSの確認
- [ ] 使っている全プラットフォームの把握
- [ ] 投稿履歴の確認
- [ ] つながり・フォロワーの分析
- [ ] 当該テーマに関する過去の発言
- [ ] 削除された投稿の有無

### メディア露出
- [ ] 過去のインタビュー
- [ ] 現在の主張との一貫性
- [ ] 他の記者による評価
- [ ] 訂正・撤回の有無

日本での公的記録の調べ先（目安）。 法人の登記情報は法務局・登記情報提供サービス、法人番号は国税庁の法人番号公表サイト。政治資金は総務省・各都道府県選管が公表する収支報告書。許認可・行政処分は所管省庁・自治体の公表ページ。詳細な行政文書は情報公開請求で取り寄せる。

インタビュー中の検証

## リアルタイム検証の技法

### 資料の依頼
- インタビュー中に裏付け資料を求める
- 資料が改変されていないか確認する
- 写しではなく原本を求める（可能なとき）
- 資料の状態・入手経路をメモする

### 具体的な細部を掘る
- 具体的な日付・氏名・場所を尋ねる
- 裏付けとなる目撃者を求める
- 「それをどうして知ったのか」を問う
- 曖昧な答えは追いかける

### 一貫性の確認
- 最初に語られた筋を記録する
- 後で要点に立ち返る
- 語り直しごとに細部を比較する
- 食い違いは追加確認の対象として記録する

### 録音の作法
- 同意を得る（録音の可否・通知義務は状況・媒体により異なる。要確認）
- 信頼できる機材を使う
- リアルタイムでバックアップを取る
- 非言語の様子は別途メモする

検証リソース

ツール（汎用）

ツール	用途	URL
InVID / WeVerify	動画検証ブラウザ拡張	weverify.eu
TinEye	逆画像検索	tineye.com
Yandex 画像検索	逆画像検索（顔に強い）	yandex.com/images
Google レンズ	逆画像検索	images.google.com
Wayback Machine	ウェブアーカイブ	web.archive.org
Archive.today	ウェブアーカイブ（Waybackが拒否されるサイトにも）	archive.ph
FotoForensics	画像の誤差レベル分析（ELA）	fotoforensics.com
SunCalc	太陽の位置・影から日時を推定	suncalc.org

情報源の「信頼度ランク」サイトについて。 海外には報道機関の偏向・信頼度を格付けするサイトがあるが、いずれも一観察者の編集的分類であり査読された権威ではない。未知の媒体を評価する際の一つの入力として使い、決定的な判定にはしない。

日本の参考先・学習リソース

- 日本ファクトチェックセンター（JFC）……検証手法・事例
- FIJ（ファクトチェック・イニシアティブ）……国内ファクトチェックの推進・ガイドライン
- InFact、リトマス 等の国内ファクトチェック媒体……検証記事の実例
- Bellingcat（bellingcat.com/resources）……OSINT・ジオロケーションの手引き
- Google ニュース イニシアティブ（newsinitiative.withgoogle.com）……検証ツールの解説
- Verification Handbook（verificationhandbook.com）……検証実務の定番ガイド
- 国土地理院「地理院地図」、気象庁「過去の気象データ検索」……撮影地・日時の照合

米国固有の研究ツール・州別リソース・特定国の透明性ツール等は、日本の実務に合わないため割愛している。

取材倫理・法令上の注意

• 二次被害への配慮：個人の特定・拡散は深刻な二次被害を生む。検証の過程で個人を特定できても、安易に公表しない。個人情報保護法と各社の取材倫理規程に従う。被害者・遺族・未成年・無関係の第三者が写り込む素材の扱いは特に慎重に。
• 未確認の明示：検証できていない情報を「未確認」と明示せずに扱わない。確認できた範囲のみを記述する。
• 検証過程の保存：確認した情報源・日時・判断の根拠を記録し、後から説明できる状態にする（上記「検証トレイル」を使う）。
• デマ・誤情報の拡散防止：検証目的でも、誤情報の原文・元画像をそのまま拡散しない。引用・転載の範囲は最小限にし、訂正・打ち消しと一体で扱う。
• 撮影・録音の適法性：盗撮・無断録音にあたらないか、状況ごとに確認する。プライバシー・肖像権・著作権にも注意。法的判断が必要な場合は社内法務・弁護士に相談する。
• 生成AIの判定の限界：検知ツールの判定は確率であり、誤判定がある。ツールの結論だけで「偽」と断定して報じない。

関連スキル

• 情報公開請求：一次情報となる行政文書を正規に入手し、文書の真偽照合にも使う
• 取材準備：インタビュー前に情報源の背景を確認する
• ファクトチェックの判定ワークフロー、OSINT、ウェブアーカイブの詳細手順は、それぞれ別途の手引きを参照

---

出典・ライセンス（帰属表示）

本スキルは claude-skills-journalism（by Joe Amditis, MIT License, © 2025 Joe Amditis, https://github.com/jamditis/claude-skills-journalism ）の journalism-core/source-verification を 原典の構成（SIFT法・情報源評価・SNSアカウント分析・逆画像/動画検証・C2PA来歴・AI生成検知・文書検証・検証トレイル・アーカイブ・取材検証・リソース）に沿って日本語化し、 日本語SNS環境・国内の一次情報確認・個人情報保護法・取材倫理・拡散による二次被害への配慮を加えて再構成したものです。 米国固有のツール・研究機関・透明性リソース等は日本／汎用のものに置き換え、該当しない部分は割愛しています。 第三者の著作物本文（各社用語集・ハンドブック等）は転載していません。原作者の公認・推奨を受けたものではありません。 MIT ライセンス全文は同梱の LICENSE-MIT.txt を参照。