毎回同じ名前でフォルダを掘って、同じ文言で文書を整えて、同じゴミを消しているなら、もう人間がやる仕事ではない。そこを Claude Code に渡すと、作業そのものよりも「抜け漏れを気にしている時間」がごっそり減る。
Claude Code は、指示された処理を実行する CLI のコーディングエージェントだ。コードを書くためだけの道具だと思われがちだが、実際にはファイル整理、レポート生成、命名の統一、不要ファイルの洗い出しみたいな定型作業にもかなり使える。要は、手で何度もやっていた手順を、毎回同じ形で再現させればいい。
ただし、ここで雑に「このへん片付けて」と投げると、だいたい薄い返答が返る。筆者も最初はそのやり方で何度か手戻りした。理由は単純で、作業の目的と入力と出力が曖昧だと、エージェントは余計な確認にコンテキストを食うし、こちらも差し戻しに時間を取られるからだ。定型作業のスクリプト化は、気合いではなく設計で決まる。
まずやることは、作業を「手順」に分解することだ。Claude Code に任せたいのは、漠然とした片付けではない。たとえばこういう粒度に落とす。
このとき大事なのは、「何を入力にするか」「何を出力にするか」「どこまで自動でやるか」を先に決めることだ。ここを飛ばすと、作業がブレる。しかもブレた分だけ、Claude Code とのやり取りが増える。手作業を消したいのに、チャット往復が増えたら本末転倒だ。
たとえば、案件フォルダを毎回同じ形で作りたいなら、最初からそのルールを文章にして渡す。こんな感じで十分だ。
次のルールで新規案件フォルダを作るスクリプトを書いてください。
- ベースディレクトリは ./cases
- 入力は案件名と日付
- 案件名はファイル名に使える形に整える
- 作成するのは以下の構成
- 01_notes
- 02_materials
- 03_output
- README.md を1つ作り、案件名と日付を入れる
- 既存フォルダがあれば上書きしない
- 実行前に作る内容を表示し、確認してから実行する
完成物は bash スクリプトでお願いします。
これだけでもかなり違う。曖昧な「フォルダを作って」ではなく、命名ルール、階層、上書き禁止、確認フローまで指定しているからだ。Claude Code に必要なのは、才能のある指示文ではない。迷わない指示文である。
文書作成でも同じだ。たとえば毎週の報告書、議事録、申請書のたたき台みたいな定型文は、手で整えるほど無駄が出る。Claude Code には、既存のテンプレートを読ませて、差分だけ埋める仕事をやらせればいい。
reports/ 配下の markdown ファイルを読み、各ファイルの見出し構造をそろえてください。
条件:
- 見出しは「概要」「対応内容」「未完了」「次回対応」に統一
- 各ファイルの本文は意味を変えずに整理する
- 言い回しは簡潔にする
- 事実が書かれていない箇所は勝手に補完しない
- 変更後は diff を確認できるようにする
ここで重要なのは、「勝手に補完しない」と明記することだ。Claude Code は雑に任せると、もっともらしい文章を整えてしまうことがある。文章の読みやすさは上がるが、事実が増えるわけではない。定型作業で怖いのは、きれいに見える誤情報だ。これがいちばんだるい。
ファイル整理やディスク削減でも、考え方はまったく同じだ。たとえば大きなダウンロードフォルダを片付けたいなら、消す前に一覧を出させる。いきなり削除させるのは乱暴すぎる。まずは候補を見て、こちらが判断する。
Downloads フォルダを整理したいです。
やってほしいこと:
- 30日以上触っていないファイルを候補として一覧化する
- 拡張子ごとに分類する
- 重複しそうな名前のファイルをまとめる
- 削除はしない
- 最後に、残すべきものと消してよさそうなものを分けて提案する
結果は markdown で出してください。
このやり方の利点は、結果が説明可能になることだ。なぜそのファイルを候補にしたのか、あとで追える。手でやると、つい勢いで消してしまって「これ、何だったっけ」となる。筆者はこのパターンで一度、下書きの原稿と最終版の区別を見失い、別ファイルとして残すべきものをまとめて動かしてしまった。整理のつもりが混乱を増やす、よくある失敗だ。自動化の前に、まず確認ステップを挟めば防げる。
実際の運用では、いきなり大きなスクリプトを作るより、小さく始めるほうが強い。最初から「全部やる」道具にしない。まずは一つの定型だけを切り出す。命名変更、一覧化、テンプレ差し込み、不要ファイル検出。このくらいの単位がちょうどいい。小さく作ると、失敗しても直しやすいし、Claude Code に渡す指示も短くなる。
スクリプト化するときは、出力の保存先も決めておくといい。たとえば、実行ログや生成した一覧を別ファイルに残す。あとから見返せるだけでなく、同じ作業を次回に流用しやすい。人間が毎回ゼロから思い出すより、ログを見て再現したほうが早い。
実行結果は次の形式で残してください。
- 作業ログ: ./logs/YYYY-MM-DD-task.log
- 変更一覧: ./logs/YYYY-MM-DD-changes.md
- 実行前の確認: まず dry run 相当の出力を表示する
ここで気をつけたいのは、Claude Code に「何をしてよいか」と「何をしてはいけないか」を両方書くことだ。特に削除や上書きは、確認なしでやらせない。定型作業は速いほうがいいが、速さは慎重さを雑に捨てる理由にはならない。
もう一つ、地味に効くのが「既存のルールを先に読ませる」ことだ。プロジェクト内に命名規則、フォルダ構成、文書テンプレートがあるなら、それを参照させてから作業させる。ルールを無視して新しい流儀を生むのが、エージェント系のありがちなズレだ。そこを止めるだけで、やり直しがかなり減る。
以下のファイルを先に読んで、既存ルールに従ってください。
- README.md
- docs/style-guide.md
- templates/report.md
そのうえで、weekly_reports/ 配下のファイルを同じ書式にそろえてください。
この一手間は面倒に見えるが、後で効く。定型作業の本質は、毎回の判断を減らすことだ。だからこそ、判断基準を人が持ち、実行を Claude Code に渡す。ここを逆にすると、毎回その場の空気で作業することになって、結局また手作業へ戻る。
応用するなら、単発のスクリプトではなく、よくやる処理を「作業メモ」として残しておくといい。たとえば「案件ごとのフォルダ作成」「月末の資料整理」「古いキャッシュの棚卸し」「議事録の整形」みたいに、繰り返す作業を並べておき、その都度 Claude Code に再利用させる。毎回同じ指示をゼロから書く必要はない。
定型作業をスクリプト化するコツは、賢く見せることではない。迷わせないことだ。入力、出力、禁止事項、確認方法。この四つを固めれば、手でやっていた時間はかなり消える。雑な一回を減らすだけでなく、二回目、三回目が速くなる。そこがいちばん効く。