「Claudeがシステムプロンプトを忘れた」が、大抵スコープの問題である理由
単一の入力欄は存在しない — 4つの場所とAPIが存在する
Anthropicのパーソナライズに関する概要では、次のように説明されています。「Claudeは、体験をパーソナライズするためのいくつかの方法を提供しています。プロファイル指示、プロジェクト指示、およびスタイルです。」これにTeamプランおよびEnterpriseプラン向けの組織レイヤーと、APIのsystemパラメータを加えると、全体像は次のようになります。
Claudeへの指示（Instructions for Claude） — アカウント全体に適用。「指示はアカウント全体の設定であり、Claudeが回答を生成する際に考慮すべき一般的な指示を理解するのに役立ちます。」また、「ここに追加した指示は、Claudeとのすべての会話に適用されます。」左下のイニシャルをクリックし、「Settings（設定）」からアクセスできます。
プロジェクト指示（Project instructions） — 単一のプロジェクトにスコープ。「これらの指示は、そのプロジェクト内のチャットにのみ適用されます。」
スキル（Skills） — オンデマンド。「Claudeとの会話に特定の動作や機能を追加」し、「オンデマンドで有効化する、繰り返し利用可能な動作を定義」します。
組織の指示（Organization instructions） — ユーザーの上位で設定。TeamおよびEnterpriseプランでは、管理者（Admin）以上が「組織全体のすべての会話でClaudeが従うカスタム指示」を設定できます。
APIのsystemパラメータ — 文字通り「システムプロンプト」と呼ばれる唯一のものです。
5つのコンテナ、5つの挙動。「忘れてしまった」という報告のほぼすべては、指示が間違ったコンテナに置かれていることが原因です。
入力欄ではなく、チャットに直接入力してしまっている
圧倒的に最も多いケースです。会話を開始し、Claudeがどのように振る舞うべきかを説明する3つの段落を書き、その会話内では見事に機能しました。しかし、新しいチャットを開始すると機能しなくなります。
会話内のテキストは、その会話のみを支配します。常時適用されるものではありません。間接的にClaudeに影響を与えることはあるかもしれません（メモリは「コミュニケーションの好みや作業スタイル」をキャプチャするため）。しかし、それはメモリが好みを推測しているだけであり、指示が保存されているわけではありません。毎回適用させたい場合は、専用の入力欄に記述する必要があります。
作業している場所に対して、間違ったレベルで設定されている
アカウント全体の指示はすべての会話に適用されます。プロジェクト指示はそのプロジェクト内でのみ適用されます。この2つの文は、相反する2つの失敗パターンを生み出します。
あるプロジェクトの指示に記述したのに、別のプロジェクトや通常のチャットで作業してしまった場合。そこには最初から指示は存在しません。
あるいは、アカウント全体に記述したため、独自の指示やナレッジベースを持つプロジェクト内でも十分に機能すると期待してしまった場合。指示は存在しますが、同じ事柄についてより具体的な指示を持つプロジェクト固有の方向性と競合してしまいます。
ご自身のアカウントで確認する価値のある利用可能性に関する注意点として、プロジェクトのドキュメントには、プロジェクトは「無料のClaudeアカウントを持つユーザーを含むすべてのユーザーが利用可能」で、無料ユーザーは5つまでに制限されていると記載されています。一方、パーソナライズの概要では、プロジェクト指示は有料プラン限定と説明されています。思い込まずに「Settings（設定）」を開いて、ご自身のアカウントでどちらが有効か確認してください。
組織の指示が優先されており、それが目に見えない
これはユーザーの立場からは本当に見えないものであり、ドキュメントに正確に記載されています。2つのレベルの相互作用について：「両方が設定されている場合、組織の指示が優先されます。個人の指示が組織の指示と直接矛盾する場合、Claudeは組織レベルの指示を優先します。」挙げられている例は的確です。組織の指示で「常にフォーマルな英語で回答する」とされている場合、個人の指示で「カジュアルなトーンを使用する」と書いても無視されます。
そして、同じ表の公開範囲の列には、組織の指示は「管理者（Admin）以上」にのみ表示されると記載されています。
つまり、仕事用のアカウントでは、あなたが読む手段のないテキストによって、あなたの指示が一貫して却下される可能性があります。個人の指示が破棄されるわけではありません。「組織の指示が言及していない事項については、引き続き個人の指示が適用されます。」しかし、直接競合する点については、あなたの負けになります。これは、Claudeの書き方を標準化したい企業にとっては正しい設計ですが、個人で原因を特定するのが最も難しい原因でもあります。管理者に何が設定されているか尋ねてみてください。
このレイヤーに関するさらに2つの詳細：組織の指示は最大3,000文字に制限されており、「変更がClaude製品全体に反映されるまでに最大1時間かかる場合があります。」管理者が変更したばかりの場合は、少し待つのが賢明なステップです。
APIでは、システムプロンプトは「忘れられる」のではなく「省略される」
APIを呼び出している場合、systemパラメータはリクエストの一部です。すべての呼び出しで送信するか、送信しないかのどちらかです。
message = client.messages.create(
model="claude-opus-5",
max_tokens=1024,
system="You are a helpful coding assistant specializing in Python.",
messages=[{"role": "user", "content": "How do I sort a list of dictionaries by key?"}],
)保存される場所がないため、失われることもありません。APIの文脈で「Claudeがシステムプロンプトを忘れた」というのは、コードパスがそれを送信しなくなったことを意味します。新しいクライアント、リトライヘルパー、ストリーミングブランチ、独自のリクエストを構築するフレームワークなどが原因です。送信されるペイロードを一度ログに出力すれば、すぐに原因がわかります。
読み込まれたのに、Claudeが従わない
これが最後の、そして紛れもないカテゴリであり、Anthropic自身も注意を促しています。指示の優先順位について：「指示の優先順位付けは、プロンプトレベルの指示に依存します。直接矛盾する指示が含まれる稀なエッジケースでは、挙動が異なる場合があります。指示をテストして、期待通りの結果が得られるか確認してください。」
関連するガイダンス：「組織の指示が互いに矛盾している場合、Claudeはいずれの指示にも確実には従わない可能性があります。」また、Claudeのコアトレーニングと矛盾する指示は実行されません。指示は強力なコンテキスト（文脈）であり、強制力が保証された設定ファイルではありません。これのより広いバージョン（指示ファイルが無視されているように見える4つの明確な理由）は、エージェントが作成した指示ファイルを無視する理由で解説しています。
よく試される（が効果の薄い）対策
すべての会話の冒頭に指示ブロックを毎回貼り直す。 確実かつ「永続的」な方法です。あなたがそれを「永続的」にやり続けるという意味において。
より長い指示を書く。 長さは解決策にはなりません。組織レベルではむしろ逆効果です。それらの指示は「組織内の全員が送信するすべてのメッセージに含まれる」ためです。
すべてのプロジェクトに同じ指示を複製する。 4つ目のコピーが最初のコピーと乖離し、どれが最新版かわからなくなるまでは機能します。
上書きされたのをバグだと思い込んで報告する。 気持ちはわかります。しかし、TeamまたはEnterpriseプランを利用している場合は、結論を出す前に管理者に確認してください。
すべてをアカウント全体の指示に入れる。 そうすると、Claudeはコードレビューの基準をあなたの旅行計画にも適用するようになります。スコープが存在するのには理由があります。
Claudeに指示を「常に覚えておく」ように指示する。 それはメモリ（記憶）への要求であり、指示フィールドへの指示ではありません。メモリは好みを保持することはできますが、強制力のある仕組みではありません。
解決策：それぞれの指示を、それが「常に真である」最も狭いレベルに配置する
この問題を恒久的に解決するルールは、設定の変更ではなく、整理のルールです。指示は、それが常に真（有効）である最も狭いレベルに配置されるべきです。
常に、どこでも真 → Claudeへの指示（Instructions for Claude）。 左下のイニシャル → Settings（設定） → Instructions for Claude。好ましいアプローチ、使用する用語、一般的なコミュニケーションの方向性など。短く、本当に普遍的な内容にとどめてください。
特定の業務でのみ真 → プロジェクト指示。 プロジェクトを開き、「Set project instructions（プロジェクト指示を設定）」をクリックして入力し、保存します。Claudeは「プロジェクト内のすべてのチャットでこれらの指示を使用」します。役割、ワークフローのガイドライン、その業務の要件など。
呼び出したときだけ真 → スキル（Skill）。 オンデマンドで有効化する繰り返し可能な動作は、他のすべてと競合する常時オンのフィールドではなく、ここに配置します。
組織によって設定されている → 管理者に確認。 仕事用アカウントでClaudeが個人の指示と確実に矛盾する挙動をする場合、組織の指示が優先されており、それは管理者（Admin）以上しか表示できません。1つの質問で1週間分の無駄な時間を節約できます。
コードから送信される → リクエストをログに記録。 すべてのパスでsystemパラメータが存在することを確認します。
この整理によって配置は解決します。しかし、解決できないのは5番目のカテゴリ、つまり指示が参照し続ける「常時必要な知識」です。「ハウススタイルに従う」という指示は、ハウススタイルがClaudeの読める場所にあって初めて機能します。指示フィールドは方向性を指示するためのものであり、ドキュメントを置く場所ではありません。
それこそがMemoryLakeが保持するものです。アカウントの設定に依存せず、アシスタントが読み取れるレイヤーに、永続的なコンテキストと規約を保持します。セットアップは3つのステップです。
ステップ 1: APIキーを作成する
MemoryLakeにサインインし、APIキーを作成します。接続するツール間で共通の1つの認証情報です。
ステップ 2: 最初のメモリをアップロードする
指示が参照している実体を、1項目1件の短いエントリとして書き出します。
標準そのもの。 「スタイルガイドに従う」ではなく、検証可能な形で記述された実際のルール。
各ルールの背後にある理由。 ルール単体は1つの会話で終わるかもしれません。「リリースノートで受動態を使用しないこと。サポートが電話で読み上げるため」という理由は、ツールが変わっても生き残ります。
用語集。 チームが特定の意味で、特定の方法で使用する用語。これにより、すべてのプロジェクトで用語を再説明する手間が省けます。
すでに却下されたアイデアとその理由。 誰も記録に残さず、全員が何度も議論を蒸し返すカテゴリです。
ステップ 3: AIとエージェントを接続する
使用しているツールを接続します。MemoryLakeはMCPおよびAPI経由でアクセスできるため、MCPネイティブのエージェント（Claude Code、Codex、OpenClawなど）はMCPサーバーを指定して接続し、他のアシスタントはAPIを介して同じメモリを読み取ります。
3つの率直な制限事項があり、特に最初のものが重要です。メモリレイヤーは強制力のある仕組みではありません。 基準を利用可能にするだけであり、モデルがそれに従うことを保証するものではありません。上記の「読み込まれたが従わない」カテゴリは依然として発生し得ます。また、Claudeの設定に直接書き込むわけではないため、指示フィールドは引き続きご自身で管理する必要があり、ステップ2の作業は手動となります。
実践において何が変わるか
指示が短くなり、短い状態を維持できる。 方向性は入力欄に、実体はメモリレイヤーに置かれます。指示フィールドがドキュメントを貼り付ける場所ではなくなるため、指示が無視される最大の原因が解消されます。
組織による上書きが謎ではなくなる。 依然として見ることはできませんが、優先ルールを知っていれば、不可解なフォーマルなトーンも説明がつくようになり、デバッグ作業ではなく話し合いによって解決できるようになります。
プロジェクト間での重複がなくなる。 基準は1か所にのみ存在します。プロジェクト指示は、そのプロジェクトに特有の事項のみを指し示すようになります。
基準がツールよりも長生きする。 指示フィールドはベンダーごとに異なります。Claudeの設定に書き込んだ内容はCursorやCodexには存在しませんが、それらすべてが読み取れるメモリレイヤーは存在し続けます。その構成については、AIツール間で1つのメモリをセットアップする方法で解説しています。
「また忘れた」が2分間のチェックで済むようになる。 どのフィールドか、どのスコープか、どのレベルか。ほぼ常にその3つのいずれかです。
Claudeにおける常時指示のベストプラクティス
書く前に整理する。 普遍的か、プロジェクト限定か、オンデマンドか、組織レベルか。これを一度正しく行うだけで、再発の大部分を防ぐことができます。
指示フィールドはドキュメントではなく、方向性の指示にとどめる。 Claudeにどのように振る舞うべきかを伝え、参照資料は取得可能な場所に保管します。
新しい会話でテストする。 組織の指示に関するドキュメントのアドバイスは、個人の指示にも当てはまります。保存後、新しいチャットを開始し、いくつかの異なる種類の質問を試してください。
3,000文字の制限を一般化しない。 この数字は組織の指示に特化してドキュメント化されているものです。個人のフィールドにも適用されると思い込まないでください。また、いずれにせよ簡潔さは必須です。
管理者の変更後は1時間待つ。 組織の指示の変更は、「Claude製品全体に反映されるまでに最大1時間かかる場合があります。」
自己矛盾を避ける。 互いに矛盾する2つの指示があると、両方とも信頼できなくなる可能性があります。フィールドの内容を1つのドキュメントとして上から下まで読み直してください。
安全性の挙動を指示で回避しようとしない。 効果がないことがドキュメント化されており、労力を費やすべき生産的な場所ではありません。
ルールの隣に理由を書く。 これにより指示の移植性が高まります。また、単にClaudeが適用するルールと、想定外のケースに対してもClaudeが正しく適用できるルールの違いを生みます。この一般的なポイントについては、永続メモリが実際に意味することで解説しています。
結論
Claudeアプリには、忘れるようなシステムプロンプト自体が存在しません。存在するのは、アカウント全体の指示、プロジェクト指示、スキル、TeamおよびEnterpriseプランにおける組織の指示、そしてAPIにおいてリクエストごとに送信するsystemパラメータです。「消えてしまった」指示は、ほぼ常にこれらの中で間違った場所に置かれているか、目に見えない組織レイヤーによって上書きされているか、終了した会話の中に直接書き込まれたかのいずれかです。
それぞれの指示を、それが常に真である最も狭いレベルに整理し、それらのフィールドを短く保ち、指示が参照する実体（基準、用語、決定事項、却下されたアプローチ）をツールが読み取れるレイヤーに移動させましょう。そうすれば、指示フィールドはどのように振る舞うべきかを示し、メモリレイヤーは何が真実であるかを保持し、どちらも相手の役割を肩代わりする必要がなくなります。もし問題が方向性ではなく、Claudeがプロジェクト資料そのものを失ってしまうことにある場合は、Claudeがプロジェクトの知識を忘れる理由でそのケースをカバーしています。