← 기사 목록
日本語https://zenn.dev/topics/llm/feed

prompt / context / harness: ボトルネック移動で読むLLM engineeringの系譜とその先

원문 사이트로 이동 ↗

추출된 키워드

60개
context engineering·5harness engineering·5LLM engineering·5ボトルネック·5prompt engineering·5エージェント·4governance·4eval·4Anthropic·4RAG·4LLM·4Claude Managed Agents·3CoT·3Philipp Schmid·3Aparna Dhinakaran·3Birgitta Böckeler·3LLM-as-judge·3Harvey·3Legal Agent Benchmark·3LAB·3OpenAI·3compaction·3few-shot·3Galileo·3Eval Engineering·3AgentCore Evaluations·3A2A·3Agent-to-Agent·3MCP Authorization Spec·3Sub-agent architectures·3reasoning model·3Structured note-taking·3subagent 分割·3Prompting Inversion·3Sculpting·3Chain-of-Thought·3sandbox·3o3-mini·2Gemini 2.5 Flash·2GPT-3·2scheduler·2Amazon Bedrock·2OpenTelemetry·2OpenInference·2sub-agent quarantine·2Gravitee·2role assignment·2PaaS·2o4-mini·2Codex·2Context pruning·2gpt-4o·2self-reflection ループ·2gpt-5·2LangGraph·2LangChain·2Arize AI·2Google DeepMind·2Hugging Face·2Tool loadout·2

원문

18,892자
prompt / context / harness: ボトルネック移動で読むLLM engineeringの系譜とその先

prompt / context / harness: ボトルネック移動で読むLLM engineeringの系譜とその先

TL;DR

  • LLM とその周辺が成熟するにつれ、ボトルネックは LLM の外側へ移っていく
  • prompt / context / harness の 3 つの engineering ラベルは、この移動の跡として読める
  • 置換ではなく積層であり、担う粒度も個人→チーム→チーム横断へ拡大する
  • 同じメタ法則を当てはめると、次のボトルネックは eval と governance の領域に移っていくと予想

はじめに

prompt engineering、context engineering、harness engineering。この 1〜2 年で「○○ engineering」のラベルが次々に現れました。新しいラベルが出るたびに技法と定義のキャッチアップが積み上がりますが、それぞれの関係はかえって見えにくくなっています。

3 つを並べると、パターンが 1 つ浮かびます。LLM とその周辺が成熟するにつれ、ボトルネックは LLM の外側へ移っていくというパターンです。3 つのラベルは流行語の交代ではなく、ボトルネック移動の跡だと読めます。前段のレイヤーが不要になるわけではなく、重心が移っています。置換ではなく積層です。

Bassim Eledath の L1-L8 分類 [1]のようにレベル別で切る整理もありますが、本記事はボトルネックの移動という切り口で 3 つのラベルを系譜として整理します。各レイヤーが必要になった背景を外部の研究・事例で裏付けたうえで、同じメタ法則を当てはめて「harness の先に来るボトルネック」を著者個人の予想として提示します。

ボトルネックは LLM の外側に押し出されていく

3 つの engineering ラベルの関係を表にまとめます。

レイヤーなぜ必要になったか主な道具ボトルネックの位置担う粒度
prompt eng.モデルが入力の言い回しに敏感だったfew-shot / CoT / role assignmentLLM への入力文個人
context eng.LLM に渡す情報の選別が出力品質を左右するようになったRAG / compaction / sub-agent quarantineLLM に渡す情報の選定個人→チーム
harness eng.情報選定だけでは複数ターンのエージェントを制御できないsubagent 分割 / sandbox / schedulerエージェントの実行環境チーム

各レイヤーの章は、メタ法則「LLM とその周辺が成熟するにつれ、ボトルネックは外側に移っていく」の具体例として読めます。ボトルネックが外に移るにつれ、担い手も個人からチーム、そしてチーム横断へと広がっていきます。

prompt engineering: 「入力をどう設計するか」が律速だった時期

LLM の初期、モデルは入力の言い回しに敏感でした。入力テキストの設計が出力品質を大きく左右した時代です。

GPT-3 の few-shot learning [2]は「例を数個見せるだけでタスクをこなせる」ことを示し、Chain-of-Thought（CoT）

は「思考の手順を書かせると推論精度が上がる」ことを示しました。この時期の中心的な道具は、few-shot の例文選定、CoT の思考手順設計、ロール指定といった、入力テキストの最適化でした。

