Claude Code 使い方ガイド：Projectsで並列開発を管理する

Claude Code Projectsは、1つの会話に継続的な開発作業を渡し、そのコーディネーターから個々のタスクごとに独立したクラウドスレッドを立ち上げ、進捗を追える機能です。Claude Code 使い方ガイドで押さえたいのは、チャット画面が増えることではありません。リポジトリの前提を何度も説明したり、セッションを手動で割り振ったり、確認すべきブランチやプルリクエストを探したりする時間を減らせることです。

再設計された新しい体験は2026年9月17日にロールアウトが始まりましたが、現在も利用できるアカウントは限られています。本稿では、自分のアカウントが対象かを確かめ、破棄してもよいリポジトリでプロジェクトを作り、互いに干渉しない2つのタスクを依頼して、成果をレビューするまでを解説します。各スレッドに何のコンテキストが引き継がれるのかも整理します。

Claude Code 使い方の要点：Projectsはフォルダではなく司令塔

Claude Codeのプロジェクトとは、Claudeとの継続的な会話と、そこからスレッドとして起動されるクラウドセッションをまとめたものです。会話を工房の現場監督だと考えると分かりやすいでしょう。監督に作業内容を渡すと、個別の作業区画がそれぞれの仕事を進めます。各区画には独立したワークスペース、コンテキストウィンドウ、Gitブランチがあり、監督は報告を受け取って作業キューを整理します。

これは、ClaudeチャットやCoworkに以前からあるProjectsとは異なります。従来版は会話と参照ファイルをひとまとめにする機能でした。新しいClaude Code Projectsベータには、作業をクラウドスレッドへ振り分け、進捗を追跡し、新しいスレッドへプロジェクトのコンテキストを渡すコーディネーターが加わっています。

各スレッドには、プロジェクトのリポジトリとファイル、指示、メモリ、選択したクラウド環境、アカウントのコネクターに加え、リポジトリ内の CLAUDE.md、スキル、プラグインが最初から渡されます。一方、手元のPCにしかないツールは引き継がれません。

対象となるClaudeプランをすでに契約しているなら、ソフトウェア費用の計算は分かりやすいものです。Claude Proは月額$20、年額$200の一括払いなら月あたり$17で、Maxは月額$100からです。Projects専用のクラウド仮想マシン料金はかかりません。ただし、各スレッドは完全なClaude Codeセッションとして動くため、並列で走らせるほど同じプランの利用上限を早く消費します。

比較用に確認したGitHub CopilotとCursorの個人向けコーディングエージェントプランは、月額$10から$200でした。すでにClaudeをコーディングエージェントとして使っているなら、Projectsは新たに席を追加する製品ではありません。変わるのは作業の調整方法であり、エンジニアリング上の判断まで肩代わりするものではありません。

まずClaude Code Projectsベータの対象か確認する

ClaudeのどこかにProjectsという機能名が見えているだけでは、利用条件を満たしたことにはなりません。

1. Claude ProまたはMaxのアカウントでサインインします。
2. claude.ai/code、またはデスクトップアプリのCodeタブを開きます。
3. 左サイドバーに Projects があるか確認します。
4. 表示されなければ、まだそのアカウントにはロールアウトされていません。Anthropicのウェイトリストに登録し、それまでは通常のクラウドセッションを使います。

初期の提供対象は、すでにクラウドセッションを使ったことがあり、ClaudeチャットやCoworkの旧Projectsを利用していないProおよびMaxアカウントが優先されています。TeamとEnterpriseは、現時点ではこの再設計版ベータの対象外です。Anthropicが移行を進める間も、既存の旧Projectsは引き続き利用できます。

Claude Codeのインストール、認証、リポジトリ単位の CLAUDE.md による前提設定がまだなら、先にClaude Codeの基本セットアップガイドを参照してください。Projectsは、そうしたリポジトリ運用の上に成り立つ機能であり、代わりになるものではありません。

最初のプロジェクトは破棄できるリポジトリで試す

