Claude Projectsフルコース：基礎から応用まで5モジュール解説

Claude Projectsの使い方を学びたい（フルコース）私はClaude Projectsに関する全てのリソースを集め、フルコースを作成した。15分以内に、Claudeを「全てを忘れる金魚」ではなく「持続的な専門コワーカー」に変える方法がわかる。この記事を読み終えた後、あなたはユーザーの99%よりClaude Projectsを理解しているはずだ（本当に）。ほとんどの人はProjectsにファイルを放り込んで、うまくいくことを祈っている。それではこの機能から価値を得られない。これからProjectsのフルコースをお伝えする——実際に何をするのか、どう構造化するか、SkillsやMCPと組み合わせて複利で効くワークフローをどう構築するか。この記事の使い方： Module 1: 基礎（Projectとは実際に何か） Module 2: ナレッジアーキテクチャ（何をアップロードし、何をしないか） Module 3: 実際に機能するカスタム指示 Module 4: Projects vs Skills vs MCP（正しいツールの選び方） Module 5: チームProjectsとプランの違い ## Module 1: 基礎 ### Projectとは実際に何か Claude.aiのProjectは、3つのコンポーネントを持つ永続的なワークスペースだ： - カスタム指示——Projectの全会話の冒頭でClaudeが読むテキストブロック。あなたの声、あなたのルール、あなたのコンテキスト。 - プロジェクトナレッジ——一度アップロードすれば、そのProject内の全会話でClaudeが参照するドキュメント。 - チャット履歴——すべての会話がProject内に残り、メインのチャットリストとは分離される。それだけだ。3つ。ほとんどの人は2つしかうまく使っていない。 Projectをコワーカーのオンボーディングだと思え。新しい採用者にスタイルガイドを毎朝読み直させたりしない。一度渡して、ルールを伝えて、覚えていることを期待する。Projectsも同じだ。 Projectsが解決する問題：デフォルトではコンテキストはチャット間で共有されない。Projectなしでは、新しい会話は毎回ゼロから始まる。スタックを説明し直し、同じPDFを再アップロードし、声を再び説明する。ProjectsはそのタスクコストをAI的に永続的に消す。 ### Projectをいつ使うか全タスクにProjectが必要なわけではない。判断基準はこれだ： - 一度だけ会話して二度と戻らない場合→通常チャットを使え - 数週間から数カ月にわたって同様の会話を繰り返す場合→Projectを使え - 複数の人が同じコンテキストから作業する必要がある場合→共有チームProjectを使え Projectに向いているもの：特定のクライアントアカウント、何度も参照する研究領域、作業するコードベース、定期的なコンテンツワークフロー、執筆中の本、管理している法的ケース。 Projectに向いていないもの：一度要約するだけのドキュメント、簡単な質問、長期保存すべきでない機密情報。 ### RAGが全てを変える理由ほとんどの人が知らない機能がここにある。 Projectsには厳しい上限があった：200Kトークンのナレッジ（約500ページ）。それを超えると詰まった。有料プラン（Pro、Max、Team、Enterprise）では、ProjectsはRetrieval Augmented Generation（RAG）で自動スケールする。ナレッジがコンテキスト制限に近づくと、ClaudeはシームレスにRAGモードを有効にし、応答品質を維持しながら容量を最大10倍に拡張する。実際には：コードベース全体、全ケースファイル、1年分のミーティングノートをアップロードできる。Claudeは全てをクエリごとにコンテキストにロードするわけではない。質問ごとに関連チャンクを取得する。より速い応答、より大きなナレッジベース、品質劣化なし。 Freeユーザーにはこれがない。通常のコンテキストウィンドウ上限の5プロジェクトしか使えない。有料ユーザーはRAG自動スケーリング付きの無制限プロジェクトが使える。Projectsを本気で使うなら、これだけで$20/月の価値がある。 ## Module 2: ナレッジアーキテクチャ Projectsの90%が失敗するのはここだ。人々はナレッジベースをゴミ捨て場として扱う。違う。 ### プロジェクトナレッジの良い候補参照素材となるものをアップロードしろ——安定していて、再利用可能で、何度も引用する価値があるもの： - スタイルガイドとボイスガイド - 再利用するテンプレート（委任状、提案書のスケルトン、SOAPノート） - 常に引用するポリシードキュメント - 誇りに思う仕事の例（Claudeは説明より例からの方が基準を早く学ぶ） - 使用するライブラリのAPIドキュメント - プロダクト仕様書、ブランドガイドライン、アーキテクチャの意思決定記録判断基準：このタイプの作業を始める度に引き出しからこのドキュメントを取り出すか？イエスなら、プロジェクトナレッジに属する。 ### 悪い候補作業中のドキュメントはアップロードするな——頻繁に変更されるもの、一つのチャットにしか適用されないもの、長期保存すべきでないもの： - 個別のクライアントファイルや患者記録 - 一度限りの案件ドキュメント - 永続化すべきでない機密情報 - 積極的に編集中のドラフトコンテンツ - 個人識別情報、財務情報、APIキーこれらはチャット自体に属する。永続ナレッジには属さない。 ### サポートされる形式と制限 Claude ProjectsはPDF、DOCX、CSV、TXT、HTML、Markdown、コードファイルなどをサポートしている。個別ファイルは最大30MB。有料プランでは無制限のファイルをアップロードできる（RAGがスケールを処理する）。ファイル名は取得に重要だ。style-guide-v3-final.pdfはbrand-voice-guide.pdfより劣る。Claudeはファイル名を見る。説明的にしろ。 ### 取得のための構造化司書のように考えろ。関連ドキュメントをグループ化しろ。ファイル名は具体的で一貫性を持たせろ。20以上のドキュメントがある場合は、カテゴリをプレフィックスとして付けろ：ref-brand-voice.md、ref-api-endpoints.md、template-proposal.md、template-email.md、example-success-story-1.md。これはRAGが機能するときにClaudeが正しいチャンクを見つける助けになり、後でProjectをメンテナンスするときに物を見つける助けにもなる。黄金律：一つの集中したProjectは五つの詰め込みすぎたProjectに勝る。ナレッジベースが無関係なドメインにまたがる場合は分割しろ。 ## Module 3: 実際に機能するカスタム指示カスタム指示ブロックはProjectで最も重要な部分だ。これをうまくやればClaudeは訓練された専門家のように振る舞う。失敗すると、ただのファイル付きチャットボットになる。 ### 長さ：200〜500語短すぎると曖昧になる。Claudeが汎用的な行動でギャップを埋める。長すぎると長い会話でClaudeが部分を失い始める——モデルは文字通り長すぎる指示ブロックの部分を忘れる。 ### 構造：プロフィール、ボイス、ルール、フォーマットこの4部構成が機能する： - プロフィール——あなたが誰で、Projectが何のためかを説明する。 - ボイス——Claudeがどのように聞こえるべきか。具体的に。「プロフェッショナル」ではなく、「パンチの効いた短い文、専門用語なし、一人称、『delve』や『leverage』は絶対使うな」。 - ルール——Claudeが絶対にやらなければいけないこと、絶対やってはいけないことを明記する。 - フォーマット——出力がどのように見えるべきかを指定する。 ### エッセイではなくルールを書け Claudeは長いコンテキストの段落より短い指示に対してより良く応答する。「TypeScript strictモードを使え」は、なぜかを説明する段落よりも効果的だ。 ### 「やってはいけない」リストを使え Claudeに避けるべきことを伝えることは、やるべきことを伝えるより効果的なことが多い。「フレームワークを切り替えることを提案するな」は、正面からの指示が見逃す一般的なイライラを防ぐ。「絵文字を使うな。」「『場合による』でヘッジするな。」否定的な指示は突き通る。 ### 毎週反復しろ最初のバージョンは完璧にはならない。3〜5回の会話の後、パターンに気づくだろう：Claudeが同じミスを繰り返したり、含められたはずのコンテキストを毎回尋ねたりする。二度修正した内容に気づくたびに指示を更新しろ。追加するすべての修正は二度としなくていい修正だ。これは急速に複利で効く。毎月：ブロック全体を読み直せ。古くなったものを削除しろ。標準化したものを追加しろ。 ### プロフィール設定を重複させるな Claudeは今、すべての会話に適用されるグローバルプロフィール設定をサポートしている。すでにグローバル設定に「私の推論に常に挑戦して」がある場合、すべてのProjectで繰り返すな。Project指示はグローバル設定の上に積み重なる——コンテキストを追加するものであり、置き換えるものではない。 ## Module 4: Projects vs Skills vs MCP ほとんどの人はProjectsを何にでも使う。これは間違いだ。Projectsは3つのツールのうちの一つであり、それぞれが異なる役割を担っている。 ### Projects = ナレッジベース Projectsは「Claudeは何を知る必要があるか？」という質問に答える。静的な参照素材。ブランドガイドライン。テンプレート。ドキュメント。Claudeが引用するが実行しないもの。 Projectsは図書館だと思え。 ### Skills = 手順書 Skillsは「Claudeはこの特定のタスクをどのように実行するか？」という質問に答える。手続き的。反復可能。毎回同じように実行するステップバイステップのワークフロー。 Skillsを訓練された従業員だと思え。「weekly-newsletter」というSkillは正確なシーケンスを知っている：今週の更新を引き出し、このボイスでドラフトし、これらのセクションを追加し、このプラットフォーム向けにフォーマットし、この構造で出力する。 Projectsは参照素材を保持する。Skillsはそれを使うワークフローを定義する。 ### MCP = 接続レイヤー MCP（Model Context Protocol）は「Claudeはどのライブデータとツールにアクセスできるか？」に答える。リアルタイム。ダイナミック。Claudeをカレンダー、データベース、受信トレイ、コードベースに接続する。 Projectはあなたのブランドボイスを知っている（静的）。Skillはニュースレターの書き方を知っている（手続き的）。MCPサーバーはGitHubリポジトリから今週の実際のプロダクトアップデートを引き出す（ライブデータ）。 ### 3つを組み合わせるここからが強力になる。コンテンツクリエイター向けの実際のワークフロー： - Project：「Newsletter Workspace」——ブランドボイスガイド、例として過去20本のニュースレター、購読者ペルソナドキュメント、編集カレンダーを含む。 - Skill：「draft-newsletter」——手続き的ワークフロー。ステップ：先週のニュースレターを確認し、MCP GitHubコネクタから新しいコンテンツを引き出し、3セクション（製品、業界、コミュニティ）をドラフトし、ブランドボイスを適用し、Markdownで出力する。 - MCPサーバー：GitHub（コミットとリリースをフェッチ）、Gmail（購読者の返信を確認）、Brave Search（業界ニュース）。一つのプロンプトがSkillを起動する。SkillはMCPを使ってライブデータを引き出す。Projectがブランドボイスと例を提供する。一発で、具体的で最新でブランドに沿ったドラフトが手に入る。 ### 判断のフローチャート - タスクにClaudeが繰り返し引用する参照素材が必要か？→ Project - タスクに反復可能なステップバイステップのワークフローが必要か？→ Skill - タスクにライブで変化するデータや外部ツールが必要か？→ MCP - 3つ全てが必要か？→ 組み合わせろほとんどの人はProjectsで止まる。3つを組み合わせる1%の人たちは、別次元でClaudeを使いこなしている。 ## Module 5: チームProjectsとプランの違い ### Free vs 有料 - Freeユーザー：標準コンテキストの5プロジェクト。RAGなし。共有なし。 - Pro（$20/月）：無制限プロジェクト、RAG自動スケーリング（10倍容量）、Projects内でのチャット全体の記憶。 - Max（$100〜200/月）：Proの全て＋プランによって5〜20倍高いメッセージ制限。 - Team（$30/シート/月）：Proの全て＋共有Projects、チームナレッジベース、管理者コントロール、全シートにClaude Codeアクセス。 - Enterprise：Teamの全て＋SSO、監査ログ、データ保管場所コントロール、高度なセキュリティ。 ### チームProjects：3つの権限レベル TeamとEnterpriseプランでは、3つの権限レベルでProjectsを共有できる： - 閲覧可能——メンバーはプロジェクト内容を見て、ナレッジにアクセスし、Project内でチャットできるが、変更は不可。 - 編集可能——メンバーは指示を修正し、ナレッジを更新し、積極的に貢献できる。 - オーナー——作成者が共有、公開設定、全設定を管理する。 ### 公開設定 TeamまたはEnterpriseでProjectを作成する際に選択する： - プライベート——自分と招待したメンバーのみがアクセスできる。 - 組織全体に共有——管理者が有効にした場合、組織の全員が閲覧・利用できる。 ### 記憶との相互作用 Claudeの記憶システムは、各Projectの個別の記憶サマリーと、Project外のチャット用サマリーを維持するようになった。これはあなたの「クライアントA」Projectが「クライアントB」Projectにコンテキストを漏らさないことを意味する。 ### 実際のチームワークフロー - プロダクトローンチProject：仕様書、競合分析、メッセージングドキュメント。プロダクトとマーケティングチーム全体と共有（閲覧可）。PMとマーケティングリードには編集アクセス。 - クライアントアカウントProject：ブランドガイドライン、過去の納品物、コミュニケーション履歴。クライアント1社につき1Project。アカウントチームのみと共有。 - エンジニアリングプレイブックProject：アーキテクチャの決定、コーディング基準、デプロイ手順。組織全体の閲覧アクセス、プラットフォームチームの編集アクセス。 - リサーチハブProject：競合レビュー、ユーザー調査、顧客フィードバック。プロダクトとデザインチームと共有。毎朝PDFをClaudeに放り込んで自己紹介し直すことを続けることもできる。あるいは、一つのProjectを正しく設定するために30分を使うこともできる。4部構成のカスタム指示。3〜4つの参照ドキュメント。毎週更新。今日、最初のProjectを作れ。最もよく繰り返すワークフローを選べ。Module 3の4部構成に従え。2〜3つの参照をアップロードしろ。使い始めろ。

Claude Projectsフルコース：基礎から応用まで5モジュール解説

AIFCC — AI Fluent CxO Club