OpenAI DevDay 2026 開発者ガイド：Responses API、Structured Outputs、Tool Calling、MCP に何が起き得るか

このガイドの使い方：予測文との役割分担

予測文は「壇上で何を言うか」に答える。本稿は「今週どの JSON をリポジトリへ書くか」に答える。2026 年の軌跡は同じだが、読者の動作は違う。前者は基調講演の照合、後者は schemas/ ディレクトリの凍結。予測のために製品を書き直すな。DevDay がゼロから API 面を発明することは稀だ。プレビュー、Beta、企業ホワイトリストを既定製品へ畳むことの方が多い。

先に「既に事実」と「発表され得るもの」を分ける。既に事実：Responses は Agent 能力の主経路。Structured Outputs は text.format.json_schema + strict で最終オブジェクトを固定する。関数ツールとリモート MCP は同一の responses.create に掛けられる。MCP は既定で承認を求め（mcp_approval_request）、require_approval / allowed_tools で狭められる。これは予測ではない。発表され得るのは、終了日、GA 化、セルフサービスのスイッチ、「2 つの Schema は同源」と宣言する公式手段だ。

有用な読み方は「GPT-5.7 は出るか」ではない。どのリクエスト面が唯一の推奨経路と宣言されるか。どの JSON Schema がモデルの提案からプラットフォーム強制へ転じるか。どの層のセッション状態が自前のデータベースから公式 Conversations へ移るか。対照は次のとおり。

Responses API：一本化され得るリクエスト面

Assistants は既に死んだ。Chat Completions は生きているが、2026 年の新能力はほぼそちらへは載らない。リモート MCP、Tool Search、Computer Use、Skills、hosted shell、WebSocket Responses、phase（commentary / final_answer）はすべて Responses に掛かる。再利用 Prompt は Chat Completions に入ったことがない。好みの問題ではない。プラットフォームが「Agent ができる面」を一本に畳んでいる。Assistant / Thread / Run からのオブジェクト移行は Assistants → Responses 移行 を見よ。

DevDay が最も切りそうなのは「Responses パラメータを一つ足す」ではない。次の三つのうちいくつかだ。Chat Completions に明確な凍結日または終了日を付ける。Conversations をテキスト Responses と Realtime を跨ぐ統一セッション原語にする。画像、文字起こし、動画をより多く組み込み tool として同一の output item 時系列へ書く。あなたにとっての意味はこうだ。新しいラッパーは input / output item、tools[]、text.format、previous_response_id または conversation だけを認める。tools[] の形を二系統で持つな。

リクエストメタデータも一本化される。Fast は既に Priority を置き換え、Ultrafast はなお限定プレビュー。service_tier、prompt_cache_retention、safety_identifier は今から明示フィールドに書け。SDK の既定値に埋めるな。基調講演のあと、請求、キャッシュヒット、安全ブロックを突き合わせるのはこれらのキーであり、モデル名ではない。下の骨格は今日合法で、DevDay 後もほぼ合法のままだ。関数ツール、リモート MCP、Structured Output は同一の responses.create を通る。

{
  "model": "gpt-5.6-sol",
  "input": "Extract the paid invoice and call billing tools",
  "tools": [
    {
      "type": "function",
      "name": "searchInvoices",
      "strict": true,
      "parameters": {
        "type": "object",
        "properties": {
          "invoiceId": { "type": "string" },
          "status": {
            "type": "string",
            "enum": ["draft", "sent", "paid", "void"]
          }
        },
        "required": ["invoiceId", "status"],
        "additionalProperties": false
      }
    },
    {
      "type": "mcp",
      "server_label": "billing",
      "server_url": "https://mcp.example.com",
      "allowed_tools": ["searchInvoices", "createCreditNote"],
      "require_approval": "never"
    }
  ],
  "text": {
    "format": {
      "type": "json_schema",
      "name": "invoice_result",
      "strict": true,
      "schema": {
        "type": "object",
        "properties": {
          "invoiceId": { "type": "string" },
          "total": { "type": "number" },
          "currency": { "type": "string", "enum": ["USD", "CNY", "EUR"] },
          "status": { "type": "string", "enum": ["paid", "open"] }
        },
        "required": ["invoiceId", "total", "currency", "status"],
        "additionalProperties": false
      }
    }
  },
  "service_tier": "fast",
  "safety_identifier": "billing-user-42"
}

