Harness Engineeringとは何か: 2026年のVibe Codingの次の波
数年ごとに、開発者が技術と関わる方法に変化が訪れます。それは単なる新しいツールではなく、仕事そのものに対する新しい考え方です。2025年、その変化は「vibe coding」という形で訪れました。2026年、それはより構造的なものへと深化しています：「harness engineering」。
harness engineeringとは何か、そしてなぜ重要なのかを理解するには、その起源を遡る必要があります。なぜなら、harness engineeringは孤立して生まれたわけではないからです。これは、人間とAIが協力してソフトウェアを構築する方法の急速な進化における最新のステップであり、vibe codingからprompt engineering、context engineeringを経て今日に至る一連の流れです。
このシーケンスの各ステップは、単なるテクニックのアップグレードではなく、パラダイムシフトを表しています。そして、この全体の軌跡を理解することが、harness engineeringが実際に何であり、なぜ存在し、2026年のソフトウェア開発の最前線で働きたい開発者に何を要求するのかを理解する最善の方法です。
AI支援開発の4つのパラダイム
1. Vibe Coding: 構文よりも意図
2025年初頭、Andrej Karpathyは「coined the term vibe coding」と表現しました。これは多くの開発者がすでに実践していたことです。コードを1行ずつ書くのではなく、自然言語で欲しいものを説明し、AIに生成させ、実行して、うまくいくものに基づいて反復する。すべての行を読むのではなく、問題を感覚的に進めていく。
その名前は半分冗談めかしたものでしたが、実践は現実的で、その意味は深刻でした。ジュニア開発者は自分で書けなかった機能をリリースし、エンジニアリングのバックグラウンドがないファウンダーは動作するプロトタイプを構築し、非技術チームは以前は開発者の関与を必要としたワークフローを自動化しました。「アイデアを持つこと」と「動作するプログラムを持つこと」の間の障壁は、本当に新しいと感じられる方法で崩壊しました。
Vibe codingの核心的な洞察は、欺瞞的にシンプルです：「intent, not syntax, is the primary input.」開発者の仕事は、コンパイラに対する正確な指示を書くことから、AIに目標を明確に伝えることに移行します。コードはコラボレーションの出力となり、媒体ではなくなります。
これは、技術的な流暢さの必要性によってソフトウェア作成から締め出されていたビルダーの世代にとって解放的でした。しかし同時に、新しい問題も露呈しました。すべてがAIによって生成される場合、それが正しいとどうやって知るのか？システムが壊れたとき、書いていないものをどうデバッグするのか？そして、自然言語による単一の説明では不十分なほどタスクが複雑になったとき、次に来るものは何か？
2. Prompt Engineering: 質問の厳密化
Vibe codingはシンプルで限定されたタスクにはうまく機能しました。タスクが複雑になり、出力に一貫性が必要になり、同じプロンプトが異なる日に大きく異なる結果を返すようになったとき、開発者は直感主導のインタラクションの限界にぶつかりました。そこで登場した答えが「prompt engineering」でした。
Prompt engineeringは、入力をより慎重に設計する規律です。どの言葉が重要か？プロンプト内の例は出力にどう影響するか？フレーミングはモデルの動作をどう変えるか？回答する前にステップバイステップで推論するようモデルに求めるべきか、それとも質問を直接与えるべきか？役割を演じさせる場合はどうなるか？
これは依然として単一交換の思考（1つのプロンプト入力、1つの出力）でしたが、即興だったものに厳密さをもたらしました。AIとの対話をコイン投げから反復可能なものに変えました。ある時期、「prompt engineer」はAIを大規模に展開する企業で正当な職種になりました。
Prompt engineeringの限界は、ユースケースがより野心的になるにつれて明らかになりました。それは根本的に脆弱です。モデルが更新されると壊れます。数十のステップにわたって展開するタスクにはスケールしません。各交換を孤立したものとして扱いますが、現実の作業は継続的で文脈的です。プロンプトを最適化することは、信頼できるシステムを構築することと同じではなく、その違いはAI生成の作業を真剣に扱おうとするときに非常に重要になります。
3. Context Engineering: AIの世界を設計する
次のパラダイムシフトは、プロンプトがAIの生成を決定する唯一の要素ではないことを認識することから来ました。同等かそれ以上に重要なのは、プロンプトを取り巻くすべてです。アクセスできるドキュメント、呼び出せるツール、参照できる会話履歴、セッション間で引き継ぐメモリ。
Context engineeringは、その情報環境全体を意図的に設計する実践です。尋ねることだけでなく、AIが見て、記憶し、行動できることです。
ShopifyのCEOであるTobi Lutkeは、広く回覧された社内メモでこれをうまく表現しました。仕事はAIに「タスクを達成するために正確に適切なコンテキスト、ツール、情報を与える」ことです。これは、検索について慎重に考えることを意味します。どの情報がいつ引き込まれるか。セッション間でメモリを管理し、AIが毎回ゼロから始めないようにする。ツール定義を構造化し、AIが利用可能な機能を知り、適切に選択できるようにする。
Context engineeringは、パラダイムを単一交換の最適化から「designing an ongoing collaboration environment」へと移行させました。開発者はプロンプトライターではなく、AIの作業条件のアーキテクトに近づきます。AIが受ける言葉ではなく、AIが動作する情報ランドスケープを形作る人です。
これは意味のあるアップグレードです。優れたcontext engineeringにより、AIエージェントは複数のステップにまたがるタスクを処理し、プロジェクト履歴を参照し、外部ツールを呼び出し、長時間のセッションで一貫した出力を生成できます。しかし、context engineeringは依然として根本的な問いを未解決のままにします。実際のユーザーが依存する本番環境で、これを確実に動作させるにはどうすればよいか？
4. Harness Engineering: 本番環境向けの構築
Vibe codingは意図を与えました。Prompt engineeringは質問を洗練しました。Context engineeringは環境を構築しました。しかし、そのどれも、AIを真剣に展開したいチームが直面する最も難しい問いを完全に解決するものではありません：「how do you take an AI agent that works in a demo and make it work reliably in production?
」これが「harness engineering
」が取り組む問題です。この用語は2026年に注目を集め、Martin Fowler's blogの寄稿者やOpenAI
のチームを含む実務家によって表現されました。「harness」という言葉はソフトウェアテストから借用したものです。テストハーネスは、コンポーネントをテスト可能、観測可能、制御可能にするための足場です。Harness engineeringは同じ考え方をAIエージェントに適用します。Context engineeringがAIが知っていることに焦点を当てるのに対し、harness engineeringは「how the AI behaves
」に焦点を当てます。現実の利害がかかるときに、エージェントの動作を一貫性があり、回復可能で、信頼できるものにする構造、制約、インフラストラクチャです。
ハーネスとは、LLMを本番グレードにするために周囲に置くすべてのものです：Tool definitions and boundaries
: エージェントができることとできないこと。明確なインターフェースは暴走を防ぎ、エージェントの機能を明示的で監査可能にします。State tracking
: エージェントはマルチステップタスクのどこにいるか、すでに何をしたか、何が残っているかを知る必要があります。これがないと、エージェントは長いワークフローで迷子になり、矛盾した出力を生成します。Error recovery
: ツール呼び出しが失敗したとき、モデルが存在しない関数を幻覚したとき、APIが予期しない出力を返したとき、どうなるか？ハーネスは、システムが壊滅的にではなく、優雅に失敗する方法を定義します。Observability
: エージェントが何を、どのような順序で、どのような入力と出力で行ったかを見ることができるか？可観測性がなければ、AIの動作のデバッグは推測に頼ることになります。Architectural constraints
: 「何でも生成できる」というモデルの汎用性を一部手放す代わりに、予測可能性を得る。具体的なパターン。強制された構造。ソリューション空間を制約するガードレール。
OpenAIのあるチームは、Codexエージェントを使って100万行以上のコードベースを保守するためのハーネスを構築し、「一切手入力のコードなし」を意図的な強制機能として文書化しました。5ヶ月後、それを機能させたのはモデルの品質ではなく、ハーネスでした。制約、パターン、そして数千の操作にわたってエージェントの動作を一貫性があり回復可能にする足場でした。
Martin Fowlerの記事が述べるように、harness engineeringは新しい規律ではなく、新しい種類のワークロードに適用されたDevOpsです。それをそう見るのが早ければ早いほど、本番で実際に動作するエージェントを構築できます。
スルーライン：より多くのAIエージェンシー、より良い人間の構造
これら4つのパラダイムを一緒に見ると、進行方向が明確になります。各ステップは「giving AI more agency
」を含みます。要求に応じてスニペットを生成する（vibe coding）ことから、単一交換を最適化する（prompt engineering）、設計された環境で複雑なマルチステップ作業を管理する（context engineering）、本番で実際の結果を伴って自律的に実行する（harness engineering）へ。そして各ステップは、開発者がその増加したエージェンシーを安全で信頼できるものにするために「better structure
」を構築することを要求します。コードを本番にリリースできるAIエージェントの利点を得るには、それを観測可能、回復可能、制約されたものにするハーネスを構築せずに済むことはありません。構造こそが、エージェンシーを価値あるものにする信頼を獲得するものです。
これが、harness engineeringがvibe codingとは別の規律ではない理由です。それは成長したvibe codingです。「デモでは印象的」から「これが実際にソフトウェアを構築する方法」へとパラダイムが成熟したときに起こることです。
この進化が重要な理由
このシーケンスの各パラダイムは、前のものが生み出した問題を解決します。Vibe codingはAI生成コードの可能性を生み出しましたが、予測不能性を導入しました。Prompt engineeringは単一交換レベルで予測不能性を減らしましたが、スケールしませんでした。Context engineeringはAIコラボレーションをマルチステップタスクにスケールさせましたが、本番信頼性は未解決でした。Harness engineeringは、前のパラダイムに欠けていた構造的規律を導入することで本番信頼性を解決します。
これは各パラダイムが置き換えられる物語ではありません。各パラダイムが次のものに包含される物語です。Prompt engineeringは適切に設計されたコンテキストの中で依然として行われます。Context engineeringはハーネスが管理するものの1つです。Vibe codingの本能（意図を明確に記述し、迅速に反復し、実装ではなく結果に焦点を当てる）は、ハーネスレベルで構築するときにも同様に価値があります。レイヤーは蓄積され、互いに打ち消し合いません。
Harness Engineeringの実践での姿
動作するハーネスのコンポーネント
AIエージェントのためのハーネスを構築するには、従来のソフトウェアエンジニアリングがこれまでこのような方法で対処する必要がなかったいくつかの次元にわたる決定が含まれます。Tool design
が基礎です。AIエージェントに与えるすべての機能（ファイルの読み取り、APIの呼び出し、データベースへの書き込み、メッセージの送信）には、明示的なインターフェースと明示的な制限を伴って明確に定義する必要があります。エージェントの動作は、アクセスできるツールとそれらのツールがどのように記述されているかに部分的に依存します。曖昧なツール定義は曖昧な動作を生み、正確なツール定義は正確な動作を生みます。Memory architecture
は、インタラクション間でエージェントがどれだけの連続性を持つかを決定します。ステートレスなエージェントは呼び出し間ですべてを忘れ、単一のコンテキストウィンドウに収まるタスクに限定されます。適切に設計されたメモリシステムにより、エージェントは関連情報を引き継ぎ、過去の決定を参照し、熟練した人間の協力者と同じように段階的に理解を構築できます。Failure modes
は明示的に設計する必要があります。エージェントがステップを完了できないとき、どうするか？リトライする、人間にエスカレーションする、失敗をログに記録して次に進む、または停止する？答えは、特定のデプロイメントコンテキストにおける各オプションの結果に依存します。失敗動作を定義しないハーネスは不完全です。Observability infrastructure
は、エージェントが実際に何をしたかを理解できるようにするものです。ツール呼び出しのログ、入出力、決定ポイント、タイミング情報により、問題のデバッグ、動作の監査、時間の経過に伴うシステムの改善が可能になります。ブラックボックスのように動作するエージェントは、自信を持ってデプロイできないエージェントです。
Context Engineering as Part of the Harness
Context engineeringはハーネスを構築するときに消えるわけではなく、ハーネスのコンポーネントの1つになります。Context engineeringが生み出す検索システム、メモリ構造、ツール定義は、それらの使用方法を管理するハーネスへの入力となります。エンジニアリングチームにとって、これはしばしばエージェントが確実にクエリできる「knowledge infrastructure
」を構築または採用することを意味します。技術ドキュメント、過去のプロジェクト決定、コード履歴、チーム議論。これらはチームのアドホックな閲覧習慣だけでなく、エージェントのニーズに役立つ方法で整理、インデックス化、検索可能である必要があります。passive knowledge capture and intelligent retrievalをサポートするツールは、このフレームワークではハーネスインフラストラクチャの一部となり、オプションの生産性ツールではなく、エージェントの動作を正確で根拠のあるものにするシステムのコアコンポーネントとなります。Engineering teams that have built searchable knowledge basesローカルの技術ドキュメントから検索可能なナレッジベースを構築したチームは、それをそう表現するかどうかにかかわらず、すでにハーネスの1つのレイヤーを構築しています。
2026年の開発者にとっての意味
メンタルモデルは拡大しなければならない
Harness engineeringの実践的な意味は、すべての開発者が一夜にしてAIインフラストラクチャエンジニアになる必要があるということではありません。AIと働くためのメンタルモデルが、プロンプトやコンテキストを超えて構造、制約、システム思考を含むように拡大する必要があるということです。
Vibe codingは依然として価値があります。意図を明確に記述し、迅速に反復する能力はなくなりません。それはより大きなスタックの1つのレイヤーになります。
Prompt engineeringは依然としてスキルです。しかし、それは複雑なシステムにおけるAI出力品質の可能な上限や主要な決定要因ではありません。
Context designはほとんどの開発者が認識している以上に重要です。AIにどのような情報を、どのような形式で、いつ検索するかを与えるか。これらの決定は、個々のプロンプトの選択よりも出力品質を形作り、時間とともに複合します。
エージェントをデプロイする場合、ハーネスが必要です。それが知的に興味深いからではなく、それがなければ開発で動作するエージェントが本番で壊れるからです。ハーネスは、強力だが予測不能なシステムを信頼できるものに変換するものです。
開発者の役割は縮小ではなくシフトしている
この物語のバージョンには、harness engineeringが開発者をより不要にするものとして描くものがあります。AIがコードを書けるなら、なぜエンジニアが必要なのか？実際の姿は異なります。
Harness engineeringは、経験豊富な開発者がキャリアを通じて培ってきたスキルそのものを必要とします。システム思考、失敗モード分析、可観測性設計、インターフェース定義、アーキテクチャ制約。これらはAIが自動的に生成するものではありません。判断、文脈、そして実際に壊れたシステムを構築した経験からしか得られない「何が間違える可能性があるか」の深い理解が必要です。
このスタックの4つのレイヤーすべてを理解する開発者。プロトタイプをvibe codeし、複雑なタスクのコンテキストをエンジニアリングし、検索システムを設計し、本番デプロイのためのハーネスを構築できる開発者は、2026年のソフトウェア開発の最前線で働いています。
The Knowledge Infrastructure Layer
4つのパラダイムすべてを通じて実行され、harness engineeringレベルで最も顕著になるテーマの1つは「knowledge infrastructure」の重要性です。
Vibe codingでは、知識は暗黙的です。AIは、その瞬間に記述したものとトレーニングデータに存在するものに基づいて動作します。Prompt engineeringでは、関連する例とコンテキストをプロンプトに意図的に含め始めます。Context engineeringでは、AIがドキュメント、プロジェクト履歴、チーム知識にオンデマンドでアクセスできるように検索システムを構築します。Harness engineeringでは、ナレッジベースは足場自体の1部となり、エージェントはそれをクエリし、更新し、セッション間で一貫した状態を維持するために依存します。
この進化は、2026年にAIを効果的にデプロイすることを真剣に考えるチームが、ナレッジインフラストラクチャが競争優位性であることをますます発見していることを意味します。人間の生産性だけでなく、AIエージェントの品質と信頼性のために。適切に整理され、最新で関連性の高い知識にアクセスできるエージェントは、盲目で飛ぶエージェントよりも優れた動作をし、その知識レイヤーを構築することは意図的に行わなければならないものです。
よくある質問
harness engineeringはAI safetyと同じですか？
正確には違います。AI safetyは、アライメント、長期的なリスク、社会的影響に関心を持つより広い分野です。Harness engineeringは、本番ソフトウェアシステムにおけるAIエージェントの信頼性と信頼性を高めることに特化した、より限定された実践的なエンジニアリング問題です。場所によっては重なります（どちらも制御可能性と可観測性を重視します）が、harness engineeringはエンジニアリング規律であり、研究アジェンダではありません。
ハーネスをゼロから構築する必要がありますか？
必ずしもそうではありません。LangChain、LlamaIndex、および新興のエージェントインフラストラクチャツールのようなフレームワークは、ハーネスが必要とする部分をカバーする足場を提供します。しかし、フレームワークを使用することは設計決定の代わりにはなりません。どのツールを公開するか、失敗をどう処理するか、何をログに記録するか、メモリをどう構造化するか。フレームワークは出発点であり、完全な答えではありません。
これはMLOpsとどう違うのですか？
MLOpsは機械学習モデルのライフサイクル（トレーニング、評価、デプロイ、モニタリング、再トレーニング）に焦点を当てます。Harness engineeringは、事前学習済みモデルをコンポーネントとして使用するAIエージェントのランタイム動作に焦点を当てます。それらはスタックの異なる部分を扱う隣接する規律です。本番でAIエージェントをデプロイするチームは、おそらく両方のプラクティスを必要とするでしょう。
プロジェクトがharness engineeringを必要とするのはいつですか？
大まかな目安として：AIエージェントが現実世界の結果を伴うアクションを取る場合（データベースへの書き込み、メッセージの送信、コードのデプロイ、購入の実行）、ハーネスが必要です。エージェントが複数のステップにわたって動作し、初期エラーが複合する場合、ハーネスが必要です。エージェントが何をしたかを説明または監査できる必要がある場合、ハーネスが必要です。失敗がユーザー影響やデータ損失を意味する場合、ハーネスが必要です。
パラダイムは動き続ける
Vibe codingが生まれてまだ1年も経たないうちに、harness engineeringは概念として結晶化し始めました。人間とAIが協力する方法の変化のペースは鈍化しておらず、harness engineeringをAI支援開発の方法に関する最終的な言葉として扱うのは間違いでしょう。
この進化のすべてのステップを通じて一貫しているのは、次のパターンです。AIはより多くの能力と自律性を獲得し、人間の開発者はその自律性を生産的に導くためのより良い構造を構築することで応答します。構造はAIを制約して役に立たなくするのではなく、より役立つように制約します。なぜなら、予測可能で回復可能な動作こそが、強力なシステムを実際にデプロイするのに十分信頼できるものにするからです。
この環境で最も効果的になる開発者は、4つのパラダイムすべてを流動的に移動できる人です。迅速なプロトタイピングが必要なときにはvibe codingの本能を使い、一貫性が重要なときにはprompt engineeringの厳密さを適用し、複雑なマルチステップワークフローのためにコンテキスト環境を設計し、実際の本番信頼性が問題になるときには完全なハーネスを構築します。
次の波は前の波を置き換えるものではありません。より良い場所で実行できるようにするものです。
