Article
🔄 Codex Day 18:連日のリセットとDecisions API正式版・Open Responses標準化
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を投稿しました。
投稿は、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全社展開 |
まとめ
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のどれに関するものなのか分けて確認する必要があります。
参考資料・一次情報
- Tibo Sottiaux氏:Day 18公式X投稿
- OpenAI Developer Community:28 days of Shipping at OpenAI
- OpenAI API Changelog(2026年10月22日)
- OpenAI:Build more responsive apps with the Decisions API
- OpenAI公式:Decisions API Guide
- OpenAI公式:Decisions API Reference
- AAIF:新規4プロジェクト発表(Open Responsesを含む)
- Open Responses公式サイト
- AWS:Open Responses Joins AAIF
- OpenAI:UberのChatGPT Work全社展開
- OpenAI:Work / Codexの利用枠とリセット
今後も28日間のアップデートを一次情報で追い、反映済みと未確認を明確に区別して解説していきます。