Gemini 3.6 Flash値下げで見積もりが陳腐化する：AI開発のAPI原価を疑う見積もりセカンドオピニオン（2026-07-23）

結論：AI開発の見積もりに書かれた「API原価」は、印刷した瞬間から古くなり始めている

2026年7月21日、GoogleはGemini 3.6 Flashと3.5 Flash-Lite、そしてセキュリティ特化のGemini 3.5 Flash Cyberを発表し、あわせて次世代フラッグシップであるGemini 4の事前学習（pre-training）を開始したことを明らかにしました（Google公式ブログ）。注目すべきは価格です。主力の3.6 Flashは入力100万トークンあたり$1.50、出力$7.50で、Googleは3.5 Flash比で出力トークン消費を17%削減したと説明しています（一部ベンチマークでは最大65%）。3.5 Flash-Liteは入力$0.30・出力$2.50という低価格帯です。

ここで経営者が押さえるべき一点は、価格そのものより「二重効果」です。同じ処理を行っても、単価が下がり、かつ消費トークン数まで減る。つまり請求書に載る実効コストは、表に見える単価の下げ幅以上に低下します。これは同時に、いま手元にあるAI開発の見積書、あるいはこれから受け取る見積書の「API利用料はこのくらい」という前提が、数週間から数か月のスパンで陳腐化することを意味します。

本稿の主張は単純です。AI開発を発注する側は、見積もりの合計金額を値切る前に、その見積もりが「どのモデルの、いつ時点の単価」を原価前提にしているのかを開示させ、モデルを差し替えられる契約になっているかを確認すべきです。原価が動く前提で組まれていない見積もりは、安く見えても後で高くつくか、逆に払い過ぎになります。この記事は、情シスが0〜1名の中堅企業の経営者・事業責任者が、AI開発ベンダーの見積もりを「第二の目」で読むための判断フレームを提供します。

まず要点：今回の発表を1枚で

注記：旧3.5 Flashの出力単価$9やキャッシュ入力$0.15は、9to5googleやその他技術系メディアの報道に基づく数値で、今回のGoogle公式発表記事の本文では確認できませんでした。値下げ「率」を語る際の根拠として引用する場合は、発注前にGeminiの公式価格ページ（ai.google.dev / Google Cloud のpricing）で最新の実額を必ず確認してください。単価は予告なく改定されます。

なぜ「値下げ」が発注側の経営リスクになるのか

普通に読めば、API単価が下がるのは発注側にとって朗報です。ランニングコストが下がるからです。ところが、AI開発を「一括請負」や「準委任＋固定モデル指定」で発注していると、この朗報が素通りして、値下げの恩恵がベンダー側に留まる構造が生まれます。ここが今回のトレンドの本質です。

具体的に3つの経路で経営リスク化します。

第一に、原価前提の陳腐化です。多くのAI開発見積もりは、提案時点で「このモデルを月◯万トークン使うから、API利用料は月◯円」と積算します。ところが提案から契約、開発、本番稼働まで数か月かかる間に、モデルの世代が上がり、単価もトークン効率も変わります。今回のように「単価↓×消費量↓」が同時に起きると、提案時の原価は実勢から大きく乖離します。見積もりに載っていた原価で請求され続ければ、発注側は下がったはずのコストを払い続けることになります。

第二に、モデル固定契約の硬直です。「Gemini 3.5 Flashを使用」と仕様書に書き込んでしまうと、3.6 Flashへ差し替えるだけで安く・速くなる状況でも、仕様変更＝追加費用の交渉事になりがちです。本来は数行の設定変更で済むモデル切り替えが、契約上の「変更管理」に化けて、追加見積もりの口実になる。これは技術の問題ではなく契約設計の問題です。

第三に、原価の不透明化です。見積書に「AI利用料一式 ◯円」とだけ書かれ、内訳（どのモデル・入力/出力トークン単価・想定コール数・キャッシュ利用の有無）が示されないと、値下げが起きても発注側は気づけません。原価が動く商材なのに、原価が固定費のように丸められている見積もりは、値下げ局面で発注側が損をしやすい構造です。

言い換えると、AIのAPIコストは「動く原価」です。動く原価を、動かない前提で契約に固めた瞬間、値下げは発注側の利益ではなくベンダーの粗利に変わります。これは悪意の有無とは無関係に、契約設計の初期設定でそうなってしまう、という点が経営者にとって怖いところです。

