OpenAI・Anthropic互換APIを無料で使おう！「さくらのAI Engine」3,000リクエスト使い切りチャレンジ

さくらのAI Engine の無償枠数千リクエストで Kimi K2.6 と Gemma 4 31B の壊れ方を測ってみた話

Posted at 2026-08-24

コーディングエージェントでは、一つのユーザー操作の裏で多数の LLM 呼び出しが発生する。したがって、リクエスト数課金とトークン課金ではコストやプロンプトの設計の考え方が大きく異なる。

GitHub Copilot が6月にトークン従量課金へと移行した¹ように、AI エージェントが主流になる時代においてはリクエスト課金制を採用するサービスは減少している。多くの利用者にとって、「プロンプトのトークン数を節約すること」や「コンテキストをどう圧縮するか」に注意する必要性が高まってきた。

「さくらのAI Engine」が2026年8月現在提供する月3000リクエストの無償枠はこの時代においては極めて強力な選択肢となる。無償枠内ではリクエスト数単位でカウントされるため、1リクエストあたりのトークン量を増やしてもリクエスト消費数は「1リクエスト」となる。

今回は、この3000リクエストを単なる無償枠としてではなく、できるだけ独立した実験を多数回実施するための「実験予算」として使ってみる。さくらのAI Engine 自体は以前から普段づかいもしているため、今回の検証は月の下旬に行った。

対象としたモデル

さくらのAI Engine が提供する以下の2つのパブリックプレビューモデルを対象としてリクエスト粒度設計という観点から、モデルの限界や壊れ方を徹底的に検証した:

Kimi K2.6（1T-A32B MoE / MoonViT Vision）: preview/Kimi-K2.6
Gemma 4 31B It（31B Dense / 文化的知識・日本語・ロールプレイングに強い）: preview/gemma-4-31B-it

1. Kimi K2.6（1T-A32B MoE / MoonViT Vision）: `preview/Kimi-K2.6`

Kimi K2.6。なんと言っても総パラメーター数1兆という（モデルリリース当時にしては）圧倒的な知識量が特徴。個人的な使用感では推論も効率的で、コーディングエージェントとしても使いやすい。また、Vision 性能もかなり高いと思っている。

Kimi は K2.5 あたりから非常に実用的になったと感じている。過去にさくらの AI Engine においても K2.5 が提供されていた。正直その Kimi K2.5 が提供されるまでは、さくらの AI Engine のコーディングエージェント利用は厳しいと感じていた。それからこの Kimi K2.6 や、次に紹介する Gemma 4 31B まで知らないうちに追加されていて、なかなかラインナップが充実してきた。

7月末よりさくらの AI Engineでは Kimi K2.7 Code のパブリックプレビュー提供も行われているが、こちらはコーディングに特化したバージョンのように見受けられるため、今回は汎用性を優先して Kimi K2.6 を対象とした。また Kimi K3 については2026年8月現在、さくらの AI Engine では提供されていない。キリンさんになって待ちます。

2. Gemma 4 31B It（31B Dense / 文化的知識・日本語・ロールプレイングに強い）: `preview/gemma-4-31B-it`

Gemma 4 31B It。私の利用範囲では、文化的な知識や世界理解、そして日本語性能やロールプレイング性能が高いと感じるモデル。Vision 性能は中程度。

31B Dense 並の思考の深さはあるが、エージェントとしての能力は競合にやや劣る印象。

【第一部】OpenAI SDK での最小接続

まずは、さくらのAI Engine の OpenAI 互換 API を OpenAI Python SDK から小規模構成で利用してみる。

1. API キー（アカウントトークン）の発行

さくらのAI Engine コントロールパネルにログイン
「アカウントトークンを作成」ボタンよりアカウントトークンを発行

※ さくらのクラウド全体の API キーとは異なる。
※ 無償枠のみの利用でも、クレジットカードの登録が必要。

2. 最小接続コード (Python)

色々とライブラリが揃っているので取り敢えず今回は Python を採用する。

Gemma 4 31B はリーズニング対応のモデルであるが、今回使用したさくらのAI Engine では特にリーズニングを有効化するパラメーターは指定せず、デフォルト状態で実験した。

from openai import OpenAI

# Initialize client with Sakura AI Engine endpoint
client = OpenAI(
    api_key="YOUR_SAKURA_AI_TOKEN",
    base_url="https://api.ai.sakura.ad.jp/v1",
)

