コーディングエージェントの仕組み
どのツールにも言えることですが、コーディングエージェントが内部でどのように機能しているかを理解することは、それらを適用する方法についてより良い判断を下すのに役立ちます。
コーディングエージェントは、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」を提案します。
モデルが大きくなり、より多くのデータで学習するようになると、より複雑な文を完成させることができます。例えば「a python function to download a file from a URL is def download_file(url): 」のような文です。
LLMs は実際には単語と直接的にやり取りするわけではなく、トークンで動作します。テキストの列は整数トークンの列に変換されるため、「the cat sat on the 」は [3086, 9059, 10139, 402, 290, 220] となります。これは、LLM プロバイダが処理されたトークンの数に基づいて料金を課すこと、そして一度に考慮できるトークン数に制限があることを理解する価値があります。
この仕組みを実際に確認したい場合は、platform.openai.com/tokenizer で OpenAI のトークナイザーを試してみてください。
LLM の入力は プロンプト と呼ばれます。LLM が返すテキストは 完了（応答 と呼ばれることもあります）と呼ばれます。
現在の多くのモデルは マルチモーダル であり、入力としてテキストだけでなく他のデータも受け取ることができます。 ビジョンLLMs（vLLMs）は入力の一部として画像を受け取ることができ、スケッチや写真、スクリーンショットを与えることができます。一般的な誤解は、これらがOCRや画像解析のために別の処理を経るということですが、これらの入力は実際にはさらに多くのトークン整数に変換され、テキストと同じように処理されます。
チャット型テンプレートプロンプト
初期の LLM は完了エンジンとして機能しました。 ユーザーはモデルが完了できるプロンプトを提供することが求められました。上に示した2つの例のように。
これは特にユーザーフレンドリーではなかったため、モデルはほとんどが代わりに チャット型テンプレートプロンプト を使用するようになり、モデルとの通信を模擬的な会話として表現します。
これは実際には特別な形式を持つ完了プロンプトの一形態で、次のようなものに見えます。
user: write a python function to download a file from a URL
assistant:
このプロンプトに対する自然な完了は、アシスタント（LLM によって表現される）がユーザーの質問に対して Python のコードを返すことです。
LLMs は状態を持ちません。プロンプトを実行するたびに、彼らは同じ白紙の状態から開始します。
会話のシミュレーションを維持するために、モデルと対話するソフトウェアは自分自身の状態を維持し、ユーザーが新しいチャットプロンプトを入力するたびに既存の会話全体を再現する必要があります：
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:
プロバイダは入力トークンと出力トークンの両方に料金を課すため、会話が長くなるにつれて、入力トークンの数が毎回増えるため、各プロンプトのコストが高くなります。
トークンキャッシュ
ほとんどのモデル提供者は、キャッシュ済みの入力トークンに対する安価な料金でこのコストをある程度相殺します。短時間のうちに処理された一般的なトークンの接頭辞は、基盤となるインフラストラクチャがキャッシュして再利用できるため、低い料金で課されることがあります。
コーディングエージェントはこの最適化を前提として設計されています。キャッシュをできるだけ効率的に利用するよう、以前の会話内容を変更することを避けます。
ツールの呼び出し
LLM のエージェントの決定的な特徴は、エージェントがツールを呼び出せることです。しかし、ツールとは何でしょうか。
ツールは、エージェントのハーネスがLLMに提供する関数です。
プロンプト自体のレベルでは、次のような感じです：
system: If you need to access the weather, end your turn with <tool>get_weather(city_name)</tool>
user: what's the weather in San Francisco?
assistant:
ここでアシスタントは次のテキストで応答する場合があります：
<tool>get_weather(\"San Francisco\")</tool>
モデルハーネスのソフトウェアは、レスポンスからその関数呼び出し要求を抽出します（正規表現を用いるのが一般的です）そしてツールを実行します。
その後、結果をモデルに返し、次のような構成のプロンプトを返します。
system: If you need to access the weather, end your turn with <tool>get_weather(city_name)</tool>
user: what's the weather in San Francisco?
assistant: <tool>get_weather(\"San Francisco\")</tool>
user: <tool-result>61°, Partly cloudy</tool-result>
assistant:
LLM はこのツール結果を利用して、ユーザーの質問への回答を生成するのに役立てることができます。
ほとんどのコーディングエージェントは、エージェントが呼び出せる12個以上のツールを定義しています。これらの中で最も強力なのは、コード実行を可能にするものです。例えば、端末コマンドを実行する Bash() ツールや、Python コードを実行する Python() ツールなどです。
システムプロンプト
前の例では、LLM に利用可能なツールと呼び出し方を知らせる「system」とマークされた初期メッセージを含めました。
コーディングエージェントは通常、会話ごとにこのようなシステムプロンプトから開始します。これはユーザーには表示されませんが、モデルの動作方法を指示するものです。
これらのシステムプロンプトは数百行にも及ぶことがあります。2026年3月時点の OpenAI Codex のシステムプロンプトは、以下のリンクのような、これらのコーディングエージェントを機能させる一連の指示の良い明確な例です。
推論
2025年の大きな新しい進歩の一つは、最前線モデル群に 推論 を導入したことです。
推論は、UI 上で 思考 として表示されることもあり、モデルがユーザーへ回答を示す前に、問題とその潜在的な解決策を解説する文章を追加で生成する時間を費やす状態のことです。
推論は、人が思考を口に出しているのと似たように見えることがあり、同様の効果をもたらします。重要なのは、モデルがより長く（より多くのトークンを）問題に取り組む時間を持つことで、より良い結果を得られる可能性が高まるという点です。
推論は、コードのデバッグに特に役立ちます。モデルに、複雑なコード経路を案内し、ツール呼び出しを混在させ、推論フェーズを用いて関数呼び出しを問題の潜在的な原因へと結びつける機会を与えます。
多くのコーディングエージェントには、推論の努力レベルを上げたり下げたりするオプションがあり、モデルが難しい問題に対してより長く取り組むよう促します。
LLM + システムプロンプト + ツールをループ
信じるか信じないかは別として、それがコーディングエージェントを構築するのにほぼ必要なものです！
これらの仕組みをより深く理解したい場合、実践的な課題としてゼロから自分のエージェントを作成してみるのが有益です。既存の LLM API の上に数十行のコードで実現できるシンプルなツールループです。
良いツールループはそれ以上に多くの作業を要しますが、基本的な仕組みは驚くほど簡単です。
これはガイド エージェント工学パターン の章です。
このガイドの章
- 原則
-
Getting started
- How coding agents work
- Testing and QA
- Understanding code
- Annotated prompts
- Appendix
作成日: 2026年3月16日
最終更新日: 2026年3月16日
7件の変更
前へ: アンチパターン：避けるべきもの
次へ: レッド/グリーンTDD
