Claude Projects刷新｜1会話で並行実行する新機能【2026年9月】

「Claudeに仕事を5つ同時に頼めるようになった、という話は本当ですか」。9月18日以降、研修や個別指導の場で立て続けに聞かれた質問です。

結論から言うと、本当です。ただし「同時に頼める」よりも「頼んだあとの段取りを人がやらなくてよくなった」と言ったほうが正確で、しかも2026年9月20日時点では誰でも使えるわけではありません。ここを取り違えたまま社内に「Claudeが並列で動くらしい」と伝えると、使えない人が大半という状態で期待だけが先に走ります。

もうひとつ、法人として先に見ておくべき論点があります。スレッドは1本ずつが完全なClaude Codeのクラウドセッションなので、並行で走らせるほどプランの利用枠は早く減ります。これは公式が自分で書いている事実で、海外メディアの見出しにもなりました。

この記事では、Anthropicの公式ブログ・公式ドキュメント・国内報道を突き合わせて、新しいClaude Projectsで何が変わったのか、今日使えるのは誰か、利用枠と費用とデータの置き場をどう考えるかを、公式に書かれている範囲だけで整理します。自社で試した結果ではなく、公式の説明をもとにした整理であることを先に断っておきます。

新しいClaude Projectsとは｜フォルダから会話へ変わった中身

Anthropicが2026年9月17日に公開したブログの題名は「Projects redesigned: from folder to conversation」です。フォルダから会話へ、という言い方がそのまま変更の中身を表しています。

公式ブログが挙げている例は2つです。1つ目は、アプリのcheckoutのp75レイテンシを下げることを目標に設定し、各エンドポイントの計測・最適化の検証・プルリクエストの作成を並行スレッドで進めさせるもの。2つ目は、API・Web・モバイルの3つのリポジトリをつないで非推奨のv1エンドポイントを廃止する目標を置くと、Claudeがリポジトリごとに1スレッドを立て、呼び出し元の移行・テスト実行・プルリクエスト作成まで進めたうえで「どれを先にマージすべきか」を教える、というものです。

ここで変わったのは、Claudeの賢さそのものより人がやっていた段取りの担当が移ったことです。公式ブログは冒頭で、これまで複数セッションを回すには「作業を分け、引き継ぎをやりくりし、結果をつなぎ直す」必要があったと書いています。その3つがClaude側に移りました。

公式ドキュメントはこの違いを、プロジェクトなしで複数セッションを回す場合と対比して説明しています。プロジェクトがないと、どのセッションに何をやらせるかを自分で決め、同じ前提を毎回最初に書き直し、どれが終わってどれが返事待ちかを自分で見に行くことになる。プロジェクトがあると、依頼は1か所に投げればよく、前提は一度設定すれば全スレッドに届き、戻ってきたときにOverviewペインが「終わったもの・レビュー待ちのプルリクエスト・自分の返事を待っているスレッド」を並べて見せる、という整理です。

旧Projectsとの違い｜作業スペースから段取り役へ

混乱しやすいのは、Projectsという名前自体は2024年6月から存在していたことです。当時の公式アナウンス（Collaborate with Claude on Projects・2024年6月25日）では、Projectsは「チャットをまとめ、内部の知識をClaudeの出力の土台にする」機能として説明されていました。プロジェクトごとに200Kのコンテキストウィンドウを持ち、カスタム指示で口調や役割を指定できる、という位置づけです。

つまり旧Projectsは置き場で、新Projectsは段取り役です。両者の違いを整理すると次のようになります。

なお、いま旧Projectsを使っている人のProjectsがいきなり作り替えられるわけではありません。公式ブログは「Pro・Maxの既存のプロジェクトは今までどおり動き続け、chatとCoworkへ展開していく過程で順次アップグレードする」と書いています。部署別に旧Projectsを組んで運用している場合は、Claude Projectsの部署別テンプレートと活用法で整理した使い方がそのまま残る、と理解して問題ありません。

この刷新は単独の動きではありません。Anthropicは9月にClaudeのチャットとCoworkの画面を1つに統合しており、Claude Coworkの統合で何が変わるかと合わせて見ると、入口を減らして迷いどころを消す方向で製品をそろえていることが分かります。

