AIエージェントの「統制をどこに仕込むか」という問いに、2026年、フレームワーク側からはっきりした答えが出はじめています。従来、人手承認やデータのマスキングといったガードレールは、エージェントの外側——プロキシやAPIゲートウェイ、独自の監視レイヤー——に外付けするのが定石でした。ところが LangChain は 1.0（2025年10月22日 一般提供）で ミドルウェア（middleware） という仕組みを標準化し、これらの統制をエージェントの実行ループそのものの内側に、差し替え可能な部品として組み込めるようにしました（LangChain, "LangChain and LangGraph 1.0"／Changelog: LangChain 1.0 GA）。2026年に入っても、MCPのエリシテーション対応やPII処理の強化など、この「ループ内ガードレール」は継続的に厚みを増しています。
homula はエンタープライズ向けの AIエージェント・インテグレーターとして、n8n / Dify / LangGraph を実装の道具に、日本企業の「PoCから本番・全社へ」を支援しています。LangGraph はその中核の一つです。本稿は特定フレームワークの宣伝ではありません。今回の変化は「エージェントの作り方」の細部の話に見えて、実は統制の置き場所——build層のミドルウェアか、組織横断のコントロールプレーンか——という設計判断に直結します。何が標準装備になり、それが統制の重心をどう動かし、日本企業がどう二層で設計すべきかを整理します。
ミドルウェアとは何か——エージェントループの「各段」に差し込む処理層
LangChain 1.0 は、エージェントを最短で組む抽象として create_agent を提供します。中身は LangGraph ランタイムの上で動く「モデル＋ツール」のループで、その各段のあいだに処理を差し込めるのがミドルウェアです（LangChain, "How Middleware Lets You Customize Your Agent Harness"／Docs: Middleware overview）。
差し込める代表的な地点（フック）は次の通りです。
before_agent/after_agent——エージェント実行の入り口と出口before_model/after_model——モデル呼び出しの直前と直後（入力・出力を検査・改変できる）wrap_model_call——モデル呼び出しそのものを包む（リトライ・フォールバック・キャッシュ向き）wrap_tool_call——ツール実行そのものを包む（承認・記録・置換向き）
実行順序も明確です。すべての before_* が順に走り、wrap_model_call が実際の呼び出しを入れ子で包み、帰りに after_* が逆順で走る——ミドルウェアを配列に積めば、層状の（積み重ねた）ガードレールとして順に適用されます（Docs: Custom middleware）。ポイントは、これらがエージェントのビジネスロジックとは独立した差し替え可能な部品である点です。統制を「本体コードに手書きで埋め込む」のではなく、「部品として着脱する」設計になりました。
統制が「標準装備の部品」になった
LangChain は、企業が毎回自作していた統制パターンをプリビルトのミドルウェアとして同梱しました（Docs: Guardrails）。主要なものを整理します。
| ミドルウェア | 何をするか | 効くフック |
|---|---|---|
| 人手承認（Human-in-the-Loop） | 高インパクトなツール呼び出しの直前で停止し、人が 承認 / 修正 / 却下 / 直接応答 を選ぶ | wrap_tool_call |
| PII処理（PII） | メール・クレジットカード・IP/MACアドレス・URL・APIキー等を検出し、赤黒塗り / マスク / ハッシュ / ブロック する | before_model / after_model |
| 要約（Summarization） | 会話履歴がトークン閾値を超えたら、古い履歴を要約に圧縮して文脈を維持 | before_model |
| コンテキスト編集（Context Editing） | 肥大したコンテキストを刈り込み、必要な情報だけを残す | before_model |
| リトライ／フォールバック | モデル呼び出しの失敗をリトライ、別モデルへ退避 | wrap_model_call |
| ツール選別（Tool Selector） | 速い補助モデルで関連ツールだけを選び、文脈の肥大を抑える | wrap_model_call |
人手承認（HITL） は、メール送信・SQL実行・本番書き込みのような「取り返しのつかない一手」の実行直前にループを止め、人の判断を待ちます。承認したら実行、修正して実行、却下、あるいは人が直接応答で返す——という4通りの分岐を、コードにベタ書きせず部品として差せます（Docs: Human-in-the-loop）。
PII処理 は、モデルへ渡す入力・モデルの出力・ツールの出力の各所で機微情報を捕まえ、サーバーの外へ出る前に赤黒塗りやハッシュ化を行います。検出できる型（メール、クレジットカード、IP/MACアドレス、URL、APIキー等）と、型ごとの戦略（赤黒塗り／マスク／ハッシュ／ブロック）を宣言的に指定できます（Reference: PIIMiddleware）。「ツール出力にAPIキーやカード番号が紛れてコンテキストに残る」という、エージェント特有の漏れ口をループ内で塞げるのが実務上の勘所です。
2026年に入ってからの強化として、MCP（Model Context Protocol）のエリシテーション対応が挙げられます。エリシテーションは「ツールが処理を終えるために、呼び出し側に追加で尋ねる」MCPの人手介在の仕組み。ステートレス化されたMCP仕様では、これがクライアントが答えを添えて再送する通常のリクエストとして表現され、LangChain 側は既存の interrupt() プリミティブでそのまま扱えます（LangChain, "MCP in LangChain: Stateless Protocol, Elicitation, and More"）。人手承認とMCPの問い返しが、同じ「割り込みと再開」の型に揃ってきたわけです。
なぜこれが「統制の置き場所」を変えるのか
ここまでは機能の話です。統制設計として重要なのは、ガードレールを置ける場所が一つ増えたことです。これまで「エージェントの外側のゲートウェイ」でしか掛けられなかった承認・マスキング・監査が、エージェントのループの内側にも、文脈を持った状態で置けるようになりました。
内側に置ける利点は具体的です。たとえば人手承認は、外側のゲートウェイからは「このツールをこの引数で呼ぼうとしている」ところまでしか見えませんが、ループ内のミドルウェアならエージェントの意図やそこまでの推論の文脈込みで止められます。PIIも、ツール出力がコンテキストに積まれるまさにその瞬間に処理できます。統制が「外から様子をうかがう」から「実行の当事者として割り込む」へ変わる——これは前進です。
ただし、ここに落とし穴があります。ミドルウェアのガードレールは、そのアプリ・そのコードベース・そのフレームワークの内側にしか効きません。開発チームAがLangGraphで組んだエージェントにHITLとPIIを丁寧に差しても、隣のチームBがノーコードや別フレームワーク、あるいは n8n / Dify で作った別のエージェントには、その部品は一切及びません。ミドルウェアは「アプリ単位の内蔵ガードレール」であって、「組織単位の統制」ではないのです。ここを取り違えると、アプリごとにバラバラの統制水準が生まれ、全社で見たときの証跡も権限も揃いません。
つまり、ミドルウェアは統制の必要条件を強力に埋めますが、十分条件ではありません。build層の各アプリに良いガードレールが入っていることと、組織として「どのエージェントが・誰の権限で・何をしたか」を横断で押さえられていることは、別の話です。
だから「二層」で設計する——ループ内ミドルウェア × 組織横断コントロールプレーン
答えは、どちらか一方を選ぶことではなく、役割を分けて二層で持つことです。build層のミドルウェアは、文脈依存の・きめ細かい・その場の判断を担う。組織横断のコントロールプレーンは、フレームワークに依存しない・全社で一枚岩の・監査と権限の土台を担う。両者は競合せず、重なって初めて統制が成立します。
| 統制の観点 | build層のミドルウェア（アプリ内蔵） | 組織横断のコントロールプレーン（全社共通） |
|---|---|---|
| 人手承認 | ループ内で意図・文脈込みに止め、修正/却下を選ぶ | 高インパクト操作の承認ポリシーを全エージェント共通で強制 |
| データ保護 | ツール入出力のPIIをその場で赤黒塗り | DLPポリシーを組織標準として適用（フレームワーク非依存） |
| 監査 | アプリ内のステップを記録 | 全エージェント横断の改ざん耐性のある監査証跡として集約 |
| 権限 | ツール選別で文脈を最小化 | エージェントID・ツール単位のRBACで最小権限を全社に適用 |
| 適用範囲 | そのアプリ／そのフレームワークのみ | ノーコードも別フレームワークも含めて横断 |
見ての通り、左の列（ミドルウェア）は開発者がアプリを速く・安全にするための道具で、右の列（コントロールプレーン）は組織が全体を統べるための基盤です。左だけでは「アプリごとにバラバラ」になり、右だけでは「現場の文脈判断」が粗くなる。二層あって初めて、現場の細やかさと全社の一貫性が両立します。
homulaの観点——「作る層」と「統べる層」を分けて設計する
homula は、エージェント導入を「便利な自動化を足す」話ではなく、統制の層を先に設計してから機能を載せる順序で進めます。LangChainミドルウェアの成熟は、この二層設計をむしろ後押しするものです。
- 作る層（build層）は適所適ツールで、ガードレールを内蔵する: n8n / Dify / LangGraph を業務の重要度に応じて使い分け、LangGraph では人手承認・PII処理・コンテキスト管理といったミドルウェアを、リスクの大小に合わせて差し分けます。「全部止める／全部任せる」の二択ではなく、一手ごとにゲートの強弱を設計します。
- 統べる層は組織横断で一枚岩に: Agens Control は、承認フロー・DLP・5年分の監査ログ・RBAC を提供します。ミドルウェアが届かないアプリ間・フレームワーク間の境界を越えて、「どのエージェントが・誰の権限で・実際に何をしたか」を全社の証跡に残し、高インパクトな操作には共通ポリシーで承認を強制できます。build層の内蔵ガードレールと、この組織横断の統制が重なることで、抜け漏れのない二層になります。
- 接続は絞って速く、統制の設計に時間を割く: Agens は MCP を活用し、200以上のツールと構築ゼロで接続します。ツールが「外部への出口」である以上、その定義とスコープ設計こそ統制の要。接続を作り込まずに用意できるぶん、どのツールにゲートを噛ませ、どの権限を誰に持たせるかの設計に集中できます。
- 着手前に統制要件を定義する: AIエージェント・ブートキャンプでは、業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で完結します。「どのアクションを承認対象にするか」「PIIをどこで落とすか」「何を単位に証跡を数えるか」を最初の要件として置くことが、後戻りを防ぎます。
順序が肝心です。ミドルウェアは強力ですが、それだけを頼りに全社展開すると、アプリごとに統制水準がまだらになり、組織としての監査も権限も揃いません。build層に内蔵ガードレールを・その上に組織横断のコントロールプレーンを——この二層を先に置いてから自律性を広げるのが、処理時間の大幅削減（homulaの実績では最大 93%削減）のような成果を、全社規模で安全に取りにいく現実的な道筋です。
まとめ——ガードレールは「内側」にも置ける。だが「横断」は別に要る
2026年のLangChainミドルウェアが示したのは、人手承認・PII処理・要約・リトライといった統制が、エージェントの外付けからループの内側の標準部品へ移ったことです。これは、統制を文脈込みで・きめ細かく掛けられるようになった大きな前進です。
一方で、ミドルウェアはあくまでアプリ単位・フレームワーク単位の内蔵ガードレール。組織として「すべてのエージェントを同じ水準で統べる」ためには、フレームワークに依存しない組織横断のコントロールプレーン——承認・DLP・監査・RBAC——が別に要ります。日本企業がいま設計すべきは、どちらか一方ではなく、作る層のミドルウェアと統べる層のコントロールプレーンを、役割を分けて二層で持つことです。統制はブレーキではなく、エージェントの自律を安心して広げるための土台になります。
「便利だが任せきれない」を「統制された自律」に変えませんか。homula は、LangGraph等での内蔵ガードレール実装から、組織横断の承認・監査・権限設計まで、業務棚卸しとROI試算を含めて一気通貫で支援します。