コーディングエージェントの構成要素
(magazine.sebastianraschka.com)- コーディングエージェントは、LLMを中心にコードの作成・実行・フィードバックを繰り返し行う制御ループとソフトウェアハーネスで構成されたシステム
- エージェントハーネスはコンテキスト管理、ツールアクセス、プロンプト構成、状態制御を担い、コーディング作業に特化したコーディングハーネスはリポジトリ・テスト・エラーチェックを管理
- コーディングエージェントは、リアルタイムなリポジトリコンテキスト、プロンプトキャッシュ、ツールアクセス、コンテキスト管理、セッションメモリ、サブエージェント委任の6つの構成要素で動作
- ハーネス設計の品質によって、同じLLMでも性能とユーザー体験が大きく変わり、適切に設計されたハーネスは継続的でコンテキスト認識的な開発環境を提供
- Mini Coding Agentは、この構造を純粋なPythonで実装した最小例であり、OpenClawとはコーディング特化かどうかと運用範囲で違いがある
コーディングエージェントの構成要素
- コーディングエージェントは、LLMを中心とした制御ループと、それを包むソフトウェアハーネス(harness) から成るシステムで、コードの作成・修正・実行・フィードバックを反復する構造
- LLMは基本的な次トークン予測モデルであり、推論モデル(reasoning model) は中間推論や検証をより多く行うよう訓練されたLLM
- エージェントは、目標達成のためにモデル呼び出し、ツール使用、状態更新、終了判断などを繰り返す制御ループ
- エージェントハーネス(agent harness) は、このループを包むソフトウェア構造で、コンテキスト管理、ツールアクセス、プロンプト構成、状態制御などを担当
- コーディングハーネス(coding harness) はコード作業に特化した形で、リポジトリコンテキスト、コード実行、テスト、エラーチェックなどを管理
LLM、推論モデル、エージェントの関係
- LLMはエンジン、推論モデルは強化されたエンジン、エージェントハーネスはそのエンジンを制御するシステムとたとえられる
- LLMと推論モデルは単独でもコーディング作業を行えるが、実際の開発環境ではリポジトリ探索、関数検索、テスト実行、エラー分析など、複合的なコンテキスト管理が必要
- コーディングハーネスはモデルの性能を最大化し、単純なチャット型インターフェースよりはるかに強力なコーディング体験を提供
コーディングハーネスの役割
- モデルを包むソフトウェア層として、プロンプト組み立て、ツール公開、ファイル状態追跡、コマンド実行、権限管理、キャッシュ、メモリ保存などを実行
- 同じLLMでも、ハーネス設計によって性能とユーザー体験が大きく変わる
- たとえば、GLM-5のようなオープンウェイトモデルでも、CodexやClaude Code級のハーネスに統合されれば同等の性能を出せる可能性がある
- OpenAIには、GPT-5.3とGPT-5.3-Codexのように、ハーネス別の後処理モデルを別個に維持した事例がある
コーディングエージェントの6つの中核構成要素
-
1. リアルタイムなリポジトリコンテキスト (Live Repo Context)
- エージェントは現在のGitリポジトリの状態、ブランチ、ドキュメント、テストコマンドなどを認識している必要がある
- 「テストを修正」といった指示はリポジトリ構造や文脈によって変わるため、作業前にリポジトリ要約情報を収集する
- これにより、毎回ゼロ状態から始めるのではなく、安定した作業基盤(stable facts) を確保する
-
2. プロンプト構造とキャッシュ再利用 (Prompt Shape and Cache Reuse)
- リポジトリ要約、ツール説明、一般指示などは頻繁には変わらないため、「安定したプロンプトプレフィックス(stable prompt prefix)」 としてキャッシュする
- リクエストごとにプロンプト全体を組み直すのではなく、変更された部分だけを更新する
- 反復セッションで計算の無駄を減らし、応答の一貫性を維持する
-
3. ツールアクセスと利用 (Tool Access and Use)
- モデルが単にコマンドを提案するだけでなく、ハーネスが定義したツールセットを通じて実際にコマンドを実行できる
- 各ツールは明確な入出力形式と境界を持ち、実行前に妥当性検証と承認手順を行う
- 例: 「既知のツールか?」「引数は妥当か?」「作業パスはワークスペース内か?」などの検証
- これによりセキュリティと信頼性が向上し、モデルの自由度は下がるが実用性は高まる
-
4. コンテキスト肥大化の最小化 (Minimizing Context Bloat)
- 長いセッションでは、繰り返しのファイル読み込み、ログ、ツール出力などによりプロンプト長超過の問題が発生する
- ハーネスはこれを2つの戦略で管理する
- クリッピング(clipping): 長いテキスト、ログ、メモを一定の長さに短縮
- 要約(summarization): 古い会話履歴を圧縮要約
- 最近のイベントは詳細に保持し、古い情報は重複除去と圧縮を行う
- 結果として、モデル品質よりもコンテキスト品質の方が実際の性能に大きく影響する
-
5. 構造化されたセッションメモリ (Structured Session Memory)
- エージェントは状態を作業メモリ(working memory) と 完全な会話記録(full transcript) に分離する
- 完全な記録には、すべてのリクエスト・応答・ツール出力が含まれ、セッション再開が可能
- 作業メモリには、現在重要な情報(現在の作業、主要ファイル、最近のメモなど)を要約して保存する
- 圧縮された会話記録(compact transcript) はモデルプロンプト再構成用、作業メモリは作業の継続性維持用
-
6. 境界付きサブエージェントによる委任 (Delegation With Bounded Subagents)
- メインエージェントは補助作業を並列処理するためにサブエージェント(subagent) を生成する
- 例: 特定シンボルの定義位置、設定ファイルの内容、テスト失敗の原因などを別のサブタスクとして分離
- サブエージェントは必要なコンテキストだけを継承し、読み取り専用・再帰深度制限などで制約される
- Claude CodeとCodexはいずれもサブエージェントをサポートしており、作業範囲とコンテキスト深度で境界を設定する
構成要素の要約
- 6つの構成要素は互いに密接につながっており、ハーネス設計の品質がモデル活用効率を左右する
- 適切に設計されたコーディングハーネスは、単なるLLMチャットよりもはるかにコンテキスト認識的で継続的な開発支援環境を提供する
- Mini Coding Agent(https://github.com/rasbt/mini-coding-agent) は、この構造を純粋なPythonで実装した最小例
OpenClawとの比較
- OpenClawは、コーディング専用アシスタントというより汎用エージェントプラットフォームに近い
- 共通点:
- ワークスペース内のプロンプト・指示ファイル(AGENTS.md, TOOLS.mdなど) を使用
- JSONLセッションファイル、会話圧縮、セッション管理機能を含む
- 補助セッションおよびサブエージェントの生成が可能
- 相違点:
- コーディングエージェントはリポジトリ探索・コード編集・ローカルツール実行に最適化されている
- OpenClawは複数チャネル・複数ワークスペース間での長期的なエージェント運用に重点を置く
付録: 新刊のお知らせ
- Build A Reasoning Model (From Scratch) の執筆は完了し、現在Early Access版を公開中
- 出版社は夏の刊行を目標にレイアウト作業を進めている
- 本書はLLMの推論メカニズムを自ら実装しながら理解するアプローチを中心に構成されている
1件のコメント
Hacker Newsのコメント
長いcontextは依然として高コストで、不要な情報が多いとノイズが生まれる
だから私は、対話型コーディングよりspecベース生成のほうが優れていると考えている
私が作ったOssatureは逆方向のアプローチだ。まず動作を記述するspecを書き、コード生成の前に欠落や矛盾を監査し、各作業がどのspecセクションとファイルを参照するかを明示したbuild plan TOMLを生成する
LLMは必要な部分だけを見て、会話履歴の蓄積がない。すべてのプロンプトと応答はディスクに保存されるので、トレーサビリティが自動的に確保される
最近ではこの方式でCHIP-8エミュレータを完全にspecだけで作り、サンプルプロジェクト群もある
以前はチーム全員が何を作っているかを把握していたが、今はエージェントが毎回ゼロから始めている
だから私は、chat → spec → code の流れが未来だと思う。spec → code の段階は人間の介入なしで回るべきだ
仕様が曖昧なら人間に明確に質問し、それを基にコード生成すべきだ
今は曖昧な要求が繰り返され、人間もなぜそうなるのか学べていない。“memory”やagentファイルはその場しのぎにすぎない
会話の代わりに、コードとspecから投影したcontextをLLMに渡し、段階ごとに異なるcontextを構成している
蓄積contextによるdriftを防ぎ、LLMではなく自分のコードがワークフローを制御する
TOMLを段階間で受け渡すartifactとして使うアイデアが面白いので参考にしたい
ユーザーはAgent Aが作ったdiffを確認すればよく、反復的なコード検証から解放される
重要なのは**意図(intent)**を常に保持することだ。仕様と文脈をそのまま保存しなければならない
コストは2〜3倍かかるだろうが、長期的にはそのほうが効率的だと思う
specベースのアプローチのほうがはるかに良いと思う。人がどう介在するのか気になる — specとauditの編集を並行するのか、コード生成の成功率はどうか、既存コードにも適用する予定があるのか知りたい
Ossatureがそのアプローチとどう違うのか気になる
単純なstate machineとbashアプローチだけでLLMの潜在力を引き出したのは驚きだ
今のエージェントエコシステムは過剰な機能と悪い判断で満ちている
10年前ならこうしたツールには責任感が必要だと言われていたが、今は恐怖と誇大宣伝が入り混じる混乱した時代だ
モデルは知識をすでに持っているが、それを実際の行動へ導くにはcontext設計が重要になる
ユーザーの要求を熟練開発者レベルの手順に翻訳し、必要なツールを接続するやり方が有望だ
オープンソースモデルでも、よく最適化されたエージェントと少しのチューニングで十分競争できると思う
複雑なハーネスが必要だが、そのおかげでLLMがツールとして決定論的に動作する
パイプラインの代わりに自由に望むロジックを組める
例が簡潔で明快だ
コーディングエージェントは使っていないが、この記事はコーディングエージェントの本質を理解するのに役立つ
わずか1k LOCの有用なコードでさえ、500k LOCの混乱に変わりうることをよく示している
すでに多くの人がGLM-5のようなオープンモデルをClaude CodeやCodex CLIにつないで使っている
GLM公式ドキュメントでもそれが推奨されている
記事は印象的だった。私はメールベースの非コーディングエージェントを作ったが、原理は似ている
各メールループごとにcontextを新しく開始することで、context蓄積問題を自然に解決している
初期プロンプトに入れるcontextとツール側に分けるcontextのバランスが重要だ
キャッシュとトークンコストも考える必要がある
詳細は私のブログ記事にまとめてある
“harness”という言葉が気に入らない。もっと良い表現はないかと思う
tool output truncationはcontextの膨張を減らすのに非常に効果的だ
私はSQLiteベースでcontextを組み立て、必要に応じてメッセージIDで切り詰められたツール呼び出しを復元している
関連する実験はドキュメントにまとめてある
Claude Codeを別のモデルで動かすのは珍しくない
例のドキュメントにも載っている
だが私の経験ではAnthropicモデルの水準には届かない
Opusがコストに見合うケースは5%程度しかない
私はOpenCodeがClaude Codeよりはるかに良いと感じて、OpenRouter APIクレジットを購入した
OpenCodeはカスタムコマンドと簡単なagent定義だけでも十分強力だ
AGENTS.md、ROADMAP.mdなどでワークフローを定義すれば、ほとんどのプロジェクトには十分だ
複雑なハーネスよりも柔軟な構造のほうが最新モデルの変化にうまく対応できると思う
コーディングエージェントの進歩は、モデル自体よりも周辺構造(scaffolding)の改善から来ている部分が大きい
ツール、リポジトリcontext、簡単な状態機械がそろうと、ボトルネックはcontext品質へと移る
記事は強烈だった。私もコーディングエージェントをエンジン/自動車の比喩で説明することがある
基本構成要素を試したいなら、OpenHands software-agent-sdkが参考になる