最初にルールを間違った場所に置いてしまい、後で調整したいと思った場合、面倒ですか？
技術的にはそれほど面倒ではない。ある場所から別の場所に内容を移す操作自体は単純だ。本当のコストは「間違って置いたことに気づく」こと自体にある——分類ロジックが間違っていることに気づかなければ、間違った場所に置かれたルールが増え続ける可能性があり、本当に調整したいと思った時には、見直すべき内容の範囲が既にかなり大きくなっていることに気づく。
実務上より良い習慣は、最初の設定時から「このルールが別の文脈に移されても適用され続けるか」という判断基準を適用することであり、ルールがある程度蓄積して挙動の不一致が現れてから振り返って原因を調べるのではない。これにより問題が蓄積してから対処する追加コストを避けられる。
あるルールが「役割の固定的な行動」と「プロジェクト固有の文脈」の両方の性質を同時に満たす場合、どう判断すればよいですか？
この状況は通常、そのルールが実は2つの部分に分割でき、それぞれ対応する層に置けることを意味する。例えば、「プロフェッショナルだが親しみやすいトーンで答える」は役割の固定的な行動パターンであり、System Promptに置くべきだ。「このプロジェクトの読者は社内の従業員であり、社内の専門用語を使ってよい」はプロジェクト固有の文脈であり、Project指示に置くべきだ。表面的には同じ1つのルールに見えても、分解してみると実は2つのことが同時に機能している。
分解してみて、2つの部分が本当に密接に結びついており、別々に記述できないと分かった場合、これは比較的まれなケースだが、実際に遭遇した場合は、より一般的に使われる層（通常はProject指示。変更頻度が通常より高いため）にまず置き、その後この役割設定が複数のプロジェクトにまたがって再利用される頻度が高まっていると分かったら、共通部分を抽出してSystem Promptに移すことを検討するとよい。
ウェブ版やDesktopアプリを使う一般ユーザーにも、System PromptとProject指示という2つの層はありますか？
ある。ただしインターフェース上の見え方が少し異なる。一般ユーザーがClaude Projects機能を通じて設定するカスタム指示は、この記事で扱っているProject指示層に対応する。System Promptについては、一般ユーザーは通常「System Prompt」という技術用語を直接目にすることはないが、各製品シナリオの背後には、実際にはClaudeの基本的な行動パターンを決定する基盤設定が動作している。ただしこの層は一般ユーザーにとって事前に設定済みであり、自分で調整する必要はない（通常はできない）だけだ。
これは、ウェブ版やDesktopアプリを通じてClaudeを使う一般ユーザーにとって、実務上実際に自分で手を動かして設定する必要があり、分類の問題に最もよく遭遇するのは主にProject指示のこの層であることを意味する。この記事で扱っている判断ロジックが一般ユーザーにとって最も実用的なのは、「この情報はどのProjectの指示に置くべきか」を判断する助けになる部分であり、別のProjectと混ざってしまわないようにすることだ。
チームで複数人が同じProjectを共有する場合、Project指示のメンテナンスで何に注意すべきですか？
Project指示はこの一連の会話が共有する背景情報であるため、複数人で共有する際に最も注意すべきなのはコンテンツの即時性だ。プロジェクトの背景情報に更新があった場合（顧客の要件が変わった、プロジェクトの範囲が調整されたなど）、Project指示も同期して更新される必要がある。そうしないと、チーム内の異なるメンバーが同じProjectの下で対話しても、得られる背景文脈が古いままとなり、異なるメンバーが一貫性のない回答を受け取り、それがClaude自体の問題だと誤解されてしまう可能性がある。背景情報が更新されていないだけなのに。
実務上より良いやり方は、チーム内で固定の担当者を指定してProject指示の更新を管理させることであり、各メンバーが個別に更新するかどうかを判断させ、変更が別の人に上書きされてしまうような状況を避けることだ。このメンテナンス責任の分担は、前述の「内容分類のロジック」と同等に重要でありながら、しばしば見落とされるもう一つの側面である。
APIまたはClaude Projectsを通じてClaudeを使用している場合、すぐに「行動ルールを事前に設定できる」2つの場所に出会うことになる。System PromptとProject内のカスタム指示だ。両者は似ているように聞こえ、どちらも会話が始まる前にルールを決めておくものだが、実際に使う際にはよく混同され、設定が分散し、後で調整したい時にルールが実際どこにあるのか分からなくなってしまう。この記事はこの2つの設定層をどう明確に分業させるかを扱うのであり、両者それぞれの定義を繰り返すのではない。
System Promptは、毎回のAPI呼び出しでユーザーメッセージと一緒に送られる役割設定であり、「この会話でClaudeがどんな役割を演じ、どんな固定ルールに従うべきか」を決定する。この設定は通常、特定のアプリケーションシナリオに固定されたロジックだ——例えば「あなたはカスタマーサポートアシスタントであり、製品関連の質問にのみ答え、範囲外の質問には丁寧に断る」といった具合だ。この種のルールはユーザーが誰であるか、議論している具体的な話題が何であるかによって変わることはなく、このアプリケーションシナリオにおいて常に成立する基盤ロジックである。
Project内のカスタム指示は、まったく異なるニーズに応える。関連する一連の会話を同じコンテナに入れ、それらの会話がすべて共有の背景情報にアクセスできるようにすることだ。ここに置かれる内容は通常プロジェクト固有の文脈である——例えば「このプロジェクトの顧客は某社で、彼らの製品ラインはA、B、Cを含む」といった具合だ。この種の情報はこの特定のProjectの下でのみ意味を持ち、別のProjectに移すとまったく適用されない。
混同は通常、ユーザーが「今回のタスクをどうやるか」という具体的なルールを誤ってSystem Promptに入れてしまう場合（結果としてアプリケーションシナリオが変わっても古いルールが適用され続ける）、あるいは「この役割が常に従うべき行動基準」を誤ってProject指示に入れてしまう場合（結果として異なるProjectで役割の挙動が一貫しなくなる）に発生する。判断基準はシンプルだ。このルールがまったく異なる文脈やProjectに移されても適用され続けるか？答えが「これは役割の固定的な行動パターンであり、どの会話に移っても従うべきものだ」であればSystem Promptに属する。答えが「これはこの一連の会話に固有の背景であり、別の会話群に移ると適用されない」であればProject指示に属する。
実務上、この2つの層はしばしば組み合わせて使われる。System Promptは役割の固定的な行動パターンを定義し（「あなたはプロフェッショナルなテクニカルライティングアシスタントであり、簡潔で明確な言葉で答える」など）、Project指示はこの特定プロジェクトに固有の背景情報を補足する（「このプロジェクトの読者は非技術系のマーケティングチームであり、専門用語を多用しないこと」など）。両者を重ね合わせることで初めて、今回の会話の完全な行動ルールとなる。すべてのルールを単一の層に無理に詰め込む必要はない。
同じ役割設定を繰り返し再利用する必要があるアプリケーションを開発している場合、固定ルールを正しくSystem Promptに分類することで、異なるプロジェクトに切り替えても役割の挙動が一貫することを保証でき、各Projectごとに再設定する必要がなくなる。プロジェクト固有の背景情報を正しくProject指示に分類することで、異なるプロジェクトの背景資料が互いに汚染し合うのを避けられる。分類ミスがあってもアプリケーションが完全に機能しなくなるわけではないが、長期的には大量の重複設定のメンテナンスコストと、原因を突き止めにくい挙動の不一致という問題が積み重なっていく。