ファクトチェッカー

ドキュメント内の事実的主張を検証し、権威のある情報源に基づいた修正を提案します。

使用する場面

以下のようなユーザーのリクエストをトリガーとします:

• 「このドキュメントをファクトチェックして」
• 「これらの AI モデルの仕様を確認して」
• 「この情報はまだ正確ですか?」
• 「このファイルの古いデータを更新して」
• 「このセクションのクレームを検証して」

ワークフロー

進行状況を追跡するためにこのチェックリストをコピーしてください:

ファクトチェック進行状況:
- [ ] ステップ 1: 事実的主張を特定する
- [ ] ステップ 2: 権威のある情報源を検索する
- [ ] ステップ 3: 主張を情報源と比較する
- [ ] ステップ 4: 修正レポートを生成する
- [ ] ステップ 5: ユーザー承認後に修正を適用する

ステップ 1: 事実的主張を特定する

ドキュメントをスキャンして検証可能なステートメントを特定します:

対象となるクレームの種類:

• 技術仕様 (コンテキストウィンドウ、価格設定、機能)
• バージョン番号とリリース日
• 統計データとメトリクス
• API 機能と制限事項
• ベンチマークスコアとパフォーマンスデータ

主観的なコンテンツはスキップ:

• 意見と推奨事項
• 説明文
• チュートリアルの手順
• アーキテクチャ的な議論

ステップ 2: 権威のある情報源を検索する

各クレームについて、公式情報源を検索します:

AI モデル:

• 公式アナウンスページ (anthropic.com/news, openai.com/index, blog.google)
• API ドキュメンテーション (platform.claude.com/docs, platform.openai.com/docs)
• 開発者ガイドとリリースノート

技術ライブラリ:

• 公式ドキュメンテーションサイト
• GitHub リポジトリ (releases, README)
• パッケージレジストリ (npm, PyPI, crates.io)

一般的なクレーム:

• 学術論文と研究
• 政府統計
• 業界標準化団体

検索戦略:

• モデル名 + 仕様を使用 (例: "Claude Opus 4.5 context window")
• 最新情報の場合は現在の年を含める
• 可能な限り複数のソースから検証する

ステップ 3: 主張を情報源と比較する

比較表を作成します:

ドキュメント内のクレーム	ソース情報	ステータス	権威ある情報源
Claude 3.5 Sonnet: 200K トークン	Claude Sonnet 4.5: 200K トークン	❌ モデル名が古い	platform.claude.com/docs
GPT-4o: 128K トークン	GPT-5.2: 400K トークン	❌ バージョンと仕様が不正確	openai.com/index/gpt-5-2

ステータスコード:

• ✅ 正確 - クレームが情報源と一致している
• ❌ 不正確 - クレームが情報源と矛盾している
• ⚠️ 古い - かつてはクレームが真実だったが、上書きされている
• ❓ 検証不可 - 権威のある情報源が見つからない

ステップ 4: 修正レポートを生成する

構造化された形式で結果を提示します:

## ファクトチェック報告書

### 概要
- チェックしたクレーム総数: X
- 正確なもの: Y
- 修正が必要な問題: Z

### 修正が必要な問題

#### 問題 1: AI モデルの参照が古い
**位置:** docs/file.md の 77-80 行目
**現在のクレーム:** 「Claude 3.5 Sonnet: 200K トークン」
**修正内容:** 「Claude Sonnet 4.5: 200K トークン」
**ソース:** https://platform.claude.com/docs/en/build-with-claude/context-windows
**理由:** Claude 3.5 Sonnet は Claude Sonnet 4.5 に置き換わりました (2025 年 9 月リリース)

#### 問題 2: コンテキストウィンドウが不正確
**位置:** docs/file.md の 79 行目
**現在のクレーム:** 「GPT-4o: 128K トークン」
**修正内容:** 「GPT-5.2: 400K トークン」
**ソース:** https://openai.com/index/introducing-gpt-5-2/
**理由:** 128K は出力制限でした。コンテキストウィンドウは 400K です。モデルも GPT-5.2 に更新されています。

ステップ 5: ユーザー承認後に修正を適用する

変更を加える前に:

1. ユーザーに修正レポートを表示する
2. 明示的な承認を待つ: 「これらの修正を適用してもよろしいですか?」
3. 確認後のみ続行する

修正を適用する際:

# Edit ツールを使用してドキュメントを更新
# 例:
Edit(
    file_path="docs/03-写作规范/AI辅助写书方法论.md",
    old_string="- Claude 3.5 Sonnet: 200K tokens（約 15 万汉字）",
    new_string="- Claude Sonnet 4.5: 200K tokens（約 15 万汉字）"
)

修正後:

1. すべての編集が正常に適用されたことを確認する
2. 修正の概要を記録する (例: 「セクション 2.1 で 4 つのクレームを更新しました」)
3. ユーザーに変更をコミットするよう促す

