# Model／Tool Health Check設計

CURRENT_STATUS: CURRENT
OBSERVATION: SPEC_ONLY
FRESHNESS: CURRENT
PAGE_TYPE: reference
CANONICAL_URL: /tools/ea-272-model-tool-health-check
CLAIM_IDS: none
EVIDENCE_IDS: EA-272-CURRENT-APPROVAL, EA-272-CURRENT-BODY-READBACK
UNKNOWN_IDS: EA-272-UNKNOWN-01
OPS_IDS: none

## Summary
「health checkが成功した」は、そのprobeが定義した時点・地点・契約を満たしたことだけを意味する。モデル品質、全tool、全tenant、end-to-end業務成功、将来の可用性を保証しない。

## Current judgment
「health checkが成功した」は、そのprobeが定義した時点・地点・契約を満たしたことだけを意味する。モデル品質、全tool、全tenant、end-to-end業務成功、将来の可用性を保証しない。

## Scope
Model／Tool Health Check設計

## Confirmed

## UNKNOWN
- EA-272-UNKNOWN-01: 組織のcritical journey、必須/任意dependency、provider/model/version、tool権限、probe credential、sampling interval、timeout/threshold、failover topology、write-probe sandbox、data retention、PII/secret policy、tenant別挙動は導入環境で確認する。

## Evidence
- EA-272-CURRENT-APPROVAL (RESEARCH): 現行本文の監査・revision対応
- EA-272-CURRENT-BODY-READBACK (IMPL): 現行本文の収録照合

## 要点と前提
AI/Agent運用のhealth checkは、単一の「200 OK」や単発LLM応答で健全性を断定せず、少なくとも process liveness、traffic readiness、model endpoint、tool/dependency、end-to-end synthetic journey を別々の信号として扱う。

## 設計原則
- livenessはプロセスが進行可能かを確認し、下流依存障害を理由に安易に再起動しない。readinessは必須依存を含め、実際に要求を受けられるかを判定する。
- model healthはHTTP成功だけでなく、model ID、認証、rate-limit/5xx、TTFT/latency、stream完了、最小の応答契約を観測する。ただしsynthetic promptの成功を業務品質保証へ外挿しない。
- tool healthは「到達可能」と「安全に正しい副作用を完了できる」を分ける。read-only probeを優先し、write probeが必要ならsandbox/idempotency/cleanup/readbackを明示する。
- dependencyを一つのANDへ無条件集約しない。必須・任意・degraded-mode可能を分類し、optional dependency障害だけで全instanceをtrafficから除外しない。
- health verdictには観測時刻、probe version、target/model/tool version、timeout、failure threshold、観測地点を残す。UNKNOWN/insufficient dataをhealthyへ暗黙変換しない。
- probe自体の障害、資格情報失効、network partition、provider側障害、false positive/negativeをfailure envelopeへ含める。

## AI固有のprobe層
1. Provider/API: DNS/TLS/auth、HTTP/API status、rate limit、model availability。
2. Model invocation: bounded synthetic request、TTFT/latency、stream termination、schema/minimum response contract。
3. Retrieval/tool: permission-aware read、timeout、error class、result freshness。副作用toolは原則read-only healthと実write verificationを分離する。
4. Agent journey: representativeだが低リスクなsynthetic taskでmodel→tool→policy→finalizationを確認する。
5. Business SLI: synthetic healthとは独立に、実トラフィックのtask completion、tool correctness、policy violation、latency等を監視する。

## 判定と自動化
health check結果を即座にrestart/failoverへ直結させず、連続失敗、複数観測地点、hysteresis/cooldown、dependency scopeを考慮する。failover先も同じshared dependencyを使う場合、切替は復旧にならない。自動remediationはblast radius、rate limit、rollback、readbackを持つ場合だけ許可する。

## SAFE_WORDING
「health checkが成功した」は、そのprobeが定義した時点・地点・契約を満たしたことだけを意味する。モデル品質、全tool、全tenant、end-to-end業務成功、将来の可用性を保証しない。

## OPEN_UNKNOWN
組織のcritical journey、必須/任意dependency、provider/model/version、tool権限、probe credential、sampling interval、timeout/threshold、failover topology、write-probe sandbox、data retention、PII/secret policy、tenant別挙動は導入環境で確認する。

NEXT: /agent/start.json
STOP: This is a knowledge projection, not an execution order.