ハーネスエンジニアリング事例集 — OpenAI・Anthropic・個人開発
OpenAIとAnthropicの一次情報、本サイトの運用例から、再利用できるハーネス設計の判断を整理します。
事例の数字より、再現可能な仕組みを見る
ハーネスエンジニアリングは、特定のツール設定集ではありません。エージェントが仕事を理解し、実行し、検証し、次の反復へ進める環境を設計する実践です。
ここでは公開事例をそのまま成功法則にせず、何が観測され、どの仕組みを自分の開発へ移せるかを分けて読みます。
事例1: OpenAI — エージェント主体のソフトウェア開発
OpenAIは2026年2月、Codexを使い、約5か月で約100万行の内部プロダクトを構築した実験を公開しました。記事では、手作業でコードを書かず、チームが3人から7人へ増え、1人あたり1日平均3.5件のPRを処理したと報告しています。
これらはOpenAI自身の実験結果であり、一般的な生産性保証ではありません。重要なのは、コード生成量を支えた環境設計です。
移植できる設計
- 指示ファイルを百科事典にせず、リポジトリ内の正本へ案内する目次にする
- アーキテクチャ、品質基準、計画、意思決定をバージョン管理する
- エージェントがアプリ、ログ、テスト結果を自分で確認できるようにする
- リンター、型検査、テスト、構造検査でルールを機械的に強制する
- 失敗のたびに指示を増やすのではなく、不足していた能力やフィードバック経路を直す
OpenAIの事例は「強いモデルへ依頼すれば完了する」という話ではありません。リポジトリを、エージェントが読めて操作できるシステムに変えた事例です。
事例2: Anthropic — 長時間アプリ開発のハーネス
Anthropicは2026年3月、Planner、Generator、Evaluatorを使う長時間アプリ開発の実験を公開しました。Plannerが仕様を具体化し、Generatorが実装し、Evaluatorが成果を独立に確認します。
独立評価を置く理由
生成役の自己評価だけでは、見た目の欠陥や要件漏れを見逃すことがあります。そこでEvaluatorには、成果物そのもの、テスト結果、画面、仕様を渡し、合否と次の修正点を出させます。
ただし、常に3エージェントが必要なわけではありません。短い変更なら、単一エージェントとCI、人間レビューで十分です。分離の価値が、追加の時間とコストを上回る場合に採用します。
ハーネスはモデルに合わせて再評価する
Anthropicの実験では、モデルが変わると有効な実行単位やコンテキスト管理も変化しました。記事中の比較では、より新しいモデルに合わせてスプリント構造を簡素化し、長い連続実行を試しています。
したがって、過去に必要だった分割、リセット、レビュー回数を固定ルールにしません。モデルやタスクを変えたら、品質・時間・コストを再測定します。
事例3: 本サイト — 小規模チーム向けの適用例
本サイトでは、次の情報をリポジトリ内で分離しています。
AGENTS.md / CLAUDE.md エージェントが最初に読む入口
.agents/rules/ コード、UI、コンテンツ、テストの規則
docs/SPEC.md 機能と技術構成の正本
docs/ARCH.md 構造と設計判断
docs/DESIGN.md 視覚表現の正本
docs/OPERATIONS.md 運用手順
tests/ 機械判定できる期待値適用している主なガードレールは、実装前の設計確認、テスト先行、仕様外実装の抑制、秘密情報の非参照、型検査とテストによる検証です。
これは運用構成の例であり、導入前後を統制して測った生産性実験ではありません。効果を評価する場合は、手戻り件数、レビュー指摘、テスト失敗、完了までの時間などを事前に定義して比較します。
3事例から得られる共通原則
1. 正本を明確にする
チャット履歴だけに要件を置かず、仕様、決定、進捗を永続的な成果物へ残します。入口ファイルは短く保ち、詳しい正本へ誘導します。
2. フィードバックをエージェントへ返す
テスト、ログ、スクリーンショット、静的解析、レビュー結果を取得可能にします。検証不能な環境では、モデルが強くても修正ループを閉じられません。
3. 完了を証拠で判定する
「実装した」という文章ではなく、受け入れ条件、テスト結果、差分、実画面などで完了を判定します。高リスクな変更には人間の承認を残します。
4. 複雑さを計測して増やす
最初からマルチエージェントや多数のフックを導入せず、観測した失敗へ対応する最小の仕組みを追加します。モデル更新時には、その仕組みがまだ必要か再評価します。