※本記事は、OpenAIが公開した動画「The Defender's Window: Cyber security keynote」の内容を基に作成されています。この講演では、OpenAIのセキュリティ専門家が、あらゆる組織にサイバー防御のための「ディフェンス・ファクトリー」が必要な理由と、Daybreakを用いたその構築方法を解説しています。
登壇者は以下の5名です。
- Emanuel Mariel氏（OpenAI 欧州・中東・アフリカ地域ゼネラルマネージャー）
- Matt氏（OpenAI サイバー部門エンジニアリング責任者）
- Lena氏（OpenAI 欧州・中東・アフリカ地域のサイバープログラムをゴー・トゥ・マーケットの立場から統括）
- Vanessa氏（OpenAI サイバー・デプロイメント・エンジニア）
- Lou氏（OpenAI サイバー部門フィールドCTO）
動画の詳細情報は https://www.youtube.com/watch?v=3jDhHA9JGUE でご覧いただけます。本記事では、講演の内容を要約しております。なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。また、OpenAIの公式ウェブサイト（https://openai.com/ ）もあわせてご参照ください。
1. ディフェンダーズ・ウィンドウとエコシステムによる対応（Emanuel Mariel）
1.1 AI能力の急速な進展と、信頼の基盤としての安全性
Emanuel Mariel： 皆さん、ようこそお越しくださいました。今日の午後はご一緒させていただきます。私はEmanuel Marielと申します。OpenAIで欧州・中東・アフリカ地域のゼネラルマネージャーを務めています。私は冒頭の数分間で導入をお話しし、その後はチームのメンバーに引き継ぎます。今日のアジェンダは盛りだくさんで、この後に1時間のセッションがあり、続いていくつかの興味深いファイアサイドチャットを予定しています。最後に私がもう一度登壇して締めくくります。今日の目的は、これから訪れる変化を理解することです。そして互いに学び合い、この部屋に集まった知見を最大限に生かすことです。
私たちはいま、非常に興味深い時代に立ち会っています。ある意味では特権的な瞬間と言ってもよいと思います。AIの能力が目に見えて伸びているからです。ほんの数週間前には、ナビエ–ストークス方程式に関する数学上の難問が解かれました。また私たちはGPT-6 Astraをリリースしました。これはOpenAIがこれまでに出荷した中で最も高性能なモデルです。
科学的な進歩だけではありません。企業でもAI技術の利用が着実に広がっています。たとえばマーケティング用途でCodexを使う週間アクティブユーザーは26%増えました。法務の分野ではおよそ108倍にまで拡大しています。こうした傾向はあらゆる領域で見られます。
具体例を一つ挙げます。今週の火曜日、私はベルリンでStadlerという中堅企業と時間を過ごしました。同社の従業員は650人で、その業務の上で145のエージェントが稼働しています。その結果、30%から40%の効率向上を実現したと報告してくれました。中小企業から大企業まで、規模を問わず企業がこの能力の恩恵を受けています。ChatGPTを毎週利用している人は10億人を超えています。
一方で、能力が高まるほど、私たち全員が抱える大きな問いも浮かび上がります。それは信頼の問題です。突き詰めれば、すべては信頼に行き着くと私は考えています。安全性は、OpenAIにとって常に最優先の課題でした。最近のインシデントを受けて、私たちは安全性にさらに力を入れています。安全性チームは大幅に拡大しました。安全性のための計算資源にも多額の投資をしています。さらに8月の初めには、直近の学習の実行を2週間ほど一時停止しました。こうした取り組みの結果、今日のAstraは、私たちがこれまでに出荷した中で最もアラインメントの取れたモデルになっています。
安全性は信頼に欠かせない要素です。ただ、その中身は立場によって異なります。私たちOpenAIにとって安全性とは、まずモデル自体の安全性です。一方、この部屋にいる皆さん、そして私たち自身も含めた全員にとっては、外の世界における安全性、つまりサイバーセキュリティを意味します。今日ここに集まっているのはそのためです。そして信頼はモデルだけから生まれるものではありません。チームとして、エコシステムとして、このセキュリティの領域で私たちが何をするかによっても築かれていきます。
1.2 「ディフェンダーズ・ウィンドウ」の定義と、経営層・パートナー・政府・OpenAIの役割
Emanuel Mariel： 私はこの2週間、各地を回って非常に多くの顧客とお会いしてきました。そこで強く感じた変化があります。6か月前には、顧客との会話でサイバーセキュリティが話題の中心になることはありませんでした。ところが6日前には、誰もがサイバーセキュリティへの懸念から話を始めるようになっていました。本当に例外なく、全員がそうでした。
世界中でAIが大きな勢いを見せる一方で、新たな脅威も現れつつあります。私たちが「ディフェンダーズ・ウィンドウ」と呼んでいるのは、ある二つの能力の間にある差のことです。一つは、私たちが出荷しているモデルが持つ高い能力です。もう一つは、そのすぐ後ろで急速に追い上げてきているオープンウェイトモデルの能力です。ウィンドウとは、この差がある今の時間を指します。防御者である皆さんが最高の能力を活用できるよう、この間に行動しなければなりません。オープンウェイトモデルはそれほど遠くにいるわけではないからです。皆さんもそれをご存じだからこそ、今日ここにいらっしゃるのだと思います。
実際、150人をお招きして150人全員が来てくださることは、普段はまずありません。今日それが起きたのは、皆さんが懸念を抱いていて、これがエコシステム全体で取り組むべき課題だと認識しているからだと思います。これはOpenAIだけのショーではありませんし、政府だけのショーでもありません。エコシステム全体で取り組むものです。だからこそ私たちは数週間前に公開書簡を発表しました。署名した企業は約100社にのぼり、今日この会場にいらっしゃる企業の多くも名を連ねています。書簡の趣旨は、一つのグループ、一つのエコシステムとして結束し、この問題を解決しなければならないということです。そして、それぞれが果たすべき役割があります。
最初の役割は、企業の経営者である皆さんにあります。サイバーセキュリティを社内の最優先事項に据えることです。その動きはすでに始まっていると感じています。数週間前に米国を訪れたときには、すでに最優先事項になっていました。欧州は少し遅れていますが、追いつきつつあります。いずれにせよ、これはトップから始まり、経営のアジェンダの一番上に置かれなければなりません。
二つ目の役割は、技術パートナーにあります。今日お越しいただいたDarktraceやCheck Pointの皆さん、ありがとうございます。私たちのモデルを各組織や企業につなぎ、実際に展開して適切なタイミングで行動するには、皆さんの能力、知見、そしてチームが必要です。これは時間との勝負であり、迅速に動かなければなりません。
三つ目は政府です。政府はこの取り組みを後押しし、加速させる存在として非常に重要です。昨日、私たちはウクライナのサイバー防御を支援することを発表しました。ウクライナは昨年だけで6,000件の攻撃にさらされており、私たちのモデルが防御に役立つことになります。動きはウクライナに限りません。欧州連合のサイバーセキュリティ機関であるENISAは、2〜3週間前に、私たちのモデルを使って脆弱性を探していると報告しました。小規模な試行にもかかわらず、想定していなかった脆弱性がいくつも見つかったそうです。お気づきかもしれませんが、私は「先週」「2週間前」「3週間前」と、ずっと週単位で話しています。それほど、すべてがこの数週間のうちに起きているのです。
そして最後の役割は、私たちOpenAI自身にあります。重要インフラを担うあらゆる組織が、この技術の恩恵を受けられるようにしたいと本気で考えています。これはお金の問題であってはなりません。病院であれ公益事業者であれ、誰もが自らを守れるべきです。信頼に基づくアクセスの仕組みを通じて、私たちの技術やサイバーモデルを防御に使えるようにすべきです。だからこそ私たちは2週間前に10億ドル規模の基金を立ち上げ、資金が障壁にならないようにしました。
経営者、技術パートナー、政府、そして私たちの技術。これらをすべて組み合わせれば、このディフェンダーズ・ウィンドウを生かす大きな機会が生まれると、私たちは今日の時点で確信しています。さて、ディフェンダーズ・ウィンドウについて詳しく語るなら、私よりはるかにふさわしい人物がこの会場にいます。これから登壇するMattに、より詳しくお話ししてもらいます。ご清聴ありがとうございました。最後にまたお目にかかります。どうぞよい午後をお過ごしください。
2. サイバーモデルの能力を実務に生かす：ディフェンス・ファクトリー構想（Matt）
2.1 重要インフラを守る責任と、社内ディフェンス・ファクトリーの始動
Matt： 皆さん、本日はお越しいただきありがとうございます。私はMattと申します。OpenAIでサイバー領域のエンジニアリング責任者を務めています。今日は、サイバーモデルの能力を実際の業務にどう生かすかについてお話しします。
まず、スライドの写真をご覧ください。これが何かお分かりになる方はいらっしゃいますか。そうです、テムズ・バリアです。今日この会場に来るまで、おそらく皆さんの頭にはなかったものだと思います。この防潮堰は40年以上にわたって、ロンドン中心部を高潮による洪水から守ってきました。巨大な鋼鉄のゲートが、川を横切るように閉じる仕組みです。この守りがあるからこそ、私たちは安心して仕事に行けますし、公共サービスも安全に保たれ、今日のように一つの部屋に集まることもできます。それでも私たちは普段、その存在をほとんど意識しません。誰か別の人がその責任を引き受けてくれているからです。
この会場にいる多くの方は、まさにその感覚をよくご存じだと思います。皆さんは、社会が依存するシステムを守っていらっしゃるからです。病院、交通網、エネルギー供給、そして私たちのあらゆるビジネスが、デジタルインフラの上に成り立っています。その依存が深まるほど、サイバーセキュリティの重要性は増していきます。そしていま、AIが何が可能かを大きく変えつつあります。
その重みを、OpenAIはごく最近になって痛切に感じることになりました。この夏、これから何が起きるのかがはっきりと見えたのです。私たちのフロンティアモデルは、これまで誰にも気づかれていなかった弱点を次々と見つけていました。同時に、広く入手可能なモデルの能力も高まっていました。そこで私たちは、いまの時点では防御側が先行していると考えています。攻撃者に悪用される前に、これらのモデルを使って弱点を塞ぐことができる状況にあるということです。
そのために、まずOpenAIの社内で行動を起こす必要がありました。私たちはセキュリティチーム、アプライドエンジニアリングチーム、そして研究チームを一つにまとめました。目的は単純で、自分たちの防御を強化することでした。具体的にどう進めるかは分かっていませんでしたが、やらなければならないことだけははっきりしていました。この取り組みが出発点となり、私たちが「ディフェンス・ファクトリー」と呼ぶものが生まれました。
その構成をご説明します。モデルは、エージェントに能力を与えます。スキルは、エージェントに繰り返し実行できるワークフローを与えます。開発環境は、エージェントがソフトウェアを実際に動かし、変更をテストして検証できるようにします。エージェントには専用の環境が必要です。弱点を調査し、修正をテストする場が欠かせないからです。私たちが目指しているのは、継続的な防御への移行です。社内のディフェンス・ファクトリーの詳細については、このセッションの後半でLouからご紹介します。
2.2 「発見」から「修正」へ：社会全体で防御者の優位を生かすために
Matt： いま私たちは、何十年も隠れていた脆弱性をモデルが掘り起こす場面を目の当たりにしています。私たちのモデルは、OpenBSDに23年間潜んでいた欠陥の特定に貢献しました。またポーランドでは、私たちのサイバーモデルがMikroTik製品の脆弱性を発見しました。影響は2013年のリリースにまでさかのぼるものでした。この会場にも、23年より古いシステムを運用されている方は大勢いらっしゃるはずです。まだ明らかになっていない問題は数多く残っており、調べを進めるほどさらに見つかるだろうと私たちは予測しています。
ただし、私が強調したいのは、脆弱性を見つけること自体はそれほど面白い話ではないという点です。指摘事項を出してくれるツールは、もう何年も前から数多く存在します。そして指摘が一つ出るたびに、まったく別の確認作業が始まります。本当に正しい指摘なのか、重複していないか、すでに追跡中の案件ではないか、リスクとして受容済みのものではないか、といった確認です。私たちはこれを修正に結びつけなければなりません。組織を守るために必要なのは、指摘ではなく修正です。このギャップを埋めなければなりませんし、その修正が実際に機能することも検証する必要があります。しかも、それを迅速に行わなければなりません。弱点を見つけ出せるのと同じ能力が、攻撃者にとっても悪用を容易にするからです。私たちがこの先もずっと先行し続けられるとは考えていません。ただ、少なくとも今は先行していることは分かっています。
私が非常に誇りに思っていることの一つは、この取り組みが国家的な優先課題にもなっていることです。政府もこの問題に注目しています。サイバーシールド・イニシアチブは、エージェントを使って脆弱性を発見し、そこから重要インフラ全体での修正の自動化へと進むことを目指す取り組みです。国家規模のディフェンス・ファクトリーと考えていただくと分かりやすいと思います。世界の他の政府も同様の検討を進めており、英国政府もその一つであることを私たちは大変誇りに思っています。
私たちは、あらゆる組織が自前のディフェンス・ファクトリーを持つべきだと考えています。しかし同時に、OpenAIには多くの組織にはない強みがあることも認識しています。私たちには専任のセキュリティチームがあり、深い技術的専門性があり、フロンティアAIを使うことができます。政府、公益事業者、オープンソースソフトウェアのコミュニティが、私たちと同じ水準のアクセスを持っていることはまずありません。そして私たちが本当に肝に銘じなければならないのは、彼らのセキュリティは私たち自身のセキュリティでもあるということです。
だからこそ、私たちは公開書簡を発表しました。500の組織がこれに署名し、社会全体での対応を呼びかけています。単独では対処するリソースを持たない防御者の手に、高性能なAIを届けなければなりません。
さらに、先ほど話に出た10億ドル規模の基金も発表しました。この基金はDaybreakへのアクセス費用を補助するものです。重要インフラや不可欠なサービスを守る人々、非営利団体、オープンソースソフトウェアの関係者が、深刻な脆弱性を修正できるよう支援します。これによって防御者は先手を取ることができます。
ただし、これらをすべてつなぎ合わせる必要があります。私たちのフロンティアモデルが能力を提供します。Daybreakプログラムは、資格を持つ防御者にそのアクセスを提供します。そしてCodex Securityは、防御的なテストと、許可を得た攻撃的なテストの両面でその能力を実際の業務に生かします。ディフェンス・ファクトリーは、これらの要素を一つにまとめて継続的な防御を実現するためのフレームワークです。今日は各要素を順に説明し、最後にもう一度この全体図に戻ってきます。
今日の目的をまとめておきます。フロンティアモデルに何ができるのかを共有すること、それを実務でどう生かし、皆さんの運用にどう組み込めるかをお見せすること、そして将来さらに安全なシステムを作るための私たちの研究アプローチをご紹介することです。ディフェンダーズ・ウィンドウは開いています。長く開いたままではありませんが、今は確かに開いています。この機会を無駄にしてはなりません。それでは、ここからはLenaに引き継ぎ、私たちのフロンティアモデルの能力について詳しくご紹介してもらいます。
3. 最高水準かつ最も安全なサイバーセキュリティモデルの構築（Lena）
3.1 GPT-6 Astraのサイバー能力と実証事例
Lena： 私はLenaと申します。OpenAIで、欧州・中東・アフリカ地域のサイバープログラムをゴー・トゥ・マーケットの立場から率いています。この6か月間は、欧州で最大規模かつ最も重要な組織の皆さんと協力して、防御能力の向上に取り組んできました。今日は、私たちがどのようにして最高水準で、かつ最も安全なサイバーセキュリティモデルを作り上げたのか、そしてそれを皆さんにどうお届けできるのかをご説明します。
今月の初めに、私たちはこれまでで最も賢いモデルであるGPT-6 Astraをリリースしました。ソフトウェアエンジニアリングや専門的な業務など、日常的なタスクで大きく前進したモデルです。特にコンピューター操作が得意です。普段ご自身でこなしている事務作業の多くを任せ、モデルに皆さんのコンピューター上で処理させることができます。サイバーセキュリティの面でも大きな飛躍を遂げています。ゼロデイを含むより多くの脆弱性を見つけ出せるよう学習させており、セキュリティ上の問題をより深く掘り下げ、より有能なレッドチーマーとして振る舞えるようになっています。
ただし、能力の高さは話の一部にすぎません。人々が大規模に実務へ投入できるよう、その知能をより費用効率の高いものにしていく必要もあります。この両面での進捗を確かめるため、私たちはさまざまな評価を用いています。その一つがExploitGymです。これは、既知のソフトウェア脆弱性を、実際に動作するエクスプロイトへと仕上げられるかを試す評価です。対象には各種アプリケーションのほか、ChromeのJavaScriptエンジンやLinuxカーネルも含まれます。スコアを得るには、エクスプロイトを実際に動作させなければなりません。クラッシュを引き起こすだけでは得点になりません。
グラフの横軸は使用した出力トークン数、縦軸は課題の成功率です。GPT-5.6 Soulの成功率はおよそ30%でした。これに対してAstraは、成功件数をおよそ40%増やしながら、使ったトークンははるかに少なく済んでいます。私たちが強調したいのはこの点です。難しい課題をより多くこなしつつ、そこに至るまでの出力を大幅に減らせているということです。防御する側にとっては、手持ちのリソースでより徹底したセキュリティテストを行える可能性が広がります。
では、実際にはどのような成果が出ているのでしょうか。私たちのモデルは、社内の研究者と協力して、ChromeのJavaScriptエンジンにあった未知の脆弱性を二つ発見し、それらをつないで一つのエクスプロイトチェーンを構成しました。一つ目の欠陥はメモリ破壊を引き起こすもので、二つ目の欠陥はその破壊を足がかりに、さらに別の防御層を突破できるものでした。難しかったのは、これらの弱点がどのように連動するかを理解することでした。研究者がこの結果を検証してGoogleに報告し、Googleは修正をリリースしました。これは、こうしたツールが、私たちが毎日使うソフトウェアをすでに安全にしつつあることを示す具体例の一つです。
私たちはこの取り組みを、個別の事例にとどまらない規模へ広げています。Patch the Planetは、Trail of Bitsと共同で進めているイニシアチブで、Python、curl、Goといった広く使われているオープンソースソフトウェアの安全性向上を目的としています。私たちは専門のセキュリティ研究者に資金を提供し、私たちのモデルとCodex Securityを使えるようにしています。研究者はメンテナーと直接協力して、発見事項を調査し、パッチを開発・テストし、情報公開の調整を行います。最初の1週間だけで37件のパッチがマージされました。その中の一つであるaiohttpでは、報告された8件の問題をメンテナーがわずか数時間のうちに修正しました。私たち全員が依存しているソフトウェアを、小さなチームで支えているメンテナーにとって、これは確かな前進です。
3.2 Cyber Critical閾値への到達と、セーフガード・アラインメントの強化
Lena： 一方で、防御者を助けるのと同じ能力は、悪用される可能性もあります。モデルの能力が高まるのに合わせて、私たちのセーフガードも進化させていかなければなりません。Astraは、私たちのモデルとして初めて「Cyber Critical」の閾値に到達しました。これは防御者にとって現実的な好機であると同時に、リスクを慎重に管理する責任が伴うことを意味します。Samが以前述べたように、私たちは人類に代わってリスクを取るべきではありませんし、人間が主導権を握り続けなければなりません。
そのために、私たちのサイバーモデルには何層もの保護を施しています。有害な依頼を拒否するようモデルを学習させること、不正利用を検知してブロックすること、そして危険な振る舞いを監視することです。これらを組み合わせることで、強力なツールを防御者の手に届けながら、悪用されにくくしています。Astraではこれらの層をさらに強化しました。サイバー領域での不正利用やセーフガードを回避しようとする試みの検知精度を高めました。リスクの高いアカウントには、より厳しい制限をかけるようにしました。さらに、モデルの推論と行動そのものを精査するモニターも導入しました。これにより、モデルが指示の範囲を逸脱したときにそれを察知し、介入できるようになっています。
この責任は、私たちがこれから作るものにも及びます。安全性は常に能力の先を行っていなければなりません。だからこそ私たちは以前、フロンティアモデルの学習を一時停止し、監視とアラインメントの研究に注力しました。能力をさらに押し上げる前に、求められる安全性の基準を満たしておく必要があるからです。
こうしたセーフガードに加えて、Astraはこれまでで最もアラインメントの取れたモデルでもあります。それを確かめる方法の一つをご紹介します。私たちはモデルに難しい課題を与えます。その課題の中には、本来はスコープ外であるにもかかわらず、近道として悪用できてしまうターゲットが含まれています。本番環境のセーフガードを外した状態では、Soulはおよそ48%のケースでそのターゲットの悪用に成功しました。ところがAstraでは、このテストでスコープ外ターゲットの悪用に成功したケースは一件もありませんでした。
これが重要なのは、課題が本当に難しくなったときでも、私たちが定めた境界をモデルに守ってほしいからです。人間が主導権を保ったまま、より複雑な仕事をより安心して任せられるようにするうえで、これは意味のある前進です。
3.3 Daybreak RedとBlue、そしてCodex Security Red
Lena： 次に、これらの能力を実際にどう作り上げているかをお話しします。出発点は、フロンティアモデルが持つコーディングと推論の能力です。その上に、サイバー領域に特化した学習を重ねていきます。具体的には、脆弱性を理解すること、実際に動作するエクスプロイトを開発すること、そして結果を検証することです。こうして得られた能力を、私たちはDaybreakの「Red」と「Blue」という二つの階層で提供しています。
Daybreak Redは、私たちのサイバー関連アクセスの中で最も高いレベルです。承認を受けたセキュリティチームが、高度なレッドチーミングや実戦レベルのエクスプロイト開発のために、専門特化したモデルを使えるようにするものです。たとえば、クラッシュを実際に動作するエクスプロイトに仕立てることや、複数の弱点を連鎖させて攻撃者がどこまで侵入できるかを確かめることがこれにあたります。
しかし、エージェントにこれほどの能力を与えるのであれば、その境界も明確にしなければなりません。何をテストしてよいのか、どこまで到達してよいのかという情報を組み込み、さらにエージェントが何をしているのかを皆さんのチームが把握できるようにする必要があります。現状では、多くのチームがこうした支援インフラをすべて自前で構築しなければなりません。実行環境、ネットワーク制御、監視、証拠の収集といったものです。その分、本来のセキュリティ業務に充てる時間が削られてしまいます。
そこで本日、Codex Security Redを発表します。皆さんのアプリケーションに対するペネトレーションテストを、マネージドな形で実行できるサービスです。スコープの設定、制御、監督の仕組みがワークフローに直接組み込まれています。
流れをご説明します。まずCodexの中で、評価のスコープと交戦規定を定義します。続いて調査エージェントが、OpenAIがホストする環境で動き始めます。各エージェントは、それぞれ隔離されたサンドボックスの中で実行されます。皆さんのチームはダッシュボードでエージェントの活動を追うことができ、そこに発見事項と裏付けとなる証拠が集約されてレビューできるようになります。エージェントが皆さんのアプリケーションとやり取りする際には、外向きのリクエストはすべてネットワーク制御を通過し、ガーディアンエージェントがそのトラフィックをチェックします。これによって、エージェントが到達できる範囲と実行できる操作を制御しながら、調査を皆さんの環境に接続できます。攻撃者が実際に何を達成できるのかを、評価全体の可視性と主導権を保ったままテストできるということです。
皆さんのチームにとっての利点を整理します。まず、自前で構築・維持しなければならないインフラが少なくて済みます。実行環境、監視、発見事項を一つの画面にまとめていますので、弱点の調査と修正により多くの時間を使えるようになります。次に、隔離された環境と外向きリクエストのチェックという形で、セーフガードがワークフローに組み込まれています。これほど高性能なモデルを使うことに伴うリスクの管理に役立ちます。さらに、アプリケーションをテストし、想定される攻撃経路を調査するためのキャパシティが増えます。今いるチームのまま、徹底的で再現性のある評価を実行しやすくすることが狙いです。最後に、モデルをどう動かすかについて自信を持てるだけの制御手段を提供します。モデルがアクセスできる範囲を設定できますし、ネットワークレベルで活動をブロックしたり制限したりすることもできます。
一方、ほとんどの防御者の皆さんにとっての出発点はDaybreak Blueです。これは、私たちのフロンティアの汎用モデルを、許可されたセキュリティ業務に合わせて調整したセーフガード付きで提供するものです。コードのレビュー、アラートの調査、脆弱性の発見、そしてパッチの作成といった業務を想定しています。新たな問題を見つけることにも、たまっている脆弱性のバックログを処理していくことにも役立ちます。対象モデルにはGPT-6 Soulが含まれ、現在はLunaも加わりました。近いうちにGPT-6 Astraも追加する予定です。これにより、最新の能力を日常的な防御業務に取り入れられるようになり、仕事に合ったサイズのモデルを選べるようになります。
それでは、もう一つ実践的なワークフローを見ていただきましょう。私たちのサイバー・デプロイメント・エンジニアであるVanessaが、Codex Securityが発見事項を調査し、パッチを提案するまでの流れをお見せします。Vanessa、お願いします。
4. 実践デモ：Codex Securityによる脆弱性調査とパッチ生成（Vanessa）
4.1 コンテキストを与えたフルスキャンと、検証済み脆弱性レポート
Vanessa： 皆さん、こんにちは。これまでZoomでお会いしてきた方々に、今日こうして直接お会いできてとてもうれしく思います。サンフランシスコにいる私が早朝の打ち合わせに臨んでいるとき、皆さんの側は深夜だったということも多かったと思います。今日ここに来られて本当によかったです。それに、今日の登壇者の中でアメリカ人は私一人だけのようなので、その意味でも少し珍しい立場ですね。
今日は、ローカルのプラグインを通じてCodex Securityを使う実践的なワークフローをご紹介します。Daybreakを通じてどのように利用できるのか、プラグインとCLIを使ってソフトウェアセキュリティにどう取り組めるのかをお見せします。セキュリティ業務でCodexを使い始めた典型的なセキュリティエンジニアにとって、エンドツーエンドのワークフローがどのようなものになるかを順に見ていきます。
いま画面に映っているのは、Codexのデスクトップアプリです。ここにLadybirdのローカルコピーを取り込んであります。Ladybirdはプレアルファ段階のオープンソースのブラウザで、しばらく前からGitHubで注目を集めているプロジェクトです。私たちはPatch the Planetを通じてLadybirdとも協力しています。今回のデモについても許可をいただいており、彼らは現在Patch the Planetと連携してこのプロジェクトの堅牢化を進めています。
まず、Codexのセキュリティのセクションを開きます。ご覧のとおり、まだ何もありません。ここでは、自分たちが所有するリポジトリに対して最初のスキャンを立ち上げる場面を想定します。設定画面を見ると、選択肢が二つあります。一つはコードベース全体を評価する方法で、もう一つは変更点だけを見る方法です。後者では、プルリクエスト、未コミットの変更、あるいは特定のリビジョンを対象にできます。今日はフルスキャンを選びます。リポジトリで初めてスキャンを行う際には、通常はセキュリティスキャンを全体に対して実行したいからです。そうすることで、既存のセキュリティツールが見逃していたかもしれない新規の脆弱性を洗い出せます。
ここで特に大切な点を二つお伝えします。一つ目は、この最初のスキャンでは推論レベルを「高」または「最高」にすることをお勧めしているという点です。モデルも基本的には、利用できる中で最もフロンティアに近いものを使うべきです。今回の場合であれば、SoulやAstraを使えます。
二つ目として私が最も強調したいのは、コンテキストです。既存のセキュリティツールと、推論モデルを内部で使う仕組みとの違いはここにあります。推論モデルであれば、スキャナーにコンテキストを与え、皆さんの環境で何を探すべきかをモデルに理解させることができるのです。この例では、攻撃ベクトルを指定し、モデルに重点的に見てほしい領域を伝え、さらに追加のセキュリティコンテキストも与えています。これは、企業としてモデルに知っておいてほしい背景情報と考えていただくとよいと思います。たとえば補完的な統制、念頭に置いているビジネスロジック、あるいは自社が不正をどう定義しているかといったことです。こうした情報はすべてスキャンの前提として組み込めます。
では、スキャンを開始します。Codexがフルスキャンを実行しているのがお分かりいただけると思います。内部では、まずリポジトリの脅威モデルを作成します。今回は28,000のファイルをレビューしたうえで脅威モデルを生成しました。続いて脆弱性の候補を洗い出し、それぞれを検証し、最終的にこのレポートとしてまとめています。
中身を見てみましょう。いま表示されているのは、共有JavaScriptバイトコードキャッシュに関する脆弱性です。概要が示されていて、Codexが脆弱だと判断したファイルに基づく具体的な攻撃経路も確認できます。そのうえで、実際に脆弱性であることを検証しています。つまり、「脆弱性かもしれない」という段階から、「ソースコード上で検証した結果、真陽性だと判断した」という段階まで進んでいるわけです。影響の評価も表示されていて、この例では影響度・可能性ともに高と判定されています。繰り返しになりますが、こうした評価結果は皆さんが与えたコンテキストによって左右されます。初回のスキャンで組み込んだ追加情報や、他のファイルを通じて与えたいコンテキストが、脆弱性の影響評価に反映されるということです。
4.2 パッチの生成・検証とsecurity.mdによる文脈付与
Vanessa： ただ、一歩引いて考えると、私たちが関心を持っているのは脆弱性を表に出すことだけではありません。私自身もう何年もセキュリティの実務に携わってきましたが、この会場にいる実務経験のある多くの方と同じく、脆弱性を大量に並べただけのリストには興味がありません。私たちの目標は、最終的に修正を行い、リスクを着実に減らしていくことです。
そこで次に、実際にパッチを生成します。ここで少し立ち止まって、なぜこれが強力なのかをご説明させてください。CodexとCodex Securityは、私たちがこれまで出荷してきたソフトウェア開発エージェントの延長線上にあります。そのため、モデルが持つソフトウェアエンジニアリングの能力を、脆弱性が何かを判断するためだけでなく、どのようなパッチが効果的かを判断するためにも活用できるのです。
では、パッチを生成してみます。内部では「fix finding」というスキルが呼び出されているのが分かります。このスキルはプラグインにも、CLIにも含まれています。生成されたパッチをレビューすれば、どこが影響を受けていて、どのコードを修正する必要があるのかを正確に確認できます。このパッチをリポジトリにローカルで適用し、修正を検証して、脆弱性がもう存在しないことを確かめることもできます。
これがワークフローの一つの構成要素です。では、スキャンにどのような情報を与え、コードベースで見つかる脆弱性全体をどう捉えるべきでしょうか。その手段となるのがsecurity.mdファイルです。基本的には、セキュリティ版のagents.mdと考えていただければと思います。皆さんが最も懸念していることについて、リポジトリ単位でコンテキストを提供するファイルです。この例のように簡単に呼び出せるスキルも用意していますが、独自のコンテキストを書き込むこともできます。このファイルによって、エージェントはスキャンを実行する際に、皆さんが何を最も重要と考えているのか、どのような攻撃の脅威がありうるのか、信頼境界やビジネスロジックをどう捉えているのかを踏まえられるようになります。エージェントにコンテキストを与えるというこの考え方こそ、私たちがセキュリティのあり方を再定義するうえでの中核となる要素です。
今回は内容をレビューして問題ないことを確認したので、このファイルをリポジトリにコミットします。これで、スキャン済みで、今後の実行に向けたsecurity.mdがコミットされたLadybirdのリポジトリができあがりました。
4.3 サブエージェントによる業務連携と、CLI・SDKによる大規模展開
Vanessa： とはいえ、これだけでは、より大きな課題は解決しません。脆弱性をどうやって大規模に修正していくのか、そして手元にある既存のツールやシステムとどう連携させるのか、という課題です。ここで活用したいのがCodexの拡張性です。具体的には、Codexにスキャン結果を渡し、サブエージェントを使って各発見事項のパッチを生成させ、それらをグループにまとめさせます。そのうえで、Jiraのチケットを起票させ、レビュー用のプルリクエストを私たちに代わって作成させ、関係するエンジニアにSlackで通知させます。
ここで興味深いのは、組織内の他の関係者とやり取りし、連携できるようになっている点です。スキャンを実行する担当者と、修正を担当する担当者が別々の人であることはよくあります。私たちがいま目にしているのは、他のエンジニアと連絡を取り合いながら仕事を前に進められるよう、ワークフローが広がっていく姿です。
ここで行っているのは、先ほどお見せしたエンドツーエンドの修正ワークフローとほぼ同じ流れです。違いは、今回はサブエージェントを起動している点です。各サブエージェントがまったく同じ手順を実行しています。コードを確認し、脆弱性を把握し、パッチを生成し、それを検証します。Codexが実際にJiraのチケットを作成し、GitHubでプルリクエストを作成しているのが分かります。チケットとプルリクエストがそろい、担当者にはCodex Securityのスキャンで見つかった発見事項について、レビューすべきチケットがあるという通知が届いています。
そのチケットを開くと、Codexが作成したドラフトのプルリクエストのレビュー依頼が入っています。先ほどCodexの中で見たのと同じように、影響を受けるコードと推奨される修正を確認できます。修正が機能し、下流に影響が出ないことも検証できます。さらに、皆さんのCIパイプラインに合わせて調整し、破壊的な変更が入らないようにすることもできます。要は、すべてのチェックがグリーンで、失敗するCIテストがない状態でプルリクエストが作られるようにするということです。そうすればエンジニアの負担が軽くなり、コードそのものに集中できます。あとは「レビューの準備ができました、問題ありません」と承認して、このプルリクエストをマージするだけです。
これはワークフローを拡張・強化する方法の一つですが、唯一の方法ではありません。この6か月間で、私は文字どおり1,000社ほどの顧客とお会いしてきました。その中で大きなテーマとなったのが規模です。脆弱性が七つしかないリポジトリ一つであれば、こうした作業はとても簡単です。では、リポジトリが10,000個ある場合はどうすればよいのでしょうか。その答えがCLIとSDKです。
先ほどCodexのプラグインでご覧いただいたものは、それぞれがスキルです。これらは、多くのチームとお会いし、それぞれのワークフローを観察した結果として開発した、組み合わせ可能なスキルです。私たちはCodex Securityプラグインでのローカルな体験をそのままCLIに持ち込み、よりプログラム的に実行できるようにしました。画面のとおり、一括スキャンを実行でき、そのスキャンに割り当てるワーカーの数も指定できます。GitHubなどのソースコード管理システム上の多数のリポジトリを列挙したrepositories.csvを渡せば、それらのスキャンをまとめて開始できます。ローカルで対話的に使う体験から、プログラムによる大規模展開を重視した使い方へと移っていくわけです。
CLIは皆さんのCIの中でも使えます。たとえば、リポジトリの中に脆弱なコンポーネントが含まれていないかを確認できます。依存関係のバージョンアップに脆弱性がないかを調べることもできますし、プルリクエストが作成されたときに問題があればCIのチェックを失敗させることもできます。このように、企業全体でプログラム的に皆さんを支援する方法を考えています。
この体験をさらに良いものにするため、ここにいらっしゃるすべての企業の皆さんと引き続き協力していけることを、私たちは本当に楽しみにしています。これらはすべてオープンソースになっていて、それ自体が素晴らしいことだと思っています。より広いエコシステムとも協力して、セキュリティの取り組みを加速させていきたいと考えています。それでは、ここからはLouに引き継ぎます。私たちが社内でディフェンス・ファクトリーにどう取り組んできたかを詳しくご紹介してもらいます。皆さん、本当にありがとうございました。
5. OpenAI社内におけるディフェンス・ファクトリーの構築（Lou）
5.1 社内「コードレッド」と継続的防御のループ
Lou： Vanessa、ありがとうございました。私はLouと申します。OpenAIのサイバー部門でフィールドCTOを務めています。水を置いて、クリッカーを手に取らせてください。今日は、OpenAIが社内で進めてきた取り組み、つまり先ほどから話に出ているディフェンス・ファクトリーの構築についてお話しします。私たちが何をしてきたのか、そしてどのように進めてきたのかを詳しくご説明します。最後に、製品に関する発表も少しだけ予告させてください。来週にはDevDayがあり、今後数週間のうちにサイバー関連の発表もさらに続く予定です。
私たちはいま、エージェントが急速に進化していく世界に生きています。そうであれば、社内のシステムやサービスも、エージェントを前提としたものへと移行させていかなければなりません。Mattが冒頭で触れたとおり、私たちはOpenAI社内で「コードレッド」を発令しました。エンジニアリング、セキュリティ、研究の各部門から250人を動員し、部門横断のチームを編成しました。このチームが、ディフェンス・ファクトリーの最初のバージョンと言えるものを作り上げ、私たちが「継続的防御」と呼ぶ姿に向けて取り組みを進めました。
ここからは、私たちがたどったループを順にご説明します。多くの方にとってはなじみのある流れだと思いますが、私たちはこのループの各段階にエージェントを適用しました。
最初の段階は、当然ながらインベントリの把握です。私たちが攻撃を受けうる資産全体、エンドポイントなど、攻撃対象となりうるあらゆる領域を理解することです。
二つ目の段階として、私たちはさまざまなサイバーモデルを自社の資産全体に対して実行し、発見のプロセスを回しました。ただ、これまでのお話にもあったとおり、技術スタック全体から問題を見つけ出すこと自体は比較的簡単な部分です。そこで私たちは、動的検証にも取り組み始めました。発見事項が開発者に渡されたり修正に回されたりする前に、エージェント自身がその内容を実際に検証するというものです。
この過程では、担当者の割り当ても行いました。Slack、PagerDutyといった社内システムやソースコードを調べ、それぞれの問題を具体的に誰に引き渡して修正してもらうべきかを特定するのです。そして修正の段階では、単に直すだけでは終わりません。その修正を検証することも行いました。つまり、私たちが想定したとおりに、その修正で本当に問題が解消されているのかを確かめるのです。
5.2 既存ツールとの統合と、エージェント実行環境の構成
Lou： 技術スタックの面では、皆さんの組織にある従来のセキュリティツールは基本的にそのまま使い続けることになります。私たちも、それらすべてと統合する形で進めました。主な統合先は三つあります。一つ目は、アプリケーションを対象とするためのソースコードへのアクセスです。二つ目は、皆さんもよくご存じのセキュリティツール群です。三つ目が非常に重要で、ワークフローです。脆弱性をこのパイプラインに通して処理していくには、担当者を割り当て、チームの間で受け渡し、その状況を確認していく必要があるからです。
では、何が新しいのでしょうか。新しいのは、当然ながらエージェントです。そして、皆さんそれぞれの組織に合わせて作り込まれたスキルです。私たちが作ったスキルの一部は、Codexのプラグインやコマンドラインツールの一部として公開していますので、参考にしていただけます。ただ、皆さんのスキルは、当然ながら皆さんの組織により特化したものになるはずです。
最後の要素で、私たちにとっても鍵となったのが、エージェントを実行できる隔離環境です。特にアプリケーションについては、エージェントのすぐ横でそのアプリケーションを実際に動かせるようにしました。そうすることで、エージェントが試行を繰り返しながら、さまざまな点を検証できるようになります。
社内のディフェンス・ファクトリーの構造をご説明します。まず全体は、ネットワークの内側で動く必要があります。私たちの場合は自社のネットワークです。後ほど少し触れますが、これを製品化する際には、当然ながら皆さんのネットワークの中で動くことになります。皆さんの社内システムすべてにアクセスできる必要がありますが、同時に、ソースコードや知的財産などをすべて皆さんのネットワーク内で安全に保つことが極めて重要です。
エージェントは、そのネットワークの中にある実行環境で動きます。私たちは、この実行環境には仮想マシンが適していると考えています。コンテナを含めてさまざまな抽象化の方法がありますが、仮想マシンを選んだ理由は二つあります。一つは、強力な隔離が得られることです。もう一つは、カーネルにアクセスできることです。カーネルを使ってエージェントの各種のやり取りや、ツールの使用・呼び出しを監視できるのです。エージェントがファイルを書き換えたりしても、私たちはそれを引き続き監視できます。
その上に開発用コンテナを置いています。これはMicrosoftが策定したオープン標準をもとに構築したもので、依存関係やツールなどをすべて開発環境の中にパッケージ化できます。これによって再現性が得られ、エージェントは毎回まったく同じ環境で作業できるようになります。さらに、フックを組み込めるという利点もあります。セキュリティの観点から、たとえばFalconのセンサーを中で動かしたい、それをWizにつないで監視したいといった場合にも対応できます。そして最上位に、スキルを備えたエージェントが載ります。この構成によって、エージェントを組織全体で大規模に実行できるようになります。環境ごとスケールアップできるからです。私たちも社内の取り組みの中で、まさにそのように展開しました。
5.3 社内運用の成果指標と、製品化に向けた展望
Lou： ここで、私たちが達成した成果をいくつかの指標でご紹介します。まず動的検証では、誤検知率を1%未満にまで下げることができました。多くの組織では、この数値は50%、60%といった、はるかに高い水準にあるのが実情です。
次に担当者の割り当てでは、精度をおよそ90%まで引き上げました。まだ改善の余地はあります。ただ、これは脆弱性を各チームに引き渡したとき、そのうち90%がそのまま受け入れられたということを意味します。残りの10%は、割り当て先のチームを誤ったか、別のチームに引き継ぎ直す必要があったものです。
そして、エージェントで行った修正については、ロールバック率が1%未満でした。つまり、実施した修正の大多数がそのまま成功したということです。
最後にもう一段だけ掘り下げて、仕組みの詳細をご説明します。要するに、さまざまな社内システムからの入力と私たちのコンテキストが、Codexとエージェントが動いている環境に流れ込みます。その結果として何らかの出力が得られる、という構造です。
動的検証を例に取ると、スキャナーやツール、あるいはDaybreakが見つけた脆弱性を受け取り、それを実際に検証します。重複していないか、すでに報告済みのものではないか、社内のシステムから到達可能なのか、といった点を確かめるのです。担当者の割り当ても同じ構造で、PagerDutyやGitHubといった社内システムを入力として使います。それぞれの脆弱性の担当者が誰なのかを特定して対応づけ、各チームに確実に引き渡せるようにします。お気づきのとおり、ここには一つのパターンがあります。プロセスの最初から最後まで、基本的にはすべてこの形で動いていました。
最後に挙げたいのが、検証済みの修正です。修正を適用したうえで、エージェント専用の環境の中でアプリケーションと一緒に実行します。そうすることで、エージェントはその修正によって問題が本当に完全に解決したのかを、高い確度で判断できます。
運用体制についても触れておきます。私たちはこの取り組みに、非常に手厚く人員を割きました。サイバーモデルが極めて強力になりつつある今という時期を、OpenAIは非常に重く受け止めているからです。私たちは自社のインフラ全体でこれらのモデルを動かしたいと考え、そのために部門横断のチームを結成しました。
いま私たちは、同じパターンを一部の顧客とも実践しています。部門横断のチームを編成し、サイバーモデルを実行し、エンドツーエンドの修正フローに集中的に取り組むのです。そうすることで、それぞれの組織に固有のプロセスについて学ぶことができます。どこに引き継ぎの問題があるのか、どこで課題やボトルネックが生じているのかが見えてきます。そのうえでバックログを減らしていき、最終的には、このプロセスのできる限り多くをエージェントが担う継続的防御を作り上げることを目指します。
これが、防御者の優位を生かすために私たちが提案している方法です。脆弱性の発見と修正に集中的に取り組むこと、エージェントに専用の環境を与えること、そして最終的に継続的防御を構築していくことです。
そして現在、OpenAIはこれを製品化しようとしています。まずは自分たち自身で試し、いわゆるドッグフーディングを行っています。それに加えて、このアーキテクチャの初期バージョンを使って検証を進めている顧客もすでに何社かあります。関心のある方は、ぜひお声がけください。現時点ではキャパシティが限られており、ごく一握りの顧客とだけ取り組んでいますが、今後数週間から数か月のうちに展開を広げていく予定です。
皆さんにぜひ持ち帰っていただきたい最も大きなポイントがあります。OpenAIはモデルをリリースし、さらにツールも追加してきました。そしていま、それを顧客の皆さんが実際の運用に組み込めるようにする方法を模索しています。これは私たちがあらゆる場面で一貫していただいているフィードバックでもあります。「モデルを提供してくれたのはありがたい。でも、それを実際にどう動かせばよいのか。どうすれば自分たちの組織で成果につなげられるのか」という声です。これが、今後数週間から数か月にわたってOpenAIが最も力を入れていくテーマの一つです。ご清聴ありがとうございました。それでは、最後にMattに戻し、締めくくりをお願いします。
6. 今すぐ始めるための実践的ステップ（Matt）
6.1 次の一歩とディフェンス・ファクトリーの全体像、結びのメッセージ
Matt： ここまで、これらの能力をCodexの中でどう実践に移せるかをお見せしました。また、私たちがディフェンス・ファクトリーを継続的な取り組みとして築き上げてきた道のりもご紹介しました。最後に、皆さんがこれらすべてをどう組み合わせて始められるかをお話しします。
まず、ぜひ持ち帰っていただきたい教訓が一つあります。Louは、私たちがこれを製品として作り上げていくとお話ししました。しかし、それを待つ必要はありません。必要な部品はすでにすべてそろっていますし、私たちには待っている時間がないからです。
今日は、予防、つまり弱点を見つけて修正するという領域を最も深く掘り下げました。ただ、セキュリティチームが担っている責任はそれよりもはるかに広いことも承知しています。実際、私たちのモデルとツールを使って、インシデントの調査や対応のワークフローを構築している顧客がすでにいらっしゃいます。セキュリティ運用の業務全般に広げて活用している例もあります。私たちの方針は、そうした顧客と並走しながら学び、うまくいったことを共有し、それを製品へと落とし込んでいくことです。ディフェンス・ファクトリーについても、まさにそのように進めていきます。
皆さんがいまこの道のりのどの段階にいらっしゃるとしても、取れる実践的な次の一歩があります。
第一に、まだであればDaybreakプログラムに申し込んでください。そして、これらのツールを実際に業務で使える状態にしてください。
第二に、Codex Securityのプラグインから始めてください。Vanessaのデモでご覧いただいたとおり、まずは一つのリポジトリから小さく始めることができます。そこからCIに組み込んで実行すれば、数万、さらには数十万のリポジトリにまで容易に広げられます。
第三に、CLIとSDKを使ってください。自分たちのセキュリティツールを自ら構築し、自社の状況に合わせてカスタマイズし、さらには顧客向けに展開していくことも可能になります。
私たちが特に重要だと考えているのは、Louが触れたエージェントの実行環境です。エージェントが動作し、検証し、テストできる環境を用意しておくことが欠かせません。そこで私からの一つの提案として、Dev Containerに目を向けてみてください。必要なものをすべてパッケージ化し、再現性をもって実行できる環境を作る方法を検討していただきたいのです。それができれば、社内のテストを確実に実行できるようになります。さらに、システムの文脈と担当者の所在も明確になります。
ここで、冒頭でお見せしたこの図にもう一度戻ります。これがディフェンス・ファクトリーです。オープンなツール群のさまざまな要素を組み合わせたもので、ここにあるのは皆さん自身が組み合わせられる部品です。モデルが能力を提供し、Codexや開発ツールがその能力を実際の仕事に生かします。そしてセキュリティのワークフローが、皆さんの現在地に応じた、より具体的な出発点を提供してくれます。
顧客にとって最大の課題の一つがキャパシティであることは、私たちもよく理解しています。だからこそ、皆さんが自前で構築しなくて済むよう、エンドツーエンドの完成した製品を作っていきます。同時に私たちが大切にしているのは、これを皆さんと一緒に歩む道のりにすることです。そのために、Daybreak Defense Networkを通じた活動を進め、トレーニングや導入を支援するパートナーを集めます。そして、皆さんがディフェンス・ファクトリーを構築し、この道のりを共に進んでいけるよう支援していきます。
最後にこれだけお伝えして締めくくります。私たちは、ディフェンダーズ・ウィンドウが現実のものであると本気で信じています。だからこそ、私にとっては待たないことがとても重要なのです。今すぐ動き始めなければなりません。私たちはいま、Daybreakのモデルを使えるという好機にあります。この機会を生かせば、皆さんは先手を取ることができます。それを生かし始めることが、本当に重要です。
デジタルの世界と物理的な世界を守るには、私たち全員の力が必要です。セキュリティチーム、研究者、パートナー、メンテナーの皆さん、私たちは同じソフトウェアを共有しています。私たちが一つの修正を貢献するたびに、そして今日のような場で一つの教訓を共有するたびに、別の企業を守り、別の防御者がより速く動けるよう後押しすることができます。それこそが、私に楽観をもたらしてくれるものです。今日、皆さんがこうして集まってくださったことをとてもうれしく思います。私たちは孤立していません。私たちにはコミュニティがあり、これらの能力を実際に役立てる準備ができています。
いつの日か、私たちはこの瞬間を振り返って誇りに思うはずだと私は信じています。私たちが力を合わせ、この局面に立ち向かい、世界をより安全な場所にしたのだと。皆さんと一緒にこれを成し遂げられることを、心から楽しみにしています。本日はご参加いただき、本当にありがとうございました。