開発チームに Claude Code を入れてコードを書く速度は上がりました。それでも、進め方は各メンバーの頭の中にあり、品質の確認も人手のままでした。この記事では、要求の受け付けからリリースまでの全工程にスキルを1本ずつ割り当て、1ヶ月運用してわかったことをまとめます。

---

対象の案件と体制

進行中の Web アプリケーション開発案件です。別チームが管理するデータ基盤と連携する機能があり、開発もリリース日も基盤側とは分かれています。体制はお客様のプロダクトマネージャーを含めて6人です。

開発自体は約6ヶ月前から動いていて、直近1ヶ月でこの進め方に切り替えました。使っているツールは次のとおりです。

属人化と人手の品質担保をやめたかった

切り替える前に困っていたことは3つあります。

進め方が担当者の記憶にあるため、担当が替わると同じ順番で進みません。メンバーごとに独自の手順が生まれ、隣の人が見つけた改善が他のメンバーに届きません。そして品質の確認が人手に残っているため、見落としが個人の集中力に左右されます。

コードを書く速度だけが上がると、この3つがそのままボトルネックになります。速く書けるほど、着手前の仕様確定と、書いた後のレビューやテストが詰まっていきました。運用ルールを増やして解決する話ではないと判断し、仕組みの側で無くすことにしました。

スキルで駆動する4つの原則

プロセス設計の土台として4つの原則を置き、それぞれを案件の運用に落としました。

「スキルで駆動する」を全工程に当てているのは、実行される場所に手順を置かないと運用されないからです。手順書を別に用意しても、作業のたびに読み直す運用は続きません。

「フローと確定を分ける」は運用を始めてから追加した原則です。ウォーターフォールの案件なら要件定義書や基本設計書がフェーズごとに確定していきますが、アジャイルでお客様と議論しながらチケットを更新していくと、確定した仕様と検討中のやりとりが同じ場所に混ざります。混ざったチケットを AI に読ませた結果、実際に古い仕様のまま実装されたことがありました。

仕様・開発・受け入れの3サイクル

全体は3つのサイクルに分かれます。仕様サイクルは Ready になるまで回し続け、開発サイクルはマージまで PR の中で回し、受け入れサイクルは STG で確認して受け入れます。

サイクルをまたぐルールは1つだけです。Ready でないものは下流に流しません。着手の条件（Definition of Ready）と完了の条件（Definition of Done）を決めておくと、手戻りがかなり減ります。

仕様サイクル: 未決論点を探しに行かない

仕様サイクルは会議を起点にした5ステップです。

1. アジェンダ作成（backlog-agenda-prep）
2. 打ち合わせと文字起こし
3. 議事録の作成と Request / User Story の起票（backlog-meeting-sync / backlog-story-breakdown）
4. Readiness 判定（backlog-request-readiness / backlog-userstory-readiness）
5. Ready なら開発サイクルへ、Not Ready なら確認質問がチケットに残る

このうち効果が大きかったのはアジェンダ作成です。Readiness スキルが出した確認質問、未決のコメント、期日切れやブロッカー、方針の矛盾を Backlog 全体から横断で集め、論点・背景経緯・確認したいこと・関係者・想定オプションの形に整理してドキュメント化します。会議の前に「何を決めるんだっけ」を探す作業がなくなりました。

議事録の反映では、議論の経緯をドキュメントに残し、確定した仕様だけをチケットに書きます。文字起こしから要約を作り、言及された既存チケットへ決定事項をコメント追記して、紐付かないものだけ新規起票します。同じ情報を二か所に持たないためです。

Readiness の判定観点

Readiness の判定は Request と User Story で分けています。

外部インターフェースへの波及は、実際に効いた観点です。たとえばアプリケーション側でデータを作成・更新し、それを upsert 専用の連携でデータ基盤へ渡している構成では、アプリケーション側で物理削除しても削除だけが下流に届きません。連携先や分析基盤に残り続けます。この始末を要求として定義しているかを、User Story の段階で聞きます。

