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

Coworkは、1つの依頼の中に互いに依存しない作業が複数含まれているとき、それらを自動的に並列で進めます。公式サイトはこの挙動を「大きな仕事は、一緒に走る小さな塊に分割される」と説明しています。逐次1つずつ片付けるのではなく、下書きをしながら同時に調査や整理も進める、という動き方です。

Coworkの並列実行とは何か

Cowork製品ページの「More than one thing at a time」という項目が、この挙動を1文で説明しています。原文は次のとおりです。

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

利用者が並列処理を意識して指示しなくても、Coworkは依頼を受け取った時点で計画を立て、独立して進められる部分を見つけて同時に走らせます。公式の用語では、この裏方の実行単位を「サブエージェント」と呼びます。並列数を指定する設定は公式には案内されておらず、並列化するかどうかの判断はClaude側に委ねられています。

どんなタスクが並列で進むか

並列化の可否を分けるのは、作業同士が互いの結果に依存しているかです。公式のベンダーオンボーディング事例は、この境界をはっきり切り分けています。

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.

ベンダートラッカーの更新と契約書の生成は、どちらも同じベンダー情報を参照するだけで、片方の出力がもう片方の入力になるわけではありません。この手の「共通の材料から複数の成果物を独立に作る」構造は、並列化が効きやすい典型パターンです。

複数の情報源から同時に情報を集める場面でも同じ理屈が働きます。顧客フィードバックを横断して傾向を洗い出す事例は、Slack・Linear・Salesforceのような複数ソースへの問い合わせを同時に走らせる使い方を紹介しています。日々の業務ブリーフィングを作る事例も、「メッセージング・タスク管理・ダッシュボードのソースを追加すると、Coworkはそれらを並列に問い合わせる」と述べています。複数の外部ソースへの読み取りは、そもそも互いに依存しないため、素直に並列化の対象になります。

このブリーフィング生成の事例は、並列で集めた結果がどう1つの成果物にまとまるかまで示している点が参考になります。SlackとNotion、Chromeで開いたチームダッシュボードを同時に問い合わせたうえで、ダッシュボードの数値低下(パイプライン速度が15%低下)と、それに関連するSlackスレッド(商談が翌四半期にずれ込む話をしていた投稿)を紐づけて1つの項目にまとめています。自分がタグ付けされていないが業務上知っておくべきスレッドまで拾い上げる形で、優先度付きの1本のブリーフィングに合成されます。並列で集めた個々の結果をそのまま並べるのではなく、後段で相互参照して1つの成果物に統合する、という2段構えの動きです。

顧客フィードバックを横断する事例では、この統合の効果を示す出力サンプルが公式に載っています。通話の文字起こし・Slack・Salesforce・Linearという4つのソースを並列に問い合わせた例では、「モバイルアプリの不具合」というテーマが合計57件(通話11件・Slack31件・CRM1件・Linear14件)というソース別内訳つきで集計される出力例が示されています。4つすべてのソースに同じテーマが現れれば、一部の声の大きい利用者だけの意見ではなく実際に広がっている課題だと判断できる、という使い方の紹介です。並列で集めた生データをソースごとに数え上げ、複数ソースにまたがって出現するテーマを重み付けする、という後処理があって初めてこの精度の統合が成立します。

明示的に並列化を指示する方法

Coworkは自動で並列化を判断しますが、依頼文の中で明示的に頼むこともできます。ベンダーオンボーディング事例のサンプル依頼文は、「ベンダーごとにテンプレートからNDAとMSAを作成し、オンボーディングフォームに記入したうえで、ベンダートラッカーに情報を追加してください」という内容です。これに、同じページの別の解説にある「サブエージェントを立ち上げて独立した作業を並列に進めてもらう」という頼み方を足すと、狙って並列化を依頼できます。この2つは同じ事例ページの別々の箇所で述べられているもので、ひとつながりの引用ではありません。

ポイントは2つです。1つは、依頼の中で「何が独立した作業か」を明確にすること。もう1つは、「サブエージェントを使って並列に」と明示的に書くことです。フィードバック分析の事例でも同様に「Slack・Linear・Salesforceへの問い合わせにサブエージェントを立ち上げるよう頼める」という紹介があり、複数ソースを扱う依頼では明示的に頼む価値があります。

