ハーネスエンジニアリングの概念と数字はわかった。では実際に何から手をつければいいのか。Anthropic公式ブログ、HumanLayerの実践ガイド、そしてコミュニティの知見を統合して、Claude Code実践者向けのロードマップを整理する。

まず最も重要な警告: 過剰設計は逆効果

HumanLayerの Kyle（@0xblacklight）が書いた記事「Skill Issue」から、実践者が最初に肝に銘じるべき一文を引用する。

漸進的にシッピングし、実際の失敗が起きた時だけハーネスを最適化する。

CLAUDE.md に100行のルールを書き込み、10個のMCPサーバーを接続し、5層のサブエージェント体制を組む——これは「ハーネスエンジニアリング」ではなく「過剰設計」だ。モデルは賢い。賢い前提で、必要な場合にのみ複雑さを足していくのが原則。

同じ記事にもうひとつ重要な洞察がある。「コンテキストウィンドウが大きくなっても精度は上がらない。干し草の山が大きくなるだけ」。情報を詰め込むのではなく、必要な情報を適切なタイミングで渡す段階的開示の方が効く。

5ステップのロードマップ

コミュニティで広く共有されている推奨順序を整理すると、こうなる。

Step 1: CLAUDE.md を整理する

すべてのハーネスの出発点。ここが散らかっていると何をやっても効果が出にくい。ポイントは:

  • プロジェクトの目的・構成を簡潔に（ファイルツリー含む）
  • 「やるべきこと」より「やってはいけないこと」を優先的に書く
  • 200行を超えたら分割を検討（agents.md、rules/ への委譲）

Step 2: フックで決定論に寄せる

リンター、コードフォーマッター、自動テスト実行——これらはLLMにやらせる必要がない。フックで自動化すれば、トークンの節約と確実性の両方が手に入る。

Claude Code のフックは PostToolUse（ツール実行後）と PreToolUse（ツール実行前）が特に有用。ファイル保存後にリンターを走らせる、コミット前にテストを走らせる、といったパターンが定番だ。

Step 3: 検証手段を入れる

Anthropic公式ブログの Justin Young が特定した4つの失敗モードは、すべてのClaude Codeユーザーが経験するものだ:

  1. 早期完了宣言 — まだ終わっていないのに「完了しました」と言う
  2. ハンドオフ破綻 — セッション間で文脈が失われる
  3. 不十分なテスト — テストなしで「動きます」と言う
  4. 不適切なセットアップ — 前提条件の確認不足

対策として、200+項目のJSON形式機能リストで「完了」の定義を明確にする方法が紹介されている。Playwright MCPを使って実際にブラウザで動作確認させるのも有効。

Step 4: 評価ループを導入する

ここがAnthropicの3エージェント構成の核心。GeneratorとEvaluatorを分離し、フィードバックループを回す。コスト比較ではソロエージェント（20分/$9）に対してフルハーネス（6時間/$200）とかなり高くなるが、品質は段違い。

ただし、Anthropicの Prithvi Rajasekaran 自身が興味深いことを述べている。「Opus 4.6の改善によりスプリント分解が不要になった」——つまり、モデルが進化するとハーネスの複雑度は下げられる。ハーネスは固定物ではなく、モデルの進化に応じて適応させるものという視点が大事だ。

Step 5: 継続的に改善する

Meta-Harness論文が示したように、ハーネス改善の鍵は「実行トレースへのフルアクセス」にある。AIがどう動いてどこで失敗したかの生ログを記録し、次のハーネス改善に活かす。

実務では、スキルの中に「失敗しやすいポイント」を記録していく、フック実行のログを保存する、といった地道な蓄積が効いてくる。

「狩りから稲作へ」

Zennで見つけた印象的なメタファーがある。「Claude Codeでハーネスエンジニアリングを実践する——狩りから稲作へ」（@ignission）。その場その場で指示を出す「狩猟型」から、環境を整えて収穫する「農耕型」へ。

この転換を意識するだけで、日々の Claude Code との向き合い方が変わる。今日の作業を早く終わらせることより、明日以降もうまく動く仕組みを一つ残すこと。それがハーネスエンジニアリングの実践だと思う。