ハーネスエンジニアリング入門：Claude Codeで自律コーディングパイプラインを構築する方法【2026】

「Claude Codeは使っているけど、毎回同じ指示を繰り返している」「AIが自律的に動いてくれると聞いたけど、何をすればいいのかわからない」

そんな悩みを持つエンジニアに注目されているのが、ハーネスエンジニアリング（Harness Engineering） という考え方です。

2026年4月現在、Zennの「AI」「Claude Code」トピックで複数の高評価記事が一気にトレンド入りし、多くのエンジニアが実践事例を共有しています。

この記事では、ハーネスエンジニアリングの概念から実践方法まで、初心者にもわかりやすく解説します。

この記事でわかること：

ハーネスエンジニアリングとは何か（エージェンティックエンジニアリングとの違い）
Claude Codeで自律パイプラインを作る3つの仕組み
CLAUDE.md設計のベストプラクティス
Hooksで自動化できること
Skillsを使ったワークフロー自動化の実践例

ハーネスエンジニアリングとは

ハーネスエンジニアリング（Harness Engineering） とは、Claude Codeを「ツールとして使う」のではなく、AIが自律的に動くための「環境・制約・ルール」を設計する エンジニアリング手法です。

「ハーネス（harness）」はもともと馬具（制御用の装具）を意味します。AIという強力な馬を、どの方向に走らせるか制御する「手綱と鞍」を設計することが、ハーネスエンジニアリングの本質です。

エージェンティックエンジニアリングとの違い

混同されやすいのですが、関連する概念として エージェンティックエンジニアリング（Andrej Karpathyが提唱）があります。

概念	焦点	主体
バイブコーディング	AIにとりあえず任せる	AI主体
エージェンティックエンジニアリング	探索→計画→実装のワークフロー	人間＋AI
ハーネスエンジニアリング	AIが自律動作するための設計	人間が環境を設計

ハーネスエンジニアリングは「何をAIに任せるか」より、「AIがどのように動くかを設計する」 ことに重きを置いています。

なぜ今注目されているのか

Claude Codeには以下の仕組みが揃い、自律的な動作が現実的になりました：

CLAUDE.md：プロジェクトのルールをAIに永続的に伝える設定ファイル
Hooks：Claude Codeの特定のアクション前後に自動で実行されるスクリプト
Skills：繰り返しのワークフローをコマンド化する仕組み
スケジューラー：定期的にClaudeを自動起動する機能

これらを組み合わせることで、「Issueを作成するとAIが自動で実装→テスト→PR作成まで行う」ようなパイプラインが実現できます。

ハーネスエンジニアリングの3つの柱

柱1：CLAUDE.md で「AIへの憲法」を作る

CLAUDE.md はプロジェクトルートまたはホームディレクトリに置く設定ファイルで、Claude Codeがプロジェクトに参加するたびに自動で読み込まれます。

基本構成

# CLAUDE.md
 
## プロジェクト概要
このプロジェクトはNext.js 16 + TypeScriptで作られたECサイトです。
 
## 開発ルール
- コンポーネントはsrc/components/配下に作成
- テストはvitest + React Testing Libraryを使用
- コミットはConventional Commitsに従う（feat:, fix:, docs:など）
 
## 禁止事項
- any型の使用
- console.logの本番コードへの混入
- .envファイルの読み取り
 
## 作業フロー
1. まず既存のコードを読んで構造を理解する
2. 実装前にTODOリストを作成して確認を求める
3. テストを書いてから実装する（TDD）
4. 完了したらPRの説明文を作成する

CLAUDE.mdを「育てる」という考え方

ハーネスエンジニアリングの重要な点は、CLAUDE.mdを「一度書いて終わり」ではなく、AIとの作業を通じて継続的に改善していく ことです。

AIが間違った判断をしたとき → そのケースをCLAUDE.mdに追記
AIが良い判断をしたとき → そのパターンをCLAUDE.mdに記録

これにより、プロジェクト固有の「AI用の知識ベース」が育っていきます。

柱2：Hooks で自動化ゲートを作る

Hooks は Claude Code の以下のタイミングで自動実行できるスクリプトです：

Hook名	実行タイミング
`PreToolUse`	ツール実行前
`PostToolUse`	ツール実行後
`Stop`	Claudeの応答完了後
`Notification`	Claude から通知があったとき

実践例1：ファイル変更後に自動でテスト実行

~/.claude/settings.json に以下を追加：

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "npm test --watchAll=false 2>&1 | tail -20"
          }
        ]
      }
    ]
  }
}

この設定により、Claude Codeがファイルを編集するたびに自動でテストが走り、結果がClaudeのコンテキストに返されます。テストが落ちていればClaudeが自動で修正を試みます。

