Claude Projects が「フォルダ」から「会話」へ再設計。Claude が並列スレッドを統括し、各スレッドは独立した Claude Code クラウドセッションになる
Anthropic が 2026-09-17、Claude Projects を再設計した。従来は関連する会話とファイルをまとめるフォルダだったが、新しい Projects では会話そのものが作業の起点になる。依頼を書くと Claude が要求を分解し、作業を委譲し、並列スレッドを調整し、出力をレビューし、最終成果物へ組み立てる。各スレッドは独立した Claude Code のクラウドセッションで、それぞれ自分のブランチとリポジトリのコピーを持つ。スレッド内でさらにサブエージェント・ループ・ワークフローを動かせる。ベータ提供で、初期対象は既存 project を持たず Claude Code のクラウドセッションを使う一部の Pro / Max 加入者。1週間かけて Pro / Max の Claude Code ユーザーへ拡大し、その後 Team / Enterprise の chat と Cowork へ展開する。既存の project は Pro / Max では従来どおり動作する。コーディネーターとワーカーでモデルと effort level を個別に選べ、project 単位の使用量モニタリングが付く。並列スレッドは使用量上限の消費を早めると公式が明記している。
ニュース原文を読む ↗要約
Anthropic は 2026-09-17、Claude Projects を再設計したと発表しました。公式のタイトルは “Projects redesigned: from folder to conversation” で、変化の方向が題名にそのまま書かれています。
これまでの Projects は、**関連する会話とファイルを1か所にまとめておく「フォルダ」**でした。ユーザーが整理し、必要なときに開き、その中で会話する。主体はユーザー側にありました。
新しい Projects では、会話そのものが作業の起点になります。 ユーザーが依頼を書くと、Claude が要求を分解し(scopes the request)、作業を委譲し(delegates the work)、並列スレッドを調整し(coordinates parallel threads)、出力をレビューし(reviews the outputs)、最終成果物へ組み立てる(assembles the finished result)——この5段階が公式の説明です。
注目すべきは、スレッドの実体です。 各スレッドは独立した Claude Code のクラウドセッションであり、それぞれが自分のブランチとリポジトリのコピーを持ちます。コーディネーター側が作業配分を決め、スレッド側が実行します。さらにスレッドの中でサブエージェント・ループ・ワークフローを動かせるため、階層は2段では止まりません。
つまりこれは、UI の改善ではなく実行モデルの変更です。 1つの会話の裏側で、複数の分離された作業環境が同時に動き、それぞれが独立した変更を作り、Claude がそれらを突き合わせて1つの成果物にします。
提供はベータです。初期対象は、既存の project を持たず、Claude Code のクラウドセッションを使っている一部の Claude Pro / Max 加入者に限られます。公式は「今週のうちに Pro / Max の Claude Code ユーザーへ拡大」し、その後に Team / Enterprise の chat と Cowork へ展開するとしています。
既存の project は Pro / Max では従来どおり動作します。 「chat と Cowork へロールアウトが広がるタイミングでアップグレードする」と明記されており、ユーザー側が今すぐ移行作業をする必要はありません。
制御項目として、コーディネーターのチャットとワーカースレッドで、モデルと effort level をそれぞれ選べます。project 単位の使用量モニタリングも提供されます。ローカル実行は現時点ではクラウドのみで、“coming very soon” とされています。
公式が使用量について明記している点は見落とせません。 「Projects は複数の並列スレッドを動かせ、各スレッドは完全な Claude Code セッションである。これは使用量上限の消費を早める」と書かれています。機能紹介の中に、コストの警告が組み込まれている形です。
何が変わったか
- Projects の位置づけが**「会話とファイルを入れるフォルダ」から「Claude が作業を分配・統合する場所」**へ変わった
- ユーザーの依頼に対し、Claude が 要求の分解 → 委譲 → 並列スレッドの調整 → 出力レビュー → 成果物の組み立てまでを担う
- 各スレッドは独立した Claude Code のクラウドセッションで、専用のブランチとリポジトリのコピーを持つ
- スレッド内でサブエージェント・ループ・ワークフローを動かせる
- コーディネーターとワーカーで、モデルと effort level を個別指定できる
- project 単位の使用量モニタリングが追加された
- 並列スレッドは使用量上限の消費を早めると公式が明記
- ローカル実行は未提供(現状クラウドのみ、“coming very soon”)
- 提供はベータ。初期対象は既存 project を持たない Pro / Max の Claude Code クラウドセッション利用者の一部
- 展開順は Pro / Max の Claude Code ユーザー(1週間かけて)→ Team / Enterprise の chat と Cowork
- 既存 project は Pro / Max では従来どおり動作し、展開に合わせてアップグレードされる
業務インパクト(一般企業向け)
最初に整理すべきは、レビュー対象が変わったことです。
従来は「Claude が出した成果物を人が見る」でした。新しい Projects では、Claude が複数スレッドの出力を自分でレビューし、統合したうえで人に渡します。 人が見るのは統合済みの結果です。
これは効率的ですが、中間の判断が見えなくなるということでもあります。あるスレッドの出力が捨てられた、2つのスレッドの結論が食い違って一方が採用された——こうした判断は、統合後の成果物からは読み取れません。「なぜこうなったか」を後から問われる業務では、この不可視性が問題になります。
対策は単純で、重要な依頼では、統合結果だけでなくスレッド構成と各スレッドの出力も確認する運用を決めておくことです。project 単位の使用量モニタリングがあるので、スレッドが何本立ったかは把握できます。
次に、コストの読みにくさです。 公式が「使用量上限の消費を早める」と明示しているのは親切ですが、どれだけ早まるかは依頼の内容次第で、事前には読めません。 同じ文面の依頼でも、Claude が3スレッドに分けるか8スレッドに分けるかで消費は数倍変わります。
Pro / Max の個人契約でこれを使うと、月半ばで上限に当たる事故が起きやすくなります。 導入初期は、「並列前提の依頼を出す会話」と「単発の会話」を意識的に分ける運用が要ります。project 単位のモニタリングは、この使い分けを検証するために使えます。
3つ目は、展開順に起因する社内の非同期です。 初期対象は「既存 project を持たず、Claude Code のクラウドセッションを使っている Pro / Max ユーザー」という、かなり限定された条件です。同じ Pro プランでも、project を1つでも作っていた人には来ません。
同じ社内で「新しい Projects の話をしている人」と「従来のフォルダとしての Projects を使っている人」が併存します。手順書やオンボーディング資料に「Projects にファイルを入れておく」と書いてある組織は、その記述が人によって意味が変わる状態になります。2026-09-16 の Cowork / chat 統合に続いて、Claude 側の段階展開が社内の共通認識を崩す例が2週続いた形です。
4つ目は、リポジトリの扱いです。 各スレッドが「自分のブランチとリポジトリのコピー」を持つということは、1つの依頼で複数のブランチが生えうるということです。ブランチ運用のルールがある組織では、誰がどのブランチを消すのかを先に決めておかないと、放置ブランチが増えます。
Team / Enterprise への展開は chat と Cowork 経由で後から来ます。 情シスとして今できるのは、Pro / Max を個人で使っている社員が先行して体験するという事実を把握しておくことです。管理者が有効化を判断する形ではありません。
副業・個人活用視点
この機能は、個人にとっては「1人で並列に働く」手段です。
副業やフリーランスで詰まるのは、たいてい同時に進められないことです。調査しながら実装はできず、実装しながら資料は作れない。新しい Projects は、その制約を外す方向の機能です。調査スレッド、実装スレッド、資料スレッドを Claude が並べて回し、結果を束ねます。
ただし、費用対効果の計算は先にやってください。 Pro / Max の使用量上限を早く消費するということは、「上限に当たったら止まる」までの時間が短くなるということです。納品直前に上限に当たるのが最悪のパターンなので、締切が近い案件では並列前提の依頼を避ける、という単純な運用で回避できます。
「Claude がレビューして統合したもの」を自分の名前で納品する点は、意識しておく価値があります。 統合の過程で捨てられた選択肢や、食い違いの解消方法は、成果物からは見えません。クライアントに「なぜこの方式にしたのか」と聞かれて答えられない状態は避けたいところです。重要な判断が絡む案件では、スレッド単位の出力も一度目を通しておくべきです。
受注形態としては、「並列で回せること」自体が単価の根拠になりにくい点も押さえておきます。クライアントから見れば成果物は同じです。短縮した時間を値引きではなく、検証の厚みや提案の幅に振り向けるほうが、単価を維持できます。
教える側の立場では、この再設計は教材として扱いやすい題材です。 「AI に仕事を任せる」という抽象的な話が、コーディネーターとワーカー、モデルと effort level の使い分け、使用量の消費という具体的な操作に落ちています。エージェント委譲の入門として、実物を触りながら説明できます。
関連リンク
- 公式: Projects redesigned: from folder to conversation
- 調査メモ:
docs/research/zenn-claude-release-basic/official-updates/2026-09-17T000000-claude-projects-redesigned.md