概要
2026 年 10 月 20 日に開かれた OpenAI DevDay Exchange Tokyo に参加してきました。エージェントの組み方から、声で操作するアプリ、セキュリティの自動化まで、手元の仕事にすぐ効く話が多い一日でした。
この記事では、技術セッションの内容を、あとから公式ドキュメントで確かめ直しながらまとめます。取り上げるのは次の 6 つです。
- マルチエージェントの組み方(Codex のスキル)
- Codex のハーネスと Agents API
- GPT-Live と Decisions API(声から操作へ)
- Codex Security と、「正しい挙動」を先に渡すコツ
- 深夜に公開された Next.js の脆弱性への自動対応の事例
- ChatGPT Sites・プラグイン・MCP
最後に、業務システムや LLM アプリを作る立場として持ち帰ったことを書きます。
料金や提供地域など、公式で確かめられなかった数字は載せていません。使う前に、末尾の公式ドキュメントで最新の状態を確認してください。
1. マルチエージェントは「階層を作らず、横でつなぐ」
Codex で複数のエージェントを動かすときの組み方として、2 つのスキル(決まった手順のひな形)が紹介されました。
協調のスキル(並行のレーンに分ける)
- 独立した作業を、成果の目標と責任範囲がはっきりした「レーン」に分け、サブエージェントに並行して進めさせる
- レーン同士の依存は、親を通さずに関係するエージェントへ直接メッセージして解決させる
- 結果を受けて計画が変わるとき、解決できないときだけ親に報告し、最後に親がまとめて確かめる
マネージャーのスキル(2 人で分担する)
- 2 人に「具体的な成果物・共通の制約・補い合う責任・最初の書き込みの分担」を渡す
- 2 人とも手を動かし、1 人がまとめ役になる。同じファイルを二重に編集しない
- 成果物や守るべき境界、他のレーンの持ち物を変えるときは、人に判断を上げる
作業ログで引き継ぐ
AGENTS.md に「作業ログを 1 つ持つ」ルールを書きます。目標・今の指示・担当・残りの作業・決めたことを 1 か所に記録し、作業を再開する前に必ずログを読ませます。
やってはいけない形
「プロデューサー → テックリード → 承認待ち → 機能リード → 実装・テスト」のように、人の組織図をそのまま写す形です。承認待ちで止まり、各層が文脈を読み直すのでトークンも膨らみます。階層は浅くし、横で直接やり取りさせるのが基本、という話でした。
2. Codex のハーネスが API 1 本で使える(Agents API)
Codex が内部で回している仕組み(ハーネス)は、次のループです。
依頼 → 文脈を組む(指示・設定・履歴・ツールの結果)
→ モデルがツールを呼ぶ → サンドボックスで実行 → 結果を文脈に戻す
→ 長くなったら文脈を圧縮して、また回す
このループを OpenAI 側で回してくれるのが Agents API です。2026 年 9 月 10 日に公開ベータになりました。
| 項目 | 内容 |
|---|---|
| 任せられること | エージェントのループ、長時間のセッション、文脈の管理と圧縮、MCP・ツール・スキル、マルチエージェント |
| 実行環境 | OpenAI が用意するサンドボックス、自前のサンドボックス、外部のサービス(Cloudflare・Daytona・E2B・Modal・Vercel など)から選べる |
| 料金 | Agents API そのものの追加料金はなく、モデル・ツール・コンテナの利用分だけ |
使い分けの目安は、細かく作り込みたいなら Responses API で自前のループを書き、ループは任せてツールと環境だけ決めたいなら Agents API、です。自前でエージェントを作る場合も、このループの形が基準になります。
3. 声で話し、操作は選択肢から選ばせる(GPT-Live × Decisions API)
音声モデルの GPT-Live は会話に専念させ、「どの操作をするか」の判断は Decisions API に任せる、という組み合わせです。
GPT-Live(会話) → Decisions API(操作を選ぶ) → アプリ(確かめてから実行)
GPT-Live から Decisions API に判断を渡す方法は 2 つあります。
| 方式 | 動き |
|---|---|
| ネイティブ委任 | GPT-Live が Decisions API を直接呼ぶ。アプリを往復しないので速い(2026 年 10 月 15 日に追加) |
| カスタム委任 | GPT-Live がアプリに知らせ、アプリが Decisions API を呼ぶ |
設定では、判断させたいことを「選択肢の質問」として定義します。公式ガイドの例を短くすると次の形です。
{
"delegation": {
"type": "decisions",
"decisions": {
"questions": [
{ "type": "choice", "name": "cabin_temperature",
"choices": [{ "value": "temperature_up" }, { "value": "temperature_down" }, { "value": "none" }] }
]
}
}
}
- 結果は、質問の
nameごとの答えとして届く。noneは「何もしない」 - 話している途中の文字起こしをきっかけに判断を走らせることもできる。結果は順不同で届くので、元のイベントの ID で突き合わせる
ここでいちばん大事だと感じたのは、LLM に「何をするか」を自由な文章で書かせず、選択肢を決めて分類させる設計です。速く、安く、結果を確かめやすくなります。実行してよいかの最後の判断はアプリ側に残します。
4. 「脆弱性を探して」ではなく「正しい挙動」を渡す(Codex Security)
Codex Security は、コードの脆弱性を探して、確かめて、直し方まで出してくれる仕組みです。発表で強調されていたのは、頼み方でした。「脆弱性を見て」とだけ頼むのではなく、アプリの正しい挙動を先に書いて渡し、実装がそれを満たしているかを確かめさせます。
頼み方の型
- 見る境界を決める(例: 文書を扱うサービスに、権限の境界を破る箇所がないか)
- データの流れを追わせる(ログインした人の情報が、検索から追跡までどう使われるか)
- 確かめる条件をはっきり書く(読み取るときに「持ち主であること」と「組織に属していること」の両方を確かめているか)
- 出力の形を決める(根拠のコードの場所・影響・直し方。確信度と重大度は分けて出させる)
- スキャンの間はコードを変えさせない
使い方は 4 つ
| 使い方 | 内容 |
|---|---|
| クラウド | GitHub のリポジトリをつないでスキャンし、新しいコミットを見張る(リサーチプレビュー) |
| プラグイン | ChatGPT のデスクトップ版や Codex CLI から、手元のリポジトリを対話しながらスキャンする |
| CLI | @openai/codex-security。GitHub Actions や GitLab CI に組み込める |
| SDK | 自社のツールにスキャンと結果の処理を組み込む |
攻撃する側の能力は上がり続ける前提で、防ぐ側も「見つける・確かめる・直す」を自動で回し続ける、という考え方(Defense Factory)も紹介されていました。
5. 深夜に公開された Next.js の脆弱性に、1 時間 52 分で対応した事例
いちばん具体的だったのが、登壇企業の対応事例です。Next.js の直近 5 回の修正版はすべて日本の深夜に公開されていて、「人が起きていない前提で、見つける → 止める → 直す → 戻す を仕組みにする」という話でした。
10 月 15 日の深夜の動き
| 時刻 | できごと |
|---|---|
| 2:47 | 重大度 Critical の脆弱性 2 件(認証なしでコードを実行される)が公開。1 分以内に検知し、該当するリポジトリ 148 件(うち本番 22 件)を特定 |
| 3:09 | 依存を上げてテストを通した PR が、自動で出始める |
| 3:13 | 外から見える 57 件を WAF でまとめて遮断(判断から 3 分) |
| 4:39 | 更新を終えて遮断を解除。公開から 1 時間 52 分 |
次の目標は、人がやっていた「遮断の判断」を自動にすることです(CVSS 9.0 以上なら、直すより先に止める)。修正は Codex が直してテストを通した PR を出し、人は承認するだけにする、という計画でした。
このとき出た脆弱性(Next.js の公式発表より)
- App Router と Cache Components の組み合わせで、
use cacheの関数が typed array を返すと、認証なしでコードを実行される(Critical。回避策なし) - 画像最適化 API の SVG の処理で、コードを実行される(Critical。sharp を 0.35.5 以上にすれば避けられる)
- Server Actions を使う App Router で、CPU を使い切らせてサービスを止められる(High)
直った版は next@16.4.1(16.4 系)と next@15.5.28(15.5 系)です。上げたあとは、念のため npm ls sharp で sharp が 0.35.5 以上になっているかも確かめておくと安心です。
6. ChatGPT Sites で MCP サーバーを置き、プラグインとして配る
ChatGPT Sites は、Web アプリと MCP サーバーを置いておける場所です。置いた MCP サーバーを、Codex や ChatGPT のプラグインとして配れます。
| 項目 | 内容(発表時点) |
|---|---|
| サイトの運用 | Web アプリを置き、複数のサイトを管理できる |
| ログイン | Sign in with ChatGPT |
| 見せる範囲 | 持ち主・管理者・個別に共有・ワークスペース・一般公開、外部の招待 |
| データ | D1 は 1 サイト 10GB まで、R2 は決まった上限なし |
プラグインの中身は、名前などを書く plugin.json、MCP サーバーへの接続を書く mcp.json、使い方の手順(スキル)、アイコンだけのシンプルな形です。ツールごとに、許可するか・毎回確認するかを決められます。指示を渡すだけで足りるなら、プラグインにせずスキルで十分です。
注意点として、Sites が面倒を見てくれるのは ChatGPT と MCP サーバーの間のログインまでです。どのデータに触れられるかは MCP サーバーの持つ API の権限で決まるので、ツールごとの権限の設計は自分でする必要があります。
自分の案件に持ち帰ること
- 深夜の脆弱性に備える。 脆弱性の公開をきっかけに、依存を上げる PR を自動で作ってテストまで回すところを、CI に用意しておく。手元の Next.js の案件は 16.4.1 / 15.5.28 に上げる
- LLM に操作を選ばせる箇所は、選択肢で設計する。 自由な文章で答えさせず、決めた選択肢から選ばせ、実行の前にアプリで確かめる。取り消しにくい操作の前に確認を挟む、これまでの作り方とも同じ方向です
- セキュリティのレビューは「正しい挙動」から書く。 誰が何を読めてよいか(持ち主か、同じ組織か)を先に書いて渡し、確信度と重大度を分けて出させる
- エージェントには作業ログを 1 つ持たせる。 AGENTS.md や CLAUDE.md に「再開する前にログを読む」ルールを書く。サブエージェントは階層にせず、責任範囲を決めた並行のレーンにする
参考(公式)
- Introducing the Agents API
- Introducing the Agents API and hosted sandboxes(OpenAI Developer Community)
- Introducing GPT-Live
- Connect voice to Decisions
- API Changelog
- Codex Security(ドキュメント)
- openai/codex-security(GitHub)
- Next.js Security Update(2026-10-14)
- Model Context Protocol(ChatGPT)
- Hosting a plugin with ChatGPT Sites
