AIに関する議論における欠落したピース
誰もがAIエージェントについて語っています。テック系のフィードをスクロールすれば、大規模言語モデル（LLM）がフライトを予約したり、コードを書いたり、サポートチケットに回答したりする様子を、たった一つの目を見張るような会話の中で見せるデモが、何十個も見つかるでしょう。そこにあるメッセージは明白です。「ユーザーをLLMに接続すれば、魔法が起きる」というものです。
その幻想は、5分間のデモであれば見事に機能します。しかし、実際のユーザー、実際のデータ、そして実際のお金が介在した瞬間に、その幻想は崩れ去ります。本番環境において、その関係は決して「ユーザー ↔ LLM」だけではありません。それは「ユーザー ↔ LLMを含む複雑なシステム」なのです。誰もそのシステムについて語らない部分、それが「ハーネス（harness）」です。モデルの周囲にあるすべてを選択、ルーティング、保護、そしてオーケストレーションする足場のことです。これなしでは、それは製品ではなく、単なるプロトタイプに過ぎません。
なぜ単純なループでは破綻するのか
デモは制御された環境です。クエリは短く、コンテキストは限定的で、リスクも低いです。開発者が一度APIを呼び出し、流暢なレスポンスが返ってくれば、観客は拍手を送ります。しかし、本番環境は混沌としています。ユーザーは曖昧な追質問を投げかけます。サードパーティのAPIはタイムアウトします。昨日まで完璧なJSONを生成していたモデルが、突然Markdownを吐き出すこともあります。コンテキストウィンドウは一杯になり、最悪のタイミングでレート制限がかかります。
生のプロンプト・レスポンス・ループには、こうした問題への答えがありません。どのモデルのバリアントが特定のタスクを処理すべきかを知りません。3ターン前に何が起きたかを覚えていません。失敗した呼び出しをリトライしたり、コストが急騰したときにリクエストを制限したり、データベースに書き込む前に出力をサニタイズしたりすることもできません。これらはエッジケース（例外的な事象）ではありません。これらこそが、現実世界のソフトウェアを定義づける特性なのです。これらを処理することこそが、ハーネスの役割です。
ハーネスが実際に果たす役割
ハーネスを、言語モデルを「巧妙なテキスト生成器」から「信頼できるサービスコンポーネント」へと変えるエンジニアリング層だと考えてください。その責務は具体的かつ地味なものであり、だからこそ見落とされがちなのです。
目の前のタスクに対するモデルの選択。 すべてのやり取りに、利用可能な中で最も強力な基盤モデルが必要なわけではありません。生の推論能力を必要とするタスクもあれば、単にスピードと低コストを必要とするタスクもあります。優れたハーネスは、リクエストをインテリジェントにルーティングします。例えば、カスタマーサポートのエージェントは、まず高速で安価なモデルを使用して、届いたメッセージの意図（返金リクエストなのか、配送に関する質問なのか）を分類するかもしれません。もしその意図が複雑なポリシーに関する紛争を示唆している場合、ハーネスはそのタスクをより強力な推論モデルへとエスカレーションします。ユーザーが単に追跡リンクを求めているだけであれば、軽量モデルが即座に回答し、バーンレートを低く抑えることができます。
データフローの制御。 本物のアプリケーションは真空状態で動いているわけではありません。AIエージェントは多くの場合、ベクトルストアからドキュメントを抽出し、CRMにクエリを投げ、最近のユーザーのアクティビティを読み取り、それらすべてを統合して一貫した回答を生成する必要があります。ハーネスはそのインジェクション（取り込み）を管理します。適切なコンテキストのチャンクを取得し、関連性を失わずにトークン制限内に収まっているかを確認し、モデル向けに構造化し、その結果得られた出力をチェーン内の次のシステムへと渡します。このオーケストレーションがなければ、モデルはコンテキスト不足に陥るか、あるいはノイズに溺れてしまいます。
エラー管理。 LLMは、従来のサービスとは異なる方法で失敗します。構造化された出力をハルシネーション（幻覚）させたり、空の補完を返したりします。基盤となるモデルのバージョンがわずかに変わっただけで、フォーマットの指示に違反したりします。ハーネスは、これらの失敗を「驚き」ではなく「想定内の挙動」として扱います。スキーマを検証し、不正な形式のレスポンスをキャッチし、指数バックオフを用いたリトライロジックを適用し、プライマリのエンドポイントが躓いた場合にはセカンダリのプロバイダーやキャッシュされた結果へとフォールバックします。すべてが失敗した場合には、支払っている顧客に対して黙ってデタラメな回答を出すのではなく、人間のオペレーターへとエスカレーションします。
システムの信頼性の確保。 本番環境とは、同時ユーザー、コスト上限、そして予測不可能なレイテンシを意味します。ハーネスはレート制限を適用し、コネクションプーリングを管理し、サーキットブレーカーを実装することで、一つの動作の遅いモデルプロバイダーによってアプリケーション全体がフリーズすることを防ぎます。また、すべてのやり取りをログに記録するため、特定のセッションがなぜ脱線したのかを追跡できます。さらに、プロンプトのバージョニングを行うことで、デプロイによって監査証跡なしにエージェントのパーソナリティが誤って書き換えられてしまう事態を防ぎます。
同じモデル、全く異なる結果
これは多くのプロダクトチームを困惑させている現象を説明するものです。2つの企業が、全く同じ基盤モデル（同じ重み、同じコンテキストウィンドウ、同じ学習カットオフ）からスタートしたとしても、全く別物と感じられる体験を提供できることがあります。一方は、動作が不安定で、遅く、妙に忘れっぽい。もう一方は、軽快で、一貫性があり、信頼できる。
その違いは、決してモデル自体にあるのではありません。モデルを包み込む「システム」にあります。あるチームはモデルを製品そのものとして扱いました。別のチームは、規律あるアーキテクチャの中の一つのコンポーネントとして扱いました。その規律が宿る場所こそが、ハーネス（harness）なのです。
プロンプトからアーキテクチャへの転換
初期のAI開発では、プロンプトエンジニアリングが中心でした。言い回しを微調整したり、例を追加したり、ロールプレイの指示を重ねたりすることで、出力の質を劇的に向上させることができました。そのスキルは今でも重要ですが、競争上の優位性（モート）としての効果は収穫逓減の時期に入っています。リトライポリシーの欠如や、プライベートなコンテキストが公開レスポンスに漏れ出してしまうような、絡まり合ったデータパイプラインの問題を、プロンプトだけで解決することはできません。
今まさに起きている真の転換は、ソフトウェアアーキテクチャへの移行です。エンジニアは状態マシンを設計し、モデルレイヤーとアプリケーションロジックの間に厳格なインターフェースを定義し、非決定性を第一級のエンジニアリング上の懸念事項として扱っています。彼らは分散システムの問いを投げかけています。マルチターンの会話において状態はどう保持されるのか？ 下流のツールが利用できない場合はどうなるのか？ コアコンポーネントが確率的なシステムのテストはどう行うのか？ これらが、「おもちゃ」と「ツール」を分ける問いなのです。
本番環境に向けた構築：オブザーバビリティとコントロール
本格的に製品をリリースしようとするなら、ハーネスには何よりも「オブザーバビリティ（可観測性）」と「オーケストレーション」という2つの資質が求められます。
オブザーバビリティとは、モデルが何を受け取り、何を返し、各ステップにどれくらいの時間がかかったかを確認できることを意味します。それは、エージェントの意思決定ループを14回ものツール呼び出しにわたって追跡し、どこでループが発生したか、あるいはどこで目的から逸脱し始めたかを正確に特定できることを意味します。その可視性がなければ、AIシステムのデバッグは暗闇の中で車のエンジンを修理するようなものです。
オーケストレーションとは、ビジネスロジックがモデルとのインタラクションレイヤーから分離されていることを意味します。プロンプトをコードと同じようにバージョン管理し、新しいデプロイによって動作が密かに変わることがないようにすることを意味します。また、APIをリクエストの途中で停止させる、不正なツール結果を入力する、コンテキストウィンドウのオーバーフローをシミュレートするなど、失敗モードを意図的にテストし、ハーネスがシステムを維持できるかを確認することを意味します。フレームワークは次々と現れては消えていきますが、既製品のオーケストレーションライブラリを採用しようが自作しようが、重要なのはブランド名ではなく、その規律（discipline）です。
真の教訓
基盤モデルは進化し続けるでしょう。より速く、より安く、より高性能になっていくでしょう。しかし、より強力なエンジンが、壊れたシャシーを直してくれるわけではありません。今後数年間で勝利を収めるチームは、最も豪華なモデルへのアクセス権を持っているチームではありません。信頼性が高く、オブザーバビリティに優れ、適切にオーケストレーションされたハーネスを構築したチームです。彼らはアプリケーションを書き直すことなくモデルを入れ替えることができます。ハーネスがすべてのトークンを制御しているため、コストを管理できます。システムが優雅に失敗（fail gracefully）するため、彼らは夜もぐっすり眠れるのです。
モデル単体に執着するのはやめましょう。それを動かすシステムに執着し始めてください。未来は、スマートなモデルの周囲に、よりスマートなシステムを構築するエンジニアたちのものです。
この記事は、Abdulaziz Zos氏が "Beyond The Model" で最初に論じたアイデアに基づいています。
AIエンジニアリングとシステムデザインに関するさらなる議論については、GyaanSetu learning community をチェックしてください。