コンテンツへスキップクリックして折りたたむCtrl+Bドラッグしてサイズ変更ChatCoworkCodeNew task⌘NProjectsScheduledLive artifactsDispatchベータCustomizePinnedDrag to pinRecentsView all夏の俳句 Opus4.6小説書いてもらってるコンテクストウィンドウとナレッジファイルの影響10と1000の関係を表す記号DeepMindの創業者ナノクロウの古いパソコン対応30点の法則についてトークンの数え方すべてを既に持っている法則UFCMMAmillion CPU クレジットカード決済にStripeは便利か実装という言葉の意味の違いGoogle Earthの面白い活用法女性の最適な出産年齢VPSとOpenClawClaudeとMCPの便利な連携例Markdownの基本的な書式要素YouTube字幕ダウンロードと要約ツールTransformerアーキテクチャとライオン・ジョーンズScheduledDaily english learning topic毎日PinnedMarkdown folder agent setupDaily report templateRecentsView all小説作家Sonnet4.6NewTask vs ProjectsAgent setup usage question英語レッスンの動作を修正エージェントの役割を勉強した。旧コーチングメルマガ下書き作成とCowork機能確認PinnedDrag to pinRecentsCrepe shop websiteクレープ屋のHPAdd Sakura server FTP access supportImage conversion to JPG with compression英語xSNSxNOTEで月20万円Qwen3-TTS installationConnect Google Drive to Claude via MCPDisplay work history JSONL file listLearn Claude API usage basicsmario·ProAgent setup usage questionあなたの入力: projectの中のPinnedしている、projectの中のPinnedしている、
Markdown Folder Agent Setup
Daily Report Template
のスレッドについて聞きたいんですけど。
あのスレッドでたしかにエージェントを作った気がする。
「エージェントを作成中」というグルグルがまわってる画面もあった。
でも、複数のエージェントとやりとりしてる感じはなくて、ひとつのスレッドでひとつのClaudeとおしゃべりしているような感じなんだけど、これは僕の使い方の何がわるいのでしょうか？Claudeが返答しました: 結論から言うと、使い方は間違っていません。今感じている「1つのスレッドで1人のClaudeとしゃべっている」状態が、本来の正しい姿です。思考プロセス思考プロセス結論から言うと、使い方は間違っていません。今感じている「1つのスレッドで1人のClaudeとしゃべっている」状態が、本来の正しい姿です。
仕組みを整理すると：
スレッドは常に「メインのClaude（あなたの会話相手）が1人」という構造です。あなたは常にこの1人とだけ会話します。「エージェントを作成中」のグルグルは、メインのClaudeが裏側で**サブエージェント（下請け役）**を一時的に呼び出して、ある作業（例：たくさんのファイルを探す、調査する等）をやらせている瞬間です。サブエージェントは作業が終わると結果だけをメインのClaudeに渡して消えます。あなたが直接サブエージェントとチャットすることはありません。
つまり「複数のエージェントとやりとりしている感じがしない」のは正常で、サブエージェントは表に出てこない裏方だからです。
ここで混乱の元になっていそうなのが、「Markdown Folder Agent Setup」という名前です。これはおそらくサブエージェントを呼ぶ話ではなく、特定の作業を自動でやってくれる仕組み（スキル／カスタムエージェントの設定や、Markdownフォルダを扱うための準備）を作ったスレッドだと思われます。「Agent」という言葉が2つの意味で使われていて紛らわしいんですね：
会話相手としてのClaude本体（あなたが話している相手）
設定として作る「○○用エージェント／スキル」（道具のようなもの）
何が知りたいかで、次の確認が変わります。
そのスレッドで実際に何が作られたのか（中身）を一緒に見たい
作ったエージェント／スキルを別スレッドで実際に呼び出して使う方法を知りたい
どちらでしょう？必要なら、ピン留めされたそのスレッドの中身を読んで「結局何が作られたか」を確認することもできます。確認しましょうか？あなたの入力: なるほど、そしたら、話相手のClaudeがHaikuでも、サブエージェントはOpusで作ってと言っておけば、後ろで動いているAIはOpusで高度な計算も可能ということですか？なるほど、そしたら、話相手のClaudeがHaikuでも、サブエージェントはOpusで作ってと言っておけば、後ろで動いているAIはOpusで高度な計算も可能ということですか？Claudeが返答しました: 考え方としては正しいです。サブエージェントは呼び出すときにモデルを指定できる仕組みになっていて、メインの会話相手とは別のモデルで動かせます。なので理屈の上では「会話相手はHaiku、重い処理はOpusのサブエージェントに投げる」という構成は可能です。思考プロセス思考プロセス考え方としては正しいです。サブエージェントは呼び出すときにモデルを指定できる仕組みになっていて、メインの会話相手とは別のモデルで動かせます。なので理屈の上では「会話相手はHaiku、重い処理はOpusのサブエージェントに投げる」という構成は可能です。
ただ実際の効果には注意点があります。
サブエージェントに何をどう指示するか（タスクの切り出し、判断、結果の解釈）は、結局メインのClaude＝Haiku側がやります。つまり高度な計算そのものはOpusが担えても、「どんな問題を、どう分解して、Opusに何を渡すか」という司令塔の質はHaiku側の能力に縛られます。難しい問題ほど、この司令塔部分が結果を左右するので、「会話相手をHaikuにしてサブだけOpus」では期待ほど賢くならないことが多いです。
それから、サブエージェントは裏方なので、あなたが対話しながら詰めていく作業（途中で軌道修正する、質問し合う）には向きません。一回投げて結果が返る、というバッチ的な使い方になります。
なので、本当に高度な計算や判断をさせたいなら、素直に会話相手のClaude自体をOpusにするのが確実です。サブエージェントでOpusを使うのが効くのは、「メインはそこそこの賢さで十分だが、特定の重い調査・探索を並列でOpusにまとめてやらせたい」といったケースです。
何か具体的にやらせたい計算やタスクがあれば、どういう構成が合うか一緒に考えますよ。あなたの入力: いや。いまは特にやりたい作業はないんだけど、このCoworkの使い方を知りたかっただけなんです。いや。いまは特にやりたい作業はないんだけど、このCoworkの使い方を知りたかっただけなんです。Claudeが返答しました: なるほど、それなら今ので大事なところはほぼ押さえられていますよ。整理すると：なるほど、それなら今ので大事なところはほぼ押さえられていますよ。整理すると：
1スレッド＝メインのClaude1人との会話。これが基本。
「エージェント作成中」のグルグルは、そのメインClaudeが裏方（サブエージェント）を一時的に呼んで作業させているだけ。あなたが直接複数のAIと話すわけではない。
賢さが必要なときは、サブに任せるより会話相手そのものを上位モデルにするのが確実。
補足すると、Coworkが本領を発揮するのは「ただ話す」よりも、ファイルを作る・調べる・自動化するといった手を動かす作業を任せたときです。例えば、
フォルダを指定して中のファイルを整理・要約してもらう
調べ物をして、Word／Excel／PDF／スライドにまとめてもらう
「毎朝○○して」のように定期実行を仕込む（スケジュール機能）
メールやカレンダーなど、つないだツールを操作してもらう
ピン留めしてあった「Daily Report Template」や「Markdown Folder Agent Setup」も、おそらくこういう”作業の型”を作ろうとしたものだと思います。
今は特に作業がないとのことなので無理に何かする必要はないですが、もし「Coworkってどんなことが得意なのか実際に見てみたい」と思ったら、軽いお題で一緒に試すのが一番わかりやすいです。気が向いたら声をかけてください。あなたの入力: じゃ、上流→下流→下流。というふうに、賢い、→普通→単純なやつ。みたいにエージェントを組んだ方がいいんですね。じゃ、上流→下流→下流。というふうに、賢い、→普通→単純なやつ。みたいにエージェントを組んだ方がいいんですね。Claudeが返答しました: 方向性としては正しいです。司令塔（上流）を賢いモデルにして、そこで問題を分解し、はっきり定義できた単純な作業を下流の安いモデルに振る——これが理にかなった組み方です。さっきの話の逆、つまり「会話相手をHaikuにしてサブだけOpus」がうまくいきにくいのは、司令塔が下流より弱いと全体が引っ張られるからでした。上流を賢…思考プロセス思考プロセス方向性としては正しいです。司令塔（上流）を賢いモデルにして、そこで問題を分解し、はっきり定義できた単純な作業を下流の安いモデルに振る——これが理にかなった組み方です。さっきの話の逆、つまり「会話相手をHaikuにしてサブだけOpus」がうまくいきにくいのは、司令塔が下流より弱いと全体が引っ張られるからでした。上流を賢くするのは、その逆で筋がいいわけです。
ただ2点だけ補足を。
ひとつは、下流が必ずしも「普通→単純」と多段である必要はないこと。段を増やすほど指示の受け渡しでロスや時間がかかります。多くの場合は「賢い上流が1人 → 単純作業を下流に振る」の2段で十分で、3段以上が活きるのは作業量が本当に多いときくらいです。
もうひとつ、より大事な点。Coworkでは普段こういう構成を自分で組む必要はありません。 会話相手のClaudeを賢いモデルにしておけば、必要なときに裏で勝手にサブエージェントを呼んで振り分けてくれます。「上流→下流」を意識して設計するのは、定型作業を自動化する仕組みを自分で作り込むような、一歩踏み込んだ使い方をするときの考え方です。
なので普段の感覚としては「会話相手を賢いやつにしておく。あとは任せる」で十分、と覚えておけば大丈夫です。あなたの入力: え～。そうなんだ。そしたら、自分でチーム編成とか役割とか考えなくていいんですね。そしたらCoworkとCodeの違いってなんだろう。やってる途中から複数な作業も発生する場合にそなえて、Coworkで作業したいよね。最初から。（笑）え～。そうなんだ。そしたら、自分でチーム編成とか役割とか考えなくていいんですね。そしたらCoworkとCodeの違いってなんだろう。やってる途中から複数な作業も発生する場合にそなえて、Coworkで作業したいよね。最初から。（笑）Claudeが返答しました: そうなんです、普段はチーム編成を自分で考えなくて大丈夫。そこはClaudeが裏で勝手にやってくれます。思考プロセス思考プロセスそうなんです、普段はチーム編成を自分で考えなくて大丈夫。そこはClaudeが裏で勝手にやってくれます。
CoworkとCodeの違いをざっくり言うと、想定しているユーザーと作業の種類が違います。
Claude Codeは、もともとエンジニア向けのツールです。ターミナル（黒い画面でコマンドを打つやつ）の中で動いて、コードを書く・直す・テストする、といったソフトウェア開発の作業に強い。プログラマーが自分の開発環境にどっぷり組み込んで使うものです。
Coworkは、その技術をエンジニアじゃない人でも使えるようにしたデスクトップ向けの仕組みです。ターミナルを触らずに、ファイルを整理する・調べ物をする・資料（Word、Excel、スライド、PDF）を作る・メールやカレンダーを操作する・定期実行を仕込む、といった日常の作業を任せられます。今あなたが話しているこれがCoworkです。
中身の土台は実は共通で、Coworkはその上に「会話で気軽に頼める」「ファイルやツールにつながる」「裏でエージェントを振り分ける」といった使いやすさを乗せたもの、というイメージです。
なので「途中で複数の作業が出てくるかもしれないから最初からCoworkで」という発想は、まさに正解です（笑）。コードをガリガリ書くのが主目的でないなら、Coworkで始めておけば、調べ物から資料作成、自動化まで幅広くカバーできます。あなたの入力: いまはCodeもターミナルじゃないし、おしゃべりベースでコーディングもしてくれるし、コーディングじゃない作業もふつうにしますよね。デスクトップアプリが進化してCoworkとCodeの違いがだんだんなくなってきちゃったってことですか？一般ユーザーが見た場合の。いまはCodeもターミナルじゃないし、おしゃべりベースでコーディングもしてくれるし、コーディングじゃない作業もふつうにしますよね。デスクトップアプリが進化してCoworkとCodeの違いがだんだんなくなってきちゃったってことですか？一般ユーザーが見た場合の。Claudeが返答しました: 鋭い観察です。実際、その通りの流れになっています。読み込まれたツール, ウェブを検索しました読み込まれたツール, ウェブを検索しました鋭い観察です。実際、その通りの流れになっています。
おっしゃる通り、Codeも今は会話ベースで使えるしコーディング以外の作業もこなす、Coworkはデスクトップアプリでどんどん高機能になる——で、表面的な体験はかなり近づいてきています。一般ユーザーから見れば「どっちでも似たようなことができる」と感じる場面は増えています。
ただ、設計思想としての違いはまだ残っていて、整理するとこんな感じです。位置づけとしてよく言われるのが、Claude（チャット）は「Claudeと考える」、Coworkは「Claudeに任せる（delegate）」、Codeは「Claudeと作る（build）」というすみ分けです。
残っている実際の違いは主に3つ。
ひとつは入り口。Coworkはデスクトップアプリの中でそのまま動いて、インストールも設定も不要。Codeは自分のPCにインストールして環境を設定して使う、という前提が依然あります。
ふたつめは安全性。Coworkは隔離された仮想環境（VM）の中で動くので、外部からの影響を受けにくい作りになっています。Codeはあなたの実環境に近いところで動く分、自由度が高い代わりにリスク管理も自分の責任になります。
みっつめは精度とコントロール。Codeは設定の手間と引き換えに、精度・速度・拡張性・制御の細かさで上回る、と位置づけられています。作り込んでガッチリ使いたい人向けですね。
なのであなたの感覚は正しくて、一般ユーザー目線では境界はかなり曖昧になってきている。ただ「気軽さ・安全さで選ぶならCowork、作り込みと制御で選ぶならCode」という軸は残っている、という状態です。コードをガッツリ書くのでなければCoworkで始めておく、という判断は今でも理にかなっています。
ちなみに今はPpro/有料プランにCodeもCoworkも両方含まれているので、気が向いたら両方触って比べてみるのもありですよ。