Claude Codeで業務ルーチンを回す ─ SREエンジニアの実践記録(2026/03版

はじめに

こんにちは。SREチームでインフラエンジニアをしております小林(id: kasei_san) です。 Claude Codeを業務に組み込んで1ヶ月ほど経過しました。

最初は「コード生成ツール」として使い始めましたが、スキル・hooks・ルールを整備していくうち、朝の立ち上げからセッション終了まで、一日の業務ルーチン全体がClaude Codeを軸に回るようになりました。

この記事では、その仕組みと工夫を共有します。

全体像: 一日のルーチン

まず全体像です。

朝の /good-morning でその日の状況を把握し、タスクを確認・計画し、作業を実行し、セッション終了時に /session-summary-local で引き継ぎ情報を記録する。翌朝の /good-morning がその引き継ぎを読み込む──というサイクルです。

横断的な自動化（自律性ルール・hooks・memoryへの学び蓄積）が全フェーズに効いています。

1. 朝の立ち上げ（/good-morning）

/good-morning と打つだけで、以下を一括で取得・表示します:

前回セッションの振り返り（HANDOFF.mdから）
GitHubプロジェクトボードのタスクサマリー（ステータス別）
レビュー待ちPR・自分のPRの状況
未読メールの分類（要対応 / 返信待ち / FYI）
おすすめタスクの提案

さらにHTMLに書き出してブラウザで表示するので、ダッシュボード的に使えます。月初には先月の月報が未作成なら自動生成まで行います。

2. タスク確認・計画

GitHubプロジェクトボードをベースに、チーム共通のプラグインスキルで管理しています:

task-summary — 進行中タスクの状況確認
backlog-review — バックログの優先順位レビュー
sprint-estimation — スプリントの見積もり・ポイント付け

3. 作業

作業中のClaude Codeは以下のフローを自律的に進めます:

issueのbodyに作業計画をTODOリスト化
実装・修正
lint / test実行
commit → push → PR作成
CIチェックの自動追跡（失敗時は自分で修正して再push）
Terraform変更ならTFC runの追跡まで

「PR作ってもいいですか？」とは聞きません。 後述する自律性ルールにより、技術的に実行可能なことはすべて自分で判断して進みます。

4. セッション終了（/session-summary-local）

セッション終了時に /session-summary-local を実行すると:

セッション中に触れたissue/PRの操作履歴（hookが自動記録）を集約
作業概要と「次やること」をHANDOFF.mdに記録
翌朝の /good-morning がこれを読み込む

ここは最初自動でやっていたのですが、うまく行かずに手動に変更しました。Claude Code自身も作業が一区切りつくと、/session-summary-local の実行を提案してくれるので、今のところ忘れずに回せています。

特に自慢したいポイント

「聞くな、自分で調べろ」─ 自律性ルール

Claude Codeの最大の生産性向上ポイントは、止まらないことです。

デフォルトのClaude Codeは親切すぎて、すぐ「これでいいですか？」「確認してください」と聞いてきます。しかしSRE業務では、CLI/APIで確認できることを人間に聞く必要はありません。

そこで rules/autonomy.md に自律性ルールを定義しています:

# 自己検証・自律判断ルール（抜粋）

- **「これでいいですか？」「確認してください」と聞かない。** 自分で検証して進むこと
- **PR作成後**: CIチェック完了まで自分で追跡する。落ちたらログを読んで自分で修正・再push
- **PRマージ後（Terraform）**: TFC runを追跡する。apply待ち（手動承認が必要）の場合のみユーザーに依頼する
- **コード修正後**: lint系チェック → commit → push → PR作成まで自律的に進む
- **人間に聞いてよいのは**: 物理的に自分で不可能な場合のみ
  （TFC手動apply承認、SMS/MFA認証、ブラウザ手動操作、ビジネス上の意思決定）

さらに self-verify スキルを用意し、Claude Codeが質問しようとする前に自動ロードされるようにしています。このスキルには「人間に聞く前に使える検証ツールカタログ」が含まれていて、AWS CLI、GitHub CLI、TFC APIなど、自分で確認する手段を具体的に示しています:

# self-verifyスキル 検証ツールカタログ（抜粋）

## PR作成後 → CIチェックを自分で確認
~/.claude/bin/gh-wait-checks <PR番号>

## PRマージ後（Terraform） → TFC runを自分で追跡
~/.claude/bin/tfc-api /runs/{run_id}
~/.claude/bin/tfc-wait {run_id}

## AskUserQuestionを使う前に自分で調べる
- SESのサンドボックス状態 → aws sesv2 get-account
- GitHub Secretsの設定状況 → gh secret list
- TFCの設定状況 → tfc-api
- 命名は自分で決めること（人間に聞かない）

効果: Claude Codeが止まらず作業を進めるので、自分は別の仕事に集中できます。「PRできたよ」「CIも通ったよ」と報告が来るのを待つだけです。

また、別途Claude Codeからの確認を効率化するツールを自作していますが、こちらは後日また別の記事で紹介いたします。

セッション間の引き継ぎシステム

Claude Codeのコンテキストウィンドウには限界があります。長期タスクを複数セッションにまたがって進めるには、セッション間の引き継ぎが不可欠です。

3つの仕組みで実現しています:

1. HANDOFF.md ─ 引き継ぎファイル

# Handoff

## infra-110: BaiduBot Chrome/48 UAブロック (2026-03-05 11:08)
- https://github.com/example/repo/issues/110
- 次: PR #1332のレビュー・マージ待ち。マージ後WAFに反映確認

## sre-270: RDS Reader Auto Scalingチューニング (2026-03-05 11:04)
- https://github.com/example/repo/issues/270
- 次: PR #3244のレビュー・マージ後、夜間ピークでスケーリング改善を確認

2. track-session-issues.sh hook ─ 操作履歴の自動記録

gh issue / gh pr コマンドの実行をhookで検知し、TSVファイルに自動記録します。セッション終了時にこのTSVを読み取るので、「どのissue/PRに触れたか」を手動で思い出す必要がありません。

# hookの仕組み（抜粋）
# gh issue/pr コマンドを検知し、アクション種別（create/comment/view等）と
# modified/viewedシグナルに分類してTSVに記録する

if [[ "$command" == *"gh pr create"* ]]; then
  action="pr_create"; signal="modified"
elif [[ "$command" == *"gh issue comment"* ]]; then
  action="issue_comment"; signal="modified"
elif [[ "$command" == *"gh pr view"* ]]; then
  action="pr_view"; signal="viewed"
fi

printf '%s\t%s\t%s\t%s\n' "$timestamp" "$signal" "$action" "$url" >> "$TSV_FILE"

3. /session-summary-local スキル ─ セッション終了処理

セッション終了時にTSVを読み込み、作業概要と「次やること」をHANDOFF.mdに書き出します。翌朝の /good-morning がこれを自動的に読み込むので、コンテキストが途切れません。

また、/session-summary-local にて、ここまでやった内容で、issueのbodyを更新させ、 issueのbodyだけ見れば、何をすればよいか分かるようにしています

これは、以下のようなメリットがあります

HANDOFF.mdのコンステキスト量の圧縮
他のメンバーや、他のメンバーのAIがそれを見れば、状況が理解できる

個人的には、これはかなりオススメなので 、是非真似してください。(コメントにやったことが羅列されているだけのissueは人間にもAIにも厳しいです……)

hookによる自動化の積み重ね

小さなhookの組み合わせが、大きな自動化になります。

hook	何をするか
track-session-issues.sh	`gh` コマンド実行を検知して操作履歴を自動記録
open-github-url.sh	PR/issue作成後にブラウザで自動オープン
log-permission-request.sh	許可要求をログ記録 → 定期的にsettings.json改善に活用

特に track-session-issues.sh は、session-summary-localスキルと組み合わせることで「セッション中に何をしたか」を手動で振り返る必要をなくしています。

log-permission-request.sh も地味に便利です。Claude Codeの許可ダイアログの記録が溜まっていくので、定期的に /permission-review スキルで分析し、settings.jsonのallow/denyルールを改善できます。「よく許可するコマンドはallowに追加」「繰り返すパターンはシェルスクリプトに抽出」といった改善サイクルが回ります。

月報の自動生成

月末に /monthly-report と打つだけで、GitHub APIからその月にマージしたPR・クローズしたissueを取得し、月報を自動生成します。

# 月報スキルの仕組み（抜粋）

## Step 1: マージ済みPR取得
gh search prs --author=@me --merged=YYYY-MM-01..YYYY-MM-{末日}

## Step 2: クローズ済みissue取得
gh search issues --assignee=@me --closed=YYYY-MM-01..YYYY-MM-{末日}

## Step 3: issue bodyから作業概要を抽出
- bodyのチェックリスト（- [x]）やh2見出しから主な作業内容を要約

## Step 4: PRをissueにグルーピング
- PRタイトルのprefix（例: sre-backlog-172:）からissue番号を抽出し紐付け

さらに /good-morning スキルが月初に先月の月報ファイルの存在をチェックし、未作成なら自動で /monthly-report を実行します。これにより、毎月何をしたかの振り返りも可能になりました。

チーム向けプラグイン化

個人で磨いたスキルのうち、チームの誰が使っても同じ価値があるものは claude-infra-skills プラグインとして切り出しました。

スキル	説明
task-summary	プロジェクトボードのタスクサマリー
backlog-review	バックログの優先順位レビュー
sprint-estimation	スプリント見積もり
estimate-issue	個別issueの見積もり
session-summary	セッション振り返り・issue更新
tfupdate	Terraform CLIバージョン更新の自動化
terraform-workspace	TFCワークスペース追加