Structured Outputs：形、ストリーミング、同源 Schema

今日の Structured Outputs は最終オブジェクトを固定できる。Responses では text.format に置き、規則は Chat Completions の response_format と同じで、外側のフィールド名だけが違う。公式の売りは型安全、検出できる拒否、「必ず JSON を出せ」というプロンプト依存の削減だ。売らないのは意味だ。形を固定しても業務意味は固定しない。途中切れのストリーム文字列、$ref の黙った欠落、巨大 Schema、動的列挙は、2026 年のつなぎ込みでなお最多の落とし穴だ。サイト内 Structured Output チュートリアル と AI 生成 JSON エラーガイド は同じ一文を書いた。プラットフォームは括弧の対応を保証する。請求合計が正しいことは保証しない。

DevDay が「話しそう」な開発者の痛みは、この三点だ。① ストリーミング Structured Output。増分は合法な部分オブジェクトまたは JSON Patch であり、欠けた文字列ではない。② Tool Schema と Output Schema を同源と宣言できる。ほぼ同じファイルを手で二系統持たない。③ より欠けの少ない JSON Schema 部分集合。oneOf / $ref の黙った欠落を減らす。確率は Completions 一本化より低い。だが発表された瞬間、ストリームパーサと Schema ディレクトリが名指しされる。

今できることは壇上と無関係だ。schemas/output/ と schemas/tools/ を分ける。各出力 Schema は Draft 2020-12、strict + additionalProperties: false、required を書き切る。同じファイルをプラットフォームとローカル検証器に食わせる。プラットフォームエラーとローカルエラーが食い違うなら、先に二枚の Schema を Diff し、それからモデルを疑え。ユーザまたは下流へ渡す最終答えは、checkpoint とも MCP arguments ともファイルを共用するな——AI Agent State を見よ。

Tool Calling：プログラマブル呼び出しと多 Agent

2026 年のツール呼び出しは、もう「モデルが関数を一つ選び、あなたが一度走らせ、文字列を戻す」ではない。7 月 9 日、GPT-5.6 は Programmatic Tool Calling、明示的な Prompt Cache、persisted reasoning、Multi-agent orchestration（Beta）を Responses に書いた。意味はこうだ。モデルはプログラム構造に沿って連続してツールを呼べ、子 Agent を一等オブジェクトとして扱える。Beta の典型的な運命は、DevDay で免責を外し、SLA と上限を足すことだ。

GA になれば、編成器は境界を引き直す。どの hop をプラットフォーム orchestration に渡し、どれを自前ループに残すか。JSON に新しい家族が出る——子 Agent の中間 artifact。最終 Structured Output や MCP arguments と同じ schema ファイルへ押し込むな。各ツールログには今から correlationId / runId / callId を打て。GA のあとで突合できる。関数ツールの arguments はなお JSON 文字列であることが多い。実行前に JSON.parse + Schema は必須で、MCP tools/call と同種の問題だ。

Tool Search、Skills、hosted shell は既に Responses にしか掛からない。DevDay が「先にツールを検索してから呼ぶ」を既定にすれば、80 個の関数を一度に tools[] へ詰めたことを後悔する。先に領域でツールパックを分け、allowed_tools 式のホワイトリストは関数ツール側でも先に使え。引数 Schema は小さく、列挙は短く、additionalProperties は禁止。詳細は MCP と JSON Schema。

MCP：リモートツール、承認、Connector

GPT-5.5 以降、Responses はリモート MCP を掛けられる。モデルは先に mcp_list_tools を出し、どれを呼ぶかを決める。コンソールには OpenAI が保守する Connector がある。5 月 19 日の Secure MCP Tunnel は ChatGPT、Codex、Responses、AgentKit を顧客側 tunnel-client 経由で社内網へ届ける。いまは企業開通に寄っている。既定動作を覚えよ。プラットフォームはデータをリモート側へ渡す前に承認を求め、出力に mcp_approval_request が出る。信頼したあと、require_approval を一部ツールまたは never にできる。ツールが多いときは allowed_tools を使え。でなければ list だけで文脈を焼く。

