自社ビジネスに最適化したカスタム Agent Harness をいかに設計・構築するか？

特定の業務に特化した AI Agent を構築する際、開発者が真に決断すべき極めて重要な問いは、往々にして「どの最強モデルを選ぶか」ではなく、対象タスクにおける具体的な実行要件を明らかにすることにあります。すなわち、そのタスクはどのようなコンテキストを必要とするのか（context it needs）、どのような潜在的障害に直面するのか（failures it'll encounter）、どのようなポリシーを強制執行しなければならないのか（policies it must enforce）、そしてどのような実環境で動作するのか（environment it operates in）という点です。これら4つの側面こそが、原文において Task-Harness Fit（タスクと実行基盤の適合度） を定義する際に明示された中核的な評価基準です。

真に実用的なエージェントを構築する本質は、カスタマイズ（Customization）にあります。つまり、特定のタスクにおいて、エージェントを必要なコンテキスト、データ、および実行環境にいかに接続するかということです。モデルの外部を包み込み、この接続を実現するエンジニアリング上の実体こそが Agent Harness（エージェント実行基盤／ハーネス） です。なお留意すべき点として、原文はそのまま使える完全な業務実装チュートリアルを提供しているのではなく、極小プリミティブを核としてミドルウェアを活用し、業務に合わせて Harness をテーラーメイドに設計・カスタマイズするためのアーキテクチャ上の道筋を体系的に解説しています。

概念の分離：Harness とは何か？ なぜ「Agent = Model + Harness」なのか？

最も本質的なレベルにおいて、エージェントとは、タスクが完了して結果を返すまで、ループ内で外部ツールを継続的に呼び出し続けるモデルにすぎません。

この実行メカニズムは、ひとつの核心的な数式で明確に表現できます。

Agent = Model + Harness

ここでの Harness とは、大規模言語モデル（LLM）の外部を包み込み、それを現実世界と接続する役割を担う足場（スキャフォールディング）エンジニアリング全体を指します。

このアーキテクチャ上の認識は、次の2つの前提に基づいています。

1. エージェントの実際のパフォーマンスは、モデルに提供されるコンテキストの品質によって決まる（An agent is only as good as the context provided to the model）；
2. Harness の核心的な責務は、ループのすべてのステップにおいてモデルに必要なコンテキストを的確に提供することである（The job of a harness is to provide context to the model at every step）。

したがって、真に実用的なエージェントを構築するためには、特定タスクに対して適切なタイミングかつオンデマンドで正しいコンテキストをモデルへ供給することに長けた Harness を組み上げる必要があります。

極小プリミティブと事前組込型基盤の分岐点：なぜ create_agent を選ぶのか？

LangChain エコシステムにおいて、カスタム Harness を構築するための基盤プリミティブこそが create_agent です。モデル、ツールセット、およびシステムプロンプトを渡すだけで、正常に動作するエージェントが得られます。

from langchain.agents import create_agent

agent = create_agent(
    model="anthropic:claude-sonnet-4-6",
    tools=tools,
    system_prompt="you are a helpful assistant..."
)

エンジニアリングの選定において、市場にはまったく異なる2つの基盤構築アプローチが存在します。

• 事前組込型 Harness（Pre-assembled Harnesses）：Deep Agents や Claude Agent SDK などがこれに該当します。これらはメモリ、コンテキスト管理、サンドボックスなどのコンポーネントを含む、明確な設計方針を持ったミドルウェアスタックを最初から備えています。この種の実行基盤は、チームが本番環境で即座に利用可能な Agent を迅速に得ることを目指しており、多くのユースケースに適しています。しかし、多くの Agent は専用プロンプト、業務ロジック、ガードレールなど、既製の基盤が提供するものよりもきめ細かなカスタマイズ制御を依然として必要とします。
• 意図的に極小化されたプリミティブ路線（Purposefully Minimalistic Primitive）：create_agent は異なるアプローチを採用しており、その設計思想は柔軟な設定が可能なコードエージェント Harness である Pi に類似しています。create_agent は最も中核となるエージェントループのみを実装し、ミドルウェア（Middleware）をカスタマイズ用プリミティブとして公開しています。

ミドルウェア機構：4つのレバーで Harness をいかに精緻にカスタマイズするか？

ミドルウェアは、Harness を高度にカスタマイズするための中核的な手段です。ミドルウェアは、Agent の実行サイクルの各段階（モデル呼び出しの前後、ツール呼び出しの前後、ならびにエージェントの起動時および終了時）に直接フックできます。各ミドルウェアは単一の関心事を独立して処理し、他のミドルウェアと自由自在に組み合わせることが可能です。

ミドルウェアを通じて、開発者は相乗効果を発揮する以下の4つの「エンジニアリングレバー」を駆使し、業務要件に応じて実行基盤を精緻にカスタマイズできます。

