Memo

Memo — 知識倉庫への記録

現在のセッションから「後から振り返る価値のある知識」を抽出し、~/dev/knowledge/notes/ に Markdown で保存する。 このフォルダはユーザーが Obsidian の vault として開くため、Obsidian の流儀（ファイル名 = タイトル、ウィキリンク、frontmatter タグ）に従う。

記録の基準

記録するかどうかは、次の 1 問で決める。

半年後の自分が同じ場面に出くわしたとき、このノートが無いと同じ時間を使い直すか？

「検索すれば 5 分で分かる」なら記録しない。ノートが増えるほど、読み返す価値のあるノートが見つけにくくなる。該当が 0 件なら何も書かずに終了する。何も記録しないセッションがあってよい。

具体的な足切りは次のとおり。

• 原因の特定に複数回のやり取りを要したものだけを記録する。1 回で原因が分かったものは記録しない
• 公式ドキュメントに書いてある内容、ライブラリの基本的な使い方は記録しない
• 挙動については、調べても出てこなかったもの、またはドキュメントの記述と実際の動作が食い違ったものに限る
• 設計判断は、選択肢を複数比較して却下理由まで残す価値があるものに限る
• style / strength / weakness は、同じ傾向を 2 回以上観測したときだけ記録する。1 回の観測は傾向ではない

記録すべきもの

上の基準を通過したうえで、以下に分類する。

• knowledge: 実装を通して得た学び。ライブラリの非自明な挙動、API の落とし穴、デバッグで判明した原因など
• decision: 設計判断。検討した選択肢、採用した案とその理由、却下した案とその理由
• style: ユーザーのコーディング観・クセ・好み。指示の出し方、レビューコメント、選択の傾向から読み取れたもの
• strength: ユーザーの長所・強み。良い設計判断をした、鋭い指摘をした、リスクに先回りで気づいた、質問の筋が良かった、など上手くいった行動とその理由
• weakness: ユーザーの苦手・つまずき。理解が浅かった概念、繰り返しハマった箇所、質問が多かった領域、後から手戻りになった判断など。完全な失敗だけでなく、「つまずきかけたが確認・質問で自力回復したケース」も含める（確認が必要だったこと自体が知識の穴のシグナルであり、回復できたことは同じ事象の strength 側面として別途記録してよい）
• domain: 事業・業務ドメインの理解。業務フロー、用語、システムの背景、仕様の意図など実務固有の知識

style / strength / weakness は自己の振り返りが目的なので、お世辞ではなく根拠のある事実だけを書く。weakness も事実ベースで書き、人格評価はしない。

1 回の観測では記録しない。 同じ傾向を過去のセッションでも見たとき、または 1 セッション内で 2 回以上繰り返されたときに初めて記録する。単発の質問や確認は健全なやり取りであって、傾向ではない。既存ノートに同じ傾向がある場合は、新規作成せず ## 事例 に 1 行追記する。

観測の候補（これ単体では記録の理由にならない。繰り返しを確認してから書く）:

• 同じ概念について複数回、言い換えの質問があった
• 一度説明した内容について、後のターンで再度質問があった
• 実行したコマンドや修正が期待と違う結果になり、やり直した

保存先の振り分け

• 汎用的な内容（knowledge / decision / style / strength / weakness）→ notes/ に保存する。 実務プロジェクト由来でも、社名・案件名・仕様の詳細・コード断片を含めず、一般化した技術知識として書く
• ドメイン知識（domain）→ domain/<プロジェクト名>/ に保存する。実務固有の情報をそのまま書いてよい
• 迷ったら（一般化しきれない・実務の文脈と不可分な内容は）domain/ 側に倒す

記録すべきでないもの

• コードやコミット履歴を見ればわかること
• そのセッション限りの些末な作業ログ
• 検索や公式ドキュメントで分かること。ライブラリの基本的な使い方
• 1 回のやり取りで原因が判明し、解決した問題
• 1 回しか観測していないユーザーの傾向
• 「やってみたら動いた」で終わり、なぜ動いたかを説明できないもの

二段運用 — 逐次1行メモと節目の清書

長いセッションではコンテキスト圧縮で序盤の学びが劣化するため、記録は2段階で行う。

作業の途中（設計判断が確定した・非自明な挙動が判明した・ユーザーの良い判断やつまずきを観測した直後）は、inbox に1行追記するだけで本来の作業に戻る。ノートの清書はしない:

echo "- YYYY-MM-DD (プロジェクト名) [type]: 内容の1行要約" >> ~/dev/knowledge/inbox.md

