Claude Codeデスクトップアプリの新機能7つ、サイドチャットと分割表示で作業を止めずに進める

出典: Claude 2.0 is Insane (All Updates Explained)

ふだん Cowork を使っている人が、Claude Code の新しい画面に移る理由は何でしょう？ 動画の最初の章は、この問いから始まります。話の入口は、画面の作り直しです。

Benさんは、新しい画面が大きく良くなった、と話し始めます。最近までは Cowork が中心で、画面と見た目が好みだったから、という前置きつき。

乗り換えを考える理由は3点。1つ目は、画面がかなり良くなったこと。2つ目は、Anthropic が新しい機能を最初に出す場所がここのようだ、という見立てです。

Benさん（動画 0:41〜）

2つ目に、Anthropicが新しい機能を最初に出す場所は、どうもここのようだ。

原文: Second, it also seems to be the place where Anthropic is launching their newest features first

3つ目は、新機能が強力で、仕事の進め方が良くなる点です。

話は、ためらう人にも向かいます。コードを書く人だけの物ではなく、裏側は Cowork と同じ道具で、機能が増えているだけ。パソコンの任意のファイルや、コマンドラインの道具にも触れられます。威圧感はかなり減った、とBenさんは見ています。

画面の変化の1つ目は、to-doリストです。Claude が計画を立てると、チャットの中にリストが現れ、作業が進むたびに項目へ完了のチェックが付いていきます。

Benさん（動画 1:24〜）

Claudeが計画を立てるたびに、チャットの中にto-doリストが出る。作業が進むにつれて、項目が消し込まれていくのを見られる。

原文: every time Claude makes a plan, you now get a to-do list inside of the chat, and you can watch it tick off each tasks as it progresses.

次は、Cowork で気に入っていたという横のパネル。計画、スキル（Claude に覚えさせる手順書）、使うファイルが一目で分かる画面で、これが Claude Code にも入りました。

画面は、チャットの横に新しいカードを並べます。環境カードは、チャットがどのフォルダで動くか、ローカルかクラウドかを示すカード。リモート操作のスイッチを入れると、ローカルのチャットをクラウドで続けられ、スマホからも作業を続けられる、という説明です。

コンテキストカード（チャットが覚えていられる量の枠を示すカード）は、どれだけ埋まったか、何が枠を占めているかを見せます。圧縮（古いやり取りを要約して空きを作る）のボタンもあり、性能を保ったまま話し続けるための仕組みだ、とBenさんは話します。

ほかに、コネクター（外のサービスにつなぐ口）のカードと、出力カードがあります。出力カードには、チャットが作ったファイルも使ったファイルも全部出ます。

最後は、チャットのセクション分け。三点メニューから新しいセクションへの移動を選び、名前を付けて作ったら、あとはドラッグで移すだけ。以前のグループ分けは使いにくく、古いチャットを探すのに時間がかかった、とBenさんは振り返ります。

計画が画面に見えて、進むたびにチェックが付いていく。to-doリストも横のカードも、いまどこにいるかを見せる仕組みです。

AIに仕事を任せた時、人の手が戻ってくるのはどこでしょう？ 進み具合を思い出して聞きに行く、その瞬間です。

進み具合を確かめに行った瞬間、管理のボールは任せた側に戻ってきます。任せたつもりで、実は手元に持ち直している状態です。

計画が画面に出ていれば、聞きに行かなくても今の位置が分かります。聞く側に戻らずに済む向きです。

横のパネルに計画やスキルが並ぶのも、同じ流れの話。AIが何を使って動いているかを、聞かずに見られるからです。

見る場所が決まっていることも大事です。to-doはチャットの中、枠の残りは横のカード、作った物は出力カード。

私なら、進み具合が画面に出る形を選び、催促する側に戻らないようにします。

仕事をいくつかのチャットに分けると、チャット同士はお互いの様子を知りません。この困りごとを、新しい形はどう扱うのでしょう？

Benさんは、この機能がいちばんのお気に入りだと話します。段階的な提供で、人によって見え方が違う、という前置きです。

