多くの人の Claude Code の使い方は、いまだ「プロンプトを書く -> コピペ -> 繰り返し調整」にとどまっています。しかし、本番環境で AI プログラミングを実際に回せているチームの核心の仕事は、もはやプロンプトの最適化ではなく、モデルを取り巻くエンジニアリング基盤（Harness）の構築です。この記事では、Claude Code の3大エンジニアリング機構と、今日から着手できる具体的なステップを解説します。

コア概念：Model + Harness

Martin Fowler はこの公式を次のように整理しました：Agent = Model + Harness。

Harness（馬具）という言葉は馬術に由来します。馬は強靭でも、どこへ向かうべきかは知りません——手綱、鞍、頭絡が方向を決めます。AI プログラミングに置き換えると：モデルの能力は高いのに、あなたのコードベースでどのルールに従うべきかを知りません。Harness とは、あなたがモデルのために造るハンドル、ブレーキ、ナビゲーションなのです。

あるデータがこの問題を物語っています：VILA-Lab の研究システムが Claude Code v2.1.88 の51.2万行の TypeScript ソースコードを分析したところ、AI の意思決定ロジックはわずか1.6%で、残り98.4%は決定論的なエンジニアリング基盤——権限ゲートウェイ、コンテキスト管理、ツールルーティング、エラー復旧——でした。

ステップ1：CLAUDE.md を作成する —— プロジェクトの脳

CLAUDE.md はプロジェクトのルートに置く Markdown ファイルで、Claude Code がセッション開始のたびに自動で読み込みます。

これは何か

プロジェクトの脳であり、オンボーディングマニュアルです。アーキテクチャの意思決定、命名規則、テスト要件、繰り返し踏んだ落とし穴を、すべてここに書きます。

書き方

完璧である必要も、長い必要もありません。3つの原則に従います：

• Claude がミスをするたびに -> ルールを1つ追加する
• 同じ説明を繰り返すたびに -> ワークフローを1つ追加する
• バグが出るたびに -> ガードレールを1本追加する

# プロジェクト：MyApp

## アーキテクチャルール
- TypeScript strict mode を使用する
- API レイヤーは src/api/ の下に統一配置する
- コンポーネントは関数型で書き、class は使わない

## 命名規則
- ファイル名は kebab-case
- コンポーネント名は PascalCase
- ユーティリティ関数は camelCase

## よくある落とし穴
- useEffect 内で直接 setState しない。ref でマウント済みかを判定する
- DB クエリには必ず limit を付け、全テーブルスキャンを防ぐ

ヒント：次に AI がミスしたとき、手作業で直す前に「CLAUDE.md に何が欠けているか」と自分に問いかけてください。それを補えば、次からは同じミスを繰り返しません。

ステップ2：Skills を作成する —— 再利用可能なワークフロー

.claude/skills/ ディレクトリには、再利用可能な自動化ワークフローを置きます。

コアな考え方

Claude Code の生みの親である Boris Cherny は、こう繰り返し強調しています：「1日に複数回やることは、skill か command にしろ」。

Skill に向いている場面

• Code Review：コードスタイル、セキュリティホール、パフォーマンス問題を自動レビューする
• Commit Message の生成：diff から規約に沿ったコミットメッセージを自動生成する
• リリースノートの作成：git log から変更を抽出して CHANGELOG を生成する
• 同一種類のバグの修正：同種の問題を一括修正する、テンプレート化されたフロー

1つの Skill は本質的に、実行可能な方法論のかたまりです。それはプロンプトではなく、入出力の定義を備えた自動化スクリプトです。

ステップ3：Hooks を作成する —— 自動ガードレール

.claude/hooks/ は最も重要な部分です。AI の自己判断に頼らず、決定論的なコードが AI がミスを犯す前に食い止めます。

なぜ Hooks が最も重要か

これは、AI を「監督なし」で走らせる勇気を与えてくれる仕組みです。ミスが起きうる境界を hooks が確実に塞ぐのであって、AI 自身の「慎重さ」に頼るのではありません。

実際の事例

OpenAI Frontier チームのやり方は参考になります。彼らの linter のエラーメッセージは、人間向けの「violation detected」ではなく、Agent 向けの修正指示なのです：

// 通常のプロジェクトの lint エラー
Error: Unexpected console statement

// OpenAI Frontier の lint エラー
Error: Use logger.info({event: 'name', ...data}) instead of console.log

Agent はこの指示をそのまま読み取って修正でき、人間の介入は不要です。

完全なディレクトリ構造

your-project/
  CLAUDE.md              # プロジェクトの脳（セッション開始時に自動読み込み）
  .claude/
    skills/              # 再利用可能なワークフロー
      code-review.md
      commit-gen.md
    hooks/               # 自動ガードレール
      pre-commit.sh
  docs/
    decisions/           # アーキテクチャ決定の記録（AI に「なぜ」を知らせる）
  tools/                 # カスタムツール
  src/                   # ビジネスコード

効果の検証

この手法は理論だけではありません。LangChain は Harness（システムプロンプト、ツール、ミドルウェア、推論モード）を調整しただけで、モデルを一切変えずに、Terminal Bench 2.0 のスコアを52.8から66.5へ引き上げました。

今日からできること

1. CLAUDE.md を1つ作る：最も重要なプロジェクトのルートに作成し、10分かけてアーキテクチャルールと踏んだ落とし穴を書き出す
2. 繰り返している操作を1つ Skill に変える：1日に2回以上やっていることを見つけ、.claude/skills/ の下の1つのワークフローにする
3. 落とし穴の起きやすい場所に Hook を1つ足す：人間のエンジニアの判断力を、機械が読める制約へと翻訳する

今後のエンジニアの能力曲線は、「自分が何行コードを書けるか」から「AI のためにどれだけ厳格な作業環境を設計できるか」へと移りつつあります。コードを書く作業は Agent に引き継がれつつありますが、Agent が良いコードを書ける環境を設計することは、依然としてあなたの仕事です。