ハクソク

世界を動かす技術を、日本語で。

ハーネスエンジニアリング：エージェントファーストの世界におけるCodexの活用

1日前原文(openai.com)

概要

  • Codexエージェント が全コードを自動生成した社内ソフトウェア開発の実験
  • 人間は設計・指示・レビュー に専念し、コードは一切手書きせず
  • リポジトリ知識管理やアーキテクチャ強制 でエージェントの生産性と信頼性を最大化
  • 人間の時間と注意力 が最大の制約であり、エージェントの自律性強化が鍵
  • 学びと課題 から、今後のエージェント駆動開発の指針を提示

Codexエージェントによる完全自動コード生成の実践

  • 5ヶ月間、Codexエージェントのみで社内β版ソフトウェアを開発・運用
  • 手書きコードゼロ を徹底し、アプリロジック・テスト・CI設定・ドキュメント・ツール全て自動生成
  • 初期リポジトリ構成 （CI、パッケージ管理、AGENTS.md等）もCodex CLI＋GPT-5で自動生成
  • 3名→7名体制 で1500以上のPRを作成・マージ、日平均3.5PR/人の高スループット
  • 数百人の内部ユーザー が利用、外部αテスターも参加

エンジニアの役割再定義

  • 人間は環境設計・意図指定・フィードバックループ構築 に集中
  • エージェントが作業できる抽象化とツール群 を整備することが主業務
  • タスク分解・設計・レビュー・テスト をプロンプトでCodexに指示し、PR作成を自動化
  • 人間の直接的なコードレビューは任意、大半はエージェント同士で完結

アプリケーション可読性向上の工夫

  • QAのボトルネック化 を受け、UI・ログ・メトリクス等をCodexが直接読み取れるよう拡張
  • git worktree毎にアプリ起動可能化 し、CodexがUIテスト・バグ再現・修正検証を自動実行
  • Chrome DevTools ProtocolやDOMスナップショット機能 を組み込み、UI挙動検証を自動化
  • ローカル観測基盤（LogQL/PromQL） を導入し、パフォーマンス要件も自動検証

リポジトリ知識管理の最適化

  • AGENTS.mdは目次のみ、詳細知識はdocs/ディレクトリに構造化保存
  • 設計・アーキテクチャ・品質・実行計画 等を体系的に管理・バージョン管理
  • 知識の鮮度・網羅性・クロスリンク をCIや専用エージェントで自動チェック
  • 「マップを渡す」方針で、エージェントが必要な知識を段階的に探索可能化

エージェント可読性・アーキテクチャ強制

  • エージェントが直接参照・推論できる情報 のみをリポジトリに集約
  • 外部ドキュメントや口頭知識は不可視 とみなし、全てリポジトリ内に反映
  • 依存関係や抽象化は「エージェントが理解しやすい」ものを優先
  • 各ビジネスドメインを固定レイヤー構造（Types→Config→Repo→Service→Runtime→UI）で厳格管理
  • 依存方向や許可エッジをカスタムリンターで自動検証し、構造劣化を防止

人間の時間・注意力の最大活用

  • 最大の希少資源は人間の判断力・集中力
  • エージェントの自律性強化・可読性向上で人間の介入を最小化
  • 設計・知識管理・アーキテクチャ統制による「エージェントレバレッジ」の最大化

今後のエージェント駆動開発への示唆

  • 人間は「コードを書く人」から「環境・意図・知識を設計する人」へ転換
  • エージェントが安全かつ高速に開発できる基盤構築が最重要課題
  • 知識管理・構造強制・自動検証の仕組み化がエージェント開発の成否を左右
  • 人間の時間を守るための「機械による自動レビュー・修正・知識更新」体制の確立
  • 今後は複数エージェント連携や他AIツールとの協調も視野に入れた設計が必要

Hackerたちの意見

何週間もかけて、最終的に100万行のコードを出荷したんだ… 5ヶ月後、リポジトリにはアプリケーションロジック、インフラ、ツール、ドキュメント、内部開発者ユーティリティを含む約100万行のコードがある。 この期間中に、約1500件のプルリクエストがオープンされ、Codexを推進するたった3人のエンジニアの小さなチームによってマージされた。 これは、エンジニア1人あたり1日平均3.5件のPRを処理したことになる。驚くべきことに、チームが7人に増えたことで処理能力はさらに向上している。 重要なのは、これはただの出力ではないことだ。製品は内部で何百人ものユーザーに使われていて、日々のパワーユーザーも含まれている。これはすごい処理能力だよ。良い基準は何だろう？エージェントコーディングの前、エンジニアが期待されていたPRの数はどれくらいだった？ 2〜10くらいかな？この6ヶ月でソフトウェアが良くなったと感じる人はいるのかな？エンジニアの数は多分同じだから、主要なソフトウェアアプリで5倍速のサイクルを期待すべきだけど、そうは見えない。AIアプリはすごく早く変わるけど、これは新しい分野だから当然だと思う。でもそれ以外では、あまり変わっているとは思えない。

