---
title: "v3で広げる用途"
language: "ja"
documentation_version: "3.x"
channel: "development"
release_context: null
source_revision: "f18cae3d806b2f4141db0c785143bb0035fbd33d"
working_tree_clean: true
source_path: "docs/ja/guides/edge-control.md"
source_sha256: "a1d19caf42464e6890242dd0288f801271b7983e4611eb5ae76a5c0c811096e8"
source_at_revision: true
source_url: "https://github.com/matsumotory/ngx_mruby/blob/f18cae3d806b2f4141db0c785143bb0035fbd33d/docs/ja/guides/edge-control.md"
html_url: "https://ngx.mruby.org/ja/guides/edge-control/"
markdown_url: "https://ngx.mruby.org/markdown/ja/guides/edge-control.md"
last_updated: "2026-11-02"
---

# v3で広げる用途

モデル、エージェント、通信、AIゲートウェイの語は、[用語集](/ja/glossary/)が定義しています。

**v3で広げる用途の構想です。完成した連携機能ではありません。**nginxにRubyの規則を置き、データの中継はnginxに任せます。[モデルAPIの中継の実行例](/ja/guides/agent-proxy/)では、利用者キーの検査、モデルの振り分け、ストリーム中継をnextで確認しています。以下では、モデルAPIやMCPサーバーの前段に置くAIゲートウェイの拡張と、Webサイトへ来るAIクローラーやエージェントのリクエストの制御を分けて説明します。log handlerのテレメトリも扱います。いずれも用途を広げる設計であり、すべてをv3.0に含める約束ではありません。

## MCPの認可

エンドユーザーがAIアプリケーションからMCPツールを呼び出す際に、ユーザーごとに使える機能やアクセスできるデータを制限する構成を想定しています。

MCPサーバーの運用者が、AIアプリケーションとMCPサーバーの間にngx_mrubyを置く構成です。MCPゲートウェイは、認証済みユーザーと、MCPのツール呼び出し（JSON-RPCのメソッド`tools/call`）のMCPツール名・引数を照合してから、設定済みのサービスへ転送する想定です。検索だけを許可されたユーザーによる更新や、アクセス権限のない文書の指定を拒否する設計です。データのアクセス権限はMCPサーバーも検証します。

トークンの検証とMCPツールの認可は別の処理です。リソースサーバーの認証機構でトークンの発行元、audience、scopeを検証し、Rubyは検証済みの主体を使います。自己申告のエージェントのIDを信用しません。規則や集計のキーに検証済みのユーザーIDとデータのアクセス範囲を含め、振り分け用ヘッダとJSON-RPC本文の一致も確認します。ユーザーの所属グループごとにデータを分離するサービスでは、アクセスを許可されたグループも、この範囲に含めます。

MCPツール一覧、エラー、キャンセルの契約は接続先と揃えます。MCPゲートウェイを置くだけでOAuthサーバーやMCPツール一覧の集約機能ができるわけではありません。[MCPの設計案](/ja/guides/mcp-gateway/)に最初のmock例と対象のバージョンを定めています。2026-07-28のStreamable HTTP、Mcp-Session-IdとGETのストリームを持つ2025-03-26から2025-11-25のStreamable HTTP、旧HTTP+SSEは別々に検証し、更新系MCPツールの再実行や、対象の違うサービスへのトークン転送を防ぐ設計です。

呼び出しの集中、同時ストリーム数、本文量にもnginxで上限を設けます。契約に合う再試行の案内を返しても、調査が十分かどうかはAIアプリケーション内のエージェントが判断します。頻度だけで意味的なループと決めつけず、必要な読み直しを妨げないか検証します。