さらに厄介なのは、この陳腐化が「見えにくい」ことです。従来のシステム開発なら、サーバー費用やライセンス費用は年単位でしか動かず、見積もりの前提が数週間で崩れることは稀でした。ところがAIのモデルは、今回のように四半期どころか数週間の単位で世代交代と値下げが起こります。発注側が従来のシステム開発と同じ感覚で「一度合意した原価は据え置き」と考えていると、その据え置きが年単位で続いた結果、市場実勢より高い原価を払い続けることになる。値下げは静かに起きるので、契約に還元の仕組みがなければ、損をしていること自体に気づけません。今回のGemini 3.6 Flashの発表は、その「静かな陳腐化」が現実に起きていることを可視化した好例だと捉えるべきです。ニュースとして消費するのではなく、自社の契約書を開いて「うちはこの値下げの恩恵を受けられる契約になっているか」と問い直す——それが、この発表を経営に活かす唯一の方法です。

誰が読むべきか

• これからAIエージェントや生成AI機能を外注で開発しようとしている経営者・事業責任者
• すでにAI開発の見積書を受け取り、金額の妥当性を判断しかねている決裁者
• 情シスが0〜1名で、API単価やトークンの仕組みを社内で検証する人手がない中堅企業
• PoCは動いたが、本番運用のランニングコストが読めず本番化を止めている担当者
• 「AI利用料一式」で丸められた保守見積もりに、なんとなく違和感を持っている財務・管理部門

逆に、社内に生成AIの原価計算とベンダー交渉を両方こなせる人材がいる企業は、本稿のチェック項目を確認プロセスに組み込むだけで十分です。多くの中堅企業はそこが手薄で、だからこそベンダーの言い値が通りやすい、というのが実態です。

主要モデルの価格を並べて見る（発注前の相対感づくり）

見積もりを読む前に、まず「いま市場でどのくらいの単価帯があるのか」の相対感を持っておくと、原価前提の妥当性を判断しやすくなります。以下は今回発表分の実額と、比較のための位置づけです。

この表から発注側が読み取るべきは、個別の$ではありません。読み取るべきは次の構造です。

• 同じ「Flash系」でも、世代とグレードで単価が数倍違う。3.5 Flash-Liteと3.6 Flashでは出力単価が3倍差です。用途に対して過剰なグレードを指定すると、原価は簡単に膨らみます。
• 出力トークンは入力の数倍高い。3.6 Flashは入力$1.50に対し出力$7.50で5倍です。だからこそ「出力トークンを17%減らせる」という改善が、単価の値下げと同じかそれ以上に効きます。要件定義で「AIに長々と生成させる設計」を選ぶと、ここが直撃します。
• キャッシュ活用の有無で原価が桁で変わりうる。同じシステムプロンプトや同じ社内文書を何千回も送り直すエージェント処理では、入力キャッシュ割引が効くかどうかで実効原価が大きく動きます。見積もりがキャッシュ前提かどうかは必ず確認事項です。

なお、他社モデル（Claude系・GPT系など）との横断比較を含めた生成AI活用のモデル選定・要件整理では、用途別に「最安ではなく、要件を満たす最小グレード」を選ぶ姿勢が要点になります。最新の実額は各社公式価格ページで都度確認してください。ここで示した数値は2026年7月時点のスナップショットに過ぎません。

見積もりに何を「書かせる」べきか：原価が動く前提の発注設計

AI開発の見積もりは、従来のシステム開発の見積もりと同じ様式で書かれがちです。しかしAPIコストが動く原価である以上、いくつかの条項を明示的に書かせておかないと、値下げ局面でも改定局面でも発注側が不利になります。以下は、見積書・契約書に盛り込むべき最低ラインです。

1. 原価内訳の明示

「AI利用料一式」を禁止し、次を分解して書かせます。使用モデル名と世代、入力/出力の単価、想定月間コール数、1コールあたりの想定入力/出力トークン、キャッシュ利用の有無と割引前提、想定月額レンジ（下限〜上限）。これが書けないベンダーは、原価を自分でも把握していないか、丸めて粗利を隠しているかのどちらかです。

2. モデル差し替え可能条項