└

彼らは製品が具体的に何であるかを明示しなかったから、投稿を判断するのは不可能だ。なぜか「エージェント」のほとんどの使い方は、さらに別のAI製品を作るためのもので、まるで亀が重なっているみたいだ。これは「エージェント」の力よりも、ハーネスの分野についてのことを多く語っているのかもしれない。

└

100万行のコードになった これは「コードベースを掃除したことがない、コードが多すぎて、エージェントやLLMに掃除させることすらしなかった」という匂いがする。100万行のコードはほとんど必要ないよ。これにはソフトウェア、インフラ、テスト、運用ツールが含まれている。3週間でLinuxカーネルを出荷したわけじゃないって、分かってるよね。コードはすでにスパゲッティ状態で、基本的な機能は大丈夫だけど、シンプルにしたり、絡まりを解いたり、維持するのがどんどん難しくなるよ。

└

面白いことに、Firefoxは現在の行数を約250万LOCとリストしている。これは、数年間で約100万のコミットから来ている。コミットごとに約3行追加されることになるけど、ほとんどが完全な追加ではなく修正だから、そんなにおかしくはない。ここでは、1500件のPRと100万LOCがあって、1PRあたり約650行のLOCが追加されている。覚えておいて、PRの合計が650行ではなく、追加と削除の後のバランスが+650行だよ。注意深い読者への面白い質問： - 10年後、1年でFirefoxのコードベース分のLOCが増えるプロジェクトはどんな感じになるのか？ - 行数はツールの冗長性について何を示していて、プロジェクトの目的が明確に開示されていないことについて何を示しているのか？ - 手動でコードを書くことがない世界でLOCを気にする理由はあるのか？ コードベースが大きくなるとトークン使用量はどうなるのか？ - LLMの使用が行数を増やすことが確認された場合、数ヶ月の使用後に手動コーディングに戻りたいコードベースにはどんな影響があるのか？（例えば、ツールが高くなるから）

└

主要なソフトウェアアプリで5倍速のサイクルを期待すべきだ それは何のためで、どういう感じになるの？すべてを最大速度で劣化させるの？私が普段使っているアプリやプラットフォーム - GitHub、Spotify、Googleマップ（いくつか挙げただけだけど） - は最近、明らかに劣化しているよ。

└

AIエージェントのおかげでドメイン知識へのアクセスが楽になるから、確かに良くなってると思う。でも、問題は人々がコードをうまく覚えてないことなんじゃないかな。変化のスピードが増すにつれて、問題は長期的なものになると思う。成功するプロダクトは、よく考えられた体験や顧客発見に依存してるから（OpenAIのForward-Deployed Engineerの求人を見てみて）、コードの速度はあまり関係なくなるんだよね。正しい問題を解決していて、良いチームがいるなら、競争優位はコードの速度以外のところから来ると思う。もっと重要な質問は、速いコードが長期的にもっと価値を生むのかってことだと思う。今のところ、私たちは1日に3.5回プルリクエストをしてるって言ってるけど、いいね、頑張ってるねって感じ。3つのプルリクエストを1つにまとめれば、1日に1回になるだけじゃん。これは実際にはあまり意味のない定量的データだよね。

└

Claude Codeのチームが主張してることに比べると、これはかなり穏やかだね。

└

この1年くらい、ずっと感覚でコーディングしてたけど、そろそろやめようと思ってる。実際、昔のコパイロットのオートコンプリートワークフローに戻って、そこを最大限に活かせるか挑戦したいなって思ってる。ほとんどのコードを書くのは自分でやって、AIを使ってフローステートを強化したり、ブロッカーを取り除く方法を見つけたい。ツールは実際のコード生成は最小限に。

先日、e-vape工場で働く人たちの動画を見た。彼らはコンベアベルトからたくさんのe-vapeを拾い上げて（それぞれ6つのe-vapeがある）、口にくわえて、約5秒間激しく吸ってから、次のバッチをテストしていた。AIが書いたPRの数百行の変更を人間がレビューするのもあまり変わらないね。

