長いメモを抱えたまま Claude Code に作業させると、だいたい途中で鈍る。読ませた本人が満足してしまうのがいちばん厄介だ。実際には、後で効くのは「何を決めたか」だけで、経緯や雑談はほぼ邪魔になる。
ここでいうのは、作業メモを絞る、短い指示で回す、という考え方だ。Claude Code に持たせるメモは、思いついたことを全部盛りしたメモ帳ではない。作業の途中で迷わないように、決定事項だけを残す道具だ。
筆者は最初、仕様の経緯も未決定の論点も、全部そのまま投げていた。すると Claude Code は筋のいい補助をする前に、どこが確定でどこが未確定かを読み解くところで余計なコンテキストを使う。結果、出てくる差分が散らかる。ひどいときは、古い前提を拾って戻り作業が増えた。あれは単純に、メモが長すぎたせいだ。
Claude Code に渡すメモは、次のような形に寄せると強い。
目的: README を短くする
決定事項:
- 対象は使い方の説明だけ
- インストール手順は別ファイルに分けない
- 例は macOS と Linux のみ
- 文章は日本語で書く
- 既存の見出し構成は維持する
この程度で足りることが多い。ポイントは、背景説明を削ることではない。背景が必要な場面はある。ただし、作業中に Claude Code が何度も参照するメモに入れるべきなのは、解釈がぶれない決定事項だ。
たとえば「なぜそうするのか」は、最初に一度共有すれば十分なことが多い。作業メモに入れるのは「何を採るか」「何を捨てるか」だけでいい。そこを濃くすると、モデルは迷いにくい。
やりがちなのが、会議の議事録みたいなメモをそのまま食わせることだ。候補案、検討中、保留、たたき台、全部入り。人間の読み物としてはわかるが、作業指示としては弱い。
Claude Code は「決めたこと」を使って動かすのが向いている。逆に、まだ決めていないことをメモに残すと、途中で余計な分岐が増える。たとえば文書修正なら、次のように切る。
修正方針:
- 用語は「利用者」に統一する
- 重複説明は削除する
- 導入文は半分の長さにする
未決定:
- 事例を増やすかは別途判断する
- 参考リンクはあとで精査する
この「未決定」は、作業中のメモには置かないほうがいい。別の管理場所に逃がす。Claude Code に見せるのは、今その場で判断済みのものだけだ。
長文のメモが悪いのは、長いからではない。繰り返し読む価値がない情報が混ざるからだ。たとえば「この案件はこういう経緯で、あの人がこう言っていて……」という話は、作業者の頭には残るが、編集対象のファイルには何も残らない。
筆者がファイル整理を手伝わせたときも、最初は「なぜこの分類なのか」まで延々と書いた。だが、実際に必要だったのは「このフォルダは年度別にまとめる」「重複候補は別フォルダへ退避する」「迷うものは消さず保留にする」だけだった。経緯を削ったら、指示はむしろ通りやすくなった。
Claude Code に渡す文は、こういう書き方が扱いやすい。
やること:
- docs/ 配下の説明文を整理する
- 重複している段落は統合する
- 変更後も意味が変わらない範囲で短くする
守ること:
- コード例は削らない
- ファイル名は変えない
- 事実関係は足さない
これで十分だ。説明が必要なら、別メモで補足しておけばいい。作業中のメモに全部入れる必要はない。
ここは勘違いされやすい。短いメモは、情報を削ることではない。判断済みの要点だけ残して、迷いの材料を捨てることだ。
雑なメモは、重要な制約まで抜ける。すると Claude Code は勝手に埋めようとする。そこが危ない。たとえば「要約して」とだけ投げると、何を残すべきかがぼやける。逆に、次の三つがあればかなり戦える。
この三つを短く書くと、作業は安定する。
目的: 依頼メールの下書きを読みやすくする
変更してよい範囲: 文章の順番、重複表現、言い回し
変更してはいけないもの: 相手の名前、期限、金額
この手のメモは、開発でも文書作成でも同じだ。実装なら「API の挙動は変えない」「UI 文言だけ直す」。書類整理なら「案件名は維持する」「日付順に並べる」。決めるべきことだけが生き残る。
ここを履き違えると、メモがどんどん膨らむ。あとで見返したくなるから全部残す、という気持ちはわかる。だが、Claude Code にとって必要なのは記録ではなく、今の行動を決める文だ。
だから、作業メモには「何をしたか」を入れすぎないほうがいい。代わりに「今どこまで決まっているか」を書く。
現時点で確定:
- 章立ては維持
- 重複する注意書きは統合
- 例は 2 個まで
- 口調は常体
保留:
- FAQ を残すかどうか
これなら、後で見返しても迷わない。しかも、作業途中で Claude Code が前提を取り違えにくい。
作業が詰まると、つい補足を足したくなる。だが、たいていは逆だ。補足を足す前に、まず「それ本当に今必要か」を見る。不要な背景や例外は切る。決定事項だけ残す。これで大抵は解ける。
筆者は差分が膨らんだとき、補足を追加して乗り切ろうとして失敗したことがある。Claude Code は親切に受け取るぶん、入力が増えると、どれを優先すべきかの読み取りに余計なコストがかかる。結局、メモを短くしたほうが速かった。地味だが、これが効く。
最後にひとつだけ。長い会話の途中で方針が変わったら、古いメモを残したまま追記しないほうがいい。新しい決定事項に差し替える。古い前提が混ざると、作業が静かに壊れる。Claude Code はそこを察して掃除してくれる存在ではない。
メモは厚くするものではなく、削って尖らせるものだ。決定事項だけ残す。これだけで、作業の速度も、差分のきれいさも、かなり変わる。