S4 Firewall
LLMトークン予算と暴走ループ制御
自分のVPC内で動く転送プロキシで、LLMトラフィックの手前に事前的なスペンドファイアウォールを置きます。アプリのbase_urlを向けるだけ(OpenAI互換 / Anthropic Messages互換 / Bedrock互換)。各リクエストは attribute → reserve → budget/anomaly → forward → reconcile を同期的に通過。中核は暴走ループのサーキットブレーカ: 予算超過となるリクエストを中継前に決定論的にブロックします。
S4 Firewall は、LLMトークン支出の手前に予算とサーキットブレーカを置く転送プロキシです。2つの層を正直に分離: 層1のハードキャップは決定論的・事前的で、累積支出が分かるため設定上限を超える予約のリクエストを中継前にブロックします(上限超過の100%事前ブロック、同一状態→同一判定をカオステストで固定)。層2のループブロックはベストエフォートの振る舞い検知で、エージェントループ・近重複コール連鎖・セッション内増幅を検出して被害範囲を限定します。支出はfeature / tenant / customer単位で帰属。ストリーミングはチャンク単位で素通しし、TTFTを損ないません。
課題
LLM のトークン課金は、暴走したエージェントや near-duplicate な呼び出しの連鎖、セッション内での増幅によって、気づいたときには月の予算を焼き尽くしている、という事故が起きやすい領域です。出力トークン数は応答が返るまで分からないため、請求が発生する前に止める仕組みがないと、機能・テナント・顧客のどこでコストが膨らんだのかも後追いになりがちです。支払額が実際に必要な処理ではなく、制御されないループに連動してしまう点が課題です。
仕組み
- 1
base_url を向けるだけ
S4 Firewall はお客様自身の Amazon VPC 内で動く転送プロキシです。アプリケーション側は base_url を変更するだけで、OpenAI 互換・Anthropic Messages 互換・Bedrock 互換のインテークを受け、リクエストを既存のアップストリームプロバイダーへ中継します。ストリーミング応答はバッファせずチャンク単位でそのまま通すため、最初のトークンまでの時間(time-to-first-token)が保たれます。
- 2
同期パイプラインで予約・判定
中継の前に、リクエストごとに attribute → reserve → budget/anomaly → forward → reconcile の同期パイプラインを実行します。リクエストを機能・テナント・顧客に紐づけ、最悪コスト(入力トークンは今カウント、出力は max_tokens × 出力レートで価格化)を予約し、予算階層と照合してから、転送するかブロックするかを決めます。
- 3
2 層で止め、実測値で照合
Layer 1 のハードキャップは決定論的かつ先制的で、予約が設定上限を超えるリクエストは中継前に 100% ブロックします(同じ状態を入れれば同じ判定が出る、chaos test で確認済み)。Layer 2 のループブロックはベストエフォートの挙動ベースで、エージェントループや near-duplicate な呼び出し連鎖、セッション内増幅を検知して被害範囲を限定します。応答が返ると、プロバイダー報告の usage を真実の値として予約と reconcile します。
特長
決定論的ハードキャップ: 予算超過となるリクエストを中継前にブロック(tenant / feature / customerの予算階層)。
暴走ループのサーキットブレーカ: エージェントループと近重複コール連鎖を検出して被害を限定。
ドロップイン: OpenAI / Anthropic / Bedrock互換のbase_url、ストリーミング素通し(TTFT維持)、自分のVPC内で稼働。
含まれるもの
- Amazon Linux 2023 ベースの arm64 AMI(c6g / c7g Graviton インスタンスで動作、インスタンス時間あたりの従量課金)
- OpenAI 互換・Anthropic Messages 互換・Bedrock 互換のインテークを持つ転送プロキシ(アプリは base_url を変えるだけ、ストリーミングはチャンク単位でそのまま通過し TTFT を維持)
- Layer 1 ハードキャップ — 決定論的かつ先制的なサーキットブレーカー。機能・テナント・顧客の予算を超えるリクエストを中継前に 100% ブロック(chaos test で確認済み)
- Layer 2 ループブロック — エージェントループ・near-duplicate な呼び出し連鎖・セッション内増幅を検知するベストエフォートの挙動ベース層(被害範囲を限定。100% 保証ではなく、dry-run シャドウモードを同梱)
- reserve-then-reconcile のトークン会計 — 予約は最悪コスト(入力は今カウント、出力は max_tokens × 出力レート)、応答後はプロバイダー報告の usage を真実の値として照合
- 機能・テナント・顧客ごとのトークンスペンド属性付け、Amazon CloudWatch への出力(namespace S4/Firewall)と、オプションの counts-only 監査台帳(プロンプトや応答本文は記録しない)
- ワンクリックの CloudFormation テンプレート(単体構成の cfn-single.yaml と、内部ロードバランサー配下の冗長フリート用 cfn-ha.yaml)、最小権限の IAM ロール付き、別途コントロールプレーンやデータベースは不要
こんな用途に
暴走したエージェントが月の予算を焼き尽くす前に、決定論的なハードキャップで先制的に止めたいケース
機能・テナント・顧客ごとにトークンスペンドを属性付けし、IAM プリンシパルより細かい粒度で予算を割り当てたいチーム
プロンプトや応答本文を外部に渡したくなく、台帳にはトークン数のみを記録する形で LLM トラフィックを統制したいケース
アプリの base_url を向けるだけで、OpenAI / Anthropic / Bedrock 互換のトラフィックを自社 VPC 内で一括して予算管理したいケース
よくある質問
暴走したエージェントを 100% 止められますか?
2 つの層を正直に区別しています。Layer 1 のハードキャップは決定論的かつ先制的で、予約が設定上限を超えるリクエストは中継前に 100% ブロックします(同じ状態を入れれば同じ判定、chaos test で確認済み)。一方 Layer 2 のループ検知はベストエフォートです。暴走は数回呼び出してみないと判別できず、その数回はすでに課金されているため、100% 保証ではなく被害範囲を小さなリクエスト数・小さな金額に抑える性質のものです。enforce 前に false-block 率を測れる dry-run シャドウモードを同梱しています。
出力トークン数は事前に分からないのに、どうやって課金前に止めるのですか?
フラットな見積もりではなく reserve-then-reconcile で行います。中継前の予約は最悪コスト(入力トークンは今カウント、出力は max_tokens × 出力レートで価格化)を用いてハードキャップの判定を下します。応答が返ったら、プロバイダーが報告する usage を真実の値として予約と照合(reconcile)します。トークン数はプロバイダー間で正規化し、入力・出力・cached-read・cache-write に分けて各社の実レートで会計します。
プロンプトはどこに保存・送信されますか?
S4 Firewall 自体はプロンプトや応答を保存も送信もしません。外向きの通信は、アプリが元々行っていたプロバイダーへのリクエストだけで、ファイアウォールが余計な egress を足すことはありません。台帳とメトリクスにはトークン数のみが載り、本文は載りません(counts-not-content、property test で確認済み)。プロンプトがどこへ出るかは選んだアップストリーム次第です。Bedrock を VPC インターフェースエンドポイント(PrivateLink、本 AMI が任意で作成可能)経由で使えば呼び出しは AWS 境界内に留まり、公衆インターネット上のサードパーティへ送ればそのトラフィックは VPC を出ます。
別途コントロールプレーンやデータベースは必要ですか?
不要です。コントロールプレーンも外部データベースもありません。予算の状態はインスタンスごとにメモリ上で保持し、再起動時はゼロから再導出します。データプレーンは、昇格された capability を一切持たないハードニング済み systemd ユニット上で動く単一の静的バイナリで、最小権限の IAM ロール(アップストリームのモデル呼び出し、S4/Firewall namespace に限定した CloudWatch PutMetricData、台帳バケットへの write-only PutObject)が付与されます。テレメトリの home-call もライセンスキー検証もありません。
どのように課金され、どうデプロイしますか?
課金は AMI の時間課金(インスタンス時間あたりの従量)で、年間契約のオプションもあります。c6g / c7g(Arm)インスタンス上で動作します。デプロイは付属の CloudFormation テンプレートで行い、単体構成は cfn-single.yaml、内部ロードバランサー配下の冗長フリートは cfn-ha.yaml を使用します。テンプレートは任意で Bedrock の VPC インターフェースエンドポイントも作成できます。あとはアプリケーションの base_url をファイアウォールに向けるだけです。
料金モデル
時間課金のソフトウェア利用料 + EC2(c6g級、Arm)。インスタンスタイプ別の従量課金。