Claude Code Projectsの使い方｜5手順と4つの注意点

結論: 刷新版のClaude Code Projectsは、ファイルや会話をまとめるだけの入れ物ではありません。1つのproject conversationがcoordinatorとなり、仕事を複数のthreadsへ分け、進捗、確認待ち、Pull Requestをまとめて追う仕組みです。1回のsessionで終わらない開発や複数リポジトリの移行に向きます。

ただし、2026年10月13日時点ではPro／Maxへの段階提供中です。複数threadsは利用枠を早く消費し、beta中のprojectは1人専用。Team／Enterpriseの共同管理機能としては、まだ使えません。

この記事の要点:

• 新Projectsは、coordinator、threads、Overview、memory、Libraryで長期作業を束ねます
• 作成は、対象確認、goalとcontext、instructions、実行設定、小さな初回taskの5手順です
• 通常のthreadはcloudで動きますが、Remote Control経由で自分のPCへlocal threadを置く方法も追加されました
• 共有不可、利用枠、複数リポジトリの権限設定、未commit変更の消失に注意が必要です

対象読者: Claude Codeで複数sessionsを並行利用しており、task分解、進捗確認、Pull Requestの追跡を1か所へ集めたい開発者。継続的な移行や改修をAIへ任せる前に、利用条件と止め方を確認したい方。

この記事で持ち帰れるもの: Projectsに向く仕事の判定、最初のprojectを作る5手順、coordinatorとthreadへの指示の分け方、利用枠と権限の確認表です。

根拠は、2026年10月13日に確認したAnthropicの発表記事とClaude Code公式ドキュメントです。本稿が整理するのは公式画面と仕様であり、betaの実機検証と成果品質の比較は対象外としました。

Projectsを使う前に、目標、共通指示、環境、レビューの境界を決めます。ここまで揃えば、coordinatorへ任せる範囲が見える図です。

最初から多数のthreadsを動かす必要はありません。共通instructionsを設定し、小さな実taskを1件だけ渡し、結果を読んでから並列数を増やす。これが最も確認しやすい始め方です。

新Projectsは複数sessionを管理する会話

Anthropicは2026年9月17日、Projectsを「folderからconversationへ」再設計したと発表しました。利用者がgoalを伝えると、Claudeがscopeを整理し、threadsへ仕事を委ね、進捗と結果をproject conversationへ戻します。

旧Projectsとの違い

Claudeには同名の従来版Projectsがあります。旧版は、chat histories、project knowledge、project instructionsをまとめるワークスペースです。刷新版は、その考え方を残しつつ、Claude Code sessionsを動かすcoordinatorを加えました。

旧版の共有やRAGの説明を、刷新版の権限や上限へそのまま当てはめないでください。公式Help Centerでも、既存Projectsは当面そのまま動き、刷新版はClaude Codeから段階展開すると区別しています。

coordinatorとthreadsの構造

Project conversationは、利用者の依頼を受ける窓口です。簡単な質問にはその場で答え、新しい作業は既存threadか新しいthreadへ渡します。無関係な作業をまとめて送ると、複数threadsへ分かれる仕組みです。

各threadは独立したcontext windowを持つClaude Code sessionです。Cloud threadはrepositoryのcopyと専用branchで作業し、必要に応じてPull Requestを作成。内部でsubagents、loops、workflowsを使う場合もあります。

coordinatorが束ねるのは各threadからの報告です。全操作を常時把握する構造ではありません。軌道修正は対象threadを開いて直接行います。

単発のcloud sessionとの違いは、誰が分解と追跡を担うかです。個別sessionでは、利用者がtaskを切り、背景を渡して完了まで追います。Project側でその役を担うのがClaudeです。Threadsへ同じinstructionsを渡し、Overviewへ状態を集約します。Cloudの実行環境自体を知りたい方は、Codex Cloudの使い方も比較材料になります。

向く仕事4選と別の機能が合う仕事

Projectsは、parallel executionそのものより、同じgoalの下で作業が続く場合に価値が出ます。作るか迷ったら、仕事の長さ、依存する場所、taskの発生頻度で判断してください。

Projectsに向く4つの仕事

