海外の掲示板 Reddit で、Claude のユーザーたちが興味深い議論を交わしていました。
テーマは「Chat と Cowork、Code はいつ統合されるのか」です。
同じプロジェクトを3つのタブで開いて使い分けている。
それなのに、文脈や記憶がタブをまたいで引き継がれない。
この不便さに、多くの人が「わかる」と声を上げていたのです。
1. 何が不満として語られているのか
スレッドを立てた人の使い方は、こんな感じでした。
まず Chat で考えを練る。
ときには Cowork で始めた作業が、そのままコーディングの課題に流れ込んでいく。
3つのツールの間をなめらかに行き来しながら進めている。
それなのに、肝心の文脈と記憶だけが自分についてこない。
この訴えに、コメント欄はおおむね同意で埋まっていました。
タブを切り替えるたびに、プロジェクトの構成を一から説明し直す。
地味ですが、これが本当に疲れるのですよね。
しかも、対象は3つだけではありませんでした。
「Design も忘れないで」と指摘した人がいたのです。
一つのプロジェクトを進めるために、4つの環境にそれぞれ手作業で前提を教え込む。
冷静に考えると、なかなか大変な作業です。
2. みんながやっているワークアラウンド
では、現場の人たちはどう乗り切っているのか。
最も多く挙がっていたのが、プロジェクトのルートに CLAUDE.md を置いておく方法でした。
ツールを切り替える前に、今どこまで進んだかを短くそこへ書き出しておく。
次のタブでは「CLAUDE.md を読んで状況を把握して」と最初に伝えるだけで済む、というわけです。
ただし、ここには大きな落とし穴があります。
このファイルを自動で読みに行ってくれるのは Code の CLI だけです。
Web版の Chat はローカルのファイルを見ません。
だから、結局は中身をコピーして貼り付ける羽目になります。
Chat にも読ませたいなら、いくつか代替案がありました。
プロジェクトの指示（instructions）に内容を入れておく。
あるいは、専用のスキルを作って毎回呼び出す。
そういった工夫が紹介されていました。
このやり方への鋭い指摘もありました。
よい状態サマリーを書こうとすると、いちばん作業に集中している瞬間に手を止めなければならない、というのです。
だから、探索的な会話そのものを Code のセッション内で済ませてしまう。
そして CLAUDE.md は「あとから書く要約」ではなく「進行中の記録」として扱う。
そのほうがうまくいった、という経験談でした。
もっと作りこんでいる人たちもいます。
引き継ぎ用のドキュメント、意思決定のログ、プロジェクトの作業記録。
こうしたものを普段からきちんと残しておく。
すると、Cowork と Code を行き来してもまったく問題なく続きから作業できる、という声が複数ありました。
文脈が分断されるのは、そもそもワークスペースを構造化していないからだ、と言うのです。
整えてしまえば、各ツールが必要な情報を自分で拾ってくれる。
そんな主張でした。
具体的な運用を共有してくれた人もいました。
最近はリポジトリ内で agents.md が CLAUDE.md の役割を引き継ぎつつあるそうです。
Claude でも別のツールでも、同じファイルを読みに行く。
流れはこうです。
まず Chat にその場のセッション計画を書かせ、リポジトリへ保存する。
agents.md には、最初にその計画を読むよう指示しておく。
コーディングが終わったら変更履歴を更新する。
これで、新しいセッションを開いても、同じプロジェクトなら必要なことはひととおり把握した状態で作業が始まる、とのことでした。
さらに踏み込んだ人もいます。
記憶を共有する仕組みを、自分で組んでしまった人です。
MCP を間に挟んだり、外部のメモ環境と同期させたりと、アプローチはさまざまでした。
要するに、公式の統合を待ちきれない人たちがいる。
そして彼らは、それぞれの方法で「記憶の壁」に穴を開けているのです。
3. あえて分けておきたい、という立場
一方で、統合を望まない人たちも少なからずいました。
これは見落とされがちな視点です。
だからこそ、丁寧に紹介しておきます。
理由としてよく挙がっていたのは、次のようなものでした。
- コーディングのプロジェクトに、雑多なチャットの履歴を持ち込みたくない
- ツールごとに役割がはっきりしているほうが、頭の中が散らからない
- 企業環境では、むしろ分かれているほうが都合がいい
ある人の工夫が具体的で参考になりました。
プロジェクトの中に「アイデア」用のフォルダを一つ用意する。
そして、Cowork にはそこだけを見せる。
こうすれば、Cowork が既存コードの細部にまで首を突っ込むことはありません。
一方 Code はコードベース全体を見ています。
だから「アイデアフォルダのあのメモを見て」と言えば、すぐに参照してくれる。
コピー＆ペーストは不要です。
通常の Chat は、また別の用途に使い分けていました。
語学や歴史のような、開発とは無関係な話題を置く場所です。
画像の一括変換や論文の要約といった雑務は、Cowork に任せる。
この「役割ごとに区切る」感覚を、むしろ心地よいと感じている様子でした。
企業利用の観点も説得力がありました。
会社のパソコンでこうしたアプリを使えるようにする。
そのためには、承認のプロセスが長く厳しいことが多いのです。
一つのアプリに機能を詰め込むほど、その分だけ禁止される確率も上がってしまう。
特に、AIが自律的に動くような機能は警戒されやすい。
だから業務では、機能が分かれていることがリスク低減につながる、というのです。
なるほど、と思わされました。
4. 「Codeだけで十分」という声
もう一つ目立ったのが、「結局 Claude Code に全部寄せた」という人たちです。
速いし、シンプルです。
しかも、セッションが圧縮されるまで長くもつ。
Chat や Cowork でやっていたことも、Code でこなせるようになった、と言います。
彼らにとっての Chat は、ちょっとした疑問を投げる場所でした。
あるいは、本格的なセッションに入る前に頭を整理する場所です。
リモートコントロールを有効にすればスマホからも操作できる。
だから、これで十分だ、という意見もありました。
中には「Chat モードの存在意義がよくわからない」と率直に書いている人もいたのです。
ツールの取捨選択が、かなり進んでいる印象を受けます。
ちなみに、Cowork ならではの機能として「dispatch」が話題に上がっていました。
リモートコントロールとの違いをめぐって、やり取りが続いていたのです。
このあたりには、重なり合う機能の境界がユーザーから見ても曖昧だ、という現状がよく表れていたと思います。
5. では、統合はいつ来るのか
肝心の時期について。
結論から言います。
スレッドの誰も、公式の明確なロードマップを持ってはいませんでした。
ただ、空気としては「記憶の共有レイヤーが次の一手になるのは自明」という見方が大勢を占めていました。
やり方についての予想も語られています。
いきなり全部を切り替えるのではない。
まず文脈や記憶の共有から始める。
その後でワークフローの統合へ進むのではないか。
そんな段階的なシナリオが有力視されていました。
加えて、こんな話も出ていました。
Anthropic の関係者がインタビューで、製品どうしの重なりを増やしていく方向性に触れていたらしい、というのです。
タブを分ける形から離れる。
そして、必要なときに必要なツールが顔を出す一つの流れのような体験へ向かうのではないか、と。
もっとも、これはあくまでスレッド内で語られていた推測です。
具体的な時期を示す公式情報を提示できた人はいませんでした。
期待は大きい。
けれど、確証はない。そんな温度感です。
まとめ
このスレッドが映し出していたのは、一つのきれいな緊張関係でした。
多くの人は、ツールの壁を取り払った地続きの体験を望んでいる。
けれど、あえて壁を残しておきたいと考える人も確かにいる。
どちらの言い分にも、それぞれの現場に根ざした理由がありました。
公式の動きを待つあいだ、いま効いている答えは、案外地味なものです。
ワークスペースをきちんと構造化する。
引き継ぎのメモやログを残す。
共有ファイルを「真実の置き場所」として扱う。
派手さはありません。
それでも、これが今のところ多くの人にとって現実的な解になっていました。
統合が来るのか、来るとしていつなのか。
それは誰にもわかりません。
ただ、待っているだけの人ばかりではない。
自分の手で文脈をつなぐ工夫を、積み重ねている人たちがいる。
その姿勢のほうが、ツールの行く末よりもよほど参考になるのかもしれません。
