OpenClawのメッセージチャネル設定：まず1つを安全につなぐ

Telegram、Discord、Slack、WhatsAppを一度に設定する必要はありません。最初に選ぶべきなのは、人気が高そうなサービスではなく、自分で管理できるbot、app、workspace、server、または電話番号を持つ1チャネルです。DMで1人だけを承認し、その人のメッセージに対する返信が同じチャットへ戻るところまで確認してから、グループや追加機能へ進みます。

最初の用途	選ぶチャネル	最初に閉じておく範囲
自分専用のbotから始めたい	Telegram	1人のDMをペアリングし、グループはまだ追加しない
管理できる非公開serverで試したい	Discord	1つのserver・channel・userだけを許可し、メンション必須にする
電話番号が利用者の入口になる	WhatsApp	1番号のQRセッションと1送信者だけを承認する
社内workspaceへ置きたい	Slack	SocketかHTTPを先に決め、1DMまたは1channelだけで試す

2026年7月13日に確認したOpenClaw公式のチャネル設定では、TelegramとiMessageはcoreに含まれ、Discord、Slack、WhatsAppなどは個別pluginです。これは優劣の順位ではありません。pluginの配布元、platform側の権限名、commandやdefault policyは変わり得るため、実際の導入時は現在の公式ページと手元のCLI表示を照合してください。

最初のアクセス範囲は閉じたままにします。DMはpairing、グループはallowlist、共有channelではrequireMentionを維持します。テストを通すためだけにDMをopenへ変え、allowFrom: ["*"]を置くのは、接続確認ではなく公開運用への変更です。

接続完了の基準は、tokenが保存できたことでも、botがonlineになったことでも、QRを読み取れたことでもありません。想定したアカウントが解決され、1件のメッセージがGatewayへ入り、agent/modelが処理し、送信元と同じ会話に見える返信が戻ることです。

ここで一度止まります。 その1往復が確認できるまで、optional scope、追加group、別user、public access、2つ目のaccount、2つ目のchannelを増やさないでください。

チャネルを追加する前にGatewayとモデルを確認する

新しいchannelの問題を、不安定なOpenClaw本体の上で調べると原因が混ざります。Telegram tokenはprovider認証の失敗を直せず、Slack scopeは停止したGatewayを起動できません。まず、これからchannelを追加するのと同じinstallation、service、configで通常の1ターンが完了するかを確かめます。

最初は状態を変えない観察commandを使います。

hljs bash
openclaw status
openclaw gateway probe
openclaw doctor
openclaw channels list --all
openclaw channels status --probe

各commandの役割は異なります。

openclaw statusは、現在参照しているinstallationと大まかなruntime状態を示します。
openclaw gateway probeは、Gatewayに到達できるかを確認します。
引数なしのopenclaw doctorは、設定やmigration上の問題を観察します。最初からdoctor --fixを実行する手順ではありません。
openclaw channels list --allは、installed、configured、enabled、installableの違いを見分ける入口です。
openclaw channels status --probeは、Gatewayに到達できる場合にliveなaccount/transport状態を確認します。Gatewayが停止してconfigの要約へfallbackしただけなら、platform接続の証明にはなりません。

channel作業へ進める基準は、Gateway probeが通り、すでに使えるlocalまたはwebの入口でmodel-backed turnが完了し、選んだchannelがcore・installed・installableのどれかとして見えることです。ここでCLI自体、service、model routeが失敗しているなら、channel tokenやpermissionを変えず、先にその所有範囲を直します。

最初のチャネルは管理できる身元から選ぶ

「どれが一番良いか」ではなく、「どの身元と接続方式なら継続して管理できるか」で選びます。同じメッセージアプリでも、作成者、管理者、credentialの保管場所、接続が切れたときの復旧担当が曖昧なら、最初のchannelには向きません。