└

本当にその通り。PRが1000行あったら、全部をチェックするんじゃなくて、ほんの数行だけ見て、残りはテストスイートに任せるかな。

脱線だけど、これが2月に公開されて以来、HNに15回以上投稿されたのは面白いね。https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... でも、これが唯一注目を集めた投稿なんだ。内容がほぼ同じだから、フロントページに載るのがちょっとランダムだってことが浮き彫りになってる。（ただ、これが「Leveraged」を大文字にした唯一の投稿だから、もしかしたらそれが秘密かも）

└

https://github.com/tsz-org/tsz

これはまさに私がやっていることと同じだ。 - Claude/Codexに自分の作業を検証する方法を与える（ブラウザ、スモークテスト、e2eテスト、高忠実度のローカル環境） - すべてのコンテキスト（問題追跡、ドキュメント、アイデア、計画、作業ログ）をリポジトリ内に保持する（https://github.com/shepherdjerred/monorepo/tree/main/package...） - Claude/Codexに可視化へのアクセスを与える（Grafana、Prometheus、Tempo、PagerDuty） - Claude/Codexに、フェイルファースト、型安全、境界でのパースなどの良いエンジニアリングガイドラインに従わせる まだコストとCIの負荷のために完全な自律性を達成できていない。

└

いい結果が出るのかな？ドキュメントの代わりにAIにコードを読ませる方が簡単だと思った。これってコードのコメントと同じだよね。すぐに古くなるし。

まだ理解できないのは、なぜ大量のコード生成が自慢になるのかってこと。過去3年間でソフトウェアが大きく良くなったとは思えないし、むしろ雑になった気がする。報酬ハッキングについて知ってる人が、生成されたコード行数みたいなシンプルな目標を品質の指標に選ぶのが驚きだよ。生成される行数をできるだけ少なく最適化する必要があると思うし、二次的な最適化は人間が読みやすいことだと思う。提供者にとっては、生成された行数が多いほどトークンが使われて、顧客への請求が増えるから問題視されてないんじゃないかな。既存のコードベースで作業しているとき、良いコミットって追加された行と削除された行の差がマイナスになることが多いんじゃない？コードベースを膨らませたくないし、もっと洗練されたエレガントなものにしたい。これを読んで、彼らがやったことがもっと少ない行数で達成できたんじゃないかと思った。

└

そうだね、個人コンピューティング—テキスト編集、SVGのアンチエイリアスなどは、2万行のコードに収まる（VPRIのSTEPSプロジェクト）から、100万行のコードは個人コンピューティングの50回の再発明だよ。でも、人間がこの問題を2万行で解決できたとは考えにくい。サスマンは「私たちは本当に計算の仕方がわからない！」って言ってたし、LLMは永遠のプログラミング習慣として既存の声を固定化しなきゃいけなかったから、プログラミングができないペルソナを選んじゃったんだよね。今、それに縛られてる。Claudeは私たちのチケット、実装、ドキュメント…「ノードの役割にはその権限が必要ない、サービスアカウントにすべきだ」って言うと、喜んで正しいことをするけど、味覚のセンスは全くないし、クリアしようとしてるエラーメッセージは「ノードの役割にはその権限がない、システムプロンプトは『短く、バカにしないで』って言ってる」ってだけ。おじいちゃんたちが最後の砦かもね。

└

現在の「行数」は、基本的にコンパイラから出てくるバイナリコードと同じものだよ。ほとんど見ないし、手で触ろうとも思わないもの。実際の「コード」は、ハーネスを動かすすべてのものだ。今の問題は、ハーネスがまだ決定論的でないこと。つまり、コンパイラが出力プログラムをビルドごとに少しずつ違う動作をするようなもので、コンパイラがこの問題を最小限に抑えるためにバイナリプログラムをパッチしようとしたり、さらに悪いことに、全体を逆アセンブルして何をしているかを理解しようとして、変更を加えて再コンパイルするような感じ。

└

