OpenAIの開発手法から見るハーネスエンジニアリングの考察 ― AI時代における構造・足場・増幅の再設計

本稿は、AIエージェントを使った開発に関心を持ちながらも、単にコード生成ツールとして扱うのではなく、ソフトウェア開発そのものの構造がどう変わるのかを考えたいエンジニアに向けて書いています。
特に、AIによって「実装すること」より「構造を設計すること」の比重が増している現在、その変化を思想的に整理したい読者を想定しています。

本稿は、OpenAIが公開した Harness engineering: leveraging Codex in an agent-first world を出発点にしていますが、記事内容を単純に要約するものではありません。

元記事で述べられている実践や言葉を手がかりにしながら、従来のソフトウェア工学との接続や、AI時代における開発構造の変化について、筆者自身の推察と概念整理を含めて再構成しています。

そのため、本文には OpenAI が明示している事実と、そこから読み取れる方向性についての解釈の両方が含まれます。

「ハーネス」と聞くと、犬に装着するものや、高所作業で体に巻く安全帯を思い浮かべます。
どちらも共通しているのは、行動そのものを止めるのではなく、事故や逸脱を防ぎながら目的に向かわせるための補助装置であるという点です。

この感覚は、OpenAIが公開した Harness engineering: leveraging Codex in an agent-first world を読むと、そのままソフトウェア開発にも接続できるように感じます。

AIエージェントは高い生成能力を持つ一方で、自由に動かすほど不均一な実装や不要な複製を生みやすくなります。
だからこそ必要になるのは、「もっと賢いモデル」より先に、「正しい方向へ作業を進められる環境」です。

ここでいうハーネスとは、安全装置というより、

AIエージェントが信頼できる形で作業を進めるための制約付きの構造

を指していると考えています。

従来のソフトウェア開発では、エンジニア自身がコードを書き、デバッグし、不具合を修正しながら段階ごとに前進していました。

OpenAIの提示する開発スタイルでは、その役割分担が少し変わります。

人間は、

• 何を作るべきかを定義する
• どこを固定すべきかを決める
• 失敗したときに何が不足していたかを見抜く

役割へ移っていきます。

一方でAIエージェントは、

• コードを書く
• テストを書く
• Pull Requestを作る
• 修正する
• レビューに応答する

といった実作業を担います。

つまり、

Human steers, agent executes.

という関係です。

ここで人間の仕事が減るわけではありません。
むしろ、「直接コードを書くことから、AIが安定して働ける環境を設計することへ重心が移る」と捉えたほうが自然です。

OpenAIの記事におけるハーネスは、単なるテスト実行のための補助機構ではありません。
AIエージェントが信頼できる形で作業を進めるために必要な制約・構造・検証の仕組み全体を指しています。

そこには、

• リポジトリ構造
• ドキュメント
• CI
• リンター
• 構造テスト
• 品質ルール
• observability

が含まれます。

つまり、「何を参照し、どの制約の中で判断し、どこで失敗を検出するか」を決める外部構造です。

AIは能力が高い反面、そのままでは既存の曖昧なパターンまで強く複製してしまいます。
OpenAIも、AIエージェントはリポジトリ内の既存パターンを模倣し、不均一な構造まで引き継ぎやすいと述べています。
だからこそ、構造が必要になります。

ハーネスは、「自由な生成を止めるものではなく、自由な生成を壊れない範囲へ誘導するもの」です。

OpenAIの記事には、エンジニアの新しい仕事が systems, scaffolding, and leverage に関わるものだ、という一文があります。
ただし、元記事がこの三語を厳密な三本柱として定義しているわけではありません。

本稿では、この三語をOpenAIの記事を読み解くための補助線として受け取り、筆者なりに掘り下げて整理しています。

最初に読んだとき、この三つは単なる開発用語というより、開発の見え方そのものを少し変える言葉だと感じました。

Issue → Code → Review → Merge のような表面的な手順ではなく、「AI時代において何を構造化し、何を委ねるかという抽象化レイヤー」に近いからです。

System はアプリケーションそのものではありません。
また、単なる開発プロセスとも少し違います。

ここでいう System は、

誰が作業しても同じ方向へ収束しやすくするための構造

です。

たとえば、

• リポジトリ内でどこに何が置かれ、どの責務がどこに属するか
• 変更が期待どおりに動作するかを継続的に検証するCI
• 設計意図や判断基準を共有する docs
• 判断の経緯を追跡できる decision logs
• 変更を本番へ反映するまでの経路

といったものが含まれます。

重要なのは、単に「どう作るか」ではなく、

「失敗したときにどこへ戻るか」
「何を信頼して次の判断をするか」

まで含めて固定されていることです。

開発プロセスが流れだとすれば、System はその流れを崩れずに支える土台に近いものです。

Scaffolding は足場です。

OpenAIにおける AGENTS.md はその典型です。
ただし、ここで重要なのは、OpenAIが最初から現在の形に到達していたわけではないという点です。