Pro と Max ではプロジェクト、Team プランではネストされたセッション（メインのチャットの中に立つ、子のチャット）が出ます。呼び方は違っても、考え方は同じ、という説明です。

Benさん（動画 3:08〜）

考え方は単純だ。1つのメインチャットやプロジェクトが、その中で別のチャットを立ち上げられる。これをネストされたセッションと呼ぶ。メッセージを送り、作業を確かめ、報告させる。5つのチャットを自分で管理する代わりに、小さなチームを動かす1人の調整役に話しかければいい。

原文: The idea is simple, one main chat or project can start other chats inside of it, also called nested sessions. Uh they can send them messages, they can check their work, and report back to you. So, instead of managing five chats yourself, you can talk to one coordinator or orchestrator who runs a small team of agents or sessions for you.

例は、Benさんの YouTube 動画の準備。サムネイルとタイトル、構成、ビジュアルと編集の3本のチャットを分けて持っていました。

古い形の困りごとは3点です。他のチャットで起きたことが伝わらない、セッションの切り替えが多い、1つにまとめると枠がすぐ埋まって性能が落ちる、というものです。

新しい形では、調整役のエージェントに話しかけます。調整役がスレッドを3本立て、同じチャットから全部を回せる、という流れ。

調整役の枠は圧迫されず、各スレッドの中でも直せます。どのスレッドがどこまで進んだかも、調整役が把握している、という説明。

サブエージェントとの違いにも触れます。スレッドは、自分の中でサブエージェントを動かせます。

Benさん（動画 4:54〜）

つまり、この新しいプロジェクトとネストされたセッションで、エージェントの上に、調整役という層がもう1つ増える。

原文: essentially, with these new projects and nested sessions, we get one extra layer of agents above them, a coordinator or an orchestrator.

サブエージェントとは直接やり取りできず、スレッドとはできます。大きな仕事なら強く勧める、とBenさんは自分の経験として話します。

使い方は2通り。プロジェクトなら、始めるだけでスレッドが自動で立ちます。Team プランでまだ使えない場合は、空のチャットに大きな仕事を頼むと、Claude がスレッドを立てるかを提案してきます。

関係のない用事を途中で頼むと、新しいスレッドを提案してくれます。立ったスレッドは、メインのチャットの下のドロップダウンに並ぶ、とBenさんが話します。

違いは、動画の時点での説明として語られます。

Benさん（動画 5:45〜）

今の時点では、プロジェクトは共有の記憶を持ち、どのスレッドもそこに書き込み、そこから読む。ネストされたセッションは、代わりにメインチャットから概要と指示を受け取る。プロジェクトのスレッドはクラウドで動き、ノートパソコンを閉じても続く。ネストされたセッションは、手元のコンピューターの中だけで動く。

原文: as of today, projects uh keep a shared memory, so every thread adds to it and draws from it, while nested sessions get a brief and a prompt from the main chat instead. And project threads can run in the cloud, so they can keep going uh with your laptop closed, while nested sessions only run locally on your computer.

Anthropic はプロジェクトを全プランへ広げている途中で、数週間後に来る見込み、とBenさんが話します。

調整役の1人に話しかければ、小さなチームが動く。では、その1人には何を任せるのか？

私の記事より（Claude Codeのプロジェクトで、指示する相手を1人にしてAIチームに任せる使い方を整理した記事）

2026年10月19日のLIVEで、私は2つのAIを対話させて、どちらをボスにするか決めてもらいました。それぞれが自分だと言い始めて、ちょっと喧嘩に。そのうち、決めるのは私でしたね、とAIの方が言い直したり、確かめたりするやり取りになっていました。役割が決まらないと、まず喧嘩になります。だから、渡す相手を1人にする意味は、窓口の数より、誰が最後まで持つかを先に決める点にあると見ています。指示する相手が1人でも、その1人が途中で手を離すなら、頼む側の手間は減りません。

あのLIVEの場面と並べると、動画の形でまず目に入るのは、調整役が最初から決まっている点です。メインのチャットが調整役で、子のチャットは頼まれて報告する側。

