Claude CodeにProjectsが登場 1つの会話で並列スレッドを回す仕組み
9月17日(米国時間)、AnthropicがClaude Codeに新しい「Projects」を展開し始めました。前日のCoworkとチャットの統合に続く発表です。公式ブログの題は「Projects redesigned: from folder to conversation」。プロジェクトは「フォルダ」から「会話」になる、という意味です。
これまでもClaude Codeには、仕事を分けて同時に進める仕組みはありました。ただ、日をまたいで続く仕事を複数のセッションで回すとなると、どのセッションに何を頼むか、背景を毎回説明する、終わったかどうかを見に行く、という段取りは人の仕事でした。新しいProjectsは、その段取りをClaudeに渡します。1本の会話に「これをやって」と投げ込むだけで、Claudeが仕事を分け、並列に進め、終わったら報告してくる。先に結論を言うと、人から消えるのはコードを書く作業ではなく段取りで、代わりに「どこまでやったら終わりか」を書く仕事が残ります。まだ一部のユーザーへのベータ提供で、筆者のアカウントにもまだ来ていません。
仕組みは「秘書と実働部隊」
登場人物は2種類です。公式の文書の言葉では「プロジェクトの会話」と「スレッド」。分かりやすく言えば、秘書と実働部隊です。
秘書(プロジェクトの会話) は、あなたが話しかける相手です。1本の長い会話で、あなたが投げた仕事を受け取り、それを新しいスレッドに回すか、すでに近い仕事をしているスレッドに足すか、その場で答えて済ませるかを決めます。スレッドから上がってくる報告を読んで、次に何をするかを考えるのも秘書の仕事です。細かい作業の一手一手は見ていなくて、報告だけを見ています。
実働部隊(スレッド) は、実際に手を動かす側です。1本のスレッドが1つのClaude Codeのセッションで、クラウド上で動きます。コードの置き場(リポジトリ)を自分用に複製し、自分のブランチ(作業用の枝)で作業し、必要なら変更の提案(プルリクエスト、以下PR)を開いて、終わったら秘書に報告します。スレッドは互いに独立していて、複数が同時に動きます。秘書も実働部隊もどちらもClaudeなので、秘書の側も、報告を読んで次を考える分の利用量を使います。
そして、全スレッドが仕事を始めるときに同じものを読みます。プロジェクトに登録したリポジトリとファイル、あなたが書いたプロジェクトの指示(16,000字まで)、そして共有メモリです。共有メモリは、Claudeが仕事の途中で覚えた決定事項や落とし穴のメモで、公式ブログの例では「リリースは金曜に動いた」「エクスポート機能を落とした理由」「請求のサービスを触る前に誰に確認するか」。「これを覚えて」と頼んだことや、Claudeが自分で書き留めたことが、あとから始まるスレッド全部に届きます。何が保存されているかは設定画面のMemoryで見られて、直したり消したりもできます。
進み具合は、会話の横にあるOverviewという一覧で見ます。スレッドは、レビューを待つもの、あなたの返事を待つもの、作業中のもの、取り込み待ちのもの、作業を終えて何も待っていないもの、完了にしたもの、に分かれて並び(英語の画面ではReady for review / Waiting on you / Working / Landing / Idle / Resolved)、あなたが見るべきものだけが浮き上がる作りです。デスクトップアプリなら、返事が要るときに通知も来ます。
公式ブログの例を2つ。「アプリの決済処理の遅さを減らす」という目標を置いて、処理の入り口ごとに計測と改善とPRを並列のスレッドで進めさせる。もう1つは、API・Web・モバイルの3つのリポジトリをつないで「古い接続口(v1のエンドポイント)を廃止する」と目標を置くと、リポジトリごとにスレッドが立って呼び出し元を書き換え、テストを回し、PRを開いたうえで、どれを先に取り込むべきかまで教えてくる、というものです。
最初の1件は、小さく投げる
使える場所は、ブラウザのclaude.ai/code、デスクトップアプリのCodeタブ、スマホのアプリです。ターミナルのCLIからは使えません。
前提が2つあります。ProかMaxプランであること、そしてコードを扱うならGitHub.comにあること(会社で立てたGitHub Enterprise ServerやGitLab、Bitbucketは対象外)。加えて、そのリポジトリに書き込める(プッシュできる)GitHubアカウントをClaudeにつないだうえで、リポジトリにClaude GitHub Appというアプリを入れておく必要があります。会社の組織が持つリポジトリでは、組織の管理者がアプリの導入を承認しないと使えません。
作り方は、サイドバーの「Projects」から「New project」。必須なのは名前だけで、目標(「APIの応答を200ミリ秒以内に保つ」のような1行)と、対象のリポジトリやファイルは後から足せます。すでに動いているクラウドセッションがあれば、そのメニューから「Continue as a project」を選ぶと、Claudeがその作業内容から設定を提案してくれます。
ここから先は、公式の文書が「最初の一括」として勧めている順番が実用的です。
- プロジェクトの指示を書く。 全スレッドが最初に読む台本です。どのブランチに向けて作業するか、作業をどう確かめるか、何をするときはあなたの許可が要るか
- 本物の仕事を小さく1件だけ投げる。 終わったらスレッドを開いて、どう報告してきたか、ブランチで何をしたかを見る。思い込みで進めていたり、必要なものに届いていなかったりしたら、ここで直す
- モデルと労力の設定を確認する。 労力は、Claudeがどれだけ深く考えるかの設定で、高いほど消費が増え、難しい仕事では結果が良くなることがあります。新しいプロジェクトは、初期設定で全スレッドがOpusの高い労力で動きます。いちばん賢く、いちばん早く利用上限を食う設定です
- 「スレッドは提案してから始めて」「同時に2本まで」と頼む。 数本がうまく回ったら緩める
会話の中で頼めることは、公式が具体的に列挙しています。「更新は短く」「終わったときと詰まったときだけ報告して」「計画を見せるまでPRは開かないで」「この作業は小さいモデルで」「直さずに、問題点だけ教えて」。こう頼むとClaudeは共有メモリに書き込んで、以後のスレッドでも守ろうとします。ここで、伝え方が2種類あることを押さえておくと迷いません。
- 守ろうとする指示: 会話で頼んだことと、プロジェクトの指示に書いたこと。どちらも文章で伝えた約束で、Claudeは従おうとしますが、機械的に止まるわけではありません。文言をきっちり決めて全スレッドに最初から届けたいことは、指示のほうに書きます
- 機械的に止める設定: 絶対に実行させたくない操作は、リポジトリの中の権限ルール(許可と禁止を書く設定ファイル)で止めます。ただしこの権限ルールが効くのはリポジトリが1つのプロジェクトだけで、複数のリポジトリを登録したプロジェクトでは適用されない、と公式は書いています
向く仕事は「終わらない仕事」、向かないのは「手元にしかない仕事」
公式の文書が挙げる「向く仕事」は4種類で、共通するのは、1回の返事では終わらず、やることが増え続ける仕事です。
- 1つの目標が複数のリポジトリにまたがる: 「全サービスを新しい設定に合わせる」。リポジトリごとにスレッドが立ち、PRが並ぶ
- 同じ領域に仕事を投げ続ける: あるサービスのバグ、エラーの記録、レビュー依頼を、来るたびに会話に貼る。一度「これに気をつけて」と言えば次のスレッドにも効く
- 1セッションより大きい構築や移行: 「この仕様書のとおり作って」「古いデータベースの仕組みから移行して」
- コード以外: 契約書のフォルダや、問い合わせ履歴のエクスポートを登録して、「この中で多い連携ミスを10個挙げて」のように何度も聞く。成果物はファイルとして一覧(Library)に溜まる
逆に「向かない仕事」も公式が明記しています。1回のセッションで終わる単発の修正は、普通のクラウドセッションで十分。手元のPCにしかないもの(ローカルのデータベース、端末のエミュレーター、社内ネットワークの中のAPI)を使う仕事は、スレッドがクラウドで動くので届きません。決まった時刻に1つ動かすだけなら予約実行(routines)、複数人でSlackから動かすなら別製品のClaude Tagです。
ここは正直に書いておくと、私たちの記事制作のような仕事は、半分向いていて半分向いていません。毎日テーマが湧いて、調査・執筆・レビューが並ぶ流れはProjectsの形そのもので、クラウドで完結するこの3工程はいまでも任せられるでしょう。一方で、画像を手元のツールで作る工程や、ローカルの開発サーバーで表示を確かめる工程は、いまのスレッドには届かないので、人が引き取ることになります。全部の工程を移すなら、公式が「まもなく」と書いている手元のツールへの対応が来てからだと思います。
既存の機能とどう違うか、とくにサブエージェントと
Claude Codeには、複数の作業を同時に動かす機能がすでにいくつもあります。見分ける軸は2つで足ります。段取りを持つのが自分かClaudeか、そして動く場所が手元かクラウドか。Projectsは「Claudeが段取りを持ち、クラウドで動き、日をまたいで続く」という組み合わせで、これは今までありませんでした。公式の比較表をもとに、読者に関わる違いだけ抜き出します。
| 機能 | 何か | 向く場面 |
|---|---|---|
| サブエージェント | 1つのセッションの中で脇の仕事を別の文脈でやり、要約だけ返す下請け | 検索結果やログで本筋の会話を汚したくないとき |
| Agent view | 手元で動く複数のセッションを1画面で見張る。指示役はいない | 独立した作業を自分で振って、あとで確認したいとき |
| Agent teams | 1つのセッションが仲間のセッションを立てて1つの課題を分担。実験的機能で初期設定はオフ | 1つの課題を分けて同時に進めたいとき |
| Projects | 1本の会話。Claudeがクラウドのスレッドを立て、同じリポジトリ・指示・メモリを渡し、どれが返事待ちかを見せる | 日〜週単位で続く仕事を、一度説明したら追跡まで任せたいとき |
| Dynamic workflows | 多数のサブエージェントを回して結果を突き合わせる台本 | 500ファイルの移行や、根拠を相互に検証させる調査 |
いちばん混同しやすいのはサブエージェントです。違いは2つ。誰が段取りを持つかと、親のセッションの一部か、独立したセッションか。サブエージェントは、いま開いているセッションの中でClaudeがその場で呼ぶ下請けで、親と同じ場所(手元で動かしていれば手元)で動き、結果の要約を親に返します。終わったあとに続きを頼むこともできますが、あくまで親のセッションの一部です。Projectsのスレッドは1本ずつが独立したクラウドのセッションで、日をまたいで生き続け、PRの自動テスト(CI)が失敗したりレビューコメントが付いたりすると起きて対応します。そして段取りを持つのは、その場のClaudeではなく、プロジェクトの会話です。公式も、並列に動かすこと自体がProjectsの目的ではなく、セッションを立てて追いかける役をClaudeに移すことが目的だ、と書いています。スレッドの中でさらにサブエージェントを使うこともできるので、入れ子の関係です。
もう1つの混同は、以前からある「プロジェクト」との違いです。claude.aiのチャットやCoworkにあったプロジェクトは、会話と参照ファイルをまとめる箱で、スレッドも秘書もいませんでした。公式は、既存のプロジェクトはこれまでどおり動き、展開がチャットとCoworkに広がるときに新しい形に置き換える、としています。「フォルダから会話へ」という題名は、この置き換えのことです。
Anthropicの中の人の言い方も手がかりになります。Claude Codeを作ったBoris Cherny氏は、セッションを管理するのをやめて、思いついたまま投げるとスレッドに分かれ、プロジェクトが自分の働き方を覚えていく、コーディングの大半をそこでやっている、と書いています。同社のThariq氏は、Slackの中で動くClaude Tagの構造をClaude Codeに持ち込んだもので、プロジェクトごとに1つのエージェントがメモリを管理し、作業のためにサブエージェントを生む、と説明しています。
気をつける点は、上限・クラウド限定・手元の設定が届かないこと
利用上限が早く減ります。 スレッド1本が丸ごと1セッションなので、複数動かせばその分だけ消費しますし、報告を読んで次を考える秘書の側も使います。公式は「Proではとくに、プロジェクトを動かした日は上限に早く達すると思ってほしい」と書いています。初期設定がOpusの高い労力であることも消費を早める理由で、モデルと労力は「Project settings」で下げられます。上限に達したスレッドは待って、枠が戻ると勝手に再開するので、放っておいた仕事が次の枠を使い始めることも頭に入れておく必要があります(定期実行から始まったスレッドだけは例外で、止まったままになるので自分で再開を頼みます)。1日に新しく立てられるスレッドは、全プロジェクト合わせて200本まで。PRを見張っている待機中のスレッドも、テストが落ちたりコメントが付いたりすると起きて上限を使います。止めたければ、そのスレッドに「もう見張らなくていい」と言います。
クラウドで動くので、届かないものがあります。 手元のPCにしかないファイルやツール、社内ネットワークの中のシステムは使えません。もう1つ見落としやすいのが、自分のPCにだけあるClaude Codeの設定はスレッドに引き継がれないことです。スレッドが読むのは、リポジトリの中に入っている設定(作業ルールを書いたCLAUDE.mdというファイル、スキル、プラグイン)と、claude.aiのアカウントに接続した外部サービス(コネクタ)です。自分のPCの設定ファイルで育ててきたルールは、リポジトリに入れておかないと届きません。リポジトリの中の権限ルールも、先に書いたとおりリポジトリが1つのプロジェクトでしか効きません。
未コミットの作業が消えることがあります。 スレッドの作業環境はターンの合間に止まり、再開できない場合は新しい複製からやり直すので、長い作業では「途中でもコミットしてプッシュして」(途中経過を保存して、GitHubに送っておいて)と頼んでおく、と公式が書いています。
共有と管理はまだありません。 プロジェクトは1人のもので、他の人に共有できず、組織としての管理機能もベータの間はありません。TeamとEnterpriseプランはまだ対象外です。
Xの反応も、公式の発表投稿への返信と引用を見た範囲で書いておくと、セッション管理から解放されることや、セッションを自分で束ねる前提が変わることを歓迎する声が多く見えました。一方で、利用上限をすぐ使い切るのではないか、クラウド限定でGitHubが前提だ、並列にしても変更同士のぶつかり(マージの衝突)は残るので面倒が指示からPRの処理に移るだけではないか、という冷静な見方も並んでいます。
考察 消えるのは作業ではなく「段取り」で、残るのは「終わりの定義」
ここまでが公式の発表と文書に書かれていることです。ここから先は筆者の読みになります。
Projectsが人から取り上げるのは、コードを書く作業ではなく、段取りだと思います。何をどのセッションに頼むか、背景を毎回説明する、終わったかを見に行く。この3つは、複数のセッションを回したことがある人なら誰でも面倒だと知っている部分で、Claudeに渡せるなら渡したい仕事です。
その代わりに人に残るのは、どこまでやったら終わりかを書く仕事だと思います。Claudeが自分で仕事を分けて進めるほど、「完了の条件」と「触ってよい範囲」が曖昧なままだと、スレッド同士が同じ場所を直して衝突したり、終わったつもりの仕事が終わっていなかったりします。公式が「最初にプロジェクトの指示を書け」「まず小さく1件で試せ」と念を押しているのは、そういうことではないでしょうか。私たちがAI社員の手順書と権限で毎回書いているのと同じ話が、Claude Codeの中でも問われている、と読んでいます。具体的に言うと、私たちの記事制作なら、完了の条件は「第三者レビューで残った指摘のうち、事実誤認と論理の飛躍がゼロになっていること」「ビルドが通ること」で、触ってよい範囲は「記事のファイルと画像のフォルダだけ。公開の操作は人がする」です。この2つが書けていない仕事をProjectsに渡すと、Claudeが勝手に終わりを決めるか、いつまでも終われないかのどちらかになるでしょう。
経営者の立場で見ておきたい点も1つあります。いまのProjectsは「1人のもの」で、誰が何を動かしたかを組織として見る仕組みもまだありません。共有できないので、本人以外は中を見ることも止めることもできず、止める手段は本人がプロジェクトを一時停止するか保管するかです。利用対象になった個人のアカウントなら、自分の作業の整理には今日から使えますが、担当者が異動や退職をしても引き継げる正式な業務の流れに置くのは、TeamとEnterpriseへの展開と、組織の管理機能を待ってからだと思います。
もう1つ。「1つのセッションに1つの仕事を頼み、複数のセッションは自分で束ねる」使い方から、「1つの会話に1つの目標を渡す」使い方に変わる、という見方もできます。これが本当にそうなるかは、2つの目印で分かるはずです。手元のツールに届くローカル対応がいつ来るか、そしてTeamとEnterpriseに組織としての管理機能が付くか。ローカル対応は手元のツールが要る会社にとっての条件で、組織の管理機能は引き継ぎや監査が要る会社にとっての条件です。どちらも、会社での利用が広がる目印になると見ています。
さいごに 自分の番が来ているか、まず確かめる
Codeタブかclaude.ai/codeのサイドバーに「Projects」が出ていれば使えます。出ていなければまだ順番が来ていないので、待機リストに登録しておく。公式によると、最初の展開はクラウドセッションを使っていて、チャットやCoworkに既存のプロジェクトがないアカウントからで、私たちのアカウントは既存のプロジェクトがあるためか、まだ出ていません。使うのは通常のClaude Codeと同じプランの上限で、並列に動かす分だけ早く減ります。利用クレジットを有効にしているアカウントでは、上限を超えた分がクレジットから消費されます。
順番が来たら、公式の手順どおり、指示を書いて、小さい仕事を1件だけ投げて、報告のされ方を見るところからです。その前にできる準備は1つあって、手元の設定ファイルに書いてあるルールのうち、リポジトリの中のCLAUDE.mdに移せるものを移しておくこと。スレッドが読むのはそちらだからです。次に見るのは、ローカル対応の時期と、既存のプロジェクトがいつ新しい形に置き換わるかです。