チーム全員のカレーが、毎回同じおいしさで出てくるようになりました。
——とはいっても、料理の話ではありません。開発フローの話です。
少し前まで、チームの開発フローは「自己流のカレー」でした。リンゴを入れた日、にんじんを入れ忘れた日、鶏肉も牛肉も入れたら格段に美味しくなった日。それぞれおいしい（稀に味を一から立て直すことも…）。ただ、工程も気をつけるポイントも、人ごと日ごとに少しずつ違っていて、毎回同じおいしさにはなりませんでした。
タスクを進めるときに Claude Code へ「Issueを確認して」「ブランチを切って」「実装して」「PRを作って」「レビュー依頼して」と1個ずつ指示していた頃の話です。
そこで開発フローをレシピ化しました。タスク開始からデプロイ完了までを丸ごと Claude Code のスキルにして、コマンド1つで起動できるようにしました。やってみたら、思っていた以上のことが起きました。
- 1行直すと全員の料理が進化する: 一人の改善がチーム全員のフローに漏れなく届く
- ワンタッチで長い工程が最後まで走る: 起動して他の作業をしている間に、確認ポイントまで運ばれてくる
- レシピは今も進化中: レトロや日々の気づきが、そのまま開発フローに入っていく
この記事では、execute-task という開発フロースキルを例に、「開発フローをスキル化する」と何が起きるのかを書きます。
execute-taskスキルとは
execute-task は、タスク実行のライフサイクル全体を管理するオーケストレーターです。
/execute-task <issue-number>
コマンド引数の前提（読み飛ばし可）
チームではタスクを GitHub Issue で管理しており、リポジトリの .claude/ 配下に GitHub Projects などの情報を集約しています。そのため <issue-number> 1つあれば Claude Code 側で対象 Issue を特定できるようになっています。
このコマンド1つで、以下の5フェーズが順番に走ります。
Phase 1: タスク開始（背景・目的の確認、関連調査、ブランチ作成）
Phase 2: 作業（仕様駆動でコード実装・テスト・AIレビュー）
Phase 3: PR作成・セルフチェック・修正・dev環境へのデプロイ・動作検証
Phase 4: レビュー・マージ
Phase 5: 完了処理（ステータス更新、バックログ更新）
execute-coding や execute-release などのサブスキルも内部で呼び出しながら、各フェーズを進めていきます。
execute-task（オーケストレーター）
├── execute-coding コード実装・テスト・AIレビュー
├── execute-release リリース・デプロイ
├── execute-deploy CDKデプロイ実行・検証
├── github-utils GitHub操作（Issue編集、PRコメント等）
├── opsx:archive OpenSpecアーカイブ
├── create-task 別タスク切り出し
└── create-product-backlog 別ストーリー切り出し
人間がやることは、要所の確認ポイントで判断を下すだけです。確認ポイントは大きく次の5つに整理されています:
- タスクの目的・背景の理解確認
- コード実装方針（仕様駆動での確認）
- PRの確認（AIレビュー結果と差分などから修正指示）
- デプロイ前の確認
- デプロイ後の動作検証結果の確認
実装の細部、PRテンプレ、レビュー依頼のフォーマット、バックログ更新。全部スキルが面倒を見ます。
自分のチームでは、タスクは全て execute-task のスキルを使います。チーム全員のフローとして運用しているスキルです。
ここからは、execute-task を運用してみて起きた3つの変化を順番に書いていきます。
1行直すと全員の料理が進化する
スクラムのレトロでトライを決めても、人なので忘れることもある。忙しいので日々の作業に取り込むのが後回しになることもある。
でも execute-task のスキルに1行書き足してマージしてしまえば、次から全員のフローに自動で組み込まれます。チーム全員の Claude Code が新しい手順で動き始めます。
「このトライやりました？」ではなく「どうだった？」から、改善の議論が始まるようになりました。
毎日「タスクでこれを忘れないように」と全員に伝えて確認の時間を取るくらいなら、その時間を「抜け漏れの起きにくいレシピに組み込む時間」に振り替えたほうが確実です。
Markdown を数行書き換えるだけで、作業手順がアップデートされる。 共有リポジトリを pull すれば、全員の Claude Code が新しいフローで動く。1人が改善すれば、全員が恩恵を受ける。まさに、属人化していない集合知です。
ワンタッチで長い工程が最後まで走る
もうひとつ効いたのは、起動して放っておけるようになったことでした。
導入前は、Claude Code に1個ずつ指示を打っていました。Issue確認、ブランチ作成、実装、テスト、etc…。都度「これやって」「次あれやって」と言わなければいけない。これに頭のリソースを費やし、それでも時々何かを忘れてしまう。スキルにしてフェーズを書き切ってしまえば、忘れようがない。長い工程ほど、レシピ化の価値が出ます。
導入後は、/execute-task <issue-number> を叩いてしまえば、確認ポイントまで運ばれてきます。確認ポイントはだいたい前述のとおり。あとは指示しなくても順番に進みます。
つまり、タスクを起動した直後、自分は別タスクやレビューができる。Slack に返信できる。あとは適宜戻ってきて、本質的・リスクが大きい点に関してのみ確認・判断すればよくなりました。
自然と並行作業ができるようになっており、「うまくいった」と実感しました。
レシピは今も進化中
レシピは1回書いて終わりではありません。今もどんどん進化しています。レトロやふだんの作業で「もっとこうしたい」とチームから上がってきた改善が、ほぼそのままスキルに乗っていきます。
スキル作成からの主な更新と、それぞれの修正の意図はこんな感じです。
| 時期 | 更新内容 | 修正の意図 |
|---|---|---|
| 作成時 | 初版。タスク実行の手順をそのままスキルに落とし込んだ | タスク実行の手順をそのままスキルに落とし込む |
| 2,3週間後 | 作業者セルフチェック停止ポイントを追加（後述） | このまま使うと使いづらかったので停止ポイントを入れる |
| 1か月後 | デプロイ確認とコンフリクト解決の人間承認を追加 | リスクが高いところでしっかり止める |
| 2か月後 | Phase 1の確認を1回にまとめた | 不必要な確認ポイントを減らす・まとめる |
| 2か月後 | 親ストーリー・プロダクトバックログの更新フック、Tシャツサイズ（S/M/L）を見積もり項目に追加 | レトロの改善を皆が使っているフローに追加すれば意識少なくできることに気づいた |
| 3か月後 | スキルのフロントマター整備でトークン消費を削減 | 同上 |
レトロや日々の作業から出た改善が、ちゃんとレシピに入り続けています。
作業者セルフチェック停止ポイントを追加した「経緯」
最初に作ったスキルは、人がやっていた開発フローをそのままなぞった作りでした。
ところが運用してみると、「ここは AI に任せきりにすると危ない」というポイントが見えてきました。仕様や暗黙的なドメイン知識を持って判断する場所、リスクが大きい場所。もともと人間の責任で自然と止まっていたところを、AI に開発を任せる前提で改めてチェックポイントとして組み込み直す必要がありました。
きっかけはこんな出来事です。
お昼休み前に execute-task のスキルを起動して席を立ち、戻ってきたらステータスが「レビュー待ち」になっていました。作業者の確認なしにレビュー依頼が飛んでしまっていたのです。何度か同じことを繰り返してしまいました。
構造は単純で、AIレビュー投稿 → ステータス変更 → レビュアーアサインが一気に流れていて、作業者が止まる場所がなかっただけでした。
対策として Phase 3 に「作業者セルフチェック（必須停止ポイント）」を入れました。
## Phase 3: PR作成・Pre-Review
### ★ 作業者セルフチェック（必須停止ポイント）
- PRの差分を確認
- AIレビューの指摘内容を確認
- 問題なければ「OK」と回答 → レビュー依頼へ
この一件で気づいたのは「スキルを使うと意識せずにどんどん進んでくれる。だからこそ、止めるべきポイントには明示的にストッパーをかける」という設計の方針でした。デプロイ確認も、コンフリクト解消の承認も、同じ考え方で後から追加されています。
効果
量と質の変化（参考）
チームのマージPR数と、execute-task スキルの運用に乗ったかを示す質的指標の推移です。
| 月 | スキル作成月との関係 | PR / 人 | AIレビュー対応PR% | OpenSpec 維持PR% |
|---|---|---|---|---|
| 2025-12 | 3か月前 | 3.25 | 0% | — |
| 2026-01 | 2か月前 | 3.25 | 0% | 0% |
| 2026-02 | 1か月前（Claude Code と仕様駆動開発の導入） | 12.75 | 2% | 0% |
| 2026-03 | execute-task スキル作成月 | 13.0 | 17% | 33% |
| 2026-04 | 1か月後 | 7.33 | 50% | 71% |
| 2026-05※途中集計 | 2か月後 | 2.0 | 100% | 100% |
- PR / 人: 1人あたりマージPR数。改善活動の小タスクは除外。
- AIレビュー対応PR%: チームで決めた「セルフAIレビュー対応してからレビュー依頼」のルールを守っているPRの割合（明らかに不要なPRは除く）。
- OpenSpec 維持PR%: チームで決めた「 OpenSpec アーティファクトを実装中・後に実態に合わせて更新」のルールを守っているPRの割合。
- ※ 5月は途中集計です。
正直な課題
- レトロで新しく追加したトライがスキルに反映されるまでにはタイムラグがある。その間は自分で覚えておいて、Claude がやらなかったときに手動で指示する必要があります（ここは正直めんどくさい）。スキル更新が追いつけば解消される課題ですが、ゼロにはなりません。
- レシピのアップデート自体にもそれなりに時間がかかっています。斧を研ぐような時間で、将来の作業効率を考えれば必要な投資と認識・チームでの合意はあります。ただ、「レシピのアップデートも効率化したい」という声がレトロで上がっています。次に取り組みたいテーマです。
- 3点目、Claude自体の限界なので、↓のとおり目立たせます。
これから作る人へ
ここからは、同じことをやろうとしている人向けです。
最初は雑でいい
最初は、Claude Code のセッションで1タスクを進めたあとに「この工程をスキル化して」と頼み、「汎用的になるように」と指示してうまく抽象化させる、というのがスタートでした。完璧じゃなくていい。使いながら「ここ足りない」「ここ自動で流れすぎて怖い」と気づいたところを PR で直していけば、それが進化になります。
正直、最初の明文化と形になるまでの修正はしんどいです。でも1回書いてしまえば、品質が良いものをすごい速さで出し続けられると思ってやりました。
設計で意識した3点
既に文中にありますが、自分たちのチームで時間をかけてたどり着いたポイントが、最初から取り込めるはずです。スキルを設計するときに意識した3点を整理しておきます。
1. 自動化と人間の判断を明確に分ける
「ここは止まるべき」というポイントを増やしたり、減らしたりしています。どこまで Claude Code に任せて、どこで人間が判断するか。必要と思った確認ポイントが不要になったり、その逆もあったり。チームの状況・経験で変わってくるので、柔軟に変えられるようにしています。
2. 口頭の運用ルールをスキルに落とし込む
「デプロイだけ注意しよう」のような口頭の約束は忘れます。スキルに入れてしまえば忘れようがない。レトロで決まったルールは適宜スキルに書き込めばよいことに気づき、楽になりました。
3. みんなで育てる前提で作る
最初から完璧を目指さず、とりあえず簡単に使えて便利というところから始めました。みんなで使う・改善するという認識を自然と一致させることができ、うまく成長していっています。
Claude Code スキルの基本的な作り方については、公式ドキュメントを参照してください。SKILL.md のフロントマターやディレクトリ構造の詳細が載っています。
まとめ
開発フローをスキルにすると、3つのことが同時に手に入りました。
- 1行直すと全員の料理が進化する: 改善が漏れなく全員に届く
- ワンタッチで長い工程が最後まで走る: 起動して他のことをしている間に、確認ポイントまで運ばれてくる
- レシピは今も進化中: レトロや日々の気づきがそのまま開発フローに入っていく
カレーのレシピを作るのは大変です。最初の明文化は骨が折れます。でも一度書いてしまえば、毎回同じおいしさのカレーが出てくる。しかもレシピは育つ。誰かが「ウインナーを入れると美味い」と気づいたら、それが全員のレシピになる。
開発フローも、同じです。
Discussion