検索のベストプラクティス

クエリの構成

優れたクエリ (具体的、最新):

• 「Claude Opus 4.5 context window 2026」
• 「GPT-5.2 official release announcement」
• 「Gemini 3 Pro token limit specifications」

不十分なクエリ (曖昧、一般的):

• 「Claude context」
• 「AI models」
• 「Latest version」

ソース評価

公式情報源を優先:

1. 製品公式ページ (最も信頼性が高い)
2. API ドキュメンテーション
3. 公式ブログアナウンスメント
4. GitHub リリース (オープンソースの場合)

注意して使用:

• サードパーティアグリゲーター (llm-stats.com など) - 公式ソースに対して検証する
• ブログ記事と記事 - クレームを相互参照する
• ソーシャルメディア - アナウンスメントのみ、他で検証する

避ける:

• 古いドキュメンテーション
• 引用のない非公式ウィキ
• 推測と噂

曖昧さへの対処

ソースが競合する場合:

1. 最新の公式ドキュメンテーションを優先する
2. レポートで矛盾を記録する
3. ユーザーに両方のソースを提示する
4. 重要な場合はベンダーに連絡することを推奨する

ソースが見つからない場合:

1. ❓ 検証不可とマークする
2. 別の表現を提案: 「[ソース] によると [日付] 現在...」
3. 修飾語を追加することを推奨: 「approximately」、「reported as」

特殊な考慮事項

時間に敏感な情報

常に時間的背景を含めます:

優れた修正:

• 「2026 年 1 月現在」
• 「Claude Sonnet 4.5 (2025 年 9 月リリース)」

不十分な修正:

• 「最新バージョン」 (時代遅れになる)
• 「現在のモデル」 (曖昧な時間枠)

数値の精度

精度をソースと一致させます:

ソースが言及: 「約 100 万トークン」 記述: 「100 万トークン (約)」

ソースが言及: 「200,000 トークンコンテキストウィンドウ」 記述: 「200K トークン」 (正確)

引用形式

修正に引用を含めます:

> **注**：具体的なコンテキストウィンドウはモデルの公式ドキュメントに従うものとし、本書執筆時には Claude Sonnet 4.5 を主要なツールとして使用しています。

可能な限りソースへのリンクを含めます。

例

例 1: 技術仕様の更新

ユーザーのリクエスト: 「セクション 2.1 の AI モデルコンテキストウィンドウをファクトチェックして」

プロセス:

1. クレームを特定: Claude 3.5 Sonnet (200K)、GPT-4o (128K)、Gemini 1.5 Pro (2M)
2. 最新モデルの公式ドキュメントを検索する
3. 検索結果: Claude Sonnet 4.5、GPT-5.2、Gemini 3 Pro
4. 矛盾を示すレポートを生成する
5. 承認後に修正を適用する

例 2: 統計データの検証

ユーザーのリクエスト: 「第 5 章のベンチマークスコアを確認して」

プロセス:

1. 数値クレームを抽出する
2. 公式ベンチマーク発行物を検索する
3. 報告値とソース値を比較する
4. ソースリンクで矛盾をフラグする
5. 検証された数字で更新する

例 3: バージョン番号の検証

ユーザーのリクエスト: 「これらのライブラリバージョンがまだ最新ですか?」

プロセス:

1. 記載されているすべてのバージョン番号をリストする
2. パッケージレジストリ (npm、PyPI など) を確認する
3. 古いバージョンを特定する
4. チェンジログリファレンスでアップデートを提案する
5. ユーザーが確認後に更新する

品質チェックリスト

ファクトチェックを完了する前に:

• すべての事実的クレームが特定および分類されている
• 各クレームが公式ソースに対して検証されている
• ソースが権威あり、最新である
• 修正レポートが明確で実行可能である
• 時間的背景が関連する箇所に含まれている
• 変更前にユーザー承認が得られている
• すべての編集が正常に適用されたことが検証されている
• ユーザーに概要が提供されている

制限事項

このスキルはできません:

• 主観的な意見や判断を検証する
• ペイウォールまたは制限付きソースにアクセスする
• 争点となっているクレームの「真実」を判断する
• 将来の仕様または機能を予測する

このような場合は:

• レポートで制限事項を記録する
• 修飾言語を提案する
• ユーザー調査または専門家相談を推奨する

次のステップ: 検証済みコンテンツをエクスポート

ファクトチェック後、検証済みドキュメントをエクスポートすることを提案します:

ファクトチェック完了: [N] 件のクレームが検証され、[M] 件の修正が提案されました。

オプション:
A) PDF としてエクスポート — /pdf-creator を実行 (正式なドキュメントに推奨)
B) スライドを作成 — 検証済みコンテンツから /ppt-creator を実行
C) 結構です — 修正済みドキュメントを直接使用します