「AIを導入したが、成果物がバラバラ」——この問題は、ツール選定ではなくプロセス設計の失敗として捉える必要があります。Claude Codeのスキルとサブエージェントを組み合わせたワークフロー自動化を実践したところ、デリバリー速度が約3倍になったという報告が日本の開発現場から出ています。注目すべきは速度の数字より、その裏にある設計思想です。
なぜ「人がAIに指示する」モデルでは標準化できないのか
アジャイル開発チームにAIコーディングツールを導入する際、最初に陥りやすい罠があります。それは「各メンバーが個別にAIに指示を出す」運用です。この構造では、成果物の品質がメンバーのプロンプト力に依存します。テストを書くかどうか、設計書を残すかどうかが個人の裁量になり、スプリントレビューで確認できる成果物の形式が毎回異なってきます。
スクラムにおける「完成の定義（Definition of Done）」は、チームが合意した品質基準のことです。コードが動くだけでなく、テストが書かれている・レビューが通っている・ドキュメントが存在する、という条件を満たして初めて「完成」とみなす取り決めです。ところがAIへの指示が個人に委ねられていると、この完成の定義をAIが守るかどうかも人依存になります。
シード記事が提案した解決策は、AIへの指示そのものをプロセスとして定義し直すことです。「コードを書いて」という一言から、設計書生成→実装→コードレビュー→テスト実行→デプロイ→引き継ぎマニュアル生成までを固定順序で実行する仕組みを作りました。誰が起動しても同じフローが走るため、完成の定義がツールレベルで強制されます。
オーケストレーターとサブエージェントで「役割分担」を再現する
Claude Codeには「スキル（ワークフローの手順書となるMarkdownファイル）」と「サブエージェント（独立したコンテキストで動く実行ワーカー）」という2つの拡張機構があります。スキルが指揮者、サブエージェントが演奏者という関係です。
この設計が興味深いのは、実際の開発チームの分業体制をそのままAIエージェントに写している点です。設計者・開発者・レビュア・QA・デプロイ担当者の6つのペルソナをサブエージェントとして定義し、それぞれが担当フェーズのみを実行します。たとえば設計者ペルソナには深い思考が必要なため上位モデルを割り当て、機械的な処理が中心のペルソナには軽量モデルを使うという使い分けも可能です。
サブエージェントはコンテキストを引き継がないという制約が設計上の核心です。前のペルソナが何を決めたか、どのファイルを生成したかを自動では知りません。そこでオーケストレーター（スキル）は委譲のたびに以下を明示的に渡すよう定義されています。
- 利用者の要件の要約
- プロジェクトの絶対パス
- 前のペルソナが生成した成果物のパス
- 差し戻し時の修正指示と指摘事項の全文
- ドキュメントの命名規則
この「引き継ぎ情報の明文化」は、人間のチームでいうスプリントの引き継ぎドキュメントや、チケット管理ツール上のコメント履歴に相当します。コンテキストの断絶を設計で補う発想です。
「どこで人間が判断するか」の線引きが運用品質を決める
フルワークフローの中で利用者に確認を求めるのはデプロイ先の確認だけ、というルールが設計されています。レビューや品質チェックでの差し戻しはすべて自動でループします。この「どこで止めてどこで止めないか」の設計は、チームの自律性とリスク管理のバランスを決める重要な判断です。
アジャイル開発では、素早いフィードバックループを回すことで品質を担保します。このワークフローはレビュー→差し戻し→修正→再レビューを自動化することで、フィードバックループの1サイクルを人間の作業なしに回します。ただし環境を壊すリスクのあるデプロイだけは人間の判断を介在させる設計にしています。
もう1つ注目すべき設計ポイントは、エージェントに「わからない」と言わせるガードレールです。前提情報が不足している場合に勝手に推測して進まず、停止レポートを返す仕組みです。これはテスト駆動開発でいう「レッドフェーズで止まる」感覚に近く、不確かさを曖昧なまま進めない規律をツールレベルで実装しています。
加えて、APIのハルシネーション（AIが実在しないメソッドや仕様を生成してしまう現象）対策として、1,000ページ超の公式リファレンスをローカルにインデックス化し、Web検索を禁止して唯一の正本として扱う設計も採用されています。情報源を一本化することで、バージョン違いの情報や非公式情報による誤実装を防いでいます。
開発チームがAIを導入する際に最初に問うべき問いは「どのツールを使うか」ではなく、「どこまでをツールが決め、どこから人間が判断するか」です。その境界線を設計として書き下すことが、AI駆動開発における新しいプロセス設計の核心といえます。