はじめに
「毎朝PCを開いて、今日やるべきことを確認するまでに10分かかる」
これ、地味にストレスじゃないですか？
カレンダーを開いて、Slackを確認して、昨日のログを開いて…という時点で、もう集中力のゴールデンタイムを食っている。
今回は、AIエージェント（AntiGravity）のスキル機能を使って、「毎朝の5分ブリーフィング」を自動化した話です。設計の狙い、YAMLベースのタスク判定ロジック、テスト実行で得た知見などを詳しく書きます。
解決したい課題
Obsidianにデイリーログを半年以上毎日つけています。量は十分。
ところが、「昨日何をして、何が残っているか」を毎朝手動で確認するのは5日分×3ファイル/日 ≒ 15ファイルを遡る作業になり、現実的じゃない。
結果、「たぶんこれだったよな…」という記憶頼りの優先順位づけになりがちでした。
スキルの概要
入力
-
daily_log/フォルダから直近5日分のMarkdownファイルを自動取得
出力
-
未完了タスク一覧
→ YAML frontmatterのstatusがIn Progressのログを抽出 -
今日公開予定記事のX投稿テンプレート
→archives/note_posts/,archives/qiita_posts/の日付と照合
実行方法
AntiGravityのチャットに「今日のブリーフィングお願い」と一言投げるだけです。
設計のポイント
1. ログ読み込み範囲は「5日」
テスト実行を繰り返して決めた値です。
| 範囲 | メリット | デメリット |
|---|---|---|
| 3日 | 軽い | 週をまたぐと文脈が途切れる |
| 5日 | ちょうどいい | **── ** |
| 7日 | 網羅的 | トークン消費が増える |
5日だと、月曜朝に実行しても水曜くらいまでのコンテキストが残るので、週末に仕掛かりにしたタスクも拾えます。
2. 未完了判定はYAML status フィールドベース
デイリーログのYAML frontmatterには、必ず status フィールドがあります。
---
task_id: 2026-02-12-001
date: 2026-02-12
status: In Progress
---
スキルはこの status 値を見て判定します。
-
In Progress→ 未完了タスクとして一覧に含める -
Complete→ 一覧に含めない
テキスト本文中の「TODO」「やり残し」等の自然言語表現を解析するのではなく、構造化されたメタデータで判定する方針です。
理由：自然言語ベースだと「これはTODOなのか感想なのか」の判定が曖昧になるため。YAMLなら機械的に確実。
3. X投稿の忘れ防止機能
create_articles スキルで記事を事前生成すると、公開日にX（Twitter）で告知するのを忘れがちです。
daily_briefing では、archives/note_posts/ と archives/qiita_posts/ の中から今日の日付と一致するファイルを探し、見つかったら
📢 今日公開予定の記事があります：
- note: 【開発ログ】○○○
- Qiita: なし
→ X投稿テンプレート：
「今日の記事を公開しました！○○○についてまとめています #Python #自動化」
のようなテンプレートを出力します。
4. 出力はMarkdownファイルとして保存
ブリーフィング結果はターミナル表示だけでなく、daily_log/ に YYYY-MM-DD-briefing.md として保存します。
daily_log/
├── 2026-02-13-001.md ← 通常のログ
├── 2026-02-13-002.md ← 通常のログ
└── 2026-02-13-briefing.md ← ブリーフィング結果
Obsidian上で通常ログとブリーフィングがリンクでつながり、「なぜこのタスクを今日やったのか」の文脈が追えるようになります。
テスト実行の結果
結果1：気づけなかったタスクの発見
テスト実行で、独自ドメインのCloudflare追加設定が「未完了」として拾われました。
自分では「完了した」と思い込んでいたタスクでしたが、YAML上は In Progress のまま。結果的に、転送設定の追加が必要だったことに気づけました。
→ YAMLベースの判定が「思い込み」を防いでくれた実例。
結果2：Codexでも動作確認
AntiGravityだけでなく、Codex（GitHub上のAIエージェント）でも同じスキル定義を実行できることを確認しました。
ただし、Codexはサンドボックスでの実行のため、リポジトリパスの明示指定が必要です。
# AntiGravity（ローカル実行）
daily_log/ → そのまま相対パスで読める
# Codex（サンドボックス実行）
/workspace/obsidian-vault/daily_log/ → 絶対パスで指定
結果3：無料モデルでの実用性
5日分のログは入力トークンとしてはコンパクトで、無料モデルでも十分実用できそうな手応えを得ました。
これは、将来的にPC環境構築代行サービス（松プラン）のユーザーにも「課金なしで使えるスキル」として提供できる可能性を意味します。
create_articles との棲み分け
同じ「ログを読んで何かを出力するスキル」ですが、用途が全く違います。
| daily_briefing | create_articles | |
|---|---|---|
| 目的 | 今日のタスク確認 | 1週間分の記事生成 |
| 実行頻度 | 毎朝 | 週1回 |
| 入力量 | 5日分（軽い） | 7日分（重い） |
| 出力 | タスク一覧 + X投稿テンプレ | note/Qiita/Discord記事群 |
| モデル要件 | 無料枠OK見込み | 分割実行推奨 |
SKILL.md の構造（抜粋）
実際のスキル定義ファイルは以下のような構造です。
# スキル定義：daily_briefing
## 入力
- daily_log/ から直近5日分のファイルを読み込む
## 処理
1. 各ログのYAML frontmatterから status を抽出
2. status: In Progress のログを未完了タスクとして一覧化
3. archives/note_posts/ と archives/qiita_posts/ から今日の日付のファイルを検索
4. 見つかった場合、X投稿テンプレートを生成
## 出力
- daily_log/YYYY-MM-DD-briefing.md として保存
まとめ
-
YAML frontmatterの
statusフィールドを活用した機械的なタスク判定で、自然言語解析の曖昧さを回避 - 5日間という読み込み範囲が、トークン消費と文脈保持のバランスポイント
- X投稿の忘れ防止機能で、記事公開日の「うっかり」をシステム的に防止
- 入力が軽いため、無料モデルでの運用も現実的
-
create_articles（出力）とdaily_briefing（入力確認）の2軸スキル体制が完成