マルチエージェントを自律的に運用する -振る舞い劣化の隔離と回復-

はじめに:マルチエージェント時代の新しい障害

AIエージェントを複数組み合わせて業務を回す「マルチエージェント」が、少しずつ現実的になってきました。Agentic Webやマルチエージェントによる創発なども注目されています。これらが現実化されていくと、マルチエージェントで構成されたシステムを運用する必要が増していきます。

マルチエージェントではこれまでのアプリケーションと異なる種類の障害を考える必要があります。プロセスが落ちる、応答が返らない、といった話ではありません。応答は返る。結果の形式も正しい。でも、出す結論の質が下がっているという状態です。本記事では、この状態を「振る舞い劣化」と呼びます(1.2 で定義します)。従来の死活監視や性能監視には、この障害は映りません。

本記事は、この「振る舞い劣化」を題材に、マルチエージェント時代の運用として、何を考えなければいけないのかを、論文に刺激されて(1.3 で紹介します)、手元のPCで試しながら確かめたものです。具体的には、次の4つを検証しました。

1. 観測(何を見るか): 劣化を映し出す信号は何か。今回は、各エージェントの出力に付けるレビュー点(6章)
2. 検知(いつ異常と判断するか): 信号から「持続的な劣化」と判定するルール。今回は、悪い点が直近10件で2件以上なら要注意、4件以上なら隔離(7章)
3. 制御(どう守るか): 判断を受けた自動対応。切り替え(Takeover)・隔離・復帰(7・8章)
4. コスト(いくらかかるか): 守るために増える処理量(8章)

先に要点です。検証では、振る舞い劣化を2種類入れました。D1 は「指示の脱落」(エージェントへの指示から、出力する項目を1つ抜く)、D2 は「証拠無視」(判断に必要な証拠を見せない)です(3.4 で説明します)。数値は、D1 を10試行、D2 を5試行した結果の平均です(±は95%信頼区間)。ここでの試行は、タスクの並びと劣化の起こり方を変えて、同じ検証を繰り返す1回分のことです(コード上は乱数の種=seed を変えて切り替えます)。

• 何をしたか: 手元のPC1台のローカルLLMで、6体のエージェントによる IT インシデント分析システムを構築。1体を意図的に劣化させ、監視・検知・自動制御(切り替え・隔離・復帰)を検証。
• 守る仕組み(2段構え):
  • その場を守る: 出力を別のレビュアーが採点。不合格なら待機役が代わりに処理(Takeover)。
  • 次から守る: 悪い点数が続けば隔離し、待機役へ切り替え。回復テストに受かれば復帰。
• 検証結果:
  • 劣化中のタスク成功率(D1):何もしない場合は 0.64 ± 0.04。仕組みを入れた場合は 0.95 ± 0.01。
  • D1 で成功率を守ったのは、主に「その場の切り替え」。隔離の効果は、切り替え回数の約4割減(45.6回 → 26.0回)と動作の安定。
  • D2(証拠無視):その場の切り替えだけでは 0.81 ± 0.07。隔離(点を溜めて判断)を加えると 0.88 ± 0.05。悪い点1回で隔離(B2)は 0.94 ± 0.02 とさらに高いが、誤隔離は 8.4回/実行。レビューが見逃す劣化には、隔離が効く。
  • 「悪い点が1回出たらすぐ隔離」する単純な方式:健全なエージェントの誤隔離が多発(1回の実行あたり 8.6回 対 1.2回)。点を溜めて判断する方式も、ゼロではない。
  • 見分けやすさ:指示の脱落(D1)は、機械的なルールチェックで完全に見分けられた。証拠無視(D2)は、LLM のチェックだけでは見分けにくい(0.77)。
• 運用で考えること: チェックの追加による処理量の約2倍化(呼び出し 2.1〜2.2倍、トークン 2.5〜2.7倍)/レビュアーの質という全体の上限/見分けやすさを決める「機械的に確かめられるルール」の有無。
• 注意: 論文の数値の再現ではない。単一モデル・疑似データでの検証。

1. 背景:死活監視や性能監視では見えない障害

私が SRE(Site Reliability Engineering)の立ち上げを会社で始めたころ、「性能劣化」は新しいタイプの"障害"として語られていました。サービスは動いている。エラーも出ていない。でも遅い。落ちていないのに、ユーザー体験は壊れている。それを捉えるために、ユーザーシーケンスを明らかにし、SLA/SLO を定義し、計測するということをしていました。

今後、多数のAIエージェントが協調して動くようになれば、そこにはまた新しい種類の障害を捉える必要が出てきます。

1.1 Gray Failure とは

Gray Failure は、Huang らが2017年の論文『Gray Failure: The Achilles' Heel of Cloud-Scale Systems』(HotOS '17)で整理した概念です。ざっくり言うと、アプリケーション(利用者)の側からは異常に見えるのに、監視する側(障害検知の仕組み)からは正常に見えている状態です。論文は、この見え方の食い違いを differential observability(観測の差)と呼んでいます。

死活監視は「正常」と言っているのに、利用者は壊れた体験をしている。前述の性能劣化は、その典型でした。

1.2 Behavior Degradation(振る舞い劣化)とは

この考え方を AI エージェントに当てはめた Agent Behavior Degradation(振る舞い劣化) についての Gray Failure を考えます。

• 監視する側から見ると、エージェントは正常です。 応答する。結果の形式も正しい。プロセスも生きている。HTTP も 200 を返す。
• ところが、出す結論の質が下がっています。 結論が間違っている、手順を一部飛ばしている、証拠を読み違えている。
• その結論は後続のエージェントに渡り、最終的なタスクの結果(アプリケーション側)に、異常として現れます。

つまり、「観測の差」が、AIエージェントでは**「形式は正しいのに、中身が悪い」**という形で現れます。結論が劣化したエージェントが1体いると、後続のエージェントがその結論を前提に動くため、マルチエージェント全体の信頼性に影響します。

なお、LLM は健全なときでも、たまに間違えます。単発の間違いと、持続的な劣化は区別する必要があります。この区別は、検知の設計の中心になります。

1.3 検証のベースにした論文

この問題を扱った論文として、『MeshHeal: Two-Timescale Self-Healing for Gray Failures in Decentralized LLM Agent Networks』(arXiv:2609.29015)を見つけました。劣化したエージェントを一時的に隔離する、という発想が示されています。この論文に刺激されて、実際に劣化の監視と検知と自動制御を試してみることにしました。 特に参考にしたのは、次の「二重時間スケール」の考え方です。

時間スケール	守る対象	やること
速い(fast)	今のタスク	出力をレビューし、怪しければ確認して、必要なら修正してから使う
遅い(slow)	将来のタスク	レビューの履歴から持続的な劣化を見つけ、隔離し、回復を確かめて戻す

ただし、本記事は論文の数値の再現ではありません。論文では、劣化を、強いモデルを弱いモデルに差し替えて作っています。また論文は、エージェント同士が互いにレビューし合う分散型のネットワークを対象にしていますが、本記事は、専用のレビュアーとヘルスモニタを置く集中型の構成で実装しました。また、論文の検出器は、同じ種類のタスクを担う他のエージェントとの相対的な差(ピア相対)で劣化を判断しますが、本記事は、既定では点の絶対値で判断しました(ピア相対は、7章の記録の再生でだけ試しています)。「必要なら修正する」方法も違い、論文は複数のレビュアーが修正案を作りますが、本記事の Takeover は、待機役が処理を代わりに実行します。本記事では、同じモデルのまま、振る舞いだけを悪くする(指示の一部を抜く、証拠を見せない)形に問題を設定し直し、運用として何を考えるべきかを確かめました。

