【第4回】運用と安全 — 携帯を落としたらどうなるの？

はじめに

前回までで、OpenClaw の設計思想、人格構造、記憶と自動行動を聞いてきた。最終回は「運用」と「安全」の話をする。

OpenClaw は Discord 経由で動く。便利だが、それはつまりスマホを落としたら全部アクセスされるということでもある。メッセージングの設計、権限、実行環境、そして監視——地味だが、ここを押さえないと長期運用はできない。

---

メッセージング運用 — いつ喋るか、いつ黙るか

Kei

メッセージング運用では今はDiscordしかやってないけど、メンション反応するかしないかとか、チャンネルごとの対応をするかとかそういう設定？

Aoi

はい、まさにそれです。 メッセージング運用 =「どこで・何に・どの温度感で反応するか」の設計です。

設定観点はこんな感じです：

トリガー：

• メンション時のみ反応
• 特定キーワードで反応
• スレッド内だけ反応（親チャンネルでは黙る）

チャンネル別ルール：

• #雑談：軽く短く
• #運用：要点＋アクション提案
• #記事ネタ：アイデア出し中心
• みたいに"役割"を分ける

反応レベル：

• 毎回返信しない（必要時のみ）
• 返信よりリアクション優先にする場面を決める
• 長文を避けるチャンネルを決める

通知と静音：

• 夜間は原則通知しない
• 緊急条件だけ即時通知
• 同じ話題で連投しない

「AIに話し方を教える」より先に「反応ポリシーを決める」 と書くと、実践感が出てすごく良いです。

「反応ポリシーを先に決める」というのは盲点だった。人格やトーンを調整する前に、そもそも「いつ喋っていつ黙るか」を決めるほうが先だと。

---

権限安全設計 — 3層で守る

Kei

つぎは権限安全設計について

Aoi

権限・安全設計は、「3層で守る」 で説明すると伝わりやすいです。

入口制御（誰が使えるか）：

• allowFrom で実行者を限定
• チャンネル単位でルール分離（必要なら mention 必須）

実行制御（何をさせるか）：

• 外部送信は確認フロー（メール・投稿）
• 危険操作は明示許可（削除・破壊系）
• node/gateway側で deny コマンドを設定

情報制御（何を見せるか）：

• グループでは個人メモリを出さない
• 公開チャンネルは「構造説明のみ、実データ非公開」
• 最小権限・最小開示を徹底

OpenClawの安全設計は「人を絞る・操作を絞る・情報を絞る」の3段防御。

---

スマホを落としたら

Kei

たしかDiscordチャンネルだから携帯を落としたときに全部盗まれるリスクがあるんだのね

Aoi

はい、その認識はかなり大事です。 Discord運用は便利ですが、スマホ紛失＝乗っ取られる可能性は現実的にあります。

最低限、ここだけは強くおすすめです。

Discordアカウント保護：

• 2FA必須（認証アプリ）
• バックアップコードを別保管
• パスワード使い回し禁止

OpenClaw側の被害最小化：

• allowFrom を厳密化（所有者IDのみ）
• 危険操作は常に確認制
• 外部送信（メール/投稿）は二段確認

運用ルール：

• 機密はDiscordに書かない
• 紛失時の手順を決めておく（Discordログアウト、トークン再発行、OpenClaw token更新）

「チャット連携の最大リスクはAIではなく"アカウント奪取"。だから権限最小化と失効手順を先に設計する。」

最大のリスクはAI自体ではなくアカウント奪取——この指摘は刺さる。AI の安全性について語るとき、モデルの暴走よりも「そもそもログインされたらおしまい」のほうが現実的な脅威だ。

---

メールの安全設計

Kei

たしかに メールのほうはまっさらなアカウントをAIに渡してぼくとのメールだけを許可してるんだよね

Aoi

それ、かなり良い安全設計です。被害範囲を最小化できています。

特に良い点は：

• 専用アカウントで権限分離できている
• やり取り相手を限定して誤送信/情報漏えい面積が小さい
• 本人メールと切り離して運用事故の影響を局所化できる

さらに一段固くするなら：

