ClaudeのProjectsの使い方｜設定の注意点

こんにちは。Osukeラーニング、運営者の「osuke」です。

Claudeで新しいチャットを開くたびに、同じ資料や書き方を説明していませんか。Projectsの使い方を調べても、知識ファイル、指示、メモリ、RAGの違いが分からず、結局いつものチャットへ戻ってしまうこともあると思います。資料を追加したのに回答へ反映されない、無料でどこまで使えるか分からない、といった疑問もありますよね。

私がすすめたいのは、最初から資料を全部集めるのではなく、一つの仕事に必要な資料と短い指示を置き、三つの質問で確かめる方法です。この記事は2026年9月13日に確認したAnthropic公式資料とXの公開投稿を基にした解説です。私自身の利用実績ではなく、手順中のイベント準備やファイル名は説明用の架空例として示します。

記事のポイント

• Projectsと普通のチャットの使い分け
• 知識ファイルと共通指示の作り方
• RAG・メモリ・参照失敗の確認方法
• 共有と更新で失敗しない運用手順

Claude Projectsの使い方の基本

Projectsは、案件に共通する前提をまとめる場所と考えると理解しやすくなります。まずは用途を決め、資料と指示を分けて整えましょう。

普通のチャットと何が違うか

一回で終わる質問なら、普通のチャットで十分です。Projectsを使う理由は、同じ背景資料を何度も使い、複数の会話を一つの目的へそろえたいときに生まれます。例えば「この一文を短くして」だけなら、専用の作業場所を用意する手間のほうが大きいかもしれません。一方、イベントの案内文、参加者向けFAQ、当日の説明資料を作るなら、対象者や開催条件は共通です。その前提を毎回貼り直す負担が、Projectsを検討する目安になります。

公式のProjects概要では、会話履歴や知識ベースを持つ独立した作業領域として説明されています。ここで区別したいのは、作業場所であるProject、参照する知識、回答方針を伝える指示、その都度のチャットです。箱を作っただけで、自分の意図をすべて理解するわけではありません。背景をまとめる部分と、今回作ってほしいものを伝える部分を分けると、指示が長くなりすぎるのを防ぎやすくなります。

判断に迷うなら、「同じ資料を次回も使うか」「成果物が二つ以上あるか」を自分へ聞いてみてください。これは公式の利用条件ではなく、整理のための私の提案です。どちらも当てはまらなければ、無理にProjectへ移す必要はありません。反対に、一つのチャットが案内文、議事録、別案件の相談まで抱えて探しにくくなったなら、共通資料をProjectへ置き、成果物ごとに会話を分ける余地があります。機能を使い切ることより、次に開いた自分が迷わないことを目指しましょう。

• 一回の相談は普通のチャットでよい
• 繰り返す資料や複数の成果があるときに検討する
• 事実は知識、回答方針は指示、今回の仕事はチャットへ分ける
• Projectを作るだけで情報が整うとは考えない

無料版とRAGの条件を確認

2026年9月13日に確認した英語の公式案内では、Projectsは無料ユーザーも利用でき、無料プランは最大五つとされています。最初から課金を前提にせず、小さな案件で使い方を確かめられます。ただし、Projectを作成できることと、大量の資料を扱う拡張機能が同じ条件で使えることは別です。無料で作成できたからといって、どれほど資料を増やしても同じように動くと期待しないようにしましょう。必要な量と実際の利用画面を見て判断します。

公式のRAG説明では、Pro・Max・Team・Enterpriseが対象です。知識量がコンテキストの限界へ近づくと、自動で関連箇所を探す方式へ切り替わります。RAGは、全資料を常に一度に読む代わりに、質問へ関係する部分を取り出す仕組みです。最大十倍という案内は容量の拡張についてであり、回答の精度や作業速度が十倍になるという意味ではありません。利用者が専用の検索システムを組む必要はないと説明されています。

例えば説明用に二十本の資料を用意したとしても、質問が「参加対象は誰か」なら、全資料の全文章を回答へ盛り込む必要はありません。一方、「全資料の例外条件を漏れなく一覧化して」と頼む仕事では、一つの検索結果だけで完全だと判断できません。資料一覧を先に作り、各資料を確認したか記録するなど、仕事に応じた検証を足します。RAGは便利な参照方法ですが、網羅性の点検を代行した証明にはならない、という区別を持っておくと安心です。