安全に捨てられる小さなGitHubリポジトリを使います。初回の目的は、ルーティング、コンテキスト、ブランチ、使用量の動きを確かめることです。本番環境の移行を、いきなりベータ版のコーディネーターへ任せることではありません。

1. プロジェクト作成前にGitHubアクセスを整える

コード作業に使うリポジトリはgithub.com上に置く必要があります。接続したGitHubアカウントにプッシュ権限があり、そのリポジトリへClaude GitHub Appがインストールされていなければなりません。/web-setup で発行したトークンを使えば通常のクラウドセッションでリポジトリをクローンできる場合がありますが、プロジェクトのスレッドにはそれだけでは不十分です。

このベータでは、GitHub Enterprise Server、GitLab、Bitbucketのリポジトリをプロジェクトのコードリポジトリとして利用できません。組織所有のリポジトリでは、GitHub AppのインストールとSSO認証に組織オーナーの承認が必要になる場合があります。

2. 対象を絞ったプロジェクトを作る

Projects を開いて New project を選び、次を入力します。

• Name（名前）： 一時的なものだと一目で分かる Parser Project Test など。
• Goal（目標）： Improve parser coverage and documentation without changing behavior のような1文。
• Context（コンテキスト）： 破棄可能なリポジトリだけを追加します。

必須なのは名前だけです。ただし、狭く定めた目標があればコーディネーターの判断基準になります。また、リポジトリを1つに絞ることで、複数リポジトリ間の設定差も避けられます。

3. 共通指示を1つ追加する

Project settings > Memory > Project instructions を開き、すべてのスレッドに同じ完了条件と承認範囲を与えます。たとえば次のように書きます。

デフォルトブランチから開始すること。スレッドごとに1つのブランチを使うこと。完了報告の前に関連テストを実行すること。スレッド内で確認を取らずに、マージ、CIの変更、依存関係の追加を行わないこと。アクセス権が足りなければ、不足している項目を明示して停止すること。

プロジェクト指示には最大16,000文字を入力できますが、最初のテストでは短く保ちます。リポジトリ固有のビルドコマンドは、引き続きそのリポジトリの CLAUDE.md に置きます。プロジェクトを通じて判明した要件、決定、注意点はプロジェクトメモリに記録します。

4. クラウド環境を確認する

Project settings > Environment を開きます。新しいスレッドはすべて、ここで選択した環境を使います。この設定で、ネットワークアクセス、環境変数、API認証情報、セットアップスクリプトで導入するツールが決まります。

Anthropicがホストするデフォルト環境は、よく使われるサービスの許可リストへ接続でき、主要なツールもあらかじめ入っています。ただし、ローカルのデータベース、VPN、デバイスエミュレーター、シェル設定、PC内だけにある認証情報が自動で使えるわけではありません。そうした要素が必要な仕事を割り当てる前に、環境を構成してください。

5. 競合しない2つのタスクを送る

関連しない作業がどう分割されるか確認できるよう、2つのタスクを1つのメッセージにまとめます。変更対象は別々のファイルにします。たとえば次のように依頼します。

確認を求めず、すぐに開始してください。1つ目のスレッドでは、不正なパーサー入力に対する単体テストを追加してください。2つ目のスレッドでは、APIガイドの古い例を修正してください。本番用パーサーの挙動は変えず、どちらのブランチもマージしないでください。

Anthropicによれば、1つのメッセージに複数の無関係なタスクを入れると、それぞれ別のスレッドになります。特に指定しない限り、コードを扱う各スレッドはリポジトリのデフォルトブランチから個別のブランチを作ります。別ブランチでも同じコードを変更すれば競合するため、対象ファイルを分けることが重要です。

6. コーディネーターの要約だけでなく各スレッドを確認する

各スレッドのカードを開き、次の項目を記録します。

Overviewでは、作業が Ready for review、Waiting on you、Working、Landing、Idle、Resolved に分類されます。そのほかのタブには、プロジェクトファイル、プルリクエスト、ルーティンがまとめられます。コーディネーターは各スレッドの報告を確認できますが、すべての手順までは見えません。作業監査には、引き続きスレッドの実行履歴を使います。

