
Claude Code × Obsidian Daily Note運用を半年続けて3つの改善を試してみた
はじめに
データ事業本部のkasamaです。
ObsidianのDaily Note運用を開始してから約半年が経過し、試行錯誤を重ねながら3つの大きな改善を実施しました。今回は、前回・前々回の運用からの学びと改善内容を共有します。
前提
本記事は、前回のブログで紹介したdaily-morningとdaily-eveningコマンドの改善内容を扱います。
前々回のブログ 前回のブログ
前回のブログで紹介した2つのコマンドについて簡単に説明します。
daily-morningコマンドは、朝の業務開始時に実行します。前日のDaily Noteから「明日やる」を取得し、Google Calendarの予定を読み込んで、今日のDaily Noteを作成します。
daily-eveningコマンドは、夜の業務終了時に実行します。今日のDaily Noteを読み込み、Google Calendarと照合し、6つの質問(各プロジェクトの実績、振り返り、明日やること)に答えてDaily Noteを更新します。
半年の運用で気づいたこと
振り返りの形骸化
運用開始時は、「感謝・Good・Motto」の3項目で振り返りを記録していました。しかし、2ヶ月ほど運用を続けた頃、毎日同じパターンの回答になりがちで、自分の成長目標との連動が弱いという問題に気づきました。具体的には、「今日は頑張ってタスクできた、集中してできた、疲れた、特になし」といった適当な振り返りになっていました。
質問の手間
daily-eveningコマンドで6つの質問にシーケンシャルに回答する必要があり、時間がかかっていました。例えば、案件Aに対してタスクが3つあった場合、一つの質問で3つのタスク全てを音声か手動入力しなければいけませんでした。しかし、進捗ステータスは大体同じで、未着手、進行中、レビュー中、完了だけだったので、この手間を減らしたいと考えていました。
タスク状態が視覚的に分かりにくい
- [ ] API設計
- [/] 実装進行中
- [R] コードレビュー待ち
- [x] テスト完了
VS Codeなどのエディタで見る分には記号で判断できましたが、Obsidianで見た時は全てチェックボックスとして表示されるため、進捗状態が視覚的に区別できませんでした。正しくステータス管理ができていない状態でした。実際には以下のようにObsidian上は表示されます。