なお、検証のために作ったマルチエージェント群も、題材が IT の障害対応(インシデント対応)エージェントなので、少し紛らわしいのはご愛敬です。

2. 検証環境

2.1 環境

検証は1台のPCで行いました。

• Windows 11 Pro + WSL2(Ubuntu)
• NVIDIA GeForce RTX 5070 Ti(VRAM 16GB)
• ローカルLLMの実行基盤は Ollama(Windows 側で稼働し、WSL から localhost で利用)

マシンスペックの制約を考慮し、小さなモデルを使い、回数を回しながら検証することで、1回ごとのばらつきの影響を小さくします(試行を重ねて平均を取ります)。検証で使った3モデルについて、JSON 形式の出力を8回ずつ試した結果の速度を示します。

モデル	検証での使いどころ	JSON 形式の準拠	中央値の応答時間	生成速度	VRAM(読み込み後の使用量)
nemotron-3-nano:4b	エージェント本体 A1〜A6 と待機役	100%	465 ms	219 tok/s	3.9 GB
hermes3:8b	弱いレビュアー。レビュアーの強さの比較に使用	100%	752 ms	153 tok/s	8.9 GB
qwen3:14b	レビュアー・Committee	100%	1277 ms	82 tok/s	10.4 GB

エージェント本体(6体と待機役)は、最も速い nemotron-3-nano:4b を共有して使います。論理エージェントが6体いても、モデルの実体は1つです(エージェントごとに、プロンプト・役割・履歴だけを分けています)。レビュアーは、あとで述べる理由で qwen3:14b にしました。hermes3:8b は、レビュアーの強さで結果がどう変わるかを比べるために使っています。エージェント本体と qwen3:14b の2つのモデルは、VRAM に同居できます(両方を読み込んだ実行中の nvidia-smi で約13.6GB)。

2.2 6体のエージェント

今回検証のために使用したエージェント群は、IT インシデントの初動対応を自律的に行うための自作エージェント群です。アラートの文面、メトリクス、ログ、手順書(Runbook)が入力で、6体が順番に分担して最終報告を作ります。以降、「処理」は A1〜A6 の各エージェントが担当する1ステップを指し、6体の処理を A1 → A6 の順につないだものを「本番の処理経路」と呼びます。

ID	名前	機能
A1	インシデント分析	アラートの文面から、インシデントの種類(CPU飽和、メモリリーク、ディスク枯渇、DB接続枯渇、不良デプロイ、DNS障害)を分類する
A2	ログ分析	メトリクスとログから、エラーの特徴と、異常な指標を抜き出す
A3	知識検索	知識ベースから該当する手順書を選び、必要な手順と安全確認を列挙する
A4	影響分析	影響を受けるサービスと、深刻度(P1〜P3)を判定する
A5	対処計画	手順書をもとに、実施する手順と、事前の安全確認を決める
A6	報告	上流の結果をまとめて、最終報告を作る

6体とも LLM と接続しています。各エージェントには、健全な待機役(A1b〜A6b)が付いています。同じ役割・同じプロンプト・同じモデルで、いざというときの代わりを務めます。実運用では障害時に自動リリースしたりバックアップから戻したりして動かすということを想定します。本検証では、待機役を常に起動しておく前提で、起動にかかる時間は含めていません。

2.3 コンポーネント

運用のコンポーネント。 本番のシステムに組み込み、エージェント群を監視・コントロールします。「方式」は、ルールで動くのか、LLM と接続して判断するのかを表します。

コンポーネント	方式	役割
ルータ	ルールベース(実行する待機役は LLM)	A1〜A6 の各処理を実行する直前に、各エージェントの健全性を記録したルーティング表を見て、通常系か待機系かを選ぶ。表は参照するだけ。Takeover: Committee が不合格を確認したときは、その処理を待機系に任せ、待機役が代わりに実行した出力に切り替える
レビュアー	ルールベース + LLM	各エージェントの出力を採点する。ルールチェックと、LLM(qwen3:14b)による採点を合算する。ルールチェックは、必須項目が揃っているか、手順書の内容と一致しているか、など
Committee	LLM	不合格になった出力を、もう一度採点して確認する。採点方式はレビュアーと同じだが、ルールチェックは同じ出力なら同じ結果になるため、実質は LLM(qwen3:14b)の再採点。温度を上げて呼び直し、別のサンプルで採点する。ルールチェックで不合格の出力は、Committee でも不合格のままで、覆せるのは LLM の点による不合格だけ
ヘルスモニタ	ルールベース	レビューの点を溜めて、各エージェントの状態を決め、ルーティング表を更新する。状態は NORMAL / WATCH / ISOLATED / PROBING の4つ。しきい値と状態遷移だけで動き、LLM とは接続しない。回復テスト: 隔離中のエージェントに、3タスクごとに、本番と同じ入力を流して試すシャドウトラフィックを実行させる。実行するのは隔離中のエージェント(LLM)、採点はレビュアー。出力は本番に使わず、採点結果で復帰を判断する
イベントログ	-	すべての出来事を JSONL で追記する。「検出側が見てよい情報」と「検証用の正解」を分けて記録する

検証のためのコンポーネント。 検証のためだけに用意したもの。本番には要りません。

コンポーネント	方式	役割
障害注入器	ルールベース	指定したエージェントに、確率で劣化を意図的に入れる
正解スコアラー	ルールベース	あらかじめ決めた正解と照合して、成績をつける。動作中には使わない

2.4 構成図

図A-1 通常時(全処理を通常系で実行。不合格のときだけ Takeover)

図A-2 A3 が隔離されているとき(A3 の処理だけ待機系の A3b が実行。隔離中の A3 には、ヘルスモニタが回復テストだけを送る)

読み方のポイントです。

• 処理が通るのは「本番の処理経路」の1行だけです。エージェントの処理ごとにルータがルーティング表を引き、通常系か待機系かを選びます。隔離中の通常系は経路に入らず、図A-2 の A3 は本番の出力を一切作りません。
• ヘルスモニタは処理経路の外にあります。レビューのスコアを溜めてルーティング表を更新するだけで、リクエストの通り道には入りません(本検証の実装では、各処理の直後に更新します)。表の更新は次のタスクから効きます。
• 処理経路に入るチェックはレビューだけです(その場を守る高速パス)。通常系の出力が不合格なら、Committee が LLM で再採点して確認し、Takeover でルータが処理を待機系に任せ、待機系が代わりに処理した出力に切り替えます。
• 回復テストを送るのは、ヘルスモニタです。 ヘルスモニタは、エージェントごとの状態を持っています。隔離中(ISOLATED)のエージェントには、3タスクごとに実際のタスク入力を流して試します(図A-2 の A3)。出力は本番に使わず、レビューが採点して、その結果でヘルスモニタが回復を判定します(連続3回合格で復帰)。

3. 検証の概要

3.1 何をしたか

6体で分担する IT 対応の中の1体(主に A3)の出来を、意図的に悪くしました。そのうえで次の3つを測りました。

1. 劣化を見つけられるか
2. その場で被害を防げるか
3. 切り離して、直ったら戻せるか

3.2 比べた4つの戦略

