gaipack のサイト（gaipack.ai）の運用を、Claude Code の「ルーチン」機能でほぼ自動で回すようにしました。深夜に監査ルーチンが Issue を立て、早朝に別のルーチンがそれを拾って PR を作り、始業時には人間がレビューするだけの状態になっています。この記事では、その構成と、ルーチン自身に定義書を改善させる「自己改善ループ」の組み方、そして自分のアカウントのトークンで回すときの注意点を紹介します。

Claude Code のルーチンとは

Claude Code のルーチンは、スケジュール・API・Webhook で起動できるテンプレート化された定型処理を作る機能です。起動すると対象リポジトリを clone し、与えられた指示に従って作業し、Issue を立てたり PR を出したり Slack に投稿したりして終了します。リポジトリを紐付けなくても動くので、Gmail の整理やミーティングメモの整形のような使い方もできます。

実行場所は 2 種類あります。

クラウド環境は許可リスト内のネットワークにしか到達できません。実測では Contentful の API や gh CLI が使えなかったため、それらを触るタスクはローカルに寄せています。

サイト運用の一週間はこう回る

まず、gaipack のサイトのリポジトリで回している 5 本のクラウドルーチンです。

チェック系を月〜木の 03:00 に置き、同日 06:00 の Issue 対応ルーチンがそれを拾います。出社は 09:00 なので、始業時には PR ができている流れです。人間が立てた Issue も同じ列に並べておけば、ルーチンが区別なく処理してくれます。

PR 作成後は、プルリクエスト単位で出る Vercel のプレビューでビルドが通っていることと表示を確認してからマージしています。ルーチンでは main への直接 push ができないため、ルーチンの出口は PR 止まりです。裏を返せば、ルーチンが何をしても人間のレビューを通らずにサイトが変わることはありません。

安全側の歯止めとして、1 回の実行で起票する Issue は最大 5 件（深刻度順。残りはレポートに残して次回に回す）、確信が持てない変更は PR を作らず Issue コメントで方針提案に留める、と定義書に書いています。

これに加えて、ブログ入稿（Contentful への Draft 入稿）はローカルの scheduled task として定義しています。Contentful の管理トークンをクラウドに持ち出さずに済むからです。こちらは別のメンバーが自分の端末で回しており、定義書は同じ .claude/routines/ 配下で管理しています。Publish はせず、公開は人間が管理画面で行う点も同じです。入稿の仕組み自体は Agent Skills で gaipack Blog の入稿作業を半自動化してみた で詳しく書かれています。

ルーチン本体に手順を書かない

最初にやりがちな形は、ルーチン作成 UI に長いプロンプトを貼り付けることです。これは動きはするのですが、差分が追えずレビューもできず、直すたびに再登録が必要で、何よりルーチン自身が自分の指示を直せません。

そこで、ルーチン本体には「自分が何というルーチンか」と次の 3 点だけを書いた短いブートストラップを登録しています。

1. リポジトリ内の共通ルールを読む
2. 続けて自分の定義書を読み、そこに書かれた手順に厳密に従う
3. 定義書が読めなければ、リポジトリに一切変更を加えず報告して終了する

あわせて「定義書が唯一の正本で、この指示文と矛盾したら定義書を優先する」と明記しておきます。

手順はすべてリポジトリの .claude/routines/ 配下に置きます。共通ルール（Issue のフォーマット、起票数の上限、PR の作り方、CMS への書き込み境界）を README に、ルーチンごとの手順を 1 ファイルずつ書く構成です。

.claude/routines/
├── README.md        # 共通ルール + ブートストラップの雛形
├── <監査ルーチン>.md  # チェック系(週次)が 1 本 1 ファイル
├── ...
├── <Issue 対応>.md
└── <ブログ入稿>.md    # ローカル scheduled task 用（別メンバーが運用）

定義書を Git に置いた瞬間、ルーチンは「レビューできる・改善できる・自分で直せる」ものになります。挙動を変えたいときは .claude/routines/ の .md を PR で直すだけで、ルーチン本体の再登録は要りません。新しいルーチンを足すときも、定義書を 1 枚書くだけです。

実行のたびに賢くなる自己改善ループ

定義書を外出しした一番の狙いがここです。各ルーチンは、本来のタスクを終えたあとに振り返りの工程を持っています。

1. 本来のタスク（監査・Issue 対応・取り込み）を実行する
2. 振り返る。誤検知だった項目、調査して問題なしと確認できた事項、非効率だった手順、定義の曖昧さはなかったか
3. 知見があれば、自分の定義書の末尾にある「知見メモ」セクションに追記する
4. 定義書だけを変更する改善 PR を作る
5. CI が通れば auto-merge でマージされる

ポイントは、auto-merge していい PR の範囲を定義書で固定していることです。

自分を賢くする方向は自分でマージしてよく、自分を甘くする方向は人間に聞く、という非対称ルールです。改善がない実行では PR を作らないことも明記しています。無意味な差分を毎回作られると、レビューする側が疲れてしまうからです。

