ログが大量で、振り返りに困る
前回の記事では、日々の活動を振り返り、改善につなげるための ログ収集 について紹介しました（ログを振り返り、改善する：週次レビューのための素材の作り方 ）。
ただ、ログは集めただけでは意味がなく、振り返りで改善点を見つけ、必要なものをいつでも参照できるようにしておく、ということをしなければ意味がありません。一方で、振り返りの対象となるログは膨大になりがち、読むだけで時間が溶けていきます。結果として振り返りは続きません。
今回は私が実際に構築している、 継続できる週次レビュー について紹介します。私は、集めた4種のログを週1回、1つのMarkdownに自動でまとめ、以下の情報を要約してくれる仕組みを作っています。
- 外部情報（RSSやWebクリップなど）の要約
- 自分の思考ログ（ボイスメモ要約やデイリーノートなど）の要約
- 作業進捗の把握
- 一週間の作業を踏まえた自動化の提案
今回は前回のレビュー素材集めの話題に引き続き、このようなレビューを 自動生成してくれるプログラム（何を拾い、どう分け、どこへ出し、いつ動かすか）をバイブコーディングした事例を紹介します。
ログの確認：直近7日間の更新を見る
週次レビュー作成プログラムでは、Obsidian の Vault 内のファイルのうち、直近7日間に更新された Markdown ファイルだけを確認します。画像、PDF、Word、PowerPointまで全部対象にすると重くなりすぎるので、Markdown に限定していますが、これはそもそも私がほとんどの作業を Markdown で行っているからできることになります。これはそもそも AI エージェントを積極的に活用するための仕様でもあります。
実際、現在私は原稿執筆、講演スライド、バイブコーディング時の要件定義書、ブログ記事など、ほとんどの資料を Markdown ファイルで作成しています。人と共有したり、どこかに提出する際は、この原本 Markdown ファイルを Word, PowerPoint, PDF などの提供用ファイルに変換して渡しています。この変換も、基本的にスクリプトで自動化しているので、「原本の Markdown」と「提供物」という2種類のファイルができることになります。これ、面倒そうに見えますが、案外そうでもなく、何らかの理由で提出物の様式変更があった場合も、原本 Markdown から気軽に変換できるので、むしろ楽になったと感じています。
素材の置き場は、外部情報やボイスメモ要約、Daily Noteの収集用のフォルダ（いわゆる Inbox フォルダ）と、講演などのプロジェクトフォルダに分かれています。
処理：セクションごとに小分けにする
収集したレビュー素材はローカルLLMに渡して要約・整形しています。毎週レビューのために多くのトークンを消費するため、無料でできるように、という経済的な理由と、外のサーバーに送りたくない情報が含まれる可能性を考慮して、ローカルLLMで実装しています。実際に現在、Google の Gemma 4 e4b を用いてレビュー作成をしていますが、レビュー内容の質にはそれなりに満足しています。
ただレビュー作成の際、対象となる情報は多くなりがちです。全部を1回でローカルLLMに渡すと、だいたい次の二種類の問題が生じます。
ひとつは量です。一度に処理するトークンが多くなりすぎて、ローカルLLMでは処理しきれなくなりがちです。そうなると肝心の要約が生成されません。もうひとつは話題の多様性です。外部情報もボイスメモもプロジェクトも一緒に処理すると、それぞれの話題が混ざり、要約の内容がおかしくなることがあります。
まとめて渡した結果、このような問題が発生したとき、どこでうまくいかなかったかの切り分けができなくなります。そうなると、どこで止まったかが分からず、また最初から全部やり直すことになりがちです。
そのため私は、セクションごとに小分けしてローカルLLMに情報を渡し、処理してもらっています。1回あたりのトークンを抑えるのでローカルLLMでも対処でき、話題ごとに結果を分けられ、失敗箇所の特定や該当区間だけのやり直しもしやすくなります。
実際にローカルLLMに以下のものを小分けに渡して要約してもらいます。
- 外部情報（RSSなど）を1件ずつ
- ボイスメモの要約を1件ずつ
- デイリーノートを1件ずつ
- 原稿執筆や講演などの各プロジェクト
これらの要約が出揃った段階で、改めてそれらの情報をローカルLLMに投げ、最終的なサマリーと、プロジェクト進捗においてプログラムやAIで自動化すると便利そうな案を作ってもらいます。
全体サマリーで出力させること
小分けの要約が終わったら、それを元に最終的なサマリーを出力してもらいます。このサマリーでは、大きく2つのことを出力してもらうよう指示しています。
- 全体サマリー：収集された情報や更新履歴に基づき、この一週間の活動の200字程度での要約
- 自動化の提案：作業の種類ごと（私の場合は原稿執筆や講演の準備など）で、どのような定型作業が生じ、どのような自動化が有効かの提案
この2つを週次サマリーの冒頭に作成することで、翌週以降につながる情報の全体像を確認し、その中で特に振り返りたいものがあれば、その後に続く個別要約、さらにそこからリンクされた各情報を辿れるようにしています。
出力先：日付つきの週次レビューに保存する
出力先は1つに固定します。私は、週次レビュー用フォルダ Weekly 内に、YYYYMMDD.md のように日付つきのMarkdownとして保存しています。Obsidianで読み返せますし、あとからAIエージェント（私の場合はCursor）でフォローアップする際に、このフォルダから自動的に参照してもらえるように指定しています。
「どこに出すか」が決まっていると、自動化も人間の確認も続きやすくなります。
いつ動かすか：決まった曜日に自動実行する
週次レビューは、決まった曜日に自動生成されるようにしています。macOSでは、LaunchAgent（決まった時刻にプログラムを起動する仕組み）で、毎週決まった時間にPythonスクリプトを動かせます。私は金曜日の13時に生成するよう指定しています。その日にMacが起動していなかった場合も、次に起動したときに作るようにしておくことで、生成抜けがないようにしています。
その前提として、平日はレビュー用にわざわざ集め直すのではなく、RSSやクリップ、デイリーノート、プロジェクトの更新が決まった場所に自然と貯まる運用にしています。金曜に自動生成し、週末に読む流れは次のとおりです。
注意点：読んで活かすのが本体
自動生成が担当するのは、ログを要約して1ファイルに揃えるところまでです。
出てきた週次レビューを見て、重要情報を振り返り、思考を整理し、次の作業効率化を検討するのは人の側です。生成そのものより、読んだあとの使い方が本体です。
実際にこの運用を始めてから、毎週必ず収集した情報や自分の活動を振り返るようになりました。また、自動化の提案も非常に良く、毎週自分の作業を効率化する新しいエージェント用の Skill を実装していて、どんどん作業効率が上がっていると感じます。
ここで、私がこの振り返りを続けていることができているのは、
- レビューに必要な情報収集を「意識する必要がない」状況を構築したこと
- 自然と貯まった情報から、自動的にレビューが作成される状況を構築したこと
- 作成されるレビューが適度に読みやすい長さ・内容であること
が揃っているおかげです。こういう手間を、仕組みやプログラム、AIで自動化することが大事ですね。
次に読む（関連記事）
免責
本記事は、筆者の作業環境に基づく一般的な情報です。個人情報保護や所属組織・取引先の規程に従って運用してください。ローカルLLMを使う場合でも、入力内容・保存先・ログの扱いには注意が必要です。AIや自動化ツールの出力は参考情報であり、最終判断・最終責任は利用者にあります。
コメント