株式会社ZeroPlus｜圧倒的なFlutter開発・札幌

お知らせ

ハーネスエンジニアリング入門：Claude Codeを「設定するファイル群」として設計する

同じモデルで、結果が変わる

先に結論から。Claude Codeの出力品質は、モデルの賢さよりもその周りに組んだ足場（ハーネス）の設計で決まる割合が大きいです。

象徴的な数字があります。LangChainが Terminal Bench 2.0 というエージェント評価で、モデルを一切変えずに足場（ハーネス）だけを作り込んで、スコアを52.8%から66.5%へ、13.7ポイント引き上げたという実験結果が2026年初頭に話題になりました。

同じモデルで、設計だけで10ポイント以上動く。

この「モデル以外のすべてを設計する技術」には名前がついていて、ハーネスエンジニアリング（Harness Engineering） と呼ばれています。

Anthropicのエンジニアリングチーム自身も、コーディングエージェントの設定ポイントを使って出力品質と成功率を上げる技術、という意味でこの言葉を使っています。

業界では「Agent = Model + Harness」という式で語られ、モデルはコモディティ化する、差がつくのはハーネスのほうだという認識が広まっています。プロンプトエンジニアリング → コンテキストエンジニアリング → ハーネスエンジニアリング、というエンジニアリング成熟度の第3段階だと位置づける人もいます。

この記事は、その足場を具体的にどのファイルに何を書くかまで踏み込んで解説します。概念だけでなく、実際のファイルの中身を全部見せます。読み終えたら、自分のリポジトリに最小構成を組めるはずです。

ハーネスの全体像：5つのレイヤーとファイルマップ

ハーネスエンジニアリングは、よく5つのレイヤーに分けて語られます。Claude Codeに当てはめると、それぞれ対応するファイルがあります。

レイヤー役割対応するファイル
Memory（記憶）プロジェクトの前提・規約を毎回読ませるCLAUDE.md
Tools（道具）外部システムへの接続を与える.mcp.json
Permissions（権限）できること/できないことの境界.claude/settings.json
Hooks（強制）必ず実行される決定的な処理.claude/settings.json の hooks
Observability（観測）何をやったかのログ・監査セッションログ、hooksによる記録

そして、この5つを支える共通の理解が「ファイルの置き場所」です。Claude Codeの設定は、大きく2つのスコープに分かれます。

your-repo/                      # ── プロジェクトスコープ（gitでチーム共有）
├── CLAUDE.md                   # プロジェクトの取扱説明書
├── .mcp.json                   # MCPサーバー（外部ツール接続）
└── .claude/
    ├── settings.json           # 権限・hooks・モデル（チーム共有）
    ├── settings.local.json     # 個人の上書き（.gitignore対象）
    ├── rules/                  # 用途別に切り出したルール
    │   └── database.md
    ├── agents/                 # サブエージェント定義
    │   └── code-reviewer.md
    ├── commands/               # カスタムスラッシュコマンド
    │   └── review-pr.md
    ├── skills/                 # 再利用ワークフロー
    │   └── deploy-check/
    │       └── SKILL.md
    └── hooks/                  # hookスクリプト本体
        └── block-dangerous.sh

~/.claude/                      # ── グローバルスコープ（個人・全プロジェクト共通）
├── CLAUDE.md                   # 自分の作業スタイルの好み
└── settings.json               # 個人の権限・hooks

線引きはシンプルです。

  • プロジェクト側（リポジトリ内 .claude/） = 「このリポジトリはこう動く」。gitにコミットしてチームで共有する。
  • グローバル側（~/.claude/） = 「自分はこう作業したい」。マシンローカルの個人設定で、チームには影響しない。

「APIのエラーは必ずこの形式で返す」はプロジェクトのルール、「コミットメッセージは簡潔に」は個人の好み、という具合に振り分けます。

それでは、レイヤーごとに実際のファイルの中身を見ていきます。

レイヤー1：Memory — CLAUDE.md は何を、どう書くか

