作業が終わったあとに「もう十分だろ」と放り出すと、あとで一番だるい。受け取る側が読む気を失うからだ。Claude Code を使うなら、最後にやるべき仕事は修正の上積みではない。最終要約、つまり成果物の圧縮だ。引き継げる形に整えて初めて、作業は終わる。
ここでいう「まとめ直し」は、長い説明を短くするだけではない。何をやったか、何が変わったか、残っている懸念、次に誰が触るべきかを、読み飛ばされにくい順番で並べ直す作業だ。ファイル整理でも、文書作成でも、コード修正でも効く。雑に散ったメモを、そのまま渡せる状態にする。これができると、やり直しが減る。
Claude Code に頼むときは、最初から「要約して」とだけ投げないほうがいい。あれは短くなるだけで、引き継ぎやすくはならないことがある。要点の選び方まで指示したほうが、あとで使える形になる。
たとえば、作業ディレクトリの内容を最後に整理したいなら、こう頼む。
Claude Code にこう依頼する：
このフォルダ内の作業内容を、引き継ぎ用の最終要約にまとめてください。
次の順で出してください。
1. 何をやったかを3〜5行で要約
2. 変更したファイル名と役割
3. まだ残っている確認事項
4. そのまま次の人に渡せる注意点
長文の説明は削っていいですが、固有名詞・ファイル名・未完了事項は落とさないでください。
読み手はこのフォルダを初めて見る人です。
文書作成なら、用途をもう少し絞る。単なる圧縮ではなく、読む相手を決めるのがコツだ。
この議事メモを、引き継ぎ用の最終要約にしてください。
前提を知らない人が読んでも分かるように、以下を残してください。
- 決まったこと
- 保留になったこと
- 誰が何をするか
- 次回までに準備するもの
口調は簡潔でいいですが、曖昧な表現は避けてください。
元のメモにないことは足さないでください。
ここで大事なのは、「何を削るか」より「何を残すか」だ。Claude Code は長い元データから整った文を作るのは得意だが、放っておくと気持ちよく一般論へ流れることがある。そうなると、見た目は整っているのに、実務では使えない。筆者は以前、修正履歴の要約を頼んで、見事に無難な文章へ丸められたことがある。固有のファイル名も、残タスクも薄まった。読みやすいのに引き継げない。いちばん腹が立つやつだ。
だから、最終要約では「落としてはいけないもの」を先に書く。ファイル名、日付、未完了、判断理由、この4つはだいたい残す対象になる。逆に、同じ意味の言い換えや、途中経過の細かい試行錯誤は削っていい。そこまで残すと、要約ではなく墓標になる。
次の条件で最終要約を作ってください。
- 重複した説明は統合する
- 途中の試行錯誤は省く
- 結論、差分、未完了事項は残す
- 使ったファイル名や見出しは可能な範囲で残す
- 読み手が次に何をすればいいか分かる形にする
このとき、Claude Code に「美しく書いて」とだけ言うのは危ない。美しさの基準が、引き継ぎやすさとズレるからだ。整いすぎた文章は、かえって判断の筋道が見えなくなる。要約は飾りではない。読む側の手間を減らす道具だ。
注意したいのは、成果物の圧縮をしすぎると、あとで元に戻せなくなる点だ。作業ログを全部捨てる前に、元のファイルや差分は残しておくほうがいい。特にコード修正では、要約だけ見て「もう終わった」と勘違いしやすい。実際には、テスト未実施、例外処理未確認、手作業の置換が残っていることがある。まとめ直しは、完了宣言ではなく棚卸しだ。
非エンジニア向けの使い方でも、考え方は同じだ。たとえば、フォルダの中に散った企画書、修正版、相手先別のメモを最後にまとめるときは、Claude Code に「提出版に必要なものだけ残す」と伝えるといい。不要な途中稿を並べたまま渡すと、受け手はどれが最新か分からなくなる。そこを先回りして潰すのが、引き継げる形に整える仕事だ。
この案件フォルダの内容を、提出用に引き継げる形へ整理してください。
次のルールでまとめてください。
- 最終版として使うファイルを明示する
- 古い版や重複は区別できるようにする
- 受け手が最初に見るべき順に並べる
- 不要な補足は削る
- ただし、判断に必要な注意点は残す
もう一段踏み込むなら、最終要約を「次の人のための入口」にする。つまり、単に結果を書くのではなく、次に触る人が迷う地点を先回りして書く。どこを見ればよいか、どこは触らないほうがいいか、何を確認すれば完了か。ここまで入ると、要約はメモから引き継ぎ資料になる。
Claude Code を最後に使う場面は、派手ではない。でも効く。長い経緯を削って、必要な芯だけ残す。成果物を圧縮して、受け取る側がすぐ動ける形にする。作業の終わりにこの一手を入れるかどうかで、翌日の手戻りがかなり変わる。