プログラミングをせず、Claude.aiのウェブ版でチャットしているだけでも、システムプロンプトは自分に関係がありますか？
関係はあるが、触れているのは簡易版である。標準のClaude.aiの会話では、システムプロンプトはAnthropicプラットフォームによって事前設定されており、一般ユーザーは直接閲覧・変更できない。しかしProjects機能を使っている場合、その中の「カスタム指示」欄は、実質的に自分で設定できる簡易版のシステムプロンプトとして機能する——コードに一切触れる必要はなく、Projectを作成する際に役割設定、口調の好み、常に守ってほしいルールを書き込むだけで、そのProject内で始める新しい会話すべてに自動的に適用される。
言い換えれば、APIのsystemパラメータの書き方を理解する必要はなく、「この種のグローバルなルールはカスタム指示に置くべきであり、毎回打ち直すものではない」と知っているだけで、この概念が実際に自分の役に立つ部分をすでに掴んでいることになる。
システムプロンプトの重みが高いということは、会話の中で自分が打つ指示は何でも無視されるということですか？
いいえ。システムプロンプトの重みが高いというのは、単一のメッセージによって「上書きされにくい」という意味であり、ユーザーの指示が無視されるという意味ではない。実際には、会話の途中で出す指示（例えば「今回は箇条書きで答えて」）は通常採用されるが、その効力は基本的にその瞬間、あるいはその会話に限られ、システム層のようにその後のすべての新しい会話に持続的に適用されるわけではない。
本当の違いは「持続性」であって「有効かどうか」ではない。ユーザー層の指示は有効だが範囲が狭く、次の一言に簡単に取って代わられる。システム層の指示は範囲が広く、自分で設定を変更しない限り存在し続ける。この点を理解しておくと、あるルールをシステム層に移す手間をかける価値があるかどうかを判断しやすくなる——一度きりの用途であれば、ユーザー層に留めておく方がむしろ便利である。
開発者がシステムプロンプトを書く際に、最もよく犯す間違いは何ですか？
最も一般的な間違いは、システムプロンプトを「あらゆる想定シナリオ」を網羅したルールブックとして扱い、ユーザーが尋ねうるすべての質問への回答方法を事前に列挙しようとすることだ。この結果、システムプロンプトはどんどん長くなり、個々のルール同士が矛盾し始め、モデルはどのルールを優先すべきか判断しづらくなる。
より堅実なアプローチは、システムプロンプトを「この役割は誰か」「核となる口調は何か」「絶対にしてはいけないことは何か」といった数点に絞り込み、状況によって変わる詳細はユーザー層のメッセージで補うことだ。Anthropic自身のドキュメントも同様の方向性を示している——systemパラメータで役割を設定し、タスク固有の詳細はユーザーターンに置くべきであり、両者を一緒くたに長い文章として書くべきではない。
システム層とユーザー層を見分ける練習を始めたいのですが、どこから手をつければいいですか？
最も簡単な出発点は、最近Claudeと交わした会話をいくつか振り返り、自分が打った指示をすべて書き出すことだ。そして「この一文は、今回何を聞いても常に成立すべきものか」と自問する。答えが「はい」であれば、その指示は実はずっとシステム層に置くべきものだった（Projectsを使っているならカスタム指示にあたる）。答えが「場合による」であれば、ユーザー層に留めておくのが正しい。
実践としては、まずClaudeを繰り返し使う場面（特定の種類のメールを毎回書いてもらう、特定の口調で顧客に返信するなど）を一つ選び、Projectを作成する。毎回打ち直しているルールをカスタム指示に移し、何度か試して実際に入力の手間が省けたかを確認する。この練習を一通り経験すると、「この一文はどこに置くべきか」について、かなり直感的な判断力が身についてくる。
初めてプロンプトを書く人がぶつかる戸惑いは、多くの場合「何を打てばいいか分からない」ではなく、「指示を出したのに、Claudeが完全には従っていないように見える」というものだ。この症状の背景には、言葉選びの問題ではなく、本来システムプロンプトに置くべきルールをユーザープロンプトとして書いてしまっているケースが少なくない。この2つは同じ種類の指示を場所だけ変えて書いたものではなく、重みが根本的に異なる、構造的に別の層である。
Claude の API では、この違いはデータ構造そのものに組み込まれている。`system` は会話内容とは別に保持される独立したパラメータであり、`messages` 配列には `user` と `assistant` の2つの役割のみが交互に並ぶ。つまりシステムプロンプトは最初から「会話の一部」ではない。これは舞台劇の撮影前に、監督が俳優に伝える全体的な設定に近い——このシーンでどんな役を演じるか、口調はどう保つか、絶対に言ってはいけない台詞は何か。ユーザープロンプトは、俳優がその場面でその都度読み上げる具体的な台詞であり、状況に応じて変化する。
この構造上の違いが、両者の信頼性の差を直接決めている。システムプロンプトはユーザーがその場で入力する内容より優先される重み付けがされているため、一時的な一言で簡単には上書きされにくい。一方ユーザープロンプトは、次の一言で比較的容易に修正・上書きされる——これこそが、会話の途中で気が変わったときにClaudeが新しい指示に沿って調整しつつも、全体の役割設定は崩れない理由である。
開発者としてAnthropic APIでプログラムを書いている場合、システムプロンプトは `messages.create()` 呼び出しの中の独立した `system` パラメータである。「あなたはベテランのファイナンシャルアドバイザーであり、フォーマルながら親しみやすい口調で回答してください」のように一度設定すれば、その設定は会話全体に適用され、毎回の発言で役割を再確認する必要はない。
しかしプログラミングをしなくても、この概念には触れることになる。Claude.ai の Projects 機能には「カスタム指示」という欄があり、実質的に簡易版のシステムプロンプトとして機能する。Project を作成する際に「このプロジェクトの目的」「回答時に注意してほしい書式」「押さえておくべき背景情報」を一度設定すれば、その Project 内で始める新しい会話すべてに自動的に適用され、打ち直す必要がない。多くの人が Projects を使い始めてから「Claude が自分をより理解してくれるようになった」と感じるのも、モデルが賢くなったからではなく、本来システム層に置くべきルールがようやくそこに置かれたからである。
初心者に最もよく見られるパターンは、すべてのルールを毎回のメッセージに詰め込むことだ。「フォーマルな口調で答えて」「財務関連の質問だけに答えることを忘れないで」「競合他社について触れないで」——新しい会話を始めるたびに打ち直し、しかもこれらは一回限りの質問と同じ構造層に混在している。モデルは今回聞かれた具体的な質問を優先し、以前触れたルールの重みを軽くしてしまうことがある。これはモデルが「言うことを聞かない」のではなく、本来システム層に置くべきルールが、ユーザー層の数あるメッセージの一つとして書かれてしまっていることが原因である。
あるルールをどこに置くべきかを判断するシンプルな基準は、「今回何を聞いても常に成立すべき内容」ならシステムプロンプト（あるいは Projects のカスタム指示）に、「今回の質問にだけ関係する内容」ならユーザープロンプトに、というものだ。「繁体字中国語で回答して」「口調はプロフェッショナルに保って」は通常システム層で一度設定するのに適しており、「この会議記録を3つの要点にまとめて」は典型的なユーザー層のタスクで、会話が変わるたびに繰り返す必要はない。
自分でClaude.aiを仕事に使っているなら、この違いを理解することで実際にかなりの再入力の手間を省ける——役割設定と恒常的なルールをProjectsのカスタム指示に置くことは、一度の投資でその後のすべての会話で回収される。時間単価で働くフリーランスや、タスクを頻繁に切り替える人にとっては、実質的な効率の差になる。企業としてAIカスタマーサポートや社内ツールの導入を検討しているなら、システムプロンプトの重み付け設計を理解していることで、ベンダーが言う「AIは脱線しません」という主張が、重要なルールを実際に正しい構造層に置いた上での話なのか、それともユーザーの自制心に頼っただけの楽観的な想定なのかを見極められる。これはAI導入を安全に稼働させられるかどうか、そして後からどれだけの人手で穴を塞ぐ羽目になるかを左右する、決定的な細部であることが多い。