Skip to content

Evidence for AI operations

No English page yet. Showing the Japanese source.

Back to the entrance

AI Kill Switch/Rollback設計

用語・参照用語・参照公式仕様のみ公式仕様のみ鮮度未確認鮮度を確定できない

記事状態: 公開 · 最終確認: 未確認

要点

「AIのKill Switchは、単一の『全停止ボタン』よりも、異常部分を最小単位で隔離し、必要に応じて全体停止へ拡大できる制御面として設計する方が実務的である。Rollbackにはknown-good revisionの保持とversion provenanceが必要だが、モデルやworkflowの切戻しは、既に外部世界へ生じた副作用を自動的に取り消すものではない。2026年時点で、model・prompt・workflow・tool・retrievalを一括してatomic rollbackする普遍的AI標準は確認できない。」

現在の判断

  • 「Kill Switch」を一個の物理/論理ボタンとして一般化しない。実務Coreはprivileged control plane + 複数のcontainment scopeで設計する。
  • containment hierarchyの推奨順は、(1) specific tool/API/credential deny、(2) specific agent/module/workflow branch pause、(3) model endpoint/version switch、(4) retrieval/data source quarantine、(5) whole workflow/agent stop、(6) system-wide emergency stop。実際の順序はincident severityとdependency graphで変わる。
  • control pathは対象AIの異常挙動やprompt/tool chainから独立し、より高いauthorityを持つout-of-band経路にする。AI自身に自分のkill switch判断を全面委任しない。
  • Rollbackは最低でもmodel、prompt/config、workflow/orchestrator、tool/policy、retrieval/index/data snapshot、runtime/deployment imageをversion-addressableにする必要がある、という設計仮説が強い。一次証拠が直接確立しているのはmodel version switchと一般deployment revision rollbackであり、prompt/workflow全層の共通標準は未確認。
  • known-good stateの定義にはversion番号だけでなく、compatibility(tool schema, policy, index, secrets/identity, downstream dependency)を含めるべき。
  • deployment rollbackは「実行済み副作用のundo」と同義ではない。送信済みメール、外部API mutation、DB書込み、支払等は以前のmodel/workflowへ戻しても自動的には取り消されない。compensating actionまたはmanual remediationを別runbookとして持つ必要がある(INFERENCE/PROPOSAL)。
  • incident evidenceを失わないため、可能ならcontainment前後のrevision/trace/action stateをcaptureする。ただし進行中の害を止める緊急性が証拠保存より優先する場合がある。

どこまで当てはまるか

Enterprise AI Core / Operations / Security / AgentOps / AI-SRE / implementation / non-LLM component / provider mapping / organization overlay

詳しく理解する

なぜ重要か

自律agentやtool-using workflowでは、異常時にmodel APIを止めるだけでは不十分である。異常componentを最小範囲で隔離し、必要なら全体を緊急停止し、known-good revisionへ戻し、外部副作用や汚染状態を別途処理できなければ、停止そのものが大規模業務停止または不完全復旧を生む。Kill SwitchとRollbackはAI safety機能というより、versioned deployment/control-plane/incident-response設計として扱う必要がある。

対象範囲と前提

Enterprise AI Core / Operations / Security / AgentOps / AI-SRE / implementation / non-LLM component / provider mapping / organization overlay

検討ポイント

  • AIのKill Switchは「全停止ボタン」で十分か。
  • model/prompt/workflow/tool/RAG等をknown-good stateへ安全に切り戻すために必要な前提は何か。
  • 実行済み外部副作用とdeployment rollbackをどう区別すべきか。

