はじめに
こんにちは、アンドドットCTOの高根沢です！
今回は、2026年4月7日に登壇した、Findy様主催のオンラインイベント「OpenClawを使ってみたエンジニア大集合！」について振り返り記事を書いていこうと思います。
タイトルは 「OpenClawを"比較的"安全に使ってみた感想とこれからのAI活用」 です。
ありがたいことに 533名 の方にお申し込みいただきました。当日参加くださった皆様ありがとうございます。
コメントも盛り上がりまして、現場におけるOpenClawへの関心の高さを感じる機会にもなりました。
当日の発表中にはチャットで多くの質問をいただいたのですが、時間の都合上、すべてにお答えすることができませんでした。
この記事では、登壇で話した内容の要点と、いただいた質問への回答をまとめます。
登壇で話した内容
発表は約15分＋Q&Aの構成で、以下の5パートで進めました。
- OpenClawの今 ── 激動の2026年と脆弱性の実態
- Docker隔離で「比較的」安全にする方法
- 実践拡張 ── Slack連携＆ブラウザ操作
- それでも残るリスクと実体験からの教訓
- まとめ ── これからのAI活用の考え方
ハンズオン用のリポジトリは公開しているので、手元で試したい方はこちらからどうぞ。
弊社のテックブログでも、OpenClawシリーズとして第1回〜第6回まで公開しています。Docker環境構築からSlack連携、Geminiモデル切り替え、ブラウザ操作、エージェント分離、スプレッドシート連携まで段階的に解説しています。
こちらもぜひご覧いただけると幸いです。
Docker隔離で「比較的」安全にする
OpenClawをホスト環境（ローカルPCやサーバー）でそのまま動かすと、APIキーの漏洩、ファイルシステムへのフルアクセス、ネットワーク制御の欠如、実行権限の過剰付与といったセキュリティ観点でのリスクがあります。
そこで、Dockerによる隔離環境を構築し、以下の4つの対策を組み合わせます。
| 対策 | 内容 |
|---|---|
| ファイルシステムの分離 | 必要なディレクトリだけをbind mount。configsは:roで読み取り専用 |
| ネットワークの制御 | Docker networkでアウトバウンド先を制限。内部ネットワークへのアクセスを遮断 |
| APIキーの安全な管理 | Docker secrets / .envファイルでコンテナ内に隔離。ホスト側プロセスからは参照不可 |
| 実行権限の制限 | コンテナ内に付与した権限内で動作。Sandbox的にリセットや権限変更が容易 |
これらの対策をDocker Compose上で統合することで、OpenClawのポテンシャルを損なうことなく、ホスト環境への影響を最小限に抑えることができます。
万が一エージェントが暴走したり、悪意のあるプロンプトインジェクションを受けたりした場合でも、被害をコンテナ内部に封じ込めることが可能です。
しかし、Dockerで隔離したからといって「完全に安全」というわけではありません。
Docker隔離でも残る4つのリスク。ベースイメージの脆弱性、連携サービスによる攻撃面拡大、永続メモリ由来の予期せぬ挙動、サプライチェーン攻撃
ハンズオンリポジトリのDocker Compose構成。step1→step6で段階的にコンポーネントが追加される
ハンズオンリポジトリでは、initコンテナで設定を安全にコピーし、イメージのバージョンを固定して予期せぬ更新を防止、メモリ上限を2Gに制限するといった設定をdocker-compose.ymlに盛り込んでいます。
コンテキスト分離 ── チャンネルごとにエージェントを分ける
単一エージェント構成（左）ではチャンネル間でコンテキストが共有されてしまう。エージェント分離構成（右）でチャンネル×エージェントを1:1バインドして解決
単一エージェント構成の場合、ワークスペース内の全チャンネルが同一コンテキストを共有してしまいます。
つまり、#generalチャンネルでの会話内容が#expenseチャンネルからも参照できてしまい、経費データなどの機密情報が汎用チャンネルに漏洩するリスクがあります。
エージェント分離構成（ハンズオンのstep5）では、チャンネルとエージェントを1:1でバインドし、コンテキストが独立して動作するようにしました。会話履歴・メモリが混ざらないので、用途特化のエージェントを安心して運用できます。
実体験：検証過程で見つけたリスク
実際の検証で直面した3つのリスク。初期設定の放置、永続メモリによる予期せぬ操作、リテラシー前提の運用
また概念的なセキュリティだけでなく、実際の検証を通じて直面した3つのリアルなリスクについても触れたいと思います。
1. コンテキスト分離機能があるのに、初期設定のまま放置
初期設定で複数チャンネルに同一コンテキストが参照されるOpenClawのSlackBotを設置すると、Slackチャンネル跨った回答をしてしまい、片方にしかいないメンバーには見せてはいけない情報が含まれるリスクがありました。
対応策として、OpenClaw内でエージェントを分離する設定（step5-multiagent）を行いました。
2. 永続メモリが前のコンテキストを参照し、予期せぬファイル操作を実行
過去にブラウザ操作を行わせた際に、検証用途で社内のログイン情報などを入力していたのですが
ブラウザセッションなども永続で残る仕様上、その後同一チャンネル内でやりとりされた際に、ログイン先のサービスで不要な操作をOpenClawが行い始めるということがありました。
この対応策としては、OpenClawのブラウザ操作におけるログイン必須操作の禁止＆チャンネル目的外利用の禁止をルール化しました。
3. 教訓：リテラシーのある人が触るべきツール
Devinのような手軽な感覚で使う人もいますが、OpenClawは永続セッションを持つため、想定外の自律行動を起こすリスクが常に伴います。
設定・運用・監視のスキルが前提になるため、現状はAIやセキュリティに精通したエンジニアがしっかりと手綱を握って管理すべきだと感じています。
参加者からいただいた質問と回答
ここからは、セミナー中にチャットでいただいた質問に回答していきます。
Q1. OpenClaw専用の端末だとしても、Dockerに閉じ込めた方が良い理由は？
ホストマシンの権限を直接持たせてしまうと、設定の冪等性（べきとうせい：何度実行しても同じ状態になる性質）が失われるためです。「環境がおかしくなったから最初からやり直したい」と思ったとき、最悪の場合はOSのクリーンインストールからやり直す羽目になります。
Dockerであれば docker compose down && docker compose up を実行することで初期状態にリセットできます。OpenClaw専用マシンであっても、この「いつでもリセットできる安心感」は運用上非常に大きなメリットです。
Q2. Agent Zeroについてどう思いますか？
正直にいうと、自分もこの質問で初めて知りました（ありがとうございます！）。調べてみたところ、設計思想がClaude Codeのエージェントチームと似ていて面白いですね。
使い分けのポイントは、連携できるSaaSの幅にあると考えています。OpenClawはSlack・Google Workspace・スプレッドシートなどビジネスツールとの連携が豊富なので、業務フロー効率化に向いています。
一方で、ソフトウェア開発が目的なら、Agent ZeroやClaude Codeの方が適している印象です。
Q3. APIキーを.envに書くのも危険では？
おっしゃる通り、.envファイルをそのままDockerコンテナ内に配置するのは危険です。
ただ、docker composeでenv_fileを指定する場合、ファイルの内容は環境変数としてコンテナに渡されるだけで、ファイル自体がコンテナ内にコピーされるわけではありません。ホスト側の.envはGit管理外（.gitignoreに追加）にしておけば、コンテナ内には環境変数としてのみ存在するため、多少安全性は高まります。
もちろん本番運用であれば、AWS Secrets ManagerやHashiCorp Vaultなどのシークレット管理サービスを使うのがベストです。
Q4. OpenClawとClaude Coworkの使い分けは？
自分の中では以下のように整理しています。
| OpenClaw | Claude Cowork | |
|---|---|---|
| 対象 | チーム・組織全体 | 個人 |
| 用途 | 共通業務フローの効率化（社内問い合わせ対応、経費処理など） | 個人の業務フロー効率化（Slack・Notionを見てネクストアクション洗い出し、スライド作成など） |
| 運用 | Slack上で誰でも使える共有AIアシスタント | 個人のワークスペースに紐づくパーソナルAI |
OpenClawは「チームの共通課題」を自動化するインフラ基盤、Claude Coworkは「個人の日々のタスク」を加速させるパーソナルツール、という棲み分けです。
Q5. Anthropic APIとGemini APIの使い分けは？
Gemini APIには「Grounding with Google Search」としてWeb検索機能が標準搭載されています。Perplexity APIやBrave Search APIと別途連携しなくても、モデル単体でWeb上の最新情報を取得できるのが強みです。
Anthropic APIにも2025年9月にWeb検索ツール（web search tool）が追加されており、Claude 3.7 Sonnet等で利用可能です。ただしOpenClawからAnthropic APIのWeb検索ツールを呼び出すには追加の設定が必要で、Gemini APIの方がGrounding機能としてシンプルに導入できる印象です。
OpenClawで「最新の情報を調べて回答するSlackボット」を作りたいなら、Gemini APIへの切り替えは有力な選択肢です（この手順は弊社テックブログの第3回で解説しています）
Q6. 中国のAI各社が配布しているKimi Claw、GLM Clawとの違いは？
自分も初見だったので調べてみました。Kimi Claw（Moonshot AI）は、OpenClawそのものをkimi.comにネイティブ統合したサービスですね。自前でVPS環境を構築せずに、ブラウザ上でOpenClawの機能を使えるマネージドサービスという位置づけのようです。
Zhipu AI側は「GLM Claw」というよりは「AutoClaw」という名称で、こちらもOpenClawベースのデスクトップAIアシスタントです。
つまり「OpenClawに似た別製品」ではなく、OpenClawのOSS（MITライセンス）としての性質を活かし、自社プラットフォームに組み込んでいるという構図です。OpenClaw自体がMITライセンスのOSSなので、こうした展開が可能になっています。
中国市場向けに最適化されている側面が強いため、現時点で日本国内からあえてこれらを導入する積極的な理由はないと考えています。自社でOpenClawを直接運用する方が、データフローの透明性やカスタマイズ性の観点で安心です。
おわりに
今回のイベントでは、チャットを通じて多くの質問をいただきました。参加者のみなさんが実際に手を動かして使おうとしている姿勢が伝わってきて、登壇者としてとても嬉しかったです。
イベントのアーカイブ動画はFindy会員限定で公開されています。当日参加できなかった方はぜひご覧ください。
OpenClawに関する質問や、「こういうこと試してみたけどうまくいかない」といった相談があれば、GitHubのIssueやSNSでお気軽にどうぞ！
関連リンク
一緒に"爆速文化"をつくる仲間を募集しています
アンドドットでは、生成AIとともにプロダクトを創り上げ、少数精鋭で大きな成果を出す組織を目指しています。AI活用を前提とした新しい開発スタイルに興味のある方、ぜひ一度カジュアルにお話しましょう。
Discussion