Guide

/check-in — 作業再開時に打つ

• スキルを起動すると、AIが記録しているアクティビティの一覧が表示されるので、再開したいものを選ぶだけ
• 選択すると、関連する決定事項やこれまでの経緯を一括で取得してくれる
• もし期待していたアクティビティが一覧にない場合は、それはAIが自動生成に失敗しているということなので、AIに明示的に作成を依頼してみるとよい
• タイミング: 前回の続きの作業を再開するとき

/tag-notes — 常に覚えていてほしい情報を残す

• 特定のタグを扱うときにAIが必ず参照する情報を登録・更新できる
• MEMORY.mdに近いが、特定のタグに紐づく点が異なる。そのタグに関連する作業が始まったときだけ自動的にAIに注入される
• 用途の例:
  • 特定ドメインに関する用語集やリポジトリの前提知識
  • 特定のintent（議論・設計など）で作業するときの振る舞いやスタンスの定義
• 初期状態では「discuss」と「design」のintentが登録されている。変更したくなったらこのスキルで更新できる
• タイミング: コンテキストに関係なく、常に覚えていてほしい情報があるとき

その他のスキル

• /postmortem — 完了したアクティビティを振り返り、うまくいったこと・いかなかったことを整理して、教訓をtag-notesやhabitsに永続化する。大きめの作業が終わったあとに
• /scribe — cc-memoryに蓄積された記録（決定事項・ログ・資材など）からドキュメントを生成する。ADR、議事録、設計ドキュメントなどを書き起こしたいときに
• /tag-cleanup — タグの共起分析を実行して、似たタグの統合や不要タグの整理を提案してくれる。記録が増えてきたら不定期に

よくあるパターン

設計議論 → 実装の流れ

1. 新機能の議論を始める → AIがトピックを作成
2. 議論の中で方針が決まる → AIが決定事項（decision）を記録
3. 設計が固まったら作業アクティビティを作成
4. /sync-memory でセッション終了
5. 次のセッションで /check-in 、もしくは「〇〇の作業の続きをしていこう」→ 前回の決定事項を把握して実装開始

途中で中断した作業の再開

1. /check-in でアクティビティを選択
2. AIが関連のコンテキストを取得してくる
3. 前回どこまでやったか把握して続きから再開

記録の構造

• トピック: 1つの関心事・問題・機能（話題が変わったら新しく作る）
• 決定事項（decision）: 双方が合意した結論。「何を・なぜ」を記録
• ログ（log）: 議論の経緯・生情報。決定に至るプロセスを保存
• アクティビティ: ある程度の活動の塊。デフォルトで議論・設計・作業の3つのフェーズを用意している
• リレーション: トピック・アクティビティ間の関連。check-inで2親等まで自動取得され、get_mapでさらに探索できる
• 資材（material）: 長い生情報のオフロード先。独立エンティティとしてタグ付きで保存され、リレーションでトピック・アクティビティと関連付けられる
• タグノート: タグに紐づく常備情報。関連作業時にAIへ自動注入される
• 振る舞い（habits）: check-in時にAIへ毎回注入されるルール。「materialの書き方」「コミット前の確認事項」など、常に従ってほしいルールを登録できる。AIに「覚えといて」と言えばOK

熟練度別アドバイス

初めて使うあなたに

cc-memoryは、セッション間で文脈を保持するためのツール。 セッションが終われば会話は消えるが、cc-memoryに記録された情報は次のセッションに引き継がれる。

やることは1つだけ: セッション終了前に /sync-memory を打つ。

これだけで、AIがセッション中の議論・決定事項・進捗をまとめて記録する。 次のセッションでは、AIが自動的に過去の記録を取得して文脈を把握した状態で会話を始められる。

• /sync-memory を毎セッション終了前に打つ。これだけで十分
• 記録が貯まるほどAIの初手精度が上がることを実感できるはず
• 前回の続きの作業があるときは /check-in でアクティビティを選ぶと、関連する決定事項や経緯を一括取得できる

使いこなしたいあなたに

cc-memoryは情報を構造的に管理している。 主な記録単位は トピック（話題）、決定事項（合意）、ログ（経緯）、アクティビティ（行動の塊）、資材（生情報のオフロード先）の5つで、タグがそれらに横断的な特徴を付与する。

このうちトピック・決定事項・ログ・資材はAIが比較的うまく記録してくれる。 しかしアクティビティの切り方とタグの付け方は、AIだけでは精度に限界がある。 アクティビティとは行動の単位であり、「何をやるか」だけでなく「何をやらないか」を暗に定義する。 その境界を引くにはプロジェクト全体の文脈や優先度の判断が必要で、これはAIが持ち合わせていない知識に属する。

