fact-check-rewrite

ファクトチェック＆記事リライトスキル

記事やリサーチレポートに含まれるファクト（事実）を抽出・検証し、誤りを修正した新しい記事をGoogleドキュメントまたはWordファイルとして出力する。

When to Use This Skill

以下のリクエストで使用する：

• 記事・レポートのファクトチェック（事実確認・検証）
• 記事中の数値・固有名詞・日付・出来事の正確性を確認したい
• ファクトチェック結果を踏まえた修正版記事の作成
• 「ファクトチェックして」「事実確認して」「この記事を検証して」

全体フロー

ステップ1: ファクト抽出 → ファクトリスト作成
ステップ2: 並列ファクトチェック → 1ファクト1サブエージェント
ステップ3: 統合結果リスト → 正誤・修正内容を整理
ステップ4: 修正記事作成 → story-writingスキル準拠、Googleドキュメント出力

---

ステップ1: ファクト抽出

入力の取得

ユーザーから以下のいずれかで入力を受け取る：

• テキストの直接貼り付け
• ファイルのアップロード（PDF、DOCX、テキストなど）
• URLの指定（fetch_urlで取得）

ファクト抽出ルール

入力テキストから、検証可能なファクト（事実）を網羅的に抽出する。以下のカテゴリに分類する：

カテゴリ	例
数値・統計	「売上高は前年比15%増の3兆円」「従業員数は約5万人」
日付・時期	「2024年3月に発表された」「創業は1998年」
固有名詞・人物	「CEOのジョン・スミス氏」「本社はサンフランシスコ」
因果関係・出来事	「AIチップの輸出規制により売上が減少した」
引用・発言	「同社のCEOは決算説明会で〜と述べた」
比較・ランキング	「業界第2位のシェア」「前年を上回る成長率」

ファクトリストの形式

抽出したファクトを以下の形式でワークスペースにJSONファイルとして保存する：

ファイル名: /home/user/workspace/fact_check/facts.json

[
  {
    "id": 1,
    "category": "数値・統計",
    "claim": "同社の2024年度売上高は前年比15%増の3兆円に達した",
    "context": "記事の第2段落、業績概要のセクション",
    "original_sentence": "元の記事中の該当文をそのまま記載"
  },
  {
    "id": 2,
    "category": "日付・時期",
    "claim": "新製品は2024年3月に発表された",
    "context": "記事の第3段落",
    "original_sentence": "元の記事中の該当文をそのまま記載"
  }
]

ファクトの数に上限はないが、検証可能な具体的事実のみを抽出する。主観的な評価（「素晴らしい業績」など）は対象外。

---

ステップ2: 並列ファクトチェック

実行方法

ファクトリストの各ファクトについて、1ファクトにつき1サブエージェントを run_subagent で起動する。

サブエージェントは可能な限り多く並列で起動する。ツールの上限に従い、その時点の最大同時実行数でバッチを組む。具体的には：

• run_subagent で起動する場合：1バッチあたりの上限はその時点のシステム上限に従う。全ファクトを可能な限り同時に起動し、上限を超える分は次のバッチで実行する
• wide_research で実行する場合：ファクト数が20件以上のときは confirm_action でユーザー承認を得てから実行する

目標は「全ファクトを最短時間で検証完了すること」。並列数を節約する必要はない。

サブエージェントへの指示テンプレート

各サブエージェントには以下の objective を渡す：

以下のファクト（事実の主張）が正しいかどうかを検証してください。

ファクトID: {id}
カテゴリ: {category}
主張: {claim}
文脈: {context}

検証手順：
1. search_web を使い、この主張に関連する情報を複数の信頼できるソースから収集する
2. 公式発表、決算資料、政府統計、大手メディアの報道など一次ソースを優先する
3. 主張の正確性を判定する（正確 / 不正確 / 部分的に正確 / 検証不能）
4. 不正確または部分的に正確な場合、正しい情報と修正案を提示する

結果を以下のJSON形式でファイルに保存してください：
/home/user/workspace/fact_check/result_{id}.json

{
  "id": {id},
  "claim": "{claim}",
  "verdict": "正確 | 不正確 | 部分的に正確 | 検証不能",
  "confidence": "高 | 中 | 低",
  "evidence": "検証に使用した根拠の要約",
  "sources": ["ソースURL1", "ソースURL2"],
  "correction": "不正確の場合の修正内容（正確な場合はnull）",
  "corrected_sentence": "修正後の文（正確な場合は元の文をそのまま）"
}

サブエージェントの設定：

subagent_type: "research"
task_name: "ファクトチェック: ファクトID {id}"

バッチ実行の管理

• 全サブエージェントの完了を待ってからステップ3に進む
• サブエージェントがエラーになった場合は「検証不能」として記録する

---

ステップ3: 統合結果リストの作成

結果の集約

全サブエージェントの結果ファイル（result_{id}.json）を読み込み、統合結果リストを作成する。

統合結果リストの形式

ファイル名: /home/user/workspace/fact_check/integrated_results.json

{
  "summary": {
    "total_facts": 10,
    "accurate": 7,
    "inaccurate": 2,
    "partially_accurate": 1,
    "unverifiable": 0
  },
  "results": [
    {
      "id": 1,
      "category": "数値・統計",
      "claim": "同社の2024年度売上高は前年比15%増の3兆円に達した",
      "verdict": "不正確",
      "confidence": "高",
      "evidence": "公式決算資料によると売上高は2.8兆円で前年比12%増",
      "sources": ["https://..."],
      "correction": "売上高は2.8兆円、前年比12%増が正しい",
      "original_sentence": "元の文",
      "corrected_sentence": "修正後の文"
    }
  ]
}

