No English page yet. Showing the Japanese source.
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として保持する。日付を推測補完しない。
根拠資料
- 研究資料研究資料
Author/org: AI Safety Institute, Japan (J-AISI)
確認上の限界
元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
- 研究資料研究資料
Author/org: NIST
確認上の限界
元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
- 研究資料研究資料
Author/org: Kubernetes project
確認上の限界
元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
- 研究資料研究資料
Canonical URL: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/ ;
確認上の限界
元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
- 研究資料研究資料
Author/org: MLflow
確認上の限界
元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
- 研究資料研究資料
Canonical URL: https://mlflow.org/docs/latest/ml/model-registry/ ;
確認上の限界
元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
出典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_REFERENCEAuthor/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- 裏付ける内容
- —
- 確認日
- —
- 出典・実験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_REFERENCEAuthor/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_REFERENCECanonical 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- 裏付ける内容
- —
- 確認日
- —
- 出典・実験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_REFERENCECanonical 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_PACKETEA-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_READBACKEA-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の機械可読データです。