提供状況とプラン｜2026年9月20日時点で使えるのは誰か

ここが法人にとって一番重要です。公式ブログと公式ドキュメントを突き合わせると、2026年9月20日時点の提供状況は次のとおりです。

公式ブログは、発表から1週間かけてPro・MaxのClaude Code利用者へ対象を広げ、その後にClaude全体とTeam・Enterpriseへ展開する、という順序を示しています。まだ使えないPro・Maxのユーザー向けには待機リストが案内されています。

法人にとっての実務的な意味は明確です。Team・EnterpriseでClaude Codeを全社導入している会社は、2026年9月20日時点ではこの機能を業務に組み込めません。待つ期間があるということです。逆に言えば、その期間に何を決めておくかで、使えるようになった日の立ち上がりが変わります。

サイドバーにProjectsが出てこない場合は、公式ドキュメントの言い方では「まだ順番が回ってきていない」だけです。設定をいじって出るものではないので、待機リストに登録して待つのが正解です。

仕組み｜スレッドとコーディネーターと共有メモリ

新しいProjectsは4つの部品でできています。公式ドキュメントの説明をそのまま並べます。

1. プロジェクトの会話（コーディネーター）

長く続く1本のセッションで、Claudeがまとめ役として動きます。送られてきたものを見て、何をスレッドにするかを決め、立てたスレッドを把握し続けます。ここで見ているのはスレッドが報告してきた内容であって、スレッドが踏んだ一手一手ではありません。公式ブログはこの役割について「chief of staff（参謀役）に説明するように伝えればよい」と表現しています。

2. スレッド（作業する側）

1本ずつが独立したクラウドセッションで、自分のコンテキストウィンドウを持ち、自分のブランチで1つの仕事をします。必要ならプルリクエストを開き、終わったら会話へ報告します。複数のスレッドが同じコードを触った場合は、通常のプルリクエストと同じくマージコンフリクトとして解消します。各スレッドはさらにサブエージェント・ループ・ワークフローに分割できるので、Claude Code Agent Teamsの並列実行で扱った仕組みがスレッドの内側でも使えます。

3. 共有メモリ

すべてのスレッドが読み書きする記憶です。公式ブログが挙げている例は「リリースが金曜に動いた」「なぜエクスポートが取り下げられたか」「課金サービスを触る前に誰に確認すべきか」。複雑なプロンプト設計をしなくても前提が引き継がれる、というのが公式の説明です。公式ドキュメントによると、スレッドは起動時に索引ファイルMEMORY.mdを読み、必要に応じて他のファイルを開きます。

加えて、Claudeはあなたの進め方も覚えます。どのくらいの頻度で確認を入れるか、どのくらいの頻度で新しいスレッドを立てるか、更新の粒度をどの程度にするか。これは後述する「確認の負担」の話に直結します。

4. ライブラリ

自分が追加したファイルと、Claudeが作った成果物がまとまって貯まる場所です。過去の資料を探しやすくなり、新しい作業が過去の成果の上に積めるようになります。

この4つに加えて、Overviewペインがスレッドの状態を「レビュー待ち／あなたの返事待ち／作業中／マージ待ち／待機中／完了」に分けて表示します。公式ドキュメントの表現では、1時間後や翌朝に戻ってきたときに、どれが終わってどれが自分を待っているかが一目で分かる、という設計です。

法人の業務でどう効くか｜コード以外の仕事も対象になる

「Claude Codeの話でしょう」と読み飛ばしてしまいそうですが、公式ドキュメントはコード以外の使い方も明示しています。

公式の記述では、リポジトリの代わりに書類をアップロードする使い方が挙げられています。例として出ているのは契約書のフォルダとサポートチケットのエクスポートで、「これらのチケットで一番多い連携ミス10個を見つけて」のような問いを、思いついたときに同じ会話へ投げ続ける形です。スレッドは調査結果をライブラリタブにファイルとして納品します。公式ブログの言い方では「with documents, it reads them and drafts（書類があれば、読んで下書きする）」です。

この記述の範囲で考えると、法人の業務で当てはまりそうなのは複数のパートに分かれた長い仕事です。公式ドキュメントが「1回の応答より長くかかり、パートが1つより多い仕事」と定義している類のものです。