節目（コミット直後・PR マージ直後・レビュー指摘対応完了直後、またはユーザーが /memo を明示的に呼んだとき）は、下の手順に従って inbox の未処理行とセッションの記憶からノートを清書・統合する。清書し終えた行は inbox.md から削除する。

手順

0. 倉庫が存在しない場合は作成する:

   mkdir -p ~/dev/knowledge/notes ~/dev/knowledge/domain
   

1. ~/dev/knowledge/inbox.md があれば読み、未処理行をトピック候補に含める。 あわせてセッションを振り返り、記録価値のあるトピックを抽出する（0件なら何もせず終了する）。 抽出したトピックは 1 件ずつ「記録の基準」の足切りに通し、通らなかったものは捨てる。 0 件になった場合はノートを作らずに終了する（無理に 1 件ひねり出さない）

2. 各トピックについて、既存ノートを検索する（notes/ と domain/ の両方）:

   ls ~/dev/knowledge/notes/ ~/dev/knowledge/domain/*/
   grep -ril "<キーワード>" ~/dev/knowledge/notes/ ~/dev/knowledge/domain/
   

   同じトピックの既存ノートがあれば新規作成せず追記・更新する。 特に style / strength / weakness は既存ノートへの事例の追記が基本形（傾向は積み重ねで初めて見えるため）

   あわせて、付与しようとしているタグと同義の既存タグがないか確認する（表記揺れによる集計分裂を防ぐため）:

   grep -h "^tags:" ~/dev/knowledge/notes/*.md ~/dev/knowledge/domain/*/*.md 2>/dev/null | tr -d '[]' | sed 's/tags: //' | tr ',' '\n' | tr -d ' ' | sort | uniq -c | sort -rn
   

   新しいタグを作るのは、既存タグのどれにも意味的に収まらない場合のみとする。

3. 新規の場合、ファイル名は内容がひと目でわかる簡潔な日本語タイトルにする。 style / strength / weakness は傾向そのものをタイトルにする（例: 早期リターンを好む.md、エッジケースへの嗅覚が鋭い.md、非同期処理の考慮漏れが多い.md）。 日付プレフィックスは付けない（Obsidian のリンクとグラフビューはファイル名ベースのため）

4. 以下の形式で書く:

   ---
   date: YYYY-MM-DD          # 初回記録日。事例追記時は last_seen を更新する
   last_seen: YYYY-MM-DD     # style / strength / weakness のみ。最後に観測した日
   project: プロジェクト名（横断的なものは general）
   type: knowledge | decision | style | strength | weakness | domain
   tags: [具体的な技術名やテーマ]
   ---
   
   本文
   

   タグの表記規則:

   • 英語・小文字・kebab-case に統一する（例: spring-batch、error-handling）。日本語タグは使わない

   • 固有名詞も小文字に倒す（例: macos、windowserver）

   • 単数形を基本とする（例: secret）。ただし -ing 形など既存の慣習があればそちらを優先する

   • ライブラリのメジャーバージョンはタグに含めない（spring-batch-6 ではなく spring-batch。バージョン固有の話は本文に書く）

   • knowledge は「何が起きたか」「何がわかったか」を含める

   • decision は「検討した選択肢」「採用理由」「却下理由」を含める

   • style / strength / weakness は「どういう傾向か」の要約に続けて、必ず ## 事例 セクションを設け、 観測するたびに - YYYY-MM-DD (プロジェクト名): 何があったか を1行追記する。 strength は「なぜそれが効いたか」も事例に添える（再現可能にするため）。 weakness は可能なら ## 対策 セクションに改善のヒントも書く。 自力回復したケースでは、事例に「どう回復したか」（何を確認したら理解できたか）も添える（有効な学習パターンの分析材料になる）

   • domain は「業務がどう動くか」「なぜその仕様なのか」を、コードを知らない未来の自分にも わかる形で書く

   • 本文は通常の文体（ずんだもん口調にしない）で、簡潔に書く

5. 関連する既存ノートには本文中に [[ノート名]] でウィキリンクを張る（手順2の検索結果を活用する）。 逆方向のリンクが自然な場合は、既存ノート側にも [[新ノート名]] を追記してよい

6. 記録内容の報告はしない。実装作業の流れで自動記録した場合は、記録に一切言及せず本来の作業の報告だけを行う （ユーザーが意識しなくても知識が蓄積されていくのがこの仕組みの意図）。 ユーザーが明示的に /memo を呼んだ場合のみ、記録したファイル名を1行で伝える