名前	戦略の内容
B0	何もしない(劣化したエージェントを使い続ける)
B1	出力を採点して、不合格なら待機役が代わりにやり直す(その場の対処だけ)
B2	悪い点を1回取ったらすぐ隔離する(単純なしきい値で評価。回復テストと復帰の条件は B3 と同じ)
B3	悪い点が直近10件で何回か溜まったときだけ隔離する(様子見の段階を挟む。隔離後は回復テストを経て復帰)

3.3 「採点」の定義と、劣化の測り方

「採点」という言葉は、この記事では2種類あります。最初に区別しておきます。

• 正解採点(検証用): 疑似的に作ったインシデントデータには、あらかじめ正解(分類名・深刻度・影響範囲・使うべき手順書・実施手順・安全確認)が決まっています。プログラムが出力と正解を照合して、項目ごとに○×を付けます。人や LLM の判断は使わないので、結果がぶれません。システムの動作中には使わず、あとから成績をつけるためだけに使います。

• レビュー採点(運用側): 動作中にレビュアーが付ける 0〜1 の点数です。正解は知りません。次の2つを半々で合算します。

  • (a) ルールの機械チェックの合格率(必要な項目が揃っているか、手順書の内容と一致しているか など)
  • (b) LLM が「入力に照らして妥当か」を採点した点

  この点が 0.85 未満なら「低い」。「低い」またはルールに1つでも不合格があれば、その出力は「不合格」(その場の切り替え Takeover の対象)になります。隔離の判断に数えるのは「低い」のほうです。

劣化は、「結果」で測りました。 劣化を入れる設定にしたからといって、システムが実際に悪くなったとは限らないからです。測るのは、正解採点による次の2つです。

メトリクス	何を測るか
出力の誤り率(注入したもののうち)	劣化を入れた出力が、実際に誤り・欠落になった割合。「注入したのに偶然正解だった」ものは、数えません(意味的な劣化で起こります)
タスク成功率	最終報告の6項目(分類・深刻度・影響範囲・手順書・実施手順・安全確認)がすべて正解だったタスクの割合

これ以外のメトリクス(注入率、レビュー点、見分けやすさ、検出の遅れ、誤隔離、処理量など)は、劣化そのものではなく、検証のためのメトリクスです。検証した項目ごとに、4〜9章で説明します。

3.4 劣化の種類

同じモデルのまま、振る舞いだけを悪くします。今回は2種類です。

種類	内容	注入する場所
D1 指示の脱落	A3 に渡す指示文(プロンプト)の中の、出力する項目の一覧から、手順・安全確認・出典のどれか1つを抜く。指示にない項目は出力されない(出力された場合は、あとから取り除く)。応答も形式も正常のまま	A3
D2 証拠無視	A4 に渡す入力のうち、依存関係とエラー率の部分を、「証拠は取り込まれない」という意味の定型文に置き換える。エージェントは証拠を見られないまま答える	A4

注入は確率で行います。劣化の強さは L0〜L4(0%・10%・30%・50%・80%)で、D1 の検証(以降「E1」)では「健全(タスク1〜30)→ 弱(31〜45)→ 強(46〜60)→ 最強(61〜80)→ 回復(81〜100)」の順に変えました。

3.5 検証した仮説

• H1: 悪い状態は、採点の点数に表れる
• H2: 点数を溜めて判断すると、誤って隔離する回数が減る
• H3: 隔離と切り替えで、劣化中も成功率を保てる
• H4: 回復テストに連続で受かるまで戻さなければ、悪い状態のまま戻してしまわない
• H5: 証拠無視のような意味的な劣化は、指示の脱落のような構造的な劣化(中身が欠ける)より見つけにくい

3.6 検証した項目

#	検証した項目	知りたかったこと	関係する仮説	章
1	システム自体の動作	劣化がないときに安定して正解を出せるか	-	4
2	劣化の注入	注入が狙いどおりか/検出する側が「いつ劣化を入れたか」を知らない状態で検証できているか	-	5
3	採点による見分けやすさ	劣化は点数に表れるか/レビュアーのモデルで変わるか	H1, H5	6
4	隔離・復帰の判断	誤隔離せず、劣化だけ隔離し、回復後に戻せるか	H2, H4	7
5	実際に守れるか・コストはどのぐらいかかるか	劣化中も成功率を保てるか/B0〜B3 の差/増える処理量	H3	8
6	再現性と意味的劣化	試行を変えても同じか/D2 でも同じか	H3, H5	9

4. 検証1:システム自体が正しく動くか(健全時のベースライン)

検証項目: 障害を入れる前に、劣化していないシステムが安定して正解を出せるか。

検証内容: 疑似的に作ったインシデントデータと、自動採点(3.3の「正解採点」)を用意しました。劣化を入れない状態で動かし、成功率を測って、悪い所を直しました。

使ったメトリクス: タスク成功率(健全なときの成功率)と、エージェントごと・項目ごとの正解率(どこで間違えているかを特定するため)。どちらも正解採点です。

検証結果: 最初の成功率は 0%(0/25) でした。原因を調べると、エージェントの問題というより、作りの問題が2つありました。

版	直したこと	結果
p1	(最初の版)	成功 0/25。A4 の影響範囲が 0/25、深刻度が 40%、A1 の分類が 76%
p2	A4 に渡す情報を絞る(全サービスの依存マップ → 失敗したサービスの依存先だけ)	A4 の影響範囲が 25/25 に。A1 の分類は 76% → 80%
p3	カテゴリ名 disk_full を disk_space_exhausted に変更。A4 に深刻度の対応表と件数フィールドを追加	A1 の分類が 100% に。深刻度は 83%
p4	A4 に「エラー率が8以上か」を判定するフィールドを追加	成功 39/40(97.5%)

ちなみに、disk_full の問題は、モデルが出力で disk_ful と最後の1文字を落とす癖でした。この単語で再現しました。名前を変えるだけで直りました。残る1件の失敗は、モデルの自然な間違いです。

示唆: 障害を入れる前にベースラインを固めないと、「劣化」と「作りの不具合」を区別できません。最初の成功率 0% のまま劣化を注入していたら、「劣化のせいで失敗した」と誤解してしまいます。

5. 検証2:注入した劣化が狙いどおりか、検出する側に「答え」が漏れていないか

検証項目:

• (a) 注入した劣化が、実際に出力へ現れているか
• (b) 注入の頻度が、設定どおりか
• (c) 検出する側(レビュアー・ヘルスモニタ)が、「いつ・どこに劣化を入れたか」を知らない状態で検証できているか

(c) の意味: 検出する側が劣化を入れたタイミングを知っていたら、見つけられて当たり前(カンニング)になり、検証の意味がなくなります。そのため、劣化を入れるコンポーネント・正解採点のコンポーネントと、検出する側のコンポーネントを分けました。

検証内容: ログを「検出側が見てよい情報(obs)」と「検証用の正解(gt:注入の記録など)」に分け、検出側には前者だけを渡す作りにしました。後者が混ざらないことは、テストで確認しています。

使ったメトリクス

メトリクス	何を測るか	測り方
注入率	劣化を入れる設定にしたタスクのうち、実際に入れた割合(設定した確率どおりか)	注入の記録を区間ごとに数える
出力の誤り率(注入したもののうち)	注入した出力が、実際に悪くなった割合	正解採点
注入なしで欠落・誤りになった数	注入していないのに悪くなった出力の数(0 なら、悪化は注入のせい)	正解採点