私が見たいのは、その先です。調整役が3本のスレッドを最後まで持つかどうかです。

窓口の数より、持ち主が先。プロジェクトを見る時の順番は、そこから決めます。

長い作業をAIに頼んで、途中まで進んでいる時。ふと、聞きたいことが出てきます。止めたくはないし、流れも狂わせたくない場面です。そんな時、どこから聞けばいいんでしょう？

話は、長い作業の途中から始まります。Claude がto-doの半分まで進んだところで、聞きたいことが出てきた場面。Benさんは、そこを最初に置きます。

Benさん（動画 6:47〜）

Claudeがto-doリストの途中にいて、質問はあるけれど、Claudeの作業を止めたり、狂わせたりしたくない。この場面に、解決策が来た。

原文: when Claude is halfway through its to-do list, but you have a question, and you don’t want to interrupt or derail Claude. So, we now got a fix for this.

画面は、右上の三点メニューからサイドチャットを選ぶ所へ進みます。開くのは専用のチャット窓で、いくつでも開ける、という説明です。

Benさん（動画 7:07〜）

どのサイドチャットも、その時点までのメインチャット全体を読める。いま何をしているか、どれくらいかかりそうかを聞いたり、ここまでの作業を見直させたりできる。

原文: each side chat can read the whole main chat up to that point, so you can ask what it’s doing, how long it might take, or have it review the work so far

横の窓では、進み具合や残りの見込みを尋ねたり、途中までの仕事を点検させたりもできます。それでもメインのチャットには何も書き足されない、と話は続きます。

メインの作業と関係のない質問も、横でなら大丈夫。その分はメインのコンテキスト（チャットが覚えていられる量の枠）に入らない、とBenさんが説明します。

動画は、サイドチャットを、ちょっと聞くための前からあるコマンドの成熟版と位置づけます。前の物は一時的な横のチャット。今は保存され、メインのチャットへメッセージも送れます。

使い方の例として、Benさん自身は、サイドチャットにメインの出力を見直させた、と話します。

続いて出てくるのが分割表示。チャットからチャットへ行き来する手間を減らす機能、という位置づけ。

Benさん（動画 7:47〜）

この新しい分割表示で、複数のチャットを同時に1つの画面に並べられる。

原文: with this new split view, you can have several chats on one screen at the same time.

やり方は、サイドバーのチャットを今のチャットへドラッグして分割表示を選ぶか、サイドバーの三点メニューで開く先に分割表示を選ぶか、です。たくさんの作業を同時に進められる、とBenさんが話します。

止めずに聞ける入口と、並べて見る入口。増えたのは、その両方です。

横から聞く窓と、横に並べる画面。似て見えても、向きは違うんですよね。

私の記事より（Claude Codeデスクトップアプリの大型更新を見て、並列で任せる前に私が決めることを書いた記事）

並列で頼む数が増えるほど、どの画面を見ればよいかが大事になります。答えは、まず親。子と /btw は、必要な時に開く。

この答えを書いた私の記事では、親のセッションに来週の提案書を頼み、子に資料と表と文章を同時に作らせる、という形です。見るのはまず親、と書いています。

子の画面を3本とも開いて回るより、親に戻る報告を読む。気になった子だけを開く。それが、その記事での順番でした。

分割表示で画面を並べても、目の数は並べる前と同じです。並べるほど、どこから読むかを先に決めておく必要が出てきます。

あと、横から聞く窓を使うAIには、求めたい条件が1つあります。

わかることは2度聞かないこと。既にある記録で分かることはAIの側で調べ、人に入れ直させないことです。

聞く窓が手軽になるほど、聞かずに済む所はAIが自分で調べてほしい。その条件があって初めて、横の窓は流れを止めない入口になります。

文書、スライド、デザイン、数字の画面、動画。これまで別々のサービスで作ってきた物が、Claude の中で作れるようになります。作る場所がまとまると、何が変わるんでしょう？

章の頭で、Benさんは前置きをします。この一群は、まったくの新顔というわけではないものの、まだ試していない人には紹介する価値がある、という前置き。

