doublecheck

Doublecheck

AI が生成した出力に対して、3 層の検証パイプラインを実行します。目的は、ユーザーに何が真実かを伝えることではなく、検証可能なすべての主張を抽出し、ユーザーが独立して確認できる情報源を見つけ、ハルシネーションのパターンと思われるものをすべて指摘することです。

有効化

Doublecheck は 2 つのモードで動作します: アクティブモード(常時)と ワンショットモード(オンデマンド)です。

アクティブモード

ユーザーが検証するテキストを指定せずにこのスキルを呼び出した場合は、永続的なダブルチェックモードを有効にします。次のように応答してください。

ダブルチェックが有効になりました。 回答を提示する前に、事実に関する主張を検証します。実質的な内容を含む回答の後には、インライン検証の概要が表示されます。詳細な出典を含む3層の完全な検証を希望する場合は、回答に「full report」と入力してください。「turn off doublecheck」と入力すれば、いつでも無効にできます。

その後、この会話の残りの間、以下のルールをすべて守ってください。

ルール：送信する前に、すべての回答を分類します。

実質的な回答を生成する前に、検証可能な主張が含まれているかどうかを判断し、回答を分類してください。

回答の種類	検証可能な主張を含むか	対応
事実分析、法的助言、規制の解釈、コンプライアンスに関するガイダンス、判例引用または法令の参照を含む内容	はい――高密度	完全な検証レポートを実施します（以下の高リスク内容のルールを参照）
文書、調査、データの要約	はい――中程度の密度	重要な主張をインラインで検証します
コード生成、創作、ブレインストーミング	まれ	検証を省略します。この種の内容にはダブルチェックモードが適用されないことを明記します
カジュアルな会話、確認の質問、進捗報告	いいえ	何もせずに省略します

ルール：アクティブモードではインライン検証を行います。

アクティブモードが適用される場合、回答ごとに個別の完全な検証レポートを生成してはいけません。代わりに、次の形式で検証内容を回答に含めてください。

1. 通常どおり回答を作成します。
2. 回答の後に Verification セクションを追加します。
3. 検証可能な主張をそれぞれ、確信度と、該当する場合はソースリンクとともに列挙します。

形式：

---
**Verification (N claims checked)**

- [VERIFIED] "Claim text" -- Source: [URL]
- [VERIFIED] "Claim text" -- Source: [URL]
- [PLAUSIBLE] "Claim text" -- no specific source found
- [FABRICATION RISK] "Claim text" -- could not find this citation; verify before relying on it

アクティブモードでは速度を優先してください。引用、具体的な統計、確信度の低い主張については、ウェブ検索で出典を確認してください。一般常識である主張や、確信度が高い主張については、検索する必要はありません。「PLAUSIBLE」と評価して先に進んでください。

主張の評価が「DISPUTED」または「FABRICATION RISK」の場合は、検証セクションの前に、ユーザーがすぐに気づくよう目立つ形でその旨を指摘してください。自動エスカレーションが適用される場合は（以下を参照）、完全なレポートの冒頭に、要約表より前にこの注意喚起を記載してください。

**Heads up:** I'm not confident about [specific claim]. I couldn't find a supporting source. You should verify this independently before relying on it.

ルール：リスクの高い検証結果は自動的に完全なレポートに切り替えます。

インライン検証で「DISPUTED」または「FABRICATION RISK」と評価された主張が1つでも見つかった場合は、インライン検証を行わないでください。回答の冒頭に「ご注意ください」の注意喚起を記載したうえで、assets/verification-report-template.md のテンプレートを使用して、3層の完全な検証レポートを作成してください。明らかに誤っている内容がある場合、ユーザーが詳細なレポートを求めなくても提示する必要があります。

ルール：リスクの高い内容には完全なレポートを使用します。

回答に法的分析、規制の解釈、コンプライアンスに関するガイダンス、判例引用、または法令の参照が含まれる場合は、必ず assets/verification-report-template.md のテンプレートを使用して完全な検証レポートを作成してください。こうした内容には簡略版のインライン検証を使用しないでください。リスクが高すぎるためです。

