Claudeを仕事で使っていると、顧客の背景や文章のルールを毎回説明し直す手間が気になってきますよね。
Claude Projectsを使えば、資料と指示を案件ごとにまとめ、その前提で複数のチャットを進められます。無料アカウントでも使える機能なので、まず一つの継続案件で試すのがおすすめです。
Projectの分け方から設定手順、チャット間で共有されない情報、共有時の権限まで順に整理します。
Claude Projectsは案件別の作業場所を作る機能
Claudeを仕事で使い始めると、同じ説明を何度も入力する場面が増えてきます。たとえば、顧客の事業内容、文章の読者、使ってよい用語、納品形式などです。
通常のチャットだけで運用していると、必要な資料がどの会話にあるのか分かりにくくなり、別案件の前提を混ぜる原因にもなります。
Claude Projectsは、この問題を整理するための機能です。Projectは独自のチャット履歴と知識ベースを持つ、自己完結した作業スペースと考えると分かりやすいでしょう。
Projectごとに資料を追加し、共通の指示を設定し、その前提で複数のチャットを進められます。
継続して扱う案件や業務がある人は、通常チャットを増やす前にProjectの単位を決めておくと整理しやすくなります。役割分担の基本は次のとおりです。
Project knowledgeには繰り返し参照する資料、project instructionsには継続ルール、各チャットには今回の具体的な依頼を書く。この三つの分担が、Project運用の土台になります。
Projectsは有料ユーザーだけの機能ではありません。無料アカウントを含むすべてのユーザーが利用でき、無料ユーザーは最大5件のProjectを作成できます。
まず一つの継続業務で試し、運用しやすい分け方が見えてから増やしていく方が現実的です。
最初に決めるべきは「何を一つのProjectにまとめるか」
Projectを作る前に、どの仕事を同じ前提で扱うかを決めましょう。名前だけ先に作ってしまうと、異なる顧客や用途の資料が一つの知識ベースへ集まりやすくなります。
個人事業主なら、顧客やブランド単位で分けるのが一番分かりやすいでしょう。
ほかにも、ブログやメルマガや講座運営といった業務ごと、四半期レポートや定例会議のように繰り返す仕事ごとに分ける方法があります。
学習や調査のように、参照資料を継続して使う目的で一つ作るのも手です。
判断基準は「同じ資料と同じ回答ルールを使うか」です。資料も文体も異なる仕事はProjectを分けた方がよく、同じ前提で複数の成果物を作る仕事は一つにまとめやすいでしょう。
Project名と説明は、人が管理しやすいように付けます。ここで注意したいのが、Claude自身はProjectの名前と説明を参照しない点です。
Claude Projectsを作成して共通知識を設定する
設定の流れは、Projectを作る、knowledgeへ資料を入れる、instructionsに回答ルールを書く、の3段階です。
どれも数分で終わる操作ですが、何を入れて何を入れないかの判断で、その後の使いやすさが変わります。最初から多数のProjectを作るより、継続案件を一つ選んで試す方が設定の過不足を見つけやすいでしょう。
Projectを新規作成する
基本の手順は次のとおりです。
Claudeの左側にある「Projects」を開くか、claude.ai/projectsへ直接移動してください。
画面右上の「+ New Project」を選び、Projectの名前と説明を入力します。
TeamまたはEnterpriseプランの場合は、非公開にするか組織へ共有するかを選びます。個人プランでは、この選択肢は表示されません。
作成したProjectを開き、その中で新しいチャットを始めます。以降、このProjectで始めたチャットはすべて同じknowledgeとinstructionsを参照します。
画面表示は更新される可能性があるので、ボタン名や配置が違う場合は公式ヘルプと現在の画面を照らし合わせてください。
Project knowledgeへ資料を追加する
Projectのメイン画面右側に知識ベースがあり、「+」から資料を追加できます。
文書、テキストファイル、コードの断片などを入れられ、追加した内容はProject内のすべてのチャットで文脈として使われます。
実務でknowledgeに置く候補は、次のような資料です。
- サービスや商品の基本説明
- 読者像、顧客像、ブランドの前提
- 用語集や表記ルール
- 過去に確定した方針や要件
- 作業で継続して参照する仕様書
一方、毎回変わる締切、今回だけの依頼、未確定のメモまで共通知識へ入れると、古い条件が残りやすくなります。
knowledgeには「今後の複数チャットでも参照する資料」を置き、単発の条件はそのチャットで伝える。この線引きが整理のポイントです。
資料を追加した後も、Claudeの回答が必ず正しいとは限りません。重要な数値や契約条件、顧客へ出す文章は、元資料へ戻って人が確認する工程を残してください。
Project instructionsには継続ルールを書く
Project画面の「Set project instructions」から、Claudeに継続して守ってほしい回答方針を設定できます。「Save instructions」で保存した指示は、そのProject内のすべてのチャットで使われます。
たとえば「読者をIT初心者として説明する」「結論を先に書き、その後に理由と手順を示す」「専門用語には短い説明を添える」といった内容です。
不明な情報は推測せず確認事項として分ける、出力は見出し・本文・確認事項の順にする、といった出力の型もここに書けます。
instructionsへ案件資料そのものを長く貼るより、回答の作り方や判断ルールを短くまとめる方が更新しやすくなります。ルールが増えてきたら、重複や矛盾がないかを定期的に見直しましょう。
チャットを分けても共有される情報・されない情報
Project運用で誤解しやすいのが、同じProject内ならすべてのチャット内容が自動的に共有される、という思い込みです。
実際には、Project knowledgeへ追加していない情報は、Project内の別チャット間で共有されません。
チャットAで決めた内容をチャットBでも確実に使いたいなら、必要な情報をknowledgeへ追加するか、チャットBへ改めて伝える必要があります。
共有範囲は次のように整理できます。
- Project knowledge
-
Project内の複数チャットで使う共通資料。
- Project instructions
-
Project内の複数チャットで使う回答ルール。
- 各チャットの会話
-
その会話で扱う依頼と経緯。別チャットへは自動で引き継がれない。
なお、Free、Pro、Maxプランのウェブ版やアプリでは、過去のチャットを参照するmemory機能が標準で有効です。
memoryはProjectごとに分かれて持たれますが、会話の要約をもとにした補助的な仕組みにすぎません。確定した方針を確実に反映したいなら、memory任せにせずknowledgeへ入れる方が安全でしょう。
重要な決定を会話の中だけに残すと、別チャットから見えない場合があります。確定した方針は元の管理資料へ反映し、必要に応じてknowledgeも更新する運用にしておくと安心です。
既存チャットをProjectへ移す
すでに通常チャットで始めた仕事も、チャット名の横にあるメニューから「Add to project」を選べばProjectへ移動できます。
表示される「Move chat」の画面で移動先を検索して選ぶ形です。チャット履歴のページからは、複数のチャットを選んでまとめて移すこともできます。
移動前に、その会話が本当に同じ案件の内容だけかを確認しましょう。複数顧客の情報が混在する会話を一つのProjectへ移すと、整理した意味が薄れてしまいます。
チャットごとの目的を一つに絞る
同じProject内でも、構成案、本文、確認作業を別チャットに分けると履歴を追いやすくなります。
Projectが共通資料とルールを持っているので、チャットを分けても同じ土台から始められるのが便利なところですね。
ただし、前のチャットで決めた細かな内容が、自動的に次へ引き継がれるとは限りません。次の工程に必要な決定は短くまとめ、次のチャットに渡すか共通資料へ反映してください。
実務で使いやすいProject設計例
個人事業主が自社メディアを運営するなら、「自社ブログ」というProjectを作る形が分かりやすいでしょう。
読者像、カテゴリ方針、文体ルール、避ける表現などをknowledgeとinstructionsへ分けて置きます。記事ごとのキーワード、締切、今回の構成は個別チャットで扱います。
顧客案件では、「顧客A」と「顧客B」を分けましょう。各Projectには、その顧客から使用許可を得た資料だけを入れます。
納品形式や表記ルールをinstructionsへ置いておけば、毎回の説明を減らせるのが助かるところです。
定例業務なら、「月次レポート」のProjectを作り、指標の定義や報告書の型を共通化できます。月ごとのデータは個別チャットで渡し、古いデータをknowledgeへ残す必要があるかはその都度判断します。
どの例でも共通するのは、AIだけを正式な保管場所にしないことです。
確定資料は自社のファイル管理や業務システムに残し、Projectは作業を進めるための参照場所として使うと役割が明確になります。
無料アカウントと有料プランの違い
無料ユーザーもProjectsを利用できますが、作成できるProjectは最大5件です。
有料のPro、Max、Team、Enterpriseでは、knowledgeがコンテキスト上限に近づくとRAGと呼ばれる仕組みが自動で有効になります。
これにより、扱える容量を最大10倍まで拡張できるとされています。RAGは、必要な情報を検索して回答へ使う仕組みです。
| プラン | Project作成数 | RAGによる容量拡張 | Project共有 |
|---|---|---|---|
| Free | 最大5件 | なし | なし |
| Pro、Max | 上限の明記なし | あり(最大10倍) | なし |
| Team、Enterprise | 上限の明記なし | あり(最大10倍) | あり |
無料で5件の上限に近づいたら、完了した案件のProjectをアーカイブする方法があります。アーカイブしたProjectは一覧の下部に移り、会話はそのまま参照できます。
ただし、アーカイブ状態のままでは削除できないため、完全に消したい場合は一度アーカイブを解除してから削除してください。
最大容量を前提に資料を詰め込むより、現在の仕事に必要な資料だけを残す方が管理しやすくなります。
プランや機能は変更される可能性があるので、契約判断の前には公式のProjects案内と料金ページを確認しておきましょう。
共有と機密情報で注意したいこと
Projectの共有機能はTeamまたはEnterpriseプラン向けです。組織全体で使える公開Projectと、招待されたメンバーだけが使える非公開Projectを選べます。
招待メンバーの権限は「Can view」と「Can edit」の2種類です。
| 権限 | できること |
|---|---|
| Can view | Projectの内容、knowledge、instructionsを閲覧し、Project内でチャットできる。編集はできない |
| Can edit | instructionsやknowledgeの変更、メンバー設定の更新など、Projectの編集全般ができる |
資料を変更する必要がない人へは、最初から編集権限を渡さない方が管理しやすいでしょう。
もう一つ押さえておきたいのが、共有Projectでも各メンバーのチャットは標準では共有されない点です。Projectや知識ベースを共有しても、チャットは利用者が明示的に共有しない限り非公開のままです。
Projectの共有と個別チャットの共有は、別の設定として確認してください。
機微な情報の扱いについては、個人向けClaudeの公式ヘルプが慎重な共有を促しています。対象は、金融情報、健康情報、パスワードやログイン情報、機密性のある業務文書などです。
Projectへ資料を追加する前に、次を確認しておくと安心です。
- 顧客や組織のルール上、外部AIへ入力してよい情報か
- 氏名、連絡先、認証情報などを削除または置換できるか
- Projectの公開範囲と参加メンバーが適切か
- Claudeのプライバシー設定が運用方針と合っているか
- 回答や生成物を人が確認する担当が決まっているか
入力できることと、入力してよいことは同じではありません。判断がつかない資料は追加せず、管理者や情報管理の担当者へ確認しましょう。
Claude Projectsが向いている人・向かない人
Projectsが向いているのは、同じ資料やルールを使って複数回Claudeとやり取りする人です。
- 顧客ごとに前提資料や納品ルールが決まっている継続案件がある
- ブログやメルマガなど、同じ文体ルールで定期的にコンテンツを作る
- 月次レポートのように、同じ指標や型で繰り返す調査・報告がある
一方、次のような使い方なら、通常チャットと短いテンプレートでも足りる場合があります。
- 単発の質問や調べ物が中心で、前提資料をほとんど使わない
- 案件ごとに参照資料が変わらず、共通化するものが少ない
- 厳格な文書管理、承認履歴、アクセス監査が必要な業務
Projectを細かく分けすぎると、どこに資料を置いたか探す作業が増えてしまいます。
厳格な管理が必要な業務では、Projectsだけで完結させず、正式な資料管理は既存の業務システムで行い、Claudeには必要な範囲だけを渡す形がよいでしょう。

