株式会社ヘンリーでソフトウェアエンジニアをしているwarabiです。
ヘンリーは医療業界向けのプロダクトを開発しており、開発メンバーにも難解なドメイン知識が求められます。そのため普段からドメインの理解や深堀りに時間をかけたいところですが、実際は開発業務も進めなければならないため、時間の使い方に悩んでいました。
この課題に向き合うために、普段開発で使っているClaude Code（Anthropic社が提供するCLIベースのAIコーディングアシスタント）をもっとうまく活用し、実装にかける時間を減らして学習に充てる時間を増やせないかと考えました。
それまでのClaudeCodeの使い方と課題
それまでの私のClaude Codeの使い方は、一言で表すとAIとのペアプロです。
AIによるコードの変更をリアルタイムに確認しながらその場で質問もできるため、設計やサービスの理解には役立ちます。
ただ、このやり方だと人間がAIのそばを離れられません。会話のラリーを続けるために生成されたコードをそのつど読む必要があり、別の作業に移りづらい状態でした。
理想の動作を考える
使い方を切り替えるにあたり、まずは普段の業務フローを整理し、自動化できそうな部分を洗い出しました。
開発フローを3フェーズ・7ステップに分解したところ、それまでペアプロで行っていた計画・実装の2ステップに加え、情報収集・PR作成を含む計4ステップを完全に自動化できる可能性があると考えました。
As-Is: 黄色がAIとのペアプロ
To-Be: 緑色をAIで完全自動化
なるべく完走させるために
自動化したい作業がはっきりしたので、次は「どうやってAIに任せるか」を考えます。
ここで活用したのがClaude Code Skillsです。
Skillsは、Claude Codeに対して特定のタスクの進め方を手順として定義できる仕組みです。
先ほど挙げた「ペアプロから離れられない」という課題の根本は、Claude Codeに一連の作業を任せきれないことにあります。
プロジェクトの前提知識はCLAUDE.md（Claude Codeのプロジェクト設定ファイル）に書けますが、CLAUDE.mdは会話の開始時に常に読み込まれるため、ワークフローのような長い手順まで書くとコンテキストウィンドウを圧迫します。コンテキストが長くなるほど指示が正しく実行されないケースが増えるため、CLAUDE.mdにすべてを詰め込むのは現実的ではありません。
Skillsを使うと、こうしたワークフローを手順書のように定義しつつ必要なときだけ読み込ませることができます。各ステップで何を参照し、どういう判断をし、どんな出力を期待するかを明示しておくことでClaude Codeが一連の流れを人間の介入なしに自走できるようになります。
CLAUDE.mdが「プロジェクトの前提知識」を常に伝えるものだとすれば、Skillsは「作業の進め方」を必要なときだけ渡すものです。ペアプロ型から自動化へ切り替えるにはこのSkillsの活用が適切だと考えました。
オーケストレーター型Skill
Skillsで自動化を実現する方針は固まったので、次は「どのようにSkillを作るか」を考えます。
Skillとはいえ1ファイルに大量の命令を書くと、コンテキストが長くなり指示が正しく実行されない問題が起きます。4ステップすべてを1つのSkillにまとめるのは避けたいところです。
そこで取り入れたのがオーケストレーターという考え方とSubAgent機能（親のAgentから独立したコンテキストで子Agentを実行する仕組み）です。各ステップを独立したSkillとして定義し、呼び出し順だけを管理する親のSkillを用意します。各ステップはSubAgentとして実行されるため親とは別のコンテキストで動作し、ステップごとにコンテキストがリセットされます。
この構成により、各Skillは担当ステップの手順だけを小さなコンテキストで実行できます。ステップ単位での修正や差し替えもしやすくなります。
情報取得Agentや設計Agentは、それぞれの結果を特定のフォルダにファイルとして保存します。AgentはOrchestratorに「処理が完了した」とだけ伝える仕組みです。これによりOrchestratorが調査結果を丸ごと読み込む必要がなくなり、コンテキストの圧迫を防いでいます。
成果物を別のAgentにレビューさせる
オーケストレーターとAgentの組み合わせにより、タスクを与えれば実装完了まで一撃で行えるようになりました。
この時点でSkill構築を完了しても良いのですが、実装の品質をさらに高めるために、Agentの成果物を別のAgentにレビューさせるというアイディアを取り入れました。
エンジニアの普段の開発でも、実装したものはそのまま使わず他者にレビューしてもらいます。この工程をSkillにも流用できると考えました。
親が受け取った成果物をReviewAgentに渡してレビューさせます。問題があればその内容を親に報告し、親が再度Agentに修正を依頼します。
上限回数を設けたうえでこのループを回すことで、レビューを通過するまで品質を高めるようにしました。
最終的なSkill構成
devと名付けたOrchestrator型Skillは最終的に以下のようなフローになりました。
大まかな流れ:
- ユーザーはdev Skill(Orchestrator)を呼び出し、タスクのIDを渡す
- タスクの中身を確認・更新したら内容が問題ないかを人間に最終確認
- 問題なければ後は基本的に全自動で設計・実装・PRまで行う
- 各ステップには実作業を行うAgentと、レビューを担当するAgentがペアで存在する
- 作業とレビューを繰り返すことで品質を高める
以前のClaudeCode利用との比較
Skill活用前とSkill活用後でどのような体験の差があるかを整理してみます。
| Before (ペアプロ) |
After (全自動) |
感想 | |
|---|---|---|---|
| 作業時間の確保 | ☓ | ◎ | 最終確認にOKを出したら後はVSCodeをバックグラウンドにし、他タスクの情報収集などに時間を充てることができている。 全てではないですが、修正不要でマージできるPRも結構作れている。 |
| 開発速度 | ◯ | ◎ | 実担当AgentとレビューAgentを分けたことで全自動でも品質が大きく低下することもない。 |
| 実装の理解 | ◎ | ◯ | ペアプロの頃はリアルタイムに細かな質問もできていたため、時間をかけているぶん実装の理解はペアプロに軍配が上がりました。 ただ、実装完了後のPRレビューはまず作業者である私が行うようにしているので、何も知らないということはなく他者のコードをレビューする時と同等に理解を維持できています。 |
総括
今回、作業時間を捻出するためにClaude Codeの活用方法を見直しました。
フローの整理、SkillsやAgentの活用、オーケストレーター、フィードバックループ。これらを取り入れたことで使い方を大きく変えることができ、時間の捻出だけでなく開発速度の向上にもつながりました。
まだ日が浅いため今後も調整は必要ですが、一人あたりの作業速度は明らかに向上しており、新しい使い方に切り替えた効果を日々実感しています。
今回Skillの活用によって開発体験は大きく向上しました。このアプローチは実装系業務に限らず、普段の様々な業務にも応用できるはずです。今後もSkillを使った自動化に取り組んでいきたいと考えており、またブログネタが生まれたら投稿しようと思います。
