ハーネスエンジニアリング入門 — AIに「書かせる」から「品質を維持し続ける」へ

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

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

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

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

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

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

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

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

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

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

今日から始める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

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