この記事の要点（2026年9月18日時点）
結論：2026年9月17日に刷新された Claude Projects は、「会話やファイルをまとめるフォルダ」から「コーディネーターが Claude Code のクラウドセッションを並列スレッドとして指揮する場」に変わりました。公式ブログ「Projects redesigned: from folder to conversation」（claude.com/blog、2026年9月17日）によれば、開発者はプロジェクトの会話に「何を終わらせたいか」を書き、Claude が要求のスコープ決め・委任・並列スレッドの調整・出力のレビュー・結果の組み立てを行います。
- 要点1：各スレッドは独自ブランチとリポジトリのコピーで動く Claude Code のクラウドセッションです。重なった変更は通常の PR と同じマージコンフリクトとして解決します。
- 要点2：提供は段階的です。初日はClaude Code のクラウドセッションを使っていて、web／デスクトップに既存 Projects を持たない一部の Pro・Maxにベータ提供。1 週間かけて同プランの Claude Code 利用者へ広げ、その後 Claude 全体と Team・Enterprise へ拡大するとされています。
- 要点3：複数スレッドはそれぞれフルの Claude Code セッションなので、使用量上限に早く達しうると公式が明記しています。プロジェクト単位の使用量確認と、コーディネーター／ワーカーごとのモデル・effort 選択が用意されています。
対象読者：ターミナルの Claude Code は日常的に使っていて、複数セッションの並列運用を自分で切り盛りしている開発者・テックリード。読み終えたらできること：コーディネーターに任せる範囲と自分で持つ範囲を決め、最初のプロジェクト指示文を書ける状態になります。
この記事は公式ブログと公式ドキュメント（Let Claude coordinate ongoing work with Projects）の記述だけを根拠に書いています。ベータは既存 Projects を持たない一部の Pro・Max 限定で、筆者の環境では実機検証ができていません。そのため手順スクリーンショットは載せず、「公式ブログによれば」「公式ドキュメントによれば」の形で書き分け、体験談や測定した数字は一切含めていません。用語も、公式が使う「updated projects」「Projects redesigned」に合わせ、「Claude Code Projects」のような固有名は使いません。
前提となるクラウドセッション自体の準備（GitHub 接続・cloud environment・権限モード）は、Claude Code web版の使い方｜クラウドセッション7手順に分けて書いています。Projects はその上に載る機能なので、未設定の方はそちらを先に済ませてください。
何が変わったか：フォルダ型から会話型へ
公式ブログの副題は「from folder to conversation」です。これまでの Projects は、会話と参照ファイルと指示文を 1 か所にまとめる「フォルダ」でした。刷新後は、プロジェクトそのものが1 本の長い会話になり、その会話の中で Claude がコーディネーターとして働きます。公式ドキュメントは「A project is one ongoing conversation where Claude coordinates a stream of related work for you」と定義しています。
| 観点 | 旧 Projects（フォルダ型） | 刷新 Projects（会話型） |
|---|---|---|
| 中心にあるもの | 会話とファイルの置き場 | コーディネーターが仕事を振り分ける 1 本の会話 |
| 作業の実行主体 | 各会話でユーザーが指示 | スレッド（Claude Code のクラウドセッション）が並列で実行 |
| コードとの関係 | 参照ファイルとして添付 | 各スレッドが独自ブランチとリポジトリのコピーで動き、PR を開く |
| 文脈の引き継ぎ | 指示文と添付ファイル | 共有メモリ・プロジェクト指示・ライブラリが積み上がる |
| 進捗の確認 | 各会話を開いて読む | Overview で全スレッドの状態を一覧、スマホからも確認 |
| 既存の Projects | — | Pro・Max の既存 Projects はそのまま動き、展開に合わせて順次アップグレード |
公式ブログが挙げている使い方の例は 2 つあります。1 つは「アプリのチェックアウトの p75 レイテンシを下げる」というゴールを設定し、各エンドポイントのプロファイル・最適化の検証・PR 作成を並列スレッドで進めさせる例。もう 1 つは API・web・モバイルの 3 リポジトリを接続し、「廃止予定の v1 エンドポイントを引退させる」ゴールのもとで、リポジトリごとにスレッドを立てて呼び出し元を移行し、テストを回し、PR を開き、どれを先にマージすべきかを Claude が教えてくれる例です。どちらも「複数リポジトリ・複数 PR・順序の判断」が絡む仕事で、1 セッションでは収まりにくい形です。
前日の統合発表との関係
1 日前の 2026年9月16日には、公式ブログ「Claude Cowork and chat are now one Claude」（claude.com/blog）で、Claude Cowork とチャットの統合が発表されています。Cowork で使っていたチャット・プロジェクト・アーティファクト・コネクタ・スキルはそのまま引き継がれ、Pro・Max から数週間かけて展開するとされています。Projects の刷新はこの流れの翌日に、Claude Code 側から先に出てきた形です。公式ブログは「Existing projects on Pro and Max plans keep working as they do today. We’ll upgrade them as the rollout expands to chat and Cowork」と書いており、チャット側・Cowork 側の Projects が置き換わるのは後段になります。
コーディネーターと並列スレッドの仕組み
公式ブログの見出しは「Threads do the work, Claude directs it」です。仕組みは 2 層に分かれます。
- プロジェクトの会話（コーディネーター）：ユーザーが送った依頼を受け取り、何をスレッドにするかを決め、起票したスレッドを追跡します。公式ドキュメントによれば、コーディネーターは「スレッドが報告してきた内容」を見るのであって、スレッドの一手一手を見ているわけではありません。
- スレッド（ワーカー）：1 本ずつが独立したクラウドセッションです。自分のコンテキストウィンドウを持ち、独自ブランチで 1 つの仕事を進め、必要なら PR を開き、終わったら会話に報告します。
公式ブログは、ブリーフの仕方を「chief of staff（参謀）に伝えるように」と表現しています。プロジェクトを始めるとゴールとリポジトリ（またはコンテキスト）を選び、Claude が「すぐ着手できる仕事」を提案してくる、というのが公式の説明です。cloud environment・コネクタ・プラグイン・指示文・モデルはプロジェクト側で設定できます。
各スレッドは「独自ブランチ＋リポのコピー」で動く
ここが Claude Code の事例メディアとして最も押さえたい点です。公式ブログは「Under the hood, each thread is a Claude Code cloud session working on its own branch and copy of the repo」と明記しています。コーディネーターは仕事の整理はしますが、複数スレッドが同じコードを触った場合の重なりは、通常の PR と同じマージコンフリクトとして解決すると書かれています。つまり、コンフリクトを消してくれる魔法ではなく、分割の設計が甘ければコンフリクトはそのまま自分に返ってきます。
さらに、各スレッドは委任された仕事をサブエージェント・ループ・ワークフローでさらに分割できるとされています。「コーディネーター → スレッド → サブエージェント」の 3 段構造だと理解しておくと、後述する使用量の話がつながります。サブエージェント側の並列の考え方は、Claude Codeサブエージェント並列開発入門で整理しています。
共有メモリ・作業スタイルの記憶・ライブラリ
公式ブログによれば、すべてのスレッドが共有メモリに書き込み、そこから読み込みます。例として挙がっているのは「リリースが金曜に動いたこと」「なぜエクスポート機能を落としたか」「billing サービスを触る前に誰に確認するか」の 3 つです。公式ドキュメントでは、この共有メモリはファイルとして保存され、各スレッドは開始時に索引ファイル MEMORY.md を読み、必要に応じて他のファイルを開く、と説明されています。
あわせて、Claude はユーザーの作業スタイルと連絡のスタイルも記憶します。公式ブログが挙げる調整項目は「どのくらいの頻度でチェックインするか」「どのくらいの頻度で新しいスレッドを立てるか」「各アップデートをどのくらい詳しくするか」の 3 つです。加えて、追加したファイルと Claude が生成した成果物を集めるライブラリが用意され、過去の仕事の上に新しい仕事を積めるようになっています。
公式ドキュメントは、共有メモリはリポジトリ内の CLAUDE.md とは別物だと念押ししています。各スレッドは clone した CLAUDE.md も開始時に読むので、「リポジトリについての指示は CLAUDE.md、プロジェクトについてのメモは共有メモリ」という住み分けになります。CLAUDE.md 側の設計はCLAUDE.md設計・運用ガイドにまとめています。
ベータ対象と提供時期
公式ブログの提供条件は次のとおりです。ここは日付とプランを混同しやすいので、原文の順序どおりに書きます。
| 段階 | 対象 | 公式の記述 |
|---|---|---|
| 初日（2026年9月17日） | Claude Code のクラウドセッションを使っていて、web／デスクトップに既存 Projects を持たない一部の Pro・Max | 「Starting today, updated projects are available in beta to select Claude Pro and Max subscribers who use cloud sessions in Claude Code and don’t have any existing projects on the web or desktop」 |
| その後 1 週間 | 同プランのより多くの Claude Code 利用者 | 「Over the coming week, we’ll expand access to more Claude Code users on those plans」 |
| さらに後 | Claude 全体、および Team・Enterprise | 「Updated projects across all of Claude and Team and Enterprise plans come after that」 |
Pro・Max でまだ使えない場合は、公式ブログ内のウェイトリストに登録できます。公式ドキュメント側は「Projects are in public beta on Pro and Max plans and rolling out gradually」とし、Team・Enterprise ではまだ利用できないこと、サイドバーに Projects が出なければ展開が届いていないことを明記しています。追加料金の記載は、ブログにもドキュメントにもありません。消費するのは既存プランの使用量上限です。
もう 1 点、ドキュメントの「Limitations」にはターミナル CLI からは使えないこと、Amazon Bedrock・Google Cloud の Agent Platform・Microsoft Foundry 経由では使えないことが書かれています。CLI の claude project コマンドは、ディレクトリ単位のローカル状態を管理する別物で、この Projects とは無関係だと注記されています。
Claude Code のクラウドセッションでどう使うか（想定例）
ここから先は、公式ブログと公式ドキュメントの仕様だけを使って組み立てた想定シナリオです。実在の導入事例ではなく、実測した数値も含みません。題材は「1 人の開発者が、機能追加を API・UI・テストの 3 スレッドに分けて Projects に任せ、自分は設計とマージ順を持つ」形にしました。
自分で持つもの、コーディネーターに任せるもの
公式ドキュメントは、プロジェクトがなければ「何をどのセッションに任せるかを決め、同じ背景説明を毎回繰り返し、どれが終わったかを見に行く」調整を自分でやることになる、と書いています。裏返せば、Projects が肩代わりするのはその調整部分です。想定例では次のように線を引きます。
| 自分で持つ | コーディネーターに任せる |
|---|---|
| ゴールと分割の判断（どの単位でスレッドにするか） | スレッドの起票と割り当て（新規か既存スレッドか） |
| 設計・マージ順の決定 | 進捗の追跡と報告（Overview・会話への報告） |
| PR の最終レビューとマージ操作 | CI 失敗・レビュー指摘への対応（auto-fix） |
| 上限とモデルの配分（Project settings） | 共有メモリの更新（決定・落とし穴の記録） |
公式ドキュメントによれば、スレッドがコードを変更するときの既定の振る舞いは「デフォルトブランチから新しいブランチを切る」「求められたとき、またはバグ修正のような具体的な変更では自分で PR を開く」「PR を開いた後は auto-fix を有効にして監視し、CI が落ちれば修正を push し、レビューコメントに対応し、チェックが通ったらスレッド内で報告する」の 3 つです。マージそのものは、スレッドのカードに出る Merge it ボタンなどでユーザーが指示する設計になっています。
コピペ用の指示 1：最初のプロジェクト指示文
公式ドキュメントは、プロジェクト指示文（Project settings > Memory > Project instructions、上限 16,000 文字）に「プロジェクトの目的」「どのリポジトリ・どのブランチ・PR の命名」「終わる前にどう自己確認するか」「足りないものがあるときどうするか」「何に自分の承認が要るか」を書くよう勧めています。公式の例文の構造を、想定例の題材に置き換えたものが次の指示です。
このプロジェクトは orders-service リポジトリに「注文の一括キャンセル」機能を追加するためのものです。
- main から分岐し、スレッドごとに draft PR を 1 本開いてください。
- 終わったと報告する前に `make test` と `make lint` を実行し、要約行を最終メッセージに貼ってください。
- リポジトリ・シークレット・API・コネクタなど届かないものがあれば、最初のメッセージで何が足りないかを書いて止まってください。代替・モック・推測はしないでください。
- マージ・force-push・CI 設定の変更は、スレッド内で私に確認してから行ってください。「届かないものがあれば止まる」の 1 行は、公式ドキュメントの例文にもある行です。後述の失敗パターンで触れるとおり、クラウドセッションはローカルのツールや社内ネットワークに届かないので、この行があるかどうかで「推測で進んだスレッド」の量が変わります。
コピペ用の指示 2：機能追加を 3 スレッドに分ける
公式ドキュメントによれば、1 つのメッセージに複数の無関係なタスクを書くと別々のスレッドになり、スレッドを起票する前に提案させることもできます。最初の 1 回は提案を挟むのが安全です。
「注文の一括キャンセル」機能を、次の 3 つのスレッドに分けて進めたいです。
まずスレッドを提案し、私の GO を待ってから開始してください。
1. API：POST /orders/bulk-cancel の追加。src/api/ 配下のみ変更。
2. UI：注文一覧に一括キャンセルのボタンとダイアログを追加。src/ui/ 配下のみ変更。
3. テスト：1 と 2 に対する結合テストを tests/ 配下に追加。実装は変更しない。
API の PR を先にマージし、その後に UI とテストをマージする順序を前提にしてください。「配下のみ変更」と書いているのは、公式ブログが「同じコードを触った重なりは通常の PR と同じマージコンフリクトになる」と明記しているためです。触るディレクトリを分けておけば、コンフリクトの発生面を最初から狭められます。
コピペ用の指示 3：共有メモリに運用ルールを残す
公式ドキュメントによれば、会話またはスレッドの中で「覚えて」「忘れて」と頼めば共有メモリに入り、後のスレッドがそれを読んで始まります。修正を指摘したときは、修正内容と一緒に記憶を頼むのが公式の勧めです。
次の 3 点をプロジェクトのメモリに記録し、今後のすべてのスレッドで守ってください。
- billing モジュール（src/billing/）に触る前に、必ずスレッド内で私に確認する。
- DB マイグレーションは 1 つの PR に 1 ファイルまで。
- リリースは毎週金曜。木曜以降に main へマージする PR は「hotfix」ラベルが付いたものだけ。1 つ目は公式ブログの例（billing サービスを触る前に誰に確認するか）を、1 人開発向けに言い換えたものです。公式ドキュメントは「こうした指示は Claude が守る指示であって強制される設定ではない」と注意しているので、絶対に越えさせたくない線は、後述の .claude/settings.json の権限ルールで別途止めます。
コピペ用の指示 4：上限に当たったときのモデルと effort の下げ方
公式ドキュメントによれば、新規プロジェクトはすべてのスレッドが Opus・高 effort、会話（コーディネーター）は Opus・低 effort で始まり、これが最もプランを速く消費する設定です。Project settings > General の Thread model／Thread effort、Coordinator model／Coordinator effort で変えられるほか、タスクの中で「このタスクは小さいモデルで」と頼むこともできます。
今日は使用量を抑えたいので、次の運用に切り替えてください。
- テストの追加やドキュメントの更新など、判断の少ないタスクは小さいモデルで実行する。
- 同時に走らせるスレッドは 2 本までにする。
- 私が「進捗を教えて」と言うまで、状況報告は各スレッドの完了時と、ブロックされた時だけにする。
この方針もメモリに記録してください。この指示は、公式ドキュメントの「Tune how Claude runs a project」に例示されている言い回し（Run at most two threads at a time／Only post when something finishes or is blocked／Do this task with a smaller model）を組み合わせたものです。ただし公式は、こうしたスレッド数の指定はハードキャップではないと明記しています。確実に制限したい場合は、Project settings 側でモデルと effort を下げるほうが効きます。
コピペ用の指示 5：マージコンフリクトの扱い
公式ドキュメントによれば、スレッドの PR に何か次の一手があるとき、会話内のカードに Resolve conflicts・Fix CI・Address comments・Merge it といったボタンが出ます。ボタンを押すと、その指示がユーザーからのメッセージとしてスレッドに送られます。ボタンを待たずに、自分の言葉でスレッドに送る場合は次の形になります。
API スレッドの PR を先にマージしました。
UI スレッドは main を取り込み直して、src/ui/ 以外の差分が混ざっていないことを確認したうえで、コンフリクトがあれば解消してください。
解消の判断に迷う箇所があれば、自分で決めずにスレッド内で私に聞いてください。注意点として、公式ドキュメントは「スレッドが待っている承認プロンプトはそのスレッドの中にあり、プロジェクトの会話で『進めて』と言ってもスレッドには届かない」と書いています。コンフリクト解消のような細かい指示は、会話ではなくスレッドを開いてスレッド側のメッセージ欄に送るのが確実です。
ローカル実行が来るまでの制約
公式ブログは「Threads run in the cloud today; running on your machine alongside your local tools and code and behind your network is coming very soon」と書いています。つまり 2026年9月18日時点では、スレッドはクラウド実行のみです。公式ドキュメントも「ローカルセッションはプロジェクトの一部になれない」「スレッドは自分のマシンにだけあるファイルやツールでは動かない」と明記しています。想定例で影響が出るのは次の 3 点です。
- 社内ネットワークの先にある API・プライベートレジストリ：スレッドの cloud environment の Network access と Add API credentials で許可する必要があります。設定できないものは、そのタスクをローカルセッションに残します。
- ローカルにしかない DB・エミュレータ・VPN 越しの API：公式ドキュメントは「ローカルセッションか agent view を使う」と案内しています。プロジェクトに載せる対象から外します。
- 手元の
~/.claude/の設定・スキル・MCP：スレッドは自分のマシンの Claude Code 設定を引き継ぎません。スキルやサブエージェントはリポジトリの.claude/skills/などにコミットし、MCP は claude.ai のコネクタとして接続し、CLI ツールは environment の setup script で入れる、というのが公式の案内です。
クラウドセッション側の Network access や環境変数の設定手順は、クラウドセッション7手順の第 3 手順で扱っています。
自前の worktree 並列との違い
「並列で走らせる」だけなら、Claude Code にはすでに手段があります。git worktree で作業コピーを分けて複数のローカルセッションを走らせる方法はClaude Code×git worktree並列開発ガイドで扱いました。公式ドキュメントも「Several Claude Code features let more than one session work at the same time, so running work in parallel is not by itself what a project is for」と書いています。違いは「誰が振り分けるか」「どこで動くか」「何を引き継ぐか」の 3 点です。
| 比較軸 | 自前の worktree 並列 | Projects のコーディネーター委任 |
|---|---|---|
| 動く場所 | 自分のマシン | クラウド（各スレッドがクラウドセッション） |
| 仕事の振り分け | 自分で決める（どの worktree で何をやるか） | コーディネーターが決める（新規スレッドか既存スレッドか） |
| 隔離のしかた | worktree ごとの作業コピー | スレッドごとの clone とブランチ。公式ドキュメントは「Threads don’t need them（worktree）」と明記 |
| 引き継ぐ文脈 | CLAUDE.md（＋自分の ~/.claude/ 設定） |
CLAUDE.md＋プロジェクト指示＋共有メモリ。ローカル設定は引き継がない |
| ローカルのツール・社内 API | そのまま使える | cloud environment で許可したものだけ。届かないものはローカルに残す |
| 進捗の見え方 | ターミナルを切り替えて見る（agent view はあるがコーディネーターはない） | Overview のスレッド一覧・Waiting on you・スマホ通知 |
| 使用量 | セッション数ぶん | スレッド数ぶん＋コーディネーターぶん＋PR 監視で起きる再稼働ぶん |
公式ドキュメントは、agent team（1 セッションがチームメイトを起こして 1 タスクで終わる）や agent view（複数ローカルセッションの一覧画面・コーディネーター無し）とも並べて整理しています。使い分けの目安は単純で、ローカルのツールが要る仕事、1 セッションで終わる仕事は worktree かローカルセッション、ゴールが 1 セッションを超えて仕事を生み続けるなら Projectsです。公式ドキュメントが「Fix the flaky login test」のような単発タスクはクラウドセッションを自分で立てるほうが向く、と書いているのもこの線引きです。並走するセッション間の連絡についてはクロスセッション・メッセージングにも整理があります。
使用量上限と運用
公式ブログの「What’s next」節は、この機能の注意点をはっきり書いています。「Projects can run several threads at once, and each one is a full Claude Code session. Because of this, projects can reach usage limits faster」。公式ドキュメントはさらに踏み込んで、Pro プランでは特に、プロジェクトを走らせた日は上限に早く到達すると想定すべきとしています。
何がプランを消費するか
公式ドキュメントによれば、プランを消費するのは次の 3 つです。
- 走っているスレッド：1 本ずつがフルのセッション。同時に走らせる本数に固定の上限はなく、Claude が仕事に応じて起票します。会話で頼んだ本数制限はあくまで希望で、強制される上限は「全プロジェクト合計で 1 日 200 本の新規スレッド」とされています。
- プロジェクトの会話：コーディネーターがスレッドの報告を読み、次の一手を決めるのにもトークンを使います。
- PR を監視しているスレッド：アイドル状態のスレッドも、CI が落ちたりレビューコメントが付いたりすると起きて再びプランを使います。止めたい場合はスレッド内で監視をやめるよう頼みます。
逆に、走っているスレッドも監視中の PR も新しいメッセージもないプロジェクトは、放置していてもプランを消費しません。アーカイブしたプロジェクトも同様です。
上限に当たったらどうなるか
公式ドキュメントによれば、スレッドや会話がプランの 5 時間上限・週間上限に達すると、自動で再試行を続け、上限がリセットされたら自分で続きを始めます。待っている間、スレッドには「Service is busy」と「Claude is still retrying and will continue automatically」が表示されます。次の使用量ウィンドウを使わせたくない場合は、スレッドで Stop を押すか、プロジェクトを一時停止（Pause）して全スレッドを止めます。例外は routine が起動したスレッドで、こちらは待たずに上限エラーで止まり、リセット後にメッセージを送って再開します。プランの上限自体は、公式ドキュメントで「usage credits」を有効にしていない限り超えないと書かれています。
下げ方の順番
Project settings の Usage でスレッド別・モデル別の消費を見たうえで、公式ドキュメントが挙げている手段は次の 4 つです。想定例では、上から順に試す運用にしています。
- スレッドのモデルを下げる：最大のモデルが要らない仕事は、スレッド用に小さいモデルを選ぶ。
- effort を下げる：スレッド・会話それぞれの effort を落とす。新規プロジェクトの既定はスレッド高 effort・会話低 effort。
- 同時スレッド数を絞る：会話で「同時に走らせるのは 2 本まで」と頼む。小さな質問はスレッドを立てずに会話内で答えてもらう。
- PR の監視を止める：マージ済み・放置中の PR を見ているスレッドに監視終了を頼む。
もう 1 つ、公式ドキュメントに固有の注意があります。Pro・Max のキャッシュ寿命（1 時間）より長くアイドルだったスレッドにフォローアップを送ると、そのスレッドの会話全体を読み直してから動き始めます。古い大きなスレッドを起こすより、新しい仕事は新しいスレッドで始めたほうが消費が少ない場合がある、というのが公式の説明です。1 セッションで上限に当たったときの一般的な対処はClaude Code v2.1.234｜上限後の自動再開にもまとめています。
【要注意】よくある失敗パターンと回避策
公式ブログと公式ドキュメントの記述から、最初の 1 週間で起きやすいつまずきを 4 つに絞りました。いずれも公式が明記している仕様に由来するもので、筆者が体験した事故ではありません。
失敗1：既存の Projects があるとベータ対象外
❌ 「Pro なのに Projects が出ない。不具合だと思って再インストールする」
⭕ 「web／デスクトップに既存 Projects があるか、クラウドセッションを使ったことがあるかを確認し、対象外ならウェイトリストに登録して待つ」
なぜこれが重要か：公式ブログの初日の対象は「クラウドセッションを使っていて、web／デスクトップに既存 Projects を持たない一部の Pro・Max」です。公式ドキュメントも「サイドバーに Projects が出なければ展開が届いていない」と書いています。設定や環境の問題ではなく、展開の順番の問題です。
失敗2：初日の既定設定のまま走らせて上限切れ
❌ 「機能追加を 6 スレッドに分けて一気に起票し、全部 Opus・高 effort で走らせる」
⭕ 「最初はスレッドを提案させて 1〜2 本だけ流し、Project settings の Usage を見てからモデルと effort を決める」
なぜこれが重要か：公式ドキュメントは、新規プロジェクトの既定が「全スレッド Opus・高 effort」で最もプランを速く消費すること、Pro では特に上限に早く到達しうることを明記しています。上限に当たっても自動で再試行はされますが、次のウィンドウを丸ごと消費する形になります。
失敗3：全部クラウドに置けると思って詰まる
❌ 「社内の DB に繋ぐ結合テストも、ローカルの MCP を使う作業も、まとめてプロジェクトに投げる」
⭕ 「ローカルにしか届かないものは worktree かローカルセッションに残し、クラウドに出す仕事は cloud environment の許可範囲で完結するものに限る」
なぜこれが重要か：公式ブログは「ローカルのツールとコードの横で、社内ネットワークの内側で動く」のは「coming very soon」であり、2026年9月18日時点ではクラウド実行のみだと書いています。公式ドキュメントも「スレッドは自分のマシンの Claude Code 設定を何も引き継がない」と明記しています。届かないものに当たったスレッドは、指示文に「止まって報告する」と書いていなければ推測やモックで進む恐れがあります。
失敗4：スタイル記憶が暴走して報告が減る（または増える）
❌ 「一度『報告は少なめで』と言ったら、ブロックされたスレッドの報告まで来なくなり、翌朝まで気づかない」
⭕ 「『完了時とブロック時は必ず報告』のように例外を明示し、Project settings > Memory で記憶された内容を読み返して直す」
なぜこれが重要か：公式ブログによれば、Claude はチェックインの頻度・スレッド起票の頻度・報告の詳しさを記憶します。公式ドキュメントは、こうした好みは Claude が自分でプロジェクトメモリに保存し、後のスレッドでも従うと書いています。便利な反面、一度覚えた省略の方針は後のスレッドにも効き続けるので、メモリのファイルを読み、編集・削除で直すのが確実です。
よくある質問
Claude Projects の刷新は誰が使えますか？
公式ブログによれば、2026年9月17日時点では、Claude Code のクラウドセッションを使っていて web／デスクトップに既存 Projects を持たない一部の Pro・Max がベータ対象です。1 週間かけて同プランの Claude Code 利用者へ広がり、その後 Claude 全体と Team・Enterprise に展開するとされています。公式ドキュメントは Team・Enterprise ではまだ使えないと明記しています。
Claude プロジェクトの使い方は、以前と何が違いますか？
以前は会話と参照ファイルと指示文をまとめるフォルダでした。刷新後はプロジェクト自体が 1 本の会話になり、Claude がコーディネーターとして依頼をスレッド（Claude Code のクラウドセッション）に振り分け、並列に進めて結果を組み立てます。既存の Projects は当面そのまま動きます。
並列スレッドが同じファイルを触ったらどうなりますか？
公式ブログによれば、各スレッドは独自ブランチとリポジトリのコピーで動き、重なりは通常の PR と同じマージコンフリクトとして解決します。自動で消えるわけではないので、触るディレクトリを分けてスレッドを切り、マージ順を自分で決めるのが安全です。
追加料金はかかりますか？
公式ブログにも公式ドキュメントにも追加料金の記載はありません。消費するのは既存プランの使用量上限で、公式は「各スレッドがフルの Claude Code セッションなので上限に早く達しうる」と注意しています。プロジェクト単位の使用量は Project settings の Usage で確認できます。
ローカルのツールや社内ネットワークは使えますか？
2026年9月18日時点では、スレッドはクラウド実行のみです。公式ブログは、ローカルのツール・コード・社内ネットワークの内側で動かす対応を「coming very soon」としています。社内 API やプライベートレジストリは cloud environment の Network access と API credentials で許可し、それでも届かないものはローカルセッションに残します。
まとめ：今日から始める3つのアクション
- 今日：自分のプランと「既存 Projects の有無」「クラウドセッションの利用歴」を確認し、対象外ならウェイトリストに登録する。前提のクラウドセッション設定は7手順で済ませておく。
- 使えるようになったら：プロジェクト指示文に「届かないものがあれば止まる」「マージ・force-push・CI 変更は確認してから」を入れ、スレッドを提案させてから 1〜2 本だけ流す。
- 1 週間回したら：Project settings の Usage を見て、判断の少ないスレッドのモデルと effort を下げる。共有メモリのファイルを読み返し、覚えさせた運用ルールを整える。
運営元 Uravation よりこの事例を自社の業務で試す場合のテーマ選定・評価・本番移行の確認項目を、無料のチェックリストにまとめています。 Claude Code業務自動化PoCチェックリストを受け取る（無料）
参考・出典
- Anthropic「Projects redesigned: from folder to conversation」（claude.com/blog、2026年9月17日） — 参照日: 2026-09-18
- Anthropic「Let Claude coordinate ongoing work with Projects」（Claude Code Docs） — 参照日: 2026-09-18
- Anthropic「Use Claude Code in the cloud」（Claude Code Docs） — 参照日: 2026-09-18
- Anthropic「Claude Cowork and chat are now one Claude」（claude.com/blog、2026年9月16日） — 参照日: 2026-09-18
要点の整理と次の一歩
- Projects の刷新は「フォルダ」から「コーディネーターがクラウドセッションを指揮する会話」への変更で、ベータは一部の Pro・Max から段階展開。
- 各スレッドは独自ブランチのクラウドセッション。分割の設計とマージ順は自分が持ち、起票・追跡・CI 対応・メモリ更新をコーディネーターに任せる。
- 使用量は早く減る。既定の Opus・高 effort のまま増やさず、Usage を見てモデル・effort・同時本数・PR 監視を順に下げる。
Claude Code のチーム導入で、リポジトリ境界・権限・レビュー経路の設計を一緒に整理したい場合は、お問い合わせフォームからご相談ください。
著者プロフィール
佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』『Claude仕事術』（SBクリエイティブ・シリーズ累計50,000部突破）。SBクリエイティブ「ビジネス+IT」ほかで生成AI連載を執筆。
