2026-08-24

作業中に持たせるメモは短く、決定事項だけ残す

長い経緯メモを Claude Code に持たせると、だいたいろくなことにならない。読み返すだけでコンテキストを食い、肝心の判断材料が埋もれる。残すべきなのは、途中の雑談ではなく決定事項だ。短い作業メモ、あるいは決定事項の圧縮という発想に切り替えると、作業が急に軽くなる。

Claude Code は会話の流れを踏まえて動く。だからこそ、途中で「ここまで何を決めたか」を短く固定しておくと強い。逆に、経緯をだらだら積み上げると、あとから見返したときに自分でも迷うし、Claude Code も無駄に揺れる。筆者は最初、会議の議事録みたいなメモをそのまま貼っていたが、修正のたびに話が分散して、同じ説明を何度もやり直した。あれははっきり無駄だった。

たとえば、あるフォルダ整理を頼む場面を考える。
悪いメモはこうなる。

昨日の続きで、あの資料も入っていて、こっちのファイル名も少し変えていて、最初はPDF中心だったけど途中で画像も混ざって、クライアントの都合で表紙の扱いが変わって、たしか社内共有用と提出用で分ける話もあって……

これだと、何が決定で何がただの経緯か分からない。Claude Code にとっても、人間にとってもノイズだらけだ。

残すべきなのは、こういう形だ。

決定事項:
- 提出用フォルダと社内共有用フォルダは分ける
- 提出用はPDFのみ
- ファイル名は yyyy-mm-dd_案件名_内容 に統一
- 画像は提出用に入れない
- 旧版は archive に移す

この程度で十分だ。むしろ、これ以上は増やさないほうがいい。作業中のメモは記録ではなく、判断の再利用装置だと考えるといい。

Claude Code にそのまま渡すなら、依頼文の中でメモの役割を明示すると効く。たとえばこうだ。

以下の決定事項だけを前提に作業してください。
経緯の説明は不要です。新しい判断が必要になったら、その場で確認してください。

決定事項:
- 提出用と社内共有用を分ける
- 提出用はPDFのみ
- ファイル名は yyyy-mm-dd_案件名_内容 に統一
- 旧版は archive に移す

ここで大事なのは、「わかるだろう」で済ませないことだ。Claude Code は察してくれる相手ではあるが、曖昧なメモを読めるほど都合よくはない。メモが長いと、後半の本題より、前半のどうでもいい経緯に引っぱられる。これが地味に痛い。差分が膨らむし、修正の意図もぼやける。

筆者がいちばん手戻りしたのは、仕様変更の履歴を全部メモに入れていたときだ。
「最初はAだったが、途中でBになり、さらにCの懸念が出たので……」と残していたせいで、Claude Code が古い方針をまだ生きているものとして扱い、不要な修正を続けた。ここで必要なのは履歴ではなく、今の決定だけだ。古い経緯は消すか、別ファイルに退避する。作業中のメモに全部入れる発想がまず重い。

短くするコツは、次の3種類に分けることだ。

1. 決定事項
2. 保留
3. 参照先

この枠だけで十分回る。実際のメモはこんな感じになる。

決定事項:
- 提出用はPDFのみ
- ファイル名は yyyy-mm-dd_案件名_内容

保留:
- 旧版の保存期間は未確定

参照先:
- 元資料は /docs/2024/project-a/

これなら、Claude Code に渡しても、人間があとで見ても迷いにくい。保留を「保留」と明示するのも大事だ。未決定の話を決定事項に混ぜると、あとで自分が引っかかる。短いメモの価値は、読む速度だけでなく、判断ミスを減らすところにある。

非エンジニアの作業でも同じだ。たとえば、契約書の下書き、請求関連の書類整理、写真やPDFの片づけでも、メモを長文化すると詰まる。
「どの版を残すか」「どれを捨てるか」「どの名前で揃えるか」だけを書けばいい。背景説明は長いほど親切、ではない。むしろ後から見返したときに邪魔になる。

決定事項:
- 2024年分は1つのフォルダに集約
- 社外提出版だけ残す
- 重複PDFは古い日時のものを削除
- ファイル名は日付を先頭にする

こうしておくと、Claude Code に「この決定に沿って重複を整理して」と頼める。ファイルの整理は、途中の迷いをいかに減らすかで決まる。長い説明を残して安心するやり方は、見た目ほど役に立たない。