不足があった場合、スキルは減点をせずに観点ごとの確認質問を生成してチケットへコメント追記します。その質問が次回のアジェンダに拾われ、打ち合わせで解消されます。User Story より下への分割はしません。実装レベルの検討は開発サイクルで扱います。

開発サイクル: チケット番号だけで着手する

開発の着手時に渡すのは User Story の番号だけです。番号を渡せば、Backlog MCP 経由でチケット本文・コメント・親子関係を読んでブレインストーミングから入れます。仕様を口頭で引き継がないので、その人だけが仕様を持っている状態になりません。仕様がチケットに集約されているから成立する進め方です。

作業場は User Story ごとに git worktree で分けています。同時に複数本を走らせられるので、レビュー待ちで手が止まりません。

実装は Superpowers の標準開発フローに乗せ、ほとんどカスタマイズせずに使っています。設計、計画、実装、レビュー、完了前チェックが同じ枠でつながるため、工程の受け渡しで文脈が落ちません。計画のタスク単位に新しいサブエージェントを割り当てる作りになっているので、長い会話で汚れた文脈のまま書き続けることもありません。

人が見る前に5つのゲートを通す

マージ前に dev 環境で機械のゲートを通し、そのあとに人が見ます。ここまでが完了の定義（DoD）です。結果はいずれも PR にコメントとして貼ります。

AI レビューで判定するのは2点だけです。チケットに記載された内容を満たしているか、実装として妥当か。実行時に対象チケットを指定するので、差分だけを見るのではなくチケットを正として突き合わせます。

機械が通せるものを人が見ないという順序を固定したのが、この5段の目的です。ゲート1から3を通して指摘が解消された後に人間がレビューします。

AI テストは実機の証跡で判定する

AI テストではログイン済みブラウザを実際に操作して画面を検証します。ソースコードは挙動の裏付けと再現手順の特定に使います。観点は2種類です。

1つ目は標準の QA チェックで、スキル側に定義しています。

• リロード時の挙動（作成・編集した状態が永続するか）
• ブラウザバックとフォワード時の挙動
• コンソールエラーの有無
• 各入力操作時の挙動と入力値の境界値
• 0件・1件・N 件・上限超過の表示
• ボタン連打時の二重送信

React のようにフロントエンド側で状態を持つ構成では、画面に成功トーストが出てもデータベースに届いていないことが起こり得ます。そのため「保存に成功した」と「一覧に反映された」を別のものとして扱い、保存直後とリロード後の両方で反映先を見ます。こうした実運用で問題になる観点をスキル側に溜めていきます。

2つ目は受け入れ条件（AC）の充足確認です。チケットに書かれた受け入れ条件を1つずつ検証手順に落とし、✅ / ❌ / ⚠ で判定して、何を操作して何が起きたかを根拠として添えます。該当しない観点は「N/A ＋ 理由」で明示します。操作していないものを OK にせず、確認できなければ「未確認」と正直に残す運用です。水増しした ◯ はレポート全体の信頼を損なうためです。

不具合はマージ前後で分ける

不具合の扱いを、マージ前に見つかったかマージ後に見つかったかで分けています。

マージ前、つまり AI レビュー・AI テスト・人間のレビューでの指摘は Bug として起票しません。同一 PR 内で修正してレビューとテストを再実行し、指摘と対応の記録は PR コメントに残します。未マージの修正が独立した課題として残らないようにするためです。

マージ後、リリース後や後続の動作確認で発覚したものは Bug を起票します。起票時は検出環境（dev / STG / 本番）を属性で持たせ、起因の Request を親課題、起因の User Story を関連課題でリンクします。関連チケットへコメントし、Slack へ自動通知して対応を促したうえで、以降は通常の開発フローに乗せます。

親子は1階層までという Backlog の制約があるため、Bug は User Story の子にできません。そのぶん検出環境を属性に持たせておくと、商用障害の月次件数も STG での検出率も検索条件1つで出せます。

会議・課題・時間のトリガーで自走させる

3つのサイクルとは独立に、チケット全体を健全に保つ層を置いています。何もしないと情報が自然に古くなるためです。

