Claude Projectsで業務ナレッジを永続化する：毎回ゼロから説明しない仕組みの作り方
Claudeに「うちの会社では〜」と説明するたびに、同じことを繰り返していないだろうか。業務の前提、担当者のクセ、使っている用語——毎回の説明コストは積み重なれば、月に数時間単位の損失になる。
Claude Projectsは、この問題に答える機能だ。プロンプト設計の改善ではなく、業務知識をAIに永続的に渡すインフラ設計の問題として捉えたとき、Projectsの本当の使い方が見えてくる。
通常会話との本質的な違い — 「コールドスタート」問題
通常のClaude会話はコールドスタートだ。会話を閉じると、Claudeは何も覚えていない。次の会話で同じ背景を説明しなければ、的外れな答えが返ってくる。この繰り返しは、見えにくいコストとして積み重なる。
Claude Projectsは、この「毎回ゼロから」を終わらせる仕組みだ。プロジェクト内に作成した会話すべてに、共通の3要素が自動で引き継がれる。
- カスタムインストラクション（Project Instructions）: Claudeへの役割・制約・文体を1度設定すれば全会話に適用。「あなたは当社のコンテンツチームの一員です。全文は1,200字以内、結論から書いてください」のように定義する。
- ナレッジベース（Project Knowledge）: 就業規則・製品仕様書・過去提案書などをアップロードすると、全会話でその内容を参照できる。
- 会話の整理: プロジェクト内の複数会話が同じワークスペースとして管理される。業務ごとに会話を分けながら、すべてが同じナレッジを共有する。
「毎日新しい人に一から説明するのではなく、Claudeが数年来のチームメンバーのように、あなたの仕事をすでに知っている状態」。これがProjectsの核心だ。
図1: 通常会話はコールドスタート。Projectsでは前提が全会話で引き継がれる
ナレッジベースの正しい設計 — 「何を入れるか」で成否が決まる
Projectsのナレッジベースには、PDF・Word・CSV・TXT・HTML・EPUBなどのファイルを入れられる。1ファイルあたり30MB、ファイル数の上限はない（コンテキストウィンドウ内に収まる量が実用上の上限）。テキストの直接貼り付けも可能で、Custom GPTsよりフレキシブルだ。
ただし「何でも入れればいい」わけではない。ナレッジとして機能するのは、更新頻度が低く、複数の会話で繰り返し参照される情報に限られる。
入れるべき情報の例：
- 自社の商品・サービスの仕様書（FAQ化したもの）
- コンテンツの文体ガイドライン・用語集
- 社内SOP（標準作業手順書）の最新版
- 過去の提案書・報告書のサンプル3〜5本
- コーディング規約・アーキテクチャ設計書（開発用途の場合）
入れるべきでない情報の例：
- リアルタイムの在庫・売上データ（静的ファイルなので更新されない）
- 個人情報・機密契約書（ファイルの扱いに注意が必要）
- 「あれば便利かも」という曖昧な資料（ナレッジが多すぎると参照精度が落ちる）
Lat91では、社内エージェントチームの設定情報（各エージェントの役割・ツール一覧・連携ルール）をProjectsのナレッジに入れて管理している。毎回プロンプトに書き直す必要がなく、メンバーの誰がClaudeに聞いても同じ前提で動く。これが実感として最も効いた使い方だ。
4ステップで始めるProjects設定
図2: Projectsの4ステップ設定
Step 01: インストラクションを書く
最初にClaudeへの「役割定義」を書く。ポイントは3つ。（1）誰として動くか（例：「あなたはLat91の採用担当アシスタントです」）、（2）何をしないか（例：「応募者の個人情報をそのままOutputに含めないでください」）、（3）出力のルール（例：「200字以内で箇条書き、です・ます体」）。これだけで効果が変わる。
Step 02: ナレッジファイルを整える
資料をそのままアップロードするだけでは効果が薄い。「Claudeが参照しやすい構造」に整えることが重要だ。具体的には、章立てに見出しをつける、専門用語に簡単な説明を添える、FAQのように「問い→答え」の形式にまとめる、の3点を意識する。
Step 03: 1業務1プロジェクトの原則
「何でも1つのProjectに入れる」は失敗パターンだ。ナレッジが混在すると参照精度が落ち、インストラクションが曖昧になる。法務・採用・マーケティング・開発は別々のProjectとして切り分けるのが原則。会話数が増えてもコンテキストを圧迫しない。
Step 04: チームと共有する
Teamプランでは、ProjectをEdit（編集権限）またはView（閲覧のみ）でチームメンバーと共有できる。全員が同じインストラクションとナレッジを使うため、「担当者によって回答が違う」という問題がなくなる。ナレッジを1か所で更新すれば、全メンバーに即反映される。
業務別の活用テンプレート
Projectsの使い方は業務によって異なる。以下は、導入効果が確認されている5つの業務別テンプレートだ。
| 業務 | インストラクション例 | ナレッジに入れるもの | 期待できる変化 |
|---|---|---|---|
| 法務（契約書レビュー） | 「過去のレビュー済み契約5件を基準に異常条項をフラグし、主要義務をサマリー化してください」 | レビュー済み契約書・NGワード一覧 | 初稿レビューを外注なしで内製化。全員が同一基準でレビュー |
| HR（社内Q&A） | 「就業規則と人事ポリシーを根拠として、社員の問い合わせに回答してください。掲載されていない場合はその旨を明示」 | 就業規則・有給規定・オンボーディング資料 | 担当者への問い合わせが減少。回答品質が均一化 |
| マーケ（コンテンツ） | 「ブランドガイドラインに沿った文体で、ペルソナ定義に基づくコンテンツを生成してください」 | ブランドガイドライン・ペルソナ・過去コンテンツ例 | 複数ライターが書いてもトーンが統一される |
| 開発（コードレビュー） | 「コーディング規約とアーキテクチャ設計書を根拠に、提出されたコードをレビューしてください」 | コーディング規約・設計書・過去PR例 | レビュー基準が統一。新メンバーのオンボーディングが早くなる |
| 営業（提案書作成） | 「過去の成功提案書のパターンに合わせて、入力した課題情報から提案書の構成と骨子を生成してください」 | 成功提案書3〜5本・製品仕様書・競合比較表 | 提案書の初稿作成時間を大幅短縮。ノウハウが組織に蓄積 |
Custom GPTsとの違い — どちらを選ぶか
「ChatGPTのCustom GPTsと何が違うのか」は、もっともよく聞かれる疑問だ。結論は「ナレッジの参照方法が根本的に異なる」。
図3: Claude Projects と Custom GPTs の主な違い
最も重要な違いは「ナレッジ参照方式」だ。Custom GPTsはRAG（検索拡張生成）でナレッジを参照するため、大量の文書では検索精度によって見落としが発生する。Claude Projectsは、コンテキストに収まる限り全文を読み込む。「確実に参照してほしい情報がある場合はProjects、コード実行やリアルタイムWeb検索が必要な場合はCustom GPTs」という使い分けが基本になる。
Projectsを使っても解決しないこと
Projectsへの期待が高まるほど、誤解も増える。以下は、Projectsが解決できない問題だ。正直に言うと、これを理解してから使い始めた企業の方が、定着率が高い。
- リアルタイムデータとの連携: Google DriveやNotionへの直接接続は不可。ファイルの変更は手動で再アップロードが必要。在庫・売上などのリアルタイムデータを参照させたい場合はAPI連携が別途必要。
- 複数SaaSの横断検索: Notion＋Google Drive＋Confluenceを1つのナレッジベースに統合することはできない。各ツールの最新情報を手動でエクスポートして入れる必要がある。
- 本格的な知識管理システムの代替: Notionや社内wikiの代替にはならない。「AIとやり取りする窓口」と「ナレッジを蓄積・管理する場所」は分けて考えるべきだ。
- コンテキストの蓄積: 会話が長くなるとコンテキストが埋まり、前半部分が見えなくなる。長いプロジェクトでは、会話を定期的に短く区切る方がクォータを効率よく使える。
よくある疑問と正直な回答
「プロンプトをちゃんと書けば、Projectsは必要ない？」
確かに、一度限りのタスクや試作段階ではその通りだ。ただし「同じ前提で、複数人が、繰り返し使う」業務になった瞬間に、毎回のプロンプト作成は属人化する。Projectsの価値は、チームが同じ品質でAIを使える再現性にある。
「ナレッジに機密情報を入れても大丈夫？」
これは懸念として正当だ。Anthropicの契約上、Proプランのデータはトレーニングに使われないとされているが、社外秘の契約書や個人情報を入れる場合はEnterpriseプランのデータ管理ポリシーを必ず確認する。Lat91では、氏名・連絡先・個人情報は入れないルールにしている。
「毎回ファイルを更新するのが手間では？」
これは正直、手間だ。Projectsは「静的な知識の管理」に向いている。更新頻度が月1回程度の情報なら問題ない。週次・日次で変わるデータには向かない。仕組みを理解して使うことで、手間のかかる場所を事前に回避できる。
まとめ
- Claude Projectsは「毎回同じ前提を説明する」コストをゼロにする仕組み
- カスタムインストラクション・ナレッジベース・会話整理の3要素がセットで機能する
- Custom GPTsとの最大の違いは「ナレッジ全文読み込み」の確実性
- 解決できないのはリアルタイムデータ連携と複数SaaSの横断検索
- 1業務1プロジェクトの原則で切り分けると、ナレッジの精度が上がる
Lat91では、社内の10体のAIエージェントの設定をProjectsのナレッジとして管理し、チームメンバーが一貫した前提でClaude Code・Slack API・MCP連携を使える環境を作っている。この「再現性のある使い方」がProjectsを単なる便利機能から業務インフラに変えた実感だ。
AIを「試す」段階から「組織で使いこなす」段階に移行したい方は、まずProjectsの設定を1業務で試してみてほしい。