Claudeに毎回「自己紹介」させるのに疲れていた。「僕はフリーランスのWebマーケターで、ブログをいくつか運営していて、文体は口語寄りで…」という説明を、会話が変わるたびに入力する作業が地味にストレスだった。
この記事では、Claudeのプロジェクト機能を使ったコンテキスト設計の方法を書く。毎回の説明を省いて、会話をまたいでも背景情報を維持するための設計手順と、実際に僕が使っているプロジェクト構成の実例を公開する。
この記事でわかること：
- コンテキスト設計とは何か（単発プロンプトとの違い）
- Claudeのプロジェクト機能の仕組み
- フリーランスが実際に設計したプロジェクト指示の構成（実例付き）
- 失敗パターンと運用ルール
毎回Claudeに「自己紹介」させるのに疲れた
「フリーランスのWebマーケター・ライターです。クライアントは中小企業が中心で、記事の文体は口語・体験談系で書いています」
これをClaudeに何十回打ち込んだかわからない。しかも毎回微妙に書き方が違うから、返ってくるアウトプットのトーンもバラバラだった。
1ヶ月ほど前にプロジェクト機能を使い始めてから、この問題が完全に消えた。毎回の指示出しが体感で5〜8分短縮されたし、何より「返ってくる文章のトーンが安定した」のが一番大きかった。
コンテキスト設計とは何か（単発プロンプトとの違い）
まず言葉の定義から整理する。
「コンテキスト設計」とは、AIに渡す背景情報を構造化しておく作業のことだ。「この会話でClaudeに覚えておいてほしいこと」を事前に整理して、毎回の会話の冒頭に自動で渡るようにする仕組みづくりと言い換えてもいい。
単発プロンプトとの違いを一言で言うと：
- 単発プロンプト：「今日の会話の中でだけ」有効な指示
- コンテキスト設計：「プロジェクト全体を通じて」有効な背景情報の設計
単発プロンプトは「今すぐやりたいことの指示」であり、コンテキスト設計は「Claudeとの関係性の基盤をつくる作業」だ。
Claudeのプロジェクト機能でできること
Claudeのプロジェクト機能（Claude.aiのProプラン以上で利用可能）は大きく2つの要素からなる。
プロジェクト指示（Project Instructions）
会話全体に反映される動作指示。「どういう役割で動くか」「何を避けるか」「出力フォーマットはどうするか」を設定する。単発の会話に書くより、ここに書いた方が毎回の会話で機能する。
ナレッジ（Project Knowledge）
繰り返し参照したいルール・定義・一次資料・テンプレートを登録する場所。ファイルのアップロードやテキスト貼り付けができる。
この2つを整備することで、「Claudeが自分のことをわかった状態でスタートする」会話が実現できる。
実際に設計しているプロジェクト構成（実例公開）
僕が現在運用しているプロジェクトの構成をそのまま公開する。
ライティング用プロジェクト
プロジェクト指示（約180字）：
あなたはフリーランスWebマーケター・ライターの業務をサポートするアシスタントです。
文体は口語寄り・断定が早い・失敗談を含める。一人称は「僕」。
誇張表現・体言止めの多用・定型の締め文句は使わない。
SEOより読者の体験を優先する視点で書くこと。
ナレッジ登録内容：
- 扱っているカテゴリ一覧（自動化・AIライティング等）
- 過去3本の記事サンプル（文体参照用）
- 自己紹介文（ペルソナ）
これだけ設定したら、毎回の会話の冒頭説明がほぼ不要になった。
クライアント対応用プロジェクト
クライアントごとに別プロジェクトを作っている。プロジェクト指示には「このクライアントのトーン・NGワード・過去の要望まとめ」を入れる。
ナレッジには「最新の要望メール」「過去のやりとりサマリー」を登録する。これで「前回のMTGの内容を踏まえて文案作って」という指示が毎回一から説明せずに使える。
失敗から学んだコンテキスト設計の注意点
正直、最初は失敗した。プロジェクト指示に500字以上の情報を詰め込んだ結果、Claudeの返答が「フワフワした印象」になった。情報が多すぎてClaudeが何を優先すべきか判断できなくなったのかもしれない。
Anthropicのプロンプトガイドラインでも「明確で直接的な指示」の方が優れた結果を生むと言及されている。公式ドキュメントでも、「コンテキストや動機を追加することで理解が深まる」と書かれているが、「詰め込めば詰め込むほど良い」とは書かれていない。
今の感覚では100〜200字が最適な長さだ。「役割・文体・NG事項」の3点に絞ると精度が上がった。
もう一つの失敗が「古いナレッジを入れたままにすること」。クライアントの要件が変わったのにナレッジを更新しなかったら、古い仕様で回答が出てきてしまった。ナレッジは月1回は確認して、不要な情報を削除することを習慣にした方がいい。
あと、クライアントAとBの案件を同じプロジェクトで扱ったら混線した。プロジェクトはケチらず分ける方がいい。
コンテキストが「効いている」かを確認する方法
設計したコンテキストが実際に機能しているかを確認する簡単な方法がある。
新しい会話を始めて、「自己紹介してください」と聞く。Claudeが設定したペルソナ・役割・文体でちゃんと自己紹介できるなら、コンテキストが機能している証拠だ。
「よくわかりません」「何かお手伝いできますか？」という汎用的な返答が来たら、プロジェクト指示が薄すぎるか、ナレッジの登録内容が不十分なサインだ。
この確認を新しいプロジェクトを作るたびにやるようにした。2〜3分で確認できるし、「なんか返答がズレてる」という感覚の原因を早めに特定できる。
運用・更新のルール（設計した後の管理）
プロジェクト設計は「作って終わり」ではない。
僕が決めている運用ルール：
- 月1回ナレッジ棚卸し：古い情報は削除する。情報過多の方がダメージが大きい
- 指示の変更は最小限に：プロジェクト指示をちょくちょく変えると、返答の安定性が失われる。1〜2ヶ月は同じ設定で使い続けてから見直す
- 新しいプロジェクトを作るタイミング：「毎回同じ前提を説明している」と感じたら、それがプロジェクトを作るサインだ
ちなみに今のところ9プロジェクトを運用中で、うち5つはクライアント別、残り4つが業務種別（ライティング・リサーチ・メール返信・アイデア出し）という構成になっている。
プロジェクト機能と「カスタム指示」の違い
余談だけど、Claudeには「カスタム指示」という設定もある。これとプロジェクト指示の違いを最初に理解していなくて、しばらく混乱した。
整理すると：
- カスタム指示：Claude全体（すべての会話）に反映される設定
- プロジェクト指示：特定のプロジェクト内の会話だけに反映される設定
カスタム指示は「どんな会話でも常にこのトーンで応答してほしい」という基本設定に使う。プロジェクト指示は「このクライアントの案件だけ、このルールで動いてほしい」という用途に使う。
この2つを組み合わせると、「基本的な文体はカスタム指示で固定・クライアント別の追加情報はプロジェクト指示で管理」という二層構造ができる。
最初はカスタム指示だけで全部やろうとしたが、クライアントの要件が混在してしまって失敗した。プロジェクト指示を使い始めてから、「どこに書いたか」が整理されてかなり楽になった。
まとめ：コンテキスト設計はAIとの関係性づくり
コンテキスト設計は「プロジェクト機能を使いこなす」という話じゃなくて、「AIにどういう前提を持ってほしいか」を整理する作業だ。
この整理をするだけで、毎回のやりとりがスムーズになるし、返ってくる内容の品質も安定する。
設定のポイント：
- プロジェクト指示は100〜200字に絞る（詰め込みすぎない）
- ナレッジは最新状態を維持する（月1回棚卸し）
- クライアント別・業務別でプロジェクトを分ける
実際のシステムプロンプトの書き方パターンは次の記事でまとめているので、そちらも合わせて読んでほしい。コンテキスト設計の「型」を理解してから読むと、テンプレートをそのまま使うだけでなく、自分の用途に合わせて調整しやすくなるはずだ。
合わせて読みたい
–
–
コメント