ルール：インライン検証では、追加情報の案内を付けます。

インライン検証を行う場合（完全なレポートではない場合）は、検証セクションの最後に必ず次の行を追加してください。

_Say "full report" for detailed three-layer verification with sources._

ルール：求められたら完全な検証を提示します。

ユーザーが「full report」「run full verification」「verify that」「doublecheck that」または同様の表現を使った場合は、以下で説明する3段階の完全な検証手順を実施し、assets/verification-report-template.md のテンプレートを使用して完全なレポートを作成してください。

ワンショットモード

ユーザーがこのスキルを呼び出し、検証する具体的なテキストを提示した場合（または以前の出力を参照した場合）は、3 層からなるパイプライン全体を実行し、assets/verification-report-template.md のテンプレートを使用して完全な検証レポートを作成します。

無効化

ユーザーが「turn off doublecheck」「stop doublecheck」などと指示した場合は、次のように応答します。

Doublecheck is now off. インライン検証を行わず、通常どおり応答します。いつでも再び有効にできます。

---

レイヤー 1：セルフ監査

対象のテキストを批判的な視点で読み直します。このレイヤーでは、主張の抽出と内部分析を行います。まだウェブ検索は行いません。

ステップ 1：主張を抽出する

対象のテキストを文ごとに確認し、検証可能な内容を述べている箇所をすべて抽出します。各主張を分類します。

カテゴリー	確認する内容	例
事実	物事の現状や過去についての断定	「Python は 1991 年に作成されました」「GPL は派生物のオープンソース化を義務付けています」
統計	数値、割合、数量	「企業の 95％がクラウドサービスを利用しています」「契約には 30 日間の解約条項があります」
引用	特定の文書、判例、法律、論文、規格への言及	「CDA 第 230 条に基づき……」「Mayo v. Prometheus（2012 年）では……」
固有名詞	特定の人物、組織、製品、場所についての主張	「OpenAI は Sam Altman と Elon Musk によって設立されました」「GDPR は EU 居住者に適用されます」
因果関係	X が Y を引き起こした、または X が Y につながるという主張	「この脆弱性によりリモートコード実行が可能になります」「この規制は 2008 年の金融危機を受けて制定されました」
時間	日付、期間、出来事の順序	「期限は 3 月 15 日です」「バージョン 2.0 はセキュリティパッチより前にリリースされました」

後続のレイヤーで追跡できるよう、各主張に仮 ID（C1、C2、C3 など）を割り当てます。

ステップ 2：内部整合性を確認する

抽出した主張を相互に照合します。

• テキスト内に矛盾はありませんか？（例：同じ出来事について異なる日付が 2 つ記載されている）
• 論理的に両立しない主張はありませんか？
• あるセクションでの前提が、別のセクションで矛盾していませんか？

内部矛盾があれば、すぐに指摘します。問題の特定に外部検証は必要ありません。

ステップ 3：初期の確信度評価

各主張について、自分の知識だけを基に初期評価を行います。

• 正確な内容だと記憶していますか？
• モデルが幻覚を起こしやすい種類の主張ですか？（具体的な引用、正確な統計、厳密な日付はリスクが高い項目です。）
• 検証できるほど具体的ですか。それとも、反証不可能なほど曖昧ですか？

初期の確信度を記録しますが、まだ調査結果として報告してはいけません。これはレイヤー 2 で使用する情報であり、出力には含めません。

---

レイヤー 2：情報源による検証

抽出した各主張について、外部の根拠を検索します。このレイヤーの目的は、ユーザーが自分で主張を検証できる URL を見つけることです。

検索方法

各主張について、次の手順を実行します。

1. 一次情報が見つかる検索クエリを作成します。 引用の場合は、正確なタイトルまたは判例名を検索します。統計の場合は、具体的な数値とトピックを検索します。事実に関する主張の場合は、主要な固有名詞と関係性を検索します。

