2025年10月6日、OpenAIは計算基盤、ChatGPT内のアプリ、エージェント開発、コーディング支援に関する4件の発表を行いました。
4件は対象が異なりますが、計算資源から利用者との接点、開発と運用までを広く扱っている点でつながっています。この記事では、発表当時に示された内容と、組織が導入を検討するときの確認事項を分けて整理します。
4件の発表を先に整理
| 発表 | 発表時点の要点 | 導入判断で見る点 |
|---|---|---|
| AMDとの契約 | 複数年、複数世代にわたり、合計6GW規模のAMD GPUを導入する計画 | 計画と稼働実績を分け、対応環境と移行条件を確認する |
| Apps in ChatGPT | 会話の中から外部サービスの機能を呼び出せるアプリと、開発用SDKを公開 | 共有データ、権限、利用者の同意、実行できる操作を確認する |
| AgentKit | エージェントの設計、会話画面、接続管理、評価を支えるツール群を発表 | 後日の提供方針変更を踏まえ、現在選べる開発経路を確認する |
| Codexの一般提供 | Slack連携、SDK、管理機能を加え、チーム利用を拡張 | 任せる作業、権限、テスト、レビューと承認の境界を決める |
AMDとの6GW契約が示した計算基盤の拡張
OpenAIとAMDは、複数年、複数世代にわたる戦略的な契約を発表しました。契約では、OpenAIが合計6GW規模のAMD GPUを導入し、最初の1GW分はAMD Instinct MI450シリーズを使って2026年後半に導入を始める計画とされています。
GW(ギガワット)は電力規模を表す単位です。この数字はGPUの枚数や処理速度そのものではありません。したがって、「6GWだから特定の性能が得られる」とは判断できず、設備の導入時期、利用するGPU、ソフトウェアの対応状況を別々に見る必要があります。
この発表から直接確認できるのは、AMDを大規模な計算基盤の協力先に加える計画です。供給リスクや価格がどこまで改善するかは、契約の数字だけでは確定しません。自社の調達判断では、次の点を確認すると計画を具体化しやすくなります。
- 学習、推論、画像、音声など、どの処理をどの環境で動かすのか
- 特定のGPUや開発環境に依存している処理がないか
- 性能、費用、供給時期を同じ条件で比較できるか
- 移行前後で品質を比較する評価項目が決まっているか
Apps in ChatGPTが変えた外部サービスとの接点
Apps in ChatGPTは、会話の途中で外部サービスの機能を呼び出し、結果を地図、一覧、プレイリストなどの画面で扱える仕組みとして発表されました。利用者が会話を別の画面へ移し替える手間を減らし、質問から操作までを一つの流れにできます。
発表時の提供例にはBooking.com、Canva、Coursera、Expedia、Figma、Spotify、Zillowが含まれていました。たとえば、Spotifyに用途を伝えてプレイリストを作る、Zillowの物件情報を地図で絞り込む、といった使い方です。
開発者向けのApps SDKはプレビューとして公開されました。これは、ChatGPTと外部のツールやデータをつなぐMCP(Model Context Protocol)の考え方を土台に、アプリの処理と画面を定義できるようにしたものです。
接続前に決めたいデータと権限
会話内で操作できることと、安全に業務へ組み込めることは同じではありません。接続時にどの情報が外部サービスへ共有されるのか、誰がどの操作を実行できるのか、誤操作をどこで止めるのかを先に決める必要があります。
- データ:入力文、添付情報、会話の文脈のうち、何を共有するか
- 権限:検索だけを許すのか、予約、更新、送信まで許すのか
- 同意:利用者が接続先と共有範囲を理解できる表示になっているか
- 記録:実行した操作と承認した人を後から確認できるか
AgentKitがまとめた設計、画面、接続、評価
AIエージェントは、モデルの回答だけで終わらず、ツールの選択や処理の実行までを進める仕組みです。基本的な構成はAIエージェントとモデルの役割の違いで詳しく整理しています。
AgentKitは、こうしたエージェントの開発に必要な作業を支えるツール群として発表されました。発表時の主な構成は次のとおりです。
- Agent Builder:処理の流れを視覚的に組み立て、版を管理するキャンバス
- ChatKit:会話画面を製品に組み込むためのツールキット
- Connector Registry:管理者がデータやツールへの接続を管理する仕組み
- Evals:データセットや実行履歴を使い、応答や処理を評価する機能
- RFT:評価基準に沿ってモデルの振る舞いを調整する強化学習ベースの微調整
安全策としては、個人を識別できる情報の検出やマスキング、意図しない指示への対策を、設計と評価の両方に組み込む考え方が示されました。ただし、安全策を有効にしただけで運用品質が保証されるわけではありません。失敗例を含む評価データ、停止条件、人への引き継ぎを合わせて設計する必要があります。
Codexの一般提供で増えたチーム向けの選択肢
Codexは2025年10月6日に一般提供となり、Slack連携、Codex SDK、管理者向け機能が発表されました。Slackではチャンネルやスレッドから作業を依頼し、Codex cloudで完了した作業へのリンクを受け取る流れが示されました。SDKは、Codexを自社の開発工程やアプリへ組み込むための手段です。
管理機能では、Codex cloudの環境管理、ローカル利用の設定、操作の監視、利用状況の分析が案内されました。これは、開発者個人の補助からチーム運用へ対象が広がったことを示します。
ただし、導入効果はツールを追加しただけでは決まりません。調査、修正、テスト、レビュー準備のうち何を任せるかを分け、完了条件と承認者を決める必要があります。現在の使い方は、OpenAI Codexの始め方と安全な運用手順も参考になります。
4件の発表を導入判断に変える手順
- 解決する業務を一つに絞る。「生産性を上げる」ではなく、「問い合わせを分類して担当者へ渡す」「小規模な修正案を作りテストする」のように、開始と終了が分かる作業を選びます。
- 入力データと実行権限を分ける。閲覧できる情報、外部へ送信できる情報、更新や購入などの操作権限を一覧にします。
- 正解例と失敗例で評価する。平均的な例だけでなく、情報不足、曖昧な依頼、権限外の操作も試し、止まるべき場面で止まるかを確認します。
- 人が確認する地点を決める。外部送信、データ更新、コードの統合など、影響が残る操作の前に承認を置きます。
- 小さく試してから対象を広げる。一つの業務で品質、時間、費用、修正量を記録し、続ける条件を満たした場合に範囲を広げます。
2025年10月6日の発表から得られる判断軸
4件の発表は、計算基盤、会話内の操作、エージェント開発、コーディング支援という異なる層を扱っていました。発表の規模や新しさだけで導入を決めるのではなく、現在も利用できる機能か、自社のデータと権限に合うか、品質をどう確かめるかを順に確認する必要があります。
実務では、公式情報の更新を確認し、対象業務を一つに絞り、評価と承認を含む小規模な試行から始めるのが現実的です。特にAgentKitのように提供方針が変わった製品では、発表当時の説明と現在の選択肢を分けて読むことが欠かせません。
参考リンク
- OpenAI公式ニュース
- OpenAIとAMDの6GW契約に関する公式発表
- AMDによる同契約の公式発表
- Apps in ChatGPTとApps SDKの公式発表
- AgentKitの公式発表と2026年の提供方針追記
- Codex一般提供の公式発表
- AMDとOpenAIの契約に関するThe Vergeの補足報道
- AMDとOpenAIの契約に関するBloombergの補足報道

