案件ごとにProjectsを分けるか一つにまとめるか：Claudeでの粒度の決め方

粒度を決める前に知っておくProjectsの仕様

分け方の理由になる仕様を、公式ヘルプで確認した範囲で整理します（2026年10月27日時点。画面や提供条件は変わることがあります）。

• Projectsは、独自のチャット履歴とナレッジ（資料）を持つ作業スペースです。プロジェクト指示も、そのProject内のすべてのチャットに使われます（What are projects?、How can I create and manage projects?）。
• Projectの名前と説明文は、Claudeからは参照されません（作成・管理のヘルプ）。必要な前提は指示かナレッジに書きます。
• 同じProject内でも、チャット同士の文脈は、ナレッジに追加しない限り共有されません（同ヘルプ）。使い回したい情報は、チャットで伝えるのではなくナレッジに入れます。
• 無料プランで作れるProjectは最大5つです。有料プラン（Pro、Max、Team、Enterprise）では、資料が増えて上限に近づくと、容量を広げるRAGモードが使われます（What are projects?）。
• メモリはProjectごとに分かれます。Project内では、そのProjectのメモリとProject外のチャットのメモリが使われ、別Projectのメモリは使われません。Projectページでアカウントのメモリの利用をオフにすると、メモリを完全に切り離せます。TeamとEnterpriseでは、メモリを使えるかどうかを組織のオーナーが制御します（チャット検索とメモリのヘルプ）。
• チャットは後から別のProjectへ移せます。Projectはアーカイブでき、その後もメンバー、権限、ナレッジはそのまま保たれます（作成・管理のヘルプ）。

つまりProjectは、資料・指示・メモリ・共有相手が1セットになった箱です。この4つが同じなら1つの箱で足り、1つでも違えば分ける理由になります。

なお公式ヘルプには、Projectを「1つの会話」として扱う新しいベータ版が、Pro・Max向けに展開中との記載があります。本記事は従来のProjects画面を前提にしています。新方式で表示や挙動が違う場合は、ヘルプを優先してください。

粒度判断フロー

上から順に答え、最初に当てはまった行で止めてください。

1. 同じ資料や前提を、3回以上貼り直す予定がありますか？

• いいえ → Projectを作らず、通常のチャットで済ませます。「3回」は説明用の目安で、公式の基準ではありません。
• はい → 2へ。

1. 読み手や共有相手が違いますか？（社外と社内、別のクライアントなど）

• はい → 分けます。チーム向けプランでは、共有の設定もProject単位で行うためです。
• いいえ → 3へ。

1. 文体や出力形式のルールが衝突しますか？（例：提案書は丁寧語、社内メモは箇条書き）

• はい → 分けます。指示がProject全体に効くため、混ぜると毎回の指定が増えます。
• いいえ → 4へ。

1. 他案件の情報が混ざると困りますか？（数値や固有名詞の取り違え、守秘上の区別）

• はい → 分けます。別Projectのメモリは使われないので、混ざりにくくなります。
• いいえ → 5へ。

1. 終わりのある案件ですか？

• はい → 案件単位で1つ作り、終了後はアーカイブします。
• いいえ（定常業務） → 業務の種類単位で1つにまとめ、年度や半期ごとに見直します。

判断表

• 1回きりの文章校正、おすすめの粒度：Projectなし（通常チャット）
• 3か月の提案案件、関係者が固定、おすすめの粒度：案件単位で1つ
• 毎週の議事録整形・週報づくり、おすすめの粒度：業務種別で1つ（年単位）
• 同じ取引先の小さな案件が3つ、資料も読み手も共通、おすすめの粒度：まとめて1つ（取引先単位）
• 社外向けと社内向けで文体も相手も違う、おすすめの粒度：分ける
• 無料プランで5つを超えそう、おすすめの粒度：取引先単位や業務種別単位にまとめる

命名例とプロジェクト指示の雛形

Claudeは名前を読まないので、名前は人間が探すためのものと割り切ります。「種別_対象_期間」の形にそろえると、一覧で探しやすくなります。以下は説明用の仮名です。