料金の比較へ進むのは、必要な資料が今の条件では収まらない、実際に利用枠で中断するなど、不足が具体的になってからでよいと思います。単にファイルが多いことと、答えが役立つことは同じではありません。まず重複や古い版を整理し、それでも不足するならClaudeの料金とプランの選び方で利用量と支出を比較してください。提供条件は変わるため、申込前には自分のプラン画面と現行の公式案内を照合します。

• 無料の作成件数と有料RAGの条件を分ける
• 容量の倍率を精度の倍率に読み替えない
• 大量資料の網羅確認は別の検証が必要
• 課金前に不要資料と重複を整理する

新規作成は目的を一つに絞る

作成は、ClaudeのProjects画面から新規Projectを選ぶ流れです。公式の作成・管理ガイドには、名前と説明を入力する手順が示されています。ただし、名前と説明はClaudeから参照できないという注記があります。名前を「初心者向けの丁寧な案内文を作る場所」にしても、それだけを回答ルールの代わりにはできません。目的や読者は、後で設定するプロジェクト指示にも明記してください。画面のラベルや配置は利用環境で確認します。

名前は人が見分けるためのもの、と割り切ると決めやすくなります。例えば「仕事全部」より「秋の説明会・参加案内」のほうが、何を入れる場所か判断しやすいですよね。切り分けの軸は、使う資料、読む相手、共有する人です。同じ会社の仕事でも、公開用の案内と社内の人事相談では、扱う情報も共有相手も違います。会社名だけで一つにまとめず、混ざると困るものは別にすることが、整理と情報管理の両方に役立ちます。

最初の案件には、成果が分かりやすく、機密のない小さな仕事を選びます。架空の説明会なら、完成条件を「案内文とFAQを一つずつ作り、日時と参加条件を原資料で確認する」と設定できます。対象外も「申込者の個人情報は扱わない」「外部への送信はしない」と書いておきましょう。何でも頼める箱にするより、終わったかどうかを自分で確かめられる箱にするほうが、試用の良し悪しが見えます。最初の成功を大きく見せる必要はありません。

すでに関連する会話がある場合も、過去の内容を丸ごと正しい前提にするのは避けます。途中案と承認済みの決定が混ざっていないか、別案件の情報が紛れていないかを先に確認してください。引き継ぐなら、確定事項、未決事項、参照先を短いメモへまとめると整理しやすくなります。画面上の会話移動ができる場合でも、移したこと自体は内容の品質確認ではありません。必要な決定だけを取り出す作業には、依然として人の判断が必要です。

• 人が見分けられる案件名を付ける
• 目的と読者はプロジェクト指示にも書く
• 完成条件と対象外を一つずつ決める
• 共有相手や機密性が違う案件を混ぜない

知識ファイルは三つから始める

最初の知識ファイルは、必要な事実、言葉のルール、良い出力例の三種類に絞ると整理しやすいと思います。これは公式の最低件数ではなく、試しやすくするための提案です。説明会なら、開催要項、用語集、承認済み案内の見本が候補になります。必要な資料が一つしかなければ一つで構いません。逆に三つを超えることが問題なのではなく、どの資料が何のために必要なのかを説明できない状態を避けることが大切です。

ファイル名には、用途と版が分かる情報を入れます。「最終版2」より「開催要項_2026-09-13_承認済み」のほうが後から確認しやすいですね。本文にも適用日、管理者、旧版との差分を短く置いておけば、ファイル名だけでは分からない条件を補えます。ただし、日付が新しいだけで内容が正式とは限りません。未承認の改訂案ならその旨を明示し、実際に使う版を人が選びます。アップロードした資料が自動で原本の変更へ追従するとは考えず、更新作業を予定へ入れます。

公式のファイル案内では、Projectのファイルは一つ30MBとされ、チャットへの添付とは別の条件です。また、非PDF文書は基本的にテキスト抽出であり、埋め込まれた画像を読めるとは限りません。アップロード成功と内容の理解は別です。重要な表や図があるなら、値や条件が正しく取り出されるか、小さな質問で確かめてください。ファイルの形式・容量・抽出内容を区別すると、単に再アップロードを繰り返すより原因を絞れます。

例えば開催要項の表に「受付開始九時半、開始十時」と書いてあるなら、最初に二つの時刻を区別できるか聞きます。答えにはファイル名と該当見出しを求め、自分で原本と照合します。図の中にしかない情報が落ちていた場合は、その範囲を読める形式へ整えるか、必要な箇所を別途示します。資料に含まれる個人情報や第三者の著作物も、追加前に利用してよい範囲を確認してください。便利さのために、不要な名簿や契約書まで一緒に入れる必要はありません。

