Clawdbotとは？初期設定から使い方・料金、セキュリティについて解説！

Clawdbotは、自分で用意したマシンやクラウド上に立ち上げるセルフホスト型のAIアシスタント基盤です。
LLMそのものではなく、チャットUI、LLM、ツール実行、スケジューラを統合管理するミドルウェアとして機能し、TelegramやDiscord、SlackなどのチャットアプリからAIエージェントを柔軟に利用できます。

本記事では、Clawdbotの基本的な仕組みや対応チャネル、導入手順に加え、個人での情報整理からチームでの一次対応自動化といった具体的なユースケース、さらにセルフホスト運用時に不可欠なセキュリティ対策について、2026年1月時点の情報を基に体系的に解説します。

Clawdbotとは？

Clawdbotは、自分で用意したマシンやクラウド上に立ち上げる「セルフホスト型のAIアシスタント基盤」です。
LLM（大規模言語モデル）そのものではなく、「チャットUI」「LLM」「ツール実行」「スケジューラ」をまとめて扱うための実行基盤に近い位置づけです。

基本構成とGateway

基本構成はシンプルで、Telegram / Discord / Slack / WhatsAppなどのチャットサービスからメッセージを受け取り、ローカルやクラウドのLLMに投げ、必要に応じて外部ツールを呼び出したうえで、結果をそのままチャットに返すという流れになります。

中心にあるのが「Gateway」と呼ばれるプロセスで、どのチャネルからの入力を受け付けるか、どのLLMを使うか、どのツール（Skills）を許可するか、といったポリシーを一元的に制御します。

オープンソースと柔軟なLLM選択

Clawdbot自体はオープンソースのNode.js製アプリケーションで、macOS / Linux / Windows（WSL2推奨）のどれでも動作させることができます。

LLMはAnthropic ClaudeやOpenAI、あるいはOllama経由のローカルLLMなど、用途やコストに応じて組み合わせられるため、「手元 or VPSに常駐させる個人／チーム専用のAIアシスタント」を比較的柔軟に構築できるのが特徴です。

Clawdbotでできること

ここでは、Clawdbotがどのようなチャネル・ワークフローを扱えるのかを、「成果ベース」で整理します。

具体的な設定方法は後述の「Clawdbotの使い方」に集約し、この章では「何ができるか」の射程に絞っておきます。

対応チャネル

Clawdbotは複数のチャットチャネルを横断して扱えるように設計されています。代表的なものは次のとおりです。

• WhatsApp（QRログイン）
• Telegram / Discord / Slack / Mattermost
• SMS（Twilio等のゲートウェイ経由）
• macOSメッセージアプリ（iMessage）との連携
• ローカルのCLI / Web UI

同じGatewayインスタンスに対して複数チャネルをぶら下げることで、「個人のDMはTelegram」「チーム向けの通知はSlack」「ブラウザからの操作はWeb UI」といった役割分担が可能です。

どのチャネルからの入力を受け付けるか、どのチャネルに対して能動的にメッセージを送るかは、後述の許可設計・スケジューラと組み合わせて細かく制御できます。

会話の受付と返答

Clawdbotの基本は、チャットから自然言語で依頼を受け、LLMで解釈・実行し、その結果を同じスレッドに返すことです。
個人のDMだけでなく、チーム用のグループチャットに常駐させ、「メンションされたときだけ応答する」「特定のプレフィックスを付けたメッセージだけ拾う」といった動作も設定できます。

会話の文脈（コンテキスト）はGateway側で管理され、スレッド単位・チャネル単位で履歴を引き継げます。

また、Clawdbot側に「メモ」や「設定」を保存させることで、「昨日の要約」「特定プロジェクトの前提条件」などを踏まえた継続的なやり取りも実現できます。

外部ツール実行

Clawdbotは、単なるテキスト対話にとどまらず、外部ツールやAPIを呼び出す「Skills」を通じて、PCやクラウド上での具体的な作業を自動化できます。

代表的な例としては、次のような操作が挙げられます。

• ローカルファイルの読み書き・検索
• シェルコマンドの実行（ログ収集やバッチ処理など）
• ブラウザ自動操作によるWebスクレイピングやフォーム入力
• 各種SaaS（カレンダー、タスク管理、Gitホスティングなど）のAPI呼び出し

Skillsは追加・削除が可能な拡張ポイントになっており、個人用途なら「日記の保存」「家計簿更新」、チーム用途なら「GitHub Issue起票」「CI結果の集約」といった形で、用途に応じて拡張していくことができます。

