エージェントにコード生成能力が不可欠な理由を解説

エージェントに関する議論の多くは、コード生成能力に焦点を当てています。ソフトウェア開発のためにエージェントを使う場合も、単なるスプレッドシートの整理に使う場合でも、コードを書けるという能力が膨大な機能の可能性を開きました。

コード生成エージェントはもはやエンジニアだけのものではありません。マーケター、デザイナー、アナリストなどにも活用されています。ホワイトカラーの職場で急速に普及しているのは、実務を完遂できるからであり、この普及が成長スピードを加速させています。市場での実績がそれを証明しています。Claude Code や Codex には非エンジニア向けの変種として「Claude Design」や「Codex Work」が存在し、Anthropic の収益は前年比で 10 倍に拡大しています。

ではなぜ、コードを書かない業務にもコード生成エージェントを使うのでしょうか？コードが解き放つ秘密の能力とは何でしょうか？

答えはシンプルです。現在、コードはほとんどのエージェントタスクにとって最適なツールだからです。LLM はプログラミング言語を使ってコードを通じて問題を解決できます。別のモダリティで訓練する必要はありません。

これは明確に最先端の研究機関の注目の的となっています。コード生成エージェントが台頭して以来、最新のフロンティアモデルは主にソフトウェア工学のベンチマークに基づいて訓練・評価されてきました。

「コードモード」「ダイナミックワークフロー」「サンドボックス」といった用語を耳にしたことがあるかもしれません。なぜこれらが今ほど注目されているのかと疑問に思った人もいるでしょう。結局のところ、LLM がツールを呼び出しているだけではないですか？関数を呼び出すことと何が違うのでしょうか？

本稿では、コード実行モードがなぜ重要なのか、単純なツール呼び出しがどこで破綻するのか、そして独自のエージェント基盤にサンドボックス化された実行環境を追加する際に注意すべき点について解説します。

ツール呼び出しの基礎：仕組みを理解しよう

コード実行モードの話に入る前に、まず「ツール呼び出し」が何を指すのか理解しておく必要があります。ツールを使えば、LLM（大規模言語モデル）の能力を拡張できます。例えば、多くの LLM は数学的な計算が苦手です。しかし、電卓というツールを与えれば、正解を導き出す可能性が高まります。

基本的な仕組みは以下の通りです。LLM に利用可能なツールのリストを与え、ユーザーから質問が出されます。モデルは直接回答するか、あるいは情報不足と判断して特定のツールを選択します。LLM がツールを選んだ場合、そのツールのパラメータを満たす JSON を生成し、生成を停止します。その後、エージェント基盤（harness）がそのツールを実行し、結果をモデルにフィードバックします。これにより、モデルは次の行動について推論できるようになります。コンテキストウィンドウ内に結果が含まれた状態で、モデルはユーザーへの回答を出力するか、あるいはまだ情報が不十分だと判断して別のツールを選択します。エージェント基盤の役割は、要求されたタスクが完了するまでこのループを維持し続けることです。

このループはあらゆるエージェントの中核であり、多くの状況で機能します。しかし、エージェントに与えられるツールが多すぎた場合、どうなるでしょうか？

ツールが多すぎる問題

エージェントが接続するツールが増え（多くは複数の MCP サーバーを通じて）、その数は膨らんでいきます。すると、いくつかのコストが複合的に増大し始めます。

ツール定義がコンテキストウィンドウを埋め尽くしてしまいます。多くの大規模言語モデル（LLM）は、利用可能なツールの情報を事前に読み込むため、ツール定義を最初からロードします。しかし、ツールの数が増えると、これらの定義が推論に使えるトークンを圧迫し、コンテキストウィンドウがいっぱいになるとモデルの性能は低下する傾向があります。

すべての中間結果がモデルを経由して流れます。「会議の議事録をダウンロードして、Salesforce のリードに添付してください」と指示すると、長い議事録の場合、その全文がコンテキストウィンドウを2回通過することになります。1 回はツールからの結果として、もう 1 回は次のツール呼び出しへコピーする際です。会議が長引けば、追加で数万トークンが必要になり、モデルがデータを書き換えてしまうリスクも現実のものとなります。

レイテンシとコストはターンごとに積み上がります。各ツール呼び出しは新たなモデルのターンとなり、そのたびに増え続けるコンテキスト全体が再送信されます。30 の小さなステップからなるワークフローでは、トークン生成、ツールの実行、コンテキストの再構築というプロセスを 30 回繰り返す必要があります。これは遅く、かつ高価です。30 回の LLM 呼び出しに対して支払いが必要となり、それぞれ最後のものよりも長いプロンプトが使用されます。プロンプトキャッシュはコストを緩和しますが、完全に解消するわけではありません。キャッシュされたトークンにも費用がかかり、さらに各ターンで新しいトークンが追加されるためです。

