ツェッテルカステンが扱わない作業状態管理層：work-hubの設計と運用
概要¶
この記事では以下の内容について扱います：
- ツェッテルカステンを運用しているときに発生する、 走り書きメモの枠に収まらない情報の扱いについて
- ツェッテルカステンについては こちらの記事 で紹介
- 知識の永久保存と時間軸管理の間に位置する状態管理層
work-hubについて
走り書きメモの分類¶
ツェッテルカステンを運用していると、走り書きメモのフォルダ _wip に入ってきたメモが以下に分類されることが分かりました：
- 自分の思い付きのメモ
- 読書メモ（要約〜本文丸ごとまで）
- 何かの概念を知った後に、さらに調べようと思った参考リンク集
最初の2つはツェッテルカステンの範疇なので問題ないです。
読書メモで本文丸ごと保存されている場合であっても、それ自体は内容量が多くとも「分解してツェッテルカステンに入れる」という目的のためなので問題ありません。
3番目の「何かの概念を知った後に、さらに調べようと思った参考リンク集」は、他の2つとは違います。
それは「さらに調べる」という作業と状態が含まれているためです。
つまり、3番目は作業状態を管理する場所が必要だし、それはツェッテルカステンでやるべきではないということです。
graph TB
subgraph "_wip"
w1[思いつきのメモ]
w2[読書メモ]
w3[さらに調べるリンク集]
end
subgraph "ツェッテルカステン"
w2 -->|調整して保存| Z2[文献・読書メモ]
w1 -->|調整して保存| Z3[メインメモ]
end
w3 -->|さらに調査が必要| M -->|調べた結果| _wip
subgraph "調査のための場所が必要！"
M[調べる]
end
この作業状態のメモがあると、走り書きメモのフォルダ _wip が「洞察を得るのか分からない情報」で重くなります。
そこで、 work-hub という状態管理層を作ることにしました。
work-hubの構成について¶
情報の質による分類¶
私の例ですと、既にツェッテルカステンとリマインダーは導入していました。
しかし、リマインダーはトリガーに過ぎません。
そこで、知識の永久保存（ツェッテルカステン）と時間軸管理（リマインダー）の間に位置する work-hub という状態管理層を作ることにしました。
情報の質によって以下のような分類ができます：
stateDiagram-v2
[*] --> input
input: 情報を得た
input --> ZK: 洞察がある
ZK: ツェッテルカステン
state ZK {
[*] --> _wip: 思いつき・読書メモを記録
_wip --> Main: 繋がりを考える
_wip --> Info
Main --> [*]
Info --> [*]
_wip: _wipで保管
}
input --> workhub: 作業要素がある
workhub: work-hub
state workhub {
[*] --> planning: やることを記録
planning --> active: 実行
active --> completed: 完了
completed --> [*]
}
input --> Reminder: 時間軸がある
Reminder: リマインダー
state Reminder {
[*] --> notification: その時が来た
notification --> execute
execute --> [*]
notification: 通知
execute: タスク実行
}
work-hubの原則¶
work-hub の原則は以下のとおりです：
- 「ツェッテルカステンに昇華する前の低品質な作業メモ」を許容
- タスクを実行して、洞察がなければツェッテルカステンには取り込まない
- 完璧を求めず、実行の痕跡を残すことを優先
- タスク一覧インデックスは自動生成にする
フォルダ・ファイル構成¶
以下のようなフォルダ構成で、複数のタスクを管理します：
work-hub/
└─ tasks/ # タスクごとのフォルダ
├─ README.md # タスク一覧（自動生成・編集禁止）
├─ nvim-refactor/
│ ├─ README.md # タスク概要
│ └─ migration-steps.md # 調査メモ2
└─ rag-system/
├─ README.md
└─ architecture.md
個別のタスクファイルのフォーマットで最低限必要なのはフロントマターだけです：
---
title:
status: planning
date: 2026-02-21
tags: []
---
work-hub をGitHub管理しておけば、GitHub Actionsでフロントマターの情報を読み取ってタスク一覧インデックスを自動更新することができます。
タスク一覧インデックスの例：
# Projects Index - Complete History
## 🚀 Active
- [文章解析ツールの改修](./morph-tools-expansion/) 2025-12-24 [morph]
## 📋 Planning
- [ローカル翻訳ツール実装](./implement-translate-tool/) 2026-01-18 [ai, translate]
- [work-hubをローカルで運用する基盤構築](./work-hub-local/) 2025-12-13 [work-hub]
- [キーボードの複数接続設定方針](./keyboards-connect-strategy/) 2025-12-13 [keyboard]
## ✅ Completed
- [ブログにllms.txtと英語メタデータを追加](./add-blog-llms-english/) 2026-01-31→2026-01-31 [blog]
- [RSLをブログに入れる](./blog-rsl/) 2026-01-04→2026-01-13 [rsl, blog]
work-hubの運用について¶
タスクのライフサイクル¶
タスクのライフサイクルは3段階です：
- planning: タスク追加時
- active: タスク実行時
- completed: タスク完了時
一定期間経過したらオミットするようなことはしません。
planning 状態にしていたが不要になった作業も出てきますが、このようなタスクは理由を書いて completed にします。
タスクの内容をツェッテルカステンに取り込む判断¶
もしもタスク実行時・タスク完了時にツェッテルカステンに記録するような洞察があれば、そのときは _wip を経由してツェッテルカステンに記録します。
例えば「nvim設定を1ファイルから複数ファイル構成にする」タスクの場合。
これ自体はnvim設定ファイルの init.lua を分割するだけの作業です。
既にあるものを分割するだけなので、洞察は得にくいです（ただし、その分離の方法が自分にとって意義があれば、その観点でツェッテルカステンに入れるのは可能です）。
逆に「RSLをブログに入れる」タスクであれば、 RSL の導入が「最近流行っているから」であったとしても、「どうしてRSLができたんだろう」といった観点でツェッテルカステンに入れることが可能です。
チャットAIとの連携¶
work-hub のテンプレートが決まれば、AIとのチャットで調べたいと思った内容を work-hub の内容に落とし込むことが容易になります。
Skills といった機能もあるので、チャットの最後に「work-hubでまとめて」と指示すると、設定したテンプレートでチャット内容をまとめるのが楽になります（もちろん、そのまとめの内容が正しいかは人間が判断しないといけませんが）。
「ローカル翻訳ツール実装」タスクでの実例を示します。
Googleの TranslateGemma が発表されたことをきっかけに、 Claude と英文翻訳のツールを実装したいというチャットをしました。
既に私の扱う情報システム（ツェッテルカステンなど）について、プロジェクトナレッジでClaudeに設定している状態なので、それを考慮した情報をまとめることができます。
work-hub タスクファイル：
---
title: ローカル翻訳ツール実装
status: planning
date: 2026-01-18
tags: [ai, translate]
---
## Why
英文読書時の認知負荷削減と、ツェッテルカステンのInfo/wiki自動育成を両立させたい。特に：
- 専門用語の即座の意味確認（辞書引きの中断コスト削減）
- 用語の実用文脈理解（辞書的定義では不足）
## Outcome
**Phase 1（即時実装）**: WordNet + spaCyによる最小実装
- 選択テキスト → wiki初期稿生成スクリプト
- Obsidian Shell Commandから実行
- 出力先: Info/wiki/
**Phase 2（検討課題）**: TranslateGemma統合
- 条件: Phase 1運用で「pragmatic情報不足」が顕在化した場合