初期のコーディングエージェントは、驚くほど強力な事実を明らかにしました。エージェントにBashへのアクセスを与えるだけで、コードを書くことから、コンテキストの収集、Gitワークフロー全体の管理まで、ほぼ何でもできるようになったのです。
この発見は、CLIファーストなソフトウェアへの流れをさらに後押ししました。複雑なアプリケーションを AI エージェントから操作できるようにする標準的な方法として、コマンドラインインターフェースが定着し始め、こんなスローガンも生まれました。
必要なのはCLIだけです。
しかし、そこには見えにくいコストがあります。エージェントは多くの場合、人間と同じようにターミナルを使います。短いコマンドを実行し、結果を確認して、次に何をするかを決める、などです。タスクが複雑になるほど、モデルとツールの間のやり取りが増え、それに伴ってLLMの呼び出し回数や無駄なコンテキストが増え、待ち時間も長くなります。
私たちは、エージェントに複雑なシェルスクリプトを組み立てさせるよりも、すでに理解しているプログラミング言語を使ってタスクを組み立ててもらう方がよいと考えました。そこから、少し異なるアーキテクチャが生まれたのです。
CLIを共通の入り口として残しつつ、ソフトウェアとの実際のやり取りにはコードを使う。
エージェントは、本来なら何度ものやり取りに分かれる操作・判断・データ処理を1つのコードブロックにまとめて送信します。そして、そのワークフローをローカルランタイムが実行します。
ego-browser は、この考え方を軸に設計されています。CLIからプログラム可能な環境を起動し、ブラウザの機能を少数の関数として提供します。エージェントは、すでに持っているプログラミングスキルを活かして、それらの関数を組み合わせ、処理全体を 構成します.
この記事では、CLIを通じてコードを実行する2つの方法、 ヒアドキュメントとREPLを比較し、ego-browserで行った実験の結果を紹介します。ヒアドキュメントを使用した場合、エージェントは同じタスクを44%少ない実行ラウンド、35.5%少ないツール呼び出し、21.6%低いコストで完了しました。
「必要なのはCLIだけ」——では、その先は？
「必要なのはCLIだけ」という主張は、モデルがそのCLIの使い方をすでに知っていることを前提にしています。
Git、Docker、FFmpegのようによく知られたツールであれば、これは通常問題になりません。モデルは学習の過程で無数のコマンドやチュートリアル、スクリプト、エラーメッセージに触れており、引数の使い方やコマンド同士の組み合わせ方をすでに理解しています。
しかし、エージェント向けに新しいCLIをゼロから作るとなると、話は変わります。CLIごとにサブコマンド、引数、出力形式、エラーの扱い方が異なるからです。 モデルから見れば、それは実質的に新しいミニ言語です。 ドキュメントが揃っていても、モデルはまずそのルールを学び、何度も呼び出しを繰り返しながら、コマンド同士をどう組み合わせるかを理解する必要があります。
一方、同じ機能をJavaScriptなどの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でヒアドキュメントを使った1回限りのコード実行と、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 result一方、REPLの動作は異なります。インタプリタのプロセスが継続するため、エージェントは変数やセッションの状態を保持したまま、繰り返しコードを入力できます。
> 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 result一方、REPLではツール側により多くの機能が求められます。プロセスの維持、セッション管理、継続的な入力、中断、復旧などです。多くのエージェントに組み込まれている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では、エージェントは短いコードを実行して結果を確認し、そこから次の操作を判断する、という流れを繰り返す傾向がありました。本来なら1つのプログラム内で完結できるループ・フィルタリング・判断処理が、モデルとツールの何度ものやり取りに分散していたのです。
どちらの環境も、表現力という点ではほぼ同じです。効率の差を生んでいるのは、主にインターフェースの違いがエージェントの行動をどう変えるかです。 少なくとも今回の4つのブラウザタスクでは、ヒアドキュメントを使うことで、モデルが最初から完結したプログラムを組み立て、ループ・フィルタリング・判断をコードの中に落とし込み、逐次的な判断による余分なやり取りを減らす傾向が一貫して見られました。
同じ傾向がより大きな規模でも見られるかを確かめるため、ego-browserと、似た仕組みを持つREPLベースのブラウザ自動化製品をOdysseysデータセット上でも比較しました。ただし、先ほどの比較実験とは異なり、こちらは同じモデルに2つのインターフェースを使わせた比較ではなく、完成した2つの製品同士の比較です。そのため、全体的な効率を見るうえでは参考になりますが、結果の差をヒアドキュメントとREPLの違いだけによるものと考えることはできません。
これはヒアドキュメントの決定的な勝利というわけではありません
ヒアドキュメントがREPLより本質的に優れている、と考えているわけではありません。
今回の結論は、モデルの能力、学習データの傾向、そして2026年現在のエージェントツールの設計に基づくものです。
現在のエージェントは総じて、1回で完結するコードブロックを書くことを得意としています。多くのシェルツールも、「コマンドを送信する→終了を待つ→結果を返す」というシンプルなライフサイクルを前提に設計されています。この条件下では、ヒアドキュメントの方がやり取りの回数を減らし、制御フローをローカルで実行するコードに移しやすくなります。
ただし、こうした状況はすぐに変わる可能性があります。
将来のエージェントツールでは、信頼性の高い継続的なセッション、構造化された出力、安定した状態復元などが提供されるようになるかもしれません。そうなれば、エージェント自身がREPLのプロンプトやプロセスの状態、セッションの中断などを直接管理する必要はなくなるでしょう。 また、適切な学習によって、モデルが細かな操作を逐次的に繰り返すのではなく、最初から完結したプログラムをREPLに送るようになる可能性もあります。
そうなればREPLは、モデルの呼び出し回数を増やすことなく、状態の再利用や即時フィードバックといった利点を活かせるようになるかもしれません。初期化コストが高いタスク、長時間にわたって状態を維持するタスク、あるいは本当に探索的なワークフローでは、REPLの方が適している可能性もあります。
だからこそ、タイトルでは 2026を強調しています。私たちは、これが今後も変わらない普遍的な答えだと主張しているわけではありません。これはあくまで、現在利用できるモデルとエージェントツールを前提とした、現時点でのエンジニアリング上の判断です。