1. 決定論的ロジック（Deterministic Logic）：
   • 解決する設計課題：業務ルール、ポリシーの強制執行、動的なランタイム制御など、実行サイクルの特定タイミングでトリガーされる必要があり、プロンプト（Prompt）内にすべて詰め込むには適さない処理。
   • メカニズムと原文の例：ループ内の特定ノードでトリガーされる決定論的コードです。原文が明示する主要ユースケースはエージェント実行時の動的制御であり、タスクの複雑度に応じたモデルの動的切り替え（swapping the model based on task complexity）、プロンプトの動的調整（adjusting the prompt）、ならびにコンテキスト圧縮時のメッセージ履歴の更新（updating the agent's message history, during compaction, for example）が含まれます。プロンプトに記述できない、あるいは記述すべきでないロジックは、すべてここに分類されます。
2. ツールのライフサイクル管理（Tools）：
   • 解決する設計課題：ツールに外部依存関係が存在したり、初期化や終了時のクリーンアップが必要な場合、エージェントへ単にツールを直接登録するだけでは、設定や統制ロジックが散乱してしまいます。
   • メカニズムと原文の例：ツールをエージェントに直接静的登録するのではなく、ミドルウェアがツールのライフサイクル全体（初期化セットアップ（setup）、終了時のクリーンアップとティアダウン（teardown）、動的登録（registration））を完全に引き受け、ツールの依存関係を適切に管理して、最終的にクリーンで整頓されたツールセットをエージェントに提供します。これにより、ツール設定とその背景にある制御ロジックの凝集度が高まり、設定の分散を防止できます。
3. カスタム状態（Custom State）：
   • 解決する設計課題：異なるライフサイクルフック間で、業務上の状態を継続的に記録し共有する必要性。
   • メカニズムと原文の例：カスタムプロパティによってエージェントの状態オブジェクトを拡張します（extend the agent's state with custom properties）。原文では、これによりミドルウェアが実行サイクル全体を通じてカウンター（counters）、状態フラグ（flags）、またはその他の永続的な値を保持し、異なるフック間でデータをシームレスに共有できるようになると明記されています。
4. ストリームハンドラー（Stream Handlers）：
   • 解決する設計課題：エージェントの出力ストリームに含まれる異なるイベントを、UI、監査、監視といった異なるコンシューマーへ振り分けて処理させる必要性。
   • メカニズムと原文の例：ミドルウェアは出力ストリームをインターセプトして再形成できます（イベントのフィルタリング（filtering events）、メタデータの注入（injecting metadata）など）。そして、種別ごとのイベントを異なるコンシューマーへルーティングします。原文が挙げる代表的なユースケースには、リアルタイムのタイピング表示を実現するためのフロントエンド UI によるトークン増分（token deltas）の消費、コンプライアンス証跡を残すための監査ログシステムによるツール呼び出し（tool calls）のキャプチャ、サービスの安定性を担保するための監視システムによるレイテンシ（latency）の追跡があります。

ミドルウェア機構の核心的なエンジニアリング価値は次の2点にあります。

1. エージェントのライフサイクルにおける任意のインターセプトポイントでシームレスなカスタマイズを可能にすること；
2. 関連するエンジニアリングロジックを、独立して疎結合であり、自由に組み立て可能で、プロジェクト間で再利用可能なコードユニットへとカプセル化すること。

LangChain は一般的なパターンを網羅するビルトインミドルウェア（Prebuilt Middleware）を提供しています。独自の要件がある場合は、カスタムミドルウェア（Custom Middleware）を作成することも可能です。各ミドルウェアは相互に独立しているため、同じミドルウェアを組織内で再利用でき、新しい Agent に検証済みの振る舞いを継承させることができます。

業務タスクからの逆算：8大ケイパビリティ要件とミドルウェアのマッピング

Harness の究極の使命は、ループのすべてのステップにおいて、現在のタスクに正確に合致したコンテキストをモデルに届けることです。

Harness の構築とは、すべてのミドルウェアを無差別に組み込むことではありません。原文では、エージェントが最終的に採用すべきミドルウェアの組み合わせは、具体的タスクの中核的要件、すなわち長時間実行されるのか（is it long running?）、タスク自体がどれほど複雑か（how complex are the tasks?）、そしてエージェントが実行するアクションがどれほどセンシティブか（how sensitive are the agent's actions?）に依存すると明記されています。カスタマーサポート Agent と長時間稼働するコーディング Agent では求められる Harness が明確に異なりますが、原文はこれら2つの業務に対して固定の組み合わせを規定していません。

業務設計メソッド：タスク要件から逆算する Harness のアセンブリ

「自社の業務要件に基づいたカスタム Harness をいかに設計・構築するか」というテーマに沿って、原文の Task-Harness Fit に関する4つの側面と公式ケイパビリティマップを組み合わせることで、業務開発者向けの逆算型設計メソッドを導出できます（注：これは原文の Task-Harness Fit の検討事項とケイパビリティ表を統合した読者向けの活用手法であり、LangChain 公式が提示した固定の4ステップ規範ではありません）。