なお、セキュリティの観点では「シェル実行」「ファイル操作」「ブラウザ自動化」はリスクが最も高いカテゴリです。最初は無効（または最小）から始め、必要になったタイミングで、許可チャネルと権限を絞ったうえで段階的に有効化するのが安全です。

ジョブの定期実行

Clawdbotには、ジョブスケジューラとしての機能も備わっています。
いわゆるcronのように、あらかじめ定義したタスクを「毎朝9時」「毎週月曜」「5分おき」などの間隔で自動実行し、その結果をチャットに送り返すことができます。

たとえば次のような運用が典型です。

• 毎朝、その日の予定と天気、重要タスクをまとめた「モーニングブリーフ」をDMで受け取る。
• 毎週、特定リポジトリのPR一覧とレビュー状況をチームのチャンネルに自動投稿する。
• 定期的にRSSやニュースサイトを巡回し、指定キーワードに関連するトピックだけ要約して通知する。

「チャットから依頼したことを、そのまま定例ジョブとして登録する」といった運用も可能で、会話ベースで自動化の範囲を広げていけるのが特徴です。

通知・リマインド

Clawdbotは、自分から話しかけなくても、必要なタイミングで「先に話しかけてくる」タイプのアシスタントとして設計されています。
上記の定期ジョブや外部ツール連携と組み合わせることで、次のような通知・リマインドが実現できます。

• カレンダーの予定やタスクの締切前に、チャットでリマインドする。
• 特定のログやメトリクスに異常値が出たときに、アラートと簡単な分析コメントを送る。
• 「今日やるべきこと」を朝にまとめ、夜に「できた／できなかった」を振り返るテンプレートを投げてくる。

通知の送り先チャネル・頻度・内容は設定で制御できるため、「うるさすぎるボット」にならないよう、チームや個人のワークスタイルに合わせて調整しやすい構造です。

Canvas・音声

Clawdbotは、チャットだけでなく、macOSやスマートフォン向けの専用アプリからも利用できます。
デスクトップでは「Canvas」と呼ばれるUIを通じて、画面上での作業と会話をひとまとめに扱うことができ、音声モードでは「声で呼び出して、声で返答を受け取る」といった使い方も可能です。

Canvasでは、右下の小さなウィンドウとして常駐させ、「いま開いているウィンドウに対する操作依頼」や「目の前のテキストの要約」などを一気通貫で扱えます。

音声モードは、作業中に手を離せないタイミングでも、ToDo追加や簡単なメモ、リマインド設定などを素早く指示できるのが利点です。

Clawdbotの料金体系

Clawdbot本体は無料で利用できます。
必要になるのは、Gatewayを動かすためのマシンと、そのマシンをインターネットに接続しておくためのインフラコストです。

典型的なパターンとしては次のような選択肢があります。

• 自宅やオフィスにあるPC・ミニPCに常駐させる。
• 低価格のVPS（例：月数ドル〜数ユーロ程度）にインストールして24時間動かす。
• 既存のDockerホストやホームラボ（NASなど）の一つのコンテナとして動かす。

軽めのチャット運用であれば、2GBメモリと2コア程度のマシンでも動作し、ブラウザ自動化や複数ワークフローを同時に走らせたい場合は4GB以上のメモリと数十GBのストレージを用意しておくと余裕を持って運用できます。

サブスク運用の前提

Clawdbotが使うLLMは、主に次の3パターンに分類できます。

• Anthropic Claudeなどの商用LLM（サブスク／API）
• OpenAIやその互換API（ChatGPT系、Codex CLIなど）
• OllamaなどのローカルLLMランタイム（自前GPU・CPUで推論）

Clawdbotは、Anthropicの「Claude Pro/Max」やOpenAIの「ChatGPT Plus/Pro」といったサブスクリプションとのOAuth連携もサポートしています。
ただし、サブスク認証の扱いは規約・提供形態・監査ポリシーの変更が起こり得る領域でもあります。

恒常運用を考える場合は、APIキーを用いた正規のAPI利用や、OllamaによるローカルLLMを前提とした設計にしておく方が、中長期的なリスクを抑えやすいと言えます。

API課金が出る条件

API課金が発生するのは、Clawdbotから外部のLLMプロバイダ（Anthropic / OpenAI / その他OpenAI互換APIなど）に対してリクエストを送ったときです。