これら3つの課題に対しての改善として実装を修正したので紹介します。
実装
今回の実装コードは、GitHub上に格納してあるのでご確認いただければと思います。
前回のブログから更新した内容だけ紹介します。
daily-eveningの実装
.claude/commands/daily-evening.md
---
allowed-tools: Bash(cd:*), Bash(date:*), Bash(TZ=:*), Bash(uv:*), Bash(find:*), Write, Read, Glob, Edit, LS
argument-hint: [YYYY-MM-DD]
description: 成果と明日の計画でデイリーノートを更新(オプション: 特定の日付)
---
# デイリーノート夜用アシスタント(更新)
## 日付の扱い
- date引数($1)がYYYY-MM-DD形式で指定された場合、その日付を使用
- 引数が指定されない場合、今日の日付(JST)を使用
- 対象日付: ${TARGET_DATE}
## 環境変数
```txt
PROJECT_A = "Aプロジェクト"
PROJECT_B = "Bプロジェクト"
PROJECT_C = "Cプロジェクト"
GOAL_1 = "技術力の向上"
GOAL_2 = "プロジェクト管理能力の強化"
GOAL_3 = "コミュニケーション能力の向上"
```
## タスク
1. 引数から対象日付を決定、または今日の日付を使用
2. 対象日付のGoogle Calendarイベントを取得
3. 対象日付のデイリーノートを検索して読み込む
4. 成果と振り返りについて5つの質問をユーザーに一つずつ行う
5. 回答と自動生成された明日のタスクで既存のデイリーノートファイルを更新
### ステップ0: 対象日付の決定
```bash
TARGET_DATE="$1"
if [ -z "$TARGET_DATE" ]; then
# 明示的にJSTタイムゾーンを使用
TARGET_DATE=$(TZ=Asia/Tokyo date +%Y-%m-%d)
fi
echo "Processing daily note for: $TARGET_DATE"
```
### ステップ1: カレンダーイベントの取得
```bash
cd .claude && uv run today_cal/today-calendar.py --date "$TARGET_DATE"
```
カレンダー出力を解析して対象日付のイベントを理解し、関連する質問を生成する。
### ステップ2: 対象日付のデイリーノート検索
- 重要: 現在のディレクトリは`.claude/`なので、Globを使用する際は`path=".."`を指定する必要がある
- bashコマンド`find ../01_Daily -name "${TARGET_DATE}.md" -type f`を使用して対象のデイリーノートを検索
- または`Glob(path="..", pattern="01_Daily/**/[TARGET_DATE].md")`を使用
- ファイルは`01_Daily/YYYY/MM/[TARGET_DATE].md`形式である必要がある
- ファイルを読み込んで現在のコンテンツ構造を理解
### ステップ3: カレンダーコンテキストを使用したユーザーへの質問(AskUserQuestionツールを使用)
まず、Google Calendarのイベントを分析してプロジェクトに対応付ける。次にAskUserQuestionツールを使用してチェックボックス形式で質問を行う。
重要: 以下のすべての質問にAskUserQuestionツールを使用する。これにより、インタラクティブなチェックボックス・選択インターフェースが提供される。
ステータス番号: 1=未着手, 2=進行中, 3=レビュー中, 4=完了
中止したタスクは「Other」フィールドから入力する際に打ち消し線を含めて入力可能(例: ~~タスク名~~)
#### 質問パターン(プロジェクトごと)
重要: 各プロジェクトについて、複数の質問(最大4つ)を含む単一のAskUserQuestion呼び出しを使用する。これにより、ユーザーが質問を切り替えられるTab付きインターフェースが作成される。
各プロジェクト(PROJECT_A、PROJECT_B、PROJECT_C、ブログ・その他)について
1. 質問を行う前に、このプロジェクトのGoogle Calendarイベントを示すテキストメッセージを出力
2. デイリーノートからプロジェクト内のすべてのタスクを収集
3. 「未定」のタスクはスキップする - ステータスを尋ねない
4. タスクごとに1つの質問を作成(追加タスク質問のためのスペースを残すため最大3タスク)
5. 追加タスクについて尋ねる最後の質問を追加
6. すべてのタスクが「未定」の場合、追加タスクの質問のみを行う
7. すべての質問を1回のAskUserQuestion呼び出しで送信
まず、次のようなテキストメッセージを出力する
```text
## {PROJECT_NAME}のタスク進捗
Google Calendar予定
- [event 1]
- [event 2]
```
Then ask questions
タスクステータス質問フォーマット(プロジェクト内の各タスクについて)
```text
タスク「[タスク内容]」の状態を教えてください。
```
header: "タスク[N]" (e.g., "タスク1", "タスク2", etc.)
multiSelect: false
タスクステータスのオプション
- label: "未着手", description: "タスクにまだ着手していない"
- label: "進行中", description: "タスクを進行中"
- label: "レビュー中", description: "タスクがレビュー待ち"
- label: "完了", description: "タスクが完了"
中止したタスクは「Other」フィールドから打ち消し線付きで入力(例: ~~タスク名~~)
追加タスク質問フォーマット(プロジェクトの最後の質問)
```text
{PROJECT_NAME}で追加でやったタスクがあれば「Other」で入力してください。なければ「なし」を選択してください。
```
header: "追加タスク"
multiSelect: false
オプション(最低2つ必要)
- label: "なし", description: "追加タスクはありません"
- label: "入力する", description: "Otherで追加タスクを入力します"
注: ユーザーは「Other」フィールドから追加タスクを入力できる。
例: PROJECT_Aに2つのタスクがある場合、Tabとして表示される3つの質問(タスク1、タスク2、追加タスク)を含む1回のAskUserQuestion呼び出しを送信する。
#### 質問1: PROJECT_Aのタスク進捗
PROJECT_Aセクションの各タスクについてAskUserQuestionツールを使用
#### 質問2: PROJECT_Bのタスク進捗
PROJECT_Bセクションの各タスクについてAskUserQuestionツールを使用
#### 質問3: PROJECT_Cのタスク進捗
PROJECT_Cセクションの各タスクについてAskUserQuestionツールを使用
#### 質問4: ブログ・その他のタスク進捗
ブログとその他セクションの各タスクについてAskUserQuestionツールを使用
#### 質問5: 今日の振り返り(目標に沿った振り返り)
振り返りにはAskUserQuestionツールを使用しない。代わりに、振り返りを求めるテキストメッセージを出力する
```text
今日1日を設定した目標に沿ってKPT形式で振り返ってください(該当する観点があれば教えてください)
- {GOAL_1}に関連する振り返り
- {GOAL_2}に関連する振り返り
- {GOAL_3}に関連する振り返り
```
ユーザーのテキスト回答を待つ。ユーザーは振り返りたい各カテゴリについて自由形式のテキスト回答を提供できる。
重要: ユーザーが1回回答したら、追加の確認や質問は一切せず、そのまま次のステップ4に進むこと。1つまたは2つの目標だけに言及した場合でも、それ以上質問せず受け入れる。
### ステップ4: デイリーノートファイルの更新
すべての回答を収集した後、デイリーノートファイルを更新する
1. `01_Daily/YYYY/MM/[TARGET_DATE].md`ファイルを読み込む
2. MTG・イベントセクションを更新
- すべてのGoogle Calendarイベントを`- [x]`(参加)としてマーク
- デイリーノートには存在するがGoogle Calendarにないイベントは打ち消し線でマーク: `- [ ] ~~イベント名~~ (実施せず)`
3. 今日のTodoセクションを更新
- 完了した項目を`- [x]`としてマーク
- 進行中の項目を`- [/]`として更新
- レビュー中の項目を`- [R]`としてマーク
- 中止した項目はチェックボックスはそのままで、タスク名を打ち消し線`~~タスク名~~`でマーク
- 未着手の項目は`- [ ]`のまま保持
- 進捗詳細を更新(例: 「実装進める」→「実装80%完了、動作検証に移行」)
4. 今日の振り返りセクションを更新
- ユーザーが言及した目標のみを記載
- 言及されなかった目標のセクションは空のまま(`-`のみ)にしておく
- ユーザーの回答を箇条書きで追加
5. 明日やるセクションを更新
- 「今日のTodo」セクションから完了していないタスク(状態が[x]でないもの)を自動抽出
- 以下のステータスのタスクを含める: [ ] 未着手, [/] 進行中, [R] レビュー中
- 以下のタスクを除外: [x] 完了, 打ち消し線が付いているタスク(中止)
- これらのタスクを「明日やる」セクションにコピーし、すべてのチェックボックスを[ ]にリセット
- プロジェクトに残りタスクがない場合、「[ ] 未定」に設定
すべてのステップを実行し、ただちにファイルを更新すること。
更新例
```markdown
## MTG・イベント
- [x] 08:30 - (プロジェクトA)実装 # Google Calendarにあった予定
- [x] 11:00 - (プロジェクトB)内部MTG # Google Calendarにあった予定
- [ ] ~~14:00 - (プロジェクトC)内部MTG~~ (実施せず) # Daily noteにあったがGoogle Calendarになかった予定
- [x] 終日 - 自宅 # Google Calendarにあった予定
## 今日のTodo
- Aプロジェクト
- [x] 実装80%完了、動作検証に移行 # 完了
- [/] APIテスト進行中 # 進行中
- Bプロジェクト
- [x] 単体テスト完了、結合テスト開始 # 完了
- [R] コードレビュー待ち # レビュー中
- Cプロジェクト
- [x] アーキテクチャ検討完了、構成図作成中 # 完了
- [ ] ~~会議が中止になったため延期~~ # 中止
- ブログ
- [ ] (予定なし) # 未着手
- その他
- [ ] (予定なし)
## 今日の振り返り
### {GOAL_1}
- [ユーザーが言及した場合のみ回答内容を記載]
### {GOAL_2}
-
### {GOAL_3}
-
## 明日やる
- {PROJECT_A}
- [ ] [今日のTodoから未完了タスクを自動抽出]
- {PROJECT_B}
- [ ] [今日のTodoから未完了タスクを自動抽出]
- {PROJECT_C}
- [ ] [今日のTodoから未完了タスクを自動抽出]
- ブログ
- [ ] [今日のTodoから未完了タスクを自動抽出]
- その他
- [ ] [今日のTodoから未完了タスクを自動抽出]
```
daily-eveningコマンドでは、以下の2つの改善を実施しました。
1つ目は振り返り形式の見直しです。個人の成長目標に直接結びつく3つの観点(GOAL_1/2/3)を設定し、KPT形式で振り返りを記録するように変更しました。これにより、毎日の振り返りが「何をしたか」ではなく「何を学んだか」にシフトし、月次レビュー時に目標ごとにKPT(Keep・Problem・Try)分析ができるようになりました。また、抽象的な「よかったこと」ではなく、「どの目標に対してどう成長したか」が明確になります。個人的に、中期や期末の振り返りが苦手で、Backlogチケットから目標達成度を振り返るのに苦労しています。先週やったことすら曖昧なのに、半年前となると正直思い出せません。だからこそ、達成したことを日々記録し、評価のタイミングでAIにまとめれば、かなり効率化できるのではと考えています。
2つ目はTab形式UIの導入です。Claude CodeのPlan modeで使われているAskUserQuestionツールを活用し、各プロジェクト内でタスクごとのステータスをTab形式で質問できるようにしました。
従来は各プロジェクトの実績をテキストで回答していました。
質問1 PROJECT_Aの実績を教えてください
[ユーザーがテキストで回答]
質問2 PROJECT_Bの実績を教えてください
新しい方式では、各プロジェクト内で複数のタスクをTabで切り替えながらステータスを選択できます。
質問1 PROJECT_Aのタスク進捗
Tab1「実装を進める」の状態
○ 未着手 ○ 進行中 ○ レビュー中 ○ 完了
Tab2「お客様定例の準備」の状態
○ 未着手 ○ 進行中 ○ レビュー中 ○ 完了
Tab3 追加タスク
○ なし ○ 入力する
質問2 PROJECT_Bのタスク進捗
この変更により、各プロジェクト内で複数タスクのステータスをTabで切り替えながら一度に確認・更新でき、チェックボックス形式で選択するだけなので回答が早く、自動更新が容易になりました。
monthly-reviewの実装
.claude/commands/monthly-review.md
---
allowed-tools: Bash(cd:*), Bash(date:*), Bash(TZ=:*), Bash(find:*), Write, Read, Glob, LS
argument-hint: [YYYY-MM]
description: デイリーノートからKPT形式の月次振り返りを生成(引数なしで実行月、引数ありで指定月)
---
# KPT形式の月次振り返り生成
## 日付の扱い
- 引数なし: 実行日の月のまとめ(例: 2025-12-26実行時は2025-12)
- 引数1つ(YYYY-MM形式): 指定月のまとめ(例: 2025-11)
- 対象日付: ${START_DATE} 〜 ${END_DATE}
## 環境変数
```txt
PROJECT_A = "Aプロジェクト"
PROJECT_B = "Bプロジェクト"
PROJECT_C = "Cプロジェクト"
GOAL_1 = "技術力の向上"
GOAL_2 = "プロジェクト管理能力の強化"
GOAL_3 = "コミュニケーション能力の向上"
```
## タスク
完全なレビューを生成するために、以下のステップを順番に実行する
### ステップ0: 対象期間の決定
引数がない場合は実行日の月を使用する。
```bash
if [ -z "$1" ]; then
# 引数なし: 実行日の月
TARGET_MONTH=$(date +%Y-%m)
echo "Generating review for current month: $TARGET_MONTH"
else
# 引数1つ: 指定された月
TARGET_MONTH="$1"
echo "Generating review for: $TARGET_MONTH"
fi
# 開始日と終了日を計算
START_DATE=$(date -j -f "%Y-%m" "$TARGET_MONTH" +%Y-%m-01)
# 終了月の月末を取得
NEXT_MONTH=$(date -j -v+1m -f "%Y-%m" "$TARGET_MONTH" +%Y-%m-01)
END_DATE=$(date -j -v-1d -f "%Y-%m-%d" "$NEXT_MONTH" +%Y-%m-%d)
```
### ステップ1: デイリーノートの検索と読み込み
- 重要: 現在のディレクトリは`.claude/`なので、親ディレクトリから検索する必要がある
- bashコマンド`find ../01_Daily -name "*.md" -type f | sort`を使用してすべてのデイリーノートを検索
- Globツールを使用する場合、`path=".."`パラメータを明示的に指定する必要がある: `Glob(path="..", pattern="01_Daily/**/*.md")`
- 対象の日付範囲(START_DATEからEND_DATE)内のファイルをフィルタリング
- デイリーノートは`01_Daily/YYYY/MM/YYYY-MM-DD.md`のパターンに従う
- 対象期間に該当する各ファイルを読み込む
### ステップ2: 情報の抽出と分析
各デイリーノートから以下を体系的に抽出する
1. MTG・イベント - 完了した会議とイベント(以下の条件を満たす項目)
- [x]マークがついている
- かつ、以下のキーワードのいずれかを含む:「定例」「MTG」「会議」「1on1」「○○会」
- 作業時間ブロック(括弧で始まるプロジェクト作業)は除外
2. 今日のTodo - プロジェクトカテゴリ別のタスクとステータス追跡
- [ ] 未着手
- [/] 進行中
- [R] レビュー中
- [x] 完了
- [-] 中止
3. 今日の振り返りセクション(KPT観点で分析)
- {GOAL_1}の内容から、Keep(うまくいったこと)、Problem(課題)、Try(次に試したいこと)の要素を抽出
- {GOAL_2}の内容から、Keep、Problem、Tryの要素を抽出
- {GOAL_3}の内容から、Keep、Problem、Tryの要素を抽出
4. 明日やる - 作成された計画
5. その他の重要なコンテンツや成果
### ステップ3: 事実ベースの集約と分析(KPT構造)
抽出した情報を事実ベースで整理する
重要: タスクとMTG・イベントは重複を排除してユニークなリストにする
1. 案件別の実績 - {PROJECT_A}、{PROJECT_B}、{PROJECT_C}別に完了したタスクと成果を列挙
- 同じタスク名が複数の日に登場しても、1回だけ表示する
2. 目標達成状況(KPT形式) - {GOAL_1}、{GOAL_2}、{GOAL_3}の各目標について
- Keep: うまくいったこと、効果的だった取り組み、継続すべきこと
- Problem: 課題、問題点、うまくいかなかったこと、障壁
- Try: 来月試すこと、改善策、新しく取り組むこと
3. 数値による実績
- 総タスク数: すべてのユニークなタスク(完了、進行中、未着手、レビュー中、中止を含む)を重複排除してカウント
- 完了タスク数: [x]マークがついたユニークなタスクをカウント
- 完了率: 完了タスク数 ÷ 総タスク数 × 100(小数点第1位まで)
- MTG・イベント参加数: [x]マークがつき、キーワード条件を満たすユニークなイベントをカウント
- デイリーノート記録日数: 対象期間内に存在するデイリーノートの日数をカウント
- 重要: すべての数値は正確にカウントすること。推測や概算は絶対に記載しないこと
### ステップ4: レビューファイルの作成
`02_Monthly/YYYYMM_review.md`にファイルを生成する
以下のテンプレート構造を使用し、実際のデータとインサイトを入力する
レビューテンプレート
```markdown
# 月次振り返り(KPT) - [期間表示]
## 対象期間
- [START_DATE] 〜 [END_DATE]
## 案件別の実績
### {PROJECT_A}
- 完了したタスク
- [x] [具体的なタスク内容]
- [x] [具体的なタスク内容]
- 参加したMTG・イベント
- [日付] [MTG名]
### {PROJECT_B}
- 完了したタスク
- [x] [具体的なタスク内容]
- 参加したMTG・イベント
- [日付] [MTG名]
### {PROJECT_C}
- 完了したタスク
- [x] [具体的なタスク内容]
- 参加したMTG・イベント
- [日付] [MTG名]
### その他(ブログ・その他)
- 完了したタスク
- [x] [具体的なタスク内容]
## 目標達成状況(KPT形式)
### {GOAL_1}
- Keep(継続すべきこと)
- [うまくいったこと、効果的だった取り組み]
- [関連する完了タスクやMTG参加]
- Problem(課題・問題点)
- [うまくいかなかったこと、障壁になったこと]
- [未達成のタスクや発生した問題]
- Try(来月試すこと)
- [改善策、新しく取り組むこと]
- [具体的なアクションプラン]
### {GOAL_2}
- Keep(継続すべきこと)
- [うまくいったこと、効果的だった取り組み]
- [関連する完了タスクやMTG参加]
- Problem(課題・問題点)
- [うまくいかなかったこと、障壁になったこと]
- [未達成のタスクや発生した問題]
- Try(来月試すこと)
- [改善策、新しく取り組むこと]
- [具体的なアクションプラン]
### {GOAL_3}
- Keep(継続すべきこと)
- [うまくいったこと、効果的だった取り組み]
- [関連する完了タスクやMTG参加]
- Problem(課題・問題点)
- [うまくいかなかったこと、障壁になったこと]
- [未達成のタスクや発生した問題]
- Try(来月試すこと)
- [改善策、新しく取り組むこと]
- [具体的なアクションプラン]
## 定量的な実績
- 総タスク数: XX件(すべてのユニークなタスク)
- 完了タスク数: XX件
- 完了率: XX.X%
- MTG・イベント参加数: XX件
- デイリーノート記録日数: XX日
```
すべてのステップを実行し、ただちにファイルを作成すること。
以下を含むKPT形式の振り返りファイルを作成する
1. 適切な日付計算と範囲決定
2. 範囲内のすべてのデイリーノートからの体系的な抽出
3. 案件別の完了タスクとMTG参加の記録(重複を排除したユニークなリスト)
4. 目標ごとのKPT分析
- Keep: デイリーノートの振り返りから、うまくいったこと、効果的だった取り組みを抽出
- Problem: 課題、問題点、うまくいかなかったことを抽出
- Try: 来月試すこと、改善策、新しく取り組むことを提案
5. 定量的な実績(タスク数、完了率、MTG数など)
重要な注意事項
- 主観的な評価や推測は避け、デイリーノートから抽出できる事実のみを記載すること
- タスクは重複を排除し、同じタスク名は1回のみ表示すること
- MTG・イベントは「定例」「MTG」「会議」「1on1」「○○会」などのキーワードを含むもののみを抽出すること
- 作業時間ブロック(括弧で始まるプロジェクト作業)は除外すること
- KPTの各要素はデイリーノートの振り返りセクションから具体的な内容を抽出して記載すること
- 定量的な実績の数値は、すべて正確にカウントすること。推測や概算は絶対に記載しないこと
- 総タスク数は、すべてのステータス(完了、進行中、未着手、レビュー中、中止)のユニークなタスクをカウントすること
最終ファイルを`02_Monthly/`ディレクトリに保存すること。
monthly-reviewコマンドは、デイリーノートから月次振り返りを自動生成します。引数なしで実行すると実行月のまとめ、引数1つ(YYYY-MM形式)で指定月のまとめを生成します。
生成されるレビューは、案件別の実績(完了タスク、参加MTG・イベント)、目標別のKPT分析(Keep・Problem・Tryの3つの観点)、定量的な実績(完了率、記録日数など)で構成されます。
定量的な実績では、総タスク数(すべてのユニークなタスク)、完了タスク数([x]マークがついたタスク)、完了率(完了タスク数 ÷ 総タスク数 × 100)、MTG・イベント参加数(「定例」「MTG」「会議」「1on1」「○○会」を含むイベント)、デイリーノート記録日数を自動計算します。
CSS Snippetsでタスクステータスを視覚化
.obsidian/snippets/custom-task-status.css
/* カスタムタスクステータス - 色分け */
/* Reading View & Live Preview 両対応 */
/* [/] 進行中 - オレンジ */
input[type="checkbox"][data-task="/"],
ul > li[data-task="/"] > input,
ul > li[data-task="/"] > p > input,
.HyperMD-task-line[data-task="/"] > .task-list-marker::before,
.markdown-preview-view ul > li[data-task="/"].task-list-item.is-checked::before {
border-color: #ff9800 !important;
background-color: #ff9800 !important;
}
/* [R] レビュー中 - 青 */
input[type="checkbox"][data-task="R"],
ul > li[data-task="R"] > input,
ul > li[data-task="R"] > p > input,
.HyperMD-task-line[data-task="R"] > .task-list-marker::before,
.markdown-preview-view ul > li[data-task="R"].task-list-item.is-checked::before {
border-color: #2196f3 !important;
background-color: #2196f3 !important;
}
/* [x] 完了 - 緑 */
input[type="checkbox"][data-task="x"],
ul > li[data-task="x"] > input,
ul > li[data-task="x"] > p > input,
.HyperMD-task-line[data-task="x"] > .task-list-marker::before,
.markdown-preview-view ul > li[data-task="x"].task-list-item.is-checked::before {
border-color: #10a915 !important;
background-color: #4caf50 !important;
}
タスクステータスの視覚化では、[ ] 未着手を白、[/] 進行中をオレンジ色、[R] レビュー中を青色、[x] 完了を緑色で色分けして表示します。
従来はObsidianでどのタスクも同じチェックボックスで表示されていましたが、CSS Snippetsで色分けすることで視覚的に状態が分かりやすくなりました。以下の画像のように、Daily Noteを開いた瞬間に進捗状況が把握でき、色分けによって未着手/進行中/レビュー中/完了が一目瞭然になります。

