AIエージェントの″ハーネス″に関わる混乱と私見
はじめに
「Agentic Coding 生成AI時代のシステム開発入門」という本を出すくらいなのでAIエージェントのハーネスには興味があって、1週間ほど調査した結果、「ハーネス」の見え方が固まりつつあるので、表題についてラフに書き留めておきます。根拠があるものないものがあるので話半分に読んでください。
スライドの形式で読みたい人はこのスライドの30Pまでくらいを読むと、本記事に近い知見を得られます。
1. ハーネスという言葉への混乱
最近、AI Agent関連のドキュメントやブログで「エージェントハーネス」「ハーネスエンジニアリング」という言葉がよく出てきます。言葉がそれぞれ指す概念が曖昧かつズレている場合がちらほらあり、バズワードなのかなと感じてしまうのが最近の悩みです。
内部ハーネスと外部ハーネス
コーディングエージェントユーザ視点でのmartinfowlerのハーネスの記事があって、図を引用する。
このモデルを囲むようにした紫色のハーネスが内部ハーネスで、AIエージェントにおけるLLMモデル「以外」の実装、つまりエージェントの作り手側が考慮するハーネスを指す。
その内部ハーネスを囲むようにしたハーネスが外部ハーネスで、AIエージェントにフィードフォワードとフィードバックを与える環境、エージェントの使い手側が考慮するハーネスを指す。
この内部ハーネスと外部ハーネスについて、要はAIエージェントの作り手と使い手がそれぞれ自分の関心のあることをエージェントハーネスって呼んでて、それを作る一連の領域をハーネスエンジニアリングと呼んでいる。同じ言葉をスコープが違うのに使っている点に混乱がある。
2. 内部ハーネス
(再掲)AIエージェントにおけるLLMモデル「以外」の実装、つまりエージェントの作り手側が考慮するハーネス
内部1：LangChainの立場
「The Anatomy of an Agent Harness」に書いてあるTLDR: Agent = Model + Harness. という定義が彼らの思想の全てである。
LangChainチームがどんな製品を提供しているかを考えると理解できる。LangChain社はユーザーにAgentを作らせるために製品を提供している側面があって、その領域をエージェントハーネスと呼び、ユーザにハーネスエンジニアリングをさせたがっている。違和感はない。
内部2：Anthropicの立場
Anthropicのブログでハーネスという言葉が使われるとき、LLMを長時間駆動させるための馬具として表現しているように思える。具体的には以下3件の記事だ。
ステートレスなLLMモデルに記憶の受け渡しをさせよう、という話が2025/11の記事。
Setupスクリプト、進捗ファイル、git履歴、自動テストなど、リレーのバトンのように受け渡そうとしている様子が分かる。
”GAN”型の評価者エージェントを追加したよ、というのが2026/03の記事。
マルチエージェント構成に関心があるようで、生成Agentと評価Agentからなるマルチエージェント構成でGAN（敵対的生成ネットワーク）ぽく複数のエージェントを競わせたら良かったよ。という話。
2026/04の記事ではモデルの自主性を尊重しよう。と書かれている。
セキュリティ境界への決定論的手段は設定してもいいけど、不要な補助ロジック・ツール・制御...は外そうね。LLMモデルは賢くなるんだから未来には枷にしかならないよ。という話。
ここからは個人の見解なのだけれど。この一連の記事での(内部)ハーネスの定義をLangChainのように素直に受け止められないのは、Anthropicが競合領域に次々にケンカを売るからで、記事の通りに読者が参考にしても妨害されるんじゃねえの？って雑念が消えないからだ。Clineが出たら格安プラン付きのClaude Codeを公開し、Cowarkなどと競合するOpenClawへの定額適用を禁じたりする動きの話です。
要するに彼らが公開するハーネスへの言及は内部ハーネスなのですが、あくまでベンダー側の機能アピール・Claude Managed Agentsなどへの製品戦略であって、Claudeユーザがこのハーネスエンジニアリングを実質的に参考にできるのか？ 参考にしたとて作ったエージェントハーネス部分は競合したら本家に奪われるのではないか？という懸念が残るのがモヤモヤする部分である。
3. 外部ハーネス
(再掲)：AIエージェントにフィードフォワードとフィードバックを与える環境、エージェントの使い手側が考慮するハーネス
外部1：Mitchell Hashimoto氏の立場
Mitchell Hashimotoの「My AI Adoption Journey」というブログで言及されている。
ブログの内容もDeveloperがAIエージェントを使う道のりのなかで、「AIエージェントが同じミスをしないように、解決策を設計する」ことをハーネスエンジニアリングと呼んでいる。普通に使ってる利用者の視点といった形で、個人的にも共感できる。
外部2：OpenAIの立場
OpenAIのハーネスエンジニアリングへの見解は、上記とほぼ同じだ。
生成されたコードは、必ずしも人間のスタイルの好みに合致するとは限りませんが、それでも構いません。出力結果が正しく、保守可能であり、将来の実行エージェントが読み取れる限り、基準を満たしています。
Anthropicと異なり、エージェントの利用者向けの色が強い。この辺は妄想だけどOpenAIはAGI、つまりモデルでの完結が目標なので、内部ハーネスを押し出すとコンフリクトするのかもしれない。丁寧に書いていていい記事なのだが、あくまで現時点でのお客さんに迎合しているだけな気もする。
4. まとめ
結局のところ、「ハーネスエンジニアリング」という言葉自体が同じ言葉なのにスコープが違うのは、言う側のポジションで意味合いがズレているのが理由で、あまり使いたくない用語だなと感じた。LLMに書かせた、まとめっぽい表で雑に締める。
| 視点 | 呼び方 | 主なプレイヤー | 目的 | 利用者にとっての印象 |
|---|---|---|---|---|
| 内部ハーネス | Agent Harness | LangChain, Anthropic | 自社製品でAgentを作らせる | ロックイン寄り |
| 外部ハーネス | Agent Harness | Mitchell Hashimoto, OpenAI利用者ガイド | 現場でAgentを安全に使う | 実務寄り・ベスプラ |
Discussion
最後の表の「呼び方」が両方とも Agent Harness になってますね。外部の方は User Harness でしょうか？