動画は、Googleドキュメント、Googleスライド、デザインツール、Looker Studio、動画を作るツールの名前を並べます。Anthropic が、それらに近い物を Claude の中に作っている、という例えです。

Benさん（動画 8:18〜）

Anthropicは、Googleドキュメント、Googleスライド、デザインツール、Looker Studio、それに動画を作るツールまで、Claudeの中に作っているようなものだ。

原文: Anthropic is basically building its own Google Docs, Google Slides, a design tool, Looker Studio, plus a video creation tool, all inside of Claude.

出力の形は、アーティファクト（Claude の中で作って、直したり共有したりできる成果物）です。キャンバスのような画面でコメントを付けながら一緒に直せて、リンクのライブページとして、チームやリンクを持つ人と共有もできます。

ダッシュボードは、最近出た機能です。コネクター（外のサービスにつなぐ口）から直接データを引き、開くたびに、その時点のデータへ入れ替わります。

Benさん（動画 8:49〜）

この新しいダッシュボードは、コネクターから直接データを引き、最新のデータを表示できる。開くたびに、コネクターから最新のデータを取ってきて、いちばん新しい数字を見せてくれる。

原文: these new Dashboards can pull data directly from your connectors and now show live data, meaning every time you open it, it pulls the latest data from your connectors to show you the upmost up-to-date metrics.

スライドは、アニメーション付きの発表資料を Claude から作る機能です。PPT形式でダウンロードするか、そのまま Claude から発表できます。

ドキュメントは、タブ付きの Googleドキュメントのような物。チームとAIのエージェントが、同じ文書にリアルタイムで取り組めます。YouTube 動画の準備は全部これ、とBenさんが話します。

デザインは、Figma のようなボード。SNSやWebサイトのデザインでは、まずこれを使う、とBenさんが話します。文言を直したり、コメントを残したり、Claude に直させたりできる、という説明です。

モーションは、コードでアニメ動画やモーショングラフィックを作る機能です。動画のモデルを使わずに見栄えのする動画が作れて、キャンバスがあるので直して改善するのが速い、と話は締めくくられます。

作れる形式が5つ、Claude の中に。動画が見せているのは、その並びです。

そして、どの形式も、コメントで直せるページにまとまります。

私の記事より（AIの出力を確認する負担を、窓口を絞り、読む画面を1ページにして減らす話を書いた記事）

2026年10月13日のこと。私は確認の質問の自由記入に、何を今確認して判断すればいいのか非常に分かりづらいです、分かりやすくしてください、と書きました。10月2日には、どこを見たらいいかページ内リンク付きで出して、以後毎回そうして、毎回めちゃ分かりにくい、と書いています。どちらも、見る場所と決めることについての言葉。でね、1つ目は頭の1行です。ページをHTMLにまとめても、頭に、今決めること、見る所、が書かれていなければ、読む量は減りません。形式より先に、ここ。

あの2つの言葉は、ページの形式には触れていません。書いたのは、何を今決めるかと、どこを見るかです。

Benさんが話すのは、出力がアーティファクトにまとまり、キャンバスでコメントを付けながら直せて、リンクで共有できる形です。作って直して渡すまでが、1つのページで済む作りです。

読む側に立つと、私が先に見るのはページの頭の1行です。今決めることと見る所が、そこに書かれているか。

開くたびに最新のデータを取るダッシュボード。私には、古い数字で判断しないための作りに見えます。ただ、どの数字から見るかを決めるのは、見る人の側。

整った1ページに任せきらず、一次の数字を自分の目で先に読む。読む入口は、ページの形式とは別に、自分で決めておきます。

毎回読まれる指示が、古いまま残っていないか。気になりませんか？ その古い指示を、コマンドのほうが探してくれるとしたら。この章は、Benさんが挙げる4つのスラッシュコマンドの話です。

Benさんは、Cowork から Code に乗り換える理由として、スラッシュコマンドが多いことも挙げます。スラッシュコマンドは、スラッシュで始めて打つ近道。知っておきたいのは4つ、という数え方です。