EVIDENCE TABLE

  • Source class: official national AI incident-response guidance Exact title: AI Incident Response Approach Book / AI-IRS v1.0 Author/org: AI Safety Institute, Japan (J-AISI) Canonical URL: https://aisi.go.jp/assets/pdf/ai-irs_v1.0_ja.pdf Publication/update/access: 2026-01-09; accessed 2026-09-14 Version: AI-IRS v1.0 Supporting locator: pp.16, 18-19; local stop/over-control; design-time controllability; model-version switch; malicious-data handling; unauthorized API disconnection; isolated higher-authority control interface Evidence label: SOURCE_REPORT / VERIFIED_SPEC Relation: support/limit Claim supported: safe containmentは全停止より局所停止を優先し得る。controlabilityをdesign timeに組み込み、異常modelから別version/alternate modelへの切替、不正API切離し、異常の影響を受けない上位control interface等が具体例として示される。局所隔離できなければagent全体停止によるbusiness interruptionというover-control riskがある。
  • Source class: official cyber incident-response standard/guidance Exact title: NIST SP 800-61 Rev. 3 Author/org: NIST Canonical URL: https://csrc.nist.gov/pubs/sp/800/61/r3/final Publication/update/access: April 2025; accessed 2026-09-14 Version: Final SP 800-61r3 Supporting locator: containment, recovery, risk-management integration Evidence label: VERIFIED_SPEC Relation: context/support Claim supported: containment/recoveryはincident responseの基礎。AI固有kill switchはこの一般IR controlを具体化・拡張するものとして位置づけるのが妥当。
  • Source class: official OSS implementation documentation Exact title: Updating a Deployment / Rolling Back a Deployment Author/org: Kubernetes project Canonical URL: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/ ; https://kubernetes.io/docs/tasks/run-application/update-deployment-rolling/ Publication/update/access: current docs accessed 2026-09-14; page modified 2026-03-12 in current documentation Version: current Kubernetes documentation Supporting locator: rollout history / kubectl rollout undo / revisionHistoryLimit Evidence label: OSS_PRACTICE Relation: support/limit Claim supported: generic deployment rollback is implemented through retained/versioned prior revisions; rollback capability depends on revision history retention. This is an implementation pattern, not evidence that an AI model/prompt/workflow automatically rolls back.
  • Source class: author-maintained OSS documentation Exact title: MLflow Model Registry / Model Registry Workflow Author/org: MLflow Canonical URL: https://mlflow.org/docs/latest/ml/model-registry/ ; https://www.mlflow.org/docs/latest/ml/model-registry/workflow/ Publication/update/access: current latest docs accessed 2026-09-14 Version: current latest documentation Supporting locator: model versions, aliases/tags; reassignable alias such as champion pointing to a model version Evidence label: OSS_PRACTICE Relation: support/context Claim supported: model versionをaddressableに保持しaliasを切り替える実装は、known-good modelへtraffic/referenceを切り替えるrollback/switch patternとして利用できる。

利用できる条件

  • provider model alias/version pinning、prompt versioning、workflow revision、tool disable、credential revoke、RAG snapshot/index rollbackの有無はprovider/product/planによる。
  • model providerが旧versionをretireした場合、同一modelへのrollbackが不可能なためalternate model/fallback qualificationが必要。
  • SaaS agentではsystem-wide stopやforensic snapshot権限がcustomer adminへ公開されない場合があるため、provider mappingで確認する。

実装・運用

Evidence-backed Core design (PROPOSAL): CONTROL PLANE (out-of-band, privileged, audited) -> scope selector [tool / credential / module / workflow / model / retrieval / global] -> action [deny / pause / disconnect / route-switch / revision-switch / stop] -> evidence snapshot -> health/eval gate -> recover or escalate.

Rollback manifest案: - application/workflow revision - model provider + model ID/version - system/developer prompt/config revision - tool schema/policy revision - retrieval corpus/index/snapshot revision - runtime/container/dependency revision - credential/identity/policy bindings - evaluator/test-set revision - migration/compatibility notes - external side-effect reconciliation status

確認・評価方法

安全なtabletop/game-dayで、以下を測る: - kill latency / containment latency - local-stop成功率とglobal-stop fallback率 - known-good revisionへの復旧時間 - rollback後のeval/regression pass率 - evidence capture completeness - orphaned tool calls/queued actions数 - uncompensated external side effects数 - control-plane availability and authorization failure 数値thresholdはorganization risk tierごとに定めるPROPOSALであり、共通業界値として断定しない。

セキュリティとプライバシー

kill/rollback権限をagent runtimeから分離し、least privilege + strong admin auth + dual controlを高impact用途で検討。

セキュリティとプライバシー 2

emergency snapshotに秘密情報やPIIが含まれ得るためincident evidence retention policyを定義。 AUDIT: 誰が、何を、どのscopeで停止/切替し、どのrevisionへ戻し、何を検証したかを記録。

コストと運用負荷

