Google GenAI SDK のストリーミングでマルチターン画像編集🍌が不安定になる問題と対処法

Google GenAI SDK のストリーミングでマルチターン画像編集🍌が不安定になる問題と対処法

こんにちは!

Gemini 3 Pro Image (Nano banana Pro)を使ったマルチターン画像編集機能を実装していたところ、動いたり動かなかったりするという厄介な問題に遭遇しました。

本記事では、この問題の現象、原因調査の過程、そして解決策を共有します。


問題の現象

実行環境

Google GenAI SDKライブラリ(pip): google-genai 1.56.0

期待する動作

  1. ユーザー: 「かわいい子猫の画像を生成して」
  2. Gemini: 子猫の画像を生成
  3. ユーザー: 「この子にメガネをかけて」
  4. Gemini: 同じ子猫にメガネをかけた画像を生成

実際に起きた現象

  1. ユーザー: 「かわいい子猫の画像を生成して」
  2. Gemini: 茶色の子猫の画像を生成
  3. ユーザー: 「この子にメガネをかけて」
  4. Gemini: メガネをかけた女の子の画像を生成
あれれ、メガネをかけた子猫になるはずが、メガネをかけた女の子の画像が生成されてしまった

つまり、前回生成した画像を「覚えていない」状態になっていました。

厄介だったのは「再現性のなさ」

この問題が特に厄介だったのは、動いたり動かなかったりするという点でした。

  • 同じコードなのに、タイミングによって成功したり失敗したり、と挙動が変わる
  • サーバー再起動したら、タイミングからは長時間動作しなくなる
  • 開発環境では動いたが、ステージングでは動かない

同一コードで急に動かなくなると、「いったん再起動しよう」などとりあえずやってしまうと、環境の固定が崩れてしまい、問題の切り分け難しくなり「さっきまで動いてたのに...」という状況が発生し、原因特定に時間がかかりました。


原因調査

thought_signature の仕組み

Gemini 3 Pro Image のマルチターン画像編集は、thought_signature という仕組みに依存しています。

  • 画像生成時に、モデルは thought_signature を返す
  • これは生成した画像の情報(構図、色、内容など)を保持する約2MBのデータ
  • 次のターンでこれを渡すことで、前回の画像を「覚えている」状態になる

Google の公式ドキュメントによると

If you use the official Google Gen AI SDKs and use the chat feature, thought signatures are handled automatically.

ということで、つまり、SDK のチャット機能を使えば自動管理されるはず...でした。
この thought_signature という仕組みをつかえば、テキストチャットで行う毎回それまでのすべての履歴を送信する、ということを避けることができます。

SDK のチャットセッション

私たちのアプローチでは Google GenAI SDK の client.aio.chats.create() でチャットセッションを作成し、chat.send_message_stream() でメッセージを送信していました。

# チャットセッション作成
chat = client.aio.chats.create(model="gemini-3-pro-preview", config=config)

# メッセージ送信(ストリーミング)
response_stream = await chat.send_message_stream(content_parts)
async for response in response_stream:
    # レスポンス処理
    ...

ドキュメント通りなら、これで thought_signature は自動管理されるはず。しかし実際には動作しませんでした。

GitHub Issue #1791 の発見

調査を進める中で、GitHub で関連する issue を発見しました。

[Bug] ChatSession history fragmentation when using send_message_stream with Thinking (Gemini 3 Pro)
https://github.com/googleapis/python-genai/issues/1791

当該issue

この issue によると

When using Gemini 3 Pro Preview with thinking_config enabled, the ChatSession history becomes fragmented when using send_message_stream. Instead of appending a single model turn with the complete response, the SDK appends multiple model turns corresponding to the streaming chunks.

つまり、send_message_stream() を使うと、チャット履歴が断片化されてしまうというバグが報告されていました。

期待値

[User, Model]  # 2エントリ

実際

[User, Model, Model, Model, Model, ...]  # 複数のModelエントリ

