Claude Code Projectsの使い方｜16枚の画面で設定から成果物まで

Claude Code Projectsとは？従来のProjectsとの違い

新しいProjectsの特徴は、共通の背景を持つ仕事を、Claudeが複数のスレッドへ振り分けて管理することです。スレッドとは、個別の仕事を進める作業用の会話です。プロジェクト全体の会話にはまとめ役がいて、仕事の追加や方針の変更を受け付けます。

無料プランでも作れる従来のProjectsと、Pro・Max向けに段階提供されている新Projectsは、利用条件も同じではありません。旧機能の「無料で5件まで」という説明を、新機能へ当てはめないでください。公式ヘルプは両方を分けて説明しています。

ブランチは元のコードから分けた作業先、PRは変更を取り込むための提案です。Libraryは、追加した資料や作成したファイルを集める場所です。

まとめ役が各スレッドのすべての操作を常に見ているわけではありません。全体の報告を読んだ後、必要に応じてスレッドを開き、作業内容と成果物を確かめる使い方になります。公式：Projectsの構成

使えるプランと、Projectsが表示されないときの確認

2026年10月10日時点では、Pro・Max向けのパブリックベータです。claude.ai/codeやデスクトップアプリのCodeタブに「Projects」が表示されるかを確認してください。モバイルアプリからも利用できます。新Projectsは、Team・Enterpriseへはまだ提供されていないと公式資料に記載されています。

日本時間10月10日、@ClaudeDevsは、ウェイトリストにいたPro・Maxユーザー全員を受け入れたと発表しました。これは、すべてのPro・Max契約者へ一律に開放したという意味ではありません。表示されない場合は、公式ウェイトリストと利用アカウントを確認します。再インストールすれば必ず出る機能ではありません。

コードを扱う場合は、github.com上にコードと変更履歴を保存するリポジトリが必要です。接続したGitHubアカウントには、変更を書き込むpush権限も必要です。対象リポジトリにはClaude GitHub Appを導入しておきます。/web-setupで接続しただけではProjectsのクラウドスレッドの要件を満たしません。文書だけの仕事なら、リポジトリなしでも始められます。公式：利用前提

どんな仕事を任せると役立つ？

選ぶ基準は、同じ目標に向けて、仕事が何度も発生するかです。一問だけの質問なら通常のチャットで十分です。以下は機能の特性を踏まえた編集部の使い分け案です。

一方、すべての作業で手元のデータベースや端末を使うなら、ローカルのClaude Codeから始める方が扱いやすい場合があります。毎週1回の定型処理だけならRoutines、個々の仕事の中で専門役を呼びたいならサブエージェントも候補です。Projectsは、こうした機能をすべて置き換えるものではありません。公式の使い分けとサブエージェントの解説も参考にしてください。

Projectsの始め方：画面を見ながら最初の依頼まで進める

まず1つの目的で作り、必要な資料と指示をそろえます。手順1は編集部の実画面、手順2〜16は出典付きの公式デモです。赤枠の番号と画像下の説明を対応させています。

最初に設定する指示・モデル・使用量

共通指示には「何をもって完了か」を書く

Project settings → Memory → Project instructionsには、新しいスレッドが最初に参照する共通指示を書きます。目標だけでなく、使ってよい資料、成果物の形、確認方法、足りない情報の扱いを決めます。

目的：問い合わせ記録をもとに、FAQの改善案を作る。
使用資料：私がこのプロジェクトへ追加した資料。

・事実には元資料のファイル名と該当IDを付ける。
・資料に書かれていない仕様や原因は推測で確定しない。
・成果物は「確認できたこと」「提案」「未確認」を分ける。
・完了時は、作成したファイルと確認した内容を報告する。
・外部への送信、公開、既存FAQの変更は、私の確認を待つ。
・必要な資料を読めない場合は、何が足りないか伝える。

これは編集部の記入例です。自分の業務へ置き換えてください。共通指示は作業の前提を伝える文章であり、操作を機械的に禁止する権限設定ではありません。「同時に2スレッドまで」と書いても、強制的な上限にはなりません。公式：動かし方の調整

大量に任せる前に、1件の使用量を見る

Project settings → Generalで、作業側のThread model・Thread effortと、まとめ役のCoordinator model・Coordinator effortを確認します。effortは推論に割く労力の設定です。高くすれば成果物の正しさが保証されるわけではありません。

公式資料の現行の初期設定では、モデルはOpusです。effortは作業スレッドがhigh、まとめ役がlowになっています。設定は変わり得るため、自分の画面でも確認してください。編集部としては、まず小さな仕事を1件終わらせ、成果物とUsageを見てから仕事を増やす使い方を勧めます。公式：モデルとeffort