# preview/gemma-4-31B-it
response = client.chat.completions.create(
    model="preview/gemma-4-31B-it",
    messages=[
        {"role": "user", "content": "ご機嫌よう。お嬢様らしく自己紹介してくださる？"}
    ],
)
print("Gemma 4 31B:", response.choices[0].message.content)

Kimi-K2.6 はややリーズニング (CoT) が長めのモデルであるため、max_tokens を小さく設定しすぎるとリーズニング途中でトークン上限に達してしまい、最終回答 (content) が None (finish_reason='length') になってしまうので注意。

# preview/Kimi-K2.6
res = client.chat.completions.create(
    model="preview/Kimi-K2.6",
    messages=[{"role": "user", "content": "ごっつ斬新なダジャレ、なんか言うてや！"}],
    max_tokens=32768, # リーズニング用に十分なトークンを確保
)
msg = res.choices[0].message
# 今回は reasoning_content ではなく reasoning フィールドで返ってくる

if hasattr(msg, "reasoning") and msg.reasoning:
    print(f"[リーズニング内容]:\n{msg.reasoning}\n")
print(f"[最終回答]:\n{msg.content}")

※ Kimi-K2.6 はダジャレを振ると長考する傾向があるため、素早く応答させたい場合はより簡単な内容のプロンプトを推奨。

3. CLI で追試

本記事の実験系はすべて GitHub に公開しているため、気軽に手元で10問のミニテストを試すことができる:

git clone https://github.com/Rinrin0413/Sakura-AI-3K-lab.git
cd Sakura-AI-3K-lab
python3 -m venv .venv && source .venv/bin/activate # Windowsの場合は .venv\Scripts\activate
pip install -r requirements.txt
cp .env.example .env # SAKURA_AI_API_KEY を設定
python -m lab.runner --budget 10

【第二部】リクエスト粒度設計と実証耐久試験

1. ローカル LLM での限界とクラウドの必要性

私は普段 RTX 3060 12GB で Linux 上の llama.cpp を用いて、GGUF 量子化モデルのローカル推論を行っている。しかし、今回の2つのモデルを私のローカル環境で動かすには「サイズ」という大きすぎる壁が存在する：

モデル	ﾊﾟﾗﾒｰﾀｰ構成	4ﾋﾞｯﾄ量子化でのﾌｧｲﾙｻｲｽﾞ	12GB VRAM での可否
Gemma 4 31B	31B Dense	約 19GB	困難²
Kimi K2.6	1T-A32B MoE	約 580GB	不可

これらを日本国内の高速なクラウド基盤で、月3000回無償で利用できることの恩恵は計り知れない。

2. リクエスト粒度設計

リクエスト課金制においては、プロンプトをどう設計すべきであろうか。

バッチ充填型（詰め込み）: リポジトリ全体の依存関係解析や長文抽出など、全体文脈が必要なタスク（コンテキストウィンドウを最大限活用）。
独立試行型（展開）: 会話履歴によるバイアスを排除すべきタスク（LLM-as-a-Judge における順序バイアス回避や、本実験で採用したメタモルフィックテストのように、1問ごとにクリーンな文脈で推論させるべきタスク）。

本実験では後者の「独立試行型」の検証としてメタモルフィックテスティングを採用した。これは、「文脈の完全な独立性」が測定において不可欠となるため。

メタモルフィックテスティングとは、テスト対象の正解出力が事前に一意に定まらない場合でも、入力に対して一定の変換則を与えた際に、出力が期待される関係性を維持できるかを検証するソフトウェアテスト手法。本実験では「論理順序の入れ替え」「掛け算の対称性（可換律）」「等価なコードリファクタ」「二重否定」「敬語変換」の5系統の変換パターンを用いて検証を行った。

【第三部】実測データ・壊れ方・経済性考察

本実験におけるバッチ実行は、API インフラに過度な突発負荷をかけないよう最大並行数を 6 に制限し、レート制限検知時の指数バックオフ (1.5s–) による自己抑制機構を組み込んだパイプラインによって、約5時間半かけて穏やかに実行している。

また、短問に対する十分な思考バッファを確保しつつ、思考の過度な肥大化によるタイムアウトを防止するガードレールとして max_tokens=1024 に設定して実行した。

1. ベンチマーク実測結果

1,775リクエスト（成功 1,717件）の自動非同期バッチ実行による実測メトリクス:

