title: OpenAIが発表した「ハーネスエンジニアリング」を700時間の自律運用で実践している話
tags: プロンプトエンジニアリング, AI, LLM, Node.js, ClaudeCode
OpenAIが発表した「ハーネスエンジニアリング」を700時間の自律運用で実践している話
OpenAIが「Harness Engineering」という考え方を発表した。
3人のエンジニアが5ヶ月間、一行もコードを書かずに、AIだけで100万行のプロダクトを作った実験。エンジニアの仕事は「コードを書く」から**「環境を設計する」**に変わった。
自分はClaude Codeを700時間以上自律稼働させている。非エンジニアだ。この発表を読んで驚いた。自分がやっていたことに名前が付いたからだ。
ハーネスエンジニアリングとは
「ハーネス」は馬具の手綱のこと。AIは走る力を持っている。でも方向を制御しないと意図しない方向に行く。その手綱の設計が「ハーネスエンジニアリング」。
OpenAIの実験結果:
- 3人のエンジニア × 5ヶ月 × コード0行
- AIが書いたコード: 100万行
- PR: 1,500件（1人あたり1日3.5件）
- 結果: 社内何百人が使うプロダクトが稼働
エンジニアがやったこと: 環境の設計。
自分の環境との一致
読んで驚いたのは、自分がClaude Codeでやっていることとほぼ同じだったこと。
| OpenAIの実験 | 自分の環境 |
|---|---|
| AGENTS.md（思想+地図） | CLAUDE.md（判断基準+ルール） |
| リンター（自動チェック） | hooks（PreToolUse/PostToolUse） |
| 段階的な開示 | Skills（Progressive Disclosure 3層構造） |
| ガベージコレクション | セルフレビュー（10タスクごと） |
3層構造がドリフトを防ぐ
OpenAIもこの構造を取っている:
- 思想(Why): 行動原則。「こういう人であれ」
- マインドセット(How): スキル横断の行動規範
- チップス(What): 具体的タスク制約
3層をごちゃ混ぜにしない。混ぜるとどちらも機能しなくなる。
自分のCLAUDE.mdも最初は全部1ファイルに書いていた。判断基準もhookの設定方法もデプロイ手順も同じファイルに。結果、Claude Codeが「何が重要か」を判断できなくなり、ルールを無視し始めた。
3層に分離してから、遵守率が体感で上がった。
Anthropicも同じことを言っている
OpenAIだけではない。Anthropicも公式ブログでハーネス設計について書いている。
Anthropicの記事で特に重要な2つの発見:
コンテキスト不安
AIがコンテキストウィンドウの限界に近づくと、作業を途中で打ち切ろうとする。Anthropicはこれを「コンテキスト不安」と呼んでいる。
自分の環境でも経験している。Claude Codeが突然「ここまでのまとめを書いて終わります」と言い始める。まだ作業が残っているのに。
対策としてcontext-monitorhookを入れた。コンテキスト残量を監視し、40%を切ったら警告、20%で「/compactを実行しろ」と通知する。
AIは自分の仕事を過大評価する
Anthropicの実験で判明した:「AIは自分が作った成果物を評価すると、過度に肯定的になる」。
つまり、Claude Codeに「今のコード、大丈夫？」と聞いても「はい、問題ありません」と答えがちだ。
対策: 生成者と評価者を分離する。Claude Codeがコードを書き、PostToolUseのsyntax-checkが客観的に検証する。書いたAIとチェックするhookは別プロセス。これがハーネスの本質。
「気をつけて」は対策にならない
OpenAIの記事で最も印象的だった一文:
ガイダンスが多すぎると、ガイダンスにはならない。すべてが「重要」になると、何も重要ではなくなる。
自分のCLAUDE.mdに「注意: rm -rfを使うな」と書いても、Claude Codeは時々無視した。
代わりにhookを書いた。rm -rfを検出したらexit 2でブロック。「気をつけて」→「検知して強制」に変換した。これがハーネスエンジニアリングの日常だ。
# 「気をつけて」→「検知して強制」
npx cc-safe-setup
# 8つの安全hookが10秒でインストール
「百科事典ではなく目次を渡せ」
OpenAIの記事で重要な指摘:
モノリシックなマニュアルは、古くなったルールの墓場と化す
CLAUDE.mdを巨大なマニュアルにするのではなく、「何がどこに書いてあるか」を示す地図として機能させる。詳細はSkills（references/）に分離する。
自分のCLAUDE.mdも最初は200行以上あった。3層に分離してから、Claude Codeの理解度が上がった。
もう一つの重要な概念が「テイスト不変条件」。命名規則、ログ形式、コードスタイルなどの小さな一貫性を、好みではなくルールとして固定する。人間のチームでは「空気を読む」で済むが、AIには通用しない。明文化されていないルールは存在しないのと同じ。
手綱を編むのもAI
最も重要な気づき。
ルールを書くのもAIに任せられる。失敗が起きたら「これがダメだった」とClaude Codeに伝える。Claude Codeがhookやルールを書く。
人間の仕事は**「何がダメだったか」を言語化すること**。
実際、自分のhook（執筆時442個、現在は658個以上）のほとんどはClaude Codeが書いた。自分はプログラミングの知識がないので、コードを自分で書くことはできない。でも「この操作は危険だ」「このパターンはブロックすべきだ」と伝えることはできる。
まとめ
- ハーネスエンジニアリング = 環境設計 — コードを書く力ではなく、AIが正しく動く環境を設計する力
- 3層構造で整理 — 思想/マインドセット/チップスを混ぜるな
- 「気をつけて」→「検知して強制」 — hookは注意書きの上位互換
- 手綱を編むのもAI — 人間は「何がダメだったか」を伝えるだけ
- 非エンジニアでもできる — 必要なのは言語化力
📖 トークン消費に困っているなら → Claude Codeのトークン消費を半分にする——800時間の運用データから見つけた実践テクニック（¥2,500・はじめに+第1章 無料）
📖 AIで事業を回す実体験を全記録 → Claude Code×個人事業 800時間の全記録（¥800・第2章まで無料）
⚠️ Opus 4.7緊急情報（2026年4月17日）
Opus 4.7のauto mode安全分類器がOpus 4.6にハードコードされている問題が発覚。3日間で23件以上のデータ損失。さらにv2.1.100以降、APIコールごとに約20,000トークンが見えない場所で追加課金されている問題も判明（#46917、GitHub上196件のリアクション）（50GB永久消失含む）。4倍のトークン消費も報告されている。対策: npx cc-safe-setup --opus47（Survival Guide / Safety Scanner）
📚 最新の事故を毎月追う (Claude Code 安全運用便): 本記事の自律運用の続編として、ハーネスの実装で起きた事故（子の作業者の境界の不在、主張と実態の乖離、取り返しのつかない操作）を毎月まとめて届ける会員制 「Claude Code 安全運用便」(月500円)。まだ本の章になっていない最新の事故を、複数のツールにまたがって継続して追える。
📖 過去の事故の総括 (Postmortems): ハーネスの実装の事故の整理は Postmortems、 Gumroad、 4,350 円 に納めています。
関連の素材
本記事の harness engineering の段で観察される主張と実態の乖離は、 本書の中核の主題の系統の中の1件です。
5月22日に新刊の事例集 Claude Code Claim-Verify Handbook ($19、 約89頁、 約113,000字) を公開しました。 道具が「成功した」 「比較した」 「設定された」 と主張する一方で実態が乖離していた事例を GitHubの起票の集まりから130件 (本文15件+付録D 115件) 整理した本で、 14件の防衛の手順と5件の自動の点検の道具と一緒に提供しています。 試し読みのGist (約16,000字、 章1の全件) は こちら。
予防 hook の集まりは cc-safe-setup (MIT、 約800件の hook)。 最新の事故を継続して追うなら、会員制 「Claude Code 安全運用便」(月500円) が、まだ本の章になっていない事故を毎月まとめて届ける。まず無料で試すなら 事故防止チェックリスト を配っている（破壊的な変更や新しい事故が出た時だけ設定のパッチ付きで知らせる・月に数通・いつでも解除）。
📅 Claim-Verify Handbook（Gumroad、19米ドル）は、道具が「成功した」「設定した」と報告する裏で実態がずれていた100件以上の失敗を、操作する側の意図・システムの主張・実際の動作の三層で整理した本です。試し読み（無料） で序文と最初の章を読めます。
ハーネスエンジニアリングの延長で、2026年6月15日に Anthropic は Claude Code の課金の経路を分割する予定だった（claude -p と Agent SDK の自動化を別の課金枠に分ける計画）が、施行当日に一時停止された。再実施される可能性はあるので、claude -p や cron / CI / GitHub Actions の自動化を運用しているなら、課金の経路がどちらの枠で数えられるかを検証しておく価値はある。
起票 #61704 の 84.68 ユーロの事例は、 モデルの billing claim の confidently 間違った routing の回答に依存して 122 セッションの bot プールを構築した利用者の事例で、 ハーネスエンジニアリングの段で 「モデルの自己 articulation を検証の入力に使わない」 の規律の現代の最強の事例。 自分のハーネスの自動化の段の判定の入力。
📘 本記事の延長の Zenn の本: 700時間のハーネスエンジニアリングの整備の段で、 自律運用の事故予防の整備の全記録は、 Anthropic公式ガイドにない事故防止 で整理しています。 第3章まで無料で読めます。 2026年5月27日に Chapter 16 (5月の3つの集積) を追加。
📚 関連の参考資料 (2026年5月28日追加)
本記事の内容と関連する整理を、 公開済の素材で articulate しています。
-
6月15日に予定された課金分離(当日に一時停止・再実施に備える)の判定の枠組み: Migration Playbook v2 (Gumroad、 $19) ——14日後の決定の整理、 9集積の文脈、 130件の claim-verify divergence の事例。 60秒の購入判定の道具で事前判定が可能
-
月次の追補の継続: Claude Code 事故まとめ(無料・月次) ——5月から12月の8ヶ月の章本文 (cache_control / 副の作業者 / AGENTS.md / Pro Max / 権限 / Skills / v2.1.150 / AUP false-positive)
-
9集積の枠組みの英語の長編 Gist: The 9-Cluster Framework: Mapping the Structural Failure Surface of Claude Code Operator Defense ——約3,300単語、 全件の集積の mechanism / symptom family / defense path の整理。 cluster 9 (Usage Policy classifier over-trigger on Opus、 25+件の起票) の対話型診断道具: 4問の質問→推奨経路の道具
-
約800件の MIT ライセンスの hook: cc-safe-setup (GitHub) ——9集積に対応する hook を整備した累計
ほかにも、800時間の運用データから、トークン消費の削減・複数ベンダー(Claude / Codex / Gemini / Copilot)の並行運用・サブエージェントの沈黙の失敗対策など、テーマ別の手引きを公開しています。気になる人は著者の本の一覧から、価格と評価を見て選べます。