だから、ユーザーが能動的にAIに指示を出すことで記録の質が大きく変わる。

• アクティビティの範囲を指示する: 「このissueの調査をアクティビティにして」「設計と実装は別アクティビティに分けて」のように、自分が管理したい粒度で切るようAIに伝える。AIに任せると1セッション＝1アクティビティになりがちだが、実際には1セッションで複数の話題を扱うことも、複数セッションで1つの作業を続けることもある
• タグを指示する: 「domain:backendをつけて」「sprint-3タグで管理したい」のように、自分の整理軸をAIに伝える。domain:タグはアクティブコンテキスト（SessionStart hookの注入情報）のグルーピングに直結するので、複数プロジェクトを扱うなら早めに設計しておくと効く
• 議論→設計→作業のフェーズを意識する: 急いで作業に入らず、議論と設計を丁寧にやるとAIの引き継ぎ品質が上がる。「まず議論フェーズで進めて」「設計が固まったら作業アクティビティを作って」のように、フェーズ遷移も明示するとAIが適切なintent:タグ（discuss / design / implement）を付けてくれる
• /tag-notes で繰り返し伝えていることを永続化する: 同じフィードバックを2回以上したら登録のサイン。「AIに毎回言い直している指示」があれば、それはtag-notesに書くべき情報

長く使っていくあなたに

cc-memoryは使い続けるほど価値が出るツールだが、放っておいて勝手に良くなるわけではない。 AIが自力では知りえない情報をユーザーが教えてあげることで、記録の質と活用精度が根本的に変わる。

AIに教えるべき情報

時間を取って、以下のような情報をAIに伝えてみてほしい。一度伝えれば、tag-notesやhabitsとして永続化され、以降のセッションで自動的に参照される。

• 取り組んでいるプロジェクトの概要: 何を作っていて、なぜ作っているのか。AIはコードは読めるが、プロジェクトの目的やビジネス上の文脈は知らない
• プロジェクトとディレクトリの対応: 「このリポジトリは〇〇プロジェクトのバックエンド」「△△はこのmonorepo内のpackages/appにある」など。domain:タグと紐づけておくと、check-in時の文脈取得が的確になる
• ユビキタス言語: プロジェクト固有の用語や略語。AIが勝手に別の言い回しで記録すると、後から検索で引っかからなくなる

データ保護（スナップショット）

cc-memoryはセッション開始時（SessionStart hook）にDBの自動スナップショットを取得する。デフォルトでは12時間間隔で、最新5世代を保持する。スナップショットはDBと同階層の snapshots/ ディレクトリに保存される。

自動検知と警告:

セッション開始時にヘルスチェックが実行され、前回スナップショットと比較してテーブルの行数が100件以上減少している場合、AIに緊急警告が注入される。この警告が表示された場合は、ユーザーに即座に状況を報告すること。

スナップショットからの復元手順:

1. 全てのClaude Codeセッションを閉じる（DBへの書き込みを停止するため）
2. スナップショット一覧を確認する:

   ls ~/.claude/.claude-code-memory/snapshots/
   

3. 復元を実行する:

   python scripts/snapshot.py restore <snapshot_db_path>
   

4. Claude Codeを再起動する

スナップショット一覧の確認:

snapshots/ ディレクトリ内の .json ファイルにメタデータ（作成日時、DBサイズ、各テーブルの行数）が記録されている。復元先を選ぶ際の参考にできる。

カスタマイズできるもの

• tag-notes: タグに紐づく常備情報。そのタグに関連する作業が始まったときにAIへ自動注入される。/tag-notesで確認・更新できる
• 振る舞い（habits）: 文脈を問わず、check-in時にAIへ毎回注入されるルール。AIに「覚えといて」と言えばOK
• intent:タグのtag-notes: 議論・設計・作業の各フェーズでAIにどう振る舞ってほしいかを定義できる。初期状態でdiscussとdesignが登録されている
• 環境変数: .mcp.jsonのenvフィールドで以下の値をオーバーライドできる。未設定ならデフォルト値で動作する

現在の設定値はget_config()ツールで確認できる。

定期メンテナンス

記録が増えてくると、タグが散らかったり似たようなタグが乱立したりする。 不定期に /tag-cleanup を実行して、タグの共起分析と整理をしておくと、検索精度と分類の質を維持できる。