Claude Codeで本番環境を運用する｜自宅サーバーの6サイトを一元管理する仕組み

作成日：2026年10月2日 14:46更新日：2026年11月6日 21:54読了時間：約 20 分

「Claude Code」に本番のサーバーを操作させると、コードの修正からログの調査までを任せられる一方で、コマンド 1 つでサイトが止まることもあります。

私は、このサイト（ryusei.io）を含む 6 つのサイトを、自宅のミニ PC 1 台で運用しています。コードの修正から記事の投入、サーバーの管理までを、すべて Claude Code で一元管理しています。本当は開発用の環境を別に用意したかったのですが、メモリやストレージの値上がりでマシンの価格が上がっていたため見送り、本番のサーバーの上で直接 Claude Code を使っています。予算に都合がつけば、開発用のマシンも導入するつもりです。ソースを書き換えるとそのまま本番のファイルが変わる構成なので、事故が起きるたびに、指示ファイルと確認の仕組みを足してきました。

この記事では、そうして足してきた仕組みの全体を説明します。

この記事でわかること

本番のサーバーで使う CLAUDE.md の分け方
危ない操作の前に Claude Code に確認を取らせる方法
無人で実行する Claude Code の権限の絞り方
セッションをまたいで知識を引き継ぐ方法
繰り返す作業の手順を Claude Code のスキルにまとめる方法

Claude Code のインストールや CLAUDE.md の役割といった基本は知っている人を想定しています。自宅サーバーの構築と外部への公開は別の記事で説明しているので、この記事では扱いません。

本番のサーバーで Claude Code を使っている構成

サイトはそれぞれ Docker コンテナで運用しています。閲覧者からの接続は、IPv4 の入口にしている VPS を経由して自宅のサーバーに届きます。

Claude Code での作業は、サーバーで「Remote Control」（claude rc）を常駐させておき、PC の「Claude Desktop」やスマートフォンの Claude アプリからセッションを開いて行っています。同じセッションを PC とスマートフォンのどちらからでも開いて、続きを操作できます。自分でコマンドを実行したいときや、ターミナルでの作業が必要なときだけ、SSH でサーバーに接続しています。

claude rc（Remote Control）とは

claude rc（claude remote-control）は、このマシンで動く Claude Code のセッションを、ブラウザーの claude.ai/code や Claude のアプリから操作できるようにするコマンドです。作業フォルダで実行すると待ち受けの状態になり、別の端末からセッションを開くと、このマシンの上でセッションが起動します。ファイルの読み書きやコマンドの実行はすべてこのマシンで行われ、ほかの端末は画面の表示と入力にだけ使います。

このマシンの側から Anthropic のサーバーへ接続して指示が来るのを待ち、ほかの端末からの指示は、その接続を通って届きます。ほかの端末とこのマシンが直接つながることはなく、外へ向かう HTTPS の通信だけで動くので、ルーターでポートを開放する必要はありません。

利用するには、Pro・Max・Ultra・Team・Enterprise のいずれかのプランのアカウントで Claude Code にログインしている必要があります（Team・Enterprise では、管理者が先に Remote Control を有効にする必要があります）。API キーを設定して Claude Code を使っている場合は利用できません。

既定の --spawn same-dir では、すべてのセッションが同じフォルダで動きます。複数のセッションで同じファイルを同時に編集しないよう注意が必要で、セッションごとに git の worktree を分けたいときは --spawn worktree を使います。SSH で接続して起動したプロセスは、接続を切ると終了してしまうので、私は tmux の中で起動して常駐させています。

PC やスマートフォンの Claude のアプリから Remote Control を経由して Claude Code を使い、作業フォルダをバインドマウントで Docker コンテナに反映している構成図

作業フォルダの構成

Claude Code は、すべてのサイトのリポジトリをまとめた 1 つの作業フォルダで起動しています。作業フォルダ自体も git で管理し、サイトごとのリポジトリや nginx の設定のリポジトリを、サブモジュールとして追加しています。フォルダ名を例示用の名前に置き換えると、次のような構成です。

