注記: 本記事の調査（各手法や関連研究の裏取り）には、Claude と、そのリサーチ機能を利用しています。
はじめに
前回の記事で、LLMはほぼチューリングマシンである、という見方を整理しました。要点はこうでした。順伝播は状態を持たない純粋関数で、これがチューリングマシンの遷移関数 δ に当たる。コンテキストがテープに当たる。そして δ（重み）は固定で利用者には触れないので、動かせる変数はテープの中身だけ。だから「良いテープを作る」ことが使いこなしの本体だ、という話でした。
ここで自然に次の問いが出てきます。その「良いテープ」は、誰が作るのか。人間が手で組むのか、それとも自動で組んでくれる仕組みがあるのか。
後者を担うのが、本記事のテーマである「ハーネス」です。ここで言うハーネスとは、Claude Code、OpenCode、cline、aider、Cursor、OpenHands といった、モデルの外側でコンテキストを組み立て・実行・検証・修正してループを回す、エージェント型のコーディングツールを指します。ひとことで言えば、ハーネスは「テープを自動で育てる機械」です。
前回が「テープを手で作る話」だったとすれば、今回は「テープを自動で作らせる話」になります。なお、各ツールはこの一年で機能が激しく動いているので、細部は必ず公式ドキュメントで確認してください。本記事は2026年前半時点の情報をもとにしています。
ハーネスとは何か ─ テープの読み書きを成立させる実行環境
チューリングマシンの図をもう一度思い出します。遷移関数 δ は状態を持たず、テープを読み、テープに書き、ヘッドを動かす。この「テープを読み書きしてヘッドを進める」部分を、実機のLLM単体は持っていません。LLMは、与えられたテープ（コンテキスト）を一度読んで次のトークンを返すだけです。
そこを外側から補うのがハーネスです。ハーネスは、固定されたモデル（δ）を取り囲み、テープを組み立ててモデルに投入し、返ってきた出力に応じてツールを動かし、その結果をテープに書き戻し、また投入する。
ただし、ハーネスをチューリングマシンの「ヘッド」そのものと言い切るのは、やや雑すぎます。ハーネスは、コンテキストを作り、ファイルを読み書きし、shell を実行し、テストや LSP、grep を呼び、MCP で外部システムに接続し、権限管理や承認を行い、ログやセッション状態を保持します。単なる読み書きヘッドというより、モデルを何度も呼び出し、外部記憶・外部ツール・検証器を接続して、テープの読み書きループを成立させる実行環境、と捉えるのが正確です。Claude Code の公式説明も「コードベースを読み、ファイルを編集し、コマンドを実行し、開発ツールと統合するエージェント型コーディングツール」で、単なるコンテキスト投入器ではなく実行環境込みの仕組みだ、という位置づけになっています。
SystemVerilog で検証をやっている立場だと、この構図はUVMのテストベンチにそのまま重なります。DUT（被検証対象）に相当するのがモデルで、それを取り囲むテストベンチ一式がハーネスです。対応させるとこうなります。
| チューリングマシン | UVMテストベンチ | コーディングハーネス |
|---|---|---|
| 遷移関数 δ | DUT | LLM（固定の重み） |
| テープ | スティミュラスと観測の系列 | コンテキスト |
| ヘッドの読み書き | ドライバ / モニタ | テープの投入と出力の取り込み |
| （外部からの駆動） | シーケンサ / シーケンス | プランナ・タスク分解 |
| （TMは停止するだけ） | スコアボード / チェッカ | 検証（compile / test / lint） |
| テープ更新のループ | 印加 → 応答 → 判定 → 次 | 出力 → ツール実行 → 検証 → 追記 |
この対応は視点によって変わる、という点は補足しておきます。LLMを一個の部品として外から駆動する視点ならモデルが DUT ですが、ソフトウェア開発というタスクとして見ると、DUT はむしろ編集対象のコードベースや生成された成果物のほうです。その見方では、LLM はスティミュラス生成器、ハーネスはドライバ／モニタ／スコアボード、そして compiler / test / lint がチェッカに当たります。検証をやっている読者には、こちらの対応のほうがしっくり来るかもしれません。
もう一点、素のチューリングマシンと判定の関係も正確にしておきます。TM には accept / reject 状態を持つ判定器としての使い方もあるので、「ただ計算して止まるだけ」は少し雑でした。正しくは、TM 自体は与えられた遷移規則に従って計算するだけで、問題設定や仕様の妥当性までは内包しない、ということです。出力が「正しい」かどうかは、外に置かれた仕様・テスト・判定基準との対応で決まります。ハーネスはそこにスコアボード（テストやコンパイラ）を持ち込み、正誤の判定結果をテープに書き戻す。UVMのテストベンチがDUTに判定を与えるのと同じで、ハーネスはモデルに「間違っているぞ」というフィードバックを与えられる。この一点が、後で見る自己修正ループの土台になります。
ハーネスがテープをどう改善するのか
ハーネスの仕事を、テープの言葉で分解すると、だいたい次の8つに整理できます。
| 手口 | 何をするか | テープへの効き方 |
|---|---|---|
| コンテキストの組み立て・取得 | 関連するファイルやスニペットを選んで載せる | 必要な記号だけをテープに載せる |
| コンテキストの圧縮 | 古いやり取りを要約・剪定して畳む | ノイズを減らし、有限の窓に収める |
| ツール実行 | 編集・テスト・コード実行・grep | 外界の事実をテープに書き戻す |
| 検証ループ | compile / test / lint の結果を戻す | 誤りを検出し、追記して再試行させる |
| サブエージェント | 調査を別ウィンドウに委譲する | 本線のテープを汚さず結果だけ受け取る |
| メモリファイル | 恒久的な指示を毎回読み込む | テープの先頭に載る前提知識になる |
| 計画・TODO管理 | タスクを分解し進捗を追う | テープに作業の骨格を書いておく |
| 窓の管理 | ファイルへ退避し、必要時に読み戻す | 有限テープを窓の外へ延長する |
このうち、前回の記事の主張と直結して効くのが2つあります。検証ループと、窓の管理です。順に見ます。
検証ループ ── δの弱さを外から補う
前回、一発の順伝播は浅い計算で、途中結果をテープに書きながら回すことで実効的な計算深さを稼げる、という話をしました。ハーネスの検証ループは、これを自動化したものです。
モデルがコードを書く。ハーネスがそれをコンパイルし、テストを走らせる。失敗すれば、エラーメッセージをテープに追記して、もう一度モデルに投げる。この「書く → 試す → 直す」を、人手を介さずに回します。実装はツールごとに個性があります。
- aider は
--auto-lint（既定でオン）で編集のたびにリンタを走らせ、--auto-testとテストコマンドを指定すればテスト失敗を検出して自動で直しにいきます - cline はターミナルの出力を実時間で監視し、コンパイルエラーやテスト失敗、サーバのクラッシュをその場で拾います。ブラウザ操作（Computer Use）でUIの動作確認までさせられます
- OpenCode は LSP（言語サーバ）連携に対応しており、有効化すると編集後の型エラーや診断をそのままモデルに戻せます。テキストではなく本物のコンパイラの目でテープに書き戻すわけです。ただし LSP は既定では無効で、有効化時にファイル拡張子や要件に応じて起動します。同期ズレやメモリ消費、遅延もあるため、プロジェクトによっては lint / typecheck コマンドを直接走らせるほうが安定します
- OpenHands は Docker サンドボックス内でコードやテストを実行し、その結果（観測）をイベントストリーム経由でモデルに返します
- Cursor はエラーやスタックトレースといったデバッグ情報を文脈に取り込む仕組みを持っています（詳細は版により変わるため公式ドキュメントで確認してください）
- Claude Code は bash でテストを走らせるほか、フック（PostToolUse）で編集後に自動でフォーマッタやリンタを回し、必要な結果をテープに残せます
UVMで言えば、スコアボードがミスマッチを検出したら、その情報を次のシーケンスにフィードバックして刺激を変える、という閉ループに当たります。重要なのは、このループが δ そのものを賢くするわけではない点です。1ステップの質は変わりません。ただ、間違いを検出してやり直させることで、弱い δ でも正解にたどり着く確率を上げている。前回の言葉で言えば、テープという増幅器を自動で回している、ということになります。
ただし注意が要ります。compile / test / lint は、完全な正しさの証明ではなく、仕様の一部を機械的に観測しているにすぎません。ハーネスの自己修正能力は、テストやチェッカの質に強く依存します。テストが弱ければ、ハーネスは「テストを通る間違ったコード」に収束してしまう。UVMでカバレッジの低い検証環境がバグを見逃すのと同じ話で、スコアボードの質がそのまま自己修正の質になります。
窓の管理 ── ファイルシステムとMCPへテープを延長する
実機のLLMのテープ（コンテキスト窓）は有限でした。ハーネスは、この有限のテープを外へ延長することで、実質的に広げます。
コード全体を窓に載せることはできません。そこでハーネスは、必要になったファイルだけをその都度読み込み、使い終わったら要約して逃がします。中間の作業ログや設計メモをファイルに書き出させるのも、窓の外にテープを伸ばす行為です。
もう一つの延長口が MCP（Model Context Protocol）です。これは Anthropic が2024年11月に発表した共通プロトコルで、データソースごとの個別実装を共通の作法で置き換える狙いのものです。いまでは後述の AGENTS.md と同じく Linux Foundation 傘下の標準になっています。MCP に対応したハーネスなら、データベースや外部API、社内ドキュメントといった窓の外の情報を、共通の作法でテープに引き込めます。採用は Claude Code・Cursor・OpenCode をはじめ主要ツールで進んでいますが、対応状況はツールごとに差があり、特に CLI 系ではバージョンや設定に依存するので、個別に確認してください（たとえば aider は AGENTS.md を読む設定はありますが、それは MCP 対応とは別の話です）。ファイルシステムがローカルなテープ延長なら、MCP は外界へのテープ延長です。
ただし、ファイルシステムも MCP も、有限のコンテキストを実用上は広げますが、理論上の無限テープそのものではありません。窓の外に置いた情報のうち、何をいつ読み戻すかを決める検索・要約・権限管理の品質が、そのまま新しいボトルネックになります。前回「実機は有限テープの FSM」と書いた話は、テープを外へ延ばしても本質的には消えず、延ばし方の設計問題として残る、ということです。
窓の中身の順序も効きます。長い文脈の中盤は埋もれやすい、という lost in the middle と呼ばれる現象（Liu ら, 2023）が知られていて、ハーネスは効かせたい情報を窓の端に置いたり、圧縮で中盤の無駄を削ったりして、これに対処します。Claude Code のように、用途の違う複数段の圧縮（個別ツール出力の削減、履歴の畳み込み、意味的な要約など）を段階的にかける実装も出てきています。
コンテキストの組み立て方は三系統
テープの初期組み立て、つまり「どのファイルを載せるか」の決め方には、大きく3系統あります。
一つ目はリポジトリマップ型です。aider が代表で、tree-sitter でリポジトリ全体のシンボル（関数やクラスの定義と呼び出し関係）の地図を作り、グラフのランキング（PageRank 的な手法）で重要度を付けて、指定トークン量に収まる要約をテープに載せます。全体像を安く俯瞰させるやり方で、地図は SQLite にキャッシュされます。C++ のように tree-sitter 文法が不完全な言語では字句解析にフォールバックします。
二つ目は索引型です。Cursor が代表で、プロジェクトを開いた時点でコード全体を埋め込みベクトルに索引化しておき、質問に意味的に近い箇所を検索してテープに載せます。@file や @codebase で明示的に足すこともできます。
三つ目はエージェント的探索型です。Claude Code や OpenHands、OpenCode、cline が代表で、事前の索引をあまり作らず、必要になった時点で grep やファイル読み込みを自分で実行して、テープを動的に組み立てます。人間が調べながらコードを読む動きに近いやり方です。このうち OpenCode と OpenHands は、加えて LSP で型情報や診断も引ける点が特徴です。
各ハーネスの比較
ここまでを一覧にまとめます。繰り返しになりますが、更新が速い領域なので細部は公式ドキュメントで確認してください。
| ツール | インターフェース | 提供・ライセンス | コンテキスト取得 | メモリ / ルール | 検証ループ | サブエージェント | 計画モード |
|---|---|---|---|---|---|---|---|
| Claude Code | CLI（デスクトップ / モバイルも） | 商用（Anthropic） | エージェント的探索（grep / glob / read） | CLAUDE.md が基本。AGENTS.md は import / symlink で共有 | bash・テスト・フックで実行 | あり（.claude/agents、最大5階層。実験的にエージェントチーム） | あり（Plan Mode、Shift+Tab） |
| Cursor | IDE（VS Code フォーク） | 商用 | 埋め込み索引 ＋ @メンション | .cursor/rules/*.mdc（旧 .cursorrules）。AGENTS.md 対応は版に依存 | デバッグ情報を文脈に取り込む機能あり | 並列エージェント中心 | あり（Ask / Agent） |
| cline | VS Code 拡張（JetBrains / Zed / Neovim / CLI も） | OSS（Apache-2.0） | エージェント的読込 ＋ @メンション | .clinerules（単一 or ディレクトリ）＋ Memory Bank | 端末出力を実時間監視、ブラウザ検証 | あり（読み取り専用のリサーチのみ。編集・ブラウザ・MCP・入れ子は不可） | あり（Plan / Act） |
| aider | CLI（ターミナル） | OSS（Apache-2.0） | リポジトリマップ（tree-sitter ＋ グラフランク） | CONVENTIONS.md（read-only で読込） | auto-lint / auto-test で自動修正 | なし（architect / editor の二段） | architect モード |
| OpenCode | TUI ＋ デスクトップ ＋ IDE パネル | OSS（MIT、Anomaly／旧 SST） | エージェント的読込 ＋ LSP 診断（既定は無効、有効化時） | AGENTS.md（CLAUDE.md は fallback） | LSP 診断を戻す、Git スナップショット | あり（General / Explore / Scout） | あり（Plan / Build、Tab） |
| OpenHands | Web / CLI / SDK | OSS（MIT、All Hands AI） | サンドボックス内でエージェントが操作 | .openhands のマイクロエージェント | Docker 内で実行し観測を返す | あり（AgentDelegateAction で委譲） | あり |
大づかみには、テープを人間がある程度コントロールしたいなら aider や cline のように明示的に載せる系、テープの組み立てごとエージェントに任せたいなら Claude Code や OpenHands、OpenCode のような自律探索系、という軸で選ぶと外しません。モデルを固定したくない（δ を差し替えたい）なら、OSS でプロバイダ非依存の cline・aider・OpenCode・OpenHands が候補になります。
サブエージェントという別テープ
比較表のサブエージェントの列を、テープの言葉で補足しておきます。サブエージェントとは、本線とは別のコンテキスト窓（＝別のテープ）で調査や下請け作業をやらせて、結果の要約だけを本線のテープに戻す仕組みです。本線のテープを長大な調査ログで汚さずに済むのが利点です。
実装はさまざまです。Claude Code は .claude/agents/ にサブエージェントを定義でき、それぞれ独立した窓で走り、最終メッセージだけが親に返ります（入れ子は5階層まで）。実験的に、リーダーが複数のteammateへ仕事を配る「エージェントチーム」もあります。OpenCode は General・Explore・Scout という3つの下請けを標準装備しています。OpenHands は AgentDelegateAction で、たとえば汎用の CodeActAgent がブラウジングを専門エージェントに委譲します。cline のサブエージェントは、現状はコードベース調査向けの読み取り専用リサーチエージェントで、ファイル編集・ブラウザ操作・MCPアクセス・入れ子はできず、それらは本線のエージェント側に残ります。むしろ「汚れた調査ログを本線テープに入れないための別テープ」として、cline はきれいな実例になっています。aider には本格的な並列サブエージェント機構は主役として無く、代わりに計画役と編集役でモデルを分ける architect モードがあり、これも「役割ごとにテープを分ける」発想の一種です。
メモリファイルという恒久テープ
ハーネスの重要な部品が、メモリファイルです。これは毎回テープの先頭に自動で載る恒久的な指示で、プロジェクトの規約や前提を、都度書かずに済ませるための仕組みです。ツールごとに名前が違います。
| ツール | メモリ / ルールファイル |
|---|---|
| Claude Code | CLAUDE.md が基本（利用者全体の ~/.claude/CLAUDE.md も）。AGENTS.md は CLAUDE.md から @import または symlink で共有 |
| cline | .clinerules（単一ファイル or .clinerules/ ディレクトリ）＋ Memory Bank |
| aider | CONVENTIONS.md（--read で読み取り専用として読込）や --read AGENTS.md |
| Cursor | .cursor/rules/*.mdc（4つの適用モード）。旧 .cursorrules。AGENTS.md 対応は版に依存するため要確認 |
| OpenCode | AGENTS.md（初回起動時に生成、階層的に適用）。CLAUDE.md は fallback として対応 |
| OpenHands | .openhands のマイクロエージェント |
この規約ファイルは、いま AGENTS.md という共通名に収束しつつあります。もともとは 2025年8月に OpenAI の Codex から始まり、Amp（Sourcegraph）、Google の Jules、Cursor、Factory などが加わって共通仕様になりました。そして 2025年12月、Anthropic の MCP や Block の goose とともに、Linux Foundation 傘下の Agentic AI Foundation（AAIF）へ寄贈され、特定企業に依存しない標準として統治されるようになりました。6万を超えるリポジトリと20以上のツールが対応しており、ディレクトリごとに置くと近いものが優先される、という素直な仕様です。ツールを乗り換えても同じテープの前提を使い回せるので、実務的にはありがたい方向です。
テープの言葉で言えば、メモリファイルは「毎ターン必ず載る固定の記号列」です。何を書くかは、良いテープ設計そのものです。冗長に書けばノイズになって窓を圧迫し、薄すぎれば前提が伝わらない。Cursor の推奨が「常時適用ルールは200語以内に」であるように、ここでも前回の「何を載せるか」の判断が効いてきます。
使い分け
どのハーネスを選ぶか。作業の性質で向き不向きが分かれます。
言葉でも整理しておきます。
| 状況 | 向いているハーネス |
|---|---|
| 巨大な既存リポジトリを git 管理下でピンポイントに直す、CIで非対話に回す | aider（リポジトリマップと git 自動コミットが効く） |
| 計画 → 実装 → テスト修正まで自律で回したい、サブエージェントを多用したい | Claude Code |
| 隔離されたサンドボックスで安全に自律実行したい、委譲を使いたい | OpenHands |
| VS Code から離れず、OSS でMCPを気軽に足したい、UIまで検証したい | cline |
| ターミナルで軽量に、モデル非依存＋LSP で、ローカルモデルも使いたい | OpenCode |
| 補完やエディタ体験の完成度、半自動の編集を重視 | Cursor |
Hermes について
Nous Research の「hermes-agent」というプロジェクトで、これは汎用のエージェント基盤です。ただし位置づけが独特で、Claude Code・Codex CLI・aider・OpenHands といった本記事のハーネスを「スキル」として呼び出し、タスクを委譲する側にいます。つまり hermes-agent は、ハーネスと横並びの存在ではなく、ハーネスを束ねて使う一段上のオーケストレータに当たります。
ハーネスは能力の増幅器であると同時に、権限の境界装置
ハーネスを「テープを自動で育てる機械」と見ると、能力の話にばかり目が行きます。しかし実務でもう一つ重要なのは、どこまで自動で実行させるか、です。
テープを外界へ延ばすことは、同時に攻撃面を外界へ広げることでもあります。ファイルを読むだけなら安全側、書くと影響が出る。shell を許すとビルドやテストが回せますが、破壊的なコマンドも実行できます。MCP を許すと外部システムに届きますが、認証情報や社内データにも届きえます。実際、MCP サーバが shell 実行・ネットワーク・ファイル操作といった特権を公開するため、自然言語の入力から危険な操作へ到達する経路が生まれる、という指摘も出ています。prompt injection やツール汚染（tool poisoning）、権限過多のリスクも、能力と引き換えに増えます。
つまりハーネスは、計算能力の増幅器であると同時に、権限境界を設計する装置でもあります。良いハーネスとは、単に強いループを回す装置ではなく、権限境界・承認・監査ログ・サンドボックスを備えた実行基盤です。実際、OpenHands が Docker で隔離し、cline が読み書きや実行に人間の承認を挟み、OpenCode の plan モードが編集や bash を確認付きにするのは、いずれもこの境界設計に当たります。テープ設計だけでなく、実行環境設計まで含めて評価すべき、ということです。
コーディング用途で効いてくる軸を並べると、何を読むか（コンテキスト選択）、何を捨てるか（圧縮）、何で正しさを判定するか（検証）、何を実行させるか（権限）、どこまで隔離するか（分離）、何をログに残すか（可観測性）、失敗時に戻せるか（rollback / diff / git worktree）、同じ条件で再現できるか（再現性）、といったところです。良いハーネス選びは、この多くを同時に見ることになります。
まとめ
前回の記事は、δ は固定で触れないので動かせるのはテープだけ、良いテープを作ることが使いこなしの本体だ、という主張でした。本記事は、その「良いテープ作り」を自動化する装置としてハーネスを位置づけ直したものです。
- ハーネスは、ステートレスなモデル（δ）を取り囲む、テープの読み書きコントローラです。UVMのテストベンチが DUT を駆動して応答を検査するのと同じ構図です
- ハーネスがテープを改善する手口は、コンテキストの組み立て・圧縮・ツール実行・検証ループ・サブエージェント・メモリファイル・計画・窓の管理、に整理できます
- とりわけ検証ループは δ の弱さを外から補い、窓の管理はファイルシステムと MCP へ有限テープを延長します。どちらも前回の「テープで稼ぐ」を自動化したものです
- ツールはコンテキストの取り込み方で、リポジトリマップ型（aider）・索引型（Cursor）・エージェント的探索型（Claude Code / OpenHands / OpenCode / cline）に分かれ、作業の性質で使い分けます
- 規約ファイルは AGENTS.md に収束しつつあり、MCP とともに Linux Foundation 傘下の標準になりました。ツール横断でテープの前提を共有できます
- Hermes はハーネスではなく、ハーネスを束ねるオーケストレータです
そして、前回の結論はここでも変わりません。良いテープは万能の魔法ではなく、まともな δ があって初めて効く増幅器でした。ハーネスも同じです。どれだけ精巧にテープを組み立て、検証ループを回しても、土台のモデルが弱ければ、間違いを増幅しながら回り続けるだけになります。
ただし誤解のないように補うと、ハーネスはモデルの重み、つまり δ そのものは変えませんが、外部ツール・検証器・メモリ・検索・実行環境を接続することで、LLM単体とは別物の計算システムを作ります。モデルは賢くなっていないが、システム全体は強くなっている、という言い方が正確です。
ハーネスを選ぶこと、AGENTS.md を書くこと、@メンションでファイルを足すこと。その一つひとつが、突き詰めれば「有限のテープに何をどう書くか」の設計でした。そしてハーネスの本質は、モデルを賢くすることではなく、モデル・外部記憶・外部ツール・検証器・権限管理を接続して、有限のコンテキスト窓を実用的な計算環境へ変えることにあります。前回の理論の視点は、エージェント時代のツール選びという実務にも、そのまま地続きで効いてきます。