実際に蓄積された知見メモは、たとえば「この環境ではこのコマンドが使えないので別の手段を使う」「この検索条件は当日分を取りこぼすので指定の仕方を変える」「大きな変更はこう分割して判断する」といった、実行してみて初めて分かる類のものです。いずれも人間が書いたものではなく、ルーチンが自分の失敗や詰まりを振り返って書き残したものです。

「同じ穴に二度落ちない」を、人間がメモしなくても達成できるようになりました。長期記憶をベクトル DB ではなく Markdown と Git 履歴で持っている、と言い換えてもいいと思います。もちろん失敗もしますが、出口に必ず人間のゲート（PR・Draft・下書き）があるので事故にはならず、失敗は次の実行の定義書に変わります。

「自分の代理」を作るときの線引き

同じ型を、サービス定義の正本を管理するリポジトリ（チャットの投稿から正本ドキュメントへ反映すべき知見を拾って更新 PR を作る）や、プリセールス業務のリポジトリ（タスクと SFA の突合、レビュー依頼への返信案の作成）にも横展開しています。

このうちローカルで回しているものは、自分の Slack アカウントで動きます。Claude が自分の代理で送信すると、自分には通知が飛ばないため、送ったこと自体に気づけません。そこで、レビュー依頼への返信はスレッドに下書きとして置くだけにして、送信は必ず本人が行う運用にしました。また、メッセージに Claude Code の絵文字を置き、読み手が「本人の文面か AI の下書きか」を区別できるようにする工夫をしています。

3 つのリポジトリに共通する型は次の 4 つです。

状態は見える場所に置くことも効いています。処理済みの台帳を Issue やセルフ DM に置いておけば、毎時のルーチンが同じ依頼を二重処理しません。

回っているのは自分のトークン

ルーチンはアカウント単位で登録されるので、消費されるのは自分のアカウントに紐づくトークンです。GitHub Actions と違い、自分のアカウントが消えればルーチンも止まります。毎時のローカルルーチンは平日だけで週 60 回走るため、設計で絞らないと予算は静かに溶けます。

溶かすパターンと、定義書に書いている歯止めを並べます。

モデルも用途で分けています。既定は Sonnet 5 や Opus 5 で、判断が重いルーチンは Fable 5 にしています。

自分に与えられたトークンは、自分の裁量で自分の仕事に投資する予算だと捉えるのがよいと思っています。だから「何に使うか」と「いくらで止めるか」を定義書に書くのです。

チームでトークンを分け合う働き方へ

ここからは、いま一人で回している仕組みを、チームの形にどう広げたいかという話です。まだ構想の段階ですが、ルーチンを回し始めてから考えが変わった点なので書いておきます。

自動化は「誰かに作ってもらうもの」ではなくなる

これまでの自動化は、詳しい人が作って配る形が普通でした。依頼して、順番を待って、できたものが自分の仕事に合わないこともあります。ルーチンは定義書を 1 枚書けば動くので、自分の繰り返し仕事を一番よく知っている本人が、自分で定義書にするのが一番早いし精度も高いはずです。

ルーチン本体が 3 行で、手順が Markdown なのはそのためでもあります。コードが書けなくても、自分の仕事の手順を日本語で書ける人なら誰でも始められます。

一人ひとりが自分の予算でルーチンを回しアウトカムを最大化する

トークンはアカウント単位で消費されます。これは制約であると同時に、チーム運営のうえでは好都合だと考えています。割り当てられたトークンを「自分の裁量で使える予算」として一人ひとりが持ち、その予算で何を自動化してアウトカムを増やすかを自分で決める形になるからです。

予算である以上、使い方には差が出ます。毎回ゼロから全件調査するルーチンを回せば予算はすぐ溶けますし、知見メモを育てて上限を決めたルーチンなら同じ予算で何倍も回せます。どこに投資して、どこで止めるかを考えることが、そのまま仕事の設計になります。

上司の仕事はルーチンをレビューして予算を渡すことに変わる？

メンバーが自分のルーチンを定義書として書くと、上司の仕事も変わります。作業を割り振って進捗を追う代わりに、定義書をレビューして安全境界（出口が人間のゲートになっているか、件数上限があるか）を確認し、予算を渡す。成果が出ているルーチンには予算を足し、空回りしているものは止める判断をする。マネジメントの対象が「人の時間」から「定義書と予算」に移っていくイメージです。

これからは、割り当てられたトークン予算ありきで仕事のアウトプットを問われる場面が増えていくのではないでしょうか。だとすれば、今のうちに自分の予算で小さく回し始めて、何にいくら使うと何が返ってくるのかを体感しておくのがよいと思っています。

まとめ

あなたの仕事で「毎朝始業前に終わっていてほしいこと」は何でしょうか。まず 1 本、定義書から書いてみてください。

Claude Code を開発現場に組み込む進め方については、AI 駆動開発（AIDD）の解説記事や、AIDD インハウスのサービスページもあわせてご覧ください。