plaintext

workspace/                ← Claude Code を起動するフォルダ
├── CLAUDE.md             ← 全サイト共通の制約と構成
├── .claude/
│   ├── settings.json     ← このフォルダで起動したときの権限
│   ├── skills/           ← 作業ごとの手順（スキル）
│   └── rules/            ← 特定のファイルを開いたときだけ読む規約
├── docs/                 ← 変更履歴と未解決の課題
├── memory/               ← Claude Code のメモリ
├── site-blog/            ← サイトごとのリポジトリ
│   └── CLAUDE.md         ← そのサイトのコマンドと注意
├── site-tool/
│   └── CLAUDE.md
└── proxy/                ← nginx の設定

各サイトのソースは、サイトごとのフォルダをそれぞれの Docker コンテナにそのまま共有する形（バインドマウント）で配信しているので、Claude Code がファイルを 1 つ書き換えると、本番の Docker コンテナの中のファイルも同時に変わります。Next.js のサイトはビルドし直すまで表示は変わりませんが、ファイルの変更を監視して自動で再起動するプロセスは、保存した時点で再起動します。

動作の確認は Playwright で E2E まで行わせる

サーバーには、ブラウザーをプログラムから操作するツール「Playwright」と「Chromium」をインストールしてあります。Claude Code が修正したあとの動作の確認は、ページを開いて操作し、結果の表示を確かめる E2E の検証まで、このマシンの中で完結させています。記事に載せるスクリーンショットも、同じ仕組みで撮らせています。

検証のためのビルドは、配信中のビルド成果物を上書きしないよう、フォルダを /tmp に複製してから行わせています。画面を確かめるだけなら、本番とは別のポートで開発用のサーバーを起動して開かせることもあります。

自分のサイトを自動で開くときは、広告と計測を止めた状態で開かせています。検証で開いた分が、広告の表示回数やアクセス解析に数えられないようにするためです。

Claude Code に任せていること

作業の種類ごとに、確認なしで任せるものと、実行する前に私の確認を取らせるものを分けています。

作業	確認なしで任せるもの	実行前に確認を取らせるもの
コードの修正	編集・型チェック・リント	本番のビルドと反映
記事	構成・下書き・図解の作成	下書きの内容・公開・有料の画像生成
調査	ログ・アクセス解析・DB の読み取り	—
動作の確認	Playwright での E2E の検証・スクリーンショットの撮影	広告を表示させた状態での検証
サーバーの管理	Docker コンテナとプロセスの状態の確認	本番に影響する操作（後述）
git	—	作業の区切りの commit と push

CLAUDE.md を 3 層に分け、書く内容を 4 種類に絞る

本番で起きた事故を振り返ると、多くはコマンドそのものの誤りではなく、そのコマンドがこの環境で何を引き起こすかという情報が、Claude Code に渡っていなかったことが原因でした。たとえば、型チェックのコマンドを実行したら、「pnpm」が実行前の確認で依存パッケージのずれを検出し、本番の依存パッケージを再インストールし始めたことがあります。.env を直してビルドしただけでは、Docker コンテナの作成時に固定された古い環境変数のまま公開されたこともありました。こうした環境ごとの事情は、CLAUDE.md や規約のファイルに書いて渡すしかありません。

Claude Code は、ユーザー全体の ~/.claude/CLAUDE.md と、起動したフォルダの CLAUDE.md をセッションの最初に読み込み、サブフォルダの CLAUDE.md は、そのフォルダのファイルを開いたときに読み込みます。私はこれに合わせて、CLAUDE.md を 3 つの層に分けています。

層	置き場所	書いていること
ユーザー全体	`~/.claude/CLAUDE.md`	応答の言語、確認の取り方、作業の区切りで commit と push を確認すること
作業フォルダ	作業フォルダの直下	本番であることと確認が必要な操作、サーバー全体の構成、全サイトに共通する規約
サイトごと	各リポジトリの直下	そのサイトのコマンド、データと設定の正本の場所、そのサイトだけの注意

