「ハーネスエンジニアリング」（公式の記事では agent harness design）は、公式の用語ではありませんでした
AI エージェントの話で「ハーネスエンジニアリング」（公式の記事では agent harness design）という言葉を見かけるようになりました。
意味はだいたい共通しています。モデルそのものではなく、その外側を設計すると結果が変わる、という考え方です。外側というのは、使わせる道具、与える権限、毎回読ませる指示書、動かし方のループあたりを指します。
私は一人会社を Claude で運用していて、まさにその外側をいじっています。なので公式の資料ではどう書かれているのかを確かめました。2026年10月12日に、Anthropic と Claude の公式記事を3本開いて読んでいます。
結論は3つです。
「ハーネスエンジニアリング」という語は、その3本には出てきませんでした
公式が使っているのは harness（agent harness）で、それを設計することは agent harness design と書かれています
ただ、公式の中でも harness という語は2つの別のものを指していました
公式の定義
いちばんはっきり定義しているのは「Agent Harness Design: 3 Patterns for Harnessing Claude's Intelligence」（2026年4月2日）です。
agent harness は "the software scaffolding around a model"、つまりモデルを取り巻くソフトウェアの足場だと書かれています。
中身として挙がっているのは4つです。
ループ
ツール
コンテキスト管理
ガードレール
この4つが、生の知能を動くエージェントに変えるもの、という説明です。
そして harness の設計（agent harness design）とは、その足場に何を入れるかを決めることであり、モデルが良くなったら何を外せるかを決めることだとされています。「外す」が定義に入っているところが、私には大事に見えました。
harness と書かれていても、指すものが2つある
もう1本、評価についての記事も読みました。「Demystifying evals for AI agents」（2026年1月9日）です。
こちらでも agent harness は、モデルをエージェントとして動かす仕組みだと説明されています。入力を処理し、ツール呼び出しを取り回し、結果を返すもの、という書き方です。scaffold（足場）という言い換えも添えられているので、上の記事と同じものを指していると読めます。
ただ、同じ記事に evaluation harness という別の語が出てきます。こちらは評価を端から端まで走らせる基盤のことで、エージェントの足場とは別物です。
公式の用語集は見つかりませんでした。なので英語の記事で harness とだけ書かれているときは、どちらの話なのかを前後から確かめる必要があります。
Claude Code そのものが harness
調べていていちばん大事だと思ったのはここです。
evals の記事では、Claude Code そのものが柔軟な agent harness の例として挙げられています。エージェントを評価するとき、評価しているのは harness とモデルの組み合わせだとも書かれています。
ここからは私の読みです。Claude Code を使っている人は、もう harness の中で仕事をしています。CLAUDE.md や許可の設定を書き換えるのは、その足場の一部を自分で組み替えていることになると思います。
メリット
この考え方の利点は、モデルを替えずに結果を変えられることです。
使わせる道具、与える権限、毎回読ませる文書。これはどれも自分の側にあります。モデルの新版を待たなくても、今日いじれます。
デメリット
デメリットもはっきり書かれていました。作り込みすぎた足場は、あとで荷物になります。
Agent Harness Design の記事には、モデルの弱点を補うために作った仕掛けが、モデルが良くなったあとは足場の中の余計な重り（dead weight）になっていた、という話が出てきます。使用頻度の低い指示を先読みでコンテキストに積むのは無駄だとも書かれています。
実際、私も同じことをしました。全セッションが毎ターン読む CLAUDE.md が育ちすぎていたので、71% 削りました。その話は別に書いています。
https://note.com/bebsite/n/nf510fbcdcccb
合う使い方
Agent Harness Design の記事に、3つの型が挙げられています。私の読みを添えて書きます。
足場に頼る前にモデルに頼る。Claude が元から知っている道具（bash など）を使う。独自の道具を増やすほど、モデルが上手くなったときの恩恵を受けにくくなると思います
足場を削る。モデルの力が一段上がるたびに「何をやめられるか」を問う
境界は慎重に置く。harness は Claude の周りに構造を置いて、UX・コスト・セキュリティを効かせるものだと書かれています
逆に言うと、境界には理由が要ります。私の運用では、夜中に無人で動くタスクに何を許して何を許さないかを決めるのがここに当たります。その話も別に書いています。
https://note.com/bebsite/n/n3bfa84243a94
言葉の扱いについて
最後に、調べた目的を書きます。
「ハーネスエンジニアリング」（公式の記事では agent harness design）も「ループエンジニアリング」も、便利な言葉だと思います。
ループエンジニアリングのほうは、私が読んだ3本には対応する語がありませんでした。harness の部品の1つとして、ループ（the loop）が挙がっているだけです。
2026年10月12日追記：そのあと、Claude の公式ブログに「Loop engineering: Getting started with loops」（2026年6月30日）という記事があるのを見つけました。題名にこの語が入っています。ただ、いま話題になっている語として紹介されていて、Anthropic が名付けたとは書かれていません。ループの話は別に書いています。
https://note.com/bebsite/n/n3d71c8b4c5c6
ただ、公式が使っていない語を「公式によると」と紹介すると、読んだ人が公式の資料を探しても見つかりません。
なので私は、世間の呼び名を先に書き、そのあとに公式の語を添えることにしました。
この記事に書いた harness の説明は、2026年10月12日に本文を読んで確かめた範囲のものです。記述は版で変わるので、日付を入れています。
この記事の仕組みを、業務に合わせて組むところまでをココナラで引き受けています。
