Claude Codeのスキルが毎日勝手に改善されていく仕組みを作った

この記事は Claude on SonicGarden の記事です。ソニックガーデンのプログラマが、Claude Codeの活用について書いています。#claude_on_sonicgarden

きっかけ

最近は dev-workflow というスキルでワークフロー化された開発をしているのですが、開発が一段落するたびに「今回の dev-workflow のここが微妙だったな」と感じる箇所を直してから次のタスクに行く、という流れを毎回繰り返していることに気づきました。

そんな時に Claude Code の Routines が発表されて、これ使えば dev-workflow の改善はある程度自動化できるのでは？と考え、次のような自己ふりかえりの仕組みを作りました。

• dev-workflow での開発完了時にそのセッションの会話履歴から自己ふりかえりを実施
• 自己ふりかえりで検出した課題を GitHub Issues に登録
• Routines で毎日 Issues に登録されている課題を修正

ざっくり 3 週間で 40 件以上の auto-triage コミットが PR 経由で main に入っている状態です。今のところ人間がレビューしてマージする運用なので完全自動ではないですが、ふりかえり〜PR 出しまでが勝手に進むだけでもだいぶラクになりました。

加えて、自分が「今回はうまくいったな」と思ったときでも、実は裏でサブエージェントとのやり取りで発生した問題を自己ふりかえりは拾ってくれます。自分では気づけなかった部分まで改善されていくようになったのは面白い発見でした。

---

全体像

段	スキル	場所	やること
1. 発見	dev-workflow の自己ふりかえり	ローカル	自分の会話 jsonl から「うまくいかなかった signal」を抽出して Issue 起票
2. 判定+適用	dev-workflow-triage	Claude Code on the Web	Issue を読んで accept/reject、accept なら SKILL.md を修正して PR 作成
3. 無人運転	Routines	Claude Code on the Web	2 を 1 日 1 回叩く

最後に PR を人間がレビューしてマージするので、main に commit が積まれるのは人間が OK を出した分だけです。

---

発見側: 会話履歴から改善のタネを拾う

dev-workflow の自己ふりかえりでやっていることです。

何を signal とするか

最新の ~/.claude/projects/<encoded-cwd>/<session-id>.jsonl をサブエージェントに丸投げして、次のような「うまくいかなかった signal」を拾わせています。

• ユーザーからの修正指示（「違う」「stop doing X」）
• 同じ指示の繰り返し（スキルが内面化していない signal）
• 進まないステップが何度も走るループ
• レビュースキルが SKILL.md 文面を root cause として名指しした箇所

jsonl はそこそこサイズが大きいので、生会話をメインのコンテキストに乗せずにサブエージェント側で処理させる構成にしています。

---

適用側: Issue を読んで判定→修正→コミットする

dev-workflow-triage というスキルを別途作って Routines に登録しています。

なぜ dev-workflow とは別スキルなのか

dev-workflow はユーザーとの対話を前提としたスキルなので、Routines で無人運転するには向きません。なので dev-workflow の開発品質は維持したまま、無人で回せる triage 専用のローカルスキルを別に作りました。

品質ゲート 3 段

最終的には完全自動でのスキル改善を見据えているので品質ゲートをしっかり設けています。

ゲート	何を見るか	内側ループ上限
verify-diff	Edit が Finding の 意図 を達成したか（empirical 検証）	3
skill-review	SKILL.md の best practices（構造・記述スタイル・冗長性）	3
publicity-review	公開リポへの leak（絶対パス、内部 hostname、credential、ユーザー識別子）	2

各ゲートはそれぞれ内側でループしますが、その 3 段全体を 1 ユニットとして外側でさらに 最大 3 回ループ させています。skill-review が SKILL.md に手を入れると verify-diff の意図達成チェックや publicity-review の leak チェックの結果が変わりうるので、3 段を直列で 1 回流して終わりだと整合が取れないためです。外側ループは「どのゲートも 1 件も edit を入れなかった iter があれば convergence」「fatal な verdict が出たら break」で抜けます。

verify-diff は empirical-prompt-tuning の発想を参考にさせてもらっています。

---

Routines で回してハマったポイント

ワークフローを途中で止めずに最後まで走らせるのが思った以上に大変でした。

• サブスキルから戻った直後に待ち始める: 冒頭に「止まらないで」と書いても止まる。判断ポイントの直前にも再掲することで対応
• サブスキルの出力が長い文章だとそこで完結扱いされる: 文章を返すとエージェントが「ユーザーへの完成された応答」と解釈して次ステップに進まなくなる。末尾を {"status": ..., "suggested_edits": [...]} のような短い JSON で閉じると「parse して次に進むやつ」と認識してくれた
• .claude/ 配下に作業ファイルを置くと止まる: 非対話環境では書き込もうとした時点で許可ダイアログが立つ。staging ファイルは .triage/ など外のディレクトリに置いて .gitignore で管理するのがよさそう
• allowed-tools の書き漏れがあると途中で止まる: TodoWrite など見落としやすいツールは、サブスキル経由で呼ばれた瞬間に permission dialog が立つ。サブスキルが使うツールを網羅できているかチェックする仕組みを入れておくと安心
• Web のデフォルト Stop hook が中間状態で誤発火する: Web 環境には stop-hook-git-check.sh というデフォルトの Stop hook が入っており、未コミット・未プッシュの変更があると exit 2 でエラーを返す。途中で未コミット状態が発生するワークフローではサブエージェント呼び出しのたびに誤発火する。オーケストレータと各サブスキルの両側に状況説明を置いて対応

---

やってみての所感

数字としては:

• 自動 triage コミット: 40 件以上 / 13 日
• 自己ふりかえり Issue: 21 件起票 / 21 close / 0 open
• 1 Issue あたり Finding 数: 1 〜 4

これは 自分 1 人だけが自己ふりかえりを有効化している試験運用段階 の数字です。もう少し安定してきたらチームに広げていく予定です。

正直、そんなに改善する所あるの？と思ったりもしますが、今のところ、明らかにスキルが改悪したというケースはなく、逆に「お、ちゃんと良くなってるな」ってことはあるので、ある程度はうまく機能していそうです。

---

おわりに

会話履歴から改善のタネを拾い、別セッションで判定して PR まで出す、という 3 段構成の自己改善ループを紹介しました。

最終的なマージは人間が PR レビューしてからやっているので完全な機械任せではないのですが、ふりかえり〜PR 出しまでが勝手に進むだけでも、同じ修正を繰り返している感覚がかなり減りました。同じような自動化スキルを作る予定の方の参考になれば。

---

今回紹介した dev-workflow / dev-workflow-triage スキルは以下のリポジトリにあります
hiroro-work/claude-plugins

---

この記事はZenn/Qiitaにクロスポストしています