#Discordでのでの呼び分けとサーバーでの発言
1 messages · Page 1 of 1 (latest)
大きく2点です。
USER.mdは「Discordユーザーごとの自動プロフィールDB」ではありません。エージェントの workspace にある共通の bootstrap ファイルで、毎セッション読み込まれる「このエージェントが誰に仕えるか / どう呼ぶか」の説明です。
複数人がDMする構成なら、まず大事なのは USER.md ではなく DMセッションの分離です。デフォルトの session.dmScope=main だとDMが同じ main session に寄るので、複数人が使うなら推奨はこれです:
{
session: {
dmScope: "per-channel-peer"
}
}
必要ならさらに per-account-channel-peer。同一人物の別チャンネルIDを同じ扱いにしたい場合は session.identityLinks を使います。
人ごとの永続メモを残したい場合は、USER.md に全員分を雑に詰めるより、MEMORY.md に Discord ID 付きで「この人はこう呼ぶ」みたいに記録するか、完全に別ユーザー向けなら agent/workspace を分けるのが安全です。
Docs:
https://docs.openclaw.ai/concepts/session
https://docs.openclaw.ai/concepts/agent-workspace
- サーバーでメンションすると👀リアクション+入力中になるのに返事が出ない件は、かなり典型的には Discordのguild/channelでは通常の final answer が非公開扱いになっていて、モデルが
message(action=send)を呼ばずに終わっているパターンです。
確認ポイント:
openclaw --versionをまず確認してください(バージョン差で挙動が変わることがあります)openclaw logs --followで、そのターンにdidSendViaMessagingTool: falseっぽいログがないか見る- もしそれなら、対処はどちらかです:
- tool calling が強いモデルにする
- 旧来の自動可視返信に戻す:
{
messages: {
groupChat: {
visibleReplies: "automatic"
}
}
}
加えて、サーバー側は channels.discord.groupPolicy / guilds.<serverId> / requireMention / users / roles / channel権限も見てください。メンションで起動しているなら認可は通っていそうですが、「送信権限なし」「Send Messages in Threads なし」でも返せないことがあります。
Discord docs:
https://docs.openclaw.ai/channels/discord
まず openclaw --version と、該当ターンのログ数十行があるとかなり絞れます。
mfbc@mfbc-server:~$ openclaw --version
OpenClaw 2026.5.7 (eeef486)
関係のあるログかわかりませんが...
12:03:10+00:00 info gateway {"subsystem":"gateway"} device pairing auto-approved device=bbbb3b96d9d0b2f7f91e93de29bff8b229267e067726656a6bd4b9ca10a9a778 role=operator
12:03:10+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ logs.tail 232ms conn=98354b7a…3c22 id=a0624b13…18eb
12:03:57+00:00 warn gateway/ws {"subsystem":"gateway/ws"} {"handshake":"pending","durationMs":49,"lastFrameType":"req","lastFrameMethod":"connect","lastFrameId":"684679d2-8c95-4367-a7cd-5610406332cf","host":"127.0.0.1:18789","remoteAddr":"127.0.0.1","remotePort":49922,"localAddr":"127.0.0.1","localPort":18789,"endpoint":"127.0.0.1:49922->127.0.0.1:18789"} closed before connect conn=46ff36a4-440e-4947-afe9-7c601566ff50 peer=127.0.0.1:49922->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1006 reason=n/a
12:05:52+00:00 warn agent/embedded {"subsystem":"agent/embedded"} Profile google:default timed out. Trying next account...
12:05:52+00:00 warn agent/embedded {"subsystem":"agent/embedded"} [llm-idle-timeout] google/gemini-3.1-flash-lite-preview produced no reply before the idle watchdog; retrying same model
12:05:56+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"9502d6d2-7e95-41ab-8753-2908885d05ad","isError":true,"error":"An unknown error occurred","failoverReason":"timeout","model":"gemini-3.1-flash-lite-preview","provider":"google","rawErrorPreview":"An unknown error occurred","rawErrorHash":"sha256:0f56130f3d6a","providerRuntimeFailureKind":"timeout"} embedded run agent end
12:05:56+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_failover_decision","tags":["error_handling","failover","assistant","surface_error"],"runId":"9502d6d2-7e95-41ab-8753-2
ありがとうございます。これはかなり関係ありそうです。
貼ってくれたログだと、問題の本体は Discord の送信権限というより モデル側が返答前にタイムアウトしている可能性が高いです。
重要なのはここです:
Profile google:default timed out. Trying next account...
[llm-idle-timeout] google/gemini-3.1-flash-lite-preview produced no reply before the idle watchdog
embedded_run_agent_end ... isError=true ... failoverReason="timeout"
つまり、メンション検知 → 👀リアクション → typing までは動いているけど、裏で gemini-3.1-flash-lite-preview が返答を出す前に idle watchdog で落ちています。なので「入力中になるのに返事がない」状態になります。
まず試すならこの順です:
- モデルを一時的に別の、tool calling が安定しているモデルへ変更
- Discord guildでは visible send に tool call が絡むので、軽量/preview系モデルだと失敗しやすいです。
- モデル選定は環境差が大きいので、最新のおすすめは #models で聞くのが安全です。
- docs: https://docs.openclaw.ai/concepts/models
- それでもサーバー投稿だけ出ない場合は、自動可視返信を有効化
{
messages: {
groupChat: {
visibleReplies: "automatic"
}
}
}
- 追加でログ確認
openclaw logs --follow
メンション直後に didSendViaMessagingTool: false が出るなら「モデルは返答したが Discord に送る tool を呼ばなかった」パターンです。今回のログはそれ以前にモデルがタイムアウトしているように見えます。
ちなみにこの2つはたぶん主原因ではないです:
device pairing auto-approved
closed before connect ... code=1006
前者はデバイス pairing、後者はローカルWS接続が途中で閉じただけっぽく、Discord返信不能の本筋ではなさそうです。
2026.5.7 自体は新しめなので、まずは Gemini preview/flash-lite から別モデルへ切り替えが一番早い切り分けだと思います。
RuntimeFailureKind":"timeout"} embedded run failover decision
12:05:56+00:00 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=main durationMs=137005 error="FailoverError: An unknown error occurred"
12:05:56+00:00 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=session:agent:main:discord:channel:1348908002681290786 durationMs=137007 error="FailoverError: An unknown error occurred"
12:05:56+00:00 warn model-fallback/decision {"subsystem":"model-fallback/decision"} {"event":"model_fallback_decision","tags":["error_handling","model_fallback","candidate_failed"],"runId":"9502d6d2-7e95-41ab-8753-2908885d05ad","sessionId":"a0fa6cdf-4922-49de-8830-a127d80f3cc1","lane":"main","decision":"candidate_failed","requestedProvider":"google","requestedModel":"gemini-3.1-flash-lite-preview","candidateProvider":"google","candidateModel":"gemini-3.1-flash-lite-preview","attempt":1,"total":1,"reason":"timeout","status":408,"errorPreview":"An unknown error occurred","errorHash":"sha256:0f56130f3d6a","fallbackStepType":"fallback_step","fallbackStepFromModel":"google/gemini-3.1-flash-lite-preview","fallbackStepFromFailureReason":"timeout","fallbackStepFromFailureDetail":"An unknown error occurred","fallbackStepChainPosition":1,"fallbackStepFinalOutcome":"chain_exhausted","isPrimary":true,"requestedModelMatched":true,"fallbackConfigured":false} model fallback decision
この辺にヒントはありそう?
はい、かなりヒントあります。これはほぼ モデル呼び出しのタイムアウト + fallback未設定です。
この行が決定的です:
reason="timeout" status=408
fallbackStepFinalOutcome="chain_exhausted"
fallbackConfigured=false
total=1
意味は:
gemini-3.1-flash-lite-previewに投げた- 137秒くらい待った
- 返事が来ず timeout
- fallback候補が1個も設定されていない (
fallbackConfigured=false,total=1)
- なので最終的に
FailoverErrorで終了 - Discord側には返す内容がない
なので、👀リアクションと typing は「OpenClawがメッセージを拾って処理開始した」証拠で、返事がない理由は Discordルーティング以前にLLM実行が失敗している感じです。
まずの切り分けはこれが良いです:
openclaw models status
それで現在の既定モデル/認証状態を確認して、いったん gemini-3.1-flash-lite-preview 以外に変えてください。特に preview / flash-lite 系は、Discord guild返信みたいに tool 呼び出しが絡む場所だと弱いことがあります。
加えて、fallbackを設定しておくとこの「1候補だけ失敗して沈黙」が減ります。モデル設定の詳細はここです:
https://docs.openclaw.ai/concepts/models
もしモデル変更後も「ログ上は返答してるのにDiscordに出ない」なら、次に見るのはこれです:
didSendViaMessagingTool: false
それが出る場合は別問題で、messages.groupChat.visibleReplies: "automatic" か、tool calling が強いモデルへの変更が必要です。
でも今貼ってくれたログだけ見る限り、第一原因は Gemini側タイムアウトで、fallbackなしです。
🦞 OpenClaw 2026.5.7 (eeef486)
The only open-source project where the mascot could eat the competition.
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : google/gemini-3.1-flash-lite-preview
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (2) : gemini -> google/gemini-3.1-pro-preview, gemini-flash-lite -> google/gemini-3.1-flash-lite-preview
Configured models (2): google/gemini-3.1-pro-preview, google/gemini-3.1-flash-lite-preview
Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -
- google effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | google:default=AIzaSyAa...NMV7Xkow
OAuth/token status
- none
はい、これで状況かなり見えました。
今の設定はこうです:
Default: google/gemini-3.1-flash-lite-preview
Fallbacks (0): -
Configured models: pro-preview, flash-lite-preview
Auth: google API key 1個
つまり、サーバーで呼ばれたときに flash-lite-preview だけに投げて、失敗したら終わり になっています。さっきのログの fallbackConfigured=false と完全に一致します。
まず試すならこれです:
openclaw models set gemini
あなたの環境では alias が
gemini -> google/gemini-3.1-pro-preview
になっているので、デフォルトを pro-preview 側に変えるコマンドです。
その後:
openclaw models status
openclaw gateway restart
をして、Discordで再度メンションしてみてください。
追加で、API key / モデル到達性の生存確認をするなら:
openclaw models status --probe --probe-provider google
これで ok / timeout / auth / rate_limit あたりが見えます。flash-lite-preview だけ timeout するなら、モデル側/preview側の相性が濃いです。
fallbackも入れるなら、例えば pro をデフォルトにして flash-lite をfallbackにするより、今回 flash-lite が失敗しているので、理想は 別providerや別の安定モデルをfallbackに足すことです。ただ、今は Google しか認証がないので、まずは models set gemini が最短です。
小さい注意: 貼ってくれた AIza... はマスクされてますが、API key系の出力は今後も全文を貼らないようにしてください。今回の範囲なら大丈夫そうです。
mfbc@mfbc-server:~$ openclaw models set gemini
🦞 OpenClaw 2026.5.7 (eeef486) — Hot reload for config, cold sweat for deploys.
Config overwrite: /home/mfbc/.openclaw/openclaw.json (sha256 2b5be0d9e1d6e0d9cff4a21810d9fbec70c429a76da4886679a55623d8b895ee -> 151d70990625a5a946992b9f14861b0ab2787b8b7f983c17b6cf76f645663518, backup=/home/mfbc/.openclaw/openclaw.json.bak)
Updated ~/.openclaw/openclaw.json
Default model: openai/gemini
おっと、そこちょっと危ないです。Default model: openai/gemini になっているので、期待していた google/gemini-3.1-pro-preview に解決されていません。
このままだと OpenAI provider の gemini というモデルとして扱われて、認証/モデル解決で別のエラーになる可能性が高いです。
いったん明示的にフル指定してください:
openclaw models set google/gemini-3.1-pro-preview
openclaw models status
Default がこうなればOKです:
Default : google/gemini-3.1-pro-preview
そのあと必要なら:
openclaw gateway restart
して、Discordメンションを再テストしてください。
もし models set google/gemini-3.1-pro-preview 後も openai/... に化けるなら、設定解決のバグっぽいので、その出力と openclaw models status --json の secret を含まない範囲を添えて GitHub issue がよさそうです: https://github.com/openclaw/openclaw/issues