OpenAIが100万行のソフトウェアを作ったのに、人間が直接書いたコードは0行なんです。その秘密は?エージェントにコードを任せつつ、エージェントが働く環境そのものを設計したことなんです。
これは何?
Harnessはもともと馬を制御するための装備を指します。手綱、鞍、くつわ — 強力だけど気ままな動物を望む方向へ導くツールセットですよね。AIコーディングエージェントにも、まさに同じものが必要なんです。
Harness Engineeringとは、AIエージェントが働く環境・制約・フィードバックループを設計する新しいエンジニアリング分野のことです。 プロンプトエンジニアリングが「何をさせるか」に注目するとすれば、ハーネスエンジニアリングは「どんな環境で働かせるか」に注目します。
Philipp Schmid(元Hugging Face)はこれをコンピュータに例えました — モデルがCPU、コンテキストウィンドウがRAMとすれば、ハーネスはオペレーティングシステム(OS)なんです。コンテキストを管理し、ブートシーケンス(プロンプト、フック)を処理し、標準ドライバー(ツールハンドリング)を提供する構造です。
なぜ今話題なのかというと、OpenAI Codexチームが5ヶ月間で100万行以上のコードをエージェントだけで書き上げ、エンジニア3人が1日平均3.5件のPRをマージしたからです。人間がやったのはコードを書くことではなく、ハーネスの設計でした。 LangChainもモデルはそのままにしてハーネスだけを変えることで、ベンチマーク順位をTop 30からTop 5へと引き上げています。
ポイント:3つの概念の違い
プロンプトエンジニアリング = 単一のやり取りで効果的な指示を作ること
コンテキストエンジニアリング = モデルが見る情報を最適化すること
ハーネスエンジニアリング = エージェントシステム全体(環境、制約、フィードバック、ライフサイクル)を設計すること
ハーネスの構成要素 — Commands、Skills、Hooks
@_petercharによるバイブコーディング用語シリーズが、この構成要素をとてもわかりやすく整理しています。 Claude Codeを例に、ハーネスを構成する核心ツール3つを見ていきましょう。
何が変わるのか?
ハーネスなしでエージェントを使うとどうなるか、みなさん経験されていると思います。間違った方向に暴走したり、同じミスを繰り返したり、コンテキストが長くなると最初の指示を忘れたりします。モデルがどれだけ良くなっても、ハーネスがなければ意味がないんです。
| ハーネスなしでエージェント使用 | ハーネス適用 | |
|---|---|---|
| 方向性 | プロンプト依存、しばしば逸脱 | 制約とフィードバックで自動修正 |
| 品質の一貫性 | 毎回結果が異なる | アーキテクチャルール + リンターで強制 |
| 長時間作業 | 50ステップ超えるとドリフト | コンテキスト圧縮、サブエージェントで分散 |
| チーム協業 | 個人ごとにバラバラ | 共有ハーネスでチーム全体の一貫性 |
| 拡張性 | 人間の介入が常に必要 | 自律運用 → 人間はレビューのみ |
NxCodeの整理によると、ハーネスエンジニアリングの3つの核心軸はこれです。
- コンテキストエンジニアリング
エージェントが正しい情報を正しいタイミングで見られるようにすること。AGENTS.mdを百科事典ではなく「目次」として使い、詳細な文書は構造化されたdocs/に分散させます。 - アーキテクチャ制約
「良いコードを書いて」ではなく、良いコードの構造を機械的に強制すること。依存関係の方向、命名規則、ファイルサイズ制限をリンターとCIで検証します。 - エントロピー管理
AIが生成したコードは時間が経つとドリフトします。定期的にドキュメントの整合性、パターン違反、不要なコードをスキャンする「掃除エージェント」を回します。
実践ハーネスフレームワーク3種の比較
理論はここまでにして、今すぐ使えるオープンソースのハーネスフレームワークを比較してみましょう。
| フレームワーク | 核心の哲学 | GitHub Stars | 対応エージェント |
|---|---|---|---|
| Superpowers | TDDベースの自律開発ワークフロー | 76.5K | Claude Code, Codex, Cursor, OpenCode |
| Oh-my-claudecode | Teamsファーストのマルチエージェントオーケストレーション | 9.2K | Claude Code (+ Codex, OpenCode変形) |
| Ouroboros | ソクラテス式の質問で意図を引き出し、振動を防止 | 1.1K | Claude Code |
SuperpowersはJesse Vincentが作ったエージェンティックスキルフレームワークです。 最も優れている点は、TDD(テスト駆動開発)を強制することです — エージェントはコードを書く前に必ずテストを先に書き、レッド → グリーン → リファクタリングのサイクルをたどります。インストールすれば、エージェントが自動的にブレインストーミング → 設計 → 計画 → サブエージェント実行 → コードレビュー → ブランチの締めくくりまで全ワークフローをこなします。
Oh-my-claudecodeは韓国人開発者のHeo Yechanが作ったフレームワークで、21個の専門エージェント(コードレビュアー、デバッガー、アーキテクトなど)がチームのように協業する構造です。 Claude Code用のoh-my-claudecode、Codex用のoh-my-codex、OpenCode用のoh-my-openagentでファミリーを形成しています。
OuroborosはQ00が作ったフレームワークで、「プロンプトを書くのをやめて、スペックを書こう(Stop prompting. Start specifying.)」という哲学に従います。 ソクラテス式の質問でユーザーの真の意図を引き出し、あいまいさスコア(Ambiguity Score)とエージェントの振動(Oscillation)状態を数値で追跡して、エージェントが迷子にならないようにします。
始め方のポイント
- CLAUDE.md(またはAGENTS.md)から整理する
プロジェクトのアーキテクチャ、コーディングルール、ディレクトリ構造を100行以内にまとめましょう。百科事典ではなく目次として。 - Hooksで決定論的なルールを設定する
.claude/settings.jsonにPostToolUseフックでリント自動実行、Stopフックで作業完了通知を設定してみてください。 - ハーネスフレームワークを一つインストールしてみる
Claude Codeユーザーなら/plugin install superpowersの一行だけで大丈夫です。TDDワークフローが自動的に適用されます。 - 段階的に制約を追加していく
最初から完璧なハーネスを作ろうとしないでください。基本的なリンティングから始めて、パターンが見えたらアーキテクチャ制約を追加し、必要であればサブエージェントを導入しましょう。
注意: 過剰設計の落とし穴
Philschmidの核心アドバイス — 「削除できるように作ろう(Build to Delete)」。モデルは急速に進化するため、2024年に複雑なパイプラインが必要だった機能が、2026年には単一のプロンプトで解決できます。制御フローを過剰に設計すると、次のモデルアップデートでシステムが崩壊します。