課金単位は一般的なLLMと同様に「トークン数（入力＋出力）」で、モデルの種類やコンテキスト長によって単価が変わります。

そのため、次のようなケースでコストが積み上がりやすくなります。

• 長文コンテキスト（ログやドキュメント一式）を頻繁に投げる。
• ブラウザ自動化や複数ステップのエージェント実行を大量に回す。
• チームの複数メンバーが同じGatewayにぶら下がり、高頻度でやり取りする。

逆に、「個人利用で1日数十リクエスト程度」「短めのQA中心」といった使い方であれば、サブスク or APIのどちらを選んだ場合でも、月額コストを数千円〜1万円前後に抑えることは十分可能です（モデル選定や為替レートによって変動します）。

LLM以外のコスト

LLM料金以外に考慮すべきコストとしては、次のようなものがあります。

• Gatewayを動かすサーバー代（VPS / クラウドインスタンス / 自宅マシンの電気代）
• ストレージコスト（会話履歴やファイル添付、ログをどこまで保持するか）
• 外部SaaS APIの上限超過や有料プラン（タスク管理、プロジェクト管理、モニタリングなど）
• ドメイン名やトンネリングサービス（外部からのアクセス経路をどうするか）

、「LLM料金＋VPS代」だけでなく、「監査ログやバックアップを何年分残すか」「SaaSの有料プランをどこまで許容するか」といった観点から、トータルコストを見積もる必要があります。

Clawdbotの使い方

ここでは、ローカル環境にClawdbotを導入し、Discordでやりとりをできる状態になるまでの手順をハンズオン形式で整理します。

インストール

1. Node.jsのバージョンを確認します。

node -v

「v22.x.x」系であればそのまま進めて構いません。古い場合は公式インストーラや「nvm」などで更新します。

2. Clawdbot本体をインストールします。

npm install -g clawdbot@latest

3. インストール後、バージョンを確認します。

clawdbot --version

正常にバージョンが表示されれば、インストールは完了です。

初期セットアップ

Clawdbotは「オンボーディングウィザード」で、Gateway・Workspace・モデル設定をまとめて行える構成になっています。
次のコマンドでウィザードを起動します。

clawdbot onboard --install-daemon

1. セキュリティの確認

初回起動時は、セキュリティに関する確認画面が表示されます。Clawdbotのエージェントは以下の操作を実行できるため、リスクを理解したうえで進める必要があります。

• コマンドの実行
• ファイルの読み書き
• 有効化したツールを通じた各種操作

公式ドキュメントを確認し、サンドボックスや最小権限の原則について理解したうえで「Yes」を選択します。

2. セットアップモードの選択

セキュリティ確認後、セットアップ方法を選択します。

• QuickStart（推奨）
  ウィザード形式で自動セットアップです。Gateway daemonも自動インストールされ、詳細設定は後から変更可能です。
  初めて使う場合や、まず動作確認したい場合に適しています。

  
  

• Manual
  コマンドを直接実行する手動セットアップです。サービス設定も自分で行う必要があります。
  上級者向けで、開発用途や細かい制御が必要な場合におすすめです。

初回セットアップでは、QuickStartを選択するのが推奨されます。本記事でも、QuickStartを選択して進める前提で解説します。

3. Gateway設定の確認

QuickStartを選択すると、次のようなGatewayの基本設定が自動的に構成されます。

各項目の意味とセキュリティ上の注意点は以下のとおりです。

• Gateway port（18789）
  Clawdbotが待ち受けるポート番号。複数インスタンスを同時に動かす場合は、インスタンスごとに異なるポート番号を割り当てる必要がある。

  
  

• Gateway bind（Loopback: 127.0.0.1）
  最も重要なセキュリティ設定。「127.0.0.1」（ローカルループバック）は、同じマシン内からのアクセスのみを許可する最も安全な設定。
  「0.0.0.0」（すべてのネットワークインターフェース）に変更すると、同一ネットワーク上の他のデバイスからもアクセス可能になるため、追加の認証設定が必須となる。

  
  

• Gateway auth（Token）
  認証方式。デフォルトでトークン認証が有効化されており、不正アクセスを防ぐ。

  
  

• Tailscale exposure（Off）
  リモートアクセスの設定。デフォルトでは無効。外部からアクセスする必要がある場合は、後からTailscale ServeやFunnelを使って安全に公開できる（Funnelで公開する場合は、パスワード認証が必須となる）。

