手書きコードを「書かない」という選択――エージェント主導の開発で変わるエンジニアの役割

2026年6月10日 H.Ueda

今回は、OpenAIから発表された Harness engineering: leveraging Codex in an agent-first world という記事を参考に、AIエージェントが開発の主体となる「エージェント・ファースト」の世界でのエンジニアリングの在り方について整理してみます。

参考まで。

ここ数年でAIによるコーディング支援は一般的になりましたが、この記事で紹介されている試みはさらにその先を行っています。なんと、5か月の開発期間で「手書きコードを0行に抑える」という制約を設け、100万行規模のソフトウェアを構築したという内容です。

エンジニアの仕事は「コードを書くこと」ではなくなる？

これまでのエンジニアリングでは、人間がキーボードを叩いてロジックを1行ずつ記述するのが当たり前でした。しかし、Codexのような高度なエージェントを活用する場合、人間の役割は「コードの記述者」から「環境の設計者」へとシフトします。

この記事では、この新しい役割を「ハーネス（馬具・装具）・エンジニアリング」と呼んでいます。馬を操るようにエージェントを制御し、彼らが本来の力を発揮できるような土台を整えるイメージでしょうか。

実際にこのプロジェクトでは、以下のような成果が出ていたようです。

開発速度: 手書きと比較して約10分の1の期間で構築。
スループット: エンジニア1人あたり1日平均3.5件以上のプルリクエスト（PR）を作成。
体制: わずか3〜7人のエンジニアで、100万行のコード（ロジック、インフラ、ツール、ドキュメント含む）を管理。

エージェント主導の開発サイクル

エージェントが主体となって開発を進める場合、人間は「何をしたいか」という意図を伝え、エージェントがそれを実行するための「フィードバックループ」を構築することに注力します。

具体的なプロセスは、以下の図のようなイメージになります。

flowchart TD
    A[人間の意図・プロンプト] --> B[Codexエージェント]
    B --> C[コード生成・修正]
    C --> D[ローカルでの自動レビュー]
    D --> E{テスト・チェック}
    E -- 失敗 --> B
    E -- 成功 --> F[別エージェントによるレビュー]
    F -- 修正が必要 --> B
    F -- 承認 --> G[プルリクエスト作成]
    G --> H[人間による最終確認]

このサイクルで面白いのは、何かが失敗したときに人間がコードを直すのではなく、「なぜエージェントが失敗したのか」を分析し、環境や指示を改善する点です。

従来型開発とハーネス・エンジニアリングの比較

人間がコードを書く場合と、エージェントに書かせる場合では、注力すべきポイントが大きく異なります。

項目	従来のエンジニアリング	ハーネス・エンジニアリング
主な作業内容	コードの記述、構文のデバッグ	システム設計、指示（プロンプト）の定義
修正のしかた	エディタで直接ソースを直す	エージェントの不足能力を特定し、補完する
ドキュメント	実装の備忘録として書く	エージェントが作業するための「仕様書」
重視されるスキル	言語・フレームワークの習熟度	課題の分解能力、環境の構築力

人間が直接コードを触らないことで、システム全体の一貫性や、エージェントが理解しやすいコード構造（レジビリティ）を維持することに意識が向くようになります。

「空のリポジトリ」から始まった自律開発

このプロジェクトの徹底している点は、最初のコミットからして人間ではなくエージェント（GPT-5ベースのCodex CLI）によって行われたことです。

リポジトリの構造、CI/CDの設定、さらには「エージェントがこのリポジトリでどう振る舞うべきか」を記した AGENTS.md というファイルまで、すべてがCodexによって作成されました。人間が書いた「既存のコード」という重しがない状態で、エージェントにとって最適な環境がゼロから作られたというわけです。

実際に運用が始まると、エンジニアの仕事は「深さ優先」のタスク分解に変わります。大きな目標を小さなコンポーネントに分け、エージェントにそれを作らせ、それらを組み合わせてさらに複雑な課題を解決していく。この「ブロックを積み上げる」感覚は、従来のコーディングよりも、より抽象度の高いアーキテクチャ設計に近いかもしれません。

課題とこれからのエンジニア像

もちろん、すべてがスムーズに進むわけではないようです。初期段階では、エージェントに与えるツールや抽象化が不十分で、進捗が遅れることもあったと言及されています。

しかし、そこで人間が「自分で書いたほうが早い」と手を出さずに、ぐっと堪えて「エージェントが自律的に動ける仕組み」を整えたことが、後の10倍近い開発速度につながったのでしょう。

これからのエンジニアには、以下のような姿勢が求められるのかもしれません。

「手書きコード」への執着を捨てる: 自分の手で書くことよりも、システムが正しく動く仕組みを作ることに価値を置く。
意図を言語化する能力: エージェントが迷わないよう、要求を厳密かつ簡潔に伝える。
フィードバックの設計: 壊れたときに、どうすればエージェントが自己修復できるかを設計する。

エージェント・ファーストの世界は、エンジニアから仕事を奪うのではなく、より高度な「設計と監督」という領域へ私たちを押し上げてくれるものだと感じました。

MicroArchitectures

H.Ueda

Programmer

ブログ