warm standby/alternate provider、revision retention、snapshot、game-dayには追加costがあるが、復旧不能リスクとのtrade-offとして扱う。

OPERABILITY

kill switchは存在確認だけでなく定期drillが必要。unused emergency controlは権限切れ・API変更・runbook陳腐化を起こし得る。

AUDITED BOUNDARY

Kill/rollback remains an out-of-band scoped control-plane proposal. Local containment may precede global stop where dependencies permit. Kubernetes revision rollback and MLflow model-version/alias switching are implementation precedents, not evidence of atomic AI-workflow rollback. Revision rollback does not undo already committed external side effects. Preserve provider/product availability gates and all OPEN_UNKNOWN.

確認できていること

  • 「Kill Switch」を一個の物理/論理ボタンとして一般化しない。実務Coreはprivileged control plane + 複数のcontainment scopeで設計する。

  • containment hierarchyの推奨順は、(1) specific tool/API/credential deny、(2) specific agent/module/workflow branch pause、(3) model endpoint/version switch、(4) retrieval/data source quarantine、(5) whole workflow/agent stop、(6) system-wide emergency stop。実際の順序はincident severityとdependency graphで変わる。

  • control pathは対象AIの異常挙動やprompt/tool chainから独立し、より高いauthorityを持つout-of-band経路にする。AI自身に自分のkill switch判断を全面委任しない。

  • Rollbackは最低でもmodel、prompt/config、workflow/orchestrator、tool/policy、retrieval/index/data snapshot、runtime/deployment imageをversion-addressableにする必要がある、という設計仮説が強い。一次証拠が直接確立しているのはmodel version switchと一般deployment revision rollbackであり、prompt/workflow全層の共通標準は未確認。

  • known-good stateの定義にはversion番号だけでなく、compatibility(tool schema, policy, index, secrets/identity, downstream dependency)を含めるべき。

  • deployment rollbackは「実行済み副作用のundo」と同義ではない。送信済みメール、外部API mutation、DB書込み、支払等は以前のmodel/workflowへ戻しても自動的には取り消されない。compensating actionまたはmanual remediationを別runbookとして持つ必要がある(INFERENCE/PROPOSAL)。

  • incident evidenceを失わないため、可能ならcontainment前後のrevision/trace/action stateをcaptureする。ただし進行中の害を止める緊急性が証拠保存より優先する場合がある。

よくある失敗・反証

  • AI-IRS v1.0はapproach book/guidanceであり、普遍的なkill-switch標準や法的義務ではない。

  • 局所停止にはdependency graphとcontrol pointが必要。dependency不明、shared credential/shared runtime、hidden stateがあると局所隔離に失敗し、全停止を余儀なくされる。

  • rollback先が存在しても、schema/data migration、external state、provider model retirement、API incompatibility、vector index変更等で実際には戻せない可能性がある。

  • Kubernetes/MLflowはimplementation precedentであり、AI workflow全体のatomic rollbackや副作用補償を保証しない。

  • modelだけ戻してprompt/tool/data/indexが新しいままなら「部分rollback」による新たな不整合を起こし得る。

  • fail-open control plane、同一credentialでのkill/restart、agent自身から書換可能なpolicy、単一provider control API依存はkill switchの信頼境界を弱める。

  • provider横断control標準または主要agent platformのversioned rollback機能が成熟した時点、J-AISI/NIST/ISO guidanceが更新された時点で再採集。現時点の初回Packetは設計・採否判断に十分。

    ---

