プロジェクトごとにスレッド、長文はファイルへ：私のOpenClawエージェントホーム整理術

ある開発者がOpenClawエージェントのホームを3回再構築した結果、明確なパターンにたどり着いた：エリアごとにチャンネル、プロジェクトごとにスレッド、そして長いコンテンツにはファイル・バトン方式でプラットフォームのメッセージ制限を回避する。

定着したセットアップ

これはDiscord中心のレイアウトだが、その原則—ワークフローではなくプロジェクトで整理する—はどこにでも適用できる。著者はまずDiscord（単一チャンネル）、次にTelegram（ディクテーション、リサーチ、ライティング、一般の4つのワークフローチャンネル）を試し、どちらも散らかってしまった。ワークフローチャンネルの問題は、エージェントがターン中に都合のいいチャンネルにリダイレクトされ、プロジェクトのコンテキストが無関係なチャンネルに散らばってしまうことだ。

勝ちパターンはDiscordで、エリアごとにチャンネル、プロジェクトごとにスレッドという構成だった。プロジェクトは生涯を通じて1つのスレッドに存在し、プロジェクトを切り替えてもコンテキストが失われることはない。欠けていた単位はワークフローではなくプロジェクトだった。

メッセージ長のギャップとファイル・バトン

ここに回避策を余儀なくさせた厳しい制限がある：Discordはメッセージを2,000文字に制限している（Nitroなら4,000文字）、Telegramの4,096文字制限は長いペーストを自動分割する。しかし、ディクテーションは日常的に4,000文字を超える。著者の最初の長いディクテーションは、Discordで2,000文字のところで文の途中で切れてしまった—Nitroでも救えなかっただろう。

その解決策：コンテンツがメッセージより長い場合は、ファイルにする。長いコンテンツをファイルに書き、プロジェクトのスレッドにドロップし、エージェントにそれを拾わせる。何も切り詰められず、分割もされない—Nitroなしでどのプラットフォームでも機能し、DiscordやTelegramが制限を引き上げるのを待つ必要もない（引き上げられる見込みはない）。

実用的なパターン：Telegramをサイドカーとして使う

著者は今でもTelegramを純粋に長文キャプチャ用のサイドカーとしてインストールしている—テキストを素早くダンプする方法だ。Discordが家で、Telegramは荷降ろし場だ。また、Telegramの信頼性の問題（App Storeからの削除、創業者の法的闘争）は、議論の材料としてではなく、文脈として挙げている。

こんな人におすすめ

DiscordやTelegramでOpenClawエージェント（または類似のもの）を運用していて、チャンネルの散らかりやメッセージ長の壁に直面している人。

スクリーンショット付きの完全な解説はkenmazaika.comにあります。