書く内容を 4 種類に絞る

一時期、CLAUDE.md が全部で 2,090 行になっていました。作業が終わるたびに、経緯や実測値まで CLAUDE.md に書き足していたのが主な理由です。そこで、CLAUDE.md に書くものを次の 4 種類に限り、全ファイルを見直して 940 行まで減らしました。

破ると事故になる制約と、何が起きるかの 1 行
データ・設定・生成物の正本の場所
毎回使う手順とコマンド
詳しいドキュメントへのポインタと、それをいつ読むか

経緯や実測値、試して駄目だった案は変更履歴のファイルに、まだ直していない問題は未解決の課題のファイルに書かせています。1 項目は 3 行以内とし、迷ったら「次のセッションでも毎回必要か」で分けることも、CLAUDE.md 自体に書いてあります。

特定のファイルを開いたときだけ読ませる規約

nginx の設定の手順のように、特定のファイルを触るときにだけ必要な規約は、作業フォルダの .claude/rules/ に置いています。ファイルの先頭に paths を書くと、そのパターンに一致するファイルを開いたときだけ読み込まれます。

markdown

---
paths:
  - "proxy/conf.d/**"
  - "proxy/nginx.template.conf"
---

# nginx の設定を変える前に読むこと

- nginx.conf は生成物なので直接編集しない。テンプレートを直して生成し直す
- 設定の反映（reload）は、実行する前に確認を取る

規約が読み込まれるのは、Claude Code が「Read」「Write」「Edit」のツールでファイルを扱ったときと、Bash の cat や sed で 1 つのファイルを読んだときです。私の環境で試したところ、cat の出力を head にパイプでつないだ場合は読み込まれませんでした。規約の本文に @ でほかのファイルを取り込むと、その部分はファイルを開く前のセッションの開始時に読み込まれるので、読み込みを遅らせたい内容は本文に直接書いています。

私は、毎回は必要ないものの、読み落とすと事故になる規約をここへ移しています。ただし、読み込まれるきっかけはファイルを開くことに限られるので、Docker コンテナの再起動のように、ファイルを開かずに行う操作の前の注意は、CLAUDE.md の本体に残しています。

危ない操作の前に Claude Code に確認を取らせる

CLAUDE.md に書いた禁止事項は、必ず守られるわけではありません。そのため、確認が必要な操作を CLAUDE.md に書くだけでなく、確認の取り方を決め、その規約をフックで毎回のメッセージに添えています。

確認なしでは実行させない操作

作業フォルダの CLAUDE.md の冒頭に、次の操作は実行前に必ず確認を取ることと書いています。

Docker コンテナの停止・作り直し・再起動
プロセスの再起動・停止・台数の変更
DB のマイグレーションの適用
ファイル・ボリューム・イメージの削除
nginx の設定の変更と反映、SSL 証明書の差し替え
作業フォルダを書き換える git の操作（checkout・reset・pull・clean）

ログやプロセスの状態を見るような読み取りの操作は、確認不要と明記しています。私は確認を毎回求められると煩わしく感じるので、確認の対象は本番に影響する操作だけに絞っています。

推奨案を付けた選択肢で確認する

確認の取り方は、ユーザー全体の CLAUDE.md で決めています。Claude Code には、選択肢を出して質問する機能（AskUserQuestion）があります。私は、先頭の選択肢を推奨案にして、各選択肢に判断材料を 1 行ずつ添えるよう指示しています。

選択肢の形なので、推奨案でよければ 1 回選ぶだけで答えられ、どれも違うときは「その他」に自由に書いて返せます。確認する場面は、commit と push、設計の方針のように後から覆しにくい判断、仕様の解釈が分かれるとき、ファイルの削除や本番への反映です。

commit と push の確認は作業の区切りで 1 回にまとめる