実務での使い方

  • provider model alias/version pinning、prompt versioning、workflow revision、tool disable、credential revoke、RAG snapshot/index rollbackの有無はprovider/product/planによる。

  • model providerが旧versionをretireした場合、同一modelへのrollbackが不可能なためalternate model/fallback qualificationが必要。

  • SaaS agentではsystem-wide stopやforensic snapshot権限がcustomer adminへ公開されない場合があるため、provider mappingで確認する。

  • Evidence-backed Core design (PROPOSAL): CONTROL PLANE (out-of-band, privileged, audited) -> scope selector [tool / credential / module / workflow / model / retrieval / global] -> action [deny / pause / disconnect / route-switch / revision-switch / stop] -> evidence snapshot -> health/eval gate -> recover or escalate.

    Rollback manifest案:

  • application/workflow revision

  • model provider + model ID/version

  • system/developer prompt/config revision

  • tool schema/policy revision

  • retrieval corpus/index/snapshot revision

  • runtime/container/dependency revision

  • credential/identity/policy bindings

  • evaluator/test-set revision

  • migration/compatibility notes

  • external side-effect reconciliation status

  • 安全なtabletop/game-dayで、以下を測る:

  • kill latency / containment latency

  • local-stop成功率とglobal-stop fallback率

  • known-good revisionへの復旧時間

  • rollback後のeval/regression pass率

  • evidence capture completeness

  • orphaned tool calls/queued actions数

  • uncompensated external side effects数

  • control-plane availability and authorization failure 数値thresholdはorganization risk tierごとに定めるPROPOSALであり、共通業界値として断定しない。

  • kill/rollback権限をagent runtimeから分離し、least privilege + strong admin auth + dual controlを高impact用途で検討。

  • EA-053 Incident Responseのcontainment/recovery mechanismとしてcross-reference。

  • provider mappingでは model version pin/alias、prompt/config revision、workflow revision、tool disable、credential revoke、RAG/index snapshot、global stop、audit log、rollback retentionを別々に確認。

  • post-update Workでは実機を伴う場合、破壊的操作を避けたTEST_PROFILEとして「dummy agent + mock tool + reversible state」でlocal kill/global kill/revision switchを検証。

  • irreversible side effectsはcompensation/idempotency設計へ別論点として接続し、rollbackと混同しない。

  • Kill/rollback remains an out-of-band scoped control-plane proposal. Local containment may precede global stop where dependencies permit. Kubernetes revision rollback and MLflow model-version/alias switching are implementation precedents, not evidence of atomic AI-workflow rollback. Revision rollback does not undo already committed external side effects. Preserve provider/product availability gates and all OPEN_UNKNOWN.

まだ確認できていないこと

  • EA-054-UNKNOWN-01
    • provider横断のstandardized kill/control interfaceの成熟状況。
    • prompt/workflow/tool/retrievalを含むmulti-layer rollback manifestの標準化有無。
    • stateful agent memory/long-running taskをrollbackする一般的方式。
  • EA-054-UNKNOWN-CURRENTNESS

    外部根拠の再確認日がcanonical body/control-planeで確定していないため、currentnessはUNKNOWNとして保持する。日付を推測補完しない。

根拠資料

出典ID・検証情報・機械可読データ

根拠の種類と情報の鮮度は、ラベルとアイコンで確認できます。

記事ID
EA-054
最終確認日
—
提供元・モデル・プラン・利用環境
—
対象地域
—
元資料の全文と収録照合記録
WHY_THIS_MATTERS_TO_UPDATE

自律agentやtool-using workflowでは、異常時にmodel APIを止めるだけでは不十分である。異常componentを最小範囲で隔離し、必要なら全体を緊急停止し、known-good revisionへ戻し、外部副作用や汚染状態を別途処理できなければ、停止そのものが大規模業務停止または不完全復旧を生む。Kill SwitchとRollbackはAI safety機能というより、versioned deployment/control-plane/incident-response設計として扱う必要がある。

SCOPE_ROUTING

Enterprise AI Core / Operations / Security / AgentOps / AI-SRE / implementation / non-LLM component / provider mapping / organization overlay

CLAIM_OR_RESEARCH_QUESTION
  • AIのKill Switchは「全停止ボタン」で十分か。
  • model/prompt/workflow/tool/RAG等をknown-good stateへ安全に切り戻すために必要な前提は何か。
  • 実行済み外部副作用とdeployment rollbackをどう区別すべきか。
