はじめに
最近学んだハーネスエンジニアリングをIBM Bob 上で実践してみたいと考えていたところ、非常に分かりやすい解説動画に出会いました。
本記事は、その動画内容を整理しつつ、どう実践するのかという 方法論 にフォーカスしてまとめたものです。
今回はまだ検証途中のため、結果や効果の比較ではなく、
実践するための最小構成と回し方のみを扱います。
参考にした動画はこちらです。
1. 動画のまとめ
そもそもハーネスエンジニアリングとは、
AIに直接「作らせる」のではなく、
複数の役割を持つAIを、決められた順序と情報の流れで動かす設計手法
です。
この考え方をAI駆動開発に落とし込むと、一手法として
複数エージェントをスプリント開発で回すという形が取れる。
大まかな流れは、３ステップ
- 3つのサブエージェントを作成
- initでAgents.mdを作成し、エージェントが協働できるように共通コンテキストを読み込ませる
- スプリント開発でエージェントを切り替え、自己改善ループを回す
2. 最小で成立する役割分担（3サブエージェント）
実践では、役割は増やしすぎない方がうまく回ります。
今回は以下の 最小構成 を採用します。
Planner
- 再現範囲の整理
- スプリント定義
- 受け入れ基準の明文化
👉「何を作るか」「どこまでやるか」を固定する役割
Generator
- UI・機能の実装
- Plannerの定義をコードに落とす
👉「手を動かす」役割
Evaluator
- 動作確認
- 仕様ズレの確認
- UI / デザイン品質の評価
👉「品質を止める」役割
（今回はデザイン観点を強化）
この3つを 混ぜない ことが重要です。
3. initで作る agents.md（コンテキスト設計）
ハーネス設計で最も重要なのが 最初の共通コンテキスト です。
init時に、全エージェントが参照する agents.md を作成します。
# agents.md
## プロジェクト目的
- ハーネス設計による開発品質の変化を検証する
- 完全再現ではなくUIと導線の簡易再現をゴールとする
## 評価の最重要軸
- デザイン品質
- 余白・色・タイポグラフィの統一感
- CTAの視認性と導線
## 制約
- Next.js App Router
- 機能過多は禁止
- UIの粗さが残る実装はNG
## 完成条件
- 入力から結果表示まで迷わず到達できる
- 見た目の破綻がない状態
ここでのポイントは、
- 判断基準を書く
- やらないことを書く
- 全員が同じ前提を持つ
これがないと、スプリントを回すほど品質がブレます。
4. スプリント駆動で回す開発フロー
基本フロー
各スプリントでは、必ずこの順番を守ります。
Plan（Planner）
↓
Code（Generator）
↓
Evaluate（Evaluator）
↓
修正 → 合格 → 次スプリント
Evaluatorは「止める役」
Evaluatorでは必ず以下を確認します。
- デザインにムラがないか
- 余白・文字サイズ・色が揃っているか
- 「まぁいいか」で流していないか
合格しない限り、次に進みません。
これにより、
- 小さな違和感が蓄積しない
- スプリントごとに品質が上がる
- 最終盤での大修正が消える
という効果が出ます。
IBM Bobでの実装
上記の 3 ステップに沿って、IBM Bob 上で開発を進めています。
IBM Bob にはデフォルトでPlan / Codeモードがあり、
それぞれPlanner / Generatorに対応します。
そのため、
- カスタムモードで Evaluator を1つ追加する
- agents.md で Code → Evaluator を回す設計にしておく
だけで、最小構成のハーネス設計が成立します。
不安な場合は Plane に評価観点を軽く書き込んでおくのも有効です。
まとめ
今回は、実践ハーネスエンジニアリングの方法論 に絞って整理しました。
- 役割を分ける（サブエージェント）
- 共通コンテキストを用意する（Agents.md）
- スプリントとレビューを必ず挟む（スプリント開発）
この型があるだけで、
AI 駆動開発の質が上がるのではと感じています。
実践した結果については、また別記事でまとめる予定です。