「上位・下位・新世代モデルへ、追加費用なしで切り替えられる」ことを明記させます。切り替えが軽微な設定変更で済む設計（モデルを抽象化したレイヤーを持つ、プロンプトをモデル非依存で管理する等）になっているかを問います。特定モデルを仕様書に固定書きした瞬間、値下げの恩恵は交渉ごとになります。

3. 原価連動の見直し条項

API単価が改定された場合に、ランニングコスト（保守・運用費のうちAPI実費分）を実額に連動させる条項を入れます。値下げ時は下げ、値上げ時は上げる、双方向の連動が公平です。ベンダーが「実費＋管理費」で請求する形なら、値下げは自動的に発注側に還元されます。

4. トークン設計の説明責任

出力トークンが最も高いのですから、「なぜこの生成量が必要か」「短く返す設計にできないか」の説明を求めます。出力を冗長にする設計は、そのまま毎月の請求に乗り続けます。要件定義の段階で「返答は要点のみ・整形は自社側」といった設計判断を入れられるかが、ランニングコストを左右します。

5. 実測ログの開示

本番稼働後、実際の月間トークン消費とモデル別コストのログを、発注側が閲覧できるようにします。原価が動く商材で、実測が見えないのは危険です。ログが出せる設計かどうかは、そのまま運用の透明性を表します。

発注前チェックリスト（このネタ専用）

見積書を手にした段階で、以下をベンダーに確認してください。全項目に明確な回答が返るかどうかが、ベンダーの実力とフェアさの試金石になります。

• 見積もりのAPI原価は「いつ時点・どのモデルの単価」で積算しているか、日付とモデル名を明記しているか
• 入力/出力トークンの単価と、想定コール数・想定トークン量を内訳で示しているか
• 出力トークンが高い前提で、生成量を抑える設計になっているか（無駄に長い出力をさせていないか）
• 入力キャッシュ割引を使える処理で、それを前提に見積もっているか
• 新世代・下位グレードのモデルへ、追加費用なしで差し替えられる契約になっているか
• API単価改定時に、ランニングコストを実額連動で見直す条項があるか
• 本番稼働後、モデル別・トークン別の実測コストログを発注側が確認できるか
• 要件に対して過剰なグレード（高い方のモデル）を初期指定していないか、下位モデルで足りる処理を切り分けているか
• PoCの単価前提と本番の単価前提がずれていないか（PoCは無料枠、本番は従量、という落とし穴の確認）

ベンダーへの質問テンプレート

そのまま使える質問文です。回答の歯切れの良さが、原価管理の成熟度を映します。

1. 「この見積もりのAI利用料は、どのモデルの、いつ時点の単価で計算していますか。モデル名と単価を教えてください。」
2. 「Gemini 3.6 Flashのように単価とトークン効率が同時に改善した場合、私たちの月額はどう変わりますか。自動的に下がりますか、それとも変更手続きが必要ですか。」
3. 「使用モデルを新世代や下位グレードに差し替える場合、追加費用は発生しますか。発生するなら、その根拠は何ですか。」
4. 「出力トークンが最も高い前提で、生成量を抑える設計にしていますか。どこで抑えていますか。」
5. 「本番稼働後、実際のトークン消費とモデル別コストを私たちが確認できるログはありますか。」
6. 「PoCで使った単価前提と、本番運用の単価前提は同じですか。違うなら、本番での月額レンジを示してください。」

これらに「確認して折り返します」ばかりが返るなら、原価を握っていないベンダーです。逆に、即座に内訳とモデル差し替えの考え方を語れるベンダーは、動く原価を前提に設計できている可能性が高い。質問への回答速度と具体性そのものが、見積もりの信頼度です。

よくある失敗パターン