ツール呼び出し機能はエージェント構築に不可欠ですが、ツールの数や記録、中間成果物が増えるにつれて、「各ステップの中心にモデルが存在する」という方式は高コストとなり、長期タスクを解決する能力を制限します。コンテキストウィンドウでは、この負荷を処理しきれないのです。

コードモードとは何か？

「コードモード」は、「ツールが多すぎる」という課題を解決する一つの方法です。その仕組みを理解するために、段階を追って解説していきましょう。

例えば、100 個のツールを持っていて、すべてをコンテキストウィンドウに事前に読み込ませたくない場合があるとします。ここで考えられるのが、検索と実行という 2 つのツールだけを公開するという案です。検索ツールを使えば LLM は自然言語で必要なツールを見つけられ、実行ツールを使えばカタログ内の任意のツールを実行できます。これだけで 100 個のツールが 2 個に減り、「問題解決！」となるように思えます。

しかし、待ってください。これはあくまで 100 個の定義を事前に読み込むコストだけを削減したに過ぎません。実際に作業を進めるには、モデルは依然として検索と実行を繰り返さなければならず、そのたびに以前よりも余計な検索呼び出しが発生してしまいます。軽量な初期プロンプトと引き換えに、往復通信がさらに増える結果となり、レイテンシとコストの問題は解消されません。

そこで登場するのがコーディングサンドボックスです。すべてのツールをモデルに直接公開するのではなく、エージェントにサンドボックスを提供し、その中でツールを関数として公開します。ツールを一つずつ呼び出すのではなく、エージェントはループや条件分岐を組み合わせた小さなプログラムを書き、タスクを実行して、有用な最終結果だけを返すのです。

これで、ツール数は 2 つのまま、ターン数を減らし、トークン効率も大幅に向上します。これがコードモードの核心です。

実践におけるコードモード

コードモードは、ツールの利用効率を高めるだけでなく、エージェントが「これまでどのツールでも対応できなかった作業」をコードを書くことで実行可能にするという点で、強力なパターンとなっています。

具体的な例で考えてみましょう。クレジットカード番号が誤ってデータセットに含まれてしまった場合、エージェントにそれらを削除させることを想定します。

通常のツール呼び出しの場合、エージェントは手動で 3 つのツールを順次実行する必要があります。

list_datasets()

→ get_dataset_examples("dataset-1")

→ [モデルが各例を読み込み、カード番号をマスクして書き直す]

→ update_examples("dataset-1", redacted)

→ get_dataset_examples("dataset-2")

→ ...

すべてのデータ例は、入力時と出力時の 2 回にわたってコンテキストウィンドウを通過します。モデル自身が行う赤書き処理は、レコードが数千件に及ぶ場合でも、トークン単位で逐次実行されます。これは遅く、コストも高くつき、さらに書き直しごとにデータが破損したり、カード番号の見落としや漏洩が発生するリスクがあります。

一方、コードモードではエージェントは 1 つのプログラムを記述します。ここで注意すべき点は、redactPII という関数は事前に用意されたツールではないということです。モデルがその場で自作したものです。

Copy

定数 CARD_NUMBER は、13〜16 桁のカード番号を検出する正規表現です。

function redactPII(example) {

return {

...example,

input: example.input.replace(CARD_NUMBER, "[REDACTED]"),

output: example.output.replace(CARD_NUMBER, "[REDACTED]"),

}

}

const datasets = await list_datasets()

let redacted = 0

for (const dataset of datasets) {

const examples = await get_dataset_examples(dataset.id)

const cleaned = examples.map(redactPII)

redacted += cleaned.filter((e, i) => e !== examples[i]).length

await update_examples(dataset.id, cleaned)

}

console.log(redacted ${redacted} examples across ${datasets.length} datasets)

エージェントが使用する基盤となるツール自体は変わりません。変化するのはインターフェースです。N 個のツールスキーマと N 回の往復通信を行う代わりに、モデルはコード API を見て、プログラムを実行するための単一のツール呼び出しを行います。

さらに付随するメリットとして、クレジットカード番号はコンテキストに一切入力されず、モデルが目にするのは何が起こったかの一行サマリーだけです。

"Code mode" は特殊なトリックではありません。最先端のラボがあらゆるレイヤーで構築している標準的なパターンです。Claude Code などのコードハッチは、本質的にシェルとファイルシステムを持ち、プログラムを実行できるサンドボックスを備えたモデルです。このコーディング能力こそが、ループ内でツールを使う従来の LLM を凌駕する要因となっています。

最新のモデルは、この種の環境で活躍するように明示的に訓練されており、多くの MCP サーバーも同様の方向へ進み、ツールをコード API として公開するケースが増えています。企業がこうした方針を採用するのは、モデルの能力が最も急速に進化しているのが「コード」という単位だからです。

コードモードのトレードオフ