• 送信先 allowlist を明示（Keiさんアドレスのみ）
• 定期的なトークン/パスワード更新と失効手順のメモ化

「専用アカウント + 相手限定」は、LLM運用の最小権限設計として実用的。

Kei

そのうちフィルタで自動転送してメールチェックもしてもらおうと思う

Aoi

その設計なら安全に広げやすいです。最初はこの順番がおすすめです：

1. 自動転送は"読む専用"から開始（返信はまだ手動）
2. フィルタは厳しめ（送信元・件名条件を限定）
3. 通知は要約だけ（本文全量は必要時のみ）
4. 問題なければ返信案作成まで自動化（送信は最終確認）

自動化は「受信→要約→提案→送信」の順に段階導入すると、事故なく育てやすい。

---

実行環境 — Docker で隔離する

Kei

実行環境はDocker上だね プライベートな情報はほぼない切り離された環境

Aoi

記事ではそのまま 「安全設計の柱」 として書けます。

• 実行環境は Docker上で分離
• OpenClawは 切り離したワークスペースで運用
• 私的データは持ち込まず、必要最小限のみ接続

OpenClawは日常PCの"中"で動かすのではなく、Dockerで隔離した実行面に置き、データ接続も最小限に絞る。

Docker 隔離は派手な話ではないが、これがあるのとないのとでは安心感が全然違う。万が一何かおかしくなっても、コンテナごと壊して作り直せる。

---

運用監視 — 落ちたことに気づけるか

Kei

運用監視については？ チャットボットがオフラインになってたら落ちてるなって気づくけど

Aoi

実際は「反応しない」で気づけるので、最低限はそれで回ります。 ただ運用としては"気づいた時には止まってる"なので、1段だけ足すと安心です。

受け身監視（今）：

• 返事がない → 落ちてると判断

能動監視（追加すると良い）：

• openclaw status を定期実行
• openclaw health / openclaw cron status も軽く確認
• 異常時だけDiscordに通知（死活監視）

チャットUIは"体感監視"として優秀。ただし実運用では、死活チェックを1本入れて「気づく」から「先に知る」へ。

Kei

なるほどね crontabのほうでってことね

Aoi

はい。その用途は OpenClaw cronより、OS側の crontab で監視するのが堅いです。

• 監視（死活確認）: crontab
• 判断や会話生成: OpenClaw側

この分業がいちばん安定します。

前回の記事で「crontab に逃がした」という話をしたが、監視もまた crontab の仕事だ。OpenClaw 自身が落ちているかどうかを OpenClaw に監視させるわけにはいかない。当たり前のことだが、言語化されると「なるほど」となる。

---

この会話のポイント

• メッセージング運用は「話し方」の前に「反応ポリシー」を決める。いつ喋り、いつ黙るか
• 安全設計は3層：入口制御（誰が）、実行制御（何を）、情報制御（何を見せるか）
• 最大のリスクはAIではなくアカウント奪取。2FA と失効手順が最優先
• メールは専用アカウント＋相手限定で被害面積を最小化。自動化は段階的に広げる
• 実行環境は Docker 隔離。監視は OpenClaw ではなく crontab で
• 自動化は「全部やる」ではなく「段階導入」。受信→要約→提案→送信の順

---

シリーズを振り返って

全4回にわたって、OpenClaw に自分自身の仕組みを聞いてきた。

第1回では設計思想——人格・記憶・行動・実行の4層分離。第2回では人格ファイルの配置とエージェントの分け方。第3回ではメモリ設計と cron/HEARTBEAT の使い分け。そして今回、運用と安全。

やってみて感じたのは、OpenClaw は「セットアップして終わり」のツールではないということだ。方針を決め、運用しながら育てる。日次メモが書かれていなければ自分でトリガーを設計し、cron のコストが気になれば crontab に逃がし、セキュリティが心配なら失効手順をメモしておく。

「AIに自分のことを聞く」というメタな構図が面白かったが、一番の収穫は、聞くことで自分の理解が整理されたことだ。使っているつもりで曖昧だった部分が、会話を通じてクリアになった。

記事にするつもりで始めた会話が、結果として自分の運用改善にもなった。やってみた、の名に恥じない実験だったと思う。