著者より：今お使いの Agent がまだ client.chat.completions.create に tools を渡す形になっているなら、GPT-6.1 に切り替えたときに、はっきりした分かれ目にぶつかります。テキストのやり取りはそのまま動きますが、ツール呼び出しはエンドポイントを変える必要があります。
GPT-6.1 にアップグレードすると、ツール呼び出しがエンドポイントで止まる理由
先に結論です。GPT-6 Astra、GPT-6.1 Sol、GPT-6.1 Terra の3モデルはいずれも Chat Completions に対応していますが、ツール呼び出しは Responses API を使う必要があります。つまり、同じコードの中でも、通常の会話だけなら Chat のままで問題ありません。ただし、関数を渡す、ツールの戻り値を読む、複数ターンのツールループを回すといった処理が入る場合は、リクエストを Responses エンドポイントに送る必要があります。
これはパラメータの調整で回避できる互換性の問題ではありません。tools の書き方を変えても、tool_choice を追加しても効果はなく、この3モデルでは Chat Completions にツール呼び出しの機能そのものが提供されていません。変更が必要なのはエンドポイントそのものと、その周辺のリクエスト／レスポンス構造の全体です。2つのエンドポイントを自分のキーで比較したい場合は、APIYI（apiyi.com）の統一エントリポイントが便利です。base_url に https://api.apiyi.com/v1 を指定し、モデル ID を変えるだけで切り替えられます。
もうひとつ見落としやすいのが、GPT-6 Sol と GPT-6 Luna の扱いです。この2モデルは Chat Completions でも関数呼び出しができますが、条件として reasoning_effort を none にする必要があります。言い換えると、Chat でもツールは呼べるものの、その代わりに推論の強度をオフにすることになります。推論を維持したい場合は、やはり Responses に戻る必要があります。この点はよく見落とされ、コードは動くのに結果の質が期待と違う、という事態になりがちです。
この記事で得られること：読み終えるころには、自分のツール呼び出しチェーンがどのパターンに当てはまるかを判断できるようになります。そのうえで、全体のアーキテクチャを作り直さずに、リクエストを Chat エンドポイントから Responses エンドポイントへ移行できます。
GPT-6.1 ツール呼び出しの重要ポイント
下の表は、3つのモデルと2つの旧型番について、どのエンドポイントを使うべきかをまとめたものです。まず自分が使っているモデルを確認してから、後述の移行手順に進むのがおすすめです。
| モデル | Chat Completions テキストのみ | Chat Completions ツール呼び出し | ツール呼び出しで使うエンドポイント |
|---|---|---|---|
| gpt-6.1-sol | 対応 | 非対応 | Responses |
| gpt-6.1-terra | 対応 | 非対応 | Responses |
| gpt-6-astra | 対応 | 非対応 | Responses |
| gpt-6-sol | 対応 | reasoning_effort が none の場合のみ対応 |
Responses（推論を維持したい場合） |
| gpt-6-luna | 対応 | reasoning_effort が none の場合のみ対応 |
Responses（推論を維持したい場合） |
エンドポイントの役割分担：Chat はテキスト、Responses はツール
この表を一言でまとめると、GPT-6 シリーズでは Chat Completions がテキスト専用のチャネルになり、ツール呼び出しのチャネルは Responses に切り分けられた、ということです。この変更が既存プロジェクトに与える影響は、用途によって段階的に異なります。質問応答、要約、分類だけを行うサービスなら、ほとんど手を加える必要はありません。一方、Agent、関数呼び出し、複数ステップのツール連携を行うサービスは、移行が必須です。
すでに SDK を一層ラップしているチームにとっては、移行の影響範囲が想像より小さいのは嬉しいポイントです。モデル ID も認証方式も base_url も変わりません。変わるのはリクエストボディの構造と、ツール実行結果の返し方に集中しています。つまり、本当の作業量は「モデルの切り替え」ではなく「呼び出し方の切り替え」にあります。
主力3モデルの選び方
GPT-6.1 Sol と GPT-6.1 Terra は今世代の主力ペアで、違いは主に位置づけとコストです。GPT-6 Astra は前世代のフラッグシップで、Chat のテキスト呼び出しと Responses のツール呼び出しにどちらも対応しているため、すでに安定稼働していて大きく変更したくないプロジェクトに向いています。選定の際は、まずツール呼び出しの頻度、次に1回あたりのコンテキスト長、最後に単価の順で検討してください。ツール呼び出しは何度もやり取りを重ねることが多く、トークン消費が膨らみやすいためです。
具体的な料金は後述の価格表で確認できます。APIYI（apiyi.com）のドキュメントで現在適用されている課金基準を直接確認すれば、古い価格で予算を組んでしまうこともありません。
GPT-6.1 のツール呼び出しで修正すべき5か所
ここは記事の中でいちばん実用的なパートです。以下の5か所を書き換えれば、典型的なツール呼び出しループを Chat エンドポイントから Responses エンドポイントへ切り替えられます。
| No. | 変更点 | Chat Completions の書き方 | Responses の書き方 |
|---|---|---|---|
| 1 | 呼び出しメソッド | client.chat.completions.create |
client.responses.create |
| 2 | 入力の受け渡し | messages 配列 |
input パラメータ |
| 3 | ツール宣言 | tools（そのまま） |
tools（構造はほぼ同じ） |
| 4 | ツール結果の返し方 | role: "tool" のメッセージ |
function_call_output タイプのアイテム |
| 5 | マルチターンのコンテキスト | messages 全体を手動で組み立てる |
previous_response_id でつなげられる |
1つ目と2つ目は、特に見落としやすいポイントです。tools の構造を書き換えただけで移行が終わったと思い込み、SDK のメソッドがまったく変わっておらず、リクエストが相変わらず chat.completions に送られていた、というケースは少なくありません。エンドポイントを決めるのはメソッドなので、メソッドを変えない限りエンドポイントは変わりません。
4つ目は、移行でもっとも引っかかりやすい部分です。Chat では、ツールの実行結果を role: "tool" のメッセージとして messages に追加します。一方 Responses では、モデルが返した呼び出しアイテムをそのまま次のリクエストに含めたうえで、function_call_output を1件追加します。1件でも欠けたり、順序が1つずれたりすると、モデルが同じ呼び出しを繰り返してしまうことがあります。
5つ目は「必須ではないけれど、変更をおすすめしたい」項目です。Responses では previous_response_id を使って前のターンを引き継げるため、毎回すべての履歴メッセージを再送するコストを省けます。ツール呼び出しのターン数が多い Agent では、モデルを替えるよりもコストへの影響が大きくなります。
🎯 技術アドバイス：移行期間中にもっとも手軽に検証する方法は、新旧2つの経路で同じリクエスト群を並行して実行し、ツールのヒット率と返却構造を比較することです。APIYI（apiyi.com）の統一インターフェースを使えば、複数プラットフォームのキーを管理する手間が省け、一度の設定で Responses と Chat の実際のレスポンスの違いを見比べられます。
GPT-6.1 ツール呼び出しクイックスタート
ツールを呼び出す最小限の例
注文ステータスを調べる関数ツールがあるとします。名前は get_order_status、引数は注文番号です。変更が必要な箇所は2つだけで、呼び出し方法と結果の書き戻しです。
- クライアントの初期化はそのままで構いません。
api_keyにはご自身のキーを指定し、base_urlにはhttps://api.apiyi.com/v1を設定します。これで OpenAI 互換インターフェースのモデルをそのまま呼び出せます。 - モデル ID には
gpt-6.1-sol（またはgpt-6.1-terra、gpt-6-astra）を指定します。この3つはいずれも、ツール呼び出しに Responses を使います。 - これまでの
client.chat.completions.create(...)をclient.responses.create(...)に置き換え、messagesパラメータをinputに変更します。 toolsはこれまでどおり渡します。ツールの説明やパラメータの schema を書き直す必要はありません。- 返ってきた
outputから、タイプがfunction_callのエントリを探し、ツール名と引数を取り出して、注文照会関数をローカルで実行します。 - 実行結果を
function_call_outputとして追加し、2回目のリクエストを送って最終的な回答を受け取ります。
この6ステップのうち、本当に「変更が必須」なのはステップ3とステップ6です。ステップ1と2は設定で、ステップ4と5は Chat 時代の習慣を、読み取る場所だけ変えて引き継ぐものです。
🚀 クイックスタート：テスト環境を自分で用意したくない場合は、APIYI（apiyi.com）で無料のテスト枠を受け取り、上の注文照会の例を一度動かしてみてください。そのうえで本番コードを改修すれば、リスクを最小限に抑えられます。
さらに手間を省く方法として、先にツール層とモデル層を切り離しておくやり方があります。ツール定義を1か所にまとめ、呼び出しの入口を1つの関数にラップして、内部で「テキストのみなら Chat、tools 付きなら Responses」と振り分けます。こうすれば移行はラップ層だけで完結し、業務コードは1行も変更せずに済みます。
GPT-6.1 モデルの料金と選び方（2026-11-12）
下表は 2026-11-12 時点で有効な基準でまとめたものです。単位はすべて 1M トークンあたりの米ドル価格です。
| モデル | 入力 | 出力 | キャッシュ読み取り | 推奨エンドポイント |
|---|---|---|---|---|
| gpt-6.1-sol | $2 | $10 | $0.1 | responses |
| gpt-6.1-terra | $1 | $5 | $0.05 | responses |
| gpt-6-luna | $0.1 | $0.5 | $0.01 | chat（reasoning_effort が none の場合）または responses |
この表から、実用面でわかりやすい結論が読み取れます。GPT-6.1 Terra は入出力の価格がちょうど Sol の半分です。ツール呼び出しのラウンドが多く、コンテキストの重複率が高いケースでは、Terra をデフォルトにするのが合っていることが多いでしょう。一方、GPT-6 Luna は価格が一桁安く、分類や抽出といった軽いタスクに向いています。Sol や Terra は、本当に推論が必要なツールオーケストレーションの部分に回すのがおすすめです。
キャッシュ読み取りの列は、ぜひ単独で見ておきたいところです。ツール呼び出しでは、システムプロンプト、ツール定義、会話履歴など、重複するプレフィックスが自然と大量に発生します。この部分がキャッシュにヒットすると、単価は入力価格の約 1/20 になります。そのため、Responses で previous_response_id を使ってコンテキストを引き継げば、通信量が減るだけでなく、実際のコスト削減にもつながります。
💰 コストのヒント：プロジェクトごとに予算を分けて管理したい場合は、APIYI（apiyi.com）の統一 API キーで呼び出すと、複数モデルの使用量を一か所にまとめて集計できます。従量課金と組み合わせれば、ツール呼び出しの実際のコストも把握しやすくなります。
GPT-6.1 ツール呼び出しのよくある質問 FAQ
Q1：GPT-6.1 とは何ですか？ GPT-6 とはどのような関係ですか？
GPT-6.1 は GPT-6 シリーズの改良版で、現在は GPT-6.1 Sol と GPT-6.1 Terra の2モデルがあります。GPT-6 シリーズには GPT-6 Astra、GPT-6 Sol、GPT-6 Luna が含まれます。いずれも同じ Responses のツール呼び出し経路を共有しており、違いは主に性能面での位置づけと価格です。
Q2：Chat Completions でツールを呼び出せないのですが、パラメータの書き方が間違っていますか？
パラメータの問題ではありません。GPT-6 Astra、GPT-6.1 Sol、GPT-6.1 Terra は、Chat Completions ではテキストのみの機能しか提供されておらず、ツール呼び出しは Responses API に限定されています。`tools` や `tool_choice` を書き換えても効果はありません。SDK のメソッドを `chat.completions.create` から `responses.create` に切り替える必要があります。
Q3：GPT-6 Sol と GPT-6 Luna は Chat で関数呼び出しできますか？
できますが、`reasoning_effort` を `none` に設定している場合に限ります。推論強度を維持したい場合は、この2モデルでも Responses を使う必要があります。この制約は移行時に最も見落としやすいポイントです。エラーにはならず、結果が期待と食い違うだけだからです。
Q4：Responses に移行する際、モデル ID を変更する必要はありますか？
必要ありません。モデル ID は `gpt-6.1-sol`、`gpt-6.1-terra`、`gpt-6-astra` のままで問題なく、`base_url` や認証方法も変わりません。実際に変更が必要なのは、呼び出しメソッド、入力の渡し方、ツール結果を戻す際の構造の3点です。
Q5：移行後のツール呼び出しが正常に動くか、手早く確認するにはどうすればいいですか？
注文照会のような簡単なツールを使ったスモークテストがおすすめです。まずリクエストが Responses エンドポイントに届いていることを確認し、次に返却された `output` に `function_call` の項目があることを確認します。最後に `function_call_output` を戻したあと、モデルが最終回答を返すことを確認してください。3つとも通れば、経路は正常です。APIYI（apiyi.com）でテスト用のキーを取得すれば、この一連の検証を行えます。
Q6：テキストのみのサービスも、一緒に Responses へ移行する必要がありますか？
その必要はありません。主力3モデルの Chat Completions によるテキストのみの機能は引き続き利用できるため、質問応答・要約・翻訳といったタスクだけを行うサービスはそのままで構いません。移行が必須なのは `tools` を含むリクエストだけで、今回の変更の影響範囲が段階的になっているのはこのためです。
Q7：複数ターンのツール呼び出しで、コンテキストのコストを抑えるにはどうすればいいですか？
毎ターン全履歴を送り直すのではなく、`previous_response_id` で前のターンを引き継ぐのがおすすめです。こうすると重複するプレフィックスがキャッシュにヒットしやすくなり、キャッシュ読み取りの単価は入力単価より大幅に安くなります。`gpt-6.1-sol` の場合、入力が $2、キャッシュ読み取りが $0.1 で、差はかなり大きいです。
Q8：Responses への移行で、既知の落とし穴はありますか？
代表的なものは2つあります。1つ目は、`tools` の構造だけを変更して呼び出しメソッドを変えていないケースで、リクエストが依然として Chat エンドポイントに送られてしまいます。2つ目は、ツール結果を戻す際に `role: “tool”` という従来の書き方を引き継いでしまうケースで、モデルが出力を受け取れず、同じ呼び出しを繰り返してしまいます。また、チーム内で GPT-6 Sol のように `reasoning_effort` を `none` にする必要があるモデルを併用している場合は、ラッパー層で統一的に制約をかけておくとよいでしょう。そうすれば「同じツールがあるモデルでは使えて、別のモデルでは使えない」という事態を避けられます。
GPT-6.1 ツール呼び出しの要点 Key Takeaways
- エンドポイントが分かれました：GPT-6.1 Sol、Terra、GPT-6 Astra では、テキストは Chat、ツールは必ず Responses を使います。
- 例外が一つあります：GPT-6 Sol と GPT-6 Luna は Chat でも関数呼び出しができますが、
reasoning_effortをnoneにする必要があります。 - 変更点は五つです：呼び出しメソッド、
inputの渡し方、toolsの宣言、function_call_outputの返却、previous_response_idによるつなぎ方です。 - モデル ID は変わりません：
base_urlと Key はそのままで、移行が必要なのはラッパー層だけです。 - コストはキャッシュ次第です：ツール呼び出しのプレフィックスは重複率が高く、キャッシュ読み取り価格は入力価格の約 20 分の 1 です。
- 検証は三段階で行います：エンドポイントの確認、
outputにfunction_callがあることの確認、結果を返却したあとに最終回答が得られることの確認です。 - 始め方：APIYI（apiyi.com）の無料枠で、まず注文照会用の小さなツールを動かしてみて、それから本番の処理系に手を入れるのがおすすめです。
まとめ
今回の変更の核心は一言で言えます。GPT-6.1 では、ツール呼び出しが Chat Completions から Responses に移り、テキストだけの機能はそのまま残りました。ここから、覚えておきたいポイントが三つ出てきます。
- まず分類してから移行する：テキストだけのサービスは変更不要で、
toolsを含むリクエストだけエンドポイントを切り替える必要があります。 - パラメータではなくメソッドを変える：エンドポイントを切り替えるスイッチは
client.responses.createで、toolsの構造はそれに付随するものです。 - 結果の返却でつまずきやすい：
function_call_outputがrole: "tool"に代わるもので、順序も内容の完全性も正しく揃える必要があります。
すでに本番でツール呼び出しを動かしているなら、まず最小限のツールを一つ選んで段階的に切り替え、処理が通ることを確認してから全面移行するのがおすすめです。複数のプラットフォームの Key や環境設定を用意する手間を省きたい場合は、APIYI（apiyi.com）を使えば、同じ Key で Responses と Chat の実際のレスポンスを見比べられます。base_url は https://api.apiyi.com/v1 に統一するだけで済みます。
参考資料
- OpenAI 公式モデルドキュメント：GPT-6 シリーズと GPT-6.1 シリーズのエンドポイント対応状況の説明。ツール呼び出しには Responses を使う必要があるという制限も記載されています
- リンク：
developers.openai.com/api/docs/guides/latest-model -
説明： あるモデルが Chat Completions で関数呼び出しに対応しているかを判断するための一次情報です
-
APIYI モデル・料金ドキュメント：各モデルの入力・出力・キャッシュ読み取りの単価と、推奨エンドポイントを掲載
- リンク：
docs.apiyi.com/models - 説明： 2026-11-12 から適用される課金ルールとエンドポイントの推奨を確認できます
著者: APIYI 技術チーム
技術交流: APIYI apiyi.com のトップページからお気軽にご連絡ください。API の詳しい説明は docs.apiyi.com のドキュメントセンターでご覧いただけます