• 事実・用語・見本を必要最小限で用意する
• 用途・適用日・承認状態を明確にする
• アップロード後は既知の内容を一問確認する
• 画像や表の読み落としを原本で点検する
• 原本はProjectとは別に保管する

共通指示を短い型で整える

プロジェクト指示には、どのチャットでも変えたくない方針を置きます。毎回の依頼内容まで全部入れると、案内文を作りたいのか、FAQを作りたいのかが混ざってしまいます。共通部分は「誰のために」「何を根拠に」「どう答え」「不明ならどうするか」の四つから始めると整理しやすいです。「最高の回答を完璧に作って」のような強い表現を増やすより、読み手が確認できる条件を置くほうが、直す場所を見つけやすくなります。

以下は、架空の説明会準備で使うための編集例です。公式の推奨プロンプトや、実測で効果を保証したものではありません。自分の案件へ合わせて、対象読者と資料名を置き換えて使ってください。見本を丸ごと貼る前に、守れない条件が入っていないかも確認します。例えば資料にページ番号がないのに必ずページを出すよう指示すると、不自然な出典を作る原因になります。存在する見出しや項目名を使う形なら、原本へ戻りやすくなります。

共通指示の編集例

• 目的：初めて参加する人向けの説明会案内を作る
• 根拠：承認済みの開催要項と用語集を優先する
• 出力：結論を先に、専門用語は短く説明する
• 確認：日時・料金・条件には資料名と該当箇所を添える
• 不明：資料にない事実を補わず、不明点と確認質問を分ける
• 矛盾：資料同士が食い違う場合は勝手に決めず報告する

個別チャットでは「開催要項を使い、初参加者向けの案内文を300字程度で作成してください。参加条件と未確定事項を分けてください」のように、その回の成果を頼みます。共通指示があるからといって、今回は何を作るかを省略しないことが大切です。逆に毎回同じ注意を書いていると気づいたら、それが本当に全会話へ適用したい条件かを判断して指示へ移します。一回限りの修正を恒久ルールにすると、次の仕事まで不必要に縛ってしまいます。

試した後は、指示を足し続けるより、矛盾する文を減らすところから見直しましょう。「できるだけ短く」と「すべてを詳しく」が並んでいたら、どちらを優先するかを決めます。「通常は短く、根拠の説明を求められたら詳しく」と条件を分けてもよいですね。ただし、指示文だけで誤答や情報漏えいが完全に防げるわけではありません。秘密情報を入れない、重要な結果を確認するなど、利用者側の運用と組み合わせて初めて役立つものです。

Claude Projectsの使い方と注意

設定が終わったら、引き継ぎ、参照の精度、共有範囲を確認します。「入れたから安心」ではなく、期待した動きになっているかを小さく試していきましょう。保存済みの資料、会話からの記憶、共有相手の権限は別々に確認し、一つの設定変更で全部解決すると考えないことがポイントです。

別チャットとメモリを区別する

同じProjectの中にある会話でも、すべての文章がそのまま次の会話へ常時入ると考えないほうがよいでしょう。一方で、「別チャットへは何も引き継がれない」と言い切るのも現在の説明としては不十分です。公式のチャット検索・メモリ案内では、Projectごとの独立した記憶領域や、有料プランでの過去会話検索が説明されています。利用できる機能と設定を確認し、知識ファイルとは別の仕組みとして捉えます。

知識ファイルは人が用意する参照資料、指示は回答方針、メモリは会話から保持される文脈、過去会話検索は必要な履歴を探す機能、と分けると整理できます。このうち重要な決定の正式な保管先を、曖昧なままにしないことが大切です。「前に話したから覚えているはず」で締切や条件を任せると、古い案と確定事項を取り違えたときに気づきにくくなります。記憶の有無を議論するより、どの文書を正式な根拠にするか決めるほうが実務では役立ちます。

架空の説明会で開始時刻が変更されたなら、会話で伝えるだけで終えず、承認済み開催要項と変更メモを更新します。メモには「何が変わったか」「いつ決まったか」「何がまだ未定か」を書きます。次のチャットで「変更メモと開催要項を確認して、案内文へ反映する点を先に挙げて」と依頼すれば、文章を作る前に前提を点検できます。これは機能を疑って毎回すべて貼り直す方法ではなく、間違えると困る数点だけを明示する方法です。

