最近、AIコーディングエージェント周りでハーネスエンジニアリングという言葉を見かけるようになりました。プロンプトの工夫に近く見えますが、実際にはモデルの外側を設計する話です。今回は、その定義とアプリ開発への活かし方を整理します。

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

ハーネスが指す範囲は記事によって少し違います。Anthropicの評価設計記事では、エージェントハーネスを次のように定義しています。

“An agent harness (or scaffold) is the system that enables a model to act as an agent.”

つまりハーネスは、言語モデルを仕事のできるエージェントとして動かす周辺システムです。Anthropicは、評価の実行、記録、採点を担うevaluation harnessを別に定義しています。本稿ではOpenAIの記事に近い広い意味で、評価やリポジトリ側の仕組みまでを扱います。

この意味でのハーネスエンジニアリングは、必要な資料、ツール、実行環境、権限、作業状態、テスト、ログ、再試行、人間へ判断を戻す条件までを設計し、失敗を見ながら改善することです。

プロンプトやコンテキストとの違い

プロンプトエンジニアリングは「何を、どう頼むか」、コンテキストエンジニアリングは「今、どの情報を見せるか」を設計します。ハーネスエンジニアリングは、その二つも部品として使いながら、「どの資料とツールを使い、何をもって完了とするか」まで設計します。

具体的には、次のようなものがハーネスになります。

  • AGENTS.mdや設計資料など、最初に読む地図
  • リポジトリ、ビルドツール、シミュレータなどの実行環境
  • タスクリスト、進捗ファイル、Gitなどの作業状態
  • ビルド、テスト、Lint、画面確認などのフィードバック
  • サンドボックス、承認、停止条件などのガードレール

OpenAIの実践記事でも、巨大な説明書ではなく、短いAGENTS.mdを地図にして必要な資料へ案内し、設計ルールはLintや構造テストで検査できるようにしています。

アプリ開発でどう活かすか

アプリ開発では、コードを書かせるだけでなく、現象を再現する → 修正する → ビルドとテストを実行する → シミュレータで操作する → 画面とログを確認するまでを一つのループにします。条件を満たさなければ、修正へ戻します。

iOSならxcodebuildとSimulator、AndroidならGradleとEmulatorを使えるようにします。スクリーンショット、アクセシビリティ情報、クラッシュログも読めれば、UIや実行時の問題を確認しやすくなります。

長い開発では、機能一覧や進捗をリポジトリに残します。Webアプリを題材にしたAnthropicの実験でも、進捗ファイルとGitで次のセッションへ状態を渡しています。ここで紹介した方法は、この考え方をモバイル向けに置き換えた活用案で、検証結果ではありません。

一方、リリース、署名、本番データの変更などは人間の承認を必須にする。自動で進める範囲と、人間へ戻す境界を決めることもハーネスの一部です。

小さく始める

ハーネスは複雑にするほど良いわけではありません。AnthropicがOpus 4.5で行った一例では、著者の評価で成果物が改善した一方、単独実行の20分・9ドルに対し、フルハーネスは6時間・200ドルかかりました。モデルの進化に合わせて不要になった部品も報告されています。

まずは短いAGENTS.md、一つのビルドコマンド、明確な完了条件が最初の入口になります。失敗したときに、足りなかった資料、ツール、検証を少しずつ足していく。ハーネスエンジニアリングは、AIにうまくお願いする技術というより、AIの迷いを減らし、間違いを検出して修正へ戻りやすくする開発環境の設計だと思います。