QuickStartでは、この設定確認後、順番に次のような項目を設定していきます。

4. 利用するモデル / 認証方法

使用するLLMプロバイダーを選択します。2026年1月時点で対応している主なプロバイダーは以下のとおりです。

すでにClaude CodeやOpenAI Codex CLIを使っている場合は、その認証情報を引き継ぐ選択肢が提示されます。

本記事では、「OpenAI (Codex OAuth + API key)」を選択して進める前提で解説します。OpenAIを選択すると、次の3つの認証方法から選択できます。

例えば、ChatGPT OAuthを選択した場合は、ブラウザが開いてOpenAIのOAuth認証画面が表示されます。

認証完了後、デフォルトモデル（gpt-5.2など）が提案され、確認・変更の選択画面が表示されます。

そのまま使う場合は「Keep current」を選択し、別のモデル（gpt-5.1やcodex特化モデルなど）に変更したい場合は選択肢から選びます。

5. チャネル選択

モデル設定後、最初に接続するチャットチャネルを選択します。
2026年1月時点で対応している主なチャネルは以下のとおりです。

初回セットアップでは、後から設定できるため「Skip for now」を選択しても問題ありません。

本記事では、「Discord (Bot API)」を選択して進める前提で解説します。

5-1. Discordを選択した場合の設定手順

Discordを選択すると、Discord Bot Tokenの入力が求められます。

まだDiscord Botを作成していない場合は、以下の手順で作成します（完全無料）。

Discord Botの作成手順

1. Discord Developer Portalを開く
   ブラウザで Discord Developer Portal を開き、Discordアカウントでログインします。
   
   

2. 新しいアプリケーションを作成

• 右上の「New Application」ボタンをクリック
  
  
  

• アプリケーション名を入力（例：「My Clawdbot」など、任意の名前）し、利用規約に同意して「Create」をクリック
  
  
  

3. Botユーザーを追加

• 左メニューの「Bot」をクリック
  
• 「Add Bot」ボタンをクリック（すでにBotが存在する場合はスキップ）し、 確認画面で「Yes, do it!」をクリック

4. Privileged Gateway Intentsを有効化
   Bot設定画面の下部にある「Privileged Gateway Intents」セクションで、以下を有効化します。
   
   • ✓ Message Content Intent（必須：メッセージ内容を受信するために必要）
   • ✓ Server Members Intent（推奨：サーバーメンバー情報の取得に必要）

変更したら、画面下の「Save Changes」をクリックして保存します。

5. Bot Tokenを取得

• Bot設定画面上部の「Token」セクションで「Reset Token」ボタンをクリック
  
  
  
• 確認画面で「Yes, do it!」をクリック
  
  
  
• 表示されたTokenを「Copy」ボタンでコピー
  
  
  

6. ターミナルにTokenを入力
   コピーしたTokenをターミナルの入力欄に貼り付けて、Enterキーを押します。

Discordチャンネルアクセス設定

Token入力後、Discordチャンネルへのアクセス制御方法を設定します。

1. 「Configure Discord channels access?」で「Yes」を選択
   セキュリティのため、チャンネルアクセスを制限することを推奨します。
   
   

2. アクセス制御方法を選択
   | 設定項目 | 説明 |
   | :--- | :--- |
   | Allowlist (recommended) | 許可リスト方式。特定のチャンネルやユーザーのみ許可（最も安全）★推奨 |
   | Open (allow all channels) | すべてのチャンネルで使える（セキュリティリスクあり） |
   | Disabled (block all channels) | すべてブロック |

3. Botをサーバーに招待（まだの場合）
   チャンネルを指定する前に、BotをDiscordサーバーに追加する必要があります。

• Discord Developer Portalに戻り、左メニューの「OAuth2」→「URL Generator」画面に遷移します。
  
  
  

• Scopeで「bot」と「applications.commands」にチェック
  
  
  

• Bot Permissionsで以下を選択します。

  • ✓ View Channels
  • ✓ Send Messages
  • ✓ Read Message History
  • ✓ Embed Links
  • ✓ Attach Files
    
    
    

• 生成されたURLをコピーして、新しいタブで開きます(ページ最下部)。
  

• Botを追加したいDiscordサーバーを選択して「認証」をクリック
  
  
  

4. チャンネルを指定
   ターミナルに戻り、Botを使用したいチャンネルを以下の形式で入力します。

サーバー名/#チャンネル名

例:

• 「My Server/#general」
• 複数指定: 「My Server/#general, My Server/#bot-test」

入力してEnterキーを押すと、チャンネルIDが解決されて設定が保存されます。

6. Skills設定

チャンネル設定完了後、Skills（機能拡張）を設定します。

Skillsは、Clawdbotが実行できるタスク（ファイル操作、ブラウザ自動化、API呼び出しなど）を追加する機能です。

Node.jsパッケージマネージャーの選択

Skillsのインストールに使用するパッケージマネージャーを選択します。

初回は「npm」を選択することを推奨します。最も安定していて、トラブルが少ないためです。

追加Skillsのインストール

次に、追加のSkillsをインストールするか選択します。

026年1月時点で利用可能な主なSkillsには以下があります。

初回セットアップでは「Skip for now」を選択することを推奨します。

基本機能だけで動作確認してから、必要なSkillsを後から追加する方が安全です。特に、実行系（シェル／ファイル／Web操作）に関わるSkillsは、許可チャネルと権限設計を決めてから段階的に追加することを推奨します。

APIキーの設定

Skillsによっては、外部サービスのAPIキーが必要なものがあります（Google Places API、Gemini API、OpenAI API、ElevenLabs APIなど）。

初回セットアップでは、すべて「No」を選択することを推奨します。必要になったら後から設定できます。

Hooksの設定

Hooksは、エージェントコマンドが実行されたときに自動的にアクションを実行する機能です。

初回セットアップでは「Skip for now」を選択することを推奨します。後から必要になったら追加できます。

7. Gatewayサービスのインストール

Hooksの設定後、Gatewayサービスが自動的にインストールされます。

Installing Gateway service...
Installed LaunchAgent: /Users/[username]/Library/LaunchAgents/com.clawdbot.gateway.plist
Logs: /Users/[username]/.clawdbot/logs/gateway.log

macOSの場合、LaunchAgentとして登録され、PC起動時に自動的にGatewayが起動するようになります。

インストール完了後、以下の情報が表示されます。

追加情報として表示される内容

• Web search - Web検索機能を使うにはBrave Search APIキーが必要（オプション）
• Security - セキュリティ設定を強化することを推奨
• Workspace backup - ワークスペースのバックアップを推奨

8. ボットの初期設定（Hatch）

最後に、ボットのキャラクターと役割を設定します。「How do you want to hatch your bot?」という質問が表示されます。

「Hatch in TUI」を選択すると、ターミナルでボットとの最初の会話が始まります。

ボットから以下の質問があります：

ボットの名前の選択肢

回答例：

Call me 〇〇 (Asia/Tokyo). I'll call you Clawd.

または日本語で
〇〇と呼んでください。タイムゾーンはAsia/Tokyoです。あなたの名前はClawdにします。

回答すると、ボットが以下のように応答します。

そして、ボットが以下のファイルを自動作成します。

今回はDiscordでの動作確認を行うために、「Discordで試したい」と入力しました。

Discordアプリまたはブラウザ版で、設定したサーバーとチャンネル（例：AI-souken/#一般）を開くと、ボットからのテストメッセージが届いています。

これで、ClawdbotからDiscordへのメッセージ送信が正常に動作していることが確認できました。

次に、Discord側からボットに話しかけてみます。

Discordの「#一般」チャンネルで、以下のようにメッセージを送信します。
ボットが応答すれば、Discord連携は正常に動作しています。

これでClawdbotの初期セットアップは完了です。

次のステップとして、以下の方法でClawdbotを使い始められます。

• Discord/Telegram/Slackなどのチャットアプリから使う - 設定したチャンネルでボットに話しかける
• TUI（ターミナル）から使う - 「clawdbot tui」 コマンドで起動
• Web UI（ブラウザ）から使う - 「clawdbot dashboard」 コマンドで起動

トラブルシューティング

Gateway接続のトラブルシューティング

セットアップ後、Discord連携がうまく動作しない場合、以下を確認してください。

1. Gatewayの状態確認

clawdbot gateway status

「RPC probe: ok」と「Runtime: running」が表示されることを確認します。

2. Gatewayが起動していない場合

clawdbot gateway start

3. それでも接続できない場合

clawdbot gateway stop
pkill -9 -f "clawdbot.*gateway"
clawdbot gateway install
clawdbot gateway start

ボットが応答すれば、連携は正常に動作しています。

TUI（ターミナル）での使用

ターミナル（TUI）でもボットと会話できます。以下のコマンドでTUIを起動します。

