デルタメモ

情報の自動取得

Geminiの無料枠が変わると報道されたら—アプリとAPIのどちらの話かを分けてから、定時収集への影響を判断する

Geminiの料金や上限の変更が報道されたとき、チャットアプリとAPI（AI Studio）とVertex AIでは別の仕組みです。AIの要約を定時バッチで回している側が、どの経路の話かを出典で分け、自分たちのキー・モデル・ティアを設定から確かめてから答えるための判断基準と、AIエージェントに渡す指示文。

AIの料金や無料枠の変更が報道されると、「うちに影響はあるか」をAIエージェントに調べさせたくなります。ところが同じ「Gemini」という名前でも、チャットアプリとAPIでは料金も上限も別の仕組みです。エージェントがAPIの料金ページだけを見て「影響なし」と答え、報道されている変更には触れなかったら、結論が合っていても信用できず、人が調べ直すことになります。読み終わると、料金や上限の変更を聞かれたときの判断基準がそろいます。どの経路の話かを出典で分け、自分たちが使っている経路を実際の設定で確かめてから答える、という順序です。あわせて、その調べ方をAIに渡す指示文も手元に残ります。

この記事でわかること

同じ製品名の下で料金の経路が分かれているときの見分け方と、自分たちの経路を設定から確かめるやり方を、2026年10月に実際に答え損ねた例をもとに、失敗ごとに合格条件つきで示します。料金の数字はすぐに古くなるので、主役にはしません。

前提

2026年10月時点の例です。GitHub Actionsの定時収集バッチで、セキュリティ情報の短い要約をGemini APIの無料枠（Google AI Studioで発行したキー）に任せている環境で起きました。料金と上限はGoogleの公式ページを優先してください。

失敗1 料金ページを1つ見ただけで「影響なし」と答える

2026年10月4日、「Geminiの料金変更は僕たちに影響する？」と聞かれたエージェントは、Gemini APIの料金ページだけを確かめました。Gemini 3.6 Flashなどの有料枠の単価が2027年1月1日から倍になり、無料枠は「Free of charge」のまま。そこで「定時収集の要約は無料枠なので影響なし」と答えました。

返ってきたのは「無料枠も5時間ごとになんとかって報道されてるよ、ちゃんと調べて」という一言です。報道されていたのは、Geminiアプリ（チャット）の上限の変更でした。調べ直しても結論は変わりませんでしたが、聞かれた変更に触れていない回答は、合っていても確かめ直しが要ります。

悪い例は、自分が見つけた変更を調べて、それで質問に答えたことにすることです。良い例では、質問の元になった報道や告知を先に特定し、その変更そのものが自分たちに影響するか、しないかを答えます。調べる途中で見つけた別の変更は、そのあとに分けて書きます。

合格条件は、回答の冒頭に、聞かれた変更が何で、それが自分たちに影響するかどうかが書いてあることです。

失敗2 アプリとAPIの話を分けずに判断する

同じ「Gemini」でも、料金と上限の決まり方は経路ごとに違います。2026年10月時点の整理です。

経路使う人上限と料金の決まり方公式の案内
Geminiアプリ（Webとスマホのチャット）個人がチャットで使うGoogle AIのプラン（なし・AI Plus・AI Pro・AI Ultra）ごと。5月17日から計算量で数える上限になり、5時間ごとに戻り、週の上限もある。10月9日から順に、プランなしで選べるのはFlash-LiteだけになるGemini Apps Help（support.google.com）
Gemini API（Google AI Studioのキー）プログラムから呼ぶプロジェクトごとの無料枠と有料ティア。有料はトークン単価Google AI for Developers（ai.google.dev）
Vertex AIGoogle Cloudの中で使うGoogle Cloudの課金Google Cloudのドキュメント

10月に報道された「5時間ごと」「週の上限」「無料はFlash-Liteだけ」は、どれもアプリの話です。APIの変更履歴には、無料枠の回数や5時間ごとの上限に当たる変更はありませんでした。同じ形は、ClaudeのアプリとAnthropicのAPI、ChatGPTとOpenAIのAPI、エディタのAIプランと自分のAPIキーを持ち込む使い方にもあります。

悪い例は、「Geminiの無料枠」という言葉だけで、アプリの変更をAPIに、またはAPIの変更をアプリに当てはめることです。良い例では、変更の出典ページがどこにあるかで経路を特定します。報道も、どのヘルプページが更新されたかを書いていることが多く、今回はGemini Apps Helpでした。

合格条件は、回答に、変更がどの経路の話かと、その根拠になる公式ページが書いてあることです。

失敗3 自分たちの経路をコードの既定値だけで決める

経路を分けたら、次は自分たちがどれを、どの条件で使っているかです。要約バッチのコードには既定のモデル名として gemini-3.6-flash が書いてありましたが、CIの変数で上書きできる作りでした。

悪い例は、コードの既定値を読んで「3.6 Flashの無料枠を使っている」と決めることです。実際にはCIの変数で別のモデルを指定していたり、キーが有料ティアのプロジェクトのものだったりすることがあります。

