OpenClawを社内導入する前に、まず決めたい信頼境界

OpenClawを個人で試していると、「これを社内のSlackやチャットから使えるようにしたい」と考える場面があります。PoCとしては自然な流れです。ただ、社内利用へ広げる前に、設定項目を増やすより先に整理しておきたいことがあります。

それは、OpenClawを「誰の代理人」として動かすのか、そしてGatewayへ誰がどこから到達できるようにするのかです。

この記事では、OpenClawの社内導入を検討する中小企業の技術責任者、情シス、運用担当者向けに、共有してよい利用者、Gatewayへ接続できる範囲、最初に許可する業務の3点を、導入前メモとして書き出せる形にします。細かな設定手順ではなく、「何を決めてから進めるか」に絞ります。

これは、OpenClawが危ないという話ではありません。個人で便利に使う前提と、社内で複数人が使う前提では、先に決めるべき境界が変わるという話です。

OpenClaw公式のSecurityページは、OpenClawを「personal assistant trust model」として説明しています。1つのGatewayは、1つの信頼された運用者の境界として見る設計です。OpenClawは、敵対的な複数利用者を1つの環境で隔離するための境界ではない、という趣旨も同じ資料で示されています。

OpenClawを広げる前に、まず「誰の代理人か」を決める

最初に決めたいのは、1つのGatewayを誰と共有してよいかです。

Gatewayは単なる中継ではなく制御面として見る

OpenClawのGitHub READMEでは、OpenClawは自分のデバイスで動かすパーソナルAIアシスタントであり、Gatewayはチャットチャネルとエージェント、ツールをつなぐcontrol planeとして説明されています。ここで大事なのは、Gatewayが単なる中継サーバーではなく、ツール実行や設定、資格情報に近い場所を扱う制御面になることです。

会話を分けて見せる仕組みは、利用者ごとの権限分離の代わりにはなりません。同じSecurityページでも、sessionKeyやsession ID、labelはルーティングのための選択子であり、認可トークンではないと説明されています。

共有してよい人と分けたい人を書き出す

社内で最初に書き出すなら、まずは次の3つから始めると整理しやすくなります。

• 同じGatewayを共有してよい人
• 別Gateway、別OSユーザー、別ホストに分けたい人
• Gateway上で触れる業務データと、触れさせない業務データ

たとえば、同じ情シスチーム内で限定的に使うPoCと、営業・外部委託先・顧客対応窓口まで含める運用では、同じ設計にはできません。同じチーム、同じ権限水準、同じデータ範囲、同じ運用責任で説明できるなら、1つの限定Gatewayから試せる余地があります。部署ごとに扱うデータが違う、委託先や顧客向けの利用者が入る、同じ資格情報を共有させたくない、といった条件があるなら、GatewayやOSユーザー、可能ならホストを分けるところから考える方が自然です。

公開面は、接続できる範囲を広げるほど運用条件が重くなる

次に見るのは、Gatewayへどこから接続できるようにするかです。

まずは閉じた範囲から考える

限定導入では、Gatewayへ接続できる範囲をできるだけ狭く置くところから考えます。OpenClaw公式のSecurityページでは、Gatewayのbind modeとして、既定のloopbackはローカルのみ接続可能と説明されています。一方で、非loopback bindは攻撃面を増やすため、共有トークンやパスワード認証、厳格なファイアウォールを前提に限定利用する考え方が示されています。無認証で0.0.0.0へ公開する構成は、避けるべき候補として扱うのが妥当です。

Tailscaleを使う場合も、「Tailscaleなら常に安全」とは言えません。Tailscale Funnelの公式ドキュメントでは、FunnelはローカルサービスをHTTPS URLとしてインターネット上で利用可能にできる機能として説明されています。社内端末やtailnet内に閉じる設計と、インターネットから到達可能にする設計は、同じ公開ではありません。

外へ広げるほど確認事項が増える

公開先は、次の順に運用条件が重くなると考えると分けやすくなります。

• ローカルだけで使う
• 自分または社内の閉じたネットワークから使う
• LAN内で使う
• リバースプロキシやidentity-aware proxyの後ろで使う
• インターネットから到達できる形にする

小さく試す段階では、loopbackまたはtailnet内に閉じる候補から始めます。LAN、リバースプロキシ、インターネット公開へ広げるほど、業務上の必要性だけでなく、認証、直アクセス遮断、ログ、token/passwordのローテーション、復旧手順まで説明する項目が増えます。外部公開は、この一式を社内で説明できるまで待つ、と決めておく方が進めやすくなります。

