#claude-code-workflow

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

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

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

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