毎日つけているログは、そのままでは読みものにならない。出来事と思考が時系列で並んでいるだけで、文脈も、読み手も、結論も置かれていない。そこから記事を書くには、候補を探して、選んで、書き直すという手間がかかる。この手間を減らすために、ログから記事の下書きを作り、PR を出すところまでを仕組みにした。

公開の判断は手元に残す

自動化する範囲は、候補の抽出から PR の作成まで。マージはしない。PR をレビューして自分でマージしたときだけ、記事が公開される。

ブログの公開経路を PR に一本化したので、CMS は置いていない。記事は Markdown で、コミットと PR がそのまま編集履歴になる。プレビューは PR ごとに発行され、公開前にレイアウトと誤記を確認できる。

流れ

  1. ログの索引から、直近の候補を抜き出す。支出・健康・視聴履歴のような、公開に向かない種類の記録はここで落とす。
  2. 候補の本文を読み、記事として成立するかを判定する。判定するのはエージェントで、根拠にした記録より外のことは書かせない。
  3. 技術・暮らし・雑談のいずれかにカテゴリ分けし、Markdown の記事を書く。
  4. ブランチを切って PR を作る。根拠にした記録は PR の本文にだけ書き、記事には残さない。
  5. プレビューを読んで、必要なら直してマージする。

候補が良いものにならなかった週は、PR を作らずに終わる。記事の本数を目標にしない方が、続けやすいと思っている。

記事の外に出さないもの

ログには、健康・家計・人間関係・居場所のような、公開する前提のない記録が混ざる。記事に書かない条件を決めて、機械で検出できるものは CI で落とす。

  • 健康・体調・服薬
  • 金額・収支・口座
  • 第三者の実名や、特定できる描写
  • 自宅・勤務先・行動パターンが分かる場所や時刻
  • 非公開リポジトリの URL やトークン、記録 ID

機械で判定できない部分は、PR を読むときに確認する。速くするより、出さないことを優先している。

下書きフラグをやめた

最初は「AI の下書きは draft: true にしておき、公開時に本人が false にする」という設計を考えていた。だが PR のプレビューを見るには、下書きもビルド対象にする必要がある。プレビュー用にだけ下書きを含める分岐が増え、マージし忘れると公開されない状態も生まれる。

いまは下書きフラグを持たない。ブランチ上にある記事は未公開、main にある記事は公開。状態はこの二つだけで足りる。