2. web_search を使用して検索を実行します。最初の検索で関連する結果が得られなければ、別の語句でクエリを作り直し、もう一度試します。

3. 見つかった情報を評価します。

   • 主張を直接扱う一次情報源または信頼できる情報源が見つかりましたか？
   • 信頼できる情報源から、矛盾する情報が見つかりましたか？
   • 関連する情報が見つかりませんでしたか？（これ自体が兆候となります。実在する事柄なら、通常はウェブ上に情報が見つかります。）

4. 情報源の URL とともに結果を記録します。 情報源の内容を要約する場合も、必ず URL を記載してください。

ソースとして認められるもの

一次資料および権威ある情報源を優先してください。

• 公式ドキュメント、仕様、規格
• 裁判記録、立法文書、規制当局への提出書類
• 査読済みの刊行物
• 公式の組織ウェブサイトおよびプレスリリース
• 定評ある参考資料（百科事典、法律データベース）

情報源が二次資料（ニュース記事、ブログ記事、Wikiページ）か一次資料かを明記してください。ユーザーはそれに応じて重み付けできます。

引用の具体的な扱い

引用は、幻覚が起きるリスクが最も高い項目です。特定の判例、法令、論文、規格、文書を引用する主張については、次の手順に従ってください。

1. 正確な引用情報（判例名、タイトル、条項番号）を検索します。
2. 見つかった場合は、引用された内容が、対象の文章で述べられていることを実際に示しているか確認します。
3. まったく見つからない場合は、捏造のリスクとして明記します。モデルは、もっともらしいものの、実在しない引用を頻繁に生成します。

---

レイヤー 3：敵対的レビュー

姿勢を完全に切り替えてください。レイヤー 1 と 2 では、出力を理解して検証しようとしていました。このレイヤーでは、出力には誤りがあると想定し、積極的に誤りを探します。

幻覚パターンのチェックリスト

次のよくあるパターンを確認してください。

1. 引用の捏造 -- レイヤー 2 で見つけられなかった特定の判例、論文、法令を文章が引用している。権威があるように見えるため、これは最も危険な幻覚パターンです。

2. 出典のない具体的な数値 -- 数値の出典を示さずに、文章が具体的な統計（例：「企業の 78％が……」）を述べている。モデルは、もっともらしく聞こえるものの、まったくの作り話である統計を生成することがあります。

3. 不確かな話題についての断定的で具体的な記述 -- 実際には詳細が不明、または議論の余地がある話題について、文章が非常に具体的な内容を述べている。専門家の間で意見が分かれる分野では、正確な日付、具体的な金額、断定的な帰属に注意してください。

4. もっともらしいが誤った関連付け -- 文章が概念、判決、出来事を誤った主体と関連付けている。たとえば、判決を誤った裁判所に帰属させる、引用を誤った人物のものとする、法令名は正しいものの条文の内容を誤って説明する、といった例です。

5. 時系列の混同 -- 文章が、古くなっている可能性のある情報を現行のものとして説明している、または出来事の順序を誤って説明している。

6. 過度な一般化 -- 特定の法域、状況、期間に限って当てはまることを、文章が普遍的に真実であるかのように述べている。法律や規制に関する内容でよく見られます。

7. 限定条件の欠落 -- 重大な例外、制約、反論があるにもかかわらず、文章が複雑な話題を確定事項または単純なものとして提示している。

敵対的な問い

レイヤー 1 と 2 を通過した主要な主張ごとに、次の問いを投げかけてください。

• この主張が誤りであるとしたら、どのような理由が考えられますか？
• この分野に、モデルが取り込んでいる可能性のあるよくある誤解はありますか？
• この分野の専門家なら、この表現に異議を唱えるでしょうか？
• この主張は学習データのカットオフより前の情報ですか、それとも後の情報ですか。また、古くなっている可能性はありますか？

報告で特に明記すべき危険信号

次のいずれかが見つかった場合は、報告で目立つように明記してください。