• 提案書：現状分析・競合比較・導入計画・費用の各パートを別々に進め、決まった前提を共有メモリに置いて全体をそろえる
• 規程の改定：現行規程の洗い出し・改定案・関連規程との整合確認を分けて進め、「この条文は法務確認が要る」を記憶させる
• 調査のまとめ：対象ごとに調べさせ、ライブラリに貯まったファイルを後からまとめて読む

ただし現時点では注意が要ります。公式ドキュメントは、スレッドが触れるのはGitHubのリポジトリと、プロジェクトにアップロードしたファイル・フォルダ・Google Driveのフォルダだけで、自分のパソコンの中だけにあるファイルやツールには届かないと書いています。公式ブログの「What’s next」も、スレッドが手元のマシンやネットワークの内側で動くのは「近日中」としています。社内ファイルサーバーの資料をそのまま読ませる運用は、まだできません。

利用枠と費用｜並行で走らせるほど枠は早く減る

ここは経営側が最初に確認すべき点です。海外の技術メディアThe New Stackは9月17日の記事に「Anthropic’s new Claude Code feature could drain your plan before lunch（昼前にプランを使い切りかねない）」という見出しを付けました。煽りに見えますが、根拠はAnthropic自身の記述です。

公式ブログの「What’s next」に、こう書かれています。プロジェクトは複数のスレッドを同時に走らせることができ、その1本ずつが完全なClaude Codeセッションである。そのためプロジェクトは利用上限に早く達しうる、と。公式ドキュメントはさらに踏み込んで、Proプランでは特にプロジェクトを回した日は上限に早く届くと考えておくべきだ、と書いています。

枠を使う要素は3つです。

1. 動いているスレッド：1本ずつが完全なセッション。本数に固定の上限はなく、仕事に応じてClaudeが立てる。「2本まで」と頼んでも、それは好みの伝達であって強制される上限ではない。強制される上限は、全プロジェクト合計で1日200スレッドまで
2. 会話そのもの：Claudeがスレッドの報告を読み、次をどうするか決める分のトークンを使う
3. プルリクエストを見張っているスレッド：待機中のスレッドも、CIが落ちたりレビューコメントが付いたりすると起き上がって枠を使う

逆に、走っているスレッドも見張っているプルリクエストも新しいメッセージもないプロジェクトは、置いてあるだけでは枠を使いません。アーカイブしたプロジェクトも同じです。

費用の構造で押さえておきたいのは次の2点です。

• クラウドで動くからといって別建てのコンピュート料金はかかりません。公式ドキュメントは「クラウドVMに対する別個のコンピュート課金はない」と明記しています。かかるのは既存のプランの利用枠です
• 上限に当たったスレッドは止まるのではなく待ち、枠がリセットされると自動で再開します。つまり、走らせたまま離席すると次の利用枠の区間を勝手に使い始めます。プランの上限を超えて使われるのは、アカウントで利用クレジットを有効にしている場合だけです

公式ドキュメントが案内している減らし方も具体的です。新しいプロジェクトは既定で会話もスレッドもOpusで動き、スレッドは高い思考強度になっているので、ここを落とすのが一番効きます。加えて、しばらく放置したスレッドへ追加の依頼を投げると、そのスレッドの会話全体を読み直してから動くため、新しい仕事は新しいスレッドで始めたほうが安く済みます（キャッシュの保持時間はPro・Maxで1時間）。プラン別の枠の考え方はClaude Code法人導入ガイドの料金の節とあわせて見てください。

なお、The New Stackは同じ記事で、Maxプランの利用者から週次の上限が当初開示されていなかったとする集団訴訟が前週に提起されたとも報じています。訴訟の中身は係争中の主張であって確定した事実ではありませんが、利用枠の見通しに神経質になっている利用者が一定数いる、という文脈として押さえておくと社内説明がしやすくなります。

データの置き場と社内規程｜クラウドで動くことの意味

新しいProjectsのスレッドは、Anthropicが管理するクラウド環境で動きます。ここは情報システム部門が必ず確認する点なので、公式ドキュメントに書かれている制約を並べておきます。

