agentic-harness-design について
Agentic Harness Designは、長期かつ複雑なタスク向けのマルチエージェントシステムを設計するスキルです。プランナー、生成役、評価役の分担に加え、スプリント契約、コンテキスト管理、評価者の調整を扱います。
主な機能
- 01役割を分けて計画・生成・評価
- 02スプリント契約の作成
- 03コンテキストのリセットか圧縮を選択
- 04基準と例による評価者の調整
- 05モデルの進歩に合わせた構成の簡素化
活用シーン
- 01単一のコンテキストウィンドウを超える作業の構成
- 02単一エージェント方式での品質向上
- 03主観的なデザインやUX成果物の評価
- 04コンテキストをリセットするか圧縮するかの判断
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/agentic-harness-designを入力して読み込まれたか確認します。
詳細
エージェント型ハーネスの設計
長く複雑なタスクで高品質な出力を実現するマルチエージェントシステムの構築パターンです。ジェネレーター／評価者のループ、コンテキスト管理、タスクの分解を取り上げます。
コアアーキテクチャ：プランナー → ジェネレーター → 評価者
3つのエージェントに分けることで、単独エージェントの主な2つの失敗要因に対処します。
- コンテキストの劣化 — コンテキストウィンドウが埋まるにつれて、モデルの一貫性が失われます。「コンテキスト不安」を示し、早々に作業を終えるモデルもあります。
- 自己評価のバイアス — エージェントは自分の出力を過度に高く評価しがちです。生成者と評価者を分けることが、最も効果的な対策です。
プランナーは短いユーザープロンプト（1〜4文）を受け取り、完全な製品仕様に展開します。成果物と大まかなアーキテクチャのレベルにとどめ、実装の細部には踏み込まないでください。細部を指定しすぎると、その誤りが後続工程に連鎖します。仕様に AI ネイティブな機能を組み込める機会を特定するよう、プランナーに依頼しましょう。
ジェネレーターは仕様に沿って実装します。モデルに足場が必要な場合は、1つずつ機能を実装するスプリント方式で進めます。より高性能なモデルであれば、SDK レベルの圧縮処理でコンテキストの増加に対応しながら、1回の継続セッションで実行できます。引き継ぎ前に、各スプリントの最後で自己評価を行います。
評価者は、合意した基準に照らしてジェネレーターの出力を評価します。静的なスクリーンショットを採点するのではなく、ライブブラウザーツール（Playwright MCP など）を使って実行中のアプリを操作します。具体的で実行可能な指摘を提示します。
スプリント契約
各スプリントの前に、ジェネレーターと評価者はスプリント契約を交渉します。ジェネレーターは実装する内容と成功の検証方法を提案し、評価者が確認して合意します。これにより、実装を事前に細かく指定しすぎることなく、高レベルの仕様とテスト可能な動作の間をつなぎます。
契約はファイルを介して伝達します。一方のエージェントが書き込み、もう一方が読み取って同じ方法で返答します。これにより、両方のエージェントが合意した範囲から逸脱しないようにできます。
コンテキスト管理
コンテキストのリセットと圧縮は同じものではありません。
- 圧縮では、以前のコンテキストをその場で要約し、同じエージェントが続行します。コンテキスト不安が残ることがあります。
- コンテキストをリセットすると、以前の状態と次の手順をまとめた構造化された引き継ぎ資料を使って、新しいエージェントを開始します。オーケストレーションの負荷と引き換えに、まっさらな状態から始められます。
モデルにコンテキスト不安（早々に作業を終える様子として観察できます）が見られる場合は、リセットを使用します。より高性能なモデル（Opus 4.6+ など）は、リセットなしでも長時間のセッションを継続できることが多く、圧縮だけで十分です。
評価者の調整
初期状態の評価者は、判定が甘い傾向にあります。調整の手順は次のとおりです。
- 求める品質水準を明確に示す採点基準を作成します。主観的な判断（「これは良いか？」）を、具体的で採点可能な条件に置き換えます。
- 詳細な内訳付きの少数の例を使い、評価者の判断基準を定めます。
- 各基準に厳格な閾値を設定します。いずれかが閾値を下回った場合、そのスプリントは失敗とします。
- 各実行後に評価者のログを確認します。評価者の判断が自分の判断と異なる場合は、その差を解消するようプロンプトを更新します。
- 評価者には懐疑的になるよう指示します。単独の評価者を批判的に調整するほうが、ジェネレーターに批判的な自己評価をさせるよりはるかに簡単です。
デザインタスクでは、モデルが標準では十分に発揮しにくい基準（独創性、一貫性）を、得意な基準（機能の正確性、技術的な完成度）より重く評価します。
ハーネス簡素化の原則
各コンポーネントには、モデルが単独ではできないことについての仮定が組み込まれています。モデルが進化すれば、そうした仮定は古くなります。モデルをアップグレードするたびに、次のことを行います。
- 簡素化したハーネスで代表的なタスクを再実行する
- コンポーネントを1つずつ取り除き、出力品質への影響を測定する
- より単純な方法では不十分であることが明らかな場合にのみ、複雑さを加える
モデルの能力が向上するにつれて、スプリントへの分解、コンテキストのリセット、スプリントごとの評価ループは、いずれも不要なオーバーヘッドになる可能性があります。
このスキルを使用する場面
以下の場合にこのスキルを使用します。
- 1つのコンテキストウィンドウを超えて実行されるタスク向けのエージェントハーネスを構築するとき
- 単一エージェントのアプローチでは、出力品質の向上が頭打ちになっているとき
- デザインや UX など、二元的な正誤チェックが適用できない主観的な品質基準を持つタスクの場合
- コンテキストのリセット、圧縮、新しいセッションのアーキテクチャのどれを使うべきか判断するとき
- 評価エージェントを調整し、求める品質基準に照らして信頼性の高い採点を行うとき