以前は、フックで commit と push のたびに許可を求めさせていました。毎回聞かれるのが煩わしくなり、外しています。今は、commit と push を許可の確認なしで実行できる設定にしたうえで、作業が一区切りついたときに、commit と push をまとめて 1 回だけ確認させています。

確認を取らずに応答を終えようとしたときは、Stop フック（Claude Code が応答を終える直前に呼ばれるフック）が、未コミットや未 push の変更が残っていないかを調べて止めます。同じ状態で 2 回は止めないので、私が「コミットしない」と答えた変更で何度も止まることはありません。

このフックが実行する git status は、git のインデックスを書き換えます。そのため、ファイルの変更を監視して自動で再起動するプロセスが、フックが動くたびに再起動していました。今は、フックの git に GIT_OPTIONAL_LOCKS=0 を付けてインデックスを書き換えないようにし、監視の対象からも .git を外しています。

フックと権限の設定

確認の取り方のように常に守らせたい規約は 1 つのファイルにまとめ、UserPromptSubmit フック（私がメッセージを送るたびに呼ばれるフック）で、毎回のメッセージに添えています。規約のファイルを直すと、次のメッセージから反映されます。ユーザー全体の設定（~/.claude/settings.json）のうち、確認に関わる部分は次のとおりです。

json

{
  "permissions": {
    "allow": ["Bash(git add:*)", "Bash(git commit:*)", "Bash(git push:*)"]
  },
  "hooks": {
    "UserPromptSubmit": [
      { "hooks": [{ "type": "command", "command": "$HOME/.claude/hooks/inject-rules.sh", "timeout": 10 }] }
    ],
    "PreToolUse": [
      { "matcher": "Bash", "hooks": [{ "type": "command", "command": "$HOME/.claude/hooks/guard-production.py", "timeout": 10 }] }
    ],
    "Stop": [
      { "hooks": [{ "type": "command", "command": "$HOME/.claude/hooks/check-git.sh", "timeout": 15 }] }
    ]
  }
}

確認なしで通す操作は、ユーザー全体の設定と、作業フォルダの設定（.claude/settings.json）に分けています。外部のサーバーへの接続のように影響の大きいものは、作業フォルダで起動したセッションでだけ確認なしで通るようにしました。

ここまでの仕組みは Claude Code に確認を求めさせるためのもので、指示が守られなければ確認なしで実行されます。そこで、コマンドの実行前に呼ばれる PreToolUse フックで本番に影響するコマンドを判定し、該当する場合は許可の確認を表示させています。判定の対象は、Docker コンテナの停止や再起動、プロセスの停止、マイグレーション、nginx の設定の反映、作業フォルダを書き換える git の操作、ビルド成果物の削除で、docker exec や SSH の中で実行するコマンドも対象です。フックは実行を拒否するのではなく確認を表示するだけなので、承認すればそのまま実行されます。コマンドの文字列から判定しているので取りこぼす可能性はあり、CLAUDE.md の指示と AskUserQuestion での確認も残しています。

無人で実行する Claude Code の権限を絞る

以前、毎朝 cron で Claude Code を無人で実行し（claude -p）、記事の題材を調べて、執筆の材料をフォルダに置かせていました。提案される題材がいまひとつだったので、今は止めています。題材は自分で用意しています。

作るときに分かったのは、無人の実行でも、対話で使っているユーザー全体の設定と作業フォルダの設定をそのまま読み込むことでした。そのため、commit や push などを確認なしで通す許可と Stop フックが、無人の実行にもそのまま引き継がれていました。無人の Claude Code は外部の Web ページを読むので、ページに書かれた指示を実行した場合（プロンプトインジェクション）に、それらの許可を使える状態になっていました。

そこで、無人で実行するときは、対話用とは別の狭い設定を渡しています。

