---
title: ハーネスエンジニアリング入門 — AIに「書かせる」から「品質を維持し続ける」へ
tags:  #claudecode #生成ai #aiエージェント #contextengineering  
author: [井本 賢](https://image.docswell.com/user/kenimo49)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/GJ5MKM5XJ4.jpg?width=480
description: AIにコードを書かせる時代、成果が出る人と出ない人の差はどこにあるのか。差を生むのは、モデルの賢さよりもAIを動かす「ハーネス（馬具）」の設計です。  このスライドは、ハーネスエンジニアリングの考え方を、コンテキスト管理・制約の強制・品質フィードバックの3層で12枚にまとめた入門編です。AIが書いたコードの品質を、人間が逐一確認しなくても維持できる状態をどう作るかを扱います。  全体像と実装は関連書籍にまとめています。  ▼関連書籍『ハーネス・エンジニアリング』Zenn Book（¥1,500） https://zenn.dev/kenimo49/books/harness-engineering-guide  ▼Kindle版 https://www.amazon.co.jp/dp/B0GF8VGSPC  著者: ken imoto / kenimoto.dev
published: June 11, 26
canonical: https://image.docswell.com/s/kenimo49/ZPRGGQ-harness-engineering-practice
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/GJ5MKM5XJ4.jpg)

HARNESS ENGINEERING
AIを&quot;使う&quot;から
&quot;操る&quot;へ
コードを書かせるより、品質を維持し続ける技術
ken imoto エンジニア / Propel-lab
AIを&quot;使う&quot;から
&quot;操る&quot;へ
ハーネス
エンジニアリング
Ken Imoto
ハーネス・エンジニアリング
kenimoto.dev

# Page. 2

