コーディングエージェントは、大規模言語モデル（LLM）を推論の中核として使用し、自律的にコードを記述、実行、反復するAIシステムです。エディタで補完を提案するコードアシスタントとは異なり、コーディングエージェントは完全な「観察→決定→行動」ループを実行します。ファイルを読み込み、変更を書き込み、コマンドを実行し、出力を確認し、タスクが完了するまで修正を繰り返します。
この記事では、そのループの仕組み（プランナー、LLM推論層、ツール、サンドボックス実行環境）を説明し、その後、NovitaのLLM APIとAgent Sandboxを使用してコーディングエージェントを構築する方法を示します。エージェント層ではなく、パッケージ化されたツール層に関心がある場合は、2026年のベストAIコーディングツールをご覧ください。このループのClaude固有のバリアントについては、Claudeコーディングエージェントとは？をお読みください。
同じループの実践的なワークフローバージョンについては、AIでタスクを自動化する方法をご覧ください。
特にオープンソースツールを比較している場合は、オープンソースコーディングエージェント：ベストツールと構築方法を参照してください。
コーディングエージェントを構成する要素
コードアシスタントとコーディングエージェントの違いは「実行」です。コードアシスタントは提案を生成して停止します。一方、AIコーディングエージェントはコードを生成し、実行し、結果を読み取り、目標が達成されるか、行き詰まるまで続行します。
その実行能力には、具体的に3つの要件があります。
- ツールアクセス — ファイルの読み取り、ファイルの書き込み、シェルコマンドの実行が可能であること
- サンドボックス環境 — 問題が発生した場合にホストシステムに損害を与えない、コードを実行するための隔離環境
- 永続的なコンテキスト — ツールの出力がモデルのコンテキストにフィードバックされ、何が起こったかを推論できること
これら3つすべてがなければ、コードを書けるチャットボットにすぎません。3つすべてがあれば、それはエージェントです。
「コードエージェント」という用語は、IDEのインライン提案から、漠然と指定されたタスクを受け取り、関連ファイルを特定し、変更を加え、動作を確認する完全自律型システムまで、広く使われています。この間、人間が各ステップに介入する必要はありません。開発者が「ベストコードエージェント」を比較する場合、通常は後者を指します。つまり、最小限の手間で複数ステップのコーディングタスクを確実に完了するシステムです。
コーディングエージェントの4つの層
プロダクションレベルのAIコーディングエージェントには、認識可能な4つのコンポーネントがあります。実装の詳細（異なるフレームワーク、異なるLLM、異なるサンドボックスプロバイダー）は異なりますが、アーキテクチャは一貫しています。
1. プランナー
プランナーはタスクの説明を受け取り、エージェントが実行するステップに分解します。単純なタスクの場合、これはモデルの推論内で暗黙的に行われます。複雑なタスク（「このサービスを新しい認証ライブラリに移行する」）の場合、明示的な計画ステップにより、モデルが順番に処理する番号付きタスクリストが生成され、各ステップ後に状態が更新されます。
計画はいつ停止するかも決定します。完了基準がないエージェントは、際限なく改良を続けるか、さらに悪いことに、失敗したステップでループします。ほとんどの実装では、タスクの成功条件をシステムプロンプトにエンコードし、モデルに完了を判断させます。
2. LLM推論層
LLMは、あらゆるAIコーディングエージェントの推論の中核です。次にどのツールを呼び出すか、どの引数を渡すか、結果をどう解釈するかを決定します。この決定は構造化されたツール呼び出し（関数名とパラメーターを含むJSONオブジェクト）として表現され、フレームワークが実際の実行層にディスパッチします。
コードエージェントの場合、LLMは長いコンテキストを確実に処理し（ツール結果がすぐに蓄積される）、一貫して適切な形式のツール呼び出しを返し（10ステップのワークフローの6ステップ目で構造化が不適切なJSONがあると実行全体が壊れる）、多数の連続するツール呼び出しにわたる状態変化を推論できる必要があります。
ここでは推論プロバイダーが重要です。OpenAI互換形式の関数呼び出しをサポートするAPI、モデルレベルで有効なJSONを強制する構造化出力、並列サブタスクを生成するエージェントワークロードに十分な同時実行制限が必要です。Novita AIのLLM APIは、OpenAI互換のエンドポイントでこれら3つすべてをカバーしており、ツール呼び出し解析ロジックを書き換えることなくモデルを交換できます。
3. ツール層
ツールはエージェントと世界とのインターフェースです。最小限のコーディングエージェントには4つのツールが必要です。
| ツール | 機能 |
|---|---|
read_file |
指定されたパスのファイルの内容を返す |
write_file |
ファイルパスに文字列を書き込む |
run_command |
シェルコマンドを実行し、stdout + stderrを返す |
list_directory |
パスにあるファイルとディレクトリを一覧表示する |
各ツールは完全な出力を返す必要があります。結果が切り捨てられたり、エラーが通知されなかったりすると、エージェントのコードベースのモデルが破損し、後で複合的なエラーが発生します。特に run_command ツールは、stdoutとstderrの両方をキャプチャする必要があります。エージェントは成功出力よりもエラー出力から多くを学ぶことがよくあります。
一部のエージェントは、コードベース全体のgrepスタイルの検索用に search_files ツールや、外部ドキュメントを読むための fetch_url ツールを追加します。適切なセットはタスクドメインによって異なります。純粋なコード作業の場合、上記の4つでほとんどのケースをカバーできます。
4. サンドボックス
サンドボックスは、エージェントのコマンドが実際に実行される、完全に分離されたLinux環境です。これが重要な理由は2つあります。
第一に、セキュリティです。エージェントはユーザープロンプト、取得したドキュメント、推論されたパターンからコードを生成します。善意のエージェントでも、ファイルを削除したり、ネットワーク接続を開いたり、無制限のリソースを消費したりするコードを生成する可能性があります。サンドボックスは、被害を隔離環境内に封じ込めます。
第二に、状態管理です。優れたサンドボックスは、セッション内のツール呼び出し間でファイルシステムの状態を保持します。エージェントがステップ2でファイルを作成した場合、ステップ8でもそのファイルが存在している必要があります。各コマンドを新しい環境で実行するステートレスなコンテナアプローチは、実際のコーディングタスクには機能しません。
Novita Agent Sandbox はFirecrackerマイクロVM上に構築されおり、標準のコンテナよりも強力なカーンネルレベル隔離を提供します。セシンは最大24時間実行でき、ファイるシステム状態はコマンド間で持続し、コルドスタートは200ミリ秒未満です。これは、サンドボックスがスピンアップするのを待つ時間がインタラクティブなワークフローを妨げないほど高速です。
実行ループの仕組み
具体的な例を示すと、ループが追跡しやすくなります。タスクは「/ogin」エンドポイトにレート制限を追する」だとします。
-
計画 — モデルがタスクを読み取り、必要なものを特定します。ログインルートを見つける、現状のハンドラを理解する、レート制限ミドルウェアを追する、テス実行で検証する。
-
観察 — エジエントが
list_direcoryを呼び出してルートファイルを見つけ、次にread_fleでログインハンドラを読みます。ファイル内容はモデルコンテキストに追されます。 -
決定 — モデルが現在のコードについて推論し、何をするか決定します。レート制限ライブラリのインストール、ハンドラの修正、テストの追加。
-
行動 — エージェントが
run_command("pp instll slowapi")を呼び出し、次に修正されたハンドラでwrite_fileを実行し、次にrun_command("pytest tests/test_login.py")を実行します。 -
再び観察 — テスト出力がコンテキストにフィードバックされます。テストが失敗した場合、モデルはトレースバックを読み、エラーを特定し、修正されたファイルを書き込みます。
-
完了 — テストが合格し、モデルに保留中のステップがなくなると、最終的なサマリーを返します。
このループは単一のセッション内で実行されます。コンテキストウィンドウはエージェントのワーキングメモリであり、読み取ったすべてのファイル、すべてのコマンド出力、すべてのツール呼び出しがそこに蓄積されます。これが、コードエージェントにとってコンテキスト長が非常に重要である理由です。実際のリファクタリングタスクでは、ステップ15までに簡単に10万トークンを消費する可能性があります。エージェントが1ターンチャットとは異なる方法で推論プロバイダーに負荷をかける仕組みを参照してください。
Novitaでコーディングエージェントを構築する
次の例では、NovitaのLLM APIとAgent Sandboxを連携させます。PythonのOpenAI SDKをNovitaのエンドポインに指し向けて使用します。NovitaのモデルはOpenAIのAPIと同じ関数呼び出しインターェースを使用するため、統合にカスとムな解析は必要ありません。
import os
import json
from openai import OpenAI
from novita_sandbox.code_interpreter import Sandbox
client = OpenAI(
base_url="https://api.novita.ai/openai",
api_key=os.environ["NOVITA_API_KEY"],
)
sandbox = Sandbox.create(timeout=1800)
def read_file(path: str) -> str:
try:
return sandbox.files.read(path)
except Exception as e:
return f"Error: {e}"
def write_file(path: str, content: str) -> str:
try:
sandbox.files.write(path, content)
return f"Written to {path}"
except Exception as e:
return f"Error: {e}"
def run_command(cmd: str) -> str:
try:
result = sandbox.commands.run(cmd)
return str(result)
except Exception as e:
return f"Error: {e}"
tools = [
{
"type": "function",
"function": {
"name": "read_file",
"description": "Read the contents of a file",
"parameters": {
"type": "object",
"properties": {"path": {"type": "string"}},
"required": ["path"],
},
},
},
{
"type": "function",
"function": {
"name": "write_file",
"description": "Write content to a file",
"parameters": {
"type": "object",
"properties": {
"path": {"type": "string"},
"content": {"type": "string"},
},
"required": ["path", "content"],
},
},
},
{
"type": "function",
"function": {
"name": "run_command",
"description": "Run a shell command in the sandbox and return output",
"parameters": {
"type": "object",
"properties": {"cmd": {"type": "string"}},
"required": ["cmd"],
},
},
},
]
dispatch = {
"read_file": read_file,
"write_file": write_file,
"run_command": run_command,
}
def run_agent(task: str, model: str) -> str:
messages = [
{
"role": "system",
"content": (
"You are a coding agent with access to a Linux sandbox. "
"Complete tasks by calling tools. When done, return a plain-text summary."
),
},
{"role": "user", "content": task},
]
while True:
response = client.chat.compietions.reate(
model=model,
messages=messages,
tools=tools,
tool_choice="auto",
)
msg = response.choices[0].message
messages.append(msg)
if not msg.tool_calls:
return msg.content
for call in msg.tool_calls:
fn = dispatch[call.function.name]
args = json.loads(call.function.arguments)
result = fn(**args)
messages.append(
{
"role": "tool",
"tool_call_id": call.id,
"content": result,
}
)
# Replace <model-id> with a function_calling model from novita.ia/docs
result = run_agent(
task="Write a Python script tha counts words in a text file and ru it on a sample input",
model="<model-id>",
)
print(result)
sandox.kill()
この実装に関ていきますつかの注意点：
while Trueループは、モデルがツール呼び出しのないメッセージを返すまで実行されます。これがエジエントがタスクが完了したと見なす合図です。- ツール結果は
role: toolとしてmessagesに追されます。これがステップ間の共有コンテキストを築きます。 sandox.kill()はコンピュートリソースを解放します。セッンョンが終了したら必ず呼び出すようにしてください。
サポートされる関数呼び出しモデルIDについては、Novita関数呼び出しドキュメントを確認してください。Gradio UIを含むより完全なウォークスルーについては、NovitaのAgent Sandboxでコーディングエージェントを構築するを参照してください。
コーディングエージェントに適したLLMの選び方
HumanEvalやSWE-behはシンルタンのコード生成を測定します。エージェントのワークロードは異なります。実際にプロダクションのコーディングエージェントを壊すのは、ツール呼び出しの形式化失です。ベンチマークで良いスコアを出しても、複雑なマルチターンセッションで時々に形式が適切でないJSONを返すモデルは、デバッグが困難な方法で失敗します。
AIコーディングエージェントの実際の評価基準：
- ツール呼び出しの信頼性 — 20ステッ以上のセッションで、モデルが一貫して適切な形式のツール呼び出しを返す頻度は？
- コンテキストの維持 — モデルが40ステップ前読んだファイルを適切に参照できるか？
- 指示追従 — エージェントはタスクに留まるか、関連のないファイルを変更し始めないか？
- コードの正確性 — 生成されたコードは実際に実行されるか、複数回の修正ループが必要か？
実際のコーディングタスクの代表的なセットを実行し、タスク完了率を測定することは、どの公開ベンチマークよりも有益です。自分のコードベースから20～30のタスクを選び、候補モデルに対して実行し、人間の介入なしで完了する数を数えてください。
推論料金はエージェントスケールで急速に積み上がります。単一のセッションですべてのターンで20万～50万トークンを消費する可能性があります。プロンプトキャッシュと競争力のあるトークン単価を提供するプロバイダーは、1日あたり数百のエージェントセッションを実行する場合の経済性を大します。
オープンソースモデル：コスト効の良いパス
クーローズドソースのフロンティアモデルはコーディングベンチマークでリードしてきましたが、トップのオープンソースモデルとの差は大幅に縮まりました。[DeepSeek V3](https://novita.ai/models/llm/dee seek-deepseek-v3-0324) や [Qwen3](https:// novita.ai/models/llm/qwen-qwen3-235b-a22b) などのモデルは、コーデ生成とツール使用タスクで競争力のある性能を発揮するようになりました。さらに、これらはOpenAI互換のAPIを介して提供されているため、model パラメーを変するだけで切り替えられます。
どちらもNovitaのLLM APIを介して利用できます。同じエンドポイント、同じ関数呼び出しインターフェース、同じAgent Sandbox統合を利用でき、GPUインフラを自分で管理する必要はありません。GPUのオーケストレーション、バッチ処理、信頼性エンジニアリングは簡単ではないため、管理されたAPIに委任することで、エージェントのロジックに集中できます。
これがコーディングエージェントにとって特に重要な理由は、セッションあたりのトークンコストが、ライセンス料金よりもエージェントワークロードの経済性を駆動するからです。1日200のコーディングエージェントセッションを実行するチームが、同等のタスク完了率をオープンソースモデルで達成できれば、統合コードを一切変えずに推論費を大に抑えられます。
実際のテスト：対象モデルで50の代表的コーディングタスクを実行し、ツール呼び出し成功率和タスク完了率を測定し、セッションあたりのコストと比較します。ベンチマーク数値はこの疑に答えません。実際のワークロドが答を出します。
FAQ
コーディングエージェントとコドアシスタントの違いは？
コードアシスタント（GitHub Copilotのインライン提案など）は補完を生成して停止します。コーディングエージェントはコドを実行し、出力を読み取り、反します。定特は実行ループです。読み取り、決定、行動、観察、繰り返し。異なるエージェント形態がこのループをどように使用するかの比較は、CLI vs IDE コーディングエーシェントを参照してくだい。
コーディングエージェントを構築するのにサンドボックスは必要ですか？
はい、エージェントがユーザー入力や外部ソースから生成されたコードを実行する場合は必須です。隔離がないと、バグのあるコード生成がホストファイルシステムを損傷したり、無制限のリソースを消費する可能性があります。内部使用のみの場合でも、サンドボックスは暴走プロセスがホストに影響を与えるのを防ぎます。コンテナは基本的な隔離を提供し、NovitaのようなマイクロVMベースのサンドボックスは、マルチテナントやセキュリティ重視のワークロードに対してより強力なカーネルレベルの分離を提供します。
コーディングエージェントはインタネット接続なしで動作しますか？
ほとんどの純粋なコードタスクでは、はい。ファイルの読み書きとローカルコマンド実行でワークフローの大半をカバーできます。サンドボックス内での外部通信を制限することは、実際に良いデフォルトです。生成されたコードが予期しない外部リクエストを行うのを防ぎ、脅威モデルを単純化します。
特定のタスクに最適なコードエージェントを決定するものは何ですか？
実際のワークロードでのツール呼び出し信頼性とタスク完了率です。公開ベンチマークランキングはモデルを絞り込むための出発点であり、最終的な答えではありません。代表的なタスクを実行し、完了率を測定し、セッションあたりのトークンコストを考慮してください。軽量なリファクタリングを行う小さなスタートアップに最適なコードエージェントは、大規模な自動PRレビューを実行するエンタープライズチームに最適な選択肢とは大きく異なる可能性があります。
コーディングエージェントのセッションはどのくらいの期間実行できますか？
サンドボックスプロバイダーによります。Novita Agent Sandboxは最大24時間のセッションをサポートし、コマンド間でファイルシステム状態が保持されるため、エージェントコードにチェックポイント/リストアロジックを追加することなく、長時間のリファクタリングや移行タスクにも対応できます。