「複数threadsを動かせるから使う」のでは足りません。goalが一度で終わらず、後からtask、修正、判断が増えるかを見ます。

別の実行方法が合う4つの仕事

単発のbug修正はcloud session、すべてのtaskがlocal databaseやdevice emulatorを必要とするならlocal sessionやagent viewが適任です。毎週1回の定型処理だけならroutine、複数人が同じAI作業へ指示する用途はTeam／EnterpriseのClaude Tagなどを検討します。

Projectsが合うのは、goalが続き、taskと判断が積み上がる仕事です。単発作業や全面的なlocal依存には、より小さい実行単位が合います。

従来の複数sessionsを自分で起動し、session間messageを組む方法とは役割が違います。その構成はClaude Codeのsession間messagingで確認できます。

始める前に確認する3条件

New projectを開く前に、account、GitHub、実行環境を分けて確認します。画面が見えない場合、操作手順より提供対象の確認が先です。

Pro／MaxとProjects表示

刷新版はpublic betaで、Pro／Maxへ段階展開中です。提供済みaccountでは、claude.ai/codeのsidebar、desktop appのCode tab、Claude mobile appにProjectsが現れます。

表示がなければ未提供の可能性があります。Team／Enterpriseへの提供時期は未公表。Pro／Maxでも全accountへ届いたとは限らないため、公式のwaitlistとsidebarを確認してください。

Projectsの作成・管理に使うのは、browser、desktop app、mobile appの画面です。Terminal CLI、VS Code extension、JetBrains plugin、Bedrock、Google Cloud Agent Platform、Microsoft Foundryは対象に含まれません。

GitHub Appとpush権限

Code repositoryを扱うには、次の3条件が必要です。

1. 対象がgithub.com上にあること
2. Claudeへ接続したGitHub accountがpush権限を持つこと
3. 対象repositoryへClaude GitHub Appをinstall済みであること

/web-setupで渡したtokenだけでは、Projectのcloud threadsに不足します。GitHub Enterprise Server、GitLab、Bitbucketは、現行Docsの対象外です。

cloud environmentとlocal依存

Cloud threadsのnetwork access、environment variables、network secrets、setup script、installed toolsはcloud environmentで決まります。PC側の.env、MCP server、login状態は、自動移行の対象外です。

内部API、private package registry、特定toolが必要なら、最初のthreadを動かす前に到達条件を確認してください。local database、device emulator、VPN内APIだけが必要なtaskは、後述するRemote Control経由のlocal threadへ分けると実行場所が明確です。

最初のProjectを作る5手順

最初に確かめるのは、共通指示が1つのthreadへ届き、止まるべき場所で止まるかです。最大速度の確認は後へ回します。

初回は1件のtaskで、指示、環境、検証、レビュー経路を確認します。多数のthreadsへ広げるのは合格後です。

1. New projectの作成

claude.ai/codeまたはdesktop appのCode tabで、Projects、New projectを選びます。Nameだけでも作成できますが、長く続く1つのwork streamとして命名してください。

既存cloud sessionのmenuにContinue as projectがあれば、そのsessionから新しいprojectを作れます。Move to projectは、既存projectへworkを引き継ぐ操作です。元sessionは残るため、同時進行が不要なら元のrunning turnを止めます。Local sessionから直接変換する操作はありません。

2. goalとcontextの絞り込み

Goalには、継続して達成したい状態を1行で書きます。「payment APIのp95 latencyを200ms未満に保つ」が一例です。Contextへ加えるのは、頻繁に使うrepositories、files、folders、Google Drive foldersです。

最初からすべてのrepositoriesを入れる必要はありません。毎回使う1〜2件だけをprojectへ追加し、残りはtaskごとに指定する方針なら、cloneとcontextを抑えられます。

3. project instructionsの記入

Project settingsのMemory、Project instructionsに、全threadsへ渡す共通briefを置きます。含める内容は次の5点です。

• projectの目的
• 開始branchとPull Request名
• 完了前に実行する検証command
• 必要な情報や接続先が不足した場合の停止条件
• 事前承認が必要な操作

