論文解説: TSCG — JSON Schemaの決定論的コンパイルでLLMツール定義トークンを52%削減

論文概要（Abstract）

TSCG（Tool-Schema Compilation for Generation）は、OpenAI Function Calling・Anthropic Tool Use・MCPなど本番エージェントフレームワークが送信するJSONツールスキーマを、トークン効率の高い構造化テキストに変換する決定論的コンパイラです。モデルへのアクセスやファインチューニングを必要とせず、8つの合成可能な演算子によりAPIバウンダリで動作します。TSCG-Agentic-Bench（約19,000コール、12モデル、5シナリオ）の評価で、Phi-4 14Bの精度を20ツール環境で0%から84.4%に回復し、52-57%のトークン削減を達成したと著者は報告しています。1,200行のゼロ依存TypeScriptパッケージとして公開されています。

この記事は Zenn記事: MCPサーバー自作でトークン消費94%削減の深掘りです。Zenn記事ではMCPツール定義の設計パターンによるトークンコスト削減を実装面から解説していますが、本論文はJSONスキーマからの変換を体系的・学術的に検証しており、なぜ構造化テキストへの変換がトークン削減と精度向上を同時に達成できるのかの理論的基盤を提供しています。

情報源

arXiv ID: 2605.04107
URL: https://arxiv.org/abs/2605.04107
著者: Furkan Sakizli
発表年: 2026年5月
分野: Software Engineering (cs.SE), Artificial Intelligence (cs.AI), Computation and Language (cs.CL)
GitHub: SKZL-AI/tscg

背景と動機（Background）

本番エージェントフレームワーク（OpenAI Function Calling、Anthropic Tool Use、MCP）は、ツール定義をJSON Schemaとして送信します。JSONはマシンパースに最適化された形式ですが、言語モデルによる解釈には適していません。特に4B-14Bの小規模モデルでは、JSONの冗長な構造（波括弧、引用符、キー名の繰り返し）がトークンを浪費し、ツール選択精度を著しく低下させます。

著者はこの問題を「プロトコルミスマッチ」と位置づけています。JSONは構造化データの交換規格として設計されたものであり、LLMのBPEトークナイザやTransformerのアテンション機構とは整合しません。たとえばJSON中の "description": "Get the current weather for a location" というフィールドは、スキーマの構造情報と自然言語の説明が混在しており、トークン効率が低くなります。

従来のプロンプト圧縮手法（LLMLingua等）はモデル推論を必要とし、42.5秒のレイテンシを伴います。検索ベースの最適化（DSPy、OPRO等）は反復的なLLM呼び出しが前提です。TSCGはこれらと異なり、モデルアクセスなしで決定論的にスキーマを変換するアプローチを提案しています。

主要な貢献（Key Contributions）

決定論的コンパイラ: JSON Schemaをトークン効率の高い構造化テキストに変換する、モデル非依存の変換パイプライン
8つの合成可能な演算子: トークン削減（4演算子）、構造再配置（2演算子）、トークン拡張（2演算子）の3カテゴリ
形式圧縮限界の証明: 整形されたスキーマで51%以上のトークン削減を保証する定理（Theorem 3.1）
TSCG-Agentic-Bench: 12モデル x 5シナリオ、約19,000コールの評価ベンチマーク
3つのoperator-response profile: モデルごとの最適な演算子構成の発見（operator-hungry / operator-sensitive / operator-robust）
フォーマット vs 圧縮の分離: R^2値が0.88から0.03に崩壊することで、精度向上の主因がフォーマット変換であることを実証

技術的詳細（Technical Details）

8つの合成可能な演算子

TSCGのパイプラインは10パス構成で、8つの演算子を3カテゴリに分類しています。

トークン削減演算子（4つ）

演算子	名称	機能
SDM	Semantic Density Maximization	104以上のフィラーパターンを除去し、セマンティック密度 $D(p) = \|sem(p)\| / \|tok(p)\|$ を最大化
TAS	Tokenizer-Aligned Syntax	BPEの学習済みマージに整合するデリミタを選択し、トークン数を最小化
DRO	Delimiter-Role Optimization	冗長な構造フレーズ（例: “the following items”）をコンパクトなデリミタに置換
CFL	Constraint-First Layout	出力制約をポジション0に再配置し、attention sink現象を利用