1つ目は output-style。Claude の出力の仕方を決めます。Claude が専門的になりすぎることがあるので、Benさんのチームは、答えを短く簡単にする出力スタイルを作った、と話します。

自分で作るなら、Claude に作らせて、出力スタイルとして加え、スラッシュコマンドで呼ぶ流れです。

2つ目は doctor。話は、古くなった、または新しいモデル向けに整えられていないスキル（Claude に覚えさせる手順書）と Claude.md（チャットのたびに Claude が最初に読む指示書）を抱える人が多い、という前置きから入ります。

Benさん（動画 10:45〜）

多くの人が、古くなったり、新しいモデル向けに整えられていなかったりするスキルとClaude.mdを抱えている。このコマンドは、Claude.md（チャットのたびにClaudeが最初に読む指示）と、すべてのスキルと設定を自動で読み、古い指示や食い違う指示を探す。

原文: many people have lots of skills and a Claude.md that are outdated or not optimized for newer models. Now, this command fixes that by automatically reading your Claude.md files, which are the first instructions Claude reads in every chat, plus all of your skills and all other settings for outdated or conflicting instructions

doctor の役目は、Claude.md とすべてのスキルと設定を自動で読み、古い指示や食い違う指示を探すこと。Opus 5.5 を含む5.5のモデルには、今は要らない指示もある、とBenさんは説明します。

数字は、Benさん自身の環境の物です。404ファイルを調べて、312件の問題が見つかったと話します。

Benさん（動画 11:06〜）

私の場合は、404ファイルを調べて、312件の問題が見つかった。Opus 5.5にはもう要らない指示が、余計なトークンを使っていた。

原文: in my case, it analyzed 404 files, it found 312 problems, like instructions that aren’t needed anymore for Opus 5.5, and are consuming unnecessary tokens.

要らない指示が、余計なトークンを使っていた、という話です。ときどき走らせて、Claude のアカウントを片づけるのにちょうどいい、とBenさんが話します。

3つ目は skill-doctor。入れたスキルは、使わなくても、Claude のコンテキスト（チャットが覚えていられる量の枠）を少し占めます。各スキルが占める量と実際に使う頻度を見せ、ほとんど使わないスキルを指摘して、消してよさそうな物を勧めるコマンドです。

こちらも Benさん自身の環境の数字。使っていないスキルのファイルに使われていた約20,000トークンを減らせた、と話します。

4つ目は advisor。新しくはないものの、Benさんのお気に入りで、特に5.5のモデルで使うと言います。軽いモデル（Sonnet や Haiku）で動かしている時、Claude は作業の要所で、強いモデル（Opus）に助言を求められます。

Benさん（動画 11:58〜）

Claudeは、タスクの要所で、Opusのような強いモデルに助言を求められる。

原文: Claude can ask a stronger model like Opus for advice at key moments in a task.

使い方の例は、Sonnet で受信箱を整理する時に advisor を一緒に使う形。大事な返信の下書きなど、重要な所では Opus 5.5 を使う、と説明します。

4本の役目は、それぞれ違います。output-style は出力の仕方を決め、doctor は古い指示や食い違う指示を探す。skill-doctor はスキルが占める量と使う頻度を見せ、advisor は要所で強いモデルに助言を求める形です。

私の記事より（Claude Codeの環境設定を整えて、会話を分けても前提を話し直さない形にした記事）

実は私、2026年9月に、自分の指示体系を見直して、AIに毎回読ませる指示書 CLAUDE.md を、20KBから約5KBの痩せ版にしました！狙いは、毎回読む量を減らすこと。

痩せ版にした後の数字も、同じ記事に記録しています。起動時に読み込まれるトークンは、Claudeで58,175から30,086、まとめ役のタスクでは115,047から55,743へ。

私がやったのは、毎回読む量を自分で見直すことです。Benさんの doctor は、古い指示を探す所からコマンドの側が受け持つ、と語られます。見直しの入口が、人からコマンドへ移る形です。

ただ、古いから消す、と決めると、気になることがあります。過去に入れた訂正まで、一緒に消えてしまわないか？

減らすことと、訂正を残すこと。ここは別の仕事。古い指示の中に、訂正の跡が混じっていることもあるはずなんです。

