LangChainが2026年6月3日に公開したブログ記事「How to Build a Custom Agent Harness」を読んだ。create_agent とミドルウェアによるエージェント設計の考え方をまとめた内容で、自社でAIエージェント事業を進めている立場から、いくつか思うところがあったので整理しておく。
要点（記事の事実）
- エージェント = モデル + ハーネスという定式を提示。ハーネスとは、モデルを現実の環境に接続する「足場（scaffolding）」。
- LangChainの
create_agentは意図的にミニマリスティックな設計で、コアのエージェントループだけを実装し、拡張はミドルウェアに任せる。 - ミドルウェアはエージェントループの各ステップ（モデル呼び出し前後、ツール呼び出し前後、起動・終了時）にフックし、決定論的ロジック・ツール管理・カスタム状態・ストリームハンドラという4つのレバーを提供する。
- プリビルドのミドルウェアとして、
SummarizationMiddleware・PIIMiddleware・HumanInTheLoopMiddleware・ToolRetryMiddleware・ModelFallbackMiddlewareなど多数が用意されている。 - Deep AgentsやClaude Agent SDKのような「意見の強いハーネス」とは対照的に、
create_agentは業種・用途固有のカスタマイズを前提とした設計思想をとる。 - LangChain自身のGTMエージェント、非同期コーディングエージェント、ノーコードエージェントビルダーも、すべて
create_agent＋カスタムミドルウェアで構築されている。
著者見解
「ハーネスがタスクにフィットするかどうかがエージェントの有用性を決める（Task-harness fit）」という表現が、この記事で最も重要な概念だと思う。
私がエージェントの実装・検証を進める中で痛感するのは、モデル性能よりもループの外側の設計がボトルネックになる場面の多さだ。コンテキストウィンドウの溢れ、ツール依存関係の初期化タイミング、PII処理の漏れ、失敗時のリトライ戦略——これらはすべてモデルとは無関係で、ハーネス側の問題だ。記事の言い方を借りれば「ハーネスがいかに右コンテキストを右タイミングでモデルに届けるか」がすべてで、この整理は正確だと思う。
ミドルウェアをコンポーザブルな単位として扱う設計は、受託開発の現場にも直接効く。PIIMiddlewareや承認ゲートのHumanInTheLoopMiddlewareを業種横断で使い回せるなら、新しい案件のたびにゼロから再実装する必要がなくなる。複数エージェントを並走させる組織では、この「バトルテスト済みミドルウェアの継承」という思想は実際のコスト削減に直結する。
一方で、現場目線で慎重に見るべき点もある。ミドルウェアスタックが増えるほど、ループ1ステップあたりのレイテンシと実行コストは積み上がる。デモ環境では見えにくいが、長時間稼働エージェントで ModelCallLimitMiddleware や PromptCachingMiddleware を組み合わせたとき、実際のトークン消費と応答時間がどう振る舞うかは、本番投入前に必ず計測する必要がある。ミドルウェアの設計の美しさと、プロダクション上の運用コストは別の話だ。
発注側の企業——特に中小・中堅でAIエージェントの導入を検討している会社——にとって重要な示唆は、「汎用ハーネスでは業務に乗らないケースが出てくる」という点だ。Deep AgentsやClaude Agent SDKのような事前組み立て済みハーネスで始めることは合理的だが、業務固有の制約（承認フロー、データ分類ポリシー、外部システムとの認証）が増えてくると、カスタマイズ余地のあるレイヤーが必要になる。その局面でこそ create_agent のような設計が生きてくる。プロジェクト初期から「どこまで標準ハーネスで賄い、どこからカスタムミドルウェアが必要になるか」を整理しておくことが、後の手戻りを減らすうえで重要だ。
