なぜClaudeにはドメイン知識の置き場所がないのか
まず、人々が同じように呼んでいる3つの概念を区別する
これを誤解することが、ほとんどの試みが失敗する原因です。なぜなら、それぞれ異なる場所に属しているからです。
ドメイン知識とは、すべての業務において常に真実であり続けるものです。保険金請求の査定プロセス、あなたの分野における「コホート」という言葉の一般的な意味との違い、すべてのプロジェクトを制約する規制などがこれに該当します。これは単一のプロジェクトの寿命を超えて存在し、常に再利用されます。
プロジェクト知識とは、1つの業務（仕様書、データセット、契約書など）のための資料です。これは具体的であり、プロジェクトの終了とともに期限切れになります。これについては、why Claude forgets your project knowledgeで詳しく解説しています。
ハウスルール（組織内の慣習）とは、チームの仕事の進め方（フォーマット、レビュー基準、命名規則など）です。これもまた異なり、why Claude forgets your house conventionsでカバーされています。
ドメイン知識をプロジェクト知識として保存しようとすると、プロジェクトごとにコピーを管理することになります。指示（Instructions）として保存しようとすると、設定フィールドの制限にすぐに達してしまいます。
アカウント全体のフィールドは方向性を指示するためのものであり、ドキュメント用ではない
「Claudeへの指示（Instructions for Claude）」は、確かにアカウント全体に適用されます。「ここに追加した指示は、Claudeとのすべての会話に適用されます。」また、ドキュメント化された例もドメイン資料に対して不親切ではありません。Anthropicは、そこに記載すべきものとして「よく使用する用語や概念」や「遭遇する典型的なシナリオ」を挙げています。
そのため、コンパクトな用語集はここに置くのが適しています。10個ほどの用語をそれぞれ1行で定義することは、非常に有効でありながらあまり活用されていない手法です。しかし、膨大なコーパス（資料群）はここには適しません。これは常時適用される指示のためのテキストボックスであり、そこに含まれるすべての単語が、あらゆるトピックに関するすべての会話で送信されます。ここに分野の参照資料を詰め込むと、1つの会話を良くするために、関係のない他のすべてのチャットの品質を低下させることになります。
プロジェクト知識は強力だが、1つのプロジェクト内に閉じ込められている
プロジェクト知識はドキュメントを格納するのに適したコンテナであり、うまく機能します。「このスペースにアップロードしたものはすべて、そのプロジェクト内のすべてのチャットで使用されます。」また、有料プランでは容量が拡張されます。「プロジェクト知識がコンテキスト制限に近づくと、ClaudeはシームレスにRAGモードを有効にし、回答の品質を維持しながら容量を最大10倍に拡張します。」この拡張容量は、Pro、Max、Team、およびEnterpriseプランで利用可能であるとドキュメントに記載されています。
落とし穴は最初の言葉にあります。プロジェクトは「独自のチャット履歴とナレッジベースを持つ、自己完結型のワークスペースを作成できる」機能です。「自己完結型」であることがポイントであり、だからこそドメインコーパスを1つのプロジェクトに置いて他のプロジェクトで使い回すことができないのです。
プロジェクトメモリも同様の設計で隔離されている
メモリ機能もその架け橋にはなりません。「各プロジェクトには独自の独立したメモリスペースと専用のプロジェクトサマリーがあるため、各プロジェクト内のコンテキストは焦点を絞り、関連性が高く、他のプロジェクトやプロジェクト外のチャットから分離されています。」
そもそも、メモリはドキュメントストアではありません。Claudeのメモリが焦点を当てているのは、あなたに関する業務コンテキスト（あなたの役割や専門的な背景、コミュニケーションの好みや仕事のスタイル、技術的な好みやコーディングスタイル、プロジェクトの詳細や進行中の業務など）です。これは便利ですが、「この業界における決済のタイミングがどのように機能するか」とは異なるカテゴリーです。
同じ領域における2つの小さな罠もあります。コンテキストは「情報がプロジェクトのナレッジベースに追加されない限り、プロジェクト内のチャット間で共有されません」。つまり、1つのチャットで説明した定義は、同じプロジェクト内であっても次のチャットでは利用できません。また、プロジェクトを作成する際、「プロジェクトに名前と説明を付けます（Claudeはこれらの詳細にアクセスできないことに注意してください）」。プロジェクトに「Insurance Claims — EU」と名付けても、Claudeには何も伝わりません。
すべてのプロジェクトに同じファイルをアップロードするのは、メンテナンスの悪夢である
これは多くの人が行っている方法であり、初日はうまく機能します。しかし3ヶ月目には、5つのプロジェクトに規制の概要が存在し、そのうち3つは法改正前の古いものであり、どのチャットがどれを使用したか分からなくなります。知識が腐敗したのではなく、コピーが乖離してしまったのです。
人々が試みること
すべてのチャットの冒頭に背景を貼り付ける。 効果的ですが、際限がありません。これはhow to stop re-explaining context to AIで説明されているループです。
各プロジェクトに同じPDFをアップロードする。 アクセスの問題は解決しますが、バージョンの乖離が発生します。また、人々がre-uploading the same documents forever（同じドキュメントを永遠に再アップロードし続ける）ことになる原因でもあります。
ドメイン全体に対して1つの巨大なプロジェクトを作成する。 これを行うと、関係のないすべてのタスクが1つのメモリスペースと1つのサマリーを共有することになり、クライアントワークのために必要だった隔離環境が失われます。
アカウント全体の指示フィールドに参照資料を詰め込む。 スケジュール調整に関する会話も含め、あらゆる会話にドメインコーパスが適用されてしまいます。
チャット検索で見つかることを期待する。 検索は要求に応じて、ドキュメント化された境界内でのみ機能します。プロジェクト内の検索はそのプロジェクト内にとどまります。これは検索（リトリーバル）であり、常設のナレッジベースではありません。この違いは重要です：why RAG isn't memory。
メモリがそれを学習するのを待つ。 メモリは、あなたやあなたのプロジェクトに関する業務関連のコンテキストに焦点を当てています。分野の参照資料を吸収するようには設計されておらず、ドキュメントストアとして扱うと、気づかないうちに情報の抜け漏れが発生します。
解決策：1つのドメインレイヤーの上にプロジェクトファイルを重ねる
機能する構造とは、常に真実であることと、この仕事において真実であることを分離し、1つのコンテナに両方を担わせるのをやめることです。
プロジェクト知識はプロジェクト資料のために残しておく。 これに抗う必要はありません。それが適切なツールです。仕様書、データ、契約書、現在のドラフトなど。有料プランでは必要に応じて容量が拡張され、Google ドライブから追加されたドキュメントは同期されるため、古いアップロードではなく最新のバージョンで作業できます。
アカウント全体の指示に短い用語集を入れる。 あなたの分野で特定の意味で使用される10〜15個の用語を、それぞれ1行で記載します。Anthropicは、共通の用語や典型的なシナリオをそのフィールドに適したコンテンツとして明示的に挙げています。20ページにも及ぶものにしたいという衝動は抑えてください。
すべてのプロジェクトに明確なスコープを与え、その中にコンテキストを置く。 業務ごとに1つのプロジェクトを作成します。それぞれが独自のメモリとサマリーを持つためです。また、プロジェクト名と説明はClaudeには見えないことを忘れないでください。そのため、スコープに関する重要な事項は指示（Instructions）またはナレッジベースに入力します。
ドメイン自体にプロジェクト外の「家」を1つ与える。 これこそがClaudeが提供していないピースであり、MemoryLakeが提供するものです。これは、すべてのプロジェクト、通常のチャット、および使用する他のツールから読み取り可能な、永続的な知識を保持するメモリレイヤーです。セットアップは3つのステップで行えます。
ステップ 1: APIキーを作成する
MemoryLakeにサインインし、APIキーを作成します。接続するツール間で共通の認証情報となります。
ステップ 2: 最初のメモリをアップロードする
ここでの間違いは、ドキュメントをそのままアップロードしてしまうことです。利用可能な形式のドメイン知識は、インデックス化されるのではなく、抽出されます。短いエントリ、1つの主張につき1つのエントリとし、検証可能な形で記述します。記録すべき内容は以下の通りです：
一般的な意味とは異なる定義。 すべての分野には、内部で特定の意味を持つ言葉があります。モデルは自信を持って一般的な意味を適用してしまうため、これらは他の何よりも「静かなエラー（気づきにくい間違い）」を引き起こす原因になります。
ルールと、それを生み出す制約。 「決済はT+2で行われる」は事実です。「決済はT+2で行われるため、照合処理を当日中に行うことはできない」は、誤った提案を防ぐための知識です。
境界線と例外。 通常のルールが適用されないケース。これは最も価値の高い資料であり、どこにも書き留められていない可能性が最も高いものです。
除外されたアプローチとその理由。 あなたの分野ですでに廃止されたアプローチ。これがないと、新しい会話のたびにそれらが再び提案されてしまいます。
重要な数値と、その基準日。 しきい値、制限、比率など。日付を記載することで、古いエントリであることが一目でわかるようになります。
現実的な比率を想定してください。40ページの参照ドキュメントからは、通常15〜30個のエントリが抽出されます。もし200個も作成しているなら、それは抽出ではなく、ドキュメントの書き写しになってしまっています。
ステップ 3: AIとエージェントを接続する
使用しているツールを接続します。MemoryLakeはMCPおよびAPI経由でアクセスできるため、MCPネイティブのエージェント（Claude Code、Codex、OpenClawなど）はMCPサーバーを指定することで接続し、他のアシスタントはAPIを介して同じメモリを読み取ります。これにより、各プロジェクトが独自のファイルを保持したまま、作業中のあらゆる場所からドメインレイヤーを読み取れるようになります。
3つの率直な制限事項。これはプロジェクト知識を代替するものではありません。プロジェクトファイルはプロジェクトに属するべきであり、MemoryLakeはドキュメント管理システムではありません。あなたやエージェントが書き込んだ内容のみを保持するため、ステップ2は実際の作業を伴います。また、コンプライアンスやデータ保持のためのシステムでもありません。
実践においてこれがもたらす変化
プロジェクトの開始が、分野の再定義を意味しなくなります。 新しいプロジェクトを立ち上げても、ドメインレイヤーはすでに読み取り可能です。アップロードするのは業界の知識ではなく、仕様書だけです。
法改正に対する単一の真実のソース。 規制が変更された場合、5つのプロジェクトナレッジベース（そのうち3つは古いコピー）を更新するのではなく、1つのエントリを更新するだけで済みます。
プロジェクトの隔離が純粋に有益になります。 再説明というコストを支払うことなく、業務間の必要な分離を維持できます。
定義の乖離がなくなります。 1つの場所で一度定義された用語は、すべてのプロジェクトやツールで同じように使用されます。
他のツールもそれを継承します。 ドメイン知識は、まさにアシスタント間で共通するコンテキストそのものです。Claudeの外部に置くことで、Cursorや他のエージェントも同じ情報を読み取ることができます。この仕組みについては、cross-tool memory for knowledge workersで説明しています。
ドメイン知識のベストプラクティス
保存する前に分類する。 ドメイン、プロジェクト、またはハウスルール。それぞれ異なる置き場所と異なる寿命を持っており、これらを混同することがメンテナンスの問題を引き起こします。
アップロードするのではなく、抽出する。 ドキュメントは「読むもの」です。エントリは「検索するもの」です。この変換プロセスにこそ価値があります。
ルールの横に理由を書く。 理由が記載されていれば、Claudeは想定外のケースにも対応できます。ルール単体ではそれができません。
数値データには日付を入れる。 しきい値や比率は変化します。日付のない数値は、将来のエラーの原因になります。
1つのエントリには1つの主張のみを含める。 複数の内容が混ざった長いエントリは検索精度が低下し、一部が誤りになった際の修正も困難になります。
例外を記録する。 境界線上のケースを記録しておくことが、「もっともらしい回答」と「正確な回答」の差を生みます。
アカウント全体の用語集は短く保つ。 これはすべての会話で送信されます。10語程度なら有用ですが、1章分もあると関係のない作業に余計なコストがかかります。
分野に変化があった後は見直す。 過去の仕組みを説明するエントリの横に注記を追加するのではなく、古いエントリ自体を削除してください。矛盾する2つのエントリが存在することは、1つの古いエントリが存在することよりも悪影響を及ぼします。これについては、what AI memory is and isn'tで詳しく説明しています。
結論
Claudeにはコンテキストを格納するための優れたコンテナがありますが、そのどれもドメイン知識の形状には合致していません。アカウント全体の指示フィールドは常時適用される指示のためのものであり、すべての会話に付随します。プロジェクト知識はドキュメントを置くのに適した場所ですが、そのプロジェクトのメモリと同様に、1つの自己完結型プロジェクト内に閉じ込められています。メモリ自体は、あなたの分野の参照資料ではなく、あなたに関する業務コンテキストに焦点を当てています。
したがって、実用的なセットアップは「分割」することです。プロジェクトファイルはプロジェクト内に留めます。短い用語集はアカウント全体に適用します。そしてドメイン（定義、ルール、理由、例外、すでに除外された事項）は、すべてのプロジェクトやツールから読み取り可能なレイヤーに一度だけ抽出します。これこそが、新しいプロジェクトを開始した時点であなたの分野がすでに理解されており、法改正の際にも5つのコピーを探し回る代わりに1つのエントリを編集するだけで済む仕組みです。