コーディングエージェントの構成要素

2026年4月4日原文(magazine.sebastianraschka.com)

概要

コーディングエージェント と エージェントハーネス の全体設計を解説
LLM、 推論モデル、 エージェント の違いと関係性を説明
コーディングハーネス の主要6要素を具体例とともに紹介
エージェントハーネス がユーザー体験や能力に与える影響を強調
Mini Coding Agent による実装例とその特徴を解説

コーディングエージェントとエージェントハーネスの全体像

Claude Code や Codex CLI などは、LLMをアプリケーション層でラップした エージェント型コーディングツール
コーディングエージェントは、 モデル選択 だけでなく リポジトリ文脈、 ツール設計、 メモリ管理、 長時間セッション維持 など、周辺システム全体の設計が重要
LLMの「コーディング能力」は、モデル・推論挙動・エージェント製品の違いを理解することが重要
LLM は「次トークン生成」エンジン、 推論モデル は中間推論や自己検証に強化されたLLM、 エージェント は目標に応じてモデルとツール・状態管理・停止判断を制御するループ
エージェントハーネス はエージェントの外枠であり、 文脈管理 ・ ツール利用 ・ プロンプト構築 ・ 状態管理 ・ 制御フロー を担う

コーディングハーネスの特徴と重要性

コーディングハーネス は、ソフトウェア開発向けに最適化されたエージェントハーネス
Codex や Claude Code はコーディングハーネスの代表例
LLMや推論モデル単体でもコーディングは可能だが、 リポジトリ探索 ・ 関数検索 ・ テスト実行 ・ エラー解析 ・ 文脈保持 など、実務に必要な多くの作業をハーネスが補完
LLM性能が均質化する中、 ハーネス設計 がユーザー体験や実用性を大きく左右
ハーネス特化型ファインチューニング も有効であり、OpenAIのGPT-5.3とGPT-5.3-Codexのようなバリエーションも存在

コーディングエージェントの6つの主要コンポーネント

Mini Coding Agent （https://github.com/rasbt/mini-coding-agent）の実装例を基に解説
6大要素：
- リポジトリ文脈の取得 （WorkspaceContext）
- プロンプト構造とキャッシュ再利用 （build_prefix, memory_text, prompt）
- ツール設計・検証・権限管理 （build_tools, run_tool, validate_tool, approve, parse, path, tool_*）
- 文脈圧縮と出力管理 （clip, history_text）
- 会話記録・メモリ・再開 （SessionStore, record, note_tool, ask, reset）
- 委譲とサブエージェント管理 （tool_delegate）

1) リポジトリ文脈の取得

作業開始時 に リポジトリ情報 （ブランチ、README、AGENTS.mdなど）を収集
リポジトリの状態 や 進行中の変更 を把握し、的確なアクション選択を支援
ワークスペース要約 を作成し、ユーザーリクエストと組み合わせてモデルへ入力
安定した事実情報 を事前に収集することで、毎回ゼロから開始しない設計
Git情報 や プロジェクト構成 を活用した文脈強化

2) プロンプト構造とキャッシュ再利用

プロンプトの安定部分 （一般指示・ツール説明・ワークスペース要約）を キャッシュ し、毎回再構築を回避
セッション状態 （短期メモリ・直近会話・最新リクエスト）は都度更新
効率的なプロンプト合成 により、計算資源の無駄遣いを防止
変化しにくい部分 と 頻繁に変わる部分 を分離して管理
スマートランタイム によるプロンプト再利用の最適化

3) ツール設計・検証・権限管理

ツールアクセス により、単なるチャットから 実行型エージェント へ昇華
許可されたツール一覧 を定義し、 入力検証 や 権限確認 を自動化
モデルが出力するアクション をハーネスが認識・検証・実行し、結果をループへ返却
ユーザー承認 や ワークスペース外アクセス制限 などの安全対策
実行結果のフィードバック によるインタラクティブな問題解決

エージェントハーネスがもたらす体験の違い

ハーネス層 がユーザー体験の大半を決定
直接プロンプト や WebチャットUI との違いは、 文脈管理 や ツール統合 の有無
同等性能のLLM でも、ハーネス次第で実用性や快適さに大きな差
ハーネス固有のファインチューニング や 後処理 による追加強化
GLM-5 のような最新LLMも、優れたハーネスで GPT-5.4 や Claude Opus 4.6 に匹敵する可能性

まとめ

コーディングエージェント は、単なるモデルではなく エージェントループ と ハーネス の組み合わせ
6大コンポーネント の設計が、実践的なコーディング支援の鍵
ハーネス技術 が今後のLLM活用・差別化の主戦場
Mini Coding Agent のような実装例を参考に、独自のエージェント開発も可能
モデルの能力 と ハーネス設計 の両輪で、より強力なコーディング支援環境を実現

Hackerたちの意見

LLMをシンプルなステートマシンで囲んで、bashにアクセスさせることで解き放たれた力には、まだまだ驚かされるよね。

└

道具が人間に他の動物に対する優位性を与えたんだ。

└

残念ながら、エージェントCLIを作ってる人たちは、bashにアクセスさせるだけじゃ足りないって決めちゃったみたい。代わりに、想像できるあらゆる機能をJavaScriptの「TUI」に詰め込む必要があるって。

└

