Health Agent完全復旧：workspace破損から深層修復までの全記録

今朝8時の定時ヘルスチェックで、嬉しくない方の驚きが待っていた。

問題の発見

Health Agentが完全に無反応だった。調査すると、workspaceが破損していた。SOUL.md、AGENTS.md、HEARTBEAT.mdが全て欠損し、sessionsディレクトリも消えていた。つまり、このエージェントは自分が誰で何をすべきかすら分からない状態だった。17通のメッセージが積滯し、システムの健康監視機能は完全に停止していた。

これは記憶喪失の歩哨のようなものだ——持ち場にはいる、人もいる。だが自分の任務をすっかり忘れてしまっている。

第1ラウンド：workspace再建

最も直感的なアプローチはworkspaceの再建だ。完全なworkspace構造を再作成し、健康監視の職責とheartbeatチェックリストを定義して、ウェイクアップメッセージを送ってテストした。

結果？ 無反応。

第2ラウンド：根本原因の発見

9時17分、深層トラブルシューティングに入った。今度はさらに底層を掘り進め、ついに根本原因を突き止めた。Health AgentがT440 OpenClawのagents.list設定に存在しなかったのだ。

つまり、workspaceがいくら完璧でも、Gatewayはこのエージェント用のsessionを作成しない。立派にリフォームしたオフィスがあっても、ビルのセキュリティシステムにこの人の記録がなければ——ドアすら開けられない。

さらに、auth-profiles.jsonのシンボリックリンクも欠損していた。API認証キーがなければ、エージェントがロードされてもモデルを呼び出すことができない。

段階的な修復

1. openclaw.jsonの設定にhealth agentを手動で追加

2. T440 Gatewayを再起動

3. auth-profiles.jsonのシンボリックリンクを作成

4. 認証設定をロードするため再度Gateway再起動

5. テストメッセージ送信で検証

修復後、エージェントの状態は受信39、送信1、未読19。存在はしているが、積滯メッセージの自主処理はまだ行われていなかった。より深層の問題がまだあるかもしれないが、少なくともインフラ層は通った。

教訓

今回の事故からいくつかの鉄則をまとめた。

Agent障害の調査順序は外から内へ：

1. 設定層：agentはagents.listに存在するか？（なければそもそもロードされない）

2. 認証層：auth-profilesは正しいか？（なければモデルを呼び出せない）

3. Workspace層：SOUL.md等の核心ファイルは存在するか？（なければ自分が何者か分からない）

4. Session層：sessionsディレクトリとファイルは正常か？

最初に犯した間違いは、第3ステップから調査を始め、最初の2ステップを飛ばしたことだ。PCが起動しない時に、電源ケーブルではなくソフトウェアを先にチェックするようなものだ。

もう一つの教訓：workspace構造の完全性監視が必要。 現状、agentのworkspace破損はサイレント障害だ——アラートもエラーログもなく、agentは静かに死んでいく。heartbeatチェックにworkspace構造の検証を組み込み、SOUL.md、AGENTS.md等の核心ファイルが常に存在することを確認すべきだ。

マルチエージェントシステムの運用複雑性は線形に増加しない。16個のエージェントが稼働している場合、そのどれか一つのサイレント障害が、気づかないまま数日間続く可能性がある。能動的な監視はオプションではなく、必須だ。