気をつけたいのは、短くすることと雑にすることは別だという点だ。短い作業メモは、曖昧でいいわけではない。むしろ逆で、曖昧な部分ははっきり「保留」と書く必要がある。ここをぼかすと、Claude Code が勝手に穴埋めしてしまう。穴埋めが許される場面と、絶対に勝手に決めてほしくない場面は違う。そこははっきり線を引く。

もうひとつ、メモは増やしすぎないほうがいい。作業中のメモ帳が肥大化すると、結局どこに決定があるのか分からなくなる。筆者は一時期、箇条書きを増やしすぎて、自分で探すのに時間を取られた。あれは実質的にコンテキストの浪費だ。残すのは、あとでそのまま再利用できる文だけで十分だ。

運用としては、次のやり方がいちばん扱いやすい。

- 作業の節目でメモを1回圧縮する
- 長い経緯は消す
- 決定事項だけ残す
- 新しい判断が出たら、古い決定は上書きする

Claude Code に渡す前に、自分で一度読み返すだけでも効く。もし読んだ瞬間に「長いな」と感じたら、その時点でだいたい失敗している。半分くらいまで削っても困らないことが多い。残すのは説明ではなく、次の手を打つための芯だ。

作業中のメモは、日記でも議事録でもない。短く、決定事項だけ残す。これだけで、Claude Code の動きはかなり素直になる。長い説明を抱え込ませるより、要点を圧縮して渡したほうが、修正も整理も速い。細かい経緯は別にしまう。作業の場には、今使う判断だけ置いておけばいい。

関連 TIPS

同じ著者の記事

返答を短くさせたいなら、先に分量の上限を伝える

長文を投げておいて「要点だけ返せ」は、だいたい伝わりきらない。Claude Code でも同じで、先に分量の上限を決めておかないと、返答は平気で膨らむ。短くまとめさせる、要点だけ返させる、という使い方をしたいなら、最初に「何行まで」「何文字まで」「箇条書き何点まで」を入れておくのがいちばん効く。これはコードの相談だけの話ではない。ファイル整理の相談でも、文書の下書きでも、ディスク削減の手順でも、先に制限を言うだけで返答の密度が上がる。逆に、あとから「もっと短く」と言い足すと、すでに出した長文を削る作業が発生して、無駄が増える。たとえば、こう頼む。 ```text 次の内容を、3行以内で短くまとめてください。要点だけ返してください。前置きは不要です。 ``` Claude Code にコーディングの相談をするなら、もう少し型を決めるといい。 ```text この変更案を、箇条書き3点以内で短くまとめてください。各項目は1文まで。背景説明は不要です。 ``` 文書作成なら、分量の上限を先に置く。 ```text この文章を、200字以内で要点だけ返してください。読者が次に取るべき

papoo.work

Markdown か表かを最初に決めると、返答が暴れない

Claude Code に雑に「一覧で」「見やすく」で投げると、返答の形が毎回ぶれる。ここを甘く見ると、あとでコピペしづらい、差分が読みにくい、保存したときに壊れやすい、の三重苦になる。先に Markdown で出すのか、表で出すのかを決めておく。要するに出力形式の固定だ。成果物の形を先に決めるだけで、返答はかなり安定する。この手の話は、エンジニアのコードレビューだけの話ではない。ファイル整理でも、議事録作成でも、請求書の確認でも同じだ。たとえば「重複ファイルの候補を拾ってほしい」と頼むときに、表で返してほしいのか、Markdown の見出し付きで返してほしいのかが曖昧だと、途中で形式が変わる。そうなると人間の目でも扱いにくいし、次の工程に渡しづらい。筆者も最初はここで何度も手戻りした。Markdown のつもりで頼んだのに、途中から表が混ざる。逆に、表で見たかったのに箇条書きが増える。Claude Code は内容をちゃんと理解していても、出力の器が決まっていないと、返し方が揺れることがある。コンテキストを食うわけではないが、余計な往復が増える。地味にだるい。まず、最初に器を決

papoo.work

前提が変わったら古い指示を捨てて、言い直す

Claude Code に同じ話を延々と持ち込んでいると、だいたい一回はズレる。古い前提を残したまま「ちょっとだけ追加で」と積み上げるからだ。方針変更の再指示、古い前提を残さない、というのは派手なテクニックではないが、実務ではこれが効く。たとえば、最初は「このフォルダの重複画像を整理して」と頼んでいたのに、途中で「やっぱり削除は怖いから一覧だけにして」と方針が変わったとする。ここで前の指示を引きずったまま会話を続けると、Claude Code は「削除前提の整理」と「一覧化だけ」を両方気にして、中途半端な出力を返しやすい。これは開発でも文書作成でも同じで、前提が変わったのに古い条件を残すと、やり直しが増える。やることは単純だ。方針が変わったら、差分だけを足すのではなく、いったん前提を切り替えて言い直す。Claude Code は会話の流れを見て動くので、「さっきの続き」より「今の前提」を明確に渡したほうが強い。たとえば、こう書き直す。 ```text ここからは前の指示をいったん忘れてください。前提を変更します。目的: 重複ファイルの削除ではなく、一覧化だけを行う禁止事項:

papoo.work

節目で要約を挟ませると、長い会話でも前提が崩れにくい

長いやり取りほど、Claude Code は勝手に賢くなった気になって崩れる。実際には、途中で前提が抜ける、対象ファイルを取り違える、同じ修正を別名で繰り返す、こういう地味な事故が起きやすい。そこで効くのが途中要約だ。会話を区切って要約させる。節目で一度整理を挟むだけで、どこまで進んだか、何を決めたか、何を残したかが見えやすくなる。 Claude Code は、長い会話を続けるほど文脈をたくさん抱える。便利ではあるが、文脈が増えれば増えるほど「今なにを前提に話しているか」がぼやける。ファイル整理でも、ディスク削減でも、文書作成でも同じだ。最初は「不要ファイルの洗い出し」だったのに、いつの間にか「命名規則の話」へ飛び、最後には「手順書の整形」に話が化ける。人間が手綱を握っていないと、会話は平気で迷子になる。だから、節目を作る。たとえば、ひとつの大きな作業を終えたら、次の指示を出す前に要約を挟む。途中要約でもいいし、会話を区切って要約させる、でもいい。要は「今までの議論を、後で読んでも使える形で短く固めておけ」ということだ。実際の頼み方は、こんな形で十分だ。 ```text ここまでの

papoo.work

途中報告の頻度を指定して、黙って進みすぎるのを防ぐ

Claude Code に任せると、気づいたら最後まで走り切っていて、途中の判断材料が消えることがある。これが地味に痛い。途中報告を入れさせる、中間報告を入れさせる、進捗の粒度を決める。この3つをちゃんと使うだけで、勝手に突き進んで戻れなくなる事故をかなり減らせる。特に、ファイル整理や文書作成みたいな「正解はあるが、途中で見たい」作業では効く。全部終わってから見せられても、そこまでの流れが雑だと手戻りがだるい。最初に報告の頻度を決めておけば、Claude Code は勝手に走る道具ではなく、区切って確認しながら進む相棒になる。まず押さえるべきなのは、指示は「こまめに見せて」だけでは弱いという点だ。Claude Code は、曖昧な指示だと節目の定義を自分で決めがちだし、その節目があなたの感覚とズレる。だから、何回ごとに、どの単位で、何を報告するのかまで決める。たとえば、文書のたたき台を作らせるなら、こう書く。 ```text まず作業計画を短く出してから、3段階ごとに途中報告してください。各途中報告では、今やったこと、次にやること、迷っている点を3行で示してください。勝手に最

papoo.work

返答の形を先に固定する：Markdown か表かを決めてから頼む