このprojectはpayment APIのp95 latencyを200ms未満に保つためのものです。
- mainからbranchを作り、threadごとにdraft Pull Requestを1件開く
- 完了前にmake testとmake lintを実行し、結果の要点を報告する
- repository、secret、API、connectorへ到達できない場合は推測せず停止する
- merge、force-push、CI設定変更は、対象threadで私の承認を待つ

Repository固有のbuild commandや規約は、そのrepositoryのCLAUDE.mdへ置いてください。Project instructionsはproject全体の運用条件、CLAUDE.mdはcodebase固有の規則。この分担なら、片方を直したときの影響範囲が明確です。設計例はClaude.mdの書き方ガイドにまとめました。

4. modelとthread方針の調整

現行Docsでは、新規projectの既定はcoordinatorとthreadsの両方がOpusです。Thread effortはhigh、Coordinator effortはlow。大きなmodelを複数threadsで動かすため、そのままでは利用枠を早く使います。

Project settingsのGeneralで、Coordinator model／effortとThread model／effortを確認してください。さらにconversationへ、次のような運用条件を渡します。

新しいthreadは開始前に候補を提示してください。
当面は同時に2件までを希望します。
小さな確認はconversation内で答え、code変更だけthreadへ渡してください。
Pull Requestを開く前にplanを報告してください。

指定した同時数はpreferenceとして扱われるため、開始後もOverviewで実際のthreadsを確認します。

5. 小さな実taskを1件だけ依頼

初回には、書き込み範囲が狭く、成否を人が判断できるtaskを選びます。調査だけでも構いません。

payment API repositoryを読み、p95 latencyに影響しそうなendpointを3件まで挙げてください。
変更は行わず、根拠にしたfile、計測に必要なcommand、不足している情報を報告してください。
1つのthreadで進め、推測が必要になった時点で止めてください。

完了後に照合するのは、thread transcript、変更file、実行command、test結果、Pull Requestの5点です。1件目で誤ったassumptionが見つかった場合は、次のtaskを増やす前にinstructionsかenvironmentを修正してください。

coordinatorとthreadsの途中制御

Projectを作った後も、Claudeへ任せきりにはしません。Project conversationと個別threadでは、指示の届き方が違います。

conversationでの全体方針変更

新しいtask、並列数、更新頻度、Pull Requestを開く時期はconversationへ送ります。割当先は、Claudeが選んだ既存threadまたは新規threadです。

「すべてのopen threadsについて、依頼内容、assumption、到達できなかったもの、確認待ちを一覧にして」と頼めば、停滞箇所をまとめられます。Project全体の停止には、Project settingsのPauseを使ってください。対象はrunning threads、conversation、routinesです。

Overviewと個別threadによる詳細確認

Overviewでは、threadsを次の状態へ分類します。

個別threadで扱えるのは、stepごとのtranscript確認、直接message、permission promptへの回答、Stopによる中断です。Coordinatorが受け取るのはthreadからの報告で、全tool callを常に読んでいるわけではありません。重要な変更はthread側でも確認してください。

memory・Library・local threadの使い分け

Projectsでは、継続contextを1か所へ詰め込みません。Standing rules、learned decisions、files、repository rulesを分けて持ちます。

instructions、memory、Libraryの分離

Cloud threadは開始時にmemoryのindexであるMEMORY.mdを読み、必要に応じて他filesを開きます。進行中threadへ変更したinstructionsが、そのthreadへ遡って届くとは限りません。誤りを直した後の確認先は、新しいthreadです。

Libraryの上限は、1回100 files、合計2GB、単一file 480MBです。New project dialogでは30MB超がskipされるため、大きいfileは作成後にLibraryへ加えてください。Uploadはcopyで、PC側の更新とは自動同期しません。

PCだけにあるもののlocal threadへの受け渡し

現行Docsでは、Project conversationのWork locallyから、自分のPCへlocal threadを起動できます。前提はClaude Code v2.1.280以降です。Desktop appからfolderを許可するか、そのfolderで次のcommandを実行してください。

claude remote-control

Git repositoryでの同時作業には、--spawn worktreeまたは画面のWorktree設定を使います。同じfolderへ2 threadsを置くと、変更を上書きする恐れがあるためです。