EVIDENCE TABLE
  • Source class: official national AI incident-response guidance Exact title: AI Incident Response Approach Book / AI-IRS v1.0 Author/org: AI Safety Institute, Japan (J-AISI) Canonical URL: https://aisi.go.jp/assets/pdf/ai-irs_v1.0_ja.pdf Publication/update/access: 2026-01-09; accessed 2026-09-14 Version: AI-IRS v1.0 Supporting locator: pp.16, 18-19; local stop/over-control; design-time controllability; model-version switch; malicious-data handling; unauthorized API disconnection; isolated higher-authority control interface Evidence label: SOURCE_REPORT / VERIFIED_SPEC Relation: support/limit Claim supported: safe containmentは全停止より局所停止を優先し得る。controlabilityをdesign timeに組み込み、異常modelから別version/alternate modelへの切替、不正API切離し、異常の影響を受けない上位control interface等が具体例として示される。局所隔離できなければagent全体停止によるbusiness interruptionというover-control riskがある。
  • Source class: official cyber incident-response standard/guidance Exact title: NIST SP 800-61 Rev. 3 Author/org: NIST Canonical URL: https://csrc.nist.gov/pubs/sp/800/61/r3/final Publication/update/access: April 2025; accessed 2026-09-14 Version: Final SP 800-61r3 Supporting locator: containment, recovery, risk-management integration Evidence label: VERIFIED_SPEC Relation: context/support Claim supported: containment/recoveryはincident responseの基礎。AI固有kill switchはこの一般IR controlを具体化・拡張するものとして位置づけるのが妥当。
  • Source class: official OSS implementation documentation Exact title: Updating a Deployment / Rolling Back a Deployment Author/org: Kubernetes project Canonical URL: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/ ; https://kubernetes.io/docs/tasks/run-application/update-deployment-rolling/ Publication/update/access: current docs accessed 2026-09-14; page modified 2026-03-12 in current documentation Version: current Kubernetes documentation Supporting locator: rollout history / kubectl rollout undo / revisionHistoryLimit Evidence label: OSS_PRACTICE Relation: support/limit Claim supported: generic deployment rollback is implemented through retained/versioned prior revisions; rollback capability depends on revision history retention. This is an implementation pattern, not evidence that an AI model/prompt/workflow automatically rolls back.
  • Source class: author-maintained OSS documentation Exact title: MLflow Model Registry / Model Registry Workflow Author/org: MLflow Canonical URL: https://mlflow.org/docs/latest/ml/model-registry/ ; https://www.mlflow.org/docs/latest/ml/model-registry/workflow/ Publication/update/access: current latest docs accessed 2026-09-14 Version: current latest documentation Supporting locator: model versions, aliases/tags; reassignable alias such as champion pointing to a model version Evidence label: OSS_PRACTICE Relation: support/context Claim supported: model versionをaddressableに保持しaliasを切り替える実装は、known-good modelへtraffic/referenceを切り替えるrollback/switch patternとして利用できる。
FINDINGS
  • 「Kill Switch」を一個の物理/論理ボタンとして一般化しない。実務Coreはprivileged control plane + 複数のcontainment scopeで設計する。
  • containment hierarchyの推奨順は、(1) specific tool/API/credential deny、(2) specific agent/module/workflow branch pause、(3) model endpoint/version switch、(4) retrieval/data source quarantine、(5) whole workflow/agent stop、(6) system-wide emergency stop。実際の順序はincident severityとdependency graphで変わる。
  • control pathは対象AIの異常挙動やprompt/tool chainから独立し、より高いauthorityを持つout-of-band経路にする。AI自身に自分のkill switch判断を全面委任しない。
  • Rollbackは最低でもmodel、prompt/config、workflow/orchestrator、tool/policy、retrieval/index/data snapshot、runtime/deployment imageをversion-addressableにする必要がある、という設計仮説が強い。一次証拠が直接確立しているのはmodel version switchと一般deployment revision rollbackであり、prompt/workflow全層の共通標準は未確認。
  • known-good stateの定義にはversion番号だけでなく、compatibility(tool schema, policy, index, secrets/identity, downstream dependency)を含めるべき。
  • deployment rollbackは「実行済み副作用のundo」と同義ではない。送信済みメール、外部API mutation、DB書込み、支払等は以前のmodel/workflowへ戻しても自動的には取り消されない。compensating actionまたはmanual remediationを別runbookとして持つ必要がある(INFERENCE/PROPOSAL)。
  • incident evidenceを失わないため、可能ならcontainment前後のrevision/trace/action stateをcaptureする。ただし進行中の害を止める緊急性が証拠保存より優先する場合がある。
