Claude Projectsに社内資料を入れるだけでは、業務で信頼できる回答基盤にはなりません。
資料の正しさ、更新日、対象範囲、回答の確認方法まで設計して初めて、チャットがチームの仕事に組み込めます。
この記事では、Claude Projectsを調査、企画、顧客対応、開発支援などに使うチーム向けに、ナレッジを整える五つのルールと導入手順を示します。
Projectsが解決することと残る課題
Claude Projectsは、チャット履歴、プロジェクト固有の指示、アップロードした資料を一つの作業領域にまとめる機能です。
Anthropicの案内によれば、文書、テキスト、コードなどをプロジェクトのナレッジとして登録し、個々の会話で参照できます。
ナレッジが大きくなると、関連部分を検索して回答に使うRAGが自動的に働く場合もあります。
ただし、検索できることは「登録した情報が正しい」「最新版だけが選ばれる」「結論が業務上妥当である」を意味しません。
古い規程と新しい規程が同居していれば、どちらを優先するかは資料側の設計で示す必要があります。
ルール1 プロジェクトの問いを一つに絞る
最初に決めるのは、どの資料を入れるかではなく、プロジェクトが答える問いです。
「営業に使う」のような広い目的では、見積もり条件、製品仕様、提案文の作成、顧客情報の扱いが一つの場所に混ざります。
「公開済みの製品資料から提案書の下書きを作る」「承認済みのサポート手順から一次回答を作る」のように、入力、出力、利用者を特定します。
| 決める項目 | 記述例 |
|---|---|
| 利用者 | 法人営業と営業支援担当 |
| 入力 | 承認済みの製品資料と公開FAQ |
| 出力 | 提案書の構成案と確認事項 |
| 禁止事項 | 未公開価格、個人情報、契約判断を扱わない |
| 最終確認 | 担当者が原資料と照合してから利用する |
用途を絞ると、不要な資料を入れずに済み、誤った回答を見つけるための評価基準も作りやすくなります。
ルール2 資料を正本、参考、作業中に分ける
プロジェクトのナレッジには、論理的な役割が異なる資料を同列に置かないほうが安全です。
- 正本：現行の規程、承認済み仕様、正式な料金表など、回答の根拠にできる資料です。
- 参考：過去の提案書、事例、議事録など、表現や背景の理解には役立つものの、現在の判断根拠にはできない資料です。
- 作業中：草案、レビュー前の仕様、検討メモなど、内容が変わる前提の資料です。
可能であれば、正本だけをProjectsに置き、参考資料と作業中資料は別のプロジェクトまたは別の保管場所に分けます。
同じ場所に置く必要がある場合は、ファイル名と文書冒頭に状態、担当部門、適用開始日、更新日を記載します。
AnthropicもRAGを使うProjectsでは、内容が分かるファイル名、関連資料の整理、質問時の文書名指定を案内しています。
ルール3 更新責任と廃止手順を先に置く
ナレッジの品質は、登録時よりも変更時に崩れやすくなります。
規程を改定したのに旧版が残れば、Claudeは矛盾する根拠を受け取ります。
各資料には所有者を一人または一部門割り当て、更新周期ではなく変更の起点を決めます。
- 製品仕様をリリースしたら、製品担当が正本を差し替える。
- 価格を承認したら、営業企画が旧版を削除して新しい適用日を確認する。
- 規程を廃止したら、管理部門がProjectsから削除し、関連する指示も見直す。
差し替え後には、旧条件を尋ねる質問と新条件を尋ねる質問の両方を試し、廃止済みの内容が現行情報として返らないか確認します。
ルール4 プロジェクト指示に回答の作法を書く
プロジェクト指示には、人格設定よりも、根拠の扱いと出力の条件を書きます。
次の項目を短く明記すると、レビュー可能な回答に近づきます。
- 登録資料だけで答えるのか、外部情報も使えるのか。
- 根拠にした文書名と該当箇所を示すこと。
- 資料同士が矛盾するときは結論を出さず、矛盾を列挙すること。
- 分からない項目を推測で埋めず、確認質問として残すこと。
- 事実、解釈、提案を分けて書くこと。
- 最終判断が必要な担当者または部門を示すこと。
「丁寧に答える」だけでは、正確さを評価できません。
回答の長さ、必須項目、引用方法、禁止する推測を具体化すると、担当者が変わっても同じ観点で確認できます。
ルール5 代表的な質問で検証を続ける
導入時の印象ではなく、実際の依頼に近い質問で品質を測ります。
Anthropicの評価ガイドも、成功条件を具体的かつ測定可能にし、用途に合う複数の基準で評価するよう勧めています。
業務向けProjectsでは、少なくとも次の四種類を含む質問集を用意します。
- 正本に答えが明記されている通常の質問。
- 複数資料を照合しなければ答えられない質問。
- 資料に答えがなく、「分からない」と返すべき質問。
- 古い資料や権限外の情報へ誘導する質問。
評価では、結論の正しさだけでなく、根拠の追跡可能性、不要な推測の有無、確認先の適切さも記録します。
失敗例が見つかったら、質問を言い換えるだけで済ませず、資料、指示、運用手順のどこに原因があるかを分けて直します。
データ管理はプランと契約に合わせる
Projectsへ登録できる情報と、登録してよい情報は同じではありません。
個人情報、顧客の秘密情報、未公開の契約条件、認証情報、ソースコードなどは、社内規程、契約、利用プランの条件を確認してから扱います。
Anthropicの商用製品向けプライバシー案内では、APIと会話を保存できる商用製品で保持の仕組みが異なり、例外や個別契約もあると説明されています。
したがって、「一律に何日で消える」と覚えるのではなく、利用する製品、アカウント種別、組織設定、契約条件を対応づけて確認する必要があります。
高リスクの消費者向け用途では、人による監督など追加の保護策が求められる場合もあるため、公開前の審査をProjectsの外側に残します。
小さく始める導入手順
- 判断リスクが低く、正本がそろっている一つの業務を選ぶ。
- 目的、利用者、入力、出力、禁止事項、確認者を一枚にまとめる。
- 正本だけを登録し、状態と更新責任をファイルごとに示す。
- プロジェクト指示に根拠、推測、矛盾、出力形式のルールを書く。
- 通常、横断、未回答、誘導の質問で試し、失敗を記録する。
- 利用範囲を広げる前に、削除、更新、権限変更の手順を実行して確かめる。
最初から全社の知識を集める必要はありません。
一つの用途で資料の鮮度と回答の検証を回せる状態を作れば、その運用を別の部門へ移すときも判断基準を保てます。
よくある質問
資料は多いほど回答が良くなりますか
資料の量だけでは改善しません。
重複、旧版、用途外の文書が増えると、検索結果と回答の根拠が不安定になるため、問いに必要な正本を優先します。
RAGが動けば内容の正しさも保証されますか
RAGは関連資料を探して回答へ渡す仕組みであり、資料自体の正確さや業務判断の妥当性を保証するものではありません。
回答には必ず出典を付けるべきですか
契約、価格、仕様、規程のように確認可能性が必要な業務では、文書名と該当箇所を付ける運用が適しています。
アイデア出しでは出典より発想の幅を優先できますが、事実として採用する前には別途確認します。
ProjectsとAPIはどう使い分けますか
担当者が対話しながら調査や草案作成を進めるならProjectsが始めやすく、社内システムへの組み込み、権限制御、ログ、定型処理が必要ならAPIを含む実装を検討します。