ClawdbotをDiscordで使おうとしたのに、「Botを招待したのに反応しない」「権限をどこまで付ければいいか分からない」「チャンネルを限定したいのに設定が難しい」——そんなところで止まっていませんか。実は、つまずきの原因はだいたい決まっており、Intents・allowlist・トークン設定のどれかが抜けているケースがほとんどです。
本記事では、Discord Developer PortalでのBot作成から、Clawdbot側の設定キー、最小権限での運用、特定チャンネル限定の設計、そして無反応時に5分で切り分ける復旧手順までを、迷いどころを先回りしながら整理して解説します。読み終える頃には「動かす」だけでなく、「安全に使い続ける」ための型まで手元に残るはずです。
※本コンテンツは「記事制作ポリシー」に基づき、正確かつ信頼性の高い情報提供を心がけております。万が一、内容に誤りや誤解を招く表現がございましたら、お手数ですが「お問い合わせ」よりご一報ください。速やかに確認・修正いたします。
ClawdbotをDiscordで使いたい人が最初につまずくポイント
ClawdbotをDiscordで動かす作業は、見た目以上に「引っかかりどころ」が決まっています。多くの人がつまずくのは、次の3つです。
1つ目はDiscord側の設定（Intents・Scopes・Permissions）が混ざって理解しづらいことです。権限（Permissions）だけ整えても、BotのGateway Intentsが不足していると「メッセージ本文を受け取れず反応しない」状態になり得ます。公式のDiscordチャネル手順でも、用途に応じたIntentsの有効化が前提として扱われています。
2つ目はClawdbot側の設定キーの迷いです。ClawdbotではDiscordチャネルの設定として channels.discord.token を使い、環境変数 DISCORD_BOT_TOKEN はフォールバックとして扱われます。また channels.discord.enabled が false でないことが起動条件に含まれます。ここが曖昧だと「どこにトークンを入れたのに動かない」が発生します。
3つ目はallowlist（チャンネル限定）の書き方です。Discordサーバ（ギルド）内の許可チャンネルは、channels.discord.guilds.<サーバID>.channels にチャンネルIDを列挙する形で制御するのが基本です。DMやグループDMは別系統の設定で扱われるため、ここを混同すると「想定外の場所で反応」または「どこでも反応しない」が起きやすくなります。
Clawdbot Discord導入の全体像とゴール設定
この記事で達成するゴール
この記事を読み終えた時点で、次を達成できる状態をゴールにします。
-
DiscordでBotを作成し、必要なIntents・Scopes・Permissionsを理解したうえで設定できる
-
Clawdbotに
channels.discord.token（またはDISCORD_BOT_TOKEN）を設定し、Discordチャネルを起動できる -
channels.discord.guilds.<id>.channelsを使って、反応させるチャンネルを限定できる -
反応しないときに、原因を5分で切り分けて復旧できる
-
“DM限定でも起こり得る”prompt injection等を踏まえ、縮退運用で安全に運用開始できる
導入フロー（Discord側→Clawdbot側）
作業は大きく4ブロックです。
-
Discord Developer PortalでApplication（アプリ）を作成
-
Botトークンを発行し、Gateway IntentsとPermissionsを整える
-
OAuth2 URL Generatorで招待URLを作り、Botを自分のサーバへ追加する
-
Clawdbot側にトークンとallowlistを設定し、起動→疎通確認する
事前準備チェックリスト
-
Botを追加したいDiscordサーバの管理権限（招待・権限付与ができる）
-
DiscordのDeveloper Modeを有効化し、サーバID/チャンネルIDを取得できる状態
-
Clawdbotを動かすPCまたはサーバ（常時稼働させるならVPS/自宅サーバ/ラズパイ等）
-
「どのチャンネルで使いたいか」を先に決めておく（allowlist設計が楽になります）
-
トークンを保管する方針（環境変数か設定ファイルか、漏洩対策）
Discord Developer PortalでBotを作成する手順
手順1：Applicationを作る
Discord Developer Portalで「New Application」からアプリを作成し、任意の名前を設定します。このアプリが“Botの入れ物”になります。
作業のポイントは、名前は後で変えられるので「まず作る」ことです。迷いがちな人ほど、ここで止まりがちです。
手順2：Botを作成し、Tokenを発行する
Applicationを作成したら、サイドメニューの「Bot」へ移動し、Botを作成します。Tokenは「Reset Token」等から発行し、必ず安全な場所へ控えます。
トークン取り扱いの基本（ここだけは徹底）
-
DiscordのチャットやSNS、スクショ、共有ドキュメントに貼らない
-
ターミナルの履歴に残りやすい形でコマンド直打ちしない
-
誤って公開した可能性がある場合は“即再発行”し、旧トークンを無効化する
ClawdbotはDMやサーバ内で動く“エージェント”として強い権限を持ち得るため、トークン管理は最初に固めるべきセキュリティ境界です。
手順3：Gateway Intentsを有効化する（反応しない原因の最頻ポイント）
DiscordのBot設定には「Gateway Intents」があります。用途に応じて、DMやギルドメッセージ、Message Content（メッセージ本文）などが必要になります。Clawdbot公式のDiscord手順でも、必要なIntentsを有効化してトークンを取得する流れになっています。
よくある落とし穴：
「権限（Permissions）を付けたのに、本文が取れず反応しない」ケースです。これはIntents不足で発生し得ます。最初は“必要最低限の用途”に合わせて有効化し、後から増やす方針で問題ありません。
手順4：OAuth2 URL Generatorで招待URLを作る
Botは通常の招待リンクではなく、OAuth2でサーバへ追加します。Discord公式のOAuth2ドキュメント、および開発ガイドでも、OAuth2 URL Generatorでスコープ（bot / applications.commands等）を選び、招待URLを生成する流れが示されています。
Scopesの考え方（混同しやすいので分けて理解）
-
Scopes：アプリが“何をするアプリか”の申請（例：bot、applications.commands）
-
Permissions：Botが“サーバ内で何をできるか”の権限（例：Send Messages）
スコープだけ選んで権限ゼロ、または権限だけ意識してスコープ不足、という事故が起こりがちです。両方をセットで揃えます。
最小権限で始めるためのPermissions設計
権限は「困ったら全部付ける」ではなく「理由がある分だけ付ける」
Discord公式のPermissionsは、階層・上書き・計算ルールが明文化されています。まずは“会話に必要な分”に絞るのが安全です。
最小権限セット早見表（用途別）
| 用途 | まず検討するPermissions | 理由・注意 |
|---|---|---|
| 指定チャンネルで会話（送受信） | View Channels / Send Messages / Read Message History | 会話の最小セット。チャンネル側の上書きで絞ると安全 |
| リンク埋め込み表示 | Embed Links | 出力の見栄えに必要なことがある。不要なら付けない |
| スラッシュコマンドも使う | （Scopes）applications.commands | URL Generatorで追加。運用が複雑になるため、最初は後回しでもよい |
| 管理系操作（基本非推奨） | Manage Channels / Manage Roles 等 | 初期導入では避ける。被害半径が急増するため |
推奨の進め方（縮退運用）
-
最初は「会話できる最小権限＋allowlistで1チャンネルだけ」
-
動作確認後に、必要になった権限だけ増やす
-
管理系権限は“どうしても必要になった時だけ”理由を書ける状態で付与する
ClawdbotでDiscordチャネルを有効化する（公式仕様に沿った設定）
ClawdbotがDiscordを起動する条件
Clawdbot公式によると、Discordチャネルは概ね次の条件で起動します。
-
channels.discord.tokenが設定されている（またはフォールバックとしてDISCORD_BOT_TOKENが利用可能） -
channels.discord.enabledがfalseではない
ここが曖昧だと、導入が成功しているのに「起動していない」状態になります。
トークンの設定場所：どこが安全か
トークンの設定は大きく2択です。
-
環境変数（推奨しやすい）：運用で設定ファイル露出を減らせる
-
Clawdbot設定（設定ファイル等）：導入は簡単だが、閲覧権限・バックアップ・共有PCでの扱いに注意
公式ドキュメント上は channels.discord.token と環境変数フォールバックの両方が説明されています。どちらにせよ「見える場所に残さない」設計が重要です。
トークン管理の現実的な落としどころ（運用Tips）
-
個人PC：OSの秘密情報管理（キーチェーン等）→起動時に環境変数へ注入
-
サーバ：systemd等のサービス設定で環境変数を持たせ、ファイル権限を最小化
-
共有環境：そもそも共有しない（トークンは権限そのものです）
allowlistで「このチャンネルだけ反応」を確実にする
Clawdbotのグループ（サーバ）側の制御は、公式のGroups概念で整理されています。Discordの場合、allowlistは channels.discord.guilds.<id>.channels を使うのが基本です。
まずは「1チャンネルだけ」で動作確認する
運用を安全に始めるコツは、最初から複数チャンネルで使わないことです。
-
最初はテスト用チャンネルを1つ作る
-
allowlistにそのチャンネルIDだけ入れる
-
動いたら、用途別にチャンネルを増やす（例：作業ログ用、相談用）
DMやグループDMは別扱いになる
Groupsの説明では、Discordのグループ（ギルド）とDM系は分けて扱う前提が示されています。DMも使いたい場合は、DM側の設定系（channels.discord.dm.*）を参照しつつ、まずはギルドで安定させるのが安全です。
動作確認のやり方（最短で「動いた」を作る）
テスト手順（最短ルート）
-
Botを招待したDiscordサーバで、テスト用チャンネルを開く
-
allowlistがそのチャンネルを許可していることを確認する
-
Botにメッセージを送る（運用方針によりメンションが必要な場合は@mentionで開始）
-
返答が来るか、別チャンネルに漏れていないか確認する
-
問題があれば次章のトラブル表で切り分ける
“動いたのに危ない”状態を避ける確認
-
Botが想定外のチャンネルで反応しない（allowlistが効いている）
-
権限が過剰でない（管理系権限を付けていない）
-
トークンをどこにも貼っていない（ログや共有メモ含む）
反応しない・エラーが出る時の5分切り分け
ここは“最重要”なので、症状→原因→確認→対処を表で固定します。
症状別トラブルシュート早見表
| 症状 | 最頻原因 | 確認（3ステップ） | 対処 |
|---|---|---|---|
| まったく無反応 | Intents不足／allowlist漏れ／チャネル未起動 | ①Bot Intents確認 ②allowlist確認 ③Clawdbot側でtoken設定有無 | Intents有効化、allowlistを1チャンネルに絞り直す、channels.discord.tokenを再確認 |
| 起動していない感じ | token設定先の混線／enabled=false |
①channels.discord.token ②DISCORD_BOT_TOKEN ③channels.discord.enabled |
参照元を一本化し、enabledを見直す |
| 403っぽい権限エラー | Permissions不足 | ①View Channels ②Send Messages ③Read Message History | 会話の最小権限だけ追加。チャンネル上書きで付与 |
| たまに遅い／途切れる | レート制限・スパム扱い | ①短時間連投の有無 ②自動返信頻度 ③同時チャンネル数 | 送信頻度を下げ、まとめ返信にする。運用を縮退 |
無反応の原因トップ3を先に潰すチェックリスト
-
Gateway Intents：Message Content等が用途に対して不足していないか
-
allowlist：
channels.discord.guilds.<id>.channelsが正しいサーバID・チャンネルIDになっているか -
トークンの参照元：
channels.discord.tokenとDISCORD_BOT_TOKENが混在していないか（どちらを見る運用かを決める）
それでも直らない場合の次の一手
-
Botをサーバから一度外し、再招待（URL GeneratorのScopes/Permissionsを見直す）
-
チャンネル権限上書きで“見えているが送れない”状態を疑う（View/Send/Historyの組み合わせを確認）
-
まずはテストチャンネル1つだけに限定し、段階的に広げる（縮退運用）
安全に運用するためのベストプラクティス（E-E-A-T強化）
“DM限定なら安全”は誤解になり得る
Clawdbotのセキュリティガイドでは、送信者が限定されていても、ボットが読む外部コンテンツ（検索結果、Webページ、メール、添付、貼り付けログ等）を通じてprompt injectionが起こり得る点が明確に説明されています。つまり「誰が送るか」だけでなく「何を読ませるか」が脅威面になります。
まず守るべき縮退運用ルール
-
初期はツールやスキルを最小化し、いきなり強い操作（ファイル・ネットワーク・外部送信）を許可しない
-
allowlistでチャンネルを限定し、意図しない入力面を増やさない
-
ログに機密（トークン、個人情報、URL）を残さない
-
“外部の文章をそのまま信じて実行しない”運用（リンク先の指示を鵜呑みにしない）
トークン漏洩時の即時対応手順（事故対応の型）
万一、トークンを貼ってしまった可能性がある場合は「多分大丈夫」で止めないのが重要です。
-
Discord Developer PortalでTokenを再発行（旧トークンを無効化）
-
Clawdbot側の設定（
channels.discord.tokenまたは環境変数）を新トークンへ更新 -
サービス/デーモンを再起動（古いトークンのプロセスを残さない）
-
Botが想定外のサーバやチャンネルに居ないか監査（招待履歴・権限）
-
今後のために、トークンの保管方法を“仕組み化”して再発防止
権限監査のルール（毎月1回でも効果が高い）
-
“最小権限”から増えた権限を一覧にし、用途が説明できない権限は外す
-
チャンネル上書きで絞れるものは絞る（サーバ全体付与を避ける）
-
管理系権限は原則禁止（必要なら別Botに分離する選択肢も検討）
よくある質問（FAQ）
DiscordのDMでも使えますか
公式のGroups概念では、Discordのギルド（サーバ）とDMは別系統で扱われる前提が示されています。まずはサーバ内でallowlist運用を安定させ、次にDM設定系（channels.discord.dm.*）の設計へ進むのが安全です。
複数サーバで使えますか
可能ですが、最初は1サーバでの運用確立を推奨します。複数サーバに広げると、allowlist・権限・入力面が増え、事故（想定外反応、入力面拡大、監査困難）が増えます。安全運用の基本は「面を増やさない」です。
反応させるチャンネルを増やす判断基準は
次の2条件を満たす場合だけ増やすのが堅牢です。
-
そのチャンネルに“Botがいる理由”が説明できる
-
そのチャンネルで扱う情報が、万一外部に出ても致命傷にならない（機密を流さない運用ができる）
どの設定が正しいか迷ったら何を基準にすべきですか
基準は公式ドキュメントです。特にDiscordチャネル手順、Groups（allowlist構造）、Securityは優先して参照してください。
最短チェックリスト（今日やること）
導入の最短チェック
-
DiscordでApplication作成→Bot作成→Token発行
-
Gateway Intentsを用途に合わせて有効化（Message Content等）
-
OAuth2 URL GeneratorでScopes/Permissionsを設定し、Botをサーバへ招待
-
Clawdbotへ
channels.discord.token（またはDISCORD_BOT_TOKEN）を設定し、Discordチャネルを起動 -
channels.discord.guilds.<id>.channelsにテスト用チャンネル1つだけ許可して疎通確認
運用の最短チェック
-
権限は最小のまま。増やす時は理由が説明できる
-
トークンを貼らない・残さない・漏洩時は即再発行
-
DM限定でもprompt injectionが起こり得る前提で、外部コンテンツの扱いを制限する
参考情報源
-
Clawdbot公式ドキュメント（Discordチャネル）
https://docs.clawd.bot/channels/discord -
Clawdbot公式ドキュメント（Groupsとallowlistの考え方）
https://docs.clawd.bot/concepts/groups -
Clawdbot公式ドキュメント（Security：prompt injection等）
https://docs.clawd.bot/gateway/security