LIMITS / COUNTEREVIDENCE / FAILURE ENVELOPE
  • AI-IRS v1.0はapproach book/guidanceであり、普遍的なkill-switch標準や法的義務ではない。
  • 局所停止にはdependency graphとcontrol pointが必要。dependency不明、shared credential/shared runtime、hidden stateがあると局所隔離に失敗し、全停止を余儀なくされる。
  • rollback先が存在しても、schema/data migration、external state、provider model retirement、API incompatibility、vector index変更等で実際には戻せない可能性がある。
  • Kubernetes/MLflowはimplementation precedentであり、AI workflow全体のatomic rollbackや副作用補償を保証しない。
  • modelだけ戻してprompt/tool/data/indexが新しいままなら「部分rollback」による新たな不整合を起こし得る。
  • fail-open control plane、同一credentialでのkill/restart、agent自身から書換可能なpolicy、単一provider control API依存はkill switchの信頼境界を弱める。
AVAILABILITY_GATES
  • provider model alias/version pinning、prompt versioning、workflow revision、tool disable、credential revoke、RAG snapshot/index rollbackの有無はprovider/product/planによる。
  • model providerが旧versionをretireした場合、同一modelへのrollbackが不可能なためalternate model/fallback qualificationが必要。
  • SaaS agentではsystem-wide stopやforensic snapshot権限がcustomer adminへ公開されない場合があるため、provider mappingで確認する。
IMPLEMENTATION_STATE

Evidence-backed Core design (PROPOSAL): CONTROL PLANE (out-of-band, privileged, audited) -> scope selector [tool / credential / module / workflow / model / retrieval / global] -> action [deny / pause / disconnect / route-switch / revision-switch / stop] -> evidence snapshot -> health/eval gate -> recover or escalate.

Rollback manifest案: - application/workflow revision - model provider + model ID/version - system/developer prompt/config revision - tool schema/policy revision - retrieval corpus/index/snapshot revision - runtime/container/dependency revision - credential/identity/policy bindings - evaluator/test-set revision - migration/compatibility notes - external side-effect reconciliation status

BENCHMARK_OR_EVAL

安全なtabletop/game-dayで、以下を測る: - kill latency / containment latency - local-stop成功率とglobal-stop fallback率 - known-good revisionへの復旧時間 - rollback後のeval/regression pass率 - evidence capture completeness - orphaned tool calls/queued actions数 - uncompensated external side effects数 - control-plane availability and authorization failure 数値thresholdはorganization risk tierごとに定めるPROPOSALであり、共通業界値として断定しない。

SECURITY

kill/rollback権限をagent runtimeから分離し、least privilege + strong admin auth + dual controlを高impact用途で検討。

PRIVACY

emergency snapshotに秘密情報やPIIが含まれ得るためincident evidence retention policyを定義。 AUDIT: 誰が、何を、どのscopeで停止/切替し、どのrevisionへ戻し、何を検証したかを記録。

COST

warm standby/alternate provider、revision retention、snapshot、game-dayには追加costがあるが、復旧不能リスクとのtrade-offとして扱う。

OPERABILITY

kill switchは存在確認だけでなく定期drillが必要。unused emergency controlは権限切れ・API変更・runbook陳腐化を起こし得る。

SAFE_WORDING_FOR_FUTURE_BOOK

「AIのKill Switchは、単一の『全停止ボタン』よりも、異常部分を最小単位で隔離し、必要に応じて全体停止へ拡大できる制御面として設計する方が実務的である。Rollbackにはknown-good revisionの保持とversion provenanceが必要だが、モデルやworkflowの切戻しは、既に外部世界へ生じた副作用を自動的に取り消すものではない。2026年時点で、model・prompt・workflow・tool・retrievalを一括してatomic rollbackする普遍的AI標準は確認できない。」

UPDATE_WORK_HANDOFF
  • EA-053 Incident Responseのcontainment/recovery mechanismとしてcross-reference。
  • provider mappingでは model version pin/alias、prompt/config revision、workflow revision、tool disable、credential revoke、RAG/index snapshot、global stop、audit log、rollback retentionを別々に確認。
  • post-update Workでは実機を伴う場合、破壊的操作を避けたTEST_PROFILEとして「dummy agent + mock tool + reversible state」でlocal kill/global kill/revision switchを検証。
  • irreversible side effectsはcompensation/idempotency設計へ別論点として接続し、rollbackと混同しない。
OPEN_UNKNOWN
  • provider横断のstandardized kill/control interfaceの成熟状況。
  • prompt/workflow/tool/retrievalを含むmulti-layer rollback manifestの標準化有無。
  • stateful agent memory/long-running taskをrollbackする一般的方式。
