# Gemini 3.5 Flashの性能評価：公式API ID、得意分野、制限、移行判断

> Gemini 3.5 Flashは`gemini-3.5-flash`として公式に呼び出せる。エージェント型コーディング、長いツールワークフロー、マルチモーダル入力理解に強い一方、画像生成、音声生成、Live API、Computer Use、最安バッチ処理には向かない。

- URL: https://blog.laozhang.ai/ja/posts/gemini-3-5-flash-capabilities
- Published: 2026-05-20
- Updated: 2026-05-20
- Author: AI Free API Team (https://blog.laozhang.ai/ja/about)
- Category: AI Model Guide
- Tags: Gemini 3.5 Flash, Gemini API, gemini-3.5-flash, AIモデル選定, Google AI

---
2026年5月20日UTC時点で、Gemini 3.5 FlashはGemini APIのGA/stableモデルとして公開されており、APIでは`gemini-3.5-flash`を使います。短い結論は、エージェント型コーディング、長いツールワークフロー、マルチモーダル入力理解、長文脈の作業をまず試す価値がある、というものです。

ただし、すべてのFlash用途を置き換えるモデルではありません。画像生成、音声生成、Live API、Computer Use、または最安コストを優先する大量処理では、別のGeminiルートを先に確認すべきです。モデルが賢いことと、実行ルートが合っていることは別問題です。

| 判断 | Gemini 3.5 Flashを先に試す条件 | 先に避ける、または比較する条件 |
|---|---|---|
| 使う | エージェント型コーディング、ツール呼び出しの多い作業、長文脈、マルチモーダル入力、構造化出力、短い反復が重要。 | 低価格の抽出、単純な大量翻訳、リアルタイム音声、画像出力、音声出力、ブラウザやUI操作。 |
| 公式契約として扱う | コード、設定、ログでは`gemini-3.5-flash`を使う。 | 古いGemini 3 Flashの価格、preview前提、model stringをそのまま引き継がない。 |
| 移行テストする | 既存のFlash、Flash-Lite、Live、Proでエージェントやコード作業に限界がある。 | 同じ入力、同じツール、同じtoken予算、同じ失敗例で比較する前に本番標準を変えない。 |

![Gemini 3.5 Flashの能力判断ボード](https://blog.laozhang.ai/posts/ja/gemini-3-5-flash-capabilities/img/cover.webp)

2026年5月20日の公式ドキュメント確認では、Gemini 3.5 Flashはtext、image、video、audio、PDFを入力でき、出力はtextです。入力上限は1,048,576 tokens、出力上限は65,536 tokens。Standard価格はinput `$1.50 / 1M tokens`、output `$9.00 / 1M tokens`です。したがって評価すべき点は「強いかどうか」だけではなく、エージェント性、コード品質、長文脈処理の改善がその価格に見合うかです。

## 公式ステータスとmodel ID

Gemini 3.5 Flashは旧Gemini 3 Flashの言い換えではなく、Google AI for Developersで安定版として掲載されているモデルです。開発で使う文字列は`gemini-3.5-flash`です。Gemini APIのchangelogにも2026年5月19日の項目として記録されています。

この区別は実装上かなり重要です。`gemini-3-flash-preview`、Flash-Lite、Live、Proは、それぞれ価格、出力種別、対応機能、実行モードが違います。Flashという名前だけで「安い」「速い」「既存のFlash用途を全部置き換える」と判断すると、品質ではなくルート設計で失敗します。

チームの設定では、model ID、Developer APIかVertex AIか、StandardかBatch/Flex/Priorityか、ログ上のroute ownerをまとめて管理してください。あとで価格や機能が変わっても、アプリ全体を検索して古い文字列を探す必要がなくなります。

Gemini 3.2 Flashのステータスを追っていた場合は、[Gemini 3.2 Flashのステータス記事](https://blog.laozhang.ai/ja/posts/gemini-3-2-flash-news)と切り分けてください。ここで扱う判断は、正式に載った3.5 FlashのAPI契約と実ワークロードでの移行可否です。

## 得意分野

![Gemini 3.5 Flashの能力マトリクス](https://blog.laozhang.ai/posts/ja/gemini-3-5-flash-capabilities/img/capability-matrix.webp)

Gemini 3.5 Flashが最も試しやすいのは、推論、ツール呼び出し、長文脈、複数形式の入力が同時に必要なタスクです。具体的には、コードエージェント、障害解析、長いPDF束の読解、スクリーンショットを含むサポートチケット、URL付きの調査、構造化JSON出力、ファイル検索を含むアプリ内アシスタントなどです。

公式モデルページでは、Batch API、caching、code execution、file search、function calling、Google Maps grounding、Google Search grounding、structured outputs、thinking、URL context、Flex inference、Priority inferenceが列挙されています。これは短いチャット応答だけでなく、実際のバックエンドワークフローに組み込むための機能面が広いことを示します。

入力面も広く、text、image、video、audio、PDFを受け付けます。出力はtextなので、マルチモーダルな材料を読み、最終的に判断、修正案、JSON、チェックリスト、次の作業へ変換する使い方と相性が良いです。逆に、画像や音声そのものを出力する契約ではありません。

| ワークロード | 適性 | 理由 |
|---|---|---|
| コードエージェント | 高い | function calling、code execution、structured outputs、長文脈が直接効く。 |
| マルチモーダル文書アシスタント | 高い | PDF、画像、動画、音声、テキストを同じ判断に使える。 |
| 検証可能な回答生成 | 中高 | URL context、Google Search grounding、構造化出力が役立つ。 |
| バッチ評価やオフライン分析 | 中高 | Batch/Flexで費用を下げられる可能性がある。 |
| 低価格の大量抽出 | 要比較 | Flash-Liteや別の低コストモデルのほうが合うことがある。 |

日本語圏の話題では「FlashなのにProに近い」「速度が速い」といった見え方が強くなりがちです。しかし開発チームに必要なのは、ベンチマークの印象よりも、どの作業で失敗率、再試行、人手レビュー、ツールミスを減らせるかです。

## 使わない条件

Gemini 3.5 Flashの現在のモデルページでは、image generation、audio generation、Live API、Computer Useが対応項目として並んでいません。ここは曖昧にしないほうが安全です。出力や実行形式が違うなら、別のモデルルートを選ぶべきです。

リアルタイム音声対話ならLive APIのモデルを見ます。画像を作るなら画像生成向けのGemini imageやImagenのルートを見ます。UIやブラウザ操作が必要ならComputer Useを明示的にサポートするモデルを選びます。Gemini 3.5 Flashの推論力で別ランタイムの不足を埋める、という考え方は本番では危険です。

| 要件 | Gemini 3.5 Flashでよいか | より安全な方向 |
|---|---|---|
| マルチモーダル入力からテキスト回答 | よい | `gemini-3.5-flash` |
| リアルタイム音声エージェント | 不適 | Live APIモデル |
| 画像生成 | 不適 | Gemini imageまたはImagenルート |
| 音声生成 | 不適 | Live/audio generationルート |
| UIやブラウザ制御 | 不適 | Computer Use対応モデル |
| 最安の大量処理 | 要比較 | Flash-Lite、Batch/Flex、低コストモデル |

モデル選定では、まずoutput type、runtime、価格モード、ツール対応を見ます。そのあとに品質を比較します。この順番を逆にすると、賢いモデルを選んだのにプロダクト要件を満たせない、という状態になります。

## 価格の読み方

![Gemini 3.5 Flashの価格とルートマップ](https://blog.laozhang.ai/posts/ja/gemini-3-5-flash-capabilities/img/pricing-route-map.webp)

2026年5月20日の公式価格スナップショットでは、Gemini 3.5 FlashのStandardはinput `$1.50 / 1M tokens`、output `$9.00 / 1M tokens`です。BatchとFlexはinput `$0.75 / 1M tokens`、output `$4.50 / 1M tokens`。Priorityはinput `$2.70 / 1M tokens`、output `$16.20 / 1M tokens`です。

この価格は、旧Flashの感覚で安いと決めつけるべきではありません。Standardは通常のオンライン呼び出し、Batch/Flexは待てる評価やバッチ処理、Priorityはキューや遅延リスクを下げたい高優先度トラフィックに使うものです。

| モード | 入力価格 | 出力価格 | 主な使い方 |
|---|---:|---:|---|
| Standard | `$1.50 / 1M` | `$9.00 / 1M` | オンライン呼び出し、最初の評価、本番候補。 |
| Batch / Flex | `$0.75 / 1M` | `$4.50 / 1M` | オフライン評価、待てるジョブ、バッチ処理。 |
| Priority | `$2.70 / 1M` | `$16.20 / 1M` | 優先度が価格より重要なトラフィック。 |

出力tokensが多いタスクでは費用が急に大きくなります。コード生成、長い報告書、複数回の修正提案では、単価だけでなく再試行回数、検証コスト、人間のレビュー時間を一緒に見てください。単発のtoken価格が高くても、失敗や再作業が減るなら総コストで有利になることがあります。

無料枠やレート制限は固定の数字として扱わないでください。モデル、プロジェクト、地域、billing state、serving modeで変わります。詳細は[Gemini API無料枠ガイド](https://blog.laozhang.ai/ja/posts/gemini-api-free-tier)を確認し、実際のリリース前には必ず現在のプロジェクトで確認してください。

## 最初のAPIテスト

最初のテストは雑なチャット質問ではなく、導入したい実タスクで行うべきです。コードエージェントの失敗trace、長いPDF、マルチモーダルな問い合わせ、構造化出力、ツール呼び出しを含む作業を使います。

```ts
import { GoogleGenAI } from "@google/genai";

const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });

const response = await ai.models.generateContent({
  model: "gemini-3.5-flash",
  contents: [
    {
      role: "user",
      parts: [
        {
          text:
            "Analyze this failing coding-agent trace. Return the likely owner, first verification step, and safe rollback plan.",
        },
      ],
    },
  ],
});

console.log(response.text);
```

評価では、model ID、serving mode、input tokens、output tokens、latency、tool-call成功率、structured outputの合格率、retry数、人手レビュー時間を記録します。Developer APIとVertex AIのどちらで運用するかも決める必要がある場合は、[Gemini API vs Vertex AI API](https://blog.laozhang.ai/ja/posts/gemini-api-vs-vertex-api)で認証、IAM、監査、リージョン、Cloud課金の違いを分けてください。

## 移行前のスモークテスト

![Gemini 3.5 Flashの移行スモークテスト](https://blog.laozhang.ai/posts/ja/gemini-3-5-flash-capabilities/img/migration-smoke-test.webp)

新しいモデル名だけで本番defaultを変えないでください。同じタスクで比較し、どのworkloadだけを移すか決めます。

1. 現在のモデルが失敗しやすい、コストが高い、または人手修正が多いタスクを5つ選ぶ。
2. 既存ルートと`gemini-3.5-flash`を同じ入力で実行する。
3. 回答品質、tool correctness、JSON validity、latency、token use、retry count、review timeを比較する。
4. Standardで費用を計算し、待てるタスクはBatch/Flexも再計算する。
5. 事前に決めた閾値を超えたworkloadだけを移し、旧model stringをrollbackとして残す。

| 現在のルート | 3.5 Flashを試す条件 | 現在のルートを残す条件 |
|---|---|---|
| Gemini 3 Flash | エージェント、コード、長文脈でより強い動作が必要。 | 既存ルートが十分正確で安い。 |
| Flash-Lite | 品質低下や推論ミスがtoken節約より高くつく。 | タスクが単純、大量、価格重視。 |
| Flash Live | 音声会話ではなくテキスト出力backendへ移る。 | 製品がまだリアルタイム音声中心。 |
| Proルート | 一部タスクをより速く、安く回したい。 | 正確性が最優先でProが明確に必要。 |

移行判断はブランド単位ではなくworkload単位です。コードエージェントだけ3.5 Flashに移し、低価格抽出はFlash-Liteに残し、音声UIはLiveに残す、という分割が自然です。

## よくある質問

### Gemini 3.5 Flashは公式に公開されていますか？

はい。Google AI for Developersは`gemini-3.5-flash`をGA/stableモデルとして掲載しており、Gemini API changelogにも2026年5月19日の項目があります。ただし価格や対応機能は変わる可能性があるため、本番前には公式ページを再確認してください。

### API model IDは何ですか？

`gemini-3.5-flash`です。`gemini-3-flash-preview`や`gemini-3.5-flash-preview`に置き換えないでください。特定ルートの公式ドキュメントが別名を示す場合だけ例外です。

### 何に一番向いていますか？

エージェント型コーディング、長いtool workflow、マルチモーダル入力理解、structured outputs、file-heavy tasks、URL context、Google Search grounding、1,048,576 tokenの入力窓が効く作業です。

### 画像生成や音声生成に使えますか？

現時点ではその用途で選ぶべきではありません。モデルページの出力はtextであり、image generationやaudio generationの契約ではありません。

### Live APIやComputer Useは対応していますか？

現在確認したモデルページでは、Gemini 3.5 Flashの対応項目としてLive APIやComputer Useは示されていません。リアルタイム音声はLive API、UI制御はComputer Use対応モデルを選びます。

### Gemini 3 Flashより安いですか？

そうとは限りません。現在のStandard価格はinput `$1.50 / 1M`、output `$9.00 / 1M`です。古いFlash価格の感覚ではなく、最新の価格表と自分の入出力比率で計算してください。

### Gemini 3 Flashから移行すべきですか？

実タスクのside-by-sideテストで改善が出た場合だけ移行してください。3.5 Flashはエージェント、コード、長文脈で強い候補ですが、低価格処理、リアルタイム音声、画像出力の万能代替ではありません。

## 推奨判断

Gemini 3.5 Flashは、エージェント型コーディング、長いツールワークフロー、長文脈、多様な入力を扱う開発チームにとって有力な第一候補です。`gemini-3.5-flash`を公式model IDとして扱い、価格と対応機能は日付付きで確認します。

一方で、Live voice、image output、audio output、Computer Use、最安大量処理は別ルートを先に見ます。強いモデルを選ぶより、正しいruntime contractを選ぶほうが本番では重要です。導入するなら、同じ入力、同じツール、同じ予算、同じ評価基準で移行テストを行い、改善したworkloadだけを段階的に移してください。