著者注：Codex と WorkBuddy は、いずれも Claude 専用に設計されたクライアントではありません。エラーのほとんどは接続部分で発生します。この記事では、「エンドポイント」「ツールのやり取り」「思考ブロック」の3種類に分け、エラーメッセージと対処法を対応させて紹介します。
私たちも実際にこの問題にはまりました。最初は手軽さを優先し、OpenAI 互換プロトコルで Claude を呼び出していました。つまり、Claude を OpenAI のモデルとして扱っていたのです。簡単な会話は問題なくできましたが、ツールを呼び出すとエラーになり、再試行しても解決しませんでした。その後、Anthropic ネイティブの /v1/messages に切り替えたところ、ようやくスムーズに動きました。
まずは該当する症状を確認しましょう。Codex の起動直後に wire_api 関連のエラーが出る、WorkBuddy で会話はできるのにツールを呼び出すと 400 エラーになる、あるいは返答がなぜか空になる場合は、この記事で取り上げる問題の可能性が高いです。
- モデル自体の故障ではなく、接続部分の3か所で仕様が合っていないことが原因です。エンドポイント、ツールのやり取り、思考ブロックの3つです。
- 最も修正しやすいのは第3の問題（思考ブロックと出力予算）で、クライアント側の読み取り方と
max_tokensを変更するだけです。 - 難易度が中程度なのは第2の問題（ツールのやり取り）で、主に変換レイヤーやゲートウェイで修正します。
- 最も手間がかかるのは第1の問題（エンドポイント）で、クライアントを変更するか、変換ゲートウェイを追加する必要があります。
この記事の結論を優先順位で示すと、Anthropic ネイティブプロトコル > ゲートウェイで Anthropic 形式に変換 > OpenAI 互換の chat です。まずは、以下の対照表でエラーがどの種類に当てはまるかを確認してみてください。
Codex・WorkBuddy で Claude を使うときに起きるエラー：3つの原因
まず、用語を整理しましょう。Responses、Messages、Chat Completions は、レストランでの3通りの注文方法のようなものです。厨房で作る料理は同じでも、注文票の形式が異なります。Codex は Responses でしか注文できず、Claude が受け付けるのは Messages と Chat Completions です。thinking ブロックはモデルの下書きに相当し、Anthropic はこの下書きが改変されていないかを検証します。
| カテゴリ | 仕組みを一言で | 主な修正対象 | 修正の難しさ |
|---|---|---|---|
| 第1類：エンドポイントの不一致 | Codex は Responses だけを送信し、Claude はその形式を受け付けない | ツールまたはゲートウェイの変更 | 最も難しい |
| 第2類：ツールとのやり取りの不一致 | 変換の過程で ID、コンテンツブロック、thinking ブロックが変更される | 主にゲートウェイ | 中程度 |
| 第3類：thinking ブロックと予算の不一致 | モデルは毎回思考するが、クライアントは従来の方法で結果を読み取る | クライアント | 最も簡単 |
第1類：CodexからClaudeを呼び出す際にエンドポイントが合わない
エラーの表示例：Error loading config.toml: wire_api = "chat" is no longer supported. How to fix: set wire_api = "responses".
これは、設定での wire_api = "chat" という指定がサポートされなくなったため、responsesに変更する必要があるという意味です。
原因：Codexの公式設定リファレンスによると、現在 wire_api に指定できる値は responses だけです。以前の「回避策としてwire_apiをchatに変更する」という方法は使えなくなり、新しいバージョンのCodexでは設定の読み込み時にエラーが発生します。そのプロバイダーを実際には使っていなくても、codex login status も実行できなくなります。一方、APIYI apiyi.comのClaudeモデルではanthropicとopenaiの2種類のエンドポイントのみが提供されており、/v1/responses は利用できません。両者の形式が合わず、間で変換も行われないため、エラーが発生します。
解決方法：
1. クライアント：~/.codex/config.toml を開き、エラーメッセージに従って残っているchatの指定を削除し、まずCodexを正常に起動できるようにします。
2. ツールを変更：Claudeでコードを書きたいだけなら、Claude Codeに切り替えましょう。Claude CodeはネイティブのMessages APIを使います。
3. ゲートウェイ：Codexを使い続ける必要がある場合は、ResponsesをMessagesに変換できるゲートウェイを追加します。プロバイダーのアドレスには、Anthropicのネイティブエンドポイントを優先して指定します。
確認基準：codex login status が正常に実行できること。ゲートウェイを使う場合は、ファイルの読み取りが必要な指示を送り、Codexがツール呼び出しを最後まで完了できることを確認します。
第2類：Claude のツール呼び出しと結果が対応していない
エラーの表示例：
– tool_use ids were found without tool_result blocks immediately after
– An assistant message with 'tool_calls' must be followed by tool messages...
– thinking or redacted_thinking blocks in the latest assistant message cannot be modified
– Invalid signature in thinking block. The block is bound to a different conversation.
1つ目は、tool_use の直後に対応する tool_result がないことを示します。2つ目は、Chat 形式での同様の問題です。3つ目は前のターンの思考ブロックが変更されたこと、4つ目は思考ブロックの署名が現在の会話と一致しないことを示します。
原因：互換レイヤーは、Claude の text、tool_use、tool_result、thinking といったコンテンツブロックを、tool_calls や role: tool に変換し、その後再び元の形式に戻します。この過程で ID の対応を間違えたり、コンテンツブロックが結合されたり、thinking ブロックが移動したりすると、400 が返されます。Responses には developer ロールがありますが、Messages にはないため、system に統合する必要もあります。また、claude-opus-5-5 では次の古い指定方法を受け付けません：tool_choice の強制（any またはツールの指定）、assistant メッセージの事前入力（prefill）、temperature / top_p / top_k。
対処法：
1. ゲートウェイ：各 tool_use の直後に同じ ID の tool_result を配置し、tool_result は user メッセージのコンテンツブロックの先頭に置きます。
2. ゲートウェイ：前のターンの assistant メッセージをそのまま返します。thinking フィールドが空のブロックも含め、developer の内容は system に統合します。
3. クライアント：tool_choice は auto または none のみにし、prefill とサンプリングパラメーターを削除します。
4. クライアント：すでに署名エラーが発生している場合は、新しい会話を開始します。APIYI の公式 FAQ によると、この種のエラーが Request rejected (429) として表示されることもありますが、レート制限ではないため、待機時間を延ばしながら再試行しても解決しません。
5. ツールの変更：harness に強制的な tool_choice が固定されていて自分で変更できない場合は、クライアントを変更します。
同様の 400 エラーの調査には、Claude Code の 400 エラーと tool use concurrency を参考にしてください。tool_use と tool_result のペアリングに失敗した場合に、原因を一つずつ特定する方法を解説しています。
確認基準：複数ターンにわたる連続したツール呼び出し（ファイルの読み込み、編集、再読み込み）で 400 が発生せず、同じ会話内でも署名エラーが発生しないこと。
第3類：Claudeの思考ブロックと出力予算の不一致
エラーの例："thinking.type.enabled" is not supported for this model. Use "thinking.type.adaptive" and "output_config.effort" to control thinking behavior. または、"thinking.type.disabled" is not supported for this model. というエラーが出ることもあります。エラーは出なくても、返信が空になったり、途中で切れたりする場合もあります。
原因：claude-opus-5-5はすべてのリクエストで思考を行うため、レスポンスがthinkingブロックから始まることがあります。クライアントが位置を指定してcontent[0].textを読み取ると、空の値を取得してしまいます。思考トークンは出力トークンとして課金され、max_tokensも消費します。また、この世代からはツール呼び出しの合間の説明もthinkingブロックに格納されます。デフォルトのdisplayはomittedなので、説明が表示されず、空に見えることがあります。
修正方法：
1. クライアント側：thinkingパラメータを省略するか、thinking: {"type": "adaptive"}と指定し、budget_tokensを削除します。
2. クライアント側：思考の深さはoutput_config.effortで制御します。low / medium / high / xhigh / maxから選べ、デフォルトはmediumです。
3. クライアント側：返信を読み取るときは、位置ではなくtypeに基づいてtextブロックを探します。
4. クライアント側：max_tokensには思考と本文の両方を収められる値を設定します。ツール呼び出しの合間の説明を表示したい場合は、thinking.displayをsummarizedに設定します。
この新しい仕組みを詳しく知りたい方は、Adaptive Thinking（適応的思考）の解説をご覧ください。budget_tokensからeffortの各設定値へ移行する方法を説明しています。
確認基準：同じプロンプトを続けて数回送信しても、毎回本文が空にならず、thinking.type関連のエラーも発生しないこと。
Claude のエラー原文・早見表
| エラー原文のキーワード | 分類 | 5分でできるセルフチェック | 解決しない場合の関連記事 |
|---|---|---|---|
wire_api = "chat" is no longer supported |
第1類 | config.toml に古い chat の記述が残っていないか確認 | Magpie チュートリアル |
tool_use ids were found without tool_result |
第2類 | tool_result の ID と位置を確認 | Claude Code の 400 エラー：tool use concurrency |
must be followed by tool messages |
第2類 | Chat 互換レイヤーを経由しているか確認 | Claude Code の 400 エラー：tool use concurrency |
Invalid signature in thinking block |
第2類 | 新しいセッションを開いて再試行 | Adaptive Thinking（適応的思考）の解説 |
thinking.type.enabled / 応答が空 |
第3類 | budget_tokens を削除し、type に基づいて読み取るよう変更 | Adaptive Thinking（適応的思考）の解説 |
| 簡単な会話はできるが、ツールを呼び出すとエラーになる | 第2類 | WorkBuddy の接続プロトコルを確認 | WorkBuddy は Claude ネイティブ形式の呼び出しに対応している？ |
Codex・WorkBuddy で Claude の呼び出しエラーを解決する2つの方法
| 方法 | こんな人におすすめ | プロトコルの優先度 |
|---|---|---|
| A ネイティブクライアントに戻す | Claude を使ってコードを書きたい人 | 最高。変換によるロスがない |
| B 変換ゲートウェイを追加する | Codex または WorkBuddy を使い続ける必要がある人 | 次点。プロバイダーのアドレスに anthropic を指定 |
| chat 互換のまま使い続ける | 非推奨 | 最低。ツール呼び出しや thinking ブロックで問題が起きやすい |
方法 A：Codex で Claude を使いたい場合は、Claude Code に切り替えます。WorkBuddy の公式モデル設定には /chat/completions と「カスタムプロトコル」のスイッチしかなく、Anthropic ネイティブの接続先はありません。そのため、WorkBuddy でネイティブの thinking を使うことは期待できません。詳しくは Workbuddy は Claude ネイティブ形式の呼び出しに対応している？ をご覧ください。「会話はできるのにツールでエラーが出る」理由と、その回避策を解説しています。
WorkBuddy に直接接続する場合は、「設定 → モデル → カスタム」を開き、Base URL に https://api.apiyi.com/v1、モデル名に claude-opus-5-5 を入力します。Key には APIYI apiyi.com のトークンページで作成したキーを使います。URL は /v1 までにして、/chat/completions を自分で追加しないでください。
図注：URL が /v1 までになっているか、モデル名が claude-opus-5-5 か、「カスタムプロトコル」のスイッチがオフのままになっているかを確認してください。
方法 B：Codex にゲートウェイを追加する場合、Codex 側の wire_api = "responses" は変更せず、ゲートウェイがリクエストを Messages に変換して転送します。WorkBuddy のカスタムモデル URL にはローカルゲートウェイを指定し、Claude モデルのプロバイダーアドレスには Anthropic ネイティブエンドポイント https://api.apiyi.com を入力します。
🎯 技術的なアドバイス：1つのキーで、ネイティブの Messages と互換 chat の両方のエンドポイントを検証できます。まずは APIYI apiyi.com のテスト枠を使い、2つのプロトコルでツール呼び出しの動作を比較してから、どちらの方法を選ぶか決めるのがおすすめです。
Magpie を使って Codex・WorkBuddy に Claude を接続する
Magpie は、MIT ライセンスのコミュニティ製オープンソースツールです。ローカルの 127.0.0.1:3425 にゲートウェイを立ち上げ、OpenAI Chat、Responses、Anthropic Messages の間で相互に変換できます。これにより、第1の問題を補えます。手動設定のほか、Magpie の画面から視覚的に設定することもできます。GUI で APIキーと Base URL を入力し、Codex と WorkBuddy を同じゲートウェイに接続すれば、設定ファイルを手作業で編集する必要はありません。詳しい手順は Magpie チュートリアル をご覧ください。1つのゲートウェイで複数の Agent のモデル接続先をまとめる方法を解説しています。
- プロバイダーページ：キーを追加します。APIYI は「中継」グループにあります。「+ カスタムプロバイダー」をクリックして手動で入力することもできます。
- Agent ページ：Codex と WorkBuddy それぞれで claude-opus-5-5 を選択します。
- 古いセッションの履歴を引き継がず、新しいセッションを開始します。
図注：プロバイダーが「中継」グループで利用可能と表示されているか、Base URL が Anthropic ネイティブのアドレスになっているか、Agent ページの2つのスイッチが両方オンになっているかを確認してください。
Claude の呼び出し料金とキャッシュコスト
以下の料金の単位は米ドル／100万トークンです。2026年10月28日確認。モデルと料金はプラットフォームのモデル一覧をご確認ください。
| モデル | 入力 | 出力 | キャッシュ読み取り | 利用可能なプラットフォーム |
|---|---|---|---|---|
| claude-opus-5-5 | $4 | $20 | $0.2 | APIYI apiyi.com |
| claude-sonnet-5-5 | $2 | $10 | $0.1 | APIYI apiyi.com |
| claude-haiku-5-5 | $0.1 | $0.5 | $0.01 | APIYI apiyi.com |
エージェントは各ラウンドで履歴全体を再送します。また、claude-opus-5-5 の思考トークンには出力料金が適用されます。変換レイヤーで system、tools、プレフィックスの順序が変わると、cache_control のブレークポイントが無効になり、コストとレイテンシーの両方が増加します。キャッシュヒット率に異常がある場合は、Claude のキャッシュヒット率が 0 に低下した場合の診断をご覧ください。ブレークポイントが無効になる原因の特定方法を解説しています。
リスクとアカウント停止について
Magpie などのゲートウェイは、コミュニティによるオープンソースツールであり、APIYI の公式コンポーネントではありません。APIYI はこれらを推奨しておらず、技術サポートも提供していません。このようなツールを介してリクエストを転送すると、接続先のサービスでレート制限を受けたり、アカウントが停止されたりする可能性があります。その結果については、利用者の自己責任となります。まずはテストアカウントで一連の流れを確認し、問題がないことを確かめてから本番アカウントでの利用を検討することをおすすめします。
こんな場合は無理に導入しなくてOK
Codex で Claude を使うのがたまに一度きりの場合や、会社の環境で追加ソフトウェアをインストールできない場合、もともと Claude だけを使えれば十分な場合は、ゲートウェイを構築する必要はありません。クライアントを Claude Code に変更するか、Codex で Responses にネイティブ対応したモデルに切り替えるほうが、ずっと手軽です。
よくある質問 FAQ
Q1：Codex は Claude を公式にサポートしていますか？
サポートしていません。Codex は Responses のみを使用し、Claude はこのエンドポイントを提供していないため、利用するには変換レイヤーが必要です。
Q2：APIYI の Claude で /v1/responses を使えますか？
使えません。APIYI（apiyi.com）の Claude モデルでは、anthropic と openai の2種類のエンドポイントのみが提供されています。
Q3：429 エラーはレート制限が原因ですか？
エラー内容に `Invalid signature in thinking block` が含まれている場合は、レート制限ではなく、思考ブロックの署名検証に失敗しています。新しいセッションを開始すれば解決します。
Q4：WorkBuddy で Anthropic のネイティブプロトコルを使えますか？
公式の設定には Anthropic ネイティブの接続先がありません。OpenAI 互換の方法を使うか、ゲートウェイを介して変換する必要があります。
Q5：修正できたかどうかを手早く確認するには？
APIYI（apiyi.com）のテスト用利用枠で新しいセッションを開始し、ツール呼び出しを数回続けて実行します。あわせて、本文が空になっていないことも確認してください。
Codex・WorkBuddy で Claude を使う際のエラー確認リスト
- Codex の設定に chat 形式の記述が残っていない。
- Claude へのリクエストは、ネイティブプロトコルまたは Anthropic 形式に変換するゲートウェイを経由しており、chat 互換形式を使っていない。
- すべての tool_use の直後に、同じ ID の tool_result がある。
- 前のターンの thinking ブロックを変更せず、そのまま返している。
- 強制的な tool_choice、prefill、サンプリングパラメータを使用していない。
- レスポンスを type に応じて読み取り、
max_tokensで思考に必要な余裕を確保している。
まとめ
Codex・WorkBuddy で Claude を使う際のエラーは、ほとんどがエンドポイント、ツール呼び出しと結果のやり取り、思考ブロックの3つに分類できます。修正する順序は、まずクライアントの読み取り方法を見直し、次に変換レイヤーを修正し、最後にクライアントの変更やゲートウェイの追加を検討します。
プロトコルは、ネイティブの Anthropic 形式を使えるならそれを選び、使えない場合はゲートウェイで Anthropic 形式に変換しましょう。chat 互換形式を長期的に使い続けることは避けてください。APIYI（apiyi.com）を通じて、同じ APIキーで異なるプロトコルの動作を比較することをおすすめします。
📚 参考資料
- Codex 設定リファレンス：wire_api の設定値に関する説明
- リンク：
developers.openai.com/codex/config-reference - 内容：wire_api が現在 responses のみをサポートしていることを確認できます
- Codex 設定の読み込みエラー事例
- リンク：
github.com/openai/codex/issues/41816 - 内容：wire_api のエラーメッセージ原文の出典です
- Claude Opus 5.5 移行ガイド
- リンク：
platform.claude.com/docs/en/models/opus-5-5/migration-guide - 内容：thinking、tool_choice、サンプリングパラメータに関する厳格な制限
- Anthropic ツール呼び出しのトラブルシューティング
- リンク：
platform.claude.com/docs/en/agents-and-tools/tool-use/troubleshooting-tool-use - 内容：tool_use と tool_result のペアリングルール
- WorkBuddy モデル設定
- リンク：
www.workbuddy.ai/docs/zh/workbuddy/From-Beginner-to-Expert-Guide/Function-Description/Model - 内容：カスタムモデルの設定画面とカスタムプロトコルの切り替え
- Magpie リポジトリ
- リンク：
github.com/yetone/magpie - 内容：コミュニティ製のオープンソースゲートウェイです。使用前にご自身でリスクを評価してください
著者：APIYI 技術チーム
技術に関するお問い合わせ：APIYI（apiyi.com）のトップページからお気軽にご連絡ください。詳しい資料は docs.apiyi.com のドキュメントセンターをご覧ください。
