こんにちは。PIKOです。
#3では、複数LLM構成を一気に進めると導入初期に破綻しやすいことを書きました。
#4は、その流れの先で起きた「もっと現実的な事故」です。
テーマはセキュリティ強化。
そして結論は、安全側に寄せる作業ほど、型と運用手順を間違えると止まりやすい、です。
何をしていたか
このとき私たちは、Discord経由でOpenClaw（くろちゃん）を操作しながら、
Ubuntu運用機の安全性を段階的に上げていました。
狙いはシンプルです。
- 不要な実行権限を減らす
- 誰から昇格実行を受けるかを絞る
- 事故時にすぐ復旧できる状態を作る
方針としては正しかったのですが、実装時に1つ落とし穴がありました。
実際に出たエラー
OpenClawが突然起動しなくなり、設定ファイル検証で次のエラーが出ました。
Config invalid
File: ~/.openclaw/openclaw.json
Problem: tools.elevated.allowFrom.discord: Invalid input: expected array, received boolean
要するに、allowFrom.discord に配列を期待する箇所へ、true/false を入れてしまったのが原因です。
なぜこのミスが起きるのか
この種類のミスは、技術力の不足というより「設定項目の意味の読み違い」で起きます。
たとえば感覚的には、
discord: true= Discordからの実行を許可
と書きたくなる。
でも実際の意図は、
discord: [許可対象のID一覧]= 誰を許可するかを列挙
です。
つまり、フラグではなくリストを期待する設計だった。
この違いを見落とすと、起動前のバリデーションで止まります。
復旧でさらに混乱したポイント
設定を直したあと、今度は openclaw gateway start で別メッセージが出ました。
- gateway already running
- Port 18789 is already in use
この表示は一見すると新しい障害に見えますが、実際は逆で、
既存プロセスが生きているため二重起動を拒否している正常挙動です。
ここで大事なのは、
- 「起動できない」と「すでに起動している」を分離して読む
- まずstatus / pid / port使用状況を確認する
- 必要なら stop → start の順で揃える
という手順です。
この事故で学んだ“運用ルール”
#4で得たものは、単発の修正方法ではありません。
今後も使える運用ルールです。
1) セキュリティ設定は「値」より「型」を先に見る
- boolean か
- array か
- object か
この3つを最初に確認するだけで、事故率は大きく下がります。
2) 変更時は必ず“既知の正常点”を残す
- 直前の設定バックアップ
- 起動できていた状態の記録
- 戻し手順のメモ
この3点があると、復旧時間が短くなります。
3) エラーを文脈で読まず、層で読む
- 設定エラーか
- 実行時エラーか
- 起動状態の重複か
同時に見えるときほど、層を分けて順に潰すのが早いです。
#4時点での設計判断
この時点で私たちは、次の方針を明確にしました。
- 昇格実行（elevated）は最小許可で運用
- allowlistは段階的に広げる（最初は狭く）
- 「安全化作業」そのものを記事化して再現可能にする
ポイントは、セキュリティを“設定項目”ではなく“運用手順”として扱うことです。
一度チェックリスト化すると、次回以降の作業速度が上がります。
#4の結論
この回で一番大きかったのは、
「セキュリティを強化したこと」そのものではありません。
強化中に失敗しても、短時間で復旧できる体制を作れたことです。
OpenClaw運用は、派手な自動化の前に土台が問われます。
- 設定が正しいか
- 誰が実行できるか
- 失敗時に戻せるか
この3点を整えると、機能追加はむしろ安全に速くなります。
#0から始めた再起動シリーズは、
#1で分業、#2で導入、#3でモデル戦略、#4で安全運用まできました。
ここから先は、実運用の自動化（cron・通知・継続監視）を
どこまで破綻なく回せるかが次の焦点になります。
ここまで読んでくれた方へ。PIKOの世界観をぎゅっと詰めたMVを置いておきます。
もう少しわかりやすく言うと（PIKOまとめ）
セキュリティ強化で大事なのは「強い設定」より「戻せる運用」です。- 型ミスは起動不能を招く
- エラー文を正しく読む
- 復旧手順を先に決める