指示を出さなくてもCoworkは独立性を見つけて自動的に並列化を試みますが、複雑な依頼ほど「どこまでが独立した作業か」の判断が割れやすくなります。並列化してほしい境界がはっきりしているなら、依頼文に含めておくほうが狙いどおりの動きになりやすいです。

「サブエージェントを立ち上げて並列に」という言い回しは、ベンダーオンボーディングとフィードバック分析という性質の異なる2つの公式事例で、ほぼ同じ表現で繰り返し登場しています。特定の業務向けの裏技ではなく、独立した作業を含む依頼であれば汎用的に使える指示の型だと見てよさそうです。

並列化されない条件

すべての依頼が並列化の対象になるわけではありません。

• 単発の依頼には分割する材料がない: 「このファイルを要約して」のような1手順で完結する依頼は、そもそも分けられる部分がないため並列化されません
• 前の工程の出力が次の工程の入力になる作業は直列のまま: 契約書の内容を確認してから承認メールを送る、のように順序に意味がある作業は、依存関係があるため並列化できません
• 1つのファイルやページに対する連続した操作: 同じスプレッドシートを読み込みながら複数の列を同時に編集するような、対象そのものが1つで競合しうる操作は、まとめて1つの作業として扱われます

フィードバック分析の事例では、この境界がフォローアップの依頼にも表れています。初回の統合結果をもとに「特定のテーマだけを深掘りする」「ロードマップ提案を書く」といった追加の依頼は、直前の統合結果を土台にするため直列に進みます。並列化が効くのは独立した情報収集の段階までで、そこから先の統合・提案フェーズは順番に積み上げる形に戻ります。

進捗パネルには、Claudeが今どのファイルを読み、何をしているかがステップごとに表示されます。並列で複数のワークストリームが動いているときも、途中で内容を確認したり指示を追加したりできます。ブリーフィング生成の事例は、この表示を診断にも使えると紹介しています。今どのコネクタに問い合わせているかがリアルタイムに見えるため、生成が想定より時間がかかっているときは、どのプラットフォームの応答がボトルネックになっているかをパネルから特定できます。並列実行は全体の完了時間を縮める仕組みですが、応答が遅いソースが1つでもあれば全体の完了はそのソースに引きずられるため、この可視化には実務上の価値があります。

Coworkサブエージェントの使い方とは何が違うか

Coworkの並列実行を支えているのはサブエージェントという裏方の仕組みで、その導入方法や制約(プラグイン経由でしか使えない、チャットでは動かない等)はCoworkサブエージェントの使い方にまとめています。本稿はその一歩手前、どんな依頼が並列で進み、どう指示すれば狙って並列化できるかという挙動そのものに絞っています。プラグインを1つも入れていない素のCoworkでも、独立した作業を含む依頼を投げれば同じ並列化は起こります。

この設計をどう見るか

「大きな仕事は一緒に走る塊に分割される」という説明は、利用者に並列処理の仕組みを意識させないという設計判断の表れと見ることもできます。GitHub ActionsやCIツールのように依存関係をワークフローとして明示的に書く仕組みとは対照的に、Coworkは依頼文という自然言語から独立性を推定します。この推定に頼る設計は、依頼が単純なうちは驚くほどうまく機能しますが、複雑な依頼になるほど「独立している」という判断がずれるリスクも同時に増えるはずです。公式が「明示的にサブエージェントを頼める」余地を残しているのは、この自動推定を利用者側から補正する手段として理にかなっています。

まとめ

Coworkの並列実行は、依頼の中に互いに依存しない作業が含まれているときに自動で発動する挙動です。ベンダートラッカーの更新と契約書生成、複数ソースへの同時問い合わせのように、共通の材料から独立した成果物を作る依頼が典型的な対象になります。狙って並列化したいときは、依頼文で独立した作業の境界を明示し、「サブエージェントを立ち上げて並列に」と直接頼むと安定します。単発の依頼や、前工程の出力が次工程の入力になる直列作業は対象になりません。Cowork全体の内部構造はClaude CoworkのComputer Use・VMサンドボックスで扱っています。