#claude-code-context-control-2

作業が終わったあとに「もう十分だろ」と放り出すと、あとで一番だるい。受け取る側が読む気を失うからだ。Claude Code を使うなら、最後にやるべき仕事は修正の上積みではない。最終要約、つまり成果物の圧縮だ。引き継げる形に整えて初めて、作業は終わる。 ここでいう「まとめ直し」は、長い説明を短くするだけではない。何をやったか、何が変わったか、残っている懸念、次に誰が触るべきかを、読み飛ばされにくい順番で並べ直す作業だ。ファイル整理でも、文書作成でも、コード修正でも効く。雑に散ったメモを、そのまま渡せる状態にする。これができると、やり直しが減る。 Claude Code に頼むときは、最初から「要約して」とだけ投げないほうがいい。あれは短くなるだけで、引き継ぎやすくはならないことがある。要点の選び方まで指示したほうが、あとで使える形になる。 たとえば、作業ディレクトリの内容を最後に整理したいなら、こう頼む。 ```bash Claude Code にこう依頼する： このフォルダ内の作業内容を、引き継ぎ用の最終要約にまとめてください。 次の順で出してください。 1. 何をやったかを3〜5行

「短くして」とだけ投げると、返ってくる文量が妙にぶれる。そこを曖昧にしたままだと、Claude Code は空気を読んでいるようで読んでいない。なら最初から上限を切る。短文指定、出力量の制御は、だいたいここで効く。 Claude Code で要点だけ欲しい場面は多い。たとえば、変更内容を一言で説明してほしいとき、長いログから異常だけ拾いたいとき、整理メモを作りたいときだ。こういうときに「短めで」と頼むだけでは弱い。短めの感覚は人によって違うし、モデル側にも余地が残る。だから、返答の長さを「感覚」ではなく「上限」で縛る。 いちばん手堅いのは、文字数か行数で切るやり方だ。たとえばこう書く。 ```text この内容を要約してください。3行以内で、箇条書きは2点まで。 ``` ```text 変更点を説明してください。120字以内で。 ``` ```text 不要ファイルの整理方針を、見出しなしで5行以内にまとめてください。 ``` この頼み方のいいところは、Claude Code が余計な前置きや保険文を足しにくくなる点だ。「短く」とだけ言うと、結局は小見出し付きのミニ解説が返ってきたりす

「とりあえず答えて」で始めると、あとで整形し直す羽目になる。Claude Code でもここは同じで、返答の形を先に固定するだけで手戻りがかなり減る。出力形式の指定、返答フォーマットを先に渡しておく、というやつだ。 たとえば、作業メモを整えたいのに段落だらけの文章が返ってくると、結局こちらで見出しを切り直すことになる。逆に、最初から Markdown で返させれば、見出し、箇条書き、コードブロックがそのまま使える。表が欲しいなら表に寄せる。ここを曖昧にしたまま進めるのは、箱を開けてから「やっぱりこの棚は縦じゃなく横だった」と言っているようなものだ。 Claude Code に頼むときは、まず使い道を一言で言い切る。そのうえで、返答形式を最初の条件として置く。たとえばこうだ。 ```text この作業はMarkdownで返してください。見出しは h2 相当、要点は箇条書き、最後に次の作業だけ短く書いてください。 ``` 表で欲しいなら、最初からそう言う。 ```text この内容は表で返してください。列は「項目」「内容」「補足」の3つで固定し、余計な前置きは不要です。 ``` フ

Claude Code でいちばん無駄なのは、もう変わった前提を延々と引きずることだ。昨日まで有効だった指示を、そのまま今日も抱え続けると、会話は静かに濁る。出力がズレる、修正が増える、diff が太る。地味だが、かなり痛い。 ここで効くのが、指示の更新と前提の再提示だ。要するに、「前に言ったこと」を神聖視しないで、状況が変わったら言い直す。Claude Code は長い文脈を読めるが、だからこそ古い前提をそのまま残すと、昔の依頼に引っ張られる。ファイル整理でも、文書作成でも、コード修正でも同じである。 たとえば最初は「このフォルダの重複画像を探して」と頼んだのに、途中で「いや、削除はしないで一覧だけ出して」と方針が変わったとする。このときに「さっきの続きで」などと曖昧に流すと、Claude Code は削除前提のまま手を動かし続けることがある。ちゃんと、いったん前提を上書きするのが正解だ。 実際の頼み方は、短くていい。むしろ短いほうが強い。前提を明示して、古い指示は捨てると書く。 ```text 前提を更新します。ここからは「削除しない」が正しい前提です。 重複候補は一覧だけ出してく

黙って最後まで走らせて、あとで「あれ、思っていたのと違う」が出る。Claude Code でもこれをやると、地味に痛い。 進捗報告、報告間隔を先に決めておくだけで、その手戻りはかなり減る。 Claude Code は、こちらが待っている間も延々と考えたり、ファイルを見たり、差分を積んだりできる。だからこそ、途中報告の頻度を先に決めておくのが効く。短い作業なら最後まで黙っていてもいいが、少しでも長引くなら、どのくらいの間隔で止まって報告するかを最初に渡しておくべきだ。これを怠ると、手元では静かでも、裏では見当違いの方向に寄っていき、最後にまとめて修正する羽目になる。 たとえば、最初の依頼文にこう書く。 ```text この作業は途中報告を入れながら進めてください。 ひと区切りごとに、今やったこと・次にやること・迷っている点を短く報告してください。 報告間隔は、作業の節目ごと、または10分ごとを目安にしてください。 大きく方針が割れそうなら、その場で止まって確認してください。 ``` ここで大事なのは、「途中で報告して」で終わらせないことだ。 それだと、Claude Code 側はどこで止