検証結果(D1:指示の脱落、A3 に注入、何もしない B0 の実行。試行1)

区間(タスク)	設定の確率	注入された数	注入のうち欠落を確認	注入なしで欠落	タスク成功率
1〜30(L0)	0	0/30	-	0/30	1.00
31〜45(L1)	0.1	3/15	3/3	0/12	0.87
46〜60(L3)	0.5	9/15	9/9	0/6	0.47
61〜80(L4)	0.8	17/20	17/17	0/3	0.50
81〜100(L0)	0	0/20	-	0/20	0.95

• 注入した29件のすべてで、出力の欠落が確認できました。注入していないのに欠落した例は0件でした。
• 劣化中も、A3 は応答し、結果の形式も正しいままでした(「止まらずに中身だけ悪くなる」状態の再現)。
• 注入された割合は、設定した確率の統計的な許容範囲(3σ)に収まりました。

D2(証拠無視) は、A4 に注入しました(9章の5試行のうち、何もしない B0 の記録 500件)。注入された出力は114件で、そのうち実際に誤りだったのは 88件(77%) でした。残りの26件は偶然正解でした(証拠を見なくても、深刻度が P3 で影響範囲が1サービスの場合は当たってしまう)。意味的な劣化は、「いつも間違い」にはなりません。注入していない出力386件の誤りは、0件でした。

図で確かめる: 下の図は、何も対処しない B0 の実行です。

タイムライン図の読み方

縦に5段を並べ、横軸(タスク番号。図中の表記は task index)を共通にしてあります。上から下へ、因果の鎖を追うための図です。図の中の文字は英語なので、対応を表にしました。

段	図の中の表記(英語)	何が見えるか	見方
(1)	(1) injection probability (ground truth)	検証側が設定した劣化の強さ(注入の確率、0〜0.8)	持ち上がった所が劣化の始まり
(2)	(2) review score of the degraded agent (A3)	A3 の出力に付いたレビュー点。破線は 0.85(これより下が「低い」)	劣化すると点が落ちる。点がない所は、A3 が本番で使われていない期間(隔離中)。図中の注記 no point: A3 is not used in production (served by the standby) がこれを表す。B0 では B0: no review(レビューをしない)と出る
(3)	(3) health state of A3	A3 の状態(NORMAL / WATCH / ISOLATED / PROBING)	低い点が続くと WATCH → ISOLATED。隔離中の PROBING は回復テストの最中
(4)	(4) actions	上から A3 step run by the standby(A3 の処理を待機系が実行)、takeover (output replaced)(Takeover:出力を切り替えた。A3 以外のエージェントの Takeover も含む)、recovery probe(回復テスト)	縦線1本=1回の出来事
(5)	(5) task result (green=success, red=failure)	タスクごとの結果。緑=成功、赤=失敗	赤が少ないほど守れている

図の下の注記 shaded = ground-truth degraded interval, dotted line = true recovery. Only the degraded agent (A3) is plotted. は、網掛け=劣化の区間(正解)、点線=本当の回復、図に出るのは劣化を入れた A3 が中心という意味です。ただし takeover の行だけは、すべてのエージェントの Takeover を含みます。図の上の題 B0 (seed 1) success in degraded interval = 0.60 は、戦略(B0)、試行(seed 1 は、乱数の種で試行を切り替える番号で、試行1のこと)、劣化区間のタスク成功率(0.60)です。

読み取りの手順は、「(1)が上がる → (2)の点が下がる → (3)の状態が変わる → (4)で待機系に切り替わる/出力が置き換わる → (5)の赤が減る」です。この順に見ると、劣化 → 検出 → 隔離 → 保護 → 回復 → 復帰の鎖が1枚で確認できます。

B0 では(2)〜(4)が空です。レビューも監視もしないからです。そして(1)が上がるのに合わせて、(5)に赤(失敗)が増えます。何も守らなかったときの被害そのものです。

6. 検証3:採点で劣化を見分けられるか(仮説 H1・H5)

検証項目: 悪くなった出力は、採点の点数で見分けられるか。レビュアーのモデルの強さで変わるか。ルールによる機械チェックは効くか。

検証内容: 3.3で定義した「レビュー採点」(機械的なルール確認と LLM による採点の合算)を使い、劣化した出力と正常な出力を、点数でどれだけ分けられるかを測りました。記録済みの出力を、あとからレビュアーに通して測っています。

使ったメトリクス

メトリクス	何を測るか	測り方
ルール合格率	必要な項目が揃っているか、手順書と一致しているか、などの合格割合	正解を使わず、入力と出力だけで判定(ルールベース)
LLM の採点	「入力に照らして妥当か」を、レビュアーが付けた 0〜1 の点	qwen3:14b など
レビュー点(合算)	動作中に見える点数	0.5 ×(ルール合格率)+ 0.5 ×(LLM の採点)
見分けやすさ(AUROC。説明は表の下)	悪い出力と良い出力を、点数でどれだけ分けられるか。1.0=完全に判別できる、0.5=当てずっぽう	悪い出力と良い出力の全ペアで、良い方の点が高い割合

AUROC(Area Under the ROC Curve) は、2つのグループを点数でどれだけ分けられるかを、0〜1 で表す評価指標です。ここでは、悪い出力と良い出力を1つずつ取り出して点数を比べたとき、良い出力のほうが点が高くなる確率として読めます。1.0 なら必ず良い出力のほうが高く(完全に分けられる)、0.5 なら当てずっぽうと同じです(点が同じ場合は、半分(0.5)として数えます)。

この記事での「悪い出力」は、D1 では注入した出力、D2 では実際に誤った出力(偶然正解した出力は含めない)としました。

D1(指示の脱落):A3 の出力、注入あり29件 vs 注入なし71件(試行1の記録)

信号	見分けやすさ(AUROC)
ルールの機械チェックのみ	1.000
LLM のみ(hermes3:8b)	0.674
LLM のみ(qwen3:14b)	0.818
ルールと LLM の合算(hermes3:8b)	0.918
ルールと LLM の合算(qwen3:14b)	0.989

D1 は「必須の項目が欠けている」という構造的な欠落なので、ルールの機械チェックだけで完全に見分けられました。LLM の採点だけでは、欠落を見逃すことがありました(hermes3:8b は安全確認の欠落を、qwen3:14b は出典の欠落を、ほぼ満点と採点しました)。

レビュアーの強さで変わる

レビュアーを hermes3:8b にしたところ、A2 の正しい出力100件のうち54件に0点を付けました。たとえば、エラー率 23.9% を見て「8% を下回っている」と判断するような推論ミスです。qwen3:14b に変えると、A2 の0点は 1/100 まで減りました。

弱いレビュアーは、健全なエージェントに悪い点を付けるので、隔離の判断に使うと誤隔離の原因になります。以降のレビュアーは qwen3:14b にしています。

ただし、qwen3:14b も万能ではありません。A1 の出力は、系統的に低く採点しました。たとえば、アラート文「autoscaler is maxed out」を CPU 飽和と分類した正しい出力を、「CPU 飽和は書かれていない」と判定するなどして、正しい A1 の出力100件のうち18件に0点を付けています(試行1)。8章以降の誤隔離や、不要な Takeover の主な原因の1つです。

D2(証拠無視):A4 の出力、実際に誤った88件 vs 正しい412件(5試行の B0 の記録)