行数は常にひどい指標だった。でも、他の条件が同じなら、それは一つの指標だよね。もし他の条件が同じでないなら、通常そうなるけど、それは指標にならない。最近はAIに注目が集まってるけど、3年前には非エンジニアが英語で自分の欲しいものを説明して、他のソフトウェアによって動作する（まあ、なんとなく）ソフトウェアが生成されるなんてなかったよね？それって「ソフトウェアがずっと良くなった」ってことじゃないの？それ以外に「ソフトウェアが良くなった」をどう測るのか分からない。新しいアプリケーション？もっと多くの機能？どうやって雑な部分を測るの？Googleマップが突然、間違った道に案内することが増えたの？あなたの主観的な経験を疑っているわけじゃないけど、どうやって判断するの？ドキュメントはドキュメントで、スプレッドシートはスプレッドシートだよね。私たちは、より大きな違いを生む可能性のあるモデルが登場してからまだ約10ヶ月しか経っていなくて、まだそれをどう使うのがベストかを模索しているところなんだ。

└

ソフトウェア開発者の生産性を追加された行数で測るのは、航空宇宙エンジニアの生産性を追加された質量で測るのと同じだと言われているよ。それは指標だ。でも、あまり良い指標とは言えないことが多い。だけど、測るのは簡単なんだ。

└

「提供者側は、生成された行数が多いほどトークンが使われて、顧客への請求が増えるから、問題だとは思ってないんじゃないかな。自分の請求が増えるのを避けるためにトークンの使い方には疑念を抱いてる！でも、自分で少ない行数のコードを書くのにもっと努力が必要だと感じるから、手っ取り早くて雑なAI生成の解決策は、むしろ行数が多くて、少ない行数の簡潔でエレガントな解決策よりも生成コストが安いと思う。」

└

ただ単に大量のコードを書くためじゃなくて、複雑で大きなソフトウェアを自ら構築したからなんだよね。Linuxカーネルの行数と、誰かのGitHubのオモチャカーネルを比べると、その行数の違いが複雑さの指標になるはず。「トルストイが自分の本のページ数を自慢してるのは変だよね、俺は『スポットが学校に行く』って本を書いたけど、たった20ページだし。」

└

「報酬ハッキングについて知ってる人たちが、生成された行数のようなシンプルな目標を質の指標として選ぶのは驚きだ。シンプルな答えは、行数を関連する指標として推進すること自体が報酬ハッキングだってこと。大きな行数を主要な指標として推進する方が簡単なのか、それとも難しい指標に対してエージェント工学を証明する方が簡単なのか？一般的に言えば、ソフトウェアプラクティスのマーケターたちは、かなりの間その方向に押し進めてきた。「クラウドが必要だ」、「スケールでアジャイルをやる方法」、「マイクロサービスをすべて」など。」

└

これは、LLMが大規模なコードベースと相性が悪いという主張への反論だと思う。コードの質についての自慢というよりは、コードの複雑さとLLMがその複雑さに対処できる能力についての自慢だね。その複雑さが本当に必要かどうかは別の話。コードベースが10倍に膨れ上がっても、それに伴うコストがビジネスの観点からソフトウェアを開発するコストよりも低ければ、選択は明確だよ。

└

まあ、正直言って、目標がどんどん変わっていくのはかなり激しいよね。「AIが『真剣な』プロジェクトで働けない」とか「おもちゃプロジェクトに限られている」というのは長年の批判だ。でも、やっぱり大きなプロジェクトにはある程度の行数が必要だし、これが当たり前じゃないとか悪いことだと pretend するのはちょっとおかしい。だから、この質問への答えは大体こんな感じかな：エージェントが大きめのコードベースで働けることを確立するのは価値がある。なぜなら、1) それができないことが批判されてきたし、2) 多くのソフトウェアプロジェクトにとって必要なことだから。

└

「プロバイダーにとっては、生成されるラインが多いほどトークンが使われて、顧客への請求が増えるから、問題視されてないんじゃないかな。もっと制約のあるエレガントなコードを生成するには、もっと考えるトークンが必要で、指示に対する遵守も強くなる。だから、請求のためにやってるっていう単純な見方は間違ってるよ。」

こういう息を呑むようなブログ記事が、もっと教育的になってほしいな。例えば、これらの超パワーを持つワークフローのセットアップ方法を実際にウォークスルーして、具体的なデモをしてほしい。私はAI懐疑派じゃないよ。むしろ、実際の超パワーを逃したくないんだ。

└

