エグゼクティブサマリー

ハーネスエンジニアリング (Harness Engineering) は、エンタープライズ環境向けの信頼性の高いエージェントシステムを構築する責任を担う、新たなエンジニアリング規律です。大規模言語モデル（LLM）は確率的な次のトークンの予測器ですが、エンタープライズが必要とするのは、タスクを実行し、ポリシーを遵守し、安全に失敗する、信頼性の高いシステムです。ハーネスとは、モデルの周囲に設計されたすべてのもの（メモリ、ツール、プランニング、オーケストレーション、オブザーバビリティ、評価、ガバナンス、セキュリティ）であり、両者の間のギャップを埋めるものです。本章では、この規律を定義し、そのテーゼを述べ、ハンドブックの残りの部分の枠組みを示します。

主要概念

モデル (Model): コンテキストを次のトークンの分布にマッピングする確率的なコア（LLMまたはマルチモーダルモデル）。強力ですが、デフォルトではステートレスで、ガバナンスが効かず、非決定論的です。
ハーネス (Harness): 信頼性の高いシステムを構築するために、1つ以上のモデルの周囲にラップされた、決定論的および半決定論的なエンジニアリングの足場。
エージェントシステム (Agentic system): モデルが、目標を追求するためにツールや環境に対して認識、推論、行動のループを駆動するシステム。
信頼性 (Reliability): 実際の条件および負荷の下で、システムが正確で安全、かつポリシーに準拠した結果を出力する確率。
決定論の境界 (Determinism boundary): モデルに決定を委ねる部分と、ハーネスがコードで固定する部分を分ける意図的な境界線。
エンタープライズ環境 (Enterprise environment): 規制データ、監査要件、SLA、攻撃者など、現実のリスクが存在する環境。

定義

ハーネスエンジニアリング (Harness Engineering) とは、確率的モデルを取り囲むシステムの設計、構築、および運用に関わる新たなエンジニアリング規律であり、結果として得られるエージェントシステムが、エンタープライズでの使用に耐えうる十分な信頼性、オブザーバビリティ、ガバナンス、およびセキュリティを備えるようにすることを目的としています。機械学習がモデルを生み出すのに対し、ハーネスエンジニアリングはシステムを生み出します。その作業単位は、プロンプトや重み行列ではなく、目標を検証可能で監査可能な結果へと変換するエンドツーエンドのループです。

アーキテクチャ図

