ハーネスこそがアーキテクチャの半分である

業界では、ある特定の数式が使われている：エージェント = モデル + ハーネス。

もしあなたがモデルでないなら、あなたはハーネスである。この見方は、それ以外のすべてをサポート用のインフラとして扱う。モデルをエンジンとし、ハーネスを単なるシャシーや燃料システムと見なしているのだ。

この論理には欠陥がある。

車は、アクセサリーを備えたエンジンではない。車は、対等なサブシステムからなるシステムである。ブレーキはエンジンのためにあるのではない。電気系統もエンジンのためにあるのではない。ブレーキが故障すれば、車は機能しない。車両が止まれなければ、エンジンの出力など無意味である。

AIエージェントも同様である。

現在のエージェント・アーキテクチャは、検証（verification）、意図（intent）、調整（coordination）を、「ハーネス」という一つの従属的なカテゴリにひとまとめにしている。この誤りが、設計不足のシステムを招いている。

検証はハーネスではない。それは対等なサブシステムである。 意図はサポート用インフラではない。それは生成を制御するサブシステムである。 調整はモデルのラッパーではない。それはマルチエージェントの動作を整合させるサブシステムである。

検証に失敗すれば、エージェントは失敗する。モデルがいかに賢かろうと関係ない。

数学は、このギャップが現実であることを証明している。NISTの証明によれば、いかなる有限のガードレールも、すべての入力に対して普遍的な堅牢性を備えることはできない。より優れたハーネスを構築することでこれを解決することはできない。モデルを完璧にするために、十分な数のルールで包み込むことも不可能だ。ギャップは常に存在する。

業界は、より優れたモデルが最終的にこれらの問題を吸収すると賭けている。だが、それは間違いだ。ハードウェアの歴史が示すように、CPUの高速化によってメモリコントローラーやキャッシュの必要性がなくなることはなかった。各サブシステムには、独自の物理的特性と制約がある。

真のエージェントを構築するには、現在のハーネス・モデルが欠いている4つの要素が必要である：

• 仕様レイヤー：何が「正しい」かを人間が定義した宣言。
• 独立した検証ゲート：モデルそのものではない、機械的なチェッカー。
• 引き算の規律：肥大化を防ぐために、どのコードが存在すべきでないかを決定する手法。
• プロトコルによる調整：単なる共有ファイルシステムではなく、仕様を用いること。

ハーネスはモデルをより優れた生産者にする。仕様レイヤーはシステムに説明責任を持たせる。

その両方が必要だ。もし前者だけを構築するなら、数学が突破不可能であると示している天井に向かって構築していることになる。

ハーネスはアーキテクチャの半分である。欠けているもう半分の正体。

ソフトウェアアーキテクチャについて語るとき、私たちはしばしば「脳」—つまりコアロジック、アルゴリズム、モデル—に焦点を当てがちです。プロンプトを完璧にしたり、重みを調整したり、関数を最適化したりすることに何週間も費やします。しかし、その脳が現実世界で機能することを可能にする「体」—すなわちハーネス（harness）—を忘れてしまうことがよくあります。

「脳」対「体」

脳はロジックです。ハーネスは、インフラストラクチャ、データパイプライン、オブザーバビリティ（可観測性）、エラーハンドリング、そしてデプロイ戦略です。

脳が「何をするか」を決定するのに対し、ハーネスは「どのように、どこで、どの程度の信頼性で」それを行うかを決定します。

ハーネスを構成する要素

ハーネスは単なる「周辺機器」ではありません。それは、ロジックが価値を生み出すために不可欠な、以下の要素で構成される堅牢なシステムです。

1. データパイプライン (Data Pipelines)

ロジックが動作するためには、適切なデータが必要です。データの収集、クリーニング、変換、そしてロジックへの供給を担うパイプラインがなければ、どんなに優れたモデルも機能しません。

2. バリデーションとガードレール (Validation & Guardrails)

入力が正しい形式か、出力が期待される範囲内かを確認する仕組みです。これがないと、システムは予期せぬ入力によって崩壊したり、有害な出力を生成したりするリスクがあります。

3. オブザーバビリティ (Observability)

システムが内部で何を行っているかを把握するための仕組みです。ログ、メトリクス、トレースを通じて、問題が発生したときに「なぜ」それが起きたのかを理解できるようにします。

4. フィードバックループ (Feedback Loops)

システムが実行された結果を収集し、それをモデルの改善やロジックの調整に役立てる仕組みです。これこそが、システムを継続的に進化させるエンジンとなります。

なぜハーネスが欠落するのか

多くの開発者がハーネスを軽視する理由はいくつかあります。

• 目に見えにくい価値: 優れたモデルやアルゴリズムは、デモで見栄えが良く、すぐに成果が分かります。一方で、堅牢なデータパイプラインや監視システムは、問題が起きていないときには目立ちません。
• 複雑性の回避: ハーネスを構築するのは、ロジックを書くよりもはるかに複雑で、地味な作業です。
• 「自分の環境では動く」という錯覚: ローカル環境でのテストは成功しても、本番環境の複雑な相互作用を考慮できて