AI 開発

AI モデルはなぜ大きくなるのか？パラメータ、Token、Context Window と JSON データ処理

JSONSort 公開 2026-09-05 更新 2026-09-07 約 16 分

数千億パラメータと百万トークンの窓が、それ自体を進歩として売られる。JSON 開発者にとって「より大きい」はたいてい、同じ注文オブジェクトがより高く、切れやすく、合法な構造として出しにくいことを意味する。混同されがちな三語——パラメータ、Token、Context Window——を分け、2026 年の JSON の扱い方に着地する。

先に要点

概念	一言	JSON との関係
パラメータ	学習可能な重みの数。おおよその「容量」	合法 JSON を安定して出せるかに効く
Token	テキストの長さと課金の単位	括弧・引用符・繰り返すキーにも料金が付く
Context Window	1 リクエストに載せられる token 上限	大きな JSON と多段の tool 結果が最初にぶつかる

より大きい ≠ JSON が上手。パラメータは容量、Token は請求、Context Window はバケツだ。バケツが広がっても、最初の一手は API 応答を丸ごと注ぐことではない。

大規模モデルはなぜさらに大きくなるのか

経験則は単純だ。データと計算が追いつくなら、パラメータを増やし、長く訓練するほど損失曲線は良くなりやすい。だからベンダーは「より大きい」を既定の物語にする——ベンチ、デモ、調達リストで語りやすい。

2024–2026 年の「大きい」は三軸に裂けた。もはやパラメータ数だけではない：

パラメータ規模：密なモデルはまだ増える。MoE は総パラメータを大きく保ち、トークンごとに一部だけ活性化する。
Context Window：8K・32K が 128K、さらに百万へ。Agent と長文が口実になる。
出力制約：Structured Outputs / JSON Schema は「より大きい」を「より安定したオブジェクト」に換え、長い散文にはしない。

JSON を書く人の問いは「何 B か」ではない。Schema への安定度、千 token あたりの価格、tool 結果が窓にまだ入るかだ。

パラメータとは何か？

パラメータは学習後に残る重みだ。推論では更新せず、計算にだけ使う。7B、70B、405B（十億）は容量であり、今回のリクエストが何文字読んだかではない。

パラメータが増えると、だいたい三つのことが起きる：

複雑な制約への適合が上がる。 入れ子、enum、required を踏み外しにくくなる。
推論は高く、遅くなる。 同じ JSON でも、大きいモデルは token あたりの遅延と単価が上がる。
Context Window が大きいことと同義ではない。 小さいモデルでも 128K を載せられる。巨大モデルが 32K のこともある。

2026 年の製品ページは MoE の「総パラメータ」と「活性化パラメータ」を並べたがる。請求がどちらで、遅延がどちらで測られるかを聞け。GPT-6 Astra ガイドが書いた通り、JSON 作業では安定した Structured Outputs の方が、一段大きな密モデルより価値が出ることが多い。

Token とは何か？

Token はトークナイザが切った断片であり、文字でも単語でもない。英語は 1 token ≈ 4 文字に近いことが多い。中国語・コード・JSON の句読点はより細かく割れ、同じ見た目の長さでも高くなる。

API は token で課金し、token で切る。システムプロンプト、ツール定義、履歴、ツールが返した JSON、モデルが出す JSON は、同じ台帳に入る。

JSON は本質的に高い。括弧、引用符、カンマ、インデント、繰り返すキーはそれぞれ token を取りうる。次の「完全な注文」は読みやすいが、送ると無駄だ：

{
  "order": {
    "order_id": "A-1042",
    "customer": {
      "full_name": "Ada Lovelace",
      "email": "ada@example.com",
      "locale": "en-GB"
    },
    "line_items": [
      {"sku": "KB-1", "title": "Keyboard", "qty": 1, "price": 99.00}
    ],
    "shipping": {"city": "London", "method": "express"},
    "debug": {"trace_id": "tr_9f", "retries": 0}
  }
}

次の Agent ホップでは、同じ業務でも普通はこれだけで足りる：

{
  "order_id": "A-1042",
  "amount": 99.00,
  "status": "paid"
}

まずローカルで整形して形を見、JSONPath 抽出で order_id / amount / status を抜き、minify してからモデルへ渡す。デバッグは整形、推論は痩せる。同じ payload ではない。

Context Window とは何か？

Context Window は1 リクエストが同時に持てる token 上限だ。入力と出力を同じ窓に数えるベンダーも、出力用に枠を残すベンダーもある。文書が曖昧なら「入力 + 予約した出力 ≤ 窓」で予算を組む。

8K から 128K、百万へ広がっても、JSON 処理が自動で簡単にはならない。「応答を全部貼る」が見かけ上可能になるだけだ。可能であることと、安く安定していることは別だ。

Agent ループでは、窓はだいたいこう削られる：

{
  "context_window": 128000,
  "spent": {
    "system": 1200,
    "tools": 3400,
    "history": 18000,
    "tool_result_json": 42000
  },
  "reserved_output": 4000,
  "remaining": 59400
}

表は例示であり、公式の請求書ではない。要点はtool 結果の JSON が prompt より太いことが多いことだ。投影も要約もしない多段 AI Agent 完全ガイドは、3 ホップ目でオブジェクトの半分を切り、次ホップがそれを完全な注文として扱う。