flowchart TB
  subgraph Harness[\"ハーネス（設計された足場）\"]
    direction TB
    PL[プランニングと目標管理]
    OR[オーケストレーション]
    MEM[メモリ]
    TL[ツール / アクチュエーション]
    OBS[オブザーバビリティ]
    EVAL[評価]
    GOV[ガバナンス]
    SEC[セキュリティ]
  end
  USER([目標 / リクエスト]) --> PL
  PL --> OR
  OR <--> MODEL{{確率的モデル}}
  OR <--> MEM
  OR <--> TL
  TL <--> ENV[(エンタープライズシステムとデータ)]
  OBS -.計測.- OR
  EVAL -.スコアリング.- OR
  GOV -.制約.- OR
  SEC -.保護.- TL
  OR --> OUT([検証済みで監査可能な結果])

詳細な説明

業界は2020年から2023年にかけて、より優れたモデルが必要条件ではあるものの、十分条件ではないことを学びました。厳選されたプロンプトで人々を魅了するデモも、本番環境では、曖昧な入力、悪意のあるユーザー、古いデータ、ツールの一部の障害、および同じ入力でも2回目には異なる出力が得られるという単純な事実によって崩壊します。その対策は「よりスマートなモデル」ではなく、モデルの周囲に設計されたシステムでした。そのシステムこそがハーネスであり、それを適切に構築すること自体が独自の規律となります。

本ハンドブックの中心的な主張は、関心の分離です。モデルは自由度の高い推論と言語を提供し、ハーネスはその推論を信頼できるものにするためのすべてを提供します。モデルを、優秀で迅速だが、信頼性の低い契約社員として扱ってください。そのような契約社員に対して、スコープも、ログ記録も、レビューも、ロールバックもなしに、監視されていない本番環境へのアクセス権を渡すことはないでしょう。ハーネスとは、そのスコープであり、ログ記録であり、レビューであり、ロールバックなのです。

モデルはシステムではありません。 有用なメンタルモデルは、モデルを差し引いて何が残るかを問いかけることです。残るものがハーネスであり、そこにエンタープライズエンジニアリングの取り組みの圧倒的多数が存在します。

メモリ (Memory) は、モデルが何を見るかを決定します。何が取得され、圧縮され、記憶され、忘れられるかです（HRN-005を参照）。
ツール (Tools) は、型定義されたコントラクトと失敗のセマンティクスを持ち、エージェントが世界に対してどのように行動するかを定義します。
プランニング (Planning) は、目標を分解し、サブゴールと再計画を管理します。
オーケストレーション (Orchestration) は、誰が、どのようなコンテキストでモデルを呼び出し、出力に対して何が起こるかというループを実行します。
オブザーバビリティ (Observability) は、すべてのステップを追跡可能で再現可能なスパンにします（HRN-006を参照）。
評価 (Evaluation) は、「うまく動いているようだ」という感覚を、測定され、回帰から保護された品質へと変換します（HRN-007を参照）。
ガバナンス (Governance) は、ポリシー、承認、および説明責任を強制力のあるコントロールとしてコード化します。
セキュリティ (Security) は、モデルを信頼できない、操作可能なコンポーネントとして扱い、それに応じて防御します。

これらはオプションの追加機能ではなく、荷重を支える構造そのものです。HRN-003のタクソノミーは分解を正確に行い、HRN-004はこれらすべてに共通するエンジニアリング原則を述べています。

なぜ新しい規律が必要なのか？ それは、失敗モードが新しいからです。古典的なソフトウェアは決定論的です。入力を与えれば同じ出力を計算し、アサーションを使用してテストします。エージェントシステムは確率的かつ自律的です。同じ入力であっても、異なる経路をたどり、異なるツールを呼び出し、異なる（時には誤った）結論に達することがあります。アサーションだけで確信を得ることはできません。分布を測定し、モデルの権限を制限し、すべてを計測する必要があります。確率的信頼性、評価設計、プロンプトおよびコンテキストエンジニアリング、ツールコントラクト設計、敵対的セキュリティなど、求められるスキルは、従来のMLや従来のバックエンドエンジニアリングのいずれにも明確には当てはまりません。そのギャップこそが、この規律なのです。

なぜ新たな規律であり、単なる規律ではないのか？ 正直な答えには4つの部分があり、それらは等しく強力ではないからです。異なるハーネスの下で同じモデルが異なる結果をもたらすということは、観察された事実です。実践が同じ関心事（コンテキスト、ツール、評価、オブザーバビリティ、制御）に収束しつつあるというのは、業界の動向分析です。これらの関心事が独自の規律を構成しているというのは、中程度の確信度で保持されている私たちの立場です。認定制度も、標準的なカリキュラムも、合意された知識体系も、専門機関も存在しないため、これを確立されたものと呼ぶのは、実証できる以上のことを主張することになります。モデルではなくハーネスが永続的な競争資産になるというのは、低い確信度で保持されている賭けです。これらはそれぞれ、その限界とそれを撤回させる観察結果とともに、HE-CLAIM-001からHE-CLAIM-004として個別に公開されています。get_claimで問い合わせてください。

対象読者。 ハーネスエンジニアリングは、エージェントを重要な本番環境に導入する責任を負うチームを対象としています。エージェントランタイムを構築するプラットフォームエンジニア、エージェント機能をリリースするMLおよび応用AIエンジニア、承認を行うセキュリティおよびガバナンス部門、そして全体を統括するアーキテクトです。これは明確にエンタープライズファーストです。この規律を定義する制約（監査、規制、SLA、攻撃者、スケール）は、まさにホビイスト向けのツールが無視するものです。

率直に述べられた意見： モデルはますますコモディティ化しており、ハーネスこそが永続的なエンジニアリング資産であり、参入障壁（モート）です。フロンティアモデルが収束し、交換可能になるにつれて、エンタープライズAIシステムの差別化され、防御可能な価値はハーネス（そのメモリ構造、評価コーパス、ガバナンスコントロール、オブザーバビリティ）へと移行します。ハーネスへの投資は、複利効果を生む部分への投資です。

観察された失敗モード

モデル中心の思考: チームはプロンプトの微調整やモデルの選択に過剰に投資する一方で、ハーネスへの投資を怠り、システム全体の失敗をモデルのせいにします。
デモから本番への崖: ハッピーパスのデモで動作するシステムには、メモリの規律も、オブザーバビリティも、評価も存在しないため、実際の負荷に耐えることができません。
無制限の権限: 決定論的なコードで固定されるべき事項をモデルに決定させてしまい、回復不能または監査不可能なアクションを引き起こします。
測定の欠如: 評価がなければ、デグレード（先祖返り）が密かにリリースされ、「改善」はエビデンスではなく単なる感覚（バイブス）になってしまいます。

コスト指標

単純なシステムにおける主なコスト要因は、モデルの推論（入力/出力トークン）です。適切に設計されたハーネスは、メモリ圧縮、キャッシュ、安価なモデルへの安価なリクエストのルーティング、および決定論的ロジックによるショートカットを通じてこれを削減します。その一方で、オブザーバビリティのストレージや評価の実行に対するわずかな固定コストが追加されます。成熟したハーネスは通常、コールごとの推論から償却インフラへと支出をシフトさせ、リクエストごとの計測が増加しても、成功したタスクあたりのコストを削減します。

スケーリング特性

システムがどのようにスケールするかを決定するのは、モデルではなくハーネスです。並行性、メモリのステートフル性、オーケストレーションのファンアウト、およびツールのバックプレッシャーが、スループットとテールレイテンシを支配します。信頼性は、タスクの複雑さ（ステップ数とツール数）に応じて非線形に低下する傾向があります。そのため、ハーネスは固定された成功率を前提とするのではなく、段階的な機能縮退（グレースフルデグラデーション）を考慮して設計される必要があります。

参考文献

エージェントシステムにおける「デモと本番のギャップ」に関する業界の観察（2023〜2026年）。
エージェントアーキテクチャ、ツールの使用、およびLLMオーケストレーションフレームワークに関する実務者向け文献。
Santa María, S. — 規律としてのハーネスエンジニアリングに関するワーキングノート。

FAQ

Q: ハーネスエンジニアリングは、プロンプトエンジニアリングの名前を変えただけですか？ A: いいえ。プロンプトエンジニアリングは、単一のモデルインタラクションを最適化します。ハーネスエンジニアリングは、モデルを取り囲む信頼性の高いシステム全体（メモリ、ツール、オーケストレーション、オブザーバビリティ、評価、ガバナンス、セキュリティ）を構築します。プロンプティングは、1つのコンポーネントに対する小さな入力の1つにすぎません。

Q: モデルが改善され続ければ、ハーネスは不要になりませんか？ A: その逆です。より優れたモデルはエージェントが試みるタスクの限界を押し上げ、それによってリスクと、ハーネスが管理、監視、保護しなければならない領域が増加します。ハーネスこそが、エンタープライズの信頼性と差別化が宿る場所です。

Q: どこから始めればよいですか？ A: まずHRN-003（タクソノミー）を読んでコンポーネントをマッピングし、次にHRN-004（原則）を読んでください。何かを最適化する前に、オブザーバビリティ（HRN-006）による計測を開始してください。測定できないものを改善することはできません。

ハーネスエンジニアリング (Harness Engineering)：定義と概要