どのスキルも提示、承認、実行の順で動き、承認なしにチケットを更新しません。

1ヶ月でどこが速くなったか

工程ごとに変化を並べると、速くなったところがはっきり偏っています。

良くなったことは3つあります。

dev の preview が早く出るようになり、関係者が早い段階で実物を触れるようになりました。結果としてフィードバックが増えました。会議の前に未決論点を探す作業は消え、アジェンダが Backlog 全体から自動で組み上がるようになりました。そして進め方がスキル定義として書かれているので、誰がやっても同じ順番で進み、改善もそこに書き戻せます。

うまくいっていない3つのこと

AI の過剰な情報生成と過剰検出。 Request と User Story だけで、数週間で150枚まで積み上がりました。自分が起票していないチケットも増えるため、把握していないチケットが増えていきます。スキルが拾ってくる論点も指摘も、量が人の処理能力を超えます。150枚なら追えても、これが1000枚に増えたときには追えません。全部に目を通す前提で設計すると破綻するので、何を見ないかを決めるのが次の課題です。

リードタイムは劇的には縮まない。 AI レビューの指摘は毎回1〜2件ほどあり、そのうえで人間のレビューでも1〜2件付きます。最後は人が承認する設計なので、そこが律速になります。プロダクトマネージャーとソフトウェアエンジニアの意思決定も待ちになりやすく、人間のレビューはまだ軽くなっていません。

AI にコンテキストがない。 開発は6ヶ月前から動いていて、その経緯が AI にありません。いま出ている指摘の多くは、その不足を埋める作業になっています。チケットのコメントには過去のやりとりも残るため、仕様を A から B にして A に戻した経緯を読んだ AI が、B で実装してしまったこともありました。

いま打っている手

1つ目には、スプリントで情報の濃度を分ける方針で対応しています。直近のスプリントは濃く、先のスプリントは薄く見る。先の分は優先度を下げ、意図的にコンテキストへ入れません。スキルも、先のスプリントのアライメントを取るものと直近を整える管理のものに分けます。

2つ目は、価値を早く当てて切る方向です。投資対効果に響かない管理画面の小さな不具合は捨て、コア機能に寄せます。ただし、これで縮むのは前半だけです。残り半分はプロダクトマネージャーとソフトウェアエンジニアの判断に必要な時間で、代われません。関連情報をまとめて支援するところまでが限界です。レビューは担当者どうしのナレッジ共有の時間にもなっているので、削らずに残します。

3つ目には、先に挙げた「フローと確定を分ける」原則を当てました。確定した仕様と検討中のやりとりを分け、古い情報が AI に入らない状態にします。入らなければ古い実装は出ないという見立てで運用を始めたところで、効果はまだ測れていません。

PR で人が見る5点

機械のゲートを通した後に人が見る観点も、明示して分けています。

まとめ

1ヶ月運用して、持ち帰れたことは4点です。

1. 進め方を書き出す。 手順を人の記憶から出して読める形にすると、誰がやっても同じ順番で進み、担当が替わっても再現します
2. 関門を2つ置く。 着手の条件と完了の条件だけを決め、Ready でないものを下流に流さないようにします
3. 機械と人の担当を分ける。 CI、AI レビュー、AI テストで機械が通せるところまで通し、人は最終判断と例外だけを見ます
4. 確定と検討中を分ける。 AI が読むのは確定した側だけにします。混ざると選別の手間が生まれ、古い仕様のまま実装されます

そのうえで、速くなるのは AI が担う工程だけでした。AI に大胆に工程を担わせるには、その前の準備が8割を占めるというのが1ヶ月の実感です。

KDDIアイレットでは、こうした工程の標準化をサービスとしても提供しています。要件定義の型づくりは AIDD 要件定義、プロジェクト運営そのものへの導入は AIDD PMO で扱っています。実際の導入内容は要件定義を標準化し開発の手戻りを削減した事例にまとめています。

進め方の標準化からご相談いただけます。お気軽に KDDIアイレットへお問い合わせください！