コードモードにはメリットだけでなく、課題もあります。よく理解されている問題群と引き換えに、新たな問題群を抱え込むことになります。その中には深刻なものも含まれています。

LLM が生成したコードを実行することになります。

LLM 生成コードの実行には、本格的なサンドボックス化が不可欠です。また、コードがどこで実行されるかも極めて重要です。生成されたコードは、CPU・メモリ・実行時間・ファイルシステムアクセスに対して厳格な制限を設けた隔離環境（コンテナ、マイクロ VM、またはインタプリタレベルのサンドボックス）内で実行されなければなりません。ネットワークアクセスについても慎重な検討が必要です。プロンプトインジェクションを受けたエージェントが開放された接続を持つと、コードを書くだけでデータを外部へ持ち出せる可能性があります。サンドボックスは、ユーザーがアクセス権限を持つ関数とデータのみを公開すべきです。また、エージェントが何と言ったかだけでなく、実際に実行した内容も記録しておく必要があります。これらを後付けするのは容易ではありません。最初から設計に組み込む必要があります。幸いなことに、隔離の問題は自社でゼロから構築するよりも、既存のサービスを利用する方が現実的です。Vercel Sandboxes や Daytona といったプロバイダーが存在するのも、多くのチームが同時にこの壁にぶつかったからです。

デバッグが難しくなります。

ツール呼び出しの失敗は、明確な入力と出力を持つ離散イベントとして捉えられます。一方、プログラムのバグはより微妙です。その原因はエージェントのロジックにあるのか、ツールの組み合わせ方にあるのか、あるいはサンドボックス内で発生して外部に現れなかった中間結果にあるのかもしれません。こうした状況では、トレース（実行履歴）を読み解き評価することが難しくなります。

もしかすると、モデルやハッチス（検証環境）が既に持っている機能を、あなたが新たに作り直そうとしているのかもしれません。

コードモードには、サンドボックス以上のものが必要です。エージェントは適切な関数を見つけ、その API を学習できる手段を備えている必要があります。つまり、何らかの形でツールを検索する機能が必要なのです。

しかし、基盤モデルやコーディングハッチスでは、すでにツール検索とコード実行が組み込まれて提供されるケースが増えています。もし MCP サーバーなどの独自環境内でこれらを実装すると、本来そのレイヤーが担うべきではない機能を、ハッチスが既に提供しているものを重複して実装することになりかねません。この分野のベストプラクティスはまだ進化途上にあるため、これは絶対的なルールというよりも、一つの注意喚起として捉えるべきでしょう。

実は、コードモード自体が必要ないケースもあるのです。

コードモードが求められる背景には現実的な課題が存在しますが、1 年前に比べてその深刻さは低下しています。モデルはより多くのツールリストを扱いやすくなり、ハッチスもロードする内容について賢くなっています。

ツールの数が限られた製品であれば、単純なツール呼び出しの方がシンプルで安全な選択肢となるでしょう。コードモードが複雑さを正当化するのは、ツールの数やデータ量、あるいはタスクの範囲が、ツール呼び出しがスムーズに処理できる規模を超えた時です。

コードによってエージェントは何ができるのか

エージェントにコード記述能力を与えることで、自然言語による推論だけでは到達できなかった機能を実現できます。これにより、エージェントはその場でワークフローを生成したり、大規模なデータ変換を行ったり、単一のプログラム内で数十ものツールを調整できるようになります。動的ワークフローといった新しいパターンでは、堅牢なオーケストレーション層に頼るのではなく、コードを通じてサブエージェントの起動と調整も可能になります。

Arize では、コードモードを積極的に活用しています。私たちのエージェントはコードモードを使って、自身のコンテキストウィンドウを管理します。実験結果のような大規模なペイロードはサンドボックス内に保持し、モデルのコンテキストに到達する前に結果をフィルタリングするために利用します。

トレース上で何かが失敗した場合、エージェントはサンドボックス内で SQL を記述・実行して集約クエリにより問題箇所を特定します。これは、ツール呼び出しごとに結果を一つずつ確認する従来の手法とは対照的です。

ツール呼び出し機能によってエージェントが有用なものとなりましたが、コードの導入によってその拡張性が飛躍的に向上したことは疑いの余地がありません。モデルはこの目的に合わせてチューニングされ、インフラストラクチャもこれに成熟し、このパターンはエコシステム全体で収束しつつあります。

LLM に新しいインターフェースを与えることは、その能力範囲を広げることを意味します。コードこそが、私たちが発見した最も汎用性の高いインターフェースです。自らのソフトウェアを記述できるエージェントは、与えられたツールに制限されません。問題に応じて必要なものを自ら構築できます。このパターンが AGI への道筋となるかどうかはまだ不明ですが、自律性における確かな一歩であることは間違いありません。

この記事「Code mode: Why your agent should code」は、Arize AI の公式ブログで最初に公開されました。