![Page Image](https://bcdn.docswell.com/page/LE3WZWN4E5.jpg)

AIが書いたコード、誰が見ている?
Claude CodeやCodexで自動生成は当たり前になった。問題はその先にある。
「AIが書いたコード、
ちゃんとレビューできてる?」
速く書けるほど、確認の負担だけが積み上がっていく。
ハーネス・エンジニアリング
02
kenimoto.dev

# Page. 3

![Page Image](https://bcdn.docswell.com/page/8EDKRKW57G.jpg)

3人で、5ヶ月、100万行
OpenAIのCodexチームの実績。手書きのコードは0行、すべてエージェント生成。
3
人
のエンジニアで開発
(現在は7人)
100万行
のコードベースを
5ヶ月で構築
3.5PR
1人あたり/日の
スループットを維持
すごいのは「書けた」ことではなく、品質を維持し続けられたこと。
ハーネス・エンジニアリング
03
kenimoto.dev

# Page. 4

![Page Image](https://bcdn.docswell.com/page/V7PKWK9DJ8.jpg)

ハーネス = 馬具の設計
馬(AI)を自由に走らせつつ、暴走させない。手綱・鞍・轡をどう組むか。
エンジニアの仕事は、もはやコードを書くことではない。
環境を設計し、意図を指定し、フィードバックループを構築することだ。
AIエージェントの価値 = 出力の便利さ - 人間の確認コスト
ハーネス・エンジニアリング
04
kenimoto.dev

# Page. 5

![Page Image](https://bcdn.docswell.com/page/2JVV8VMGJQ.jpg)

なぜAIで成果が出ないのか
多くの企業はAIを導入した。でも、ハーネスを構築していない。
1 AIツール導入 → コード生成が速くなる → 便利!
2 でもレビュー体制は従来のまま → 人間が全部確認し直す
3 確認コストが増え、手戻りも増える
4 トータルの生産性は変わらない、むしろ下がる
5 「AIは使えなかった」 → 棚上げ
ハーネス・エンジニアリング
05
kenimoto.dev

# Page. 6

![Page Image](https://bcdn.docswell.com/page/5EGL5LXDJL.jpg)

実践① コンテキスト管理
CLAUDE.mdで「使わない技術」を宣言する。これが一番効いた。
# CLAUDE.md / 技術スタック
- ORM: SQLAlchemy (asyncは使わない)
- 認証: セッション (JWTは使わない)
- フロント: React (Next.jsは使わない)
「やらないこと」を
書くだけで確認コスト
激減
目安は500行以下。百科事典でなく目次として設計する。OpenAIのAGENTS.mdも約100行。
ハーネス・エンジニアリング
06
kenimoto.dev

# Page. 7

![Page Image](https://bcdn.docswell.com/page/4JQYZY8X7P.jpg)

実践② 制約の強制
CLAUDE.mdでTDDを叩き込む。これはコーディング規約ではなく機械的な制約だ。
# 開発ルール(厳守)
1. 変更前に必ずテストを書く
2. 既存テストを削除・スキップしない
3. テストが通らない状態でコミットしない
4. 1コミット1変更
AIが暴走しないための
機械的な制約
CLAUDE.mdの制約はコンパクション後も残るため、長いセッションでもルールが維持される。
ハーネス・エンジニアリング
07
kenimoto.dev

# Page. 8

![Page Image](https://bcdn.docswell.com/page/K74W3W22E1.jpg)

実践③ 品質フィードバック
AIが書いて、AIがレビューする。人間の出番は最終判断だけになる。
Claude Code
コード生成
→
CodeRabbit
AIが一次レビュー
→
E2Eテスト
Playwright自律実行
→
マージ判断
人間はここだけ
Codexチームはレビューのほぼ全てをagent-to-agentに移行。人間レビューはオプション。
ハーネス・エンジニアリング
08
kenimoto.dev

# Page. 9

![Page Image](https://bcdn.docswell.com/page/LJ1Y1YMKEG.jpg)

3層が重なると何が起きるか
Codexの100万行も、個人開発も、規模が違うだけで原理は同じ。
① コンテキスト管理
AIが何を知っているか
CLAUDE.md + AGENTS.md
② 制約の強制
AIが何をしてはいけないか
TDDルール+リンター
③ 品質フィードバック
AIの出力が正しいか
E2Eテスト+AIレビュー
AIが書いたコードの品質を、人間が逐一確認しなくても維持できる状態が生まれる。
ハーネス・エンジニアリング
09
kenimoto.dev

# Page. 10

![Page Image](https://bcdn.docswell.com/page/GJWG8G3P72.jpg)

ハーネスなし vs ハーネスあり
同じAIを使っても、手綱の有無で確認コストは正反対になる。
ハーネスなし
- AIが自由に書く
- 人間が毎回全部レビュー
- テストは忘れがち
- 技術的負債が蓄積
- 確認コストが高い
→
ハーネスあり
- AIがルールに従って書く
- AIが一次レビュー、人間は最終判断
- テストが先、実装が後(TDD)
- 制約とフィードバックで品質維持
- 確認コストが低い
ハーネス・エンジニアリング
10
kenimoto.dev

# Page. 11

![Page Image](https://bcdn.docswell.com/page/4EZL8LV673.jpg)

今日から始める4ステップ
一度に完成させるものではない。Step 1だけでも確認コストは大きく変わる。
STEP 1 / 10分
CLAUDE.mdに制約を書く
「やっちゃダメ」を3行。使わない技術を宣言。
STEP 2 / 5分
TDDルールを追加
テスト先行→Red→実装→Green→コミット。
STEP 3 / 5分
Playwright MCPを接続
E2Eテストの生成→実行→修正を自律化。
STEP 4
CIにAIレビュー
CodeRabbit等をGitHub Actionsに追加。
まずはCLAUDE.mdに3行書くところから。
ハーネス・エンジニアリング
11
kenimoto.dev

# Page. 12

![Page Image](https://bcdn.docswell.com/page/Y76WPW5L7V.jpg)

手綱の全体像は、
この本に。
Zenn Book ¥1,500
zenn.dev/kenimo49/books/harness-engineering-guide
Kindle amazon.co.jp/dp/B0GF8VGSPC
AIを&quot;使う&quot;から
&quot;操る&quot;へ
ハーネス
エンジニアリング
Ken Imoto
コンテキスト管理・制約の強制・品質フィードバックの3層を、実装コードと事例で体系化。AIを&quot;使う&quot;から&quot;操る&quot;へ。
kenimoto.dev
ハーネス・エンジニアリング
12
kenimoto.dev