CLAUDE.md はハーネスの土台です。Claude Codeはセッション間で記憶を持たないので、毎回ここを読んで「このプロジェクトはこういうものだ」を思い出します。記憶を持たない優秀なエンジニアを、毎朝オンボーディングし直しているイメージです。

読み込みの挙動を知る（これを知らないと事故る）

CLAUDE.md は、現在の作業ディレクトリからリポジトリのルートに向かってツリーを遡り、見つけたファイルを順に集めて連結します。上書きではなく追記的なので、ルートとサブディレクトリの両方が文脈に入ります。

この挙動から、設計方針は2つに分かれます。

単一アプリなら、ルートに1枚で十分。 凝った構造は不要です。

モノレポなら、ルート＋パッケージ単位で階層化。 全体共通をルートに、各パッケージ固有をそのディレクトリに置きます。

repo/
├── CLAUDE.md          # 全体共通：構成、共通コマンド、全体方針
├── apps/
│   ├── web/
│   │   └── CLAUDE.md  # フロント固有：コンポーネント規約
│   └── api/
│       └── CLAUDE.md  # API固有：エンドポイント設計、認証方針
└── packages/
    └── db/
        └── CLAUDE.md  # スキーマ・マイグレーション方針

肝は、フロント・DB・デプロイのルールを1枚の巨大ファイルに詰め込まないこと。それぞれのワークフローを所有するディレクトリの「近い場所」に置く。これがディレクトリ設計の本質です。

実際の CLAUDE.md の中身

抽象論だと伝わらないので、TypeScript + Hono + Drizzle、ECSにデプロイするバックエンドを例に、実物を載せます。

# example-api

## 概要
WebサービスのバックエンドAPI。Hono (Node.js 20) を
ECS Fargate 上で動かし、PostgreSQL に Drizzle ORM で接続する。

## 主要コマンド
- 開発サーバー: `pnpm dev`
- 型チェック: `pnpm typecheck`   # 編集後は必ず通す
- テスト: `pnpm test`
- Lint: `pnpm lint`
- マイグレーション生成: `pnpm drizzle-kit generate`

## アーキテクチャ
- `src/routes/` … エンドポイント定義（1ファイル1リソース）
- `src/services/` … ビジネスロジック。routes からはここだけ呼ぶ
- `src/db/schema/` … Drizzle スキーマ。手書きSQLは原則禁止
- DBアクセスは必ず service 層を経由する。routes から直接 db を触らない

## コーディング規約
- エラーは AppError クラスでラップし、HTTPステータスを明示する
- 非同期処理は async/await。.then チェーンは使わない
- 環境変数は src/env.ts の zod スキーマ経由でのみ参照する

## やってはいけないこと
- マイグレーションファイルを手で編集しない（必ず drizzle-kit で生成）
- 本番DBへの直接接続を試みない
- `.env` や `secrets/` 配下を読まない

ポイントは、長さではなく密度です。

「ドキュメント」ではなく「ふるまいの契約」

ここで最大のアンチパターンが、CLAUDE.md を立派なドキュメントにしようとして肥大化させることです。重要な事実として、常設の指示は毎ターンの注意力を消費します。 ファイルが膨れるほど一行あたりの重みが薄まり、出力品質はむしろ下がる。40行のタイトなファイルは、400行の網羅的なファイルに勝ちます。

良い判断基準は「その一行はClaudeのふるまいを変えるか？」。変えないなら消す。CLAUDE.md は読み物ではなく、チームとエージェントの間のふるまいの契約書です。

逆に書かなくていいのは、Claudeが1セッション触れば自分で学習・記録すること。テストユーティリティの場所などは自分で見つけるので、わざわざ常設指示に入れる必要はありません。

運用のコツ：

  • 2回同じ修正をしたら書く。 1回の失敗では書かない（例外だらけのファイルになる）。本当にプロジェクトの不変条件だと言えるものだけ。
  • 嘘になったルールは即削除。 CIで強制されるようになったルールも消す。
  • 四半期に一度棚卸し。 毎回少し短くなっているファイルは、たいてい良くなっています。
  • 巨大化してきたら、領域ごとのルールを .claude/rules/ に切り出す（次項）。CLAUDE.md は常時読み込みなので、ここを薄く保つのが効きます。

