Coworkの並列実行の仕組みと指示のコツ

Coworkは、1つの依頼の中に互いに依存しない作業が複数あるとき、それらを同時に進めます。製品ページは「大きな仕事は、一緒に走る小さな塊に分割される」と説明しています。ただし説明は、ページによって「自動で並列」と「頼めば並列」の間で揺れています。その差を知っておくと、依頼文をどこまで具体的に書くかを決めやすくなります。

公式は並列実行をどう説明しているか

Cowork製品ページの「More than one thing at a time」という項目が、この挙動の一番短い説明です。

Big projects are split into chunks that run together. While it drafts, it researches and organizes at the same time. You review polished work.

裏方の実行単位は「サブエージェント」と呼ばれます。ヘルプセンターの「Get started with Claude Cowork」には、これに関する記述が3か所あります。1つ目は「Claudeは複雑な作業を小さなタスクに分け、並列のワークストリームを調整する」という機能説明です。2つ目は、Anthropicのサーバー上で動く実行環境の説明にある「必要に応じて複数のワークストリームを並列に調整する」という一文です。3つ目は「複雑なタスクでは、複数のサブエージェントが同時に動くことがある」という記述です。

2つ目と3つ目は「if appropriate(適切なら)」「may(することがある)」という留保付きです。1つ目の機能説明だけは断定形で、ヘルプセンター内でも書き方が揃っていません。並列にするかどうかの判断はClaude側にあり、この記事で参照したページには、並列数を利用者が指定する方法は載っていません。

ページによって「自動」と「頼む」が揺れる

3つの事例ページを並べると、並列化の書き方が微妙に違います。

フィードバック分析のページは、説明では並列を前提にしながら、tipsで「頼んでみる」と勧めています。前提なら頼む必要はないはずなので、字面どおりに読めば、頼むことで並列化の判断が狙いどおりになりやすくなる、という意味合いです。ブリーフィングのページは頼む方法に触れず、コネクターを足せば並列で問い合わせると書くだけです。

並列になる依頼の形は「共通の材料、独立した成果物」

並列化の可否を分けるのは、作業同士が互いの結果に依存しているかどうかです。ベンダーオンボーディングの事例ページは、この境界を1文で示しています。

Updating the vendor tracker and generating the contract don't depend on each other — so you can ask Claude to spin up subagents and run them in parallel.

トラッカーの更新と契約書の生成は、どちらも同じベンダー情報を読むだけで、片方の出力がもう片方の入力にはなりません。もう1つの型は、複数の情報源への読み取りです。Slack、Linear、Salesforce、Notionへの問い合わせは互いに依存しないので、並列化の対象になります。

同じ事例ページのサンプル依頼文は、ベンダーごとにNDAとMSAをテンプレートから作り、オンボーディングフォームに記入する内容です。最後に全情報をトラッカーへ追加し、新しい書類をデスクトップで仕分けます。ページは「終わった状態を書く」よう勧めています。ただしサンプル自体は作業の列挙で、トラッカーへの追加は「Afterwards(そのあと)」と後ろに置かれています。tipsの「トラッカー更新と契約書生成は独立」とは、順序の扱いが揃っていません。計画はClaudeが立て、独立した部分があれば並列で走る、というのが同ページの説明です。

並列で集めたあとに、突き合わせが入る

並列化の価値は、速さだけではありません。ブリーフィングの事例は、並列に集めた結果が1つの項目に合成される様子を出力例で示しています。

ダッシュボードに「パイプライン速度が今週15%低下」という警告があり、Slackの#salesでは商談2件が翌四半期にずれ込むという投稿がありました。出力例はこの2つを別々に並べず、「関連するスレッドを見つけた」と紐づけた1項目にしています。タグ付けされていないが、自分の採用依頼に関わる#leadershipの議論も拾っています。

顧客フィードバックの事例では、同じ構造が数字で現れます。

出力例は、4ソースすべてに現れるこのテーマを「一部の声の大きい利用者ではなく本当の課題」と評価しています。逆にSSO連携は件数が少ないのにCRMの失注メモに集中して出るため、「利用の問題ではなく商談を止める要因」として別枠で扱われます。並列で集めた生データは、そのまま並べられていません。ソース別に数え、複数ソースにまたがるかで重みを変えています。この後処理を引き出しているのは、依頼文の「ソース別の件数、横断パターン、代表的な引用がほしい」という指示です。

並列を頼むときの依頼文の組み立て方

並列化を狙うなら、依頼文で「終わった状態」に加えて、独立した作業の境界を名指しします。公式のサンプル依頼文に足すと、次のような形になります。以下は事例ページのサンプルを元にした筆者の組み立て例で、公式の文面そのものではありません。

新規ベンダーごとに次を行ってください。
- テンプレートからNDAとMSAを作成する
- 調達ポータルのオンボーディングフォームに記入する
- ベンダー情報をトラッカーのスプレッドシートに追加する
トラッカーの更新と契約書の生成は互いに独立しているので、
サブエージェントを立ち上げて並列に進めてください。
全員分が終わってから、新しい書類をデスクトップのフォルダに整理してください。