選択	向いている最初の場面	自分が管理するもの	最初に避ける条件
Telegram	1人または少人数向けの専用bot	BotFather identity、bot token、user/group ID、privacyとmention挙動	本当はworkspace app、server role、電話番号が必要
Discord	非公開serverや小規模community	Developer application、bot、intents、invite permission、guild/channel ID	serverを管理できず、有効なpermissionを確認できない
WhatsApp	電話番号を入口にする運用	linked device、QR session、番号、phone allowlist、session保存先	linked sessionを秘密かつ安定して保持できない
Slack	appをinstallできるworkspace	Slack app、Socket/HTTP、tokenまたはsigning secret、scopeとevent	appをinstallできず、必要なnetwork形状も用意できない

coreかpluginかも確認します。現在のCLIは、installableなcatalog channelであれば次のflag-drivenな形から現在のsourceを解決できます。

hljs bash
openclaw channels add --channel <name>

古い記事からpackage名を推測してconfig blockだけを追加するより、openclaw channels add --helpとchannels list --allで今の選択肢を見る方が安全です。また、最初はplatformだけでなくaccountも1つにします。Telegram botを2つ、Slack workspaceを2つ、WhatsAppの個人番号と業務番号を同時に扱うと、どのcredentialとrouteが返信したのか分からなくなります。

接続前に5項目を1行ずつ決める

credentialを保存しただけではchannelは完成しません。作業を始める前に、次の5項目を短く記録します。

項目	事前に答える質問	秘密を含めず残す証拠
身元	利用者に見えるbot、app、workspace、server、電話番号はどれか。管理者は誰か	account labelとstable ID
接続方式	coreかpluginか。polling、Discord Gateway、Socket、HTTP、QR linked sessionのどれか	installed channelと選んだmode
秘密情報	token、app token、signing secret、linked-device stateをどこから読むか	environment/file/SecretRefの参照先だけ
アクセス範囲	どのsender、DM、group、channel、guild、mention、commandを許可するか	pairing approvalとID-based allowlist
確認結果	inbound、model、outbound、見える返信を何のmessageで確認するか	時刻、probe、必要部分だけのlog、返信

この5行を書くと、見落としている責任が早く分かります。「Slackを使う」だけでは、Socket ModeかHTTP Request URLsかが未決定です。「WhatsAppをつなぐ」だけでは、どの電話番号とhostがlinked sessionを所有するかが未決定です。「Discord botがonline」だけでは、対象userのmessageが入り、同じchannelへ返信できたかが未確認です。

tokenやsessionを作業中の会話へ貼らない

publishableな例にはsecretの値を入れません。Gateway host上のprotected environment、file、または現在サポートされるSecretRefを使います。たとえばDiscordでは、値そのものではなくenvironment variableの参照をconfigに置けます。

hljs json5
{
  channels: {
    discord: {
      enabled: true,
      token: {
        source: "env",
        provider: "default",
        id: "DISCORD_BOT_TOKEN"
      }
    }
  }
}

DISCORD_BOT_TOKENの値はservice environmentに置き、config、chat、terminal screenshot、issue、support bundle、Git repositoryへ出しません。Telegram bot token、Slack bot/app token、Slack signing secret、WhatsApp authentication directory、QR dataも同じ扱いです。

TelegramはBotFatherと1件のDMから始める

Telegramは専用botを使うcore channelです。現在のOpenClaw Telegramガイドは、正規の@BotFatherでbotを作り、bot tokenを設定する方法を案内しています。default transportはlong pollingで、webhookはoptionalです。Telegramをopenclaw channels login telegramで接続するわけではありません。

1. botを作り、tokenをGateway hostへ置く

Telegramで正確な@BotFatherを開き、/newbotから名前とusernameを設定します。返されたtokenは、default accountならTELEGRAM_BOT_TOKENのenvironment fallback、named accountなら個別のbotTokenまたはtokenFileとして保護します。shell historyに値を残さない形を選びます。

hljs bash
openclaw channels add --channel telegram --use-env
openclaw gateway

2. groupより先にDMを1人だけ承認する