--restricted で、ユーザー全体の設定と作業フォルダの設定を読み込まず、コマンドを実行するツールを外す（--tools で名前を挙げたツールだけは使える）
専用の設定ファイル（--settings）で、書き込める場所を作業用のフォルダ 1 か所に、実行できるコマンドを自作のスクリプトだけに限る
--permission-mode dontAsk で、確認が必要になる操作は、許可の一覧に無ければすべて拒否する（読み取りは通るので、秘密の情報を含むファイルは deny で読めないようにする）
自動メモリ（判明したことを Claude Code がファイルに書き残し、次のセッションで読み込む機能）を無効にする。保存先は git のリポジトリごとに決まるので、有効のままだと対話用のメモリに書き込めてしまう
DB や git は前処理のスクリプトで扱い、Claude Code には結果のファイルだけを読ませる

bash

claude -p --restricted \
  --tools Read Glob Grep Write Edit WebFetch WebSearch Bash \
  --settings ./config/headless-settings.json \
  --permission-mode dontAsk \
  --output-format json < prompt.md

設定を決めたあと、ダミーのファイルを使って、作業用のフォルダの外への書き込み、秘密の情報を含むファイルの読み取り、git の実行がすべて拒否されることを確かめました。

セッションをまたいで知識を引き継ぐ

新しく始めたセッションには、前のセッションの会話の内容は含まれていません。次のセッションでも必要な情報は、作業を終える前にファイルへ書かせています。書く場所は、内容によって 4 つに分けています。

書く場所	書くもの	例
CLAUDE.md	毎回必要な制約・正本の場所・手順	本番のビルド成果物を削除しない
変更履歴	経緯・実測値・試して駄目だった案	ある設定にした理由と、そのときの測定値
未解決の課題	まだ直していない問題と、確認する予定	対策の効果を確かめる日
メモリ	私の好み・進行中の案件	文章は比喩を使わずに書く

メモリには自動メモリの機能を使い、保存先を設定（autoMemoryDirectory）で作業フォルダの中に移して、git で管理しています。

作業が終わったら、判明したことをこの分類で書かせ、完了の報告で更新したファイルを挙げさせています。セッションを開始したときには、SessionStart フックで、バックアップの失敗や、確認を待っている件を表示させています。

繰り返す作業の手順をスキルにまとめる

繰り返す作業の手順は、CLAUDE.md ではなくスキル（作業の手順と参照資料をまとめておき、必要なときに Claude Code が読み込むファイル）にまとめています。セッションの開始時に読み込まれるのはスキルの説明（description）だけで、本文は使用するときにだけ読み込まれるので、長い手順を書いても、ほかの作業で使うコンテキストは増えません。公式ドキュメントでも、CLAUDE.md の一部が事実ではなく手順になってきたら、スキルを作成するよう案内しています。

自作している 3 つのスキル

私は次の 3 つのスキルを自作しています。記事の執筆のスキルはブログのリポジトリの中の .claude/skills/ に置き、残りの 2 つは作業フォルダの .claude/skills/ に置いています。

スキル	手順に含まれるもの	スキルにした理由
記事の執筆	題材の決定から公開までの手順、文体の規則、文体のチェッカー、CMS への投入スクリプト	規則と手順が長く、記事を書くときにしか必要ないため
アクセス解析と広告収益の集計	データの取得手順、集計スクリプトの使い方、数値を読み違えやすい点	手順と注意点がメモリに分散し、スクリプトを毎回複製していたため
セキュリティ監査	cron のスクリプトが集めた結果の読み方、脆弱性の判定、更新の手順	結果の判定と更新の判断を、無人の実行で行わないため

サブフォルダに置いたスキルは、そのフォルダのファイルを Claude Code が読むか編集するまで読み込まれないので、記事の執筆のスキルは、作業フォルダで起動した直後のスキルの一覧には表示されません。

集計のスキルは、同じ集計を 16 回行ったあとに作りました。「Google Search Console」の直近 2 日の値を確定値として読まないといった注意点が回ごとのメモリに分散し、集計のスクリプトも毎回、前回の作業用のフォルダから複製していました。そこで、手順と注意点とスクリプトの使い方を 1 つのスキルにまとめました。