同じSecurityページでは、token、password、trusted-proxy認証の考え方や、token/passwordのローテーション手順も扱われています。ただし、Gateway HTTP bearer authは実質的にoperator accessとして扱うべき境界である、という注意もあります。部分的な権限のつもりで配るものではなく、誰に渡すか、どこに保管するか、漏れた時にどう止めるかまでセットで考える対象です。

チャットから利用できる人は、ツール権限の入口にもなる

OpenClawをチャットから使う場合、「誰がbotにメッセージを送れるか」は、そのままツール実行を始められる人の範囲になります。

DMとグループで入口を分ける

OpenClaw公式のPairingページでは、未知のDM送信者には短いコードが発行され、承認されるまでメッセージは処理されない仕組みが説明されています。Securityページでも、DM policyとしてpairing、allowlist、open、disabledが扱われ、openは明示的なopt-inを前提にする位置づけです。

グループやチャンネルで使う場合は、groupPolicyやgroupAllowFromで、誰の発言を受けるかを設計できます。ここでも大事なのは、チャネルの許可とGateway内の権限分離を混同しないことです。allowlistやpairingは「話しかけられる人」を制御する入口です。相互に信頼できない人を、同じGateway上で安全に分離する仕組みとして過信しない方がよいでしょう。

会話の分離と権限分離を混同しない

複数人がDMできるshared inboxのような運用は便利です。Securityページでは、shared inbox的な運用ではsession.dmScope: "per-channel-peer"などで会話コンテキストを分ける考え方が示されています。同時に、共有DMと広いツール権限を同居させない注意もあります。

同じ情シスチーム内など、同じ権限セットを共有してよい相手に限るなら、dmScopeで会話の混線を減らし、許可ツールを狭くした限定運用から始める、という整理はできます。避けたいのは、shared inboxそのものではなく、誰が何を実行できるかを決めないまま権限を広げることです。

社内説明では、まず「DMで使う人」と「グループで使う人」を分けて表にすると、議論が進みます。そこに、許可するツールと触れるデータを並べると、どこから限定導入できるかが見えやすくなります。

小さく始めるなら、最初に1つの業務と1つのルールへ落とす

OpenClawの業務利用を始めるなら、最初から全社共通のAIアシスタントにしない方が進めやすいです。まず1つの業務、1つのチャネル、1つの権限セットに絞ります。

まず1業務・1チャネル・1権限セットに絞る

たとえば、次のように決めます。

• 対象業務: 社内ナレッジの確認、定型作業の補助など
• 使うチャネル: 特定のDMまたは特定グループだけ
• 触れるデータ: 個人情報、顧客秘密、管理者権限を含まない範囲
• 許可するツール: 業務に必要なものだけ
• 禁止するツール: 設定変更、スケジュール登録、外部送信、永続化につながるもの

最初のルールは、特定グループから社内ナレッジ確認だけを許可し、外部送信、設定変更、永続化につながるツールはdenyにする、という粒度まで狭めると判断しやすくなります。これなら、試す業務、指示できる人、触れるデータ、止める権限を1枚で説明できます。

日本語のOpenClaw Tools設定ガイドでは、tools.allowとtools.denyでツール権限を制御でき、両方に記載がある場合はdenyが優先されると説明されています。Securityページでは、gatewayやcronなど、設定変更やスケジュール登録に関わるツールを、未信頼コンテンツを扱う面では既定拒否にする考え方も示されています。

状態保存領域と資格情報も導入条件に入れる

もう1つ、PoCの時点で後回しにしない方がよいのが、状態保存領域と資格情報です。Securityページでは、~/.openclaw/または$OPENCLAW_STATE_DIR配下に、config、チャネルcredentials、auth-profiles、APIキーやOAuth token、セッショントランスクリプト、プラグイン、サンドボックス作業領域などが保存され得ると説明されています。

これは、守る場所が明確になるという利点でもあります。一方で、そこに重要な情報が集まりやすいということでもあります。ディレクトリやファイル権限、ログの残し方、資格情報のローテーション、再構築手順は、正式導入後ではなく、限定導入の条件に入れておくと安心です。

MicrosoftのAzure Pipelinesセキュリティガイダンスでも、self-hosted agentは可能な限り低権限の専用アカウントで実行することが推奨されています。OpenClaw固有の仕様ではありませんが、社内でツール実行を任せる仕組みを扱うときの考え方として参考になります。

導入前チェックリストで、進める・待つ・避けるを分ける

最後に、導入判断を3つに分けておきます。ここでの目的は、完璧な設計を一度で作ることではありません。自社で小さく試せる範囲と、まだ広げない範囲を分けることです。

限定導入に進める条件

次がそろっていれば、まず1つの業務で試す判断に進みやすくなります。