元記事では、初期に「ひとつの巨大な AGENTS.md に全部書く」やり方を試し、それがうまくいかなかったことが率直に語られています。

理由は、

• コンテキストを圧迫する
• 重要な制約が埋もれる
• すぐに古くなる
• 機械的に検証しにくい

からでした。

その失敗を踏まえて、AGENTS.md は百科事典ではなく、

• どこを見るか
• 何から読むか
• どこに信頼できる情報があるか

を示す短い入口へと役割が変わります。

知識本体は docs に置かれ、必要に応じて段階的に開示されます。

ここで重要なのは、「すべてを一度に与えないこと」です。

Scaffolding は、AIに何をしてはいけないかを教えるものでもありますが、それ以上に「どこへ到達すればよいか」を示す補助構造です。

建築の足場は完成すれば外れるものですが、AI開発ではこの足場がそのまま恒久構造に近づいているのが少し面白いところです。

三つの言葉の中で、Leverage は少し掴みにくいかもしれません。
System や Scaffolding は比較的目に見えますが、Leverage はそれらが機能した結果として現れるからです。

ここで述べる Leverage も、OpenAIが厳密に定義しているというより、元記事で触れられた言葉をもとに筆者が解釈を深めている部分です。

一般にレバレッジは、

「限られた資源でより大きな成果を生むこと」

と説明されます。

AI開発においてもこの意味は変わりません。
ただし、ここで増幅されるのは単純なコード量ではありません。

増幅されるのは、

人間が一度与えた判断や意図が、どこまで整合的に波及するか

です。

たとえば、

「このバグを直す」と人間が一度判断したとき、その後に必要になる作業は本来かなり多くあります。

• 不具合を再現する
• 修正を行う
• テストを追加する
• 関連ドキュメントを更新する
• Pull Request を作成する
• レビューコメントに応答する

従来は、これらを一つずつ人間が判断しながら進めていました。

Leverage が高い状態では、この分断された判断が減ります。

一つの意図から、AIエージェントがその後の工程を連続して進められます。

1判断 → 修正 + テスト + docs + PR + review対応

ここで増幅されているのはコード量ではなく、

一度の判断で届く成果の範囲

です。

逆に、一つの指示で1ファイルだけ修正され、テストもなく、周辺の整合性も崩れるなら、それは出力量があっても leverage は低いと言えます。

Leverage は単独で存在するものではありません。

System が整い、Scaffolding によってAIエージェントが迷わず動けるようになった結果として、はじめて現れる増幅効果です。

ここから先は、OpenAIの記事に書かれている内容をそのまま要約するというより、そこで示されている開発上の考え方を、従来のソフトウェア工学の文脈に引き寄せて読み直した筆者自身の解釈です。

OpenAI自身が DDD、Clean Architecture、DevOps を直接比較対象として論じているわけではありません。

ただ、記事に現れている構造への強い関心や、暗黙知を減らして検証可能な形へ寄せる態度を見ると、既存の設計思想との連続性や違いを考えたくなります。

DDD が重視してきたのは、ドメインごとの意味の境界を明確にすることでした。

• どこまでが一つの責務か
• どの概念がどの文脈で意味を持つか
• どの層でどの言葉を使うか

を整理することで、複雑さを制御してきました。

OpenAIが強調するアーキテクチャ文書や構造ルールも、この点ではかなり近い考え方です。

違いは、

従来は人間が理解できればよかった境界が、AIエージェントにも誤読されない形で固定される必要がある

という点です。

Clean Architecture が重視してきたのは、

依存関係の方向を明確に保つこと

でした。

OpenAIの記事に出てくる、

• 厳格に定義されたアーキテクチャモデル
• 固定されたレイヤー構造
• 制限された依存関係
• 構造テスト

という発想は、かなりここに近いです。

ただし違いは、

レビューで守る設計から、機械的に破れない設計へ移っていること

です。

DevOps は、

• 開発
• テスト
• デプロイ
• 運用

を分断せず、継続的に流す思想でした。

OpenAIでも、

AIエージェントがコードを書き、テストし、PR を作り、レビューへ応答し、修正を続けます。

ここは非常に DevOps 的です。

ただし断絶もあります。

従来の DevOps では、

人間が flow の中心

でした。

AI時代では、

人間は flow を作る側へ移り、flow の内部実行はAIエージェントが担う

ようになります。

従来の開発では、

• なんとなくの慣習
• 会話で共有される判断
• 暗黙のレビュー文化

で成立する部分が多くありました。

しかしAIエージェントは、それを読めません。

AIエージェントが参照できるのは、

リポジトリ内に存在する構造化された情報だけ

です。

つまり、

書かれていないものは存在しないのとほぼ同じ

になります。

ここで初めて、

docs、ルール、構造テスト、decision logs が単なる補助ではなく、実装そのものに近い意味を持ちます。

現場レベルで見ると、ハーネスエンジニアリングによって人間の作業は「各工程を順に実行すること」から、「AIが工程を回し続けられる状態を維持すること」へ変わります。

