Article

🔄 Codex Day 18:連日のリセットとDecisions API正式版・Open Responses標準化

codex, openai, api, ai, chatgpt

OpenAI・Codexの28日間アップデート Day 18では、新たな利用枠リセットの予告に加え、Decisions APIの正式提供(GA)、Open ResponsesのLinux Foundation傘下への移管、パフォーマンス改善、UberのChatGPT Work全社展開が発表されました。

日本時間2026年10月23日13時46分頃、Codexを率いるTibo Sottiaux氏がXにDay 18を投稿しました。

Day 18:Tibo氏の公式投稿

投稿は、4つの技術・導入トピックを挙げたうえで、最後に 「But yes… that’s a reset!」 と明言しています。

この記事の調査時点:2026年10月23日(日本時間)。 公式X投稿、OpenAI API Changelog、OpenAI公式ブログ、Agentic AI Foundationの発表、OpenAI Developer Communityを照合しました。リセットの「発表」と「全アカウントへの適用完了」は区別しています。


1. Day 18の発表を一覧で確認

トピック 10月23日時点で確認できる内容 一次情報
Codex / Workリセット 新たに予告、適用完了は未確認 Tibo公式X
Decisions API GA(一般提供)。機能・料金の詳細も公開 OpenAI API Changelog
Open Responses Linux Foundation傘下のAgentic AI Foundationに参加 AAIF公式発表
パフォーマンス改善 複数の改善を出荷したと表明。内訳・改善率は投稿から特定できない Tibo公式X
Uberの導入 ChatGPT Workを3万人超へ展開開始、Codex利用も継続 OpenAI公式発表

Day 18は「リセットだけの日」でも「新機能だけの日」でもなく、改善とリセットの両方を発表した日です。

2. いつリセットされる? 日本時間へ換算

Tibo氏はDay 18の追加投稿で「Landing tomorrow before 10am PST together with a small ship.」と説明しています。これは翌日の米国太平洋時間午前10時より前に、小規模な改善と合わせて反映予定という意味です。

発表記録:Codex Reset Tracker / Day 18を含むOpenAI Developer Communityの公式情報集約

日本時間の目安

米国の2026年10月22日は夏時間中なので、現地で実際に使われているのはPDT(UTC-7)です。ただし投稿はPST(UTC-8)と書いています。

元投稿の「10am」の解釈 現地時刻 日本時間(JST)
現地の実際の時計(PDT)を意図 2026年10月23日10:00 PDT 10月24日02:00
文字どおり標準時(PST)を意図 2026年10月23日10:00 PST 10月24日03:00

したがって、日本時間10月24日午前2〜3時頃が公式予告の換算上の目安です。「before」なので、その時刻より前に反映される予定という意味であり、その時刻ぴったりに全員が更新されるという告知ではありません。

混同に注意:Day 17のリセットは日本時間10月23日午前2〜3時が目安、Day 18は10月24日午前2〜3時が目安です。 連日の異なる告知です。

Day 17:米国10月21日の発表
    └─ 日本時間10月23日午前2〜3時が反映目安

Day 18:米国10月22日の発表
    └─ 日本時間10月24日午前2〜3時が反映目安

「フルリセット」は何の上限?

Tibo氏の28日間企画は、Codex / ChatGPT Workの利用者に向けて「改善またはfull reset」を毎日届けるというものです。今回のDay 18投稿も「reset」と述べています。

ただし、どのプランのどの枠が何%回復するのか、保存型リセット券が追加されるのか、全対象アカウントへの反映が終わったのかまでは、短い投稿だけでは断定できません。

  • 5時間枠:短時間で使える利用量の制限。存在するプランが対象
  • 週間枠:週単位で管理する利用量の制限
  • banked reset(保存型リセット):利用者が保存して手動で使用する特典。自動適用とは別物
  • APIの利用料金・クレジット:Work / Codexのサブスクリプション利用枠とは別の仕組み

自分のアカウントが回復したかどうかは Settings → Usage(設定 → 使用状況)を確認してください。

参考:OpenAI Help:Response speed and usage resets / 保存型リセットの仕組み


3. Decisions APIがGAに:何が便利なのか

Day 18で特に実装への影響が大きいのは、Decisions APIが正式版になったことです。

**GA(General Availability)**は一般提供という意味で、公開ベータ(試験的な一般公開)から正式な提供段階へ移ったことを指します。

OpenAIの変更履歴には2026年10月22日の更新として明記されています。

公式ブログ:Build more responsive apps with the Decisions API / 公式ガイド:Decisions

普通の文章生成APIと何が違う?

たとえば、問い合わせを「請求」「技術サポート」「配送」に振り分けるだけなら、長い文章を生成する必要はありません。