信号	ルールが「構造チェックのみ」	ルールに「証拠との整合チェック」を追加
ルールの機械チェックのみ	0.614	1.000
LLM のみ(qwen3:14b)	0.769	0.769
ルールと LLM の合算	0.769	0.993

(5試行の500件をまとめた値です。試行ごとに求めた平均は、LLM のみが 0.77 ± 0.06、構造チェックのみのルールが 0.62 ± 0.09 で、整合チェックを追加したルールは5試行とも 1.000 でした。)

D2 では、LLM だけだと 0.77 で、D1 のルールチェック(1.0)より見分けにくい結果でした。「影響範囲が依存関係の一覧と一致するか」「深刻度が規則どおりか」のように、入力から計算で確かめられるルールを足すと、0.99〜1.0 になりました。

見分けられるかは、機械的に確かめられるルールがあるかで決まるというのが、この章の結論です。

7. 検証4:隔離と復帰の判断は正しいか(仮説 H2・H4)

検証項目: 劣化したときだけ隔離でき、健全なエージェントを誤って隔離せず、回復したら安全に戻せるか。

検証内容: 下の状態を持つヘルスモニタ(ルールベース)を作り、試行1で記録済みのレビュー点を再生して、判断の良し悪しを測りました。隔離中の回復テストは、その時点の本番の記録で代用しています。設定を変えた場合の違いも調べています。

単発の間違いは LLM の通常のばらつきとみなし、直近10件のうち、点が「低い」ものが2件以上で要注意(WATCH)、4件以上で隔離とするのが既定の設定です。しきい値(0.85)は、試行1の A3 の注入なしの出力71件のスコア分布(平均 0.993、標準偏差 0.059)から、スイープの前に決めました(平均 − 2.5σ ≒ 0.85)。結果を見てから都合のよい値に合わせないためです。窓10件・2件・4件は、分布から決めた値ではなく、既定として先に置いた値です。ほかの試行(8章・9章)は、これらの値を固定して実行しました。

使ったメトリクス

メトリクス	何を測るか	測り方
窓内の「低い」点の件数	直近10件のうち、点が低いものの数。持続的な劣化かどうかの判断材料	レビュー点(0.85 未満を「低い」)
検出の遅れ	劣化が始まってから、最初に隔離されるまでのタスク数	注入の区間と、隔離の記録の差
誤隔離	健全なエージェントを隔離した回数	隔離の記録と、その時点の正解(健全か)の突き合わせ
隔離が保たれた割合	隔離したあと、本当に直るまで本番に戻らなかったタスクの割合	隔離から回復までのあいだの、待機系で処理された割合
早すぎる復帰	本当に直る前に、復帰させてしまった回数	劣化の区間内の復帰の回数
復帰の遅れ	本当に直ってから、復帰させるまでのタスク数	回復の時点と復帰の記録の差

検証結果(A3、タスク31〜80が劣化、81が回復)

• 劣化の強い期間(タスク46)が始まった3タスク後(49)に隔離され、本当の回復(81)の2タスク後(83)に復帰しました。劣化の開始(31)から数えた検出の遅れは18タスクですが、これは軽度の劣化(注入確率10%)の間は、点数にほとんど信号が出ないためです。
• 回復テストの途中で、運よく合格した場合(注入確率が100%ではないため)も、その後の失敗テストで隔離に戻り、劣化中に本番へ戻ってしまうことはありませんでした。

設定を変えたときの違い(記録の再生・qwen3:14b)

設定を、次の6つのカテゴリに分けて比べました。

カテゴリ	何を変えるか
A. 隔離する条件	悪い点が1回出たら隔離する(B2)か、溜めて判断する(B3)か
B. 様子見(WATCH)	要注意の段階を挟むか、挟まないか
C. 件数と窓の大きさ	直近何件のうち、悪い点が何件で隔離するか
D. 「低い」とみなす点	何点未満を「低い」とみなすか
E. 回復テストの条件	何タスクごとに試すか、何回合格で復帰するか
F. 判断の材料	点の絶対値で見るか、他のエージェントとの差(ピア相対)で見るか

表は、B2 → B3 の順に並べました。B0 と B1 は隔離をしないので、この表には出てきません。B3 の既定(直近10件で2件が要注意、4件が隔離、0.85 未満が「低い」、回復テストは3タスクごと・3回連続で合格)は、カテゴリ A の最後の行に置き、B〜F では、既定からその部分だけを変えた結果を示します。

カテゴリ	設定	検出の遅れ	隔離が保たれた割合	早すぎる復帰	復帰の遅れ	誤隔離
A. 隔離する条件	B2:悪い点が1回で隔離(「低い」=0.85 未満)	6	0.95	1	2	10
	B2:悪い点が1回で隔離(「低い」=0.5 未満)	6	0.68	3	0	1
	B3(既定):溜めて判断	18	1.00	0	2	1
B. 様子見(WATCH)	WATCH なし(2件で隔離)	11	1.00	0	4	7
C. 件数と窓	窓5件・2件で隔離	15	1.00	0	2	6
	窓10件・3件で隔離	15	1.00	0	2	4
	窓10件・6件で隔離	20	1.00	0	4	0
	窓20件・6件で隔離	19	1.00	0	0	1
D. 「低い」とみなす点	0.7 未満	20	0.83	1	0	0
	0.95 未満	18	1.00	0	8	8
E. 回復テスト	毎タスク試す	18	0.72	2	0	1
	6タスクごとに試す	18	1.00	0	11	1
	1回合格で復帰	18	0.28	3	0	1
	5回連続合格で復帰	18	1.00	0	8	1
F. 判断の材料	ピア相対(他のエージェントとの差で判断)	18	1.00	0	8	0

(誤隔離は、健全なエージェントの出力、約550件分(6体×100タスクから、A3 の劣化区間50タスクを除いたもの)で数えています。)

読み取れることは次のとおりです。

• H2(点を溜めて判断すると、誤隔離が減る)は支持されました。 同じ「低い」の基準(0.85)で、1回で隔離する方式(A の B2)は誤隔離10件、溜めて判断する方式(A の B3)は1件でした。B2 は「低い」とみなす範囲を 0.5 未満まで狭めると、誤隔離は1件に減りますが、隔離が保たれた割合が 0.68 に下がり、早すぎる復帰も3回に増えました。
• 様子見(WATCH)を挟まず、2件で隔離すると、誤隔離は1件から7件に増えました(B)。ただし本検証の実装では、WATCH 中も本番で使われ、振り分けは変わりません。この差は主に「何件で隔離するか」の違いです(C も参照)。
• 判断を急ぐほど誤隔離が増えます(C・D)。隔離の件数を6件にすると誤隔離は0件ですが、検出が遅れます。
• H4(連続で受かるまで戻さなければ、悪い状態のまま戻らない)は支持されました(E)。回復テストを1回の合格で復帰させると、隔離が保たれる割合は 0.28 まで下がります。3回連続を要求すると 1.00 で、復帰は少し遅れます。
• ピア相対(F)は誤隔離が0件でしたが、復帰が遅れました(復帰の遅れ 8)。

なお、レビュアーを hermes3:8b(弱い方)に替えて同じ既定設定を再生すると、隔離が保たれた割合は 0.38、早すぎる復帰は2回、誤隔離は2回になりました。レビュアーの質が、全体の上限になります。

8. 検証5:実際に守れるか・コストはどのぐらいかかるか(仮説 H3)

検証項目: 実際にシステムを動かして、劣化中のタスク成功率を守れるか。守るためのコストはいくらか。4つの戦略(B0〜B3)の違いは。