従来は、

• 要件を整理する
• 設計する
• 実装する
• テストを書く
• レビューする
• マージする

を人間が順に進めていました。

AI駆動開発では、この各工程に AI が入り込み、コード生成やテスト作成を補助します。

一方でハーネスエンジニアリングでは、タスクに分解された後の工程を AI が自律的に進めることを前提にします。

たとえば Todo アプリの登録機能を修正させたとき、ツールによって自動生成される schema ファイルまで AI が直接編集してくることがあります。

この種のファイルは、通常は人間も直接編集しません。

元になる定義ファイルを変更し、その内容をもとにツールが再生成することで反映される前提になっているからです。

そのため、生成済みの schema ファイルに直接差分が入っている場合、

修正結果だけを見ると正しそうでも、

次回の再生成で上書きされるか、他の箇所との整合が崩れる可能性があります。

従来なら、

生成ファイルの差分を戻し、

「ここは直接編集しない」とレビューコメントを残して終わります。

ハーネスエンジニアリングでは、その次の作業が増えます。

たとえば リポジトリ 内に、

ドキュメント/schema.md
schemaファイルは直接編集せず、make schema コマンドを実行して生成すること

という一文を追加します。

さらに AGENTS.md からその ドキュメント へ辿れるようにし、

AI が次回同じ作業をするときに先に参照できるようにします。

必要であれば、

生成ファイルに直接差分が入ったとき CI で検知する仕組みも加えます。

つまり、

差分を直して終わるのではなく、誤りを構造として再発防止する

ことが仕事になります。

これまで開発現場では、

• 設計工程
• 製造工程
• テスト工程

に人間が最も時間を使ってきました。

AI駆動開発でも基本は同じで、

各工程の出力を人間が順に評価します。

ハーネスエンジニアリングでは、この内部介入が減ります。

たとえば、

「Todoアプリの登録機能を作りたい。要件はこれです」

と渡すと、

AI は

• 計画
• 実装
• テスト
• PR作成

まで一連で進めます。

人間が見るのは、

最終出力が意図どおりか

です。

違っていた場合、

従来はコードを直して終わっていたところが、

次は

• どの ドキュメント を参照したか
• どの既存実装を模倣したか
• どの指示が曖昧だったか

を確認し、入力側を修正します。

つまり、

入力 → 出力 → 評価 → 入力修正

が中心になります。

新しく増えるのは、

AI が必要な知識だけを最短で参照できるように整理する仕事

です。

たとえば Todo リストの登録処理を作る場合でも、

最初から大量のドキュメントを読ませるのではなく、

• docs/architecture/task-flow.md で処理の流れと責務境界を確認する
• CODING_RULES.md で命名規則や生成ファイルの扱いを確認する
• docs/domain/todo.md で Todo の状態や業務ルールを確認する

という最小限の流れで実装に到達できる状態が望まれます。

そのために、リポジトリ内には、

AGENTS.md
CODING_RULES.md
docs/
  architecture/
  domain/
  lessons/

のような入口を用意し、

必要な知識へ段階的に辿れるようにします。

さらに、一度起きた誤りはその場で終わらせず、

• AGENTS.md の参照先を整理する
• ドキュメント に判断基準を追記する
• lessons に短い失敗記録を残す

といった形で構造へ戻します。

ここで重要なのは、

長い説明を書くことではなく、少ないコンテキストで正しく判断できる位置に置くこと

です。

従来は Notion や会議メモに閉じ込められていた知識が、

リポジトリ内の実行資源へ変わります。

つまり、

ドキュメントの配置設計そのものが開発作業になる

ということです。

ここまで見ると、コードを書く時間が減るぶん、ソフトウェアエンジニアリングそのものが不要になると考えていた方もいらっしゃるかもしれません。

しかし実際には逆です。

たとえば、

• service と controller の責務がわからなければ lesson は書けません
• 依存関係がわからなければ構造テストは作れません
• ドメインがわからなければ issue を切れません

つまり、

構造を書く仕事ほど、構造理解が必要になる

ということです。

違うのは、

その知識をコードの中で一つずつ実行するのではなく、

AI が繰り返せるよう前提条件として埋め込むこと

です。

ソフトウェアエンジニアリングは消えるのではなく、

実装から実装条件の設計へ移動している

と考えたほうが近いです。

ハーネスエンジニアリングを現場で始めるなら、
最初にやることは大きくありません。

• AGENTS.md を入口だけに絞る
• 構造テストを1つ追加する
• AI の失敗を1件 ドキュメント に残す

この3つだけでも十分です。

重要なのは、一度起きた誤りをその場で閉じず、次の生成条件へ返すことです。
コードを書く量が減っても、構造を書く責任はむしろ増えます。
AI が読む リポジトリ は、これから人間にとっての設計書でもあり続けます。

• OpenAI, Harness engineering: leveraging Codex in an agent-first world
  https://openai.com/index/harness-engineering/