隙間ははっきりしている。普通のプロジェクトはなおワンクリックでプライベート MCP を掛けられない。Connector カタログも自前ツールを覆わない。予測文は「Hosted MCP / Connector のセルフサービス化、Tunnel をプロジェクトスイッチへ下ろす」を高確率とした。本ガイドが求めるのは確率と無関係な一事だ。MCP Tool.inputSchema とモデル tools[].parameters は同源。ラッパーのフィールド名は違ってよい。プロパティ、必須、列挙は同一のソースファイルから生成せよ。プラットフォームは Server の実行時検証を代行しない。検証鎖はなお parse → Schema → 業務規則。リモート MCP 自体はステートレス JSON-RPC であり、業務の機位は Server にない——Stateless MCP を見よ。

A2A と混ぜるな。MCP はモデルがツールを呼ぶこと。A2A は Agent の横委託であり、タスクは独自のライフサイクルと artifacts を持つ。OpenAI は既にモデル層で MCP を食っている。横委託はなお穴だ。DevDay が AAIF / A2A に一言触れても、それは相互運用であり、Agent Card と inputSchema を一つのオブジェクトに書く理由にはならない。対照は A2A vs MCP。プライベートツールの arguments と MCP params.arguments が合わないときは、生成連鎖を Diff せよ。モデルの「気まぐれ」ではない。

先に凍結する 6 つの JSON Schema

巨大 JSON 一つで済ませるな。読み手でファイルを分けよ。モデルは出力の形を見、ランタイムはツール引数を見、MCP Server は inputSchema を見、編成器はセッション item と子 Agent 産物を見、台帳は usage を見る。6 枚で DevDay が最も触れそうな面を覆える。ソースは Draft 2020-12。OpenAI ラッパー（text.format / parameters）を生成するときは包装だけを足し、プロパティは変えるな。

リポジトリに索引を一つ置け。どの二枚が同源か、どれが包装だけかを宣言する。索引自体も普通の JSON で、レビューと Diff がしやすい：

{
  "schemaVersion": "1.0",
  "pack": "devday-2026-prep",
  "files": [
    {
      "id": "so.invoice_result",
      "path": "schemas/output/invoice_result.json"
    },
    {
      "id": "fn.searchInvoices.parameters",
      "path": "schemas/tools/searchInvoices.json"
    },
    {
      "id": "mcp.searchInvoices.inputSchema",
      "path": "schemas/mcp/searchInvoices.json",
      "sameOriginAs": "fn.searchInvoices.parameters"
    },
    {
      "id": "conv.item",
      "path": "schemas/session/conversation-item.json"
    },
    {
      "id": "agent.artifact",
      "path": "schemas/agent/child-artifact.json"
    },
    {
      "id": "obs.usage",
      "path": "schemas/obs/usage-record.json"
    }
  ]
}

つなぎ込みの順は常に三歩だ。モデルが DevDay で「賢く」なっても関係ない。parse → Schema → 業務規則。途中切れ JSON、Schema エラー、MCP arguments の漂い、それぞれ実失敗サンプルを一つ残せ。講演当日は新しい振る舞いをそれに照合する。SNS 要約でフィールドを当てるな。

ブラウザで完結できる：JSON フォーマッタで parse を見、JSON Schema 検証で output と tools を見、JSON Diffでモデル arguments と MCP params.arguments を比べる。データは本機を出ない。

関連：DevDay 10 件の予測、Assistants → Responses 移行、Structured Output、MCP と JSON Schema、Stateless MCP、A2A vs MCP。

よくある質問

まとめと次の一手

DevDay 2026 で開発者に本当に効くのは、モデル名を一つ覚えることではない。プラットフォームが Responses、Structured Outputs、Tool Calling、MCP を既定スタックへ畳むかどうかだ。4 本は同じ一事を指す。並行 API を減らし、守るべき JSON 契約を一枚増やす。

9 月 29 日までに、Completions の新規コードを止め、6 枚の Schema を分け、失敗サンプルを残せ。講演当日は changelog を照合せよ。要約投稿ではない。応答の形を確かめるときは JSONVue を開けば足りる。