#claude-code-claude-code

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

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

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

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

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