爆速進化！次世代型「エージェント型ハーネス」の構築術を徹底解説

近年注目を集めているAIエージェントの自律的なタスク実行を支える、高度な「エージェント型ハーネス（Agentic Harness）」をいかに構築すべきか。その設計思想と実装のポイントを深掘りします。

計画はグラフである

個人的にはLLMにREPLループを与えて、すべてのツールをそのREPL内の関数として注入するやり方の方がずっと好きだな。

そうすればLLMはDAG（有向非巡回グラフ）を書くことに縛られず、ループや早期終了などを含むコードを書けるようになるからね。

いい内容だね、そのままキープで。

これに関連して参考になる記事や資料を知っている人はいる？今独自のハーネスを構築中でループサポートなどを実装し始めたいと思ってるんだけど、動的な（例えば計画フェーズにはx回のイテレーションが必要で、実行フェーズにはy回必要、といったような）フレームワークをどう構築すればいいか悩んでいて。

これで実際に問題解決能力が向上したとか、エラーが減ったといったベンチマークはあるの？

アイデアは面白いけど、ハーネス開発の経験から言うと、良さげに見えるアイデアでも予期せぬ相互作用でパフォーマンスが悪化することってよくあるからね。

正直、ちょっと懐疑的かな。

Terrence Taoたちが数学的成果を証明するためにハーネス[1]を開発していて、それ以降も他の人たちによって効果的に使われているみたいだね。このハーネスの構造について批評できる人はいないかな？自分はこの分野については全くの素人なので。

そして関連するGitHubリポジトリがこちら: https://github.com/DataForScience/LLMs

いいチュートリアルだね。一般的に言って、ハーネスとはLLMとそのタスクの間にある環境レイヤーのことだよね。呼び出せるアクションセットや状態、参照できるコンテキストやメモリなどが含まれる。

ただ最近のハーネス開発を通じて強く感じるのは、システム内でLLMを「どこで使うか」よりも「どこで使わないか」という判断の方が重要だということ。あと、結果のバリデーションもどんどん重要になってきている。みんなはどう考えてる？

タイトルやイントロとは裏腹に、これは高度な「エージェントハーネス」というより、エージェント型の「ワークフロー」ビルダー兼ランナーに見えるな。

いくつか気になった点：

• 「この投稿の内容で、ほとんどのケースでうまくいくことが証明されるわけではない」と断っている点

• DAGは良さそうに聞こえるけど、LLMはタスクを必要以上に小さく分割しがちで、それが原因で全体像を見失ってしまうことがよくある

• 経験上、JSONでのやり取りを強制すると、gpt-5.6-solクラスでさえ「IQ」が少し下がってしまう

これを読んでいる人に言っておくと、このチュートリアルはClaude Code以前に皆が構築していた「エージェント」に近いものだ。

tl;dr ここの「オーケストレーター」は単なるソフトウェアループでしかなく、LLMのプロンプトによってかえってプランナーやワーカーの柔軟性が制限されてしまっている。

自分も（たぶん他にもたくさんいるだろうけど）似たようなものを作ったよ。主な違いは、次の開発ステージに進む前に各ステージで「批評家（Critics）」を動作させている点かな。ステージはイシュー、計画、プルリクエストといった成果物によって定義されていて、次のステージに進むには批評家が各成果物を承認しないといけない。つまり、ある成果物から次へどう移行するかをDAGで定義しているわけだ。作るの楽しかったし近いうちにオープンソースにしたいと思っているけど、他にも同じようなシステムに取り組んでいる人は多そうだよね。

なるほど。もし僕の理解が正しければ、エージェントの一つがジョブごとにワークフローをDAGとして動的に生成しているということ？そこが一番興味深いな。それ以外は既知の概念だったし。

たぶん、それこそが「AI企業」に必要な要素の大きな部分を占めるんだろうね。目標や階層を管理するエージェントが必要ってことだ。もちろんDAGとエージェントの階層は厳密には別物だけど、ワークフローやサブワークフローこそが鍵なのかもしれない。