Claude Codeに継続的な仕事を任せるなら、作業を再開するときに読む申し送りを決めておく。今回、ブログの運営記録にある確認期日、未マージの変更提案、残っている作業場所を、1回の実行で一覧にする仕組みを使った。
集めるところまでは任せられた。ただし、一覧に載ったものを「未処理」「削除してよい」と決める仕事は残った。申し送りの役割は、確認の入口をまとめることだ。
「1人法人1000馬力化計画」は、AIや仕組みに仕事を任せ、1人のまま事業を回せる範囲を広げる連載。初回は、社員を何人増やしたかよりも、作業再開時の何を任せ、何を自分に残したかを記録する。
再開のたびに確認するものが、3か所に分かれていた
ブログでは、記事を書いた後に反響を見る日を決めている。確認期日はMarkdownの運営記録にあり、原稿や仕組みの変更提案はGitHubのPRにある。並行作業には、作業ディレクトリを分けるgit worktreeを使っている。
この3つは、確認する場所も意味も違う。
| 確認するもの | 置き場所 | 確かめたいこと |
|---|---|---|
| 記事施策の確認期日 | 運営記録のMarkdown | どの記事を、いつ振り返る予定だったか |
| 未マージPR | GitHub | どの変更がまだ取り込まれていないか |
| 残ったworktree | ローカルのGit | どの作業場所が残り、片付け候補になりそうか |
従来の手順書にも、作業開始時に期日を確認する指示はあった。ただ、記録を読む、PRを見る、worktreeを照合する、という収集はセッションごとの作業だった。そこで、この収集部分を1つのコマンドにまとめた。
秘書の担当は「集めて並べる」まで
連載の台帳では、この担当を秘書・帳前 秘（とばりまえ ひめ）として登録している。本体はdaily-briefing.tsというTypeScriptのスクリプトだ。
「AI社員」という企画の中にいるが、この処理自体はLLMを呼ばない。日付とGitの状態を決めた規則で整理する。名前から自由な判断や会話を想像すると、実装との間にずれが生まれる。
期日は、運営記録に書かれた「判定予定日」「次回確認予定日」「効果判定予定日」を拾い、次のように分類する。
- 当日を含めて過ぎた日付は「期日が来ている判定」へ。
- 翌日から3日以内の日付は「まもなく来る判定」へ。
- 同じ日付と同じ見出しの組み合わせは、重複表示をまとめる。
現在は、運営記録の「YYYY-MM-DDの判定」という見出しから最新の判定日を読み、その日以前の期日を表示対象から外している。これは日付による除外であり、個々の仕事が本当に完了したかを調べる処理ではない。
日付の境界は日本時間に合わせている。午前中に実行したとき、UTCの日付のままだと前日として扱う時間帯があるためだ。
PRはGitHub CLIで取得し、worktreeはGitが持つ一覧とマージ済みPRのブランチ名を照合する。新しい管理表を作って転記するのではなく、それぞれの元の記録を読む形にした。
初回実行では、過去の期日も一覧に現れた
2026年9月14日に、原稿用の作業ディレクトリで実行した。使った環境はNode.js 22.12.0とGitHub CLI 2.89.0。これは同日に入った、判定済みの期日を除外する修正より前の記録だ。記事の事実確認のため、その時点の実装と出力を照合している。
この回の出力には、次の項目があった。
| 出力の区分 | 表示された内容 |
|---|---|
| 期日が来ている判定 | 9月13日を期日とする記録が7件 |
| まもなく来る判定 | 9月17日を期日とする記録が3件 |
| マージ済みなのに残っているworktree | 7件 |
これは実行時点の表示件数であり、未処理作業や不要なディレクトリの確定件数ではない。
この時点の処理は運営記録から日付を抽出するだけで、後の判定記録を読んでいなかった。表示された7件をそのまま「7件の確認漏れ」と数えることはできなかった。その後、最新の判定日以前を除外する修正が入り、この7件は表示対象から外れた。
ただし、判定日以前の仕事を一括で処理済みと扱う規則には限界もある。未完了の仕事が残っていれば、一覧から消えてしまう。個別の完了確認を任せられるようになったわけではなく、元の記録との照合は引き続き必要だ。
worktreeも同じだ。マージ済みPRのブランチ名が見つかっただけでは、その後に新しい変更を積んでいないか、未コミットの作業がないかは分からない。候補が出たら、対象の作業状況を確認する必要がある。
この実行では、ファイルの削除、PRのマージ、記事の公開はしていない。一覧を得る操作と、一覧を見て何かを変更する操作を分けている。
Claude Codeに渡す開始手順を固定する
私のリポジトリでは、ブログ用のCLAUDE.mdに作業開始時のコマンドを置いている。Claude Codeの公式ドキュメントでも、CLAUDE.mdはプロジェクトの指示を持たせる仕組みとして説明されている。ここには、毎回変わる作業一覧を貼るのではなく、最新の状態を確認する入口を書く。
実際の実行コマンドは次の1行だ。リポジトリのルート相当のディレクトリから実行する。
node --experimental-strip-types scripts/lib/daily-briefing.tsこのコマンドは私のリポジトリ内のファイルとGitHubの状態を読むものなので、別のプロジェクトへそのまま貼っても使えない。Node.jsとGitHub CLIが利用でき、対象リポジトリを読む権限があることが前提になる。
同じ考え方を取り入れるなら、まず次の3点を自分の業務に合わせて決める。
- 入力：期日はどの記録から、変更提案はどのリポジトリから取るか。
- 完成条件：何日前から表示し、どこまでを一覧に出せば十分か。
- 人の仕事：完了確認、優先順位の決定、片付けの承認を誰が行うか。
Claude Codeへ渡す確認指示も、この範囲に絞る。例えば、私の実装を使う場合は次のように依頼できる。
申し送りコマンドを実行し、出力を確認してください。
期日は元の運営記録で、完了済みか・予定が変わったかを確かめてください。
worktreeはブランチと未コミット変更を確認し、削除候補の報告までにしてください。
一覧の取得に失敗した場合は「該当なし」と扱わず、確認できない項目を報告してください。この指示は、スクリプトに追加済みの機能ではなく、出力を受け取った後の確認手順だ。現行のスクリプトには、GitやGitHub CLIの実行失敗を空の結果として扱う箇所がある。また、PRの取得件数にも上限がある。一覧が空でも、全件を確認できたとは限らない。エラー表示や取得元を見直す工程は省けない。
「毎朝、自律的に働く」とはまだ書けない
今回の運用は、作業を始めるときに呼び出す形だ。毎朝自動で起動する設定や、結果を自動送信する仕組みではない。日中に別の作業を始めるときにも、同じ入口を使える。
任せたのは、散らばった情報を集め、一定の規則で並べる工程。何を先にするか、記録が現状を表しているか、外へ出す変更を承認するかは人が握る。これは自分の業務を別の会社へ展開するときにも確認したい境界だ。入力先と日付の規則を差し替えられても、その会社の承認判断まで同じにはできない。
確認時間が何分減ったかは、まだ計測していない。今の時点で言えるのは、3種類の情報を1回の実行で見る入口ができ、元の記録を確かめる場面も見えた、ということまでだ。
1週間後は、一覧の長さより確認の負担を見る
次の1週間は、使った日に「実行結果を受け取ってから、次の作業を決めるまで」を記録する。対象は次の3つに絞る。
- 表示された候補のうち、実際に確認や対応が必要だったもの。
- 完了済み・重複など、見直した結果、対応不要だったもの。
- 元の記録の確認と手直しに使った時間。
利用しなかった日も残す。短い出力でも重要な期日を落としていれば困るし、長い出力でも判断に使えていれば意味がある。導入前の同条件の時間が取れていない間は、削減率に換算しない。
初回の結論は、仕事を任せる入口には、入力と完成条件に加えて「出力を受け取った人が確かめること」も必要だったということ。次回は、この申し送りを使い続けたとき、確認の負担がどう変わったかを確かめる。