構造再配置演算子（2つ）

演算子	名称	機能
CAS	Causal Access Score	脆弱性スコアに基づきアトムをポジション0（attention sink）とポジションn（recency）に配置
CFO	Causal-Forward Ordering	オペレーション間の依存関係をトポロジカル順に再配置し、因果的アクセスを保証

トークン拡張演算子（2つ）

演算子	名称	機能
SAD-F	Selective Anchor Duplication with Fragility	脆弱性/トークン比で上位kのアトムをバジェットB内で重複配置し、重要情報を強化
CCP	Causal Closure Principle	ポジションnにクロージャブロックを追加し、recencyバイアスを利用してキーアトムを再提示

決定論的パイプライン

flowchart LR
    A[JSON Schema] --> B[Parse]
    B --> C[SDM]
    C --> D[TAS]
    D --> E[DRO]
    E --> F[CFL]
    F --> G[CFO]
    G --> H[CAS]
    H --> I[SAD-F]
    I --> J[CCP]
    J --> K[TSCG Output]

パイプラインは純粋関数合成 $\Pi = \tau_{10} \circ \cdots \circ \tau_1$ として定義され、決定論的な出力を保証します。同一入力に対して常に同一出力を返すため、キャッシュやテストが容易です。

形式圧縮限界（Theorem 3.1）

著者は以下の定理を証明しています。

\[|\text{tok}(\Pi(S))| \leq |\text{tok}(S)| \cdot \left(1 - \sum_i r_i \cdot f_i(S)\right)\]

ここで、

$\Pi(S)$: TSCGパイプライン適用後のスキーマ
$r_i$: 演算子 $T_i$ のトークンあたり削減率
$f_i(S)$: 演算子 $T_i$ が影響するトークンの割合
各トークン削減演算子は素なトークン部分集合に作用する

この定理は整形されたスキーマで51%以上の圧縮を保証します。実測値はシナリオAで61%、BFCLで66%、description圧縮で75%であり、素集合仮定の保守性から10-24ポイント上回ると著者は報告しています。

フォーマット vs 圧縮の分離分析

論文の重要な知見として、精度向上の主因はトークン「圧縮」ではなく「フォーマット変換」（JSON → 構造化テキスト）にあることが実証されています。

JSON baselineに対する回帰: $R^2 = 0.88$（強い予測力）
テキストbaselineに対する回帰: $R^2 = 0.03$, $p = 0.24$（相関消失）

$R^2$ が97%崩壊することから、小規模モデルの精度向上はJSON形式からの脱却によるものであり、真の圧縮効果ではないと著者は結論づけています。一方、フロンティアモデル（Claude Sonnet 4）ではテキストbaselineに対しても+5-11ppの改善が見られ、フロンティアモデルに対しては真の圧縮効果が存在することを示しています。

Causal Accessibility（因果的アクセス可能性）

CAS演算子の基盤となる概念として、アトム $a$ の因果的アクセス可能性を以下で定義しています。

\[A(a) = \frac{1}{L} \sum_{\ell=1}^{L} \text{Attn}^{(\ell)}(n, i)\]

ここで $L$ はレイヤ数、$\text{Attn}^{(\ell)}(n, i)$ はレイヤ $\ell$ における生成位置 $n$ からアトム位置 $i$ へのアテンション重みです。重要度が高くアクセス可能性が低いアトム（$F(a) \propto \text{importance}(a) - A(a)$）を、attention sinkとrecency位置に再配置します。

実装のポイント（Implementation）

TypeScriptでの基本的な使用方法

TSCGは @tscg/core パッケージとして公開されています。

  
import { compress } from "@tscg/core";

/**
 * MCPツールスキーマをTSCG形式に圧縮する
 *
 * @param tools - JSON Schema形式のツール定義配列
 * @param options - 圧縮オプション（model, profile等）
 * @returns 圧縮結果とメトリクス
 */