• 1つのGatewayを共有してよい人が明文化されている
• Gatewayへ接続できる範囲が最小化されている
• DM、グループ、allowlist、pairingの扱いが決まっている
• tools.allowとtools.denyで、許可する実行範囲を絞っている
• ~/.openclaw/やOPENCLAW_STATE_DIRを重要資産として扱っている
• token、password、secrets、ログ、再構築手順の担当が決まっている
• 導入対象版の設定内容、Securityページ、リリースノート、必要に応じて security audit の結果を確認している

まだ待つ条件

次の論点が未整理なら、社内展開や外部公開は待つ方がよいです。

• shared inboxと広いツール権限を同時に使いたい
• Gatewayをインターネットから到達可能にしたい
• trusted-proxy認証を使うが、直アクセス遮断やヘッダの扱いが決まっていない
• 個人アカウントやログイン済みブラウザを業務自動化に使いたい
• どのデータがログやトランスクリプトに残るか説明できない

ログイン済みブラウザが必要な業務でも、最初は業務専用アカウント、専用ブラウザプロファイル、専用VMなどに分けられるかを先に確認すると、個人利用と業務利用の境目を説明しやすくなります。

避けたい構成

少なくとも初期導入では、次の構成は避ける対象として扱うのが現実的です。

• 無認証で0.0.0.0へ公開する
• sessionKeyやdmScopeを権限分離として扱う
• 相互に信頼できない利用者を同じGatewayに乗せる
• DMをopenにしたまま、強いツール権限を許可する
• Gateway tokenを部分権限のように配布する
• secretsやログの保管場所を決めずに本番業務へ進める

MITREのATLAS OpenClaw Investigationでは、公開されたOpenClawのcontrol interface、資格情報アクセス、prompt injection、悪性skillによる供給網リスクなどが調査例として扱われています。ここから言えるのは、OpenClawが一律に使えないということではありません。公開面、ツール権限、資格情報、復旧手順を分けて設計しないと、便利な利用経路が強い権限の利用経路にもなり得るということです。

限定導入では、skillsやpluginsは業務に必要なものだけを明示的に信頼し、追加、更新、無効化の担当を決めてから広げる、くらいの小さな運用ルールから始めます。

よくある質問

OpenClawは社内利用に向かないということですか？

そうではありません。この記事で見ているのは、OpenClawを社内で使う前に、個人利用と同じ前提で広げてよい範囲と、先に分けておきたい範囲を整理することです。1つの業務、1つのGateway、信頼できる利用者に絞るなら、小さく試せる余地はあります。

Tailscaleを使えば外部公開ではないと考えてよいですか？

tailnet内に閉じる使い方と、Funnelのようにインターネットから到達できる使い方は分けて考える必要があります。社内説明では、誰が到達できるか、どの認証を通るか、直アクセスを防げているかをセットで確認する方が安全です。

1つのGatewayを複数人で使ってもよいですか？

同じ権限水準、同じデータ範囲、同じ運用責任で説明できる相手に限るなら、限定的に検討できます。部署、委託先、顧客対応などで扱うデータや責任が変わる場合は、Gateway、OSユーザー、ホストを分ける候補として見た方が自然です。

最初に許可する業務はどう選べばよいですか？

失敗しても戻しやすく、顧客秘密や管理者権限を直接扱わず、効果を確認しやすい業務から選ぶのが現実的です。たとえば社内ナレッジ確認や定型作業の補助のように、使うチャネル、許可するツール、触れるデータを1枚で説明できる範囲から始めます。

自社でどこから始めるか迷う場合は

OpenClawを社内で使うかどうかは、「リスクをゼロにできるか」ではなく、「自社の業務で、信頼する人、到達できる場所、許可するツール、守る情報を狭く定義できるか」で判断すると進めやすくなります。

まずは、自社の状況を次の3点で確認してみてください。

• 同じGatewayを共有する人を、名前や役割で説明できるか
• Gatewayの公開先と、外部公開を待つ条件を説明できるか
• 許可するツール、触れるデータ、secrets・ログ・復旧手順の担当を説明できるか

この3点を書き出すと、1つの業務、1つのGateway、1つのチャネルから始められる範囲と、まだ広げない方がよい範囲が見えやすくなります。

ここで迷う場合は、ツール設定だけを詰めるよりも、社内で説明できる運用境界を先に整理すると判断しやすくなります。

PASHでは、共有したい利用者、公開したい範囲、許可したいツール、secrets・ログ・復旧手順の現状をもとに、社内利用に進める範囲、分けるべき境界、まだ待つべき構成を一緒に整理できます。