Gemini 3.8 Flashのトークンコストは増える？2026年Agentコスト見積もり

Googleのリリース記録では、Gemini 3.8 Flashは2026年9月2日にGA（一般提供）となっています。公式リリース記録で確認できるこの時点から、移行判断を始めるべきです。Gemini 3.8 Flashのトークンコストは必ずしも高くなりませんが、3.7と単価が近いことだけで同じ費用になると判断してはいけません。 複雑な処理では思考トークン、ツール呼び出し、再試行、実行時間が増える可能性があるため、単純な処理は3.7または低推論、複雑な処理は3.8で同一タスクの完了コストを比較してください。

この記事は、Gemini 3.8 Flashへの移行を検討しているものの、Agentの用量が膨らむことを懸念している開発チーム向けです。モデル請求とツール実行資源を分けたいFinOps・プラットフォーム担当者、XcodeやmacOSのデスクトップツールまで含めてAI Coding環境を設計する担当者にも適しています。

注意: 以下では価格そのものを固定値として扱いません。Googleの料金、推論仕様、モデル状態は更新されるため、判断時点ではGemini APIの公式料金表とリリース記録を再確認してください。

移行前に押さえるトークンコストの構造

Gemini APIの請求を確認するとき、最初に「1回のリクエスト単価」だけを見ると判断を誤ります。最低でも、次の費目を別々に保存してください。

• 入力トークン: プロンプト、過去の会話、リポジトリの抜粋、ツール結果の再送分です。
• 出力トークン: 回答、パッチ、コマンド、次のアクションを含みます。
• 思考トークン: 推論強度やタスクの難しさによって増減する内部処理です。思考機能の公式説明では、複雑なタスクほど追加の思考や反復が発生し得ることが説明されています。
• 外部ツール費用: 検索、コード実行、外部APIなど、モデル料金とは別に発生する費目です。
• 再試行と実行器: 失敗した呼び出し、タイムアウトからの復旧、Agentを動かすサーバーやMacの占有時間です。

つまり、タスク単位の総費用は、モデルの入出力だけでなく、思考、ツール、再試行、実行環境を加えたものです。公式ベンチマークは特定条件での性能を示しますが、その数値をそのまま本番の費用削減率や開発速度へ換算することはできません。

低負荷タスクの分流

短い質問、コードの説明、小範囲の修正では、最高の推論強度が常に有利とは限りません。低推論で十分な処理を高推論に送ると、改善しないまま思考トークンと応答時間だけが増えることがあります。

Gemini 3.8 Flashの低・中・高推論は、モデル名を変えるのではなく、タスクの失敗コストに応じて使い分ける設計にします。低推論で完了した短い処理を、モデルの新しさだけを理由に全面移行する必要はありません。

複雑なリポジトリ作業の完了コスト

クロスファイルの修正、依存関係の確認、テスト失敗の修復では、単発のレスポンス料金より「最終的に動く状態へ到達するまでの総量」が重要です。Gemini 3.8 Flashが追加の推論で初回の計画を改善しても、ツールの誤選択や過剰な調査が増えれば、総費用は下がらない可能性があります。

比較時は、Gemini 3.7 Flashと3.8 Flashに同じ入力、同じブランチ、同じツール権限を与えます。次の記録を1タスク単位で保存すると、単回請求と実際の納品コストを分離できます。

• 最初の変更案が出るまでの時間
• 完了までの総呼び出し回数
• テスト失敗、権限エラー、ファイル競合などの失敗種別
• 再試行の回数と、同じツール結果の再利用回数
• 人が修正した行や確認した時間
• 最終的に必要だった入力、出力、思考トークン

場面例: あるAgentが3つのファイルを変更する場合、3.8の1回目の回答だけを見て「高い」と決めるのは不適切です。3.7で同じ作業が何度もテスト失敗になり、人による修正が必要なら、3.8の思考トークンが増えても納品までの総コストは低くなることがあります。逆に、両方とも同じ回数で完了するなら、短い処理は低推論または3.7に残す判断が合理的です。

ツール型Agentの反復呼び出し

