コーディングエージェントの仕組み
Simon Willisonは、コーディングエージェントの内部動作を理解することが適用判断に不可欠であり、LLMのトークン化・プロンプト形式・マルチモーダル処理の仕組みを解説している。
キーポイント
コーディングエージェントの正体
LLMを基盤とし、見えないプロンプトとツール呼び出しで拡張されたソフトウェアハースであり、単なるモデルではなく実行環境を指す。
LLMの動作原理とトークン化
テキストは整数のトークン列に変換され、処理量で課金・コンテキスト制限がかかるため、コスト管理とトークン数の把握が実務上不可欠である。
マルチモーダルとチャットテンプレート
画像入力もテキスト同様にトークン化して処理するためOCRなどの別プロセスを経ず、会話形式のプロンプトは実質的に構造化された完成予測プロンプトである。
影響分析・編集コメントを表示
影響分析
本記事は、コーディングエージェントの黒箱化が進む中で、その内部動作（トークン処理・プロンプト構造）を明確に可視化した。開発者はこれにより、コスト最適化やプロンプト設計の精度を高められるため、エージェント開発の実践ガイドラインとして広く参照されるだろう。
編集コメント
技術的な仕組みを平易に解説しており、エージェント開発の初学者から中級者まで実装設計やコスト見積もりに役立つ実践的なリソースである。
*Agentic Engineering Patterns >*
どのようなツールと同様に、コーディングエージェント が内部でどのように動作するかを理解することは、それらをどのように適用するかについてより良い意思決定を下すのに役立ちます。
コーディングエージェントとは、LLM（大規模言語モデル）のためのハネスとして機能するソフトウェアの断片であり、目に見えないプロンプトによって駆動され、呼び出し可能なツールとして実装された追加機能をその LLM に拡張します。
大規模言語モデル
あらゆるコーディングエージェントの中核には、大規模言語モデル（LLM）があります。これらには GPT-5.4 や Claude Opus 4.6、Gemini 3.1 Pro、Qwen3.5-35B-A3B といった名前が付けられています。
LLM は文章を完成させることができる機械学習モデルです。モデルに「the cat sat on the」というフレーズを与えると、（ほぼ確実に）文の次の単語として"mat"を提案します。
これらのモデルが大きくなり、より多くのデータでトレーニングされるにつれて、より複雑な文章を完成させることができます。例えば、「URL からファイルをダウンロードする Python 関数は def download_file(url): です」といったものです。
LLM は実際には言葉そのものではなく、トークン（token）を使って動作します。テキストのシーケンスは整数のトークンのシーケンスに変換されるため、「the cat sat on the」は [3086, 9059, 10139, 402, 290, 220] となります。これは理解しておく価値があります。なぜなら、LLM プロバイダーは処理されたトークンの数に基づいて課金しており、一度に考慮できるトークンの数には制限があるからです。
この仕組みは platform.openai.com/tokenizer の OpenAI トークナイザーを実験することで確認できます。
LLM への入力入力はプロンプトと呼ばれます。LLM が返すテキストは完成文、あるいは単に応答と呼ばれることもあります。
今日の多くのモデルはマルチモーダルであり、これはテキストだけでなく他の形式も入力として受け取れることを意味します。ビジョン LLM（vLLMs）は画像を入力の一部として受け付けることができ、スケッチや写真、スクリーンショットを供給することが可能です。よくある誤解として、これらは OCR や画像分析のための別プロセスを経ると考えられがちですが、実際にはこれらの入力もさらに多くのトークン整数に変換され、テキストと同じ方法で処理されます。
チャット形式のプロンプト
最初の LLM は完成エンジンとして機能していました。ユーザーはモデルによって完成されるべきプロンプトを提供する必要があり、上記の 2 つの例がその典型です。
これは特にユーザーフレンドリーではなかったため、モデルは主にチャット形式のプロンプトへと切り替えました。これはモデルとの対話をシミュレーションされた会話として表現するものです。
実際にはこれこそが、以下のような特殊なフォーマットを持つ完成プロンプトの一種です。
user: URL からファイルをダウンロードする Python 関数を書いてください
assistant:
このプロンプトに対する自然な完成文は、LLM で表されるアシスタントがユーザーの質問に答える形で、いくつかの Python コードを提供することです。
LLM はステートレスです：プロンプトを実行するたびに、同じ白紙の状態から開始されます。
会話のシミュレーションを維持するためには、モデルと対話するソフトウェアが独自の状態を保持し、ユーザーが新しいチャットプロンプトを入力するたびに既存の会話をすべて再生する必要があります：
user: write a python function to download a file from a URL
assistant: def download_url(url):
return urllib.request.urlopen(url).read()
user: use the requests library instead
assistant:
プロバイダーは入力トークンと出力トークンの両方に対して課金するため、会話が進むにつれて各プロンプトのコストが高くなります。これは、入力トークンの数が毎回増加するためです。
トークンキャッシング
ほとんどのモデルプロバイダーは、キャッシュされた入力トークン（cached input tokens）に対するより安価なレートを通じて、この問題をある程度緩和しています。短時間内に処理された共通のトークンプレフィックスは、基盤となるインフラストラクチャがその入力を処理するために使用される多くの高コスト計算をキャッシュして再利用できるため、より低いレートで課金されます。
コーディングエージェント（coding agents）はこの最適化を意識して設計されており、キャッシュを最も効率的に利用できるように、以前の会話内容を修正しないようにしています。
ツールの呼び出し
LLM エージェントの定義的な特徴は、エージェントがツール（tools）を呼び出せる点です。しかし、ツールとは何でしょうか？
ツールとは、エージェントが LLM に提供する関数です。
プロンプト自体のレベルでは、それは以下のようなものになります：
システム：天気にアクセスする必要がある場合は、get_weather(city_name) でターンを終了してください
ユーザー：サンフランシスコの天気はどうですか？
アシスタント：
ここでアシスタントは以下のようなテキストで応答する可能性があります。
get_weather("San Francisco")
モデルを制御するソフトウェアはその後、その関数呼び出し要求をレスポンスから抽出します（おそらく正規表現を用いて）し、ツールを実行します。
そして、構築されたプロンプトと共に結果をモデルに返します。このプロンプトは以下のような見た目になります。
システム：天気にアクセスする必要がある場合は、get_weather(city_name) でターンを終了してください
ユーザー：サンフランシスコの天気はどうですか？
アシスタント：get_weather("San Francisco")
ユーザー：61°、曇り時々晴れ
アシスタント：
LLM（大規模言語モデル）は теперь このツールの結果を使用して、ユーザーの質問に対する回答を生成するのを助けることができます。
ほとんどのコーディングエージェントでは、エージェントが呼び出すための dozen 以上のツールが定義されています。これらのうち最も強力なものはコードの実行を可能にするものであり、例えばターミナルコマンドを実行するための Bash() ツールや、Python コードを実行するための Python() ツールなどがあります。
システムプロンプト
前の例では、「システム」とマークされた初期メッセージを含め、利用可能なツールとその呼び出し方を LLM に通知しました。
コーディングエージェントは通常、ユーザーには表示されないが、モデルの行動様式を指示する命令を提供する、以下のようなシステムプロンプトで会話を開始します。
これらのシステムプロンプトは数百行に及ぶこともあります。2026 年 3 月時点の OpenAI Codex のシステムプロンプト は、これらのコーディングエージェントを機能させるための指示の種類の有用で明確な例となっています。
推論（Reasoning）
2025 年の大きな新進歩の一つは、最先端モデルファミリーに推論（reasoning）が導入されたことです。
推論は、ユーザーへの回答を提示する前に問題とその潜在的な解決策について説明するテキストを生成するためにモデルが追加の時間を費やすプロセスであり、UI では思考（thinking）として表示されることもあります。
これは人が声に出して考える様子に似ており、同様の効果をもたらします。重要なのは、より良い結果を得ることを目指して、モデルが問題に取り組むためにより多くの時間とトークンを割けるようになる点です。
推論は特にコード内のデバッグにおいて有用です。これにより、モデルは複雑なコードパスをナビゲートする機会を得られ、ツール呼び出しを組み合わせながら、推論フェーズを使用して関数呼び出しを追跡し、問題の潜在的な発生源へと辿り着くことができます。
多くのコーディングエージェントには、推論の努力レベルを上げたり下げたりするオプションが含まれており、モデルがより難しい問題を咀嚼するために時間を費やすよう促しています。
LLM + システムプロンプト + ツールのループ
信じられないかもしれませんが、これがコーディングエージェントを構築するために必要なことのほとんどです！
これらの仕組みをより深く理解したいのであれば、自分自身でエージェントをゼロから構築してみるという有用な演習があります。既存の LLM API を基盤にすれば、数行程度のコードでシンプルなツールループを実現できます。
しかし、*良い*ツールループを実現するには、それよりもはるかに多くの労力が必要ですが、その根本的なメカニズムは驚くほど単純です。
Tags: coding-agents, generative-ai, agentic-engineering, ai, llms
原文を表示
*Agentic Engineering Patterns >*
As with any tool, understanding how coding agents work under the hood can help you make better decisions about how to apply them.
A coding agent is a piece of software that acts as a harness for an LLM, extending that LLM with additional capabilities that are powered by invisible prompts and implemented as callable tools.
Large Language Models
At the heart of any coding agent is a Large Language Model, or LLM. These have names like GPT-5.4 or Claude Opus 4.6 or Gemini 3.1 Pro or Qwen3.5-35B-A3B.
An LLM is a machine learning model that can complete a sentence of text. Give the model the phrase "the cat sat on the " and it will (almost certainly) suggest "mat" as the next word in the sentence.
As these models get larger and train on increasing amounts of data, they can complete more complex sentences - like "a python function to download a file from a URL is def download_file(url): ".
LLMs don't actually work directly with words - they work with tokens. A sequence of text is converted into a sequence of integer tokens, so "the cat sat on the " becomes [3086, 9059, 10139, 402, 290, 220]. This is worth understanding because LLM providers charge based on the number of tokens processed, and are limited in how many tokens they can consider at a time.
You can experiment with the OpenAI tokenizer to see how this works at platform.openai.com/tokenizer.
The input to an LLM is called the prompt. The text returned by an LLM is called the completion, or sometimes the response.
Many models today are multimodal, which means they can accept more than just text as input. Vision LLMs (vLLMs) can accept images as part of the input, which means you can feed them sketches or photos or screenshots. A common misconception is that these are run through a separate process for OCR or image analysis, but these inputs are actually turned into yet more token integers which are processed in the same way as text.
Chat templated prompts
The first LLMs worked as completion engines - users were expected to provide a prompt which could then be completed by the model, such as the two examples shown above.
This wasn't particularly user-friendly so models mostly switched to using chat templated prompts instead, which represent communication with the model as a simulated conversation.
This is actually just a form of completion prompt with a special format that looks something like this.
user: write a python function to download a file from a URL
assistant:
The natural completion for this prompt is for the assistant (represented by the LLM) to answer the user's question with some Python code.
LLMs are stateless: every time they execute a prompt they start from the same blank slate.
To maintain the simulation of a conversation, the software that talks to the model needs to maintain its own state and replay the entire existing conversation every time the user enters a new chat prompt:
user: write a python function to download a file from a URL
assistant: def download_url(url):
return urllib.request.urlopen(url).read()
user: use the requests library instead
assistant:
Since providers charge for both input and output tokens, this means that as a conversation gets longer, each prompt becomes more expensive since the number of input tokens grows every time.
Token caching
Most model providers offset this somewhat through a cheaper rate for cached input tokens - common token prefixes that have been processed within a short time period can be charged at a lower rate as the underlying infrastructure can cache and then reuse many of the expensive calculations used to process that input.
Coding agents are designed with this optimization in mind - they avoid modifying earlier conversation content to ensure the cache is used as efficiently as possible.
Calling tools
The defining feature of an LLM agent is that agents can call tools. But what is a tool?
A tool is a function that the agent harness makes available to the LLM.
At the level of the prompt itself, that looks something like this:
system: If you need to access the weather, end your turn with get_weather(city_name)
user: what's the weather in San Francisco?
assistant:
Here the assistant might respond with the following text:
get_weather("San Francisco")
The model harness software then extracts that function call request from the response - probably with a regular expression - and executes the tool.
It then returns the result to the model, with a constructed prompt that looks something like this:
system: If you need to access the weather, end your turn with get_weather(city_name)
user: what's the weather in San Francisco?
assistant: get_weather("San Francisco")
user: 61°, Partly cloudy
assistant:
The LLM can now use that tool result to help generate an answer to the user's question.
Most coding agents define a dozen or more tools for the agent to call. The most powerful of these allow for code execution - a Bash() tool for executing terminal commands, or a Python() tool for running Python code, for example.
The system prompt
In the previous example I included an initial message marked "system" which informed the LLM about the available tool and how to call it.
Coding agents usually start every conversation with a system prompt like this, which is not shown to the user but provides instructions telling the model how it should behave.
These system prompts can be hundreds of lines long. Here's the system prompt for OpenAI Codex as-of March 2026, which is a useful clear example of the kind of instructions that make these coding agents work.
Reasoning
One of the big new advances in 2025 was the introduction of reasoning to the frontier model families.
Reasoning, sometimes presented as thinking in the UI, is when a model spends additional time generating text that talks through the problem and its potential solutions before presenting a reply to the user.
This can look similar to a person thinking out loud, and has a similar effect. Crucially it allows models to spend more time (and more tokens) working on a problem in order to hopefully get a better result.
Reasoning is particularly useful for debugging issues in code as it gives the model an opportunity to navigate more complex code paths, mixing in tool calls and using the reasoning phase to follow function calls back to the potential source of an issue.
Many coding agents include options for dialing up or down the reasoning effort level, encouraging models to spend more time chewing on harder problems.
LLM + system prompt + tools in a loop
Believe it or not, that's most of what it takes to build a coding agent!
If you want to develop a deeper understanding of how these things work, a useful exercise is to try building your own agent from scratch. A simple tool loop can be achieved with a few dozen lines of code on top of an existing LLM API.
A *good* tool loop is a great deal more work than that, but the fundamental mechanics are surprisingly straightforward.
Tags: coding-agents, generative-ai, agentic-engineering, ai, llms
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み