2026年10月20日、OpenAI DevDay[Exchange(Tokyo)] に参加しました。

セッションは先日サンフランシスコで開催された DevDay の内容を振り返るものが中心で、英語と日本語が半々くらい。 デモブースでは開発チームに個別の質問をする機会もありました。

今回はその中から普段の開発や運用に持ち帰れそうな話をまとめます。 複数のエージェントへの仕事の渡し方から音声による操作、脆弱性対応、既存システムの移行まで、扱う対象はさまざまでした。中でも脆弱性対応やシステム移行の事例からは、任せる作業とその結果を確かめる方法を合わせて考える大切さを感じました。

ループエンジニアリングのその先へ

このセッションでは Ralph loop から /goal 、そして複数エージェントの協業へと、エージェントに任せられるタスクが長時間・大規模化してきた、という経緯についてご説明いただきました。 これに対応するため GPT-6 についてはコンテキストの圧縮やマルチエージェントの扱いも含めて学習しているとのことでした。

セッションでは複数のエージェントを協調させるプロンプトの例も紹介されていました。長時間の作業を任せる際の指示の組み立て方を考える材料になりました。

実務で試すなら、どのエージェントに何を任せるかに加えて途中で分かったことや未解決の問題をどう共有するかまで考えたいところです。 例えば調査結果を次の実装担当に渡すなら、結論だけでなく根拠や未確認の点も残してほしい。 そうした情報の受け渡しまで含めて仕事の任せ方を設計したいと感じました。

GPT-Live と画像生成を用いた音声エージェント開発

こちらは GPT-Live で作ったエージェントと対話しながら進めるデモセッションでした。

GPT-Live が音声での指示を受け取り、操作が必要かどうかを Decisions API が判定し、その結果をもとにアプリケーションが実際の処理を行うという構成です。 会話を受け持つ部分と処理を実行する部分の組み合わせ方を、実際の動きとともに見られたのが興味深かったです。

思うように進まない場面もあり、見ている側も少しハラハラしました。その場で対話しながら進めていたからこそ、音声を操作の入口にする体験を具体的に想像できました。

アプリケーションに取り入れる際は、会話の自然さに加えてエージェントが判断しやすい決定論的なツール群の設計、そしてツール実行結果の返し・見せ方が大切になりそうです。 うまくいかなかったときも利用者が状況を理解してやり直せるように設計する必要があると感じました。

カスタマー事例：脆弱性への対応をどう速くするか

GenerativeX 様の事例では利用中のソフトウェアのバージョンと脆弱性データベースを定期的に照合し、対応につなげる取り組みが紹介されました。

Next.js の重大な脆弱性に対応した際は深夜に AI が検知し、人間が WAF で全通信を遮断することを決断。その後はエージェントによる修正を人間が確認し、対応を完了したというお話でした。 ここで印象に残ったのは、修正コードを作る速さに加えて人とエージェントの役割を分けた運用が組まれていたことです。検知や修正をエージェントが担い、通信を遮断する判断や修正内容の確認は人が行っていました。

今回紹介された対応では人間が遮断を判断しています。一方で講演では今後さらに自律的に対応する仕組みの必要性も語られていました。

Acsim でもお客様の情報を預かっているので、自分たちの運用に引き寄せて考えさせられる事例でした。 検知から修正案の作成、検証、反映に至るまで、機械が実行する範囲と人が判断する箇所を見直し、より安心してご利用いただける環境を AI と協力して強固にしていきたいと考えております。

デモブースで聞いた既存システムの移行と評価

モダナイゼーション：移行作業に入る前に Eval を用意する

既存システムのモダナイゼーションについて展示していたブースでは OpenAI 様の FDE の方から COBOL から Java へのモダナイゼーション事例を伺うことができました。 特に面白かったのは、ブラウザから操作できる独自の「移行ワークベンチ」です。 依存関係や機能ごとのまとまりを確認し、そこから Codex Cloud に並列で作業を指示して進捗を追えるというご説明でした。

まず既存のソースコードを解析し、作業が無事に完了したかを判断する Eval を用意します。 その後はシステムの規模や予算に応じてモデルを試し、計測したうえで実際の移行作業に進む流れだと聞きました。

既存システムの移行ではコードが生成されてビルドが通っても、元の業務を引き継げたかは分かりません。 依存関係を理解し、どの機能を一緒に扱うかを決め、移行前後をどう比較するかを考える。この準備ができて初めて並列実行の規模を大きくしていけるのだと思います。

Acsim においては Acsim リバースエンジニアリング、Acsim テスト を併せてご利用いただくことにより、同様の考え方に基づいたモダナイゼーションを行うことができます。 より一層 Acsim の各サービスの連携も強化していきたいと考えておりますので、ぜひご検討いただけますと幸いです。

AWS：Bedrock について

AWS 様のブースでは Amazon Bedrock の API の選び方や利用枠の相談をさせていただきました。 Acsim では現在 LLM 実行基盤として Amazon Bedrock を活用させていただいております。

個別の構成について質問できるのは、こうしたイベントのありがたいところです。 モデルを使えることに加えてアプリケーションが必要とする API の機能や利用量まで含めて確認する機会になりました。

リーダーシップ Q&A で感じた専門性と判断力の大切さ

最後は OpenAI で Applied AI Engineering を統括する Bonnie Chatterjee 様と Developer Experience を担当する Corey Ching 様によるリーダーシップ Q&A でした。 印象に残ったのは、好奇心を持って自分のドメインに取り組み、判断力を身につけていくことが大切だという話です。

エージェントに任せられる作業が増えても、解決したい課題や結果の適切さを考えるための知識は必要です。 その知識をタスクの分け方や評価の条件、実行できる手順に落とし込むことが実務で重要になっていくのだと思います。

今回のイベントは、日々使っている AI を実務でどう活かすかを改めて考える機会になりました。会場で得たヒントを Acsim の開発・運用でも試しながら、お客様の課題解決につなげていきたいと思います。

登壇者の皆様とブースで質問に答えてくださった皆様、そしてイベントを運営してくださった皆様、ありがとうございました。