そのまま試せる例：問い合わせ6件からFAQの候補を選ぶ

ここからは、編集部が用意した架空の教材です。顧客の実データでも、Projectsの実行記録でもありません。入力と確認基準を小さくそろえることで、出力の良し悪しを自分で判断できるようにします。

1. 次の6件を資料として渡す

以下をテキストファイルに保存して追加するか、依頼文と一緒に貼り付けます。実務で置き換える場合は、まず共有してよい内容だけを使ってください。

T-01：招待メールが見つからず、利用を始められない。
T-02：招待メールを再送したが、受信箱に見当たらない。
T-03：閲覧はできるが、資料を編集するボタンが押せない。
T-04：招待を送ったと言われたが、メールが見つからない。
T-05：閲覧者から編集者に変えてほしい。
T-06：ダウンロードしたCSVを開くと、日本語が文字化けする。

2. 分類だけを1スレッドへ依頼する

この6件から、FAQを追加する優先順位を考えたいです。
まず1スレッドで分類だけを行ってください。

入力に書かれた「困りごと」でまとめ、次の列の表を作ってください。
分類／該当ID／件数／確認できる事実／追加で確認したいこと

条件：
・T-01からT-06までを、漏れなく1回ずつ分類する。
・原因は断定しない。解決方法も、資料になければ未確認とする。
・件数順に並べ、最後にFAQ候補を1つ提案する。
・FAQ本文の作成と外部への公開は、まだ行わない。
・分類表をMarkdownファイルとして残し、場所を教える。

3. 「もっともらしさ」より、元データとの一致を見る

分類名に唯一の正解はありません。この教材では、次のようなまとまりなら内容を追えます。下表は編集部が作った確認用の例です。

検品は次の4点です。

1. IDが6件すべてあり、重複していない。
2. 件数の合計が6になる。
3. 「迷惑メールが原因」「文字コードが原因」など、入力にない原因を確定していない。
4. 作成したファイルを開いて、本文を読める。

この4点を確認すれば、文章が整っているだけの出力と、元資料を追える出力を見分けられます。

また、6件中3件という結果はこの教材の中での件数です。実際の利用者全体の半数が困っている、という結論にはできません。

4. 選んだ1件だけ、次の仕事へ進める

分類表を確認しました。
「招待メールが見つからない」のFAQ草稿を1本作ってください。

今回は解決策を断定せず、ユーザーに確認したいことと、
運営側で確認すべきことを分けてください。
裏付けのない操作手順、画面名、解決時間は書かないでください。
参照した問い合わせIDを末尾に残し、未確認の項目も列挙してください。
公開はせず、レビュー用の文書として保存してください。

一度に「問い合わせを全部解決して」と渡すより、分類を確認してからFAQへ進める方が、誤った前提を早く直せます。自分の資料に置き換えるときも、小さな入力・確認できる出力・次の依頼を一組にすると、仕事を広げやすくなります。

進捗と成果物はどこで見る？

Overviewでは、まずWaiting on youとReady for reviewを確認します。前者は返事や承認が必要なもの、または失敗した作業、後者はプルリクエストのレビューを待つ作業です。文書はLibraryから開き、コードは変更内容とテスト結果を見て判断します。

承認を求める表示が出た場合は、該当スレッドの中で答える必要があります。プロジェクト全体の会話へ「進めて」と送っても、その承認への回答にはなりません。公式：承認待ちの解消

コードの仕事では、ブランチやPRができたことと、変更が正しいことを分けて確認します。複数スレッドが同じ箇所を変えた場合、変更の衝突を解く作業が必要になることがあります。公式発表でも、競合は通常のPRと同様に解決すると説明されています。

メモリ・CLAUDE.md・Skillsはどう引き継がれる？

設定を置く場所をそろえると、「手元では使えたのに、Projectsでは見つからない」を切り分けやすくなります。

特に注意したいのは、Project settingsで変えた指示・リポジトリ・プラグイン・環境は、すでに動いているスレッドへ自動で反映されないことです。設定を直したら、新しいスレッドで小さく確認します。基本的な指示ファイルはCLAUDE.mdの書き方、接続の考え方はMCPの解説で補えます。公式：設定の反映範囲

複数のリポジトリを登録するときは、Anthropicが提供するクラウド環境での設定の扱いに注意してください。各リポジトリの.claude/settings.jsonにある権限ルールは、スレッドへ適用されません。決まったタイミングで処理を自動実行するhooksの設定も同様です。CLAUDE.mdやSkillsの読み込みとは別の扱いです。公式：リポジトリから引き継ぐ設定

PCを閉じても動く？クラウドとローカルの違い