パラメータ、Token、Context Window はどう重なるか

三語は「モデルが大きい」に潰されがちだ。役割は違う：

パラメータは品質の上限：Schema に追けるか、additionalProperties の外で即興するか。
Tokenは各ホップの請求と遅延。同じ窓の肥えた JSON は履歴と出力余白を押し出す。
Context Windowは一度に見える量。バケツが大きくても、「パラメータが足りず制約を保てない」「token が高すぎて再試行できない」は直らない。

2026 年の定番事故：大きな窓を買い、2MB の pretty-printed JSON を注ぎ、モデルが前のフィールドを「忘れた」と責める。忘れていない。先に窓を満タンにしただけだ。

JSON データ処理に何を意味するか

日々のパイプラインでは、三層は具体的になる：

人には整形、モデルには圧縮。 インデントはエディタでは元が取れ、token 請求では純粋な浪費だ。
原文より投影。 ツールが 80 フィールド返すなら、次ホップが required としたキーだけ残す。
Schema は再試行の保険。 Structured Outputs は検証で不正 JSON の生成回数を減らし、出力 token を直接節約する。
文字列化された arguments は形を二度払う。 エスケープされた引用符は読みにくく枠を食い、ホストは再パースする。
長い文脈はデータベースではない。 照会はツールで。比較はローカル Diff で。5000 行のファイル二つを一つのメッセージに詰め込まない。

AI Agent が JSON Schema を必要とし始めた理由は Schema をランタイムゲートにした。構文は JSON Schema チュートリアル。版がずれたら、より大きなモデルを買う前に、先週動いたオブジェクトと今日拒まれたオブジェクトを JSON Diff する。

2026 年にコストを抑える（先に JSON、それからモデル）

各 Agent ステップに「文脈へ入れてよいフィールド」の許可リストを書く。JSON.stringify(fullResponse) は使わない。
ツール定義も痩せる。description に制約を残し、呼び出しを変えない散文は削る。
strict: true / json_schema を付け、再試行の代わりに検証を使う。
履歴は状態オブジェクトだけ残し、tool 原文は残さない。checkpoint は小さな JSON であり、チャットログではない。
秘密とユーザーフィールドはローカルで見て切る。公開 JSON サイトへ上げず、理由なくモデルへも送らない。

順番は投影 → 圧縮 → Schema → それから小さい／大きいモデルを検討する。逆にすると窓もパラメータも無駄になる。

よくある誤り

パラメータ数を Context Window だと思う。 70B と 128K は別の調達項目だ。同じスライドにあっても結びついていない。
文字数で token を見積もる。 JSON の句読点と中国語は、「長く見えない」オブジェクトを先に上限へ運ぶ。
窓が広がったから投影をやめる。 百万 token でも課金される。肥えた JSON は請求を長くするだけだ。
不正 JSON を大きなモデルで直す。 先に Schema とホスト検証を見る。多くの「モデルが鈍った」は required が一つ増えただけだ。
pretty JSON を本番 payload と同じだと思う。 エディタの空白を推論リクエストに出してはいけない。

FAQ

パラメータが大きいほど JSON は合法になるか？

傾向として良くなるが保証ではない。Schema とホスト検証がなければ、大きなモデルもフィールドを落とし、数を文字列で書く。容量は事故率を下げ、ゲートは事故が次ホップへ行くかを決める。

Token と文字は 4:1 で換算できるか？

英語の散文なら経験値になる。JSON・コード・中国語では不可。ベンダーの tokenizer か公式の計数 API を使え。エディタの文字数で請求を見積もるな。

Context Window にモデル出力は含まれるか？

多くの Chat / Responses API は出力を同じ予算に入れるか、max output を別に置く。最悪ケースは「入力 + 予約出力 ≤ 窓」。最後の閉じ括弧が切れないようにする。

すでに 1M 窓がある。JSON はまだ切るべきか？

切る。窓は「入るか」に答える。「払えるか」「次ホップが安定か」には答えない。投影と minify は既定動作のまま。

JSON が文脈を壊すか、ローカルでどう見るか？

まず整形して構造を見、フィールドを投影し、実際に送る文字列を数える。JSONSort はブラウザローカルで整形・抽出・Diff し、アップロードしない。

まとめ

モデルが大きくなるのは、より多いパラメータ、より長い窓、より多いデータが、今も評価で売れるからだ。JSON を扱う人にとってパラメータは容量、Token は請求、Context Window はバケツだ。整形済み JSON を大きなバケツに注ぐのは、別の形の使い過ぎでしかない。

今日から「このホップに入れてよいキー」を先に書き、それから大きなモデルが要るか決める。モデルはまだ大きくなる。口径は先に小さくせよ。

AI Agent とは？Tool Calling と JSON ランタイム、ツール呼び出し、JSON 契約
AI Agent が JSON Schema を必要とし始めた理由 Tool Calling から構造化ワークフローへ
GPT-6 Astra と JSON / API 新モデルでの Structured Outputs
JSON Schema とは required、enum、additionalProperties
JSONSort ローカルツール箱整形、抽出、Diff
すべての記事 JSON と AI 開発のノート

更新履歴： 2026-09-05 初回公開