引き継ぎが変だと感じたら、いきなりメモリをすべてリセットせず、参照した資料や保存されている内容を確認しましょう。原因が旧版のファイルなら、記憶の設定だけを変えても解決しません。原因が別案件の会話混入なら、Projectの分け方を見直す必要があります。設定の変更や削除は影響範囲を確認してから行います。大切なのは、メモリを便利な補助として使いつつ、正式な決定や原資料の代わりにしないことです。

• 知識・指示・メモリ・履歴検索を別々に考える
• 全履歴が常に参照されるとは期待しない
• 重要な変更は正式な資料と変更メモへ残す
• 原因確認前にメモリを一括削除しない

資料を読まないときの確認順

資料に書いてあるのに回答が違うときは、すぐに「Claudeが読んでいない」と決めつけず、入れた場所、読み取れる形式、質問の範囲、資料の版を順に確認します。別のProjectへ追加していた、今回だけの添付へ置いていた、図の中の文字が取り出せないなど、同じように見える症状でも原因は違います。上位プランにすれば必ず直る問題でもありません。まず一つのファイルと一つの質問へ絞り、どこまでは確認できるかを見ます。

例えば「参加条件を教えて」で違う返答が出たら、「開催要項の参加対象の項目だけを参照し、条件を三つ以内で列挙してください。見つからない場合は見つからないと答えてください」と範囲を限定します。回答に資料名が付いていても、原本の該当箇所と一致するかは自分で確認してください。公式も誤答や根拠のない引用が起こり得ると説明しており、もっともらしい書式は正しさの証明になりません。

全体比較が必要なときは、いきなり完成レポートを頼むより、資料ごとの確認表から始めます。「ファイル名、確認した項目、見つかった条件、不明点」の四列にすれば、どこを調べていないかが見えやすくなります。その表自体にも漏れがないか原資料一覧と突き合わせます。答えが出なかった箇所を、一般知識で埋めて完成形にするよう急がせないことも重要です。不明が残る状態を許したほうが、間違った内容を確定事項として配る危険を減らせます。

改善しない場合は、機密を除いた小さな再現例で試します。どの資料のどの箇所をどう質問し、どの回答が違ったかを残せば、設定の見直しやサポートへの相談が具体的になります。問い合わせのために元の顧客名簿や社外秘資料をそのまま渡す必要はありません。重要な判断が迫っているなら、AIの修正待ちだけに頼らず、資料の管理者へ確認します。Projectsの目的は確認作業をなくすことではなく、確認する場所を探しやすくすることだと考えると使いやすいでしょう。

• 場所→形式→範囲→版の順に切り分ける
• 一つの資料と既知の質問から試す
• 引用風の表示も原本で確認する
• 分からない部分を無理に埋めさせない

Xの活用例を安全に読み替える

Xの公開投稿には、Projectsを継続業務へ使う提案が見られます。例えばWOLF氏の2026年3月25日の投稿は、共通指示を持つProjectsを繰り返し作業へ使う考え方を示しています。また、Simon Willison氏の2024年10月27日の投稿には、特定のライブラリを適切に使う例をProjectsなどへ渡す提案があります。ここから参考にできるのは、漠然と賢くするより、仕事の前提と具体的な見本を用意するという方向です。

一方で、便利そうなテンプレートをそのまま採用しない注意も必要です。Loshmi氏の2026年4月7日の投稿は、制度などを調べるために、詳細な個人プロフィールを入力する提案を含んでいました。私はこの入力例をそのまますすめません。調査の最初は地域や一般的な条件だけで公式の窓口を探し、個人情報が本当に必要な段階は該当機関の正規の手続きで扱うほうがよいでしょう。投稿に手順があることと、安全性や成果が検証されていることは別です。

さらに、morgan氏の2024年6月26日の投稿には、当時のClaudeと他サービスの資料参照方式を比較する説明があります。しかし現在はClaudeの有料ProjectsにもRAGの公式説明があります。古い投稿の容量や方式を、今の契約条件として転用できません。投稿の日付と、扱っている製品・画面・プランを確認する習慣が必要です。「何年も読まれている情報だから正しい」ではなく、変わりやすい仕様だけは現在の公式資料へ戻るようにします。

今回取得できたのは検索結果に掲載された投稿本文で、直接ページでは本文を十分に取得できませんでした。返信全体や実際の作業環境、効果の再現は確認していません。そのため、四件を利用者全体の評価や性能比較としては扱いません。用途の提案、過剰入力への注意、古い仕様への注意として分けて読むのが妥当です。自分の仕事へ取り入れるなら、個人情報を外し、必要な資料を少量にし、期待する答えが出るかを確かめるところまでを一組にしてください。