私は、背景と意図まで書いた指示を、古いまま残さないようにします。

新機能の紹介の締めくくりに出てくるのが mod です。アプリの見た目や動きを変える、とは、どういうことでしょうか？

Benさんは、新機能の中で、mod をお気に入りの機能に挙げます。

Benさん（動画 12:18〜）

modは、Claude Codeの見た目と動きを変えるもので、Claude Codeのデスクトップアプリの中に、自分で機能を作れるようにするものだ。

原文: A mod basically changes how Claude code looks and behaves, and it essentially allows you to build features inside of the Claude code desktop app yourself.

mod は、デスクトップアプリに自分で足す機能です。Claude Code の見た目と動きを変えます。

例は、Benさんが作ったブレインダンプ mod。Benさん自身は Claude に長い音声で指示することが多く、その音声は、誤りが混じり、あちこちに飛び、整理されておらず、矛盾することもある、と説明します。

Benさん（動画 12:39〜）

このmodは、私が長い音声のブレインダンプを使ったことを見つけて、Claudeが処理する前に、分かりやすく構造化された指示に自動で変える。

原文: this mod detects when I’ve used a long voice brain dump and automatically turns that into a clear, structured prompt before Claude even processes it.

この mod は、長い音声のブレインダンプを見つけると、Claude が処理する前に、分かりやすく構造化された指示へ自動で変えます。

作り方は、Claude に mod を作ってと頼み、何をさせたいかを説明するだけ。とても簡単に作れる、と話します。

Benさん（動画 12:50〜）

これらのmodは、Claudeにmodを作ってと頼んで、何をさせたいかを説明するだけで、とても簡単に作れる。

原文: you can build these mods really easily by just telling Claude to build your mod and describing what it needs to do.

画面には、9つの mod のカードの一覧が出ます。

機能を足す手段が、説明するだけになりました。

ただ、足すのが手軽になるほど、足した物がどう動くかを見る場面は増えるはず。

私の記事より（Claude Codeに機能を足すmod 9本を、同じチャンネルの別の動画から整理した記事）

2026年10月2日の夜、自作の safe-delete を、AIに頼んで試してもらいました。削除を、移動に書き換える mod。最初の版は、判断の前に時計を読む作りでした。その時計の読み出しが1回エラーになり、削除の命令がそのまま素通り。mod の hook がエラーで落ちると、止める働きが外れて、命令が通ってしまうんです。そこで、rm かどうかの判定を先にする形に直しました。claude plugin test の中の話で、本番の設定には入れていない版。

あの夜の直しで変えたのは、処理の順番でした。rm かどうかの判定を先にする形にしたことです。

Benさんのブレインダンプ mod も、Claude が処理する前に動く作りだと話します。処理の前に割り込む mod ほど、その hook がエラーで落ちた時に何が通るかを、先に見ておきたい所です。

それと、構造化した後に何が残るかも確かめたい。なぜそう言ったのか、という背景や迷いは、残っているでしょうか？

指示だけが残ると、込めた物が抜けます。整った指示の形と、そう言った理由は、別物なんです。

私なら、機能を足しても、魂は渡さず、込める所は自分で決めます。

動画は、新しい画面、プロジェクト、サイドチャットと分割表示、ドキュメントからモーションまで、新しいコマンド、mod の順に進みます。7つの機能を、Benさんが画面で一つずつ見せる流れです。

持ち帰ったのは、進み具合が画面に出る形を選ぶこと、窓口の数より持ち主を先に見ること、AIには、わかることは2度聞かない条件を求めることです。整った1ページに任せきらず一次の数字を先に読むこと、毎回読まれる指示を古いまま残さないこと、mod は hook が落ちた時を先に見ることも。

私の運用でも、AIに任せる範囲は広がっています。それでも、何を残し、何を人が決めるかを決めるのは、最後は私です。Benさんの話には、私の記事の場面と重なる所も、ずれる所もあるんです。

新しい機能を足す前に、毎回読まれている指示のうち、古いまま残っている物はどれでしょうか？