hip-agent: プロンプト内に収まる軽量エージェント・ハネス

「hip-agent（ハルネス・イン・プロンプト）」は、エージェント向けに設計された軽量な実行環境です。モデル自身がそのハルネスを読み込み、設定は環境変数で行い、残りの部分は既存のプロトコルを利用します。

*注*: この記事は Claude Fable 5.1 と GPT 5.6 sol で執筆されました。コード：github.com/changjonathanc/hip-agent。

背景

Claude Code や Codex など、多くのコーディング用ハルネスが存在しますが、これらはすべて人間が使うことを前提に設計されています。

エージェントが利用することを想定して作られたものではありません。もしエージェントに対して codex exec をサブエージェントとして使用させようとすると、適切な CLI フラグを見つけたり出力を解析したりするだけで数ターン消費してしまう可能性があります。さらに、よりカスタマイズされたループを実現したい場合、エージェントは Codex CLI のソースコードまで掘り下げて実装の詳細を学ぶ必要があり、それにもさらに多くのターンが必要になります。

ハルネス・イン・プロンプト

「hip-agent（ハルネス・イン・プロンプト）」は、まさにエージェントのために設計された実行環境です。コアとなるループは約 200 行の Python コードと、Codex API を扱う 1 つのモジュールで構成されています。その核となる考え方は以下の 3 つです。

このハレスはプロンプト内に収まるように設計されています。ループは最小限に抑えられ、モデルには sh と view_image の 2 つのツールしか与えられません。また、プロンプトにはソースコードを読み込んでハレスの動作を正確に理解するよう指示が記されています。

OS がランタイムとして機能します。設定は環境変数で行い、アクションはシェルコマンドで実行し、サブエージェントは子プロセスとして起動されます。

残りの部分は既存のプロトコルとフォーマットによって処理されます。プラグインは Agent Plugins に従い、フックは Claude Code のフック契約を採用しています。会話は Codex CLI セッションファイルとして記録されるため、codex resume コマンドで再開可能です。

全体の構成は以下の通りです：

# ~/.zshrc
P=~/hip-agent/plugins
export AGENT_MODEL=gpt-5.6-sol
export AGENT_PLUGINS=$P/environment:$P/cwd:$P/agentsmd

実行例は次のようになります：

codex login
./agent "inspect this repository and explain it"

この設計から自然に導き出される要素は、これらすべてです。

サブエージェントとは、sh から実行される agent のことです。環境を継承し、独自の会話履歴を持ちます。親エージェントは環境変数を通じてこれを設定します（例：AGENT_MODEL=... agent "..."）。デフォルトでは親エージェントが確認できるのはサブエージェントの最終出力のみですが、その状態はセッションファイルから読み取ることも可能です。より高度なインタラクションはプラグインとして実装できます。

このハネスは修復可能です。ハネスの内容を理解した十分な知能を持つモデルであれば、その制限を回避したり、自ら変更したりすることができます。

hip-agent をスキルとして登録し、既存のエージェントにサブエージェントの生成を任せることもできます。コード自体がドキュメントとなっています。

ネイティブなサブエージェントを使わない理由

現在のモデルはすでにサブエージェントの訓練済みですが、なぜ新たなハネスが必要なのでしょうか？

モデルは、固定された環境（ハルネス）の中で常に最高のパフォーマンスを発揮するわけではありません。むしろ、モデルの能力が向上すればするほど、その固定された環境自体がボトルネックになる可能性があります。

hip-agent はそのような固定された環境ではありません。これは意図的に小さく設計されたリファレンス実装です。これにより、エージェント自身がこのコードを読み込み、修正し、状況に応じて適応させることが可能になります。

モデルに対して、この仕組みの使い方を学習させることもできます。将来のモデルは hip-agent のアプローチを採用し、タスクに応じて自分自身でサブエージェント用のハルネスを構築・編集できるようになるでしょう。

結果

Terminal-Bench 2 で gpt-5.6-luna を最大限の努力（effort max）で使用してコードの試行錯誤を行いました。シェル設計やプロンプトの微調整、view_image ツールの追加、コマンドのタイムアウト設定などを加えましたが、それ以外はコードとプロンプトの変更は最小限に抑えられ、ベンチマーク最適化は行っていません。

最終的なコードは DeepSWE で評価されました。ここでは 113 のタスクに対して、Codex CLI 0.147.0 をベースラインとして比較検証を行いました。その結果、hip-agent は Codex CLI と同等の性能を発揮することが示されました。

各モデルを 1 回ずつ実行し、エラーバーは表示していません。2 つの試行は同じ CPU を持つ 2 台のローカルマシンで並列に実行されましたが、それ以外のハードウェア構成は異なります。hip-agent はトークン使用量をログに残さないため、その数値については比較していません。

結論

現在、ほぼすべてのモデルプロバイダーが独自の TUI ハーネスを同梱しています。しかし、誰もそれをすべて試す時間はありません。

また、評価（evals）も困難になります。ベンチマーク実行はモデルとハーネスの両方を測定することになるからです。OpenAI は、ARC-AGI-3 のハーネスがモデルの手順間の推論能力を低下させていることを発見しました [1]。Codex がデフォルトで使用する 2 つの設定を有効にするだけでスコアが 3 倍に向上しています。一方、ユーザー向けのハーネスは毎週のように変更されますが、すべての変更が改善とは限りません。Anthropic の 4 月の事後分析 では、モデル自体に変更がなくても、ハーネスの仕様が結果を静かに低下させる事例が記録されています。つまり、ユーザー向けのハーネスはモデルを評価するための適切な指標にはなり得ないのです。

理想的な形としては、すべてのモデルビルダーが hip-agent のような最小限のネイティブ参照ハーネスを提供すべきです。ネイティブ参照ハーネスとは、ツールパーサーやチャットテンプレートのようなもので、モデルが世界とどのように相互作用するように訓練されたかを記述するものです。これは、モデルプロバイダーが提供するユーザー向け製品から独立しているべきです。また、新しいモデルを試す際にも便利です。ユーザーは既存のエージェントに指示を出すだけで、新しいモデルをサブエージェントとして実行させることができます。

[1] https://openai.com/index/how-two-settings-tripled-our-arc-agi-3-scores/

[2] https://www.anthropic.com/engineering/april-23-postmortem