実践例2：コミット前にリントチェック

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "if echo '$CLAUDE_TOOL_INPUT' | grep -q 'git commit'; then npm run lint && npm run type-check; fi"
          }
        ]
      }
    ]
  }
}

実践例3：作業完了時にSlack通知

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "curl -X POST $SLACK_WEBHOOK_URL -d '{\"text\": \"Claude Codeの作業が完了しました\"}'"
          }
        ]
      }
    ]
  }
}

長時間かかる作業をClaudeに任せている間、Slackで完了通知を受け取れます。

柱3：Skills でワークフローをコマンド化する

Skills（スキル）は、よく使うワークフローを /コマンド名 で呼び出せる仕組みです。

スキルファイルの作成

~/.claude/skills/ ディレクトリにMarkdownファイルを作成します：

<!-- ~/.claude/skills/review-pr.md -->
# PRレビュー
 
このスキルを実行したら、以下を順番に行ってください：
 
1. `git diff main...HEAD` で変更内容を確認
2. 以下の観点でレビューを実施：
   - セキュリティ上の問題はないか
   - パフォーマンスへの影響はないか
   - テストが充分に書かれているか
   - CLAUDE.mdのルールに従っているか
3. 問題があれば具体的な修正案を提示
4. 問題がなければ「LGTM」とレビューコメントの下書きを作成

Claude Codeのプロンプトで /review-pr と入力するだけで、このワークフローが自動的に実行されます。

実践：完全自律コーディングパイプラインの例

以下は、ハーネスエンジニアリングの実践例として、Zennでも紹介されている「Issue → 実装 → PR」の自律パイプラインです。

セットアップ

Step 1: CLAUDE.mdにワークフロールールを記載

## GitHub Issues 対応フロー
 
Issueを渡されたら以下の手順で対応すること：
 
1. Issueの内容を読んで要件を整理する
2. 実装計画をコメントに書き、確認を求める（ここで人間のOKを待つ）
3. OKが出たら新しいブランチを作成（ブランチ名: `feat/issue-{番号}`）
4. テストを先に書く
5. テストが通るように実装する
6. `npm run build` が成功することを確認
7. PRを作成し、説明文にIssue番号を含める

Step 2: Issue対応スキルを作成

<!-- ~/.claude/skills/handle-issue.md -->
# Issue対応
 
引数として渡されたIssue番号のGitHub Issueを取得し、
CLAUDE.mdの「GitHub Issues対応フロー」に従って実装してください。
 
GitHub CLI を使ってIssue情報を取得：
gh issue view {番号} --json title,body,labels

Step 3: スケジューラーで定期実行（任意）

# 毎朝9時にPendingのIssueを確認・着手
/schedule 0 9 * * 1-5 /handle-issue 未着手のIssueを1件選んで対応開始

運用してみてわかったこと

ハーネスエンジニアリングを実践しているZennの記事群から見えてくる共通のポイント：

CLAUDE.mdは具体的であるほど良い — 「良いコードを書く」ではなく「関数は20行以内、引数は4つ以内」など定量的なルールが効果的
Hooksは段階的に導入する — 最初からすべて自動化しようとせず、1つずつ追加して動作確認
人間の確認ポイントを明示する — 「ここで一度確認を求める」を明記しないとAIが暴走する可能性がある
ログを残す仕組みを作る — AIが何をしたかトレースできないと、問題発生時に原因特定が困難

ハーネスエンジニアリングの「落とし穴」

過度な自動化はむしろ生産性を下げる

「すべてを自動化しよう」とHooksやSkillsを詰め込みすぎると、かえって複雑になり管理コストが増します。

良い自動化の基準：

週に3回以上繰り返す操作
人間がやると30秒以上かかる作業
ミスが多い定型作業

向いていない自動化：

要件が頻繁に変わる作業
高度な判断が必要な意思決定
まだ試行錯誤中のワークフロー

CLAUDE.mdが長すぎると読まれなくなる

CLAUDE.mdは長ければ良いというものではありません。長すぎると重要なルールが埋もれてしまいます。

推奨：200〜500行以内 でセクションを明確に区切る。

まとめ

ハーネスエンジニアリングの核心は「AIを使う」から「AIが動く環境を設計する」への発想の転換です。

従来のAI活用	ハーネスエンジニアリング
毎回プロンプトを考える	CLAUDE.mdにルールを書く
手動でテストを実行する	HooksでAIがテストを実行
ワークフローを都度説明する	Skillsにワークフローを記録
作業完了を確認しに行く	Notificationで自動通知

最初から完璧な設計を目指す必要はありません。今日からできる小さな一歩 として、まずプロジェクトにCLAUDE.mdを作り、「このプロジェクトで守ってほしいルール」を3つだけ書いてみましょう。

関連記事：