セキュリティ監査のスキルは、cron のスクリプトと役割を分けています。ログや脆弱性の勧告の本文には攻撃者が指定できる文字列が含まれるので、無人の Claude Code には読ませず、cron のスクリプトには情報の収集と基準との比較だけをさせています。結果の判定と更新の判断は、私が開いたセッションでスキルの手順に沿って行わせ、更新は私が承認してから実行させています。調査するサーバーの上で実行する以上、管理者の権限を取得されていれば痕跡を隠すことができます。そのため報告は「調べた範囲で兆候なし」までとし、「侵害されていない」とは書かせていません。

スキルの説明と本文の先頭に書くこと

Claude Code は、スキルの説明を読んで、そのスキルを使用するかどうかを判定します。私は説明に、スキルに含まれる内容ではなく、スキルを使用する場面を書いています。集計のスキルの説明には、「収益を見て」「なぜ減った」のような依頼の言い方も並べています。

コンテキストが圧縮されると、再び読み込まれるのは、呼び出したスキルごとに本文の先頭 5,000 トークンまでです。そのため、間違えやすい点は SKILL.md の先頭に置き、詳しい規則は別のファイルに分けて、圧縮のあとはそのファイルを読み直すよう SKILL.md に書いています。

公開されているスキルの更新は内容を確かめてから適用する

自作のスキルのほかに、shadcn/ui、Payload、Prisma、Vercel が公開しているスキルも、skills コマンドでユーザー全体の ~/.claude/skills/ に導入しています。私のサイトは Docker コンテナでセルフホストしているので、Vercel へのデプロイのスキルと、Prisma のクラウド製品のスキルは導入していません。

スキルの本文は Claude Code への指示として読み込まれます。Anthropic のドキュメントでは、スキルは自作のものか Anthropic が提供するものだけを使用し、それ以外の提供元のものは使用する前に内容を十分に確認するよう注意しています。

このサーバーには本番のソースや秘密の情報を含むファイルがあるので、提供元の変更をそのまま取り込むと、変更に混入した指示がそれらのファイルにアクセスできる状態で実行されるおそれがあります。そのため、更新は自動で適用していません。週に 1 回、cron のスクリプトが HOME を別のフォルダに差し替えて更新を試し、差分があれば報告のファイルに書き出します。報告のファイルがあればセッションの開始時に知らせるよう CLAUDE.md に書いています。更新は、差分の内容を確かめてから適用します。allowed-tools に書かれたツールは、スキルを呼び出したターンでは許可の確認なしで使用できるので、差分ではこの欄の変更も確かめています。

記事の執筆と画像の作成をスキルにまとめる

このサイトの最近の記事は、執筆の手順をスキルにまとめて、Claude Code に書かせています。スキルには、題材の決め方から、文体の規則、記事の構成、画像の作り方、CMS への投入までの手順が含まれています。なかでも次の 3 つは、記事の内容と見た目に直接関わるので、手順の中で必ず行わせています。

書く前に体験を聞き取る

スキルには、構成を決めたあと、本文を書く前に、調べても分からない点だけを私へ質問する手順があります。Claude Code は、検索の上位の競合記事から読者が判断に迷う点を書き出し、公式の文書やコード、サーバーの記録から分かることは自分で確かめたうえで、残った点のうち、私の経験や判断で本文が変わるものだけを質問します。私が体験していないことは書かせないので、実測値や失敗、選んだ理由のような私にしか無い事実が無いと、誰が書いても同じ一般論の記事になります。

以前は、最初に失敗したところや途中で捨てた選択肢など、決まった 6 つの質問をすべての記事で聞かせていました。使い方や比較の記事では題材に関係の薄い質問が残り、その回答が本文に入って、私が読み直す箇所が増えたので、質問の数を固定するのをやめました。今は、質問ごとに回答を入れる見出しを添えさせ、見出しを指せない質問はさせていません。本文に使わなかった回答は、理由を下書きと一緒に報告させています。