Projectsを使わない代替手段
単発作業なら、通常チャットの冒頭に共通テンプレートを貼る方法があります。前提が短く、再利用回数が少ないなら、この方が手軽です。
資料の正本を管理する目的には、クラウドストレージや社内の文書管理を使います。Claude Projectsは資料を参照して作業する場所であり、版管理や社内承認の仕組みを置き換えるものではありません。
複数のAIツールを使う場合は、共通ルールを外部の文書にまとめ、必要な部分を各サービスへ渡す方法もあります。一つのAIサービスだけに前提を閉じ込めたくない場合に向いています。
まとめ
Claude Projectsを使う目的は、チャットを増やすことではなく、仕事ごとの前提を混ぜずに再利用することです。
Project knowledgeには繰り返し使う資料、project instructionsには継続ルール、個別チャットには今回の依頼。この役割分担を守るだけで、資料の置き場所に迷う時間はかなり減ります。
最初は一つの継続案件で試し、別チャットにも必要な情報がknowledgeへ入っているか、instructionsが長くなりすぎていないかを確認してください。
共有する場合は、Projectの公開範囲、メンバー権限、個別チャットの共有状態を別々に見直しましょう。この三つを整理できれば、Projectsは単なるチャット置き場ではなく、再利用しやすい仕事の作業場所になります。

