この記事はすきま経営からの転載です。

Claude Codeで業務自動化をやるとき、何を任せて何を人が握るか。私はこの1か月、ブログ・Threads・Xの運用という定型業務を、Claude Codeのセッションにほぼ丸ごと任せて回してきた。リポジトリの初コミットが2026年8月8日、この記事を書いている9月11日までにマージしたPRは254本、記事の原稿は110本、Claude Codeに固定手順として渡しているSkillは10個、GitHub Actionsのワークフローは15本ある。私がやっているのは「マージした」「公開GO」「その数字は違う」と返すことで、手を動かす作業のほとんどはClaude Code側にある。

この記事では、コードを書く話ではなく「定型業務をAIに任せる」ときの設計を書く。結論から言うと、うまく回るかどうかを決めたのはAIの賢さではなく、任せる範囲を先に線引きしたことと、AIの報告を信用しない歯止めを仕組みに埋めたことの2つだった。

任せている定型業務の中身

対象にしたのは、毎日・毎週必ず発生するが判断の型が決まっている作業だ。

ブログ記事の執筆・タイトルの検索語寄せ・WordPressへの同期・内部リンクの整備
Search Consoleの実測を毎週取得し、順位11〜20位の記事を押し上げ候補として抽出する
Threads・Xの投稿案の量産、品質チェック、予約登録、投稿頻度の監視、リプライ対応
Zenn・Qiitaへの転載と、配信の失敗時の復旧
これらの実施記録を残し、効果判定の期日を管理する

たとえばこの記事を書いている日は、既存記事21本のタイトル・メタ・冒頭を狙う検索語に寄せて本番に同期し、新規記事を1本書き、本番サイトでSEOタグが二重出力されている問題を見つけて修正し、転載の配信が途中で止まる不具合をワークフローの分解で直した。私が入力した文字数より、Claude Codeが読んだファイルの行数の方が桁で多い。

任せる範囲は「絶対ルール」で先に線を引く

最初にやったのは、リポジトリ直下のCLAUDE.md（Claude Codeが毎回読む指示ファイル）に、破ってはいけない線だけを書くことだった。今は6項目ある。

mainへの直pushは禁止、すべてPR経由でマージは人が行う
mainへのマージは自動公開（Zenn・Qiita）なので、PR本文に公開への影響を必ず書く
WordPressの公開（publish）は人の明示的なGOが必要。下書きまでが既定
原稿にタスク番号を書かない
シークレットは.envとsecrets/にしか置かない。値をコマンド出力・原稿・コミットに出さない
守秘義務。クライアント名や特定できる要素は書かない

ポイントは「やっていいこと」を列挙していないことだ。やっていいことを列挙すると、列挙にない作業が出るたびに人が判断する必要があり、任せた意味がなくなる。逆に「外に出る瞬間」（公開・配信・シークレット・守秘）だけを人が握ると決めると、それ以外はAIが自走できる。

この線引きは効いた。1か月で公開されたものはすべて私がGOを出したものだけで、シークレットが原稿やログに漏れたことは一度もない。一方で、線の内側では事故も起きている。それが次の話だ。

歯止め1: AIの完了報告を信用せず、`git diff`で検証する

一番大きい学びは、AIの「やりました」は事実ではなく報告であるということだ。

サブエージェント（Claude Codeが並列で立てる作業用のセッション）に記事のリライトを任せたとき、「完了しました」と報告が来たのにgit statusを見ると変更が1行もなかったことがある。以後、サブエージェントの報告は必ずgit statusとgit diff --statの実出力を貼らせ、親セッションがそれを再実行して照合するルールにした。この記事の日にリライトした21本も、3つのサブエージェントに分けて任せ、それぞれの報告の末尾に実出力を付けさせている。

自動化の判定ロジックでも同じことが起きた。投稿頻度を毎朝チェックするcronが失敗せず動き続けていたのに、実は日付の正規表現がスラッシュ区切り専用で、実データはハイフン区切りだったため一度もマッチしておらず、「0投稿（不足5件）」を毎日誤報していた。テストはモックデータがスラッシュ区切りで書かれていたので通り続けていた。cronが動いている＝結果が正しい、ではない。 外部データを扱う自動化は、モックのテストが通っても、最低1回は実データで動かして出力を目で見るまで「できた」と言わないことにした。

歯止め2: 記録ファイルを「状態」の正本にし、セッションをまたぐ

Claude Codeのセッションは長くなると文脈が要約され、セッションが変われば記憶はない。だから「今どこまでやったか」「何を判断したか」「次にいつ何を見るか」は、リポジトリ内のMarkdownを正本にしている。

実測記録（記事ごとの表示回数・クリック・判定）
実施ログ（何を・なぜ・いつ判定するか）
投稿の台帳（Google Sheets、APIで読み書き）

