エージェントスキャフォールドとは、コーディングエージェントにおいて言語モデルを取り巻く足場（スキャフォールディング）のコードである。 すなわち、制御ループ、ツール定義、状態管理、コンテキスト戦略である。 スキャフォールドの内側：コーディングエージェントアーキテクチャのソースコードレベルの分類体系 は、エージェントが研究用プロトタイプから本番用ツールへと移行するにつれて、 このコードがエージェントの振る舞い、犯す誤り、トークン予算の使いどころをますます左右するようになっていると論じる。 それにもかかわらず、このコードは研究文献ではほとんど理解されていない。概念的なサーベイは、ある本番システムを別の 本番システムと区別する実装戦略によってではなく、抽象的な能力によってエージェントを分類しているからだという。
用法
同論文の分類体系は、13 のオープンソースエージェントのソースコード分析から導かれたもので、スキャフォールドの 設計を 3 つの層に整理している。
制御アーキテクチャ — エージェントが次に何をするかをどう決めるか。これには制御ループのトポロジーが含まれ、 同論文はこれを、フィードバックループを持たない固定パイプラインから、ユーザー駆動のループ、逐次的な ReAct ループ、 フェーズ分けされたループを経て、深さ優先の木探索、完全なモンテカルロ木探索に至るスペクトラム上に位置づけている。 また、ループの駆動主体、すなわち次に何が起こるかをユーザー、スキャフォールド、モデルのいずれが決めるかも含まれる。 さらに、ループを実装するコードレベルの仕組みも含まれ、それは命令型の while ループ、再帰、コンパイルされた状態機械、 あるいは例外によるシグナル伝達でありうる。
ツールと環境のインターフェース — エージェントがコードや実行環境とどうやり取りするか。これには、ツールセットと ツールをモデルに伝える方法、編集とパッチの形式、ツールを起動時に静的に登録するか動的に発見するか、 コンテキスト取得のパラダイム（モデル主導のツール呼び出し、事前計算されたインデックス、埋め込み検索、または静的な リポジトリマップ）、そしてエージェントとホストの間の信頼境界を記録する実行隔離モデルが含まれる。
リソース管理 — エージェントがコンテキスト、状態、モデルをどう管理するか。これには、状態管理戦略（履歴を保持する データ構造と、それが追記専用か変更可能か）、コンテキストのコンパクション手法、マルチモデルのルーティング、 セッションをまたぐ永続的メモリが含まれる。
同論文は、これらの次元は連続的なスペクトラムとして扱うのが最善だと論じ、さらに 5 つの ループプリミティブ（ReAct、generate-test-repair、plan-execute、複数回試行のリトライ、木探索）が、 エージェントが重ねたり入れ子にしたりする合成可能な構成要素として働くため、ありうるスキャフォールドの空間は カテゴリー的ではなく組み合わせ的であると主張する。
11 の本番コーディングエージェントを対象とした別のソースコード研究である ハーネスエンジニアリング：コーディングエージェントの解剖、アーキテクチャ、進化 ― 11 システムのソースコード研究 は、 「スキャフォールド」と エージェントハーネス の関係を取り上げ、両者を実務上はほぼ同義語だとしている。 区別が有用な場合には、「スキャフォールド」をループやレジストリといった構造的なコードに、「ハーネス」をそれを組み込んだ 出荷されるランタイム成果物に充てる。その例として、Mini-SWE-Agent のスキャフォールドは 100 行の Python である一方、 Claude Code のハーネスはターミナル UI、パーミッションシステム、プラグインエコシステムを備えた製品である、と挙げている。 この研究は Inside the Scaffold を方法論的に最も近い先行研究として挙げ、同論文の 12 の次元を自らの 7 つのハーネス サブシステムに対応づけ、自らの語彙よりも鋭いと判断した箇所ではループプリミティブの語彙を採用している。また、 本番のループの大半は 1 つのプリミティブを実装するのではなく複数のプリミティブを合成しているという観察についても 同論文に依拠しており、自らが調査したプロバイダーネイティブな 4 つのエージェントが現在搭載しているプランモードを、 ReAct に plan-execute を接ぎ木したものとして読んでいる。
適用される場面
- モデルの外でなされるあらゆる設計判断に当てはまる。どのツールをどの粒度で公開するか、履歴をどう表現するか、 いつ圧縮するか、コードをどこで実行するか、どのステップをどのモデルが担当するか、といった判断である。同論文の 捉え方では、同じ基盤モデルでもこれらの選択次第で振る舞いが変わるため、これらの選択は単にモデルの能力を支える のではなく、それを媒介するものである。
- スキャフォールドとモデルを切り離して論じられることを前提とする。同論文は、この前提が実際にはしばしば破られることを 明言している。同論文がコーパス内のエージェントのベンチマーク評価を行わないのは、ベンチマークのスコアが スキャフォールドのアーキテクチャを、モデルの能力、プロンプトエンジニアリング、そして反復回数の上限やコスト上限の ような付随的な設定と混同してしまうからである。
- 単一のラベルに還元されると、分析の枠組みとしては機能しなくなる。同論文の主張によれば、複数のプリミティブを重ねた システムに 1 つの名前（「ReAct エージェント」「パイプラインエージェント」）を与えると、そのシステムを実際に 差別化している判断が見えなくなり、そうしたラベルを比較する研究は、ループのトポロジー、ループの駆動主体、 ツールセットの設計、コンテキスト管理を 1 つの二値に混同してしまう。
- 一様に決着しているわけではない。同論文は、外的制約が支配的で実務家が共通の答えに到達した、収束した次元と、 支配的な解決策が現れていないために分岐したままの次元とを区別し、後者のグループとしてコンテキストのコンパクション、 状態管理、マルチモデルのルーティングを挙げている。
- 根拠は、当初の 22 の候補から網羅的でない方法で選ばれた 13 のエージェントを対象とする、研究者 1 名による定性的な 事例研究であり、すべての主張は固定されたコミットにおけるファイルパスと行番号に紐づけられている。その知見は、 2026 年初頭時点で調査されたオープンソースのコーパスを記述するものであり、スキャフォールドのコードを検査できない プロプライエタリなエージェントは、構造上対象から除外されている。