はじめに
シリーズ最終回。第4回の5段階パイプラインの続きです。
この記事では、その5段階を「誰が・どう」回すかを扱います。
- 手順と知識を担う スキル（Skill）
- 役割と独立文脈を担う サブエージェント（Agent）
- 9体のエージェントを段階とゲートに結線する方法
📦 ソースコード：https://github.com/NeoSolleil/aim-trainer/tree/harness-only
（harness-onlyブランチ。mainは今後の機能開発で変わるため、記事と一致する状態を固定したブランチです）
↓mainブランチはこちらです
なぜ役割分担するのか
1つのAI（1つの会話文脈）で発見も設計も実装もレビューも全部やると、2つの問題が起きます。
- 文脈の肥大：あれもこれも抱えて、肝心の指示が薄まる。
- 観点の偏り：実装した本人がレビューしても、思い込みは見つけにくい。
そこで、役割ごとに独立した文脈と専門ペルソナを与えることで、それぞれの仕事に集中させ、品質を上げます。Claude Code には、これを実現する2つの道具があります。
- スキル（Skill）：「何を・どう作るか」＝手順と知識
- サブエージェント（Agent）：「誰がやるか」＝役割・観点・道具・独立文脈
関係はシンプルです。サブエージェントがスキルを呼び出して作業します。
スキル（Skill）— 手順と知識を一元化する
.claude/skills/<名前>/SKILL.md にMarkdownでスキルをDRYに定義します。本プロジェクトでは11本作りました。
- 段階駆動5本：discover / specify / plan / tasks / implement（各段階の手順）
- ドメイン参照6本：用語集 / BDDの書き方 / バック・フロントのアーキ / デザイン / E2E（知識）
スキルとエージェントのファイル配置はこうです。
.claude/
├── skills/ # 11本
│ ├── discover/ specify/ plan/ tasks/ implement/ # 段階駆動（人間が /コマンド で起動）
│ └── ubiquitous-language/ bdd/ backend-architecture/
│ frontend-architecture/ design/ e2e-testing/ # ドメイン参照（自動読込）
└── agents/ # 9体
├── product-analyst.md quality-analyst.md solution-analyst.md # 発見の3アミーゴス
├── scenario-author.md backend-engineer.md frontend-engineer.md # 清書・実装
└── spec-compliance.md test-coverage.md code-reviewer.md # レビュー役
段階駆動スキルには、フロントマターに disable-model-invocation: true を付けました。これは「AIが勝手に発動せず、人間が /specify のように明示的に呼んだ時だけ動く」設定です。SDDのゲート（人間が段階を進める）を、呼び出しレベルでも守らせる工夫です。
---
name: implement
description: SDD段階4（実装）。TDD（red→green→refactor）で…
disable-model-invocation: true
---
（ここに手順をMarkdownで書く）
参照スキルは逆に自動で読み込ませ、必要に応じてAIが知識として引きます。なお参照スキルは「原則は汎用、固有データ（用語集やデザイン値）は差し替え可能」と明記し、他プロジェクトでも再利用できる形にしました。
サブエージェント（Agent）— 役割と独立文脈を与える
.claude/agents/<名前>.md に、役割・ペルソナ・使える道具を定義します。9体作りました。
ワーカー役（スキルを呼んで実作業）
- product-analyst / quality-analyst / solution-analyst（発見のスリーアミーゴス：価値・品質・実現性の3視点）
- scenario-author（EARS＋Gherkin の清書）
- backend-engineer / frontend-engineer（TDD実装）
レビュー役（独立文脈で検証。コードは直さず指摘のみ）
- spec-compliance（仕様どおりか・スコープ逸脱はないか）
- test-coverage（全要件にシナリオ・テストがあるか）
- code-reviewer（バグ・可読性・重複）
各エージェントの冒頭にはペルソナを置きました。「あなたは経験豊富なシニアバックエンドエンジニアです」のように役割を明示すると、出力の水準が上がります。レビュー役は道具を読み取り専用に絞り、「直さず指摘する」を構造で担保しています。
結線：スキルとエージェントとゲートをつなぐ
道具を並べただけでは動きません。どの段階を誰がやるかを結線しました。
- 各段階スキルに「実行はこのエージェント」と明記（例：discover＝3アミーゴス、specify＝scenario-author、implement＝engineers）
- 発見では、3アミーゴスが並行に観点を出し、統合は進行役が1箇所で行う（同じファイルへの同時書き込みを避ける）
- 実装の後は、レビュー役3体を回し、指摘をワーカーが直し、全クリア＋人間承認まで繰り返す
これで「9体のエージェントが、スキルとゲートに沿って、実際の流れの中で動く」状態になります。
シリーズのまとめ
5回にわたって、AIに仕様駆動開発を“強制”するハーネスを組みました。
- 総論：禁止は文章でなく仕組みに置く
- 指示と文脈の層：CLAUDE.md（索引）と .claude/rules/（パス別ルール）
- 機械強制：import-linter / pre-commit / Claudeフック / CI で「やったら止める」
- SDDパイプライン：発見→仕様→設計→分解→実装＋人間ゲート
- スキルとサブエージェント：役割分担で品質を上げる
ここまでで、**アプリのコードを1行も書く前に「設計どおり作らせ続ける枠組み」**が完成しました。次は、この上で実際に最初の機能を回し、ハーネスが本当に逸脱を止めるかを実地で検証していきます。その記録は、また別の機会に。