モデル／ツール Health Check設計

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へ含める。

• Provider/API: DNS/TLS/auth、HTTP/API status、rate limit、model availability。
• Model invocation: bounded synthetic request、TTFT/latency、stream termination、schema/minimum response contract。
• Retrieval/tool: permission-aware read、timeout、error class、result freshness。副作用toolは原則read-only healthと実write verificationを分離する。
• Agent journey: representativeだが低リスクなsynthetic taskでmodel→tool→policy→finalizationを確認する。
• 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を持つ場合だけ許可する。

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

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