Notionを「生活OS」にする試み ― NLOS v1.1で入口を自由にした話

はじめに

前回の記事で、Notionを「生活OS」として運用するフレームワーク「NLOS（Notion Life Operating System）」を紹介しました。あれから2週間ほど運用してみて、「ここは変えたほうがいいな」と思うところが出てきたので、v1.1としてアップデートした話を書いていきます。

この記事はv1.0の続編ですが、NLOSの概要もおさらいするのでこの記事単体でも読むことができます。

フレームワークって、作った直後は「とりあえずこれで回るだろう」と思うものですが、実際に回してみると「あれ、ここ回り道してるな」みたいな部分が見えてきます。NLOSもまさにそうでした。

NLOS(v1.0)のおさらい

NLOSは5つのデータベースで構成されています。

DB	役割
Notes	メモ、設計、記録などの保管庫
Task	課題・成果の管理単位。工数見積や期間管理を持つ
Todo	「今日・明日やること」の短期実行枠。カレンダー連携の正本
Project	複数のTaskを束ねる成果の器
Journal	生活ログ。日記や振り返り

NotesとTaskは双方向リレーションで繋がっていて、Taskを進める中で生まれたメモや設計はNotesに記録されます。あとから「このTaskの時に何を考えていたか」を辿れるのが便利です。

タグの2層構造

Notesの管理にはタグを使っています。

状態タグ ― ノートが今どのフェーズにいるか

inbox：未処理（キャプチャ直後）
seed：Task/Todoに振り分け済み（起点として保持）
hold：保留（週次レビュー対象）
archive：不要/終了（保管のみ）

内容タグ ― ノートの中身の性質

memo：短いメモ、途中経過
document：設計・仕様・結論など、参照価値が高いもの

「今どうすべきか」と「何が書いてあるか」を分けて管理できるのがこのタグ体系のポイントです。

v1.0の肝：Notes起点のNLOS Loop

v1.0では「すべてはNotesから始まる」をルールにしていました。何か思いついたら、まずNotesにinboxで入れる。そこから行動が必要か判定して、必要ならTask/Todoに変換する。

これはGTDの「まずキャプチャして、あとから振り分ける」という考え方を取り入れたもので、「これはTaskかな、Todoかな」と迷う時間を減らすのが狙いでした。

詳しくは前回の記事で書いているので、気になる方はそちらを見てください。

v1.0を2週間運用して見えた課題

v1.0を実際に回してみると、理想と現実のギャップが見えてきました。

起点はNotesじゃなかった

自分の1日を振り返ると、起きている時間のうち仕事の割合が大きいです。仕事中はプロジェクトのページを開いて、そこからTaskを追加して、工数見積や期間を設定して、NotionカレンダーからTodoを作る。この流れが一番自然でした。

つまり、ページ追加の起点はNotesではなくTaskだったんです。

「今日やること」も同じで、Notes経由ではなくNotionカレンダーからTodo直接作成が多かった。明確にやることが決まっているのに、わざわざNotesに書いてからTask/Todoに変換するのは回り道でしかない。

GTDの「Ubiquitous Capture」に反していた

ここで思い出したのがGTDの原則です。GTDでは「入口は1つに限定しない」が基本。キャプチャの摩擦をできるだけ減らすことが大事で、入口を限定すると逆効果になる。

v1.0の「すべてはNotesから」は、GTDの考え方を取り入れたつもりが、肝心の「Ubiquitous Capture」に反していました。

入口を限定すると何が起きるか。

摩擦が増える → そもそもキャプチャしなくなる
明確なタスクまでNotesを経由させられる → 非効率

フレームワークを作った時は「Notes起点で統一するのがシンプルでいい」と思っていたのですが、実運用では「シンプル」と「摩擦が少ない」は別物でした。

v1.1で変えたこと

1. Multi-Entry方式の採用

v1.1での一番大きな変更がこれです。「すべてはNotesから」をやめて、「状況に応じた最適な入口を選ぶ」にしました。

3つの入口にはそれぞれ役割があります。

パターンA: Task起点（仕事で最も多い）

Project配下でTask作成 → 工数見積・期間設定 → NotionカレンダーでTodo追加 → 実行中にNotesを追加

