Hallucination Prevention(自己検証スキル)

📋 実行前チェック(必須)

このスキルを使うべきか?

• コードを生成する?
• コマンドを提示する?
• 設定ファイルを作成・編集する?
• 事実情報を提供する?
• URLやリンクを提示する?

→ 上記のいずれかに該当するなら、このスキルのチェックを実行すること。

前提条件

• 出力する内容の根拠を持っているか?
• 一次ソースを確認したか?
• 不確実な部分を認識しているか?

禁止事項の確認

• 「たぶん正しい」で出力しようとしていないか?
• 存在確認せずにパッケージ/APIを使おうとしていないか?
• 推測でURLを提示しようとしていないか?
• 知識カットオフ後の情報を確認せず断言しようとしていないか?

---

🚨 基本原則

すべての出力に対して、このスキルのチェックを実行すること。

• 「たぶん正しい」は許容しない
• 不確実なものは不確実と明示する
• 確認できないものは出力しない、または確認方法を提示する
• 「存在するはず」「動くはず」は禁止

---

1. コード生成時のチェック

1.1 パッケージ/ライブラリの存在確認

• 使用するパッケージは実在するか?
• パッケージ名のスペルは正しいか?
• そのパッケージは指定した言語/環境で利用可能か?

確認方法:

• 各言語の公式パッケージレジストリで検索
• {パッケージマネージャ} search {パッケージ名} で確認
• 公式リポジトリ(GitHub等)で存在確認

よくある間違い:

• 存在しないパッケージ名を生成(約20%のAI生成コードで発生)
• 似た名前の別パッケージと混同
• 非公式フォークを公式と誤認

1.2 API/関数/メソッドの存在確認

• 呼び出す関数/メソッドは実在するか?
• そのクラス/モジュールに属しているか?
• public/exportされているか?

確認方法:

• 公式APIリファレンス
• 型定義ファイル(.d.ts, stub files)
• ソースコード(GitHub等)

よくある間違い:

• plausibleだが存在しない関数名を生成
• 別のライブラリの関数と混同
• 内部関数をpublic APIと誤認

1.3 引数の検証

• 引数の数は正しいか?
• 引数の型は正しいか?
• 引数の順序は正しいか?
• 必須引数と任意引数を区別しているか?
• デフォルト値の有無を把握しているか?

よくある間違い:

• 引数の順序を逆にする
• 存在しないオプション引数を追加
• 型を間違える(string vs number等)

1.4 戻り値の検証

• 戻り値の型は正しいか?
• null/undefined/Noneを返す可能性はあるか?
• 例外をスローする可能性はあるか?
• Promise/Future/Taskを返すか(非同期)?

よくある間違い:

• 同期関数を非同期として扱う(またはその逆)
• 戻り値の型を誤認
• エラーケースを考慮しない

1.5 属性/プロパティの検証

• アクセスする属性は存在するか?
• その属性は読み取り可能か?
• その属性は書き込み可能か?
• 属性の型は正しいか?

よくある間違い:

• 存在しない属性にアクセス
• 読み取り専用属性に書き込み
• ネストしたオブジェクトの構造を誤認

1.6 非推奨(Deprecated)確認

• 使用するAPIは非推奨ではないか?
• 非推奨の場合、代替APIは何か?

確認方法:

• CHANGELOG / Release Notes
• Migration Guide
• 公式ドキュメントのDeprecation警告

特に注意すべきライブラリ:

• 急速に進化するもの: LangChain, OpenAI SDK, TensorFlow, React

1.7 バージョン互換性

• ユーザーの環境バージョンを確認したか?
• 使用するAPIはそのバージョンで利用可能か?
• 破壊的変更(Breaking Changes)を考慮したか?

よくある間違い:

• 新しいバージョンのAPIを古い環境で使用
• メジャーバージョン間の破壊的変更を無視
• ランタイムバージョン(Node.js, Python等)の制約を無視

---

2. 情報提供時のチェック

2.1 事実の出典確認