指標	Kimi K2.6	Gemma 4 31B
総リクエスト数	888	887
成功率 (200 OK)	96.4%	97.1%
レスポンス時間 (平均値)	61.71s	2.29s
レスポンス時間 (中央値)	63.56s	1.03s
総消費出力トークン数	392,348	126,478
メタモルフィック一貫性スコア	90.1%	92.6%
摂動時の平均絶対文字数差	342.5 chars	52.2 chars

※ 論理推論・可換律・コード等価性・敬語表現の各タスクにおいて、入力表現を変化（摂動）させても本来保存されるべき論理結論が、摂動前後の双方で崩れず一致した割合を「メタモルフィック一貫性スコア」として算出した。
※ 全リクエストにおいては temperature=0.0 を明示的に指定して実行している。
※ メタモルフィックテストでは、5系統の代表的な摂動パターン（論理順序・計算対称性・コード等価性・二重否定・敬語表現）について、それぞれ選定した代表的な固定問題ペア（例: 17×23 と 23×17 等）を反復実行（Gemma 430ペア／Kimi 426ペア）した。これにより、同一の入力摂動に対してどれだけ結論がブレずに一致するか（ルールベース判定による一貫性スコア）、および出力文字数にどれほどのゆらぎ（ジッター）が生じるかを統計的に測定している。
※ 一貫性の判定は、LLM による主観的な採点を排除し、各カテゴリごとに定義された期待結論キーワード（論理順序・二重否定: yes、計算対称性: 391、コード等価性: true/yes、敬語表現: お伺い等）が摂動前後の双方の出力に含まれているかを決定論的（ルールベース）に判定した。
※ 短問に対する十分な思考バッファを確保しつつ、思考の過度な肥大化によるタイムアウトを防止するガードレールとして max_tokens=1024 に設定している。
※ API エラー等で片方でもレスポンスが欠損したペアは、比較の公平性を保つために集計から除外している。

ベンチマークの可視化

レスポンスレイテンシ分布を可視化した:

Kimi-K2.6 では直ぐに応答する群（0–20秒）だけでなく、約60秒–120秒付近にレイテンシのクラスタが観測された。ログを精査したところタスク種別による偏りはなく、クライアント側リトライが発生していないリクエストでも同様のクラスターが現れている。公開 API のブラックボックス検証であるため本実験のデータのみでは原因の特定には至っていない。

トークン生成密度とメタモルフィック頑健性（摂動感度）についても可視化した:

2. 壊れ方

Gemma 4 31B:
- 低レイテンシ (2.29s) と入力摂動に対する一貫性の高さ (92.6%)。
- 入力の順序や表現を変えてもブレが少なく、短文対話やリアルタイム TUI ツール、ロールプレイに適している。
Kimi-K2.6:
- リーズニングによる圧倒的な出力トークン量（39.2万トークン）。
- メタモルフィック一貫性スコアは 90.1% であったが、不一致となったログを精査したところ、推論の破綻ではなく「プロンプトの摂動によってリーズニング過程で長考し、1024トークンの上限に達して回答出力前に打ち切られた」ことが原因だった。よってモデル本来の論理破綻とは断定できない。

第一部で述べた通り本来 Kimi には余裕を持った max_tokens を指定すべきだったが、今回は無償枠の予算と検証時間の都合上あえて厳しいガードレール (max_tokens=1024) でのテストとした。結果として、案の定 Kimi はリーズニングを完遂できずエラーとなるケースが頻発してしまった。本番実行の前はよく考えよう（戒め）

3. レートリミット (429) の挙動と無償枠の使い切り

本実験による1,775リクエストの集中バッチ実行（及び今月の日常的な開発・検証利用分）を通して、さくらのAI Engine におけるレートリミット (429 Too Many Requests) の挙動について観測した。

ダッシュボードの利用状況とログを照合したところ月間の総リクエスト枠（3000回）だけでなく、モデルごとに設定された短時間のレート制御が個別に存在しているようだった。
バッチ処理を行う際は単純なリクエスト連打ではなく、リーズニングの有無などに応じた指数バックオフや並行数の調整が重要となる。

さいごに

測定データ、JSONL ログ、及び自動実行コードは GitHub で公開している。

GitHub Copilot is moving to usage-based billing - The GitHub Blog ↩
CPU 側への部分オフロードも可能だが、私の環境では生成速度は1桁 t/s ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up