AIREITEROpenAI DevDay 2026は、単なる新モデル発表の場ではなかった。OpenAIが9月29日に公開した総括では、低コストな実用モデル、マネージド型のエージェント実行基盤、クラウド上のコーディング環境、常時稼働するコンシューマー向けエージェントがひとつの方向性として示されている。開発者にとって本質的な変化は、モデルそのものよりも、その周辺にあるセッション、ツール、実行環境、バックグラウンド処理までがOpenAIのマネージド製品へ移りつつあることだ。
開発者目線での結論
短期的に最も分かりやすいAPIの選択肢はGPT-6.1 Solだ。OpenAIはモデル名をgpt-6.1-solとしており、Responses API、ツール呼び出し、computer use、MCPに対応する。Agents APIは、マネージドなCodex型エージェントを構築するためのパブリックベータだ。Codex Cloudは、非同期のコーディング作業をホスト型のワークフローに変える。Dotsは同じ方向性を示すコンシューマー向けの実例だが、開発者向けAPIの代わりになるものではない。
実際の導入では、まずSolとAgents APIを試し、リモート実行によって調整コストを減らせる場面ではCodex Cloudを使うのがよい。Dotsについては、安定した連携先というより製品の方向性を示すシグナルとして捉えたい。
正式に始まったものと、まだ展開中のもの
OpenAIの公式DevDay総括では20を超える発表が紹介された。ただし、開発者にとって重要な4つの項目は、提供状況がそれぞれ異なる。
| 発表 | できること | 開発者が前提にすべき提供状況 |
|---|---|---|
| GPT-6.1 Sol | コーディング、computer use、専門業務向けの低コストモデル | gpt-6.1-solとしてAPIで利用可能。プランや製品によって利用範囲は異なる |
| Agents API | ツール、セッション、オーケストレーション、ホスト型computer useを備えたマネージドCodexハーネス | パブリックベータ |
| Codex Cloud | 委任したコーディング作業に使える、リモートで再利用可能な開発環境 | 段階的に製品へ展開中。制限や連携機能は環境によって異なる |
| Dots | クラウドコンピューターと接続アプリを備えた常時稼働エージェント | ベータ／段階的な展開。プランや市場による制限がある |
APIの利用可否を確認する際は、OpenAIのモデルドキュメントを見るのが確実だ。Agents APIについては発表ページにパブリックベータであることが明記されている。ただし、どちらのページも、すべてのアカウントで同じクォータや地域提供が保証されるという意味ではない。
GPT-6.1 Solがエージェントの実行コストを変える
OpenAIのGPT-6.1 Solの発表によると、SolはGPT-6 Solを強化したモデルで、コーディングとcomputer useではAstraに近い性能を、より低い運用コストで実現するという。RuntimeWireの報道によれば、OpenAIが公開した料金は入力100万トークンあたり$2、キャッシュ済み入力100万トークンあたり$0.10、出力100万トークンあたり$10だ。アプリケーション側で毎回コンテキストを送り直すのではなく、キャッシュ済み入力を再利用できれば、繰り返し利用するコンテキストのコストを大きく抑えられる。
| 料金項目 | DevDayで報告されたGPT-6.1 Solの価格 |
|---|---|
| 入力 | $2 / 100万トークン |
| キャッシュ済み入力 | $0.10 / 100万トークン |
| 出力 | $10 / 100万トークン |
この価格体系は、長い指示、ツールの実行履歴、プロジェクトのコンテキストを繰り返し使うエージェントワークフローと相性がよい。ただし、どの作業でも安くなるわけではない。出力が多い処理、リトライ、ブラウザー操作、外部ツールの利用料がコストの大半を占めることもある。OpenAIの「Astraに近い」という位置づけは定性的な主張であり、自分のリポジトリ、ツールスキーマ、許容できる失敗コストで検証する代わりにはならない。
最初の検証としては、代表的なタスクを20–50件選び、Solと現在の本番モデルの両方で実行するとよい。成功率、ツール呼び出しの修正率、レイテンシ、総トークン数を記録すれば、オーケストレーションにかかる実コストを含めてもトークン単価の低さが効くのか判断できる。
Agents API：モデル呼び出しから実行基盤へ
今回の開発者向け発表で最も重要なのはAgents APIだ。これは単にモデルを選ぶためのAPIではない。OpenAIが説明するマネージド型のCodexハーネスは、セッション管理、オーケストレーション、コンテキストの圧縮、障害からの復旧を担い、開発者はツールと実行環境を用意する。
パブリックベータの発表や関連報道では、コード実行、ファイル編集、MCP接続、別エージェントへの委任、OpenAIがホストするブラウザー経由のcomputer useが紹介されている。対象は、大きなシステムプロンプトを付けたresponses.create呼び出しではなく、エージェントを動かすランタイムそのものだ。
一方で、認証、業務上の権限、ツール設計、承認ポリシー、オブザーバビリティ、ドメインの許可リスト、機密操作の確認、監査ログ、再現可能な失敗ケースは、引き続きアプリケーション側の責任になる。ホスト型のcomputer useによってブラウザー基盤の運用は軽くできても、こうした統制まで不要になるわけではない。
「Sol 6.1とOpus 5.5の性能比較について、何か情報はありますか？」 — r/codexでの議論に投稿されたu/Ashamed-Subject-8573の質問
この疑問は、基調講演のメッセージと本番導入の間にある差をよく表している。開発者が必要としているのは、見出しになる比較結果だけではない。自分のワークロードでのモデルの挙動、ツールの信頼性、実際のコストが重要だ。Agents APIは評価すべきベータ版の実行基盤として扱い、すべてのエージェント処理をOpenAIのマネージドスタックへ移す根拠だとは考えないほうがよい。
Codex Cloudで実行環境まで製品になる
Codex Cloudは、コーディングエージェントを開発者が操作しているターミナルの外へ広げる。発表報道によると、プロジェクトのリポジトリ、依存関係、ツール、アクセス設定を含む再利用可能な環境を用意できる。タスクはデスクトップ、Web、モバイルからリモートで実行でき、ノートパソコンを閉じたあとに作業へ戻ることも可能だ。
実務上のインパクトは次のとおりだ。
- 長時間の処理を非同期で進められる。コードレビュー、テスト修正、マイグレーションなどを、ローカルのセッションを開いたままにせず進められる。
- 環境構築を共有できる。タスクのたびに依存関係を作り直すのではなく、承認済みのワークスペースをチームで定義できる。
- 人とエージェントの引き継ぎがスムーズになる。開発者は差分を確認し、セッションを再開し、マージする内容を判断できる。
- セキュリティがデプロイ時の課題になる。リポジトリへのアクセス、シークレット、ネットワークの外向き通信、クラウドIDには明確なポリシーが必要だ。
OpenAIのDevDay総括と、同じ製品一覧では、Codex CLIのエージェント画面、音声操作、デスクトップでのコードレビュー、接続したGitHubリポジトリ向けのCodex Security Cloudも紹介されている。こうした機能によって、Codexは単なるコード補完ではなく、リモートのエンジニアリング運用レイヤーに近づいている。
ただし、Codex Cloudがローカルの開発環境をそのまま置き換えるわけではない。リポジトリの対応状況、依存関係のインストール、ネットワークアクセス、シークレットの扱い、セッションの継続時間、失敗したタスクから再現可能なワークスペースを残せるかを確認する必要がある。まずは、本番マイグレーションやリリースに直結する変更ではなく、リスクの低い保守作業から始めたい。
Dotsは開発者向けAPIではなく、コンシューマー向けの到達点
Dotsが示しているのは、OpenAIがエージェント製品をどこへ進めようとしているかだ。クラウドコンピューター、接続アプリ、継続的なコンテキスト、バックグラウンド処理を備えた常時稼働のアシスタントである。OpenAIのDots発表とワークスペースのドキュメントでは、接続サービスと制御されたアクセスが説明されている。さらに関連報道では、対象となるプランや市場でChatGPT、Slack、Microsoft Teams経由の利用が紹介されている。
開発者にとってDotsは、逐次的なプロンプト入力から処理の委任へ向かう流れを示す一方、自律性とプライバシーについてはまだ検討すべき点が残る。OpenAIのワークスペース向けドキュメントでは、アクセスがワークスペースとプランの設定によって管理されることが確認できる。関連報道では、対象市場でChatGPT、Slack、Microsoft Teams経由の利用が示されている。Dotsは開発者向けの契約面ではない。ホスト型エージェントを選ぶ前に、Agents APIと比べて制御性、データの保管場所、ツール権限、監査可能性、乗り換えコストを確認したい。
エンジニアリングチームのための現実的な導入順序
今回の4つの発表は、次の順番で評価すると整理しやすい。
- 実際の作業でGPT-6.1 Solをベンチマークする。リポジトリ上のタスク、構造化されたツール呼び出し、代表的なコンテキストを使う。コストモデルには、入力キャッシュを前提にした場合の影響も含める。
- Agents APIで狭い範囲のワークフローをひとつ作る。課題の振り分け、テストの原因調査、ドキュメント更新など、やり直しのきくタスクを選ぶ。権限を広げる前に承認ゲートを追加する。
- 非同期のコーディングを必要な範囲だけCodex Cloudへ移す。まずは機密情報を含まないリポジトリで再利用可能な環境を試し、その後にシークレットとネットワークの制御を文書化する。
- Dotsは製品リサーチのシグナルとして見る。権限、連携機能、提供状況を追いかける。ただし、アプリケーションのアーキテクチャがDotsに依存する設計にはしない。
- 移植性を確保する。プレビュ―APIで制限や挙動が変わった場合に置き換えられるよう、ツール定義、プロンプト、評価ケース、承認ロジックは自分たちのリポジトリで管理する。
SolにはAPI用のモデルエントリーと公開料金がある。Agents APIは明確にパブリックベータだ。Codex Cloudは運用面に未知の部分が残るホスト型ワークフローであり、Dotsは開発者向けの契約の基盤として最も適していない。
FAQ
GPT-6.1 SolはAPIで利用できますか？
はい。OpenAIの開発者向けモデルページでは、gpt-6.1-solをAPIで利用できるモデルとして掲載しており、Responses APIやツール指向の機能にも対応している。利用可否や制限は、アカウントや展開状況によって異なる場合がある。
Agents APIは一般提供されていますか？
いいえ。OpenAIはAgents APIをパブリックベータとして発表している。本番で取り消しのきかない処理に使う前に、評価、ログ、フォールバック経路を用意しておきたい。
Dotsは開発者が呼び出せるAPIですか？
いいえ。Dotsは独自の展開状況とプラン条件を持つOpenAIのエージェント製品だ。マネージド型エージェントを構築する開発者向けのインターフェースはAgents APIになる。
Codex Cloudがあればローカルの開発環境は不要になりますか？
必ずしもそうではない。Codex Cloudはリモート実行と再利用可能な環境を追加するが、チーム側でリポジトリへのアクセス、依存関係、シークレット、ネットワークポリシー、永続化、レビューのワークフローを検証する必要がある。
本番の作業を移す前に、何を確認すべきですか？
実際に提供されるモデル、リトライやツール呼び出しを含む料金、データの扱い、権限の境界、障害からの復旧、オブザーバビリティ、地域ごとの提供状況、ベータ機能の変更に備えた撤退経路を確認する。
開発者が見落としてはいけないトレードオフ
トレードオフは明快だ。マネージドなセッションやブラウザーを使えばインフラ運用は減る。一方で、ランタイムを自前で管理すれば、データ、認証情報、デバッグ、モデル変更に対するコントロールをより多く維持できる。まずはSolとAgents APIから始め、運用上のメリットがはっきりしている場面に限ってCodex Cloudを使うのがよい。