• どこにも見つからない特定の引用
• 特定可能な出典のない統計
• 権威ある情報源の記述と矛盾する法律または規制に関する主張
• 高い確信をもって述べられているものの、実際には議論の余地がある、または不確かな主張

---

検証レポートの作成

3 つのレイヤーすべてを完了した後、assets/verification-report-template.md のテンプレートを使用してレポートを作成してください。

確信度評価

各主張に最終評価を付けます。

評価	意味	ユーザーが行うべきこと
VERIFIED	裏付けとなる情報源が見つかり、リンクされています	その主張が作業上重要な場合は、情報源のリンクを抜き取り確認してください
PLAUSIBLE	一般的な知識と一致していますが、具体的な情報源は見つかっていません	妥当ではあるものの未確認として扱い、意思決定の根拠にする場合は独自に検証してください
UNVERIFIED	裏付けとなる証拠も反証となる証拠も見つかりませんでした	独自に検証せずに、この主張を根拠として使用しないでください
DISPUTED	信頼できる情報源から反証となる情報が見つかりました	反証となる情報源を確認してください。この主張は誤っている可能性があります
FABRICATION RISK	幻覚のパターン（例：見つからない引用、出典のない詳細な統計）に一致しています	一次情報源で確認できるまでは、誤りだと想定してください

報告の原則

• 断定ではなく、リンクを提示してください。何が正しいかはユーザーが判断します。
• 矛盾する情報が見つかった場合は、両方の見解を情報源とともに示してください。どちらか一方を選ばないでください。
• 主張が反証不能（曖昧すぎる、または主観的すぎて検証できない）場合は、その旨を伝えてください。「反証不能」は有用な情報です。
• 確認できなかった内容を明示してください。「検証できなかった」ことと「誤りである」ことは異なります。
• 重要度別に調査結果をまとめてください。最も注意が必要な項目から提示してください。

制限事項の開示

レポートの最後には、必ず次の内容を含めてください。

この検証の制限事項：

• このツールは人による検証を迅速化するものであり、それに代わるものではありません。
• ウェブ検索の結果には、最新情報や有料記事が含まれない場合があります。
• 対抗的レビューには、元の出力を生成した可能性のあるものと同じ基盤モデルが使用されています。多くの問題を検出できますが、すべてを検出できるわけではありません。
• VERIFIED と評価された主張は、裏付けとなる情報源が見つかったことを意味するだけで、主張が確実に正しいことを意味しません。情報源も誤っている場合があります。
• PLAUSIBLE と評価された主張も、誤っている可能性があります。反証となる情報がないことは、正確である証拠にはなりません。

---

分野別のガイダンス

法律に関する内容

法律に関する内容は、次の理由から、幻覚が生じるリスクが特に高くなります。

• モデルが判例名、引用、判示内容を捏造することがよくあります
• 法域ごとの細かな違いが単純化されたり、省略されたりすることがよくあります
• 法令の文言を言い換える際に、法的な意味が変わることがあります
• 「多数説」と「少数説」の区別が失われることがよくあります

法律に関する内容では、判例の引用、法令への言及、規制の解釈、法域に関する主張を特に注意深く確認してください。可能であれば、法律データベースを検索してください。

医療・科学に関する内容

• 引用されている研究が実際に存在すること、またその結果が正確に説明されていることを確認してください
• 古いガイドラインが現行のものとして提示されていないか注意してください
• 用量、治療手順、診断基準は変更されるため、誤りが危険につながる可能性があることに留意してください

金融・規制に関する内容

• 金額、日付、基準値を確認してください
• 規制要件が正しい法域に帰属され、現行のものであることを確認してください
• 最近の法改正により古くなっている可能性のある税法上の主張に注意してください

技術・セキュリティに関する内容

• CVE 番号、脆弱性の説明、影響を受けるバージョンを確認してください
• API 仕様と設定手順が最新のドキュメントと一致していることを確認してください
• バージョン固有の情報が古くなっていないか注意してください