const tools = [
  {
    type: "function",
    function: {
      name: "search_files",
      description: "Search files by content or pattern in a directory",
      parameters: {
        type: "object",
        properties: {
          query: { type: "string", description: "Search query string" },
          path: { type: "string", description: "Directory path to search" },
          max_results: { type: "number", description: "Maximum results to return" },
        },
        required: ["query"],
      },
    },
  },
];

const result = compress(tools, {
  model: "claude-sonnet",
  profile: "balanced",
});

console.log(result.compressed);
// 出力例: search_files(query:str path?:str max_results?:num)|Search files by content or pattern
console.log(`Token savings: ${result.metrics.tokens.savingsPercent}%`);
// 出力例: Token savings: 62.5%

4つのプロファイル

著者はモデル特性に応じた4つのプロファイルを定義しています。

  
import { compress } from "@tscg/core";

// conservative: SDMのみ（小規模モデル向け）
const conservative = compress(tools, { profile: "conservative" });

// balanced: SDM+CAS+CFO+DRO+TAS+CCP（フロンティアモデル向け）
const balanced = compress(tools, { profile: "balanced" });

// aggressive: 全8演算子（Opus系向け）
const aggressive = compress(tools, { profile: "aggressive" });

// auto: ツール数に基づき自動選択
const auto = compress(tools, { profile: "auto" });

変換前後の比較

著者が示す実データの変換例として、約120トークンのJSON Schemaが約45トークンに圧縮されます（62.5%削減）。

変換前（JSON Schema）:

  
{
  "type": "function",
  "function": {
    "name": "search_files",
    "description": "Search files by content or pattern",
    "parameters": {
      "type": "object",
      "properties": {
        "query": { "type": "string", "description": "Search query" },
        "path": { "type": "string", "description": "Directory path" }
      },
      "required": ["query"]
    }
  }
}

変換後（TSCG balanced）:

search_files(query:str path?:str)|Search files by content or pattern

パフォーマンス特性

指標	値
処理速度	50ツールで2.4ms
4,096トークン以下	1ms未満
バンドルサイズ	34.7KB（gzip: 11.7KB）
外部依存	ゼロ
LLMLinguaとの比較	約40,000倍高速（42.5s vs <1ms）

Production Deployment Guide

AWS実装パターン

TSCGはAPIバウンダリで動作する軽量コンパイラであるため、インフラ構成はエージェントアプリケーション側に依存します。以下はTSCGをMCPプロキシとしてデプロイする3パターンです。

トラフィック量別の推奨構成:

規模	月間リクエスト	推奨構成	月額コスト	主要サービス
Small	~10,000 (300/日)	Serverless	$50-200	Lambda + API Gateway + Bedrock
Medium	~100,000 (3,000/日)	Hybrid	$500-1,500	Lambda + ECS Fargate + ElastiCache
Large	500,000+ (15,000/日)	Container	$2,000-8,000	ECS Fargate + ALB + ElastiCache

コスト削減テクニック:

TSCG圧縮によるBedrock費用削減: 52-57%のトークン削減はそのままBedrock利用料の削減に直結（入力トークン課金のため）
結果キャッシュ: 同一スキーマの圧縮結果は決定論的であるため、DynamoDBまたはElastiCacheにキャッシュ可能
プロファイル選択: 小規模モデル向けにはconservativeプロファイル（SDMのみ）で十分な圧縮効果を得られる
モデルルーティング: TSCGにより小規模モデルの精度が回復するため、簡単なタスクはPhi-4（14B）等の安価なモデルにルーティング可能

コスト試算の注意事項: 上記は2026年7月時点のAWS ap-northeast-1（東京）リージョン料金に基づく概算値です。Bedrockのトークン課金額がコストの大部分を占めます。最新料金はAWS料金計算ツールで確認してください。

Terraformインフラコード（Small構成: Lambda + API Gateway）

  
# TSCG MCP Proxy - Serverless構成
# TSCGの決定論的圧縮をLambda上で実行し、
# 圧縮済みスキーマでBedrockを呼び出す

