結論：案件名ではなく、同じ判断基準を使う仕事で分ける

先に答えると、Claude Projectsはチャットを入れるフォルダではありません。Anthropic公式では、固有のチャット履歴と知識ベースを持ち、資料、背景情報、project instructionsを共通利用できる自己完結した作業スペースです。したがって「営業部」「2026年」と大きく作るより、同じ正本と同じ完成条件を使う仕事で分けます。例は「採用FAQ更新」「月次顧客分析」「製品Aの提案書」です。

読者の具体的な困りごとは、似た名前の資料と会話が散らばり、Claudeが旧版を参照しても、誰も正しい資料を説明できないことです。読了後は、Projectの目的、知識、共通指示、共有範囲、更新担当を決められます。次の行動は、一つの反復業務を選び、「このProjectで作る成果物」と「使ってよい正本」を一文ずつ書くことです。

Projectsに入れるもの、入れないもの

Project knowledgeには、規程、製品仕様、用語集、承認済みFAQ、テンプレートなど、複数のチャットで繰り返し参照する内容を入れます。project instructionsには、回答形式、語調、引用方法、禁止事項、確認が必要な条件を書きます。個々の依頼や一時的なデータは、その仕事のチャットへ置くと役割が分かれます。

逆に、用途が違う資料、期限切れの旧版、出典不明のメモ、他部署へ見せられない情報を一つのProjectへ混ぜません。ファイル名だけで判断せず、所有者、版、更新日、有効期限を本文や台帳へ持たせます。Projectは情報分類やアクセス管理を自動で正しくするものではないため、送信可否のルールは別に必要です。

有料プランのProjectsでは、知識量がコンテキスト上限へ近づくとRAGが自動で有効になり、公式案内では容量を最大10倍へ拡張します。ただし、取得候補が増えるほど古い資料や似た文書の混入リスクも増えます。「多く入れられる」と「正しい根拠を選べる」を分け、検索対象を定期的に整理します。

Projectを作る前の5項目brief

  1. 目的：一つのProjectが繰り返し支援する業務を一文で定義します。
  2. 成果物：回答、表、草案、分析など、完成形と合格条件を決めます。
  3. 正本：使ってよい資料、版、所有者、更新日を記録します。
  4. 境界：入れない情報、外部送信不可、必須の人間確認を決めます。
  5. 責任：Project owner、資料更新者、共有承認者、廃止判断者を置きます。

このbriefが書けない場合、Projectを作っても資料置き場が増えるだけです。特に「最新の資料を使う」という指示は不十分です。ファイル名、版、日付、優先順位を具体的にし、矛盾時は回答せず担当者へ確認するルールを置きます。

Claude Projectsを使う8手順

  1. Projects画面で新規Projectを作り、業務と成果物が分かる名前を付けます。
  2. 説明欄へ目的、対象外、所有者、最終確認日を書きます。
  3. 知識ベースへ承認済み資料だけを追加し、版と出典をそろえます。
  4. project instructionsへ回答形式、根拠表示、禁止事項、確認条件を設定します。
  5. 既知の質問を三件試し、引用、旧版混入、回答不能時の挙動を確認します。
  6. 実案件のチャットをProject内で開始し、一つの目的だけを依頼します。
  7. Team・Enterpriseで共有する場合は、閲覧者と編集者を最小にします。
  8. 月次または資料変更時に知識を棚卸しし、完了案件はarchiveします。

既存の単独チャットは、チャット名のメニューからProjectへ移せます。ただし移動前に、その会話へ別案件や不要な個人情報が含まれないかを確認します。Team・Enterpriseのmemory利用ではProjectごとにmemoryが分離され、チャットを外すと非Project側のmemoryへ含まれるため、単なる整理操作ではなく情報境界の変更として扱います。

共通指示を短く、検証可能にする

良い共通指示は「丁寧に回答する」だけではなく、「結論、根拠、未確認、次の作業の順で回答する」「価格は正本ファイルと確認日を併記する」「個人情報を含む場合は処理を止める」のように確認できます。毎回変わる依頼まで共通指示へ入れると、後の仕事と競合するため分けます。

資料を追加したら、質問に答えられるかだけでなく、答えてはいけない例を試します。旧価格、対象外顧客、根拠のない例外、外部送信を含むケースを用意し、必要な時に保留できるかを確認します。Projectの品質は資料数ではなく、代表質問の正答率と重大誤りで測ります。

共有と更新のチェックリスト

目的と成果物が一つか／正本に所有者と日付があるか／旧版を除いたか／共通指示が検証可能か／入力禁止情報を決めたか／共有先を組織内の必要者へ絞ったか／編集者と閲覧者を分けたか／変更履歴を残すか／代表質問と失敗例を試したか／archive・deleteの責任者がいるか、を確認します。

Projectを共有すると、複数メンバーが資料を追加し、チャットを作れます。便利さと同時に、誰が正本を変えたか分からなくなるため、変更申請、レビュー、反映日を外部台帳でも残します。機密度が高い資料は、Projectsへ置けるかを契約、社内規程、保持条件から別途判断します。

運用指標はProject数やファイル数ではなく、旧版を引用した件数、根拠を示せなかった件数、人が修正した時間、回答不能として正しく保留できた割合を使います。改善時は資料追加だけでなく、不要資料の削除、共通指示の短縮、Projectの分割を候補にします。三か月使われないProjectは、所有者へ継続理由を確認してarchiveし、一覧から現役の正本を見つけやすくします。

よくある質問

Projectは何個作ればよいですか？

部署数ではなく、使う正本と完成条件が変わる地点で分けます。管理者が月次棚卸しできない数へ一度に増やしません。

知識ベースへ全部の社内資料を入れるべきですか？

いいえ。対象業務に必要で、利用許可と更新責任が明確な正本だけを入れます。不要な情報は取得精度と管理負荷を下げます。

共有Projectなら出力確認は不要ですか？

不要にはなりません。顧客送信、価格、契約、人事、本番変更は、影響に応じた人間承認を残します。

関連ガイドと公式情報

長文資料の絞り方はClaudeのコンテキスト管理、入力の境界はClaudeに入力してはいけない情報、全社ルールはClaude社内利用ガイドラインを参照してください。

機能はAnthropic公式What are projects?、作成・移動・共有・archiveは公式How can I create and manage projects?、共有条件は公式Project visibility and sharingで公開直前に確認してください。

Miraigentの無料診断では、Projectの目的、正本、共通指示、共有範囲、更新責任を一枚にし、資料を迷子にしない運用へ整理します。