botへDMを1件送ります。defaultのdmPolicy: "pairing"では、未承認senderへ一時codeが返ります。自分が今発生させたcodeだけを確認し、承認します。

hljs bash
openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

現在、pairing codeは1時間で失効します。DMの承認は、そのsender identityのDM accessを許可するものです。すべてのgroup、group内のcommand、tool approvalまで自動的に開くわけではありません。

3. user IDとgroup chat IDを混同しない

Telegramでは、正のnumeric user IDと、-100で始まることが多い負のgroup/supergroup chat IDの役割が違います。

user IDはallowFromやgroupAllowFromで、誰が送れるかを表します。
負のgroup chat IDはchannels.telegram.groupsのkeyで、どの共有先を扱うかを表します。

負のgroup IDをgroupAllowFromへ入れても、group内の送信者を許可したことにはなりません。controlled messageを送りながらopenclaw logs --followでIDを確認し、最初のgroupではrequireMention: trueを残します。Telegram Privacy Modeもbotへ届くgroup messageを左右します。挙動を理解しないままPrivacy Modeを無効化したり、botをadministratorにしたりしないでください。

Telegramの最初の合格: probeが期待したbotを解決し、承認済みDMがGatewayへ入り、model処理後の返信が同じDMに戻ることです。その後に限り、group IDを1つ追加し、明示的な@botusernameメンションで再確認します。

Discordは非公開serverと最小権限で試す

Discordはapplicationとbotを作り、Discord Gatewayへ接続するplugin channelです。botのonline表示はtransportの一部が動いたことしか示さず、serverのmessage content、user access、返信permissionまでは証明しません。

1. 最初のtext routeに必要なintentsだけ有効にする

OpenClaw Discordガイドに沿ってDeveloper Portalでapplicationとbotを作ります。通常のtext routeでは次を区別します。

Message Content Intent: 通常のmessage本文を扱うために必要です。
Server Members Intent: 推奨されます。role allowlist、name-to-ID resolution、channel audienceのaccess groupがmember dataを使う場合は必要です。
Presence Intent: presence updateが実際の用途に含まれる場合だけ追加します。

inviteではbotとapplications.commands scopeを選びます。最初のtext channelでは、View Channels、Send Messages、Read Message History、Embed Links、Attach Filesが基準です。Add Reactionsはoptional、Send Messages in Threadsは最初からthreadを使う場合だけです。voice、moderation、role管理、広いadministrator権限は別の拡張として扱います。

2. DMまたは1つのserver channelだけで確認する

Gateway hostにDISCORD_BOT_TOKENを置き、現在のchannel add routeを使います。

hljs bash
openclaw channels add --channel discord --use-env
openclaw channels status --channel discord --probe

DMを利用できる場合は、まず1人をpairingします。

hljs bash
openclaw pairing list discord
openclaw pairing approve discord <CODE>

server側は、管理できるprivate serverとchannelを1つだけ選びます。groupPolicy: "allowlist"を維持し、server IDとuser IDをnumeric IDで記録し、mentionを必須にします。

hljs json5
{
  channels: {
    discord: {
      groupPolicy: "allowlist",
      guilds: {
        "YOUR_SERVER_ID": {
          requireMention: true,
          users: ["YOUR_USER_ID"]
        }
      }
    }
  }
}

Discordの最初の合格: probeが期待したbot identityと必要なintentsを確認し、想定userがDMまたはallowlist済みchannelから1件を送れ、そこへ返信が見えることです。onlineなのにserverで沈黙するなら、Message Content Intent、guild/channel allowlist、user restriction、mentionの順に確認し、permissionを一括追加しません。

WhatsAppは番号の所有者とQRセッションを先に決める

WhatsAppは、電話番号をWhatsApp Web/Baileys経由でGateway-owned sessionへlinkするplugin channelです。現在のOpenClaw WhatsAppガイドが示すのはTwilioの別channelではなく、QR認証されたlinked sessionです。

pluginがまだない場合、interactiveなchannel設定からinstallを案内できます。現在のmanual sourceは次です。

