2026.09.20働き方

引き継ぎメモの書き方｜後任は、次のセッションの自分だった

金曜の夜に考えていたことを、月曜の朝にはもう覚えていなかった。
困っていたのは記憶力ではなく、書き残し方だった。
三つに分けてから、月曜の自分がようやく迷わなくなった。

金曜の夜、この技術ブログを毎日書かせている仕組みの一部を直していた。
なぜその設計にしたのか、そのときは頭の中に理由があった。
月曜の朝に続きをやろうとしたら、その理由がもう出てこなかった。

正確には、僕が忘れたわけじゃない。
毎日の記事はAIエージェントに任せていて、週末をまたぐとそのエージェントのセッションもリセットされる。
金曜の判断を月曜の別のセッションに引き継ぐには、どこかに書いておくしかなかった。

最初は、ひとつのメモに全部書いていた

「このサイト専用のメモ」を一つ作って、思いついたことを片っ端から足していった。
DBのテーブル名、投稿のルール、過去に踏んだ落とし穴、今日やること。
ジャンルを分けずに、時系列でただ積んでいった。

三週間もすると、そのメモは読み切れない量になっていた。
新しい作業を始めるたびに最初に読むのがこのメモなので、長くなるほど読み込みに時間がかかる。
もっと困ったのは、古い情報と新しい情報が同じ重みで並んでいたことだった。
「本番の設定はこれ」という一生変わらない話と、「今日はこの記事まで書いた」という今日限りの話が、同じ行の並びに入っていた。

どれも「メモ」だけど、寿命がまったく違った

読み返して分けてみると、書いていた内容は三種類あった。

ひとつめは、いつまでも変わらないルール。
「投稿の本文に生の改行を入れない」「本番へ反映する前に必ずローカルで検証する」のような、この先ずっと守るべき決めごとだった。

ふたつめは、このサイトだけの事実。
「技術ブログはカテゴリを七つ順番に回している」「本番とローカルで採番がずれることがある」のような、他の案件には持っていけないけれど、このサイトではずっと正しい情報だった。

みっつめは、今この瞬間の作業の状態。
「今日はここまで書いた」「次はこの分岐を試すつもりだった」のような、数日で役目を終える情報だった。

これを同じ場所に同じ扱いで書いていたのが、そもそもの失敗だったと思う。
みっつめの「今の状態」は放っておくと古くなって嘘になるのに、ひとつめの「ずっと変わらないルール」と並んでいると、どちらも同じくらい信用できる情報に見えてしまう。

三つの引き出しに分けた

今は、書く場所を三つに分けている。

ルールは、作業のたびに必ず読み込まれる場所に置く。
量が増えすぎないよう、本文はできるだけ書かず「詳しくはこのメモを見る」という参照だけを残すようにした。

このサイト固有の事実は、案件ごとのメモに置く。
DBの構成、過去に決めた方針、踏んだ落とし穴。
時間が経っても変わらない前提なので、消さずに育てていくメモになる。

今の作業の状態だけは、別の場所に書く。
作業がひと区切りついたときに、判断の理由と残っている課題を書き残す。
このメモは、次のセッションが読んだら役目を終える前提で書く。
触ったファイルの一覧だけを書いても意味がなくて、「なぜその設計にしたか」「どこでつまずいたか」まで書かないと、次の自分は同じ場所でまた迷うことになる。

自動で残る要約だけに頼って、一度足を止めた

実は、三つに分ける前は「自動で残る要約」だけに頼っていた時期があった。
セッションが長くなると、それまでのやり取りが自動的に一つのファイルへ圧縮されて保存される仕組みがある。
便利だったので、それだけで十分だと思い込んでいた。

ところがある日、続きの作業を始めてすぐに、前回すでに検討して見送った設計をもう一度提案してしまったことがあった。
自動の要約には「どのファイルを触ったか」は残っていたのに、「なぜその案を見送ったか」までは残っていなかった。
見送った理由を書かずに次のセッションへ渡すと、次は同じ案をもう一度検討することになる。
自動の要約はあくまで補助で、正本は自分の手で書く引き継ぎメモのほうだと決めてから、この足止めはなくなった。

これはAIに限った話ではないと思う

ここまで書いてきたのは、AIエージェントに仕事を任せている僕の運用の話だった。
ただ、分け方そのものは、人間同士の引き継ぎにもそのまま使えると思う。

「これはずっと変わらないルールか」「この現場だけの事実か」「今日で役目を終える話か」。
メモを書く前にこの三つのどれかを自分に聞くだけで、後から読み返す人が、どこまで信じていい情報なのかを迷わなくなる。
引き継ぎ書が読みにくいのは、たいてい文章の書き方のせいじゃなくて、寿命の違う情報が同じ棚に並んでいるせいだと、今は思っている。