Local threadが使うのは、PC上のfiles、tools、MCP servers、hooks、permission rulesとproject instructionsです。Project memory filesは自動loadの対象外。PCのsleep、desktop appの終了、claude remote-controlの終了のいずれかで処理が止まります。

利用枠を守る3つの確認

Projectsに別の実行料金が付くという公式案内はありません。利用量はClaude Codeと同じplan limitsへ入り、複数threadsがfull sessionsとして動くため、単独sessionより早く上限へ達しやすい設計です。

何が利用枠を使うか

• Running threads。各threadが独立したfull sessionです
• Coordinator conversation。thread reportsを読み、次の動きを決めます
• Pull Requestをwatchするthread。CI failureやreview commentで再稼働します

全Projectsを通じた強制上限は、1日200 new threadsです。固定の同時実行上限は公開されておらず、「2件まで」と伝えてもpreferenceとして扱われます。

Plan limitへ達したthreadは待機し、reset後に自動で再開します。放置したworkが次のusage windowを使う場合があるため、継続不要ならthreadをStopし、projectをPauseまたはArchiveしてください。Usage creditsを有効にしているaccountでは、plan内の枠を超えた分にも注意が必要です。

3つの節約策

1. Thread modelとeffortをtask難度へ調整
2. 小さな質問はthreadを作らずconversation内で回答
3. 長くidleだったthreadを再利用せず、新しいworkはfresh threadへ分離

Project settingsのUsageでは、thread、model、coordinator conversation別のtoken usageを確認できます。より一般的なcontext削減は、Claude Codeトークン節約術も参照してください。

【要注意】導入前に見る4つの制約

Cloud sessionsはisolated VMで動き、network accessは既定で制限されます。Git credentialsやnetwork secretsをsandbox外からproxyで付与する仕組みもあります。それでも、接続先、repository権限、実行command、成果物のreviewは別の確認です。

特に複数repositoriesをAnthropic-hosted environmentで使う場合、各repositoryの.claude/settings.jsonにあるpermission rules、hooks、envは適用されません。CLAUDE.mdとskillsは読み込まれますが、同じ設定fileにある制御を一括で継承する構造ではない点に注意してください。

よくある質問

Q. 新Projectsは無料planで使えますか

2026年10月13日時点の刷新版は、Pro／Maxへ段階提供中のbetaです。旧Claude.ai ProjectsにはFreeを含む別の提供条件があるため、Help Centerの一般的な「Projectsは全利用者向け」という説明と混同しないでください。

Q. Team／Enterpriseでprojectを共有できますか

刷新版betaは1 user専用で、projectやthreadsを他userへ共有できません。Organization-level controlsも未提供です。Team／Enterpriseへの展開時期は公表されていません。

Q. terminalでProjectsを操作できますか

Projectの作成・管理画面は、claude.ai/code、desktop app、mobile appの3か所です。Terminal CLIはProjects画面の対象外。Remote Controlを使えば、terminalで接続したfolderへProjectからlocal threadを置けます。

Q. coordinatorはPull Requestを自動でmergeしますか

自動mergeを前提にしないでください。ThreadsはPull Requestを開き、CIやreview commentsへ対応できますが、merge conflictは通常のGit運用と同様に残ります。Instructionsへ「merge前に承認を待つ」と書き、review後にmergeします。

Q. Claude Code Modsやsubagentsとの違いは何ですか

Projectsは複数sessionsを編成し、継続するgoalを追う統括レイヤーです。Subagentは1 session内の補助役。ModsはClaude Codeのprompt、tools、permissions、UIなどの動作を拡張します。Modsの権限と安全な試し方はClaude Code Mods入門で解説しています。

参考・出典

• Projects redesigned: from folder to conversation — Claude by Anthropic、2026年9月17日公開、2026年10月13日参照
• Let Claude coordinate ongoing work with Projects — Claude Code Docs、2026年10月13日参照
• What are projects? — Claude Help Center、2026年10月13日参照
• Use Claude Code in the cloud — Claude Code Docs、2026年10月13日参照
• Security — Claude Code Docs、2026年10月13日参照
• Data usage — Claude Code Docs、2026年10月13日参照
• Remote Control — Claude Code Docs、2026年10月13日参照