hljs bash
openclaw plugins install clawhub:@openclaw/whatsapp

1. どの電話番号がOpenClawを表すか決める

専用番号は、利用者に見える身元とallowlistが明確になるため推奨されます。個人番号とself-chatを使う構成もサポートされますが、senderとlinked accountが同じ人になる境界があります。QRを読み取る前に、番号を所有する人、deviceをunlink/relinkできる人、authentication directoryを保持するhostを決めます。

documentやconfig例にはE.164形式のplaceholderだけを使い、最初のgroup policyは閉じます。

hljs json5
{
  channels: {
    whatsapp: {
      dmPolicy: "pairing",
      allowFrom: ["<YOUR_NUMBER_E164>"],
      groupPolicy: "allowlist",
      groupAllowFrom: ["<YOUR_NUMBER_E164>"]
    }
  }
}

2. 生きているQRを表示できるterminalでlinkする

hljs bash
openclaw channels login --channel whatsapp

loginはQR-onlyです。phoneから読めるlive QRを表示できるterminalで実行します。screenshotやchat attachmentを経由している間にQRが失効する場合があります。読み取り後のauthentication directoryはtokenと同じcredentialです。Gatewayがsocketとreconnect loopを所有するため、明確なaccount migrationなしにdirectoryを複数hostへcopyすると、session ownerが競合します。

最初のsenderがpairingを発生させたら、対象codeだけを承認し、live stateをprobeします。

hljs bash
openclaw pairing list whatsapp
openclaw pairing approve whatsapp <CODE>
openclaw channels status --channel whatsapp --probe

WhatsAppの最初の合格: 想定したlinked accountがliveで、承認済み番号のmessageがGatewayへ入り、返信が同じchatに戻ることです。それまではgroup、追加番号、2つ目のlinked accountを有効にしません。

Slackはscopeより先にSocketかHTTPかを選ぶ

Slackでは、最初にnetworkと運用形状を決めます。公式pluginをinstallし、現在のOpenClaw SlackガイドからSocket ModeまたはHTTP Request URLsを選びます。

hljs bash
openclaw plugins install @openclaw/slack

配置条件	Socket Mode	HTTP Request URLs
公開inbound URL	不要	DNS、TLS、到達可能なevent pathが必要
接続方向	GatewayからSlackへのoutbound WebSocket	SlackからGatewayへのsigned HTTPS request
credential	bot token + `connections:write`を持つApp-Level Token	bot token + signing secret
最初に合う構成	1台のGateway、開発host、firewall内	複数Gateway、既存のpublic webhook基盤

両modeはmessageとinteractionについて同等の機能を持つため、networkとscalingの責任で選びます。二組のcredentialをbackupのつもりで同時設定しません。Socketのapp tokenとbot tokenは同じSlack app/workspaceの組である必要があり、HTTP modeはmatching signing secretでrequestを検証する必要があります。

最小manifestから1DMまたは1mentionを通す

Slack公式channelページのcurrent minimal/recommended manifestを起点にします。最初のDMまたはmentionに不要なfile、reaction、history、App Home、slash command、interactive scopeを全部付けません。featureを1つ追加するとき、そのfeatureに必要なscope/eventを追加し、元のtext replyも再確認します。

Slack DMはdefaultでpairingです。

hljs bash
openclaw pairing list slack
openclaw pairing approve slack <CODE>

共有channelでは、表示名の#channel-nameではなくC...形式のstable channel IDをallowlistに使います。allowlist policy下ではname-based keyが無視され、接続済みappが沈黙しているように見える場合があります。channel messageはdefaultでmention-gatedなので、最初の境界として維持します。

Slackの最初の合格: probeが正しいapp credentialとtransportを解決し、想定workspaceのpairing済みDMまたは許可channelのmentionが入り、同じDMまたはthreadへ返信が見えることです。configured_unavailable、tokenの組違い、missing scope、signature failureはcredential/transportの修復対象であり、広いallowlistを与える理由ではありません。