検証内容: 同じタスク・同じ劣化の条件で、B0〜B3 を実際に動かして比較しました(E1、各100タスク)。この章では代表例として試行1の結果を示し、10試行の平均は9章で示します。

使ったメトリクス

メトリクス	何を測るか	測り方
劣化中のタスク成功率	劣化の区間(タスク31〜80)で、守れたか	正解採点
Takeover の回数	どれだけ切り替えたか	Takeover の記録の件数(全エージェントの合計)
処理量	コストはいくらか	モデルの呼び出し回数・トークン数(B0 を 1.00 とした倍率)

試行1の結果です。

戦略	劣化中の成功率(31〜80)	全体の成功率	検出の遅れ	誤隔離	モデルの呼び出し	トークン
B0 何もしない	0.60	0.79	-	-	600(1.00倍)	266k(1.00倍)
B1 採点と切り替えのみ	0.98	0.98	-	0	1297(2.16倍)	697k(2.62倍)
B2 悪い点1回で隔離	0.98	0.98	6	8	1324(2.21倍)	703k(2.65倍)
B3 点を溜めて隔離	0.98	0.98	18(L3 開始から3)	0	1277(2.13倍)	685k(2.58倍)

区間別の成功率(健全 / 弱 / 強 / 最強 / 回復)は、B0 が 1.00 / 0.87 / 0.47 / 0.50 / 0.95、B1〜B3 が 1.00 / 0.93 / 1.00 / 1.00 / 0.95 でした。

検証結果

• 劣化中の成功率: B0 の 0.60 が、B1〜B3 では 0.98 になりました。
• 守ったのは、主に「その場の切り替え」です。 隔離のない B1 でも 0.98 に届きました(D1 は、1つの出力ごとの確認で見つけやすい劣化なので、切り替えだけで足りてしまいます)。
• D1(試行1)では、隔離の効果は、成功率ではなく処理量と安定性に出ました。(D2 では、成功率にも効きました。9章)Takeover の回数(全エージェントの合計)は、B1 の48回に対して B3 は25回でした。B3 は、隔離後は待機役が最初から処理するので、やり直しが約半分で済みます。
• B2(悪い点1回で隔離)は、誤隔離が8回(A1 が7回、A2 が1回)ありました。特に A1 は、隔離と復帰を何度も繰り返しました。B3 は0回でした(試行1の結果。10試行の平均は 1.2 回で、ゼロではありません。9章)。
• コスト: チェックを入れると、モデルの呼び出しは約2.1倍、トークンは約2.6倍です。大半はレビュー自身の費用(トークンの約55%)で、戦略による差は小さくなりました。

図で確かめる: B1・B2・B3 のタイムラインを並べます(読み方は5章を参照)。B0 は5章の図と見比べてください。

B1 は(3)が NORMAL のままで、(4)の takeover が多数(48回。全エージェントの合計)あります。それでも(5)の赤がほぼ消えています。その場の対処だけで守れていることが確認できます。

B2 は、早い時点(タスク37)で隔離しています。ただし、この図に出るのは A3 だけなので、健全な A1 の誤隔離は図に出ません(上の表の数字で示しています)。

B3 では、(2)の点が落ち続けたあと、(3)が WATCH(タスク42)→ ISOLATED(49)→ 回復テストを繰り返す → NORMAL(85)と動いています。(4)では、隔離中の A3 の処理を待機系が実行し(A3 step run by the standby)、takeover は減っています(25回)。劣化 → 検出 → 隔離 → 保護 → 回復 → 復帰の鎖が、1枚で確認できます。 (5)の赤は2か所だけで、どちらも劣化とは無関係な A1 の自然な誤り(タスク42・89)です。

限界: 切り替え先の待機役も同じモデルなので、モデルの自然な間違いは直せません。実際、A1 のタスク42・89 の誤りは、Takeover しても直りませんでした(A2 のタスク61の誤りも直りませんでしたが、最終報告には影響しませんでした)。

9. 検証6:試行を変えても成り立つか/意味的な劣化(D2)でも成り立つか

検証項目: 1回の偶然ではないか(D1 を10試行)。意味的な劣化でも同じ結論か(D2 を5試行)。

検証内容: タスクの並びと劣化の起こり方を試行ごとに変えて繰り返し、平均と95%信頼区間で比べました。D1 は10試行 × B0〜B3 の40回、D2 は5試行 × B0〜B3 の20回(各100タスク)です。D2 は A4 に証拠無視を注入し、劣化の強さを「弱(31〜40)→ 中(41〜50)→ 強(51〜65)→ 最強(66〜80)→ 回復(81〜100)」の順に上げました。D2 のレビュアーは、証拠との整合チェックを含まない設定(6章の「構造チェックのみ」で、LLM 単体の見分けやすさは 0.77)で動かしています。見つけにくい側の条件です。

使ったメトリクス: 4〜8章のメトリクスを、試行ごとに求めて、平均と95%信頼区間(試行間のばらつき)で示します。同じ試行の中では、タスクの並びと劣化の起こり方が同じです。そのため戦略の差は、試行ごとの差(対応のある差)を求めて、その平均と信頼区間で示します。

検証結果(D1:A3 への指示の脱落、10試行)

戦略	劣化中の成功率	検出の遅れ(タスク)	誤隔離 / 実行	早すぎる復帰 / 実行	Takeover / 実行	呼び出し(B0比)	トークン(B0比)
B0 何もしない	0.64 ± 0.04	-	-	-	0	600(1.00)	266k(1.00)
B1 採点と切り替えのみ	0.95 ± 0.01	-	0	-	45.6 ± 2.7	1292(2.15)	694k(2.61)
B2 悪い点1回で隔離	0.95 ± 0.01	9.4 ± 3.9	8.6 ± 1.1	1.4 ± 0.6	11.4 ± 1.4	1332(2.22)	709k(2.67)
B3 点を溜めて隔離	0.95 ± 0.01	24.3 ± 5.1	1.2 ± 0.9	0.3 ± 0.3	26.0 ± 3.3	1286(2.14)	688k(2.59)

検証結果(D2:A4 への証拠無視、5試行)

戦略	劣化中の成功率	検出の遅れ(タスク)	誤隔離 / 実行	早すぎる復帰 / 実行	Takeover / 実行	呼び出し(B0比)	トークン(B0比)
B0 何もしない	0.62 ± 0.10	-	-	-	0	600(1.00)	268k(1.00)
B1 採点と切り替えのみ	0.81 ± 0.07	-	0	-	33.0 ± 3.3	1266(2.11)	672k(2.51)
B2 悪い点1回で隔離	0.94 ± 0.02	8.2 ± 6.7	8.4 ± 1.1	2.0 ± 0.9	11.2 ± 1.6	1332(2.22)	700k(2.61)
B3 点を溜めて隔離	0.88 ± 0.05	35.0 ± 6.9	1.6 ± 0.7	0.2 ± 0.6	24.8 ± 3.8	1285(2.14)	678k(2.53)

(検出の遅れは、劣化の開始(タスク31)から最初の隔離までのタスク数です。)

図の読み方です。左から「劣化中のタスク成功率」(task success in degraded interval)、「健全なエージェントの誤隔離の回数」(false isolations per run (healthy agents))、「Takeover の回数」(takeovers per run (outputs switched to standby))です。棒が平均、ひげが95%信頼区間、点が各試行の値、青が D1 の検証(E1)、オレンジが D2 の検証(E2)を表します。