resource "aws_lambda_function" "tscg_proxy" {
  filename      = "tscg_proxy.zip"
  function_name = "tscg-mcp-proxy"
  role          = aws_iam_role.lambda_tscg.arn
  handler       = "index.handler"
  runtime       = "nodejs20.x"
  timeout       = 30
  memory_size   = 256  # TSCGは軽量（<1ms処理）

  environment {
    variables = {
      TSCG_PROFILE        = "balanced"
      BEDROCK_MODEL_ID    = "anthropic.claude-sonnet-4-20250514-v1:0"
      CACHE_TABLE          = aws_dynamodb_table.tscg_cache.name
      ENABLE_METRICS       = "true"
    }
  }
}

resource "aws_dynamodb_table" "tscg_cache" {
  name         = "tscg-schema-cache"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "schema_hash"

  attribute {
    name = "schema_hash"
    type = "S"
  }

  ttl {
    attribute_name = "expire_at"
    enabled        = true
  }

  tags = {
    Purpose = "TSCG compressed schema cache"
  }
}

resource "aws_apigatewayv2_api" "tscg_api" {
  name          = "tscg-mcp-proxy-api"
  protocol_type = "HTTP"
}

resource "aws_iam_role" "lambda_tscg" {
  name = "tscg-lambda-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = {
        Service = "lambda.amazonaws.com"
      }
    }]
  })
}

resource "aws_iam_role_policy" "lambda_tscg_policy" {
  name = "tscg-lambda-policy"
  role = aws_iam_role.lambda_tscg.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = [
          "bedrock:InvokeModel",
          "bedrock:InvokeModelWithResponseStream"
        ]
        Resource = "arn:aws:bedrock:ap-northeast-1::foundation-model/*"
      },
      {
        Effect = "Allow"
        Action = [
          "dynamodb:GetItem",
          "dynamodb:PutItem",
          "dynamodb:Query"
        ]
        Resource = aws_dynamodb_table.tscg_cache.arn
      },
      {
        Effect = "Allow"
        Action = [
          "logs:CreateLogGroup",
          "logs:CreateLogStream",
          "logs:PutLogEvents"
        ]
        Resource = "arn:aws:logs:*:*:*"
      }
    ]
  })
}

Terraformインフラコード（Large構成: ECS Fargate + ALB）

  
# TSCG MCP Proxy - コンテナ構成
# 高トラフィック環境向けのECS Fargate + ALB構成
# ElastiCacheによる圧縮結果キャッシュを含む

resource "aws_ecs_cluster" "tscg" {
  name = "tscg-proxy-cluster"

  setting {
    name  = "containerInsights"
    value = "enabled"
  }
}

resource "aws_ecs_task_definition" "tscg_proxy" {
  family                   = "tscg-mcp-proxy"
  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"
  cpu                      = 512   # 0.5 vCPU（TSCG処理は軽量）
  memory                   = 1024  # 1GB

  container_definitions = jsonencode([{
    name  = "tscg-proxy"
    image = "${aws_ecr_repository.tscg.repository_url}:latest"

    portMappings = [{
      containerPort = 3000
      protocol      = "tcp"
    }]

    environment = [
      { name = "TSCG_PROFILE", value = "auto" },
      { name = "REDIS_URL", value = "redis://${aws_elasticache_cluster.tscg.cache_nodes[0].address}:6379" },
      { name = "BEDROCK_REGION", value = "ap-northeast-1" },
      { name = "NODE_ENV", value = "production" }
    ]

    logConfiguration = {
      logDriver = "awslogs"
      options = {
        "awslogs-group"         = "/ecs/tscg-proxy"
        "awslogs-region"        = "ap-northeast-1"
        "awslogs-stream-prefix" = "tscg"
      }
    }
  }])
}

resource "aws_ecs_service" "tscg_proxy" {
  name            = "tscg-proxy-service"
  cluster         = aws_ecs_cluster.tscg.id
  task_definition = aws_ecs_task_definition.tscg_proxy.arn
  desired_count   = 2
  launch_type     = "FARGATE"

  network_configuration {
    subnets          = var.private_subnet_ids
    security_groups  = [aws_security_group.tscg_ecs.id]
    assign_public_ip = false
  }

  load_balancer {
    target_group_arn = aws_lb_target_group.tscg.arn
    container_name   = "tscg-proxy"
    container_port   = 3000
  }
}