7. 後続タスクに保存済みコンテキストが届くか試す

2つのスレッドが完了したら、Documentation changes must preserve every runnable example のような無害なルールを記憶するようコーディネーターへ伝えます。その後、小さなドキュメント作業用の新規スレッドを立ち上げ、編集前にプロジェクトのブランチ規則とドキュメント規則を説明させます。

これで、異なる2つのコンテキスト経路を確認できます。プロジェクト指示は、固定された作業要件としてすべての新規スレッドに届くはずです。プロジェクトメモリに保存した決定は MEMORY.md を通じて引き継がれるはずです。リポジトリの CLAUDE.md は、それとは別にコードベース固有のルールを置く第3の層です。

新しいスレッドに届くもの、ローカルに残るもの

Projectsを誤解しやすいのは、クラウドスレッドを自分のPCのリモートコピーだと思ってしまうことです。実際には、プロジェクト、リポジトリ、アカウント、環境のコンテキストを組み合わせて作られる、新しいクラウドセッションです。

複数リポジトリを使う場合には、注意すべき点が1つあります。プロジェクトに複数のリポジトリを入れると、すべてのリポジトリの CLAUDE.md、スキル、プラグインは読み込まれます。一方、リポジトリごとの権限ルール、フック、env 設定は読み込まれません。リポジトリ横断の規則はプロジェクト指示へ、環境変数はクラウド環境へ置きます。

Claude Codeの並列実行は無制限ではない

Anthropicは、同時実行できるスレッド数を固定値で示していません。コーディネーターに同時実行を2つまでと頼むことはできますが、これは希望する動作の指示であり、強制される上限ではありません。別に設けられた明確な上限は、全プロジェクトを通じて 1日200個の新規スレッド です。

実行中のスレッドはプラン利用量を消費します。コーディネーターも、報告を読んで次の動きを判断している間は同じ利用量を使います。プルリクエストを監視するスレッドは、CIの失敗やレビューコメントが入ると再び起動し、利用量を消費します。実行中のスレッドも、監視中のプルリクエストも、新しいメッセージもないアイドル状態のプロジェクトは、置いてあるだけなら何も消費しません。

新しいプロジェクトでは、スレッドはOpusのhigh effort、コーディネーターはlow effortがデフォルトです。大きなバッチを走らせる前に Project settings > General を開き、各作業をこなせる範囲で最も低コストなモデルとeffort levelを選びます。そのうえで、少ない並行数を指定してください。重要なのは、Projectsが何スレッド起動できるかではありません。キューがノイズになる前に、自分がいくつの結果をレビューできるかです。

Claude Code Projectsが特に役立つ7つの用途

1. 複数リポジトリの移行を指揮するプラットフォームリード

サーバー、Web、モバイルの各リポジトリを接続し、廃止予定のエンドポイントをなくすという1つの目標をプロジェクトへ与えます。別々のスレッドが各呼び出し元を個別のブランチで更新し、コーディネーターが作業順と障害要因を追跡できます。3つのエージェントセッションを手作業で同期する代わりに、1つのレビューキューを使えることが利点です。目標が1セッションより長く続き、リポジトリ単位で作業をきれいに分割できるため、最も相性のよい用途です。

2. 1つのサービスのバグキューを処理するメンテナー

新しいバグ報告やスタックトレースが届くたびに、同じプロジェクトへ貼り付けられます。コーディネーターは、その領域をすでに調べているスレッドにリグレッションを渡すか、プロジェクトに保存された注意点を添えて新しいスレッドを立ち上げます。説明を繰り返す手間が減り、アクセス、レビュー、意思決定のどれを待っているバグなのかを継続的に記録できることが利点です。

3. 独立したリリース準備チェックを回すリリース責任者

テストスイート、ドキュメントのリンク、依存関係の監査、リリースノートの下書きを別々のスレッドへ渡します。結果を確認するまでは、各作業を読み取り専用にします。コーディネーターが合格項目と回答が必要な項目を示すため、証拠を1つの巨大な実行履歴へ混ぜずに済みます。チェックリストから意思決定までの時間を短縮しながら、最終判断はリリース責任者が握れます。