ユーザーへの中間報告

統合結果リストをユーザーに見やすく提示する。表形式で以下を示す（根拠ソースURLは必ずインラインリンクで記載する）：

#	カテゴリ	主張	判定	信頼度	修正内容	根拠ソース
1	数値・統計	売上高は3兆円	不正確	高	正しくは2.8兆円	公式IR, 日経
2	日付・時期	2024年3月発表	正確	高	—	プレスリリース

この時点でユーザーに確認を取る：「この検証結果をもとに修正版の記事を作成してよいですか？」

---

ステップ4: 修正記事の作成

出力先の決定

Google DocsコネクタまたはWordファイル（.docx）で出力する。優先順位は以下の通り：

1. Google Docsコネクタが接続済み → Googleドキュメントに出力
2. Google Docsコネクタが未接続 → 接続を促す。ユーザーが接続しない場合、または接続に失敗した場合 → Wordファイル（.docx）で出力
3. いずれの場合も記事の品質基準は同一

記事作成ルール

story-writingスキル準拠

修正記事は以下のルールに従って作成する（story-writingスキルの原則）：

• 箇条書きの羅列ではなく、文章として流れる構成にする
• 冒頭で読者の関心を掴むフックから始める
• 具体例・数字・固有名詞を必ず交える
• 一文は60字程度を目安
• ナットグラフを記事冒頭10〜15%以内に配置
• ダイヤモンド型構成（逸話→文脈化→具体と抽象の往復→冒頭に回帰）
• 各セクション末尾にブリッジ文
• 見出しは結論・主張を含む具体的な文にする
• AI特有の報告書口調（「〜について述べる」「以下にまとめる」）を避ける
• 構成予告（「この記事ではXXについて解説します。まず…」）を使わない

フォーマットルール（Googleドキュメント向け）

以下のフォーマットルールを厳守する：

• マークダウン記法は一切使用しない（#、**、- などのマークダウン記号を本文に含めない）
• 見出しは 「見出し1」「見出し2」の2階層のみ を使用する
  • 見出し1: 記事タイトルおよび大セクション見出し
  • 見出し2: サブセクション見出し
  • 見出し3以降は使用しない
• 本文は「標準テキスト」（Normal text）
• 強調したい箇所は太字（bold）で表現する
• 段落間は改行で区切る

ファクト修正の反映

• 「不正確」と判定されたファクトは、corrected_sentence に置き換える
• 「部分的に正確」は、修正内容に基づいて文を修正する
• 「正確」「検証不能」は元のまま維持する
• 修正箇所が文脈に影響する場合は、前後の文も自然になるよう調整する

Googleドキュメントへの出力

Google Docsコネクタの使用

list_external_tools で Google Docs コネクタ（source_id: google_docs__pipedream）を確認する。

接続済みの場合：

1. describe_external_tools でGoogle Docsの利用可能なツールと入力スキーマを確認する
2. ドキュメント作成ツールを使って新規Googleドキュメントを作成する
3. 見出し1・見出し2・本文のスタイルを適用して記事を書き込む

未接続の場合：

1. connect ツールを呼び出してユーザーにOAuth認証を促す
2. 認証完了を待ってからドキュメント作成に進む

Wordファイル（.docx）での出力

Google Docsコネクタが利用できない場合、python-docx で .docx ファイルを作成する：

1. Heading 1 スタイルで見出し1を設定
2. Heading 2 スタイルで見出し2を設定
3. Normal スタイルで本文を設定
4. 太字の強調は run.bold = True で設定
5. マークダウン記号は一切含めない
6. ファイルを share_file でユーザーに共有する
7. ユーザーがGoogleドライブにアップロードしてGoogleドキュメントとして開ける旨を伝える
8. story-writing スキルの文章品質基準はGoogleドキュメント出力時と同一

出力ドキュメントの構成例

[見出し1] 記事タイトル

[本文] フック（問いかけ・意外な事実・エピソード）

[本文] ナットグラフ（何の話か・なぜ重要か・読む価値）

[見出し1] 大セクション見出し（結論・主張を含む文）

[本文] セクション本文...

[見出し2] サブセクション見出し

[本文] サブセクション本文...

[見出し1] 次の大セクション見出し

[本文] ...

[見出し1] 展望・締めの見出し

[本文] 冒頭に回帰し、読者への示唆で締める

---

エラーハンドリング

状況	対処
入力テキストが短すぎる（ファクトが抽出できない）	ユーザーにより詳細なテキストの提供を依頼する
サブエージェントがタイムアウト	該当ファクトを「検証不能」として記録し、続行する
全ファクトが「正確」と判定された	修正なしの旨を報告し、記事のリライトが必要か確認する
Google Docsコネクタ未接続	接続を促す。接続しない／失敗した場合はWordファイル（.docx）で出力

---

品質チェックリスト

ステップ4の出力前に以下を確認する：

• 全ての「不正確」ファクトが修正されているか
• 修正箇所が前後の文脈と自然に繋がっているか
• story-writingスキルの構成パターンに従っているか
• ナットグラフが冒頭10〜15%以内に配置されているか
• 各セクションに具体例・数字・固有名詞があるか
• 見出しが結論・主張を含む文になっているか
• マークダウン記号が一切含まれていないか
• 見出しが「見出し1」「見出し2」の2階層のみか
• AI特有の報告書口調になっていないか
• ドキュメントのリンクをユーザーに共有したか