resource "aws_elasticache_cluster" "tscg" {
  cluster_id           = "tscg-cache"
  engine               = "redis"
  node_type            = "cache.t3.micro"
  num_cache_nodes      = 1
  parameter_group_name = "default.redis7"
  port                 = 6379
  subnet_group_name    = aws_elasticache_subnet_group.tscg.name
  security_group_ids   = [aws_security_group.tscg_cache.id]
}

resource "aws_appautoscaling_target" "tscg_ecs" {
  max_capacity       = 10
  min_capacity       = 2
  resource_id        = "service/${aws_ecs_cluster.tscg.name}/${aws_ecs_service.tscg_proxy.name}"
  scalable_dimension = "ecs:service:DesiredCount"
  service_namespace  = "ecs"
}

resource "aws_appautoscaling_policy" "tscg_cpu" {
  name               = "tscg-cpu-autoscaling"
  policy_type        = "TargetTrackingScaling"
  resource_id        = aws_appautoscaling_target.tscg_ecs.resource_id
  scalable_dimension = aws_appautoscaling_target.tscg_ecs.scalable_dimension
  service_namespace  = aws_appautoscaling_target.tscg_ecs.service_namespace

  target_tracking_scaling_policy_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ECSServiceAverageCPUUtilization"
    }
    target_value = 60.0
  }
}

運用・監視設定

TSCGの決定論的特性を活用した監視ポイントを以下に示します。

  
import { compress, CompressResult } from "@tscg/core";

/**
 * TSCG圧縮結果のCloudWatchメトリクス送信
 *
 * @param result - compress()の戻り値
 * @param toolCount - 入力ツール数
 */
function emitMetrics(result: CompressResult, toolCount: number): void {
  const metrics = {
    event: "tscg_compression",
    level: "info",
    ts: new Date().toISOString(),
    token_savings_percent: result.metrics.tokens.savingsPercent,
    input_tokens: result.metrics.tokens.input,
    output_tokens: result.metrics.tokens.output,
    tool_count: toolCount,
    profile: result.metrics.profile,
    duration_ms: result.metrics.durationMs,
  };

  // 構造化JSONログ（CloudWatch Logs Insights対応）
  console.log(JSON.stringify(metrics));
}

監視すべきメトリクス:

メトリクス	閾値	アラート条件
token_savings_percent	< 40%	圧縮率が期待値を下回る（スキーマ形式の異常）
duration_ms	> 10ms	TSCGコンパイルの異常遅延
tool_count	> 100	スケーリング実験の飽和点に接近
bedrock_error_rate	> 5%	圧縮後スキーマの解釈失敗

コスト最適化チェックリスト

TSCGプロファイルの最適選択（モデルごとのoperator-response profileに基づく）
スキーマ圧縮結果のキャッシュ（決定論的であるためTTL長めに設定可能）
Bedrockのトークン削減効果を月次で計測（52-57%の入力トークン削減）
小規模モデルへのルーティング（TSCGによりPhi-4等の精度が回復するため）
Operator-response profileに基づくCFO除外（GPT系モデル使用時）
Bedrock Batch API活用（非リアルタイム処理で50%割引）
CloudWatchアラーム設定（圧縮率異常・エラー率スパイク検知）
AWS Budgets設定（TSCG導入前後のBedrock費用比較）
コスト異常検知（Cost Anomaly Detection有効化）
Lambda Provisioned Concurrencyの検討（コールドスタート回避、高頻度呼び出し時）

実験結果（Results）

TSCG-Agentic-Bench

著者は5つのシナリオで評価を実施しています。評価指標は複合精度 $\text{Overall} = 0.6 \times \text{TSA} + 0.4 \times \text{Parameter_F1}$ です。統計手法として、各セル $n=20$ タスク $\times 3$ シード $= 60$ コール、ブートストラップCI（1,000反復）、Holm-Bonferroni補正済みMcNemar検定（$\alpha=0.05$、107比較）を使用しています。