ストリーミングのチャンクごとに履歴エントリが追加されてしまい、会話構造が壊れるとのこと。

「動いたり動かなかったり」の理由

この issue を読んで、「動いたり動かなかったり」の理由が推測できました。

  1. 同じサーバーインスタンス内で連続してリクエストすると、セッションがメモリ上に残っているため動くことがある
  2. サーバー再起動や新しいセッションでは、壊れた履歴から再開しようとして動かない
  3. タイミングやネットワーク状況によって、履歴の断片化の程度が変わる

これが再現性のない挙動の原因でした。


解決策

非ストリーミング版を使う

issue #1791 を参考に、send_message_stream() の代わりに send_message() を使うことにしました。

# 修正前(ストリーミング)
response_stream = await chat.send_message_stream(content_parts)
async for response in response_stream:
    # 処理
    ...

# 修正後(非ストリーミング)
response = await chat.send_message(content_parts)
# 処理
...

結果

非ストリーミング版に変更したところ、マルチターン画像編集が安定して動作するようになりました。

  • 子猫を生成 → 同じ子猫にメガネを追加
今度は、ちゃんと、元の子猫にメガネが装着されました
  • 何度試しても同じように​
  • サーバー再起動後も動作

まとめ

問題

Google GenAI SDK の send_message_stream() を使うと、チャット履歴が断片化され、thought_signature が正しく管理されない。

影響

Gemini 3 Pro Image のマルチターン画像編集が不安定になる(動いたり動かなかったりする)。

解決策

send_message_stream() の代わりに send_message() を使う。

副作用

  • リアルタイムのストリーミング表示ができなくなる(文章+SVG出力などでの逐次表示に影響)
  • 画像生成完了まで結果が返ってこない
  • ただし、進捗表示(「処理中です...」など)のサブメッセージを別途実装すれば UX への影響は最小限で済む

今後

  • SDK のバグ修正を待つ
  • issue #1791 の進捗を監視
  • 修正されたらストリーミング版に戻すことを検討

参考リンク


最後に

同一コードで「動いたり動かなかったりする」バグは、原因特定が非常に難しいですね。今回のケースでは、SDK の内部動作を疑うまでに時間がかかりました。

同じ問題で困っている方の参考になれば幸いです。

それでは、次回またお会いしましょう!

Read more

ゼロから作るコーディングエージェント【第2回】完了は「作った」ではなく「動いた」で決める。完了の門と、押し戻しに書くこと

ゼロから作るコーディングエージェント【第2回】完了は「作った」ではなく「動いた」で決める。完了の門と、押し戻しに書くこと

モデルの「完了しました」は5つの形ですり抜けました。構文検査だけ、テストは通るが動かない、待ち受けは立つが最初の要求で落ちる、起動するが仕様のAPIが無い、assertの無いテスト。完了の門を3段で閉じる設計と、押し戻しに「落ちた行と調べ方」を書いて「答え」を書かない理由を、数字つきで書きます。

By Qualiteg プロダクト開発部
「Blackwell」は 1 つではなかった。NVIDIA の Compute Capability 番号のわかりにくさを整理する

「Blackwell」は 1 つではなかった。NVIDIA の Compute Capability 番号のわかりにくさを整理する

こんにちは! NVIDIA の GPU を扱っていると、sm_120 や sm_100 といった番号を見かけます。Compute Capability と呼ばれる番号です。 この番号、製品の世代名と対応しているように見えて、実はずれています。 きっかけは、2026年9月23日に公開された TensorRT-LLM の v1.3.0rc28 でした。リリースノートに「SM107」という記述があります。次世代の Rubin に対応した、という文脈です。 ここで引っかかります。Blackwell の GeForce は sm_120 です。次の世代の Rubin が、なぜ 107 という小さい番号なのでしょうか。 調べてみると、引っかかりの原因は Rubin ではありませんでした。

By Qualiteg プロダクト開発部