Claude Codeの知識管理術｜「毎回同じ説明」をなくす実践法
Claude Codeの知識管理やコンテキストの記憶をどう維持するか。
セッションが切れるたびに「毎回同じ説明をする」問題に悩んでいる方は多いはずです。私自身、Claude Codeを2025年10月から業務のほぼ全領域で使い続けてきましたが、この「記憶が消える問題」への対処法は何度も変わりました。
結論から言えば、プロジェクト単位のGitHub管理 + Markdownによる知見蓄積という構成にたどり着いてから、セッション間のコンテキスト維持の問題はほぼ解消しています。この記事では、私が試行錯誤した4つの方法とその結果、そして現在の運用を具体的に公開します。
なぜClaude Codeのセッション間で知識管理が重要なのか
Claude Codeはセッションごとにコンテキストがリセットされます。つまり、前回のセッションで伝えた「プロジェクトの方針」「コーディングルール」「過去の判断理由」は、次のセッションでは何も覚えていません。
これが個人の趣味プロジェクトなら大した問題ではありません。しかし、事業でClaude Codeを使う場合、知識管理の欠如は致命的なコストになります。
- セッションのたびに同じ説明を繰り返す時間のロス
- 過去に決めたルールが反映されず、出力品質にばらつきが出る
- 蓄積した知見が活かされず、毎回ゼロからのスタートになる
- 複数の案件を並行していると、文脈の混同が起きる
私の場合、約6つのプロジェクトを並行運用しています。Webサイト開発、SEO記事執筆、営業資料作成、SaaS開発、AI検索最適化ツールの企画など、それぞれに異なるルール・方針・データがあります。これらを毎回口頭で伝え直すのは現実的ではありません。
実際に計測したわけではありませんが、知識管理を整備する前は、1セッションあたり10〜15分をコンテキストの再説明に使っていた感覚があります。1日に5〜6セッション立ち上げることもあるので、それだけで1時間近くが消えていた計算です。
私が試した4つの方法と、その結果
現在の運用にたどり着くまでに、いくつかのアプローチを試しました。時系列で振り返ります。
方法1: メモリファイルのみに頼る（ほぼ機能しなかった）
最初に試したのは、Claude Codeの自動メモリ機能（MEMORY.md）だけに頼る方法です。セッション中に重要な情報があれば自動的に記録してくれる仕組みですが、これだけではセッション間のコンテキスト維持はほぼ機能しませんでした。
メモリファイルに保存される情報はどうしても断片的になります。「何を覚えるか」の判断がAI任せになるため、本当に必要な情報が抜け落ちたり、逆に不要な情報が蓄積されたりします。プロジェクトの方針やルールのような「体系的な知識」を管理するには力不足でした。
方法2: スキル内に知識を保持する（管理が煩雑になった）
次に試したのは、Claude CodeのSkills（再利用可能なタスク定義）の中に、関連する知識を埋め込む方法です。例えば「SEO記事執筆スキル」の中に、記事の表記ルール・過去の記事一覧・キーワード戦略まで全部含めるようなイメージです。
これは一定の効果がありましたが、スキルが細分化されすぎて管理が煩雑になるという問題が発生しました。同じ情報が複数のスキルに重複し、ルールを1つ変更するたびに3〜4箇所を修正する必要がある。知識の一元管理という観点では破綻していました。
方法3: 外部ツール連携（フォーマットの制約で断念）
NotionやObsidianなどの外部ナレッジツールとClaude Codeを連携させる方法も試しました。MCP（Model Context Protocol）経由で外部ツールのデータを読み書きできるため、技術的には可能です。
しかし、各ツールのフォーマットに合わせる必要があり、コンテキスト保持の形式を自由に決められないという壁にぶつかりました。NotionならブロックStructure、ObsidianならフロントマターMarkdownと、ツール側の制約に引きずられます。結局、「Claude Codeにとって最適な形式で知識を保持する」ことができず、この方針は撤回しました。
ちなみに、LlamaIndex創業者のJerry Liu氏がmd/html出力をObsidianでナレッジベース化するアプローチを公開しており、注目はしています。ただ、私の運用規模と要件では、もっとシンプルな方法のほうが合っていました。
方法4: プロジェクト単位GitHub管理 + Markdownデータフォルダ（現在の運用）
data/フォルダにMarkdownで知見を蓄積していく形にしてから、セッション間のコンテキスト維持の問題はほぼ解消しました。これが現在の運用です。
ポイントは3つあります。
- CLAUDE.md: プロジェクトの全体像・ディレクトリ構成・主要ルールへの参照を記述。「常駐指示書」の役割
- rules/フォルダ: 記事執筆ルール・コーディング規約・ビジネスコンテキストなど、テーマ別のルールファイル
- data/フォルダ: 案件実績・AIツール知見・SEOキーワードなど、セッションをまたいで参照する一次情報のMarkdownデータベース
この構成なら、セッション開始時にClaude CodeがCLAUDE.mdを読むだけで「このプロジェクトで何をすべきか」「どんなルールがあるか」「どんなデータがあるか」を把握できます。詳細が必要な場合だけ、各ファイルを参照する設計です。
現在の運用 — 知識蓄積ルールの設計と進化
プロジェクト構成だけでは不十分です。「セッション中に得た新しい知見をどう蓄積するか」のルールがなければ、知識は増えていきません。
私はknowledge-accumulation.md（知見蓄積ルール）というファイルを作成し、Claude Codeに「どの情報を・どのファイルに・いつ追記するか」を明示的に指示しています。
振り分け先の設計
知見の種類に応じて、蓄積先を明確に分けています。
- 案件実績・エピソード → 実績データベース（記事執筆の素材として使用）
- AIツールの使用知見・比較 → ツール知見データベース（新しいツール体験や運用方針の変更時に追記）
- 記事の投稿記録 → 既存記事CSV（重複防止のため）
- ルール変更 → 該当するルールファイル（コーディング規約・記事執筆ルール・ビジネス方針など）
- 分類しにくい一時的な知見 → learnings/フォルダ（月単位で蓄積し、月末に棚卸し）
重要なのは、「保存して」と言われるまで待たないという設計です。私がセッション中に質問に回答したり、案件の詳細を説明した時点で、Claude Codeが自動的に該当ファイルに追記します。一次情報は発生した瞬間に記録しなければ、次のセッションでは失われるからです。
learningsから正式DBへの昇格
すべての知見を最初から正確に分類できるわけではありません。「今は分類しにくいが、後で重要になるかもしれない情報」はlearnings/フォルダに一時保存します。
各エントリにはカテゴリ（tech / business / feedback / debug / idea）と日付を付け、月末に棚卸しを行います。重要なものは正式なデータベースに昇格させ、不要なものは削除する運用です。
例えば、あるセッションで「デザイン系MCPを外して、プロンプトとスキルでガイドラインを制定したほうがトータルコストが下がる」という知見を得ました。最初はlearningsに記録しましたが、その後の複数セッションで同じ判断が求められたため、AIツール知見データベースに昇格させました。今では新しいMCP連携を検討するたびにこの判断基準が参照されます。
知見蓄積ルールの進化
このルール自体も最初から完成形だったわけではありません。セッション間のコンテキスト引き継ぎを観察しながら、少しずつ微調整してきました。
最大のトレードオフは「保存する情報の量と質のバランス」です。全てを保存すれば知識の網羅性は保たれますが、トークン量が増えてコンテキストウィンドウを圧迫します。逆に絞りすぎると、必要な情報が欠落する。
「良いとこ取り」ができる構成を目指して、今もアップデートし続けています。具体的には、推測や一般論は蓄積しない、同じ情報を複数ファイルに重複して書かない、gitで追跡できる情報（コード変更内容）は蓄積しない、というルールを設けています。
知識管理を機能させる3つのコツ
コツ1: プロジェクト立ち上げ時の初期化テクニック
プロジェクトを新規に立ち上げた直後が最も重要です。最初のセッションでClaude Codeに覚えておいてほしいコンテキストを効率よく入力する必要があります。
ここで私が実践しているのは、一方通行で情報を提供するのではなく、質問形式で聞き返してもらう方法です。具体的には、Claude Codeに「このプロジェクトについて理解を深めるために質問してください」と依頼します。
すると、以下のような構造的に必要な内容を逆算した質問が返ってきます。
- プロジェクトの目的は何か
- 目的を達成するために何が必要か
- どのデータを保存すべきか
- 何を定期的に行うべきか
この質問に答えていくだけで、プロジェクトの方針・構成・運用ルールが自然とCLAUDE.mdやルールファイルに整理されます。人間が「何を伝えるべきか」を考える負担が大幅に減るのがこの方法の利点です。
逆に、最初のセッションで箇条書きのメモを一気に貼り付ける方法は、情報の優先順位が不明確になりがちです。質問→回答の往復で構造化するほうが、結果的にClaude Codeにとって読みやすいドキュメントが生成されます。
コツ2: プロジェクトの粒度設計
私は約6つのプロジェクトを運用していますが、この「分け方」は意外と重要です。3つの軸で判断しています。
- トークン量の節約: 1つのプロジェクトに全てを詰め込むと、CLAUDE.mdだけで膨大なトークンを消費する。関連性の低い情報は分離する
- コンテキストの維持: 相互に作用し合うことで品質が向上する部分は同一プロジェクトに置く。例えば、SEO記事の執筆ルールと案件実績データは密接に関連するため、同じプロジェクトに配置
- 人間側の認識しやすさ: Claude Codeだけでなく、自分自身が「今どのプロジェクトで作業しているか」を直感的に把握できる粒度にする
同一にすべきものは、相互参照で出力品質が上がる組み合わせです。私の場合、Webサイト開発・SEO記事執筆・営業資料・ビジネスデータは同一プロジェクトにまとめています。記事を書くときに案件実績を参照し、営業資料を作るときにサービス体系を参照するからです。
分離すべきものは、方針やポジションが混合されると混乱の原因になるものです。例えば、独立したgitリポジトリで管理しているSaaS開発は、コーポレートサイトとは別プロジェクトにしています。技術スタックもデプロイ先も異なるため、同じCLAUDE.mdに同居させると指示が競合します。
コツ3: 繰り返す作業のSkill化
知識管理と並んで重要なのが、繰り返し行われる作業をSkill化して、コンテキストに頼らず再現可能にすることです。
Skill（スキル）とは、Claude Codeに特定のタスクの実行手順を定義したファイルです。例えば私の場合、以下のようなスキルを運用しています。
- SEO記事の執筆 → MicroCMS投稿までの一連の流れ
- GSCデータの取得 → 分析レポートの生成
- X（旧Twitter）記事の生成 → 下書き保存
- 品質レビュー（QAチェック）
スキルの中に「このタスクに必要なルール・参照先・手順」が全て定義されているため、セッションが変わっても同じ品質のアウトプットが再現されます。知識管理が「プロジェクト全体の記憶」だとすれば、スキルは「特定タスクの手順書」です。両方が揃って初めて、セッションをまたいだ一貫性が実現します。
自己進化するのはモデルではなく、ハーネスである
ここまで読んで「Claude Code自体が賢くなっていくのでは？」と思った方がいるかもしれません。しかし私の実感は逆です。
変わったのはモデルではなく、ハーネス（CLAUDE.md・Skills・ルールファイル・知見データベースの総体）です。Claude Codeの基盤モデルがアップデートされることはありますが、日々の出力品質の向上に最も寄与しているのは、ハーネスの整備度合いです。
新しいセッションを立ち上げるたびに、前回のセッションで蓄積された知見が反映され、ルールが改善され、スキルが磨かれている。この積み重ねが「同じプロンプトでも、先月より今月のほうが良い出力が出る」という体験を生み出しています。
知識管理は地味な作業です。しかし、この基盤がなければClaude Codeはただの「高性能だが記憶のないツール」のままです。セッション間で知識が引き継がれる仕組みを作ることが、Claude Codeを真に業務の中核として活用するための最も重要な一歩だと考えています。
知識管理の具体的な実装に興味がある方は、以下の関連記事もご参照ください。
知見蓄積の仕組みを自動化する方法については、こちらの記事で詳しく解説しています。
CLAUDE.mdの設計と運用のコツについては、こちらをご覧ください。
Skillsによる業務自動化の具体的な手順はこちらで公開しています。
御社の業務に合わせたClaude Code導入支援
「AIツールを導入したが、現場で使われない」を終わらせる。
業務課題のヒアリングから設計、ハンズオン実践、運用定着まで一貫して支援します。