シナリオ	ツール数	タスク数	特徴
A: Claude Code Catalog	16	20	実プロダクションツール
B: MCP Server Collection	43	100	MCP標準サーバ群
C: Scaling Stress	25-100	20	スケール限界テスト
D: Small Model Threshold	3-50	20	7モデルサイズ比較
E: Multi-Collection Stress	57	20	複合コレクション

小規模モデルの精度回復

モデル	Natural (JSON)	TSCG	改善幅
Phi-4 14B (20tools)	0.0%	84.4%	+84.4pp
Phi-4 14B (50tools)	-	90.3%	-
小規模モデル全体 (4B-14B)	0-49%	65-90%	+17-92pp

BFCL外部検証（Berkeley Function Calling Leaderboard）

著者はBFCLベンチマーク（$n=60$、3回実行）でも外部検証を実施しています。

条件	精度	ツール選択	パラメータF1	トークン削減
Natural	85.7%	86.7%	84.2%	-
TSCG	93.2%	95.0%	91.7%	46.8%
TSCG+SAD	89.0%	90.0%	87.5%	46.0%

精度保持率（ARR: Accuracy-Retained Ratio）は108-181%であり、トークン削減と同時に精度が向上するという結果を著者は報告しています。

3つのOperator-Response Profile

Leave-one-in方式（8演算子 x 3フロンティアモデル、各セル $n=40$、2シード）による分析の結果、著者は3つの異なるプロファイルを発見しています。

プロファイル	対象モデル	特徴	推奨構成
Operator-HUNGRY	Opus 4.7	全演算子が個別に貢献。CCP単独で+20pp	全8演算子（aggressive）
Operator-SENSITIVE	GPT-5.2	CFO適用で-5pp。全8演算子で-10pp	CFOを除外
Operator-ROBUST	Sonnet 4	6/7条件で80.0%同一。CFOのみ-2.5pp	任意の安全構成

スケーリング実験

Opus 4.7での5点スケーリング曲線の結果、軽量合成カタログ（75-100ツール）ではTSCGの優位性が飽和する一方、重いプロダクションMCPスキーマ（約10,500入力トークン/コール）では+5.0ppの改善とシード安定性（80/80/80）が持続すると著者は報告しています。合成ベンチマーク（TAB）は実MCPスキーマ性能を0.1精度ポイント以内で予測するとのことです。

実運用への応用（Practical Applications）

MCPプロキシとしての統合

TSCGは @tscg/mcp-proxy パッケージにより、既存のMCPサーバとクライアント間に透過的なプロキシとして挿入できます。アプリケーションコードの変更なしにトークン削減が実現可能です。

  
import { withTSCG } from "@tscg/tool-optimizer/langchain";

/**
 * LangChain統合: 既存エージェントにTSCG圧縮を適用
 *
 * @param agent - LangChainエージェントインスタンス
 * @returns TSCG圧縮が適用されたエージェント
 */
const optimizedAgent = withTSCG(agent);
// 以降のツール呼び出しは自動的にTSCG圧縮が適用される

モデル選択への活用

TSCGの実験結果は、小規模モデルの実用性を拡大します。Phi-4 14Bが20ツール環境で84.4%の精度を達成するということは、エッジデバイスやプライバシー制約環境でのツール呼び出しが実用レベルになることを意味しています。コスト面では、フロンティアモデルの52-57%のトークン削減は、大規模デプロイメントで月間数千ドルの節約に相当し得ます。

スキーマ圧縮が内部化できない理由

著者は、スキーマ圧縮をプロンプト内の指示で代替できない理由を以下のように説明しています。

トークナイゼーションはワンショット: モデルは事後的にトークンを再分割できない
圧縮指示がトークンを追加: 指示自体がトークンを消費し、削減効果を相殺する
フォーマット効果はアテンション前: モデルのmid-stream reframing機構では対処できない

まとめと今後の展望