clawdbot tui

TUIでは：

• リアルタイムでボットと会話
• トークン使用量の確認
• セッション履歴の閲覧

が可能です。Ctrl+Cで終了できます。

Web UI（ブラウザ）での使用

ブラウザでも管理画面を開けます。

clawdbot dashboard

Web UIでは

• チャット履歴の閲覧
• 設定の変更
• Skillsの追加・削除
• ログの確認

が可能です。

Control UIのURLは以下の形式となります。

http://127.0.0.1:18789/?token=[your-token]

Clawdbotのユースケース

ここでは、Clawdbotをどのような場面で活用できるかを、「個人」「チーム」「開発フロー」「定常タスク」という4つの観点から整理します。

「できること」は前章に集約しているため、この章では実際のワークスタイルに落とし込んだイメージにフォーカスします。

個人の情報整理

個人用途では、「自分専用の第二の脳」としてClawdbotを常駐させるイメージが分かりやすいでしょう。

• その日のメモや日記、学習ログをチャットに投げると、自動的にタグ付け・要約して保存する。
• ブラウザで読んでいる記事を要約してもらい、後で検索しやすい形でストックする。
• 家計簿やタスク管理ツールと連携し、「月末にこのカテゴリーの支出を振り返る」といったリマインドを自動化する。

「ChatGPTタブを毎回開き直す」のではなく、TelegramやiMessageなど普段使っているチャットアプリに常駐させることで、思いついたときにすぐメモできるのが強みです。

チームの一次対応

チーム向けには、「一次対応ボット」としての利用がわかりやすいユースケースです。

• 社内のよくある問い合わせ（開発環境の初期セットアップ手順、休暇申請のフローなど）に対して、ドキュメントをもとに自動回答する。
• 監視ツールやCI/CDからの通知を受け取り、関連するIssueやログへのリンクをまとめて提示する。
• チャンネルに投稿された質問を要約し、適切な担当者にメンションして割り振る。

人間のオペレーターや担当者が対応する前段に、「必要な情報の整理」「優先度付け」「簡単な回答」をClawdbotに任せることで、チーム全体の負荷を下げるイメージです。

開発の作業導線

開発チームでは、Clawdbotを「コードリポジトリやCIとつながったエージェント」として活用できます。

• Gitリポジトリの差分やIssueの内容を要約し、「今日の開発ハイライト」を毎朝ポストする。
• 特定のブランチにPushされたときに、自動でテスト結果やパフォーマンスの変化をまとめて投稿する。
• チャットから「このPRの懸念点を教えて」「このエラーの原因候補を一覧にして」といった質問を投げる。

既存のコーディングエージェント（IDE拡張）と使い分ける形で、「チーム全体の文脈を把握している側のエージェント」として位置づけると、役割がはっきりします。

定常タスクの自動化

最後に、「人間がやるには単調だが、完全に捨てるには惜しい」定常タスクの自動化です。

• 毎週のレポートや議事録のテンプレートを自動生成し、必要な数値やログを埋め込んでおく。
• 定期的にSaaSのメトリクスを取得し、「今週変化の大きかった指標」をピックアップして通知する。
• チームメンバーのタスク進捗をざっくり集約し、「今週ブロッカーになっている項目」のみリストアップする。

こうしたタスクは、最初から完全自動化を目指すのではなく、「下書きや集計をClawdbotに任せ、人間が最終確認する」という運用から入るのが現実的です。

Clawdbotのセキュリティと注意点

Clawdbotは、「チャットからPCやクラウドを操作する」性質上、設計を誤るとセキュリティリスクが大きくなりがちです。

この章では、「入口制御」「権限・共有」「データ保存」「ログと監査」の4つの観点で、押さえておきたいポイントを整理します。

入口制御と許可設計

まず重要なのが、「どのチャネルからの入力を受け付けるか」と「誰がボットに命令できるか」の設計です。

入口の種類を決める（DM／グループ／スラッシュコマンド）

ClawdbotのGateway設定では、チャネルごと・エージェントごとに「受け付けるメッセージの種類」「利用可能なツール」を細かく制御できます。

特にDiscordやSlackなど複数ユーザーが出入りする環境では、「参加させるチャンネルの絞り込み」と「招待・キックの運用ルール」を事前に決めておくことが重要です。

