#claude-code-context-hygiene

最後の最後に雑に投げるだけだと、Claude Code はかなり簡単に“作業した気分の断片”を吐く。そこから人に渡せる形へ直す一手間を入れるかどうかで、引き継ぎ用の要約、最終サマリー、成果物の整形の質が露骨に変わる。ここをサボると、あとで「結局どこが変わったのか」「何を前提に進めればいいのか」が読み取れず、会話をもう一往復、いや二往復する羽目になる。 筆者は最初、作業が終わった直後に「変更点をまとめて」とだけ頼んでいた。すると、モデルはだいたい“それっぽい説明”を返すが、実際にはファイル名の列挙だけだったり、重要な判断理由が抜けていたりする。コード修正なら diff を見ればまだ追えるが、書類整理や設定整理だとそれができない。終わり際にもう一回、引き継ぐ前提でまとめ直す。これが効く。 やり方は単純だ。作業が一通り終わったら、Claude Code に対して「ここまでの成果を、後任がそのまま続きから入れる形に整えて」と明示する。ポイントは、単なる要約ではなく、次の人が迷わない順序に並べ替えさせることだ。たとえば次のように頼む。 ```text ここまでの作業を、引き継ぎ用の要約として整理

Claude Code に雑に「適当に進めて」と投げると、静かに深掘りしすぎて、あとから人間が困る。これが一番ありがちな事故だ。節目だけ報告、進捗の粒度、黙らせるか返させるかを先に決めておくと、作業の暴走をかなり防げる。 特に Claude Code は、頼み方が広いほど、丁寧にやりすぎる。ファイルを読み込み、関係ありそうな箇所まで追い、修正案を積み上げる。その間に「今どこまで進んだか」が見えないと、こちらは待つしかない。長いコード修正でも、書類整理でも、途中報告の設計がないと後でまとめて確認する羽目になる。差し戻しが重い。 筆者も最初はこれで何度か手戻りした。たとえば「このフォルダの重複ファイルを整理して」とだけ頼むと、探索を丁寧にやりすぎて、不要な比較や候補出しに時間を使う。あとで「そこまで細かく見なくてよかった」となる。逆に、途中で一度だけ報告させるようにすると、方向修正が早い。Claude Code を黙らせるか、こまめに返させるかを先に決めるだけで、かなり扱いやすくなる。 やり方は単純でいい。最初の指示に、報告の節目を入れる。ポイントは「何文字ごと」みたいな機械的な指定より、

Claude Code に雑に長文を投げて、そのまま最後まで走らせる。これをやると、途中で前提がズレたまま突き進み、あとで手戻りする。かなりあるあるだ。 そこで効くのが、途中で要約を挟ませるやり方である。節目で要約、中間サマリー、会話の棚卸し、と呼び方はいろいろあるが、要するに「ここまでの理解を一回言わせる」だけだ。これを入れると、Claude Code が勝手に補完した前提、抜けた制約、あいまいな目的を早めに炙り出せる。 特に、ファイル整理、古い資料の整理、複数フォルダにまたがる改修、長い文章の整形みたいな作業で効く。人間側も、途中で判断軸を見直しやすくなる。 筆者は一度、長い修正依頼を最初から最後まで一気に投げて、Claude Code が「見た目を整える」方向に寄りすぎたせいで、肝心の命名ルールを外されたことがある。あのとき、途中要約を入れていれば、ズレは半分くらいで止められたはずだ。 やり方は単純で、最初に「一定量進んだら、作業を止めて要約して」と明示する。ポイントは、単に「要約して」では弱いことだ。何を確認したいのかまで書く。たとえば、目的、前提、未確定点、次にやることを分け

長い資料を丸ごと投げて「読んで」とやると、だいたい途中で雑になる。Claude Code は雑にしても止まらないが、こちらの意図は平気で薄まる。そこで効くのが、章ごとに渡すやり方だ。分割投入、資料を小分けにする、一気読みさせない、というやつである。 これは単なる小技ではない。長文の仕様書、契約書の下書き、議事録、マニュアル、フォルダ整理のルール説明まで、長いものを扱うときの基本動作だ。資料を一気に食わせるより、章単位で渡したほうが、Claude Code は論点をつかみやすい。こちらも「今どこを見ているか」を見失いにくい。 たとえば、20ページの社内手順書を要約したいとする。全文を貼る前に、目次だけを見せる。次に第1章だけ、次に第2章だけ、という具合に進める。これだけで、抜けやすい注意点や、章ごとの言い回しの揺れを拾いやすくなる。非エンジニアの人でも同じで、案件フォルダの整理ルールや、請求書の命名規則を見直すときに相性がいい。先に全体像、あとで各章。順番を守るだけで迷子になりにくい。 実際の頼み方は、かなり素直でいい。まずは全体の目的を一言で固定する。 ```text この資料を章ごと

「たくさん渡せば賢くなる」は、Claude Code ではわりと危ない思い込みだ。長文をそのまま投げる、関係ないフォルダまで一緒に渡す、メモを全部貼る。やりがちだが、これで答えが良くなるとは限らない。むしろノイズが増えて、出力がぶれる。要点だけ渡す、長文を圧縮する、文脈を削る。こっちのほうが、狙いが通りやすい。 Claude Code は会話の空気を読む道具ではあるが、空気を吸わせすぎると息が詰まる。特に、ファイル整理や文書作成みたいな用途では、材料を盛るほど安心しがちだ。だが実際には、余計な背景が多いほど「何を優先するべきか」がぼやける。筆者も最初は、関連資料を全部貼って「これで完璧だろ」と思い、逆に修正の手戻りを増やした。要らない文脈が混ざると、エージェントはそれを無視しきれず、無駄に広い解釈を始める。 なので、まずやるべきは「情報を増やす」ことではなく、「仕事に関係する芯だけ残す」ことだ。Claude Code に渡す前に、次の3つに分けると扱いやすい。 何をしたいのか どのファイル、どの範囲が対象か 何をしないのか この3つだけで、かなり通る。 たとえば、リポジトリ内の古い M

Claude Code に雑に頼んで、返ってきた答えが毎回バラつく。これはかなりありがちな失敗だ。長文で返ってきたり、逆に一言で終わったり、箇条書きが崩れたりする。先に返答の形を決めておかないと、後で整える手間が地味に重い。 ここで効くのが、Markdown か表かを決める、つまり出力形式の固定だ。要するに「返答を整える」ための下ごしらえを先にやる。Claude Code は指示が曖昧だと、内容は合っていても見た目や粒度が暴れやすい。逆に、最初に形を縛ると、比較・一覧・手順書・要約がかなり扱いやすくなる。 たとえば、ファイル整理や文書作成で Claude Code を使うとき、返答の形を先に決めないと困る場面は多い。重複ファイルの候補を洗い出したいのに、説明文ばかり返ってくる。案件メモを整えたいのに、段落が長すぎてコピペしづらい。そんなときは、最初から「この形式で返して」と言い切るのがいちばん手っ取り早い。 実際の頼み方はこうだ。 ```text 以下の内容は Markdown の見出しと箇条書きで返してください。 余計な前置きは不要です。 各項目は 1 行で短くまとめ、最後に次にやる