How coding agents work｜コーディングエージェントの仕組み

*[Agentic Engineering Patterns](https://simonwillison.net/guides/agentic-engineering-patterns/) >* どのようなツールと同様に、[コーディングエージェント](https://simonwillison.net/guides/agentic-engineering-patterns/what-is-agentic-engineering/) が内部でどのように動作するかを理解することは、それらをどのように適用するかについてより良い意思決定を下すのに役立ちます。 コーディングエージェントとは、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](https://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 のシステムプロンプト](https://github.com/openai/codex/blob/rust-v0.114.0/codex-rs/core/templates/model_instructions/gpt-5.2-codex_instructions_template.md) は、これらのコーディングエージェントを機能させるための指示の種類の有用で明確な例となっています。 ## 推論（Reasoning） 2025 年の大きな新進歩の一つは、最先端モデルファミリーに**推論（reasoning）**が導入されたことです。 推論は、ユーザーへの回答を提示する前に問題とその潜在的な解決策について説明するテキストを生成するためにモデルが追加の時間を費やすプロセスであり、UI では**思考（thinking）**として表示されることもあります。 これは人が声に出して考える様子に似ており、同様の効果をもたらします。重要なのは、より良い結果を得ることを目指して、モデルが問題に取り組むためにより多くの時間とトークンを割けるようになる点です。 推論は特にコード内のデバッグにおいて有用です。これにより、モデルは複雑なコードパスをナビゲートする機会を得られ、ツール呼び出しを組み合わせながら、推論フェーズを使用して関数呼び出しを追跡し、問題の潜在的な発生源へと辿り着くことができます。 多くのコーディングエージェントには、推論の努力レベルを上げたり下げたりするオプションが含まれており、モデルがより難しい問題を咀嚼するために時間を費やすよう促しています。 ## LLM + システムプロンプト + ツールのループ 信じられないかもしれませんが、これがコーディングエージェントを構築するために必要なことのほとんどです！ これらの仕組みをより深く理解したいのであれば、自分自身でエージェントをゼロから構築してみるという有用な演習があります。既存の LLM API を基盤にすれば、数行程度のコードでシンプルなツールループを実現できます。 しかし、*良い*ツールループを実現するには、それよりもはるかに多くの労力が必要ですが、その根本的なメカニズムは驚くほど単純です。 Tags: [coding-agents](https://simonwillison.net/tags/coding-agents), [generative-ai](https://simonwillison.net/tags/generative-ai), [agentic-engineering](https://simonwillison.net/tags/agentic-engineering), [ai](https://simonwillison.net/tags/ai), [llms](https://simonwillison.net/tags/llms)

コーディングエージェントの仕組み

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト