エンジニアの皆さん、こんにちは。
最近、Claude Code と LiteLLM、そして Gemini 3 Flash-preview を組み合わせて費用対効果を上げている当ブログ。
しかし本日3月12日、「昨日まで動いていた簡単なコマンド（ls -Rなど）が急に失敗するようになった」という事象を確認しました。ログを解析したところ、Gemini側のアップデートに伴う APIレスポンスの構造変化 が原因であることが判明しました。
今回はその詳細と、現時点での解決策を共有します。
1. 発生している現象
Claude Code上からGemini 3 Flash-previewを呼び出し、ファイル一覧の取得やコミットなどのツール実行（Bashコマンド等）を行おうとすると、エラーが発生して処理が中断される。
2. 原因：thoughtSignature（思考プロセス）の混入
Geminiのログ（JSONレスポンス）を比較したところ、ツール呼び出し（Function Call）時の構造に変化がありました。
❌ 失敗時のログ（現在の挙動）
{
"functionCall": {
"name": "Bash",
"args": { "command": "ls -R", ... }
},
"thoughtSignature": "Eq0ECqoEAb4..." // ←ココが問題！
}functionCall と同じ階層に、「思考プロセス（thoughtSignature）」が同居してしまっています。
多くのツール（LiteLLMのパーサーなど）は、「ツール呼び出しのブロックには、ツール実行に必要なデータのみが含まれる」という厳格なスキーマを想定しています。そこに予期せぬ thoughtSignature というキーが入ってきたことで、解析エラー（Validation Error）を引き起こしているのが真相です。
✅ 正常時のログ（以前の挙動、またはテキスト回答時）
以前は、以下のように「テキスト回答」と「思考データ」が別々のパーツとして分離されていました。
"parts": [
{ "text": "commit this" },
{ "text": "", "thoughtSignature": "EjQKMg..." }
]このように分離されていれば、ツール側は不要なパーツを無視できるため、正常に動作していました。
3. 今すぐできる対策は？
いろいろ試しましたが、いまのところ解決策がなく。LiteLLM のアップデートを待つのが最善な気がしています。
まとめ
「昨日まで動いていたのに…」という時の原因の多くは、AIモデル側のレスポンス形式の微細な変化にあります。特に Gemini 3 Flash-preview のような最先端モデルは「動く標的」です。
複数社、複数モデルを使えるようにしておくのが、一番の予防策かもしれません
