# Harness Design

> AIエージェント/ハーネス/Loop設計の診断・新規設計を支援する。エージェントの動作が不安定・長時間タスクで失敗する・プロンプトやツール設計を改善したい・新しくエージェントやハーネスを設計したい時に使う。「このエージェント設計をレビューして」「ハーネスを診断して」「こういうエージェントを作りたい」等で発火。

- Skill: `ntaksh42/harness-design` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ntaksh42/harness-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ntaksh42/harness-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ntaksh42 (https://skillmd.com/u/ntaksh42)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/ntaksh42/harness-design

---


# Harness Design — エージェント/ハーネス/Loop設計の診断・設計支援

AI出力向上のためのハーネスエンジニアリングの体系的知識を使い、エージェント設計を
**診断（レビュー）** または **新規設計** する。一次情報源はAnthropic公式エンジニアリング記事・
OpenAI GPT-5ガイド・マルチエージェント研究に基づく。

## モード判定

ユーザーの依頼から、まず2モードのどちらかを判定する（両方なら設計→診断の順）。

- **診断モード**: 既存のプロンプト/エージェント/ハーネス/ループ設計が対象にある。
  「レビュー」「診断」「改善点」「なぜ失敗する」「もっと良くしたい」等。
- **設計モード**: まだ作っていないものを作りたい。
  「作りたい」「設計して」「どう組むべき」「どんな構成がいい」等。

判定が曖昧なら AskUserQuestion で1問だけ確認する。

## 共通の進め方

1. **対象を把握する**（コードがあれば必ず読む。プロンプト・ツール定義・ループ構造・eval有無を確認）
2. **要件を1〜3点に絞る**（タスクの時間軸＝数分か数時間か、並列性、外部I/Oの有無、信頼境界）
3. `references/checklist.md` の観点で評価/提案する（全部を機械的に並べず、対象に効く観点を選ぶ）
4. **指摘は具体・実装可能に**。各指摘に「現状→問題→具体的修正」を付ける。
5. 推奨は survey でなく **推奨案を1つ** 出す（CLAUDE.md の行動指針に従う）。

## 診断モードの出力形式

```
## 診断: <対象>
要件の理解: <時間軸/並列性/信頼境界 を1-2行>

### 重大（出力品質・信頼性に直結）
- [観点] 現状 → 問題 → 修正

### 改善（効率・コスト・保守性）
- [観点] 現状 → 問題 → 修正

### 良い点（維持すべき設計）
- ...
```

ハルシネーション禁止。コードを読んでいない指摘はしない。「○○が無いように見える」は
確認してから書く。

## 設計モードの出力形式

```
## 設計: <作りたいもの>

### 1. ループパターン
推奨: <ReAct / Plan-Execute / Reflexion混成 / マルチエージェント> — 理由

### 2. コンテキスト戦略
<compaction / note-taking / just-in-time検索 のどれを軸にするか> — 理由

### 3. ツール設計
<必要なツールと、命名・粒度・トークン効率の方針>

### 4. 検証ループ / eval
<生成と評価の分離、trajectory vs output、停止条件>

### 5. 状態・メモリ
<永続化の方法、セッション再開、ハンドオフ成果物>

### 6. 権限・セキュリティ
<lethal trifecta 該当チェック、Rule of Two、human-in-the-loop境界>

### 最小構成での第一歩
<まず作るべき最小ハーネス。"最も単純に機能するもの"から始める>
```

## 重要な設計原則（常に効かせる）

- **ハーネスは暫定的補完**: モデルができないことだけを補う。過剰な足場を組まない。
- **最も単純に機能するものを採用**: マルチエージェントは単一の~15倍トークン。並列独立の
  高価値タスク以外では単一エージェントを推奨する。
- **生成と評価を分離**: 自己評価は甘くなる。
- **コンテキストは希少資源**: context rot を避け、最小限の高シグナルトークンを設計する。
- **構成変更（prompt/param/topology）はモデル交換と同等の効果を持つ**。

詳細な観点チェックリストと一次情報源は `references/checklist.md` を参照（必要時に読む）。