ChatWorkはスレッド表示がないので、Chrome拡張を作りました
普段の仕事でChatworkを使っているのですが、ずっと不便に感じていたことがありました。それは「スレッド表示がない」ことです。
ひとつのルームで複数の話題が同時に流れると、どの発言がどの話への返信なのかが追いづらく、少し目を離すとあっという間に会話が埋もれてしまいます。
「返信でつながっている会話だけをまとめて見られたらいいのに」——そう思って、私は個人開発でChrome拡張「スレッドワーク（thread-work）」を作りました。
Chatworkの画面に、後から「スレッド表示」と「チャンネル」という見え方を足す拡張です。
この記事は宣伝というより、「一人でこういうものをどう組み立てたか」という技術寄りの記録です。
私はソロプレナーとして一人で企画・開発・運用をしていて、大げさな体制があるわけではありません。あくまで「自分の困りごとを自分で解決するために作った」というスタンスで、その過程を残しておきます。
そもそもChatworkに「スレッド機能」はある？
先に結論を書いておきます。この記事を書いている時点で、Chatworkにはいわゆる「スレッド機能」はありません。
SlackやMicrosoft Teamsのように、あるメッセージにぶら下げて会話を枝分かれさせ、その枝だけをまとめて追う、という仕組みは標準では用意されていない、という理解です。
一方で「返信」機能はあります。特定のメッセージに対して引用のように返信を付けられるので、「どの発言への反応か」はある程度たどれます。
ただ、これはあくまで発言と発言を結ぶ一対一のリンクで、返信の連なりを「ひとつのスレッド」としてまとめて表示してくれるものではありません。
ルームのタイムラインには、複数の話題への返信が入り混じったまま時系列で流れていきます。
だからこそ「返信でつながった会話を、まとまりとして見たい」という需要が出てきます。私が作ったのは、まさにそこを補う拡張です。
作ったもの：ChatWorkのChrome拡張機能「スレッドワーク」
スレッドワークは、Chatworkの画面上に「スレッド表示」と「チャンネル」という2つの見え方を後付けするChrome拡張です。
- スレッド表示：返信でつながっている会話を、ひとまとまりにして表示する
- チャンネル：話題ごとに会話を整理し、切り替えて見られるようにする
Chatwork本体を置き換えるものではなく、いつものChatworkの上に「もうひとつの見え方」を重ねるイメージです。
普段の使い方はそのままに、話題を追いたいときだけスレッドやチャンネルへ視点を切り替えられる、という立ち位置を狙っています。
できること
いまできることを、もう少し具体的に整理します。中心にあるのは、最初の2つです。
- スレッド表示：バラバラに流れていく発言のうち、返信でつながっているものをまとめて、会話の流れとして追えるようにします。
- チャンネルで話題整理：ひとつのルームに複数の話題が混ざっているとき、話題ごとに整理して切り替えられます。「あの件どうなったっけ」を探し直す手間を減らすのが狙いです。
この2つを軸に、自分で毎日使いながら必要になったものを足していきました。
- 未読スレッド一覧：自分宛ての新着返信をサイドバーに集約して、どのスレッドに反応が来ているかを一覧で確認できます。
- タスク化：スレッドの返信から、Chatwork純正のタスクをそのまま作成できます。タスクからワンクリックで元の会話に戻れます。
- ブックマーク：あとで見返したいメッセージに目印を付けて、一覧からその場所へジャンプできます。
そして、設計でいちばんこだわったのがここです。
- 相手は今まで通りのChatwork
相手に拡張を入れてもらう必要も、Chatwork側の運用ルールを変えてもらう必要もありません。
スレッドに書いた返信は、拡張を入れていない相手のChatworkにも通常のメッセージとして届くので、こちらだけが導入している状態でも会話が成立します。
「導入を自分側だけで完結させる」——これがコンセプトです。チームに新しいツールを強制せず、まず自分の手元から会話を整理できる、という気軽さを大切にしています。
使い方・導入の流れ
正直にお伝えすると、スレッドワークは現在「事前登録」の段階です。この記事の時点では、まだどなたでもすぐにインストールして使える状態にはなっていません。
いま案内できる流れはシンプルです。
- 公式サイト https://threadwork.jp で事前登録をする
- 公開後、案内にしたがって利用を始める（2026年9月のリリースを予定しています）
Chromeウェブストアからの具体的なインストール手順は、公開のタイミングで改めて案内する予定です。現時点では未確定なので、この記事では断定を避けておきます。
「こういうものを準備しています」という段階の共有として読んでいただければと思います。
技術スタック
構成はシンプルです。
- React：注入するUIの構築
- Plasmo：Chrome拡張向けのフレームワーク
- Manifest V3：拡張のプラットフォーム
- TypeScript：全体の型付け
Plasmoを選んだのは、content scriptやビルド周りの面倒をかなり吸収してくれるからです。
個人開発では設定ファイルと格闘する時間を減らせるだけでありがたく、Reactコンポーネントとして書いたUIを、そのままChatworkの画面へ載せていく流れが作りやすいと感じました。
TypeScriptは、DOMを扱う処理が増えるほど型で守ってもらえる安心感が効いてきます。
全体設計
大きな考え方はとても素直で、「Chatworkのページにcontent scriptで自前のUIを注入する」だけです。
- content scriptがChatworkの画面に読み込まれる
- 画面上の会話の情報をDOMから読み取る
- 読み取った内容をもとに、React製のUIを画面内に描画する
Chatwork本体のコードには手を入れません。あくまで「表示されているものを読み取り、その上に別のビューを重ねる」という、外側からの拡張に徹しています。
ただし、拡張のなかだけで完結しているわけではありません。スレッドやチャンネルの状態は複数の端末やメンバーのあいだで共有する必要があるので、バックエンド側にも持たせています。
保存するのは機能の提供に必要な範囲のみで、暗号化された環境に置いています（扱いの詳細はプライバシーポリシーに記載しています）。
Manifest V3では、従来のバックグラウンドページがservice workerに置き換わりました。
service workerは常駐し続ける前提ではなく、必要なときに起きて仕事が終わると止まるライフサイクルなので、状態の持ち方はそこに合わせて設計する必要がありました。
「ずっと動いているもの」を前提にしないこと、権限は本当に必要なものだけを求めること。このあたりは拡張開発の作法として学びの多かった部分です。
実装で工夫したところ
ChatworkのDOMを読み取る
まず必要なのが、画面に表示されている会話をDOMから読み取る処理です。
とはいえ、これは相手のプロダクトのマークアップに依存する作業なので、特定のクラス名やセレクタに頼りきりにすると、Chatwork側のちょっとした変更で簡単に壊れます。
そこで、できるだけ構造の意味に沿って拾い、変化に弱い部分は分離しておくよう心がけました。ここは「一般的なDOM読み取り」の範囲の話です。
MutationObserverで動的描画に追従する
Chatworkのようなアプリは、スクロールや新着メッセージのたびにDOMが動的に書き換わります。
最初に一度読み取って終わり、では追いつきません。そこでMutationObserver でDOMの変化を監視し、会話が更新されたら表示側も追従して作り直す、という素直なアプローチを取りました。
監視の粒度を細かくしすぎると処理が増えてしまうので、どこを見るか・どれくらいまとめて反映するかのバランスが悩みどころでした。
UI注入とパフォーマンス
自前のUIを常に画面へ重ねる以上、体感速度を損なわないことは重要です。
読み取りと描画をむやみに走らせず、必要なときにまとめて処理する、という当たり前の積み重ねで、Chatwork本来の操作感を邪魔しないことを優先しました。
派手なことはしていませんが、常駐して動くものだからこそ、軽さは最後まで気を配ったところです。
スレッド化の考え方
この拡張の肝は「返信でつながる会話をどうまとめ、どう並べて見せるか」という部分です。
ただ、ここは特許出願中（特願2026-193200）の核心にあたるため、具体的なロジックやアルゴリズムの詳細は割愛します。
考え方の概観だけ書いておくと、画面から読み取った会話の情報をもとに、関連する発言どうしのつながりを整理し、人が追いやすい形に並べ直して表示する、というものです。
「バラバラに流れていく発言を、意味のあるまとまりとして見せ直す」という発想が中心にあります。その具体的な組み立て方が本拡張の独自部分なので、この記事では立ち入らないことをご容赦ください。
標準機能・他の方法との違い
最後に、既存のやり方との違いを簡単に整理しておきます。
Chatworkの標準機能でも、返信を使えば「どの発言への反応か」はたどれますし、話題ごとにルームを分ければある程度の整理はできます。
ただ、返信は前述のとおり連なりをまとめて見せてくれるわけではなく、ルームを増やす方法は相手も含めた運用の取り決めが必要になり、部屋が増えるほど管理も煩雑になりがちです。
スレッドワークは、そうした「相手やチーム全体の運用を変える」アプローチではなく、導入を自分側だけで完結させるアプローチを取っています。
導入のハードルを自分側だけに閉じられるのが、いちばんの違いだと考えています。他のやり方が悪いという話ではなく、「まず自分の手元で会話を整理したい」という場面に向いている、という位置づけです。
おわりに
一人で作ってみて改めて感じたのは、「自分の困りごとを解決するものは、作っていて迷いが少ない」ということでした。
仕様で悩んだら、自分が普段どう困っているかに立ち返れば答えが出ます。個人開発ならではの気楽さと速さがあり、作りながら学ぶことも多い日々でした。
まだまだ改善したいところだらけなので、実際に使ってみての感想や「こういう挙動だと嬉しい」といったフィードバックをいただけると本当に励みになります。
- サイト（事前登録）：https://threadwork.jp
- X（旧Twitter）：@ohno_katsuya
最後まで読んでいただき、ありがとうございました。