上記のCSSファイルを実装し、ObsidianのSettings → Appearance → CSS snippetsでcustom-task-statusを有効化してスニペットをリロードするだけです。既存のDaily Noteに即座に反映されます。
試してみた
daily-evening
試しに、sampleのDaily Noteを準備した状態でdaily-eveningを実行します。
2025-12-26.md
---
tags:
- Aプロジェクト
- Bプロジェクト
- Cプロジェクト
---
# Daily 2025-12-26
## タスクステータス
| ステータス | 記法 | 色 | 説明 |
| ---------- | ----- | ------------- | -------------------------- |
| 未着手 | `[ ]` | 無色 | まだ開始していないタスク |
| 進行中 | `[/]` | オレンジ(⏵) | 現在作業中のタスク |
| レビュー中 | `[R]` | 青(R) | レビュー・承認待ちのタスク |
| 完了 | `[x]` | 緑(✓) | 完全に完了したタスク |
中止したタスクは打ち消し線(~~タスク名~~)で表現します。
## MTG・イベント
- [ ] 10:00-11:00 週次定例会議
- [ ] 14:00-15:00 お客様との打ち合わせ
- [ ] 16:30-17:00 チーム振り返り会
## 今日のTodo
- Aプロジェクト
- [ ] API実装を進める
- [ ] テストコードを追加する
- [ ] 設計レビューの準備
- Bプロジェクト
- [ ] お客様定例の資料作成
- [ ] 障害対応の調査
- Cプロジェクト
- [ ] 週次報告書の作成
- [ ] 次Sprint計画の確認
- ブログ
- [ ] Obsidian記事の執筆
- その他
- [ ] 経費精算の提出
- [ ] 年末休暇の調整
## 今日の振り返り
### 技術力の向上
-
### プロジェクト管理能力の強化
-
### コミュニケーション能力の向上
-
## 明日やる
- Aプロジェクト
- [ ] 未定
- Bプロジェクト
- [ ] 未定
- Cプロジェクト
- [ ] 未定
- ブログ
- [ ] 未定
- その他
- [ ] 未定
実行するとAプロジェクトのタスク1について選択形式で尋ねられます。Tabを移動するとタスク2、3、追加タスクと聞かれるので、ステータスをEnterで選択して次に進みます。振り返りだけは音声や手動で入力する自由形式にしました。


完成したmdをObsidianからみたら、以下のようになります。最初のうちは色とステータスを頭の中で一致させるのに慣れが必要そうですが、見やすさはこっちの方が良いですね。

monthly-review
先ほど作ったmdファイルのみを対象に実行しました。
さすがに1ファイルの集計なので、あまり意味がないですが、毎日の積み重ねで良いまとめができそうです。


最後に
もっとベターな方法を思いつかない限りは、この方法を運用しようと思っています。大幅なUpdateがありましたらその時は報告しようと思います。どなたかの参考になれば幸いです。







