HERMES、リポジトリの構成要素を協調型コーディングエージェントへ

導入

ターミナルを利用できる大規模言語モデルは、ファイルの編集、テストの実行、バグの調査などを自動化できるようになった。しかし、タスクが複数のソースファイル、設定、依存関係、テスト、実行時の挙動にまたがると、エージェントの信頼性は低下しやすい。エージェントは分散した情報からプロジェクトの状態を何度も再構築しなければならず、対話履歴の肥大化や意味のずれが起こる。大規模なリポジトリでは、関係する構成要素の発見も難しい。

Hugging Face Daily Papersで紹介された研究は、この問題に対し、モデルそのものの大型化だけでなく、エージェントが作業する環境の設計を見直すHERMESを提案した。

Dev-Primitivesという考え方

HERMESの基盤は、Development Primitivesを意味するDev-Primitivesである。研究では、コードモジュールやテスト関連の成果物など、リポジトリ内の要素に常駐型の言語モデルを組み合わせる。モデルは要素を外部から観察するだけでなく、その実装と依存関係を根拠に、エージェント向けのインターフェースを提供する。

主な特徴は次の三つだ。

• 局所的な推論：各要素が自分の責務、実装、制約を中心に説明でき、毎回リポジトリ全体を読み込む必要を減らす。
• 要素間の通信：複数のプリミティブが自然言語で状態や前提、修正案を共有する。
• 局所的な修正：実行結果から問題のある要素が絞られた場合、関連するプリミティブが変更を提案・支援する。

HERMESは、依存関係を考慮した動的アクティベーションによって、これらをリポジトリ全体へ展開する。すべての要素を常に起動するのではなく、タスクと依存関係から関連性の高いものを選ぶ。また、テストや実行時に得られた証拠を、修正すべき要素へ対応付ける診断機構も備える。狙いは、実行、診断、対象を絞った修正という循環を作ることにある。

実験結果と意味

4つのソフトウェアエンジニアリング・ベンチマークで、HERMESは対応するベースラインに対して平均12.4%の改善を報告した。さらに、強力なアクティベーションモデルと診断モデルを組み合わせると、Dev-PrimitivesにQwen3-8Bを使った構成でも、4つのベンチマーク全体でGPT-5.6 Solを一様に使う構成との差は4.5%以内だった。Terminal-Bench 4.0では推論コストを26.2%削減している。

これは、小型モデルが常に高性能モデルを置き換えられるという意味ではない。むしろ、タスク分解、コンテキストの経路制御、失敗原因の特定が、コーディングエージェントの性能とコストを大きく左右することを示している。

影響と課題

HERMESは、リポジトリを単なる静的なファイル集合ではなく、局所知識を持つ実行可能な協調単位の集合として捉え直す。これにより、長期タスクのコンテキスト負荷を抑え、バグ修正を実行証拠に基づく工程へ近づけられる可能性がある。

一方で、性能はアクティベーションと診断モデルの品質に依存する。プリミティブの境界をどう設定するか、自然言語通信による誤解をどう抑えるか、局所的な変更で全体の整合性をどう維持するかは今後の課題だ。それでも本研究は、コーディングエージェントの改善にはモデルの規模だけでなく、モデルとソフトウェアをつなぐインターフェースの設計が重要だと示している。

出典：Hugging Face Daily Papers