「ルールを書いたのに効かない」と思ったら、まず /memory コマンド。 現在アクティブなメモリ／指示ファイルを確認できます。多くの場合、そのディレクトリのファイルをまだ読んでいないだけです。

CLAUDE.md を太らせない：.claude/rules/ で関心を分離する

CLAUDE.md が育ってくると、必ず「フロントの規約も、DBの規約も、テストの規約も、全部ここに書きたい」という圧力がかかります。でも前述のとおり、常時読み込みのファイルは太らせるほど効きが悪くなる。ここで使うのが .claude/rules/ です。これも Memory レイヤーの一部で、CLAUDE.md の「1枚に全部」を「関心ごとに分割」へ展開する仕組みだと考えてください。

.claude/rules/ 配下の .md ファイルは、CLAUDE.md と同じ高優先度で読み込まれる指示です。サブディレクトリも再帰的に探索されます。

.claude/rules/
├── coding-style.md      # 常時適用：命名・フォーマット
├── testing.md           # テストの書き方
├── security.md          # セキュリティチェックリスト
└── api.md               # API固有の規約

運用面の利点も大きい。API規約は api.md のオーナーが、テスト規約は testing.md のオーナーが、それぞれ独立して更新できる。1枚の巨大な CLAUDE.md を取り合ってコンフリクトする、ということが減ります。

rules には2つのモードがあります。

1. 常時適用（フロントマターなし） — セッション開始時に毎回読まれます。CLAUDE.md とほぼ同じで、「どのファイルを触っていても効かせたいルール」向けです。

# コーディング規約
- インデントは2スペース
- 1行は最大100文字
- 複数行構造には末尾カンマを付ける

2. パススコープ（paths: フロントマターあり） — 指定したglobにマッチするファイルを触っているときだけ読み込まれる、という設計です。特定領域でだけ効かせたい重めのルールを、普段は文脈から外しておけます。

---
paths:
  - "src/api/**/*.ts"
  - "src/**/*.{ts,tsx}"
---

# API開発ルール
- エンドポイントは必ず Zod で入力を検証する
- エラーは { error: string, code: number } の形で返す
- 全リクエストに相関IDを付与してログする

{ts,tsx} のようなブレース展開も使えます（glob が { や * で始まる場合は、YAMLの仕様上クォートが必要です）。

ただし、パススコープには2026年前半時点で挙動の粗さがあります。代表的なのが「ルールはファイルの読み込み（Read）時には注入されるが、新規作成（Write）時には注入されない」という点。「新しいAPIファイルには必ずこのヘッダを付ける」のような、作成時に効かせたいルールほど作成の瞬間には効かない、という直感に反する挙動です。加えて、ユーザーレベル（~/.claude/rules/）の paths: が読み込まれないケースも報告されています。

実務上の対処はシンプルです。作成時に必ず効かせたいルールは、パススコープにせず、常時適用（フロントマターなし）か CLAUDE.md 側に書く。 そして、効いていない疑いがあれば /memory（または /context）で実際に何が読み込まれているかを必ず確認する。「書いたから効いているはず」と思い込まないことが、ここでも鉄則です。

使い分けを一言で。CLAUDE.md はどこでも効く土台（構成・全体方針・品質基準）、rules は領域ごとの個別ガイド（API規約はAPIファイルに、テスト要件はテストファイルに）。この2つを組み合わせると、文脈を薄く保ちながら、必要な場所に必要な指示だけを高優先度で届けられます。

レイヤー2：Tools — MCPで外部システムにつなぐ

Claude Codeはファイルとシェルは触れますが、それ以外の外部システム（DB、社内API、チケット管理、監視）には標準では手が届きません。これを橋渡しするのが MCP（Model Context Protocol） で、リポジトリルートの .mcp.json に定義します。

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
    }
  }
}