1件の返信経路を最後まで確認する

ここからはconfigではなく、messageが通った経路を確認します。有効なtokenでもsenderが拒否される場合があり、socketがconnectedでもeventが許可されない場合があり、modelが完了しても元のthreadへ送れない場合があります。

test messageを送る前に、観察する面を開きます。

hljs bash
openclaw channels status --probe --json
openclaw channels logs --channel all
openclaw logs --follow

想定senderから、他と区別できる短いmessageを1件送ります。たとえばReply exactly: CHANNEL-OK-714です。送信時刻と、使用したDM、group、server channel、workspace channel、WhatsApp chatを記録します。

確認地点	合格の証拠	最初に失敗した場合の範囲
身元	probeが期待したbot、app、workspace、linked numberを解決	account、credential、SecretRef、古いlinked session
接続	core/plugin runtimeとprovider connectionがhealthy	plugin、Gateway network、Socket/HTTP、Discord Gateway、polling、QR session
アクセス	senderと宛先がpairing/allowlistに一致	pairing、sender ID、group/channel ID、guild/workspace、mention、command authorization
受信	unique messageが指定時刻のlogに現れる	event、intent、subscription、privacy mode、routing
model	対象agent/modelがそのturnを完了	provider auth、model availability、rate、timeout、agent route
送信	元のrouteと宛先へのdelivery attemptが見える	platform permission、signature/session、thread target、send failure
見える返信	承認senderが同じ場所で指定返信を確認	宛先/threadのずれ、client visibility、outbound delivery

7地点すべてが通って初めて、最初のchannelを接続済みとして扱えます。account label、秘密でないdestination IDまたはhash、probe結果、時刻、関連error行、見える返信をredactして残します。token値、signing secret、session file、QR data、private message全文、無関係なlogは残しません。

追加は毎回1項目だけにする

最初の返信が通った後も、一度に複数の境界を広げません。private senderから始め、authorizationまたは運用の複雑さを1段ずつ増やします。

次の追加	変わるもの	次へ行く前に再確認すること
DMを1人pairing	1 senderがprivateに到達できる	同senderの受信、model完了、同じDMの返信
明示allowlistを1件追加	一時承認からdurable identityへ移る	probeと同じDM test
group/channelを1つ追加	共有destinationとstable IDがscopeに入る	承認userのmention付きmessage
optional featureを1つ追加	scope、event、intent、media、file、command、interactionが増える	feature固有の操作と元のtext reply
userを追加	routeを呼べる人が増える	許可userと未許可userの両方
2つ目のaccount/channel	身元、secret、transport、routing、復旧担当が増える	新routeで7地点すべて

openはpairingの次の便利な段階ではなく、公開運用という別モデルです。open DMには明示wildcardが必要で、botを見つけた任意accountが到達できます。意図的なpublic bot、制限されたtool、abuse control、露出を引き受けるownerが揃う場合だけ選びます。

command authorizationも分けて確認します。DMでpairingした人が、すべてのgroupでowner commandを実行できるとは限りません。commands.ownerAllowFrom、channel allowlist、group sender rule、tool approvalを実際のoperatorに合わせます。

失敗した最初の地点だけを直す

接続testが失敗したとき、setup全体をやり直す必要はありません。最初に証拠が欠けた場所を修復対象にします。

症状	主な担当範囲	次の小さな操作
`channels list --all`にchannelがない	catalog、plugin、installation	current channel pageと`channels add --channel <name>`を確認し、架空configを作らない
Gateway probeが失敗	OpenClaw runtime/service	channel作業を止め、Gatewayの所有範囲を修復
credentialがinvalid/unavailable	SecretRef、platform identity	選択accountを確認し、必要なら影響するsecretだけrotate
connectedだがinboundがない	pairing、allowlist、mention、event、intent、platform privacy	senderとdestinationをchannelの条件と照合
inboundはあるがmodel完了がない	agent、model、provider route	model routeを単独でtestし、channel permissionを広げない
modelは完了するが返信が見えない	outbound permission、destination/thread、session、platform send	outbound logと実際の宛先を確認
setup後にbotがonlineのまま沈黙	稼働中routeのruntime	OpenClawの無返信診断で最初に欠けた証拠まで進む
secret/sessionを公開した	platform credentialとincident対応	該当credentialだけをrevoke/rotateし、必要ならsessionをunlinkして再確認