本質的にはプロンプトやコンテキストのエンジニアリングだよね。モデルには多くの知識が詰まっているけど、それをどう引き出して（半自律エージェントにとって実行可能にするか）... コンテキストを作って生成を導き、状態を維持する（ステートレスなLLMとやり取りしながら）必要があるし、スキルやツールを（コンテキストの一部として）提供して、モデルの出力をツールコールに「絞り込む」必要がある。半素朴なユーザーのリクエストを、シニア開発者が実行するためのステップに翻訳することがもっとできると思う。必要なツールも含めてね。著者が、最高のオープンソースモデルが最高のクローズドソースモデルと競えるかもしれないと考えているのは面白い。最適化されたエージェントと少しのファインチューニングがあれば、十分かもしれない。結局、SOTAモデルに匹敵することが目標じゃなくて、能力のある人間レベルに近づくことが重要なんだと思う。固定された基準で、動くものじゃない。エージェントがユーザーのリクエストや意図を実行ステップに翻訳・補強することで、モデルが一発でできることの基準を下げる可能性は確かにありそうだね。

└

だから、今は自分のシンプルで隔離されたコーディングエージェントを作ろうとしているんだ。膨張はすでに怖いけど、悪い決定がみんなを震えさせるはず。10年前は、責任を持って使う必要があるような多面的なものについて、みんなが延々と文句を言ってたのに、今はみんなパニックかハイプモードで、混沌としたタイムラインの中で何とか relevance を保とうとして、良いアドバイスを無視しているように見える。

└

クロードコードのリークを見たことがあれば、ハーネスが単純じゃないことが分かるよ。広がりのある迷路のようなごちゃごちゃだけど、LLMをある程度決定論的で役に立つ道具にするためには必要なんだ。

└

bashをpythonに置き換える方が便利だと思った…そうすれば、無限にガムをつなげる必要なく、好きなものを作れるからね。

これは推測だけど、もし最新の高性能なオープンウェイトLLM、例えばGLM-5を似たようなハーネスに入れたら、CodexのGPT-5.4やClaude CodeのClaude Opus 4.6と同等のパフォーマンスを発揮できるんじゃないかと思う。ここで説明されていることを誤解していなければ、異なるバックエンドモデルでClaude Codeを動かすのは結構一般的だよ。 https://docs.z.ai/scenario-example/develop-tools/claude 私の経験では、Anthropicのモデルと同等のパフォーマンスは出ないけどね。

└

私の経験では、Anthropicのモデルと同等のパフォーマンスは出ないけどね。どうしてそう思う？Anthropicのモデルが単に優れているのか、それともハーネスとより良く連携するようにトレーニングされているのかな？

└

いくつかのプロジェクトでは、OpenCodeのSonnet 4.6でできることの70〜80%が、MiMo V2 Proみたいな安いモデルでもできることが分かったよ。他のプロジェクトではSonnetが完全に優れてる。なんでかはよく分からないけど。Opusが追加コストに見合う価値があるのは、せいぜい5%の時だけだと思う。OpenCodeはClaude Codeよりも圧倒的に良いと思う。だから、Claude MaxよりもOpenRouter APIクレジットを買ってる。Claude Codeは全然良くないからね。OpenCodeがカスタムコマンドをいくつか使ってできることには正直驚いてる（品質レビューみたいな一般的なことのためにね）。多くのプロジェクトでは、これらの機能のほとんどが必要ないことも多い。たいていは、AGENTS.mdを作成して、良い開発ワークフロー、gitのブランチ/コミットポリシー、テストと品質基準、ROADMAP.md、マイルストーンごとのマークダウンファイルにフェーズとタスクトラッキングをまとめるように頼むだけで十分なんだ。もっと自動化したり強制したりするハーネスには興味があるけど、今持ってるもの以上のものを得られるかは分からないし、特定のものと比べて最新の技術に追いつくのは難しいと思う。

長いコンテキストはまだ高価で、追加のノイズを引き起こすこともある（関係ない情報が多いと）。この理由から、仕様駆動の生成はチャットスタイルのコーディングの対極だと思う。Claude Codeのようなツールを使うと、何がすでに作られたか、どんなインターフェースが存在するか、なぜ何かが特定の方法で生成されたのかを自分で追跡することになる。私はOssatureをその逆のモデルで作ったんだ。行動を説明する仕様を書いて、それをコードを書く前にギャップや矛盾を監査して、各タスクが必要とする仕様のセクションや上流ファイルを正確に宣言するビルドプランのtomlを生成する。LLMはそれ以上のものを見ないし、会話の履歴が蓄積されることもない。すべてのプロンプトとレスポンスはディスクに保存されるから、トレース可能性が組み込まれていて、チャットをスクロールして再構築する必要がない。最近、仕様だけからCHIP-8エミュレーターを作るのに使ったよ。GitHubに他のプロジェクトもいくつかあるよ。1: https://github.com/ossature/ossature 2: https://github.com/beshrkayali/chomp8 3: https://github.com/ossature/ossature-examples

└

すごくいいと思う！チャット駆動のワークフローは疲れるし、情報が翻訳の過程で失われちゃうことが多い。LLMが役に立たなくなるまでね。人間の介入はどうなってるの？仕様書と監査編集を混ぜて、生成準備状態に持っていく感じ？タスクからコードを生成する場合の成功率やエラー率はどれくらい？LLMは物事を忘れたり、間違えたりするのか、それとももっと良い感じになるのかな？仕様書駆動のアプローチは、ゼロから書くのには良さそうだけど、既存のコードに関しては何か計画ある？

Hacker Newsで議論の続きを見る

ハクソク