TL;DR

Chaos MeshでKubernetesに障害を注入し、ai& Inference上のモデルが
kubectlを使って自律的に復旧するまでを計測した。
ai&の全7モデル×5シナリオ×3回=105試行を同一条件で回し、復旧成功率・MTTR・ツール呼び出し数を記録した。
結果は全モデル100%成功。単一障害点であれば、小さなモデルでも実用性を感じた。

1. 背景と目的

「LLMに障害対応をどこまで任せられるか」を再現可能な数値で確かめたかった。
そこで次の3つを1本のパイプラインにまとめた。

障害の注入: Chaos Meshで、Podの継続Kill・ネットワーク断・不正イメージ・Service設定ミスといった障害を再現する。
自律復旧: LLMエージェントにkubectlを渡し、調査(読み取り)→原因特定→最小限の修復(書き込み)をさせる。
評価: probe Podからのヘルスチェックが復旧するまでの時間などを自動で記録する。

どのモデルが一番優秀かというランキングよりも、LLMによる自律復旧が実運用の障害にどこまで通用するか、
モデルによって挙動がどう変わるかを見ていく。

全体構成

2. ai& Inferenceの使いどころ

ai& Inferenceは、オープンモデルをOpenAI／Anthropic互換のAPIで提供する国内の推論プラットフォーム。
Qiitaのイベントでトライアルがあったので試してみた。

今回使ったGET /v1/modelsには、gpt-oss・Gemma・DeepSeek・Qwen・GLM・Kimiといったモデルが並んでいた。

OpenAI互換なので、Pythonのopenaiライブラリをそのまま使える。

エージェント側はOpenAI(base_url=AIAND_BASE_URL, api_key=...)の接続先を差し替えるだけで、
複数モデルを同じコードで回せる。

# agent/client.py（抜粋）
client = OpenAI(base_url=AIAND_BASE_URL, api_key=AIAND_API_KEY,
                default_headers={"X-Aiand-Metrics": "true"})

GET /v1/modelsで取得できたラインナップ(全7・すべてtool_calling対応):

モデル	context
`qwen/qwen3.6-27b`	262k
`deepseek-ai/deepseek-v4-flash`	1M
`google/gemma-4-31b-it`	262k
`openai/gpt-oss-120b`	131k
`deepseek-ai/deepseek-v4-pro`	1M
`moonshotai/kimi-k2.7-code`	262k
`zai-org/glm-5.2`	1M

今回はこの7モデルすべてを検証対象にした。

3. 障害シナリオ（Chaos Meshで作る）

Chaos MeshはKubernetes向けのカオスエンジニアリング用ツール(CNCFプロジェクト)で、Podのkillやネットワーク遅延・
パケットロスといった障害を、カスタムリソース(CR)を適用するだけで注入できる。

共通のヘルスチェックは「probe Podからhttp://podinfo.demo.svc:9898/healthzが200を返すか」。
各シナリオは「注入で確実にunhealthyになり、正しい対処でhealthyに戻る」ことを確認済み。

id	何をするか	注入後どうなるか	正しい対処
scale-zero	replicasを0にする	Podが全滅しServiceの宛先が消え、全リクエストが失敗	replicasを戻す
pod-kill	Scheduleで全Podを15秒ごとにKill	起動→即killを繰り返し、再起動では止まらない	原因のScheduleを削除して止める
bad-image	存在しないイメージタグに変更	新PodがImagePullBackOffで上がらず、全Pod停止	`rollout undo`／正しいタグに戻す
network-loss	NetworkChaosで通信を100%ロス	PodはRunning/Readyのままなのに通信が通らずヘルスチェック失敗	NetworkChaos CRを削除
svc-selector	Serviceのselectorを壊す	PodはReadyだがEndpointsが空になり、宛先ゼロで全リクエスト失敗	selectorを元に戻す

継続注入型(pod-kill／network-loss)は、Podをいくら再起動しても直らない。原因のCRを削除できるかがポイント。
svc-selectorは「Podは健全なのに全部失敗する」ので、endpointsやdescribe svcまで見にいけるかで挙動が分かれる。

# scenarios/01-pod-kill.yaml（抜粋）: 全Podを継続的にkillするSchedule
apiVersion: chaos-mesh.org/v1alpha1
kind: Schedule
spec:
  schedule: "@every 15s"
  type: PodChaos
  podChaos:
    action: pod-kill
    mode: all
    selector: { namespaces: [demo], labelSelectors: { app: podinfo } }

4. 自律復旧エージェントの設計

調査(読み取り)で根拠を得てから、最小限の書き込みを行うようsystem promptで誘導する。
止血の考え方を明示する: 継続注入する実験リソース(Schedule/NetworkChaos)が原因なら削除して止める。
安全策として、deleteはPodとChaos Mesh CRだけに限定した。