• 提案時の単価を「固定費」だと思い込む：AIのAPIコストは動く原価。提案書の月額をそのまま3年分の固定費として稟議に載せると、値下げ局面で払い過ぎ、値上げ局面で不足します。レンジと連動条項で持つのが正解です。
• 仕様書にモデル名を固定書きする：「Gemini 3.5 Flash使用」と書いた瞬間、上位・新世代への切り替えが変更管理＝追加費用に化けます。モデルは抽象化し、差し替え可能条項で縛るべきです。
• 最上位モデルを一律指定する：全処理に高いモデルを充てると原価は跳ね上がります。分類・要約・軽い応答は下位グレード、複雑な推論だけ上位、と処理ごとに割り当てるのが原価設計の基本です。
• 出力を冗長にする設計を放置する：出力トークンが一番高いのに、AIに長文を吐かせ続ける設計は毎月の請求に乗り続けます。「短く返す・整形は自社」で大きく変わります。
• PoCの安さで本番を判断する：無料枠や少量コールで動いたPoCの単価は、本番の従量課金とは別物です。本番のコール数・トークン量で積み直さないと、稼働後に原価が跳ねます。
• 値下げニュースを一喜一憂で終わらせる：今回のような発表を「へえ安くなった」で流すと、自社の契約に還元される仕組みがないまま終わります。ニュースは契約の見直しトリガーとして使うべきです。

「動く原価」を前提にした発注設計の実務：3つの視点

ここまでの話を、発注実務に落とし込みます。抽象論で終わらせないために、経営判断として押さえるべき視点を3つに整理します。

視点1：契約形態そのものが原価還元を左右する

同じAI開発でも、契約形態によって値下げの恩恵が誰に落ちるかが変わります。API実費を「原価＋管理費」として発注側に透明に請求する形（実費精算型）であれば、単価が下がった分はそのまま発注側に還元されます。一方、開発から運用までを月額固定の一括請負に丸めてしまうと、内部の原価が下がってもベンダーの粗利が増えるだけで、発注側の支払いは変わりません。どちらが良い・悪いという単純な話ではなく、**「原価が動く部分（API実費）を固定費に混ぜ込まない」**という設計思想が要点です。開発の工数は固定でよい。しかしトークン従量で動くAPI実費は、固定に溶かさず、実額が見える形で切り出しておく。この一手だけで、値下げ局面での取りこぼしはかなり防げます。

視点2：処理をグレードで分けると原価は大きく変わる

AI機能を「全部いちばん賢いモデルで動かす」設計は、作るのは簡単ですが原価は最も高くなります。現実の業務処理は、難易度がバラバラです。問い合わせの分類、定型的な要約、フォーマット整形といった軽い処理は、3.5 Flash-Liteのような低コスト帯で十分こなせることが多い。一方で、複数の情報を突き合わせて判断する複雑な推論だけを、上位グレードに回す。この「処理の難易度に応じてモデルを振り分ける」設計（ルーティング）ができているかどうかで、月額の原価は数倍変わりえます。発注側は技術の中身を作れなくても、「うちの処理は全部同じモデルで動かしていませんか。軽い処理は安いモデルに振り分けられませんか」と問うことはできます。この一問が、毎月の請求を左右します。今回3.5 Flash-Liteという低コスト帯が同時に出たことは、まさにこの振り分け設計の選択肢が広がったことを意味します。

視点3：情シスが手薄でもできる最小限の原価モニタリング

人手をかけずに原価を守るには、契約に「見える化」を織り込むのが最も現実的です。具体的には、月次で「使用モデル別のトークン消費量」「モデル別のコスト」「前月比の増減」の3点だけをレポートさせる。これはベンダー側の管理画面から出せる範囲であることが多く、発注側に専門人材がいなくても読めます。数字が読めれば、「先月から急に高い処理が増えていないか」「安いモデルに移せる処理が放置されていないか」を、月に一度眺めるだけで異常に気づけます。原価が動く商材で最も危険なのは、動いていること自体に気づけない状態です。完璧なFinOps体制を組む必要はありません。月1枚のレポートを契約に義務づける——これが、情シス0〜1名の企業にとって最もコスト対効果の高い守りです。

GXOに相談すべきタイミング

次のいずれかに当てはまるなら、発注や契約更新の前に第三者の目を入れる価値があります。

• AI開発の見積書を受け取ったが、「AI利用料一式」で内訳が見えず、金額の妥当性を判断できない
• 「どのモデルを使うか」「モデル差し替えを契約でどう縛るか」を社内で判断できる人材がいない
• PoCは動いたが、本番のランニングコストが読めず本番化に踏み切れない
• すでに契約したAIシステムの月額が下がらず、値下げの恩恵を受けられていない気がする
• 複数ベンダーの見積もりを、原価前提の違いを含めて横並びで比較したい