TSCGは、JSONツールスキーマのLLMへの送信という、本番エージェントシステムで見過ごされがちな非効率に対して、理論的根拠のある解決策を提示しています。8つの合成可能な演算子による決定論的変換で52-57%のトークン削減を達成し、特に小規模モデルの精度回復（0% → 84.4%）は、エッジデプロイメントやコスト制約環境への応用可能性を示しています。

今後の展望として、モデル固有のoperator-response profileの自動検出、動的なプロファイル切り替え（ツール数やモデルに応じたautoプロファイルの高度化）、そしてマルチモーダルツールスキーマ（画像・音声パラメータを含むスキーマ）への拡張が考えられます。

参考文献

arXiv: TSCG: Deterministic Tool-Schema Compilation for Agentic LLM Deployments (arXiv:2605.04107)
GitHub: SKZL-AI/tscg
Related Zenn article: MCPサーバー自作でトークン消費94%削減：ツール定義設計の実装パターン
BFCL: Berkeley Function Calling Leaderboard
LLMLingua: LLMLingua: Compressing Prompts for Accelerated Inference

📄 論文解説: TSCG — JSON Schemaの決定論的コンパイルでLLMツール定義トークンを52%削減

論文概要（Abstract）

情報源

背景と動機（Background）

主要な貢献（Key Contributions）

技術的詳細（Technical Details）

8つの合成可能な演算子

トークン削減演算子（4つ）

構造再配置演算子（2つ）

トークン拡張演算子（2つ）

決定論的パイプライン

形式圧縮限界（Theorem 3.1）

フォーマット vs 圧縮の分離分析

Causal Accessibility（因果的アクセス可能性）

実装のポイント（Implementation）

TypeScriptでの基本的な使用方法

4つのプロファイル

変換前後の比較

パフォーマンス特性

Production Deployment Guide

AWS実装パターン

Terraformインフラコード（Small構成: Lambda + API Gateway）

Terraformインフラコード（Large構成: ECS Fargate + ALB）

運用・監視設定

コスト最適化チェックリスト

実験結果（Results）

TSCG-Agentic-Bench

小規模モデルの精度回復

BFCL外部検証（Berkeley Function Calling Leaderboard）

3つのOperator-Response Profile

スケーリング実験

実運用への応用（Practical Applications）

MCPプロキシとしての統合

モデル選択への活用

スキーマ圧縮が内部化できない理由

関連研究（Related Work）

まとめと今後の展望

参考文献

📄 論文解説: TSCG — JSON Schemaの決定論的コンパイルでLLMツール定義トークンを52%削減

論文概要（Abstract）

情報源

背景と動機（Background）

主要な貢献（Key Contributions）

技術的詳細（Technical Details）

8つの合成可能な演算子

トークン削減演算子（4つ）

構造再配置演算子（2つ）

トークン拡張演算子（2つ）

決定論的パイプライン

形式圧縮限界（Theorem 3.1）

フォーマット vs 圧縮の分離分析

Causal Accessibility（因果的アクセス可能性）

実装のポイント（Implementation）

TypeScriptでの基本的な使用方法

4つのプロファイル

変換前後の比較

パフォーマンス特性

Production Deployment Guide

AWS実装パターン

Terraformインフラコード（Small構成: Lambda + API Gateway）

Terraformインフラコード（Large構成: ECS Fargate + ALB）

運用・監視設定

コスト最適化チェックリスト

実験結果（Results）

TSCG-Agentic-Bench

小規模モデルの精度回復

BFCL外部検証（Berkeley Function Calling Leaderboard）

3つのOperator-Response Profile

スケーリング実験

実運用への応用（Practical Applications）

MCPプロキシとしての統合

モデル選択への活用

スキーマ圧縮が内部化できない理由

関連研究（Related Work）

まとめと今後の展望

参考文献

関連記事

📄 論文解説: MCP-Zero — 能動的ツール探索でMCPトークン消費を98%削減

📄 論文解説: MCP Tool Descriptions Are Smelly! — MCPツール記述の品質問題と改善手法

📄 論文解説: ツールスキーマ圧縮がコンテキスト制約下のAgentic RAGを可能にする