• IPアドレス制限との衝突：クラウドセッションはAnthropic側のインフラからAPIを呼びます。組織でIPアローリストを有効にしていると、Anthropicがホストするクラウドセッションはすべて認証エラーで失敗します。使う場合はAnthropicのサポートに連絡して、Anthropicホストのサービスを除外する必要があります
• ゼロデータ保持（ZDR）との関係：ゼロデータ保持を有効にしている組織は、クラウドセッションの機能を使えません
• リポジトリの制約：github.com上のリポジトリが前提で、GitHub Enterprise Server・GitLab・Bitbucketは対象外です（GitHub Enterprise ServerはTeam・Enterpriseのクラウドセッションでは対応があります）。Claude GitHub Appのインストールも必要です
• 共有できない：プロジェクトは1人のユーザーに属します。プロジェクトやスレッドを他の人と共有することはできず、ベータの期間中は組織レベルの管理機能もありません

最後の1点は法人運用でとくに重い制約です。個人のアカウントに紐づく作業場が増えるということなので、そこに置いてよい資料の線引きを先に決めておかないと、あとから棚卸しが大変になります。社内規程の書き方はClaude Code法人導入のセキュリティと稟議テンプレの内容がそのまま流用できます。

もう1つ、運用上の落とし穴が公式ドキュメントに書かれています。スレッドのサンドボックスはターンの合間に一時停止し、続きのときに再開します。再開できなかった場合はまっさらなクローンから続けるため、コミットしていない変更が失われることがあります。長い作業では「途中でもコミットしてプッシュして」と伝えておくように、と公式が案内しています。

始め方の手順｜最初の1プロジェクトが動くまで

使えるようになったあとの手順は、公式ドキュメントに沿うと次の流れです。

1. 前提を確認する：Pro・Maxであること、サイドバーにProjectsが出ていること。コードを扱うならgithub.comのリポジトリにClaude GitHub Appがインストールされ、自分のGitHubアカウントにプッシュ権限があること
2. プロジェクトを作る：claude.ai/codeまたはデスクトップアプリのCodeタブでProjects → New project。必須は名前だけで、目標（1行）と対象（リポジトリ・ファイル・Google Driveフォルダ）は後から足せます
3. プロジェクト指示を書く：新しいスレッドが必ず最初に受け取る決まりごと。上限は16,000文字です
4. 小さい仕事を1つ投げる：終わったらスレッドを開いて、どう報告してくるか・ブランチで何をしたかを確認する
5. モデルと思考強度を見直す：Project settings → Generalで、スレッド側と会話側それぞれに設定します

ここからは、会話にそのまま打ち込んで使える指示文です。いずれも公式ドキュメントが「こう伝えられる」として挙げている操作に沿っています。Claudeはこうした好みを自分でプロジェクトメモリに保存し、後のスレッドでも守ります。ただし公式が但し書きしているとおり、これは強制される設定ではなく、Claudeが守ろうとする指示です。必ず効かせたいものはプロジェクト指示に書きます。

指示文1：プロジェクト指示の雛形（Project settings → Memory → Project instructions に貼る）

このプロジェクトの目的は[目的を1行で]です。

- 作業は[リポジトリ名／資料のフォルダ名]で行い、[main]から分岐してスレッドごとに下書きのプルリクエストを1本開いてください。
- 終わったと判断する前に[確認コマンド／確認手順]を実行し、結果の要約を最後のメッセージに貼ってください。
- 必要なもの（リポジトリ・認証情報・API・コネクタ）に届かないときは、何が足りないかを最初のメッセージで具体的に書いて止まってください。代わりのもので済ませたり、仮の値で進めたりしないでください。
- [マージ／強制プッシュ／CI設定の変更]は、スレッド内で私に確認してから行ってください。

指示文2：勝手に始めさせない

スレッドを提案するだけにして、私のOKが出るまで開始しないでください。

指示文3：同時本数を抑える（利用枠の節約）

同時に走らせるスレッドは2本までにしてください。小さい質問はスレッドを立てずにここで答えてください。

指示文4：報告の粒度を決める

更新は短くしてください。何かが終わったときと、詰まって進めないときだけ報告してください。

指示文5：先に全体像だけ出させる