4. 大規模な変更を境界ごとに分けるリファクタリング責任者

1つのコンテキストウィンドウに収まらない移行では、独立したモジュールやパッケージを別々のスレッドへ割り当て、守るべき不変条件をプロジェクト指示に記します。各スレッドは自分のブランチを検証して報告します。共通の完了条件を維持しながら並行して進められることが利点です。ただし、同じ共通抽象化に2つのブランチが触れれば、通常どおりマージコンフリクトが起こり得ます。

5. クライアントアプリを保守する受託開発エンジニア

クライアントごとに、リポジトリ、指示、環境をまとめた非公開プロジェクトを1つ作ります。契約期間を通じて、小さな修正、レビュー依頼、ドキュメント作業を同じ場所へ渡せます。クライアントのコンテキストを混ぜずに継続できることが利点です。ベータ期間中、Projectsは1人のユーザーに属し共有できないため、クライアントとの共同作業ポータルではなく、個人用の運用コックピットとして使います。

6. 繰り返す連携障害を分析するサポートエンジニアリングリード

Projectsにリポジトリは必須ではありません。サポートチケットのエクスポートと連携ドキュメントをアップロードし、障害の分類、例の検証、改善方針書の作成を別スレッドへ依頼できます。出力ファイルはLibraryに保存されます。再利用できる1組のプロジェクトコンテキストと、分析・執筆それぞれの独立した証拠の流れを持てることが利点です。

7. 種類の異なるバックログを片付けるソロ創業者

テスト作業を1つ、ドキュメント作業を1つ、リポジトリ監査を1つ含む小さなバッチを送ります。コーディネーターには2スレッドだけを実行し、破壊的な変更は先に提案するよう指示します。各セッションを見張り続けず、完成したブランチのレビューに集中できることが利点です。すべてのタスクが同じファイルを必要とする場合や、創業者のPCからしか到達できないサービスが必要な場合には適しません。

Claude Code Projectsの周辺で作れる3つのプロダクト

このベータには公開済みのProjects APIがないため、当面はワークフローの隣で機能するプロダクトが現実的です。コンテキストを整え、GitHubの状態を確認し、人間による成果レビューを支援する製品です。

1. Project Readiness Auditor：最も有望な案

リポジトリがクラウド型コーディングエージェントを迎える準備ができているか確認する、読み取り専用のGitHub Appを作ります。リポジトリ指示、テストコマンド、ブランチ保護、GitHub Appの導入範囲、必要なシークレット、ネットワーク依存関係を検査し、プロジェクト指示の下書きとクラウド環境のチェックリストを生成します。

この仕事への需要はすでに検索にも表れています。「ai powered coding agent」は米国で月間8,100回検索され、購買意図があります。本稿で確認した公式の個人向けコーディングエージェントプランは月額$10から$200ですが、有料ライセンスを買うだけでリポジトリが並列クラウド作業に耐えられるようになるわけではありません。

販売できる最小版では、GitHubリポジトリを1つスキャンし、環境について6つ質問して、貼り付け可能な指示書を出力します。ただし、プラットフォームリスクには注意が必要です。AnthropicやGitHubがセットアップ検査をすぐに取り込む可能性があるため、Claude専用テンプレートだけでなく、複数エージェントへの対応と有用な監査履歴が必要です。

2. AI delivery lifecycle board

ブランチ、プルリクエスト、CIステータス、レビューコメント、人間の承認をデリバリー目標ごとにまとめる、GitHub連携ボードを作ります。複数のコーディングエージェントを使い、ベンダーに依存しないレビュー画面を必要とする技術リード向けです。

「AI software development life cycle」は米国で月間720回検索され、キーワード難易度は4、CPCは$18.13です。最小版はGitHubイベントを読み、working、blocked、ready、landedの4状態へ整理します。Claudeプロジェクトの非公開実行履歴へアクセスする必要はありません。

課題は差別化です。GitHubやエージェントベンダーも、すでに同種の状態を多く表示しています。ベンダーをまたいで作業を結び付け、承認の証拠を保存し、単に見栄えのよいキューを描くのではなく、変更が止まっている理由まで説明できて初めて価値が出ます。