クラウドのスレッドは、PCを閉じても続きます。自分のPCで動くスレッドには、そのPCの稼働が必要です。9月の発表記事だけを読むとクラウド専用に見えますが、現行ドキュメントではRemote Controlを使ったローカル実行も案内されています。

ローカルで動かすには、PC側にClaude Code v2.1.280以降が必要です。デスクトップのSettings → Claude Code → Use this computer from your phone and claude.aiでフォルダーを接続するか、対象フォルダーでclaude remote-controlを実行します。

次にProjectsの会話の＋ → Work locallyから依頼し、表示されたカードの対象フォルダーを確認してAllow onceを選びます。同じフォルダーで複数の作業を動かすと変更が競合し得るため、GitリポジトリではWorktreeで作業コピーを分ける方法があります。

アプリやRemote Controlを終了すると、その接続による作業も止まります。また、Require trusted devicesが有効なアカウントでは、ProjectsからPC上のスレッドを動かせないとされています。無効化を前提に進めず、自分の利用条件を確認してください。公式：PCでの実行手順と制約

料金と使用量：並列に動かすほど消費は速くなる

Projectsは、ほかのClaude Codeのセッションと同じプランの使用上限を使います。スレッドごとの作業に加え、まとめ役の会話や、PRの自動テストの失敗やレビューへの対応でも使用量が増えます。「今、自分が入力していない」ことと「使用量が増えない」ことは同じではありません。

通常のスレッドがプランの上限に達すると、リセットを待って自動で再開します。次の利用枠を使いたくない場合は、そのまま放置せず停止してください。プランを超える利用には、アカウント側で利用クレジットを有効にしている必要があり、スレッドが勝手に有効にすることはできません。定期実行のスレッドには、上限時に終了し、リセット後に自動再開しない例外があります。

使用量はProject settings → Usageで確認します。公式資料にある「1日200件」は、全プロジェクトを通じて新規に作るスレッド数の上限です。同時実行数の保証や、200件分を定額で使える保証ではありません。公式：使用量と費用

費用対効果を確かめるなら、スレッドの数だけでなく、採用できた成果物と、人が修正・確認した時間も一緒に記録します。先ほどの教材なら、「分類表を作れたか」「IDと件数を確認できたか」「次のFAQ作成に使えたか」を見れば、仕事として役立ったか判断できます。

うまく動かないときは、症状から確認する

何が止まっているか分からない場合は、同じ仕事を新しく依頼する前に、スレッドの最後の報告と成果物を見ます。二重に作業を始めると、使用量と変更の重複を増やすことになります。エラーの詳しい確認方法は、公式のトラブルシューティングを参照してください。

Claude Code Projectsのよくある質問

無料プランでも使えますか？

本記事の新Projectsは、確認時点ではPro・Max向けのベータです。無料プランで利用できる従来のチャット版Projectsとは分けて考えてください。

ターミナル版のClaude Codeから使えますか？

Projectsを管理する画面はWebやアプリです。一方、ターミナルでRemote Controlを起動し、ProjectsからそのPC上で作業スレッドを動かすことはできます。詳しくはクラウドとローカルの違いを参照してください。

プログラミングをしなくても使えますか？

リポジトリを登録せず、資料をもとに文書を作る仕事にも使えます。まずは問い合わせ6件の教材のように、答えを自分で確認できる小さな仕事から試せます。

チームで同じProjectsに指示できますか？

新Projectsは確認時点では個人のもので、ほかの人と共有する機能はありません。従来のチャット版Projectsの共有機能を、新Projectsでも使えると読み替えないでください。公式：ほかの機能との関係

サブエージェントとは何が違いますか？

サブエージェントは、あるセッションの中で一部の作業を任せる役割です。Projectsは、継続する仕事を複数のスレッドへ振り分け、全体を管理する場です。スレッドの中でサブエージェントを使うこともあり、排他的な選択ではありません。公式：並列実行機能の使い分け

最初は、成果物を確認できる仕事を1つ任せる

Projectsで最初に決めたいのは、スレッドの数よりも「何が返ってきたら仕事が終わりか」です。目的と資料をそろえ、小さな仕事を1件渡し、成果物と使用量を確認する。その結果を踏まえて共通指示を直し、仕事を広げていきましょう。

自社で導入する場合は、機能の設定に加えて、任せる業務、参照する資料、確認する担当者を決める必要があります。PLaiでは、こうした業務設計から構築・運用までを支援しています。必要な方はAI社員導入支援の内容をご覧ください。

次に読む：設定と仕事の分担を深める

• Claude Codeの基本的な使い方：通常の作業をまだ試していない方へ。
• Skillsの作り方と使い方：繰り返す手順をまとめたい方へ。
• サブエージェントの役割と使い分け：1つの仕事の中で担当を分けたい方へ。