週次レビューを読んだあとにつなげる:自動化・アクション・ブログの3つの出口

作業OS

週次レビューを「次につながる」振り返りに

これまでの記事では、週次レビューに向けた流れを2段階で書いてきました。

  1. 4種類のログをObsidianに溜める — 振り返りの素材を、決まった置き場所に集める
  2. 週1回、その素材から週次レビューを自動生成する — 要約・進捗把握・自動化の提案まで、1つのMarkdownにまとめる

ここまでで、週次レビューのための素材の確保と、振り返り用の週次レビュー作成が自動的に行われる状態になりました。このおかげで、毎週レビューを確認するのが非常にしやすくなり、習慣化しました。

ただ、週次レビューを読んでも「なるほど」で終わり、翌週以降の改善につながらないのでは意味がありません。目的は振り返ることだけでなく、改善や仕組み化、今後の行動の入口にすることです。

つまり私がしたいのは、週次レビューを「作って満足」で終わらせず、読んだあとに次につながる振り返りに変えることです。私は、Obsidianに週次レビューを残し、Cursor 向けに自分で作成したフォローアップ用 Skill(エージェントへの指示書)で読み返しながら、自動化の実装・今後のアクション提案・ブログ下書きの作成を行なっています。

本稿は、出来上がった週次レビューを読んだあとの運用(何を実装し、何を翌週やり、何を発信のネタにするか)について紹介します。素材の集め方や自動生成の仕組みは、上記2本を先に読んでください。

要点まとめ
  • 前2本で「読める週次レビュー」はできた。本稿は読んだあとの話
  • 読んだ後は、Cursor 向けに自作したフォローアップ用 Skill に任せる
    • 自動化の実装 — 繰り返しを段階的にルール化・Skill 化・スクリプト化へ
    • 今後のアクション提案 — 締切と進捗から翌週の優先を決め、1〜2週先の見通しも整理する
    • ブログ下書きの作成 — 自動化の実装で一般化した運用を、記事の下書きにする

読んだあとに何をするか

私の運用では、金曜に週次レビューが自動生成されたあと、週末か月曜の朝に1ファイルを読み、Cursor でフォローアップ用 Skill を走らせます。やりたいことは大きく3つに分かれます(abstract の3出口と同じです)。

  • 定型作業の自動化 — 繰り返しを rules / Skills・スクリプトに落とす
  • 翌週のプラン — 来週いちばん先に手を付けることを決める
  • ブログの下書き — 一般化した運用を PGP の記事ネタにする

いずれも「次の成果に繋げる」作業です。この振り分けは、Skill の指示に任せています。

フォローアップ用 Skill の入出力

再現の手がかりとして、私が Skill に書いている入出力の骨子を示します。

入力

  • その週の週次レビュー(Markdown 1ファイル。指定されたフォルダにあるため、Cursor が自分で参照してくれる)
  • 参照させるファイルの種類(Skill 内で列挙)
    • 週次レビュー内の全体サマリーと作業の進捗
    • 各プロジェクトのメモ(締切、フェーズ、完了したかどうか)
    • 毎朝1枚にまとめた優先リスト(緊急の返信・期限が近い提出物・様子見の案件。私は DailyDashboard という Markdown として毎朝自動生成しています)

出力

  • 週次レビューの冒頭## フォローアップ 節を追記(または更新)
  • 中身は次の4ブロック
    • 翌週の優先(3〜5件)
    • 今週の進捗の先(中期的な次の一手)
    • 翌々週以降・検討候補
    • 自動化の実装メモ、Skill / Rule 提案
    • ブログ下書きへのリンク

以下は、実際の追記を匿名化した例です。

## フォローアップ

作成: 2026-07-26
対象: 当週の週次レビュー(7/17〜7/24)

### Skill / Rule 提案(実装済み)

- **対象**: 毎朝の優先リストに、プロジェクトのフェーズと残日数を表示する rule
- **内容**: Overview の YAML にフェーズ用キーを定義し、締切30日以内を urgent に振り分ける

### 翌週の優先

1. **プロジェクトA — 残タスクの仕上げ** — 根拠: 週次で中間成果まで進行。期限まで2週。今週は最終チェックと提出物の生成
2. **プロジェクトB — 依頼への返信** — 根拠: 毎朝の優先リストで要対応。相手の担当者確認を先に片付ける
3. **プロジェクトC — 原稿の骨子** — 根拠: 依頼整備済み。締切は先だが、今週中に見出しと図のたたき台まで

### 今週の進捗の先(中期的な次の一手)

- **プロジェクトA 提出後**: プロジェクトD の資料整理に移る(週次で次ステップ整理済み)
- **プロジェクトE**: 校閲待ちの間はパッケージ維持のみ。結果待ちのあと切替用

### 翌々週以降・検討候補

- **プロジェクトF** — 締切は先だが、来週は手を付けない(今週 urgent 外)
- **イベント準備** — 1か月以内の講演が入る見込み。来週から開催前点検 Skill を回す

### 作成したブログ(公開前)

- PGP: 週次レビューの読了後運用(本稿の下書き)

この例のように、読んだあとの判断が1か所に残るのが、フォローアップの第一の成果です。

1. 自動化の実装