これらのリポジトリで問題になっている箇所を一覧にしてください。まだ何も直さないでください。

指示文6：止まっているスレッドをまとめて点検する

開いている全スレッドについて、何を頼んだか・何を前提にしたか・何に届かなかったか・いま何を待っているかを一覧にしてください。

指示文7：軽い仕事は安いモデルで

この作業は小さいモデルで進めてください。

どの指示文も、不足があれば先に質問してから作業を始めるよう一言添えておくと事故が減ります。仮定した点は「仮定」と明記させるのも同じ効果があります。

【要注意】よくある失敗パターンと回避策

失敗1：使えない人に向けて社内展開の号令をかける

❌ 「Claudeが並列で動くようになったので全員使ってください」

⭕ 「2026年9月20日時点ではPro・Maxの一部だけです。該当者は待機リストに登録、それ以外は現行の使い方を継続してください」

なぜ重要か：Team・Enterpriseは公式ドキュメントで未提供と明記されています。全社アカウントをTeam以上で契約している会社ほど「使えない」に当たります。社内告知の1行目に提供範囲を書かないと、問い合わせ対応で時間を失います。

失敗2：承認待ちをプロジェクトの会話で解除しようとする

❌ 会話に「進めていいよ」と書いて、スレッドが動き出すのを待つ

⭕ 止まっているスレッドを開いて、そのスレッドの中で承認する

なぜ重要か：公式ドキュメントは、承認のプロンプトはそのスレッドの中にあり、プロジェクトの会話で「進めて」と言ってもそのスレッドには届かない、と明記しています。これを知らないと「動いていない」と見えて、原因が分からないまま放置されます。

失敗3：走らせっぱなしで離席する

❌ 大量のスレッドを立てて、そのまま翌朝まで放置する

⭕ 同時本数を抑え、モデルと思考強度を下げ、プロジェクト単位の使用量を確認する習慣を作る

なぜ重要か：上限に当たったスレッドは待って自動で再開するので、離席中に次の利用枠の区間を消費します。新しいプロジェクトは既定で会話もスレッドもOpusの高い思考強度で動きます。ここを見直さないまま運用すると、想定より早く枠に当たります。

失敗4：並行本数を増やせば早く終わると考える

❌ とにかく多く立てて同時に走らせる

⭕ 終わりの形がはっきりした仕事から1本ずつ足し、報告が期待どおりに返るのを確認してから増やす

なぜ重要か：公式ドキュメントは、複数のスレッドがそろって間違った前提で戻ってきた場合、原因はたいてい個々のタスクではなくプロジェクトの設定にある1つの穴だ、と書いています。しかも本数が増えるほど、人が確認する対象も増えます。並行実行は確認の負担を減らす仕組みではありません。最初から全開にせず、報告の質を見てから広げるのが安全です。

Uravationならこう判断する｜5段階で進める

2026年9月20日時点では、法人の大半は「まだ使えない」側です。そこで待つのではなく、使える日までに決めておくことを進めます。順番はこうです。

段階1：待機リストに登録し、対象かどうかを確かめる

Pro・Maxを使っているメンバーのサイドバーにProjectsが出ているかを確認します。出ていなければ順番が回っていないだけなので、待機リストに登録します。Team・Enterprise契約なら、この時点では対象外と判断して次へ進みます。

段階2：いまのProjectsを棚卸しする

旧Projectsを部署別に作っている場合、そのまま残すもの・統合するもの・捨てるものを分けます。公式ブログはchatとCoworkへの展開に合わせて既存のプロジェクトを順次アップグレードすると書いているので、整理は早いほど楽です。

段階3：小さな目標で1プロジェクトだけ試す

最初の1本は、終わりの形がはっきりした仕事を選びます。公式が挙げている例で言えば「この契約書のフォルダから、よくある不利な条項を洗い出す」のような、成果がファイルで返ってくる仕事です。いきなり基幹の開発に入れません。

段階4：確認の頻度と報告の粒度を決める

先ほどの指示文2から4を使って、始める前の承認・同時本数・報告の粒度を先に決めます。ここを決めずに始めると、通知の量に耐えられずプロジェクトごと放置されます。Claudeは進め方を覚えるので、最初に決めたことがそのまま運用の型になります。

