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

51日前原文(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は物事を忘れたり、間違えたりするのか、それとももっと良い感じになるのかな？仕様書駆動のアプローチは、ゼロから書くのには良さそうだけど、既存のコードに関しては何か計画ある？

└

これ、めっちゃ良さそう！試してみるためにブックマークしたよ。@構文を使ったカスタムマークダウン形式を選んだ理由って何かある？frontmatterみたいなものを使わなかったのは意識的なのかな？これだとGitHubとかでマークダウンのレンダリングができなくなるし。

└

ねえ、君も似たような考えを持ってるみたいだね。アイデアは安いって分かってるけど、聞いてほしい。エージェントAと話すと、その仕様書だけを修正するんだ。まだチャットできて「もっと綺麗にして」って言えるけど、そのエージェントは仕様書だけを修正する。仕様書は「明示的」と「推測的」を分けることもできるしね。もちろん、エージェントBはその仕様書しか見ない。ユーザーはエージェントAが生成した差分に再び気を使うことができる。誰も繰り返しだらけで検索と置換で作られたエージェントのコードの差分を確認したくないからね。これをうまく実装する人がいれば、業界のやり方が変わると思う。もちろん、より良いモデルがあれば、仕様書を使って製品を実際に意味のある形で改善できる。要するに、今の業界が欠けているのは、意図が神聖であるべきだってこと。常に保存されるべきで、できればそのままの形で、関連するコンテキストと一緒にね（「そう、まさにそれ」じゃ足りない）。今のLLMの世代はそれをすでに処理できる。コストは2〜3倍になるかもしれないけど、それだけの価値があると思うし（長期的には1倍以下に抑えられる可能性もある）、典型的なワークフローや繰り返しを考えるとね。

└

最近これについてよく考えてるんだ。ほとんどのコーディングエージェントに欠けてるのは、中央の真実のソースみたいだね。会社が何を作っているのか、整合性が分散する前は、人々は自分たちが何をしていて、他の人が何をしているのかのコンテキストを持っていた。今はコーディングエージェントが毎回ゼロから始まって、何を頼んだのか理解してフィードバックループを提供するのは自分次第。チャットからコードへではなく、チャットから仕様へ、そして仕様からコードへが未来だと思う。仕様からコードのフェーズは人間から独立しているべきだよ。仕様が不明瞭なら、人間に仕様を明確にしてもらって、それを使ってコードを生成する。今は何かが不明瞭で、エージェントが広い理解を得ようとするループがあるけど、その理解は次のチャットで失われちゃう。そして人間も自分のリクエストがなぜ不明瞭だったのか学ばない。「記憶」やエージェントファイルはこの問題に対する応急処置みたいなものだね。

└

これが基本的にAugment Intentだよ。

└

いいけど、テキストだけじゃダメだね。

└

完全に同意！Cucumberでclaude codeを使うのがうまくいってるよ。仕様から始めて、claudeにコードを反復させる感じ。ossatureはそのアプローチと比べてどうなの？

└

これ、めっちゃ面白いし、私の開発スタイルとも合ってる！ollamaをサポートしてるみたいだけど、ローカルモデルで効果的だったことある？Gemma 4とか？絶対試してみるつもり！

└

これってSuperpowersとどう違うの？

この例はすごくシンプルでわかりやすいね。俺はコーディングエージェントは使わないけど、これはいい概要だと思う。コーディングエージェントは洗練された結果を出すかもしれないけど、実際のやり取りは全然魔法みたいじゃないってことが分かるはず。あと、1,000行のコードコンポーネントを500,000行のごちゃごちゃに変えられるっていう良い例でもあるね。

ハーネスよりもいい言葉はないの？生の力を導いて制約するというメタファーは理解できるけど、あんまり好きじゃないな。

└

何が心配なの？ハーネスは「他のプログラムを管理するシムプログラム」という文脈でかなり一般的だよね（例:「テストハーネス」、「ファジングハーネス」など）。

これは推測だけど、もし最新の高性能オープンウェイトLLM、例えばGLM-5を同じような環境に投入したら、CodexのGPT-5.4やClaude CodeのClaude Opus 4.6と同じくらいのパフォーマンスを発揮できるんじゃないかな。もう1年以上前からみんなやってるし？GLMは公式にClaude Codeに接続することを推奨してるよ。https://docs.z.ai/devpack/tool/claude どんなモデルでもCodex CLIに接続できるし（オープンソースで、設定ファイルで設定できる）。

└

それはOpusレベルではないけど、めっちゃ良いよ。個人プロジェクトではほぼ専らこれ（とqwen3.5-plus）を使ってる。

いい記事だね！エンジンと車のアナロジーはずっと使ってるよ。コーディングエージェントの基本的なビルディングブロックで遊びたいなら、ここをチェックしてみて。https://github.com/OpenHands/software-agent-sdk

ツールの出力を切り詰めるのはすごく助かるし、コンテキストの膨張を減らすための最良の方法の一つだよ。私のコーディングエージェントでは、コンテキストはSQLiteから組み立てられてる。メッセージIDを付けて、必要に応じて切り詰めたツールコールを再生成してるけど、これがうまくいってる。コンテキスト管理に関する私の探求は、ここにほとんど記録されてるよ。https://github.com/hsaliak/std_slop/blob/main/docs/CONTEXT_M...

この書き込み、めっちゃ良かった！クライアントのために特定のニッチな用途向けのエージェントを作ったんだけど（コーディングエージェントじゃないよ）、原則は似てるんだ。今のところ1から4までしか実装してないけど、次は長期記憶に取り組む予定。ただ、LLMに自分のメモを書かせるときのプロンプトインジェクションの問題が心配なんだよね。うちのエージェントはメールで動いてるから、コアエージェントループは一通のメッセージを処理してから、send_replyツールを使って返事を作るんだ。次のメールが来ると、また最初からループが始まる感じで、実際にユーザーとエージェントの間で送られた返信だけを注入してる。これで自然にコンテキストが整理されて、長いコンテキストウィンドウの問題を防いでるんだよね。初期プロンプトに何を注入するか、ツールに何を入れるかを決めるのも難しかった。コンテキストの膨張とツールのルックアップコストのトレードオフがあって、トークンごとにお金がかかるからね。キャッシュのことも考えないといけないし。興味がある人は、こちらに詳しい書き込みがあるよ：https://www.healthsharetech.com/blog/building-alice-an-empow...

コンパウンディングが多分分岐点だね。一つのエージェントの出力が別のエージェントの入力になるけど、ゴミが入ればゴミが出るってルールは当てはまるのかな？

ハクソク