関数呼び出しでは、モデルがツールを選択し、引数を渡し、結果を受け取り、その結果を次の判断へ戻します。Function callingの公式仕様に沿ってログを設計する場合、1回の会話を「入力1回、出力1回」と数えてはいけません。

検索やコード実行を使うAgentでは、次のようなループが発生します。

1. ユーザーの指示と現在のコンテキストを入力する。
2. モデルがツール選択と引数を出力する。
3. ツールが結果を返す。
4. 結果を含む入力を再度モデルへ送る。
5. 完了条件を満たすまで修正や検証を続ける。

コード実行の公式ドキュメントも参照し、モデル料金と実行器の利用を別の台帳にしてください。低・中・高の推論ごとに、無効なループ、同一検索の反復、停止条件を満たせなかった回数を比較します。

低推論は呼び出しが少なくなりやすい一方、前提を読み落として再試行が増えることがあります。高推論は初期の検討が厚くなりますが、単純なツール作業では追加トークンに見合う改善が出ない場合があります。成功停止条件を「回答を返した」ではなく、「テスト成功」「成果物保存」「人の確認完了」などに固定することが大切です。

長時間タスクの容量計画

バックグラウンドで動くAI Agentでは、コンテキストが時間とともに膨らみます。ツールの結果を毎回そのまま再送すると入力トークンが増え、失敗からの復旧では過去のログと新しい指示が重なります。コンテキスト上限は、毎回その上限まで消費するという意味ではありません。

見積もりでは、次の4つを分けて保存します。

• タスク完了までの経過時間
• モデルとツールを合わせた呼び出しラウンド数
• タイムアウトやテスト失敗からの復旧回数
• 同時実行による待ち行列とピーク時の占有量

短いタスクが多い環境では、平均値だけでなく、失敗が重なったときのピークを見ます。長時間タスクが少数でも、同時刻に集中するとモデルのリクエスト枠、ツール実行器、Mac環境のすべてが詰まる可能性があります。

コンテキストの再利用が有効な処理では、コンテキストキャッシュの公式説明を確認し、キャッシュ対象、保持条件、再利用できなかったケースを記録します。3.7を継続するか、複雑なタスクだけ3.8へ移すか、全面移行するかは、平均コストではなくピーク容量と復旧コストを含めて決めてください。

XcodeとMac実行環境の二層管理

モデルのクラウド推論費用と、Mac上で成果物を作る費用は別の層です。Gemini 3.8 Flashの応答が速くなっても、Macの使用量が同じ比率で減るとは限りません。反対に、思考トークンが増えても、Mac上で待機しているだけならビルド資源が比例して増えるとは限りません。

Macを増やさなくてよい処理

• リポジトリの設計相談
• コードの読み取りと説明
• 差分案の作成
• テスト結果を人が貼り付けた上での原因分析

Mac容量を分けて考える処理

• Xcodeのビルドとテスト
• シミュレーターの起動と操作
• ブラウザーやmacOSデスクトップツールの操作
• ファイル生成、変換、成果物の保存
• 複数ブランチの同時ビルド

ここで見るべき変数は、モデルのトークン数ではなく、タスクごとのMac占有時間、同時ビルド数、シミュレーターの同時利用、待ち行列の長さです。純粋な分析AgentだけならMacの追加は不要ですが、実際の検証や納品まで自動化するなら、モデルの分流とは別に隔離した実行環境を計画します。

Xcodeを含む運用の整理には、kvmsyncの日本語ブログも参照できます。利用可能な環境や運用上の制約を確認したい場合は、kvmsyncのヘルプで先に条件を確認してください。

完全タスク単位の分流手順

移行を一括で進めるのではなく、次の手順で判断します。

