2026年2月、デイリーノートを書くのをやめる1週間のPoCをやりました。今年3月末を最後に、日付ファイルは1つも増えていません。今振り返ると、あのPoCがそのまま定着したことになります。
形骸化していた理由は、ルールではなく運用にあった
やめる前のデイリーノートは、こんな状態でした。
- 毎日決まった内容を書くという意識が続かない
- スケジュール通りに動けていない日が多い
- デジタルの手帳と紙の手帳で二重管理していた
- 書かない日もある
- タスクをどこに書くかが不安定で、情報が集約できていない
書くこと自体は悪くありません。悪かったのは「今日という単位で必ず1ファイル作る」という制約のほうでした。予定通りに動けなかった日ほど書くことがなく、書くことがない日ほど「サボった記録」だけが残ります。記録が目的化すると、こうなります。
1週間だけ試した3層アーキテクチャ
そこで組んだのが、記録先を3層に分けるPoCです。目的は「記録義務」を捨てて、「思考」と「成果」に集中するワークフローへ戻すことでした。
| レイヤー | ツール | 役割 |
|---|---|---|
| L1 | 手帳 | 揮発性の書き殴り。保存しない |
| L2 | プロジェクト単位のMarkdown | 実装ログ |
| L3 | Obsidian | 未来の自分に役立つ知見だけを蒸留して保存 |
どのレイヤーにも「今日の日記」は書かない、と決めたのがポイントでした。日次サイクルも3段階に分けています。朝の「Pull」でタスク管理ツールから今日やる分だけを選び、日中の「Flow」では書くことより終わらせることを優先します。夜の「Extract」だけ、手帳とログを見返して、来年の自分も使いそうな知見だけをObsidianへ新規ノートとして抽出します。
「この知見、来年の自分も使いそうか」に対してNOなら、そのまま閉じて何もしません。それが最高、というのがPoC時点のメモに残っています。
半年経って、実際に残った運用
1週間の実験のつもりでしたが、そのまま半年続きました。手帳は今も書き殴り専用で、見返さない前提のまま運用しています。プロジェクトのログは会社側のツールに残し、Obsidianには技術知見や汎用理論だけが増えていきます。この記事の元になったノートも、そうやって溜まった1つです。
続いた理由は、たぶん「書かない日があってもいい」設計にしたからです。デイリーノートは1日単位が管理の最小単位だったので、空白の日が失敗として残りました。3層に分けると、最小単位は「知見」になります。知見が生まれない日は、単に何も抽出しない日になるだけで、失敗になりません。
チームに広げるなら、要るのは記録ではなくトレーサビリティ
個人の運用としてはこれで足りますが、チームで同じ話をすると論点が変わります。ここで効いてくるのがトレーサビリティとADRです。
トレーサビリティとは、成果物がいつ・どこで・誰によって作られたのかを明らかにしておくことを指します。重要なのは、対応した判断だけでなく、対応しなかった判断も理由付きで残しておくことです。「なぜあの案は採用しなかったのか」は、採用した理由よりも忘れられやすいところです。
ADR（Architecture Decision Record）は設計判断の経緯を残す記録で、AI駆動開発が進むほど、この記録をどう保管・更新するかが新しい課題になっています。デザイン判断側にも同じ発想を持ち込んだDDR（Design Decision Record）という整理があり、背景・決定・代替案・影響・検証計画をセットで残します。共通しているのは、成果物そのものより「なぜそれにしたか」を成果物の外側に置く、という考え方です。
ドキュメントをGitで管理するメリットは、履歴からAIが変更経緯を追いやすくなることと、CodeownerやPR保護で意図しない変更を抑えられることにあります。デメリットは、毎回PRを立てる必要があり、変更頻度の低いドキュメントだとスピード感が失われる点です。ここは個人の3層運用と違って、トレードオフとして残ったままになっています。
AI時代は、経緯が消えやすい場所が増えた
AIチャットで設計や仕様を詰めると、その経緯はチャットの中に閉じたまま消えやすくなります。指示ファイルとテンプレートでADRやDDRの下書きを自動生成し、人間が確認し、pre-commitで記録漏れを検査する、という分担にすればこの負担を減らせます。
もう1つ気になっているのが、非公開チャンネルの話です。職場の会話をナレッジベースとして扱う発想では、非公開チャンネルはAIエージェントにとっての死角になります。エージェントはアクセスできる情報からしか学習できないので、会話や意思決定は公開チャンネルで行うことを既定にし、機密でない作業はデフォルトで公開する運用のほうが、チームと将来のAIの双方に効きます。
Loglass社の「.mdc駆動ナレッジマネジメント」の事例も近い発想だと感じました。Cursorのルールファイル（.mdc）に蓄積した知識を、MCPサーバー経由の「知識API」として提供する取り組みで、50名規模のエンジニア全員がCursorを使う前提で組まれています。ドキュメントを書く場所と、AIが読む場所を最初から一致させている点が効いていそうです。
ナレッジ化の生産性は、活動量では測れない
最後に、ずっと引っかかっていることを1つ書いておきます。ナレッジはドキュメントと同義ではありません。ドキュメントはナレッジの一部にすぎず、本題は暗黙知の整理と、チームとして集合的なナレッジを持てているかどうかです。
集合知の維持に必要な条件は、最新の状態を保ち続けることと、誰でもアクセスできる状態へ誘導することの2つに集約できます。組織が大きくなるほど、この2つの両立は難しくなります。ノートの数や更新頻度のような利用状況の指標は、「導入されているか」を示す脈拍チェックにすぎず、機能しているかの証明にはなりません。この線引きは、個人のObsidian運用にもそのまま返ってきます。ノートが増えたことを成果にしないよう、自分にも言い聞かせています。
まとめ
- デイリーノートが形骸化したのは、「今日という単位で必ず1ファイル作る」制約が続かなかったため
- L1（手帳・揮発性）、L2（プロジェクトログ）、L3（Obsidian・蒸留）に分け、最小単位を「日」から「知見」に変えたら半年続いた
- チームに広げるには、記録そのものより「なぜそう決めたか」を残すADR・トレーサビリティの発想が要る
- AIチャットや非公開チャンネルは経緯が消えやすい場所なので、公開をデフォルトにし、記録を仕組みで補う
- ナレッジ化の成果は活動量では測れない。最新性とアクセスしやすさの2条件で見るべき
PoCのつもりで始めた運用が、そのまま定着しました。次に崩れるとしたら、たぶん「知見の抽出」自体が面倒になったときのはずです。そのときはまたこの記事に追記します。