段階5：社内規程に置ける資料の線を書く

プロジェクトは1人のユーザーに属し、ベータの間は組織レベルの管理機能がありません。何をアップロードしてよいか、どのリポジトリをつないでよいか、IPアローリストやゼロデータ保持の設定と衝突しないかを先に書いておきます。使えるようになってから考えると、すでに置かれてしまっているのが実情です。

Claude Codeそのものの導入が済んでいない場合は、先にClaude Code Webの使い方でクラウドセッションに慣れておくと、Projectsが来たときの立ち上がりが早くなります。スレッドの実体はこのクラウドセッションだからです。

よくある質問

Claude Projectsは無料で使えますか

新しいProjectsは2026年9月20日時点でPro・Maxのパブリックベータです。無料プランは対象に含まれていません。なお、プロジェクトの利用は既存プランの利用枠を消費する形で、クラウドVMに対する別建てのコンピュート料金はかかりません。

Team・Enterpriseではいつ使えるようになりますか

公式ブログは「Pro・MaxのClaude Code利用者へ広げたあとに、Claude全体とTeam・Enterpriseへ展開する」と順序だけを示しており、2026年9月20日時点で具体的な時期は公表されていません。

いま使っているProjectsは消えますか

消えません。公式ブログは「Pro・Maxの既存のプロジェクトは今までどおり動き続ける」と明記しており、chatとCoworkへ展開していく過程で順次アップグレードするとしています。

エンジニアでなくても使えますか

公式ドキュメントは、リポジトリを持たないプロジェクトも作れると書いています。契約書のフォルダやサポートチケットのエクスポートをアップロードし、スレッドが調査結果をライブラリタブにファイルとして納品する使い方が例として挙げられています。ただし使える場所はclaude.ai/code・デスクトップアプリのCodeタブ・Claudeモバイルアプリで、入口がClaude Code側である点は変わりません。

社内のファイルサーバーの資料を読ませられますか

2026年9月20日時点ではできません。公式ドキュメントは、スレッドが扱えるのはGitHubのリポジトリと、プロジェクトにアップロードしたファイル・フォルダ・Google Driveのフォルダだけだと書いています。手元のマシンやネットワークの内側で動くことについては、公式ブログが「近日中」としています。

まとめ：今日から始める3つのアクション

1. 今日やること：自社のプランを確認し、Pro・Maxのメンバーのサイドバーに Projects が出ているかを見る。出ていなければ待機リストに登録する
2. 今週中：旧Projectsの棚卸しをして、残すもの・統合するもの・捨てるものを分ける。あわせて「置いてよい資料」の線引きを起案する
3. 今月中：使えるメンバーが1人でもいれば、終わりの形がはっきりした仕事で1プロジェクトだけ試し、確認の頻度と報告の粒度を決めてから範囲を広げる

刷新の本質は「Claudeが速くなった」ではなく「段取りの担当が移った」ことです。段取りを任せるなら、任せ方の決めごとを先に持っているほうが強い。使えるようになるまでの期間は、その決めごとを作る時間として使えます。

参考・出典

• Projects redesigned: from folder to conversation — Anthropic 公式ブログ（2026年9月17日・参照日: 2026-09-20）
• Projects — Claude Code Docs — Anthropic 公式ドキュメント（参照日: 2026-09-20）
• Claude Code on the web（cloud sessions） — Anthropic 公式ドキュメント（参照日: 2026-09-20）
• Using Claude Code with your Pro or Max plan — Anthropic 公式ヘルプ（参照日: 2026-09-20）
• Collaborate with Claude on Projects — Anthropic 公式（2024年6月25日・旧Projectsの発表・参照日: 2026-09-20）
• Anthropic、Claudeの「Projects」を刷新 — gihyo.jp（2026年9月18日・参照日: 2026-09-20）
• Anthropic’s new Claude Code feature could drain your plan before lunch — The New Stack（2026年9月17日・参照日: 2026-09-20）

著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。
100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』『Claude仕事術』（SBクリエイティブ・シリーズ累計約6万部）。
SBクリエイティブ「ビジネス+IT」ほかで生成AI連載を執筆（NewsPicks最大1,125ピックス）。

ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。