verifiable-trust

検証可能な信頼

AI の作業を独立して検証し、失敗した場合の影響を限定できない限り、失ってもよいと思える範囲を超えて、時間、データ、金銭を AI に委ねてはいけません。

簡潔に言えば、AI の作業を検証できる範囲、または失敗しても許容できる範囲でのみ、AI を信頼してください。

これは出力とアクションの両方に等しく当てはまります。検証可能なコードでも、無制限の実行が安全になるわけではありません。読み取り専用の作業でも、時間を浪費したり、データを漏えいさせたり、誤った結論を導き出したりする可能性があります。

ルール

1. 独立して検証できるように設計する。 コンパイラー、有意義なテスト、静的解析、観察された動作、範囲を限定した比較、信頼できる情報源など、客観的にテスト可能な出力を優先してください。結果に依存する前に、検証方法を計画します。
2. AI の自信は検証ではありません。 自己評価、別のモデルとの一致、あるいは生成された前提をなぞるテストでは、要件に照らした正しさを独立して確認できません。
3. リスクにさらされる範囲を限定する。 時間、再試行回数、トークンや API の費用、データアクセス、権限、変更範囲、本番環境への潜在的な影響を制限します。必要最小限の権限と費用を使います。
4. 元に戻せるアクションを優先する。 影響の大きさに応じて、ブランチ、使い捨てのサンドボックス、段階的なロールアウト、バックアップ、検証済みの復旧手段を利用します。永続的なデータ削除は、コードがユニットテスト済みでも高リスクです。
5. 損失に応じて厳密さを調整する。 小さなドキュメントの編集に大がかりな手順は不要ですが、認証情報、破壊的なマイグレーション、本番インフラ、金融取引には、より強力なチェック、限定された権限、場合によっては明示的な承認が必要です。
6. 根拠と限界を報告する。 実際に確認できたことと前提を区別し、テストされていない失敗パターンと残存リスクを開示します。

判断のループ

AI の成果物を信頼したり、アクションを実行したりする前に、次の点を確認します。

• 正確性： 何が間違っている可能性がありますか？ 作業を行ったエージェントから独立した、どのような根拠で誤りを検出できますか？
• 権限： エージェントは何を読み取り、変更、削除、実行できますか？ アクセスをさらに限定できますか？
• リスク： 失敗した場合、時間、金銭、データをどれほど失う可能性がありますか？
• 復旧： 停止、ロールバック、復元は可能ですか？ 必要な場合、その手段は検証済みですか？
• 承認： 実行は明示的に承認された範囲内ですか？ 後戻りできない、費用がかかる、または機密性の高い境界を越える場合は、そのアクションの前に承認を得てください。

すでに承認されている範囲内では、制限を設けた作業を進めてください。日常的な編集のたびに、繰り返し承認を求める必要はありません。

実践例

状況	リスクに応じた安全対策
README や、元に戻せる小さなコード編集	差分の確認、関連するフォーマットチェックやテスト。
機能の実装	要件に沿った成功・失敗テスト、ビルド／リント、重要な契約のレビュー、範囲を限定したブランチ。
不慣れな依存関係	有用性、互換性、利用をやめる際のコストを評価し、採用前に承認を求める。
認証、シークレット、個人データ	最小権限を適用し、トークンを出力せず、重大な実行の前に強力なテストとレビューを行う。
破壊的なスキーマ／データマイグレーション	代表的な使い捨てデータでテストし、影響を受けるレコードを確認し、本番環境での実行前にバックアップ／復元と承認を確認する。
本番環境または有料インフラ	計画／差分、影響範囲、費用を確認し、可能な場合は段階的に実施し、重大または取り消せないアクションには明示的な承認を得る。
自律的な調査または委任されたエージェント	呼び出し回数、再試行回数、トークン予算、範囲を制限し、同じ失敗が繰り返されたら停止して根拠を確認する。

検証の品質と安全策

• 生成された実装だけでなく、要件と外部から観測可能な動作を検証してください。テストに合格しても、そのテスト対象についてしか証明されません。
• AI によるレビューは間違いの発見に役立ちますが、独立した受け入れ基準や観測されたシステムの動作、重大な変更に対する人間の判断に取って代わるものではありません。
• ドライランは有用ですが、実際の副作用や環境を再現しているかを確認してください。
• 成功させるために、権限、サンドボックスの制限、承認、認証、TLS 検証を決して回避しないでください。
• ログやレポートに、シークレット、機密設定、トークン、個人データを漏らさないでください。
• 独立した検証が現実的に不可能で、リスクが許可または許容される範囲を超える場合は、重大な操作を行う前に停止し、不確実性を明らかにして、適切な承認を求めてください。
• 意味のある証拠と判断をリポジトリやタスクの成果物に記録し、形式的なチェックリストは避けてください。

保守性と検証可能性を備えた設計には engineering-principles を、スタックの選択には tech-preferences を使用してください。このスキルが扱うのは、技術選定ではなく信頼と自律性です。