第2回 ResponsesとMessagesの設計差 — 会話・推論・ツールの責任はどこにあるか
連載：LLMのAPIと提供経路を選ぶ・第2回 ｜ 連載のまとめ
APIはアプリの責任範囲を決める
OpenAIのResponses APIとAnthropicのMessages APIは、どちらも文章生成、推論、ツールを使う処理の土台になります。差が表れるのは、会話状態の持ち方と、ツールの選択や出力形式をAPIの設定でどこまで指定できるかです。
ここでは、提供元のAPIを直接使う場合のGPT-5.6 SolとClaude Opus 5.5を中心に比較します。Microsoft Foundry（以下、Foundry）でも同じ機能がすべて使えるという意味ではありません。
| 観点 | GPT-5.6 Sol／Responses | Opus 5.5／Messages | 設計への影響 |
|---|---|---|---|
| 会話の継続 | 応答IDで参照、または自前履歴 | メッセージ履歴を送る | 保存・削除・復旧の責任を決める |
| 推論の調整 | reasoning.effort、noneも可能 | output_config.effort、思考は常時有効 | 品質を満たす設定と遅延を実測する |
| 推論の持ち越し | 状態参照、または暗号化アイテムの再送 | 署名付き思考ブロックを再送 | 不透明な状態を加工しない |
| 出力の構造 | outputに本文・推論・ツール等のアイテム | contentに型別のブロック | 配列の先頭だけを回答にしない |
| 必須ツールの指定 | 対応するtool_choiceで選択を指定 | any／toolの強制指定は不可 | 必須の業務手順をアプリに置く |
| 形式の制約 | Structured Outputs | Structured Outputs、strict tool use | 形式が正しくても内容と実行結果は検証する |
会話の履歴と推論状態を分ける
OpenAIでは、前の応答をprevious_response_idで参照する方式や、履歴を自分で送る方式を選べます。したがって「Responsesはサーバー管理、Messagesは自前管理」という二択にはなりません。Responsesも自前管理で使えます。[1]
ClaudeのMessages APIでは、アプリがそれまでの会話履歴を次のリクエストに含めて送ります。Opus 5.5では、利用者の発言やモデルの回答文に加え、推論の継続に使う「思考ブロック」も履歴に含める必要があります。そのため、アプリは回答文だけでなく、APIが返した思考ブロックも保存し、次のリクエストで再送できるようにします。[2]
設計では、次の3種類を分けて扱います。
| データ | 目的 | 移行時の扱い |
|---|---|---|
| 利用者に見える発言と回答 | 会話の表示、検索、利用者による確認 | 他モデルへの引き継ぎ用に整える |
| プロバイダー固有のアイテム・署名 | 推論継続、ツール呼び出しの対応付け | 互換性を確認し、原文で保つ |
| 取得済みの根拠・業務の確定状態 | 判断の再現、二重実行防止 | モデルを切り替えても業務の判断の基準として保持する |
この分離は筆者の設計提案です。原文保存は無期限保存を意味しません。保存期限・暗号化・閲覧権限・削除の対象として扱います。
「考える深さ」は同じ目盛りではない
GPT-5.6 Solはreasoning.effortで推論量を調整でき、noneも選べます。Claude Opus 5.5は思考を無効化できず、output_config.effortで深さを調整します。Sonnet 5.5ではbetween_toolsにより前置きの思考を省けますが、対応するeffortや併用パラメーターに制約があります。GPT-5.6 Sol[3]、Opusの変更点[4]、Sonnetの変更点[5]
同じmediumでも品質・遅延・消費量が同じになるとは限りません。「どちらもmediumで比較」だけでは、自社に最適な設定を評価できません。各モデルで合格品質を満たす最小の設定を探し、その状態で費用と遅延を比べます。
思考の要約が表示できることも、推論の内部状態を完全に読めることとは別です。UIには処理中の状態を出し、監査には参照資料・ツール実行・最終判断を残す構成が実用的です。
JSONの保証とツール実行の保証は違う
Claude Opus 5.5／Sonnet 5.5では、tool_choiceのanyや特定ツール指定はエラーになります。Structured Outputsやstrict tool useは、出力やツール引数の形式を整えるための機能です。それだけでは特定のツールが呼ばれたことを保証しません。 Opusのツール選択仕様[4]
「必ず顧客の権限を確認してから検索する」などの業務要件は、アプリが先に実行します。モデルが検索を提案しなかった場合の扱いも、アプリの制御フローに置きます。
OpenAI側で使うツールを指定しても、呼び出し先のシステムでは権限不足でアクセスを拒否されたり、処理がエラーになったりする場合があります。アプリ側では、ツールが選ばれたことだけで処理が成功したと判断せず、呼び出し先から返る結果を確認します。
| 要件 | 保証を置く場所 |
|---|---|
| 所定のJSONで受け取る | 対応する構造化出力とアプリ側の検証 |
| 許可された検索を必ず実施する | アプリの必須処理 |
| 申請・注文を一度だけ確定する | 業務APIの認可・冪等性・トランザクション |
| 実行結果を根拠として回答する | ツール結果の保存、回答評価、失敗時の停止 |
「ツール対応」の実行主体を読む
検索やコード実行が提供元のサーバーで動くのか、モデルが呼び出しを提案してアプリ側で動かすのかを区別します。後者には、実行環境、資格情報、タイムアウト、承認、再試行の実装が必要です。OpenAIのツールには組み込み機能と外部連携、Claudeにはサーバーツールとクライアントツールがあります。OpenAIのツール[6]、Claudeのツール概要[7]
SDKと管理型エージェントを同じ層で比較する
モデルを呼ぶクライアントSDK、ツールループを動かすエージェントSDK、実行環境ごと預ける管理サービスは、互いに置き換えられる範囲が一部に限られます。
| 層 | OpenAI側の例 | Anthropic側の例 | 自社が判断すること |
|---|---|---|---|
| モデルAPI | Responses API | Messages API | 入出力・状態・ツールの契約 |
| クライアントSDK | OpenAI公式SDK | Anthropic公式SDK | 接続、型、ストリーム、採用バージョン |
| エージェントの実行ループ | Agents SDK | Claude Agent SDK | ツールの権限、状態、制御、実行環境 |
| 管理型の実行基盤 | Agents API | Claude Managed Agents | 保存、実行環境、復旧、契約と所在地 |
Claude Agent SDKはClaude Codeのツールと実行ループをアプリへ組み込む選択肢です。管理型のAgents APIとClaude Managed Agentsは、実行や状態をサービス側へ預ける選択肢です。Claude Agent SDK[8]、OpenAI Agents API[9]、Claude Managed Agents[10]
2026年10月8日の文書では、この2つの管理型基盤はいずれもゼロデータ保持（Zero Data Retention、以下、ZDR）の対象外です。自前の実行環境を選べることから、管理APIが保持するセッションまでZDRになると判断してはいけません。
ゼロデータ保持が必須の場合は、まず利用するモデルAPIがZDRに対応するか、その適用条件を確認します。その上で、会話履歴の管理やツールの呼び出しを、管理サービスに任せず自社のアプリで行う構成を検討します。
Agents SDKやClaude Agent SDKを採用しても、モデルAPIやホスティングの非対応機能が自動で使えるようにはなりません。Foundry Agent Serviceも、この表の各社の直接サービスとは別に評価する対象です。
共通アダプターを作るなら、テキスト、使用量、終了状態、ツール結果を共通化しつつ、各社固有の原文を別に保持します。共通のeffortをそのまま各社に送るような抽象化は、互換性を過大評価しやすい設計です。
HTTP 200の後にも判断が残る
通信が成功しても、回答が完成したとは限りません。上限到達、拒否、ツール待ち、途中のストリームエラーを分け、本文が空でも終了状態を検査します。画面で「完了」を出すのは、アプリが最終状態を確認した後にします。
APIの差は、こうした責任分担を通じて実装工数と障害時の体験へ現れます。
前回： 第1回 性能以外の選定軸
参考資料
参考資料の仕様確認日：2026年10月8日。表と実装方針は筆者の整理・提案です。