AIと作業していると、その日は順調に進んだのに、翌朝になると「どこから再開すればよいのか分からない」ことがあります。
チャットには長い会話が残っています。ファイルも増えています。それでも、最後に何を確認し、何が未完了で、次に何をすればよいのかが見つかりません。
この状態を防ぐために、私は作業の終わりに短い引き継ぎメモを残します。日報のように一日を詳しく振り返るのではなく、明日の自分や別のAIが、最初の5分で作業を再開するためのメモです。
この記事では、非エンジニアでも続けやすい引き継ぎメモの項目、AIへの依頼方法、書かないほうがよい内容を具体的に紹介します。
チャット履歴だけでは再開地点にならない
AIとのチャットには、質問、提案、修正、失敗、別案が時系列で並びます。その場では流れを理解できても、翌日に最初から読み直すのは大変です。
特に、次のような言葉は後から判断しにくくなります。
「対応しました」
「次は確認します」
「この方向でよさそうです」
「あとで直します」
何を対応したのか。どこを確認するのか。誰が方向を決めたのか。「あとで」はいつなのか。会話の前後を読まないと分かりません。
さらに、AIが「完了」と答えていても、実際の画面や公開URLを人間が確認していない場合があります。会話の最後だけを見て、作業が完了したと思い込むのは危険です。
チャット履歴は検討の過程として残し、再開地点は別の短いメモにまとめます。
引き継ぎメモは5項目で十分
私が最低限残すのは、次の5項目です。
1. 今日の目的
2. 完了したこと
3. 確認できたこと
4. 未完了・保留
5. 次に行う1つの作業
この5つを分ける理由は、「作った」と「確認した」を同じ意味にしないためです。
たとえば、AIが記事原稿を作成しただけなら「完了したこと」には書けます。しかし、Qiitaへ公開し、公開ページでタイトルや本文を確認していなければ、「公開を確認した」とは書きません。
今日の目的：Qiita記事の公開準備
完了したこと：
- Markdown原稿を作成
- タイトルと5個のタグを決定
確認できたこと：
- 原稿が4,000文字以上ある
- タイトルと管理ファイルが一致している
未完了・保留：
- Qiitaへの公開
- 公開ページでの表示確認
次に行う1つの作業：
- 人間が原稿を読み、公開可否を判断する
この形なら、翌日の自分が「原稿はできているが、まだ公開していない」とすぐ判断できます。
「完了」と「確認済み」を分ける
AIとの作業で最も混ざりやすいのが、作業結果と確認結果です。
ファイルを作成した。コードを変更した。入力欄へ本文を入れた。これらは作業結果です。一方で、テストが通った。公開URLで表示できた。正しいアカウントから投稿された。これらは確認結果です。
表にすると違いが分かりやすくなります。
| 作業結果 | 確認結果 |
|---|---|
| 原稿ファイルを作った | 文字数と禁止語を検査した |
| コードを変更した | テスト結果を確認した |
| 公開画面へ入力した | 公開ページを開いて確認した |
| 設定値を変更した | 変更後の動作を確認した |
AIが作業結果を報告しても、確認結果が空欄なら、次の担当は確認から始めます。
逆に、確認まで終わっているなら、同じ操作を繰り返しません。外部サービスへの投稿や設定変更を二重に行う事故も減らせます。
次の作業は1つだけ書く
引き継ぎメモへ、思いついた作業をすべて書きたくなることがあります。
- 原稿を読む
- タイトルを考える
- 画像を作る
- タグを決める
- 公開する
- SNSへ投稿する
- 次の記事も考える
これはタスクリストとしては使えますが、再開地点としては広すぎます。翌日にまた優先順位を考える必要があるからです。
引き継ぎメモでは、最初に行う作業を1つだけ決めます。
次に行う1つの作業：
公開前に原稿を読み、未確認の表現がないか確認する
その作業が終わったあとに、次の1つを決めれば十分です。
AIへ依頼するときも、「残っている作業を全部進めて」ではなく、「引き継ぎメモの『次に行う1つの作業』だけを実行してください」と伝えます。範囲が小さければ、意図しない変更も見つけやすくなります。
未完了には「止めた理由」を添える
未完了の項目だけでは、翌日に「忘れたのか、意図的に止めたのか」が分かりません。
そこで、短い理由を添えます。
未完了：Qiitaへの公開
理由：Human Approval待ち
保留：説明画像の追加
理由：今日の公開範囲には含めないと判断
未確認：スマートフォンでの表示
理由：確認端末を用意できていない
理由があると、別のAIが勝手に未完了部分を進めにくくなります。「承認待ち」は人間の判断を待つ状態であり、AIが自動で解決する作業ではありません。
また、できなかったことを隠す必要もありません。エラーで止まったなら、エラー全文を大量に貼るのではなく、再開に必要な範囲だけを残します。
停止地点：公開設定画面を開く前
起きたこと：ログイン画面へ移動した
確認済み：原稿はローカルに保存済み
次の作業：人間がログイン状態を確認する
これなら、翌日に同じ原稿を作り直さずに済みます。
AIに引き継ぎメモを書かせる依頼文
作業の最後に、AIへ次のように依頼します。
今回の作業を、翌日再開するための引き継ぎメモにしてください。
項目は次の5つです。
1. 今日の目的
2. 完了したこと
3. 人間または実行結果で確認できたこと
4. 未完了・保留と、その理由
5. 次に行う1つの作業
提案しただけの内容を完了扱いにしないでください。
確認できない内容は「未確認」と書いてください。
秘密情報、トークン、個人情報は含めないでください。
AIが作ったメモは、そのまま保存せず、人間が短く確認します。
- 実際に終わったことだけが書かれているか
- 確認していない内容が「確認済み」になっていないか
- 次の作業が1つに絞られているか
- 公開してはいけない情報が含まれていないか
確認後、プロジェクトの原本や日次メモへ保存します。
Obsidianに残すと、使うAIが変わっても引き継ぎやすい
私は引き継ぎメモの保存先としてObsidianを使っています。理由は、Obsidianのメモが特別な専用形式ではなく、基本的にMarkdownファイルとしてローカルへ保存されるからです。
同じMarkdownファイルなら、ローカルの作業フォルダを読めるChatGPT、Claude、Cursorなどへ、共通の資料として渡しやすくなります。あるAIとの会話履歴だけに現在地を閉じ込めず、別のAIへ切り替えるときも同じメモから始められます。
Obsidianで引き継ぎメモを書く
↓
Markdownファイルとして保存される
↓
作業フォルダを読めるAIが同じメモを確認する
↓
前回の完了・未完了・次の作業から再開する
たとえば、文章の整理はChatGPT、実装はCursor、長い資料の確認は別のAIというように担当を変えても、引き継ぎメモを作り直す必要がありません。AIごとに同じ説明を何度も入力する手間も減らせます。
ただし、Obsidianを入れただけで、すべてのAIが自動的にメモを読めるわけではありません。AI側にローカルファイルを読む機能や権限が必要です。利用するツールごとに、対象フォルダを安全に共有できるか確認します。
また、Vault全体を無条件に渡すのではなく、今回の作業に必要なファイルだけを対象にします。顧客情報、個人情報、パスワード、APIキーなどは、AIへ渡すMarkdownへ含めません。
Obsidianの便利さは、どのAIにも魔法のようにつながることではありません。AIの種類が変わっても、人間が確認した同じMarkdownを出発点にできることです。特定のチャットサービスへ記録を閉じ込めないため、将来使うAIを変えるときも、引き継ぎメモをそのまま活用できます。
自分ですべて書こうとすると、メモを残すこと自体に疲れる
Obsidianは、知識や日々の記録を整理するメモアプリとして紹介されることが多く、私も情報を残す場所として便利だと感じています。
一方で、毎日の作業が終わったあとに、出来事を思い出し、文章を整え、見出しを付け、関連するメモへつなぐ作業をすべて自分で行うと、記録を続けること自体に疲れてしまいます。メモをきれいに作ることが目的になり、本来の仕事や開発が進まなくなることもあります。
そこで私は、メモの下書きや整理をAIに手伝ってもらいます。
人間：今日行ったことと確認結果を短く渡す
↓
AI：事実・判断・未完了・次の作業へ整理する
↓
人間：内容を確認し、間違いや秘密情報を除く
↓
AIまたは人間：確認済みの内容をObsidianへ反映する
たとえば、まとまっていない箇条書きや作業ログをAIへ渡し、「重複を除き、引き継ぎメモの5項目に整理してください」と頼みます。既存のメモが長くなったら、古い情報と現在地を分けてもらうこともできます。関連するファイル名が分かっていれば、追記先の候補を出してもらえます。
ローカルファイルを編集できるAIなら、確認した内容をMarkdownへ追記するところまで任せられます。ファイルを直接編集できないAIでも、貼り付け用のMarkdownを作ってもらえば、自分で一から文章を書く負担を減らせます。
ただし、AIが書いた内容を無確認で原本にはしません。実際には行っていない作業が完了扱いになっていないか、古い情報が混ざっていないか、個人情報や認証情報が含まれていないかを人間が確認します。
Obsidianを「自分が毎日きれいな文章を書く場所」と考えると負担になります。「自分の事実をAIに整理してもらい、確認済みの記録を残す場所」と考えると、メモを続けやすくなります。
書かないほうがよい内容
引き継ぎメモは、詳しいほどよいわけではありません。翌日の再開に不要な情報を増やすと、重要な項目が埋もれます。
私は、次の内容を原則として書きません。
- チャット全文のコピー
- 採用しなかった案の長い説明
- AIが推測した将来予定
- APIキー、トークン、パスワード
- 顧客や個人を特定できる情報
- 「たぶん完成」「おそらく問題ない」のような曖昧な判定
採用しなかった案に意味がある場合は、引き継ぎメモではなく決定記録へ残します。エラーの詳細が必要な場合は、ログの保存場所だけを書きます。
引き継ぎメモの役割は、すべてを保存することではありません。次の担当が迷わず安全に再開できる入口を作ることです。
翌朝はメモから始める
翌日に作業を再開するときは、先にチャットを開くのではなく、引き継ぎメモを読みます。
確認する順番は次の通りです。
- 今日の目的がまだ有効か
- 完了した作業を繰り返そうとしていないか
- 確認済みの内容に新しい変化がないか
- 未完了の理由が解消されたか
- 「次に行う1つの作業」を今実行してよいか
状況が変わっていたら、以前のメモを無理に実行しません。たとえば、公開予定日が変わった、原稿の前提になった情報が更新された、人間の判断が変わった場合は、現在地を更新してから再開します。
メモは命令書ではなく、前回の作業から安全につなぐための記録です。最新の事実と人間の判断が優先されます。
5分で終わる形にする
引き継ぎメモが長すぎると、毎日続きません。目安は、書くのに5分、読むのに1分です。
1日の終わりに、次の問いへ一文ずつ答えるだけでも構いません。
今日は何をする日だったか？
実際に何を終えたか？
何を自分の目で確認したか？
何が残り、なぜ止めたか？
明日、最初に何をするか？
何日か続けると、よく止まる場所も分かります。承認待ちが多い、公開後の確認を忘れやすい、次の作業が大きすぎる、といった傾向です。
その傾向をもとに、チェック項目や作業の分け方を改善できます。引き継ぎメモは、記録であると同時に、作業方法を見直す小さな材料になります。
まとめ
AIとの作業を翌日に引き継ぐとき、長い会話をすべて読み直す必要はありません。
- 今日の目的
- 完了したこと
- 確認できたこと
- 未完了・保留と理由
- 次に行う1つの作業
この5項目を残せば、別のAIへ切り替えたときも、作業結果と確認結果を混同せずに再開できます。
大切なのは、AIに美しい日報を書かせることではありません。昨日の自分が何を終え、どこで人間の判断を待ち、今日の自分が何から始めればよいのかを明確にすることです。
まず今日の作業が終わったら、「次に行う1つの作業」だけでも書いてみてください。それだけで、明日の最初の迷いを減らせます。
この記事は、Qiita記事制作とAIを使った個人開発で、作業結果、確認結果、Human Approval、公開記録を分けてきた本プロジェクトの運用をもとに構成しました。