settings.json を書いた。
CLAUDE.md も用意した。
スキルファイルも作った。
それでも、長時間のタスクで品質が崩れる。
スライド生成で3回やり直す。
記事を書かせたら後半がグダグダになる。
「設定はしたはずなのに、なぜ安定しないんだろう」
この感覚、覚えがあるなら読んでください。
原因は個別の設定ではありません。
ハーネス全体の設計思想が欠けていたんです。
2026年3月、Anthropicがエンジニアリングブログで公開した記事があります。タイトルは「Harness Design for Long-Running Application Development」。
この記事を読んで、自分のPCを全面的に見直しました。
結果、70点だった設計が85点まで上がりました。
今回はその実装の全記録を公開します。
まず、記事の核心を3つだけ押さえます。
GAN（敵対的生成ネットワーク）から着想を得た考え方です。 作る役（Generator）と評価する役（Evaluator）を分離する。 なぜか。 AIは自分の成果物を評価すると、甘くなるからです。 記事の原文にはこうあります。
独立した評価者を懐疑的にチューニングする方が、生成者に自己批判させるよりはるかに扱いやすい つまり「自分で書いて自分でレビュー」はダメ。 別のAIにレビューさせるのが正解です。
長時間タスクで品質が崩れる原因、これです。 コンテキスト（会話の履歴）が埋まるにつれて、モデルの一貫性が崩れます。さらに厄介なのが「コンテキスト不安」。限界に近づいたと感じると、タスクを早期に切り上げてしまう。 だから後半がグダグダになるんです。
ここが一番重要。
ハーネスのすべてのコンポーネントは、モデルが単独ではできないことについての仮定をエンコードしている つまり、今の設定は「今のモデルの限界」に合わせて作ったもの。 モデルが進化すれば、設定も変えるべき。 3ヶ月前に作った
CLAUDE.mdをそのまま使い続けるのは、古い地図で新しい街を歩くようなものです。
Anthropic記事の設計思想に照らして、自分のClaude Code環境を診断しました。 できていたこと:
writer → review → fact-check のパイプラインで生成と評価が部分的に分離planning スキルで企画→仕様展開PROTOCOL.md で出力型を制御最大のギャップから潰します。 Web成果物（HTML/CSS/JS）を書いた瞬間に、Playwright MCPで実物を見て検証する仕組みです。
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write",
"hooks": [
{
"type": "command",
"command": "~/.claude/hooks/web-evaluator.sh",
"timeout": 5,
"statusMessage": "Visual Evaluator..."
}
]
},
{
"matcher": "Edit",
"hooks": [
{
"type": "command",
"command": "~/.claude/hooks/web-evaluator.sh",
"timeout": 5,
"statusMessage": "Visual Evaluator..."
}
]
}
]
}
}Write と Edit の両方にフックを仕掛けています。
HTMLファイルが保存されるたびに発火します。
#!/bin/bash
INPUT=$(cat)
TOOL_NAME=$(echo "$INPUT" | jq -r '.tool_name // ""')
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // ""')
if echo "$FILE_PATH" | grep -qE '\.(html|css|js)$'; then
DIR=$(dirname "$FILE_PATH")
if [ -f "$DIR/index.html" ]; then
cat <<EOJSON
{
"hookSpecificOutput": {
"additionalContext": "【Visual Evaluator】変更を検知。
1. localhostを起動
2. Playwrightでスクリーンショット撮影
3. 合格基準に照らして評価
4. 問題があれば即修正"
}
}
EOJSON
fi
fi仕組みはシンプルです。
これがAnthropicが言う「独立した評価者が実際にアプリケーションとインタラクションする」の実装です。
次に「合格基準」の問題。
従来の planning スキルでは「成功条件」を5つ前後で定義していました。
しかし、これが曖昧だった。
「冒頭で引き込めるか」「具体性があるか」。
何をもって合格とするか、判定者によってブレます。
Anthropic記事では、PlannerとGenerator間で「このスプリントで何を達成するか」を明示的に合意し、Evaluatorがその契約に照らして検証すると書かれています。
これを実装しました。
### 合格基準（Sprint Contract）
#### 構造・説得力（review判定）
- [ ] 冒頭3行で課題提示→共感→解決の予感が揃っている
- [ ] 各セクションが1メッセージに絞れている
#### 読者反応（stakeholder-scorer判定）
- [ ] ペルソナが30秒以内に自分事として読める
- [ ] 読了後にsettings.jsonを開きたくなる
#### 事実（fact-check判定）
- [ ] Anthropic記事の引用が原文と一致
- [ ] 実装ファイルの内容が記事と一致ポイントは 「検証可能な条件のみ」 という制約です。 「良い」「適切な」といった曖昧な言葉は禁止。 チェックリスト形式で、1項目ずつPASS/FIXを判定できる粒度にします。
もう1つ重要なルール。 Evaluator（reviewやstakeholder-scorer）は、合格基準にない観点で不合格にしない。 これはスコープクリープの防止です。 「ここも直したほうがいい」「あれも気になる」。 際限なく修正が入ると、いつまでも完成しません。 契約にないことは指摘しない。 契約にあることだけを判定する。 これで評価が安定しました。
長時間タスクで品質が劣化する問題。
Anthropic記事が指摘する「コンテキストウィンドウの劣化」への対策です。
/brain deep コマンド（長時間の複雑なタスク用）に、以下のパターンを組み込みました。
Phase 1: Agent(research) → ファイルに保存
Phase 2: Agent(planning) → Phase 1を読み込み → ファイルに保存
Phase 3: Agent(generator) → Phase 2を読み込み → 成果物を保存
Phase 4: Agent(evaluator) → Sprint Contract + 成果物を読み込み → 評価結果を保存
Phase 5: FIXなら → Phase 3に修正指示を渡して再実行核心は 「各フェーズを別のAgentで実行する」 こと。 Agent（サブエージェント）は毎回クリーンなコンテキストで起動します。 前のフェーズの成果物はファイルに書き出し、次のフェーズはファイルから読み直す。 コンテキスト内の記憶には依存しません。 これにより
最後に、hooks全体の設計を見せます。
{
"hooks": {
"PostToolUse": [
{
"matcher": "Bash",
"hooks": [{
"command": "~/.claude/hooks/invoice-ledger.sh",
"statusMessage": "請求書チェック中..."
}]
},
{
"matcher": "Write",
"hooks": [{
"command": "~/.claude/hooks/web-evaluator.sh",
"statusMessage": "Visual Evaluator..."
}]
},
{
"matcher": "Edit",
"hooks": [{
"command": "~/.claude/hooks/web-evaluator.sh",
"statusMessage": "Visual Evaluator..."
}]
}
],
"SessionStart": [
{
"hooks": [{
"command": "echo '{cron登録の指示JSON}'",
"statusMessage": "朝ルーティンcron設定中..."
}]
}
]
}
}3種類のフックが動いています。 フックの考え方は 「人間が忘れる検証を、仕組みで強制する」 です。 HTMLを書いたら自動でブラウザ確認。 請求書を作ったら自動で帳簿更新。 セッションを開いたら自動でルーティン登録。 全部、人間がやり忘れることです。 フックがあれば忘れません。
改善前と後を比較します。 全体像をまとめると、こうなります。（一部） GAN的なフィードバックループが回っています。 上段がGenerator-Evaluatorループの全体フロー。 中段が指示階層・スキル・メモリの3レイヤー。 下段がコンテンツパイプラインとVisual Evaluatorの実際のデータフロー。 緑がGenerator、赤がEvaluator、黄色がHook/自動化。 この色分けで、自分のPC上のどこで「生成」と「評価」が分離されているかが一目でわかります。
85点の内訳と、残り15点の話をします。
ハーネスの前提は経年劣化する 今の85点は、Opus 4.6時点での最適解。 次のモデルが出たら、またスプリント分割が不要になったり、Evaluator自体が過剰になったりするかもしれません。 だから
/pc:optimizerコマンドに「ハーネスコンポーネント監査」を組み込みました。定期的に「このコンポーネント、まだ必要か？」を検証する仕組みです。
全部を一気にやる必要はありません。
たとえば、HTMLファイルを保存したらPlaywrightでスクリーンショットを撮る。
それだけで「テキストベース評価」から「実物検証」に1歩進みます。
~/.claude/settings.json の hooks セクションに、上で紹介した web-evaluator.sh を追加してみてください。
その次にやるなら、Sprint Contract。
planning の出力に「合格基準」を追加するだけ。
チェックリスト形式で、曖昧語を排除する。
最後にコンテキストリセット。
長時間タスクをAgent分離する。
この順番で進めれば、あなたのClaude Codeも段階的に強くなります。
Anthropic公式記事はこちらです。
https://www.anthropic.com/engineering/harness-design-long-running-apps
英語ですが、今回の記事で核心は全てカバーしました。
原文を読みたい方はぜひ。