ユーザーからの問い合わせ
         │
         ▼
    Decisions API
         │
         ├─ billing(請求)
         ├─ technical(技術)
         └─ shipping(配送)
         │
         ▼
   バックエンドで次の処理へ

Decisions APIは、制限された答えの候補から素早く判断することに特化しています。GPT-6 Lunaを使い、OpenAIの説明では、同モデルをResponses API経由で使う場合と比較して最大10倍高速とされています。これは全ワークロードで実測10倍を保証する数値ではありません。

3種類の回答形式

種類 意味 例
predicate 条件が真である確率(0〜1) この写真には破損があるか
choice 定義済みの選択肢から1つ選ぶ 請求・技術・配送のどこへ転送するか
score 順序のある段階で評価する 障害の重大度を0〜2で判定する

scoreの値は各段階の確率で重み付けした平均なので、1.1など整数以外にもなり得ます。人間のレビューが必要かどうかは、システム側がしきい値を決めて判断します。

最小APIリクエストの例

以下は「問い合わせをどの担当部署へ回すか」を判定する、公式仕様に沿った最小例です。実行した結果ではなく実装例です。

curl https://api.openai.com/v1/decisions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-luna",
    "input": "クレジットカードで二重請求されました。返金してほしいです。",
    "questions": [
      {
        "type": "choice",
        "name": "department",
        "instructions": "問い合わせを適切な担当部署に分類してください。",
        "choices": [
          {"value": "billing"},
          {"value": "technical"},
          {"value": "other"}
        ]
      }
    ]
  }'

主な要素の意味は次のとおりです。

要素 役割
curl HTTPリクエストを送るコマンド
-H 認証・送信データ形式を表すHTTPヘッダー
$OPENAI_API_KEY 環境変数から読み取るAPIキー。記事やソースコードに秘密の値を直書きしない
-d JSON形式のリクエスト本文を送る指定
model 判断に使うモデル。現時点ではgpt-6-luna
input 判断材料となるテキスト、画像、JSONなど
questions 判定してほしい問い。正式版は1リクエスト最大400問

応答のanswersに結果が入り、choiceでは選ばれた値に加え、選択肢ごとの確率やconfidenceも確認できます。

公式:Create a decision API Reference

公開ベータ版から正式版で何が増えた?

項目 変化
1リクエストの質問数 200問 → 400問
Prompt caching 共通入力の再利用に対応
JSON入力 input_jsonで構造化データを直接渡せる
画像入力 問いごとの画像指示やHTTP(S)画像URLに対応
会話履歴 メッセージやツール結果を判定材料として扱える
GPT-Live 音声会話の途中で判断を呼び出せる
監視 組織単位の使用量集計をサポート
通信 Private Linkなどの企業向け選択肢が追加

注意点として、最大400問に増えたからといって、依存関係のある400の判断を1回で順番に実行できるわけではありません。 先の質問の結果を次に渡す場合は、段階を分ける設計が必要です。

APIの料金

公式価格(2026年10月22日の発表)では次のとおりです。

項目 料金
通常入力 100万トークンあたり $0.10
キャッシュ済み入力 100万トークンあたり $0.01
出力トークン料金 なし

これは/v1/decisionsでの基本的な入力料金です。キャッシュ書き込み、長い入力、地域処理などの条件では適用単価が変わる場合があります。

実務では、分類結果の精度、API往復レイテンシ(応答時間)、コスト、誤分類時の被害を計測し、重要な判断には人間の承認を残す設計が安全です。

Decisions APIが無料になったわけでも、一般ユーザーのCodexの利用枠を増やすAPIになったわけでもありません。 リセットとは別の発表です。


4. Open ResponsesがLinux Foundation傘下へ

OpenAIが貢献したOpen Responsesは、Linux Foundation傘下の**Agentic AI Foundation(AAIF)**に参加しました。

厳密には「Linux FoundationがOpenAIのAPIサーバーを買収した」という意味ではありません。複数モデル提供者が共通して実装できるオープンなAPI仕様を、中立的な団体のガバナンスで開発していくという話です。

Agentic AI Foundation公式リリース(2026年10月22日)

何が標準化される?

LLM(大規模言語モデル)のAPIには、サービスごとにリクエスト、ツール呼び出し、ストリーミングの形式が異なるという課題があります。

従来(概念図)
アプリ ── OpenAI専用形式 ── OpenAI
      ├─ Provider A専用形式 ── Provider A
      └─ Provider B専用形式 ── Provider B

Open Responses(目標)
アプリ ── 共通スキーマ ── 対応プロバイダーA
                       ├─ 対応プロバイダーB
                       └─ 対応プロバイダーC

**スキーマ(schema)**とは、データの構造や許される項目を決めた仕様です。Open Responsesは、メッセージ、ツール実行、途中経過を伝えるストリーミングイベントなどを共通化します。