これがあると、別の日に別のセッションを立ち上げても「実施ログの末尾にある次回確認予定日」を見るところから始められる。逆にこれが無いと、AIは毎回ゼロから状況を推測して動くので、同じ判断を繰り返したり、判定日を忘れて通過したりする。

副作用として、記録ファイルは複数のPRから同時に追記されるのでコンフリクトが起きやすい。この記事の日だけで3回解消した。追記型（既存の記述を書き換えない）にしても、同じ位置に追記すればぶつかる。今は「記録ファイルに追記を伴うPRは直列にマージする」で運用している。

歯止め3: 判断の基準はSkillに固定する

「この投稿案は75点以上か」「この実測から立てる仮説は何か」のような判断を、その場のプロンプトでやると、セッションごとに基準がぶれる。だから判断の型はSkill（Claude Codeが呼び出せる固定手順ファイル）にした。品質チェックは配点制で機械的に採点し、仮説立案は分析の観点を固定して、棄却済みの仮説を再提案しないようにしている。

Skillにする効果は精度より再現性だ。基準を変えたいときはSkillのファイルを直せばよく、変更がPRとして残る。「あのとき何を基準にしたか」がプロンプトの履歴ではなくファイルの差分で追える。

歯止め4: 並行セッションはworktreeで分け、主ディレクトリは触らせない

定型業務を複数同時に回すので、Claude Codeのセッションを複数立ててgit worktreeで作業ディレクトリを分けている。ここで起きた事故が2つある。

1つは、あるセッションが主ディレクトリで直接ブランチを切り替えて作業し、別セッションが「主ディレクトリは常にmainのはず」と思ってgit reset --hardを実行し、未コミットの作業を巻き込みかけたこと。もう1つは、作業ディレクトリが主ディレクトリに戻っていることに気づかずに同期コマンドを実行し、末尾のrm -f .envで主ディレクトリの.envを消したこと（値は漏れていない、失っただけ）。

どちらもworktreeという仕組みの問題ではなく、「今どこにいるか」を確認しない運用の問題だった。対策は「破壊的操作の前にgit branch --show-currentを出す」「.envは主ディレクトリにしか置かず、絶対パスで参照する」というルールをCLAUDE.mdと手順書に書き、事故の経緯ごと残すこと。ルールだけ書くと、次のセッションは「なぜこのルールがあるか」を知らないまま守るか破るかするので、経緯を残す方が守られる。

歯止め5: 外部サービスの「成功」は自分で確かめる

最後は自動化の出口側。mainにマージすればZennとQiitaに配信される仕組みにしていたが、この記事の日に確かめると、Zennの連携先がリポジトリのリネーム前の名前のままで、3週間分のデプロイが全部失敗していた。Qiitaは公式のGitHub Actionが「投稿→投稿IDのコミット」を一体で行う設計で、連続投稿の上限で途中で止まるとIDのコミットが走らず、次回に重複投稿する構造になっていた。

どちらも「ワークフローが存在する」「以前は動いた」ことを根拠に動いているつもりになっていたものだ。外部サービスへの配信は、配信先の記事数をAPIで数える、ダッシュボードのデプロイ履歴を読む、というところまでを完了条件に含めた。Qiita側は投稿が途中で失敗しても投稿済みIDだけは必ずコミットするようにワークフローを分解した。

任せてよかったこと、任せられないこと

任せてよかったのは、判断の型が決まっていて、量が多く、記録さえ残れば後から検証できる作業だ。21本のリライトを1日で本番に出すことは、私一人では物理的にやらなかった。SEOタグの二重出力のように「気づけば直せるが、気づくために本番のHTMLを読む必要がある」問題も、任せているから見つかった。

任せられないのは、実体験の供給と、外に出す最後の判断だ。このブログは「実際にやったこと・使ったものしか書かない」を原則にしているので、新しい記事の材料は私が話すしかない。AIは書ける文章を無限に作れるが、私が経験していないことを書かせた瞬間にブログの価値がなくなる。公開のGOも同じで、ここを自動化すると絶対ルールが空文になる。

まとめ

Claude Codeで業務自動化をするなら、先に「外に出る瞬間」だけを人が握る線をCLAUDE.mdに引く。やっていいことは列挙しない
AIの完了報告は事実ではなく報告。git diffの実出力、実データでの実行、配信先の実数で検証する
状態は記録ファイルを正本にしてセッションをまたぐ。判断の基準はSkillに固定して再現性を取る
並行セッションはworktreeで分け、破壊的操作の前に現在地を確認する。事故はルールだけでなく経緯ごと残す
任せられないのは実体験の供給と最後の公開判断。ここを残す限り、あとは任せて回る