このページは、おい丸(AI)による要約・構成案をもとに、人間が確認・加筆した合作です。内容を正確に確認したい場合は、元論文もあわせて参照してください。
これは何の論文か
この論文の出発点は、LLM とコードの関係が変わったことにある。以前の中心は、自然言語から正しいプログラムを生成できるかだった。だがエージェント型システムでは、コードは出力される成果物であるだけでなく、エージェントが推論し、行動し、環境を表現し、実行結果から自己修正するための媒体になっている。
著者らはこの変化をコードをエージェントハーネスとして使う考え方と呼ぶ。ここでいうハーネスは、LLM の外側にあるツール、API、サンドボックス、記憶、検証器、権限境界、実行ループ、フィードバック経路を含む実行基盤である。重要なのは、コードがそのハーネスの中で、実行可能で、検査可能で、状態を持てるオブジェクトとして働く点にある。
論文は、コード中心のエージェントシステムを三層で整理する。第一にハーネスインターフェース、つまりコードが推論、行動、環境モデリングの入口になる層。第二にハーネス機構、つまり計画、記憶、ツール利用、制御、最適化を支える層。第三にハーネスの拡張、つまり共有リポジトリ、テスト、トレース、ワークフローなどを使って複数エージェントが協調する層である。
このサーベイの読みどころは、コード生成の論文リストではなく、コードがエージェントの外部化された認知・実行・検証インフラになっているという視点だ。Codex、Claude Code、OpenHands、SWE-Agent、GUI/OS エージェント、科学的発見エージェントなどを、単なる応用例ではなく、同じコード中心のハーネスの変種として読める。
最後に、著者らは未解決課題として、最終成功率を超える評価、不完全なフィードバックのもとでの検証、回帰を起こさないハーネス改善、複数エージェント間の共有状態、人間の監督、マルチモーダル環境への拡張を挙げる。これはそのまま、実務のエージェントハーネス設計で詰まりやすい場所でもある。
Code as Agent Harness は、コードを LLM の生成対象ではなく、エージェントの運用可能な形で基盤として整理するサーベイである。
コードは、プログラム補助推論、ロボットや GUI の行動、リポジトリ編集、テスト、実行トレース、サンドボックス、ワークフローなどを通じて、エージェントの推論、行動、状態、フィードバック、検証を支える。
論文の中心主張は、エージェントの自律性のボトルネックは基盤モデルの推論力だけではなく、モデル出力を長期的な行動と永続状態へ接続するハーネスの信頼性にもある、ということ。
何が問題だったのか
コード生成エージェントは、コードを書くモデルとしてだけ見ると実態を捉えにくい。実際には、コードは推論の途中計算になり、環境への行動になり、テストや状態管理の媒体にもなる。
問題は、コード生成、ツール利用、記憶、計画、検証、複数エージェント協調が別々の話として扱われやすいことだ。すると、失敗した時にモデルが弱いのか、実行環境が弱いのか、状態の持ち方が悪いのか、検証の設計が悪いのかを切り分けにくい。
この論文が扱う問題は、コードを生成物としてだけではなく、エージェントを動かす実行基盤として見るための地図が足りないことにある。
LLM とコードの関係は、長く「モデルがコードを生成する」という見方で語られてきた。しかしコーディングエージェントやツール利用エージェントでは、コードは最終成果物であるだけでなく、状態を保存し、環境を操作し、検証を走らせ、複数エージェントが共有する実行基盤にもなる。
既存の議論で足りなかったのは、この実行基盤としてのコードをまとめて扱う語彙である。プロンプト、ツール、テスト、ログ、サンドボックス、ファイル、権限、回復手順がばらばらに語られると、エージェントの成功や失敗をモデル性能だけに還元しやすい。
このサーベイは、コードをエージェントハーネスとして捉え直す。つまり、LLM の推論を外部化し、検査可能にし、状態を持たせ、複数回の行動に耐えさせるための実行媒体としてコードを見る。
提案手法の中身
ハーネスインターフェースの層では、コードが三つの入口になる。推論のためのコードは中間計算や 記号的な解答手段、実行トレースを通じて推論を外部化する。行動のためのコードはツール呼び出し、振る舞いの木、再利用可能なスキルとして環境への行動を表す。環境モデリングのためのコードはリポジトリ、プログラム状態、シミュレータ、テスト、トレースを環境状態の表現として使う。
ハーネス機構の層では、コードが長時間実行の制御面になる。計画は目標を分解し、構造や探索を使って次の行動を決める。記憶はリポジトリ証拠、作業文脈、実行トレース、再利用可能な経験を管理する。ツール利用は API、端末、サンドボックス、検証ツールを管理されたインターフェースとして接続する。
同じ層で重要なのが Plan-Execute-Verify ループである。計画は意図した変更の契約、実行はサンドボックス化され、権限管理された環境内の状態遷移、検証はテスト、静的解析、実行環境エラー、人間レビューなどを通じて受理、修正、エスカレーション、巻き戻しを決める。
ハーネスの拡張の層では、manager、planner、coder、reviewer、tester などの役割特化エージェントが、共有コード成果物、リポジトリ、テスト、トレース、構造化ワークフローを通じて協調する。コードは単なる成果物ではなく、複数エージェントが互いの作業を検査し、検証し、修正する共通基盤になる。
どうやって確かめたのか
この論文は新しい単一手法のベンチマークではなく、サーベイとして多くのエージェントシステムを整理する。確認対象は、既存研究をハーネスインターフェース、ハーネス機構、ハーネスの拡張という観点で分類できるかである。
比較対象は、コードを単なる生成物として使うシステムと、計画、状態、検証、協調の媒体として使うシステムである。計画をコード化するのか、環境状態をファイルに残すのか、検証をテストとして実行するのか、複数エージェントが共有コード基盤を通じて協調するのか、といった違いを読む。
測るものは単一スコアではなく、既存システムをこの分類で説明できるか、抜けや曖昧な境界がどこに残るかである。
結果はどうだったのか
この論文は新しいベンチマーク結果を出す実験論文ではなく、2026 年時点のコード中心のエージェントシステムを整理するサーベイである。したがって見るべき結果は、数値より分類体系と未解決問題の切り方にある。
特に重要なのは、コードの役割を生成された成果物から、エージェントが起動するコード成果物へ広げている点である。回帰テスト、一時ツール、DSL プログラム、実行可能なワークフロー、再利用可能なスキル、中間プログラム状態などが、エージェントループの中で生成・実行・観測・修正・保存・共有される対象として扱われる。
応用領域の整理では、コードアシスタントが最も明確な実装例として扱われる。リポジトリ状態、テスト、ビルドスクリプト、課題、ブランチ、プルリクエスト、CI のフィードバックがエージェントの運用可能な形で文脈になり、ハーネスがサンドボックス、権限、文脈の配線、計測、検証フックを制御する。
GUI/OS エージェント、科学的発見、身体性を持つエージェントでも同じ構造が見える。GUI では DOM、アクセシビリティツリー、スクリーンショット、アクション、評価スクリプトがコードで定義された世界になる。科学研究では仮説、プロトコル、分析、LaTeX 原稿が実行可能なパイプラインになる。身体性を持つエージェントではコードベースのスキルが行動境界と再利用可能な記憶になる。
限界・注意点
- この論文は広い サーベイ なので、個々のシステムの評価条件や実装差分を細かく検証するものではない。各手法の有効性を比較したい場合は、元論文へ戻る必要がある。
- コードをハーネスとして見る視点は強いが、コード中心に寄せすぎると、自然言語の社会的合意、組織内の運用ルール、人間の判断、暗黙の責任境界を過小評価する危険がある。
- エージェントが起動するコード成果物は強力だが、実行権限、サンドボックス、承認境界、巻き戻し、監査ログが弱いと危険にもなる。論文も、人間の監督と安全上重要な行動の扱いを未解決課題として残している。
- 複数エージェントの実行制御では、共有コード成果物が協調を助ける一方、同時変更、古い状態、他エージェントの前提破壊、検証責任の分散が新しい失敗モードになる。
おい丸のようなエージェントにどう使えるか
おい丸のような作業支援エージェントを作る時、この論文は「モデルを賢くする」以外の設計面を見せてくれる。作業ディレクトリ、生成ファイル、テスト、ログ、権限、承認、巻き戻し、再開手順は、すべてハーネスの一部である。
実装上は、エージェントに長い説明を持たせるだけでなく、状態をどこに外部化するか、どの操作を検査可能にするか、失敗した時にどこから再開できるかを設計する必要がある。コードやMarkdownファイルは、そのための一時的な足場にも、長期的な共有資産にもなる。
この視点を持つと、エージェントの失敗を「モデルが弱い」で終わらせずに済む。必要なのは、より良い検索、より良いテスト、より狭い権限、より明確な完了条件、より戻りやすい作業状態かもしれない。
Q&A
Q. この論文の中心問いは？
コードを LLM が生成する最終成果物としてだけでなく、エージェントが推論し、行動し、状態を保持し、検証し、協調するためのハーネスとして見られるか、という問い。
Q. エージェントハーネスとは何？
LLM をツール、APIs、サンドボックス、記憶、検証器、権限境界、実行ループ、フィードバック経路 で包み、長時間タスクを実行できるエージェントにするソフトウェア層。
Q. Code as Agent Harness は普通のコード生成と何が違う？
普通のコード生成は、正しいプログラムを出すことが目的になりやすい。Code as Agent Harnessでは、コードはエージェントループの中で実行され、観測され、修正され、保存され、他エージェントと共有される運用可能な形で基盤になる。
Q. 三層の 分類体系は？
ハーネスインターフェース、ハーネス機構、ハーネスの拡張の三層。最初はコードが推論・行動・環境表現の入口になる層、次が計画・記憶・ツール・制御を支える層、最後が複数エージェントの共有基盤になる層。
Q. エージェントが開始するコード成果物とは？
エージェントがタスク中に作り、実行し、観測し、修正し、保存し、共有するコードオブジェクト。例として 回帰テスト、一時ツール、DSLプログラム、実行可能なワークフロー、再利用可能なスキル、中間プログラム状態 がある。
Q. なぜ記憶もコードハーネスの一部になる？
リポジトリ証拠、作業文脈、実行トレース、検証結果、再利用可能な経験 などは、次の行動を決めるための 変更可能な状態だから。単なる会話履歴ではなく、実行環境と結びつく状態管理層として扱われる。
Q. Plan-Execute-Verify ループの意味は？
計画が変更意図の契約になり、実行がサンドボックスや権限の中で状態遷移を起こし、検証がテスト、静的解析、実行環境フィードバック、人間レビューで受理・修正・巻き戻しを決めるという制御ループ。
Q. 複数エージェントでは何が変わる？
manager、planner、coder、reviewer、tester などの役割が共有リポジトリ、テスト、トレース、ワークフローを通じて協調する。コードは成果物であると同時に、エージェント間の共通作業場と検証対象になる。
Q. 実務で一番使える見方は？
エージェントの性能をモデルだけで見ないこと。サンドボックス、権限、ファイルシステム、テスト、ログ、記憶、承認、巻き戻しまで含めてハーネスとして設計・評価する。
Q. これは既存ツールの使い方の話？ それとも自前ハーネスを作る話？
両方である。最初は、既存のコーディングエージェントやチャットUI、Git、CI、デプロイ環境の上に、リポジトリガイダンス、スキル、作業ログ、知識ベース、承認フローを重ねるところから始まる。これは既存ハーネスの上に、チームや個人の作業に合う 第二層のハーネスを作る段階である。
次の段階では、エージェントを単なる利用ツールではなく、実行エンジンの一部として扱う。スケジューラ、通知、状態管理、スキル評価、検索コーパス、権限管理など、自分たちで触れる層を増やす。この論文は、その移行を「便利な運用」ではなくエージェントハーネス設計 として説明するための地図になる。
Q. 一番注意すべき限界は？
コードが実行可能であるほど、権限と安全性が重要になること。エージェントが書いたコードを何でも実行・保存・再利用できるようにすると、失敗や危険な変更もハーネスに取り込まれてしまう。
Q. この論文を一言でいうと？
コードを書く AIから、コードで動く AI へ視点を切り替えるためのサーベイ。
関連する記事
grepだけで十分なのか
エージェント型検索の性能は、検索器単体では決まりません。grep、ファイル読み取り、シェル、結果の受け渡しを含む作業環境まで見ると、Code as Agent Harness の「外側の基盤が性能を決める」という見方が具体化します。
Agent libOS: 長時間動くエージェントの実行環境
Code as Agent Harness が「コードを実行基盤として見る」地図だとすると、Agent libOS はその基盤にプロセス、権限、承認、監査ログを持たせる設計です。実行可能なコードと安全な実行環境を分けて考える助けになります。
Agent Hooks Reading Guide
ハーネスの考え方を日々の作業フローへ落とすなら、フックが入口になります。コード、テスト、ログ、完了ゲートを、モデルの注意ではなく実行環境側で必ず動く処理として扱えます。