注意点が一つ。MCPで接続したツールはそのまま大きな権限になり得ます。後述する権限設計でスコープを絞るのが前提です。「とりあえず全部つなぐ」は事故のもとなので、本当に必要な接続だけにします。

レイヤー3：Permissions — settings.json で境界を引く

ここがハーネスの中で最も費用対効果が高い部分です。権限を放置すると、両極端のどちらかに陥ります。

  • 何も設定しない → 操作のたびに承認を求められ、作業にならない
  • --dangerously-skip-permissions で全許可 → 速いが、危険

正解はその中間、.claude/settings.json での粒度の細かい権限設計です。

実際の settings.json

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(pnpm test:*)",
      "Bash(pnpm typecheck)",
      "Bash(pnpm lint)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Read(src/**)"
    ],
    "ask": [
      "Bash(git push:*)",
      "Bash(pnpm drizzle-kit:*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(aws:*)",
      "Bash(terraform apply:*)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ],
    "defaultMode": "default"
  }
}

冒頭の $schema 行は入れておくと、VS CodeやCursorで補完とバリデーションが効きます。

構文と評価順序

権限ルールは Tool または Tool(specifier) の形式です。

  • Bash(pnpm test:*) … pnpm test で始まるコマンドを許可（:* は前方一致ワイルドカード）
  • Bash(git status) … 完全一致
  • Read(./.env) / Read(./secrets/**) … gitignore構文のパスパターン
  • WebFetch(domain:example.com) … ドメイン指定

そして、評価順序が極めて重要です。

ルールは deny → ask → allow の順で評価され、最初にマッチしたものが結果を決める。

つまり deny が常に最優先。Bash(aws:*) のような広い deny は、より具体的な Bash(aws s3 ls) の allow があっても拒否します。deny は例外（許可リスト）を持てません。さらにこの優先順位はスコープを跨いでも成立します。プロジェクト設定で allow していても、グローバル設定の deny が勝ちます。リスクの高い操作を deny で塞いでおけば、うっかり allow を広げても安全側に倒れる、という設計ができます。

permission mode：セッション単位のレバー

権限にはもう一つ、セッション単位で切り替えるモードがあります。Shift+Tab で循環します。

  • default：システムを変える操作の前に確認する。安全なデフォルト。
  • acceptEdits：ファイル編集は自動承認、シェルは確認。編集が多い局面で効く。
  • plan：分析と計画だけ。ファイル編集もコマンド実行もしない。設計レビューに使う。
  • dontAsk：allowで明示したもの以外は自動拒否。CIなどの自動化向け。
  • bypassPermissions：全プロンプトをスキップ。完全に隔離された環境でのみ。

初期モードは defaultMode で設定できます。作業フェーズに応じて手動で切り替えるのが基本です。

重要な落とし穴

権限設計で必ず知っておくべき制約があります。Read / Edit の deny ルールは、Claude Codeのファイルツールと認識済みのファイルコマンドには効きますが、任意のサブプロセスは止められません。 たとえば Read(.env) を deny していても、Claudeが Bash で node -e "console.log(require('fs').readFileSync('.env'))" のようなスクリプトを実行すれば、中身は読めてしまいます。

だから「.env を deny したから秘密情報は安全」というのは誤りです。本当に守るなら、シェルアクセス自体を絞る（広い Bash(*) を許可しない）か、後述の hooks で実行内容を検査する必要があります。

レイヤー4：Hooks — 「お願い」を「強制」に変える

ここがハーネスエンジニアリングの核心です。

CLAUDE.md に「コミット前に必ず型チェックを走らせて」と書いても、それはお願いであって強制ではありません。CLAUDE.md の指示は、何千トークンもの中でモデルの注意を奪い合う一行に過ぎず、無視されることがあります。

確実に毎回起きてほしいことは、hooks にします。hooks は settings.json に定義する、セッションの特定タイミングで実行されるシェルコマンドです。決定的な違いは、hooks はモデルではなくハーネス（ランタイム）が実行すること。だから100%動きます。

一方は助言、もう一方は強制。 CLAUDE.md は markdown の中で注意を奪い合う一行。hook は毎回必ず走り、回避できないシェルスクリプト。この差を多くのチームは知らずにいる。

hooks の構造とJSON

hooks は3階層のネストで定義します。イベント（いつ）→ matcher（どのツールで）→ ハンドラ（何を実行）。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": ".claude/hooks/block-dangerous.sh" }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          { "type": "command", "command": "pnpm prettier --write \"$CLAUDE_TOOL_INPUT_FILE_PATH\"" }
        ]
      }
    ],
    "SessionStart": [
      {
        "hooks": [
          { "type": "command", "command": "echo \"現在のブランチ: $(git branch --show-current)\"" }
        ]
      }
    ]
  }
}

主なイベントはこのあたりです。

  • PreToolUse：ツール実行の前。実行をブロックできる（ガードに使う）
  • PostToolUse：ツール実行の後。編集後の自動フォーマッタなど
  • SessionStart：セッション開始時。標準出力に書いた内容が文脈に注入される（ブランチ情報など）
  • UserPromptSubmit / Stop / SubagentStop：その他のライフサイクル

matcher は Write|Edit のように正規表現で複数ツールにマッチさせられます（大文字小文字を区別するので bash は Bash にマッチしません）。

ブロックの仕組み：exit code 2

PreToolUse hook の肝は終了コードです。

  • exit 0：許可（実行を続行）
  • exit 2：ブロック（実行をキャンセルし、stderr の内容がClaudeに渡る）
  • exit 1：非ブロックの警告（実行は続行される）

セキュリティ目的のhookは必ず exit 2 を使います。exit 1 では止まりません。危険コマンドをブロックする block-dangerous.sh の中身はこんな具合です。hook には tool の情報がJSONで標準入力に渡ります。

#!/bin/bash
# 標準入力から tool_input.command を取り出す
cmd=$(jq -r '.tool_input.command // ""')

# 破壊的パターンを検出したらブロック
if echo "$cmd" | grep -qE 'rm -rf|DROP TABLE|terraform destroy'; then
  echo "危険なコマンドを検出したためブロックしました: $cmd" >&2
  exit 2
fi
exit 0

「すべてのhookは傷跡である」

hooksの設計思想として、いい言葉があります。Terraform や Ghostty の作者 Mitchell Hashimoto が示した原則で、「エージェントがミスをするたびに、二度と同じミスをしないよう仕組みで解決する」。実際、Ghostty のリポジトリでは、エージェント向け指示ファイルの各行が「過去にエージェントがやらかした失敗」に1対1で対応していると言われます。「every hook is a scar（すべてのhookは傷跡である）」というわけです。

最初から完璧なhookセットを作る必要はありません。痛い目を見るたびに1個ずつ足していく。これが正しい育て方です。

再利用の資産化：サブエージェントとスラッシュコマンド

ここまでが基礎の5レイヤーです。さらに作業を資産化する仕組みが2つあります。

サブエージェント：コンテキストを分離する

長いセッションでは、ファイル読み込み・ツール出力・中間推論がどんどん文脈に溜まり、95%あたりで自動圧縮（auto-compact）がかかって、それまでの理解が薄れます。サブエージェントは、この問題を解決します。脇道のタスクを、独自の文脈・ツール・モデルを持つ子インスタンスに委譲し、親には要約だけ返す。親のセッションは本筋に集中できます。

定義は .claude/agents/<name>.md。YAMLフロントマター＋本文（システムプロンプト）です。

---
name: code-reviewer
description: 直近の差分をレビューし、問題を深刻度つきで報告する。コード変更後に PROACTIVELY 使うこと。
tools: Read, Grep, Glob, Bash
model: sonnet
---

あなたはシニアコードレビュアーです。呼ばれたら：

1. `git diff` で変更ファイルを特定する
2. 変更されたコードパスに集中してレビューする
3. セキュリティ問題・明らかなバグ・スタイル違反を洗い出す
4. 深刻度（high / medium / low）とファイル:行 を添えて優先順位つきリストで返す

具体的であること。修正案はコードスニペットで示すこと。

設計のコツ：

  • description が委譲のトリガー。 「〜のとき使う」「PROACTIVELY」を含めると、親が自動で判断して投げてくれます。曖昧な説明だと自動委譲が機能しません。
  • tools は最小権限に。 レビュアーに Write は要りません。省略すると親の全ツールを継承してしまうので、明示的に絞ります。
  • model でコストを最適化。 これが効きます。親セッションは Opus で高レベルの判断、実装やルーチン検索は Sonnet、ファイル探索や単純な変換は Haiku、という振り分けが定番です。model: inherit で親に揃えることもできます。

注意点として、ファイルで作ったサブエージェントはセッション開始時に読み込まれるので、ディスク上で編集したらセッション再起動が必要です（/agents コマンド経由なら即時反映）。また、サブエージェント多用ワークフローは、各エージェントが独自の文脈を持つぶん、単一スレッドの7倍程度のトークンを消費し得ます。安いタスクほど安いモデルに振るのが効く理由です。

スラッシュコマンド / Skills：手順を固める

繰り返す手順は、.claude/commands/<name>.md にプロンプトテンプレートとして保存し、/コマンド名 で呼べます。

---
description: PRをレビューしてマージ可否を判断する
allowed-tools: Read, Grep, Glob, Bash
model: opus
---

`main` と `HEAD` の差分を監査し、次の観点でレビューせよ：
- 認証・認可の変更
- 入力バリデーションの境界
- ログへの秘密情報の混入
- 新規依存の妥当性

結果を「対応必須 / 要検討 / 任意」のパンチリストで報告せよ。

$ARGUMENTS で引数全体、$1 $2 で位置引数を受け取れます。

なお2026年現在、スラッシュコマンドとSkillsは統合の方向にあります。.claude/commands/ は引き続き動きますが、新規はディレクトリ＋SKILL.md の Skills 形式が推奨で、こちらは自動起動・モデル上書き・段階的開示（progressive disclosure）といった上位機能を持ちます。

最小構成から始めて、育てる

ここまで構成要素が多く見えたと思いますが、最初から全部作るのはアンチパターンです。ハーネスエンジニアリングの実践者も口を揃えて「Memory と Hooks の2つから始めろ」と言います。この2つが、最も頻度の高い失敗モードをカバーするからです。

おすすめの順番：

  1. ルートに CLAUDE.md を1枚。 主要コマンドとアーキテクチャの要点を20〜40行で。
  2. settings.json に最低限の権限。 破壊的操作（rm -rf、aws:*、terraform apply）と秘密情報読み取りを deny。よく使う安全な操作を allow。残りは都度確認させ、頻出するものを /permissions で足す。
  3. PreToolUse ガードを1個。 危険コマンドを exit 2 でブロックするだけでいい。
  4. 運用しながら育てる。 2回同じ修正をしたらルールを足す。毎回必ず起きてほしい処理が出てきたら hooks にする。再利用したいワークフローが固まったら subagent や command に資産化する。

ハーネスは一度書いて終わる設計図ではなく、チームの作業の中で少しずつ削り、足していく生き物です。最小構成で始めて、痛みを感じた箇所だけ補強する。これが現実的で、一番効きます。

チームで運用するためのチェックリスト

.claude/settings.json はアプリケーションコードと同じように扱うのが、チーム運用のコツです。権限変更はPRでレビューする。レビュアーは次の3つを問います。

  • allow の各ルールは、繰り返し実行しても安全か？
  • ask の各ルールは、本当に人間の判断が要るチェックポイントか？
  • deny は、秘密情報・強制プッシュ・削除・本番操作をカバーしているか？

そして、設計の最終チェックとして、自分のハーネスにこう問いかけてください。「Claudeがミスをしたとき、その向こう側に何があるか」。本番の認証情報、共有インフラ、公開リポジトリ——失敗のコストが大きい領域ほど、ハーネスを厚くする。逆に使い捨てのサンドボックスなら、思い切って自律性を上げる。自律性は姿勢ではなく道具です。

まとめ

  • Claude Codeの品質は、モデルよりハーネス（足場）の設計で大きく決まる。同じモデルで設計だけが10ポイント以上動いた実験もある。
  • ハーネスは5レイヤー：Memory（CLAUDE.md）/ Tools（.mcp.json）/ Permissions（settings.json）/ Hooks / Observability。
  • CLAUDE.md はドキュメントではなく「ふるまいの契約」。短く、ふるまいを変える行だけ。読み込みは追記的なので、ルールは所有ディレクトリの近くに置く。領域ごとの規約は .claude/rules/ に分割し、CLAUDE.md を薄く保つ（パススコープは作成時に効かない等の粗さがあるので /memory で確認）。
  • 権限は deny → ask → allow でdeny最優先。ただし Read deny は任意サブプロセスを止めない——シェルアクセス自体を絞るかhooksで補う。
  • hooks は「お願い」を「強制」に変える唯一の仕組み。exit 2 でブロック。失敗のたびに1個ずつ足す。
  • サブエージェントはコンテキストを分離し、モデルルーティングでコストを下げる。
  • 最初から作り込まず、Memory と Hooks の2つから育てる。

プロンプトを磨く時間を、足場を整える時間に振り向けてみてください。同じモデルでも、出力の安定感がはっきり変わります。それがハーネスエンジニアリングという、2026年のエンジニアリングの主戦場です。

※ Claude Codeの機能・設定キー・ファイルの挙動は更新が非常に速い領域です。本記事の具体例は執筆時点のものなので、実運用の前に下記の公式ドキュメントで最新仕様を確認してください。

参考リンク

公式ドキュメント（最優先で参照）

  • Claude Code 概要 — https://docs.claude.com/en/docs/claude-code/overview
  • .claude ディレクトリの全体像 — https://code.claude.com/docs/en/claude-directory
  • 設定リファレンス（settings.json） — https://code.claude.com/docs/en/settings
  • 権限の設定（allow/deny/ask・評価順序） — https://code.claude.com/docs/en/permissions
  • hooks リファレンス — https://code.claude.com/docs/en/hooks
  • サブエージェントの作成 — https://code.claude.com/docs/en/sub-agents
  • Agent Skills の設計思想（Anthropic Engineering） — https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills

ハーネスエンジニアリングの考え方

  • Harness Engineering: The System Around AI Matters More Than AI — https://shipwithai.io/blog/harness-engineering-claude-code/
  • ハーネスと環境設計の実践（hidekazu-konishi.com） — https://hidekazu-konishi.com/entry/claude_code_harness_and_environment_engineering_guide.html

CONTACT

システム開発・アプリ開発・AI導入の課題を抱える
すべての企業様へ

ZeroPlusが北海道・札幌を中心に、最適な開発ソリューションでビジネス課題をスピード解決します。

ZeroPlusは、北海道・札幌を拠点にFlutterを用いたクロスプラットフォーム開発を中心に、システム開発・アプリ開発をワンストップでご提供しています。
スタートアップから上場企業まで幅広いクライアントのDX・デジタル化を成功へ導いてきた実績があります。
無料見積もりにも対応しておりますので、システム開発やアプリ開発をご検討中の企業様はお気軽にご相談ください。

  • これまでに手がけてきた多様なプロジェクトで培ったノウハウを活かし、企業様のシステム開発、アプリ開発、AI導入などの課題をワンストップで解決してきた実績をご覧ください。

    開発実績を見る

  • ご相談・お問い合わせはいつでも無料です。
    システム開発・アプリ開発・AI導入をご検討の企業様は、課題の規模に関わらずお気軽にご相談ください。

    相談する