コペルシステム株式会社AIに判断を委ねない。
意思決定の責任は、人に残す。
判断を人に残すAI
答えを出さない。
危険なときだけ、理由を示す。
監査と説明責任に耐える前提で設計する。
Signals（兆候）Why（理由）Evidence（証跡）ログで再構成
業務は、簡単には止められません
何かがおかしい気がする。けれど、止めるほどの確信もない。そんな場面は、どの企業にもあります。
- 誤検知で業務が止まる
- 確認時間が積み上がる
- 事故が起きたとき、説明を求められる
だからこそ必要なのは、誰かの仕事を奪うことではなく、判断の前に「危険の兆候」と「理由」を静かに揃えることです。
誤検知コスト・確認時間・説明コストは、最終的に現場責任者に残ります。
自動で決めない、という違い
違いは思想ではなく、仕様です。止めずに、判断材料を揃え、経緯を残します。
- 断定ラベルを出さない
- 遮断・隔離しない（既存ポリシーを上書きしない）
- 経緯をログで再構成できる
対象（拾いにいく）
- 危険の兆候（Signals）
- 理由（Why）と根拠の所在
- 後から再構成できる証跡（Evidence）
対象外（やらない）
- 遮断・隔離の強制（既存ポリシーの上書き）
- 断定ラベルでの結論提示
- 判断の責任移譲（人の承認を飛ばす）
絵空事ではなく、すでに形にしています
実装例
MailDoc（メールドック）
この考え方を、最初に形にした実装例です。危険の兆候と理由を示し、最終判断は人に残します。
ログに残すのは判断結果ではなく判断材料です（例：mail_id / signal_id / policy_version）。
ログに残す（最小セットの例）
mail_idmessage-id 等
signal_id検知要素のID
policy_version評価条件の版
evidence_refs根拠参照
この考え方を、もう少しだけ
まずは「なぜその設計にするのか」を短くまとめています。いま判断を迫りません。
よくある確認（要点のみ）
止めないと危なくないですか？
止める／止めないの判断は、人の権限に残します。ここで扱うのは、判断前に「兆候」と「理由」と「証跡」を揃えることです。
結局、何が残りますか？
判断結果ではなく、判断材料が残ります。後から経緯をログで再構成できる前提に寄せます。
既存の運用やポリシーと競合しますか？
遮断・隔離を強制しないため、既存のポリシーを上書きしません。判断の入口で材料を揃える形に寄せます。