plugin reinstall、全token rotation、Gateway restart、group policy変更、model変更を一回にまとめると、どれが効いたか分かりません。1回に1変更を行い、失敗したのと同じmessageを同じ宛先から再送し、返信まで確認します。

よくある質問

OpenClawで最初に接続するならTelegram、Discord、Slack、WhatsAppのどれですか？

管理できる身元と配置で選びます。1人用の専用botならTelegram、非公開serverならDiscord、電話番号が入口ならWhatsApp、appをinstallできるworkspaceならSlackが自然です。すべての人に共通する1位はありません。

channelやpluginがunavailableと表示されるのはなぜですか？

openclaw channels list --allでcore、installed、configured、enabled、installableを区別します。Telegramは現在core、Discord・Slack・WhatsAppはpluginです。古いpackage specを推測せず、current official instructionまたはopenclaw channels add --channel <name>に現在のsourceを解決させます。

Telegramでも`openclaw channels login telegram`を使いますか？

使いません。正規の@BotFatherでbotを作り、tokenをprotected config/environmentへ置き、Gatewayを起動します。interactive loginはWhatsAppのようなQR/session channelで使います。

DMをpairingすればgroupでも使えますか？

自動では使えません。DM pairingはそのsender identityのprivate accessです。group、guild、workspace、channel、group内sender、mention、commandには別のruleがあります。destination IDを1つずつ追加し、承認userのmentionで再確認します。

Discordの最初のtext testに必要なpermissionは何ですか？

Message Content Intentを有効にし、botとapplications.commands scopeでinviteします。対象channelではView Channels、Send Messages、Read Message History、Embed Links、Attach Filesを基準にします。Server Members Intentは推奨で、role/audience controlにmember dataを使う場合は必要です。reaction、thread、voice、moderation、presenceは別の追加です。

SlackはSocket ModeとHTTP Request URLsのどちらを選びますか？

1台のGatewayや公開inbound URLを持たないhostならSocket Modeが扱いやすく、複数Gatewayや既存のpublic webhook基盤ならHTTP Request URLsが合います。Socketはbot tokenとApp-Level Token、HTTPはbot tokenとsigning secretを使います。

channel tokenやWhatsApp sessionはどこに保存しますか？

Gateway hostのprotected environment、file、またはcurrent SecretRefに保存します。token、Slack signing secret、WhatsApp auth directory、QR data、pairing codeをchat、screenshot、issue、repositoryへ入れません。

botがonlineなのに返信しないときは何を確認しますか？

openclaw channels status --probeとbounded logを開き、unique messageを1件送ります。身元、接続、アクセス、受信、model、送信、見える返信のうち、最初に欠けた地点で止めます。online表示を理由にpermissionを増やさないでください。

2つ目のチャネルはいつ追加できますか？

最初のrouteが1 senderで7地点を通り、groupまたはfeatureを1項目追加した後も安定して返信できたときです。2つ目は新しい身元、plugin/transport、secret、policy、routing、復旧担当を持つため、同じ7地点を新規に確認します。

WhatsAppは専用番号が必須ですか？

必須ではありませんが推奨です。専用番号は利用者に見える身元とallowlistを明確にします。個人番号/self-chatを使う場合も、番号とlinked sessionのowner、保管host、unlink/relink担当を決め、1 chatの返信を確認してからgroupへ進みます。

最初のゴールは、チャネル数を増やすことではありません。守られた1 routeで、誰が送り、どこを通り、どこへ返信したかを説明できる状態です。次に広げる範囲、その管理者、同じ経路を再確認するmessageが言えるようになってから、次の1項目へ進んでください。