• 投稿の用途と、実測された成果を区別する
• テンプレートの個人情報欄を無条件に埋めない
• 古い容量や機能説明は公式の現行条件で照合する
• 少数投稿を全ユーザーの代表とみなさない

共有と更新のルールを決める

共同利用では、誰が読めるかと誰が変えられるかを分けて考えます。公式のProjects案内では、Team・Enterpriseの組織内共有に閲覧と編集の役割が示されています。閲覧できる人もProjectの資料や指示へアクセスするため、「編集できないなら秘密は見えない」という意味ではありません。共有前には、相手に見せてよい資料だけが入っているかを確認しましょう。名前が似た別案件の資料や、不要な個人情報が紛れていないかも点検します。

権限は、実際に担当する仕事へ合わせます。例えば案内文を作る担当者には参照できる範囲を、開催条件を管理する担当者には更新作業を認める、といった役割分担です。全員を編集可能にすると、どの変更が正式か分かりにくくなることがあります。組織での運用方法は管理者と相談し、資料の責任者と確認手順を決めてください。個人契約へ社内資料を移して共有ルールを回避する方法は、便利でも採用しないほうが安全です。

更新時には、原本を保管したうえで、Projectで使う版を明確にします。旧版が残っているなら「比較用」なのか「もう使わない」のかを決め、新版と混同しない状態にします。削除する場合は他の利用者が必要としていないか確認し、正式な保管場所の原本まで消さないようにします。簡単な更新記録は「日付、対象、変更内容、確認者」の四項目で足ります。資料を入れた直後と同じように、変更した条件を一問聞いて、回答が正式版と一致するか試します。

終了したProjectをアーカイブしても、共有相手のアクセス解除にはなりません。公式管理ガイドでは、共有権限やメンバーが保持されると説明されています。退職者や担当を外れた人のアクセスを止める必要がある場合は、共有設定そのものを確認します。「一覧から消えたから誰も見られない」と思い込まないことが大切です。案件の終了時には、成果物の保存、不要データの扱い、メンバーの権限という三点を分けて点検すると、作業後の取り残しを減らせます。

• 閲覧権限でも資料が見えることを前提にする
• 編集担当と正式版の確認者を決める
• 更新日だけでなく承認状態も管理する
• アーカイブとアクセス解除を混同しない
• 業務情報の持ち込みは組織の管理者へ確認する

Claude Projectsの使い方を試す

最初の試用は、一つのProject、必要な資料三種類、短い共通指示、三つの確認質問という小さな構成で始めてみてください。資料数や所要時間は公式の条件ではなく、準備を大げさにしないための目安です。今回の架空の説明会なら、開催要項、用語集、出力見本を用意し、案内文を一つ作ります。すでに資料が整理されていれば少なくて済みますし、まだ前提が決まっていないなら文章生成より先に、その不明点を整理する段階です。

一つ目の確認は、資料に答えがある質問です。「開始時刻と受付時刻を分けて教えて」と頼み、原本と照合します。二つ目は、資料に答えがない質問です。「記載のない駐車料金を教えて」と聞いた場合に、勝手に金額を補わず不明と扱えるかを見ます。三つ目は更新後の質問で、改訂した条件が反映されるかを確かめます。ここで示した質問は説明用であり、これに通ればあらゆる回答が正しいという品質保証ではありません。

評価は文章の見栄えだけでなく、再説明の量、事実修正の数、根拠を確認する手間で行います。三回使って毎回同じ注意を伝えているなら、共通指示へ移す候補です。毎回別の資料を大量に追加しないと動かないなら、Projectの目的が広すぎるかもしれません。逆に単発チャットのほうが早い仕事なら、Projectsを使わないという結論でも構いません。機能を導入した実績より、自分の仕事が整理されたかを優先しましょう。

Claude全体の使い分けを確認したい方は、Claudeのできることと注意点の総合ガイドも参考にしてください。Projectsでまず整えるのは、作業を全部自動化することではなく、繰り返す前提と参照先です。資料を置く、指示を分ける、答えを原本で確かめる。この三つがそろって初めて、次の会話でも使いやすい作業場所になります。今日の一歩は、機密のない一つの案件を選び、「何ができれば成功か」を一文で書くことです。

• 答えのある質問で参照の正確さを確認する
• 答えのない質問で不明の扱いを確認する
• 更新後の質問で旧版との混同を確認する
• 便利さと検証の手間を合わせて評価する
• 向かない仕事は普通のチャットへ戻す