3. Automated review policy router

エージェントが作成したプルリクエストに、リポジトリ固有のレビューポリシーを適用するGitHub Appを作ります。パーサーの変更にはテスト成果物を必須にし、課金処理の変更を指定レビュアーへ回し、自動修正コメントから権限付きの自動処理が起動しないよう止める、といった運用が可能です。

「Automated code review」は米国で月間210回検索され、CPCは$63.33です。対象は小さくても、支払い意欲の高い検索であることが分かります。MVPに必要なのはポリシーファイル、プルリクエスト検査、不足している証拠を簡潔に示す説明です。

競合には注意が必要です。Claudeのスレッドはすでにプルリクエストを監視し、CIの失敗やレビューコメントへ反応します。新しい製品は、別のレビューボットをまねるのではなく、複数のエージェントとリポジトリを横断してリスクを統制する必要があります。

Claude Code Projectsで解決できないこと

Projectsが力を発揮するのは、作業を分割でき、必要なコンテキストをGitHub、アップロード済みファイル、コネクター、クラウド環境のいずれかに置ける場合です。1セッションに収まる単発の修正、ローカルデバイスやVPNに結び付いた作業、複数人で同じプロジェクトを操作する必要があるチームには向きません。

通常の開発・提供上のリスクがなくなるわけでもありません。

• 別スレッドでも、ブランチの変更箇所が重なればマージコンフリクトが起こります。
• 同時実行数の指定はコーディネーターへの指示であり、強制的な予算管理ではありません。
• スレッドを並列実行すると、Proの利用上限をすぐに使い切る可能性があります。
• 一時停止したサンドボックスが新しいクローンから再開され、コミットしていない作業が失われる場合があります。
• ベータは個人向けで、プロジェクト共有や組織単位の管理機能はありません。
• スレッドを後から別のプロジェクトへ移すことはできません。

結論はシンプルです。Projectsは、分割できる作業の調整に使い、アーキテクチャや承認まで委ねないでください。まず2つのタスクで始め、両方の実行履歴を確認し、ブランチと利用量の挙動を予測できるようになってから並行数を増やします。

よくある質問

Claude CodeでProjectsは使えますか？

再設計されたProjectsベータは、対象となるClaude ProおよびMaxアカウントで、claude.ai/code、デスクトップ版のCodeタブ、Claudeのモバイルアプリから利用できます。CodeのサイドバーにProjectsがなければ、そのアカウントにはまだロールアウトされていません。claude project というターミナルコマンドは、これとは無関係なローカルディレクトリの状態を管理するものです。

Claude Code Projectsはどう使いますか？

Claude Codeでプロジェクトを作成し、目標と必要最小限のリポジトリまたはファイルを追加します。短い共通指示を書き、クラウド環境を選び、コーディネーターとの会話に1つ以上のタスクを送ります。何かをマージする前に、Overviewで各スレッドを確認し、ブランチ、実行履歴、検証結果、利用量を調べてください。

Claude Codeは既存プロジェクトでも使えますか？

はい。既存のgithub.comリポジトリを使ってプロジェクトを作るか、既存のクラウドセッションから Continue as a project を選べます。コードリポジトリでは、接続済みGitHubアカウントのプッシュ権限と、そのリポジトリにインストールされたClaude GitHub Appが必要です。

Claude ProjectsとClaude Codeの主な違いは何ですか？

Claude Codeは、ローカルまたはクラウドのセッションで動くコーディングエージェントです。再設計されたClaude Code Projectsは、その上にある調整レイヤーです。1つの会話から複数のClaude Codeクラウドセッションを起動・追跡し、共通のプロジェクトコンテキストを渡して、各セッションの状態を集約します。ClaudeチャットとCoworkの旧Projectsは、移行対象になるまで従来どおりファイルと会話をまとめるワークスペース型です。

リポジトリ、承認フロー、クラウド環境に合わせたプロジェクト対応のエージェント運用を構築したい場合は、AI production systemsをご覧ください。