Coworkは指示がなくても独立性を探しますが、複雑な依頼では、どこまでが独立かをClaudeの判断に任せきりにしない方が、意図どおりに分かれやすくなると考えられます。依頼文の側で境界を示すのは、その補正です。事例ページ3本は、最初の依頼のあとにClaudeが質問を返し、サイドバーに計画を出すと述べています。この計画が、並列の切り分けが意図どおりかを確かめる場所になります。分割の結果を確かめる手段として参照ページに書かれているのは、このサイドバーの計画だけです。

並列にならないのは、どんなときか

「並列化されない条件」の一覧は、参照したページにありません。事例ページに書かれているのは「独立した部分は並列に進む」という条件の側だけです。そこから逆に読める範囲を、記述とは分けて書きます。

• 1手順で終わる依頼: ファイルを1つ要約するだけの依頼には、切り分ける部分がありません。並列の話は生じないと考えるのが自然です
• 前の工程の出力が次の入力になる作業: 契約内容を確認してから承認メールを書く、のような依存のある作業は、依存する側が待つ形になるはずです。これは記述そのものではなく「独立した部分が並列になる」という条件からの推論です
• 追加の依頼: フィードバック分析のフォローアップ例(特定テーマの深掘り、ロードマップ提案)は、別のプロンプトとして紹介されています。既に出た統合結果を材料にするため、性質上は前の結果に依存する依頼です。ブリーフィングのページにも「最初の依頼が文脈を作り、フォローアップは全部を問い合わせ直さずに絞り込める」という趣旨の記述があります

3つ目は特に注意が要ります。フォローアップが直列か並列かは、書かれていません。並列にならない条件として断言できるのは、依存関係のある作業は前提の結果を待たざるを得ない、という論理の部分だけです。

遅いとき、どの応答が全体を引っぱっているか

進捗パネルには、Claudeが読んでいるファイルや問い合わせ中のコネクターが、ステップごとに表示されます。ブリーフィングのページは、生成に想定より時間がかかるとき、この表示から「どのプラットフォームがボトルネックか」が分かると説明しています。フィードバック分析のページには、あるプラットフォームからの結果が少なすぎるときは、進行中に調整できるという記述もあります。

並列は全体の完了時間を縮める仕組みですが、遅いソースが1つあれば完了はそこに引きずられます。原因の切り分けは、次の順が手がかりになります。

最後の行の根拠は、ヘルプセンターのトラブルシューティングです。ローカルセッションでは、タスクの間ずっとClaude Desktopアプリが開いていて、コンピューターがスリープしていない必要があります。閉じたりスリープしたりすると、セッションが終わることがあります。クラウドのセッションはバックグラウンドで動き続けます。ただしクラウドでも、ローカルのファイルやブラウザー、コンピューターを使うタスクでは、Claudeが届くようにデスクトップアプリを開いておく必要があります。ProとMaxでは、2026年10月6日以降、新しいCoworkタスクはクラウドで動き、設定の「Only on your computer」は削除されます。

並列にしたことで使用量は増えるのか

並列実行が使用量にどう影響するかは、参照したページに数字がありません。ヘルプセンターが明記しているのは次の点です。

• コードの実行、ファイル作成、コネクターやブラウザーを使う複数ステップのタスクは、簡単な質問より多く使用量を使う。ステップごとにトークンを使うため
• 使用量の上限に頻繁に当たるなら、関連する作業を1つのタスクにまとめ、無関係な作業は新しい会話に分ける
• 承認モードの「Auto」は、Claudeが追加のチェックを行うため、ほかのモードより使用量を多く消費する

並列の数と消費量の関係は書かれていないので、サブエージェントを増やせば必ず消費が増える、とも減る、とも言えません。使用量の設計はCoworkのコスト管理で扱っています。

サブエージェントの解説記事との切り分け

並列実行を支えるサブエージェントの導入方法や制約は、Coworkサブエージェントの使い方にあります。この記事は一歩手前の挙動、つまりどんな依頼が並列で進み、どう頼めば狙えるかを扱いました。ヘルプセンターはプラグインが「スキル、コネクター、サブエージェントを1つにまとめたもの」だと説明しています。並列そのものがプラグインの導入を前提にしているかは、事例ページには書かれていません。

自然言語で独立性を推定させる設計の賭け

GitHub ActionsのようなCIツールは、依存関係をワークフローとして利用者が書きます。Coworkは、依存関係を依頼文の自然言語から推定します。書く手間が要らない代わりに、推定が外れたときは、利用者からは何が起きたのか見えにくくなります。

「サブエージェントを頼める」余地が残されているのは、この推定を利用者が補正する手段と読めます。ただし補正が効くのは、利用者が作業の独立性を正しく把握している場合だけです。依存があるのに「独立している」と書けば、その依頼文は誤った前提を渡すことになります。並列の指示を書く前に、片方の出力がもう片方の入力になっていないか、一度確かめる価値があります。

まとめ

並列を頼む価値があるのは、共通の材料から独立した成果物を作る依頼と、複数ソースへの読み取りです。遅いときは進捗パネルで問い合わせ先を見て、原因のソースを切り分けます。Cowork全体の内部構造はClaude CoworkのComputer Use・VMサンドボックスで扱っています。