第2章: ループを巻きつけるという発明 ── 三角形をもう一段深く
第1章で、「LLM + 道具 + ハーネス」という三角形を置いた。 そのあと、こんな疑問を持った読者がいるはずだ。
「LLM はわかる。道具もわかる。でもハーネスって、結局なんなんだ?」
ニュースで名前が出るのは、たいてい上の二つだ。 「Claude Opus 4.5 がすごい」「MCP で道具が増えた」── LLM と道具は、見えやすい。
それに対して ハーネス は、姿が見えにくい。
ターミナルに claude と打ったときに立ち上がる あのプログラム が、まさにハーネスなのに、ふだん誰もその中身の話をしない。
しかし、本書の主張はここから始まる。 エージェントの体感を決めているのは、ほとんどハーネスだ。 この章では、その正体を腑に落とす。
2.1 そもそも、ハーネスって何をしているのか
第1章の図 1.1 を思い出してほしい。LLM と道具のあいだに座っている「外側のプログラム」── あれがハーネスだ。 名前は地味だが、実際にやっていることは多い。
ハーネスとは、LLM という「続きを書く機械」を “動く” エージェントに化けさせるために、外側で回り続けている縁の下のプログラム のこと。 ループ・道具・履歴・停止・承認 ── これらの 設計判断の総量 が、そのままエージェントの人格になる。
具体的な顔ぶれを並べると、こうなる。
- ターミナルに
claudeと打ったとき立ち上がる、Node.js 製の CLI 本体(Claude Code) - VS Code 拡張として VS Code プロセスの中に居候する Cursor の Agent ランタイム
codexコマンドで動く OpenAI の Codex CLI- クラウド上のコンテナで動き続ける Devin の Devbox プロセス
- エディタにかぶせて動く Aider の Python プログラム
- Docker コンテナの中で安全に走る OpenHands のオーケストレータ
UI も配置場所も違うが、中で動いている仕事の 骨格 は驚くほど似ている。
2.2 ハーネスが「やっていること」 7 つ
ハーネスの仕事を、思い切って 7 つに棚卸ししてみる。 これは本書の残り全章で何度も戻ってくる「ハーネスのお品書き」になる。
| # | 仕事 | やっていること |
|---|---|---|
| ① | 道具カタログの組み立て | どんな道具を LLM に見せるか決め、JSON Schema 形式で渡す |
| ② | メッセージ履歴の管理 | これまでの user / assistant / 道具の結果ブロックを順に積み、毎ターン LLM に渡す |
| ③ | LLM 呼び出し | 履歴 + 道具カタログを API に投げる。ストリームで返事を受け取る |
| ④ | 道具の実体実行 | LLM が「Read を呼べ」と言ったら、本当にファイルを読む |
| ⑤ | ループ制御 | think → act → observe を、止まるまで回し続ける |
| ⑥ | 停止判断 | いつ抜けるか。自然停止・上限・人間介入 ── 第4章の本題 |
| ⑦ | UI / UX | 何を画面に出すか。承認をどう求めるか。割り込みをどう受けるか |
JSON SchemaJSON で書かれた「データの型と形」の取り決め。「この道具は
pathという文字列を 1 つ取る」のような契約を機械可読に表現する。LLM はこれを読んで、道具呼び出しを組み立てる(詳細は第5章で詳述)。
具体的に Claude Code を例に当てはめると、こうだ。
- ① Read / Write / Edit / Bash / Grep / Glob / WebFetch などを束ねて LLM に見せる
- ② 直近の会話と道具実行結果を、ターンごとに追記する
- ③ Anthropic Messages API に投げる
- ④
Readならfs.readFileSync、Bashなら子プロセスを起動して結果を取る - ⑤ LLM が「ツール呼び出しブロック」を出している限り、回し続ける(その正体は第5章で詳述)
- ⑥ ツール呼び出しを含まない応答が来た瞬間に抜ける(第4章で詳述)
- ⑦ ターミナルに
● Bash(pnpm test) ⎿ 3 failingのような行を出す、Escで止められる
Cursor の Agent モードも、Codex CLI も、Devin も、この 7 つを別々のやり方でやっているだけ で、お品書き自体は共通している。
2.3 ハーネスが「やっていないこと」
ここまで読むと「じゃあハーネスがすべてやっているのか」と思いたくなるが、そうではない。 ハーネスがやらないこと を明示しておくと、責務がもっとくっきりする。
- LLM 自体を改造しない。ハーネスは API を叩く側であって、モデルの中身は触らない
- 道具の中身そのものは書かない。
Readの実体はファイルシステム呼び出しで、ハーネスは「呼んで結果を返す」だけ - タスクの中身を考えない。「次に何をするか」は常に LLM が決める
ハーネスは 「賢くないが、賢く動くための舞台装置をぜんぶ用意する」役 だ。 舞台監督ではなく、舞台監督が能力を発揮できる照明・音響・スクリーン・幕の上げ下げ を担う黒子。
主役の LLM が舞台で輝けるかどうかは、この黒子の段取りに 9 割かかっている。
2.4 三角形をもう一段ぶら下げる
第1章の図 1.1 は、三角形の外形を見せた図だった。 ここでは、各頂点の 内側で何が動いているか をぶら下げて、絵を一段深くする。
第1章の三角形と並べると、こうなる ── LLM と道具は箱の中身が見えるが、ハーネスは “7 つの仕事の束” として現れる。
ここから先、本書で「ハーネスがどう設計されているか」と言うときは、この 7 つのどこに手が入っているのかを指していると思って読んでほしい。
2.5 ハーネスはどこに住むか ── 3 つの居場所
7 つの仕事を担うハーネスも、どこで動いているか によって設計判断の前提がガラッと変わる。 居場所は大きく 3 つに分類できる。これは第7章(コンテキストウィンドウ)や第10章(HITL)でも繰り返し戻ってくる視点だ。
① 手元の CLI に住むハーネス
ターミナルから claude codex aider と打つと、その PC の中でループが回る。
ファイルアクセスもシェル実行もローカル。人間が近くにいる前提 で、承認や割り込みが日常的に効く。代表例は Claude Code(Node.js 製 CLI)や Codex CLI(Rust 製 CLI)。
② エディタ拡張に住むハーネス Cursor の Agent モードや、VS Code 系の拡張型エージェントがこれ。 エディタプロセスの中 でループが回り、開いているファイル・選択範囲・カーソル位置などをそのまま文脈にできる。代表例は Cursor (Agent モード)。
③ クラウドに常駐するハーネス Devin や GitHub の Coding Agent、Claude Code の Cloud などがこれ。 専用 VM やコンテナの中で動き、人間が画面を見ていなくても回り続ける。長時間タスクに強い半面、暴走したときに止めにくい(第10章で詳述)。
ハーネスがどこに住むかで、人間との距離 が決まる。 距離が近い(CLI、エディタ)ほど、停止条件をゆるくしても安全に倒せる。 距離が遠い(クラウド常駐)ほど、ハーネス側で 自前で慎重に止まる仕掛け を作り込む必要が出てくる。
「Devin がときどき豪快に脱線する」「Claude Code は細かく承認を求めてうるさい」── 両者の体感差は、LLM ではなく 居場所の違いに合わせた設計判断 から来ている。
骨格(7 つの仕事)は 6 プロダクトで共通だが、どこに重心を置くか が違う ── Claude Code は対話と承認の手触り、Devin は長時間自走、Aider は Git コミット単位の差分。プロダクト単位の詳しい比較は 付録A にまとめてあるので、必要になったら地図として開いてほしい。
同じ LLM を使っていても、ハーネスの重心が違えば “別人格” になる。 せかせか確認してくる慎重な同僚、静かに長時間こもる職人、コミットごとに律儀に報告する真面目な後輩 ── たとえるならそんな違いだ。 LLM の世代交代より、ハーネスの設計判断のほうが、体感への効きが大きい場面は多い。
2.6 結局、ハーネスは何を握っているのか
7 つの仕事 × 3 つの居場所 ── これだけ並べると、ハーネスが握っているものの大きさが見えてくる。
私はハーネスをよく 「LLM のための作業環境を、丸ごと用意する執事」 だと言う。 朝起きてから夜寝るまでの段取り、机の上に置く道具、来客との取次、ヤバいときに肩を叩く役 ── これを全部、執事がやる。
主役の LLM(続きを書く機械)は、いつまでたっても続きを書く機械のままだ。 だが執事の腕によって、その主役が 凡庸な相談相手にも、頼れる同僚にも、危なっかしい暴走者にも なる。
本書の残り 8 章は、執事の手仕事を一つずつ追っていく旅だ。
次章では、この執事が回している ループの中身 ── think → act → observe という三拍子 ── に踏み込む。 ハーネスが何をどの順で実行しているのかが、いよいよ動画として動き出す。
この章の振り返り
- ハーネスは LLM を “動く” エージェントに化けさせる 外側のプログラム
- 仕事は 7 つ: 道具カタログ / 履歴 / LLM 呼び出し / 道具実行 / ループ制御 / 停止判断 / UI
- 一方で「LLM の改造」「道具の中身」「タスクの判断」は やらない
- 居場所は 3 つ: 手元 CLI / エディタ拡張 / クラウド常駐 ── 人間との距離が設計を変える
- 同じ骨格でも、重心の置き方はプロダクトごとに違う(付録A 参照)
- 同じ LLM を使っても、ハーネスの設計判断の総量 がエージェントの人格を決める
この章で読めるようになるツイート / ブログ
- 「Cursor から Claude Code に乗り換えたら、対話のリズムが違いすぎて慣れない」 → 同じ「コーディングエージェント」でも、居場所(エディタ拡張 vs 手元 CLI)が違うと、承認導線も文脈の渡し方も別物になる、と読める
- 「Cursor の Agent モードは、開いてるファイルを勝手に読んで気が利く」 → エディタ拡張型のハーネスが、エディタの状態を文脈に組み込んでいる、と読める
- 「Devin と Claude Code、同じタスクを投げてもログの粒度が違いすぎる」 → クラウド常駐ハーネスと手元 CLI ハーネスでは、UI と承認導線(7 つの仕事の ⑦)の作り方がまるで別、と読める
次章は、このハーネスが回しているループの 中身のリズム ── think → act → observe ── に踏み込む。