文体を私の記事と数字で比べる

文体の規則は、私が書いた記事 14 本を集計した値で決めています。たとえば私の 1 文は平均 52 字ですが、スキルを作った当初に Claude Code が書いた記事は平均 31.7 字で、同じくらいの長さの短い文が並んでいました。

下書きは、付属のチェッカーで文の長さのばらつきや「」と「私」の頻度を私の記事と比べ、使わない語が無いかも調べさせ、すべての項目が基準を満たしてから私が読みます。私が読んで「自分ならこう書かない」と感じた箇所は、「× こう書いた / ○ こう書く」の表に追記させています。

それでも、Claude Code が書いた記事 12 本を照合し直したところ、事実の誤りと、ツールの変更で古くなった記述が 18 件見つかりました。古くなった記述は、記事を書いたあとにツールの仕様を変えたのに、記事を直していなかったものです。今は、ツールの画面や上限を変えるファイルを開くと、その仕様を書いた記事も直すよう求める規約が読み込まれるようにしています。

画像は SVG で描かせて、縮小して確かめる

サムネイルと図解は、Claude Code に SVG で描かせ、自作の小さなツールで PNG や WebP に変換しています。このサーバーには日本語のフォントがインストールされておらず、そのまま変換すると日本語の文字がすべて「□」になるので、ツールに「Noto Sans JP」を同梱し、変換するときだけ読み込ませています。

Claude Code は変換した画像を読み込んで内容を確認できるので、サムネイルは記事の一覧に表示される大きさまで縮小した画像も見させ、文字が読めるかを確認させています。

写真のような絵が必要なときだけ、Google の画像生成モデル「Nano Banana Pro」の API を呼び出す別のツールを使います。こちらは 1 枚ごとに料金がかかるので、実行前に見積もりを出させ、私が確認してから生成させています。

サブエージェントで調査とレビューを分ける

調査やレビューは、サブエージェント（別のコンテキストで動く Claude Code）に分けて、並行して進めさせています。

サブエージェントのモデルを使い分ける

私は Claude の「Ultra」プランを契約しています。このサーバーの運用とほかのプロジェクトの開発の両方で、朝から晩まで同じアカウントの Claude Code を使っています。最近は、大きなコードベースで複数のサブエージェントを決まった手順で動かすワークフロー機能を使うことが増えています。

以前、モデルを指定せずに 6 本のサブエージェントを同時に起動したところ、親のセッションと同じ「Fable」で動き、利用枠を大きく消費したことがあります。Fable は、1 トークンあたりの料金が最も高いモデルです。それ以降、モデルは Claude Code に選ばせ、Fable だけは使う前に私の承認を取らせています。

モデルの別名（sonnet など）が指すモデルは、Claude Code のバージョンで決まります。私の環境では Claude Code の自動更新を止めていたため、新しい Sonnet が出たあとも、sonnet を指定したサブエージェントが 1 つ前の Sonnet で動いていました。Remote Control の常駐プロセスも起動したときのバージョンで動き続けるので、Claude Code を更新したら、常駐プロセスも起動し直す必要があります。今は、新しいバージョンが出ていないかを、cron のスクリプトで週に 1 回確かめています。

自分の差分を別のサブエージェントにレビューさせる

不具合をまとめて直したあとは、その修正の差分を、別のサブエージェントにもう一度レビューさせています。私が運用しているツールのサイトで、レビューで見つかった 59 件の不具合をまとめて直したときは、この差分のレビューで、修正によって新しく発生した不具合が 6 件見つかりました。どれも型チェックとリントは通っていました。うち 2 件は、直そうとした問題が、別の形で再発していたものです。

差分のレビューは修正をコミットする前に行い、修正前のファイルを git show HEAD:<パス> で取り出させて、その問題が本当に差分によって発生したものかを比べさせています。