TL;DR
- issueを渡すだけで調査・計画・実装・レビュー・PR作成まで自動化するSkillを作っている
- 人間の判断が必要な部分をなくすため、自分の分身エージェント /white-hedgehog を追加した
- 自分の判断基準を言語化してエージェントに持たせることで、意思決定ごと任せられるようにした
- 実際はうまくいかないことも多く、プロンプトを地道に修正している
- 判断基準の言語化が、思考を整理する副産物になった
はじめに
fluctでデータエンジニアをやっているyanyanです。
最近、新規プロダクトの開発やデータ基盤の整備など、自分の仕事の守備範囲がじわじわ広がってきています。 コードを書かせたりコードリーディングをさせるのは以前からやっていました。ただ、実装の方針を決めたりAIの成果物をレビューする部分は結局自分でやっていて、そこに地味に時間がかかっていました。「ここもAIに任せられるのでは？」と思うようになったのが、このSkillsを作り始めたきっかけです。
そういう経緯で作り始めたのが、issueを渡すと調査・計画・実装・レビューまで全部やってくれるClaude Code Skillsです。 今回はそのSkillsに関する話と、さらにそこから、「自分の分身」となるオーケストレーターエージェントを追加して、人間が関与する部分をさらに減らそうとした話をします。
開発を自動化するClaude Code Skills
Claude Codeには、独自のカスタムコマンドを定義できる「Skills」という仕組みがあります。コマンドの中でどんなエージェントを呼んで何をさせるかを指示として書いておくと、/コマンド名 の形で呼び出すだけで一連の作業が動き出します。
手始めにこの仕組みを使って /issue-dev というSkillsを作りました。issueの番号を渡すと以下をすべてやってくれます。
- 実装方法の調査・比較
- 実行計画の作成
- 実装
- コードレビュー
- draft PRの作成
ただ、最初の設計では人間が判断を挟むタイミングが2回ありました。
- 複数の実装方針の中からどれで進めるかを選ぶとき
- 最終的な成果物（draft PR）を確認するとき
この構成でもかなり自動化できていたんですが、「もっと手を離せないか」という気持ちが出てきました。各エージェントの出力を次のエージェントにそのまま渡すだけで、出力品質を磨く仕組みがなかったのも気になっていました。
自分の分身エージェントを作った
そこで思ったのが、自分が意思決定をする際の思考や基準を言語化できれば、AIに任せられるのではないかということです。方針の選択も計画のレビューも、「自分が何を重視してどう判断しているか」を文書として渡せば、AIに自身の判断や考えを再現させられるのでは？と考えました。
そして生まれたのが、自分の分身となるオーケストレーターエージェント /white-hedgehog です。
名前の由来は、Slackのアイコンがハリネズミなので、ハンターハンターに出てくる「自分の分身となるゴリラを生み出す能力」ホワイトゴレイヌをもじりました。
このエージェントの役割はシンプルで、「自分だったらこう判断する」という基準に従って全体の流れを仕切ることです。具体的には以下をやっています。
- issueの内容を見て、調査エージェントに渡すのに情報が十分かを判断する（足りなければユーザーに確認）
- explorer → planner → red team → developer の各エージェントを順番に呼び出す
- 各エージェントの出力を評価し、基準を満たすまで改善させる
- planner の実行計画と red team の批判的な指摘を見比べて、最終的な実行計画を決める
- developer の成果物をレビューし、approve が出たら draft PR を作る
- 全フェーズが終わったら一連の流れを振り返り、Skill自体の改善点がないかを評価する
人間がやることは最終的な draft PR の確認だけ。あとは white-hedgehog が全部仕切ります。
分身には何を持たせたか
white-hedgehog が「自分の分身」として機能するには、自分の判断基準を言語化してエージェントに渡す必要があります。参照させているのは以下の3つです。
- issue-description-rules.md：issueにどんな情報が揃っていれば調査エージェントに渡せるか
- agents-evaluation-rule.md：各エージェントの出力をどう評価するか
- making-decision-rules.md：複数の選択肢があるとき、何を重視してどう選ぶか
つまるところ、「自分がどういう情報が揃ったときに考え始めるか」「自分が作ったものをどう評価するか」「自分はどういう観点で意思決定するか」を言語化したものです。
言語化してみてわかったこと
この作業、思ったより難しかったです。
判断基準や大切にしている考え方自体は言葉にできます。「シンプルな実装を優先する」「後から変えにくい設計上の決定は慎重に」といったことは書き出せる。でも、その一歩奥にある「なぜそれが大切なのか」「どういう状況でその基準を優先し、どういう状況では別の基準を優先するのか」という部分が、言語化しようとするとなかなか難しく筆が止まりがちでした。
「自分はこういうことを大事にしている」はわかる。でもそれがなぜ大事なのかは、自分でもよくわかっていないことが多い。普段は感覚と経験で処理していることを、文章として誰かに渡せる形にする作業は思っていた以上に骨が折れました。
実際に動かしてみると
何度か実際のissueを渡して試してみましたが、意外と上手く動かないところが多かったです。
一番困ったのがdraft PRを作るはずなのにmainに勢いよくpushしてくる問題です。Skillsの指示には「draft PRを作れ」と書いているのに、なぜか普通のPRを作ってmainにマージしようとしてくる。プロンプトに「必ず draft PR を作ること」と強く書いたら直りましたが、こういうのを一つひとつ潰していく作業が続いています。
もう一つは振り返りをしてくれない問題。white-hedgehog は最後に一連のフェーズ全体の振り返りをすることになっているんですが、さらっとスルーされることが多いです。「振り返りを行うこと」というだけでは不十分で、何をどう振り返るかを細かく指示しないとやってくれません。
必ずやってほしいことややってはいけないことは、hooksのような特定のタイミングで必ず発火するものでコンテキストを注入したり抑制をさせるのがよさそうだなと考えています。
プロンプトで自分を再現するという試み
「自分の分身をプロンプトで再現する」という試みは、想定外の副産物をもたらしました。判断基準を言語化しようとすることで、自分が普段どんな思考をしているかがすこし見えてくる。エージェントを鍛えるつもりが、自分の思考の輪郭が浮かび上がってきた感じがしています。
white-hedgehogの構成や指示の出し方というのは今も試行錯誤の段階にあります。しかし「自分の分身となるエージェントを育てる」ことが自身を形成している価値観や考え方を整理し言語化するとてもよい機会となりました。