STOP_CONDITION

provider横断control標準または主要agent platformのversioned rollback機能が成熟した時点、J-AISI/NIST/ISO guidanceが更新された時点で再採集。現時点の初回Packetは設計・採否判断に十分。

---

AUDITED_BOUNDARY

Kill/rollback remains an out-of-band scoped control-plane proposal. Local containment may precede global stop where dependencies permit. Kubernetes revision rollback and MLflow model-version/alias switching are implementation precedents, not evidence of atomic AI-workflow rollback. Revision rollback does not undo already committed external side effects. Preserve provider/product availability gates and all OPEN_UNKNOWN.

  • EVD-EA-054-URL-923392A0DE3A研究資料研究資料根拠の出所: SOURCE_PACKET_REFERENCE

    Author/org: AI Safety Institute, Japan (J-AISI)

    裏付ける内容
    —
    確認日
    —
    出典・実験ID
    SRC-EA-054-URL-923392A0DE3A
    検証箇所
    EVIDENCE TABLE · Canonical URL: https://aisi.go.jp/assets/pdf/ai-irs_v1.0_ja.pdf
    適用範囲
    EVIDENCE TABLE
    出典・来歴
    SOURCE_PACKET_REFERENCE_PROJECTED
    限界
    元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
  • EVD-EA-054-URL-F53ED62DD159研究資料研究資料根拠の出所: SOURCE_PACKET_REFERENCE

    Author/org: NIST

    裏付ける内容
    —
    確認日
    —
    出典・実験ID
    SRC-EA-054-URL-F53ED62DD159
    検証箇所
    EVIDENCE TABLE · Canonical URL: https://csrc.nist.gov/pubs/sp/800/61/r3/final
    適用範囲
    EVIDENCE TABLE
    出典・来歴
    SOURCE_PACKET_REFERENCE_PROJECTED
    限界
    元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
  • EVD-EA-054-URL-D9A16560DB2B研究資料研究資料根拠の出所: SOURCE_PACKET_REFERENCE

    Author/org: Kubernetes project

    裏付ける内容
    —
    確認日
    —
    出典・実験ID
    SRC-EA-054-URL-D9A16560DB2B
    検証箇所
    EVIDENCE TABLE · Canonical URL: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
    適用範囲
    EVIDENCE TABLE
    出典・来歴
    SOURCE_PACKET_REFERENCE_PROJECTED
    限界
    元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
  • EVD-EA-054-URL-157F12DF6B17研究資料研究資料根拠の出所: SOURCE_PACKET_REFERENCE

    Canonical URL: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/ ;

    裏付ける内容
    —
    確認日
    —
    出典・実験ID
    SRC-EA-054-URL-157F12DF6B17
    検証箇所
    EVIDENCE TABLE · Canonical URL: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/ ; https://kubernetes.io/docs/tasks/run-application/update-deployment-rolling/
    適用範囲
    EVIDENCE TABLE
    出典・来歴
    SOURCE_PACKET_REFERENCE_PROJECTED
    限界
    元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
  • EVD-EA-054-URL-B3B7EFD6E280研究資料研究資料根拠の出所: SOURCE_PACKET_REFERENCE

    Author/org: MLflow

    裏付ける内容
    —
    確認日
    —
    出典・実験ID
    SRC-EA-054-URL-B3B7EFD6E280
    検証箇所
    EVIDENCE TABLE · Canonical URL: https://mlflow.org/docs/latest/ml/model-registry/
    適用範囲
    EVIDENCE TABLE
    出典・来歴
    SOURCE_PACKET_REFERENCE_PROJECTED
    限界
    元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
  • EVD-EA-054-URL-249922A3E9A3研究資料研究資料根拠の出所: SOURCE_PACKET_REFERENCE

    Canonical URL: https://mlflow.org/docs/latest/ml/model-registry/ ;

    裏付ける内容
    —
    確認日
    —
    出典・実験ID
    SRC-EA-054-URL-249922A3E9A3
    検証箇所
    EVIDENCE TABLE · Canonical URL: https://mlflow.org/docs/latest/ml/model-registry/ ; https://www.mlflow.org/docs/latest/ml/model-registry/workflow/
    適用範囲
    EVIDENCE TABLE
    出典・来歴
    SOURCE_PACKET_REFERENCE_PROJECTED
    限界
    元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
  • EA-054-R11-RESEARCH研究資料研究資料根拠の出所: AUDITED_CANONICAL_RESEARCH_PACKET

    EA-054 監査済みresearch / canonical revision binding

    裏付ける内容
    - 「Kill Switch」を一個の物理/論理ボタンとして一般化しない。実務Coreはprivileged control plane + 複数のcontainment scopeで設計する。 - containment hierarchyの推奨順は、(1) specific tool/API/credential deny、(2) specific agent/module/workflow branch pause、(3) model endpoint/version switch、(4) retrieval/data source quarantine、(5) whole workflow/agent stop、(6) system-wide emergency stop。実際の順序はincident severityとdependency graphで変わる。 - control pathは対象AIの異常挙動やprompt/tool chainから独立し、より高いauthorityを持つout-of-band経路にする。AI自身に自分のkill switch判断を全面委任しない。 - Rollbackは最低でもmodel、prompt/config、workflow/orchestrator、tool/policy、retrieval/index/data snapshot、runtime/deployment imageをversion-addressableにする必要がある、という設計仮説が強い。一次証拠が直接確立しているのはmodel version switchと一般deployment revision rollbackであり、prompt/workflow全層の共通標準は未確認。 - known-good stateの定義にはversion番号だけでなく、compatibility(tool schema, policy, index, secrets/identity, downstream dependency)を含めるべき。 - deployment rollbackは「実行済み副作用のundo」と同義ではない。送信済みメール、外部API mutation、DB書込み、支払等は以前のmodel/workflowへ戻しても自動的には取り消されない。compensating actionまたはmanual remediationを別runbookとして持つ必要がある(INFERENCE/PROPOSAL)。 - incident evidenceを失わないため、可能ならcontainment前後のrevision/trace/action stateをcaptureする。ただし進行中の害を止める緊急性が証拠保存より優先する場合がある。
    確認日
    —
    出典・実験ID
    COMM-053-EA0054
    検証箇所
    COMM-053-EA0054 · EA-054-R5-LEGACY-MIGRATION-20261008-R1 · content/staging/EA-054.md
    適用範囲
    監査済みEA本文・canonical revision・既存Source Graph relationの範囲。欠損currentnessは推測で閉じない。
    出典・来歴
    AUDIT_PASS_CANONICAL_BINDING
    限界
    canonical監査・revision bindingの存在を示す。外部ソースcurrentnessが本文またはcontrol-planeで確定していない場合は、currentnessをUNKNOWNのまま保持する。
  • EA-054-R11-WEB-READBACK実装資料実装資料根拠の出所: IMPLEMENTATION_READBACK

    EA-054 Web body identity / canonical readback

    裏付ける内容
    canonical staging bodyのSHA-256一致とR9 canonical ledger readbackをProduction projectionの入力として検証する。
    確認日
    —
    出典・実験ID
    WEBBODY-EA0054-R8-7C0CBE91
    検証箇所
    WEBBODY-EA0054-R8-7C0CBE91 · content/staging/EA-054.md · EA-054-R5-LEGACY-MIGRATION-20261008-R1
    適用範囲
    R9/R10 canonical readback後のProduction生成時body identity。
    出典・来歴
    CANONICAL_READBACK_BODY_HASH_MATCH
    限界
    body identity/readbackは本文claim自体の真偽や外部ソースの最新性を追加保証しない。
出典ID
COMM-053-EA0054, SRC-EA-054-URL-923392A0DE3A, SRC-EA-054-URL-F53ED62DD159, SRC-EA-054-URL-D9A16560DB2B, SRC-EA-054-URL-157F12DF6B17, SRC-EA-054-URL-B3B7EFD6E280, SRC-EA-054-URL-249922A3E9A3, WEBBODY-EA0054-R8-7C0CBE91
追跡中のUNKNOWN ID
EA-054-UNKNOWN-01, EA-054-UNKNOWN-CURRENTNESS
再確認のきっかけ
canonical revision/publication state change · body artifact hash change · source currentness change · new contradiction or implementation readback

機械検査: 通過 — Automated validation does not guarantee accuracy or authorize execution.

    同じ記事IDの機械可読データです。