必要な機能と状態は、台帳の[MCPツールの認可とデータのアクセス範囲の検査](https://github.com/matsumotory/ngx_mruby/blob/next/docs/proposals/edge-control.md#mcp-tool-authorization)の行と[MCP呼び出しの集中の制御](https://github.com/matsumotory/ngx_mruby/blob/next/docs/proposals/edge-control.md#mcp-burst-control)の行にあります。

### AIアプリケーションに合わせる

同じサービスで、専用のMCPツールやsearch・fetchの入口をAIアプリケーション別に用意する設計です。設定したプロファイルで接続先を選び、ツールの一覧（`tools/list`）のスキーマと`tools/call`の挙動を揃えます。製品名だけで契約を決めつけず、プロファイルごとに用意した転送先のMCPサーバー（バージョンを付けたバックエンド）に変換を任せます。MCPツールを一覧から隠すだけでは、MCPツールの認可になりません。

文書は必要な範囲から読み、続きを取得できる形にします。原本のID、バージョン、位置、継続トークンはバックエンドが管理します。MCPゲートウェイは取得方式や処理量を制御しても、JSONやSSEを途中で切ったり、継続トークンを作ったりしません。本文が未完であることをAIアプリケーションへ伝えます。

必要な機能と状態は、台帳の[AIアプリケーション別のMCPツールの出し分け](https://github.com/matsumotory/ngx_mruby/blob/next/docs/proposals/edge-control.md#mcp-tool-profiles)の行と[段階的な文書の取得](https://github.com/matsumotory/ngx_mruby/blob/next/docs/proposals/edge-control.md#mcp-progressive-retrieval)の行にあります。

### 次の探索を導き、観測する

該当なし、一部取得、取得失敗を区別し、事実に基づく次の手順を返す構想です。権限不足を該当なしに変えたり、検索の意味を変えたりしません。分野固有の提案はサービスが担当し、取得した文書中の指示をMCPゲートウェイの指示にしません。

MCPツール呼び出しの流れは、結果や所要時間など必要なメタデータで観測します。生の検索語や文書を標準で集めず、保存期間を制限します。観測用の相関IDとMCPのセッションは別物です。応答を止めない外部送信には、後述するキューの設計が必要です。

検索や読み取りのMCPツールが、資料とともに次の探索の手掛かりを返す構想です。利用者が普段使うAIアプリケーション内のエージェントがその応答を読み、再検索、追加の読解、調査の終了を選びます。この相互作用でAgentic RAGを支え、モデルやAIアプリケーションの進化に対応することを目指します。MCPゲートウェイに別のエージェントの実行基盤を持たせる構想ではありません。

必要な機能と状態は、台帳の[0件やエラーのときの次の手掛かり](https://github.com/matsumotory/ngx_mruby/blob/next/docs/proposals/edge-control.md#mcp-next-step-guidance)の行と[調査の軌跡の非同期のロギング](https://github.com/matsumotory/ngx_mruby/blob/next/docs/proposals/edge-control.md#mcp-trajectory-logging)の行にあります。

<a id="llmの切替"></a>

## モデルAPIの切替

モデルAPIの接続先とプロバイダのキーを各AIアプリケーションに埋めず、AIゲートウェイで管理する設計です。上流の429や対象とする5xxに応じ、応答を利用者へ送り始める前に、許可済みの代替先を選びます。切替をやめて元のエラーを返す条件も決めます。ngx_mrubyが自分の同時実行制限で返した429は、上流の障害として扱いません。

nginxのproxy_next_upstreamや名前付きerror_pageを使えますが、それだけでプロバイダ間の切替規則が完成するわけではありません。nginxがPOSTを次の接続先へ送るのは、proxy_next_upstreamにnon_idempotentも書いたときだけで、これを書くことが再送の判断です。POSTの再送は処理や課金を重複させます。回数と総時間に上限を設け、待機期間を守り、安全に再実行できる操作と再送可能な本文に限ります。

応答を送り始めた後は別のストリームへ切り替えません。途中の切断は中断として扱います。転送先ごとに認証情報、Host、TLSのSNIを設定し、APIのパス、モデルの機能、本文形式の一致を確かめます。プロバイダのキーの差し替えはMessages APIからResponses APIへの変換ではありません。

同じlocationの再試行ごとにヘッダを組み直すには、計画中のbalancer APIが必要です。[接続制御の計画](/ja/guides/agent-proxy/#計画プロバイダ通信)と、現在のmock中継の検証を区別してください。

必要な機能と状態は、台帳の[モデルAPIの切替](https://github.com/matsumotory/ngx_mruby/blob/next/docs/proposals/edge-control.md#llm-api-fallback)の行にあります。

<a id="クローラーの制御"></a>

## AIクローラーの制御

WebサイトやAPIの運用者が、高負荷な処理を守りながら軽い公開テキストを提供する用途です。Rubyでリクエストの特徴と規則を組み合わせ、nginxで頻度や同時実行数を制限したり、別のテキスト用エンドポイントへ振り分けたりする構想です。変化する規則を各アプリへ重複実装せず、入口で管理します。

User-Agent、IP、本文の特徴は手掛かりであって、本人や意図の証明ではありません。転送元アドレスは設定済みのプロキシからだけ信用します。本文の検査量に上限を設け、大きなアップロードを丸ごと解析しません。別の手段で確かめた身元や検証済みのリクエストの署名と、特徴から推定したAIクローラー、学習用のAIクローラー、AIスクレイパーの分類を区別します。身元の検証とアクセスの許可は別の判断であり、通常の利用者を誤って制限しないかも確認します。

拒否は明示し、軽い応答には公開を意図した内容だけを使います。Honeypotは任意の隔離先であり、標準の罰則やボットの判定ではありません。秘密を見せず、外部処理を起動せず、資源消費を制限します。worker間の動的な集計とreload時の扱いは共有辞書の計画に属し、分散した利用上限の管理の完成を意味しません。

必要な機能と状態は、台帳の[AIクローラーやエージェントのリクエストの制御](https://github.com/matsumotory/ngx_mruby/blob/next/docs/proposals/edge-control.md#ai-crawler-and-bot-control)の行に書いてあります。

## キャッシュと観測

プロンプトや認証情報を送らずに、ステータス、遅延、振り分け結果を観測する用途です。現在のlog handlerでもメタデータを記録できますが、ネットワーク応答は待てません。logフェーズのNginx::Asyncは拒否され、ブロッキングするクライアントを使うとworkerが止まります。

外部送信は、上限付きのworkerキューとworkerタイマー、ノンブロッキングな通信を組み合わせる計画です。実装前に、満杯時、サンプリング、終了時、送信失敗時の扱いを決めます。メトリクスを捨てるなら欠測を数え、永続的な配送が必要な監査記録には別の契約を設けます。収集先の障害で応答を止めません。

セマンティックキャッシュはlogフェーズではなく、リクエスト処理中の別の判断です。embedding、類似検索、回答の保存は外部サービスが担当し、AIゲートウェイは将来のノンブロッキングなフックから問い合わせます。アクセスできるデータのユーザーまたはグループ、認可の範囲、モデル、プロンプトと規則のバージョンで分離し、期限と無効化を定めます。

問い合わせのタイムアウトや一致の判断が曖昧な場合は、元の上流へ送ります。MCPツールの副作用をキャッシュせず、似たプロンプトなら同じ回答を使えるとも決めつけません。用途に合った評価が必要です。

必要な機能と状態は、台帳の[log handlerのテレメトリ](https://github.com/matsumotory/ngx_mruby/blob/next/docs/proposals/edge-control.md#log-handler-telemetry)の行と[セマンティックキャッシュ](https://github.com/matsumotory/ngx_mruby/blob/next/docs/proposals/edge-control.md#semantic-cache)の行にあります。

## 設計と検証

[v3の拡張案](https://github.com/matsumotory/ngx_mruby/blob/next/docs/proposals/edge-control.md)に、依存する機能、失敗時の挙動、受け入れテストを記します。既存のエージェントプロキシの計画を広げるもので、中継エンジンやembedding実行環境、汎用API変換をもう一つ作る計画ではありません。mock例、接続先との互換性、性能を検証してから実装済みと案内します。今試せる入口は[ローカルのモデルの振り分け](/ja/start/#モデルで転送先を選ぶ)です。

[用途の台帳](https://github.com/matsumotory/ngx_mruby/blob/next/docs/proposals/edge-control.md#use-cases-and-the-features-they-need)に、すべての用途の必要な機能と実装の状態があります。
