← Back to Index

predictability-gate

AIに「判断させない」ための運用上の境界定義

このリポジトリは、
AIモデルを作り始める前に、

その判断を AI に委ねてよいかどうか

を決めるための、
運用上の Gate（関門）を記録したものです。

これはプロダクトではありません。
フレームワークでもありません。
ベストプラクティスでもありません。

責任・安全・予測可能性が保証できない場合に、
AI の判断を止めるための運用構造です。

これは何か（What this is）

predictability-gate は、実務の中で使われている
事前判定用の意思決定ゲートです。

問いは一つだけです。

この判断を、AI に委ねてよいか？

この Gate は、次のような状況を防ぐために存在します。

  • 技術的にはモデルが作れる
  • 精度もそれなりに出ている
  • しかし 一度の誤判定が、取り返しのつかない結果を招く

本リポジトリは
モデルを良くするための資料ではなく、
判断を止めるための構造を扱います。

これは何ではないか（What this is NOT）

  • ❌ 機械学習フレームワーク
  • ❌ AIガバナンス標準
  • ❌ コンプライアンスチェックリスト
  • ❌ 安全性を保証するもの

このリポジトリは
万能性や完全性を主張しません。

あくまで、
現実の責任を背負う現場で使われた一つの構造例です。

基本原則（Core principles）

Predictability Gate は、次の原則を前提とします。

  1. 精度よりも責任を優先する
  2. 「当たるか」より「外したらどうなるか」を問う
  3. 不可逆な見逃しは、AIに委ねてはならない
  4. 最終判断は、必ず人が引き受ける

これらが満たせない場合、
正しい結論は「使わない」ことです。

適用範囲（Scope）

本 Gate は、主に
数値時系列データを扱う AI 案件を対象としています。

以下を主要判断軸とする案件は、
意図的に 別プロジェクト として分離します。

  • 音
  • におい
  • 画像
  • 人の感覚・勘・経験

これらを早期に混在させないことは、
安全と成功確率のための意図的な設計です。

本リポジトリでは、Gate 定義の前に
なぜこの境界が必要になったのか（失敗パターン） を明示します。

Gate の構成（Structure）

Predictability Gate は、
48〜72時間以内に以下の観点で評価されます。

Gate 項目

  • G1：情報量
    数値時系列に、予測に足る情報が含まれているか
  • G2：業務許容下限
    誤判定時に
    「安全側に倒れる」「判断保留できる」逃げ道があるか
  • G3：時序整合
    時系列 CV やシャッフル検証により、リークがないか
  • G4：代理変数の可能性
    ラグ・滞留・比率・ロールアップ等で改善余地があるか
  • G5：現場依存度＋不可逆性（最優先）
    見逃しが、安全・品質・法規・資産に対して
    不可逆な影響を与えないか
  • G6：ROI（概算）
    便益と運用コストのバランスが取れているか
G5 は他のすべてに優先します。
見逃しが不可逆な場合、この案件は採用されません。

判定結果（Outcomes）

Gate の結果は、次のいずれかになります。

  • 進める
    → シャドー運用や A/B テストへ
  • 限定パイロット
    → 限定範囲での検証とデータ改善
  • やめる
    → 予測可能性または価値が不足
  • 別案件化
    → 非構造データ／人判断前提の専用ルートへ

責任の所在（Responsibility）

Predictability Gate は、
自動承認の仕組みではありません。

最終的な判断は、
運用責任者が Gate 結果を確認した上で行います。

これは次の立場表明です。

AI は責任を取らない。
責任を取るのは人間である。

他の概念との関係

このリポジトリは、
境界と責任を扱う一連の思想とつながっています。

  • idk-lamp
    AI が「分からない」と止まるための象徴
  • VCDesign / BOA / RP
    責任と境界を設計するための思想群

predictability-gate は、
それらを 運用の現場で実体化した場所です。

利用について（Usage philosophy）

このリポジトリは自由に参照できます。

  • 読んでもよい
  • 参考にしてもよい
  • 使わなくてもよい

ただし、

適用した結果についての責任は、
利用者自身が引き受けるものとします。

保証はありません。
サポート義務もありません。

なぜ公開するのか（Why public）

なぜなら、

AI を作る方法は無数にあるが、
AI を「使わない」と判断する方法は
ほとんど共有されていない

からです。

これは、その空白を
明示的な構造として残す試みです。