1. 代表タスクを分類します。 短い質問、小規模修正、複数ファイル変更、ツール利用、長時間実行、Xcode納品に分けます。
2. 入力条件を固定します。 同じプロンプト、同じリポジトリ状態、同じツール権限、同じ停止条件で3.7と3.8を比較します。
3. 推論強度を段階化します。 低推論から始め、失敗理由が推論不足と確認できた場合だけ中推論、高推論へ上げます。
4. トークンを分解して保存します。 入力、出力、思考、ツール結果の再送、再試行を一つの合計にせず記録します。
5. 完了証拠を定義します。 パッチ生成ではなく、テスト成功、成果物保存、レビュー完了までをタスク完了とします。
6. 人の手戻りを加えます。 修正時間、ログ確認、競合解消を費用項目に含めます。
7. Mac占有を別計上します。 Xcode、シミュレーター、ブラウザー操作、ファイル処理を行った時間と同時実行ピークを保存します。
8. 分流ルールを固定します。 単純な高頻度処理は3.7または3.8低推論、複雑な処理は回帰確認後に3.8、重要納品は3.7への回退経路を残します。
9. 価格変更時に再計算します。 公式のプロモーション、料金変更、既定推論強度、モデル状態、ツール対応範囲が変わった時点で再測定します。Gemini APIの変更履歴を監視対象にしてください。

移行判定のチェックリスト

• [ ] 3.7と3.8で同じタスク、入力、ツール権限を使った
• [ ] 入力、出力、思考トークンを別々に保存した
• [ ] ツール呼び出し、再試行、失敗からの復旧を数えた
• [ ] 成功率ではなく、納品完了までの総呼び出しを比較した
• [ ] 人の手戻り時間をモデル費用と別項目で記録した
• [ ] Xcodeやシミュレーターの占有時間を計上した
• [ ] 平均値とピーク時の同時実行数を分けた
• [ ] 3.7へ戻す条件と、3.8を停止する条件を文書化した
• [ ] 公式料金、モデル状態、推論仕様を再確認した

FAQ：移行判断で迷いやすい点

Gemini 3.8 Flashではなぜ3.7よりトークンが増えることがありますか？

複雑な処理では、より多くの思考ステップやツールとの反復が発生するためです。入力の再送、ツール結果の読み戻し、失敗からの復旧も加わります。したがって、単価が近くても、完了までの総入力・出力・思考トークンは同じとは限りません。

低・中・高の推論強度はどう選びますか？

短い質問や小規模な修正は低推論から始め、説明不足やテスト失敗が続いた場合に中推論へ移します。複数ファイルの変更や依存関係の分析では高推論を試しますが、追加の思考が初回成功率や手戻り時間を改善したかで採用を決めます。

Agentのツール呼び出し費用はどう分けて計算しますか？

モデルの入力、出力、思考トークンと、検索・コード実行・外部APIの費用を分けて記録します。さらに呼び出しラウンド数、再試行、ツール結果の再送、実行器の稼働時間を加えます。これでモデル請求だけでは見えない完了単価を把握できます。

Gemini 3.7 Flashから3.8 Flashへ移行するべきですか？

単純な高頻度処理まで一括移行する必要はありません。3.7で安定して完了する仕事は残し、複雑なコーディングや長時間タスクだけ3.8で回帰します。総トークン、完了時間、再試行、人工返工を比較し、改善が確認できた領域から段階的に広げてください。

3.8へ移行するとMacの実行容量も増やす必要がありますか？

モデルのトークン増加だけでは、Mac容量の増加量は算出できません。Xcodeビルド、シミュレーター、ブラウザー操作、ファイル処理を実行する場合に限り、占有時間と同時実行ピークを測定します。分析だけのAgentはMacを追加せず、納品タスクだけ隔離環境を増やす方法が適しています。

現行構成とMac環境の切り替え判断

現在の構成が共有Macや単一の実行環境に依存している場合、並列Agentが増えると、ビルド待ち、ファイル競合、シミュレーターの取り合いが起きやすくなります。クラウド推論だけを見て予算を組むと、実行器の待機時間や人による復旧作業を見落とします。

一方、Mac環境を常時増設すると、短い分析タスクしかない時間帯にも固定費が発生し、物理環境の管理負担も増えます。まず同一タスクのモデル費用とMac占有を分けて測定し、XcodeやmacOSツールを使う納品処理だけを短期の隔離環境で検証するのが現実的です。必要な期間だけMacをレンタルして実際の占有ピークを確認したい場合は、kvmsyncの料金案内で利用条件を確認してください。