初期のコーディングエージェントは、驚くほど強力な事実を明らかにしました。エージェントに Bash へのアクセスを与えるだけで、コードを書くこと、コンテキストを集めること、Git ワークフロー全体を管理することまで、ほぼ何でもできるようになったのです。
この発見は、CLI ファーストなソフトウェアへの流れをさらに後押ししました。複雑なアプリケーションを AI エージェントから扱えるようにする標準的な方法として、コマンドラインインターフェースが定着し始め、こんなスローガンも生まれました。
必要なのは CLI だけです。
しかし、そこには見えにくいコストがあります。エージェントは多くの場合、人間と同じようにターミナルを使います。短いコマンドを実行し、結果を確認し、次にすべきことを決める、という具合です。タスクが複雑になるほどモデルとツールの間の往復が増え、LLM 呼び出しが増え、コンテキストが無駄になり、待ち時間も長くなります。
エージェントに複雑なシェルスクリプトを組み立てさせるより、すでに理解しているプログラミング言語でタスクを組み立ててもらう方が望ましいと考えました。そこから生まれたのが、少し違うアーキテクチャです。
CLI を共通の入り口として残しつつ、ソフトウェアとのやり取りそのものはコードで行う、という考え方です。
エージェントは、本来なら何度ものやり取りに分散するはずの操作・判断・データ処理をまとめたコードブロックを一括で送信します。そのワークフローを実行するのは、ローカルランタイムです。
ego-browser は、この発想を軸に設計されています。CLI がプログラム可能な環境を起動し、ブラウザは少数の関数群として機能を公開し、エージェントは自身が持つプログラミングスキルでそれらの関数を組み合わせて それらを組み合わせる.
この記事では、 ヒアドキュメントと REPL、CLI を介してコードを実行する 2 つの方法、および ego-browser の実験結果を共有します。ヒアドキュメントを使用すると、エージェントは 44% 少ない実行ラウンドで同じタスクを完了し、35.5% 少ないツール呼び出しで、21.6% 低いコストで完了しました。
「必要なのは CLI だけ」——では、その先は?
「必要なのは CLI だけ」という主張は、モデルがその CLI の使い方をすでに知っていることを前提にしています。
Git、Docker、FFmpeg のようによく知られたツールであれば、これは通常問題になりません。モデルは学習の過程で無数のコマンドやチュートリアル、スクリプト、エラーメッセージに触れており、引数の使い方やコマンド同士の組み合わせ方をすでに把握しています。
しかし、エージェント専用に新しい CLI をゼロから作るとなると話は変わります。CLI ごとにサブコマンド、引数、出力形式、エラーの意味づけが異なるからです。 モデルから見れば、これは実質的に新しいミニ言語です。 ドキュメントが完備されていても、モデルはまずルールを学習し、そのうえで何度も呼び出しを重ねながらコマンド同士の組み合わせ方を見出す必要があります。
同じ機能を JavaScript の API として、あるいは他の言語の API として公開すれば、モデルは新しいドメイン概念こそ学ぶ必要がありますが、制御フローやデータ構造、処理の組み立て方まで学び直す必要はありません。ループ、条件分岐、例外処理、データ処理は、すでに知っているプログラミング言語の中で完結します。
シンプルなタスクを考えてみましょう。Web ページを開き、その見出しを読む、というものです。もし ego-browser が従来型のコマンド式インターフェースを提供していたら、エージェントはこれを終えるのに何段階もの手順を踏む必要があるかもしれません。
# First call: open the page
ego-browser open https://example.com
# Tool response: the page is open
# Second call: locate the main heading
ego-browser find --role heading
# Tool response: a heading was found
# Third call: read the heading
ego-browser read --role heading各ステップの後、エージェントはツールを待ち、結果を読み取り、次に何をするかを決定します。
ego-browser が実際に採用しているコードインターフェースなら、ワークフロー全体を一度に表現できます。
await taskSpaces.useOrCreate("read example page");
await browser.openOrReuseTab("https://example.com", { wait: true });
const heading = await page.getByRole("heading").textContent();
console.log(heading);どちらの方式でも結果は同じです。コマンド型インターフェースは処理をモデルとツールの何度ものやり取りに分割するのに対し、コード型インターフェースはエージェントが処理全体を一度に書き出し、ローカルランタイムに渡します。
これはまさに、先ほど触れた設計思想そのものです。CLI を共通の入り口として残しつつ、ソフトウェアとの実際のやり取りにはコードを使う。これにより、呼び出しや統合のしやすさという CLI の利点を保ちながら、モデルがすでに持っているプログラミングの力を、処理の組み立てや調整に活かせます。
CLI がコードへの入り口になるとき
CLI がコードを受け付けるようになったら、次の課題は、エージェントがそのコードを実行環境にどう渡すかです。
厳密に言えば、ヒアドキュメントはシェルの入力構文であり、REPL はインタプリタの実行モードです。両者は同じ抽象化レイヤーにあるものではありません。この記事で実際に比較しているのは、ego-browser でヒアドキュメントを使った一度きりのコード実行と、REPL 上に構築された永続的な対話セッションです。以降は簡単のため、それぞれを単に「ヒアドキュメント」「REPL」と呼びます。
1 つのオプションはヒアドキュメントです。 ego-browser では、エージェントは JavaScript のブロック全体を一度に送信します。
ego-browser nodejs <<'EOF'
await taskSpaces.useOrCreate("read example page");
await browser.openOrReuseTab("https://example.com", { wait: true });
const heading = await page.getByRole("heading").textContent();
console.log(heading);
EOFシェルはコードを ego-browser に渡し、終了するのを待ち、結果を受け取って終了します。エージェントにとって、これは従来のツール呼び出しのように動作します。
Submit command → wait for process → receive resultREPL は動作が異なります。インタプリタは生きたままであるため、エージェントは変数とセッション状態を保持しながらコードを繰り返し入力できます。
> await browser.openOrReuseTab("https://example.com", { wait: true })
< Tab {...}
> await page.getByRole("heading").textContent()
< "Example Domain"表現力という点では、両者は本質的に同等です。REPL はループ・条件分岐・例外処理を含む完全なプログラムを一度に実行できますし、ヒアドキュメントも1行だけを送ることができます。
明確な違いはプロセスのライフサイクルです。ヒアドキュメントではコードの実行が終わるとすぐにプロセスが終了しますが、REPL はインタプリタのプロセスを生かしたまま、次の入力を待ち続けます。これは、エージェントツールに求める要件も両者で異なることを意味します。ヒアドキュメントは、おなじみのリクエスト・レスポンス型のモデルにそのまま乗せられます。
submit the command → wait for the process to exit → get the resultREPL はツールに多くを要求します。プロセスの永続化、セッション管理、継続的な入力、中断、復旧などです。多くのエージェントに組み込まれた Bash ツールには、これらの機能がありません。現在の主要な製品の中でも、まともにサポートしているのは Codex くらいです。しかもツールが対応していることは、REPL を使うための必要条件にすぎず、モデルが実際にどう使うかを決めるわけではありません。同じコードをどちらの環境でも実行できる場合でも、モデルは環境ごとに違う書き方をすることがあります。
モデルが各環境でどうコードを書くか
理論上、モデルはどちらの環境でも同じプログラミング能力を持っています。しかし実際には、一貫した挙動の違いが見られました。
- REPL では、モデルはコードを段階的に入力する傾向があります。
- ヒアドキュメントでは、1回のパスで完結したプログラムを生成しやすくなります。
人間向けのソフトウェアは、人間工学への配慮が欠かせません。エージェント向けのソフトウェアにも同様の規律が必要です。それを、こう呼ぶことにしました。 モデルエクスペリエンス設計。インターフェイスは、トレーニング中に開発された行動パターン モデルと連携する必要があります。
REPL とヒアドキュメントのこの違いは、それぞれの学習データの分布をそのまま映し出しています。
REPL の実例は、たいていチュートリアルやデバッグセッション、質疑応答から来ています。典型的なパターンは探索的です。
> Get the page
< Return page information
> Find an element
< Return element information
> Read its contents
< Return the textヒアドキュメントのコードブロックは、スクリプトやソースファイルに近い見た目をしています。開始と終了の境界がはっきりしているため、モデルは一連の処理をまとめて書きやすくなります。
const page = await openPage();
const element = await findElement(page);
const text = await readText(element);
console.log(text);これは REPL が完結したプログラムを実行できないという意味ではありません。モデルは同じコードブロックを、REPL に対しても一度に送信できます。
この違いは文脈依存です。REPL は、 実行、観察、継続 パターンです。ヒアドキュメントは、 まず整理してから実行する パターン。
この傾向は、制御フローがどこに宿るかも左右します。REPL では、モデルはタスクをいくつもの段階に分け、結果が出るたびに次の一手を決める傾向があります。ヒアドキュメントでは、ループや条件分岐、フィルタリング、データ処理をプログラムの中に直接組み込み、あとはローカルランタイムに任せる傾向があります。
実験でわかったこと
確実に組み込めた主要なエージェントツールの中で、永続的な REPL に必要な実行機能を備えていたのが Codex でした。そこで Codex SDK 上に自動ベンチマークを構築し、同一のエージェントに REPL とヒアドキュメントそれぞれで4種類の実際のブラウザタスクを行わせ、複数回実行した結果を集計して比較しました。
タスクの内容は以下のとおりです。
- X のトレンド投稿分析 (典型的な SNS スクレイピング ワークロード): 過去7日間の OpenAI のオリジナル投稿を収集し、固定表示・リポスト・返信を除外したうえで、閲覧数の上位5件をランク付けし、エンゲージメント率と全体平均を算出します。
- OpenAI 求人応募: サンフランシスコのクラウドインフラ関連の求人を正しく見つけ、履歴書をアップロードして応募フォームに記入し、最終送信の手前で処理を止めます。
- Redfin 住宅ローンの計算: オースティンの物件を住宅タイプと価格で絞り込み、並べ替え後の先頭の物件を開いて、頭金を20%に変更したうえで、更新後の月々の支払い見積りを取得します。
- Expedia フライト検索: JFK から MIA への片道直行便を検索し、指定した航空会社の中で最安のものを選び、乗客情報を入力したうえで、支払いの手前で処理を止めます。
これらのタスクは、ページを開いてテキストを読むだけにとどまりません。構造化データの抽出、条件付きフィルタリング、複数ページにまたがるナビゲーション、ファイルアップロード、フォーム入力、ページ状態の変化、計算処理まで含んでおり、 ブラウザエージェントが行う一般的な操作.
どちらの方式もほとんどのタスクを完了しました。成功率はヒアドキュメントが 77.5%、REPL が 75.0% で、信頼性の差はわずかでした。
より大きな違いは効率面にありました。
- 平均完了時間が減少 35.0%.
- 完了時間の中央値が減少 30.7%.
- ツール呼び出し回数が減少 35.5%.
- トークン消費量が減少 29.8%.
- 平均コストが減少 21.6%.
REPL は実行時の状態を再利用できますが、その利点がやり取りの削減には直結しませんでした。実際にはヒアドキュメント方式のエージェントの方が、ツール呼び出し回数が少なくなりました。
結果は、これまでの観察と一致しました。REPL の中では、エージェントは小さなコードを実行しては結果を確認し、次の一手を決める、というやり方を繰り返しがちでした。本来なら一つのプログラムで済むループ・フィルタリング・判断処理が、モデルとツールの何度ものやり取りに分散していたのです。
両方の環境は、表現力という点ではほぼ同等です。効率の差を生んでいるのは、主にやり取りのパターンがエージェントの挙動をどう形づくるかです。少なくとも今回の4つのブラウザエージェントタスクにおいては、ヒアドキュメントの方が、モデルに完結したプログラムを組み立てさせ、ループ・フィルタリング・判断をコードに落とし込ませ、逐次的な判断による余分な往復を避けさせる傾向が一貫して見られました。
同じ傾向がより大きな規模でも成り立つのかを見るため、ego-browser を、似た仕組みの REPL ベースのブラウザ自動化製品と Odysseys データセット上で比較もしました。上の対照実験とは異なり、こちらは同じモデルが2つのインターフェースを使い分けたのではなく、2つの完成した製品同士の比較です。そのため全体的な効率の比較としては参考になりますが、その差をヒアドキュメントと REPL の違いだけに帰することはできません。
これはヒアドキュメントの決定的な勝利というわけではありません
ヒアドキュメントが REPL より本質的に優れている、とは考えていません。
この結論は、モデルの能力、学習データの分布、そして2026年時点で存在するエージェントツールの設計に依存します。
今のエージェントは総じて、一度で完結したコードブロックを書くのが得意です。シェルツールの多くも、コマンドを送信し、終了を待ち、結果を返すというシンプルなライフサイクルを前提に設計されています。この条件下では、ヒアドキュメントの方がやり取りの回数を減らし、制御フローをローカル実行のコードに移しやすくなります。
こうした状況はすぐに変わる可能性があります。
将来のエージェントツールは、信頼性の高い永続セッション、構造化された出力、堅牢な状態復元を提供するようになるかもしれません。そうなれば、エージェント自身が REPL のプロンプトやプロセス状態、セッションの中断を扱う必要はなくなるでしょう。的を絞った学習によって、不要な逐次的なやり取りに陥る代わりに、モデルが自ら完全なプログラムを REPL に投入するようになる可能性もあります。
そうなれば REPL は、モデル呼び出しを増やすことなく、状態の再利用や即時フィードバックといった利点を保てるようになるかもしれません。初期化コストが高いタスクや、長く状態を保持するタスク、本当に探索的なワークフローでは、REPL の方が良い選択肢になる可能性すらあります。
だからこそタイトルでは、 2026。私たちは恒久法を発見したと主張しているわけではありません。これは、現在利用可能なモデルとエージェント ツールに基づいた、その時点でのエンジニアリング上の判断です。