D1 は、試行を変えても同じ結論でした

• 何もしないと劣化中の成功率は 0.64 まで落ち、B1〜B3 は 0.95 に戻ります。B1・B2・B3 のあいだの差は 0 です(B3 − B1 = 0.000 ± 0.000)。
• 誤隔離は、悪い点1回で隔離する B2 が 8.6 回/実行、点を溜めて判断する B3 が 1.2 回/実行でした(差 7.4 ± 1.2)。B3 もゼロではありません(0〜4回)。B3 の誤隔離は、D1・D2 ともすべて A1 でした(B2 も約7割が A1)。6章のとおり、レビュアーが A1 の正しい出力を低く採点することが、主な原因の1つです。
• 早すぎる復帰は、B2 が 1.4 回/実行、B3 が 0.3 回/実行でした。B3 では、10試行のうち3試行で1回ずつ、本当の回復の数タスク前に復帰しました。
• Takeover(全エージェントの合計)は、隔離のない B1 の 45.6 回に対して、B3 は 26.0 回でした(差 −19.6 ± 3.6)。隔離で、約4割減ります。B1 の Takeover の約3分の1(34%)は、元の出力が正しかったのに切り替えたものでした。

D2(意味的な劣化)では、隔離が成功率に効きました

• 成功率は、B0 が 0.62、B1(その場の切り替えのみ)が 0.81、B3 が 0.88、B2 が 0.94 でした。B3 は B1 より 0.068 ± 0.022 高い(D1 では差が 0)。
• その場のレビューが見逃す劣化(D2)では、1つ1つの出力を確認するだけでは守りきれません(B1 は 0.81)。点を溜めて、持続的に悪いエージェントを隔離する仕組みが、成功率を押し上げました。
• B2 は、検出が速い(8.2 タスク)ぶん成功率も最も高い(0.94)ですが、誤隔離は 8.4 回/実行でした。B3 は、成功率が 0.88 で、誤隔離は 1.6 回/実行、検出は遅く(35.0 タスク)なります。隔離の判断の速さと、誤隔離は、トレードオフです。
• D1 と比べると、B3 の検出の遅れは 24.3 → 35.0 タスクに延びました。ただし、D1 と D2 では、劣化の強さの推移・対象のエージェント(A3 と A4)・ルールの設定(D2 は構造チェックのみ)が違うため、この差をすべて劣化の種類のせいにはできません。6章のとおり、整合チェックのルールを足すと D2 も見分けやすくなるので、「意味的だから」というより、確かめられるルールがないと見つけにくいと読むのが妥当です。

コスト: モデルの呼び出しは B0 の 2.1〜2.2 倍、トークンは 2.5〜2.7 倍で、D1・D2 とも戦略による差は小さい結果でした。B3 と B1 の呼び出し数の差は小さく、同程度です(差は D1 で −5.3 ± 8.8、D2 で +18.2 ± 11.3。どちらも B1 の1.5%以内)。

図で確かめる(D2): 下の図は、D2 の B3(試行1)です。

読み方は5章のとおりです。ただし、劣化を入れたのは A4 なので、(2)(3)(4)の A4 が対象です。(2)を見ると、D1 の図と違い、劣化が入る前(タスク1〜30)から、点が 0.9 まで下がる出力が散発しています。正常な出力にも点のばらつきがあるため、劣化との区別が付きにくくなります。(3)は、WATCH(タスク41)に入ったあと一度 NORMAL に戻り、58 で再び WATCH、60 で ISOLATED になりました。その後、(4)のとおり A4 の処理を待機系が実行し(61〜87)、回復テストを経て 87 で復帰します。(5)の赤は、B3 でも残っています(劣化区間の前半に多い)。隔離が間に合うまでの間は、守りきれていません。

10. 検証結果のまとめ

検証した仮説	内容	判定	根拠	章
H1	悪い状態は採点の点数に表れる	支持(D1)/D2 では弱い	D1:ルール合格率の見分けやすさ 1.0、ルールと LLM の合算 0.99。健全な出力の点はほぼ満点(平均 0.99)。D2:LLM 単体 0.77	6
H2	点数を溜めて判断すると、誤隔離が減る	支持	1回の実行あたりの誤隔離 D1:8.6 対 1.2(差 7.4 ± 1.2)、D2:8.4 対 1.6(差 6.8 ± 1.0)。記録の再生(試行1):10件 対 1件。ただし溜めて判断する方式も0ではない	7, 8, 9
H3	隔離と切り替えで、劣化中も成功率を保てる	支持(条件つき)	D1:B0 0.64 → 0.95。ただし B1(切り替えのみ)も同じ値で、隔離で上がらない。D2:B1 0.81 → B3 0.88(差 +0.068 ± 0.022)。レビューが見逃す劣化では、隔離が成功率を押し上げる	8, 9
H4	連続で受かるまで戻さなければ、悪い状態のまま戻らない	支持(記録の再生・1試行)	記録の再生(試行1):1回の合格で戻すと、隔離が保たれた割合は 0.28、3回連続なら 1.00。参考:実際に動かした場合の早すぎる復帰は、B3 で D1:0.3・D2:0.2 回/実行、B2 で 1.4・2.0 回/実行。ただし B2 も復帰の条件は同じで、この差は主に隔離の頻度の違い	7, 9
H5	意味的な劣化は、構造的な劣化より見つけにくい	支持(ルールを構造チェックのみにした条件で)	見分けやすさ D2:LLM 単体 0.77、D1:ルール 1.0。その場の切り替えだけの成功率 D2:0.81、D1:0.95。B3 の検出の遅れ D2:35.0、D1:24.3 タスク。ただし D1 と D2 は、劣化の強さの推移・対象・ルールの設定が違う(9章)	6, 9

全体として、確認できたことは4点です。

1. 劣化は点数に表れます。 ただし見えやすさは、機械的に確かめられるルールがあるかで大きく変わります(D1 は完全、D2 は LLM だけだと弱い)。
2. 劣化中の成功率を守る主役は、「その場の切り替え(Takeover)」でした。 ただし、その場のレビューが見逃す劣化(D2)では、隔離が成功率をさらに押し上げました(0.81 → 0.88)。D1 のように、その場で拾い切れる劣化では、隔離は成功率ではなく、切り替えの回数(処理量)と動作の安定に効きました。
3. 隔離の判断は、速さと誤隔離のトレードオフです。 悪い点1回で隔離(B2)は、検出が速く成功率も高い(D2 で 0.94)一方、誤隔離が多い(8〜9回/実行)。点を溜めて判断する方式(B3)は、誤隔離が少ない(1〜2回/実行)一方、検出が遅い(D2 で 35 タスク)。
4. 守るための処理量は、約2.1〜2.2倍(トークンは約2.5〜2.7倍)です。 大半はレビュー自身の費用で、戦略による差は小さい結果でした。

まだ確認できていないことは、次のとおりです。ほかの劣化(ツール結果の誤解、手順の逸脱、過信、出力の不完全さ)/レビュアー自身の劣化/別モデルの待機役/劣化の種類ごとに隔離のしきい値をどう決めるか。D2 は5試行なので、信頼区間は広めです(たとえば復帰の遅れは 7.5 ± 10.3)。

11. 運用への示唆

隔離のロジックがあると、何がよいか

