ループは入れ子だった：loop engineering と harness engineering が本当に置き換えるもの

最終更新 2026-06-10

あなたが2年間、名前もつけずに回してきたループがある。エージェントが一区切りの作業をする。 返ってきたものを読む。良し悪しと次にやることを判断する。次の指示を打つ。エージェントがまた次を進める。 この「結果を見る・判断する・また prompt する」の繰り返しがひとつのループで、 それを回しているのはあなただ。

このループが見えた瞬間、2026 年にあちこちで言われている二つの言葉は、もう競合するバズワードではなくなる。harness engineeringと loop engineeringは別々のループを相手にしている。 一方はエージェント自身のループをより長く走らせ、もう一方は、あなたのループを取りに来る。

三つのループ、入れ子になっている

上へ行くほどループだ。三つが積み重なり、外側が内側を包んでいる。

• いちばん内側は ReAct ループ。一回の実行の中で、エージェントは考え、ツールを呼び、 結果を見て、また考える。これはエージェント自身のループで、一つのタスクを自分で一周ずつ回していく。
• その外側が harness。あなたが回すループではなく、 「内側のループが行き詰まるまでどこまで走れるか」を決める仕組みだ。ツール、状態、コンテキスト管理、hooks、リカバリ。
• さらに外側があなた。実行が終わるか行き詰まると、話は人間に戻ってくる。結果を見て、 次のゴールを決め、また一周を始める。これが、誰も名前をつけてこなかったループだ。

この図を覚えておいてほしい。問いはひとつ、それぞれの言葉がどのループを変えようとしているか、だからだ。

harness engineering は内側を相手にする

素のモデルはエージェントではない。足場で包んで初めてエージェントになる。その足場が harness だ。 Viv Trivedy の一言が形をうまく捉えている。Agent = Model + Harness。モデルでないなら、あなたが harness だ。つまり harness engineeringは、 その足場を本物の成果物として扱い、磨き込む営みだ。エージェントが間違うたびに環境を変え、その間違いが二度と起きないようにし、 そこからさらに締めていく。

要するに harness とは「モデル以外」のすべてだ。

• システム prompt とルールブック（AGENTS.md や CLAUDE.md のような）。 毎ターン差し込まれる。
• ツール、skills、connectorsと、「いつどれを使うか」をモデルに伝える説明。
• コンテキスト戦略。圧縮、巨大なツール出力の退避、必要なときだけ指示を見せること。 どれも context rot（長くなるほど精度が落ちる問題）への対策だ。
• サンドボックス。コードを安全に走らせ、エージェントが自分で結果を検証できる場所。
• hooks。ルールを確定的に強制する。破壊的コマンドを止め、編集後にテストを走らせ、push 前に承認を求める。
• 可観測性。ログ、トレース、token コストとレイテンシ。

根本的な事実が繰り返し現れる。同じモデルでも、より良い harness に載せると性能が劇的に変わる。 harness を変えただけで、コーディングエージェントをベンチマークの中位から上位 5 位に押し上げたチームもある。 モデルは最初から唯一の変数ではなかった。

それが何を買ってくれるかを見てほしい。良い harness は一回の実行をより遠くまで走らせる。手数が増え、一貫性が増し、転倒が減り、 そのあとでようやく制御を人間に返す。伸びるのは「一息でどこまで、どれだけ安定して押せるか」だ。 Anthropic のエンジニアリングチームの言い方が鋭い。harness の各部品は「モデルが自力でできないこと」の仮定を埋め込んでいる。 だからモデルが強くなっても足場は消えない。新しい天井のある場所へ移るだけだ。

ただし harness engineering にできないことがある。いちばん外側のループからあなたを抜くことだ。 どれだけ harness が良くても、一回の実行はいつか終わる。誰かが結果を見て「よし、次はこれを」と言わねばならない。 この2年、その誰かはずっと人間だった。

loop engineering は外側を取りに来る