ステータス（Status）

このリポジトリは、意図的に最小構成です。

更新されるかもしれません。
更新されないかもしれません。

どちらも問題ありません。

著者メモ

これは正解集ではありません。
AI を止めるという判断を、
現場で壊れない形に固定した記録です。

合わなければ使わなくて構いません。
それでも「ここに境界がある」ことには意味があります。

Context

このプロジェクトは、AIが判断を止め、
人間の責任へと委ねるべき境界を可視化するための
実践的なシグナルとして設計されています。

この取り組みは、AI支援システムにおける
設計・責任・境界のあり方を探究する
設計思想 VCDesign から生まれました。

本リポジトリは単体でも利用・理解できます。
事前知識は必要ありません。

1. Failure Cases

Predictability Gate が存在する理由

この文書が最初にあるのには理由があります。
Predictability Gate は、これらの失敗から学んで設計されました。

この文書は、詳細な事故レポートやポストモーテムではありません。

深刻な事故、品質低下、信頼の喪失が起きる前に、
繰り返し現れる 失敗のパターン を記録したものです。

これらのケースは なぜ predictability-gate が存在するのか を説明します。

Case 1 — 精度は良かったが、責任が未定義だった

状況

  • 数値時系列モデルが許容できる精度を達成した
  • 検証メトリクスも内部基準を満たしていた
  • 導入へのプレッシャーが高かった

何が起きたか

  • 停止・介入（Override） のオーナーが不在だった
  • 予測が外れたとき、エスカレーションが遅れた
  • 「モデルがそう言っているから」という理由でシステムが稼働し続けた

なぜ Gate なら防げたか

  • G2（業務許容下限） を満たしていない
    安全なフォールバックや、判断の留保が存在しなかった。
  • G5（責任と不可逆性） が不明確だった。

教訓

責任なき精度は、静かな失敗を生む。

Case 2 — 非構造化シグナルを早く混ぜすぎた

状況

  • 数値データに、音声や画像の特徴量を追加した
  • 全体的なモデル精度は向上した
  • ランダムな交差検証（CV）で評価が行われた

何が起きたか

  • 失敗モードが観測不可能になった
  • 時間的なリークが、混合された特徴量によって隠蔽された
  • デプロイ後に初めて劣化が発覚した

なぜ Gate なら防げたか

  • 適用範囲（Scope）の分離ルール に違反している
  • G3（時序整合） が正しく検証できなかった

教訓

ドメインを混ぜることは、性能を上げる前に「失敗モード」を隠してしまう。

Case 3 — 一度の予測ミスが取り返しのつかない損害を生んだ

状況

  • 誤検知（False Positive）は管理可能だった
  • 見逃し（False Negative）は「確率的に低い」とされた
  • 明示的な不可逆性チェックは行われなかった

何が起きたか

  • たった一度の見逃しが以下を招いた：
    • 安全事故
    • 品質流出
    • 法的違反
  • ロールバック（取り消し）が不可能だった

なぜ Gate なら防げたか

  • G5 Override
    予測の見逃しが 不可逆 であるため。

教訓

確率が低くても、不可逆なリスクは減らない。

Case 4 — パイロット範囲が静かに拡大した

状況

  • 限定的なパイロットとして始まった
  • 「うまくいっているから」という理由で徐々に拡大した
  • 正式な再承認ステップが存在しなかった

何が起きたか

  • 条件が、評価された範囲の外に変わった
  • 性能が静かに劣化した
  • 損害が発生するまで誰も気づかなかった

なぜ Gate なら防げたか

  • 限定パイロットルール により、再評価が求められたはず
  • 影響半径 が明示的に定義されていなかった

教訓

Gate なき拡大は、制御不能なデプロイである。

Case 5 — システムを止められなかった

状況

  • 自動化された判断が業務に組み込まれた
  • 手動介入は手順書の上にしか存在しなかった

何が起きたか

  • オペレーターが介入を躊躇した
  • システムを止めることが、社会的・手続き的に困難だった
  • 時間とともに損害が蓄積した

なぜ Gate なら防げたか

  • 停止権限に関する 前提条件チェック で落ちていたはず

教訓

止められないシステムは、その時点で安全ではない。

全ケースに共通するパターン

すべてのケースにおいて：

  • モデルは 技術的には妥当 だった
  • 失敗は 組織的・運用的 なものだった
  • 責任の境界が不明確だった