1. タスクの使命（Mission）の明確化：まず、エージェントが達成すべき中核的な業務目標、実行境界、および期待される成果物を明確にします。
2. 4大側面による特徴の洗い出し（Context / Failures / Policies / Environment）：
   • コンテキスト（Context）：セッションは長大なマルチターン対話か、それとも1回限りのQ&Aか？ 起動時に関連知識を読み込み、終了時に知見を蓄積するメモリコンポーネントが必要か？
   • 潜在的障害（Failures）：モデルやツールにおいて、予測不能な一時的障害（transient failures）がどの程度発生し得るか？
   • ポリシーのレッドライン（Policies）：個人識別情報（PII）のマスキング、コンプライアンスチェック、あるいは人間による事前承認が必須となる高機密アクションが存在するか？
   • 実行環境（Environment）：エージェントは制約されたデータ環境で動作するのか、それともファイルシステム、コマンドライン、コードインタープリターなどのより広範な実行環境へのアクセスが必要か？
3. 8大コア機能からのオンデマンド選定：洗い出した特徴に基づき、後述の8つの能力から現在の業務に真に必要なものを厳選し、無駄な機能の積み増しを避けます。
4. 具体的ミドルウェアの組み合わせへのマッピング：選定した能力を LangChain のビルトインミドルウェアへ直接対応させるか、カスタムミドルウェアを実装し、それらを create_agent のループへ組み込みます。

下表は、原文に整理されている8つの本番コアケイパビリティ要件、その背景にある重要性、および公式に対応するビルトインミドルウェアのマッピング関係を示しています。

ビルトインミドルウェアの完全な定義と解説については、公式の Prebuilt Middleware リファレンスドキュメントを参照してください。

タスクと実行基盤の適合（Task-Harness Fit）：カスタム Harness を検証する

Task-harness fit（タスクと実行基盤の適合度）は、Harness が業務タスクの真の要件にどれほど合致しているかを測る指標です。すなわち、必要とされる具体的なコンテキスト（the context it needs）、直面し得る障害の種類（the failures it'll encounter）、強制執行すべきセキュリティ・コンプライアンスポリシー（the policies it must enforce）、そして動作の拠って立つ実行環境（the environment it operates in）との適合度です。前述のとおり、カスタマーサポート Agent と長時間稼働するコーディング Agent では、Harness の構造は根本的に異なります。

LangChain は記事の中で、いずれも create_agent をベースとし、それぞれのタスクに合わせてミドルウェアスタックを組み上げた3つの自社製 Agent を挙げています。

• GTM agent
• Open-SWE：非同期コードエージェント（Asynchronous coding agent）
• Fleet：ノーコードエージェントビルダー（No-code agent builder）

優れたエージェントは、強力なモデルだけに依存するのではなく、具体的タスクに高度に適合した Harness にも依存します。LangChain が提示する直接的なアプローチは、create_agent とミドルウェアを組み合わせて、このようなカスタム基盤を組み上げることです。

カスタム Harness 最小設計セルフチェックリスト

これらの原則を実際の業務シーンへ持ち帰る際には、原文の4つの側面およびケイパビリティマップに由来する以下の問いを用いて、迅速なセルフチェックを実施できます。

1. コンテキストとメモリ（Context & Memory）：
   • タスクは長時間稼働するセッションを伴うか？ ウィンドウの溢れを防ぐため、コンテキスト要約や編集ミドルウェアを構成する必要があるか？
   • エージェントは起動時に外部の知識／スキルを読み込み、実行終了時に新たな知見をメモリへ書き戻す必要があるか？
2. 耐障害性とコスト（Failures & Costs）：
   • 外部モデルやツールで予測不能な一時的障害が発生した際、バックオフ再試行やフォールバックモデルのミドルウェアが備わっているか？
   • 長時間タスクのトークンコストを低減するためのプロンプトキャッシングが設定されているか？ コストの継続的な累積を防ぐため、モデルやツールの呼び出し回数制限が設けられているか？
3. ポリシー制約と人間の介在（Policies & Steering）：
   • 業務内に PII マスキングやコンプライアンス審査などのルールが存在するか？ それらはミドルウェアを介して呼び出しごとに漏れなく強制執行されているか？
   • 影響度の高いアクションや機密操作に対し、処理を一時停止して人間の承認・拒絶・再指示を待つ Human-in-the-Loop 機構が組み込まれているか？
4. 実行環境とタスク協調（Environment & Delegation）：
   • エージェントは固定のツールセットを超え、ファイルシステム、コマンドライン、コードインタープリター環境にアクセスして行動力とトークン効率を高める必要があるか？
   • 複雑な長大タスクに直面した際、それを分解して独立したクリーンなコンテキストを持つサブエージェントに委任するか、あるいは ToDo リストで進捗を追跡する必要があるか？
   • ツールの依存関係、初期セットアップ（setup）、および終了時クリーンアップ（teardown）はミドルウェアによって統制されているか？
   • 出力ストリームを個別に処理する必要があるか（フロントエンドでのトークン増分の消費、監査ログでのツール呼び出しの記録、監視システムでの遅延レイテンシの追跡など）？

参考リソース・関連リンク

公式ガイドおよびドキュメント

• クイックスタート：create_agent を用いた最初のエージェント構築
• create_agent コア開発ガイド
• ビルトインミドルウェアリファレンス一覧（Built-in Middleware）
• カスタムミドルウェア開発ガイド（Custom Middleware）
• Deep Agents：create_agent をベースに構築された本番水準の事前組込型 Harness