このレポートは、オープンソースのコマンドライン型コーディングエージェントである OpenDev のエンジニアリングを記録したもので、著者はこれを、オープンソースで ターミナルネイティブな対話型コーディングエージェントに関する初の包括的な技術レポートとして提示している。 その前提として述べられているのは、AI によるコーディング支援が IDE プラグインから、開発者がすでに ソース管理、ビルド、デプロイを行っている場所に位置するターミナルネイティブなエージェントへと移行した こと（論文はこの移行を Claude Code が先導したとしている）、そして本番システムはクローズドソースで 判断が文書化されておらず、オープンなフレームワークは対話的な利用ではなくベンチマークを対象としているか 技術レポートを公開していないため、そうしたエージェントの設計空間がまだ十分に探究されていないことである。 論文は、その目的がアルゴリズム上の成果を示すことではなく、設計判断、トレードオフ、教訓を共有することに あると明言している。
アーキテクチャは 4 つの層（エントリーと UI、エージェント、ツールとコンテキスト、永続化）で構成され、 論文が区別する スキャフォールディング と ハーネス を軸にしている。スキャフォールディングは最初の プロンプトの前にエージェントを組み立てるものであり、ハーネスは実行時にツールのディスパッチ、 コンテキスト管理、安全性の強制、永続化をオーケストレーションするものである。中心的な捉え方は、この システムが単一のモデルではなく複合 AI システムだという点である。作業はセッション、エージェント、 ワークフロー、LLM の 4 階層として組織されており、各認知ワークフローはユーザーが設定したモデルに 独立して結び付けられるため、コスト、レイテンシ、能力のトレードオフをワークフローごとに調整できる。 論文はこれを基盤として 5 つの貢献を示す。ワークフローごとの LLM の設定可能性、明示的な思考フェーズと 任意の自己批評フェーズを備えた拡張 ReAct ループ、イベント駆動のシステムリマインダー、5 層の安全性 アーキテクチャを伴うトークン効率の良い拡張性、そして第一級の関心事として扱われるコンテキスト エンジニアリングである。
後半では、このシステムから 5 つの横断的な設計上の緊張関係へと一般化し、それぞれを他に転用できる教訓と ともに述べている。レポートはそのいくつかについて具体的な数値を示している。典型的なセッションでは ツール出力がコンテキストの 70〜80% を消費する。エージェントの最初のターンを律する指示は、30 回以上の ツール呼び出しの後では日常的に破られる。すべての MCP ツールスキーマを先行して読み込むと、最初の ユーザーメッセージの前にコンテキスト予算の 40% を消費していたが、遅延的な発見によってこれは 5% 未満に 減った。そして、観測をアクティブ、フェード、アーカイブの状態へと移していく適応的なコンテキスト コンパクションによって、ピーク時のコンテキスト消費が約 54% 削減された。
要点
- レポートは、スキャフォールディング（最初のプロンプトの前にシステムプロンプト、ツールスキーマ、 サブエージェントのレジストリを組み立てること）と、実行時にツールのディスパッチ、コンテキスト管理、 安全性の強制、セッションの永続化をオーケストレーションするハーネスとを区別し、それぞれが独立して 進化できるよう両者を分離しておくべきだと論じている。
- エージェントをセッション → エージェント → ワークフロー → LLM という階層を持つ複合 AI システムとして 捉えており、プロバイダーの切り替えやコストの最適化はコードの変更ではなく設定の変更で済む。
- ツール出力（ファイルの内容、コマンドの結果、検索のヒット）が典型的なセッションでコンテキストの 70〜80% を消費すると報告し、コンテキスト使用率こそがセッションがどれだけ長く有用であり続けるかを 示す最も重要な指標だと論じている。
- ハード上限での 1 回きりの緊急コンパクションではなく段階的なコンテキスト削減を主張し、観測を アクティブ、フェード、アーカイブの状態へと移していく適応的なコンパクションが、ピーク時のコンテキスト 消費を約 54% 削減し、多くの場合 LLM による要約をまったく必要としなかったと報告している。
- 大きすぎるツール出力はスクラッチファイルにオフロードし、短いプレビューとファイル参照を返すことを 推奨している。取得のコストは一度しかかからないが、コンテキスト消費のコストはその後のすべての モデル呼び出しでかかるという理由からである。
- プロバイダーが目に見えない内容を注入するため、ローカルでのトークンカウントは実際の使用量を 系統的に過小評価すると述べている。このシステムではその差が、コンパクションの発動が遅れて オーバーフローを起こすほど大きかった。プロバイダーが報告するトークン数を正解として扱うべきだと している。
- モデルは一度も目にしない機能について反論したり回避を探ったりできないため、安全性は呼び出し時に 権限をチェックするよりも、エージェントのスキーマからツールを取り除くことで強制するほうが良いと 論じ、単一の回避策でシステムが危険にさらされないよう、5 つの独立した安全性の層を説明している。
- 判断の時点で注入される短いリマインダーは長いシステムプロンプトのセクションよりも効果が高いこと、 著者の実験ではユーザーロールで送ったリマインダーのほうがシステムロールよりも強い遵守をもたらした こと、そしてリマインダーの頻度は種類ごとに上限を設けなければモデルがそれを無視するようになる ことを報告している。
- ツールを使えない思考フェーズをモデルに与えると、ツールがある状態で慎重に考えるよう指示するよりも 大幅に良い推論が得られると報告し、その効果を指示ではなく API 呼び出しにツールスキーマが含まれない ことに帰している。
- 厳密な正確さを要求してセッションをエラー回復ループに費やすのではなく、ツールがモデルの不正確さを 吸収すべきだと論じている。たとえば、編集のために段階的に緩められていくマッチャーの連鎖や、 エージェントが実際に持っているツールと照合した回復ヒントである。
- このシステムの具体的な閾値（70% でのコンパクション発動、3 回のナッジ試行、6 段階の思考の深さ）は、 第一原理からの計算ではなく反復的な失敗分析から生まれたものだと述べ、そのアプローチを推奨している。
- 定量的なベンチマーク評価は示しておらず、SWE-bench、Terminal-Bench、LongCLI-Bench での評価を、 適応的なリソース割り当て、スケールしたメモリパイプライン、メモリのための構造化されたコード表現、 階層的な委任を超えたマルチエージェントの協調とともに、今後の課題として挙げている。
補足
これは 1 つのシステムについてその作者自身が書いた設計と教訓のレポートであり、本人もそう述べている。 アーキテクチャ上の判断とその根拠を記録したもので、体系的な定量評価を欠いていると明言しているため、 示される数値（ピーク時のコンテキスト消費の 54% 削減、MCP スキーマのオーバーヘッドの 40% から 5% 未満 への低下、ツール出力が占める 70〜80% の割合）は、ベースラインに対して確立された結果ではなく、著者自身の 利用におけるこのシステムの測定値である。リマインダーのロールや、思考と行動の分離に関する主張も同様に、 実験プロトコルを伴わずに著者の実験から報告されたものである。
レポートは、近隣のシステムに対する自らの位置づけを、測定による比較ではなく各システムが何を公開して いるかによって示している。論文はあるが自動評価を対象とするベンチマーク志向のフレームワーク、文書化 されてはいるがターミナルではなくブラウザ UI を通じて動作する本番品質のシステム、技術レポートが公開 されていない複数の CLI ネイティブのエージェント、そして CLI ネイティブではあるがオープンソースでも なく技術レポートも伴わない Claude Code である。