OpenClawのメッセージチャネル設定：まず1つを安全につなぐ

目次

チャネルを追加する前にGatewayとモデルを確認する

最初のチャネルは管理できる身元から選ぶ

接続前に5項目を1行ずつ決める

tokenやsessionを作業中の会話へ貼らない

TelegramはBotFatherと1件のDMから始める

1. botを作り、tokenをGateway hostへ置く

2. groupより先にDMを1人だけ承認する

3. user IDとgroup chat IDを混同しない

Discordは非公開serverと最小権限で試す

1. 最初のtext routeに必要なintentsだけ有効にする

2. DMまたは1つのserver channelだけで確認する

WhatsAppは番号の所有者とQRセッションを先に決める

1. どの電話番号がOpenClawを表すか決める

2. 生きているQRを表示できるterminalでlinkする

Slackはscopeより先にSocketかHTTPかを選ぶ

最小manifestから1DMまたは1mentionを通す

1件の返信経路を最後まで確認する

追加は毎回1項目だけにする

失敗した最初の地点だけを直す

よくある質問

OpenClawで最初に接続するならTelegram、Discord、Slack、WhatsAppのどれですか？

channelやpluginがunavailableと表示されるのはなぜですか？

DMをpairingすればgroupでも使えますか？

Discordの最初のtext testに必要なpermissionは何ですか？

SlackはSocket ModeとHTTP Request URLsのどちらを選びますか？

channel tokenやWhatsApp sessionはどこに保存しますか？

botがonlineなのに返信しないときは何を確認しますか？

2つ目のチャネルはいつ追加できますか？

WhatsAppは専用番号が必須ですか？

タグ

この記事を共有

関連記事

OpenClawが返信しないとき：メッセージが止まった場所を特定する

OpenAI Workspace Agentsの使い方：権限確認から安全な構築、API、運用管理まで

OpenClawのインストールに失敗したら？再実行前に止まった箇所を特定する

目次

チャネルを追加する前にGatewayとモデルを確認する

最初のチャネルは管理できる身元から選ぶ

接続前に5項目を1行ずつ決める

tokenやsessionを作業中の会話へ貼らない

TelegramはBotFatherと1件のDMから始める

1. botを作り、tokenをGateway hostへ置く

2. groupより先にDMを1人だけ承認する

3. user IDとgroup chat IDを混同しない

Discordは非公開serverと最小権限で試す

1. 最初のtext routeに必要なintentsだけ有効にする

2. DMまたは1つのserver channelだけで確認する

WhatsAppは番号の所有者とQRセッションを先に決める

1. どの電話番号がOpenClawを表すか決める

2. 生きているQRを表示できるterminalでlinkする

Slackはscopeより先にSocketかHTTPかを選ぶ

最小manifestから1DMまたは1mentionを通す

1件の返信経路を最後まで確認する

追加は毎回1項目だけにする

失敗した最初の地点だけを直す

よくある質問

OpenClawで最初に接続するならTelegram、Discord、Slack、WhatsAppのどれですか？

channelやpluginがunavailableと表示されるのはなぜですか？

Telegramでもopenclaw channels login telegramを使いますか？

DMをpairingすればgroupでも使えますか？

Discordの最初のtext testに必要なpermissionは何ですか？

SlackはSocket ModeとHTTP Request URLsのどちらを選びますか？

channel tokenやWhatsApp sessionはどこに保存しますか？

botがonlineなのに返信しないときは何を確認しますか？

2つ目のチャネルはいつ追加できますか？

WhatsAppは専用番号が必須ですか？

タグ

この記事を共有

関連記事

OpenClawが返信しないとき：メッセージが止まった場所を特定する

OpenAI Workspace Agentsの使い方：権限確認から安全な構築、API、運用管理まで

OpenClawのインストールに失敗したら？再実行前に止まった箇所を特定する

Telegramでも`openclaw channels login telegram`を使いますか？