Obsidianを長期知識の正本にする一方、タスクは人が一覧で見て、担当や期限を変えられる場所が必要でした。そこでNotionを「仕事の受付と進捗確認」に限定して使うことにしました。
最小のプロパティから始める
タスク用データソースには次の列を用意しました。
| 役割 | 例 | 型 |
|---|---|---|
| タイトル | Name | title |
| 状態 | Status | status |
| Hermes側ID | Hermes Task ID | rich_text |
| 要約 | Summary | rich_text |
| 最終エラー | Last Error | rich_text |
| 優先度 | Priority | select |
| 情報源 | Source | select |
| 期限 | Due | date |
開始・完了日時も追加できますが、最初から列を増やしすぎない方が検証しやすくなります。既存データベースを使う場合は、コードに列名を固定せず環境変数で対応付けます。
DatabaseではなくData Sourceを意識する
Notion APIは2025年以降、DatabaseとData Sourceの関係が明確になりました。2026年7月20日時点の最新APIバージョンは2026-03-11で、タスク一覧の取得にはPOST /v1/data_sources/{data_source_id}/queryを使います。
内部接続には対象データベースを共有し、読み取り権限を付与します。共有していない場合は、存在していても404になる点に注意します。
先にスキーマ検証を行う
Hermes Agentからタスクを読む前に、列名、型、Statusの候補が期待どおりか検証するToolを用意しました。列が一つ不足しているだけなら、実行途中で曖昧なエラーになる前に止められます。
確認順は次の通りです。
- 接続状態とAPIバージョンを確認する
- Data Source IDが設定されているか確認する
- 必須列の存在と型を検証する
- Status候補を検証する
- 件数を絞って一覧を読む
役割を限定すると二重管理を防げる
Notionへ会議全文や原資料まで複製すると、Obsidianとのどちらが正しいか分からなくなります。Notionにはタスク名、状態、期限、短い要約、元資料へのリンクだけを置きます。詳細な記録と出典はObsidianに残します。
再現チェック
- [ ] 最新の
Notion-Versionを公式で確認した - [ ] 対象データベースを内部接続へ共有した
- [ ] Data Source IDを使用した
- [ ] 必須列の名前と型を検証した
- [ ] 取得件数に上限を設けた
- [ ] NotionとObsidianの正本を分けた
次回は、Notionへの作成・更新でも書き込みを初期無効にし、二段階確認を入れます。