• 案件_A社サイト改修提案_2026下期
• 案件_B社研修資料_2026-11〜2027-01
• 定常_週報と議事録整形_2026
• 共通_社内文書の文体ルール
• 検討_新規サービス案メモ

ルールは3つだけです。

• 先頭に種別（案件・定常・共通・検討）を置き、並び順で分類されるようにする。
• 期間は「年」か「期」までにする。月日まで書くと、延長のたびに名前が実態とずれる。
• 条件や注意事項は名前に書かず、プロジェクト指示に書く。

指示には最低限の前提を書きます。以下は仮の例なので、実際の案件に合わせて書き換えてください。

目的：A社サイト改修の提案書づくりを支援する。
読み手：A社の広報部長（技術用語は少なめにする）。
文体：です・ます調。結論を先に書く。
扱う資料：ナレッジの「ヒアリングメモ」「現行サイト構成」。
守ること：資料にない数値や事実は書かず、「要確認」と明記する。
扱わないこと：他案件の情報。

「資料にない数値は書かず要確認と書く」という一行は、案件の取り違えともっともらしい数字の混入を減らす狙いです。ただし完全には防げないため、出力された数値や固有名詞は、人が元資料と照らして確認してください。

Claudeに分け方を相談する依頼文

仕事を棚卸ししたら、Claudeに分け方の案を出してもらえます。実在の取引先名や機密はそのまま入れず、「A社」「案件1」のように置き換えてください。

次の仕事一覧を、ClaudeのProjectsに分ける案を作ってください。

判断の基準：
- 同じ資料を使い回すものは同じProjectにする
- 読み手が違うもの、文体ルールが衝突するものは分ける
- 終わりのある案件と定常業務は分ける
- Projectは最大◯個まで（無料プランなら5個）

仕事一覧：
1. A社 サイト改修の提案書（〜12月、資料：ヒアリングメモ）
2. A社 パンフレットの文案（〜11月、資料：同じヒアリングメモ）
3. 毎週の議事録整形（社内向け、箇条書き）
4. B社 研修資料の作成（〜1月）
5. 新規サービスのアイデア整理（期限なし）

出力：Project名（「種別_対象_期間」形式）、含める仕事の番号、まとめた理由、分けた理由を表で。

出てくる案は下書きです。たとえば1と2は同じ資料を使うので「A社」でまとめる案が出やすい一方、納期や関係者が違うなら分けたほうがよい場合もあります。採否は、上のフローで自分で判断してください。

作りすぎ・まとめすぎのやり直しと、共有の注意

最初から完璧に決める必要はありません。チャットは別のProjectへ移せ、Projectはアーカイブできます。公式ヘルプでは、チャット名の横のメニューからProjectへ追加する方法が案内されています。

• 作りすぎたとき：資料がほぼ同じProjectが並んでいたら、チャットを一方に移し、空になったほうをアーカイブします。アーカイブ済みのProjectは、削除する前にアーカイブを解除する必要があります。迷うならアーカイブのままで構いません。
• まとめすぎたとき：一覧に無関係な話題が混ざる、指示が「ただし〜の場合は」と条件だらけになる、といった状態が分ける合図です。該当のチャットを新しいProjectへ移し、指示を案件ごとに書き直します。
• メモリが気になるとき：別Projectのメモリは使われないので、案件間の混在はProjectを分けるだけでも減ります。Project外のチャットのメモリも使いたくない場合は、Projectページでアカウントのメモリの利用をオフにします。

見直しの時期は、納品後や期末など、案件の区切りに1回で十分です。

TeamやEnterpriseプランでは、Projectを「閲覧可」「編集可」の権限で共有できます。閲覧可はチャットできますが編集はできず、編集可は指示とナレッジの修正やメンバー設定の更新ができます。共有する可能性のある案件は、最初から個人用のProjectと分けておくと、後で共有するときに中身を選別する手間が減ります。何を入れてよいかは社内ルールに従い、迷う資料は入れずに、置き換えるか要約にとどめてください。