• DMのみ受け付けるのか、特定のグループチャット／サーバーでのみ反応させるのか。
• メンションされたメッセージだけを処理する（mention gating / requireMention）運用にするのか。
• チャンネルごとに使用できるエージェントやSkillを制限するのか。
• 「/activation」（スラッシュコマンド）など、明示的な呼び出し経路だけに限定するのか。

DMはペアリング前提で閉じる（未知送信者を通さない）

加えて、DMは「誰でも命令できる入口」になりやすいため、未知の送信者はまずペアリング（owner承認）を要求し、承認されるまで処理しない運用が安全です。

たとえば、初回DMで返ってくるペアリングコードを確認し、管理者が次のように承認する流れになります。

clawdbot pairing list whatsapp
clawdbot pairing approve whatsapp <code> --notify

グループはAllowlist＋メンション必須から始める

グループチャット側は、Allowlistで「反応してよいチャンネル／ルーム」を限定するのが基本です。

さらに、グループ内のメッセージは「メンションされたときだけ返信する（requireMention）」「それ以外は返信せず文脈として扱う」といった挙動も併用できるため、最初はメンション必須で始めて、必要に応じて緩めるのが安全です。

Control UI／リモート公開は“認証ありき”で設計する

Control UIやGatewayのリモート接続を許可する場合は、WebSocket/API側の認証（トークン/パスワード等）を必ず有効にし、「認証がないと何もできない（fail-closed）」前提で公開範囲を設計しましょう。

権限と共有の統制

次に、「どのエージェントがどの権限を持つか」「そのエージェントを誰と共有するか」という観点です。

エージェントを用途で分ける（個人／チーム／ゲスト）

• 個人用エージェント：ファイル操作やシェル実行など、危険度の高いSkillも含めて広く許可。
• チーム用エージェント：GitHubやCIなど、共有して問題ない範囲のSkillに限定。
• ゲスト向けエージェント：閲覧専用の情報参照に絞る。

同じGatewayの中でも、プロファイルやエージェントを分けることで、権限を分離できます。

“強いエージェント”を共有チャネルに出さない

「何でもできる強いエージェント」をチーム全員が触れる場所に出してしまうと、意図しないコマンド実行や情報漏えいにつながりかねないため、用途ごとにエージェントを分けておくのが安全です。

実行系Skillは隔離して走らせる（可能ならサンドボックス）

加えて、危険度の高いSkill（シェル実行や広範なファイル操作など）は、可能であればサンドボックス（隔離環境）で実行し、ホストOSや社内ネットワークへの影響範囲を限定します。

データ保存と機密

Clawdbotは、会話履歴や設定、外部ツールから取得した情報をローカルストレージに保持します。
加えて、クラウドLLMを利用する場合は、プロンプトや一部のコンテキストがベンダー側に送信される点も押さえておく必要があります。

ローカル保存の範囲と保持期間を決める（ログ／キャッシュ／添付）

• ローカルに保存されるログ・キャッシュの範囲と保存期間を決める。
• 端末紛失・侵害時の影響が大きいもの（資格情報、添付、会話ログ）を優先して棚卸しする。

外部LLMに送るデータを区分する（データ分類の明文化）

• LLMプロバイダのプライバシーポリシーやデータ利用条項（学習への利用有無など）を確認する。
• 特に機微性の高いデータ（個人情報、機密設計書など）は、ローカルLLMのみを使うエージェントに限定する。

利用時には、「どのデータをどのエージェント経由で外部に出してよいか」をデータ区分ごとに整理し、ポリシーとして明文化しておくのが現実的です。

プロンプトインジェクション対策（貼り付け指示は“敵”として扱う）

また、運用上の落とし穴として「プロンプトインジェクション」や「社会的誘導」があります。
たとえば、チャット本文や貼り付けたテキストの中に「この手順でシェルを実行して」などの命令が紛れ込むと、意図せず実行系のSkillに誘導されるリスクがあります。

実行系のSkillは“信頼できる入口（DM/限定チャンネル）”に閉じ、最初は人間の最終確認を挟む運用にしておく方が安全です。

ログと監査

最後に、「後から何が起きたかを追えるか」という観点です。

何を残すかを決める（誰が／どこから／何を実行したか）

• Gateway側のログレベルと出力先（ファイル／集中管理されたログ基盤）を決める。
• 誰がどのチャネルから、どのエージェントにどのような指示を出したかを追跡できるようにしておく。

インシデント時の遮断手順を用意する（Skill無効化／入力遮断）

