> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apiyi.com/llms.txt
> Use this file to discover all available pages before exploring further.
# ツール呼び出しにおける Gemini Thought Signature 400 エラーを解決する方法
> Gemini 3 以降のモデルにおいて、「Function call is missing a thought_signature」は履歴の再送時にクライアントがシグネチャを欠落させたことを意味し、「Invalid / Corrupted thought signature」は現在のルートでシグネチャの検証に失敗したことを意味します。これらを見分け、それぞれを解決する方法を説明します。
## 簡潔な回答
Gemini 3 以降のモデル（gemini-4-argon、gemini-3.8-flash、gemini-3.1-pro-preview など）でマルチターンの Function Calling を実行する際、思考シグネチャ（`thoughtSignature`）に関連する400エラーには2種類あり、それぞれ異なる対処が必要です。
| エラーメッセージ | 意味 | 対処法 |
| - | - | - |
| `Function call is missing a thought_signature in functionCall parts` | **リクエストにシグネチャが含まれていません。** 履歴を再送信する際、前のターンの `functionCall` パートから `thoughtSignature` フィールドが欠落しました | クライアント側を修正してください：モデルの前回の返答を履歴に\*\*そのまま（一文字も変更せずに）\*\*戻し、パートを再構築しないでください |
| `Invalid thought signature` / `Corrupted thought signature` | **シグネチャは送信されましたが、現在のルートでの検証に失敗しました。** 通常、会話の途中でルート、モデル、キー、またはグループが切り替わったことが原因です | そのまま一度再送信してください。それでも失敗する場合は、履歴のターンから `thoughtSignature` を削除して再送信するか、新しい会話を開始してください |
OpenAI 互換の `/v1/chat/completions` エンドポイント経由で呼び出す場合、**これらは一切関係ありません**。ゲートウェイがシグネチャを管理するため、標準的な `tool_calls` / `tool` メッセージを用意するだけで十分です。
## 2つのエラーの見分け方
### 署名の欠落
```text theme={null}
400 Function call is missing a thought_signature in functionCall parts.
This is required for tools to work correctly, and missing thought_signature
may lead to degraded model performance. Additional data, function call
`default_api:Bash`, position 2.
```
このメッセージには、関数名と `parts` 配列内でのインデックスが示されています。これは Gemini 3 ファミリーに対してモデルプロバイダーが適用している厳格なルールです。**現在のターンにあるすべての `functionCall` パートには、その署名が付与されている必要があります。** 1つでも欠落しているとすべてのルートで 400 エラーとなり、再試行しても解決しません。
### 無効または破損した署名
```text theme={null}
400 Invalid thought signature.
400 Corrupted thought signature.
```
フィールドは存在しますが、検証に失敗しています。署名は暗号化された blob であり、**それを生成したルートのみが検証できます**。会話の途中でルート、モデル、キー、またはグループが切り替わった場合、以前の署名は受け入れられなくなる可能性があります。
## この問題が発生する理由
tools が有効化されている場合、Gemini 3 モデルは暗号化された `thoughtSignature` を各 `functionCall` と同じパートに付加し、そのステップにおける推論状態を記録します。モデルは次のリクエストで推論チェーンを継続するためにこれを必要とするため、プロバイダーは変更を加えずにそのまま送り返すことを求めています。
最も一般的な原因です。カスタムフレームワークやミドルウェアが履歴を組み立てる際に、`name` および `args` だけを `functionCall` から保持して兄弟の `thoughtSignature` を破棄してしまっているか、シグネチャをマージせずにストリーミングチャンクを再構成していることが考えられます。
クライアントがコンテキストをトリミングまたは要約したか、複数のパートを1つに統合したことで、シグネチャも一緒に失われました。
最初のターンはルートAで処理され、その後のターンがルートBに割り振られた場合、ルートBはルートAのシグネチャを認識できません。この切り替えは、グループやキーの変更、または自動フェイルオーバーによって発生することがあります。
同一の会話内で gemini-3.8-flash から開始し、gemini-4-argon に切り替えた場合などが該当します。シグネチャはモデル間で互換性がありません。
並列関数呼び出しの場合、モデルは**最初**の `functionCall` パートにのみシグネチャを付加します。それ以外には正当な理由でシグネチャが存在しないため、偽造しないでください。順次呼び出し（1ターン内に複数のステップがある場合）では、すべてのステップにシグネチャが含まれ、そのすべてを送り返す必要があります。
## 修正方法 1：署名の欠落、クライアントによる履歴の再送方法を変更する
公式の `google-genai` SDKを使用する場合は、単に `contents.append(response.candidates[0].content)` してください。`function_call` フィールドのみを抽出しないでください。手動でRESTを実装している場合、2回目のリクエストの `contents` 内のモデルターンは次のようになっている必要があります：
```json theme={null}
{
"role": "model",
"parts": [
{
"functionCall": { "name": "lookup_order", "args": { "order_id": "B5001" } },
"thoughtSignature": "AY89..."
}
]
}
```
`thoughtSignature` と `functionCall` は、2つのパーツではなく、**同じパーツ内の2つのフィールド**です。
LangChain、カスタムエージェントフレームワーク、またはOpenAIからGeminiへの変換レイヤーを使用している場合は、2回目のターンの実際のリクエストボディを出力し、`thoughtSignature` が残っていることを確認してください。エラー内の `position N` は `parts[N]` です。そこを直接確認してください。
モデルやルーティングによって、署名の欠落をどれだけ厳密にチェックするかは異なります。通過させるものもあれば、400を返すものもあります。同じコードがgemini-3.8-flashで常に動作していてgemini-4-argonで失敗する場合、署名は最初から送信されておらず、以前は単に許容されていただけである可能性が高いです。プロバイダーの要求どおりに署名を返却すれば、すべてのモデルで安定して動作します。
## 解決策2: 無効な署名、再送信するか最初からやり直す
APIYI ゲートウェイが署名に関する 400 エラーを受信すると、別のルートで自動的にリトライするため、そのまま再送信するだけで成功することがよくあります。変更は不要です。
履歴内のすべての `role: "model"` ターンの parts から `thoughtSignature` フィールドを削除して再送信します。該当ターンの推論コンテキストは失われ、回答品質がわずかに低下する可能性がありますが、会話を継続できます。削除するのは履歴のターンのみとし、現在のターンは絶対に削除しないでください。
最もシンプルで信頼性の高い選択肢です。新しい会話では、最初のターンからすべての署名が同一ルートから取得されます。
モデル、キー、またはグループを切り替える必要がある場合は、まず新しい会話を開始してください。すでにツール呼び出し履歴がある会話の途中で切り替えないでください。
## OpenAI互換エンドポイントでの署名処理は不要
`/v1/chat/completions` 経由で Gemini を呼び出す場合、`tool_calls` メッセージには signature フィールドがありません。ゲートウェイが変換中にそれを保存および復元します。gemini-4-argon でのテストでは、単一の呼び出し、2つの並列呼び出し、テキストと呼び出しの組み合わせという3つのパターンすべてで、2ターンの会話が成功しました。標準的な OpenAI の方法で `tool_calls` および `tool` メッセージを返却するだけです。
Gemini モデルはそのエンドポイントをまだサポートしていないため、デフォルトで `/v1/responses` を使用する Codex などのクライアントは、チャットプロトコルに切り替える必要があります。[Gemini 4 Argon テキスト生成](/ja/api-capabilities/gemini-4-argon/overview) を参照してください。
## よくある質問
いいえ。シグネチャの返却はGemini 3ファミリー全体に対するプロバイダーの要件であり、一部のモデルのルートでは単にシグネチャの欠落に対して寛容であるに過ぎません。厳格な検証を行うモデルに移行したことで問題が表面化しただけであり、根本的な原因は依然としてクライアントがシグネチャを送信していないことにあります。
いいえ。シグネチャは、それを生成したルートおよび会話コンテキスト内でのみ有効です。別の会話にコピーするとInvalidになります。
`functionCall`と同じパート内、つまりそれを保持するチャンクの内部にあります。streamを再構成する際は、履歴に戻す前に、このフィールドを`functionCall`と一緒に最終的なモデルの返答へとマージしてください。
厳密には必須ではありません。プロバイダーがシグネチャを厳格に検証するのは`functionCall`パートのみです。テキストターンでシグネチャが欠落していても400エラーにはなりませんが、シグネチャを維持することで推論の継続性が向上するため、いずれにせよ返答全体をそのまま送り返してください。
## 関連ドキュメント
シグネチャの返し方を含む、完全な2ターンの例
マルチターンのツール呼び出しに関する注意点とクライアントのセットアップ
Claude側における同種の問題
各プロバイダーが期待する履歴の返却方法
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.