Claude Codeで業務自動化をやるとき、何をAIに任せて何を人間が握るべきか。
私は自社（Nogawa L.prince合同会社）において、ブログ・Threads・Xの運用という日々の定型業務を、Claude Codeのセッションにほぼ丸ごと任せて回してきました。リポジトリの初コミット（2026年8月8日）から現在までにマージしたPRは580本以上、記事原稿は140本を超え、Claude Codeに固定手順として渡しているSkillは10個以上、GitHub ActionsのCI/CDワークフローは15本以上稼働しています。
私が日常でやっている作業は、PRのレビュー確認、スマホからの「マージ」「公開GO」、そして事実と違う部分へのツッコミだけであり、手を動かす作業の9割以上はClaude Code側が担っています。
この記事の結論（要約）
- 業務自動化の成否は「AIの賢さ」ではなく「任せる範囲の線引き」と「歯止めの仕組み」で決まる：「やっていいこと」を列挙せず、「外に出る瞬間（公開・シークレット・守秘義務）」だけを人間が握り、線の内側はAIを自走させる。
- AIの「完了しました」は事実ではなくただの報告である：
git diffの実出力、実データでの実行、配信先APIでの実数確認など、人間・外部システムによる機械的な検証フローを必ず挟む。- 状態はGit上の記録ファイル、判断基準はSkillに固定してセッションをまたぐ：文脈長制限やセッション分断に対応するため、進行状態と判断ロジックをコードベースに永続化し、属人性を排除する。
適合する読者と限定事項
- この記事が役に立つ人:
- Claude CodeやCursorなどのAIコーディングエージェントを使って、開発だけでなく日々の定型業務（コンテンツ制作、データ集計、SNS運用、監視等）を自動化したいエンジニア・個人開発者
- 「AIに任せたら想定外のファイルを書き換えられた」「完了したと言われたのに動いていなかった」という失敗を経験した人
- 複数セッションを並行させて開発効率を何倍にも引き上げたい人
- 限定事項:
- 本記事はClaude Codeのインストール手順や基本的なコマンド解説ではなく、「実務の運用設計・ガバナンス・エラー防止のアーキテクチャ」に焦点を当てています。
【全体像】人が握る領域 vs Claude Codeに任せる領域
業務自動化を設計する際、最も重要なのが「どこまでをAIに自走させ、どこで人間の承認を挟むか」の境界線です。自社で確立した役割分担マトリクスが以下です。
| 業務フェーズ | 人間（オーナー）が握る領域 | Claude Code（AIエージェント）に任せる領域 | 設置している関門・歯止め |
|---|---|---|---|
| 企画・意思決定 | 一次情報（実体験・実データ）の提供、事業方針の決定 | 過去ログ分析、サジェスト需要調査、リライト候補の抽出 | 憶測や架空の体験の記述禁止 |
| 制作・実装 | PR概要と変更理由の確認、レビュー | 原稿執筆、コード修正、テスト作成、比較表・フロー図の作成 | CIによる自動リント・リンク整合性検査 |
| テスト・検証 | 最終的な目視確認（必要時） | content-checks.sh、ビルド確認、git diff検証 |
空コミット・未実行報告の自動検知 |
| 本番公開・外部配信 | PRマージ、本番公開（publish）の明示的GO | 下書き投稿（draft）、API同期スクリプトの実行 | main直pushブロック、公開ゲート7項目 |
| 監視・継続判定 | 施策の継続・撤退の意思決定 | Search Console実測取得、週次台帳更新、アラート検知 | 判定予定日の台帳自動トラッキング |
この表の通り、「コードを書く」「原稿を推敲する」「テストを走らせる」という実作業はAIが99%自走しますが、「外部に公開される瞬間（PRマージ・本番公開）」の決定権だけは人間が100%握るという非対称な構造にしています。
任せる範囲は「CLAUDE.md」の絶対ルールで線を引く
最初にやったのは、リポジトリ直下の CLAUDE.md（Claude Codeがセッション開始時に必ず読み込むシステム指示ファイル）に、**「破ってはいけない境界線」**だけを定義することでした。
現在定めている絶対ルールは以下の6項目です。
- mainへの直push禁止。すべての変更はPR経由（マージは人間が行う）
- mainへのマージ＝自動公開: 変換成果物（Zenn/Qiita）への即時配信があるため、PR本文に公開への影響を必ず明記する
- 本番公開（status: publish）は人間の明示的なGOが必要。下書き（draft）投稿までが既定
- 原稿・ファイルにタスク管理のissue番号を書かない（リポジトリの可読性・独立性を担保）
- シークレットは
.env・secrets/のみ（gitignore済み）。値をコマンド出力・原稿・コミットに出さない - 守秘義務: クライアント名・特定可能要素は書かない。実体験は複数案件を合成して抽象化する
なぜ「やっていいこと」を列挙してはいけないのか？
業務マニュアルを作るとき、「やっていいこと（許可リスト）」を細かく書きたくなります。しかしAIエージェントの運用において許可リスト方式を採用すると、リストに書かれていない新しい状況に直面するたびにAIが停止し、人間への確認が発生して自走できなくなります。
逆に、「外に出て取り返しのつかない事故になる瞬間（本番破壊、情報漏洩、無断公開）」だけを禁止ルール（禁止リスト）としてガチガチに固めると、その線の内側であればAIは自律的にあらゆる工夫をして最速でゴールへ到達できます。
この線引きを徹底した結果、PR580本以上の運用を経ても、シークレット漏洩や意図しない無断公開といった重大インシデントはゼロを維持しています。
AIの暴走・誤報を防ぐ「5つの歯止め」
しかし、禁止ルールを決めただけでは事故は防げません。Claude Codeを実際に運用して直面した生々しい失敗と、それを防ぐために組み込んだ「5つの歯止め」を解説します。
flowchart TD
subgraph 5つの歯止め
H1["1. 報告を信用せず git diff で機械検証"]
H2["2. 記録ファイルを正本にしてセッション越境"]
H3["3. 判断ロジックをSkillに固定化"]
H4["4. 並行作業を専用worktreeで物理分離"]
H5["5. 外部配信はAPI実数で検証"]
end
H1 --> SafeOps["安全かつ自律的な業務自動化"]
H2 --> SafeOps
H3 --> SafeOps
H4 --> SafeOps
H5 --> SafeOps| 歯止め | 直面した事故・リスク | 導入した対策・実装 |
|---|---|---|
| 1. 報告の機械検証 | 「完了しました」と報告されたが、実は1行も変更されていなかった | git diff --statの実出力を必須化し、差分がなければ完了とみなさない |
| 2. 状態の永続化 | セッションが切れると前回の進捗や次回確認期日を忘れる | content-tracking.mdなどのMarkdown台帳を正本にし、セッション開始時に参照 |
| 3. 判断のSkill化 | プロンプトのブレで、同じ投稿案でも採点基準や仮説が日によってブレる | 検査・採点・分析のロジックをリポジトリ内のSkill（手順書）にコード化 |
| 4. worktree分離 | 複数セッションが主ディレクトリで競合し、未コミット変更を巻き込みかけた | セッションごとに .claude/worktrees/ 配下でブランチを完全分離 |
| 5. 配信先の実数確認 | CIは「成功」と出ているのに、外部連携先の設定不備で全滅していた | ワークフロー完了後に、配信先APIやcurlで実コンテンツの存在を確認 |
歯止め1: AIの完了報告を信用せず、git diffで検証する
一番大きな学びは、**「AIの『やりました』は事実ではなく、ただの推論結果の出力である」**ということです。
サブエージェント（並行作業用に起動したセッション）に記事のリライトを任せた際、「指示通り修正を完了しました」と自信満々に報告が上がってきたにもかかわらず、git status を確認するとファイルが一切変更されていなかったことがあります。
また、外部連携の監視cronが毎日「正常終了」を出していたのに、日付判定の正規表現が実データと不一致で、実際には1回も判定ロジックが走っていなかったという事故もありました。モックテストは通っていても、実データで動いていなかったのです。
この教訓から、以下のルールを徹底しました：
- 完了報告には必ず
git statusとgit diff --statの実出力を貼らせる - モックだけでなく、最低1回は実データを通した出力結果を目視・検証するまで「完了」と認めない
歯止め2: 記録ファイルを「状態」の正本にし、セッションをまたぐ
Claude Codeのセッションは、コンテキスト長の上限に達すると過去のログが要約（コンパクション）されます。また、翌日新しいセッションを立ち上げれば、前日の会話の細部はリセットされます。
そのため、「いまどのタスクが進行中か」「誰が何を判断したか」「次回はいつ効果測定するか」をAIの会話履歴に依存させてはいけません。
自社では、すべての状態をGit上のMarkdownファイルに記録しています：
blog/content-tracking.md: 全記事の公開日、初期実測値、施策履歴、判定予定日blog/content-tracking-log.md: 押し上げ施策やリライトの実施詳細ログ- スプレッドシート（API連携）: SNS投稿の予約枠と未予約在庫
これにより、どれだけ会話が途切れても、新しいセッションは**「記録ファイルの末尾の期日」を読むだけで、1秒で直前の文脈に完全復帰**できます。
歯止め3: 判断の基準は「Skill」に固定する
「この投稿案は品質基準を満たしているか」「このSearch Console実測からどんな改善仮説を立てるべきか」といった判断を、会話ごとの自然言語プロンプトで指示していると、セッションごとに基準がブレます。
そこで、判断基準はすべてリポジトリ内の Skill（.agents/skills/） として固定化しました。
- 採点基準（配点テーブル、足切り条件）を明文化
- すでに検証・棄却された過去の仮説を再提案しないロジックを定義
- ルールを改定する際は、Skillファイルを編集してPRを作成
プロンプトの属人性を排除し、判断基準そのものを「コード」としてバージョン管理することで、常に誰が動かしても同じ75点以上の品質を再現できるようにしています。
歯止め4: 並行セッションはworktreeで分け、主ディレクトリは触らせない
定型業務を複数並行で回すため、複数の作業セッションを同時に起動し、git worktree でディレクトリを物理的に分離しています。 ここで過去に起きたのが、**「あるセッションが主ディレクトリでブランチを切り替えて作業し、別セッションが主ディレクトリを常にmainだと思い込んでリセット操作を行い、作業を巻き込みかけた」**という事故でした。
これを防ぐため、以下の運用を機械的に義務付けました：
- 作業ブランチは必ず
.claude/worktrees/<name>/配下の専用worktreeで作成する - 主ディレクトリ（リポジトリルート）は
mainのgit pull --ff-only以外には絶対に使わない - 破壊的操作（
git reset等）の直前には、必ずgit branch --show-currentで現在地を明示確認する
歯止め5: 外部サービスの「成功」は自分で確かめる
自動化の落とし穴として多いのが、**「GitHub Actionsの緑のチェックマーク（success）を見て安心してしまう」**ことです。
実際にあった事故として、リポジトリ名をリネームした際、Zenn連携の設定更新が漏れており、CIは正常終了しているのに実際には3週間分すべてのデプロイが配信先で失敗していたことがありました。
「ワークフローがエラーを出さずに終了した」ことと、「外部サービスにコンテンツが正しく反映された」ことは全く別物です。 現在では、WordPressへの同期なら curl でHTTP 200とタイトル文字列を叩いて確認し、SNS予約ならAPIでステータスを確認するまでを完了条件として定義しています。
任せてよかったこと、絶対に任せてはいけないこと
任せて圧倒的に良かったこと
- 「判断の型」が決まっている大量処理:
- 10位台記事のクエリ分析とリライト（1日20本規模の集中改定）
- 全記事のリンク切れ・相対パスの整合性一括チェック
- スプレッドシートとGit台帳の差分集計と整合確認
- こうした作業は、人間がやると集中力が切れてミスが多発しますが、AIエージェントは歯止めさえあれば1ミリのブレもなく高速で完遂します。
絶対に任せてはいけないこと
- 一次情報（実体験）の供給:
- AIは「もっともらしい文章」を無限に生成できますが、実際に体験していないことを書かせた瞬間に、コンテンツの独自性と信頼性は死にます。「何をやったか」「どこで失敗したか」の生データは、必ず人間が口頭やメモで渡さなければなりません。
- 最後の公開（Go / No-Go）の判断:
- 本番へのデプロイやマージボタンを押す責任をAIに委譲してはいけません。ここを手放すと、事故が起きたときの原因究明も修正もできなくなります。
まとめ：自社のClaude Code運用を見直す4つのチェック
Claude Codeによる業務自動化を成功させるための要点はシンプルです。
- 境界線の定義: 「やっていいこと」ではなく「絶対に破ってはいけない線（公開・秘匿情報）」だけをCLAUDE.mdに書いているか？
- 報告の検証: AIの「完了しました」を鵜呑みにせず、
git diffや実データで機械的に検証しているか？ - 状態と判断の永続化: セッションが切れても復旧できるよう、進捗はMarkdown台帳に、判断基準はSkillに固定しているか？
- ワークツリーの分離: 複数作業を並行させる際、主ディレクトリを汚さず専用worktreeで隔離しているか？
「AIに全部やらせる」でも「AIを信用しない」でもなく、「人間が境界線と検証の仕組みを作り、その中でAIを全力で自走させる」。このアーキテクチャこそが、1人法人を何倍もの馬力にスケールさせる本質です。