私はこの投稿で説明されていることを、かなり大きなプロジェクトで結構やってるよ。私にとって効果的なことはこれだね： - 新機能のためにgherkinフィーチャーを書く；強化のために更新する；リファクタリングのためには触らない。PRにはこれらの名詞をラベル付けする。 - プリプッシュフックを使って型チェック、リンティング、ユニットテスト、その他のクイックでスクリプト可能な検証を行う。 - リポジトリにvitepressサブサイトを作って、エージェントに管理させる。 - 重要な原則やアーキテクチャなどを文書化する。 - すべてのページをリストアップし、yamlフロントマターの説明を付けたCLIコマンドを作って、エージェントがコンテキストウィンドウを圧迫せずに読むものを選べるようにする。 - DDDとモノレポを使う。 - ロジックをヘッドレスレイヤーに書いて、レイヤーをアプリに組み合わせる。エージェントはレイヤーをうまくナビゲートするよ。 - zod（またはあなたの言語の同等物）を使って、契約ファーストのAPI開発をする；これが私のお気に入りの部分だね、私はorpcを使ってる。 - 「コード」という単一のスキルを作って、ライフサイクルを説明する：ワークツリーを開く、.envを設定して他のエージェントとの競合を防ぐ（未使用のポートを選ぶなど - dockerがここでは便利）、フィーチャーファイルを書くまたは更新する（ここで仕様を交渉する）、実装、検証（例：playwright mcpを使って）、プリプッシュチェック、プッシュしてレビューを待つ、解体してメインを早送りする。 - testcontainersは、複数のエージェントが競合せずにテストを実行できることを保証するのに最適だよ。正直、私はこれだけのスキルしか持ってない。他のことはドキュメントに書いてある。こうやっていると、すごく生産的な気分になるんだ。「良いソフトウェアを作る」という意味でね、行数の意味ではなく。

└

そうだね。このリポジトリに関する記事を参考にしてたんだけど、「プロバイダー」を具体的にどう実装して、インポートレイヤーをどう強制してるのかを推測するのがすごく難しかった。サンプルリポジトリがあればよかったのに。

これって「無限」の計算能力とトークンがある場合にしか通用しないかも。$20プランを使ってた私からすると、この純粋なエージェントアプローチは無理だね。すぐに限界に達しちゃって、結果も少なくなっちゃうし。私がすごく効果的だと思ったのは、人間が書いたコードを参考にして、それを拡張するように頼むこと。全体をスキャフォールドして、アーキテクチャを設計して、サンプルコード（コントローラー、サービス、モデル、コンポーネント、データベーススキーマ、認証の仕組みなど）をいくつか書くんだ。そうするとLLMが注意を向けやすくなるからね（言葉遊びも含めて）。実装方法について詳細がたくさん書かれたスタブを用意する感じ。高い抽象度の擬似コードみたいなものを作って、LLMに実装を頼む。失敗したら、全ての変更を元に戻して、スタブを調整して、再挑戦するのがいいことが多い。あるいは、変更をコミットして、新しいフレッシュなコンテキストを使って、何が間違ったのかだけに対処する。 - このエージェントアプローチを最初から試すたびに、結果も限界も満足できないことが多いんだよね。

└

$20プランじゃどこにも行けないよ。$200/月にアップグレードすれば、もっと使えるようになるけど、私のようなハードコアユーザーには、決して十分とは言えない。オープンAIのパーティーにRSVPするだけで200倍の使用量を得た人たちが本当に羨ましい。

私はAI懐疑派ではないけど、この記事の意図には懐疑的だよ。エージェントファーストのエンジニアリングについて素晴らしい主張をしていて、実際の製品、実際のユーザー、成長している実際のチームに基づいて本当のケースを作ろうとしているけど、何が作られたのかも見せずに、他のAIの誇大広告記事と同じように。

ここでライアンにインタビューしたよ：https://www.latent.space/p/harness-eng 彼はロンドンでその話のバージョンをした：https://www.youtube.com/watch?v=am_oeAoUhew

自分もtsz[1]で同じ実験をしてるんだけど（実際、過去5ヶ月間ずっと）、非常に似たような結論に達したよ。良いアーキテクチャの分割を強制するためのハーネスがたくさんあるし、テストやCIも充実してる。tszでの作業の目的は、AIを使って大規模なプロジェクトをどうやって進めるかを学ぶこと。最終的には、同じワークフローや姿勢を使って、UIを持つ顧客向けのアプリを作ることもできると思う。OpenAIが自動ブラウザテストや動画をワークフローの一部として活用しているのも見たよ。モデルが進化すれば、ソフトウェアを作るこの方向性は最終的には意味を持つようになると思う。ただ、まだその域には達してないけどね。でも、OpenAIの曖昧な主張とは違って、出力を見せることができるのはいいよ！Lovableのように非常に高い自動化レベルを提供するソリューションは、ちょっと楽観的すぎるし、自動テストと密接に結びついてるわけじゃない。