パターンB: Todo起点（今日やることが明確）

NotionカレンダーからTodo作成 → 必要ならTaskにリンク → 実行 → 完了

パターンC: Notes起点（曖昧なもの・アイデア）

Notes作成（inbox）→ 行動判定 → 必要ならTask/Todo化（inbox → seed）

v1.0では全部パターンCだったのを、状況に応じてA/B/Cを使い分けるようにした。それだけの変更ですが、運用の摩擦がかなり減りました。

デバイスによっても自然な入口は違います。

状況	デバイス	主な入口
生産活動中（仕事・開発）	PC	Task/Todo直接
非生産活動中（SNS・動画等）	スマホ	Notes inbox or Journal

PCで仕事している時はTask/Todoから直接入るし、スマホでSNS見ていて「これいいな」と思ったらNotes inboxに放り込む。この使い分けが自然で、ルールとして明文化したことで迷いがなくなりました。

2. タグ体系の拡充

v1.0では内容タグがmemoとdocumentの2種類でしたが、実運用していると「これはmemoでもdocumentでもないな」というものが出てきました。

具体的には、Claude Codeでの作業ログやリサーチ結果の記録です。作業メモにしては構造的だし、ドキュメントにしては完成度が低い。

そこでv1.1ではlog、plan、researchを追加して5種類にしました。

タグ	用途
memo	作業メモ・雑記・途中経過（自分で記載）
log	作業ログ・セッションの記録
plan	実装方針・計画・要件
research	リサーチ結果の記録
document	設計/仕様/結論など、人に見せられるレベルでまとめた資料

特にlogとresearchは、Claude CodeからNotion MCP経由で作成されることが多いです。それぞれClaude CodeのSkillsとして作っていて、リサーチはAIにリサーチさせた結果を記録、ログはセッションの作業ログを残す用途です。

documentが体系立った成果物だとすると、logはそのdocumentに至るまでの経緯が辿れるもの。自分の疑問やAIとのやり取りが残っているので、「なぜこの設計にしたんだっけ」を後から確認できます。

あと、状態タグのholdは結局使っていません。inboxのまま置いておいて、定期的に見返して判断する運用になったので、holdの出番がなくなりました。わざわざ「保留」に移すより、inboxに残しておく方が自然だったということです。

3. ボタンの整理

v1.0ではadd_documentとadd_memoでタグ別にボタンを分けていましたが、v1.1ではタグが4種類に増えたのでadd_notesに統一して、タグは手動で付ける方式にしました。

タグ別にボタンを4つ作る案もありましたが、ボタンが増えすぎるのも考えもの。add_notesで作成してから手動でタグを付ける方が、結果的にシンプルでした。

v1.1の運用感

v1.1にしてから2ヶ月以上経ちますが、特に不満なく使えています。

個人運用なので、ルールを緩めにしたv1.1の方が自分には合っています。v1.0の「すべてはNotesから」は、ルールとしてはきれいでしたが、きれいなルールが使いやすいルールとは限らない。

入口を限定しないことで「とりあえずキャプチャする」ハードルが下がった実感があります。仕事中にTaskから直接入れるようになっただけで、だいぶストレスが減りました。

まとめ

v1.0からv1.1へのアップデートを振り返ると、変更点自体はシンプルです。

Multi-Entry方式: 入口をNotesに限定せず、状況に応じてTask/Todo/Notesを選ぶ
タグ拡充: memo/documentの2種から、memo/log/plan/research/documentの5種へ
デバイス別の入口: PCはTask/Todo直接、スマホはNotes inbox/Journal

一番の学びは、入口を限定しないほうが続くということです。きれいなルールより、摩擦の少ないルールの方が実運用では生き残る。

もう一つ、フレームワークは使いながら育てるものだと改めて思いました。机上で考えた設計がそのまま完璧に動くことはなくて、使ってみて初めて見える課題がある。v1.0を作った時は「これで完成」と思っていましたが、2週間で改善点が出てきた。でもそれは失敗じゃなくて、v1.0を実際に運用したからこそ見えたことです。

NLOSはこれからも使いながら調整していくと思います。また大きな変更があったら書きます。