[3]

ところが、モデルの能力が上がるにつれて、prompt の言い回しによる差は相対的に小さくなってきています。Wharton GenAI Labs の調査では、reasoning model（o3-mini、o4-mini、Gemini 2.5 Flash）に CoT を加えても、大幅な時間コスト増に対して改善は限定的だと報告されています [4]。

CoT の効果が逓減するだけでなく、より洗練された prompt 技法が逆効果になるケースも出てきています。Khan の "Prompting Inversion" 研究 [5]がまさにそれです。Sculpting（ルールベースの制約を付与して意味的曖昧さを減らす prompt 技法）は、gpt-4o では standard CoT を上回っていました（97% vs 93%）。ところが gpt-5 では逆転し、standard CoT が 96% で Sculpting は 94% に落ちています。モデル能力の向上に伴い、制約を加える prompt 技法がかえって足枷になる現象を、Khan は「Prompting Inversion」として定式化しました。

prompt engineering のもう 1 つの特徴は、個人スキルとして閉じていたことです。few-shot の例文をどう選ぶか、CoT の手順をどう書くかは、書き手個人の判断で完結します。レビュー機構や外部検証を組み込まない限り、主観で閉じやすい構造がありました。モデルが賢くなることで、入力の言い回しに頼る必要は薄れました。代わりに浮上したのは「コンテキストをどう構成するか」という問題です。

context engineering: 「コンテキストをどう構成するか」が律速になった

コンテキストウィンドウが数十万〜100万トークン規模に拡大し、トークン上限の制約は大きく緩和されました。しかし、コンテキストウィンドウが広がっても情報を詰め込むほど性能は落ちます。Microsoft と Salesforce の共同研究では、マルチターン会話で平均 -39% の性能劣化が報告されており、o3 でさえ 98.1% → 64.1% まで落ちたとされています [6]。

Anthropic は 2025 年 9 月の記事で context engineering を次のように定義しました [7]。

the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference, including all the other information that may land there outside of the prompts.

「推論時の最適なトークン集合を選別・維持する戦略群であり、プロンプト以外でコンテキストに入りうるすべての情報を含む」という定義です。同記事では 3 つの技法を提示しました。コミュニティでも別の切り口から技法が言語化されています。

出典技法概要
Anthropic 公式Compactionトークンを圧縮して密度を上げる
Anthropic 公式Structured note-taking構造化メモとして情報を永続化する
Anthropic 公式Sub-agent architecturesサブエージェントで情報を隔離・圧縮する
コミュニティRAG必要な情報だけを検索して渡す
コミュニティTool loadoutツール選択を絞り込む
コミュニティContext pruning不要トークンを剪定する

context engineering のレイヤーでは、RAG やサブエージェント分離のように複数コンポーネントを跨ぐ設計が求められます。知識ベースの整備、検索基盤、前処理パイプラインの担い手が分業し始め、設計の担い手が個人から少人数チームへ広がり始めた段階です。

ここまでは「コンテキストをどう構成するか」の話でした。コンテキストの構成が整うと、LLM は単発の応答を超えて、複数ターンで自律的に動くエージェントとして使われ始めます。すると今度は「エージェントをどう制御するか」が律速になります。

harness engineering: 「エージェントをどう制御するか」が律速になっている

エージェントが複数ターン・複数ツールで動くようになり、その実行環境をどう構成するかが性能を左右するようになりました。

Philipp Schmid（Hugging Face / Google DeepMind）は次の比喩を示しました [8]。

Model = CPU


Context Window = RAM
Agent Harness = OS
Agent = Application

モデルが CPU のように安定した部品になるにつれ、OS にあたるハーネスの設計が性能を左右するという見立てです。

Aparna Dhinakaran（Arize AI）は別の角度から、ハーネスをアプリケーションそのもの、サンドボックスをサーバーに例えています [9]。さらに framework と harness の境界について、フレームワーク（LangChain、LangGraph 等）は人間がエージェントを作るための道具であり、ハーネスはエージェントが動く環境そのものだと定義しています

。

[10]

Birgitta Böckeler は martinfowler.com の記事 [11]で、ハーネスの構成要素を 2 軸で分類しました。縦軸は「エージェントを正しい方向に導く仕組み（Guides）」と「エージェントの振る舞いを検知する仕組み（Sensors）」。横軸は「コードやルールで決定的に制御する（Computational）」か「LLM の推論に委ねる（Inferential）」かです。