運用する側だけでなく、ユーザー(利用者)の視点でも見ます。ここでの利用者は、システムが作る最終報告を受け取って使う人です。8章・9章の結果からは、次のことが言えます。

• ユーザー(利用者)に対する信頼性が保てます。 利用者が受け取るのは、最終報告です。劣化したエージェントが1体混ざっていても、利用者に届く報告が正しい割合を保てるか。これが、利用者から見た信頼性です。その場のチェックで拾い切れる劣化(D1)では、隔離の有無で正しい報告の割合は変わりませんでした(どちらも 0.95)。一方、その場のチェックが見逃す劣化(D2)では、その場の切り替えだけだと正しい報告は 0.81 でしたが、隔離を加えると 0.88 になりました。劣化区間(タスク31〜80)では、誤った報告が利用者に届く割合が、約19%から約12%に下がったことになります(D2、5試行)。1つ1つの出力の確認で拾い切れない劣化は、持続的な悪さとして溜めて見つけるほうが、利用者を守れます。
• 処理のむだが減ります。 隔離がないと、劣化したエージェントを毎回使い、不合格のたびに Committee の確認と待機役のやり直しが必要になります(B1 の切り替え 45.6 回/実行。全エージェントの合計)。隔離すると、待機役が最初から処理するので、約4割減(B3 の 26.0 回/実行)で済みます。しかも B1 では、切り替えの約3分の1は、元の出力が正しかったものでした(レビュアーの誤判定による、不要な切り替え)。利用者から見ると、やり直しを挟む回数が減るため、応答が遅くなる要因も減ると考えられます(処理時間は今回計測していないため、未検証です)。
• 健全なエージェントを巻き込みにくくなります。 「悪い点が1回出たら隔離」(B2)では、健全なエージェントを 8〜9 回/実行も誤って隔離しました。点数を溜めて判断する方式(B3)は 1〜2 回/実行で、ゼロではありません。利用者から見ると、待機役が健全であれば、誤隔離されても報告の品質は変わりません。実際に、誤隔離の多い B2 でも、最終報告の正しい割合は B3 と同程度か、それ以上でした(D1 はどちらも 0.95、D2 は 0.94 対 0.88)。ただし、これは待機役が健全で、常に起動している前提です。誤隔離しても困らない設計(待機役の確保、すぐ戻せる回復テスト)が必要です。
• 直ったら自動で戻ります。 回復テストに連続で受かるまで戻さないので、人が「もう戻してよいか」を判断せずに済みます。7章のとおり、1回の合格で戻すと、悪い状態のまま戻りやすくなります(隔離が保たれた割合 0.28)。3回連続を要求することで、早すぎる復帰は B3 で 0.2〜0.3 回/実行に収まりました(B2 も復帰の条件は同じで 1.4〜2.0 回/実行。隔離を繰り返す分、復帰の機会が増えるためです)。
• 障害の経過が残ります。 「いつから悪くなり、いつ隔離され、いつ戻ったか」が、状態遷移の記録として残ります。原因調査や、利用者への説明(いつから、どの範囲に影響があったか)、SLA/SLO の振り返りに使えます。
• ただし、D1 のように、その場のチェックで拾い切れる劣化では、成功率は上がりませんでした。 隔離の効果は、処理量と安定性に出ます。隔離の価値が出やすいのは、その場のチェックが見逃す劣化です。

隔離以外の示唆

• 隔離の判断は、速さと誤隔離のトレードオフです。 悪い点1回で隔離(B2)は、D2 で成功率が最も高く(0.94)、誤隔離が多い(8.4 回/実行)結果でした。待機役が安価に用意できて、誤隔離の損失が小さいなら、B2 寄りの設定も選択肢です。誤隔離の損失が大きいなら、点を溜めて判断する B3 寄りにします。
• チェック自体が主要なコストです。 トークンの約55%がレビューでした。何を、どの頻度でチェックするかの設計が、運用コストを決めます。
• 待機役の多様性が要ります。 同じモデル・同じプロンプトの待機役では、モデルの自然な間違いを直せません。
• レビュアーの質が、全体の上限になります。 弱いレビュアーは、健全なエージェントに悪い点を付け、隔離の判断を誤らせます。強いほうの qwen3:14b でも、A1 の正しい出力を系統的に低く採点し、誤隔離や不要な切り替えの原因になりました。
• しきい値は、健全な出力の分布から決めます。 結果を見てから合わせるのではなく、劣化を入れる前の分布から決めておくことが重要です。
• 「検査できるルール」を用意します。 意味的な劣化は、LLM のチェックだけでは見えにくいものです。入力から計算で確かめられるルール(影響範囲が依存関係と一致するか、など)を足すと、見つけやすくなりました。

12. 限界と次の一手

• 単一モデル・疑似的に作ったデータでの検証です。実運用のデータやモデルで、同じ傾向が出るかは確認できていません。
• 劣化は D1(指示の脱落)と D2(証拠無視)の2種類だけです。ほかの劣化(ツール結果の誤解、手順の逸脱、過信、出力の不完全さ)は、これから検証します。
• D2 は5試行で、信頼区間は広めです。また、証拠との整合チェックを含まない設定(見つけにくい側の条件)で動かしました。6章の D1 の見分けやすさは、試行1の記録(100件)から求めた値で、10試行では求めていません。
• 待機役は、常に健全という前提です。 劣化はエージェント単位でしか入れていないため、同じモデル・同じプロンプトの待機役が、主系と同じ原因(モデルの退行、プロンプトの不具合、上流のデータなど)で同時に劣化する場合は、検証していません。その場合は、切り替えも隔離も効きません。
• レビュアー自身が劣化した場合(誤隔離を引き起こす、劣化を隠す)は、まだ検証していません。
• 論文の数値とは比較していません。 劣化の作り方が違う(同一モデルへの振る舞いの注入)ため、直接の比較はできません。
• 次の一手として、別モデルの待機役、劣化の種類ごとの隔離のしきい値の決め方、複数のエージェントが同時に劣化する場合、レビュアーの劣化を検証したいと考えています。

おわりに

「止まっていないのに、おかしくなる」エージェントは、マルチエージェントの運用に入ると、必ず問題になると考えています。かつて性能劣化を捉えるために、ユーザーシーケンスを明らかにし、SLA/SLO を定義して計測したように、AIエージェントにも、何を観測し、どう検知し、どう自律的に守るかの設計が要る時代になります。

今回の小さな検証からは、その場の切り替えで被害を防ぎ、点数を溜めて持続的な劣化だけを隔離し、連続で確かめてから戻すという2段構えが、成り立つことを確認できました。一方で、見分けられるかどうかは機械的に確かめられるルールの有無に大きく左右され、隔離の判断には速さと誤隔離のトレードオフがあり、チェックには約2倍のコスト(呼び出し 2.1〜2.2倍、トークン 2.5〜2.7倍)がかかることも注意点です。

参考

• Huang, P., Guo, C., Zhou, L., Lorch, J. R., Dang, Y., Chintalapati, M., & Yao, R. (2017). Gray Failure: The Achilles' Heel of Cloud-Scale Systems. HotOS '17. https://www.microsoft.com/en-us/research/publication/gray-failure-achilles-heel-cloud-scale-systems/
• Chen, K., Lin, S., Liang, Y., Bastian, N. D., & Zou, S. (2026). MeshHeal: Two-Timescale Self-Healing for Gray Failures in Decentralized LLM Agent Networks. arXiv:2609.29015. https://arxiv.org/abs/2609.29015