GXOは特定ベンダーの製品を売る立場ではなく、発注側の視点で見積もりと要件を整理する立場です。まず動く原価を前提に発注設計を点検したいならAI導入の要件整理と適合性を見るAI導入診断から入るのが実務的です。既に手元に見積書があり、その原価前提とモデル固定リスクを第三者に見てほしい場合はAI開発・生成AI活用の相談窓口へ。AI単体でなく基幹・業務システムと絡む発注ならDX・システム開発の発注整理の観点も必要です。具体的な金額感の相談は見積もりセカンドオピニオンの相談・お問い合わせ、概算レンジを整理したい場合は概算見積もりの依頼から進められます。

FAQ

Q1. Gemini 3.6 Flashの正確な料金はいくらですか。 A. 2026年7月21日のGoogle公式発表時点で、入力$1.50・出力$7.50（いずれも100万トークンあたり）です。3.5 Flash-Liteは入力$0.30・出力$2.50。ただし単価は改定されうるため、発注に使う際は必ずGeminiの公式価格ページで最新の実額を確認してください。

Q2. 「出力トークン17%減」は本当に効きますか。 A. 出力トークンは入力の数倍高い（3.6 Flashで5倍）ため、生成量の削減はコストに直結します。Googleは3.5 Flash比で出力トークン17%減、一部ベンチマーク（DeepSWE等）では最大65%減と説明しています。ただし削減率はタスク依存で、自社処理での効果は実測が前提です。

Q3. 旧3.5 Flashの単価が$9だったという話は確かですか。 A. 旧3.5 Flashの出力単価$9やキャッシュ入力$0.15は技術系メディアの報道に基づく数値で、今回のGoogle公式発表記事の本文には記載がありませんでした。値下げ幅の根拠として使う場合は二次情報である旨を前提に、公式価格ページで裏取りしてください。

Q4. うちの見積もりはもう古い、ということですか。 A. 金額が間違っている、という意味ではありません。API原価が動く前提で契約が組まれていないと、値下げの恩恵が発注側に還元されない、という意味です。差し替え条項と実額連動条項があれば、原価が動いても不利になりにくくなります。

Q5. モデルを固定しないと品質が不安定になりませんか。 A. モデルを差し替え「可能」にすることと、無検証で自動切替することは別です。差し替え時に評価（回帰テスト）を通す運用を契約に含めれば、品質を担保しつつ新世代の安さ・速さを取り込めます。固定は硬直、無検証切替は危険、その中間が正解です。

Q6. 中堅企業がここまで契約に踏み込むのは過剰ではないですか。 A. むしろ情シスが手薄な企業ほど、契約で守るしかありません。社内で単価やトークンを日々チェックできないなら、内訳開示・差し替え可能・実額連動・ログ開示の4点を契約に入れておくことが、人手をかけずに原価を守る最も現実的な方法です。

Q7. Gemini 4が出たらまた見直しですか。 A. Gemini 4は事前学習開始が公表された段階で、リリース日は未公表です。だからこそ「新世代が出ても差し替えられる」契約にしておくことが重要です。世代交代のたびに契約交渉をやり直すのではなく、最初から原価が動く前提で組むのが、結局いちばん手間もコストも少なくなります。

参考文献

• Google公式ブログ「Introducing Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber」（一次・2026年7月21日）: https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-6-flash-3-5-flash-lite-3-5-flash-cyber/
• 9to5google「Google launches Gemini 3.6 Flash and 3.5 Flash-Lite, teases Gemini 4」（二次・媒体報道）: https://9to5google.com/2026/07/21/gemini-3-6-flash-launch/
• VentureBeat「Google's Gemini 3.6 Flash model cuts AI agent token costs by up to 65%」（二次・媒体報道）: https://venturebeat.com/technology/googles-gemini-3-6-flash-model-cuts-ai-agent-token-costs-by-up-to-65-on-long-horizon-engineering-tasks-and-3-5-pro-is-on-the-way
• Gemini API 価格ページ（実額の最終確認先・都度参照）: https://ai.google.dev/pricing

※本記事の価格・削減率は2026年7月時点の公表情報に基づくスナップショットです。単価は予告なく改定されるため、発注・契約判断の際は必ず公式価格ページで最新の実額をご確認ください。