Predictability Gate は、モデルを作り始める 前 に
これらの問題を表面化させるために存在します。

重要な注意

これらのケースは意図的に抽象化されています。

これらは以下ではありません：

  • 事故報告書
  • 責任追及
  • 完全な全史

これらは 認識パターン です。

もしこれらのケースに見覚えがあるなら、
正しい対応は モデルを最適化することではなく、
AI に判断させるべきかを再考すること です。

2. Overview

Predictability Gate とは

Predictability Gate は、運用上の意思決定境界 です。

モデルが作られる前に、たった一つの問いに答えるために存在します。

この判断を、AI に委ねてよいか？

このゲートはモデルを最適化するものではありません。
誤った予測による不可逆な失敗を防ぐ ためのものです。

主な特徴：

  • 48〜72時間 以内に実行される
  • PoC やモデリングの 前に 適用される
  • 精度ではなく責任 に焦点を当てる
  • 明示的に 「進めない」という判断 を許可する

Predictability Gate はブロッカーではありません。
運用、人、そして信頼を守るための 安全境界（Safety Boundary） です。

文脈とルーツ

このゲートは孤立したアイデアではありません。
境界と責任に関する長期的な思考から生まれた、運用上の成果物です。

なぜこれらの境界が必要なのか を理解したい場合は、以下を参照してください：

3. Gate Definition

Predictability Gate は、6つの評価項目（G1–G6）で構成されます。

G1 — 情報量（Information Content）

数値時系列データに、予測に足る十分なシグナルが含まれているか？

典型的な指標：

  • ターゲットのエントロピー
  • 相互情報量の総和（上位特徴量）

G2 — 業務許容下限（Business Tolerance）

予測が外れたときに、運用上の「逃げ道」があるか？

例：

  • 安全側へのフォールバック
  • 判断の保留（Deferral）
  • 人間による確認

G3 — 時序整合（Temporal Consistency）

時間を考慮した検証下でも、結果は妥当か？

チェック項目：

  • 時系列交差検証（Time-series cross validation）
  • シャッフルによる劣化確認
  • リークの疑い

G4 — 代理変数の可能性（Proxy Feature Potential）

代理変数を使って改善する余地があるか？

例：

  • ラグ特徴量
  • 滞留時間（Dwell time）
  • 比率
  • ロールアップ

G5 — 現場依存度＋不可逆性（Override）

見逃し（Miss） が不可逆な損害を引き起こすか？

Yes の場合：

このケースは数値時系列 AI で扱ってはならない。

G5 は他のすべての項目に優先します（Override）。

G6 — 概算 ROI（Rough ROI）

期待される便益は、運用コストに見合うか？

これは大まかなチェックであり、財務的な承認プロセスではありません。

4. Templates

Case Card (5 minutes)

  • ライン / 設備:
  • ターゲット KPI:
  • 評価期間:

Difficulty Map

  • データ構造: S1 / S2 / S3
  • 現場依存度: D1 / D2 / D3

初期分類:

  • 数値時系列（Numeric time-series）
  • 条件付き（Conditional）
  • 別プロジェクト（Separate project）

5. Scoring Rules

スコアはあくまで 参考値（Reference only） です。

絶対ルール（Absolute Rule）

もし G5 = 不可逆な見逃し である場合、合計スコアに関わらずそのケースは却下されます。

スコアリングは議論を支援するために存在し、
責任を上書きするためではありません。

6. Irreversibility

不可逆性

不可逆な見逃し（Irreversible misses）には以下が含まれます：

安全（Safety）

  • 挟まれ・巻き込まれ
  • 火傷
  • 漏洩
  • 暴走状態

品質（Quality）

  • 市場流出
  • リコール
  • ブランド毀損

法規制（Regulation）

  • 環境基準違反
  • 労働安全違反
  • 医療・食品コンプライアンス違反

資産（Assets）

  • 設備破壊
  • 長期ダウンタイム

これらのリスクがログだけで軽減できない場合、
そのケースは分離されなければなりません。

7. SOP — Numeric Time-Series

Day 0

  • ケースカード作成
  • 難易度マップ作成

Day 0–1

  • データ抽出
  • 相互情報量（MI） / 交差検証（CV）準備

Day 1–3

  • G1–G6 評価
  • G5 オーバーライドチェック
  • オペレーターコメント