loop engineeringは、Addy Osmani が広め、Peter Steinberger や Claude Code の Boris Cherny も同じことを言っている言葉だ。 それが自動化するのは、まさにあなたが手で回してきたあのループだ。一区切りごとに見て prompt するのをやめ、 ゴールを一度だけ決め、そこからエージェントを本当に達成するまで走らせるシステムを組む。

しかも「次の prompt を自動で打つ」だけの話ではない。あなたのループは「次の一手を決める」だけでなく、 静かにもう一つ、「やるべき仕事があると気づく」こともやっていた。だから本物の外側ループは発見とトリアージまで引き受ける。 定時、あるいはイベント駆動のトリガーがやるべきことを拾い上げ、ループが自分で割り振り、手に負えないものだけがあなたに戻ってくる。 スケジューラ、ディスパッチャ、毎ターンのドライバー、この三役を一気に降りることになる。

動くループを分解すると、五つの部品とひとつの記憶が出てくる。

• 自動化。定時かイベント駆動で仕事を拾い上げるトリガー。心臓の鼓動だ。
• 分離。worktree や別々のコンテキスト。並行するエージェントがぶつからないように。
• skills。プロジェクトの知識を一度書いておく。ループが毎回あなたの流儀を一から導き直さずに済む。
• connectors。仕事が実際に触れるツールやデータへのアクセス。
• サブエージェント。「作る側」と「検査する側」の分離。重要なので下に専用の節を設けた。
• ディスクに残る記憶。実行をまたいで生き残るファイルやボード。モデルは実行と実行の間ですべて忘れるからだ。

もう机上の空論ではない。Claude Code には /loop と /goal があり、 OpenAI Codex には Automations と独自の /goal コマンドがある。これらの原語はもう、あなたが毎日使う道具の中にある。 この言葉が流行ったのも、半分はそれが理由だ。

本当に変わるのはここだ。重心は「この一つの prompt がどれだけ良いか」から、 「あなたの代わりに prompt を書き、結果を判定するシステムがどれだけ良いか」へ移る。 よく設計された外側ループは優秀なエンジニアを増幅する。下手な設計は、まずい判断を同じ速さで増幅する。見ている目は前より少ない。

落とし穴：人間のループは検査もしていた

素朴な loop engineering はここで崩れる。人間をただ外し、システムにゴールへ向けて prompt を回させるなら、 消したのは「次はこれを」と言う人だけではない。「待て、前の一手は間違っている」と言う人まで消している。 外側のループはずっと、一つの帽子の下に二つの仕事を詰めていた。次の一手を決めること、そして前の一手を検証することだ。

だから本当に動くループは、検証を自分の中に取り込まねばならない。定石は「作る側」と「検査する側」を分ける（maker-checker）こと。 別の検証エージェントが途中の成果を採点し、ゴール到達を判定する。作業したエージェントは断じて使わない。 モデルは自分の成果を毎回甘く採点するからだ。この検証者があってこそ、「ループが完了したと言っている」に意味が出る。 これは本気の エージェント評価を支える原理と同じだ。 生成と判定を分ける。さもなければ信じているのは、自信たっぷりの当て推量にすぎない。

検証者がいても、人間は検査の席から完全には離れない。毎ターンのループから抜け、二つの場所へ上がるだけだ。

• 着手前、まずループを設計する。ゴール、検証者が照らす「完了の定義」、実行頻度、 不可逆な操作にかける承認ゲート。「どうなったら完了か」を文章にしておくことが、いちばん逸脱を止める。
• 実行後は、重要なものだけ見る。毎ターンではなく、影響が大きく取り返しのつかない結果を。 「完了」はループの一方的な主張で、それを取り込むかどうかは依然あなたの判断だ。

だから正直な一言は「人間は最終状態だけ見ればいい」ではない。こちらに近い。 loop engineering はあなたを毎ターンの運転から外し、ループの設計と重要な成果のレビューへ引き上げる。 そしてあなたが一つひとつ手でやっていた検査は、検証エージェントが引き継ぐ。

スマホ上ではどう見えるか：Memex

