ハーネスエンジニアリングをさらに進める

ここまでで、agent-builder-kit を使って、要求整理、chunk / ticket 分解、実装、記録、status 昇華までを一通り回せるようになりました。 ただし、これでハーネスエンジニアリングが完成したわけではありません。

むしろ今の kit は、使い始めやすさと汎用性を優先した、最小構成に近いものです。 ここから先は、project の規模や要求水準に応じて、さらに足場を強くしていく必要があります。

そもそもハーネスエンジニアリングとは何か

OpenAI の Harness Engineering で語られているのは、単に agent を賢くすることではありません。 agent が実運用の開発フローに入り込めるよう、評価、レビュー、実行境界、補助ツール、運用上のガードレールまで含めて整えることが主題です。

この見方に立つと、今の agent-builder-kit はすでに入口には立っています。 AGENTS.md、docs/exec-plans/、fact-report、.canvas によって、人間と agent が同じ source of truth を見ながら進める足場はできています。

一方で、スケールさせるにはまだ足りないものもあります。

今の kit ができていること

現時点でも、次の点はかなり強いです。

• role ごとの境界が docs と Skill で明示されている
• block / chunk / ticket / fact-report の流れが固定されている
• .canvas で開発フローを視覚化できる
• 作業結果が会話ログだけでなく docs に残る

この土台があるからこそ、あとから機能を拡張しても、どこへ組み込むかを議論しやすくなっています。

まだ足りないこと

今の agent-builder-kit は、まだ単一セッション寄りです。 複数の agent が同時並行で大きな project を回すには、次のような点が不足しています。

• 並列化可能な ticket を視覚的に見分ける仕組み
• 別セッションで同時に ticket を回すときの運用ルール
• CI/CD のような自動検証レイヤ
• より厳密な境界分離を支える設計支援

このあたりは、project が大きくなるほど重要になります。

マルチエージェント化するなら

今の流れをそのまま拡張するなら、まずは chunk と ticket の並列化条件をもっと明示するのが自然です。

たとえば、

• 並列実行してよい ticket を .canvas 上で色分けする
• 競合しない editable_paths を持つ ticket だけを別セッションへ渡す
• depends_on がない ticket を同時に回す

といった運用が考えられます。

このとき大事なのは、「並列で回せそうだから回す」のではなく、「境界が見えていて衝突しないから並列で回せる」状態にすることです。 その意味で、将来的には .canvas の managed lane に、並列実行可否や担当色を持たせる拡張もありえます。

CI/CD は入れるべきか

結論から言うと、実運用を強めるなら入れるべきです。 今の kit は、ローカル build や reviewer handoff までは扱えますが、継続的な自動検証までは標準で持っていません。

ただし、CI/CD は project 依存がかなり強い領域です。 どのテストを必須にするか、どのブランチ戦略を取るか、どこで deploy するかは、成果物によって大きく変わります。

そのため agent-builder-kit では、汎用性を優先して CI/CD を標準同梱していません。 必要なら project ごとに add-on pack や専用 Skill として差し込む、という考え方のほうが自然です。

同じ文脈で、リンターも標準では抱えていません。 たとえば Rust なら Clippy を導入することで、コード品質をかなり簡単に底上げできます。 ただし、どの lint を必須にするか、どこまで厳しくするかも project 依存が強いため、これも agent-builder-kit の標準範囲には入れていません。 必要なら CI/CD や review ルールと合わせて、その project 用に差し込むべきものです。

レイヤードアーキテクチャや境界分離を強めるなら

同じことはレイヤードアーキテクチャにも言えます。 どこで domain を切るか、どのフォルダ構成にするか、どこまで interface を分けるかは、project ごとの差が大きいからです。

これも汎用テンプレートに固定で埋め込むより、必要に応じて拡張できるほうがよいでしょう。 たとえば、次のような Skill を追加する余地があります。

• architecture-creator
• folder-structure-designer
• boundary-reviewer

こうした Skill があれば、task-planner や task-worker とは別に、「構造をどう切るか」だけを専門に扱えます。 それは、より厳密な境界分離を求める project で特に効いてきます。

どこまで kit に入れるべきか

ここで難しいのは、全部入りにしすぎると kit が重くなり、逆にどの project にも合わなくなることです。 だから今の agent-builder-kit は、意図的に最小寄りにしています。

つまり方針としてはこうです。

• 共通で効くものは最初から入れる
• project 依存が強いものは add-on や Skill で差し込む
• 使いながら必要な役割をあとから増やす

この方針なら、汎用性を保ちながら、実運用に合わせて強くできます。

今後の拡張候補

今の時点で、次の拡張はかなり筋がいい候補です。

• 並列化可能 ticket の可視化
• 別セッションでの multi-agent 実行ルール
• CI/CD 用 add-on pack
• lint / static analysis 用 add-on pack
• アーキテクチャ設計専用 Skill
• 境界逸脱を重点的に見る reviewer 拡張

この章で言いたいのは、「今の kit は不完全だ」ということではありません。 むしろ、今の agent-builder-kit は展開スクリプトと .canvas 同期の Skill を除けば、ほとんどが .md の docs でできています。 だからこそ、この kit を土台にしながら、自分の project に合わせて役割や運用を拡張しやすいのです。