ただし、すべてのモデル提供者が完全に同じAPI・機能をサポートしたという意味ではありません。 実装ごとに対応範囲の検証が必要です。

AWSは同日付の公式ブログで、Amazon BedrockにおけるResponses API形式の対応と、共通形式によってプロバイダー選択の自由度が高まる意義を説明しています。

Open Responses公式サイト / AWS公式:Open Responses Joins AAIF

MCP、A2Aとの違い

標準・技術 主な役割
Open Responses アプリケーションとLLMのリクエスト・応答形式
MCP AIが外部ツールやデータにアクセスするための共通接続方式
A2A 別々のAIエージェント同士の通信・協調

これらは競合する同一仕様というより、AIエージェント構築の異なる階層を扱います。

今回、AAIFはOpen ResponsesのほかにAgent Skills、OpenEnv、OpenSandboxも新規プロジェクトとして発表しました。


5. UberがChatGPT Workを3万人超へ展開

OpenAIの2026年10月22日付公式発表によると、Uberは最初の1,000人規模の試験導入から拡張し、世界の3万人超の従業員を対象にChatGPT Workの全社展開を開始しました。

OpenAI公式:Uber brings ChatGPT Work to all employees

ChatGPT Workでは、Google Drive、Gmail、Google Calendar、Slackなどのアプリと接続し、資料作成・分析・調査・複数アプリをまたぐ業務を進めることができます。

Uberでは次のような支援とともに導入を進めると説明しています。

  • 社内AIスキルライブラリと承認済みのアプリ連携
  • 従業員向けの専用トレーニング
  • オペレーション、財務、マーケティング、プロダクトなどへの展開
  • ソフトウェア開発チームでは、引き続きCodexを利用

「3万人がすでに毎日アクティブに利用している」と発表したのではなく、「3万人超を対象に展開を開始した」という事実です。導入成果の定量評価は今後共有される予定です。


6. パフォーマンス改善はどこまで確認できる?

Tibo氏はDay 18投稿で、いくつかのパフォーマンス改善が出荷されたと述べています。

しかしこの短い投稿には、Codexのどの処理が何%速くなったか、どのモデル・プランが対象なのかという詳細はありません。そのため、本記事では「推論速度が2倍」「週間使用量が倍増した」といった数値を根拠なく付けていません。

また、上記のDecisions APIの最大10倍高速という説明は、Decisions APIとResponses APIを比較する話です。Codex全体が10倍速くなったという意味ではありません。

こうした数字の対象範囲を分けて読むことが、製品アップデートを正しく理解するうえで重要です。

7. 利用者が今日やること

Codex / Work利用者

Settings → Usageで対象利用枠を確認し、今回の新たなリセットの反映予定にあたる日本時間10月24日午前2〜3時頃を経過した後にもう一度比較してください。公式の発表済み状態と、アカウント固有の回復状況は別です。

バックエンド開発者

短い分類・振り分けが多いシステムではDecisions APIを評価候補にできます。従来のResponses APIをすべて置き換えるものではないので、自由文生成、複雑な推論、JSONの独自スキーマ生成などの用途と区別してください。

エージェント基盤の設計者

将来複数のモデル提供者を使い分けるなら、Open Responsesの仕様と各プロバイダーの対応状況を確認するとよいでしょう。ただし、標準に参加したことと、すべての機能が同等に動くことは違います。


8. 28日間企画の直近3日を比較

Day 米国太平洋時間 主な発表
Day 16 2026年10月20日 APIの12時間キャッシュ、Codex / Workのキャッシュ再利用改善
Day 17 2026年10月21日 利用枠リセット予告、Daybreak Blueへのアクセス案内
Day 18 2026年10月22日 追加リセット予告、Decisions APIのGA、Open Responses移管、性能改善、Uber全社展開

前回:Codex Day 17の詳細記事

まとめ

Day 18の発表は、Codex / Workのリセットをさらに予告しつつ、API開発とAIエージェント標準化にも大きな進展があった日でした。

  • リセット:連日の発表。ただし全アカウントへの反映完了は未確認
  • 反映目安:日本時間10月24日午前2〜3時頃
  • Decisions API GA:gpt-6-lunaによるpredicate・choice・scoreの高速な判定。最大400問、キャッシュ・JSON入力などに対応
  • Open Responses:AAIFへ移管し、マルチプロバイダーのAPI共通化を推進
  • Uber:試験導入1,000人から、3万人超を対象とするChatGPT Work全社展開を開始
  • パフォーマンス改善:出荷の発表はあるが、詳細な対象と改善率は未公表

リセットの「発表」「反映予定」「反映完了」は別々の事実です。 新機能の数字も、Codex、Work、Decisions APIのどれに関するものなのか分けて確認する必要があります。

参考資料・一次情報

今後も28日間のアップデートを一次情報で追い、反映済みと未確認を明確に区別して解説していきます。