# system prompt（要約）
あなたはオンコールのSRE。demoのみ操作可。読み取りで根拠を得てから最小限の書き込み。
継続注入の実験リソースが原因なら削除して止める。復旧したら「RESOLVED: <一行>」だけ返す。

計測は各試行で「クリーン化→注入→障害が効いたか確認→エージェント起動→復旧待ち(MTTR計測)→後片付け」を
スクリプト化して自動で回した。

5. 検証結果

全7モデル×5シナリオ×3回=105試行を実施。全試行が100%復旧に成功した。
以下は各モデルの所要時間(MTTR)と手数の記録。
(MTTRはエージェント起動〜ヘルスチェック回復までの実時間で、モデルの推論レイテンシを含む。)

5-1. モデル別の記録

モデル	試行	成功率	平均MTTR(s)	平均ツール数
deepseek-ai/deepseek-v4-flash	15	100%	10	9.3
deepseek-ai/deepseek-v4-pro	15	100%	211	11.1
google/gemma-4-31b-it	15	100%	8	7.2
moonshotai/kimi-k2.7-code	15	100%	12	9.5
openai/gpt-oss-120b	15	100%	6	7.2
qwen/qwen3.6-27b	15	100%	21	8.1
zai-org/glm-5.2	15	100%	78	7.7

5-2. シナリオ×モデル（平均MTTR、すべて成功率100%）

シナリオ	gpt-oss	gemma	ds-flash	kimi	qwen	glm	ds-pro
scale-zero	8s	8s	12s	39s	27s	45s	478s
pod-kill	6s	4s	6s	5s	14s	100s	418s
bad-image	10s	16s	11s	11s	22s	90s	33s
network-loss	6s	6s	9s	5s	30s	118s	50s
svc-selector	2s	6s	14s	3s	14s	38s	77s

難所として設計したsvc-selectorが、多くのモデルで短時間で解けた。症状が一意だと迷いようがなく、逆に単純な障害
(scale-zero)ほど余計な情報に惑わされる余地がある。

5-3. ケーススタディ（トレースの抜粋）

最短で復旧できた例(gpt-oss-120b × svc-selector): 4手・2.6秒で解決。
get pods(Podは全部Ready)→get svc(selectorがapp=podinfo-BROKENと発覚)→describe pod→patch svcで
selectorを戻す。「Podは健全なのに疎通しない→Service/Endpointsを見る」という定石を踏んだ。
手数が増えた例(deepseek-v4-pro × scale-zero): 過去実行で残った古いReplicaSet(does-not-exist-9.9.9)を
rollout履歴に見つけて「イメージ障害」と解釈し、rollout undo→scale→set imageと対応が重なった(最大20手)。
情報が多いと、単純な障害でも診断の枝が増えることがある。

6. モデルごとの挙動

各モデルの挙動をトレースから個別に整理した。

gpt-oss-120b: 調査は最小限で、原因を掴んだら即修復する傾向。手数は少なめ(平均7.2)。
gemma-4-31b-it: gpt-ossに近い挙動で、手数も少なめ(平均7.2)。
deepseek-v4-flash: 手数はやや多め(平均9.3)だが、素直に復旧まで到達する。
kimi-k2.7-code: MTTRは12秒前後、手数は平均9.5。計測中に一時的な推論レイテンシ増(endpoint負荷)で1試行だけ長引く場面があった。
qwen3.6-27b: MTTRはやや長め(平均21秒)・手数もやや多めだが、全シナリオで復旧した。
glm-5.2: 手数は少なめだが、MTTRが回によってぶれる(network-lossで20〜198秒)。
deepseek-v4-pro: 判断は的確だが手数が多くMTTRが長い。単純なscale-zeroで古いReplicaSet履歴に反応した過剰診断や、
pod-killでの長い推論時間が見られた。

7. 考察

今回の難易度帯では全7モデルが100%成功した。成否では差がつかず、所要時間や手数といった挙動に個性が出た。
モデルによって調査の深さや手数、推論レイテンシが異なる。MTTRは推論レイテンシを含む点に注意。
単一障害点のような明快な障害であれば、小さなモデルでも実用的に自律復旧できた。多段障害など難易度を上げるとどう変わるかは今後の課題。

8. コスト（実験を回すのにかかった費用）

本計測(105試行)にかかったai& APIの費用は、トライアルクレジット($50相当のプロモコード付与)の範囲内に収まった。200円もかからなかった

9. まとめ

OpenAI互換のai& Inferenceのおかげで、接続先を差し替えるだけで同じコードのまま全7モデルを試せた。
障害対応はtool-callingの出来がそのまま結果に出る題材で、全モデルが100%成功しつつ、所要時間や手数に挙動の違いが出た。
単一障害点であれば小さなモデルでも実用的に自律復旧できた。用途に合うモデルを選べばよい、という手応えが得られた。