長い指示を一気に投げて、そのまま走らせる。これ、Claude Code でいちばん手戻りが増えるやり方だ。 途中で前提がズレていても、最後までそれっぽく進んでしまうのが厄介で、気づいた時には diff が太っている。そこで効くのが途中要約、つまり節目要約だ。節目ごとに「ここまでの理解」を短く言わせるだけで、ズレを早めに止められる。 Claude Code は、長い作業ほど文脈を食う。しかも人間側は「この辺で分かっているはず」と思いがちだ。だが、分かっていないまま進むことは普通にある。 要約を挟む目的は、きれいな文章を作ることではない。こちらの意図、前提、制約、残っている論点を、途中で一回棚卸しさせることだ。 たとえば、フォルダ整理でも文書作成でも同じだ。最初に雑に「整理して」「読みやすくして」と言うと、Claude Code は広く解釈する。悪気はない。むしろ素直すぎる。だから節目で止める。止めて、今どこをどう理解しているかを返させる。そこで違和感があれば、その場で直す。 実際の頼み方はこうだ。作業の最初に、途中要約のタイミングを指示しておく。 ```text この作業は段階ごとに進め

長い依頼文を一発で投げると、たいていろくなことにならない。Claude Code は賢いが、材料の山をそのまま渡せば、要点がぼやけるし、余計なところまで気を取られる。だから使うのは分割投入、つまり長文の小分けだ。 やることは単純で、長い案件文書や仕様書、整理したいフォルダの事情を、章ごとに分けて渡す。いきなり全部貼らずに、「背景」「やりたいこと」「制約」「確認したい点」を別々に処理させる。これだけで、返ってくる文章の精度がかなり変わる。ファイル整理でも同じで、巨大な一覧を丸ごと食わせるより、まず重複候補だけ、次に古いものだけ、最後に残す条件だけを渡したほうが事故りにくい。 筆者は最初、議事録の原稿を長文のまま貼って「要約して」と頼み、見出しの粒度が崩れて手戻りしたことがある。全文に対して一気に指示すると、どこが重要なのかの優先順位が曖昧になる。人間でも、20ページの資料を一度に読んで的確に直すのはだるい。同じことだ。 実際のやり方は、こんな形で十分だ。 ```text まず、次の材料はまだ要約しないで受け取ってください。 第1章: 背景 第2章: 現状の問題 第3章: 直したいこと 受

長い依頼をそのまま投げて、Claude Code が途中でズレる。これ、かなりありがちな失敗だ。 依頼の分割、作業の切り分けを先に入れておくと、指示の抜けや解釈違いが目に見えて減る。しかも、やり直しが起きたときの損失も小さい。長文を一発で飲み込ませる前提そのものを捨てたほうがいい。 Claude Code は、長い文章を雑に「読んでくれる」道具ではない。作業を進める相手だ。だから、最初に区切りを入れて、何を先に理解してほしいのか、何を後回しにしていいのかをはっきりさせる。これだけで、コンテキストの浪費がかなり減る。 筆者も昔、変更したいファイルの背景説明から制約から希望する書き味まで、全部を一度に貼って失敗したことがある。返ってきた内容は間違っていないのに、欲しい順番ではなかった。結果、後半の条件を見落としたまま作業が進み、差分を戻してやり直す羽目になった。あれは完全に、依頼文を一気読み前提にしたこちらの負けだ。 やることは単純だ。最初に依頼を三つくらいに切る。 たとえば、まず「何をしたいか」を渡す。次に「触っていい範囲」を渡す。最後に「出力の形」を渡す。これだけで十分な場面は多い。

「あとで見返せばわかる」と思って、肝心な迷い方を残していない。これがいちばんもったいない。Claude Code は作業を進める道具としては強いが、勝手に次回のための教材まで整えてくれるわけではない。だからこそ、作業ログの確認、つまり振り返りを一手間足して、迷った地点を拾い上げておくと効く。 この TIPS の狙いは、作業が終わったあとに「何をしたか」を眺めることではない。どこで詰まり、どの指示が曖昧で、どの切り分けで前に進んだかを回収して、次の依頼文にそのまま埋め込める形にすることだ。これをやると、同じ迷子を何度もやらなくて済む。特に、ファイル整理、文書作成、不要ファイルの洗い出しみたいな用途では、作業の“正解”より“迷い方”のほうが再利用しやすい。 まずやることは単純だ。Claude Code に任せた作業を終えたら、その場でログを見返し、迷った瞬間だけ抜き出す。全部読む必要はない。雑に全部読むと、ただの記録で終わる。見るべきなのは、こちらが何を曖昧に頼んだか、Claude Code がどこで確認を返したか、こちらがどの追加条件を後出ししたか、の三つだ。 たとえば、書類整理の案件で