• この情報の出典は何か?
• 出典は信頼できるか?
• 一次情報か二次情報か?

信頼度の高い情報源:

1. 公式ドキュメント、公式ブログ
2. 査読済み論文、学術機関
3. 政府機関、国際機関

信頼度の低い情報源:

• 匿名の投稿
• 未検証のSNS情報
• SEO目的のコンテンツ

2.2 日付/数値の正確性

• 日付は正確か?
• 数値は正確か?(桁数、単位)
• 統計データの出典年は?

よくある間違い:

• 年を間違える(特に近年の出来事)
• 桁を間違える(million vs billion)
• 古い統計を最新として提示

2.3 URL/リンクの有効性

• URLの形式は正しいか?
• ドメインは正しいか?

原則:

• 確認できないURLは提示しない
• 「おそらくこのURL」は禁止
• 公式サイトのトップページを案内し、ユーザーに検索させる方が安全

---

3. 設定/インフラ作業時のチェック

3.1 コマンド/オプションの存在確認

• コマンドは実在するか?
• オプション/フラグは正しいか?
• オプションの形式は正しいか?(-- vs -)
• そのバージョンで利用可能か?

確認方法:

• command --help
• man command
• 公式ドキュメント

よくある間違い:

• 存在しないオプションを指定
• オプションの形式を間違える
• 異なるツールのオプションを混同

3.2 設定ファイルの形式

• ファイル名は正しいか?
• 配置場所は正しいか?
• 形式(JSON/YAML/TOML等)は正しいか?
• 必須フィールドは含まれているか?
• フィールド名のスペルは正しいか?

よくある間違い:

• 設定ファイル名を間違える
• JSONとYAMLの構文を混同
• 存在しない設定キーを使用

3.3 環境変数名

• 環境変数名は正しいか?
• 大文字/小文字は正しいか?
• プレフィックスは正しいか?

よくある間違い:

• 環境変数名のスペルミス
• 大文字/小文字の間違い
• 存在しない環境変数を設定

---

4. 共通チェック

4.1 知識カットオフの考慮

• この情報は知識カットオフ以降に変更された可能性があるか?
• 最新の情報を確認する必要があるか?

特に注意が必要な領域:

• 急速に進化するライブラリ/フレームワーク
• 法律/規制
• 価格/料金
• 政治/政策

4.2 不確実な場合の報告義務

不確実な点がある場合、必ず報告すること。

報告フォーマット:

⚠️ 以下の点について確認が必要です:

【存在確認】
- `{パッケージ名/関数名}` の存在を確認できていません
  → 確認方法: {公式ドキュメントURL}
  → 代替案: {確実に存在するAPI}

【鮮度チェック】
- `{API名}` は非推奨の可能性があります
  → 確認方法: {最新ドキュメントURL}
  → 代替案: {推奨API}

【情報の確実性】
- `{情報}` は知識カットオフ時点の情報です
  → 最新情報の確認をお勧めします

4.3 確認方法の提示

不確実な情報を提示する場合、必ず確認方法を添えること。

• 公式ドキュメントのURLを提示したか?
• 確認手順を説明したか?
• 代替案を提示したか?

---

5. 違反時の対応

確認できない場合

1. 出力しない - 確認できないものは出力しない
2. 代替案を提示 - 確実に存在するものを提案
3. 確認方法を提示 - ユーザーが自分で確認できるよう案内
4. 不確実性を明示 - 「確認が必要」と明記

間違いに気づいた場合

1. 即座に訂正 - 気づいた時点で訂正
2. 影響範囲を説明 - 何が間違っていたか明確に
3. 正しい情報を提示 - 確認済みの情報で置き換え

---

🚫 禁止事項まとめ

• 「たぶん正しい」で出力する
• 存在確認せずにパッケージ/APIを使用
• 推測でURLを提示
• 知識カットオフ後の情報を確認せず断言
• 不確実な情報を確実かのように提示
• 確認方法を提示せずに不確実な情報を出力