• 問題が起きたときに「特定のSkillを一時的に無効化する」「特定チャネルからの入力を遮断する」ための運用手順を用意する。

監査ログは、トラブルシューティングだけでなく、「このエージェントにどの程度の権限を与えてよいか」を見直す際の重要な材料にもなります。
最初は簡易なテキストログでも構いませんが、利用規模が大きくなるほど、中央集約型のログ基盤に流すことを検討すると良いでしょう。

起動前に監査コマンドで設定ミスを潰す（audit／deep）

運用開始前に、最低限の“安全確認”をコマンドで回しておくと、設定ミスを早期に潰せます。たとえば、次の監査コマンドで「危険な許可設定」「ローカルstate/configの権限設定」などを検知できます。

clawdbot security audit
clawdbot security audit --deep

ローカルstate/configの権限を維持する（監査を定期実行）

必要に応じて、監査結果に沿って自動で安全側へ寄せる（例：state/configの権限を締める）運用も有効です。共有端末や複数ユーザーが触れる環境では、ローカルに保存される設定や資格情報が緩いとトークン流出に直結するため、監査を定期的に回し、最小権限を維持することが重要です。

ClawdbotのFAQ

最後に、導入前後によく出てきそうな疑問を、Q&A形式でまとめます。

Q. Mac miniのような専用マシンが必須ですか？

A. 必須ではありません。軽めのチャット中心の使い方であれば、2GBメモリ・2コア程度の小さなVPSや、自宅に余っているPCでも十分動作します。

ブラウザ自動化や複数のワークフローを同時に走らせたい場合は、4GB以上のメモリと安定したネットワーク接続を用意しておくと安心です。

Q. 完全にローカルLLMだけで運用できますか？

A. できます。ClawdbotはOllamaなどのローカルLLMランタイムと連携でき、OpenAI互換APIとしてローカルモデルを利用できます。

その場合、LLMのAPI料金はかからず、GPUやCPUのリソースと電気代だけで運用することが可能です（モデルサイズや同時接続数によって体感速度は大きく変わります）。

Q. どのLLMプロバイダに対応していますか？

A. Anthropic Claude、OpenAI、OpenAI互換API（各種プロキシ）、Ollamaなど、主要なプロバイダに対応しています。

今後も対応プロバイダやモデルのラインナップは変化する可能性があるため、最新情報は公式ドキュメントの「Providers」セクションを確認してください。

Q. Anthropic Claude Pro/Maxなどのサブスクを直接使っても問題ありませんか？

A. Clawdbot自体は、Claude Pro/MaxやOpenAI CodexのOAuthサインインをサポートしていますが、サブスク認証の扱いは規約・提供形態の変更が起こり得る領域でもあります。

長期的・安定的な運用を考える場合は、公式が推奨するAPIキー経由の利用やローカルLLMへの切り替えを前提に設計しておく方が安全です。

Q. セルフホストは運用が大変そうですが、どこから始めるべきですか？

A. まずは手元のマシンや小さなVPSにGatewayを立て、個人のDMチャネルだけ接続した「マイボット」として試すのがよいでしょう。

そこで「こういう通知が欲しい」「こういうSkillがあると便利」といった要件が見えてきた段階で、チーム用のエージェントや本番用インフラへの展開を検討すると、無理なくスケールさせていけます。

Clawdbotのまとめ

Clawdbotは、「チャットUI＋LLM＋ツール実行＋スケジューラ」をセルフホストでまとめて扱えるAIアシスタント基盤です。
個人レベルでは、日々の情報整理や学習ログ、生活のちょっとした自動化を、普段使いのチャットアプリから一元的に回せるようになります。

チームや企業レベルでは、問い合わせの一次対応や開発フローのハブ、定常レポートの自動化など、「人がやるには単調だが、完全には捨てられない」作業の多くを肩代わりさせることができます。
一方で、入口制御や権限設計、データ区分といったセキュリティ面の設計を誤るとリスクも大きくなるため、Gatewayのポリシー設計とログ／監査の仕組みづくりはセットで考える必要があります。

LLMの選択肢としても、商用API・サブスク・ローカルLLMを状況に応じて組み合わせられるため、「まずは個人用環境で試し、その後チームや本番環境に段階的に広げていく」という導入パスが取りやすいプロジェクトです。
自社のセキュリティ要件やインフラ状況を踏まえつつ、「どのタスクをClawdbotに任せると最も効果が高いか」を考えるところから、検討を始めてみてください。