週次レビューの「自動化の提案」には、一週間で繰り返し行われた定型作業を抽出し、それをどう自動化するかという提案が上がってくるようになっています。ここで要約しているのはローカルLLM(前回記事の週次レビュー生成と同じ系統)で、実際の実装は Cursor で行っています。

普段の作業でAIエージェントを使うときは、ほとんど Cursor を使っています。そのため、ローカルLLMによる提案をそのまま全部入れると、普段の作業フローとずれて不具合が出ることがあります。

そこで、フォローアップ用 Skill に、Cursor での作業の仕方を踏まえた実装すべきかの判断と実装を任せています。rules / Skills レベルに落とし込むべきなのか、Python 等でスクリプト化できるくらい固定化できるものなのかの判断もここで行います。

以前は自分で「この作業、繰り返しているな」と気づき、その作業が「どんなタイミングで発生し、どんな手順で実行され、それが最終的にどこにどんな成果物として出力されるか」を一般化し、AI エージェント用の rules / Skills にするか、または Python 等でスクリプト化するかを判断して、バイブコーディングしていました。

一方で、週次レビュー生成とフォローアップ用 Skill の体制を構築してからは、特に意識せずに繰り返し作業が抽出され、自動化実装までを AI が進めてくれるようになりました。手動で気づきから実装まで追うより、週あたりの工数はかなり減っています。

2. 今後のアクション提案

週次レビューだけ読んでも、「来週何をするか」は自動では決まりません。締切や依存関係は、週次レビューの要約と、各プロジェクトの現在の状態を突き合わせる必要があります。

フォローアップ用 Skill では、先の「入出力」に書いたとおり、週次レビュー・プロジェクトメモ・毎朝の優先リスト(DailyDashboard)を参照するよう指示しています。

この結果として、翌週いちばん先に手を付けることを3〜5件に整理します。それ以外の用事も、日々の DailyDashboard でフォローされる状況になっていますが、締切が近い提出物、返信待ちの依頼、途中のまま止まっている作業の次の1ステップ——週の冒頭で迷わない短いリストを作るのが、まず最初の出口です。

ここで出すのは、翌週いちばん先に手を付けるリストだけではありません。あわせて次の2段も整理します。

今週の進捗の先(中期的な次の一手) — 今週手を付けたプロジェクトについて、いまどこまで進んだかと、完了に近づいたあとに進めるべき次の案件・次のプロジェクトを1〜3件ほど並べます。1件を仕上げたら次に何を動かすかが見えている状態が理想です。

翌々週以降・検討候補 — 今週は手を付けていなかったが、締切が近いものや、先のイベントに備えて早めに見ておくべき案件を、翌週に時間を割くか、あえて見送るかを書き分けます。新しくプロジェクトを始める提案は、計画メモや依頼の締切など根拠があるときだけ載せ、根拠が薄いものは「検討候補」に留めます。

3. ブログ下書きの作成

ブログのネタは、1週間の作業をなんとなく振り返って出てくるものではありません。私の場合、出口1の自動化の実装の過程でネタが生まれます。

フォローアップでは、定型作業の抽出から rules / Skills・スクリプト化までを AI に任せています。このとき必ず通る作業が、「繰り返しを一般化して、いつ発生し・どんな手順で・何が出力されるかを言語化する」ことです。PGP で書いているのもまさにこの種の話です。つまり自動化の実装と、ブログの下書きは同じ土台に立っています。

Skill では、週次レビューに上がった自動化提案や、実際に入れた rules / Skills ・スクリプトについて、「読者が再現できる運用として書けるか」を見ます。

  • 繰り返し作業をどう一般化したか
  • rules / Skill かスクリプトかの判断理由
  • うまくいかなかった点と直し方

こういった要素は、自動化の実装メモそのものです。そのまま記事の骨子になります。自動化を1本実装した週に、同じ一般化が記事として成立するなら下書きを1本置く——くらいの温度感で、ブログ投稿のネタを抽出し、下書きまで自動生成させます。

この下書きはその後かなり編集しますが、少なくともネタと下書きまで自動でできるだけで、きっかけ作りとしては十分です。

1本の週次レビューから実際に進める

まとめると、毎週、次の流れで翌週に繋げています。

  1. 週次レビューを読む — 1ファイルを読み、気になった繰り返しと来週の論点をメモする
  2. フォローアップ用 Skill を実行する — 週次レビューを渡し、3つの出口のたたき台を出す
  3. 追記を確認する — 週次レビュー冒頭に、自動化提案・翌週優先・中期的な見通し・検討候補・ブログ下書きリンクが入っているか見る
  4. 必要ならその場で実装 — 提案された自動化を入れるときは、続けて Cursor に実装を依頼する
  5. 週次レビューを閉じる — フォローアップが終わったら確認済みにし、次の週に持ち越さない

「読んだだけ」で終わらせず、このようにフォローアップすることで、より良い作業環境次の作業の具体化ブログ記事の骨子という成果物を、ほぼ自動で作成するループが出来上がるわけです。

次に読む(関連記事)

免責

本記事は、筆者の作業環境に基づく一般的な情報です。個人情報保護や所属組織・取引先の規程に従って運用してください。週次レビューやフォローアップの出力には、自分用のプロジェクト名や依頼内容が含まれるため、記事化するときは匿名化・一般化してください。AIや自動化ツールの出力は下書きであり、最終判断・最終責任は利用者にあります。

コメント

タイトルとURLをコピーしました