この枠組みが我々にとって単なる言葉でないのは、こういう理由だ。どちらの言葉が流行るより前から、 Memex はすでに外側ループの一つの形を端末上で回してきた。ローカルファースト、バックエンドなしのアプリで、 記録を構造化カードに整理し、知識を抽出し、洞察を浮かび上がらせるマルチエージェントが、すべてスマホ上で動く。 ここでの harness が dart_agent_core、 完全な ReAct ループに加えてツール実行、FileStateStorage でディスクに残すセッション、 コンテキスト圧縮、リカバリを実装した我々のオープンソース Dart フレームワークだ。 面白いのは制約のほうだ。サーバーもなし、shell もなし、CI もなし。 外側ループはアプリが落とされても端末が再起動しても生き残らねばならない。 だからこそ「状態をディスクに残す」「イベントで駆動する」が、ここでは飾りでなく大黒柱になる。 （詳しくは Memex の裏側のエンジニアリングで。）

その外側ループはチャットではなくイベントで回る。カードを確認してから次を指示するのではなく、 記録イベントがグローバルイベントバスを通じて、それを購読しているエージェントへ直接渡る。 トリガー、作業ディレクトリ、スキルセットはすべてディスク上の CustomAgentConfig に書かれている。 Super Agent が専門の worker（Card、PKM、Insight、Comment、Memory）を束ね、delegate_task で仕事を割り振り、それぞれが分離された状態で走る。人が次の prompt を打つことはない。

そして「完了の定義」もコードに書かれている。鵜呑みにはしない。Card Agent が走り終えると、Memex は CardRunCompletionEvidence を実行する。ディスクにカードが存在するか、fact_id が一致するか、 ステータスが completed か、タイトルと UI 設定があるか、実行記録に成功した save_timeline_card 呼び出しがあるか。すべて満たして初めて完了。欠けていれば、足りない要件を具体的に差し戻して再実行させ、 リトライ上限まで回す。さらに破壊的操作の前に止まる AgentController hooks と、 繰り返し呼び出しを捕まえるループ検出器を足せば、これがこの記事で言ってきた検証者と完了条件、まさに一台のスマホ上で動いている姿だ。

本当に面白いのは、その制約だ。loop engineering の記事はたいてい、サーバーと shell と CI ランナーを前提にする。 Memex にはどれもない。外側ループはアプリがシステムに落とされても、端末が再起動しても、ネットワークが切れても生き残らねばならない。 だからこそ「状態をディスクに残す」「イベントで駆動する」が、ここでは飾りではなく、 外側ループをスマホ上で成立させる唯一の手段になる。

リスクは消えない、一段上へ移るだけ

「人間のループ」に潜んでいた厄介ごとは、自動化したからといって消えはしない。場所を変えるだけで、いくつかはむしろ鋭くなる。

• 検証はやはりいちばん難しい。あなたはそれを自分の目から、検証エージェントと 重要な結果のレビューへ移しただけだ。検証者が頼りないと、ループは昔の人間のループより速く、より堂々と、間違った成果を出してくる。
• 「理解の負債」が積み上がる。ループが手を動かしていない変更を速く出すほど、 「実際に存在するもの」と「あなたが本当に理解しているもの」の差は広がる。
• コストはタスクでなくループに比例する。毎ターン検証者を走らせ、サブエージェントを何体も抱えた定時ループは、 大した収穫がなくても token を燃やす。まずゆっくり回し、請求を見て、本当に残したい成果が出てから頻度を上げる。

だから結論は「人間のループを自動化して放り出す」ではない。仕事の形が変わった、だ。 harness engineering は一回の実行を信頼できるものにする。loop engineering は信頼できる実行を、 あなたが運転しなくても繰り返させる。割に合うかは二点で決まる。 あなたが一つひとつ手でやっていた検証が、そのままループの中へ作り直されているか。 そして、あなたがまだそれを設計するエンジニアであって、ただ「開始」を押す人ではないか。

FAQ：ループ、harness、そして何が置き換わるのか