Claude Code に雑に「これを整理して」と投げると、返ってくるものが妙に長い説明文になって、あとで自分が切り貼りする羽目になる。ここで先にやるべきなのは、出力形式を先に決めることだ。Markdown でほしいのか、表でほしいのか、成果物の形を固定してから頼む。これだけで手戻りがかなり減る。たとえば、ファイル整理でも文書作成でも、欲しいのは「考え方」より「そのまま使える形」だろう。Markdown なら見出しや箇条書きをそのまま草案にできるし、表なら項目ごとの比較や一覧にそのまま流し込める。Claude Code は指示が曖昧だと、親切に見えて実は中途半端な出力を返しがちだ。そこを最初に縛るのが、このTIPSの肝である。実務では、依頼文の冒頭に形式を明記するだけでいい。たとえばこうだ。 ```text 次の内容を、Markdown の見出し付きで整理してください。本文はそのまま貼れる形にしてください。 ``` Markdown にしたいなら、どこまで機械的に整えてよいかも添えると強い。 ```text 次のメモを Markdown で整形してください。見出しは h2 相当

papoo.work

長い資料は章ごとに渡して、一気読み前提をやめる

長い資料をそのまま全部投げるのは、だいたい雑だ。Claude Code は長文でも扱えるが、だからといって「最初から最後まで一気に読んで、全部を一発で直してくれ」で済ませると、要点がぼける。途中で重要な条件を落としたり、修正の軸がぶれたりして、あとで手戻りになる。ここで効くのが、章分けして渡す、あるいは分割投入だ。資料を見出し単位、章単位、用途単位で切り、順番に渡していく。これだけで、Claude Code が今どこを見ているのかがはっきりする。長い議事録、仕様書、契約書の下書き、マニュアル、散らかった手順書。全部に効く。非エンジニアでも同じだ。ファイル整理のルール文書や、社内向けの手順書を整えるときにもかなり使える。筆者は最初、長文を丸ごと貼って「要約して、ついでに直して」と頼んでいた。結果は悪くないのに、肝心の制約が抜ける。後から「いや、そこは残すべきだった」と気づいて、もう一回やり直しになる。あれはだるい。章ごとに渡し始めてから、話が戻りにくくなった。やり方は単純だ。まず資料を人間が読んで、章や役割で切る。次に、各章を別々に扱わせる。たとえば、先に全体方針を固め、その後で各

papoo.work

終わった作業を片付ける

終わった仕事をそのまま残す人は多い。しかも「あとで見るから」と言いながら、数日後には同じブランチ、同じ作業フォルダ、同じ不要ファイルの山にまた足を取られる。Claude Code はそこを雑に流さず、使い終わった作業場所を整理する、ブランチやフォルダの後片付けまで含めて片づけ役にできる。ここでやりたいのは大げさな自動化ではない。作業が終わったら、残すものと捨てるものを切り分けて、コンテキストもディスクも空けることだ。これをやらないと、次の依頼で Claude Code が余計なファイルを拾ったり、古い差分に引っ張られたりして、地味に手戻りが増える。「片付ける」と言っても、全部消せばいいわけではない。残すのは、あとで参照する必要があるものだけだ。たとえば、作業メモ、最終成果物、再利用したいテンプレート、あるいは案件の証跡になる書面だ。消すのは、途中で作った一時ファイル、古い出力、使い捨ての検証フォルダ、役目を終えたブランチだ。 Claude Code には、最初からこの判断を言葉で渡しておくといい。たとえばこんな依頼で十分だ。 ```text この作業が終わったら、後片付けまでやって

papoo.work

試し書きは別場所で済ませる

本番のファイルにいきなり書き始める人は、だいたいあとで自分の差分に泣く。Claude Code でも同じで、思いついた指示を確定版に直書きすると、途中の試し書きまで履歴に残って、あとから何が本筋だったのか分からなくなる。やることは単純だ。下書き専用の場所を作る。確定版に直書きしない。これだけで、Claude Code に考えさせる内容と、最終的に残す内容を分けられる。結果として、コンテキストの無駄遣いが減り、差分も読みやすくなる。ファイル整理でも文書作成でも効く、地味だが効き目の大きい癖だ。たとえば、案件ごとにこんな構成にしておくと扱いやすい。 ```text project/ draft/ 2026-08-21-notes.md final/ report.md ``` Claude Code には、まず下書き側だけ触らせる。 ```bash claude ``` 依頼文はこんな具合でいい。 ```text draft/2026-08-21-notes.md に、報告書の材料を箇条書きで整理して。このファイルは下書き専用。本文の確定版には触らないで。まだ文章は整えなくていい。

papoo.work

ブランチを切る前に整理する

ブランチを切ってから考える人は、だいたいあとで自分の差分に殴られる。変更を小さく始める準備、作業開始前の下ごしらえを飛ばすと、Claude Code に渡す文脈が散らかる。すると指示は長くなるし、余計なファイルまで触るし、diff もでかくなる。手戻りの回数が増えるのは、たいていここだ。 Claude Code は、雑な状態でもそれなりに進めてしまう。そこが便利でもあり、危ないところでもある。だからブランチを切る前に、作業対象を絞り、不要物を片づけ、今から何をやるかを一度だけ言葉にしておく。これだけで、生成される提案の精度がかなり変わる。非エンジニアのファイル整理でも同じだ。案件フォルダ、請求書、原稿、重複画像がごちゃついたまま頼むと、まず整理にコンテキストを食われる。先に片づけるほうが早い。ブランチ名を考える前に、Claude Code に見せる範囲を狭める。これが一番効く。巨大なリポジトリ全体を相手にすると、文脈が薄まる。人間でも、机の上に関係ない紙が山ほどあると集中できない。それと同じだ。作業前にやるのは、この三つで足りる。 1. 今回の目的を一文で書く 2. 触るファ

papoo.work