messages 配列は、暗黙の順序ルールを持つ契約です。tool 応答はそれを宣言した assistant メッセージの直後に置く必要があり、宣言されたすべての tool_call_id は会話が進む前に応答されなければなりません。Anthropic ではさらに user と assistant の交互と、system の最上位パラメータへの移動が求められます。履歴の切り詰めや呼び出しの再試行などでコードが配列を動的に組み立てると、これらの不変条件は簡単に壊れますが、API のエラーはルールを引用するだけでどのメッセージが違反したかは教えてくれません。このツールは同じペアリング ロジックで配列を走査し、正確な位置を指し示します。
OpenAI Chat Completions と Anthropic Messages は基本設計が異なります。存在するロール、system 指示の置き場所、tool 呼び出しと結果のペアリング方法(最上位の tool_calls と tool メッセージ vs. tool_use と tool_result コンテンツ ブロック)。プロファイルを切り替えると同じ入力が即座に再判定されます。会話ログをプロバイダー間で移行するとき、診断リストがそのまま移行チェックリストになります。
解析と診断はすべてブラウザ内で完結します。貼り付けた内容がアップロードや記録されることはありません。会話ログには資格情報や顧客データ、内部プロンプトが含まれがちなので、意図的にサーバー側を持たず、入力に対する分析トラッキングも行いません。
このテーマに関するよくある疑問と回答をまとめました。
構造系の 400 エラーです。role が tool のメッセージは tool_calls を持つメッセージへの応答でなければならない、tool_calls を持つ assistant の後には tool メッセージが必要、未知または欠落した role、空の配列、不正な content 形式。Anthropic 側では user と assistant の交互の崩れ、system の位置ミス、tool_use と tool_result の id 不一致。モデル名の誤りやコンテキスト長超過、function 引数の形式エラーといった意味系の問題は別種の失敗であり、対象外です。
型はコンパイル時に形状エラーを捕まえますが、多くの 400 を生むのはメッセージをまたぐ順序ルールです。この tool_call_id は 2 件前に宣言されたものか、宣言された呼び出しはすべて次の user ターンの前に応答されたか。これらは履歴の切り詰めや再試行ロジックが実際の配列を組み立てた後、実行時にしか存在しません。組み立て後の配列をここに貼り付ければ、言語を問わず、本番のログでも、メッセージ間のペアリングを直接検査できます。
はい。解析と診断は完全にブラウザ内で実行され、内容がページの外に出ることはありません。アップロードも保存も、貼り付けたテキストの分析もしません。診断が読むのは role と id と形状だけなので、より慎重を期すなら貼り付け前に content の値を伏せ字にしても構いません。