Beat API Team · 仕様と料金の確認日：2026年10月14日
Gemini 4 Argon APIを既存のエージェントに組み込むなら、まず一つの作業に限定して移行し、合格条件と総費用を確認します。「100万トークン」という数字だけでは、回答に残せる枠、必要な接続方式、実際の費用は分かりません。導入時につまずきやすい5つの落とし穴を、仕様と計算例から確認します。
- 入力、内部推論、回答は同じコンテキスト枠を使います。100万トークンの入力に、さらに100万トークンの回答を追加できるわけではありません。
- GoogleのInteractions APIで65,536トークンを超える生成を行うには、バックグラウンド実行が必要です。
- 長い生成では既存の内容を再入力します。累計の課金対象入力と、現在のコンテキスト長は別の値です。
- 使用量の項目は通信形式で異なります。推論を含む合計に推論分をもう一度足すと二重計上になります。
- 合格条件を満たす最も低い推論レベルを選び、成功した作業一件あたりの費用で比較します。
対象は、コード修正や文書分析のエージェントを運用する開発者です。この記事では現在の仕様、移行例、手元で再計算できる費用モデルを組み合わせます。筆者はBeatAPIを開発しています。記事制作にあたりArgonへの認証付き推論リクエスト、速度測定、モデル品質の比較実験は実施していません。 コードは接続用のひな形、数値は仮定した入力に基づく計算です。
Gemini 4 Argon APIで何が変わるのか
9月の発表は限定公開についての説明でした。一方、10月13日更新の開発者向け資料ではAPIからの利用を案内しています。初期の記事をそのまま移行仕様として使わず、現在の公式ガイドを確認します。
特に、モデルが持つ能力と、実際に呼び出すAPIの機能を分けて考える必要があります。
| 接続先 | 今回の説明で扱う機能 | 自分の環境で確認する項目 |
|---|---|---|
| Google Interactions | 状態管理、推論レベル、バックグラウンドでの長い生成 | アカウント権限、SDKの版、保存要件、ツール結果の継続 |
| Google generateContent | Gemini固有の要求・応答、独自の継続手順 | 使用するSDKの項目と継続動作 |
| BeatAPI Chat Completions | 既存のOpenAIクライアント、モデルID、使用量 | 推論設定の対応、引数、配信内容の組み立て、出力上限 |
BeatAPIの公開ページはResponsesとGemini形式のgenerateContentも案内しています。ただし、OpenAI互換の接続先からGoogle Interactionsのバックグラウンド処理や管理型エージェント、組み込みツールまで使えると推測してはいけません。必要な機能に対応する契約を確認します。BeatAPIの接続案内
落とし穴1：100万トークンをそのまま回答に使えると考える
公式仕様の共通枠は1,048,576トークン、通常の同期生成上限は65,536です。長い生成を有効にしても、入力を除いた残りの枠を超えられません。公式モデルの入力はテキスト、画像、動画、音声、PDFで、出力はテキストです。画像生成やLive APIへの対応を意味しません。モデル仕様
生成に残せる枠 = 1,048,576 - 入力トークン
生成枠の消費 = 内部推論 + 表示される回答
入力が900,000なら、残りは148,576です。200,000なら848,576です。これは算術上の上限であり、その長さの回答が得られるという約束ではありません。
エージェントには二つの指標を持たせます。「現在組み立てている文脈の長さ」は圧縮判断に、「累計の課金対象入力」は費用計算に使います。同じ変数で管理しないことが重要です。
落とし穴2：出力上限だけで推論の負荷を調整する
Argonの推論レベルはlow、medium、highで、Googleの初期値はmediumです。推論レベルは考える深さを調整し、max_output_tokensは推論と回答の合計を打ち切ります。上限を小さくしすぎると、推論中に停止して表示される回答がほとんど残らない場合があります。推論と上限の仕様
| 候補 | 最初に割り当てる作業 | 測定する内容 |
|---|---|---|
| low | 項目抽出、単純な分類 | 値の正確さ、遅延、総使用量 |
| medium | 修正案のレビュー、ツールを使う調査 | テスト、ツールの正確さ、合格件数 |
| high | mediumで失敗する難しい課題 | 合格率の改善と追加費用 |
入力、ツール、判定条件は固定し、複数回試します。正しい答えが上限で切れたときは生成枠を増やす実験を、推論費用が大きいときは推論レベルを下げる実験を行います。設定値だけから品質向上を断言することはできません。
ツール結果を返すときに状態を失わない
Google Interactionsではstore: trueとprevious_interaction_idを使うことで、推論の署名を含む状態をサーバー側で保持します。状態を自分で持つ方式では、返された思考ブロックを変更せずに再送します。表示用の思考要約は、暗号化された署名の代わりにはなりません。組み込みツールの結果にも署名が付く場合があります。状態と署名
互換APIでは、その通信形式で定められたツール結果の対応と履歴管理を使います。同時に、入力、取得した資料、ツール呼び出し、結果、採用した成果物を独立した作業記録に保存します。あるサービスのinteraction IDは、別のサービスで復元できる履歴ではありません。
ツール実行後に通信が切れた場合、再試行前に実行記録を確認します。参照だけの処理と、決済・ファイル変更を同じ再試行規則で扱わないでください。変更には安定した操作IDと承認を使い、同じ処理を二度実行しない設計にします。
落とし穴3：長い生成を通常のリクエストとして扱う
多くのエージェントは短い往復を繰り返します。毎回巨大な回答枠を与える必要はありません。長い生成が必要なのは、一回の回答に通常の枠以上の推論と出力が必要な場合です。短い応答時間が必要なチャットや、入力だけで枠をほぼ使い切る要求には向きません。
Google Interactionsではbackground=True、store=True、65,536を超える生成上限を指定します。集めたテキストを成功結果として扱う前に、最終状態を判定します。長い生成の処理手順
import time
from google import genai
g = genai.Client() # Uses GOOGLE_API_KEY / GEMINI_API_KEY configuration.
job = g.interactions.create(
model="gemini-4-argon",
input=("Analyze this migration fixture and produce a review plan:\n\n"
+ open("task-fixture.txt", encoding="utf-8").read()),
store=True,
background=True,
generation_config={
"thinking_level": "high",
"max_output_tokens": 131072,
},
)
deadline = time.monotonic() + 900
while job.status in {"queued", "in_progress"}:
if time.monotonic() >= deadline:
raise TimeoutError(f"Resume or cancel interaction {job.id}; do not recreate it")
time.sleep(5)
job = g.interactions.get(id=job.id)
if job.status != "completed":
raise RuntimeError(f"Handle {job.status} explicitly; interaction={job.id}")
answer = "".join(
part.text
for step in job.steps if step.type == "model_output"
for part in step.content if part.type == "text"
)
print(answer)
print(job.usage)
これはGoogle API用であり、BeatAPIのバックグラウンド処理例ではありません。手元の待機が終了しても遠隔処理は止まりません。IDを保存して取得を再開するか、明示的に取り消します。requires_actionはツール実行、incompleteは上限や推論設定の見直し、failedは原因の調査が必要です。状態を区別せず再作成してはいけません。
入力12,000、生成150,000という仮定なら、65,536単位の三回の継続で参照する入力は次のようになります。
1回目: 12,000
2回目: 12,000 + 65,536 = 77,536
3回目: 12,000 + 131,072 = 143,072
累計入力: 232,608
最後の文脈: 約162,000
これは簡略化した計算例です。再入力の一部がキャッシュ対象になる場合でも、実際の応答で確認した使用量を使います。配信中のusageが累計値なら、更新前の値に足さず最新値へ置き換えます。
落とし穴4：使用量の意味をそろえずに料金を比べる
Google Interactionsはtotal_output_tokensとtotal_thought_tokensを別々に報告し、両方が課金対象です。BeatAPIのGemini Chat Completions仕様ではcompletion_tokensが推論を含み、reasoning_tokensはその内訳です。Googleの課金説明・BeatAPIのGemini仕様
通常入力 = 合計入力 - キャッシュ入力
課金対象生成 = 表示回答 + 推論 # Google Interactions
課金対象生成 = completion_tokens # Chat Completions
キャッシュ使用量が0以上で、合計入力以下であることを検証します（0 <= cached_input <= total_input）。項目が返らなければ「不明」とし、キャッシュなしの推定をする場合は推定と明示します。項目がないことを、命中ゼロの確認結果に置き換えてはいけません。元のusageも保存して、将来の仕様変更を追えるようにします。
3回の呼び出しで計算する
各要求に固定の24,000トークンと新規の3,000トークンを入れます。1回目はキャッシュなし、2・3回目は固定部分すべてに命中したと仮定します。合計の表示回答を12,000、推論を18,000とすると、通常入力33,000、キャッシュ入力48,000、課金対象生成30,000です。実測値ではありません。
費用 = (通常入力 × 入力単価
+ キャッシュ入力 × 命中時単価
+ 課金対象生成 × 出力単価) / 1,000,000
| 料金の基準 | 入力／キャッシュ／出力（100万トークン） | 計算結果 |
|---|---|---|
| Google通常枠・2026年11月30日まで | $2／$0.10／$10 | $0.3708 |
| Google通常枠・12月1日以降の公表予定 | $4／$0.20／$20 | $0.7416 |
| BeatAPI・10月14日確認の公開価格 | $1／$0.05／$5 | $0.1854 |
2026年10月14日に確認した価格では、BeatAPIのトークン単価はGoogle Standardの導入価格の半額です。100万トークンあたり、通常入力は$1（Googleは$2）、キャッシュ入力は$0.05（$0.10）、出力は$5（$10）です。同じ使用量で計算した上の例でも、BeatAPIのGemini 4 Argon APIは$0.1854で、Google Standardの$0.3708に対して50%低くなります。既存のクライアントを使いながらトークン費用を抑えたい場合に、検証する選択肢になります。GoogleのBatchとFlexは料金と実行条件が異なるため、この「半額」はStandardとの比較です。
Googleの日付と価格は公式料金表、BeatAPIは公開モデルページに基づきます。BeatAPI側は導入価格の終了日を固定していません。Googleの将来の日程をそのままBeatAPIに適用しないでください。この比較はトークン料金だけで、機能の同等性、税、ツール料金、品質や将来の価格を保証するものではありません。
キャッシュなしならGoogleの導入価格で$0.462です。キャッシュ入力の95%割引でも、この例の総額削減は約19.7%にとどまります。生成費用が大部分を占めるためです。推論18,000を忘れると$0.1908という過少な見積もりになり、反対にChat Completionsの合計へ推論を足すと過大になります。
落とし穴5：トークン単価だけでモデルを選ぶ
合格一件の費用 = 失敗・再試行も含む全作業費用 / 合格件数
仮に一回$0.10で合格率50%なら一件$0.20、一回$0.15で合格率90%なら約$0.167です。これは名前のあるモデルの成績比較ではありません。トークン単価が低いことだけでは、運用上の優劣を決められないという算術例です。
エージェント全体より先に、一つの作業を移行する
例として、決済アダプターの再試行処理にある不具合を調べる作業を考えます。機密情報を除いた失敗テスト、関係するコード、公開インターフェースの仕様を渡し、修正案と回帰テストを求めます。最初の段階では、ツールはファイルの参照とテスト結果の取得だけに限定し、変更の適用は人が確認します。
回答を見る前に、合格条件を固定します。
- 修正案が失敗していた動作を直し、既存の回帰テストを通す。
- 公開インターフェースを維持し、許可された依存関係だけを使う。
- ツールの引数がスキーマに一致し、結果が元の呼び出しIDに対応する。
- 実在するファイル位置を示し、根拠のない説明は仮説と明示する。
- 費用と時間の上限内で終わるか、再開可能な状態で停止する。
JSONが正しいことと、修正が正しいことは別です。モデルの「テストが通る」という説明ではなく、実際のテスト結果で判定します。
既存のクライアントから始める
既存のエージェントでOpenAIクライアントを使っている場合は、BeatAPIのGemini 4 Argon APIページでモデルID、対応する接続方式、現在の料金を確認できます。次はそのOpenAI互換接続を使うひな形です。APIキーは環境変数から読み込みます。
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["BEATAPI_API_KEY"],
base_url="https://api.beatapi.io/v1",
timeout=900.0,
max_retries=0, # Keep retries in your task runner's audit trail.
)
result = client.chat.completions.create(
model="gemini-4-argon",
messages=[{
"role": "user",
"content": (
"Review the sanitized code and failing tests below. "
"Propose a minimal patch, list regression tests, and "
"cite file paths. Do not claim tests were run.\n\n"
+ open("task-fixture.txt", encoding="utf-8").read()
),
}],
max_tokens=32768,
)
print(result.choices[0].message.content)
print("finish_reason:", result.choices[0].finish_reason)
print("usage:", result.usage.model_dump() if result.usage else None)
隔離した環境にopenaiを入れ、自分のtask-fixture.txtを用意します。32,768は移行時の開始値であり、すべての接続先に最適な値ではありません。このコードは手元で構文を確認しましたが、Argonには送信していません。
temperature=0を再現性の保証として追加しないでください。最新の公式ガイドでは、Argonはtemperature、top_p、top_kを無視します。互換API側が受理・拒否・削除のどれを行うかも確認します。reasoning_effortとGoogleのthinking_levelの対応も、変換処理を調べずに仮定しないことが必要です。
本番導入前の確認項目
| 症状 | 確認するもの | 対応 |
|---|---|---|
| 回答が短く、生成使用量だけ大きい | 推論中の打ち切り、最終状態 | 生成枠を増やすか推論を下げて比較 |
| 文脈を早く圧縮しすぎる | 累計入力を文脈長に使っていないか | 現在の文脈を別に数える |
| 見える回答より請求が大きい | 推論、再試行、外部ツール | 全試行を含めた使用量にそろえる |
| 長い生成が拒否される | 呼び出し先と実行方式 | 対応する継続方式を使う |
| キャッシュ割引が出ない | 固定部分の変更、命中の記録 | 固定部分を先頭にまとめて測る |
| 再接続後にツールが二度動く | 実行記録とイベントの再送 | 操作IDで重複を防ぐ |
Argonでは明示的なキャッシュ作成・参照を外します。Googleの説明では暗黙のキャッシュは4,096トークン以上の入力で有効になりますが、固定の先頭部分があっても命中は保証されません。
固定した評価用の作業集合で検証し、撤回条件を決めてから少量の本番流量へ広げます。合格率、ツールや形式の失敗、使える回答までの時間、最終状態、総費用を記録します。変更を伴う処理を二つのモデルで比較するときは、実処理の代わりに模擬ツールを使います。
よくある疑問
画像やリアルタイム音声を生成できますか。 公式モデルはテキスト出力で、画像生成とLive APIには対応していません。入力を理解する能力と生成する能力を分けてください。
100万トークンを毎回出力できますか。 入力と推論にも同じ枠を使い、実行方式による上限もあるため、できません。
すべてhighにすべきですか。 mediumから始め、同じ合格条件で比較してから選びます。
回答の文字数だけで費用を見積もれますか。 推論、再入力、失敗、外部ツールを含める必要があります。
completedなら作業も成功ですか。 モデルの生成終了と、アプリケーションの合格判定は別です。
BeatAPIではどこから始めますか。 Gemini 4 Argonの接続・料金ページで通信形式を選び、一つの限定した作業を使用量付きで記録します。高度な設定とツールの動作を確認してから対象を増やしてください。