Day 3

  • 判定レビュー

8. SOP — Non-Structured Data

  1. 別プロジェクト化（Separate project）
  2. 安全第一の設計（Safety-first design）
  3. 限定パイロットのみ（Limited pilot only）
  4. 安定性 KPI の承認（Stability KPI approval）
  5. オペレーターの承認（Operator sign-off）

9. Consensus Building

これらから始める：

  • 不可逆なリスク
  • 責任の設計

これらから始めない：

  • 精度
  • モデル性能

常に数字で締める：

  • 劣化率
  • 再現性
  • 逃げ道（Escape routes）

10. Handover Boundary

Non-Structured Data Cases

この文書は、非構造化データ（音、におい、画像、または人間の感覚的判断）への依存を理由に
predictability-gate から意図的に除外されたケースの 引き継ぎ境界（handover boundary） を定義します。

これは 実装ガイドではありません。
責任がチーム間で移動する際に、不可逆な失敗を防ぐために存在します。

なぜこの引き継ぎが存在するか

このケースが除外されたのは、難しいからではなく、以下の理由からです：

  • 予測の見逃しが 不可逆な実害 を引き起こす可能性がある
  • 判断を安全に数値時系列だけに落とし込めない
  • 元のゲート内では責任を明確に強制できない

この引き継ぎは、拒絶ではなく リスクを認識した移管（risk-aware transfer） です。

引き継ぎ前に確認されたこと

このケースを分離する前に、以下が明示的に特定されました：

  • ❌ 数値時系列だけでは、不可逆な見逃しを防げない
  • ❌ ログだけでは、安全なロールバックを保証できない
  • ❌ 構造化データと非構造化データを混ぜると、失敗モードが隠蔽される

分離の判断は、モデル構築の前 に行われました。

特定された不可逆リスク

以下のカテゴリが、見逃した場合に不可逆となる可能性があるとしてフラグ付けされました：

安全（Safety）

挟まれ、火傷、漏洩、暴走状態

品質（Quality）

市場流出、リコール、ブランド毀損

法規制（Regulation）

環境基準違反、労働安全違反、医療・食品コンプライアンス違反

資産（Assets）

設備破壊、長期ダウンタイム

これらのリスクがログやアラーム単体で軽減できない場合、
そのケースを数値のみの扱いに戻してはなりません。

非構造化アプローチの前提条件

モデリングやデータ収集を始める前に、
以下を 明示的に定義しなければなりません：

権限と制御（Authority & Control）

  • 誰が システムを止める権限 を持っているか
  • 手動介入はいつ、どのようにトリガーされるか

ロールバック（Rollback）

  • ロールバックは可能か
  • ロールバックの目標状態は何か
  • ロールバックにどれくらい時間がかかるか

冗長性（Redundancy）

  • 二重検知（Double detection） が必要か
  • 検知器が一致しない場合、何が起きるか

スコープ制限（Scope limitation）

  • 初期の導入は 制限されなければならない
    • シャドーモード
    • 限定されたライン
    • 限定された時間枠
最初のステップとしてのフルスケール導入は禁止されています。

最低評価要件

非構造化アプローチは、拡大を検討する前に
以下の すべて をパスしなければなりません：

  • 条件劣化率 ≤ 15%
  • 特徴再現性 ≥ 60%
  • 影響半径が明確に特定されている
    • どのラインか
    • どのシフトか
    • どの運用ユニットか

これらが実証できない場合、
システムは制限されたままか、停止されたままでなければなりません。

意図的に提供されないもの

この引き継ぎには、以下は含まれません：

  • モデルアーキテクチャ
  • 特徴量抽出手法
  • 性能目標
  • 実装スケジュール

これらは受け取り側チームの責任に属します。

この文書は解決策ではなく、リスクのコンテキスト を移管するものです。

責任表明

この時点から先：

  • 元の predictability-gate のスコープはここで終了します
  • 受け取り側チームが 主要なリスクオーナー となります
  • 今後のすべての決定は、責任あるオペレーターを明示しなければなりません

この引き継ぎは責任を免除するものではありません。
責任を明確に再割り当てする ものです。

最後に

回避は放棄ではありません。

この境界は、
非構造化データが 慎重に、安全に、そして誠実に 扱われるために存在します。

もし責任や不可逆性が不明確になった場合、
正しい行動は 止まって再評価すること です。