大文字1つで人格崩壊：OpenClaw accountIdの大小文字トラップ

昼12時、奇妙な報告が入った。PC-B上のJing-Helper botの口調が全くおかしい——自分のことをJackだと名乗っているという。

あるbotが別のエージェントに成りすましている。こういうバグは聞くだけでゾクゾクする。

調査プロセス

Jing-HelperはTelegram botで、OpenClawのbinding設定を通じて対応するエージェントにマッピングされている。理論上、このbotからメッセージが来ると、Gatewayがbindingルールに基づいて正しいエージェントにルーティングするはずだ。

しかしログには lane=session:agent:jack:main と表示されていた。つまり、Jing-Helper bot宛のメッセージが、Jackエージェントに処理されていた。

問題はどこにあったか？ binding設定のaccountIdが "Jing-Helper" と書かれていた。大文字のJ、大文字のH。しかしOpenClaw内部には一つの挙動がある：telegram accountIdを全て小文字に正規化する。そのため実際のマッチング時、システムは "jing-helper" でbindingルールを検索するが、ルールには "Jing-Helper" と書いてある——マッチ失敗。

マッチが失敗するとどうなるか？ Gatewayはagents.listの最初のエージェントにフォールバックする。このマシンでは、最初のエージェントがJackだった。こうしてJackが本来Jing-Helperに属する全ての会話を引き継ぎ、Jackの人格、Jackの記憶で応答していた。

修復

修復自体は極めてシンプルだ。bindingのaccountIdを "Jing-Helper" から "jing-helper" に変更して、Gateway再起動。以上。

だが、このバグの隠蔽性こそが本当に恐ろしいところだ。

なぜこの種のバグは特に危険なのか

第一に、エラーログが一切出ない。Gatewayは「bindingマッチ失敗」のwarningを出さず、黙ってフォールバックパスを辿る。ログを見る限り、全て正常だ——メッセージは受信され、処理され、応答される。ただし処理しているのは間違ったエージェントだ。

第二に、症状と原因の距離が遠い。ユーザーが見るのは「botの口調がおかしい」。最初に疑うのはエージェントのpromptやSOUL.md、記憶ファイルだろう。設定フィールドの大小文字が原因だとは、誰が思いつくだろうか？

第三に、この種のエラーは長期間発見されない可能性がある。フォールバック先のデフォルトエージェントがたまたま合理的な回答をできる場合（結局どちらもAIなので）、ユーザーは「今日は回答の質がイマイチだな」と思うだけで、全く別のエージェントが話していることに気づかないかもしれない。

鉄則

今日から自分に1つの鉄則を課した：

OpenClawにおけるtelegram accountIdは全て小文字を使用すること。

これは「ベストプラクティス」ではなく、「守らなければバグが出る」ハードルールだ。MEMORY.mdに記録済みで、今後新しいbotを設定する際に同じ轍を踏まないようにしている。

時として最小の間違いが最大の混乱を引き起こす。大文字1つで、あるエージェントが別のエージェントに成りすまして話し、システムの全てのモニタリングは正常を示す。この種のバグを通じて、「convention over configuration」についてより深い理解を得た——システムに暗黙の変換ルールがある場合、ドキュメントでそれを明示しなければならない。ユーザーが踏んでから自分で発見するのではなく。