最前線のモデルが計画し、オープン SOTA が実行する。コストは 7 分の 1。
トップティアのモデルが計画を担い、オープン SOTA モデルが定常業務の 90% を実行します。組み合わせによって請求額は約 1/7 に。数字はここで主張するのではなく、計算ツールでその場で算出されます。
- ✓モデルを混在:Claude Opus が計画し、DeepSeek / Qwen が実行 — コストは約 1/7、最大 90% 削減
- ✓どのモデルを実行するかはゲートウェイが決める:クライアントの設定に関わらず、着地モデルは管理者が固定したもの — ingress の許可リスト + ワイルドカード「*」マッピング
- ✓プロトコルは 1 つで十分:OpenAI か Anthropic で話せば、4 つのチャット系プロトコル(OpenAI / Anthropic / Gemini / DashScope)背後のモデルに届く — モデルを入れ替えてもコードは変わらない
- ✓データはオンプレに残る:完全セルフホストでプロンプトが当社に届くことはない。リクエスト経路上で資格情報と PII を検出 — スコープごとにログ / マスク / ブロック
from openai import OpenAI
# One line change: point your SDK at your own gateway
client = OpenAI(
base_url="https://your-gateway.gatellm.io/v1",
api_key="your-gateway-api-key",
)
# Existing code unchanged — the gateway routes each request
# to the right model tier (planning vs execution) per your console policy
resp = client.chat.completions.create(
model="claude-opus-5", # or claude-sonnet-5, gpt-6-astra, deepseek-flash...
messages=[{"role": "user", "content": "Plan the architecture"}],
)単一モデルではできない、ゲートウェイがやる 3 つのこと
モデルを混在させてコストを削り、実際に走るモデルを強制し、クライアントコードを 1 つのプロトコルに保つ。
100+ の LLM プロバイダー · 30+ の SDK とフレームワークに対応
- OpenAI
- Anthropic
- DeepSeek
- Qwen
- ERNIE
- Kimi
- Zhipu
- Mistral
- Cohere
ご自身で確認できます
私たちは「信じてください」と求める代わりに、資料を公開しています。本ページのすべての主張には、お問い合わせの前に読んでいただける裏付けがあります。
ひとつのインターフェースで、すべてのモデルを組み合わせる
シンプルなモデルルーティングからマルチモデルのオーケストレーションまで、GateLLM はエンタープライズ水準の機能を網羅します。
マルチモデルルーティング
ひとつのインターフェースですべてのモデルを呼び出せます。インテリジェントなフォールバック、負荷分散、自動リトライ。
- 100+ の LLM プロバイダーを統一 API で
- インテリジェントなフォールバックルーティング
- 負荷分散とレート制限
- アップストリームキープール：同一呼び出し元は 1 つのキーに固定され、失敗時は次のキーへフェイルオーバー
- Ollama / vLLM / llama.cpp を openai-compatible なアップストリームとして接続し、ガバナンスはひとつの面に統合
Composition
プランモード、ID、リクエスト形状による段階的ルーティング：計画はトップティアのモデル、実行はオープン SOTA。ゲートウェイがモデル名を書き換えるため、クライアントコードは一切変わりません。
- プランモード検出：計画はトップティア、実行はオープン SOTA へ。クライアント側の変更はゼロ
- ID スコープのモデルマッピング：同じモデル名をキーグループごとに異なるアップストリームへ
- switch-route ルール：画像付きリクエストや特殊なリクエストを適切なモデルへ振り分け
- エージェント内ダウングレード：plan 固定 / 非 plan は自動ダウングレード
マルチモデルコードレビュー
同じ PR に対して 2〜3 のモデルを並列で実行します。ゲートウェイがプロトコル相互運用とひとつのキーでの計測を提供し、ファンアウト、マージ、信頼度スコアリングはオープンソースのオーケストレーション Action が担います。
- ゲートウェイのプロトコル相互運用：Anthropic 以外のモデルも Anthropic 専用のレビューキューに参加可能
- 1 つのアクセスキーでファンアウト全体を計測・統制
- ファンアウト、[Consensus N/M] スコアリング、マージは gatellm-io/gatellm-code-review（オーケストレーション側）が担当
MCP ツールガバナンス
外部の MCP ツールサーバーをひとつの /mcp エンドポイントの背後に集約します。ツール単位の ACL、コンテキスト予算、呼び出し監査を提供。エージェントが使えるツールは、呼び出せるモデルと同じ権限面で管理されます。
- 複数の MCP サーバーをひとつの /mcp エンドポイントに集約
- キーグループごとのツール allow/deny とラベルフィルター
- ツール一覧が増えたときの組み込み BM25 検索
- REST ブリッジ：簡略化した仕様から任意の REST API をゼロコードで MCP ツール化
- MCP の呼び出し / 違反 / セッションを完全監査
Web 検索の注入
すべてのモデルにウェブ検索を均一に付与します。ゲートウェイが検索結果を取得して注入し、クライアントのプロトコルごとにネイティブな検索ブロックを合成するため、オープンモデルでも検索グラウンディングが使えます。
- プロトコルごとのネイティブ検索ブロック（Anthropic / OpenAI / Responses）
- モデル単位の三状態トグル、失敗時はグレースフルデグラデーション
- ハイジャックした検索は利用量の課金対象外
コスト管理
予算管理、レート制限、チーム別コスト配賦、モードを意識したモデルポリシー。トークン料金への上乗せは一切なく、BYOK で自社キーを利用できます。
- プロジェクト / 機能ごとのコスト配賦
- ソフトな予算アラート
- BYOK：プロバイダーへは標準料金を支払う
- モードを意識したモデルポリシー（plan / execute を強制可能）
ガバナンスと統合
クライアントのアクセス制御から CI/CD 連携まで、ゲートウェイの機能を開発・コラボレーションのワークフローへ拡張します。
- クライアントアクセス制御（User-Agent ポリシー）
- 自社ゲートウェイ経由の GitHub Actions コードレビュー
- 一括設定：ステージング → 競合の全件プレビュー → 単一トランザクションでアトミックにコミット
Office / M365 アドイン
有償アドオンExcel、Word、PowerPoint、Outlook の中で、自社のモデルゲートウェイをそのまま利用できます。セルフホスト型アドインで、データがネットワーク外に出ることはなく、pivot への依存もゼロです。
- Excel の財務モデリング / Word の契約レビュー / Outlook の受信箱
- Entra SSO + Purview ラベルによるゲーティング
- 33 個のドメインスキルを同梱、有償アドオン
変換スクリプト
サンドボックス化された JavaScript エンジン（QuickJS）が、ゲートウェイ上でリクエストとレスポンスの JSON を書き換えます。コンソールで編集すれば即時反映され、再デプロイもグルーコードも不要です。
- リクエスト前 / リクエスト後スロット + レスポンススロット：翻訳前のクライアント形式や翻訳後のアップストリーム形式を扱える
- context.useModel() でルート全体（base_url、プロトコル、認証情報）をまとめて切り替え
- 組み込みライブラリ：json_path / str_* / regex_* / array_* / encoding + hash / UUID + time
- サンドボックス化（ネットワーク・ファイルシステムなし）、fail-open / fail-closed モード、コンソール内スクリプトテスター
モデルの組み合わせ：単一モデルでは実現できない品質
Composition はゲートウェイにネイティブなパターンであり、マルチモデルコードレビューはゲートウェイが可能にするオーケストレーション側のパターンです。どちらもケイパビリティ正規化レイヤーの上に成り立っています。
Composition：モデルをまたぐ段階的ルーティング
プランモード、ID、リクエスト形状によってルーティングします。計画はトップティアのモデルに留め、実行はオープン SOTA へ落とします。ゲートウェイがモデル名を書き換え、プロトコルを翻訳するため、クライアントコードは一切変わりません。
- ✓プランモード検出：計画はトップティアへ、実行はオープン SOTA へ振り分け。クライアント側の変更はゼロ
- ✓ID スコープのモデルマッピング：同じモデル名をキーグループ / ヘッダーごとに異なるアップストリームへ
- ✓switch-route ルール：画像付きリクエストや特殊なリクエストを適切なモデルへ振り分け
- ✓グルーコード不要：プロトコル翻訳はゲートウェイが処理
- ✓強制可能なポリシー：管理者が plan / execute モードごとにモデル階層を固定し、すべてをトップティアで使うことを防ぐ
// before-slot transform script (JavaScript) — switch execution model by plan mode.
// Mounted on the entry model in the console; runs before routing.
function transform(body, context) {
if (context.sourceProtocol !== "Anthropic") {
return body;
}
const EXEC_MODEL = "qwen3.8-max"; // a model name configured in the gateway
const PLAN = /plan mode is active/i;
const EXIT = /exited plan mode/i;
// take the last marker-bearing message: later marker wins
const messages = body.messages || [];
for (let i = messages.length - 1; i >= 0; i--) {
const s = JSON.stringify(messages[i].content || "");
const inPlan = PLAN.test(s);
const exited = EXIT.test(s);
if (inPlan || exited) {
// not in plan mode → switch execution to the cost-efficient model
if (exited || !inPlan) context.useModel(EXEC_MODEL);
return body;
}
}
context.useModel(EXEC_MODEL);
return body;
}マルチモデルコードレビュー（オーケストレーション側）
ゲートウェイがパターンを可能にし、オーケストレーション層がそれを実行します。claude-code-action は Anthropic プロトコルしか話せませんが、ゲートウェイのプロトコル相互運用により、qwen3.8-max や kimi-k3 のような Anthropic 以外のモデルもレビューキューに参加できます。ゲートウェイのアクセスキー 1 つで、すべてのレビューモデルを統一的に計測します。
- ✓[Consensus N/M] の信頼度注釈、マージ、重複排除は Action が生成
- ✓各レビューモデルは個別に課金され、ゲートウェイが統一的に集計
- ✓PR の行数ゲートと過去コメントの圧縮は Action に組み込み済み
最初のトークンまで 3 ステップ。
単一モデルからマルチモデルのオーケストレーションへ、3 ステップで移行できます。ビジネスコードの書き換えは不要です。任意の SDK（OpenAI / Anthropic / Gemini / DashScope）が利用できます。
ゲートウェイをデプロイ
Docker でワンクリック起動、または Kubernetes Helm でプライベート環境へデプロイ。
キーを設定
BYOK モード：既存のプロバイダー API キーを入力するだけ。データはオンプレミスに留まり、永続化されません。
エンドポイントを置き換え
OpenAI SDK の base_url を GateLLM に向ければ、統一インターフェースですべてのモデルを呼び出せます。
またはエージェントに任せる
コーディングエージェントにこれを貼り付けてください
GateLLM ゲートウェイをインストールして設定してください。まずこのインストールガイドの生の Markdown を curl で取得し、最後まで読んでから、各ステップを順番に実行してください（ステップには依存関係があります。たとえばアクセスキーより先にキーグループが存在している必要があります。順番を飛ばさないでください）：
curl -fsSL https://docs.gatellm.io/en/quickstart/docker-single-node.mdエージェントにお客様が用意するのは 1 つだけです。アップストリームプロバイダーの API キーです。残りはエージェントが生成し、Console API 経由で（ブラウザを使わずに）すべて設定します。最初のリクエストが完了を返したら終了です。
または自分で実行する
docker run -d \
--name gatellm \
-p 7890:7890 \
-e CONSOLE_PASSWORD=change-me-on-first-login \
-e ENCRYPTION_KEY=REPLACE_WITH_YOUR_ENCRYPTION_KEY \
-e CONSOLE_SECRET_KEY=REPLACE_WITH_YOUR_CONSOLE_SECRET_KEY \
-e STORAGE_MODE=sqlite \
-v gatellm-data:/var/lib/protoflux \
ghcr.io/gatellm-io/gatellm:latest実行前に 3 つのプレースホルダー値を置き換えてください。それぞれが何であり、そのままにしておくとなぜ危険なのかはガイドで説明しています。
# Just one line change: point base_url to GateLLM
from openai import OpenAI
client = OpenAI(
base_url="https://your-gateway.gatellm.io/v1",
api_key="your-gatellm-api-key"
)
# Existing code unchanged, call any model
response = client.chat.completions.create(
model="claude-opus-5", # or claude-sonnet-5, gpt-6-astra, deepseek-flash...
messages=[{"role": "user", "content": "Hello"}]
)GitHub の実行可能なサンプル — Docker Compose と、base_url だけを変える Python / TypeScript の SDK スニペット
使い慣れた SDK をそのまま。変更は 1 行だけ。
両側で同じ 4 つのプロトコル。チャット、画像、音声、動画、リアルタイム音声、埋め込み、リランクにわたり、グルーコードなしで任意の組み合わせに変換できます。
使い慣れた SDK でそのまま動きます
任意の SDK やフレームワークを 1 行でゲートウェイに向けられます。OpenAI、Anthropic、Gemini、DashScope はネイティブ接続、LangChain、LlamaIndex、CrewAI、Vercel AI SDK など 30+ は同じ base_url の差し替えで利用できます。
base_url をゲートウェイに向ける
既定値は https://your-gateway.gatellm.io です。/v1 を含むかどうかは SDK によって異なります（各例に正確な値を記載）。
ゲートウェイのアクセスキーに差し替える
アップストリームの sk-… キーではありません。同じアクセスキーを、お使いの SDK が期待するヘッダーに載せます。
ゲートウェイのモデル名を使う
コンソールで設定した名前です。ベンダー公式の名前ではありません。
Authorization: Bearer <key>x-api-key: <key>x-goog-api-key: <key>ベンダー公式 SDK
OpenAI / Anthropic / Google の SDK はネイティブ接続。変更は base_url のみです
統合 SDK / ゲートウェイ
Vercel AI SDK、LiteLLM、Portkey、Semantic Kernel、Spring AI
オーケストレーションフレームワーク
LangChain、LlamaIndex、CrewAI、AutoGen、DSPy、Haystack
エージェント SDK
OpenAI Agents、Claude Agent、Pydantic AI、ADK、Mastra
リアルタイム / 音声
Realtime WebSocket 音声 + openai_audio ASR / TTS
ローカル / セルフホスト
Ollama、vLLM、llama.cpp をアップストリームとして利用。クライアント SDK はそのまま
任意の AI コーディングエージェントをゲートウェイに向ける
コーディングエージェントの設定をすべて見る → ↗Chat Completions ではなく Responses API を呼びます。アップストリームが openai（Chat）の場合は OpenAIChatCompletionsModel で明示的に切り替えてください。openai_response であれば文字列のモデル名でそのまま動きます。
OpenAI クラスは認識できるファミリーしか受け付けず、ゲートウェイのカスタム名を拒否します。OpenAILike（Python）を使うか、モデル情報を明示的に宣言してください。
base_url はフレームワークのパラメーターではなく OPENAI_API_BASE 環境変数で指定し、model には openai/ プレフィックスが必要です。
OpenAI SDK は /v1 を付けます。Anthropic SDK はルートを指定します（/v1/messages を自身で付加）。Vercel AI SDK の createAnthropic は /v1 を付けます（/messages を付加）。間違えるとパスのセグメントが余分に付いたり欠けたりします。
# base_url convention differs by SDK — match the one you're using
from openai import OpenAI
OpenAI(base_url="https://your-gateway.gatellm.io/v1") # OpenAI SDK: /v1
import anthropic
anthropic.Anthropic(base_url="https://your-gateway.gatellm.io") # Anthropic SDK: root (appends /v1/messages)
# Vercel AI SDK createAnthropic: baseURL ".../v1" (appends /messages) — the reverse
# LangChain ChatOpenAI: base_url="https://your-gateway.gatellm.io/v1"ケイパビリティ正規化：ベンダーをまたぐ組み合わせを可能にする
クロスベンダーでのモデル混在は、7 つの結合点を統一するケイパビリティ正規化レイヤーに支えられています。モデルを切り替えてもグルーコードを書き直す必要はありません。
ツール呼び出しの正規化
OpenAI / Anthropic / Gemini / 中国系モデルではツール呼び出しのスキーマがすべて異なります。基盤で統一するため、コードは一度書けばすべてのモデルを呼び出せます。
構造化出力の互換性
各プロバイダーは異なるプロトコル（厳格な JSON Schema、json_mode、tool_use）を使います。一貫したインターフェースに統合します。
プロンプトキャッシュの統一
Anthropic の cache_control、OpenAI の自動キャッシュ、Gemini のコンテキストは仕組みが異なります。統一されたキャッシュ戦略を提供します。
推論トークンの適応
o1 / Claude thinking / DeepSeek R1 の出力形式は異なります。各プロバイダーの推論トークンプロトコルに適応します。
マルチモーダル形式のサポート
vision / audio / ファイルアップロードのプロトコルはプロバイダーごとに異なります。マルチモーダル入力の形式を統一します。
課金モデルの抽象化
各プロバイダーの料金体系は異なります。統一されたコスト追跡インターフェースへ抽象化します。
エラーセマンティクスの正規化
ベンダーごとにエラーコードとボディが異なります。統一されたエラーボディに正規化し、z-request-id でリクエストをエンドツーエンドで相関できます。
データフロー：オンプレミスに留まり、永続化されない
BYOK モードでは、API キーはゲートウェイのメモリ内だけに保存され、永続化も送信もされません。リクエストはゲートウェイからプロバイダー公式 API へ直接ルーティングされ、データがプライベートネットワークの外に出ることはありません。
なぜコストが約 1/7 になるのか
1 日 10 億トークンを処理する企業を例に考えます。同じワークロードで「すべてをトップティアで処理した場合」と「トップティアが計画し、オープンモデルが実行する場合」の請求額を比較します。
Claude Opus 5 が計画と実行の両方を担い、すべてトップティア
実行の約 90% をオープン SOTA、重要な 10% の計画をトップティアで
削減効果の 3 つの源泉：
- 1.BYOK でトークンへの上乗せなし。プロバイダーへ標準料金を支払い、GateLLM は中間マージンを取りません（アグリゲーターは通常、定価にプラットフォーム料と決済手数料を上乗せします）。
- 2.Composition。オープン SOTA モデル（GLM / Qwen / DeepSeek）が実行の大部分（分類、抽出、翻訳）を担い、トップティアのクローズドモデル（Claude Opus など）は計画と難易度の高い推論だけに使います。
- 3.プロンプトキャッシュ。高頻度の呼び出しはキャッシュにヒットし、単価が 50%〜90% 下がります。
数値は公開価格に基づく説明用のモデルであり、実際の削減額は業務シナリオと組み合わせ比率によって異なります。Pro ライセンス料（月額 $400、2GB 単一インスタンス）は GateLLM の料金に含まれます。
見える利用量、精算できるコスト、守れる予算
Token Ops は誰が何を使っているかを追跡し、Token FinOps はトークンを課金可能で上限のある金額に変えます。ひとつのコントロールプレーンで、AI 支出をクラウド支出と同じように運用できます。
利用量とコストの可観測性
すべての呼び出しをモデル、アクセスキー、キーグループ別に分解し、入力 / 出力 / キャッシュヒットのトークンを 1 分単位で個別に計測します。
- モデル / キー / キーグループ別に集計
- 入力・出力・キャッシュヒットを個別に計測
- 24 時間 / 7 日 / 30 日 / 任意期間の時系列
クライアントの受け入れと監査証跡
承認済みのクライアントだけがゲートウェイに到達できます。User-Agent によって許可・スロットル・拒否を制御します。すべての呼び出しは監査可能な記録として残り、エンドポイントのガバナンスとコンプライアンスの証跡になります。
- クライアントアクセス制御（User-Agent ポリシー）
- ログ保持付きの呼び出し記録（Pro 以上）
- 監査 / DLP 連携（Enterprise）
Management API（プログラムによる制御）
EnterpriseAPI 経由でゲートウェイを管理できます。API キーの作成 / 失効、クォータと予算の設定、利用量とコストの照会、監査ログのエクスポートを行い、社内の運用・請求システムに組み込めます。
- API による API キーの作成 / 失効
- API によるクォータと予算の設定
- 利用量とコストの照会 API
- 監査ログのエクスポート
自社レートカードと価格スナップショット
交渉した非公開価格を手入力すると、それが正となります。システムの更新で上書きされることはありません。各価格には有効期間があり、値下げを事前に予約でき、編集しても過去のコストは書き換わりません。
- 固定した非公開価格が自動価格を覆い、上書きされない
- スナップショットは期間に応じて有効化
- 履歴の補填 / 値下げの事前予約
- トークン · 呼び出し単位 · 秒単位の課金モード
タグによる配賦とチャージバック
キーとキーグループにタグを付け、タグ別に利用量とコストを集計して、トークン支出を正しいコストセンターに着地させます。Excel エクスポートはモデル × キーで台帳を分割し、社内のショーバックやチャージバックに使えます。
- キー / キーグループへの自由なタグ付け
- タグ別の利用量・コスト集計
- 6 シートの Excel エクスポート（キー × モデルを含む）
- 社内ショーバック / チャージバックに対応
コストクォータと上限
キーごとに日次・月次の支出上限を設定できます。UTC の暦日と暦月で独立に判定し、どちらかに達した瞬間にブロックします。クォータはキー → グループ → グローバルの順に継承され、グループ間では最も広い値が採用されます。
- 日次 / 月次の上限を独立に判定
- キー → グループ → グローバルの継承
- 429 quota_exceeded、日次では Retry-After を返却
GateLLM と LiteLLM
出典で検証済みの比較です。LiteLLM にはない仕組みを GateLLM だけが搭載しており、両者は確立されたベースラインを共有し、いくつかの点は性質が異なります。宣伝ノイズではなく、上下 2 つの層で判断してください。
GateLLM だけが提供するもの
LiteLLM にはない仕組みです。各機能の下に「どう実現するか」を 1 行で示します。
| 機能 | GateLLM | LiteLLM |
|---|---|---|
| 条件付きモデル切り替え宣言的な switch-route ルール + 組み込みのプランモード検出 + context.useModel() スクリプトで、クライアント側の変更はゼロ。LiteLLM では独自の Python コールバックが必要です。 | あり | なし |
| プロトコルをまたぐモデル / SDK の混在ネイティブな任意対任意のエントリポイント。Anthropic SDK から GPT を、Gemini SDK から DeepSeek を呼び出せます。LiteLLM は OpenAI 中心で、逆方向はシムを経由します。 | あり | なし |
| 単一トランザクションでの設定コミットステージング → 競合の全件プレビュー → アトミックなコミット。競合が 1 つでもあればバッチ全体がロールバックします。 | あり | なし |
| コストクォータによる強制ゲート日次 / 月次のサイクルで、支出が上限に達した瞬間に 429 quota_exceeded を返します。LiteLLM は予算アラートを送るだけです。 | あり | なし |
| クラッシュセーフな課金事前差し引き → 精算 → 返金を進行中台帳で管理し、プロセスクラッシュをまたいでも正しく保たれます。 | あり | なし |
| アップストリームキーのプールとスティッキーな紐付け重み付き FNV-1a ハッシュで各呼び出し元を 1 つのキーに固定し、失敗時は未試行の次のキーへフェイルオーバーします。weight=0 は待機系です。 | あり | なし |
| 3 つの課金モード + 多通貨トークン / 呼び出し単位 / 時間単位、USD/CNY/EUR/JPY/GBP、カスタム次元に対応。LiteLLM はトークンベースの追跡のみです。 | あり | なし |
| アップストリームの SSO 認証ログイン静的キーを持たないベンダー（例：Kiro）をオンボーディングできます。LiteLLM は静的 API キーのみです。 | あり | なし |
| ケイパビリティメタデータレジストリ自動注入とデグラデーションを駆動し、新モデルのケイパビリティ変化にコード変更なしで追従します。 | あり | なし |
| LTS リリースブランチN-1 + LTS ブランチ（/lifecycle を参照）。LiteLLM は直近 4 つのマイナー系列のみをサポートします。 | あり | なし |
両者が得意とするもの
確立されたベースラインです。どちらのゲートウェイでもこの層はカバーできます。判断は上下の層で行います。
| 機能 | GateLLM | LiteLLM |
|---|---|---|
| API ルーティング · フォールバック · 負荷分散 | あり | あり |
| BYOK、トークンへの上乗せなし | あり | あり |
| 完全セルフホスト、データはオンプレミスに留まる | あり | あり |
| クロスベンダーのツール呼び出し正規化 | あり | あり |
| 構造化出力（JSON Schema）の正規化 | あり | あり |
| 推論 / thinking トークンの適応 | あり | あり |
| モデルをまたぐプロンプトキャッシュ | あり | あり |
| Web 検索の注入 | あり | あり |
| MCP ゲートウェイ（ツール集約） | あり | あり |
| 設定用のビジュアルコンソール | あり | あり |
| 監査ログと利用量 / コストの計測 | あり | あり |
2026-09-04 時点で各製品の公式ドキュメント（docs.litellm.ai / docs.gatellm.io）に基づき検証済みです。LiteLLM の一部機能には Enterprise ライセンスが必要です。詳細は変わり得るため、調達前に出典を確認してください。
シークレットと PII は入口で検出されます。その後の扱いはお客様が決めます。
決定論的なルールエンジンが、すべてのモデルリクエストを認証情報の形式と PII について検査し、シークレット自体を記録せずに検出結果を記録します。組み込みルールは無効かつ observe モードで出荷され、お客様が有効化し、スコープごとに log、mask、block を選べます。検出経路にモデルは介在しません。
決定論的検出、経路にモデルなし
構造上、決定論的です。まずリテラル照合、次にコンテキスト語を要求する正規表現ルール、最後にチェックサム検証（カード番号の Luhn、IBAN の mod-97、各国 ID のチェックサム、PEM / OpenSSH 秘密鍵ブロック、IPv4）を適用します。
- 認証情報の形式：モデルプロバイダーの API キー、クラウドのアクセスキー、GitHub / GitLab トークン、JWT、PEM / OpenSSH 秘密鍵、Slack トークン
- PII の種類：中国本土の携帯番号、住民 ID、銀行カード番号、IBAN、メールアドレス、IPv4 アドレス
- マルチターンの会話では新規部分だけを走査します。カーソルハッシュチェーンにより、長いセッションでも既に検査済みのテキストを再走査しません
クライアント側で復元できるマスキング、何も漏らさないブロック
mask では、アップストリームのモデルは番号付きプレースホルダーを受け取り、クライアントには実際の値が復元されて返ります。ストリーミング中も SSE フレームごとに復元します。block では、拒否応答にルールのカテゴリとリクエスト ID が含まれ、一致したテキストは決して含まれません。
- アップストリームはプレースホルダーを見て、データの所有者には自分の値が返る
- 長い貼り付けも例外ではありません。巨大な文字列はディスクに退避し、固定サイズのウィンドウで走査するため、ペイロードの大きさにかかわらずメモリ使用量は一定です
- 許可リストは値で照合し、パスでは照合しません。テストキーを承認しても、フィールド全体が黙って除外されることはありません
ログ本文：受信したまま保存し、すべての出口で秘匿化
リクエストログの永続化は出荷イメージでは無効です。有効にすると本文は受信したまま保存され、すべての出力面で秘匿化されます。Console API は既定で秘匿化し、SSE とターミナル出力は常に秘匿化され、秘匿化に失敗した場合は応答を漏らすのではなく閉じます。
- 生の内容の表示は明示的な操作です。管理者ロールと明示的な表示フラグが必要で、監査され、回数も記録されます
- 秘匿化の対象は、機密性の高い本文キー、クエリ / URL パラメーター、静的およびカスタムの認証スキームヘッダー、部分表示付きのベアラートークン値です
- 検出結果には、前後の文脈を限定したマスク済みスニペットが残り、一致したテキストは残りません。検出結果はログの保持期間を共有し、既定は 7 日です
意図的に既定でオフ
組み込みルールパックは無効で出荷され、組み込みルールのアクションはすべて log です。これは隙間ではなく安全な段階的導入です。実際のトラフィックで何が起きるはずだったかを確認し、自社の誤検知に合わせて許可リストを調整してから、必要な箇所で mask や block を有効にしてください。ポリシーはグローバル、アクセスキーグループ単位、アクセスキー単位にスコープでき、ルールはホットリロードされます。
- 1
log観測します。検出結果はマスク済みスニペットとともにコンソールに届き、リクエスト自体は変更されません。
- 2
mask可逆的に強制します。アップストリームはプレースホルダーを見て、クライアントには実際の値が返ります。
- 3
block拒否します。リクエストはルールのカテゴリとリクエスト ID 付きで拒否され、一致したテキストは返りません。
できること、できないこと
できること
- お客様自身のゲートウェイプロセス内、モデルリクエストの経路上で動作し、グローバル / アクセスキーグループ単位 / アクセスキー単位にスコープできます
- 専用のコンソールページ：管理者とモニターロール向けの検出結果ビュー、管理者向けのルールビュー、メモリ予算の事前チェック付きのオン / オフスイッチ、ホットリロード、監査エントリ
- ドライラン用のプレビューエンドポイントがあり、ルールを有効化する前にサンプルで試せます
- すべての検出結果は、ルール名、カテゴリ、重要度、実行されたアクション、一致件数、モデル、アクセスキー名まで追跡できます
できないこと
- レスポンス内容の検出はありません。レスポンス側はプレースホルダーを復元するだけです
- ML は使いません。脱獄やプロンプトインジェクションの検出、モデレーション API もありません。ルールは決定論的です
- オフラインの再監査はありません。リクエスト時に走査されなかった内容が後から走査されることはありません
- DLP スイートではありません。エンドポイント、メール、その他の出力チャネルはカバーしません
- パスポート、SSN、氏名、住所の検出器はなく、既知の残存ギャップも文書化されています。base64 エンコードされたメディアは対象外で、2 つのストリームフレームに分割されたプレースホルダーはそのまま通過します
実際に得られるもの。
調達で重視される 3 点を、価格の前に整理します。法務が署名できる DPA、暴走しない請求、そして当社に届くことのないプロンプトです。
法務チームが署名できる DPA
GDPR と CCPA に対応し、法務チームが実際に署名できる DPA を用意しています。セルフホストでデータが境界の外に出ることはなく、エンタープライズ SSO（OIDC / SAML 2.0）と SCIM 2.0 プロビジョニングも含まれます。
暴走しない請求
BYOK：プロバイダーへ標準料金を支払い、トークンへの上乗せもシート課金もありません。キーとプロジェクト単位のハードなクォータ上限により、暴走したスクリプトが予算を超えることを防ぎます。
プロンプトが当社に届くことはありません
完全セルフホストのため、プロンプトと補完が当社のシステムに入ることはありません。BYOK のキーはゲートウェイのメモリ内だけに存在し、リクエストはプロバイダー API へ直接向かい、ネットワークの外に出ません。
完全セルフホスト · 単一インスタンス 2GB · トークン料金への上乗せは一切なし
BYOK（Bring Your Own Keys）で、プロバイダーへは標準料金を支払います。当社は 2GB の単一インスタンスをライセンスし、シート課金やトークンへの上乗せは行いません。より大きなメモリや複数インスタンスは Enterprise でご相談ください。
すべてのプランに含まれるもの：トークンへの上乗せゼロの BYOK · 100+ プロバイダーへのルーティング · クライアントアクセス制御 · プロンプトキャッシュ · コストクォータ
Free
完全セルフホスト · 単一ライセンス
512MB の単一インスタンスでログ保持なし。評価や PoC 向けで、本番トラフィックには適しません。
- ✓100+ LLM のルーティング · フォールバック · 負荷分散
- ✓クロスベンダーのモデル混在 · エージェント内ダウングレード（plan 固定 / 非 plan は自動ダウングレード）
- ✓クライアントアクセス制御（User-Agent ポリシー）
- ✓プロンプトキャッシュ
- ✓BYOK（自社キーを持ち込み、上乗せなし）
- ✓メモリ上限 512MB · SQLite · 単一インスタンス
- ✓自社ゲートウェイ経由の GitHub Actions コードレビュー
- ✓ログ保持なし
Pro
/ 月 · 2GB 単一インスタンス（固定上限）· 21 日間の無料トライアル
固定の 2GB 上限でアドオンなし。マルチノード、コンプライアンス（監査 / DLP）、Management API が必要な場合は Enterprise をご利用ください。
- ✓Free のすべての機能
- ✓メモリ 2GB · 単一インスタンス（固定上限、アドオンなし）
- ✓ログ保持
- ✓エンタープライズ SSO（OIDC：Azure AD / Okta / 汎用、加えて SAML 2.0 + SCIM）
- ✓PostgreSQL · メモリ 2GB
- ✓メール / チケットサポート
ご満足いただけない場合は 30 日以内に全額返金
Enterprise
メモリ容量ベース · 年額請求 · 30 日返金
- ✓Pro のすべての機能
- ✓容量ベースの課金（ノード数 × メモリ、月額 $400/GB の定額）
- ✓マルチノード / クラスタデプロイ
- ✓自社ゲートウェイ経由の GitHub Actions コードレビュー
- ✓Microsoft 365 アドイン（Excel / Word / PPT / Outlook、有償アドオン）
- ✓拡張ログ保持
- ✓優先サポート対応
- ✓コンプライアンス（監査 / DLP）
- ✓Management API（プログラムによる API キー · クォータ · 利用量照会 · 監査エクスポート）
より大きな容量やカスタム構成が必要ですか？ お問い合わせ →
機能比較
| 機能 | Free | Pro | Enterprise |
|---|---|---|---|
| マルチモデルルーティング · フォールバック · 負荷分散 | ✓ | ✓ | ✓ |
| クロスベンダーのモデル混在（ベンダーごとに計画 / 実行） | ✓ | ✓ | ✓ |
| エージェント内モデルダウングレード（plan 固定 / 非 plan は自動ダウングレード） | ✓ | ✓ | ✓ |
| プロンプトキャッシュ | ✓ | ✓ | ✓ |
| BYOK（自社キーを持ち込み、上乗せなし） | ✓ | ✓ | ✓ |
| メモリ階層 | 512MB | 2GB（固定） | カスタム |
| ストレージ / データベース | SQLite（単一インスタンス） | PostgreSQL · 2GB | PostgreSQL + Redis Cluster |
| デプロイ規模 | 1 インスタンス | 1 インスタンス · 2GB | マルチノード / クラスタ |
| GB あたりのスループット（参考） | — | 2GB ≈ 200M TPM / 1,000 RPM | 1GB あたり ≈ 100M TPM / 500 RPM |
| ログ保持 | なし | 保持あり | 拡張保持 |
| SSO（OIDC / SAML 2.0） | — | ✓ | ✓ |
| SCIM 2.0 自動プロビジョニング | — | ✓ | ✓ |
| コンプライアンス（監査 / DLP） | — | — | ✓ |
| Management API（プログラムによるキー · クォータ · 利用量 · 監査） | — | — | ✓ |
| 自社レートカード / 価格スナップショット（非公開価格を含む） | ✓ | ✓ | ✓ |
| コストクォータ（日次 / 月次、3 階層継承） | ✓ | ✓ | ✓ |
| サポート対応 | コミュニティ | メール / チケット | 優先対応 |
| モードを意識したモデルポリシー（plan / execute、強制可能） | ✓ | ✓ | ✓ |
| クライアントアクセス制御（User-Agent ポリシー） | ✓ | ✓ | ✓ |
| GitHub Actions コードレビュー（自社ゲートウェイ経由） | ✓ | ✓ | ✓ |
| Microsoft 365 アドイン（Excel / Word / PPT / Outlook、セルフホスト） | — | アドオン | アドオン |
| Purview 秘密度ラベルによるゲーティング（addin.access / file.upload） | — | — | ✓ |