#claude-code-workflow

人は、自分で直したコードや片づけたファイルをいちばん雑に見てしまう。見たつもりで見落とすし、「たぶん合ってる」で突っ走る。Claude Code を使う場面でも、ここが一番まずい。 この手の失敗は、派手なバグより地味に痛い。ファイル整理なら不要データを残したまま「空いた気になる」。文書作成なら、参照漏れや表記ゆれを見逃す。開発なら、テストが通っただけで安心して、実は境界条件を壊している。だから Claude Code には「作って」と頼むだけでなく、「自分の作業を疑え」と頼むのが効く。 要は、Claude Code を作業者ではなく、検査役として使う発想だ。しかも、ただ「チェックして」と投げるだけでは弱い。どこを、何と照合し、何をもって問題なしとするかを、先に決めておく必要がある。 一番ありがちな失敗は、作業のあとにこう言うことだ。 ```text これ、確認して。 ``` これでは甘い。Claude Code は広く見られるぶん、広く見て終わる。見る範囲が曖昧だと、確認の密度が下がる。確認役にしたいなら、検証対象をはっきり切るべきだ。 たとえば、コードなら「変更した関数だけ」「テスト

ログを貼らずに「動きません」だけ投げるのは、ほぼ自爆だ。Claude Code に原因切り分けを頼むなら、症状の説明より先に、エラーログをそのまま渡したほうが速い。これは開発作業でも、ファイル整理でも、書類の自動生成でも同じである。曖昧な依頼は、余計なやり取りを増やしてコンテキストを食い、最後に「それ、最初に出してくれれば済んだのに」になる。 Claude Code は、端末上で見えているエラー文や関連ファイルを手がかりに、何が壊れているかをかなり実務的に絞れる。だが、こちらの頼み方が雑だと、関係ない方向を見始める。筆者も最初は「なんか失敗する」で投げて、延々と見当違いの説明を掘らせたことがある。ログを最初から貼っておけば、あの無駄な往復はかなり減ったはずだ。 まず、頼み方の基本形はこれでいい。 ```text 次のエラーログを読んで、原因候補を優先度順に切り分けてください。 不明な点は、追加で見るべきファイルやコマンドも挙げてください。 推測だけで断定せず、ログから読める事実と推測を分けてください。 ``` これだけでも十分使えるが、実際には少し足したほうが強い。Claude Cod

「直してから確認する」は、だいたい遠回りだ。Claude Code にも同じで、まず壊れるテストを作らせてから、その赤を消す形でコードを直すほうが、手戻りが少ない。 このやり方の良さは単純だ。何を満たせばいいかが先に固定される。しかも、Claude Code が勝手に話を広げにくい。いきなり実装をいじらせると、見た目は動いても境界条件を落とすことがある。先に失敗するテストを書かせれば、「何を守るべきか」をコードより先に置ける。 筆者も最初は、仕様を口で説明してそのまま直させていた。すると、動くけれどテストが増えない。次に同じ不具合が出たとき、また同じ説明を繰り返す羽目になる。そこで先にテストを書かせるようにしたら、会話の焦点が一気に締まった。曖昧な依頼が減るし、差分も追いやすい。かなり地味だが、効く。 やり方はこうだ。Claude Code に最初から「壊れているテストだけを作れ」と頼む。実装はまだ触らせない。たとえば Python なら pytest、JavaScript なら既存のテストランナーに合わせて書かせる。非エンジニアが文書整理やファイル整理に使う場合でも同じで、たとえば「

「壊れてるから直して」で投げると、だいたい遠回りになる。Claude Code みたいなCLIエージェントは、雰囲気で当てるより、再現できる条件を渡したほうがずっと強い。 バグ修正で本当に効くのは、症状の説明を増やすことではない。再現手順を切り分けて、同じ失敗をもう一度起こさせることだ。そこまでできれば、Claude Code はログやコードを追いやすくなるし、修正後の確認まで一気通貫で進められる。逆に、あいまいな「なんか動かない」は、コンテキストを食うだけ食って、外す。筆者も最初はこれで手戻りした。変更箇所を広げすぎて diff が膨らみ、直したいバグより副作用の確認に時間を取られた。あれはだるい。 まずやることは単純だ。Claude Code に「原因を探して」と丸投げする前に、こちらで再現条件を短く固める。たとえばこうだ。 ```text 次の不具合を再現してから修正してほしい。 症状: ファイル名に日本語が入っていると、出力先のリネームが失敗する 再現手順: 1. sample/ に「議事録 2024-01.txt」を置く 2. そのファイルを対象に変換コマンドを実行する 3.

毎回同じ名前でフォルダを掘って、同じ文言で文書を整えて、同じゴミを消しているなら、もう人間がやる仕事ではない。そこを Claude Code に渡すと、作業そのものよりも「抜け漏れを気にしている時間」がごっそり減る。 Claude Code は、指示された処理を実行する CLI のコーディングエージェントだ。コードを書くためだけの道具だと思われがちだが、実際にはファイル整理、レポート生成、命名の統一、不要ファイルの洗い出しみたいな定型作業にもかなり使える。要は、手で何度もやっていた手順を、毎回同じ形で再現させればいい。 ただし、ここで雑に「このへん片付けて」と投げると、だいたい薄い返答が返る。筆者も最初はそのやり方で何度か手戻りした。理由は単純で、作業の目的と入力と出力が曖昧だと、エージェントは余計な確認にコンテキストを食うし、こちらも差し戻しに時間を取られるからだ。定型作業のスクリプト化は、気合いではなく設計で決まる。 まずやることは、作業を「手順」に分解することだ。Claude Code に任せたいのは、漠然とした片付けではない。たとえばこういう粒度に落とす。 あるフォルダの中から

それ、途中で画面を見張っているからだるくなるのである。長時間かかる処理は、手を止めて待つより、Claude Code に投げて終わった結果だけ拾う形にしたほうがいい。ファイルの棚卸し、重複の洗い出し、ログの整理、文章の下書き、リポジトリ内の一括確認みたいな作業は、特に相性がいい。 ただし、雑に「これやっといて」で放り投げると、あとで手戻りが出る。筆者は最初、指示を薄くしたまま大きめのディレクトリを一気に見させて、要らないはずのものまで候補に上がってきて差し戻した。人間に丸投げするのと同じで、終わり方を先に決めておかないと、待ち時間だけ増えて得るものが薄くなる。 やり方の基本は単純だ。長い処理を「探索」「判断」「結果の保存」に分けて、Claude Code には判断と保存までやらせる。あなたは途中経過を逐一見る必要はない。最後にファイルや要約ができていればいい。 たとえば、プロジェクト内の不要ファイル候補を洗って、結果をレポートに残したいなら、こう頼む。 ```bash claude ``` 対話を始めたら、指示はこんな感じで十分だ。 ```text このディレクトリ以下を調べて、容量を