良い例では、次の3点を設定とログで確かめます。

今回は、GitHub ActionsのVariablesに GEMINI_MODEL が無いことを gh variable list で見て、既定の gemini-3.6-flash が使われていると確かめました。ティアは、過去に回数の上限で返ってきたエラー（HTTPの429）に GenerateRequestsPerDayPerProjectPerModel-FreeTier という無料枠の上限名が出ていたことから、無料ティアだと判断しました。ティアはAI StudioのProjectsページにも出るので、ログインできる人が画面で見れば確定できます。

合格条件は、キーの発行元、実行時のモデル名、ティアの3点が、どこを見て確かめたかと一緒に書いてあることです。

失敗4 確かめていないのに「変わっていない」と言い切る

APIの無料枠の回数は、ドキュメントに一律の数字が無く、プロジェクトごとにAI Studioの画面に出ます。画面を見るにはGoogleアカウントへのログインが要ります。この環境では、Googleへのログインはエージェントにさせず、人が普段使いのブラウザで行う決まりにしています。エディタ内蔵のブラウザからのGoogleログインは、アカウントの保護に引っかかりやすいからです。

悪い例は、画面を見ていないのに、変更履歴に記載が無いことだけを根拠に「無料枠の回数は変わっていない」と言い切ることです。良い例では、確かめた範囲と確かめていない範囲を分けて書きます。今回なら、確かめたのは「変更履歴に無料枠の変更が無い」「料金ページの無料枠はFree of charge」の2点で、確かめていないのは自分たちのプロジェクトに出ている上限値です。そのうえで、残りを誰がどの画面で見るかを添えます。

合格条件は、回答に、確かめていない項目と、それを確かめる人と画面が書いてあることです。

失敗5 料金の行だけ読み、同じ変更履歴のほかの項目を見落とす

料金を調べるために変更履歴を開いても、料金の行だけを読んで閉じてしまうことがあります。今回は同じ変更履歴に、temperature などのサンプリングのパラメータが非推奨になったという項目がありました。要約バッチは temperature を渡していたので、料金とは関係なくても自分たちのコードに当たる変更でした。この項目はその日のうちにコードから外しました。その後、10月8日の変更履歴には、gemini-3.7-flash を gemini-3.8-flash に、gemini-3.5-flash を gemini-3.6-flash に自動で振り向けるという項目も加わっています。使っているモデル名が分かっていれば、どちらも自分に当たるかをすぐに判断できます。

良い例では、変更履歴を前回確かめた日から今日までまとめて読み、自分たちのモデル名・パラメータ・機能に当たる項目を拾います。

合格条件は、回答に、料金以外で自分たちに当たる変更があるかどうかが、読んだ変更履歴の期間と一緒に書いてあることです。

作業前にAIへ渡す入力

人間向けの長い手順は書きません。次はすべて、作業前にAIに読ませる文と貼る文です。

AI向けの永続ルール（rulesやAGENTS.mdに書く）

AIサービスの料金・無料枠・上限の変更が自分たちに影響するかを聞かれたら、次の順で調べて答える。
- 最初に、質問の元になった報道や告知を特定する。回答の冒頭で、その変更そのものが自分たちに影響するか、しないかを答える。自分で見つけた別の変更だけで結論を出さない。
- 同じ製品名でも、チャットアプリ、API、クラウド経由で料金と上限は別の仕組みになっている（例: Geminiアプリ／Gemini API（AI Studio）／Vertex AI、ClaudeのアプリとAnthropic API、ChatGPTとOpenAI API）。変更がどの経路の話かを、出典の公式ページ（利用者向けヘルプか開発者向けドキュメントか）で特定し、URLを添える。
- 自分たちの経路は、コードの既定値ではなく実際の設定とログで確かめる。キーの発行元、実行時に使われるモデル名（CIの変数や環境変数での上書きを含む）、ティア（無料か有料か）の3点を、見た場所と一緒に書く。
- 公式の変更履歴と料金ページの両方を見る。変更履歴は前回確かめた日から今日までをまとめて読み、料金以外でも自分たちのモデル名・パラメータ・機能に当たる項目（非推奨、別モデルへの自動の振り向け、提供終了）を拾う。
- 確かめていないことを「変わっていない」と言い切らない。確かめた範囲と確かめていない範囲を分け、残りは誰がどの画面で見るかを書く。ログインが必要な管理画面は、人に見てもらう。

AI向けの開始時に貼る文

（報道や告知の見出しとURL）の変更が、こちらに影響するかを調べて。
こちらの使い方は（例: GitHub Actionsの定時バッチから、AI StudioのキーでGemini APIを呼んで要約している）。
最初に、この変更がアプリ・API・クラウドのどの経路の話かを公式ページで特定せよ。次に、こちらのキーの発行元・実際に使われるモデル名・ティアを設定とログから確かめ、表で示せ。
そのうえで、この変更がこちらに影響するか、しないかを先に答え、料金以外で見つけた変更と、確かめられなかった項目（誰がどの画面で見るか）を分けて書け。

人間向け

なし。上をAIに渡すだけでよい。

参考リンク