Computational（決定的に制御）Inferential（推論に委ねる）
Guides（導く） 例: formatter, pre-commit hook, sandbox 制限例: AGENTS.md, Skills, system prompt
Sensors（検知する） 例: テスト, 型チェック, CI チェック例: LLM-as-judge, self-reflection ループ

たとえば、formatter（左上）はエージェントの判断を介さず機械的にコードを整形します。一方、AGENTS.md（右上）はエージェントが読み取って解釈する必要があります。ハーネスの設計では、この 4 象限をどう組み合わせるかが問われます。

定量的な裏付け

Harvey（リーガル AI）は自社ブログ [12]で、モデルを変えずにハーネスだけを改修することで大幅な精度向上を達成したと報告しています。ただし、Harvey 自身が "This is a small-scale experiment" と限定性を認めています。それでも、モデルではなくハーネスが性能を決めた事例として示唆的です。後に Legal Agent Benchmark（LAB）として 1,200 以上のタスク・24 法務領域をカバーするベンチマークを OSS 化しています

。

[12:1]

OpenAI の Codex チームの実験 [13]も同じ方向を指しています。5 ヶ月で 100 万行超のコードを生成し、3 名から 7 名のチームで約 1,500 PR、1 日あたり 3.5 PR・約 10 億トークンを消費しました。エンジニアの役割は「コードを書く」から「環境設計・意図の明文化・フィードバックループ構築」に移っています。

業界誌でも同じ見方が出ています。「異なるラボのフロンティアモデル間の差は大幅に縮小した一方、同じモデルの well-designed harness の有無による差は劇的に拡大した」 [14]。本記事の主張、ボトルネックが LLM の外側に移っているという見方と合致する分析です。

harness engineering のレイヤーでは、Harvey のように組織全体でハーネスを改修する規模感になり、Böckeler の 4 象限はそもそも複数設計者の分業を前提に組まれています。チームの規律として運用される段階に入っています。

こうしてエージェントを本番で動かす基盤は整いつつあります。ここまでが、実践と外部事例で裏付けられた 3 つのレイヤーの系譜です。では、ボトルネックはここで止まるのか。同じメタ法則を当てはめると、その先も見えてきます。

その先: ボトルネックはさらに外側へ

ボトルネックの予測に入る前に、harness レイヤーに起きている変化を押さえておきます。

Anthropic は 2026 年 4 月に Claude Managed Agents [15]をパブリックベータで公開しました。サンドボックス隔離、ツールオーケストレーション、エラーリカバリなど、これまでチームごとに自前で設計していたハーネスの難所を、プラットフォーム側が PaaS として吸収し始めています。

この動きは、前のレイヤーで起きたことの繰り返しです。モデルの能力向上が prompt の言い回しの差を吸収したように、プラットフォームの成熟がハーネスの設計差を吸収していきます。ハーネスが commodity 化するほど、差別化の軸はさらに外側、つまり何を評価するか、誰にどの権限を持たせるかに移っていきます。

ここまで見てきたメタ法則を当てはめると、「harness の次に露呈するボトルネックはどこか」を考えることができます。以下は業界で確立した見方ではなく、著者個人の予測を含みます。

eval: 「出力品質をどう定義するか」

prompt・context・harness の 3 層は、いずれも「エージェントに正しく動いてもらう」ための工夫でした。ハーネスが整えばエージェントは動きます。しかし、動くことと良い結果を出していることは別の問題です。

従来の機械学習であれば accuracy や F1 など確立された指標がありました。生成 AI の自由形式の出力ではそうはいきません。同じ入力に対して妥当な出力が複数ありえるうえ、文章として自然でも事実のズレが紛れ込みます。指標を選ぶのではなく、何をもって良いとするかの基準そのものを用途ごとに設計し、それを検証可能な形で運用に組み込む必要があります。

Galileo は「Eval Engineering」というブランディングとともに eval の CI/CD 統合を推進しています [16]。commit-based（コミットごとに自動実行）、schedule-based（定期実行）、event-driven（イベント駆動）の 3 種のトリガーで eval をリリースパイプラインに組み込む方向性を示しています。2026 年 4 月には Cisco/Splunk が Galileo の買収を発表しており

