はじめに
Claude Code で作業を続けていると、コンテキストの圧縮によって過去のやり取りが参照できなくなることがあります。昨日議論した内容を翌日には引き継げていない。これは現在のLLMが抱えている仕様上の制約で、Claude Code を日常的に使っているなら、誰もが経験あるのではないでしょうか。
この制約に対処するために、Claude Code のセッションが終わるタイミングでworklog（作業記録）とtranscript（会話記録）を自動で残す仕組みを作りました。私が指示しなくても記録が自動で蓄積される構造です。
しばらく運用して作業記録が溜まってくると、あることに気づきました。何度も同じ指摘を繰り返していることや、よくあるループや失敗がこの記録に残っている。そこからパターンや傾向を見出せるのではないか。これはコンテキスト喪失への対策だけでなく、ナレッジとして価値があるんじゃないかと。
作業するだけで、自動で作業記録が溜まり、ナレッジが集まり、勝手に改善提案まで出てくる仕組みを作った話です。
この記事を読んで得られること
- 作業記録からナレッジを集め、既存のCLAUDE.mdやSkillsへ改善提案まで出す仕組みの設計
- 実際に動かしたら各スキルから何が出てきたかの具体例
- 仕組みから生まれた副産物（AI行動ガイドラインという成果物と、ナレッジ共有の流れを組み換える発想）
自動で溜まって勝手に改善する仕組み
今回作った仕組みの流れです。
作業する
↓
summarize-worklog が作業記録（worklog / transcript）を蓄積
↓
knowledge-collect が作業記録からナレッジを集める
↓
knowledge-suggest-improvements がナレッジから改善提案を生成
↓
人が採用 / 却下を判断
以下、それぞれの設計と出力の形を説明します。運用実績や具体的な提案内容は次の章で紹介します。
summarize-worklog（PreCompact / SessionEnd hook でトリガー）
| 項目 | 内容 |
|---|---|
| インプット | Claude Code のライフサイクルイベント（PreCompact / SessionEnd） |
| 処理 | worklogとtranscriptを自動で書き出して蓄積する |
| アウトプット |
docs/worklog/worklog_*.md、transcriptバックアップファイル |
Claude Code のセッションが終わるタイミングで、作業記録と会話記録を自動で書き出します。AIに「記録を残して」と依頼する方法もありますが、依頼を忘れた時点で記録が途切れます。Claude Code の PreCompact / SessionEnd hook で summarize-worklog をトリガーする形にすることで、記録するかどうかの判断自体を不要にしました。
worklogには、セッションごとの作業内容が構造化されて残ります。作業目的、実施内容、判断・決定事項、発生した問題、残課題、そして質疑応答が章立てで記録され、セッションのたびに自動で追記されていきます。出力はこんな形です。
## 2026-03-25 09:45 - 14:22 (JST) - work-base 基盤整備・スキル更新・symlink 一元管理
### セッション概要
- 作業内容: HANDOVER.md 未着手タスク（#3, #4, #5, #8）の実施、doc-review スキル更新、standards の symlink 化
### 実施作業
- タスク A: README.md 作成
- タスク B: CLAUDE.md 更新(permissions 記述を確認済みに更新)
- タスク C: ユーザーレベル hooks 設定(~/.claude/settings.json に SessionStart / PreCompact / SessionEnd を追加)
- タスク D: 全13プロジェクト移行(hooks キー削除 → 旧hookファイル削除 → symlink 作成)
### 重要判断・方針決定
- doc-review スキルの検証フェーズにステップ9追加(数値検算、日付検証、ペア要素一体検証)
### 質疑応答・ナレッジ創出
**Q**: なぜ symlink 方式に切り替えたのか？
**A**: 原本を work-base に集約し、各プロジェクトから symlink で参照することで、原本更新が全プロジェクトに自動反映される仕組みを作るため。
summarize-worklog はこのworklogを書き出すと同時に、同じセッションの会話そのものをtranscriptとしてバックアップします。worklogが要約だとすれば、transcriptはその要約の元になった一次情報です。要約では落ちてしまう細かな言い回しや前後の文脈まで、後から辿れるようにしています。
記録を確実に残すことがこの仕組み全体の土台です。残せない状態を避けるために、実装ではオーケストレーターを介してリトライ（3回）と排他制御（mkdirロック）を設け、worklogの書き込みが失敗した場合の5段階フォールバック（正常書き込み → 権限修正 → 緊急保存 → /tmp退避 → 失敗記録）も用意しました。日常的に使う仕組みなので、失敗時に黙って止まらないようにしています。
knowledge-collect
| 項目 | 内容 |
|---|---|
| インプット | worklog、transcript |
| 処理 | 作業記録から客観的事実のみを抽出し、ナレッジファイルに追記する |
| アウトプット | knowledge_facts.md |
summarize-worklog で蓄積された作業記録から、客観的事実だけを抜き出してナレッジファイル（knowledge_facts.md）に集めます。
ナレッジファイルには事実だけを入れます。後続の提案を作成する際に、事実と解釈が混ざった情報を元にすると、提案の質が落ちるためです。解釈は提案生成の段階で目的に応じて行います。過去に集めた事実は書き換えず、追記のみにしています。作業記録は作業の量に比例して膨れていくので、作業記録が長い場合は2,000行単位でチャンク分割して処理します。
集められた事実はこんな形で並びます。
### スキル修正→再実行→再レビューの検証サイクル
- 事実: スキル修正後に同一プロジェクトで再実行・再レビューし、修正前後を定量比較することで改善効果を客観的に測定できた
- 根拠:
- work-base/worklog_create_base.md（2026-03-25）: test-design スキル第1次改善→再実行→CT 62→107件（+73%）、8項目中7項目「高」効果
### AI非決定性による同一データでの分析結果の不一致
- 事実: 同じ入力データに対して、AIによる分析結果が実行ごとに揺れる事例が複数プロジェクトで発生した
- 根拠:
- model-development-templates（2026-03-06）: CV計算方式の曖昧性により、2つの異なるライフサイクル分類結果が出力された
- test-project-v1.1.0: 5回目実行で季節性判定が変化
一件ごとに「事実」と、その根拠となる worklog/transcript へのパスが対で残ります。あとから「この事実は本当にあったのか」を一次情報まで辿れるようにしています。
knowledge-suggest-improvements
| 項目 | 内容 |
|---|---|
| インプット | ナレッジファイル（knowledge_facts.md） |
| 処理 | 既存のCLAUDE.mdやrules.md、Skillsに対する改善提案を生成する |
| アウトプット | P-nnn形式の改善提案 |
ナレッジファイルのデータを分析して、既存のCLAUDE.mdやrules.mdなどの設定ファイル、Skillsに対する改善提案（P-nnn）を生成します。集めたナレッジをそのままにせず、日常的に動いている設定ファイルやSkillsの改善に還元する流れを作りました。
提案の質を担保するために2層フィルタを設計しました。
| フィルタ | 役割 | 基準 |
|---|---|---|
| 除外フィルタ | ノイズの排除 | 既存カバレッジ重複、一般常識、粒度不適切を除外 |
| 影響度×根拠件数フィルタ | 確度の担保 | 影響度高は根拠5件以上、影響度低は根拠10件以上 |
1つの事実から1つの提案を生成する原則（バンドル禁止）も設けています。複数の事実をまとめると根拠が曖昧になるためです。提案が乱発されても設定ファイルやSkillsが肥大化し、却って効果が落ちるためフィルタはかなり厳格に設定しました。
実際に出力された提案は下記です。
### P-002: AI非決定性対策としての「標準文書曖昧性チェック」のスキル更新ワークフローへの組み込み
- 対象: CLAUDE.md のスキル更新ワークフローセクション
- 操作: 修正
- 影響度: 高
- 提案内容: スキル更新ワークフローに「標準文書を更新した場合は skill_creation_guide §5-4 の曖昧性チェック（計算対象の曖昧性・計算方式の曖昧性・判定基準の区別不足）を実施すること」のステップを追加する
- 根拠: AI非決定性による同一データでの分析結果の不一致（5件: development-templates x2, test-project-v1.1.0 x1, test-project x2）
- 根拠件数: 5件
対象ファイル、操作の種類、提案内容、根拠の件数と内訳が提案ごとに記録されます。採用/却下の履歴もこの形式で追記されていき、却下された提案でも新しい根拠が集まれば再提案が可能です。
実際に各スキルを動かした結果
では、この仕組みを自分が作業をしているなかで実際に走らせたら、どんなナレッジが集まって、どんな改善提案が出てきたのか。各スキルから出てきたものを順に紹介します。
summarize-worklog の運用実績
summarize-worklog は約3ヶ月前から動き続けています。現在、12プロジェクトをまたいで worklog 28件・transcript 517件 が自動で蓄積されている状態です。記録を残すことを意識せずに、セッションが終わるたびに黙々と記録が積み上がっていきます。意識しなくなった瞬間に、仕組みとしては意図通りに動いていると言っていい状態です。
knowledge-collect の運用実績
12プロジェクト分のworklog・transcriptを対象に動かした結果、ナレッジファイルには現在までに111件の事実が集まっています。内訳は、繰り返し成功したパターン、繰り返し発生する問題、成功と失敗の対比など、作業の中で何度も現れる型が中心です。
単発の作業から出てくる気づきは埋もれがちですが、複数のプロジェクト・複数のセッションで同じ構造が繰り返されると、それは「型」として集まってきます。10件や20件ではまだ埋もれた気づきですが、100件を超えてくると「あ、これ何度も起きてるな」というパターンが見えてきます。
knowledge-suggest-improvements の運用実績
knowledge-suggest-improvements を最初に全件で動かしたときの結果です。
- 候補: 99件（ナレッジファイルから抽出された改善候補）
- 除外フィルタで除外: 97件（既存カバレッジ重複・一般常識・影響度×根拠件数不足）
- 提案として採用: 2件
さらにその後の実行で1件が追加され、最終的に改善提案（P-nnn）が3件生成されました。
| 提案 | 対象 | 根拠件数 | 判定 |
|---|---|---|---|
| P-001 | スキル設計原則にスコープ逸脱防止を追加 | 6 | 採用 |
| P-002 | スキル更新ワークフローへの曖昧性チェック組み込み | 5 | 採用 |
| P-003 | コンテキスト耐性設計の全スキルへの横展開 | 7 | 却下 |
それぞれを少し深掘りします。
P-001（採用）: スキル実行時にスコープが勝手に拡大する事例（指示範囲外のファイルまで変更してしまう等）が、複数のプロジェクトのworklog/transcriptから集められていました。根拠が6件に達したところで、knowledge-suggest-improvements が「スキル設計ガイド（docs/guides/skill_creation_guide.md）の §3-3『スキル設計の基本原則』にスコープ制約原則を新規追加する」という提案を生成しました。対象ファイルと追加すべきセクションが具体的に出てきたので、そのまま修正に反映しています。
P-002（採用）: 同じ入力データに対してAIの分析結果が実行ごとに揺れる事例が5件集まりました。knowledge-suggest-improvements は原因を「標準文書の曖昧性」とみなし、CLAUDE.md のスキル更新ワークフローセクションに曖昧性チェックのステップを追加する提案を生成しました。こちらもそのまま採用し、CLAUDE.md に反映しています。
P-003（却下）: コンテキスト圧縮による作業中断・再実行が複数プロジェクトで発生している事象に対し、knowledge-suggest-improvements が「個別スキルのSKILL.md にコンテキスト耐性設計を横展開する」提案を出しました。根拠は7件と十分です。ただし、この提案を採用すると各スキルが実行されるたびにコンテキスト耐性設計の記述を毎回読み込むことになり、毎回のコンテキスト消費が増えます。一方で、セッション中断→再開の発生頻度はそこまで高くない。コストが効果に見合わないと判断して却下しました。
2層フィルタを通過してきた提案でも、最終的な採否は人が判断します。仕組みは「ここに判断が必要です」という提案を出すところまでを担当し、採用/却下の判断は人に残しておく設計です。
普通に作業していただけで、集まったナレッジから3件の提案が出てきて、そのうち2件がそのままスキル設計ガイドとCLAUDE.mdの改善に反映されました。人が探したわけではなく、仕組みが勝手に拾って提案までしてくれました。
仕組みを動かして生まれた副産物
この仕組みを動かしている中で、さらに二つのアイデアが生まれました。ひとつは仕組み化まで進んだもの、もうひとつは発想にとどまっているものです。
AI行動ガイドライン（仕組み化まで進んだ副産物）
仕組みを試しに動かしていたところ、ナレッジを集めるだけでなく、私自身の行動パターンも抽出できるのではないかと思いつきました。行動パターンから行動原理を抽出できれば、AIが私の意図を理解してフォローできるようになるのではないかと。このアイデアから、行動パターンを集める機能を追加し、AI行動ガイドラインが生まれました。最初は手作業で自分のプロファイルを組むところから始めて、それをスキルで自動化し、さらに観察記録から行動指針に文体を変換する、という段階を経ています。
後編では、このAI行動ガイドラインを使って、AIを優秀な助手としてカスタマイズする方向に試してみた話をします。
ナレッジ共有の流れを組み換える（発想にとどまっている副産物）
ここまで見てきた仕組みを動かしていて、あるとき気づきました。作業するだけでナレッジが集まり、改善提案まで出てくる——これは、ナレッジ共有の構造そのものを組み換える試みでもあったのではないか。
従来のナレッジ共有は「人→人」の流れで成り立っています。誰かが何かを発見し、言語化し、共有する。別の誰かがそれを探し、読み、活用する。
この構造にはいくつかの問題があります。共有の質は発信する人の能力に左右されます。言語化の得手不得手によって、同じ知見でも伝わり方が変わる。そもそも共有するかどうかは発信者の意図に委ねられていて、「これは共有すべきだ」と判断されなかった知見は埋もれます。受信する側も、「誰かに聞こう」「ドキュメントを探そう」と自分から動かなければ、必要な情報に辿り着けません。つまり従来のナレッジ共有は、発信側にも受信側にも人の意図が必要で、その意図が欠けた瞬間に知見が止まる構造です。
ここで、共有の主語を「人」から「AI」にずらしてみると、こういう構造が見えてきます。
| 従来のナレッジ共有 | 主語をAIにした理想像 | |
|---|---|---|
| 発信 | 人が発見・言語化・共有する | AIが作業記録を自動で蓄積する |
| 判断 | 「共有すべきか」を人が判断する | AIが自動で蓄積するため判断が不要 |
| 受信 | 必要な人が自分で探しに行く | AIが蓄積層からナレッジを集めて提案する |
| 人がすること | 発信と受信の両方を担う | 提案の採用/却下のみ |
人A ──(作業)──→ AのAI(記録) ──→ 作業記録の蓄積層
人B ──(作業)──→ BのAI(記録) ─↗ ↓
各人のAI(ナレッジ収集・提案) ──→ 人A, 人B
今回作ったのは、この構造の手前まではいっています。自分のAIが自分の作業記録からナレッジを集めて、自分向けの改善提案を出すところまで。「共有しよう」と意図する必要もなく、「探しに行こう」と動く必要もなく、ナレッジが集まって改善提案まで出てくる形が、まず1人の環境で動いています。この構造が機能すれば、別の人のAIが蓄積層を介してナレッジを取得し、提案に使う道も開けます。ここは仕組みとしては手がついておらず、発想にとどまっている部分です。
おわりに
この記事を書いている最中にも、仕組みに救われる場面がありました。
以前のセッションで、この記事で使う用語についてAIに疑問を投げたことがありました。ところが、しばらく時間が経ってから同じ話題に戻ったとき、AIは過去のやり取りを把握できていません。コンテキストの圧縮で失われていたのです。
「worklogかtranscriptを検索してみて」とAIに指示すると、summarize-worklog で蓄積されていたworklogから当時のやり取りがすぐに見つかりました。そして分かったのは、その時の私は用語そのものへの疑問を投げていたのに、当時のAIは「読者に伝わるか」という可読性の議論にずらして返していたということです。コンテキストに残っていれば引き摺られたかもしれないずれが、記録を横から見ることで初めて見えてきました。
蓄積されているのはworklogだけではありません。生のtranscript（会話記録）もセットで残っているので、要約では落ちてしまう細かな言い回しや、そのとき何を考えていたかまで、記憶ではなく記録から辿れます。
作業するだけで、自動で作業記録が溜まり、ナレッジが集まり、勝手に改善提案まで出てくる。そしてコンテキストの圧縮で失われたはずの過去のやり取りも、必要なときに取り出せる。まずは私の環境で、この仕組みが今も動いています。
後編もぜひご覧ください。