LLM Harness Writing Study

ソース

• yan5xu, 从 Prompt 到 Harness：如何理解 LLM Engineering（「Prompt から Harness へ：LLM Engineering をどう理解するか」）, X Article, 2026-05-26
• 原文リンク：https://x.com/yan5xu/status/2059117572826746979

注記：これは読後の学習ノートで、概念フレームワークと執筆手法だけを記録する。原文中の具体的な数値・企業事例・将来の日付を正式な記事に入れるなら、一つずつ再検証が要る。

概念フレームワーク

原文は LLM Engineering の進化を三重スパイラルとして語る：

1. Prompt Engineering：タスクは比較的静的で、人が言い回し・ロール・例示・出力形式によって単発の入力を最適化する。「どう聞くか」を解決するが、多段タスクで詰まる。
2. Context Engineering：タスクは動的に展開し、プログラムが前段の出力・ツールのフィードバック・検索結果・圧縮済み履歴を次段へ注入する。「モデルに何を見せるか」を解決するが、ルールの大半は人が事前に決める。
3. Harness Engineering：モデルが十分に強くなった後は、agent にツールとフィードバック経路を与え、何を見るべきか・何を検証すべきかを自分で判断させることに重心が移る。同時に sandbox、権限、テスト、CI の回数上限、構造的制約といった境界で暴走を防ぐ。

最も価値のある区別：

• Context Engineering は、プログラムが agent の代わりに情報を編成すること。
• Harness Engineering は、agent に情報とフィードバックを獲得する能力を与えた上で、境界によって行動を制約すること。
• Runtime 能力は harness と等しくない。状態の永続化・compaction・session の継続は agent runtime のインフラに近く、harness が関心を持つのは、agent が実行中に能動的にフィードバックを得られるか、そして実行可能な境界に制約されているかだ。

再利用できる判断

この記事の主線は「新しい用語が古い用語を置き換える」ではなく「ボトルネックの移動」だ：

• prompt 時代のボトルネックは表現の仕方；
• context 時代のボトルネックは情報の流れ；
• harness 時代のボトルネックは環境・フィードバックループ・制御システム。

このフレームワークが agent エンジニアリングの記事に向くのは、抽象概念を工学の問題へ戻すからだ：前の段階はなぜ足りなくなったのか、次の段階は具体的にどの詰まりを解いたのか、そして新たにどんな信頼性の問題を持ち込んだのか。

自分の記事に移植できる文型の骨格：

• 「ボトルネックは A から B へ移った。」
• 「X はゼロから設計された新パラダイムではなく、Y が走り出した後に現実に教えられた経験だ。」
• 「まず手を放し、それから失敗モードから境界を逆算する。」
• 「前のリングは消えていない。現在のリングのインフラになったのだ。」

これらの文型は使えるが、正式な執筆では自分の事例と言葉に置き換え、そのまま複製するのは避ける。

執筆手法

1. 歴史を展開する前に、読者へ地図を渡す

冒頭の一段落で三段階の関係と TL;DR を示し、この先が概念の積み上げではなく三つの問いへの説明だと読者に知らせる：

• 古いやり方はなぜ足りなくなったのか；
• 新しいやり方は何を解決したのか；
• 新しいやり方は今度はどこで詰まるのか。

この書き出しは長文に向く。読者は詳細に入る前に「ナビゲーションの地図」を手にしている。

2. どの節も同じ推進テンプレートで進める

記事は各段階を語るたび、おおよそこの順序で進む：

1. 当時の典型的な実践は何だったか。
2. なぜそれは確かに有効だったか。
3. それは何を解決できなかったか。
4. その結果、ボトルネックはどこへ移ったか。

この反復構造が、概念のアップグレードを用語のねじ込みではなく自然な流れに見せる。

3. 抽象的な定義は事例から育てる

Harness Engineering は最初に定義されない。まず「手を放す」と「保険を掛ける」を語り、それから Stripe・Anthropic・OpenAI の三つの事例で検証する：

• Stripe：高速フィードバックのツールチェーンと制限された実行環境。
• Anthropic：長時間タスクの失敗モードから feature の粒度・JSON 状態・エンドツーエンド検証の制約を逆算。
• OpenAI Codex：エンジニアの仕事の重心を、プロダクトコードを書くことから環境・フィードバックループ・制御システムへ移す。

これは thought-forge の「概念先行を防ぐ」ルールにちょうど合致する：まず読者に実践を見せ、それから用語で実践を圧縮する。

4. 概念の境界は反例で明確にする

記事は「何が Harness に当たらないか」をわざわざ述べ、compaction・session 継続・記憶管理を harness ではなく runtime に帰属させている。

この書き方は重要だ：新しい概念が最も恐れるのは境界の膨張である。反例を示せば、著者が新語で何もかもを包もうとしているのではないと読者に伝わる。

5. 結びは要約ではなく、次のリングのボトルネックを指す

結末は「Prompt -> Context -> Harness」のまとめで止まらず、次のリングの問題を eval と governance へ向けている。

この締め方は技術トレンド記事に向く：記事が「現在の段階を定義する」から「次に何を書けるか」へ自然に移行する。

発展させうる記事の切り口

• Harness は Agent Runtime ではない：compaction をプロダクトの売りにするな
• まず手を放し、それから保険を掛ける：Agent エンジニアリングの境界はどこから来るか
• context rot から eval rot へ：LLM Engineering のボトルネックはなぜ移動し続けるのか
• Agent エンジニアリングはより長い prompt を書くことではなく、より短いフィードバックループを設計することだ

要検証リスト

この X Article の内容を正式な記事に発展させるなら、少なくとも以下を検証する：

• Context Engineering に関する Karpathy の原表現と公開時期。
• Stripe Minions のツールチェーン、CI 回数、PR の数値。
• Anthropic の長時間タスク harness 実験の具体的な設定。
• OpenAI Codex チームの記事における harness・環境設計・コード量に関する元の文脈。
• Epsilla、LangChain Terminal Bench 2.0、Microsoft/Salesforce の context rot など定量的結論の実験条件。
• 2026 年の eval・governance・agent standard に関する業界イベントが公式ソースに由来するか。