「Harness Engineering」って何？
2026年2月、OpenAIのエンジニアRyan Lopopoloが発表したブログ記事が、エンジニアの間で話題になっている。
「Harness Engineering: leveraging Codex in an agent-first world」
AIエージェントが「一人で料理できる厨房」を設計する。
それが、これからのエンジニアの仕事になる。
OpenAIはこの方法で、5ヶ月で100万行のコードを生成した。
しかも、人間が手で書いたコードはゼロ。
「え、エンジニアは何してたの？」と思うよね。
答えはこうだ。
環境を設計し、意図を仕様にし、フィードバックを返していた。
料理で例えるなら──
従来のエンジニア＝シェフが一品ずつ手で作る
Harness Engineer＝厨房のレイアウト、レシピ帳、味見の仕組み、食材の並べ方を設計して、AIシェフが迷わず料理できるようにする人
3つの柱（Martin Fowler流の整理）
Martin Fowlerのサイトで、ThoughtWorksのBirgitta Böckelerがこの概念を3つの柱に整理している。
1. Context Engineering（レシピ帳を整える）
AIエージェントに「何を、どうやって作るか」を伝えるための知識ベース。
OpenAIのチームは、リポジトリ内に構造化されたドキュメント領域を作り、約100行のAGENTS.mdというファイルをエージェントに毎回読み込ませていた。
これが「単一の信頼できる情報源」になる。
レシピ帳がなかったら、どんな腕利きのシェフでも「今日の日替わり弁当、何作ればいいんだっけ？」ってなるよね。
2. Architecture Constraints（厨房のルールを決める）
AIエージェントの「暴走防止柵」。
OpenAIは、モジュールの依存関係を層状に定義した。
Types → Config → Repo → Service → Runtime → UIこの順序を破るコードは、自動テストやLinterで弾かれる。
料理で言えば「デザートの材料でメインディッシュを作るな」「揚げ物のフライパンでスイーツを焼くな」というルール。AIに自由にやらせつつも、「この範囲で」という境界線をコードで強制する。
3. Garbage Collection（冷蔵庫の期限切れチェック）
時間が経つとドキュメントは古くなるし、アーキテクチャの違反も積み重なる。
OpenAIは「矛盾検出エージェント」を走らせて、定期的にコードベースの「期限切れ」を見つけている。
冷蔵庫の奥に放置された食材。いつの間にか腐っている。これを定期的にチェックして掃除する仕組みがないと、どんなに素晴らしい厨房もいずれ機能しなくなる。
「あれ？これ、私がやってたことだ」
ここからが面白い話。
私は2025年から、Claude Codeを使って「mothership-lab」という仕組みを作ってきた。AIエージェントに仕事を委ねるための「母艦」だ。
OpenAIの記事を読んで、正直驚いた。
やってること、ほぼ同じじゃないか。
| OpenAIのHarness Engineering | 私のmothership-lab |
|---|---|
| AGENTS.md（約100行のマップ） | CLAUDE.md + MEMORY.md（AIへの指示書） |
| 構造化されたdocs/ | cards/（知識カード） + docs/axis/（ブランド指針） |
| カスタムLinter + 構造テスト | quality_gate.sh（品質チェック自動化） |
| ガベージコレクション | /audit コマンド + noise_filter（ノイズ自動除去） |
| エージェント群のオーケストレーション | AGI Cockpit（複数AIエージェントの同時指揮） |
| 宣言型プロンプト | Layer3トリガーシステム（キーワード検出→自動注入） |
名前なんてついてなかった。
でも、やっていることの本質は同じだった。
なぜ同じことにたどり着いたのか
理由はシンプルだ。
AIエージェントに「もっと頑張れ」と言っても、うまくいかないから。
OpenAIの記事にこんな一節がある。
When something failed, the fix was almost never “try harder.”
（何かがうまくいかなかった時、解決策は「もっと頑張れ」ではなかった）
代わりに、こう考えた。
「不足しているのは何か？ それをどうやってエージェントにとって読みやすく、強制できるものにするか？」
これ、私が毎日やっていることだ。
AIが同じミスを繰り返す → 「次から気をつけて」じゃダメ。
仕組みで防ぐ。ルールをコードに書く。自動でチェックする。
料理で言えば──
「味が濃すぎた」→「次は気をつけよう」は何も変わらない。
「塩は小さじ1まで」とレシピに書く。計量スプーンを置く。味見ステップを入れる。
人間の意志力に頼らず、仕組みで品質を保証する。
これがHarness Engineeringの本質であり、私が「委ねるOS」と呼んでいるものの実装だ。
エンジニアじゃなくても関係ある話
「でもこれ、エンジニアの話でしょ？」
違う。
Harness Engineeringが教えてくれる最大の教訓は──
「AIを使いこなす」とは「AIが動ける環境を作る」ということ。
これはビジネスでもまったく同じだ。
- 部下に「頑張れ」と言っても成果は出ない → マニュアルと仕組みを作る
- AIに「いい文章書いて」と言っても60点 → ブランドガイドラインとトーン設定を渡す
- ChatGPTに「なんでもいいからアイデア出して」→ 散漫 → 制約条件を明確にする
制約を増やすほど、AIの自律性と信頼性は上がる。
これ、直感に反するよね。自由にさせた方がいい結果が出そうじゃない？
でも違う。
料理で言えば、「好きに作っていいよ」と言われたシェフは困る。
「今日の食材はこれ、お客さんは30人、予算はこれ、アレルギーの人が2人」──この制約があるから、最高の料理が生まれる。
あなたも今日から始められること
Harness Engineeringを自分の仕事に取り入れるなら、こんなステップから始めてみてほしい。
Step 1: 「レシピ帳」を作る
AIに毎回同じことを伝えていないか？
もしそうなら、それをドキュメントにまとめよう。
ChatGPTならカスタム指示に、Claude CodeならCLAUDE.mdに書く。
「この人はこういう仕事をしていて、こういうトーンで話して、こういうNGがある」
これだけで、AIの出力品質は劇的に上がる。
Step 2: 「ガードレール」を引く
AIに「これだけは絶対にやるな」を伝える。
- この表現は使わない
- この数字は出さない
- この形式で出力する
制約は自由を奪うのではなく、品質を保証する。
Step 3: 「味見」の仕組みを作る
AIの出力をチェックするステップを入れる。
全自動にしない。最後の味見だけは自分でやる。
私はこれを「味見ゲート」と呼んでいる。
「やった」と言う前に、検証する。証拠を見せる。
まとめ：「厨房設計者」という新しい働き方
OpenAIが「Harness Engineering」と名付けたもの。
それは──
「自分で料理する人」から「厨房を設計する人」へのシフト。
AIが料理する。人間は厨房を設計する。
レシピ帳を整え、ルールを決め、冷蔵庫をチェックする。
これは「楽になる」という話じゃない。
仕事の質が変わるという話だ。
私は「抱え込みOS」を「委ねるOS」に書き換えている最中。
完璧じゃない。まだ書き換わってない部分もある。
でも、OpenAIのような世界最先端のチームが、同じ結論にたどり着いている。
方向は間違っていない。
一緒に「厨房設計者」になろう。
その先に、ワクワクする未来が待っているよ。
参考:
- Harness engineering: leveraging Codex in an agent-first world | OpenAI
- Harness Engineering | Martin Fowler
- OpenAI Introduces Harness Engineering | InfoQ
この記事はプロセスエコノミーの一環として、AIエージェントと人間の協働で作成しました。
構成・執筆・校正の全プロセスを公開しています。
