目次を表示する

ハーネスエンジニアリング

第7章 エピローグ ── エンジニアリングの本質は変わらない

第7章 エピローグ ── エンジニアリングの本質は変わらない

批判と懐疑論

ハーネスエンジニアリングは称賛だけを受けているわけではない。技術コミュニティには正当な批判と懐疑論が存在する。

批判1：「グリーンフィールドでの過剰一般化」

最も印象的な成果事例——OpenAIの100万行・1,500PR——はほぼすべてグリーンフィールドプロジェクト（あるいは最初からハーネスと共に育てたコードベース）から来ている。

一貫性のないテスト、脆弱なアーキテクチャ制約、モジュール間の密結合——そういったレガシーコードベースへのハーネス後付けは、まったく別の問題だ。カスタムリンターを導入しようとしても、既存コードが数百件の違反を抱えていれば機能しない。計画フェーズを導入しようとしても、スコープが常に不明確なメンテナンス作業には馴染まない。

この批判の正当性：高い。ハーネスエンジニアリングの論者の多くはグリーンフィールドでの体験を語っており、レガシー適用の難しさを十分に論じていない。これは未解決の課題として残っている。

批判2：「検証レベル1-2への過剰一般化」

Böckelerは自身の論考の中で「この方法が確実に有効なのは決定論的なタスク（検証レベル1〜2）だ」と正直に述べている。コードが型エラーなく動くか、テストが通るか——これらは客観的に検証できる。

しかし創造的なアーキテクチャ設計、倫理的な判断、曖昧な要件の解釈——これらは検証レベルが高く、「ハーネスで品質担保できる」という証明はまだない。

この批判の正当性：中程度。ほとんどの日常的なコーディングタスクは検証レベル1〜2に収まるため、実用上の影響は限定的だ。ただし「何でもできる」という過剰な期待を抑制する意味で重要な指摘だ。

批判3：「組織的制約を無視した楽観論」

2026年2月のワークショップポジションペーパーはこう述べている。

「技術はどんな組織的問題も解決しない。人間・システムレベルの制約に先に対処しなければ、ハーネスエンジニアリングも例外ではない」

エージェントへの権限委譲に心理的抵抗があるチーム、承認フローが複雑でエージェントの計画を素早くレビューできない組織、失敗を許容する文化がない環境——これらがある限り、ハーネスの技術的な整備だけでは効果が出ない。

この批判の正当性：高い。特に大きな組織での導入を検討する場合、技術的な設計より組織的な準備の方が先決であることが多い。

変わらない問い

ハーネスエンジニアリングの出現は、ソフトウェアエンジニアリングの歴史の中でどう位置づけられるだろうか。

振り返ってみると、「複雑さを制御する仕組みの設計」という問いはいつも同じ場所にある。

1960〜70年代：プログラムの規模が大きくなるにつれ、「構造化プログラミング」が生まれた。GOTO文の乱用を制限し、制御フローを予測可能にする。

1990〜2000年代：チームが大きくなるにつれ、「デザインパターン」「リファクタリング」「アジャイル」が生まれた。コードの複雑さを管理し、変化に対応できる構造を作る。

2010年代：システムが分散するにつれ、「マイクロサービス」「CI/CD」「Infrastructure as Code」が生まれた。システム全体を設計可能・検証可能・再現可能にする。

2026年：AIエージェントが「第三のプログラマー」（コードを書く人間、テストを書く人間、そしてエージェント）として加わるにつれ、「ハーネスエンジニアリング」が生まれた。エージェントの振る舞いを設計可能・検証可能・再現可能にする。

問いは常に同じだ。「制御できないものを、どう制御可能にするか」。

エンジニアの役割移行

Peter Steinbergerの言葉は示唆に富む。

「すべてのコード行を読まずにコードを出荷するが、アーキテクチャと設計の決定は注意深く管理する」

これはソフトウェアエンジニアリングの役割定義の変化を示している。

従来、エンジニアの価値は「良いコードを書ける能力」に強く結びついていた。何行書けるか、どれだけバグを少なくできるか、アルゴリズムをどれだけ効率的に実装できるか。

ハーネスエンジニアリングが示す次のフェーズでは、エンジニアの価値は「良い環境を設計できる能力」により強く結びつく。どんなアーキテクチャを選ぶか、どんな制約を設けるか、どんなフィードバックループを作るか、何を人間が決め何をエージェントに任せるか。

これは「エンジニアが不要になる」という話ではない。むしろ逆だ。アーキテクチャの判断、設計の選択、ビジネスロジックの理解——これらは今まで以上に人間の仕事として残る。コードを書く速度ではなく、何を作るべきかを判断する能力が価値の中心になる。

「ハーネスが壊れていた」から始まる

冒頭でこう書いた。「エージェントは壊れていない。ハーネスが壊れているのだ。」

この言葉の裏には、もう一つの含意がある。ハーネスは「壊れた」状態から始まって当然だということだ。最初から完璧なハーネスを設計できる人間はいない。実際の失敗が積み重なってはじめて、ハーネスは実用的なものになる。

Hashimotoの AGENTS.md の各行が「過去の失敗の記録」であるように、優れたハーネスはすべて失敗から生まれる。

だからこそ、今日から始められる。複雑なシステムは必要ない。小さなAGENTS.mdとビルドコマンドの定義から始め、エージェントが失敗するたびに一行追加する。それが積み重なったとき、気づくと「信頼できるエージェント環境」ができている。

ハーネスエンジニアリングとは、失敗を資産に変える工学の実践だ。

参考文献

本シリーズは 2026年3月30日時点の情報を元に執筆しました。