、eval の産業化を示すシグナルと見ています。「eval engineering」というラベル自体は Galileo 発のブランディング色が強く、Anthropic・OpenAI・Google はいずれも単に「evals」と呼んでいます。しかし、eval の設計・運用が次のボトルネックになるという方向性は、各社の動きからも読み取れます。

[17]

Amazon Bedrock の AgentCore Evaluations [18]は別の切り口です。OpenTelemetry / OpenInference と統合し、エージェントのトレースを統一フォーマットに変換して LLM-as-a-Judge で評価します。observability の文法でエージェント評価を語れるようにする試みです。

eval の自動化が進むほど、eval 自体のバイアスという再帰的な問題も浮上します。Gu らの survey [19]は LLM-as-a-Judge の position bias、length bias、knowledge bias、concreteness bias を体系化しました。Zhou らの研究

でも、judge モデルが多様なバイアスパターンを示すことが報告されています。eval を自動化するほど「eval を eval する」仕組みが必要になるという再帰構造は、このレイヤー固有の難しさです。

[20]

さらに、eval は一度設計して終わりではありません。モデルのアップデート、参照データの変化、利用パターンの拡大、業務ルールの改定によって、以前は適切だった評価基準が機能しなくなることがあります。評価基準を運用の中で更新し続ける仕組みが求められます。

governance: エージェント間の可視性ギャップ

eval で単一エージェントの出力品質が測れるようになったとしても、エージェント同士が通信する A2A（Agent-to-Agent）トラフィックの可視化はそのスコープに含まれません。A2A の可視化には observability の別レイヤーが必要になり、その上にエージェントの identity 管理、通信の監査ログ、権限の動的制御といった設計が積み上がります。

Gravitee の "State of AI Agent Security 2026" [21]（919 人調査）がこのギャップを数字で示しています。A2A 通信に full visibility を持つ組織はわずか 24.4%。21.9% しかエージェントを identity-bearing entity として扱っておらず、45.6% が shared API keys でエージェント間認証を行っています。88% が直近 12 ヶ月で agent security incident を経験しています。

技術側では、MCP Authorization Spec が OAuth 2.1 ベースでエージェント間認証の標準化を進めています [22]。HashiCorp は SPIFFE（ワークロード単位の ID フレームワーク）を AI エージェントに適用し、人間ではなくワークロードに紐づく identity を発行する設計を提示しています

。Trend Micro は Agentic Governance Gateway で、エージェント governance を「identity（誰が）、authority（何の権限で）、action（何をして）、evidence（どう証跡を残すか）」の 4 要素に定式化しました

[23]

。

[24]

規制側でも動きがあります。EU AI Act の GPAI Code of Practice は、汎用 AI モデルの提供者にリスク評価や透明性の義務を課すもので、2026 年 8 月に enforcement が開始される予定です [25]。

NIST も 2026 年 2 月に AI Agent Standards Initiative を発表しました [26]。CAISI（Center for AI Standards and Innovation）が主導し、業界主導の標準策定、MCP・A2A をベースラインとするオープンソースプロトコルの発展支援、エージェント認証やセキュリティ評価の基礎研究の 3 本柱で構成されています。Q4 2026 にはエージェント間連携の標準仕様「Agent Interoperability Profile」の初版リリースが予定されており、エージェントの identity・認可・監査ログの扱いを標準化する方向です。governance は予測ではなく、技術標準・規制の両面で既に形になり始めています。

eval と governance はいずれも、ハーネスの外側で露呈し始めたボトルネックです。定着した engineering ラベルはまだありませんが、技術標準と規制の両面で基盤が整い始めている以上、このレイヤーへの投資判断は遠くない将来に迫られるでしょう。

まとめ

prompt / context / harness の 3 つの engineering ラベルは、LLM とその周辺の成熟に伴うボトルネック移動の跡として読めます。

  • prompt → context → harness の順に、ボトルネックが LLM の外側へ押し出されてきた
  • 各遷移は「前のレイヤーで足りなくなった部分」を引き受けて発達した。置換ではなく積層
  • 担う粒度も個人→チーム→チーム横断へ拡大してきた

同じメタ法則を当てはめると、次のボトルネックは eval と governance の領域に移っていくと予想します。次のラベルが現れたとき、それが流行語なのかボトルネック移動の帰結なのかを見分ける視点として、本記事の整理が役に立てば幸いです。